Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID

>>>>> On Wed, 19 May 2004 12:16:27 +0200, 
>>>>> Brian E Carpenter <brc@zurich.ibm.com> said:

> Jinmei, I believe your proposed new text at the bottom is correct.
> 2462bis should not open the door to conflict in future link-layer
> specs.

Okay, but after re-reading the proposed new text, I then changed my
mind a bit; it should be better to use link specific documents as the
primary source of the IFID length.  Otherwise, the implementor would
wonder how they should do if a received prefix in an RA does not match
ones for which ADDR-ARCH defines the corresponding IFID length.

So, the better text would be as follows:

   interface identifier - a link-dependent identifier for an interface
        that is (at least) unique per link [ADDR-ARCH]. Stateless
        address autoconfiguration combines an interface identifier with
        a prefix to form an address. From address autoconfiguration's
        perspective, an interface identifier is a bit string of known
        length.  The exact length of an interface identifier and the way
        it is created is defined in a separate link-type specific
        document that covers issues related to the transmission of IP
        over a particular link type (e.g., [IPv6-ETHER]).
(i.e., the same text as RFC2462)

with a note about the relationship between ADDR-ARCH and link specific
documents to avoid confusion:

	Note that [ADDR-ARCH] also defines the length of the interface
        identifiers for some set of addresses, but the two sets of
        definitions must be consistent.

It should also be good to emphasize that the implementation should not
assume the particular constant "64" like this:

   Note that a future revision of [ADDR-ARCH] and a future link-type
   specific document could potentially allow for an interface identifier
   of length other than 64 bits.  Thus, an implementation should not
   assume that particular constant.  Rather, it should expect any
   lengths of interface identifiers.

(the text you proposed in an earlier message)

Makes sense?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

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