I am ok with this and proper strategy for I/F ID. thanks again. /jim
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of JINMEI Tatuya / ???? > Sent: Monday, May 24, 2004 8:10 AM > To: [EMAIL PROTECTED] > Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID > > >>>>> On Thu, 20 May 2004 22:14:54 +0900, JINMEI Tatuya > >>>>> <[EMAIL PROTECTED]> 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 PROTECTED] > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > >
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
