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

Fernando Gont <> Thu, 31 October 2019 19:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C07AE120018 for <>; Thu, 31 Oct 2019 12:26:28 -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 cP8lFoRV-SkV for <>; Thu, 31 Oct 2019 12:26:27 -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 D0112120013 for <>; Thu, 31 Oct 2019 12:26:26 -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 CAD748698C; Thu, 31 Oct 2019 20:26:23 +0100 (CET)
To: Ted Lemon <>, v6ops list <>
References: <> <>
From: Fernando Gont <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Thu, 31 Oct 2019 16:21:04 -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: Thu, 31 Oct 2019 19:26:29 -0000

Hello, Ted,

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?

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

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

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

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

> First of all, fix CPEs so that they definitely support clean
> deprecation of prefixes using PD.

But robustness cannot rely on any of these specific bits.

>  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

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

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