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

Erik Auerswald <> Tue, 28 November 2023 18:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76F8CC151539 for <>; Tue, 28 Nov 2023 10:40:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pXCXAlwF3NHe for <>; Tue, 28 Nov 2023 10:40:43 -0800 (PST)
Received: from ( [IPv6:2001:638:208:120::220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C284C14CE24 for <>; Tue, 28 Nov 2023 10:40:42 -0800 (PST)
Received: from ( [IPv6:2001:638:208:ef34:0:ff:fe00:65]) by (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 3ASIeps3083869 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Nov 2023 19:40:51 +0100
Received: from (ip6-localhost [IPv6:::1]) by (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 3ASIeaVa005838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Nov 2023 19:40:36 +0100
Received: (from auerswal@localhost) by (8.14.4/8.14.4/Submit) id 3ASIeagZ005836; Tue, 28 Nov 2023 19:40:36 +0100
Date: Tue, 28 Nov 2023 19:40:36 +0100
From: Erik Auerswald <>
To: Kyle Rose <>
Cc: 6man WG <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
Author: Erik Auerswald <>
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 18:40:47 -0000

Hi Kyle,

On Tue, Nov 28, 2023 at 10:04:07AM -0500, Kyle Rose wrote:
> [...]
> according to the default policy table in any of 3484 (same precedence:
> 40), 6724 (precedence 3 < 40), or the bastardized gai.conf Debian
> distributes.

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

> [...]
> 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).

Best regards,