> 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.
ok > 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. > 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. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
