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

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.

> This would avoid the need for the CPE to keep this information in stable storage.
> So this isn’t going to be prefect (only storage on CPE will do that)

I'm leaning towards a server-side configuration option. Creating a new
option to request something that may or may not work doesn't seem
great.

- Bud

On Wed, Oct 30, 2019 at 11:43 PM Ted Lemon <mellon@fugue.com> wrote:
>
> On Oct 30, 2019, at 6:23 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
> > 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.
>
> In this case the prefix would presumably no longer be valid; if it was valid and was offered as a deprecated prefix, it would cause no harm.
>
> I am not suggesting that this should just start happening with no testing.   What I am suggesting is that forcing firmware updates on CPE routers isn’t something we should be as chary of as we used to be.
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg