Architecturally, this appears to be the correct solution.
(I would expect a lot of protest at any proposal to *actually* deviate from 64 bits, but that is another discussion.)
Brian
JINMEI Tatuya wrote:
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 --------------------------------------------------------------------
