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