> So my first point is that we should clearly specify how the preferred
> lifetime is updated in 5.5.3 e) of rfc2462bis, mainly for normal
> cases. My second point is what we should do about the preferred
> lifetime when the valid lifetime is ignored due to the two-hour rule.
>
> My suggestion to the first point is that the preferred lifetime should
> basically be reset to the advertised value (of course!).
Yes!
> My suggestion to the second point is that we should also ignore the
> preferred lifetime if the valid lifetime is ignored due to the
> two-hour rule.
In my example of the incorrectly advertised prefix that the network admin
wants to get rid of this actually makes it a bit harder.
If the network admin advertised the prefix with valid=3 hours (decrementing
in real time) and preferred=0 then if I've taken my laptop to
a meeting for 1.5 hours when I come back the laptop will have
StoredValidLifetime=7 days (whatever the original number was)
StoredPreferredLifetime=1 day (whatever the original was)
and receive packets with
valid=1.5 hours
preferred=0
and as a result the lifetimes in the advertisement will be ignored and the
(incorrect) prefix will remain preferred for a day.
This is worse than being able to move the preferred lifetime to zero
(thereby deprecating the prefix for future communication).
I think following what is in the router advertisement should always be done
(in order to give the network admin control) except in very specific cases.
There is a specific case to ignore sudden drops in the valid lifetime
but I haven't seen an equally strong argument for ignoring the preferred
lifetime.
> This issue was originally posted by Ken Powell in February 2000:
> I was able to force the preferred lifetime to zero by reconfiguring
> a router to send advertisements with near-zero lifetimes, but the
> valid lifetime couldn't be reduced below two hours.
Question: did advertizing the prefix with both lifetimes = 0 not
mean that the hosts stopped thinking that the prefix was on-link?
The intent was that the 2-hour rule only apply to address autoconfiguration
and not to the on-link'ness of the prefixes. That is why it is specified
in RFC 2462 and RFC 2461 is silent on the issue.
Thus advertising an existing prefix with both lifetimes=0 should remove it
from the on-link prefix list (RFC 2461) but keep the addresses as deprecated
from 2 hours (RFC 2462).
Perhaps this is something we should look into clarifying?
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
