JINMEI Tatuya wrote: > [Note: if you've forgotten the discussion, please first refer to the > following URL (and its followups if necessary): > https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01797.html ] > > 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.
That being so, I think it is reasonable to make 2462bis immune to theoretical future changes. But I have some comments on your proposals...
In the previous discussion, some people wanted to "hard code" the assumption that the interface identifier is 64-bit long. But there was an opposite opinion that wanted to avoid the hardcoding.
I personally think it is beyond the right of rfc2462bis to hardcode the value, regardless of whether fixing the IFID length is a good idea or not. The real problem is the conflict I pointed out, which is outside of rfc2462bis. If we tried to give an "answer" in rfc2462bis, we'd implicitly affect the other documents.
Fully agree
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.
So, my basic idea is to clarify the current situation with realistic compromise.
Specifically,
- add some notes after the definition of "interface identifier" (RFC2462 section 2) as follows:
Note that [ADDR-ARCH] and the link-type specific document can
potentially conflict with each other about the length of the
interface identifier,
No they can't, because no such link-specific document should be allowed by the IESG without an explicit update to [ADDR-ARCH].
whereas there has been no conflict in the
actual specifications. The case where the two documents actually
conflict is outside the scope of this document.
So I think this note needs to be rewritten:
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.
- describe the possible conflict I pointed out in an appendix or somewhere in the document, and refer to the description from the above note.
It isn't a *conflict* if the IESG does its job. It's a possible *change*.
- emphasize that "64-bit" is not hardcoded. For example, after the following sentence of Section 5.3
Note that interface identifiers will typically be 64-bits long and based on EUI-64 identifiers as described in [ADDR-ARCH].
Actually the word "typically" is now a bug since [ADDR-ARCH] requires the length to be 64.
make an additional note like this:
It should also be noted, however, that the exact length and the way the identifier is created is defined in a separate link-type specific document. An implementations SHOULD NOT assume the typical cases, but SHOULD follow the link-type specific document.
OK but add As noted above, this would also require an update to [ADDR-ARCH].
Brian
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
