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

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

>>>>> On Tue, 08 Jun 2004 10:07:41 +0900, 
>>>>> JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp> said:

> It seems to me that this specification allows (e.g.,) the prefix
> "::/0" to update the lifetimes all existing addresses (which may even
> include link-local addresses), since ::/0 matches any addresses.

> Is this the intended behavior? I believe not, and if not, shouldn't
> the specification be clearer to avoid this case? I believe it should.

After private e-mail exchanges, I realized I sort of misunderstood the
original text, but then found another possible issue...

RFC2462 actually says "If the advertised prefix matches ***the
prefix*** of an autoconfigured address", so the most likely
interpretation of this should be "If the advertised prefix equals to
the prefix of an autoconfigured address".  In this sense, the original
text does not have the problem I pointed out, and the meaning of
"match" is quite clear in this context.

However, there's still a possible issue with this spec in RFC2462.  It
targets addresses statefully autoconfigured addresses as well as
stateless ones:

    e) If the advertised prefix matches the prefix of an autoconfigured
       address (i.e., one obtained via stateless or stateful address
       autoconfiguration)...

and we know the stateful address autoconfiguration is DHCPv6.
However, DHCPv6 does not carry the information of prefix for addresses
being configured, so the host does not know the corresponding prefix
if the address was obtained via DHCPv6 (stateful autoconfiguration).
In this case, how can we check if "the advertised prefix matches the
prefix of an autoconfigured address"?

(BTW: I hope DHCPv6 specialists will correct me if my understanding of
DHCPv6 on this point is wrong)

Regarding rfc2462bis, the issue is a bit more subtle.  As a result of
clarifying the semantics of the M/O flags, we agreed on removing
specific behavior about the flags from rfc2462bis, and we are going to
revise the above text as follows:

    e) If the advertised prefix matches the prefix of an address
      configured by stateless autoconfiguration in the list of addresses
      associated with the interface, ...

so, the possible issue apparently disappears, while it will still
appear when we consider the effect of this for statefully configured
addresses, probably in a separate document.

Now, what should we do with this situation?  Possible actions would
include (but there may be more):

1. do nothing.  we'll consider the hidden possible issue with
   statefully configured addresses when we are ready to specify it.
2. introduce the change I proposed at the beginning of this thread (or
   a similar change Pekka mentioned).  this can apply to statefully
   configured addresses even if we decide to use the same rule
   for statefully configured addresses later.

I can live with either way, but slightly prefer option 1, since option
2 implicitly requires existing implementations to be modified (though
the implementations won't actually have to be changed because external
behavior will be the same).

I'll be listening to others for a while.  If no particular opinion is
provided, I'll simply take option 1, and close this issue without any
change on rfc2462bis (after all, this is quite a minor issue).

Thanks,

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