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

Bob Hinden <bob.hinden@nokia.com> Wed, 18 January 2006 17:55 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 1EzHX2-0004h0-0P; Wed, 18 Jan 2006 12:55:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzHX0-0004gv-Ct for ipv6@megatron.ietf.org; Wed, 18 Jan 2006 12:55: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 MAA08787 for <ipv6@ietf.org>; Wed, 18 Jan 2006 12:54:12 -0500 (EST)
Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzHfM-0003UH-FD for ipv6@ietf.org; Wed, 18 Jan 2006 13:04:17 -0500
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0IHrGVj016704 for <ipv6@ietf.org>; Wed, 18 Jan 2006 19:53:19 +0200
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2006 19:54:52 +0200
Received: from [209.157.142.164] ([10.241.59.15]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 18 Jan 2006 19:54:51 +0200
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <20060110080737.GA12312@boskop.local>
References: <y7vvexyma2k.wl%jinmei@isl.rdc.toshiba.co.jp> <02C5C0B4-6D25-410F-B87E-F9506CA2F787@nokia.com> <y7vmzi434nm.wl%jinmei@isl.rdc.toshiba.co.jp> <20060110080737.GA12312@boskop.local>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <B56E6373-DBB0-4309-B7A9-2BBC8D85A524@nokia.com>
Content-Transfer-Encoding: 7bit
From: Bob Hinden <bob.hinden@nokia.com>
Date: Wed, 18 Jan 2006 09:54:51 -0800
To: IPv6 WG <ipv6@ietf.org>
X-Mailer: Apple Mail (2.746.2)
X-OriginalArrivalTime: 18 Jan 2006 17:54:51.0829 (UTC) FILETIME=[480F2650:01C61C58]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Content-Transfer-Encoding: 7bit
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

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






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