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

Hi Bernie:

If suggestion (1) or (2), an older CPE that borks over two delegated
prefixes would stay borked until the old prefix expired. And it seems
like suggestion (3) still runs the risk of catching that older CPE.
Configuring that knob at the client level seems like a lot of
management overhead.

I wonder if introducing suggestions (1) or (2) aren't pushing existing
clients to expose new bugs they may have? Suggestion (4) seems
reasonable to me.

- Bud

On Wed, Oct 30, 2019 at 10:02 PM Bernie Volz (volz) <volz@cisco.com> wrote:
>
> Hello:
>
>
>
> DHC folks may want to check out the recent discussion on the v6ops mailing list (https://mailarchive.ietf.org/arch/browse/v6ops/) with the “SLAAC renum: Problem Statement & Operational workarounds” subject.
>
>
>
> Basically, one issue that appears to happen in networks where CPEs receive delegated prefixes and are renumbered when a CPE cycles power – why the renumbering occurs is not material. The issue is that some of the devices serviced by the CPE may still have configuration (i.e., from Prefix Information Options received via RAs or perhaps even DHCP) based on the original delegated prefix and if the CPE does not have stable storage (into which it stored the old delegated prefix), nothing initiates deprecating this information. This is because everyone is honoring the lifetimes, but the renumbering caused the SP DHCP server to provide a totally new delegated prefix and there’s no record in the CPE of the old.
>
>
>
> For a CPE that has stable storage, it could initiate steps to deprecate the old delegated prefix.
>
>
>
> Note that this issue is discussed in https://tools.ietf.org/html/draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00#section-3.2 and also in section 4.3 (S-1) of that draft.
>
>
>
> One idea that I suggested is that the SP DHCP server can provide this information to the CPE. The DHCP server should still have a record of the previous delegated prefix (as it has not yet expired for the binding) and it could therefore send this, with 0 lifetimes, in the Reply to the Request (as it would do in a Renew). This would avoid the need for the CPE to keep this information in stable storage.
>
>
>
> There isn’t any direct mention of sending IA_PD (or IA_NA) with 0 lifetimes in the processing of Requests, but it isn’t a stretch to consider this. And, without something, it isn’t obvious that servers should (or would) do this?
>
>
>
> Some possibilities are (from least conservative to most):
>
> Always have the server do this (sending 0 lifetimes) for a Reply to a Request for this condition.
> (1) but only for Relayed messages.
> Have a server configuration knob (at whatever granularities desired – global, prefix, client, …).
> Define a new option that a client would include in (Solicit/)Request to request this behavior. Note that (3) could always override.
>
>
>
> Hopefully existing clients would handle this correctly, though they likely would not take the action to deprecate the old delegated prefix. But we don’t know (and at least early in the DHCPv6 days, clients weren’t always happy when they received multiple delegated prefixes). Hence, how conservative should we be?
>
>
>
> Perhaps we can discuss as part of draft-fkhp-dhc-dhcpv6-pd-relay-requirements (which is on the agenda for IETF-106), or I could request a separate slot for it - if we need a higher bandwidth discussion.
>
>
>
> We can also just discuss here on the mailing list as it may be possible to resolve fairly quickly.
>
>
>
> It will require a short draft as it is something that would need to be folded into a RFC8415 bis or continue on it own. Probably adding it to draft-fkhp-dhc-dhcpv6-pd-relay-requirements is not best since these are the delegating relay, not server, requirements.
>
>
>
> Bernie
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg