Subject: Re: [rfc2462bis issue 271] retaining addresses in stable storage

From: Jari Arkko <[email-masked]>
Date: Fri, 06 Feb 2004 13:34:23 +0200

JINMEI Tatuya wrote:
> 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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------