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

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

I don’t really think so as this is a relay agent option – not a CPE option. For the SP, the CPE is a DHCP client.

If you are trying to simply say that a relayed packet may be the trigger, one could certainly consider doing that in all those cases but it is not clear if that could cause some problems (if theory it should not … but you never know). Certainly, one could consider a DHCP server configuration knob that says “do this” (for some part or all of the configuration).


  *   Bernie

From: JORDI PALET MARTINEZ <[e-mail]>
Date: Wednesday, October 30, 2019 at 9:33 AM
To: Bernie Volz <[e-mail]>, Ted Lemon <[e-mail]>, Timothy Winters <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Hi Bernie,

I think RFC4649, option 37, provides that option.

Regards,
Jordi
@jordipalet



El 30/10/19 14:25, "v6ops en nombre de Bernie Volz (volz)" <[e-mail]<mailto:[e-mail]> en nombre de [e-mail]<mailto:[e-mail]>> escribió:

While I haven’t followed this discussion in detail, I do wonder if the SP DHCP server could provide some assistance to CPEs that don’t have storage …

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

This would improve the situation when the CPE has no storage and reboots (whether customer or SP initiated).

Note: There could be conditions in which this would fail (such as if SP removed all configuration related to the older prefixes from the DHCP server), but in many cases it would allow for clean renumbering. Of course, it requires updating the DHCP software (on the SP servers and in the CPEs), but it probably easier to accomplish than requiring use of storage on the CPE device.

Be a relative easy draft to write up (at least in theory).


-          Bernie

From: v6ops <[e-mail]> on behalf of Ted Lemon <[e-mail]>
Date: Wednesday, October 30, 2019 at 9:00 AM
To: Timothy Winters <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

On Oct 30, 2019, at 8:40 AM, Timothy Winters <[e-mail]<mailto:[e-mail]>> wrote:
We check both, the handling of the IA_PD and the error message.

And to be clear, you mean that if the CPE asks for a prefix delegation and doesn’t get the prefix it previously had, it deprecates it as described in L-14?  When this deprecation happens, what ways are being tested for it to happen?

E.g., is it the case that the client sends an IA PD containing an IA Prefix option, is the server returning the IA Prefix option containing the same prefix, with a status code encapsulated in it?   What status code?   Or is it returning an IA Prefix option with a different prefix?   Or is it doing both?

_______________________________________________ v6ops mailing list [e-mail] https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.