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

[Brian E Carpenter <[e-mail]>]

On 2019-02-06 23:15, Nick Hilliard wrote:
> Christian Huitema wrote on 05/02/2019 22:10:
>> Lots of the discussion centers on denial. "Don't worry about that, the
>> router's prefix should not change." Really?
> 
> We know the router's prefix will change.  The challenge is transferring 
> the state information from one domain to another, so that when it 
> changes, the end devices can recover as quickly as possible.
> 
> Mark is spot on to note that TCP and UDP require addressing stability. 
> Changing from TCP and UDP is boiling the ocean, which means that if we 
> want to deal with this problem, we need to work with what we have.
> 
> The choices seem to be:
> 
> 1) ensuring that if a device is disconnected and then reconnects to the 
> same network, the device will be given the same lease,

In the general case we can't "ensure" that. Firstly it may be against
business policy or privacy policy for some ISPs. Secondly even if it
was the intended policy, there can always be failure scenarios. Thirdly,
a host might be disconnected from one LAN and reconnected to another
one without knowing it. So even if this is the recommended practice,
no host can rely on it.
 
> 2) the intermediate device remembers the old lease, compares it with the 
> new lease and if they're different, invalidates the old prefix by 
> issuing an updated PIO,

Again, we can't rely in this, due to legacy equipment and the possibility
of failures or reconnections.
 
> 3) pushing the smarts down to the host layer and detecting / monitoring 
> whether any particular prefix is still valid

https://tools.ietf.org/html/rfc6059 ?

In any case, because neither of the preceding options is guaranteed,
I think there is no choice: hosts must be able to recover from
dead addresses.

    Brian

> 
> 4) ???
> 
> Fernando's suggestion is workable but requires CPE vendors to get on 
> board with the idea of storage of addressing information.  Getting ISPs 
> to change DHCPv6 assignment policies is also workable, but requires 
> centralised provisioning and dynamic routing.
> 
> None of these is ideal and all of them require compromise and some 
> change in behaviour in a way that has side effects.
> 
> This is because the core problem is about how to deal with transfer of 
> state information.  Managing state is always a monumental headache.
> 
> Nick
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>