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

[Jan Zorz - Go6 <[e-mail]>]

On 04/02/2019 12:28, Ole Troan wrote:
> 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).

:)

I agree with you. So fixing the provisioning part should be our answer?

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

Not to end users... and they expect their Internet connection to work 
night and day :)

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

Agreed :)

Again - impose a Standards document with lots of MUSTS on provisioning folx?

Cheers, Jan