Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)

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

> Also, DHCP server vendors in particular do not implement what we intended that they implement, because we never said explicitly that they should do so, not specified what a CPE should expect in this situation.

That’s not true. The server I work on allows you to specify an expiration time for a prefix, and we will automatically decrease lifetimes to honor that time and also stop using the prefix for new leases. This allows you to introduce a new prefix to be used for prefix delegation for graceful renumbering. Once the expiration time has passed, you can remove the old prefix as there should no longer be any active leases. We introduced this with the first release with DHCPv6 support a long time ago.


  *   Bernie

From: v6ops <[e-mail]> On Behalf Of Ted Lemon
Sent: Friday, November 1, 2019 8:58 AM
To: Ole Troan <[e-mail]>
Cc: [e-mail]
Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)

On Nov 1, 2019, at 8:36 AM, Ole Troan <[e-mail]<mailto:[e-mail]>> wrote:
(4) is the definition of graceful renumbering. What makes you conclude "then we just assume that people will do whatever they want"?
(especially since your options 1-3 are exactly that, people do whatever they want…)

Okay, I missed a step (or five).  We have specified what a renumbering process should ideally look like, without taking into account several likely operational circumstances.  We have not specified in sufficient detail how renumbering works using DHCPv6 PD, e.g. in a home environment.  Consequently, providers do not have a viable way to follow our recommendations for how to renumber, and hence just do whatever they can think of, possibly without realizing that there might be a better way to do it.   Also, DHCP server vendors in particular do not implement what we intended that they implement, because we never said explicitly that they should do so, not specified what a CPE should expect in this situation.

Does that help?

FWIW, I was asked to consult with an operator who shall remain nameless about how to solve this problem, and the solution I came up with relied on the recommendations from RFC 4192. and further relied on DHCPv6 prefix delegation offering two prefixes, one valid and one preferred.  Unfortunately I don’t think this was ever implemented, but I still think it’s the right thing to do; what I’m realizing from this conversation is that not everybody saw this solution as obvious.   Which I think is a problem.