Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

["Bernie Volz (volz)" <[e-mail]>]

Ted:

A Solicit kind of means “start from scratch”. So that’s why the current RFC8415 specification does not require sending information related to “old” leases. The text also does not provide for sending 0 lifetimes in an Advertise which is where this would first appear – and then also in the Reply to the Request. Perhaps there is an argument that these leases should not be added to the Advertise, but be in the Reply to the Request.

So, it does get a bit more complex and needs to be worked out.

> I don’t see any reason why this should not just be the default behavior.

As I said that as this is a change in behavior, we don’t know what the consequences for existing devices may be – and in some cases, if the device does have storage, would this confuse it? I’m not against having this be a configuration knob in the server which can be applied at various “levels” (perhaps even globally).


  *   Bernie

From: Ted Lemon <[e-mail]>
Sent: Wednesday, October 30, 2019 9:51 AM
To: Bernie Volz (volz) <[e-mail]>
Cc: Timothy Winters <[e-mail]>; IPv6 Operations <[e-mail]>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

On Oct 30, 2019, at 9:24 AM, Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>> wrote:
When a CPE boots and does a Solicit / Request, it could include a new option that tells the DHCP server that it has no storage and therefore no knowledge of any “past” leases. The DHCP server in this case could include any “old” leases it still has a record of (i.e., that have not expired but are no longer “valid” in terms of the configuration because of renumbering or other conditions) with 0 lifetimes. That would allow a rebooting CPE to learn old delegated prefixes that it might have advertised to its clients and initiate deprecation of these prefixes (and any addresses generated from them).

I don’t see any reason why this should not just be the default behavior.