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

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 27 Feb 2004 22:58:47 +0900 (JST)

> 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.
(snip)
> 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.

	i guess it is either:
	- interface ID is always 64 bit, no matter what.  addr-arch should be
	  simplified and state that interface ID is 64 bit.
	- stateless addrconf (and maybe ND?) is currently defined only for
	  unicast prefixes starting with "001", where interface ID is 64 bit.
	  stateless addrconf (and maybe ND) for other unicast prefixes is left
	  as a homework for readers.

	i really hate the latter, as the latter means that currently-available
	implementation won't work for unicast prefixes other than "001".
	let us pick the former and simplify.

itojun

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 27 Feb 2004 16:25:19 +0200 (EET)

> 	  as a homework for readers.

How about:

        - stateless address autoconf is only defined when the prefix 
is 64 bits.  If the received router advertisement has some other 
prefix length, don't use the prefix.

I guess this is close to your first assumption -- only, I would 
probably not revise addr-arch at all.  That's beyond the scope of this 
document IMHO.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sun, 29 Feb 2004 17:34:42 +0900

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

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

Oops, that's right.  Thanks for the correction.

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

I tend to agree, though I know we have a different opinion.

The difficult point here is that this is actually not an RFC2462
issue, but a consistency issue about the definition of interface
identifiers in various documents.  Currently I don't have a good idea
on how to resolve it without affecting other documents much.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 01 Mar 2004 01:51:12 +0900

>>>>> On Fri, 27 Feb 2004 16:25:19 +0200 (EET), 
>>>>> Pekka Savola <[email-masked]> said:

> prefix length, don't use the prefix.

As I said in a separate message, I want to avoid introducing hard
limits like this as much as possible.  We still have a possibility in
the future that we have a new link type whose "IPv6 over xx" document
requires non 64 bit identifier.  And, in this case, we can use
stateless autoconfiguration per RFC2462 for a global prefix starting
with the bit "000" without conflicting any documents (i.e., RFC2462,
addr-arch, and the "IPv6 over foo").  I don't see a valid reason to
kill the possibility in rfc2462bis.

> probably not revise addr-arch at all.  That's beyond the scope of this 

I agree that revising addr-arch is beyond the scope of the 2462bis
work.  But then we can only make rfc2462bis a little bit clearer,
because the possible conflict exists at the border between the
addr-arch and the "IPv6 over foo" document.

So, assuming we will not change the other documents (soon), what we
can do in rfc2462bis, IMO, is:

1. say rfc2462bis adopts the definition of interface identifiers as a
   per link notion (i.e., based on each "IPv6 over foo" doc), just as
   currently described in RFC2462 and bis.
2. add a note that this interpretation may conflict with addr-arch
   because the latter (at least partly) defines the interface
   identifiers as a per address-format notion.  Also note that this
   does not currently cause a problem, because the two interpretations
   happen to be synchronized so far (i.e., all known links use 64-bit
   identifiers).
3. note that the possible conflict may cause a trouble in rfc2462bis
   in the future but how to solve it is beyond scope of the document.

This way, we can make the specification clear under the limitation of
the current situation.  The possible conflict currently does not cause
a problem, and this will probably be the case for the foreseeable
future.  Someday (hopefully), if the addr-arch and IPv6 over foo
documents are aligned, the implicit problem in rfc2462bis will go
away, too.

Can this be a reasonable compromise?

					JINMEI, Tatuya