Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis

[Philip Homburg <[e-mail]>]

> 1. In the conservative alternative, interface identifiers are
> required to have a standard length according to the type of link,
> and 64 bits is the recommended length for use in future standards,
> citing RFC 7421. I believe this to be consistent with what RFC 4291
> says today, but also at variance with what many participants would
> prefer and not fully consistent with what some people also say is
> the letter and spirit of RFC 4861 and RFC 4862 (including the
> authors of those documents).
> 
> 2. In the liberal alternative, the length of interface identifiers
> is unspecified, and 64 bits is the RECOMMENDED length, citing RFC
> 7421. I believe this to be a significant technical change to the
> current requirements set by RFC 4291, with additional complications
> that need to be described and understood, but it would be more in
> keeping with the letter and spirit of RFC 4861 (but not entirely
> with RFC 4862) and I believe more preferable to the participants
> who object to the current draft (and likely my conservative
> alternative too).

It seems to me that RFC 4291 uses the term interface identifier for what
are now two separate concepts. 

The first interface identifier concept is that for any prefix of length n,
the length of the interface identifier is 128-n. Let me call this prefix-iid.

The second iid concept is in auto configuration of addresses. I'll call this
slaac-iid.

The way I see it, any slaac-iid that is based on (pseudo)-random number 
has to be at least 64 bits. I don't see any reason for more than 64 so
exactly 64 sounds about right.

In theory, a link that has hardware MAC addresses with less than 64 bits
could define a slaac-iid that is shorter, however that precludes the use of
pseudo-random slaac-iids. So that doesn't make a lot of sense. Though we
could leave room for a future IPv6-over-foo document to do just that.

Simply put, a slaac-iid should be 64 bits.

For prefix-iids the situation is completely different. A /127 on p2p links is
standard. Various long prefixes are used in practice. There really is no
reason why a node would care about the length of an onlink prefix.
So basically, a node just has to support onlink prefixes of any length.

Note that onlink prefixes are not tied to a particular link type.