Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X"

[[e-mail]]

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

A comment from an operator perspective:

- We don't "flash renumber" DHCP customers if we can avoid it.
- Sometimes a DHCP customer needs to be moved to a new router or
cluster of routers. This also implies that the customer will be
renumbered.
- We normally perform such moves as a planned activity, during
nighttime, with alerts to customers beforehand.
- We *don't* start delegating new prefixes in advance (and that
would be somewhat difficult in any case since they "belong" to
the router the customer will be moved to). We have no plans to
change this.

So - TL;DR: We don't do "flash renumbering" for fun, on the other
hand we also don't strictly follow RFC 4192.

Steinar Haug, AS2116