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

Ed Horley <ed@hexabuild.io> Fri, 24 November 2023 22:49 UTC

Return-Path: <ed@hexabuild.io>
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 C7A42C14F693 for <ipv6@ietfa.amsl.com>; Fri, 24 Nov 2023 14:49:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=hexabuild-io.20230601.gappssmtp.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 Md6LlVWiEEMe for <ipv6@ietfa.amsl.com>; Fri, 24 Nov 2023 14:48:57 -0800 (PST)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 B78DFC151983 for <ipv6@ietf.org>; Fri, 24 Nov 2023 14:48:57 -0800 (PST)
Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-50797cf5b69so3271563e87.2 for <ipv6@ietf.org>; Fri, 24 Nov 2023 14:48:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hexabuild-io.20230601.gappssmtp.com; s=20230601; t=1700866135; x=1701470935; 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=4YGOpUMfVXZD6n3dgDj369dP2IM4sMjPypNYccW74pg=; b=hF2I2BOMqLYpioPT8gMUnDFfx7etaLBnWmIooALV3DyMKCzKfapv0df+9L7lN+j/6w /R3EyOO18ee+ByWt1VSp9LpIgSlNJ+Apaq96upGEe/vfUfcUktgwv6ljo0ILtnZuNMAR 1XVC9YhJ1g9w8Nt8H8sQv+i9WR6vHtwTRVjetKKvABAxOPggy1K/nUazB4LmzocDElWC fSKC8vQXs46OXxqYNE7gtdgSs+tcV7dGr0FZ2esl4mB+WDnmm/HnX4GL+WqAYzBk/QDm zgRzj2ZVJ8CJN5D9wkJuY+YW2q2S+dKhQC7IMD9C4+4RogBHzoDaGsvkWKRcUQD34dF3 Ey6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700866135; x=1701470935; 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=4YGOpUMfVXZD6n3dgDj369dP2IM4sMjPypNYccW74pg=; b=hFqYv51stgZzwXIWYI3D5ayYnUtaHxq3elyaluxto9txSVpqFZocyX/SGrQ6uUcx8f 2QswZ00nctVIKYBBneWkPZB20RhFYH0GD5LTkInB38OM07z1GdSXcpT8Rb+8NXlk3Jda YpOnBJQikfRte2H7qoOV7fhBuAC3rev9Npwf44xhUxtxWKXmxRHkDP37k2cA5CmJTWqb 8kDYhGjD7iIv7itN/0GfMMYAXBXcZ51CPb/qrQlM0NgqH8KPa8p0GFwKsSNAC1NEwIah 1gZ0TY9CGy3KhFawesRE1oB9Ow4XJiHAgSsltPtGWxfrx+68UX5CSQ7z9eY8/vD6AjGu gJiw==
X-Gm-Message-State: AOJu0YzqMQkx+mmRBlm79s1VoBXCDMK8cNaLYdcCTrLsN7emYS8NbdvL zygNf+sGa53F9h1lZV/DQ+ND2tpGuL0rE5gFRb05hQ==
X-Google-Smtp-Source: AGHT+IFMILrgZDe2VvFwUaSozuyvRI6IuvaTb7+7KEuw83GU76uwnrbU02R+W2xhCKOVCWp8lKcO+IH5hOSGaelaZUU=
X-Received: by 2002:ac2:5e9e:0:b0:50a:a571:88 with SMTP id b30-20020ac25e9e000000b0050aa5710088mr2826909lfq.61.1700866134947; Fri, 24 Nov 2023 14:48:54 -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> <CAO42Z2yFiKs09K-O+SxDytLst_Uu4MAae65PTgz3URLnc5MnQw@mail.gmail.com>
In-Reply-To: <CAO42Z2yFiKs09K-O+SxDytLst_Uu4MAae65PTgz3URLnc5MnQw@mail.gmail.com>
From: Ed Horley <ed@hexabuild.io>
Date: Fri, 24 Nov 2023 14:48:43 -0800
Message-ID: <CAE=N4xcFU+87wXy8NkHuO7rZ-T7Z7VmTkfcYFJH3PAJ+8+NPww@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
Cc: 6man WG <ipv6@ietf.org>, Nick Buraglio <buraglio@forwardingplane.net>
Content-Type: multipart/alternative; boundary="000000000000c8cc93060aedc1cb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/NsOmHZwBD8rql_fU3J4zmaO51Bg>
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:49:01 -0000

Other option is to just remove the ULA prefix entirely from 6724 and then
the OS doesn’t see it as any different then GUA (or set it the same
precedence as GUA) and leave it to OS vendors to determine ULA versus GUA
for reachability and then longest prefix match will pretty much take over
for most situations. Just a thought.

ed@hexabuild.io - 925-876-6604


On Fri, Nov 24, 2023 at 14:44 Mark Smith <markzzzsmith@gmail.com> wrote:

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