Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]

[Erik Kline <[e-mail]>]

On 17 January 2017 at 11:18, Erik Kline <[e-mail]> wrote:
> On 17 January 2017 at 10:08, Lorenzo Colitti <[e-mail]> wrote:
>> On Tue, Jan 17, 2017 at 4:57 AM, Brian E Carpenter
>> <[e-mail]> wrote:
>>>
>>> > what's the specific rationale for this change? Is it a bug in 4291 which
>>> > you're proposing that we resolve in 4291 bis? If so, what is the bug?
>>>
>>> The bug is that in SLAAC, the IID length is a parameter, not a constant,
>>> and that in routing protocols, the prefix length is a parameter, not
>>> a constant. The addressing architecture needs to recognise that.
>>
>>
>> There is no bug here.
>>
>> What that text in 4291 says is that if you run SLAAC on a Global Unicast
>> address not starting with ::/3, then the length of the IID is 64. But when
>> running SLAAC on non-Global Unicast addresses, or Global Unicast addresses
>> in ::/3, then the length of the IID is not specified in RFC 4291 (and
>> presumably left up to the IPv6-over-foo documents).
>>
>> That is why, for example, RFC 2464 has to say that on Ethernet, the
>> link-local address "is formed by appending the Interface Identifier [...] to
>> the prefix FE80::/64". It also says that the IID length is always 64 bits
>> and SLAAC prefixes must be /64. If IPv6 all addresses were classful and the
>> IID length were always 64 bits there would be no need to say that.
>>
>> Also, I'd argue that SLAAC exists to generate IPv6 addresses that conform to
>> the addressing architecture, not the other way around. But that is not in
>> any way necessary to resolve a conflict between the two documents, because
>> there is no conflict.
>>
>>> > BTW: if the reason for the text is a perceived contradiction between the
>>> > fact that "IIDs are 64 bits" and "IPv6 addresses are aggregatable on all
>>> > bit lengths" - I don't see a contradiction.
>>>
>>> I suggest discussing that with Randy Bush.
>>
>>
>> While Randy's "I want to use smaller subnets than /64 because classful
>> addressing is stupid" is a valid position, that does not mean that there is
>> a contradiction between the two specifications.
>>
>> So again - what is the text trying to accomplish? I don't see a bug in the
>> specs. Therefore, it seems to me that the proposed text is changing the IPv6
>> architecture in a pretty fundamental way, and I don't think it's reasonable
>> to do that at the same time that we elevate it to full standard.
>
> I would tend to agree.

Actually, I think the NEW text is pretty reasonable if we could
restore the word "required" for the currently allocated unicast status
quo:

From:

   ... For all currently
   allocated unicast addresses, except those that start with the binary
   value 000, that length is 64 bits.

To:

   ...  For all currently
   allocated unicast addresses, except those that start with the binary
   value 000, that length is required to be 64 bits.

We can always produce a document that updates 4291bis for 4::/3 or
whatever we want, and the new text states so explicitly.

But I'm not convinced we should change to text that could be read to
weaken the current situation.