[BEHAVE] Modified EUI-64 format

[Dave Thaler <[e-mail]>]

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.

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

-Dave