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 <[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.
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. [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 --------------------------------------------------------------------
