Re: draft-bourbaki-6man-classless-ipv6-00

[[e-mail]]

> On 9 Jun 2017, at 14:24, Fernando Gont <[e-mail]> wrote:
> 
> On 06/09/2017 10:46 AM, [e-mail] wrote:
>> 
>>> On 6 Jun 2017, at 00:25, Brian E Carpenter <[e-mail]> wrote:
>>> 
>>> On 05/06/2017 19:45, Lorenzo Colitti wrote:
>>>> On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter <
>>>> [e-mail]> wrote:
>>>> 
>>>>> None of that is the point. The point is to establish
>>>>> that routing is classless
>>>> 
>>>> 
>>>> Routing is already classless because BCP 198.
>>>> 
>>>> 
>>>>> and /64 is a parameter of specific addressing schemes.
>>>>> 
>>>> 
>>>> It *is* a parameter. The parameter's value is 64 for all unicast addresses
>>>> except those starting with 000.
>>> 
>>> The parameter's *current* value, yes. But should we really be fixing
>>> the value of the parameter once and for all in the addressing architecture?
>>> Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design
>>> assumes?
>> 
>> do we have a rationale for fixing the value in the IPv6-over-foo documents (anymore)?
> 
> At the time of this writing, we should probably be in the camp of "If
> you do slaac, better stick to 64, since it's know to work with legacy
> implementations, and besides, allows for sparse allocation (reduced
> collisions of IIDs when you pick a random one, resistance to address
> scans, etc.).
> 
> There's no compelling technical argument for mandating /64 (i.e., such
> specific value) if you do manual configuration or, for instance,
> stateful DHCPv6. And the recommendation for /64 for slaac mostly has to
> do with backwards compatibility than with anything else.

your goal is to remove the 64 bit boundary from RFC2464 et al and update RFC4862?
I intended the question for Brian, as he seemed to be of a different view.

Ole

PS: you might want to look up "legacy" in a dictionary