Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

[Ole Troan <[e-mail]>]

> On 3 Feb 2019, at 12:49, Fernando Gont <[e-mail]> wrote:
> 
>> On 3/2/19 07:32, Ole Troan wrote:
>> 
>> 
>>> On 3 Feb 2019, at 05:29, Fernando Gont <[e-mail]> wrote:
>>> 
>>> On 2/2/19 08:57, Ole Troan wrote:
>>>>> 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”.
>>> 
>>> FWIW, lifetimes are mostly irrelevant to the problem that *we* are
>>> discussing (which is rather orthogonal to the problem mentioned above):
>>> our case is that in which the router just reboots -- so no matter what
>>> the lifetime was, the information will be invalid anyway.
>>> 
>> 
>> That’s not how SLAAC and PD are designed. Lifetimes are not invalid just because of a router reboot. Look at advertised lifetimes as a sort of contract. 
> 
> Well, the problem is that you are making a contract on the LAN side for
> a contract you may not have on the WAN side. If the router reboots and
> the CEP no longer "owns" some prefix, then that contract is void.

You have the contract on the WAN side. What makes you think not. E.g via PD learns that given prefix is valid until March 1 2020.
A reboot doesn’t change that. 

> Ideally, the CPE will advertise that the contract is void. But it is
> clear that for most deployed CPEs, that will not happen.

So a bug. 
What you are talking about is the case where the ISP breaks the contract. While it previously promised to delegate you a prefix until 20200301, all trace of that has gone. 


> 
> 
> 
>> What you seem to be talking about is either a bug a misconfiguration or both. 
> 
> It's neither of those. If anything, it's the result of
> under-specification of the necessary glue between automatic
> configuration on the WAN side, and automatic configuration on the LAN side.
> 
> e.g., there were no requirements for CPEs to keep track of prefixes that
> they have been leased in the past -- if at all possible.

DHCP PD will give you the old prefix back. 

> 
> 
> 
>> With that established, you are arguing that hosts/applications should behave better in the case of this misconfiguration?
> 
> They should behave better in scenarios where the CPE may have rebooted
> and lost state of previously leased prefixes, which may have thus become
> invalid.

It’s not the CPE reboot that’s the problem. It’s the ISP breaking the contract and using the opportunity to flash renumber the user. 


> 
>> If you want something like session survivability,
>> that’s not a trivial problem to solve.
> 
> Not sure what you mean by "session survivability"

Try to keep a TCP session active while changing addresses. 

> 
>> 
>> Currently the network will give an ICMP destination unreachable code 5 and deprecate the invalid prefix if it has information to do so.
> 
> Where in RFC4443 do ICMP unreach code 5 get to invalidate prefixes?
> 
> Answer: Nowhere. They don't get to do that. All ICMPv6 error messages
> are soft errors. And it would be a huge mistake (and huge
> vulnerability!) to behave otherwise.

It’s a strong hint to the host stack to pick a different source address. 

>> Without getting into the multi-homing discussion and requiring hosts to “throw spaghetti on the wall”, I don’t see how your draft improves on that. 
> 
> Not sure what you mean. If the same router that advertised those
> prefixes doesn't advertise those prefixes anymore, why would you think
> they are still valid?

Because that’s what the network previously advertised. 
If source addresses from that prefix no longer works that’s a good hint to the host to try something else. There’s a list of heuristics the host must use. 

I still don’t see how your draft improves much on this. Can you explain?

Ole


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