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

Mark Smith <> Fri, 01 November 2019 00:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81249120105 for <>; Thu, 31 Oct 2019 17:20:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.496
X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xc30Mz7SZc1l for <>; Thu, 31 Oct 2019 17:20:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E203F1200EF for <>; Thu, 31 Oct 2019 17:20:38 -0700 (PDT)
Received: by with SMTP id v186so6831222oie.5 for <>; Thu, 31 Oct 2019 17:20:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TPjVaNG6mqGXCUY83DF1Xk3jt1L0XQqGUT6Vzi7WqK0=; b=thOSRrFcA1JHVDXps7CEwW9ylctLH3ZP41ft+Tnd1SLi1lTE49s1XzmHR0kF27IIIF DJhfbAbRi9jH3lVvH5IB9g5YmtT1rSZHNXQi70F5pXcJ2XTtKlGiy81bWqmO68cOT2EB xNqKk83itRTk3uAn4VJvmLPDwp1mjQ3eFharKMTqBkMT+XonywXOqK214u5LJ0Ct2+/9 GvZ1g5jwigLCKi1AzFulDcn1GfAq02PSDXSxgmSb3Sz8QKdKf3p8MoZmrjUDfmg3i0St mWfMVwCh7lhn/hGr1fiMFcqvVFS8nJQfY4Dp6T1mbAIa0nnjVAiKNzb0gpudc6KBac8e ZipA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TPjVaNG6mqGXCUY83DF1Xk3jt1L0XQqGUT6Vzi7WqK0=; b=P6OTOEKH9nay/MUMc9Xn9XLFBNN2FsrTuDYNjsGuh445/ejnT8EQ0DvFsXDeL3k3p+ JM+yQgtEoVoYQA7Hm3d9tdIqQlnZ27+UvsYNHGMbrZGncCjoBCe7xdtHc9r1YPfIn3UT kLcTmsMXc7B/5NI1UbQxAZ5Exma2CS8EhDKyEOkF57iaUUFCVVjwjcl8CyA6L8A83S+C hBtijZaXZjodD+WnnLvv084jyj2+sDqyhG/qYKmf1ZoOut6d6nJ7vLZxlr5aoOi64isi 6fk7mD9IW+JYdcnBrewFC8vYjwzqatoaqqiKuDRagxcvkCdCewL4YpSZsobOaDdGk34/ /nDw==
X-Gm-Message-State: APjAAAU3Fm/j7lqBmj5bFM01lBq3oiPt0K8I3HR92WkP3HY56cK9DxGd sKngFvxKA7Z2CpcNU+1HcMcxcxfOUql+13xCYg4=
X-Google-Smtp-Source: APXvYqy5aS7RYcc415J2c6dE43rF76+xxf5Qyh5+M86Q/vrN0KCLBGiTTUa6q/S5p1CCK5OdDq7Vl02xUXdwkJsvWLo=
X-Received: by 2002:aca:f553:: with SMTP id t80mr457506oih.60.1572567638166; Thu, 31 Oct 2019 17:20:38 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Fri, 1 Nov 2019 11:20:27 +1100
Message-ID: <>
To: Ted Lemon <>
Cc: Fernando Gont <>, v6ops list <>
Content-Type: multipart/alternative; boundary="0000000000007550a305963def58"
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 00:20:40 -0000

On Fri, 1 Nov 2019, 06:34 Ted Lemon, <> wrote:

> On Oct 31, 2019, at 3:21 PM, Fernando Gont <> wrote:
> On 27/10/19 09:02, Ted Lemon wrote:
> Indeed, this would also not actually solve the problem.   At present,
> the ISPs are doing something that is out of spec and causes problems.
> If we “fix” this by accommodating what they do, does that help, or
> does it just encourage them to continue doing it?
> 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.
> What should be happening on the host with a prefix that’s deprecated
> is that TCP connections should be timing out.   This doesn’t take
> very long.
> ~9 minutes, IIRC.
> Should be 90 seconds.

You've got no more than 10 seconds unless you want end users to actively
try to do something to recover, which can include calling their ISP's

A short presentation on some user experience factors for network engineers.

"A bit of UX for NEs"

> And if there is a new prefix being advertised on the
> link, that address should have a valid lifetime newer than the old
> prefix, meaning that the next TCP connection should come from that
> new prefix, not the old one.
> That's not correct. Neither the Valid Lifetime nor the Preferred
> Lifetime affect address selection.
> Okay, there’s something to fix.  Why would these not affect source address
> selection?
> I think Fernando’s plan to shorten some timers makes sense, but
> shortening the minimum really doesn’t—it just opens up an opportunity
> for an easy DoS, since I can now just send out death packets to the
> local network and break everything all at once.
> The reality with ND attacks are (modulo sanity checks on the packets):
> you enforce FHS, or you don't.
> What is “FHS”?
> If you Really Really want to be able to have the routers send out RAs
> that deprecate the default route, and, as Mark is saying here, to
> upgrade millions or perhaps billions of hosts, why not ask for
> something that’s a real improvement?
> Every piece helps.
> Right, but if the effort involved in two different options differs by
> epsilon, you should always choose the option that produces the better
> outcome, shouldn’t you?
> Second, fix RA so that it’s
> non-repudiable by a device that doesn’t have the secret key.
> SEND does this, sort of.  Nobody uses SEND because it tries to solve
> a too-big problem and does it using obsolete technology.   But the
> basic idea is good: include a public key in every RA that can be used
> to validate that the RA was signed with the corresponding private
> key.
> What's the practical difference between that, an a network that supports
> RA-Guard?
> On a network that supports RA guard, there probably is no difference, but
> RA guard on some networks, as we’ve discussed in the past, will actually
> make the network not work.   RA guard requires an active administrator.
> So the CPE case we’re talking about isn’t relevant.
> When another RA arrives, see if it was signed with the same key.   If
> so, it came from the same router, and can be trusted to update
> whatever information that router sent, including flash-deprecating a
> prefix.   If not, ignore it.
> In the non-SEND trust model, you do trust the local router. Why did you
> trust the local router to configure your network, but not for
> deprecating the prefix?
> In the non-SEND trust model, you trust the local network.   You *hope* that
> the RA you get “from the router” is actually from the router.
> _______________________________________________
> v6ops mailing list