Re: (resend) [rfc2462bis] prefix length check for existing addresses

[JINMEI Tatuya / $B?@L@x#:H(B <jinmei@xxxxxxxxxxxxxxxxxxxxx>]

>>>>> On Wed, 9 Jun 2004 07:20:06 -0700 (PDT), 
>>>>> Erik Nordmark <Erik.Nordmark@sun.com> said:

>> I first would like to know your opinion, if any, on my latest question
>> (in the separate message).  If we choose option 1 (i.e., basically do
>> nothing on this), we still might want to clarify what "match the
>> prefix" means to avoid possible confusion.

> I think we should clarify this. The word "match" is unfortunate.
> Either just saying "identical" or also stating that prefixes are
> identical when their length as well as content are the same would
> be good.

Okay, so the desired resolution (which is basically just a
clarification) would be as follows:

    d) If the prefix advertised is not equal to the prefix of an address
      already in the list of addresses associated with the interface
      (where "equal" means the two prefix lengths are the same and the
      first prefix-length bits of the prefixes are identical), and the
      Valid Lifetime is not 0, form an address (and add it to the list)
      by combining the advertised prefix with the link's interface
      identifier as follows:
      [...]

    e) If the advertised prefix is equal to the prefix of an address
      configured by stateless autoconfiguration in the list, the
      preferred lifetime of the address is reset to the Preferred
      Lifetime in the received advertisement.  [...]

The additional note on the meaning of "equal" might be trivial and
redundant, but it'll do no harm.

Also note that I've given more detailed definition of "the list" in
item d), which was in item e) in RFC2462.  I think it's an error
during the migration from RFC1971 to RFC2462.  RFC1971 had the
following organization:

 d) If the advertised prefix matches the prefix of an autoconfigured
    address (i.e., obtained via stateless or stateful address
    autoconfiguration) in the list of addresses associated with the
    interface, [...]

 e) If the prefix advertised does not match the prefix of an address
    already in the list, [...]

and RFC2462 reversed the order (probably due to introducing the
"two-hour" rule, which made the corresponding item longer) without
touching the content (except the additional rules for DoS avoidance):

    d) If the prefix advertised does not match the prefix of an address
       already in the list, [...]

    e) If the advertised prefix matches the prefix of an autoconfigured
       address (i.e., one obtained via stateless or stateful address
       autoconfiguration) in the list of addresses associated with the
       interface, [...]

With this text, the reader would wonder at item d what is "the list",
which is explained in the succeeding item.  This is unnatural.

I have one last question.  RFC2462 says just "an address already in
the list" in the case of no identical (or matched) prefix while it
says "an *autoconfigured* address in the list" in the case where there
is an identical prefix.  Does the former mean all addresses including
stateless-, stateful-, or manually- configured ones?  If so, is this
intentional?  And if so, we'll still see the problem that DHCPv6 does
not carry the information of prefix for assigned addresses...


					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp




       

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------