V6 still not supported
jmaimon at jmaimon.com
Sun Mar 27 04:17:10 UTC 2022
Owen DeLong wrote:
>> On Mar 24, 2022, at 21:18 , James R Cutler
>> <james.cutler at consultant.com <mailto:james.cutler at consultant.com>> wrote:
>> On Mar 24, 2022, at 9:25 PM, Owen DeLong via NANOG <nanog at nanog.org
>> <mailto:nanog at nanog.org>> wrote:
>>> I think that we’re still OK on allocation policies. What I’d like to
>>> see is an end to the IPv4-think in large ISPs, such as Comcast’s
>>> continued micro allocations to their customers.
>> What exactly is your definition of “micro allocations”? Is a
>> prefix/56 a “micro allocation”? In over nine years of being an active
>> forum participant and customer of Comcast, I can not recall the usage
>> of the term.
> They’re issuing /60s (maximum) to residential customers.
> And yes, a /56 is a micro allocation. /48 is the intended norm for
> IPv6 site assignments and is a perfectly reasonable prefix size for v6
> delegation to a site.
/48 as universal site assignments is a ridiculousness that should never
be a norm, and unsurprisingly in the real world it isnt.
Now if your goal is to pick a number which will never change and is
large enough to work for any assignment anywhere for any network
topology ever, well you found it.
However, thats a solution in search of a problem. Which causes its own
A /48 gives 16 bits of /64 subnetting for the site.
Which is the same number of bits initial default ISP /32 has. Ridiculous
in either direction.
If you apply the same logic to ISP's that you have to end user site
assignments (which is descended from the same logic as /64 subnets), you
need to move left. Again. Goodbye limitless ipv6.
Or you can move right on the /64 nonsense. SLAAC does not|should not
need /64. Or, SLAAC isnt needed at all. Chaining DHCP to SLAAC is more
More information about the NANOG