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

[Brian E Carpenter <[e-mail]>]

On 12/06/2017 13:00, Fernando Gont wrote:
> 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.

I believe that is simply false unless you want to go back to the era
of DIP switches with instructions to users to
a) choose an IID length for their new subnet
b) set the DIP switches on every device to select that length
c) then plug and play.

Otherwise LL addresses cannot be formed consistently on the
whole link.

OK, that is caricature, but without a substantial reworking of
RFC4862 I believe that is essentially what we would need, in
an automated version, before SLAAC can start.

Anway, all this is empty talk as long as the addressing architecture
*requires* 64 bits rather than *recommending* 64 bits.

   Brian