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

Lorenzo Colitti <lorenzo@google.com> Wed, 15 November 2023 23:55 UTC

Return-Path: <lorenzo@google.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 AC103C15109D for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2023 15:55:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.609
X-Spam-Level:
X-Spam-Status: No, score=-17.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 0TVxxpMdvtXm for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2023 15:55:46 -0800 (PST)
Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) (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 31BC5C151089 for <ipv6@ietf.org>; Wed, 15 Nov 2023 15:55:46 -0800 (PST)
Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-5a7c08b7744so2074347b3.3 for <ipv6@ietf.org>; Wed, 15 Nov 2023 15:55:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1700092545; x=1700697345; 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=Bkw4F3q4Vem8lM0YY7V5cMaFFY/DKy8pC/RhhXVg2Gc=; b=kIakhu8Arjvf5OcO5E9THqF6LcyPl0W6qxEWB+gbE5dAdbs3vZ+FdaWkt1NLY5CzzR CmNuge/g6HhINeu6EZkG/GMmW2YbVS454R8zuDZC4ObQv2ZA85yZsU/+FGp42I72oC+9 lYjqC8aghQ8dNvPY4jbvmS5MVSoJqO41PH3J9Ypr7VdUs/W2/ThxLA/BKxb1P4GNnYXy KuqJzyeGRgoBrlU9vLWUNjCtE4T7pz7sLvSxr5nQagFbcoHp7v47+JVxb6xkTZIWHfvi FLknHzqaMExzFopMc0JDPxJUmSyBUgVG0JIAo9srpzDNPDNSMDnqX0qhjEtk6kFIxVCV QsSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700092545; x=1700697345; 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=Bkw4F3q4Vem8lM0YY7V5cMaFFY/DKy8pC/RhhXVg2Gc=; b=a72k1sTaDEE8RIKsNVD7ARCQSjw5G1b6AP8/9MRpyQ+v4Xlg13objx6+Omhr1VYtK/ vP4gHvb4CCwZNmPpYBk5RGCpt3S03bVg4LFT+YP84VPmDIUuNMaxsbs1SS2zr24eoq8z q0ULnW5nDDvqjVwo/Xe0OVV1WzuhCqGH6y/4yV54QQFr9XQzU/BxSLLd8oQMCBxZa8SY DpM6jMCXrI69KoiezVhN35a+VCTzsJ7p3y2t7hk6jcYlEQYTCH7KubNlmdrBxAj4QKRP x4nrDcvZ7KkA7SiBuhNBdO6FxjwFs7CeaoI+YzQSLXqTo+eXdI6PukL2xvh1do4/DGQw pcvg==
X-Gm-Message-State: AOJu0Yxs4YoD+oYyiDGm0PXvgFd1p9HASzuVVEhFgtHqH93bpFLQy1Zu ToJ48pKpRqzVHy7woG6rdrUSppg0Zmr3J7iaDhF03uR4wJ1z6PR89oM=
X-Google-Smtp-Source: AGHT+IHaNMS/rY2m6bz9LHQWw4rHQwlXqD4V1RmGPlSgN7JYp6pdbCNDbuOWKC8Gg8gav2acVK8IMOx/G/NDo3F9vm4=
X-Received: by 2002:a81:6d0a:0:b0:5a7:be1a:6c32 with SMTP id i10-20020a816d0a000000b005a7be1a6c32mr15131433ywc.24.1700092544704; Wed, 15 Nov 2023 15:55:44 -0800 (PST)
MIME-Version: 1.0
References: <CAKD1Yr2uD+XE+HA6vs3BfEchpWr5H2NEeoXLrXm7-U9_ckw1sA@mail.gmail.com> <CAN-Dau2Nw21wUm-mjxq3bnYczPJbApVhcZZ6oie+HiB4yvr_PQ@mail.gmail.com> <CAKD1Yr1z2x8iKXYQtPVifj-XkP7MeRq=NWe0gdWBGC1aS_j0Mg@mail.gmail.com> <CACMsEX8f_qmpZ898vKLy_56Jy1WKEju94fYEz5fuV4Pc3iJ=tw@mail.gmail.com> <CAKD1Yr1tZa0W=617hQrgYYqmUbfgFp7EhmvgqKzaBvF=r=5FuA@mail.gmail.com> <CAJU8_nUOjrO5FPPXTCNeA-9YuSPT7SmGkiM82DGiMacyfntV6w@mail.gmail.com> <CAN-Dau0FP31h3s+Fzbam7GJg-rNGsX3m8Hx3k=+895NT0a4iqw@mail.gmail.com> <CACMsEX8J8nGJKX9nUvev_H_zsEmznwKUU-xZyJzubybbCeK-_Q@mail.gmail.com> <CAN-Dau2eeEd_jX6hmyUyG3Q23jrpmUboB_j-hKN20Qwe2nyNwg@mail.gmail.com>
In-Reply-To: <CAN-Dau2eeEd_jX6hmyUyG3Q23jrpmUboB_j-hKN20Qwe2nyNwg@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 16 Nov 2023 08:55:33 +0900
Message-ID: <CAKD1Yr236e37RCFngbbA=p94M_OSUGP_U9ZLWALqV=GsL1eKvg@mail.gmail.com>
To: David Farmer <farmer@umn.edu>
Cc: Nick Buraglio <buraglio@forwardingplane.net>, Kyle Rose <krose@krose.org>, IETF IPv6 Mailing List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000036b23e060a39a43a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hCGZWOp31AyA2C8lUVyhPH6_1rU>
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: Wed, 15 Nov 2023 23:55:46 -0000

I like this text and including something like it would make me much happier
about making this change.

On Tue, Nov 14, 2023 at 1:29 AM David Farmer <farmer@umn.edu> wrote:

> How about something like the following;
>
> Since ULAs are defined to have a /48 site prefix, an implementation SHOULD
> automatically add rows for all covering ULA site prefixes received in
> Router Advertisements (RAs) [RFC4861] within Prefix Information Options
> (PIOs) or Route Information Options (RIOs) [RFC4191]. These known-local ULA
> /48s SHOULD have a precedence of 45.
>
>
In general PIOs are going to be /64s. Are you suggesting that we add the
covering /48? I assume yes, and I think it makes sense to do so.


> All Nodes SHOULD provide a mechanism to configure the policy table. Any
> Node that does not provide a mechanism for policy table configuration MUST
> implement the automated increased precedence for known-local /48s of ULA.
>
> Nodes implementing the automated increased precedence for known-local /48s
> of ULA MAY set the default precedence for the ULA label (fc00::/7) to 10.
> Otherwise, the default precedence for the ULA label (fc00::/7) MUST be 30.
>
>
So you're saying that if the host implements the "SHOULD elevate local ULA
preference" bit above, then it will prefer local ULAs over IPv4, and IPv4
over non-local ULAs? That makes sense. That still leaves anything that
doesn't implement the SHOULD at risk of breakage though..


> All Nodes SHOULD implement HEv2 [RFC8305].
>
>
Note that even if the node implements HE, many apps ship their own
networking libraries that might not use it.