Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-04.txt

Kyle Rose <> Tue, 28 November 2023 19:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 44245C1516E0 for <>; Tue, 28 Nov 2023 11:17:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Status: No, score=-2.105 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_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, 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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c1KP1JdisWjs for <>; Tue, 28 Nov 2023 11:17:16 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::529]) (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 28187C1519B6 for <>; Tue, 28 Nov 2023 11:17:11 -0800 (PST)
Received: by with SMTP id 4fb4d7f45d1cf-5488bf9e193so8059167a12.2 for <>; Tue, 28 Nov 2023 11:17:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1701199030; x=1701803830;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BqUu6MU8KwpaYCBXgX02fdrk0C4zLvc7yGYx0cxFz34=; b=Vb4QZKdTNf6FSC2r7xa5p7ycreX4bGSKRu0UwvHzbVfs65OneAZICl/+qE8crn0GTW OJZUOs8tkoLIJDpCQ5XPxJjoYh5ykAPBbGMuce0auKROTUiwU7v8ThgGyuGR9SeX7APO ejeZ4gfy/BumWPcoZSltR9E9VvUchlXjzuThY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701199030; x=1701803830; 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=BqUu6MU8KwpaYCBXgX02fdrk0C4zLvc7yGYx0cxFz34=; b=C+COAPNAlpjTVZLflRrEbTuip/6QQP4qICuBtudESxy+1jD+afv/PHn0Wt/gs/vCMt vsU9T0nuCeWy3Ucw4zCiOc3QeTr+CDG345pGy89840Hi407lF0RdrAR38yt/59Jv0MHa aYLQRabTVKy5CJ9H0ZXJ2FeEnOKeasuX9c6On6hU2q8gDinuth/VSrO/NS3S6NyWnO+n ZmwhqX0g0y1zSM1DSjwPDe9TEn++SK1TRe+4srYEhcn6dhb36Qx1Eqkb8hvyh+i37t3C rE9l48xjCI23mLZ8VCFkcyulpr+ilxMlBp65uTViGX6NGx9io1hfgknKdGBVzuE9Xpa7 gz4g==
X-Gm-Message-State: AOJu0YyPxXv4Kt6ms0R89g1nvpqjKUx8AapjcQQlp7oePfYuIP6cBVzc LZowc0ipCthOvLTKZwbEPVyE7+VaqS7DMtQ/KkCjHwLxjEABZ2B3
X-Google-Smtp-Source: AGHT+IGDDYpweI5RD2vMmDTcJJ3o7cDa0LF7QMhn+kW0Dme3dew4nuq8aI3IC5D3yAwW/mDt5xZDDevD25xcAvprLns=
X-Received: by 2002:a17:907:1c99:b0:a01:977a:ed73 with SMTP id nb25-20020a1709071c9900b00a01977aed73mr13479758ejc.8.1701199030177; Tue, 28 Nov 2023 11:17:10 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Kyle Rose <>
Date: Tue, 28 Nov 2023 14:16:58 -0500
Message-ID: <>
To: Erik Auerswald <>
Cc: 6man WG <>
Content-Type: multipart/alternative; boundary="000000000000e2e227060b3b4311"
Archived-At: <>
Subject: Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-04.txt
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: Tue, 28 Nov 2023 19:17:20 -0000

On Tue, Nov 28, 2023 at 1:40 PM Erik Auerswald <>

> I think your remark concerning "gai.conf" on Debian refers to the fact
> that it describes a default policy table different from both the RFC
> 3484 and RFC 6764 policy tables.
> While a GNU/Linux distribution could choose to use a different policy
> table than that provided by upstream (the GNU C Library (glibc)),
> the gai.conf in Debian is identical to the upstream version in glibc,
> available at
> <;a=blob;f=posix/gai.conf>.

Yes. Good to know. I did not attempt to ascertain the provenance of
Debian's gai.conf; it's just the only OS I use that leverages libc's
implementation of getaddrinfo.

> > [...]
> > The only sympathy I have is for operators who are increasingly powerless
> > to fix problems unilaterally because they can't always filter such
> > bogus addresses out of DNS, and who will get complaints from users
> > that they can't directly resolve. The best strategy in this instance,
> > unsatisfying as it might be, is to inform users that the service is
> > broken and that they should direct their complaint at the service owner.
> Another strategy could be to disable IPv6 and use IPv4 instead.
> This might happen, e.g., if an operator introduces IPv6 with the result
> that some remote service breaks, and removing IPv6 restores access to the
> remote service.  If this operator would not yet have a pressing need to
> introduce IPv6, rather looking into it early, they might conclude that
> IPv6 just isn't worth the hassle (e.g., fighting third parties to make
> them change their configuration, although they think it works fine).

Yes, indeed this is a risk. But a client turning off IPv6 will always be an
option for frustrated users or operators until there are substantive
v6-only services. I don't know that the ability to eventually turn off IPv4
(a dubious prospect no matter how bullish one is on IPv6) should drive any
particular technical decision. And even if we decide it should, part of
what I'm arguing is that it's unclear which situation is worse for getting
to that outcome: one in which problems with IPv6 deployments are obvious
enough that they get fixed, or one in which the problems are less obvious
and/or visible but persist for years.