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

Kyle Rose <> Sat, 25 November 2023 00:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94147C15154A for <>; Fri, 24 Nov 2023 16:33:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, 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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qm-6eunHA7lt for <>; Fri, 24 Nov 2023 16:33:44 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12f]) (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 7F120C151984 for <>; Fri, 24 Nov 2023 16:33:44 -0800 (PST)
Received: by with SMTP id 2adb3069b0e04-5098e423ba2so3425691e87.2 for <>; Fri, 24 Nov 2023 16:33:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1700872422; x=1701477222;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=983au4BN3Zy1pG8JqT2uYItvGTJremYFw42jB8L02Nc=; b=VfQ3jbpBjJ3XyTChoN0SaIS4nWwJSmfPpLq2p0Ycs+cf1K7JrWRYI1vrGOcplrbo40 g4jgDDanLSqTMv9JeFnGwtq2xHsyt138MfBNv0xn1RMb0yawoHqo9k2hkRPt86SQAiTQ WLJQoDIeCz2sxPjDeFDR2IQe8RIXiJUc1jtdI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1700872422; x=1701477222; 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=983au4BN3Zy1pG8JqT2uYItvGTJremYFw42jB8L02Nc=; b=mwN51tt6BnHvc6t+SvnQowznyktyb9RaOnIbHihofk15IKOf2IaLCV4s9tJELf4mFP vmHZBfTSyf7xESumvSq7PXIm1NZBY9Ok7fWYIh0ilC/wBmvc3LjbY4LbJhq7x26rVBSi EE+zGeGDFCs71vW912oxQV9/g+Y+ncPKaM+MAKSzaLchCyTEN0gVfpnD8eXX3zOAavQu L9pffeZhwbZ0QzqMTRbC2y0SILCrhmBDib4tGjmYjXV7zJoelYIx2xnyEkhO3aEZKUIf 5SNSz1RclbK1SAzUHRB8SK+fjOh9UapRPA27tnoLyOw3Xa/H1dPSfSoLYq/hJ8GX351t zxwg==
X-Gm-Message-State: AOJu0YyzDKMXkrrvbBkV0bbX+UKgUTJv400fKa04qOaj/FseJYGhtXsj ld9fxSVTxVX/VhLZq0LZ4Nr145AQI1p2kBGIOoc+MA==
X-Google-Smtp-Source: AGHT+IEQ8aHqSDN4gXfI9Ux1fDtTafAK+1AT63pU3zFm1Jbf8shi5M068uH0Ns1IZ1hqL6dStDUcnQxBbzd3hh69Pps=
X-Received: by 2002:a19:911a:0:b0:508:26c0:92d0 with SMTP id t26-20020a19911a000000b0050826c092d0mr2858541lfd.62.1700872422406; Fri, 24 Nov 2023 16:33:42 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Kyle Rose <>
Date: Fri, 24 Nov 2023 19:33:31 -0500
Message-ID: <>
To: Brian E Carpenter <>
Cc: Ed Horley <>, 6man WG <>
Content-Type: multipart/alternative; boundary="0000000000008bd47c060aef3892"
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 00:33:48 -0000

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.