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

[Ted Lemon <[e-mail]>]

> On Oct 30, 2019, at 6:38 AM, Philip Homburg <[e-mail]> wrote:
> 
>>> 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.

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