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

[Brian E Carpenter <brc@xxxxxxxxxxxxxx>]

OK

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM




JINMEI Tatuya wrote:
>>>>>>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
> --------------------------------------------------------------------
> 

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