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

Kyle Rose <> Sun, 26 November 2023 15:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDFD5C14CEE3 for <>; Sun, 26 Nov 2023 07:59:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Status: No, score=-7.106 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_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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wuyx49nvyF1p for <>; Sun, 26 Nov 2023 07:59:27 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::629]) (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 C6ADEC14F73E for <>; Sun, 26 Nov 2023 07:59:27 -0800 (PST)
Received: by with SMTP id a640c23a62f3a-9ffef4b2741so448945866b.3 for <>; Sun, 26 Nov 2023 07:59:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1701014366; x=1701619166;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5YOyVYPi4uX9ynC17KuDm+iyWaeEvp+GKgjldhJlv00=; b=YwD5J0HWNoloJEpxN2RkPP2+dhK5PA6y/ubdr2bN2EnzcPa/ZqWeSPRn13OhnhzU0F h/r7QG95J1BNwGwbUZlsucw5ewpn8mKkojAZaWk1MCkUd3QpQ7O9+YsViDU9UfirrZQZ V2u0f5t2NkrQkKfe2jtmHdbd5j3ZiM3K11Bms=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701014366; x=1701619166; 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=5YOyVYPi4uX9ynC17KuDm+iyWaeEvp+GKgjldhJlv00=; b=rajvr1XWMO7xxEwD0nY/xEXjSKq2Zg5Z4wz/zfvlJtNCwZ3+lp/kl5+UaEOBJY8Pu/ TZkPi6PitE9RNYlyG4CkVzUNYnbQ4nFIPRPoys5CmQ/YMjDOnwO6ukgmHcCgA2LKSzIb adEXRjG0LQsfONPXKiEdwRpQJjEWxv124/jFLnmaQGd8fYfch71dog81R5yUjHllZLP1 vmbN18m2ME67NIAAKpCwcJzrhq872/LZ0Tbuj0I8oIjALcwafuA4WJq5YCeR0mfwsQVS YwkzWbtxHYJAkpuja4GTfm8jqwpMtaccy9z1lec1YWyPz7i91Ifvisj8C2EgPbjoYgxf 5azA==
X-Gm-Message-State: AOJu0Yx1Ub0i37uQbAG5FDRs93Xhd3JzJyulD71u2SxIaaDNJkwVz4xK IVD7omUt33MmqhqCZRKVhVaVl/2wKD8BM1s7yOXq7c0C/2FXzNWw
X-Google-Smtp-Source: AGHT+IH7sEktVFdOmWJxUFoVp1a7s7rPfPdTBHrTgOpIG8uJSQYqbrhD0aBEe+OnUZRuH+eIdFpv3MxclqEqHou8Qss=
X-Received: by 2002:a17:906:c285:b0:9be:d55a:81c5 with SMTP id r5-20020a170906c28500b009bed55a81c5mr6897909ejz.60.1701014365731; Sun, 26 Nov 2023 07:59:25 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <458732.1701012011@dyas>
In-Reply-To: <458732.1701012011@dyas>
From: Kyle Rose <>
Date: Sun, 26 Nov 2023 10:59:14 -0500
Message-ID: <>
To: Michael Richardson <>
Cc: 6man WG <>
Content-Type: multipart/alternative; boundary="000000000000070eb2060b1045c5"
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 15:59:32 -0000

On Sun, Nov 26, 2023 at 10:20 AM Michael Richardson <>

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

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.