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

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 10 Dec 2005 02:53:07 +0900

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 appreciate any clarification in advance,

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

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

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 14 Dec 2005 18:49:00 -0500

Hi Jinmei,
  I was confused by the same inconsistency couple of years ago and a
thread resulting from my question failed to clarify the choice. I guess
it is something we have to live with. You can look at this thread.

http://www.atm.tut.fi/list-archive/ipng/msg10039.html

Cheers
Suresh

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 15 Dec 2005 01:40:28 +0100

> an EUI-64 identifier from a 48bit MAC identifier" for network devices

"EUI-64" == "IEEE EUI-64" != "modified EUI-64".

The modification is exactly the flipped bit. See 2.5.1:

<cite>
   Modified EUI-64 format interface identifiers are formed by inverting
   the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
   forming the interface identifier from IEEE EUI-64 identifiers.  In
   the resulting Modified EUI-64 format the "u" bit is set to one (1) to
   indicate universal scope, and it is set to zero (0) to indicate local
   scope.  The first three octets in binary of an IEEE EUI-64 identifier
   are as follows:
</cite>

and the rationale is right below that:

<cite>
   The motivation for inverting the "u" bit when forming an interface
   identifier is to make it easy for system administrators to hand
   configure non-global identifiers when hardware tokens are not
   available.  This is expected to be case for serial links, tunnel end-
   points, etc.  The alternative would have been for these to be of the
   form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler
   0:0:0:1, 0:0:0:2, etc.
</cite>

I wonder how well-known the special meaning of the upper 3 bits are
to folks who work creativly with the 64 bit host ID space... and the
consequences of having them != 000 are. :-)

An IPv6 address (not derrived from a globally unique ID like ethernet
MAC) with the the upper 3 host bits != 000 and u or g bit set to 1
would be wrong. :-)

> Is this true, or was there any particular reason for the "confusing"

The only confusion exists in the head of the author of above article.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 15 Dec 2005 02:23:30 +0100

> MAC) with the the upper 3 host bits != 000 and u or g bit set to 1

s/upper 3 host bits/upper 3 bits 001 through 111 [except multicast
1111.1111 prefix]/

Best regards,
Daniel

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 15 Dec 2005 02:36:16 +0100

> The modification is exactly the flipped bit. See 2.5.1:

Please ignore my comment completely. I was thinking of the u/g bits,
which are NOT relevant to the FF-FF and FF-FE thing, unless I also fail
to count bits correctly. Nevertheless, the significance of bits #57 and
#58 are not widely known to IPv6 operators out there.

> The only confusion exists in the head of the author of above article.

No, in my head.

Looks like a mistake indeed, given that FF-FF is according to IEEE
MAC-48, and FF-FE is EUI-48.

Sorry for any confusion.

Regards,
Daniel

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 15 Dec 2005 02:53:59 +0100

On Thu, Dec 15, 2005 at 02:36:16AM +0100, Daniel Roesen wrote:
> Nevertheless, the significance of bits #57 and #58 are not widely
> known to IPv6 operators out there.

I cannot count. g-bit is bit #56, not #58. My only excuse for this mail
flood is that it's almost 3am local time here. :-Z My apologies.

Best regards,
Daniel

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 19 Dec 2005 15:58:01 +0900

>>>>> On Wed, 14 Dec 2005 18:49:00 -0500, 
>>>>> Suresh Krishnan <[email-masked]> said:

> http://www.atm.tut.fi/list-archive/ipng/msg10039.html

Thanks for the pointer.  I now understand this was indeed discussed
before.  I agree we should live with the confusing choice as a
"de-facto standard" rather than tweaking the specification once again.

But...at the risk of causing unnecessary discussion, I wonder whether
we can clarify this point in the RFC based on addr-arch-v4 just saying
the method shown in appendix A actually is inconsistent with the IEEE
standard but the IETF has decided to accept it.  I personally think
this can be done as a part of final editorial work with RFC editor
before publication.  What do others think?

					JINMEI, Tatuya