Subject: rfc2462bis: new section 5.7

From: Erik Nordmark <[email-masked]>
Date: Mon, 1 Mar 2004 23:59:17 -0800 (PST)

The new section looks good but I think it should require that the host
store the times when the address would become deprecated and invalid
together with the address itself in stable storage.

Without that an address might accidentally be used long after it has
become invalid.

  Erik

Example stable storage file from an existing implementation:
2002:c0a8:717:a807::c01d:a308/64 '2003-04-22 16:18' '2003-04-22 18:18'

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 22 Mar 2004 21:23:52 +0900

>>>>> On Mon, 1 Mar 2004 23:59:17 -0800 (PST), 
>>>>> Erik Nordmark <[email-masked]> said:

> Without that an address might accidentally be used long after it has

Good point, thanks.  How about changing the first sentence of Section
5.7 as follows?

   It is reasonable that implementations that have stable storage retain
   their addresses and the expiration times of the preferred and valid
   lifetimes if the addresses were acquired using stateless address
   autoconfiguration.

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.

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?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

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

>    lifetimes if the addresses were acquired using stateless address

ok

>    cannot reach consensus, I'd rather remove this section from

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.

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

  Erik