Re: A common problem with SLAAC in "renumbering" scenarios

[Ole Troan <[e-mail]>]

Jan,

>>> One question is whether it makes sense for routers to have valid lifetimes of
>>> more than a day for prefixes that are obtained using DHCP-PD.
>>> 
>>> Another is whether general purpose hosts should accept lifetimes of more
>>> than a day. Maybe hosts should just truncate.
>> The (original) intended lifetime for DHCP PD is a lifetime equal to the length of the contract with your ISP.
>> Lifetimes become meaningless with “flash renumbering”. Neither SLAAC nor DHCP PD is designed for that.
>> The simple solution to this problem is “if it hurts, stop doing it”.
> 
> Ole, in theory, I agree with you.
> 
> In practice - "if it hurts, stop doing it" means that ISPs declares IPv6 as not functioning and switch it off for good.
> 
> Is this what we want?

One doesn’t follow from the other.
Neither do we want an IPv6 deployment where TCP connections break arbitrarily or IPv6 users cannot conveniently run servers in their homes.
Short lived, arbitrary changing prefixes dumps most of the baby out with the bath water (ouch that put some awful pictures in my head).

> CPE power-cycle is something that ISP has no control of. Now, if provisioning vendors would play our game, then they would never implement a provisioning mechanism that allows flash renumbering, as you call it.

Of course no mechanism here has ever been contingent on the CPE rebooting or not.
One reason we have RFC4649 for example, for deployments where the interface ot user binding isn’t obvious.

> 
> Ole, I would ask you a favour. Can you ask internally at your employer why provisioning at BRAS allows creating "pools" of IPv6 addresses and dynamic prefix delegations? Basically, this is the core root of a problem and if we can fix it in provisioning platforms, then we are all set and there is no need for changing CPE or host.
> 
> But I'm afraid that the answer that you'll get will be "customers demanded this and we had to implement it". Money talks. Do you think we can change that? Talk VendorC, VendorJ, VendorX and all others into turning their behaviour into one that actually give ISPs even an option to honour their "contract" with a customer, even in case of unintended event with the CPE?
> 
> Should we write a Standard RFC that neatly defines all the MUSTS for provisioning platforms?

The provisioing platforms have all that they require. This is only policy.
Now, I know there are cases where huge swats of users are moved from one aggregation point in the network to another, where routing would end up very messed up if customer weren’t renumbered, and also that in those cases that flash renumbering is a lot easier to do, but those are typically known events.

> If yes - good. If not - then we have to change the host and CPE.

If we want to keep the benefits of IPv6, and solve the problem of arbitrary addresses being ripped out from underneath the host stack, we need to do quite a bit more than what is proposed in this draft. The reason why we need to push against this kind of network behaviour is that the transport protocols, host stack and applications aren’t ready, and they’re not going to be for a while.

Ole