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

From: "Bound, Jim" <[email-masked]>
Date: Tue, 25 May 2004 13:41:50 -0400

I am ok with this and proper strategy for I/F ID.
thanks again.
/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of JINMEI Tatuya / ????
> Sent: Monday, May 24, 2004 8:10 AM
> To: [email-masked]
> Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID
> 
> >>>>> On Thu, 20 May 2004 22:14:54 +0900, JINMEI Tatuya 
> >>>>> <[email-masked]> 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.
> 
> (snip)
> 
> No responses..., assuming everyone is fine with the last text 
> of mine, here is a set of concrete proposals on this issue.  
> (I'm intentionally removing the hard-coded "64"s in the 
> proposals).  Please review the proposals and make comments on 
> them (if necessary).
> 
> 1. revise the definition of "interface identifier" (at the end of
>    Section 2) as follows:
> 
>    interface identifier - a link-dependent identifier for an interface
>       that is (at least) unique per link [4]. 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 over Ethernet [2]).  Note that [4] also defines
>       the length of the interface identifiers for some set of
>       addresses, but the two sets of definitions must be consistent.
>       In many cases, the identifier will be derived from the
>       interface's link-layer address.
> 
> 2. revise the last sentence of the second paragraph of Section 5.3
>    as follows:
> 
> From:
>    [...]  If the interface identifier is more than 118 bits
>    in length, autoconfiguration fails and manual configuration is
>    required. Note that interface identifiers will typically be 64-bits
>    long and based on EUI-64 identifiers as described in [4].
> 
> To:
>    [...]  If the interface identifier is more than 118 bits
>    in length, autoconfiguration fails and manual configuration is
>    required. The length of the interface identifier is defined in a
>    separate link-type specific document, which should also be
>    consistent with [4] (see Section 2). These documents will carefully
>    define the length so that link-local addresses can be
>    autoconfigured on the link.
> 
> 3. revise the paragraph after the diagram in bullet d) of Section
>    5.5.3 as follows:
> 
> From:
>       If the sum of the prefix length and interface identifier length
>       does not equal 128 bits, the Prefix Information option MUST be
>       ignored. An implementation MAY wish to log a system management
>       error in this case. It is the responsibility of the system
>       administrator to insure that the lengths of prefixes 
> contained in
>       Router Advertisements are consistent with the length of 
> interface
>       identifiers for that link type. Note that interface identifiers
>       will typically be 64-bits long and based on EUI-64 
> identifiers as
>       described in [4].
> 
> To:
>       If the sum of the prefix length and interface identifier length
>       does not equal 128 bits, the Prefix Information option MUST be
>       ignored. An implementation MAY wish to log a system management
>       error in this case.  The length of the interface identifier is
>       defined in a separate link-type specific document, which should
>       also be consistent with [4] (see Section 2).
> 
>       It is the responsibility of the system administrator to insure
>       that the lengths of prefixes contained in Router Advertisements
>       are consistent with the length of interface identifiers for that
>       link type. It should be noted, however, that this does not mean
>       the advertised prefix length is meaningless.  In fact, the
>       advertised length has non trivial meaning for on-link
>       determination in Neighbor Discovery [5] where the sume of the
>       prefix length and the interface identifier length may not be
>       equal to 128.  Thus, it should be safe to validate the
>       advertised prefix length here, in order to detect and avoid a
>       configuration error specifying an invalid prefix length in the
>       context of address autoconfiguration.
> 
>       Note that a future revision of [4] and a future link-type
>       specific document, which will still be consistent with each
>       other, could potentially allow for an interface identifier of
>       length other than the value defined in the current documents.
>       Thus, an implementation should not assume a particular
>       constant. Rather, it should expect any lengths of interface
>       identifiers.
> 
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, 
> Toshiba Corp.
> 					[email-masked]
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------