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

Kyle Rose <> Tue, 21 November 2023 17:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3585C14CE4B for <>; Tue, 21 Nov 2023 09:32:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HPlOCiukau8I for <>; Tue, 21 Nov 2023 09:32:03 -0800 (PST)
Received: from ( [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 (Postfix) with ESMTPS id B09ADC14F5E0 for <>; Tue, 21 Nov 2023 09:32:03 -0800 (PST)
Received: by with SMTP id 2adb3069b0e04-507ad511315so8251328e87.0 for <>; Tue, 21 Nov 2023 09:32:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1700587921; x=1701192721;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mPa2u75DxQS1QdUC3g/y5dvDyVG/Lt9xr/1qkPjEAwg=; b=EKmmb4oNqPUzH5+RcWyc3TIJ0Hc4yhADbkVUJgrRIRgeG+VKpdl0Sl4mU4d0u4pdL8 90Ekkd7CIwV4lWik2bCuwcGiqVl1bImjEIAdjFM8MdWLEBHlMQNN43rkUL7KsqhxdHPI 7Um5YYPMFCLDB2Qb4/7kBes+PYaMthGYXyaiw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1700587921; x=1701192721; 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=mPa2u75DxQS1QdUC3g/y5dvDyVG/Lt9xr/1qkPjEAwg=; b=eFijuYu+upCRiMRTCW6Cyoe0bNqb+od/tb7FGb43Q7+zb67poh4OJrohGZSaEW5SYb k/UgUjPFaM8pDlQiSjskEDmHULwZFTGy00jwZWhorG75vMWxogmQK9Xqhb39ITZZEs1K S4N3gCTdjEkgDcpDGxWnE5uYado8B3dTrfgK4CaopvPzfq2M7nnrvrriSy4RCtBYf10E 92shuL4lNixjQp/QeCOIWSbHbEDWpmDKwl55ckafkgck87OIIegrJy7KokOhJJLIbv4Z JLCZiHdQyLSVlnIOw4vVm1emJfIZlNQ5KyRMcvlDoBDD4EKgyvfdq+ES2dqXCIr5evOp ytrA==
X-Gm-Message-State: AOJu0Yxf/8wnyGZeiwM4bUEkZ87W6lCEnGqJS005ce5fn3EiDJxpuIvW 2LqUd0e+CXKPxZIm0ZCik4ka3YXcH+S0q6J6Ut36BNFk061T4Qdk
X-Google-Smtp-Source: AGHT+IE+BeF5s7Jc7Yd/+Clhlm1bCPGevb464kXX+Eua018JZJFOBb5mYqKNNSgNQ3ax7/MPJzCRxjdcQBcpxhjSj9g=
X-Received: by 2002:ac2:5239:0:b0:500:b553:c09e with SMTP id i25-20020ac25239000000b00500b553c09emr7865232lfl.32.1700587920930; Tue, 21 Nov 2023 09:32:00 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Kyle Rose <>
Date: Tue, 21 Nov 2023 12:31:49 -0500
Message-ID: <>
To: Ole Trøan <>
Cc: Ted Lemon <>, Michael Richardson <>, 6man WG <>
Content-Type: multipart/alternative; boundary="000000000000efd736060aacfada"
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: Tue, 21 Nov 2023 17:32:09 -0000

Someone help me out here, because I think I need a few blanks filled in
with regard to MHMP.

When attempting to work through a straw man implementation, I ran into the
problem that there is no way to signal to the client "use GUA from prefix A
for default route X, and use GUA from prefix B for default route Y". This
implies that simply force-deprecating a prefix when a link goes down
(setting preferred_lft to 0 in subsequent RAs) won't work because the up-up
scenario would end up with clients arbitrarily using the wrong prefix for
the wrong router.

Does that capture it? If so, that is solved by rule 5.5, so 5.5 should be
made mandatory. But also, I am forced to agree with Ole that this is not a
near-term solution. (Not that we shouldn't fix it, only that it won't
immediately enable MHMP, so you'd need forwarding between routers to deal
with the long tail of clients that don't upgrade.)


On Tue, Nov 21, 2023 at 12:06 PM Ole Trøan <otroan=> wrote:

> On 21 Nov 2023, at 17:19, Ted Lemon <> wrote:
> Indeed. And nobody is stopping anyone from offering it—I think we know how
> to do it. So I don't see a real issue here—we don't actually have to pick.
> What I'm reacting to is the apparent assertion that we shouldn't try to
> improve IPv6 stacks—that e.g. implementing rule 5.5 correctly is pointless.
> I don't agree with that.
> Where exactly did I say that rule 5.5 was pointless?
> O.
> On Tue, Nov 21, 2023 at 10:32 AM Ole Troan <> wrote:
>> Ted,
>> > Honestly, it feels to me like we are converging on something that
>> works, and you are tired of it and are therefore proposing to snatch defeat
>> from the jaws of victory.
>> >
>> > It’s taken a long time to do this because the market pressure isn’t
>> there, not because it’s impossible to do.
>> It’s taken a long time for nothing to happen.
>> Nothing has continued to happen.
>> There are millions of IPv6 nodes deployed.
>> That’s not trivial to upgrade.
>> No, it’s not impossible to do. All the pieces to do it have been
>> described for years.
>> But just like SHIM6, ILNP, end to end IPsec, Multicast, IP Mobility, that
>> doesn’t guarantee success.
>> Don’t know what kind of Herculean effort would be required. Interops and
>> bakeoffs, IPv6 ready testing program, lots of guidance to application
>> developers, new socket abstractions…
>> The other multi-homing mechanisms gives better (for some definition of)
>> multi-homing with none of the host changes required.
>> Cheers,
>> Ole
>> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------