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
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.
================================================================
I tried not to introduce any new requirements that affect existing
implementations (compliant to RFC2462). But there is still a MUST in
this new section, which may be overkilling for the purpose of this
document. We could even drop the entire section and leave this stuff
as a future extension.
What do others think?
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
