[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.
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.
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.
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, 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.
- describe the possible conflict I pointed out in an appendix or
somewhere in the document, and refer to the description from the
above note.
- 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].
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.
Is this a reasonable approach?
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
--------------------------------------------------------------------
