To address rfc2462bis issue 271, "An implementation may want to use stable storage for autoconfigured addresses", I've added the following new (sub)section:
================================================================ 5.7 Retaining Configured Addresses for Stability
It is reasoanble that implementations that have stable storage retain
nit: reasonable
their addresses and the preferred and valid lifetimes if the addresses were acquired using the stateless address autoconfiguration. Assuming the lifetimes used are reasonable, this technique implies that a temporary outage (less than the preferred lifetime) will never result in the node loosing its global address even if the node were to reboot. This will particularly be useful in "zeroconf" environments where nodes are configuring their addresses by the stateless address autoconfiguration but all communication is closed in a single link. In such a case, the failure of a "router" (that provides the prefix for address configuration) is not significant, but loosing the global addresses might be a pain.
When an implementation tries to reuse a retained address after rebooting, it MUST run Duplicate Address Detection for the address under the criteria described in Section 5.4, as though the address were just configured by stateless address autoconfiguration. The reason for this is because a different host may have started using the address while the rebooting host cannot respond to Duplicate Address Detection from the other host.
So the host stores its address on stable storage across reboots? That's fine in general, I think, but I read the original issue slightly differently, quoting from what Erik wrote in the e-mail stored at rt.psg.com:
Another thing that can be contemplated relates to the "zeroconf" case (where some implementations might end up unnecessarily using smaller scope addresses when the "home" temporarily is disconnected) would be a recommendation that implementations try to provide address stability using stable storage. For instance, I think it is quite reasoanble that implementations that have stable storage retain their addresses and expiry times (preferred and valid) whether the addresses were acquired using RFC 2462 or DHCP. Assuming the lifetimes used are reasonable this techniques implies that a temporary outage (less than the preferred lifetime) will never result in the node loosing its global address even if the node were to reboot.
Perhaps there was a discussion about this on the list that I missed, but I think there are two separate issues here:
1) Router and connectivity goes away for a while. 2) Host itself reboots.
Stable storage as such addresses primarily the second scenario. But I think the proposed text may not be very clear with respect to what exactly is going to be done to assist the first scenario. For instance, if you delete your only router from the Default Router list, what is impact on the global addresses do you wish to have? Deprecate the addresses, remove them, continue as-is, or what? What if the host does NOT reboot but the router just goes away for a while, hopefully we are using the stable storage in this case too, but what about DAD?
--Jari
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
