>>>>> On Thu, 10 Jun 2004 11:49:59 -0700 (PDT),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
>> 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...
> I don't think there was an intent when 2462 was written that
> it affect the lifetime for DHCP assigned addresses.
> I don't think anybody knew at the time how DHCPv6 would manage lifetimes.
Hmm, RFC2462 clearly says "stateless or stateful" in Section 5.5.3 (e):
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, [... describe how to update the lifetimes]
and even though the RFC is not clear on "what is stateful" (probably
due to the immature statndardization status of DHCPv6), the intended
protocol was very likely DHCPv6.
But, it's okay for rfc2462bis anyway. We're going to remove specific
behavior regarding DHCPv6 as a clarification.
> And I'm sure the intent was not to affect some lifetime on manually configured
> addresses.
I'm sure about that, too. But it's not the main point whether the
intent was to affect "some lifetime" on manually configured addresses.
The point is whether the intent was to make a decision on a new
address to be auto-configured based on the existence of manually
configured addresses (as well as other automatically-configured ones).
And,
> Given this I think it makes sense to explicitly state in RFC 2462 that "the
> list" is the (per interface) list of stateless prefixes learned from
> router advertisements (i.e. the prefixes with the A-bit set).
after re-reading RFC1971 and RFC2462, I now have a similar conclusion
(but probably for a different reason).
RFC1971 (essentially) says:
d) If the advertised prefix matches the prefix of an autoconfigured
address in the list, update the lifetimes.
e) If the prefix advertised does not match the prefix of an address
already in the list, then form an address.
I think "an address" used in (e) actually meant "an autoconfigured
address" but the RFC simplified the text to avoid redundancy.
Then, as I pointed out in a previous message, RFC2462 reversed the
order of the rules without touching the text (related to this
discussion):
d) If the prefix advertised does not match the prefix of an address
already in the list, then form a new address.
e) If the advertised prefix matches the prefix of an autoconfigured
address in the list, update the lifetimes (with DoS avoidance)
and, probably unintentionally, made the meaning of "an address" in
bullet (d) a little bit ambiguous.
Having considered all the discussion so far, the final proposed text
in rfc2462 is as follows:
5.5.3 Router Advertisement Processing
For each Prefix-Information option in the Router Advertisement:
[omitted, no change from RFC2462]
d) If the prefix advertised is not equal to the prefix of an address
configured by stateless autoconfiguration 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:
[snip]
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. [...omitted]
I'll submit the new revision with this change very soon, so if anyone
of you have an objection to this, please speak up right now.
Thanks,
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
--------------------------------------------------------------------
