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

[Fernando Gont <[e-mail]>]

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.
Ideally, the CPE will advertise that the contract is void. But it is
clear that for most deployed CPEs, that will not happen.



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



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



> If you want something like session survivability,
> that’s not a trivial problem to solve.

Not sure what you mean by "session survivability".


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



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

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