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

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 06 Feb 2004 00:00:42 +0900

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-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sun, 08 Feb 2004 20:18:43 +0900

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

> nit: reasonable

Thanks.

(snip)

> Perhaps there was a discussion about this on the list that I missed,

As far as I know, there was no further discussion on this.  You can
search in a thread about this subject at:

http://www.atm.tut.fi/list-archive/ipng/msg04383.html

At least there was no replies to the main point within this particular
thread (the only response to the message was not directly related to
the RFC2462bis issue).

> but I think there are two separate issues here:

> 1) Router and connectivity goes away for a while.
> 2) Host itself reboots.

These two issues are not actually so separate, IMO.  The problem is,
as I see it, a situation like this:

- a "router" announces a global prefix by RA in a zeroconf
  environment.
- a host in this link configures a global address using stateless
  address autoconfiguration and communicates with other nodes in the
  link by the global address
- the host reboots for some reason.
- while the host is booting, the router somehow stops working.
- then the host loses its global address, and ends up communicating
  with other nodes in the link using link-local addresses.

So the problem is a mixture of 1 and 2.

> 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.

Do you mean the first scenario only?  If so, it is out of scope of
the proposed text.

> 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?

I'm not really sure what you mean by "delete"...probably delete the
router when the router lifetime expires during the router failure?

And if so, the answer is very clear: "continue as is" until the
address lifetime expires.  And, in my understanding, the sense of
RFC2462 is to use a large lifetime for prefixes so that the address
and prefix can be valid even if the advertising router goes away
"for a while".

> 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?

Are you worrying about the case where the address/prefix lifetime is
too short and it expires while the router goes away?  If so, I'd say
this case is against the usual sense of RFC2462 and is out of scope of
the stable storage technique described in this section.

					JINMEI, Tatuya