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

Brian E Carpenter <> Sun, 26 November 2023 19:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 050F2C14CF1E for <>; Sun, 26 Nov 2023 11:39:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Status: No, score=-2.196 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_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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kLgboSd-mZEX for <>; Sun, 26 Nov 2023 11:39:29 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::62c]) (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 77BE4C14CEE3 for <>; Sun, 26 Nov 2023 11:39:29 -0800 (PST)
Received: by with SMTP id d9443c01a7336-1cc9b626a96so24135155ad.2 for <>; Sun, 26 Nov 2023 11:39:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701027568; x=1701632368;; 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=yMNJGCTFna8XCJCWZYxrib2O4mWbagYjRfH88BqQ6Fk=; b=KQL0YuW8RPQ1wirf+pI1i/HMHgHLTirn7KFEZCaMIz5GYjUCtNAPGXm9gI7y4RT1Vn pWZUf7pk56IN8TtBAFHq7Q1dYm+alnLDvCnXbh5vQCO4K9Bc/rx9eePlNz3kDxs80q+B X5ftAydZgVpIMf8SW2V2888LhSa7j0R0Y6gKSPC223yJFp+a8159uRoAYtM0w5h5kE4K ZbgpSLIhAbdokzjdHJ+i5da6gJOznkuzcDMeifMBVCg+swxrdP6yGo0jUfCa4i/BKoDK episTUOFAJhdzaW0R6pcX4Jju9Dav+ROqwidQ4GNLxcIveatMxezTh2D+ogqrYaSfUzu dHPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701027568; x=1701632368; 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=yMNJGCTFna8XCJCWZYxrib2O4mWbagYjRfH88BqQ6Fk=; b=K6xpsEFQECzxAM5R19NjRKluYp1EOsK4tYBIfsY9rLAUdafY+BBZGvYxqKB4RYrHpe ZsmwiIK/xwuJomHONjqPDjO9pPPjuFipyqeOl1n67JXUbMKad/OSQcQWsViBqW8YWOKA H71wKWCKw/CLOl8Yftq2tHlbvs6fwG2NAPJb93tArAkupJQQK6I3nTmmUeEy34wxEs+q n6qVQ+H5v50kvJb8006FFzgn6aCS3okV4nRcLzkK5kb+0o+jtbV3wDlDeXtmT7omA6No waSsePQ5vbk70bmwEDji3zWUvTYZH/fQYFhhSArmAz7Q5RuMzKrpeAkridCnFno6F0WL fDTA==
X-Gm-Message-State: AOJu0YzfN+SQ7L2l7QgUgknK+DNedAjJG5Ei1DO3a+H4gph55hGz+BDq EnjucfdVBGKN2Pf2PcpsmPTnKwR8fEDTFQ==
X-Google-Smtp-Source: AGHT+IEOZzeupH1fZE2wrdxyAPclyLLYFQ85XsuV/acJ/MSPYLx2ryvwh3zTcB31G/3a+O3VxWaoTg==
X-Received: by 2002:a17:903:4282:b0:1c5:befa:d81d with SMTP id ju2-20020a170903428200b001c5befad81dmr7678311plb.10.1701027568389; Sun, 26 Nov 2023 11:39:28 -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 t10-20020a170902e84a00b001cfcf33a880sm297190plg.281.2023. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Nov 2023 11:39:28 -0800 (PST)
Message-ID: <>
Date: Mon, 27 Nov 2023 08:39:25 +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 <>, Michael Richardson <>
Cc: 6man WG <>
References: <> <> <> <> <> <> <> <> <> <> <> <458732.1701012011@dyas> <>
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: Sun, 26 Nov 2023 19:39:34 -0000

On 27-Nov-23 04:59, Kyle Rose wrote:
> On Sun, Nov 26, 2023 at 10:20 AM Michael Richardson < <>> wrote:
>     But, you as an operator, would be deleting those announcements based upon
>     your well configured BCP38.  So, it's really is entirely under your control,
>     which I agree with you: is a better.
> 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.

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

Non-authoritative answer:
Addresses:  fde1:53ba:e9a0:de11:cd63:b055:9846:cb20


> Anyway, I consider this an acceptable set of trade-offs, but there is a discussion to be had about the implications that would benefit from the experience of big-time operators who have run into a much broader set of issues than I have.
> Kyle
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------