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

Nick Buraglio <buraglio@forwardingplane.net> Fri, 24 November 2023 21:16 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 E313DC14F739 for <ipv6@ietfa.amsl.com>; Fri, 24 Nov 2023 13:16:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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
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 MH9b79zrm98M for <ipv6@ietfa.amsl.com>; Fri, 24 Nov 2023 13:16:44 -0800 (PST)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 34574C14F726 for <ipv6@ietf.org>; Fri, 24 Nov 2023 13:16:44 -0800 (PST)
Received: by mail-qk1-x72a.google.com with SMTP id af79cd13be357-77d67000b69so126169685a.2 for <ipv6@ietf.org>; Fri, 24 Nov 2023 13:16:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forwardingplane.net; s=google; t=1700860603; x=1701465403; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=r/2Ms6soxjoJTWaeQhulZXzYQ5go+1c9ZzD+uDovb2E=; b=aPXyVSS4QpbQ9lxa8ikfs5VYOh31WJwQ61xFyMS5F8fq3nAOZnwXd/dMjxKl7Z2B0C 6cAuLgs0UMgBovlPI5BKZFUEJ8mgZSL84E/MwDsRyYs+o9zZcm/IyQivZy1RvbppIMmQ z26fHmzW3nXMeHNnLpPRUKTXUpsYfgEqJTwPY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700860603; x=1701465403; h=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=r/2Ms6soxjoJTWaeQhulZXzYQ5go+1c9ZzD+uDovb2E=; b=tj+sP25KRAVap8539vEQednBZ9SQ1w65FW8WUmPnZFehWr638lrQG/Qgmwf7M8GlCq 3lk/sulWomJ8c6Yzm1bKjFiforxyTwV0JGJAwBknXZT1jbIp58c/7fCsMJhmuvUSwrKg ojquT7X5uhYxF1Bi3MKm8n7b2x+BsKV16P8JTzSCqY7YpCWa45CWUqEwJlgSPYsxWvRy OqjOIBCG0d5Ona4AdVe5klXvlBuDO78Lgc+wJxCh9Dctn/viO0bQr5waQexdx1Bd8eQh dxBFYmpLme0Hzq6vf5FGQGPpBYbHT6i+2ijkiIZ0tTdQ6kq9CbY8BpvbkboIi7o1M1LE 0xjg==
X-Gm-Message-State: AOJu0YykeZqjsQCD1iY/bUT9z7sGY3p+axL6BM9crlYYHv5f5fXImprq 91ryEr+FH9nq/kJDBftWeyqP8rIbVEqyDpwy+P/K0JxBPeuQLhdHNyc=
X-Google-Smtp-Source: AGHT+IHQvvO54PXLhYk2OOcJQMXNf+RhHw59iBXJGSP0qczpgDNBq5FKviMc0dxR78KzEzvs030qNLFUdmdp35HtPSI=
X-Received: by 2002:a05:622a:18d:b0:41c:c8f2:58ce with SMTP id s13-20020a05622a018d00b0041cc8f258cemr5515777qtw.27.1700860603076; Fri, 24 Nov 2023 13:16:43 -0800 (PST)
MIME-Version: 1.0
References: <CAJU8_nV2QoGjZoegcUSXELqgeqW6OheTt32qq6YQ5XV0g5MPQw@mail.gmail.com> <10D22CA5-CD7A-471A-B4A9-21B77D16F5F7@employees.org> <CAJU8_nVQFvp_5ZnkByCvBeA7wFz9J5FVAeud2CD1Xd4UkyL_3Q@mail.gmail.com> <4202668E-EEBE-4FA6-9801-F2A9FC92CBD8@tiesel.net> <CAO42Z2y9g3ebZ2VuXDFSK71p3X2VMVQu2=h+sXSVhcfvvxn-Qg@mail.gmail.com>
In-Reply-To: <CAO42Z2y9g3ebZ2VuXDFSK71p3X2VMVQu2=h+sXSVhcfvvxn-Qg@mail.gmail.com>
From: Nick Buraglio <buraglio@forwardingplane.net>
Date: Fri, 24 Nov 2023 15:16:31 -0600
Message-ID: <CACMsEX8q7dmRAVXuOZFVS+z_hrks=n0ChBHR4Bz9gB9ryF0ZAA@mail.gmail.com>
To: 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000f24e9060aec78f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/AaY0vunVuX1REjtfaiKBjvgQ7MA>
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: Fri, 24 Nov 2023 21:16:48 -0000

I do agree that there are quite a number of difficult and interesting
problems to solve here, but I fear this has strayed quite far from the
original intention of demoting IPv4 in the address selection process. It is
true that all of these technical challenges are very closely interrelated.
However, I suggest we create a list of bite sized issues and try to
compartmentalize them as best we can.

For this draft (6724-update) I see the following:

demote ipv4
deprecate / demote 6to4
Create a must for 5.5*

Related and open issues:

creating better flexibility for multihoming**


* If this is a point of contention, I suggest we either agree to disagree
and take it back out and work on the simpler fix, or - and probably better
overall - leave it in and massage it into something that we can live
with, understanding that the incremental progress will be harder
to implement at the start and will have a long tail to mainline. I do think
it helps, but it won't solve things like n-hops upstream route changes.
Maybe that's ok?

** This is a pretty large issue mired in very, very strong philosophical
differences in ways to solve it. Given that, we should table it for the
context of this draft and revisit it independently or after.

On Thu, Nov 23, 2023 at 4:07 AM Mark Smith <markzzzsmith@gmail.com> wrote:

>
>
> On Thu, 23 Nov 2023, 19:38 Philipp S. Tiesel, <philipp@tiesel.net> wrote:
>
>> Hi,
>>
>> On 21. Nov 2023, at 20:39, Kyle Rose <krose=40krose.org@dmarc.ietf.org>
>> wrote:
>>
>> On Tue, Nov 21, 2023 at 2:30 PM Ole Trøan <otroan=
>> 40employees.org@dmarc.ietf.org> wrote:
>>
>>> 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).
>>
>>
>> Right. However, there are transport protocols like QUIC and MPTCP that
>> can do it without too much hassle for the application.
>> I really prefer a mobility mechanism that is end to end and works on some
>> devices now. instead of discussing about L3 mobility mechanisms we might or
>> more likely might not getting deployed eventually.
>>
>
>
> I think Layer 3 is the wrong layer to solve the locator/identifier problem
> at.
>
> I call you from my phone number, we have a conversation, and then my phone
> battery dies without notice.
>
> I then immediately call you from a different phone, you answer, and then I
> say, "It's Mark", and then our conversation can and will continue from the
> point it stopped at when my phone battery died, independently of my
> (original) phone's phone number.
>
> In this scenario, the phone numbers where the locators, however the
> identity is "Mark". The phone numbers don't matter as long as the identity
> persists across phone numbers.
>
> My guess is that the locator/identifier problem came about because when IP
> was split off from TCP ("TCP/IP"), they didn't make TCP independent enough
> from IP attributes. If they'd changed TCP to have a connection identifier
> that was entirely independent from IP packet attributes, we wouldn't have
> had the locator/identifier problem.
>
> 6man needs to stop trying to solve a problem that is better solved at a
> higher layer. Phone numbers/IP addresses don't matter if the packet gets
> there and can be associated with an existing conversation/transport layer
> connection.
>
> (I realised this when I used OpenVPN back in around 2001 to carry a
> Ethernet over a dial up connection to get access to IPv6 I had in our lab,
> and for that to survive the different IPv4 addresses I would get on each
> dial up connection. Drop outs were inevitable on dial up.)
>
> As for legacy transport layer connections that do rely on IP addresses,
> they can be shimmed, so they don't realise packets' IP addresses are
> changing under them - which is what MPTCP does.
>
>
> Regards,
> Mark
>
>
>
>
>> 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.
>>
>>
>> Fully agreed.
>>
>> AVE!
>>    Philipp
>>
>>
>>
>> --------------------------------------------------------------------
>> 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
> --------------------------------------------------------------------
>