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.
Brian
JINMEI Tatuya wrote:
On Tue, 18 May 2004 17:46:15 +0200, Brian E Carpenter <[EMAIL PROTECTED]> said:
In this message, I pointed out that there might be possible conflict between the IPv6 address architecture and link specific documents (e.g. IPv6 over ethernet), and asked how we can clarify the point.
Unfortunately, I've not seen a direct answer to the question...I now think it's time to decide how we should deal with this issue in rfc2462bis.
First of all let's not forget that the addressing architecture is 100% unambiguous in saying that unicast interface IDs are required to be 64 bits, so a link-specific document that attempted to define a different ID length would be in direct conflict with RFC 3513. So the question *cannot* arise unless RFC 3513 is updated or the IESG approves something that is broken.
I don't think I forgot the point. I know RFC3513 and RFC 3587 are 100% unambiguous. I know link-specific documents (e.g. IPv6 over ethernet) are also 100% unambiguous. The problem is that the two sets of unambiguous documents may conflict with each other or at least the two sets may seem to conflict for implementors.
But at the same time, I guess it is irresponsible to leave the RFC2462 text on this point as is, because we know this issue has been annoying implementors.
In my view, only because they failed to review the addressing architecture, which is unambiguous.
I don't think so, because RFC2462 uses link-specific documents as the primary source about (the length of the) the IFID:
interface identifier - a link-dependent identifier for an interface that is (at least) unique per link [ADDR-ARCH]. [...] 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]).
BTW: according to what you were saying, it seems to me that
1. the primary source should actually be the ADDR-ARCH document, not link-specific documents 2. link-specific documents must be consistent with ADDR-ARCH. If not, the IESG will reject the document.
If this is the case, I'm just happy with it (is there any direct reference which states that ADDR-ARCH is the primary?). Then it will probably be enough to revise the definition to:
interface identifier - a link-dependent identifier for an interface that is (at least) unique per link [ADDR-ARCH]. [...] The exact length of an interface identifier is defined in [ADDR-ARCH] based on the address format. 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]).
perhaps with a note like this:
The link-type specific document may also define the length of the interface identifier. However, it must be consistent with the definition in [ADDR-ARCH].
(If there is a reference that I asked above, it's also good to add the reference here.)
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 --------------------------------------------------------------------
