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

Mark Smith <> Sat, 25 November 2023 01:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AECEAC15198D for <>; Fri, 24 Nov 2023 17:55:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.603
X-Spam-Status: No, score=-5.603 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, FREEMAIL_REPLY=1, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, 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_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 h2SKzVBQFr3p for <>; Fri, 24 Nov 2023 17:55:14 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::630]) (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 04D80C15154A for <>; Fri, 24 Nov 2023 17:55:13 -0800 (PST)
Received: by with SMTP id a640c23a62f3a-a08e4352992so169235166b.1 for <>; Fri, 24 Nov 2023 17:55:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1700877312; x=1701482112;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aqnav2SxHa2MiKY2BcnliPe+3xDzgGv3L39+mBo3g6Q=; b=nsPxVlLXTTeIQFk5w/UtcATOCCjvwl+PzwtvH8PkArdls7G4LJHek38i7+Ej/EYgpI VlMyCd5DQpnoGUJ+3zjzX2eOUjqvNFZUUowWxcIV8VKux0lxwdujeibL7Qvr2pTHdk8J JU2SBA1Azg2o1BdoJnCa4jVq6iaZasnyjTow6h80Ac72c1qnFYmcb24+L3b8u1+kshkj sUQ721CU1BorR09DA900aQ03/IlbR7clKeq9fa4Ddafzgqws17BwiqY281O1PKqKhZsU bUVItfTiu6u37Kp6T3zJxsahUkSzl4/fgD7tZFVADQWIlgc4S8VfIJbAP/fBaA9T8trX P9XQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1700877312; x=1701482112; 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=aqnav2SxHa2MiKY2BcnliPe+3xDzgGv3L39+mBo3g6Q=; b=O1QS5GmLh8jZfwx4Y4chkM/qizQOmyRbvl9Y5w6aC7r5q1g5MhgxMTG2IhU5zThoHK aJB3i4MmITUb8BD+ZaAMLh/T4aFfbT7WxQaqttqFa0/x+Xaecws1baeTsw9YfRGfpnQi Ey6pOC8BRt6GE6cnYfryT8MDY+gTLoqXKH4E6Olh8iaDVmMLwqsqhZMgb2nS+yGLZ31K vhz8DqIfBhg2FQOcRmz+MJ+8wIjKUm9P3Hv6OPYBU4Vy1ju6ERTE06X62K8Yyi0DtStO sPj3s8ITa8c4BV/j6SYc7LbZ5wtHI1fJup0f+gXfL+a/wluOxNgnUQRc3AAeP4yAJv2B lSrg==
X-Gm-Message-State: AOJu0Yw17KkoPZR4/hDOU9zK0fRX7AcNDADkbowujMKodzyDUnwzB35k 8cQ7D5HJbspAyGeepnPDPB+67CRcq5j1gojcjzv57GUl
X-Google-Smtp-Source: AGHT+IEus+3mhAA5DmZcyI7TG1qM3l4TlKPb3tAsaWwx7jLWC+0NEQE0uP7p85fXao5siCQ1aQ7+3EMk3DdwbB3quCo=
X-Received: by 2002:a17:907:1a42:b0:9be:77cd:4c2c with SMTP id mf2-20020a1709071a4200b009be77cd4c2cmr2807168ejc.28.1700877312228; Fri, 24 Nov 2023 17:55:12 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Sat, 25 Nov 2023 12:55:01 +1100
Message-ID: <>
To: Brian E Carpenter <>
Cc: Kyle Rose <>, 6man WG <>
Content-Type: multipart/alternative; boundary="00000000000000818b060af05cd9"
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 01:55:14 -0000

On Sat, 25 Nov 2023, 11:49 Brian E Carpenter, <>

> On 25-Nov-23 13:33, Kyle Rose wrote:
> > 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,
> Which is very rare, according to Dan Wing's monitoring, but indeed we
> would ideally want ULA->ULA matching at /48 (in most networks). But indeed
> we will always have some cases where failover is inevitable.

Apparently some people believe failover must never happen, meaning the
first DA returned by getaddrinfo() must always work.

I think this view is why ULAs were put below IPv4 in RFC 6724. The small
and unlikely possibility of a ULA in global DNS, and a host having to deal
with an unreachable DA meant that IPv4 was considered better than IPv6.

It's impossible for the first DA returned to always work in the presence of
multi-addressing, address spaces that have limited reachability such as
link-locals and ULAs, and networks that are dynamic where reachability can
be impacted by link and device failures or operator misconfiguration.


>     Brian
> > 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:
> --------------------------------------------------------------------