Re: why 0xFFFE is used in the modified EUI-64 format

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

>>>>> On Mon, 9 Jan 2006 09:51:48 -0800, 
>>>>> Bob Hinden <[e-mail]> said:

> Sorry for not responding sooner.

No problem, thanks for the response.

> I suspect that at the time we thought that an EUI-48 was equivalent  
> to MAC-48.  Actually until you sent your email I wasn't aware of the  
> issue.  Are there any networks that use EUI-48?

Not that I know of.

> I don't think that in practice this causes any problem since we use  
> them to create "modified-EUI-64" based interface identifiers and the  
> main technical requirement for IID is that they are unique on the list.

I agree.

> The draft is currently AUTH48 so it might be possible to change the  
> text from MAC-48 to EUI-48, but I would be concerned that this change  
> would cause confusion.  I don't think this has caused any confusion  
> for people writing IPv6 over <foo> specifications.

As I proposed in a follow-up message on this thread
(http://www1.ietf.org/mail-archive/web/ipv6/current/msg06052.html),
I'd add a note that just clarifies the mismatch.  I've attached a
proposal of changes to APPENDIX A below (marked by ">>").  We may need
to consult the IESG for making this change, but I believe this is
minor enough to incorporate at this stage and will help future readers
much.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[e-mail]

========================================================================
APPENDIX A: Creating Modified EUI-64 format Interface Identifiers
(...snip...)

   Links or Nodes with IEEE 802 48 bit MAC's

   [EUI64] defines a method to create a IEEE EUI-64 identifier from an
   IEEE 48bit MAC identifier.  This is to insert two octets, with
>> hexadecimal values of 0xFF and 0xFE (see the note below), in the
   middle of the 48 bit MAC (between the company_id and vendor
   supplied id).  For example the 48 bit IEEE MAC with global scope:

(...snip...)

   selected extension identifier.  The interface identifier would be of
   the form:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

   When IEEE 802 48bit MAC addresses are available (on an interface or a
   node), an implementation may use them to create interface identifiers
   due to their availability and uniqueness properties.

>>   Note: technically, the two-octet values to be inserted should be
>>   0xFF and 0xFF for a 48-bit MAC identifier according to [EUI64].
>>   The values shown in this document were incorrectly chosen by an
>>   accident due to confusion about the difference between EUI-48
>>   identifiers (for which 0xFF and 0xFE are used) and 48-bit MAC
>>   identifiers (MAC-48).  In practice, however, this error does not
>>   matter.  The essential requirement for an interface identifier is
>>   to be unique within the link, and it is unlikely that an EUI-48
>>   identifier, which is assigned to a non-network device, needs to be
>>   extended to be an IPv6 interface identifier.  Since implementations
>>   with interface identifiers based on the EUI-48 identifier have
>>   already been deployed, it should be less confusing to continue
>>   using the "incorrect" octets.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------