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

Ted Lemon <> Sat, 25 November 2023 01:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AA07C15198D for <>; Fri, 24 Nov 2023 17:36:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L0xUce1NjrBW for <>; Fri, 24 Nov 2023 17:36:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32e]) (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 E903BC151983 for <>; Fri, 24 Nov 2023 17:36:33 -0800 (PST)
Received: by with SMTP id 46e09a7af769-6d7e794f5d3so1574209a34.0 for <>; Fri, 24 Nov 2023 17:36:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1700876192; x=1701480992;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2C/awe9JG0Tkz75MIBeQx3XTbgiKbFZNCzs7MLbX2/I=; b=jAuGB9if1InwnaGTOCFF52DfBTW5XvEpJHKD/LoB679WTmz0+BrvbwFNnKKydCjP/p AaybJOFh/zC3tJWfbVaCCcHbkFfyFmOzet0vYkV99zg+hNS3I+MDzXp5RpKiYSAJ2WX/ vxySl286nzJIZED8sC4mEkbOS2bijrii5q1tW/8uh2nZeUboYGjtKy72utC27tx51UFx WVVY4z3xOJ8IyTE509MGDq+Qimr5XlTIOKsqu4iZ4e5qS08AnF/eQqwkBN1X6eAnXvYn cwcHUeDtitmpe2jXZvsvgm3SMSQwZ+6x5IwZEoFuQPM36lMAayRf+zSqjwR93y4levd0 ECAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1700876192; x=1701480992; 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=2C/awe9JG0Tkz75MIBeQx3XTbgiKbFZNCzs7MLbX2/I=; b=Fxvgwqq/K53/wvVAbCGTwR1oFaoY0W0rnsEIE+YCg4GOZY+GzDMxZl/I+RW37lC3RF 6ZbVHGlaW/QDO9fs9jtjNubIOsUZ/zHBONiOUYvFydMy/yJrPp/yi81BQkOPn0QZ6Tvk ql4gkAUWwmkfggg6jfxiySy3uazUZB0exYLXBxATbHFDRGaEFNlS/GThy4g5AY5gbWH2 1Kcycj7Ff6I3s8AwAjGq9QugGDjYIq064PcFJnbCZq3JvgzH7crbB6B224/vUZO2czaP O9G+1krchUwxFwOkLAqnGf2rNWttr5h5vbpqNLv6DxoBGryDSh5UwsNn4Rhp+dTBws+g ro1g==
X-Gm-Message-State: AOJu0Yw0T20OXPFHbmKuajigcJKTwfHVbtPxt1sQCNsaCrgBxTitKaLt Lu20dCrY80HET61t8cjAvVk3FYf9nSg4XI6+MOzj+A==
X-Google-Smtp-Source: AGHT+IEDNCPxSaeX2vHekno+flrwJqePZgpvPwQQbtmxiP3KpdNK6FvWaqep48jAQNJaKpqt/vKnS/PVRdGi4139m+Y=
X-Received: by 2002:a05:6830:213:b0:6d6:5577:4922 with SMTP id em19-20020a056830021300b006d655774922mr4587643otb.35.1700876192705; Fri, 24 Nov 2023 17:36:32 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ted Lemon <>
Date: Fri, 24 Nov 2023 20:36:21 -0500
Message-ID: <>
To: Kyle Rose <>
Cc: 6man WG <>, Brian E Carpenter <>
Content-Type: multipart/alternative; boundary="00000000000046080e060af019b0"
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:36:36 -0000

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 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.

Op vr 24 nov 2023 om 19:34 schreef Kyle Rose <krose=>

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