While working on the rfc2462bis (stateless address autoconf) work, I've found a new issue, and would like to hear opinions.
The current RFC2462 describes in Section 5.5.3 e) how the valid lifetime of an autoconfigured address is updated, considering the avoidance of DoS attack with too short lifetimes. However, it doesn't mention preferred lifetimes. 5.5.3 e) says:
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 specific action to perform depends on the Valid Lifetime in the received advertisement and the Lifetime associated with the previously autoconfigured address (which we call StoredLifetime in the discussion that follows): ...
This document doesn't say anything about preferred lifetimes from this part to the end of this section.
Oops. This could cause all addresses to go deprecated. That in itself may not be too dangerous, however, since according to 5.5.4 you must be able to still use deprecated addresses even on new connections if there are no other available addresses. But I agree that it would be good to avoid this.
On the other hand, RFC1971, which was obsoleted by RFC2462, clearly said in Section 5.5.3 how the preferred lifetime should be updated:
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, set the preferred timer to that of the option's preferred <--- lifetime, and set the valid lifetime to that of the option's valid lifetime.
I guess this part was unintentionally dropped in RFC2462 while we concentrated on the DoS avoidance.
If so, it should make sense to recover this part in rfc2462bis. Possible options include:
1) update the preferred lifetime regardless of whether the valid lifetime is accepted or not wrt the "two-hour" rule 2) update the preferred lifetime only when the valid lifetime is accepted 3) leave this as implementation dependent
I don't think option 3 is the way to go, since RFC1971 clearly mentioned the preferred lifetime.
The KAME/BSD implementation behaves as option 1. However, it seems to me that option 2 makes much more sense because a rejected valid lifetime indicates a possibility of attack and the other parts of the information may then be bogus as well.
I agree. Option 2 sounds right.
--Jari
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
