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

JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Fri, 09 December 2005 17:53 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkmRA-0000Xx-P8; Fri, 09 Dec 2005 12:53:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkmR8-0000X2-L3 for ipv6@megatron.ietf.org; Fri, 09 Dec 2005 12:53:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07437 for <ipv6@ietf.org>; Fri, 9 Dec 2005 12:52:37 -0500 (EST)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkmRE-0004ba-W3 for ipv6@ietf.org; Fri, 09 Dec 2005 12:53:46 -0500
Received: from impact.jinmei.org (PPP430.air-4x8x.dti.ne.jp [210.170.213.216]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2BA6C1521A for <ipv6@ietf.org>; Sat, 10 Dec 2005 02:53:14 +0900 (JST)
Date: Sat, 10 Dec 2005 02:53:07 +0900
Message-ID: <y7vvexyma2k.wl%jinmei@isl.rdc.toshiba.co.jp>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
To: ipv6@ietf.org
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: 1.4 (+)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Subject: why 0xFFFE is used in the modified EUI-64 format
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

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.
					jinmei@isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------