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

Owen DeLong <owen@delong.com> Fri, 01 November 2019 15:39 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 4D57A1201EA for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 08:39:04 -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 7JaNrrHZnFb1 for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 08:39:02 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id BE38D12016E for <v6ops@ietf.org>; Fri, 1 Nov 2019 08:38:54 -0700 (PDT)
Received: from dhcp-220-72.meetings.nanog.org (dhcp-220-72.meetings.nanog.org [199.187.220.72]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xA1FcggJ012761 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 08:38:43 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xA1FcggJ012761
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572622724; bh=dPJ1zmi++A38J+iRXJlXdYyMZOw2qSik0NAZ1vjyf8g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=NHDikv00DQVQiJO4Z9k/lm4G0gbuixEmPhMAhJAlWtutHAUGQZEw9llTQ3mGUUjiu ksX6wHG/8DHyjm1i2b/+5whTEV5UcVd4uO5FXfZstc63fySp84zBCuCpf7DINvTbUs b7qn7zOd5BSEP8Z6V2R6bbAZoAwRhq7BbLjZ+mbw=
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: <b53965d9-a6ea-8ffb-836b-491ec14033ec@si6networks.com>
Date: Fri, 1 Nov 2019 08:38:42 -0700
Cc: Ted Lemon <mellon@fugue.com>, v6ops list <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <97D59666-DAF5-4EBC-8AD9-96B9F6128649@delong.com>
References: <CAO42Z2yQ_6PT3nQrXGD-mKO1bjsW6V3jZ_2kNGC2x586EMiNZg@mail.gmail.com> <B53CE471-C6E8-4DC1-8A72-C6E23154544F@fugue.com> <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <BB1268EC-E538-48A8-AD05-A39943F1B397@delong.com> <b53965d9-a6ea-8ffb-836b-491ec14033ec@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]); Fri, 01 Nov 2019 08:38:44 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/z6quzWunn40I4HN429QUi6USlfc>
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: Fri, 01 Nov 2019 15:39:04 -0000


> On Oct 31, 2019, at 8:02 PM, Fernando Gont <fgont@si6networks.com> wrote:
> 
> On 31/10/19 16:38, Owen DeLong wrote:
>> 
>> 
>>> 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.
> 
> It's hard for me to believe that folks were breaking stuff on purpose.

Perhaps “encouraging broken…” is too strong, but certainly it “reduced motivation to fix broken IPv6” and “reduced visibility of broken IPv6”.

> In any case, I would assume and expect that helping IPv6 deployment was
> more of a priority at the time. IN fact, we wouldn't be talking about
> "google seeing 25% of IPv6" if there wasn't a way to circumvent
> brokenness, I'd assume.

It absolutely was more of a priority and that’s why it was implemented. However, we should recognize that it was not without collateral damage.

It may be that we accept that this idea, too, comes with certain unintended consequences, but we should at least make a legitimate effort to identify and consider them, mitigate them to the extent possible, and then make a conscious deliberate decision to accept them (or not).

> [...]
>> 
>>>> 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.
> 
> We'll that's the SLAAC model.

I think you are still missing the point here… The current SLAAC model is trusting the router to configure the network. The consequences when this model fails are that new hosts have difficulty (or failure) joining the network. In most cases, it has pretty limited consequences to existing hosts ability to continue to run.

On the flip side, what is being proposed does create a possibility where a single crafted packet can literally immediately disconnect every host on the link from the network.

The model is the same, but the consequences are significantly different, so perhaps the greater consequences warrant considering a different trust model.

> 
> 
> 
>> 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.
> 
> Hosts trust a lot of other crap. e.g., feel free to advertising a Cur
> Hop Limit of 1. Is that any different?

Yes… A hop limit of 1 leads to errors that make the cause rather obvious.

Crafted RAs that send out PIOs deprecating all the actually valid prefixes lead to error conditions that can be much harder to identify/isolate.

Owen