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

Nick Buraglio <buraglio@forwardingplane.net> Mon, 20 November 2023 14:02 UTC

Return-Path: <buraglio@forwardingplane.net>
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 72DA0C151088 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2023 06:02:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forwardingplane.net
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 73RSxt14VMMT for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2023 06:02:55 -0800 (PST)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4724CC151545 for <ipv6@ietf.org>; Mon, 20 Nov 2023 06:02:55 -0800 (PST)
Received: by mail-qt1-x82a.google.com with SMTP id d75a77b69052e-41cd8bd5727so26107511cf.3 for <ipv6@ietf.org>; Mon, 20 Nov 2023 06:02:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forwardingplane.net; s=google; t=1700488974; x=1701093774; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Q4VVrx3/jcRsKZVte3lmhSFPhpsZ5km4bLHSbr6saFY=; b=VUdyaTPioPatsfBJAakmgJkVKUBamHjw2bVycLyoGzqnuO0Ej7M3WWYFYn0LV8vJHS 1O1CrXLR+tzMzWSNDH2R7mhLsu3Af4UvU6IG+QkZptLJWIrEAt6dFMTfmq8jax9tPxwv Y59f9FgGjP1KRq3crBPhIZigJgcYSAZMsClYU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700488974; x=1701093774; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Q4VVrx3/jcRsKZVte3lmhSFPhpsZ5km4bLHSbr6saFY=; b=YRToRW5XZ9kBmatLUWOM1mlXWJNnHFmXk0JuQJ/e7rSLIeEP7Vcg5inxKl697ezn1L rPUehkCMJiqAWOzRmriHxBOUaLXQ5SUv5fZ6GHEhPjR7/qwnuXP+jj3BjQWMBOC3znAO TWHOURq1pM4d8GJm8WFJ3z49E837d4InzP33miH5Gjl+auMvSgQ+EAPFhJv2/yHAGmSt 1XCUKfhrRv/Zs4K0N13QQofVKQJD7XVgxxUTebdQcONEvUrIGZLklX2WnsJZBhKV51QF VvhQkiSyLhpGqDTekDlP3JI5MYHTvONbzZLaKW/B3TuqRjmkhAd+I3wj5ySwxjywPOJ+ +4WA==
X-Gm-Message-State: AOJu0Yw9jBs7maCVx5AcdspUPE/k0qvLoWQwhK2JnpU9cdAw/0kq8r4u nK9LkxIW76hGbTNODfeZ3uUx3xxSsXgRABtfBw4Vzw==
X-Google-Smtp-Source: AGHT+IG3o2rkeuKDjLHebysGNJbNQ/iKVXy7htMfOoY6GeZhOHLbI5Ws1DZ2quiSBxB7mtKWTZu5h6bOWrXUkKmGQqE=
X-Received: by 2002:ac8:5b84:0:b0:417:fa78:586c with SMTP id a4-20020ac85b84000000b00417fa78586cmr9576888qta.58.1700488973298; Mon, 20 Nov 2023 06:02:53 -0800 (PST)
MIME-Version: 1.0
References: <CAKD1Yr2uD+XE+HA6vs3BfEchpWr5H2NEeoXLrXm7-U9_ckw1sA@mail.gmail.com> <CAN-Dau2Nw21wUm-mjxq3bnYczPJbApVhcZZ6oie+HiB4yvr_PQ@mail.gmail.com> <CAKD1Yr1z2x8iKXYQtPVifj-XkP7MeRq=NWe0gdWBGC1aS_j0Mg@mail.gmail.com> <CACMsEX8f_qmpZ898vKLy_56Jy1WKEju94fYEz5fuV4Pc3iJ=tw@mail.gmail.com> <CAKD1Yr1tZa0W=617hQrgYYqmUbfgFp7EhmvgqKzaBvF=r=5FuA@mail.gmail.com> <CAJU8_nUOjrO5FPPXTCNeA-9YuSPT7SmGkiM82DGiMacyfntV6w@mail.gmail.com> <CAN-Dau0FP31h3s+Fzbam7GJg-rNGsX3m8Hx3k=+895NT0a4iqw@mail.gmail.com> <CAPt1N1=_BmOZNvOc00qdhS84REnr-thBFgrjcixsEc=+jMSOfg@mail.gmail.com> <CAN-Dau1A4=5Q6mckZ35T_Gs1ty=zSAYUOS+1-nw1rAD2eH+o9w@mail.gmail.com> <CAO42Z2yU+uHDP-xi_D6tCA45UmSiCQ2bZSUe38edEWs5o_YCeg@mail.gmail.com> <CAKD1Yr2YW-ZeyooT6tzmjoE2WJAcUcohf2C6CMj3e41J8XaLvQ@mail.gmail.com> <4106220.1700174829@dyas> <8031DEBD-BC22-480E-91FF-8F9EC1EDC2A7@employees.org> <4124157.1700231123@dyas> <17E321B1-B65C-4761-96C1-D69598AB9D53@tiesel.net>
In-Reply-To: <17E321B1-B65C-4761-96C1-D69598AB9D53@tiesel.net>
From: Nick Buraglio <buraglio@forwardingplane.net>
Date: Mon, 20 Nov 2023 08:02:41 -0600
Message-ID: <CACMsEX9RiUDKWL+47GaxQ9Q36bBjMqiTgJ16Ob+5FPbGAxNozQ@mail.gmail.com>
To: "Philipp S. Tiesel" <philipp@tiesel.net>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000032c6e2060a95f1e7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/i-qbpHn2uRGR88nbZQonrxSMJHI>
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: Mon, 20 Nov 2023 14:02:59 -0000

On Sun, Nov 19, 2023 at 3:33 AM Philipp S. Tiesel <philipp@tiesel.net>
wrote:

> Hi,
>
> On 17. Nov 2023, at 15:25, Michael Richardson <mcr+ietf@sandelman.ca>
> wrote:
>
>
> Ole Troan <otroan@employees.org> wrote:
>
> To work well, we need some kind of system-wide _give me a socket to "name"_
> daemon, which does all the getaddrinfo() work, knows the list of
> (per-provider-domain) network addresses, and can cache all of that info.
>
>
> I thought this idea had lots of promise:
>
>
> https://datatracker.ietf.org/doc/html/draft-ubillos-name-based-sockets-03
>
>
> That has some on-the-wire implications, as I read it.
> There is also this effort:..damn... it was presented at RIPE last year,
> but I
> can't find it.
>
>
> All these things are done in TAPS… with the difference that it is
> deployable one-sided and already has one widely deployed implementation
> from Apple:
> https://datatracker.ietf.org/doc/draft-ietf-taps-arch/
> https://datatracker.ietf.org/doc/draft-ietf-taps-interface/
>
> Yes, it needs a log of nifty details to get right including Rule 5.5,
> using src-dst-routing and keeping DNS separate per PD/Interface but may
> also solve the multi-homing without NAT.
>

The more I think about it, the more I am thinking that it may be a
deployable solution for multihoming, with all of the details in appropriate
stages of hand waving.


>
> It not that it is so hard to do, it's that it takes some perserverance to
> get
> it upstreamed into all sorts of desktop OSs, embedded OSs, and to patch the
> API into the dozens of tools that need it.
>
> I think it's a 7-10 year duration effort, requiring 1/3 FTE.
>
>
> Right… but it takes a lot of people to agree that it should be done to
> begin with,
>
> AVE!
>    Philipp
> --
> Philipp S. Tiesel
> https://philipp.tiesel.net/
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>