Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

[Ole Troan <[e-mail]>]

>>>> For IPv4 + NAT, if you flash renumber the upstream address then existing
>>>> connections will be stuck.
>>> Not exactly They do fairly quickly get sent TCP RSTs in most cases.
>> 
>> That's not my experience. I hardly ever see a CPE generate a RST when a flow
>> doesn't exist
> 
> To be clear, the issue is that in order for a TCP RST to be sent, the TCP message has to be delivered to the endpoint in the first place.   The CPE isn’t going to randomly send TCP RSTs to flows that don’t terminate on it.   That is, it is not going to watch TCP traffic through it, notice that the source address on a particular message is not on the prefix it is currently advertising, and then construct a TCP RST to break that connection.
> 
> So in practice, if a renumbering has happened in this way, what is going to happen is that that TCP connection is going to time out for ninety seconds.

What a CPE does do, is to send an ICMP destination unreachable (5 - Source address failed ingress/egress policy) as the source address would violate the unicast RPC check. RFC7084, L-14.

>> This is exactly what happens today in many cases. Of course, where developers
>> get annoyed by this behaviour, they implement shorter timeout at the 
>> application level. I.e., a typical webbrowser doesn't wait for the host to
>> report an error on a TCP connection.
> 
> This should not be happening often enough that application developers are adding shorter timeouts to their code.  A CPE reboot is an exceptional event, and a deliberate renumbering by the ISP ought to be as well.   If they are doing that, I suspect it’s independent of the renumbering problem.
> 
> It would not surprise me if there are CPEs that behave badly when the ISP renumbering, and ISPs that behave badly when a prefix that is still valid is, from their perspective, no longer on offer. We ought to characterize that problem and propose solutions to this.   By “characterize,” I mean look at what actual CPEs do, not theorize, although I think theorizing isn’t bad either. 


You can generalise the renumbering problem to a multi-prefix multi-homing problem. Whenever a host has multiple addresses the application must continuously evaluate all possible paths and react to path failures. An invalidated prefix is just a reachability problem close to the host, and theoretically no different than a path failure multiple hops away.

In the case when a requesting router loses a prefix, it can of course signal that to the hosts as proposed in Fernando's draft. But that doesn't solve the general problem, and I'm skeptical to using addressing as a reachability signal. E.g. if the CPE's upstream link flaps, is that enough to trigger deprecation of the prefix? Of course it shouldn't.

Ole