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

[Fernando Gont <[e-mail]>]

On 06/09/2017 09:25 PM, [e-mail] wrote:
>>>>> 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?

No. I'm just saying that such specific value is an historical artifact,
not a technical one.

It's fine for the /64 to stay for slaac -- although the more clear we
make it that its a parameter, rather some value that came from an
oracle, the better.



> 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

Agreed. I meant "implementations that expect /64", which are likely to
be a lot (if not all) nowadays. (not sure why I used the term "legacy")

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492