I've been thinking about this issue for a while. Currently, I'm not
sure if we need to do something in rfc2462bis for this issue.
I originally thought RFC2462 had some sort of assumption that an
interface identifier is 64 bits long at least for some cases.
Looking at RFC2462 again, however, I've not found such an assumption.
The only parts in RFC2462 that mentions "64 bits" are as follows:
Note that interface identifiers will typically be 64-bits
long and based on EUI-64 identifiers as described in [ADDR-ARCH].
(Section 5.3 of RFC2462)
And section 5.5.3 bullet d) has exactly the same sentence. (BTW: the
latest rfc2462bis draft lacks this part by an accident. I'll recover
it in the next revision.)
None of them assumes anything about the prefix length. In this sense,
I guess we could take the option of "do nothing".
However, I still see some unclear points around the issue.
According to Section 2 of RFC2462, the length of an interface
identifier is dependent on the corresponding link:
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]). ...
And, in fact, [IPv6-ETHER] (RFC2464) specifies that the length of
interface identifiers for an Ethernet link is 64 bits:
The Interface Identifier [AARCH] for an Ethernet interface is based
on the EUI-64 identifier [EUI64] derived from the interface's built-
in 48-bit IEEE 802 address. ...
An IPv6 address prefix used for stateless autoconfiguration [ACONF]
of an Ethernet interface must have a length of 64 bits.
(Section 4 of RFC2464)
(Note: the latter part actually specifies the length of the prefix,
but the result is the same: interface IDs are also 64(=128-64) bits.)
On the other hand, the IPv6 address architecture document seems to say
the length of interface IDs is (at least partly) determined by the
address format. For example, draft-ietf-ipv6-addr-arch-v4-00.txt says
in Section 2.5.1 that:
For all unicast addresses, except those that start with binary value
000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.
RFC3587 (Global Unicast Address Format) also adopts this convention:
[ARCH] also requires that all unicast addresses, except those that
start with binary value 000, have Interface IDs that are 64 bits long
and to be constructed in Modified EUI-64 format.
(Section 3 of RFC3587)
Which one is correct? Is the length of IF IDs determined by the link
type, or the address format, or both? If the answer is "both", there
may be inconsistency in future specification. For example, what if a
future IPv6-over-FOO document specifies like this?
An IPv6 address prefix used for stateless autoconfiguration [ACONF]
of a FOO interface must have a length of 80 bits.
Will we then have to give up using stateless address autoconfiguration
with unicast prefixes beginning with "000" in this link?
Technically, this is not necessary a contradiction. [IPv6-ETHER] only
requires 64-bit IF IDs for stateless address autoconfiguration, so the
above (imaginary) IPv6-over-FOO document and the addr-arch document
can coexist without conflicting each other if we give up stateless
autoconfiguration in this link. But is this a realistic option?
Please someone clarify this point. Then I'll consider what is
necessary for rfc2462bis (or whether we need to do something in the
first place) for this matter.
Thanks,
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
--------------------------------------------------------------------
