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

[[e-mail]]

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.
 - 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).
 - There is no technical reason to have a fixed IID length defined by data-link type.
 - 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.)

If that's what we want. I believe we have to think quite hard about it and we need to consider the consequences quite hard.

Ole