Hi Lorenzo, The current text describes the meaning of "stale" as follows in 3.2.
The received information can be considered stale in several cases, e.g., when the interface goes down, the DHCP server does not respond for a certain amount of time, and the Information Refresh Time is expired. We should add stateful DHCPv6 case here, as you mention it. Best regards, On 2013/09/06, at 21:30, Lorenzo Colitti <lore...@google.com> wrote: > On Fri, Sep 6, 2013 at 9:23 PM, Tim Chown <t...@ecs.soton.ac.uk> wrote: > > If #2, then perhaps this option needs a lifetime value? Unless the plan is > > that a) who/whatever solves the problem statement in RFC 4076 will solve > > this too, or b) that everyone needing this option will use stateful DHCPv6. > > What about use of RFC 4242, which SHOULD be supported in IPv6 CE's, for > example (as per RFC 6204)? RFC 4242 was produced to address the problems > discussed in RFC 4076. > > That seems like it would work. (Thanks for pointing it out, I hadn't seen it. > It's unfortunate that the minimum is 10 minutes, but for this particular use > case it doesn't matter.) > > Perhaps just say that clients that process this option MUST either implement > OPTION_INFORMATION_REFRESH_TIME or assign it a default lifetime of a day or > somesuch? > > Also, perhaps you might want to better specify what happens in the stateful > DHCPv6 case instead of just saying "when it's stale"? For example, you could > explicitly state that the lifetime of the option is the same as the lease > time? > > Cheers, > Lorenzo
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
