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

Brian E Carpenter <> Sat, 25 November 2023 00:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB2E8C15198B for <>; Fri, 24 Nov 2023 16:49:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Status: No, score=-2.199 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_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] 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 o96NP_-fEE4Y for <>; Fri, 24 Nov 2023 16:49:39 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::336]) (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 7347BC151989 for <>; Fri, 24 Nov 2023 16:49:39 -0800 (PST)
Received: by with SMTP id 46e09a7af769-6d7fc4661faso1129539a34.3 for <>; Fri, 24 Nov 2023 16:49:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1700873378; x=1701478178;; 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=fn/SM5QkqVaoVdR49DqGt4qSstZ14oy/2cx3SmF0L9k=; b=neObro0DlI2UzZilTebIHSFa7ZQ/x2xYTcxEygLvTq/4gjbFyzLqnCRh8v2pX9sVHU /6e5YwD692P/43Gu42kPPeW2n+o+GgBS8zRkeJrQ8BEzbHTZROnpwdz100+TQ4cRWsKe eQZoLydl8JWC8BbozcwSAGlUdvFLrm9EFn1KrdECa9D8n4KoNTc8gwr6TP4Sk0zOY14g UYSIITTaXCPRSEp9/i8iKtheqbs5CWpansK8tGdP0ctu1KMqNTXplaXp3t9mpkg6jAkM PMtHlilSF6/atf2R/MiE2duG1j1RmGZ4YQlAAKCtpQ7aR+uJ3rbVTmh1pFi9fRfHojmP jeQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1700873378; x=1701478178; 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=fn/SM5QkqVaoVdR49DqGt4qSstZ14oy/2cx3SmF0L9k=; b=fuJp3GiPdaGq2Bo1vPCCV1vrRod7rbDWIAZmrvK2IH8OP+VVfLEFNcy4suikstWGIf zz5NlGZN9n5QZr4KKy9/90MNNTcxBr7el1sPxCc9EVJxllbU5B0kReOz9xkna17qABkj VvYlsFJaqEoWeh8jfmv7ib/c1DuNnhx9TKL5f79tH4/e15Z5kSVz0bZkOE84mCS0dCkg i3LAr8/2uhMMwzVZaRFzdklZu7L0CrMbaGstc/EgXQ7XkA7Jp5r/5ZKYaBh5de5HxxgF 1OwTRNK46W2GNI15F51vzZxgFVNrdjBfT6JSv3p4k9eaCAd3eSymW5ltYhQF4j+7xRt9 FOaQ==
X-Gm-Message-State: AOJu0YytWiFzC8uQ5jWioH1yBlpcvnFKeKvXEB6SnWNVIOoeBNX7bO0F gvJbhlqS7mN7NrP8qIB1nMUx2LqU3EPB8A==
X-Google-Smtp-Source: AGHT+IHn3ROz0VuT3OFX9o1n42ATmCBRe468LoZhEX3EMk2IvDAdVE2/T6ehtvyWkQysWgNlfqqazw==
X-Received: by 2002:a9d:6392:0:b0:6d5:4daf:9894 with SMTP id w18-20020a9d6392000000b006d54daf9894mr4420061otk.7.1700873378412; Fri, 24 Nov 2023 16:49:38 -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 a2-20020a63d402000000b005b96b42f7ccsm3493404pgh.82.2023. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Nov 2023 16:49:37 -0800 (PST)
Message-ID: <>
Date: Sat, 25 Nov 2023 13:49:32 +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: Kyle Rose <>
Cc: Ed Horley <>, 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 00:49:39 -0000

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.


> 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