(Sorry for the long delay in response)
>>>>> On Mon, 22 Mar 2004 12:03:35 -0800 (PST),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> 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 PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
