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

[Fernando Gont <[e-mail]>]

Hello, Nick,

On 7/2/19 06:23, Nick Hilliard wrote:
> Brian E Carpenter wrote on 06/02/2019 19:31:
>> On 2019-02-06 23:15, Nick Hilliard wrote:
>> 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.
> 
> It's not ensuring that the customer gets the same lease all the time;
> it's ensuring that if a customer is disconnected where their previous
> lease is still active, and then they reconnect within the lifetime of
> that lease, that they can still use that lease for as long as it's active.
> 
> In other words - as some other people put it - it's about ensuring that
> ISP leases are honoured even if a customer disconnects and reconnects.

Maybe the lease is still valid, but if the user asks for a new lease, he
just gets that? WHat if, say, DUID is randomized and the user requests a
new prefix?


[....]
>>> 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.
> 
> I don't necessarily see why we can't rely on this to work in most cases.

Well... if you connect to a network that just does not happen to
implement this, your dead. -- OTOH, if the host implements some smarts,
you can workaround this issue even if the network does not play nice.

ZN analogy would be happy eyeballs: you could request that the network
does not have crappy connectivity... but the best way to avoid the cases
where that happens is to implement smarts on the host.



>>> 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.
> 
> This is potentially the boil-the-ocean option.  It's hard not to think:
> "perfect is the enemy of good enough".

RFC6059 might be -- although it does not really apply here, since the
network is the same (i.e., you will *not* detect that the network has
changed... quite the contrary).

The host-behaviour that we propose in our I-D is quite simple -- and the
benefits for the hosts implementing it is straightforward...


-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492