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

Nick Buraglio <buraglio@forwardingplane.net> Tue, 21 November 2023 19:05 UTC

Return-Path: <buraglio@forwardingplane.net>
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 0C1DBC14CE4B for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 11:05:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forwardingplane.net
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 2CBkjgH44seW for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 11:05:22 -0800 (PST)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 DE7AEC15154A for <ipv6@ietf.org>; Tue, 21 Nov 2023 11:05:22 -0800 (PST)
Received: by mail-qt1-x836.google.com with SMTP id d75a77b69052e-41cc537ed54so35806531cf.2 for <ipv6@ietf.org>; Tue, 21 Nov 2023 11:05:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forwardingplane.net; s=google; t=1700593521; x=1701198321; 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=UHjMz9KClXgodiRKEu798a0ljV7gmGYPpEI/rw3Roag=; b=VqhX6UrL+fpWawlhDsULDRH9lPjzUD5mOHk7TxIkGtQB11JLkEfn+qzeO5GnRbjgTl cvFOPcSBP6kTS1x9j2EeQOFptFd2ih2yV7RG92ENLaEmbUBHVSkFQt6OGRMyctf1s3ih BxbEjEGQqPXvk2bWfcPNzLzMHHNwI7BuFPddw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700593521; x=1701198321; 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=UHjMz9KClXgodiRKEu798a0ljV7gmGYPpEI/rw3Roag=; b=u2eAfGwSL1qw4oAGY0yTDnQV6QVK1DZV1Hviq9DCebeafgxrzI4CkyQrz2nbS49KcM Z6r3Mvmeg0lMQQijLNY/w2wC/OcsC9f4H2uBPx4MlBlvBu3ZrrD90SaGihyjzzHGlPNt lu26yLc2IdeiUAnYvOJjmd742w0yGkzqnGiM7HLJPMBEN/Aov7EbRK4AMHgd9MaR+AaG 4Bft6TsehI4g8BS0boLv2SAxFcJFX8o/70LBxo18t8MSJP4DaiEj8hsOv4QNPKQ7j9df VYJUKG0P6+N8sCxk+1q9aG6PuhXu0/+EeWROi/5MF6jnHoT/DGWAEY3eOy5SzbsdVEgD pQ9g==
X-Gm-Message-State: AOJu0Yx2I4+SnS4FwmyA9N2Pc75hmanEY+BIRb0ISp5S3CkkXZXXu/YW qDpLXVqEest09E2e6gp6RLD/535OUeu97wMljuSNIg==
X-Google-Smtp-Source: AGHT+IF+ZxAa7CDZaorz0iidCVl/ESB1Ug9QWVPjA1I8qLJilAQ61g7Rji+SF+RdEMoVMcEYOifOH6A2N7E+vc6i6gE=
X-Received: by 2002:ac8:5802:0:b0:423:6f05:33da with SMTP id g2-20020ac85802000000b004236f0533damr109282qtg.18.1700593521467; Tue, 21 Nov 2023 11:05:21 -0800 (PST)
MIME-Version: 1.0
References: <CAPt1N1mXJ6tdvEG9EsTDYxpPHTR3FH74Hp7nUnjQM8j2T3pPcg@mail.gmail.com> <36E7983C-B8C4-4945-BF70-73B196AF9841@employees.org> <CAJU8_nV2QoGjZoegcUSXELqgeqW6OheTt32qq6YQ5XV0g5MPQw@mail.gmail.com>
In-Reply-To: <CAJU8_nV2QoGjZoegcUSXELqgeqW6OheTt32qq6YQ5XV0g5MPQw@mail.gmail.com>
From: Nick Buraglio <buraglio@forwardingplane.net>
Date: Tue, 21 Nov 2023 13:05:10 -0600
Message-ID: <CACMsEX9dMLiphu4qapz08vNpbQgcfX+EWtQUZkgb_wtBWvKGVQ@mail.gmail.com>
To: Kyle Rose <krose=40krose.org@dmarc.ietf.org>
Cc: Ole Trøan <otroan=40employees.org@dmarc.ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c13553060aae4873"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/IUaLQpU324m7TiO8X2Y4DwUTp2E>
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: Tue, 21 Nov 2023 19:05:27 -0000

On Tue, Nov 21, 2023 at 11:32 AM Kyle Rose <krose=40krose.org@dmarc.ietf.org>
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". 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.
>

Good news, then! I just posted a new version with some 5.5 requirement
verbiage that we worked out after 118.


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

As I thought about this all morning, it has occured to me that regardless
of what happens, any change is a long term endeavor - probably on the order
of 8-10 years.  I personally don't believe that "no action" is really an
option, because the symptoms that this update addresses have been noted
repeatedly over quite some time. Additionally in the context of running
without IPv4 of which is my charge to make happen, this aids in the
transition. I realize that is probably not what everyone wants or needs,
but it should be an eventual end-state we are looking for for the vast
majority.

I tend to look at the end states like most people, but real change happens
in small bits over time. If this gets us *incrementally* closer to a more
predictable routing stack while also providing some much needed tweaks to
make that transition more predictable (which is the real goal of this
particular endeavor), it is worth the effort.


> Kyle
>
>
> On Tue, Nov 21, 2023 at 12:06 PM Ole Trøan <otroan=
> 40employees.org@dmarc.ietf.org> wrote:
>
>>
>>
>> On 21 Nov 2023, at 17:19, Ted Lemon <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> 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
>> 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
> --------------------------------------------------------------------
>