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.

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

Regards,
RD

>
> -Dave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave