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

[Ole Troan <[e-mail]>]

Ted,

>> 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?
> 

Neither of your options have IETF consensus behind them. DHCP PD supports renumbering, but it also says:

   "Many applications expect stable addresses.  Even though this
   mechanism makes automatic renumbering easier, it is expected that
   prefixes have a long lifespan.  During renumbering it is expected
   that the old and the new prefix co-exist for some time."

RFC4192 is as far as I know the most complete graceful renumbering description.

To continue my example:

(4) Continue to delegate prefix A with a lifetime expiring on November 11. On November 4th start also delegating prefix B with a lifetime expiring December 31st 2022.
    On November 11th, stop advertising prefix A.

This is how IPv6 renumbering has been specified for 20 years... I presume that was not news?

Cheers,
Ole