Re: [BEHAVE] Modified EUI-64 format

[Dave Thaler <[e-mail]>]

> -----Original Message-----
> From: Rémi Després [mailto:[e-mail]]
> Sent: Friday, July 03, 2009 6:10 AM
> To: Dave Thaler
> Cc: Xing Li; Behave WG
> Subject: Re: [BEHAVE] Modified EUI-64 format
>
>
> Le 2 juil. 09 à 06:06, Dave Thaler a écrit :
>
> > Section 5.2.5 of draft-xli-behave-v4v6-prefix-00 says:
> >> The selection of the prefix length may affect the EUI-64 format,
> >> since the subnet may not be in the 64 bit boundary.  However, there
> >> is no contradiction to [RFC4291], which states that first, an
> >> interface identifier has to be unique on the LAN-or-whatever it is
> >> on.  And second, when the interface identifier is a MAC address it
> >> should be in a format related to a MAC Address - except that it is
> >> different.  So, especially given privacy addressing, we can't really
> >> assume that the router or neighboring host is going to extract a MAC
> >> address from the interface identifier and directly use it to direct
> a
> >> datagram to another host; rather, the relationship between a MAC
> >> address and an interface identifier has a level of indirection
> >> managed by Neighbor Discovery.
> >
> > While it's true there's no "contradiction" per se, there is a
> definite
> > constraint.  Specifically RFC 4291 section 2.5.1 states:
> >
> >> For all unicast addresses, except those that start with the binary
> >> value 000, Interface IDs are required to be 64 bits long and to be
> >> constructed in Modified EUI-64 format.
>
> True.
> However, this in a section on Interface Identifiers which starts with:
> "Interface identifiers in IPv6 unicast addresses are used to identify
> interfaces on a link."
> In the case of an embedded IPv4 address translated by an SIIT, the
> last 64 bits are never used "identify an interface on a link".
> Rules specified for addresses processed at the link layer need not to
> be extended to addresses that are not.
> Especially since RFC 4291 also says:
> "Except for the knowledge of the subnet boundary discussed in the
> previous paragraphs, nodes should not make any assumptions about the
> structure of an IPv6 address."
> In my understanding, this means that, unless a node is exploiting an
> IID for a link layer function, it should not constrain in any way the
> format of IPv6 addresses beyond prefixes it exploits locally.

This is rebutted in the paragraph quoted below about future technology.

> > The Modified EUI-64 format reserves the universal/local bit for that
> > use.   This is then restated in that RFC both in section 2.5.1:
> >
> >> The use of the universal/local bit in the Modified EUI-64 format
> >> identifier is to allow development of future technology that can
> take
> >> advantage of interface identifiers with universal scope.
> >
> > as well as in Appendix A, which explains that there are a number
> > of approaches, but all of them adhere to the universal/local
> > bit.
> >
> > Similarly, with privacy addresses referred to in the draft quote
> > at top, RFC 3041 section 3.2.1 point 3 forces the randomized
> > interface identifier to adhere to this requirement, so that it's
> > a 63-bit random number, not a 64-bit random number.  And with
> > CGAs, RFC 3972 section 4 point 6 similarly forces a generated
> > interface identifier to adhere to this requirement. (As an aside,
> > it also reserves the "g" bit which is actually unnecessary
> > since it's not IEEE EUI-64-derived.  RFC 4291 only discusses
> > the "g" bit for addresses derived from IEEE EUI-64's, which
> > is why RFC 3041 and a translation format can still use that bit).
> >
> > Hence it is not legal for an embedded IPv4 address to span
> > this bit unless the prefix starts with binary 000.  So either
> > a well-known prefix can be used that starts with binary 000,
> > or else any embedded (or obscured) IPv4 address has to end
> > before the 71st bit (i.e. LIR prefix length <= 38) or start
> > after it (i.e. LIR prefix length >= 71).
>
> If despite the discussion above it is concluded that embedded
> addresses that span IID "u" and "g" bits are "formally" illegal, an
> action should imho be taken to make it formally legal.
> Reasons are:
> - it is useful to keep SIIT as simple and flexible as it can be
> - there is no identified technical or operational harm (if one would
> know one, it would be worth knowing).

This would be a change to the IPv6 addressing architecture, and
_cannot_ be done by the Behave WG, only by 6man.  And it would
prevent the possibility mentioned above, which is the "identified"
issue.  It's not at all clear there'd be consensus on this, given
there are groups (like HIP?) which may actually want to use the
bit as suggested.

-Dave