>>>>> On Wed, 18 Jan 2006 09:54:51 -0800,
>>>>> Bob Hinden <[EMAIL PROTECTED]> 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/
> 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.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
