Re: [IPv6] RFC 6724 shouldn't prefer partial reachability over reachability

Ole Troan <otroan@employees.org> Tue, 21 November 2023 14:58 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59072C151542 for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 06:58:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=employees.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPCbEP5g3OAE for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 06:58:17 -0800 (PST)
Received: from proxmox01.kjsl.com (proxmox01.kjsl.com [204.87.183.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CEE1C151538 for <ipv6@ietf.org>; Tue, 21 Nov 2023 06:58:17 -0800 (PST)
Received: from proxmox01.kjsl.com (localhost.localdomain [127.0.0.1]) by proxmox01.kjsl.com (Proxmox) with ESMTP id 04FC3E5EEF; Tue, 21 Nov 2023 14:58:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=employees.org; h=cc:cc:content-transfer-encoding:content-type:content-type :date:from:from:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=prox2023; bh=zSSaB48yioVY9fAc QDwQ9mZZa8pghyu9LP+NMGESJaY=; b=YhfPXSvlu8dCwFLKO8ql+fBt1SQV1c2d u0FLs9IhUEJu0i3VeimdK5qM2MRcoLWRnKEA39LQlZyyuzCR1g4qAaxvlUHxWNNa 2RD06QwSCoI0qD7IilP18JvPbAjMTIzLO6Nq5KOHm9cXGXUtswkfWAxbmL8W1Zik KGgr1Ieo5UWY09dx2OkZtsqVaTNuR0IgIX05bJZgep3LvNwun6KdwXYGrHuDZdUC 3+e3nSEQFrBO7a3DoFl8oZ5uzrguhkZIduNWJeyUZwmtmfYnkoiUaBbzwoTqIMn0 dT7f2+wCHt9BA8oNppvWmgJZ70SFrFFatKVn81hp47IjdrZB029z0Q==
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by proxmox01.kjsl.com (Proxmox) with ESMTPS id D5A8EE5EE8; Tue, 21 Nov 2023 14:58:16 +0000 (UTC)
Received: from smtpclient.apple (ti0389q160-4360.bb.online.no [82.164.52.60]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id CF2D84E11B8F; Tue, 21 Nov 2023 14:58:15 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CAPt1N1mPNYBfM-RBGULo+mAf4cSqr5=4GsdAeL3_C5YyWNsSAA@mail.gmail.com>
Date: Tue, 21 Nov 2023 15:58:03 +0100
Cc: 6man WG <ipv6@ietf.org>, Lorenzo Colitti <lorenzo@google.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Nick Buraglio <buraglio@forwardingplane.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <68CFC1FB-E178-426F-B3B0-3234D4CA1F98@employees.org>
References: <CAPt1N1kjd+m3KL-KCQY=2DWZrug=g8_zdtacF9Aja7dQ9zjnUQ@mail.gmail.com> <1BA9C21A-8EDC-4E69-8749-3C703CAB678B@employees.org> <CAPt1N1kFQpkkVNtk57_T3FTnVKhtqgm9Z6VGJDzOXo4KJvccSA@mail.gmail.com> <94FC0A0F-AD2C-4630-B509-2DAE57205B50@employees.org> <CAPt1N1mPNYBfM-RBGULo+mAf4cSqr5=4GsdAeL3_C5YyWNsSAA@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vQp7SGGd2tPDiIhsVEqH0z-Wi28>
Subject: Re: [IPv6] RFC 6724 shouldn't prefer partial reachability over reachability
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2023 14:58:21 -0000

Ted,

> Well, e.g. in a stub network with DHCPv6 PD, if the customer site is multi-homed for resiliency, it would be nice if that worked. This would require the device on the stub network to try both source prefixes, so it probably doesn’t work at the moment, but we are talking about what remains to do to make it work. 
> It’s not clear to me that this is the killer app, or even the right approach, but I don’t see the problem that you do with exploring this: my motivation certainly isn’t to avoid paying for enterprise-grade routers other than in the sense that clearly they wouldn’t make economic sense in this application.
> 
> I do realize that if we made this work in the home, it would have implications for the enterprise market in the long run, but that’s a path we’ve all trod many times before, and I don’t think we should factor that concern into our evaluation of what the right approach to the problem is. 

The problem here is that for this to work you need to make it work for _all_ hosts in the network.
I don’t doubt that you can make it work for a single host stack.
I do doubt that you will make it work well even for that host (well being defined by the multihoming requirements RFC), since most applications do not deal with failing over to different SA,DA pairs well.

You are basically putting a burden on every host and application implementation for the relatively small return of sub-par multihoming.

Compare that to something as simple to deploy as NPTv6. Or PI multi-homing. Or provider assisted multi-homing…

The best approach I can think of is to deploy MHMP as a completely separate network for each provider. Separate SSID and separate interfaces/VLANs. That leaves you with an equally awkward interface as mobile phones typically have, where you manually switch between the providers. Can’t quite see how we can get my light switch to deal with that.

We have tried this for a couple of decades. Time to admit failure.

O.