>>>>> On Fri, 27 Feb 2004 16:25:19 +0200 (EET),
>>>>> Pekka Savola <[EMAIL PROTECTED]> said:
>> 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.
> 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.
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.
> 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.
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
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
--------------------------------------------------------------------
