Subject: Re: rfc2462bis: new section 5.7

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 08 Apr 2004 15:55:00 +0900

(Sorry for the long delay in response)

>>>>> On Mon, 22 Mar 2004 12:03:35 -0800 (PST), 
>>>>> Erik Nordmark <[email-masked]> said:

>> Meanwhile, I have more fundamental questions:
>> 
>> 1. it is probably not adequate to describe this in the body of
>> rfc2462bis, since it's a kind of extension, not a bug fix or a
>> clarification to the existing specification.  Shouldn't we rather
>> move this section to appendix entitled (e.g.) "future possible
>> extensions"?  Or should we describe this in rfc2462bis in the first
>> place?  I myself do not have a particular preference, but if we
>> cannot reach consensus, I'd rather remove this section from
>> rfc2462bis.

> I understand your concern.

> Given that there are some implementations that store the prefix
> in a file there is a risk (and perhaps even implementations) that
> do not retain the lifetimes together with the prefix I think we should
> at least add a clarification that if the prefix is retained in stable storage
> in such a way that it might remain in stable storage after
> the lifetimes might have expired, the end of lifetimes must also be retauned
> in stable storage.

> Thus I agree that the extension to suggest that implementations retrain
> the prefix doesn't belong, but given that some implementations already do
> having the warning about the lifetimes makes sense.

Okay, so how about revising section 5.7 as follows?  In this proposal,
we still have the new section, but I tried to limit the description to
warnings based on experiences of existing implementations.

5.7 Retaining Configured Addresses for Stability

   An implementation that has stable storage may want to retain
   addresses in the storage when the addresses were acquired using
   stateless address autoconfiguration. Assuming the lifetimes used are
   reasonable, this technique implies that a temporary outage (less than
   the valid lifetime) of a router will never result in the node losing
   its global address even if the node were to reboot. When this
   technique is used, it should also be noted that the expiration times
   of the preferred and valid lifetimes should be retained, instead of
   or in addition to the lifetimes themselves, in order to avoid
   unexpected lifetime expiration during the boot period.

   Further details on this kind of extension are beyond the scope of
   this document.

>> 2. this extension may conflict with the rule that "if no router
>> exists, then stateful configuration MUST be performed" (though we
>> are now discussing the requirement level on this).  Assuming the
>> current requirement level, should we also describe the relationship
>> (or ordering) between the two alternatives?  For example, should we
>> require that this extension (i.e., retaining the address) be used
>> only after the attempt of stateful address configuration fails?

> If we take your suggestion that the extension is out of scope
> for the clarifications then we can defer this issue to a separate draft.

> That of course doesn't answer your technical question.

> I think the answer to the technical question lies in the DNA world.
> If you can detect that you are still connected to the same link
> it would be ok (when the lifetimes haven't expired) to
> verify and continue to use the old configuration.
> But the question is whether DNA can easily verify it is attached to the same
> link when there is not a router - the schemes proposed so far seem to assume
> a router (and/or a dhcp agent if stateful is used) just to do the verification
> that you are on the same link as before.

I tend to agree that the question should go to the DNA world.  So, for
now, I'll leave the second question open if the above proposal on
Section 5.7 is acceptable.

					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: Erik Nordmark <[email-masked]>
Date: Thu, 8 Apr 2004 11:03:41 -0700 (PDT)

>    unexpected lifetime expiration during the boot period.

The last part sounds like one need to make sure the address lives 
long enough; my concern is about it living for too long.
So I'd reword the last sentence to say:
	When this
   technique is used, it should also be noted that the expiration times
   of the preferred and valid lifetimes must be retained, in order to 
   prevent usage of an address after it has become invalid.

>    Further details on this kind of extension are beyond the scope of

  Erik

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 09 Apr 2004 11:31:32 +0900

>>>>> On Thu, 8 Apr 2004 11:03:41 -0700 (PDT), 

>    prevent usage of an address after it has become invalid.

Thanks for the suggestion.  I'll use the reworded text then.

					JINMEI, Tatuya