[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rfc2462bis issue 281] Requirement for 64bit I/F ID
I am ok with this and proper strategy for I/F ID.
thanks again.
/jim
> -----Original Message-----
> From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On
> Behalf Of JINMEI Tatuya / ????
> Sent: Monday, May 24, 2004 8:10 AM
> To: ipv6@ietf.org
> Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID
>
> >>>>> On Thu, 20 May 2004 22:14:54 +0900, JINMEI Tatuya
> >>>>> <jinmei@isl.rdc.toshiba.co.jp> 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.
> 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
--------------------------------------------------------------------