IETF Logo Mail Archive

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

"Philipp S. Tiesel" <philipp@tiesel.net> Sun, 19 November 2023 09:33 UTC

Return-Path: <philipp@tiesel.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 8F2BEC14CEFC for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2023 01:33:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.604
X-Spam-Level:
X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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
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 Pa9ZqQ8cnKnx for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2023 01:33:47 -0800 (PST)
Received: from einhorn-mail-out.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) (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 AD934C14F693 for <ipv6@ietf.org>; Sun, 19 Nov 2023 01:33:45 -0800 (PST)
X-Envelope-From: philipp@tiesel.net
Received: from x-berg.in-berlin.de (x-change.in-berlin.de [IPv6:2a0a:4580:1018:0:0:0:0:40]) by einhorn.in-berlin.de with ESMTPS id 3AJ9XVxB715006 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sun, 19 Nov 2023 10:33:31 +0100
Received: from dhcp-248.in-panik.de ([217.197.86.248] helo=smtpclient.apple) by x-berg.in-berlin.de with esmtpsa (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <philipp@tiesel.net>) id 1r4eBG-0006mF-Ns; Sun, 19 Nov 2023 10:33:30 +0100
From: "Philipp S. Tiesel" <philipp@tiesel.net>
Message-Id: <17E321B1-B65C-4761-96C1-D69598AB9D53@tiesel.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_994AD126-7FE4-45C8-AE07-2F4BDEAC027F"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
Date: Sun, 19 Nov 2023 10:33:20 +0100
In-Reply-To: <4124157.1700231123@dyas>
Cc: Ole Troan <otroan@employees.org>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, 6man WG <ipv6@ietf.org>
To: Michael Richardson <mcr+ietf@sandelman.ca>
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>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/aVGm8DtpQJigncQv1HymSY59IgM>
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: Sun, 19 Nov 2023 09:33:50 -0000

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.

> 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/

v2.23.0 | Report a Bug | By Email