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

Owen DeLong <owen@delong.com> Thu, 31 October 2019 23:17 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28C2120824 for <v6ops@ietfa.amsl.com>; Thu, 31 Oct 2019 16:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNsZMUEy68Vz for <v6ops@ietfa.amsl.com>; Thu, 31 Oct 2019 16:17:57 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E4415120026 for <v6ops@ietf.org>; Thu, 31 Oct 2019 16:17:50 -0700 (PDT)
Received: from [199.187.216.130] ([199.187.216.130]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id x9VJc4ig024527 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Oct 2019 12:38:05 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com x9VJc4ig024527
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572550686; bh=WfEgN3vpy6lYv+gn9ike8sv8srQDubeyBLmf3+JSRnU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=1xqrCXcbzyL4mVULu6ZA19QuHVkplJh0TGWOhDbhMTeMPpO1eDFZ2mHYVFcglc07t F/VGZVTvTZC9aJmYaC5uoTS1I+dZXesFRNmil07HXQ3f4Zo54ueEdagvOYShz1eUgS iKvj+x/fJRiHBZjfcDZyZoGj65fY3g25aX4hb68M=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com>
Date: Thu, 31 Oct 2019 12:38:04 -0700
Cc: Ted Lemon <mellon@fugue.com>, v6ops list <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BB1268EC-E538-48A8-AD05-A39943F1B397@delong.com>
References: <CAO42Z2yQ_6PT3nQrXGD-mKO1bjsW6V3jZ_2kNGC2x586EMiNZg@mail.gmail.com> <B53CE471-C6E8-4DC1-8A72-C6E23154544F@fugue.com> <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Thu, 31 Oct 2019 12:38:06 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Zle4QygWnXbD54UGQ3QcMnRKkYw>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Oct 2019 23:17:59 -0000


> On Oct 31, 2019, at 12:21 PM, Fernando Gont <fgont@si6networks.com> wrote:
> 
> 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?

Considering these mutually exclusive is a false dichotomy.

It did both.

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

Somewhat variable, but yes, can be as long as ~15 minutes in some cases.

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

Perhaps not, but this is the lowest hanging fruit and the cleanest set of changes.

Certainly you have to admit that the proposed CPE changes would yield the greatest improvement
in robustness at the lowest cost of any of the proposed solutions in the I-D in question.

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

Trusting the local router to configure the network to add a previously non-operational host to the network has a somewhat different set of consequence for failure than trusting whatever on-link host wishes to tell you to effectively shut down your currently operating network connection.

Especially when you consider that such an announcement can be sent to the all nodes on link multicast address, effectively dropping them all at once.

I agree it’s not a huge difference, but, it is a difference and certainly the scope of the resulting problem can be much larger than the case of individual host configuration.

Owen