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

Kyle Rose <> Sun, 26 November 2023 20:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18449C15107F for <>; Sun, 26 Nov 2023 12:04:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
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, 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_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 ol7yKGAiOo1f for <>; Sun, 26 Nov 2023 12:04:19 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62a]) (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 F395EC14CF1E for <>; Sun, 26 Nov 2023 12:04:18 -0800 (PST)
Received: by with SMTP id a640c23a62f3a-a00cbb83c82so506757466b.2 for <>; Sun, 26 Nov 2023 12:04:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1701029057; x=1701633857;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mUvqg99vDhIyej9mhwYg041L5RwJ9daiVdoEzKXQ/qA=; b=nPYLLVEP/9F6/6w0IB57UrcjZfP2CMPU8Hu+u8a8cVj30ibr4t6HxRKonamHoK56aS 5jYuYC0E6Pg+917CXNwvkmNmqIhvmyDTg2h2XvoWdC68bEiLGmxt9sxd5+T3Y498Bnnh OJQrlH44Ccyh633zD/3SbRwfA1NetpiAAvawo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701029057; x=1701633857; 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=mUvqg99vDhIyej9mhwYg041L5RwJ9daiVdoEzKXQ/qA=; b=u5CavzlPz4LJhuzvyH+W7UKsjzHAlAQMqz7ehPYf9SDqrKb7vXGtiN3lgTCSoCzW6A Sd/hY01BwO3fqEXGJAHNGpYwnUeiC7pBtyCkm05T/Ees2X1MC4A47HjVaquMPGBqvZEI 8RQt1dDXkCh30cj95xfhHXuhF4KKhdcOlNdqXRHEwldopzcs5hZ6Y6uQ0rehZtukA9kt wQnqE1x9e5qfFQmfv8iCbh61L5VAzKsEmEwsFUQOeN/3SkKA1wzoLS4OMEifikvVyzc8 ULXlhuagKjJoQirGTVlOml5h4Q99wd8yisXaTjWnnr5KnRdhVwWIbOt3s8PVjZIn8Rlu MIMA==
X-Gm-Message-State: AOJu0YxpPxWM/czferEN/3Cb2Hly90MZdsDO3Xfq6/T5wNjYzfGetPfV 922u8YA05qtMWxLKYM4JN9q2YyKjoVbmo+EJ3T6O3g==
X-Google-Smtp-Source: AGHT+IEkL0iaRB4ebsA5uWWi97RqqgXYSll/eb9kRjVanPnPEiyb/RV2bdMFFOMWZheaQA0P19s1ZtCBNOgxcF7Umok=
X-Received: by 2002:a17:906:160b:b0:9fc:346c:a5fa with SMTP id m11-20020a170906160b00b009fc346ca5famr5888785ejd.46.1701029057201; Sun, 26 Nov 2023 12:04:17 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <458732.1701012011@dyas> <> <>
In-Reply-To: <>
From: Kyle Rose <>
Date: Sun, 26 Nov 2023 15:04:05 -0500
Message-ID: <>
To: Brian E Carpenter <>
Cc: Michael Richardson <>, 6man WG <>
Content-Type: multipart/alternative; boundary="000000000000b51b1b060b13b0e4"
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: Sun, 26 Nov 2023 20:04:23 -0000

On Sun, Nov 26, 2023 at 2:39 PM Brian E Carpenter <> wrote:

> > I am not referring to leaking routes, but to leaking rendezvous
> information, i.e., DNS. In a world in which operators run recursive
> resolvers that clients can be assumed to use when on your network, you
> maybe can configure yours to drop all external address records referring to
> ULA or 1918 space, but we're now in a world in which privacy (via DoH/DoQ)
> and end-to-end integrity (via DNSSEC) have been prioritized over
> operability, so you have to assume you won't have full control over what
> DNS entries a client sees.
> All the more reason for doing everything we can to avoid trying a ULA
> destination address that is definitely unreachable. That at least is
> theoretically possible by requiring a /48 match with a locally used ULA
> prefix. But I think that is logically disjoint from RFC6724.

It would be a good optimization for operators that have the ability to push
an updated policy to at least some clients that can accept whatever the new
signaling is. Everyone will need a reasonable default, at the very least
for clients that won't or can't take updates to enable such signaling.

That means we need to choose which set of trade-offs to accept: those that
come with preferring ULA->ULA over GUA->GUA, or those that come with the
opposite preference. I don't have a strong position on which should go into
this draft, partly because I don't use both address types in responses for
a single name, and partly because leaking unreachable ULA is a
configuration error and I'm generally okay with breaking functionality over
easily-fixed errors. Either precedence ordering will work fine with my
sites' addressing across all relevant address types (v4, ULA, GUA).

> > This has implications for the set of trade-offs involved in
> misconfigurations, especially when the naive user blames you for something
> not working even when it's mostly not under your control. With border
> routers sending ICMP unreachable rejections, working Happy Eyeballs would
> hopefully make failover transparent, but "hopefully" is doing a lot of
> heavy lifting in that expectation.
> Yes. But our chances are no worse with ULAs in DNS than with RFC1918 in
> DNS, and that's a thing too.

Agreed, as I noted weeks ago (and as I'm sure many have noted over the
years). Sometimes these errors go unnoticed for years, I suspect mostly
because the application layer papers over it. I recall in an http WG
session a few years ago a participant noting that the Web basically doesn't
work without retries, and that if you knew how often browsers have to
replay requests you'd start wondering how any of this works at all.