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

Fernando Gont <> Fri, 01 November 2019 10:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37D14120816 for <>; Fri, 1 Nov 2019 03:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ki8QxMG8WxqD for <>; Fri, 1 Nov 2019 03:40:09 -0700 (PDT)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9F99B12008A for <>; Fri, 1 Nov 2019 03:40:09 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1EBDA86ABF; Fri, 1 Nov 2019 11:40:06 +0100 (CET)
To: Ted Lemon <>
Cc: v6ops list <>
References: <> <> <> <> <> <>
From: Fernando Gont <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Fri, 1 Nov 2019 06:54:38 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
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: Fri, 01 Nov 2019 10:40:11 -0000

On 1/11/19 05:50, Ted Lemon wrote:
> On Oct 31, 2019, at 10:27 PM, Fernando Gont <
> <>> wrote:
>>>> Did happy eyeballs encourage broken IPv6 connectivity, or did it
>>>> actually help IPv6 deployment?
>>> Don’t get me wrong—I’m not saying we shouldn’t do things to improve the
>>> situation.   I am saying that we should be strategic about it.
>> For the home network case, the situation right now is that there are
>> deployments that break, and ISPs meaning to deploy IPv6 that can't do
>> stable prefixes. Certainly, that's a very bad strategy on our side.
>> That said, and as noted, the home network case is just *one* scenario
>> where this problem may be faced. And a subset of the mitigations for
>> this scenarios are useful for the general case.
> You mention later that if it takes more than ten seconds for the
> connection to resume, the user will be on the phone to the ISP.

On this lat/long, *if* the failure is visible (likely not, thanks to
Happy Eyeballs), people will normally just unplug and reconnect all
boxes (e.g. CPE router). Normally, a call to the ISP will lead to the
same procedure.

(Then, in my own circle, *I* get the call. And based on past
experiences, I wouldn't bother to try to escalate the issue at the ISP,
and most likely disable IPv6 myself, keep my folks' networks running,
and use my time for something else.)

P.S.: On a related note, IPv4 masquerading IPv6 issues is the same
reason why there have not been peaks of support calls complaining about
the DNS configuration mess(android with no dhcpv6, windows with no rdnss).

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