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

[Lorenzo Colitti <[e-mail]>]

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.