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

From: Bob Hinden <[email-masked]>
Date: Mon, 9 Jan 2006 09:51:48 -0800

Jinmei,

Sorry for not responding sooner.

On Dec 9, 2005, at 9:53 AM, ext JINMEI Tatuya / 神明達哉 wrote:

> I believe this was discussed and clarified before, but I could not
> find any pointer, so let me ask here...
>
> It's regarding the "magic number" of 0xFFFE used in the modified
> EUI-64 format for the interface identifier of an IPv6 address.
>
> According to draft-ietf-ipv6-addr-arch-v4-04.txt (or already-published
> RFCs), we insert 0xFFFE in the middle of the interface identifier in
> order to convert an 48-bit MAC address to the modified EUI-64 format:
>
>    [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, in the middle of the 48 bit  
> MAC
>    (between the company_id and vendor supplied id).
> (in APPENDIX A)
>
> However, according to [EUI64], we use 0xFFFF (not 0xFFFE) "to create
> an EUI-64 identifier from a 48bit MAC identifier" for network devices
> (i.e., MAC-48):
>
> To support encapsulation of EUI-48 and MAC-48 values within small
> subsets of the EUI-64 values, the first four digits of the
> manufacturer's extension identifier shall not be FFFF16 or
> FFFE16. Thus, the 64-bit values of the following form are
> never-assigned EUI-64 values:
>
>    ccccccFFFEeeeeee(16)   (an EUI-48 extension)
>
>    ccccccFFFFeeeeee(16)   (a MAC-48 extension)       <==== this one
> (from http://standards.ieee.org/regauth/oui/tutorials/EUI64.html)
>
> My question is whether there was any special reason why the IPv6
> addr-arch document specified 0xFFFE.
>
> I googled and found a web page saying this is "an error":
>
>   Confusingly IPv6 -- one of the most prominent standards that uses
>   EUI-64 -- applies these rules inconsistenly. Due to an error in the
>   appendix to the specification of IPv6 addressing, it is currently
>   standard practice in IPv6 to extend MAC-48 addresses (such as  
> IEEE 802
>   MAC address) to EUI-64 using 'FF-FE' rather than 'FF-FF'; it remains
>   to be seen how this inconsistency will be resolved in the future.
> (http://www.kingj.com/articles/MAC_address)
>
> Is this true, or was there any particular reason for the "confusing"
> choice?

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?

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.

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.

Bob

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 10 Jan 2006 16:47:57 +0900

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

> Sorry for not responding sooner.

No problem, thanks for the response.

> issue.  Are there any networks that use EUI-48?

Not that I know of.

> main technical requirement for IID is that they are unique on the list.

I agree.

> 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.
					[email-masked]

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

   Links or Nodes with IEEE 802 48 bit MAC's

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jan 2006 09:07:37 +0100

On Tue, Jan 10, 2006 at 04:47:57PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:

> proposal of changes to APPENDIX A below (marked by ">>").

I support the addition of this clarification.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Bob Hinden <[email-masked]>
Date: Wed, 18 Jan 2006 09:54:51 -0800

Hi,

Here is the text I propose to send to the RFC-Editor to resolve the  
issue.  Take a look and let me know it is is OK.

Thanks,
Bob

> Appendix A: Creating Modified EUI-64 Format Interface Identifiers
>
.........

>    Links or Nodes with IEEE 802 48-bit MACs
>
>    [EUI64] defines a method to create an IEEE EUI-64 identifier  
> from an
>    IEEE 48-bit MAC identifier.  This is to insert two octets, with
>    hexadecimal values of 0xFF and 0xFE, in the middle of the 48-bit  
> MAC

s/0xFE,/0xFE (see the Note at the end of appendix),/

>    (between the company_id and vendor-supplied id).  An example is the
>    48-bit IEEE MAC with Global scope:
>
>    |0              1|1              3|3              4|
>    |0              5|6              1|2              7|
>    +----------------+----------------+----------------+
>    |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
>    +----------------+----------------+----------------+
>
>    where "c" is the bits of the assigned company_id, "0" is the  
> value of
>    the universal/local bit to indicate Global scope, "g" is
>    individual/group bit, and "m" is the bits of the manufacturer-
>    |0              1|1              3|3              4| 
> 4              6|
>    |0              5|6              1|2              7| 
> 8              3|
>    When IEEE 802 48-bit 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.

.....

Add:

Add to the end of the appendix:

    Note: [EUI-64] actually defines 0xFF and 0xFF as the bits to be
    inserted to create an IEEE EUI-64 identifier from an IEEE MAC-48
    identifier.  The 0xFF and 0xFE values are used when starting with an
    IEEE EUI-48 identifier.  The incorrect value was used in earlier
    versions of the specification due to an misunderstanding about the
    differences between IEEE MAC-48 and EUI-48 identifiers.

    This document purposely continues the use of 0xFF and 0xFE  
because it meets
    the requirements for IPv6 interface identifiers, specifically that
    they must be unique on the link, and that it doesn't cause any
    problems in practice.  If in the future, a new link type is invented
    that uses IEEE EUI-48 and MAC-48 identifiers on the same link, the
    0xFF and 0xFF values could be used to convert the EUI-48 identifiers
    for use as IPv6 interface identifiers to avoid any potential for
    duplicate interface identifiers.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 19 Jan 2006 13:40:42 +0900

>>>>> On Wed, 18 Jan 2006 09:54:51 -0800, 

>     versions of the specification due to an misunderstanding about the

s/an misunderstanding/a misunderstanding/

>     duplicate interface identifiers.

I said 'personally' because it may be controversial to mention the
possibility of the future use of 0xFFFF at this stage (i.e., it may be
beyond the level of 'clarification').  But if the IESG accepts the
description (or the RFC editor agrees this is minor enough), I'm happy
with that.

					JINMEI, Tatuya

---

From: Bob Hinden <[email-masked]>
Date: Thu, 19 Jan 2006 12:05:50 -0800

Jinmei,

> s/an misunderstanding/a misunderstanding/

Thanks, I will fix this.

> description (or the RFC editor agrees this is minor enough), I'm happy

It's only a note at the end of an appendix, but I wouldn't object to  
removing the last sentence if others are troubled by it.  The intent  
was to provide some advice to someone writing an IPv6 over <foo>  
specification.

Thanks,
Bob

---

From: Bob Hinden <[email-masked]>
Date: Fri, 20 Jan 2006 12:10:01 -0800

Before submitting the new text, I went back and tried to find out  
what the difference is between an MAC-48 and an EUI-48.  In the  
document:

    http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html

I found the following:
   "The (obsolete label) MAC-48 is a concatenation of a 24-bit OUI  
assigned by the IEEE Registration Authority and a 24-bit extension  
identifier assigned by the organization with that OUI assignment.

The EUI-48™ is a concatenation of a 24-bit OUI value assigned by the  
IEEE Registration Authority and a 24-bit extension identifier  
assigned by the organization with that  OUI assignment."

and:

   "The use of the MAC-48 identifier is obsolete; the EUI-48 or  
EUI-64 should be used in current and future applications requiring  
the use of unique 48-bit identifiers."

My reading of this is that from a technical point of view MAC-48 and  
EUI-48 are equivalant.  They are both have the same definition:

   Mac-48:  "a concatenation of a 24-bit OUI assigned by the IEEE  
Registration Authority and a 24-bit extension identifier assigned by  
the organization with that OUI assignment"

   EUI-48:  "a concatenation of a 24-bit OUI value assigned by the  
IEEE Registration Authority and a 24-bit extension identifier  
assigned by the organization with that OUI assignment"

They both use the same 24-bit OUI values.  It looks to me like IEEE  
decided to deprecate the name MAC-48.  Why IEEE choose to have two  
different ways to create EUI-64 from these 48-bit identifiers is a  
mystery to me.  As far as bits on the wire, EUI-48 and MAC-48 appear  
to be exactly the same.  The link in Jinmei's email that started this  
discussion confirms this:

"The distinction between EUI-48 and MAC-48 identifiers is purely  
semantic: MAC-48 is used for network hardware; EUI-48 is used to  
identify other sorts of devices and software. (Thus, by definition,  
an EUI-48 is not in fact a "MAC address", although it is  
syntactically indistinguishable from one and assigned from the same  
numbering space.)"

I will still plan to submit the new text as it clarifies our use of  
these identifiers.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Fri, 20 Jan 2006 14:24:06 -0800

One more thing,

On Jan 20, 2006, at 12:10 PM, Bob Hinden wrote:

> ....
> mystery to me.  As far as bits on the wire, EUI-48 and MAC-48  
> appear to be exactly the same.  The link in Jinmei's email that  
> started this discussion confirms this:
>

On further thought, I will change the last paragraph of the Note to:

    This document purposely continues the use of 0xFF and 0xFE  
because it meets
    the requirements for IPv6 interface identifiers (i.e., that they  
must be unique on
    the link), IEEE EUI-48 and MAC-48 identifiers are syntactically  
equivalent,
    and that it doesn't cause any problems in practice.

Let me know if anyone objects.

Thanks,
Bob