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

[Erik Kline <[e-mail]>]

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.