IETF Logo Mail Archive

Re: [IPv6] Multi6 (no longer RFC 6724 shouldn't prefer partial reachability over reachability)

"Philipp S. Tiesel" <phils@in-panik.de> Fri, 24 November 2023 14:06 UTC

Return-Path: <phils@in-panik.de>
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 0D55BC151089 for <ipv6@ietfa.amsl.com>; Fri, 24 Nov 2023 06:06:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.001, 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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 PXtPDVoLbJ1H for <ipv6@ietfa.amsl.com>; Fri, 24 Nov 2023 06:05:59 -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 EE8B7C151080 for <ipv6@ietf.org>; Fri, 24 Nov 2023 06:05:56 -0800 (PST)
X-Envelope-From: phils@in-panik.de
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 3AOE5edY260531 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 24 Nov 2023 15:05:40 +0100
Received: from x-berg.in-berlin.de ([217.197.86.42] helo=smtpclient.apple) by x-berg.in-berlin.de with esmtpa (Exim 4.94.2) (envelope-from <phils@in-panik.de>) id 1r6WoN-0000by-N4; Fri, 24 Nov 2023 15:05:39 +0100
From: "Philipp S. Tiesel" <phils@in-panik.de>
Message-Id: <E6A96EE7-E6B6-453B-9E10-15C6183B6D6A@in-panik.de>
Content-Type: multipart/alternative; boundary="Apple-Mail=_758A9683-C702-46E4-957F-861EE0D96AA1"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
Date: Fri, 24 Nov 2023 15:05:29 +0100
In-Reply-To: <e75aa1ac-b7c0-a9c4-7577-45a213afaff8@gmail.com>
Cc: Ted Lemon <mellon@fugue.com>, Ole Troan <otroan@employees.org>, Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
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> <e75aa1ac-b7c0-a9c4-7577-45a213afaff8@gmail.com>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2nJqymnQ4gWdZQqdQzyV-DDKcxU>
Subject: Re: [IPv6] Multi6 (no longer 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: Fri, 24 Nov 2023 14:06:03 -0000


> On 22. Nov 2023, at 04:58, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 22-Nov-23 03:38, Ted Lemon wrote:
>> 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.
> 
> I'm now deeply certain that getting rid of getaddrinfo() as the basic tool for address selection is essential to make it work. Trying all possible {source, destination} pairs is necessary.

The time for getaddrinfo() being sufficient is long over… once you get split-DNS or DNS based load balancing like all modern CDNs do, one needs to keep separate DNS caches and results per path/PD/prefix (which of the last one is environment specific) 
Maybe we should somewhat revive Section 6 of this draft: https://datatracker.ietf.org/doc/html/draft-tiesel-taps-socketintents-bsdsockets-02#section-6

AVE!
   Philipp

> 
>   Brian
> 
> 
>> 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.
>> Op di 21 nov 2023 om 09:23 schreef Ole Troan <otroan@employees.org <mailto:otroan@employees.org>>
>>     > Remember that my target market is end users, not enterprise. What sort of routers can an end user buy that will automatically do what you suggest?
>>    What sort of host and applications can an end user buy that supports MPMH?
>>    O.
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email