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

Brian E Carpenter <> Sat, 25 November 2023 02:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C4A9C15108B for <>; Fri, 24 Nov 2023 18:43:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Status: No, score=-2.196 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, NICE_REPLY_A=-0.091, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uo2ONXck3W2I for <>; Fri, 24 Nov 2023 18:43:56 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32b]) (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 (Postfix) with ESMTPS id E1B09C14CE52 for <>; Fri, 24 Nov 2023 18:43:56 -0800 (PST)
Received: by with SMTP id 46e09a7af769-6d7eca548ccso1425847a34.3 for <>; Fri, 24 Nov 2023 18:43:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1700880236; x=1701485036;; 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=SEm0gagcjyfHEkS+pWo9y7GL4ioT+a2OaStx8nE/5MY=; b=FU+WCHVj9cFN0QgB+BfASdmk6UlCq4VOMH43O5LGU88S8cvQORsDxm6RW5qglJtqRe bvWVqBI2dzm16OKu9vtgVkYTrpl8yOhEJWg6K1yB/QM3ygHmVYAr5GJ1EhKlSfUYuOMh Duau7vGMfJ4EJuzLqsukLd2iZsIrtOyLYLS21AWvuSoivVHHs9HvXb5hDPNSKTTKixAc DcS1DN6zMRhJZ2kKQhC7VuCfX0RdiMzd7psUMTwhzq+AI1FqypHGqdLBpkp3R1v/UrhN bT1i+31NmZ/k7kYmU7SfH/B7GDR3Dkw1yJWxz69dE+NvZAzFtN4ffu9aZ9w2QS+J6rvq dPsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1700880236; x=1701485036; 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=SEm0gagcjyfHEkS+pWo9y7GL4ioT+a2OaStx8nE/5MY=; b=F0peX5PMP3D/UD5mcTQUIzNLdKwv5sBf0vrjkRgS120qouDCv0pXS8OKTjaVt+ic2P 7kQaZJNki0zZekoe3Izl2vzE5+sR1deSlztnN+urOZOiwFf5nBFBF/yxXkFsdQXmfLaZ NL29S3vY9HXr0xKMbjJieqOPSUYcw+uiHipcmnceYdPYg5hNU/YJlG4u8QqklOCMeTup WUcs79N4S44f5J6EIBHwCtRZWpzDW0x9LNuaQsSYI90oUSQT69pbq8TYgQHwK+V6l6ot Pi05O6tBEE4OQUFVDu6R7CdzHCYqtZKBx7I7/VrpSuiWTALkpQfnoREXc9OMVxiTywTY TMHg==
X-Gm-Message-State: AOJu0YySFm71u4VBEUJeOm14CMtD0mNFgVHYpXVL46TUy4Nxf7w7KkrL f97BXQU23VA4L8MBhiPl5lsIulvMJu3RHw==
X-Google-Smtp-Source: AGHT+IGArcVx93sM8rh10UZkmYKEvviiqO089rCMTceuzHWQ8MH5LfYB0BHQ7eGbnHbW1zCeieroAg==
X-Received: by 2002:a05:6830:4d7:b0:6c6:4843:2ac5 with SMTP id s23-20020a05683004d700b006c648432ac5mr5803364otd.21.1700880236020; Fri, 24 Nov 2023 18:43:56 -0800 (PST)
Received: from ?IPV6:2404:4400:541d:a600:44b7:2c2e:2bc6:8707? ([2404:4400:541d:a600:44b7:2c2e:2bc6:8707]) by with ESMTPSA id 22-20020a630216000000b005b458aa0541sm3661304pgc.15.2023. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Nov 2023 18:43:55 -0800 (PST)
Message-ID: <>
Date: Sat, 25 Nov 2023 15:43:50 +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 <>, Kyle Rose <>
Cc: 6man WG <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <>
Subject: Re: [IPv6] RFC 6724 shouldn't prefer partial reachability over reachability
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 25 Nov 2023 02:43:58 -0000

On 25-Nov-23 14:36, Ted Lemon wrote:
> I thought we’d decided that this was a misconfiguration and hence not a problem we need to solve.
> Regarding ULA->GUA I think we need to be careful to say that this is less preferable than GUA->GUA or 1918->GUAv4, not that it is always wrong or requires NPT. What is the case where, when ULA->GUA is the only option, we are better off not trying it?

I guess, it's just a bit odd for a site to have ULAs on some hosts but not others, which is the implication of ULA->GUA without NPT. But in a default table, we can't satisfy all non-default scenarios, can we?
> I know we’ve been around before on the second point and I thought what I just said was what we intended, but I keep seeing “only with NPT” repeated and I would really appreciate it if we could get on the same page.

Fair enough.


> Op vr 24 nov 2023 om 19:34 schreef Kyle Rose < <>>
>     On Fri, Nov 24, 2023 at 7:22 PM Brian E Carpenter < <>> wrote:
>          > ULA and GUA must be treated differently for purposes of address selection: what remains in dispute is exactly *how* that treatment should differ, not *whether* it should.
>         Yes. What we want, I think, is ULA->ULA to win over GUA->GUA and that means picking source and destination simultaneously. And we want ULA->GUA to never be tried unless the stack knows that NPTv6 is in place. And we can't do any of that correctly based on getaddrinfo() alone. So the draft is the best compromise given that we currently live with getaddrinfo().
>     I think it's still an open question (to Mark's email from Wednesday night ET) whether we want to prefer GUA->GUA over ULA->ULA or vice versa. As a small-time operator I don't have a preference since I do not use the same names for both ULA and GUA AAAA records, but preferring ULA->ULA does introduce one failure mode not under control of the local operator, which is *another operator* leaking ULA addresses for public services, in so doing causing connection timeouts or failovers to Happy Eyeballs. I don't have an informed opinion about the relative impact of that kind of configuration error versus whatever the costs are for using GUAs internally to a network when ULAs would work.
>     Kyle
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
> <>
>     Administrative Requests: <>
>     --------------------------------------------------------------------