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

Mark Smith <> Thu, 23 November 2023 10:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0850AC14CE5F for <>; Thu, 23 Nov 2023 02:07:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Status: No, score=-1.601 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_DNSWL_BLOCKED=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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PcJVUe98dOAJ for <>; Thu, 23 Nov 2023 02:07:02 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::52d]) (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 (Postfix) with ESMTPS id 36ED6C1519B3 for <>; Thu, 23 Nov 2023 02:07:02 -0800 (PST)
Received: by with SMTP id 4fb4d7f45d1cf-54a94e68fb1so1802690a12.0 for <>; Thu, 23 Nov 2023 02:07:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1700734020; x=1701338820;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=g4aXxFXWpmOEnvCyliUrwgvYI1RTFuxNnnMMsChzdIM=; b=WFSuJyJouSu3pl9iLfusKHvaHRYjrntJwVc4OYA7kdkh7w83WO6kgs2NxPCDkxCwgj vrEI5yMayYhFD4KHhiPfw6cO+J6jE6/UYLb09ms0N+pY3y41zH3gxdfZhPJ6+rRlsf0+ CkPuURsO+OJN/HGe/IP/+haA+Hkb3OnqrZw+vlRhDvQUlpY8bvJ5dtsOeUaPS1phT11k pxoJQ72TzToU9eUKeIiXmk5ohoIFmDCU5G0YXrwhIPrJWU+jH0U/x1pxA3pxtrDljjw/ cwy0olUsjd08YUeffPCQShUkX9Srvp2hsHIIule/ty/a56s5ZYCczTYVK5yNwf3LY9EL RnFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1700734020; x=1701338820; 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=g4aXxFXWpmOEnvCyliUrwgvYI1RTFuxNnnMMsChzdIM=; b=aZt5g5HgqnWLT8toRaH03O5+FqlTWKejZ89sHvxtlADibI2V08rU6W3cpIqPWJHnh9 9DVRw7kS/Un94AGiFzbJGsbgYKcWammKHxIisLTke5Y7i6UWNn0Iel/+fPbI8rJ3T9/V 3pkQa1e4WzRinE+mbW6eMib/GgpH7WcVaCpcUcVEyvv34jIGqGmV6sDbyfi5D20JEjIv 56EajoTymI6e8YAC/ZLlKyS6mnx4acoMAL5HD6giPmQlUs1SjgOtxXAhBaKXj9/cTVZy 5hbio1j94foMf5jYHTEmNNjpSQLFzfJcZSi3R37xV8RCSA8dEUGWSEO3g1ehEM5eWmtX CpjA==
X-Gm-Message-State: AOJu0YzQ+AEcX9jQXm4u/5Xgv/wiaYyREXa1pOwRgKuopdi0QcH1GXL0 tEzKHhw2qtOH1k1Xnr5zRVoK7TXAq2nVZ7+j7N4=
X-Google-Smtp-Source: AGHT+IHcoAvzpP/j5fcTM8UNDrqD9P0b1UUn4RK6fxs45Nf5Rr6U0fzG348AQIOIlXHY/SSonDjpIuRiV+6URIXEKkI=
X-Received: by 2002:a17:906:100e:b0:9f2:8220:3f57 with SMTP id 14-20020a170906100e00b009f282203f57mr1567295ejm.8.1700734019940; Thu, 23 Nov 2023 02:06:59 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Thu, 23 Nov 2023 21:06:48 +1100
Message-ID: <>
To: "Philipp S. Tiesel" <>
Cc: Kyle Rose <>, Ole Trøan <>, Michael Richardson <>, 6man WG <>
Content-Type: multipart/alternative; boundary="0000000000001dbed3060aceff29"
Archived-At: <>
Subject: Re: [IPv6] RFC 6724 shouldn't prefer partial reachability over reachability
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Nov 2023 10:07:06 -0000

On Thu, 23 Nov 2023, 19:38 Philipp S. Tiesel, <> wrote:

> Hi,
> On 21. Nov 2023, at 20:39, Kyle Rose <>
> wrote:
> On Tue, Nov 21, 2023 at 2:30 PM Ole Trøan <otroan=
>> 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

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

(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.


> 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
> Administrative Requests:
> --------------------------------------------------------------------