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

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

I should point out that having the dhcp server supply this information may not work all the time. It really depends on what configuration changes were made and the server implementation. And of course is useless if you “move” the CPE.

So this isn’t going to be prefect (only storage on CPE will do that), but should improve things and especially for those situations where the SP configures the DHCP server to renumber periodically.

- Bernie

> On Oct 30, 2019, at 6:16 PM, Bernie Volz (volz) <[e-mail]> wrote:
> 
> See Ted’s message ...
> 
> Regarding (3), I was thinking that you might configure it server wide to do this, but if you had specific broken clients, those could be excluded (perhaps based on a class, such as from a specific manufacturer, or by explicit duid). There’s probably never an issuing in providing configuration knobs ... most likely it is just the default behavior that is important.
> 
> I’m less inclined to break what is working, so I’d be a bit more cautious than Ted. Also, the “now” broken CPE will cause a customer service call and could be expensive to the SP. SP support teams also would likely need to know that they might see an increase in customer issues, which probably isn’t easy to know (how many people read release notes carefully)?
> 
> - Bernie
> 
>> On Oct 30, 2019, at 5:53 PM, Bud Millwood <[e-mail]> wrote:
>> 
>> 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) <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops