[IPv6] Multi6 (no longer RFC 6724 shouldn't prefer partial reachability over reachability)

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 22 November 2023 04:08 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4BAB3C152573 for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 20:08:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Nrs_ZJAWTTCD for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 20:08:05 -0800 (PST)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 37D88C1524AC for <ipv6@ietf.org>; Tue, 21 Nov 2023 20:08:05 -0800 (PST)
Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-6bd32d1a040so6394705b3a.3 for <ipv6@ietf.org>; Tue, 21 Nov 2023 20:08:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700626084; x=1701230884; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7TpaziSqWi2SuqrjQaZvWNpsc9sL17Vv+BYjIKk7DKg=; b=E5zzt9+S7xH1Xe8lAn6UUrSIS3MiSdHicsY1hvPSi62k8JS2RJD2UzeWyyNM6y204V fH+ojGNSYQAQgPgvsySQZutPzCS2sBl0cirOkZYa5ygm7FBdiJbK6lGxLjhdW8aObwZ5 tJ/GgXv9Yr+h2qmfYyjkvorYZgh3/0TFq4+q7aIEVjj00r5wNd/g71nQd2l6SbsxQKfP lLb9s9DJa6IvVkTgZqMI8qmA/oHNfPNZjsk9C6QU/hCm/nToseA9aSbyFD26xRWW0mPg RO8mtC2rzW37pMcnNlQoXFt5bHgkURRM6nRLsa6ZUVJJz+eO5C0L06Asa6y1/U4Loem6 12Vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700626084; x=1701230884; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7TpaziSqWi2SuqrjQaZvWNpsc9sL17Vv+BYjIKk7DKg=; b=A02YBcWntkIC/DXlRmRIdi5zMUf/di6hdpWV02V8wEZkaa/msMtYMfZWMGiqrKnUYq FfZkCrpG71fsU145CQp+LSNzbB7xMsv9kn7PTopzYpGzciwF5PGfasv2YrCRKw2p7shz Rhdm2tpOsNiwCv5zCdF3Wg7pnco4OsgAUUlDU+i1ssRgJAGqKb3m55iI5DBSWLe0YmdE Lo8NgW3x7i9jkaXfDFV7flnmnKcf/KoFAS3145cs661f5sTjaxHKP+Dyg2FUI+FoI+HN 32aYopmRAm91LamCfurxFYEM5dyjWe7F9QI25iiOhqBRxefMJJh1zjNack/IiqQQ0E8a 7lHw==
X-Gm-Message-State: AOJu0YxyyTMK0hD52HcM9sU32opwpULD/sftbC5ZICO8D6kpZbDolnuN 7yXANsgi7+elX4/gNZw3Z7HnUcx/eqDxnQ==
X-Google-Smtp-Source: AGHT+IGf21ylfEklOzep5bkKOteo8JUriaXyi30tYWsSjcX1zQ1BOmQMFGkGvVe2bl7oDdmDgXmERQ==
X-Received: by 2002:a05:6a00:8d97:b0:68f:bb02:fdf with SMTP id im23-20020a056a008d9700b0068fbb020fdfmr1411370pfb.27.1700626084132; Tue, 21 Nov 2023 20:08:04 -0800 (PST)
Received: from ?IPV6:2404:4400:541d:a600:44b7:2c2e:2bc6:8707? ([2404:4400:541d:a600:44b7:2c2e:2bc6:8707]) by smtp.gmail.com with ESMTPSA id t18-20020a056a0021d200b006cb997a3210sm4550325pfj.193.2023. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Nov 2023 20:08:03 -0800 (PST)
Message-ID: <00efd16d-8b15-e3f6-cf12-fb8c97eb1e99@gmail.com>
Date: Wed, 22 Nov 2023 17:07:58 +1300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Kyle Rose <krose@krose.org>, Ole Trøan <otroan@employees.org>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
References: <CAPt1N1mXJ6tdvEG9EsTDYxpPHTR3FH74Hp7nUnjQM8j2T3pPcg@mail.gmail.com> <36E7983C-B8C4-4945-BF70-73B196AF9841@employees.org> <CAJU8_nV2QoGjZoegcUSXELqgeqW6OheTt32qq6YQ5XV0g5MPQw@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <CAJU8_nV2QoGjZoegcUSXELqgeqW6OheTt32qq6YQ5XV0g5MPQw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jTC5wFf0hOSvR74V-OjP-L1AJiM>
Subject: [IPv6] Multi6 (no longer 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: Wed, 22 Nov 2023 04:08:07 -0000

On 22-Nov-23 06:31, Kyle Rose wrote:
> 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". 

That's why we did RFC 8028 "First-Hop Router Selection by Hosts in a Multi-Prefix Network", which requires rule 5.5 and only works with upstream SADR to find the correct exit.


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.)
> Kyle
> On Tue, Nov 21, 2023 at 12:06 PM Ole Trøan <otroan=40employees.org@dmarc.ietf.org <mailto:40employees.org@dmarc.ietf.org>> wrote:
>>     On 21 Nov 2023, at 17:19, Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> 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 <otroan@employees.org <mailto:otroan@employees.org>> 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
>     ipv6@ietf.org <mailto:ipv6@ietf.org>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <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
> --------------------------------------------------------------------