Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID

From: Erik Nordmark <[email-masked]>
Date: Fri, 27 Feb 2004 13:47:35 -0800 (PST)

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

I think you meant "unless the unicast prefix begins with 000 ..."

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

I personally think we should hard-code the /64 boundary in as few places
as possible to allow for future evolution. Your 80 bit interface ID
on some new links is one example of possible future evolution.
Another example is cases where 20 years from now having less than 64 bit 
interface IDs (or addresses allocated with DHCP from a >64 bit subnet prefix)
might fill a useful role.

Hard-coding the /64 address too me sounds like the original Arpanet design
with 8 bit network numbers and 24 bit host numbers; which was revised/relaxed
first with class A/B/C and later with CIDR.
I don't know of a technical reason why /64 needs to be a hard limit.

  Erik

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 27 Feb 2004 17:25:13 +0900

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)

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