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

[Alexandre Petrescu <[e-mail]>]

Le 05/02/2019 à 23:10, Christian Huitema a écrit :
> On 2/5/2019 11:46 AM, Lee Howard wrote:
> 
>>
>> And yet when somebody says "I built my network for reasons that were
>> compelling to me at the time" you tell them they did it wrong. It's
>> tiresome.
> 
> 
> +1. I am always amazed at how long threads can become on the IPv6
> mailing list. It seems that the problem is rather simple:
> 
> 1) For some reason, the router gets reconnected, and the new connection
> comes with a different IPv6 prefix.

For this problem:

In one ADSL IPv6 connection (Free.fr) one gets always a guaranteed same 
/56 prefix from provider.  It looks hardcoded, cant change even after 
two weeks of off time.  But it's a form of IPv6-with-IPv4.

In other home ADSL operators, I guess the problem mentioned (router gets 
reconnected, come with a different IPv6 prefix) exists in _some_ ADSL 
operators - which?

In some cellular operator, which uses DHCPv6 Prefix Delegation, the 
mobile gets a new prefix at some re-connection events (not all): 
operator Orange, in France, DHCPv6-PD trial testing, re-connection 
involving around 30min off.  Which other cellular operator uses DHCPv6-PD.

Alex

> 
> 2) At that point, all IPv6 addresses allocated to hosts on the network
> become stale, and may remain so for some potentially long time.
> 
> 3) We want to transition rapidly to a new state in which hosts acquire
> addresses based on the new prefix and can communicate again.
> 
> Lots of the discussion centers on denial. "Don't worry about that, the
> router's prefix should not change." Really? There are tons of scenarios
> in which stuff happens, such as for example a router dialing up a back
> up cellular connection if the land line connection broke. Or the various
> events in which the back-haul network configuration changes. These
> events are obviously painful, as all existing TCP connections are going
> to break. The providers probably strive to make them rare, because
> inflicting pain on customers is not a great business plan. But rare does
> not mean "never". Denying that is going to cause tons of frustration.
> 
> -- Christian Huitema
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>