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

Ted Lemon <> Wed, 30 October 2019 10:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD83812013C for <>; Wed, 30 Oct 2019 03:46:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NxD59btRRJ8e for <>; Wed, 30 Oct 2019 03:46:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 26229120013 for <>; Wed, 30 Oct 2019 03:46:25 -0700 (PDT)
Received: by with SMTP id m16so1826794qki.11 for <>; Wed, 30 Oct 2019 03:46:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=content-transfer-encoding:from:mime-version:date:message-id:subject :in-reply-to:references:to:cc; bh=moMWugqUgYc86vhHUKok5RhNf6WUyJjsVaRaTLxCGQs=; b=X17K8+UMdF74ygd7E/Ru7BureoJVUbknZmqA6wDVIUw54t7bgITK35SgRf2Yqx/6oa spsoEV9b20kZFV9dRNyw93Wa9Qewmk1/Lq8argTwE/dtP16ncJp6jSpmZ4jyOj9b/2dU z1sSlzznz6h4ws2mTuZv148u7ZU4EAcmkJnAvq7wcRqsJLHXLo1pwaNtwX5vPKA+wfua fvu1w066I0AE40jKYLCrOsWn2uNnD+QFqc62FwG6xh/krwQs2o2Sm138pgX0iyXSq3JE 1/3z3k/iwLqrW0MOULOHmrhPH1lvxz4xYrGO7bjYCEvvZsOOL6aa1dcHC6ossdsshtFs XT2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :message-id:subject:in-reply-to:references:to:cc; bh=moMWugqUgYc86vhHUKok5RhNf6WUyJjsVaRaTLxCGQs=; b=fMq9BGAbrsuRY4RXlyn+Sklth+oy6EHRSL1U1CPEu3OdkNTwQwo2QDnhqFLtvxUGBc IjOdPssz0GhRJlcODHhQMxukgVW6min5QhxEVC/95dtLXtRzXtrHVX3ZGHLhiYZohh+c wEHSb/Eg6laHokALN7m/eItA4QyTbWXlY1+xRjfAivI0SXuFOIPW/4FzOVYo37uPf/NK 4Fj1hrui4crL2VMZlrPmI3WMQXWgTRnYJVxkZ77yHJk0Hk7HbjIAayEeXC/Y3ghlYTBy ZKgk4uj2F0VJ1Ww2odawExvDjWFQebgZJOofVYyA5gv9DDGgBm43qay3bMTYoPy9YSPz BPtQ==
X-Gm-Message-State: APjAAAWe2PURwo4qMdE9nvhe1FD/vAiYqnN2gXnlSVS44wrJP3u19UHl szbK2s5HDJ8AY4Vz+gtgrI68spgwPwgvRA==
X-Google-Smtp-Source: APXvYqzwl3sdWA4wAM0a4MnffsoePs7nA7DbvGmfncZNK/c7KHOcOgSMKcFyC89V5cZa941Suqv9sA==
X-Received: by 2002:a37:4a92:: with SMTP id x140mr5500639qka.24.1572432384046; Wed, 30 Oct 2019 03:46:24 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:9be:fcfd:8f35:ceef? ([2601:18b:300:36ee:9be:fcfd:8f35:ceef]) by with ESMTPSA id 187sm1441536qkk.103.2019. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Oct 2019 03:46:23 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <>
Mime-Version: 1.0 (1.0)
Date: Wed, 30 Oct 2019 06:46:22 -0400
Message-Id: <>
In-Reply-To: <>
References: <>
To: Philip Homburg <>
X-Mailer: iPad Mail (17A878)
Archived-At: <>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Oct 2019 10:46:28 -0000

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