Proposed Resolution (revised): update section 5.5.3 e)
as attached below.
Reason: based on the recent discussion on the wg list.
Key changes are:
- make it clear that the preferred lifetime is always resest to
the advertised value
- note the difference between the two lifetimes and explain the
reason
Revised text:
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, the preferred lifetime of the address is reset to the
Preferred Lifetime in the received advertisement. The specific
action to perform for the valid lifetime of the address depends on
the Valid Lifetime in the received advertisement and the remaining
time to the valid lifetime expiration of the previously
autoconfigured address. We call the remaining time
"RemainingLifetime" in the following discussion:
1. If the received Valid Lifetime is greater than 2 hours or
greater than RemainingLifetime, set the valid lifetime of the
corresponding address to the advertised Valid Lifetime.
2. If RemainingLifetime is less than or equal to 2 hours, ignore
the Prefix Information option with regards to the valid
lifetime, unless the Router Advertisement from which this
option was obtained has been authenticated (e.g., via IPSec
[1]). If the Router Advertisement was authenticated, the valid
lifetime of the corresponding address should be set to the
Valid Lifetime in the received option.
3. Otherwise, reset the valid lifetime of the corresponding
address to two hours.
The above rules address a specific denial of service attack in
which a bogus advertisement could contain prefixes with very small
Valid Lifetimes. Without the above rules, a single unauthenticated
advertisement containing bogus Prefix Information options with
short Valid Lifetimes could cause all of a node's addresses to
expire prematurely. The above rules ensure that legitimate
advertisements (which are sent periodically) will "cancel" the
short Valid Lifetimes before they actually take effect.
Note that the preferred lifetime of the corresponding address is
always reset to the Preferred Lifetime in the received Prefix
Information option, regardless of whether the valid lifetime is
also reset or ignored. The difference comes from the fact that the
possible attack for the preferred lifetime is relatively minor.
Additionally, it is even undesirable to ignore the preferred
lifetime when a valid administrator wants to deprecate a
particular address by sending a short lifetime (and the valid
lifetime is ignored by accident).
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
