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

Ted Lemon <> Thu, 31 October 2019 19:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 339BE12000F for <>; Thu, 31 Oct 2019 12:34:08 -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, HTML_MESSAGE=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 7aRIh119vnVl for <>; Thu, 31 Oct 2019 12:34:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7A16120018 for <>; Thu, 31 Oct 2019 12:34:05 -0700 (PDT)
Received: by with SMTP id 71so8297781qkl.0 for <>; Thu, 31 Oct 2019 12:34:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ltwSmjcMTMmkvIg7gYfQomWqrXoDXZBo+FW6znQ6baU=; b=UFmaYpDN/9ReFl5vDYO8fQPBnyw2Oaz7P6hDpXt4Nz6Xqilg0Dk5iHIQOkbgc/U5Tv aF+dqtiBHXBnv25L0dRJqRc2UCyApy7K9A5aDQBm1B6Zoivm8fKID0FyjMdHgLWgiPL2 /9rLJolPHEzgXgZ+QVPJhGwBf3/l9S5DdUKX3DOX3t9Y9PvqKVdx+cj0n6QzFHF0iCni /83vTMRu2QjoiJKrK1BAPFGce7oULw/GpMWYaX8EYKfxnIiEQW7e881EUGLxEmiyLaJR k5WKb+JoMOMPz3B9jAbQVANrGOQCw1c+ULJMsrj/cVsnGyPl0A/bXK7aByohNgCG4bu9 Fv6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ltwSmjcMTMmkvIg7gYfQomWqrXoDXZBo+FW6znQ6baU=; b=sj9MbGRUL+x8zE4hIAZdE1L5Y+GF6bCoFHdnfSoLW5+uJ2q73Zs1kSUM8DU8H04Dvc 5D2tEupmI5pzveDhvE18AG+rzcq3iuWD0luNllYP2L2yWBuo5kSR+rbJTyjdXHLLH/aQ 3gDdKL6/L5kyAT3Bo8ZP0VYywAUMNu/0QPW0kHg20QzFDDHouJ6h0adT8OGmCFwumbxS cVPqwmLnOve2hwKj4hPYMJUC5GWajZK7Wc7TQOMxDWJO5UQJRR0qjPKbXuB3jnJbQwJM tGlhLsGvw7kpRv1ObKNAw8OY+LaLpOVqWC+MKUuu2DsZaQFAaZzNK3/gVwwr5EcSPtpr +lUw==
X-Gm-Message-State: APjAAAUutvGJSvp1gqFuLilL92m/MpLp/ekrKuXTATSzUnJ15eV/Om/M Oqts379iPKT0eESjwQJgoI6eSgtjwIaFrA==
X-Google-Smtp-Source: APXvYqwtBgVqoxBDt41a+m5UigGPoJrQ8r35U8sWw8C+n81HCPt7EUUaGMU4Fz+s+0y977Sfoj2oyQ==
X-Received: by 2002:a37:c40d:: with SMTP id d13mr7064242qki.371.1572550444824; Thu, 31 Oct 2019 12:34:04 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:bdc1:1d6d:228a:c9c1? ([2601:18b:300:36ee:bdc1:1d6d:228a:c9c1]) by with ESMTPSA id m5sm1743549qtp.97.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Oct 2019 12:34:04 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4BF377F3-88B4-41BB-AD1F-EDBD1E762866"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\))
Date: Thu, 31 Oct 2019 15:34:02 -0400
In-Reply-To: <>
Cc: v6ops list <>
To: Fernando Gont <>
References: <> <> <>
X-Mailer: Apple Mail (2.3600)
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:34:09 -0000

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.

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