[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:11 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453B0C15C281 for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 20:11:42 -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, FREEMAIL_FROM=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=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfQd70vmbVlS for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 20:11:38 -0800 (PST)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 7CE1DC152574 for <ipv6@ietf.org>; Tue, 21 Nov 2023 20:11:38 -0800 (PST)
Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-1ccbb7f79cdso47173325ad.3 for <ipv6@ietf.org>; Tue, 21 Nov 2023 20:11:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700626298; x=1701231098; 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=DtW2JkrgShZBt7Fz2SCUIdsIJetyMf3aUgyi4CIeeGs=; b=hrj3piq/dZPB4Dxra7ZVJcR9JLC/B7T930Yp6Ca6WI85zvwU45RZ/c5F/zneFx0sM4 iJPPXNuuUBbxnM25tjRLBKODpjZk7yaflDmq1bS8Wf5n2zDB97BG5C0NsjYevFhoa+gq HbnGwRr0QU9659t0QAqi5iTGf5LG7IV6sQVnKvgWd7HP0Hrd+5IBOgwcwBgnGOKvxHcv scgqiUZ7CYXK1urHnyv2P72Getpq9h31FNH2n4GcRzuyoyTQ44uni+l4gf9bxzj4b0OD 7uEptbOb0tIjGYtW38gqOYFlVFQTrGr0MBzFj9BLzheTcZJ4t8otZm9OAwlNZmVfIN20 3Q4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700626298; x=1701231098; 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=DtW2JkrgShZBt7Fz2SCUIdsIJetyMf3aUgyi4CIeeGs=; b=w4T8lSq/SYIRoeAmeaHfThoVmtqeQo2/jV6uEda8ljK7MsJyVnYJz4TwLOcjDxYUzr TTvLZsKn/MzjhYd2antTNLFUF66f4kmeggGsRPhhuv/pcKO351rGX5WO04Fnp2b78f+t /kN4cdXWEhII2Sk6hTd5GWSpBq1xthBSROIp61KsZ6VAtU8Jwb3BzyUrtA76DH2D1YNv swJyLLZR3XzYhf1fThQxmY+8H6HBceE2LoEONOAkaeqzJtGr4FysPNqqmPryZYivHGj3 6tnumjGtvt8FoUwPR+qG7mESy3ClEBbUzA6TGkGHgNEnm7+N1RVUWWjnT455Gw1V06LF fXWg==
X-Gm-Message-State: AOJu0YxEUrVcCSQWR9kwLbGUfdETgoL+P83L/XNqufjm0e+3V6BFQsZi MjajgZ8VPBm8V3dS74DoML8=
X-Google-Smtp-Source: AGHT+IEOtSB8zvDriclEykageSUbKn1m9fHDaK8WX3KIl/70Jv9Zq28uGuWwZiEGiR2FFzbXC9MiuQ==
X-Received: by 2002:a17:903:22c1:b0:1cc:d510:85fb with SMTP id y1-20020a17090322c100b001ccd51085fbmr1279262plg.36.1700626297818; Tue, 21 Nov 2023 20:11:37 -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 iz9-20020a170902ef8900b001cf6aae59cbsm2722531plb.85.2023.11.21.20.11.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Nov 2023 20:11:37 -0800 (PST)
Message-ID: <6b2a9814-b692-30a7-eb7e-9578dc929529@gmail.com>
Date: Wed, 22 Nov 2023 17:11:32 +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: Ted Lemon <mellon@fugue.com>, Ole Trøan <otroan@employees.org>
Cc: 6man WG <ipv6@ietf.org>, Kyle Rose <krose@krose.org>, Michael Richardson <mcr+ietf@sandelman.ca>
References: <CAJU8_nV2QoGjZoegcUSXELqgeqW6OheTt32qq6YQ5XV0g5MPQw@mail.gmail.com> <10D22CA5-CD7A-471A-B4A9-21B77D16F5F7@employees.org> <CAPt1N1kYQZwUuFYzT9NSprB6L2G90XV1ROjmnjsftvbzOpHghQ@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <CAPt1N1kYQZwUuFYzT9NSprB6L2G90XV1ROjmnjsftvbzOpHghQ@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/NYZdjC4MnyCQLu6HgdoxKJ_Zxxc>
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:11:42 -0000

On 22-Nov-23 09:48, Ted Lemon wrote:
> Why would anyone use the bsd socket api for anything outbound at this late date?

Because of massive amounts of deployed code, not to mentioned deployed tutorials and programmers.

But I agree, it's time for a sea change, whether it's TAPS or something else.

     Brian

> 
> Op di 21 nov 2023 om 14:30 schreef Ole Trøan <otroan@employees.org <mailto:otroan@employees.org>>
> 
> 
> 
>>     On 21 Nov 2023, at 18:32, Kyle Rose <krose=40krose.org@dmarc.ietf.org <mailto: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 <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
> --------------------------------------------------------------------