Re: why 0xFFFE is used in the modified EUI-64 format
Bob Hinden <bob.hinden@nokia.com> Thu, 19 January 2006 20:06 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 1Ezg2l-0004zg-18; Thu, 19 Jan 2006 15:06:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezg2h-0004zM-Ec for ipv6@megatron.ietf.org; Thu, 19 Jan 2006 15:06:01 -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 PAA22577 for <ipv6@ietf.org>; Thu, 19 Jan 2006 15:04:32 -0500 (EST)
Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzgBI-0003WV-BQ for ipv6@ietf.org; Thu, 19 Jan 2006 15:14:52 -0500
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0JK3Y9J003540; Thu, 19 Jan 2006 22:03:38 +0200
Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jan 2006 22:05:52 +0200
Received: from [172.19.69.50] ([172.19.69.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 19 Jan 2006 22:05:52 +0200
In-Reply-To: <y7v64ogbzjp.wl%jinmei@isl.rdc.toshiba.co.jp>
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> <B56E6373-DBB0-4309-B7A9-2BBC8D85A524@nokia.com> <y7v64ogbzjp.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: <09818EB9-9B8C-4B1D-8414-4D05F23287A8@nokia.com>
Content-Transfer-Encoding: quoted-printable
From: Bob Hinden <bob.hinden@nokia.com>
Date: Thu, 19 Jan 2006 12:05:50 -0800
To: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
X-Mailer: Apple Mail (2.746.2)
X-OriginalArrivalTime: 19 Jan 2006 20:05:52.0522 (UTC) FILETIME=[BFCF76A0:01C61D33]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: quoted-printable
Cc: IPv6 WG <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, On Jan 18, 2006, at 8:40 PM, JINMEI Tatuya / 神明達哉 wrote: >>>>>> On Wed, 18 Jan 2006 09:54:51 -0800, >>>>>> Bob Hinden <bob.hinden@nokia.com> said: > >> 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. > > I personally support this text with one very minor nit: > >> 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 > > s/an misunderstanding/a misunderstanding/ Thanks, I will fix this. >> 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. > > 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. 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- why 0xFFFE is used in the modified EUI-64 format JINMEI Tatuya / 神明達哉
- Re: why 0xFFFE is used in the modified EUI-64 for… Suresh Krishnan
- Re: why 0xFFFE is used in the modified EUI-64 for… Daniel Roesen
- Re: why 0xFFFE is used in the modified EUI-64 for… Daniel Roesen
- Re: why 0xFFFE is used in the modified EUI-64 for… Daniel Roesen
- Re: why 0xFFFE is used in the modified EUI-64 for… Daniel Roesen
- Re: why 0xFFFE is used in the modified EUI-64 for… JINMEI Tatuya / 神明達哉
- Re: why 0xFFFE is used in the modified EUI-64 for… Bob Hinden
- Re: why 0xFFFE is used in the modified EUI-64 for… JINMEI Tatuya / 神明達哉
- Re: why 0xFFFE is used in the modified EUI-64 for… Juergen Schoenwaelder
- Re: why 0xFFFE is used in the modified EUI-64 for… Bob Hinden
- Re: why 0xFFFE is used in the modified EUI-64 for… JINMEI Tatuya / 神明達哉
- Re: why 0xFFFE is used in the modified EUI-64 for… Bob Hinden
- RE: why 0xFFFE is used in the modified EUI-64 for… Durand, Alain
- Re: why 0xFFFE is used in the modified EUI-64 for… Bob Hinden
- Re: why 0xFFFE is used in the modified EUI-64 for… Bob Hinden
- Re: why 0xFFFE is used in the modified EUI-64 for… Bob Hinden
- RE: why 0xFFFE is used in the modified EUI-64 for… Manfredi, Albert E