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

On Thu, 31 Oct 2019, 12:40 Owen DeLong, <owen@delong.com> wrote:

>
>
> On Oct 30, 2019, at 5:53 PM, Bernie Volz (volz) <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.
>

So if some enterprise network operators said to the IETF,

"We want to be able to change the VLAN assignments of any of our IPv6 hosts
randomly and unexpectedly, including at 9:10 am when everybody is checking
their email, and have the hosts handle that entirely seamlessly."

would we consider that to be a reasonable request?

> 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> wrote:
>
> On Oct 30, 2019, at 7:18 PM, Bud Millwood <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
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>