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

Bob Hinden <bob.hinden@nokia.com> Mon, 09 January 2006 23:15 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 1Ew6F4-00083p-O2; Mon, 09 Jan 2006 18:15:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew6F2-00083a-VD for ipv6@megatron.ietf.org; Mon, 09 Jan 2006 18:15:57 -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 SAA06887 for <ipv6@ietf.org>; Mon, 9 Jan 2006 18:14:37 -0500 (EST)
Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew6La-0001Gg-Vc for ipv6@ietf.org; Mon, 09 Jan 2006 18:22:45 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k09NBKsj006132; Tue, 10 Jan 2006 01:11:23 +0200
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jan 2006 01:15:46 +0200
Received: from [10.100.0.33] ([10.241.59.170]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Jan 2006 01:15:46 +0200
In-Reply-To: <y7vvexyma2k.wl%jinmei@isl.rdc.toshiba.co.jp>
References: <y7vvexyma2k.wl%jinmei@isl.rdc.toshiba.co.jp>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset="UTF-8"; delsp="yes"; format="flowed"
Message-Id: <02C5C0B4-6D25-410F-B87E-F9506CA2F787@nokia.com>
Content-Transfer-Encoding: quoted-printable
From: Bob Hinden <bob.hinden@nokia.com>
Date: Mon, 09 Jan 2006 09:51:48 -0800
To: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
X-Mailer: Apple Mail (2.746.2)
X-OriginalArrivalTime: 09 Jan 2006 23:15:46.0369 (UTC) FILETIME=[9EF10B10:01C61572]
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Content-Transfer-Encoding: quoted-printable
Cc: ipv6@ietf.org
Subject: Re: 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

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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------