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

Mark Smith <markzzzsmith@gmail.com> Fri, 24 November 2023 22:43 UTC

Return-Path: <markzzzsmith@gmail.com>
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 9DB63C151983 for <ipv6@ietfa.amsl.com>; Fri, 24 Nov 2023 14:43:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, 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 (2048-bit key) header.d=gmail.com
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 bUnnoLmcnCHM for <ipv6@ietfa.amsl.com>; Fri, 24 Nov 2023 14:43:39 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 9449AC14F693 for <ipv6@ietf.org>; Fri, 24 Nov 2023 14:43:39 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-5079f6efd64so3128663e87.2 for <ipv6@ietf.org>; Fri, 24 Nov 2023 14:43:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700865818; x=1701470618; 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=oQ3AxelAg//hg8mJxAhuwMlX3CQjNDyB+ZH/Y+hPu90=; b=DCCYOSJC6I7tJr+csa1YByIGn63Whsog191BXZipGQybheVB1JbXuRjYxi/N1uVjfb 8OTVlW3+7+nKyR1q2luepM8mZGiY1L2jvL9/BlbpVMa0aoP4TrwI9kz/0qTeDlQMO26F ntaqEXxEv7EXM0TAZ1vvOGz0fSv+MG5V7XbVusJJziVmWkOWjA133A0f3WNY+cu3AzRS OXHhIMo6CDhM4t3nseSwKGpHAojBnYmARoHSItGZXZhPc4ZDj2JTzoLNJHw1yjD5tCTT k8Y/nY6ogILJ+6hOr5XKTZ3p2zD+yABsPIS5JYfj7fUzEl37/8/4uiFHhb2iql/D2Fng sBfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700865818; x=1701470618; 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=oQ3AxelAg//hg8mJxAhuwMlX3CQjNDyB+ZH/Y+hPu90=; b=h3PP062noSu6qLKFRZRk9XgfmOtPkAn5jkfIma2XKVQwMXQF0MrygA+GMDUTfZYPy0 OKMXCxkx42/gACKQ02kxP+S9mXSO+jCzzpgkT364xW4wg3oOwQncQIsbgd36mxI8Kwo/ CYSJfCMHULxZ0IPaws7Seo6s0ui7NmAMdfCi2ZzGC2PboL6XxA7s6j7/oGSdAsEu0acC p/KODWwinQThbp+0klyBoF5wdTQpHoaM48XmbKU+P/IL1i8e5tS4Z71R5Evz0DgovrPp xkVqxdGZRDKNpIrVLAc7Dn4Qo2n12mt6ek233IeE1+LU0epM58YneP8PzHS5ZtYiSNKO pmFA==
X-Gm-Message-State: AOJu0YzfCCcxu/KpcQTT3uDFCmOsEWhJ9h6O7r6CY0uDrvB9gkPr3Kkj nsR78ix5cmHvTzYR6QL0wlTQ8SOIX+2B2FQEwrQR82GV
X-Google-Smtp-Source: AGHT+IED4c/qoSqc7CI45kjhiyj+jTg6xJqFRtHSKFo1qW92/hNePm8H1ap50rNAmR2CTf1rCdfvDmJM7cOeqEuCyN0=
X-Received: by 2002:a19:7409:0:b0:507:9a49:2d3d with SMTP id v9-20020a197409000000b005079a492d3dmr2378600lfe.31.1700865817478; Fri, 24 Nov 2023 14:43:37 -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> <CACMsEX8q7dmRAVXuOZFVS+z_hrks=n0ChBHR4Bz9gB9ryF0ZAA@mail.gmail.com>
In-Reply-To: <CACMsEX8q7dmRAVXuOZFVS+z_hrks=n0ChBHR4Bz9gB9ryF0ZAA@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sat, 25 Nov 2023 09:43:26 +1100
Message-ID: <CAO42Z2yFiKs09K-O+SxDytLst_Uu4MAae65PTgz3URLnc5MnQw@mail.gmail.com>
To: Nick Buraglio <buraglio@forwardingplane.net>
Cc: 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dc8932060aedaec9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8zkbonCLm8tD1osCLULJSsPcSsw>
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 22:43:43 -0000

Demoting IPv4 to below ULAs, but not above GUAs, doesn't restore ULA
behaviour to as it was designed, as a replacement for site-locals.

It was very clear to me what the problems with site-locals were at the time
because I'd just worked on permutations of RFC1918 addressing and NAT for
large scale IPsec VPNs. Many of the problems with site-locals, documented
in RFC3879, also exist with RFC1918 addressing, and were also partly
covered in RFC1627, "Network 10 Considered Harmful".

Site-locals were preferred over GUAs due to the scope comparison in Rule 2
of DA selection.

I really think this is the last time SA/DA default address selection can be
changed, given how long these changes take to get deployed.

If this update doesn't properly prefer ULAs over GUAs, then all it is doing
is replacing one problem (IPv4 over ULA) with another problem (GUA over
ULA).

On Sat, 25 Nov 2023, 08:17 Nick Buraglio, <buraglio@forwardingplane.net>
wrote:

> 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
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>