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

Ole Troan <otroan@employees.org> Tue, 21 November 2023 19:56 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 14AA2C15153E for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 11:56:41 -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 z9ZsIefjgvMs for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 11:56:37 -0800 (PST)
Received: from proxmox01.kjsl.com (proxmox01.kjsl.com [IPv6:2607:7c80:54:6::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 468B2C14EB1E for <ipv6@ietf.org>; Tue, 21 Nov 2023 11:56:37 -0800 (PST)
Received: from proxmox01.kjsl.com (localhost.localdomain [127.0.0.1]) by proxmox01.kjsl.com (Proxmox) with ESMTP id 15E0AE63A6; Tue, 21 Nov 2023 19:56:37 +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=pslYopBS0K02i/ij R8AOy6iCm+iMo9ejwINRh+0ld10=; b=pv/4lf4KNQf2iCgBGEMIWw9cNx2Sscd1 s3/ryLF+kYTVk3g8nNUtLXxsLyWPzp81+CBFm/88eXzBoladRMz6UTFHqw5jlAz7 LQsXWIjG9npy3ijzjF0pkM2r8QPgKveNUE2V6EjRq8TiA+s0OJ70TKmvfWnJlORA Nc0g4cMx1y2Zqsg43QxbBBY99TWIJIH8IbwoQ6phqBo2vLAgrYC+MS+tC2x9Mpx7 CO5O/4/JKcewZas+zyLRi58HAG6WoOOihAE4ivgtelUTIyBWU+6uL5mZQQ/My+BB kLwKBIJFKjkEcwjIbr4WkTsgvyCCvWLBxLl/oWZW5RxFlrxL3hzgFw==
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 EA262E62E8; Tue, 21 Nov 2023 19:56:36 +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 27B214E11B8F; Tue, 21 Nov 2023 19:56:20 +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: <CAJU8_nVQFvp_5ZnkByCvBeA7wFz9J5FVAeud2CD1Xd4UkyL_3Q@mail.gmail.com>
Date: Tue, 21 Nov 2023 20:56:08 +0100
Cc: Kyle Rose <krose@krose.org>, Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FB632ACA-E85F-416A-BDC1-915141A8D5CE@employees.org>
References: <CAJU8_nV2QoGjZoegcUSXELqgeqW6OheTt32qq6YQ5XV0g5MPQw@mail.gmail.com> <10D22CA5-CD7A-471A-B4A9-21B77D16F5F7@employees.org> <CAJU8_nVQFvp_5ZnkByCvBeA7wFz9J5FVAeud2CD1Xd4UkyL_3Q@mail.gmail.com>
To: Kyle Rose <krose=40krose.org@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RZUJfo5z7XX5rJh9HUJjlKjJNrE>
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 19:56:41 -0000

Kyle,

> Covered most of this in 7157. Including signaling policy to hosts. Good to know. I'll read that in-full.
> 
> In your straw man implementation try implementing an application using the BSD socket API and make sessions survive any set of failures along the two paths. Well, try with any networking api actually.  :-)
> 
> This is mobility, and I regard mobility as an unsolved problem, and one that is potentially too complicated to solve transparently (witness: LISP). In a failover scenario, I assume all connections tied to the now-down path (e.g., through provider-delegated addresses) are broken. That's fine for the use cases I am concerned about. Past some point, I'm okay with applications having to take basic remediation measures, like reconnecting, as long as that works more-or-less immediately.

Problems are overlapping, but I’m talking about multi-homing.
With MPMH today, I’d suspect a good part of hosts wouldn’t fail over at all.
Little point in doing multihoming if it doesn’t improve resiliency, increase bandwidth, etc.
I’m all for implementations improving regarding Rule 5.5. and applications becoming resilient against connection failure (which is also needed for NAPT44).

Connection survivability is not possible with MHMP (nor NPTv6, nor NAPT44). So we need applications to improve regardless.

What I’m arguing against is touting MPMH as a solution for multi-homing for small networks.

It would be interesting to bring up a more comprehensive test lab to figure out what works or not. But it would be quite the project.

O.