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

[Fernando Gont <[e-mail]>]

On 06/11/2017 09:29 PM, [e-mail] wrote:
> Brian,
> 
>>>>> If we remove the 64 bit boundary from 4291, then an update of 2464
>>>>> will likely result in the removal of any bit boundary there as well.
>>>>
>>>> No, for the out-of-the-box reason. I can't see any practical
>>>> alternative to a fixed length per link type.
>>>
>>> I think there are practical alternatives, so I too would suggest not to state flatly that SLAAC requires fixed length IIDs. Anything that requires RAs to work can make adjustments to its IID, in real time.
>>
>> It cannot adjust its IID length when assigning itself a link-local address *before*
>> receiving any RA/PIO messages. But whatever length N of IID it uses to generate its
>> LL address must match the the prefix length 128-N in a later RA/PIO with A=1.
>> Otherwise, SLAAC fails.
>>
>> (see Section 5.5.3 bullet d of RFC4862, as Jinmei-san kindly explained to me.)
>>
>> So in fact the only thing that works is if the equipment assumes the same IID length
>> as the router announces (as 128-N). Therefore, N must be predefined.
> 
> As I said the argument is tenuous.
> This is a trivial change, if we were to go down this route. The fixed constant is a fundamental part of the IPv6 architecture. If we remove it from there, then it is a natural consequence to remove it from the IPv6 over foo documents and tweak SLAAC.
> 
> The changes to SLAAC could be in two paragraphs:
>  - LL generation. Fix IID length to 118 _or_ make IID length implementation specific.
>    The on-link prefix for LL is regardless fe80::/10.

In practice, it's /64. BSDs assume fe80::/64, and use some of the
assummed-to-be-zero words in that prefix to store e.g. interface index.


>  - IID length = 128 - length of advertised prefix. Host is required to generate IID of suitable length per advertised prefix.
>    (or just generate a 128 bit IID, and chop of the bits needed.
> 
> 
> To summarize:
>  - There is no technical reason why SLAAC cannot be made ot work with arbitrary prefix lengths.
>    (including very long prefixes, although it might take a while to find a non-duplicate if the addressing model
>    moves from sparse to dense).

+1


>  - There is no technical reason to have a fixed IID length defined by data-link type.

+1


>  - Removing the constant from the addressing architecture will likely set these changes into motion.
>    (i.e. I don't think a position where one wants to remove the 64 bit constant from 4291 and expect the 64 bit boundary
>     to stay in IPv6 over foo is tenable.)

Me, I don't think there's a reason to keep the 64 bit constant in
ipv6-over-foo documents. Actually, with RFC8064 in place, there's no
reason why the IID should be link-type dependent.


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