In your previous mail you wrote:
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.
=> the DoS attack is about valid lifetime only because when a valid
lifetime is dropped to zero an implementation can (IMHO it is in fact
a SHOULD) kill all connections using a now unvalid address.
The behavior for zero preferred lifetime is far less drastic ("deprecated"
addresses are not used for new "connections" when there are other
available addresses) and (IMPORTANT) we need for multi-homing to be
able to play with preferred lifetimes.
However, it doesn't mention preferred lifetimes. 5.5.3 e) says:
...
This document doesn't say anything about preferred lifetimes from this
part to the end of this section.
=> this is on purpose.
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.
=> I agree. I am in favor of 1 or 2 with a little preference for 1
which seems more logical (I suggest to introduce a notion of
valid prefix information and to make prefix informations which don't
follow the two hour rule invalid).
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.
=> we agree.
And, in fact, item 2 of
5.5.3 e) says:
2) If the StoredLifetime is less than or equal to 2 hours and the
received Lifetime is less than or equal to StoredLifetime,
ignore the prefix,...
=> s/prefix/prefix information/ ?
that is, it specifies ignoring "the prefix", not just "the valid
lifetime".
=> same comment.
What do others think? As I already indicated, I'd propose to revise
the text clearly with option 2 above.
=> please proceed.
Regards
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
