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

"Durand, Alain" <Alain_Durand@cable.comcast.com> Fri, 20 January 2006 02:38 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 1EzmAn-0008GL-Ax; Thu, 19 Jan 2006 21:38:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmAl-0008GG-MC for ipv6@megatron.ietf.org; Thu, 19 Jan 2006 21:38:43 -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 VAA25222 for <ipv6@ietf.org>; Thu, 19 Jan 2006 21:37:16 -0500 (EST)
Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzmJP-0000Af-8o for ipv6@ietf.org; Thu, 19 Jan 2006 21:47:40 -0500
Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.16421359; Thu, 19 Jan 2006 21:38:01 -0500
Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jan 2006 21:38:01 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 19 Jan 2006 21:34:27 -0500
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302217B32@PACDCEXCMB01.cable.comcast.com>
Thread-Topic: why 0xFFFE is used in the modified EUI-64 format
Thread-Index: AcYdNOhkhz18xF9aQyW9G0voWFMxHwANSBVy
From: "Durand, Alain" <Alain_Durand@cable.comcast.com>
To: Bob Hinden <bob.hinden@nokia.com>, JINMEI Tatuya / ???? <jinmei@isl.rdc.toshiba.co.jp>
X-OriginalArrivalTime: 20 Jan 2006 02:38:01.0605 (UTC) FILETIME=[883C9B50:01C61D6A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
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

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

I concur that the last sentence should be removed. It doesn't help to clarify the current situation
and may be read as closing the door to other future use of 0xFF and 0xFF.
 
  -  Alain.

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