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

Ted Lemon <mellon@fugue.com> Tue, 21 November 2023 20:49 UTC

Return-Path: <mellon@fugue.com>
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 84C9BC151995 for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 12:49:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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_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=fugue-com.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 V7GD_NuAYEAg for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 12:49:03 -0800 (PST)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 96900C14CE55 for <ipv6@ietf.org>; Tue, 21 Nov 2023 12:49:03 -0800 (PST)
Received: by mail-yb1-xb2c.google.com with SMTP id 3f1490d57ef6-db3fd3e971cso86985276.3 for <ipv6@ietf.org>; Tue, 21 Nov 2023 12:49:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1700599742; x=1701204542; 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=zTIu1fhDZXEvLsW7Q6Ey2ri7mPxK6zBH5qGOMN1g6ys=; b=D9BtsOBB6Nbl0SoPbj7qe0cH7twnwwG5cNtaROUXbx+zLlUFshuQcAfWIbBVWOqRzD j2QL4aFc0+DyzQrqWZlOWoBetP+j4uwKFmf5IYLhyQcSIRIv/sqtMhdrkU64rs1KmWBU SehtYXkgFhyVmpKSakrEZr+M7ltaBZbN8IJwe5H4jo56nujfSRgo6TVxxJk/8hcjwT3/ i6JQcUeQmTF9iqTFZgW+ZyBpHlnz2TG6Y9fpFLfMCJIxxG/fMtnCHcjjkb6DV18J2snL VE7XnWOBNPGI1sRgkjKbt1ToDYvxU0y7a45z592fw76uOwoiUpGPLDQ4BiqrGC/WQMLi KIOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700599742; x=1701204542; 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=zTIu1fhDZXEvLsW7Q6Ey2ri7mPxK6zBH5qGOMN1g6ys=; b=VPniEZZ82VIsuiwgvMfj3/fGVg5YhRXvHReI+GnWiObw96/zWhob7SvPhVI3WaMIeM /CpYHI6uWQ0LDD9b7vcfbzMwNk849sokgcmLJC67nz9V+KgsVP1uyx6q8OuQvTuLZFEE /izV8w/d5HtncIlmBzsQo9gSzL1VIT9jB0S29Ft7PGAI17kHmUjk0L2+cQ05mU0h/A/N K2LWYaJ3D/Nqdw8I4sdEF8Y4VOBOJ8yCjN4qlV0IyOFaleos7GGIn8cb3+KKb3t5bQJa 1Jz0Y6DAOE+iki9BzfwJjatgnRHsPdgskWOyWG1utgHxPd5s4hkB/91y9KSHb+z9++u9 FxkA==
X-Gm-Message-State: AOJu0Yw5Hle+SV8BhkbAh7zxbwR4HF55OmVXw2ogEfU99b+HlPApri1B xEvX5joetMXjRLLVNrLr3ioBiN66pcmjgc0+X/5zn+JCSkJscRvVajg=
X-Google-Smtp-Source: AGHT+IEiwsJgrpOi5igSR/F2mHs3N1MfsdU7GedUrb/p7hhlw4y0EPhQAIi+XiyhuEwgooS7iKEiT+1E4eNJJ0bm+w0=
X-Received: by 2002:a25:820d:0:b0:d9a:e815:38f6 with SMTP id q13-20020a25820d000000b00d9ae81538f6mr115924ybk.15.1700599742434; Tue, 21 Nov 2023 12:49:02 -0800 (PST)
MIME-Version: 1.0
References: <CAJU8_nV2QoGjZoegcUSXELqgeqW6OheTt32qq6YQ5XV0g5MPQw@mail.gmail.com> <10D22CA5-CD7A-471A-B4A9-21B77D16F5F7@employees.org>
In-Reply-To: <10D22CA5-CD7A-471A-B4A9-21B77D16F5F7@employees.org>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 21 Nov 2023 15:48:50 -0500
Message-ID: <CAPt1N1kYQZwUuFYzT9NSprB6L2G90XV1ROjmnjsftvbzOpHghQ@mail.gmail.com>
To: Ole Trøan <otroan@employees.org>
Cc: 6man WG <ipv6@ietf.org>, Kyle Rose <krose=40krose.org@dmarc.ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary="0000000000008da403060aafbba9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Xhxf_J34QlbpEwTEz1HMm_EonGg>
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 20:49:04 -0000

Why would anyone use the bsd socket api for anything outbound at this late
date?

Op di 21 nov 2023 om 14:30 schreef Ole Trøan <otroan@employees.org>

>
>
> On 21 Nov 2023, at 18:32, 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. 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.)
>
>
> Rule 5.5 is useful regardless. See f.ex Jen’s proposal to use it to handle
> flash renumbering.
>
> It needs to be combined with HE. 5.5 and lifetimes doesn’t translate well
> to a routed topology. First-hop router doesn’t have to detect failure.
>
> Covered most of this in 7157. Including signaling policy to hosts.
>
> 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.  :-)
>
> Cheers
> Ole
>
>
> 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
>> --------------------------------------------------------------------
>>
>