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

[Ted Lemon <[e-mail]>]

On Nov 1, 2019, at 6:56 AM, Ole Troan <[e-mail]> wrote:
> There’s really little value in having both valid and preferred lifetimes in PD. 

Ole, I think argument from authority isn’t very useful here.   I can imagine that you might think this, but…

Suppose I want to renumber a customer.   And I have one tool with which to do this: DHCP.   What is the correct behavior?   There are options:

1: just stop renewing the old prefix, but continue to route it
2: provide two prefixes, one with a preferred lifetime of zero, the other with a nonzero preferred lifetime; continue to route both until the valid lifetime on the deprecated prefix expires, at which point stop routing that prefix.
3: stop renewing the old prefix, and don’t route it.

I think that (1) is valid, and is what we would expect, but there is a problem: how does the infrastructure know that that prefix should continue to be routed?   It’s not seeing renewal traffic, and I think that’s how it knows currently.   Maybe it does DHCP leasequery?   If so, then does the DHCP server know the prefix is still valid?   I hope so.   It would be bad if the DHCP server gave out that prefix before it had expired.

(2) seems valid, and I think is correct behavior, but there’s been some theorizing on the DHC wg mailing list (and here, a bit) that some CPE devices might not be expecting this behavior, and might choke on it.

(3) This is a flash renumbering scenario.

Now, I think what you just said was that none of these scenarios are valid, because the ISP should never renumber the customer.   Is that correct?