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

> On Oct 30, 2019, at 6:48 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
> 
> Owen:
>  
> “The CPU should write the set of received prefixes and their expected expiration times (preferred, valid) to persistent storage. The CPU should update this when a packet making a change to these timers is received. It should make every effort to deprecate prefixes it cannot renew from the links where it previously advertised them.”

Argh… That should read CPE, not CPU.

> I fully agree with that. That is the best and most complete solution. No disagreement there.
>  
> I was just trying to come up with something that could help in cases where this was not reasonable.

Such as? I cannot fathom a case where this isn’t reasonable. All CPE has non-volatile memory for storing settings. We’re talking about adding 24 octets per prefix and unlikely more than 3 prefixes per interface. Assuming no more than 4 (routed) interfaces on your basic home gateway, that’s a maximum of 12 prefixes for a total of 288 octets of storage.

> Note that it is technically a bit more than just write to storage as a clock is also needed to know whether the prefix needs to be deprecated or not. Perhaps time can come from the network or the device can just deprecate regardless of time if the new prefix is different when it reboots?

Nope… It isn’t…. The clock is an existing function of the CPE. All you need to write is the expected expiration time. (Current clock + prefix timer) to the non-volatile storage. You don’t need to count down the timer values.

The clock can be internal or synchronized to NTP or some other time service, but virtually every CPE already has an internal clock, so there’s no additional requirement here. In fact, the CPE _HAS_ to have a clock already to know when prefixes time out without a reboot or flash renumbering event.

Owen

>  
> Bernie
>  
> From: Owen DeLong <owen@delong.com <mailto:owen@delong.com>> 
> Sent: Wednesday, October 30, 2019 9:39 PM
> To: Bernie Volz (volz) <volz@cisco.com <mailto:volz@cisco.com>>
> Cc: Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>>; Bud Millwood <budm@weird-solutions.com <mailto:budm@weird-solutions.com>>; dhcwg@ietf.org <mailto:dhcwg@ietf.org>; IPv6 Operations <v6ops@ietf.org <mailto:v6ops@ietf.org>>
> Subject: Re: [v6ops] [dhcwg] SLAAC renum: Problem Statement & Operational workarounds
>  
>  
> 
> 
> On Oct 30, 2019, at 5:53 PM, Bernie Volz (volz) <volz@cisco.com <mailto:volz@cisco.com>> wrote:
>  
> Mark Smith on v6ops ml wrote: 
>  
> “I think Ole observed that this is contrary to what the PD prefix's Valid Lifetime said would be the case. The ISP supplied a PD Prefix with a Valid Lifetime of X seconds, and then broke that promise by abruptly changing addressing before X seconds. ISPs should be expected to live up to their Valid Lifetime promises.”
>  
> Sure, but in the real world, there is an entire class of ISPs that have repeatedly demonstrated utter and near complete disregard for such niceties as promises to customers (e.g. most major eyeball ISPs in the US at a minimum), so having CPE behavior that accommodates this fact in favor of the user will likely lead to a better user experience than stomping or feet and insisting that ISPs behave properly.
> 
> 
> And it would be worth better understanding exactly what happens in these situations (perhaps it was covered earlier but I missed or lost that)  ... if the Prefix configuration really is radically changed, even the SP dhcp server may be unable to assist.
>  
> With what is being proposed, the SP DHCP server doesn’t need to assist. The CPU should write the set of received prefixes and their expected expiration times (preferred, valid) to persistent storage. The CPU should update this when a packet making a change to these timers is received. It should make every effort to deprecate prefixes it cannot renew from the links where it previously advertised them.
>  
> This doesn’t require anything special on the SP side.
>  
> Owen
> 
> 
>  
> - Bernie
> 
> On Oct 30, 2019, at 7:32 PM, Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> wrote:
> 
> On Oct 30, 2019, at 7:18 PM, Bud Millwood <budm@weird-solutions.com <mailto:budm@weird-solutions.com>> wrote:
> It's not so much about the lifetime of the prefix as about putting two
> prefixes in a reply to a request, right? And any CPE that can't handle
> that gracefully gets hosed. I agree that providers of course need to
> test this feature, and a server side configuration makes that
> possible. Also, I'm all for firmware upgrades, but requiring it to fix
> a hosed CPE is could be a big issue.
>  
> The thing is, if they can’t handle a two-PD response, they are out of spec.  This is already allowed in the RFC.
>  
> Granted, there may be plenty of CPEs that won’t handle this correctly.   If they can be bricked by a message with two PDs, then bricking them is the right thing to do, because that’s a zero-day vulnerability wide open on the customer network.
>  
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org <mailto:v6ops@ietf.org>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>