V6 still not supported

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.
>
> Owen
>
/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 
problems.

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 
nonsense.

Joe