IETF Logo Mail Archive

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

Ole Trøan <otroan@employees.org> Tue, 21 November 2023 17:06 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 40F96C151067 for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 09:06:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.214
X-Spam-Level:
X-Spam-Status: No, score=-1.214 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, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, 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=no 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 91Yh-ccTYRU3 for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 09:05:56 -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 6A266C14CE22 for <ipv6@ietf.org>; Tue, 21 Nov 2023 09:05:56 -0800 (PST)
Received: from proxmox01.kjsl.com (localhost.localdomain [127.0.0.1]) by proxmox01.kjsl.com (Proxmox) with ESMTP id 022ECE6194; Tue, 21 Nov 2023 17:05:56 +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=sdXxdPDPah2OX4o4 2wg94PZsy0XTAyHTIbJgL4RR4hM=; b=OqUdkJX/Ni4C8GZom0wi2V73hZVyWsla Wb7ky+1XarnIgZSyYI72nuKncTQrl3jbD32Uyqpq/4EyOdxfLLsUjBNSnWLyUxZp uGa4OKJV8Hg/fJ5MABdty/JfOW/XwqBpbQ7dGwG02sBfWNdNz4egdPFSg9VldQbV iwp1B+7RLaSOkqNXrFqKTz9uVw1xOZE0TRgjl+U0ivnP3nZ2C7DH4aL32Mzkpvvk WZOeMQGZmIcX/jQtvPHTz7qjwSYChD/H74SoEBwDEaQ3BWS1OxFBnTPKEgkHo5DW K6s2ij7og8G0+D00+NNOkVwsALrS7yDldvQQXMvIvbzWzFGYeEWKxQ==
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 D4B5FE6163; Tue, 21 Nov 2023 17:05:55 +0000 (UTC)
Received: from smtpclient.apple (77.18.56.240.tmi.telenormobil.no [77.18.56.240]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id E8AD34E11B9E; Tue, 21 Nov 2023 17:05:36 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-AA7078EB-2469-436A-8BFE-B5ABB0C9E400"
Content-Transfer-Encoding: 7bit
From: Ole Trøan <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Date: Tue, 21 Nov 2023 18:05:22 +0100
Message-Id: <36E7983C-B8C4-4945-BF70-73B196AF9841@employees.org>
References: <CAPt1N1mXJ6tdvEG9EsTDYxpPHTR3FH74Hp7nUnjQM8j2T3pPcg@mail.gmail.com>
Cc: 6man WG <ipv6@ietf.org>, Lorenzo Colitti <lorenzo@google.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Nick Buraglio <buraglio@forwardingplane.net>
In-Reply-To: <CAPt1N1mXJ6tdvEG9EsTDYxpPHTR3FH74Hp7nUnjQM8j2T3pPcg@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: iPhone Mail (21B91)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/MBfqFJuA6tBstyQbme5J0yWv_Gc>
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 17:06:00 -0000



On 21 Nov 2023, at 17:19, Ted Lemon <mellon@fugue.com> wrote:


Indeed. And nobody is stopping anyone from offering it—I think we know how to do it. So I don't see a real issue here—we don't actually have to pick. What I'm reacting to is the apparent assertion that we shouldn't try to improve IPv6 stacks—that e.g. implementing rule 5.5 correctly is pointless. I don't agree with that.


Where exactly did I say that rule 5.5 was pointless?

O. 

On Tue, Nov 21, 2023 at 10:32 AM Ole Troan <otroan@employees.org> wrote:
Ted,

> Honestly, it feels to me like we are converging on something that works, and you are tired of it and are therefore proposing to snatch defeat from the jaws of victory.
>
> It’s taken a long time to do this because the market pressure isn’t there, not because it’s impossible to do.

It’s taken a long time for nothing to happen.
Nothing has continued to happen.

There are millions of IPv6 nodes deployed.
That’s not trivial to upgrade.

No, it’s not impossible to do. All the pieces to do it have been described for years.
But just like SHIM6, ILNP, end to end IPsec, Multicast, IP Mobility, that doesn’t guarantee success.

Don’t know what kind of Herculean effort would be required. Interops and bakeoffs, IPv6 ready testing program, lots of guidance to application developers, new socket abstractions…

The other multi-homing mechanisms gives better (for some definition of) multi-homing with none of the host changes required.

Cheers,
Ole




v2.46.0 | Report a Bug | By Email | System Status