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

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

Erik,

On 17/01/2017 15:36, Erik Kline wrote:
> 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.

I could live with that. The "currently allocated" is the point.

    Brian

> 
> 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.
>