Re: Why /64 [was Deprecating EUI-64 Based IPv6 Addresses]

[Alexandru Petrescu <[e-mail]>]

Le 27/10/2013 15:36, Fernando Gont a écrit :
> On 10/26/2013 03:41 AM, Tim Chown wrote:
>>>
>>> That's why I think that relaxing the /64 requirement is a whole
>>> different game. -- If anything, a first step would be to relax this
>>> for hosts, and *at some point in the future*, relax it for routers
>>> -- otherwise, a "legacy" host that expects a /64 might break or
>>> fail to do SLAAC if an updated router where to advertise, say, a
>>> /80.
>>>
>>> OTOH, deprecating Modified EUI-64 is a local policy which is
>>> incrementally-deployable.
>>
>> Well yes, there’s obviously a large deployed code base where /64 has
>> been assumed. And changing that assumption may simply not be
>> practical.
>
> I'm not sure about whether that's practical or not.. but just wanted to
> note that it's a different game.
>
>
>
>> But… for example, some people who were concerned over the ND cache
>> problem have run with /120 and DHCPv6.
>
> Those should call a lemon a lemon, and ask their vendors to fix their ND
> implementations ;-).
>
>
>> I’m not advocating that.
>> Indeed the homenet arch text specifically mentions not using such
>> “tricks" where the ISP only allocates one /64 to a home which
>> requires multiple subnets.
>
> So.. what do ou do in that case... IPv6 NAT?

There is also this NPT... and I wonder whether it has this 64bit limit 
or not.

Alex

>
>
>
>> I’m just suggesting it would be interesting to spend a little time to
>> figure out where the /64 really is “burnt in” so that, if there were
>> a desire to explore proposing a /80 or /96 or whatever for a future
>> SLAAC, we would have a clearer idea of what the implications would
>> be, and how/if an incremental progression to variable length SLAAC
>> could be facilitated.
>
> Agreed.
>
> Thanks,
>