[IPv6]Re: [Errata Held for Document Update] RFC4291 (6596)

Mark Andrews <marka@isc.org> Sat, 27 December 2025 20:20 UTC

Return-Path: <marka@isc.org>
X-Original-To: ipv6@mail2.ietf.org
Delivered-To: ipv6@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 7284A9FD58F8; Sat, 27 Dec 2025 12:20:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b="FoAF5dem"; dkim=pass (1024-bit key) header.d=isc.org header.b="osmSvwcS"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DptgejrJd2UL; Sat, 27 Dec 2025 12:20:08 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 092399FD58F3; Sat, 27 Dec 2025 12:20:02 -0800 (PST)
Received: from zimbra10.isc.org (zimbra10.isc.org [149.20.2.90]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 427C04E40D1; Sat, 27 Dec 2025 20:20:02 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 427C04E40D1
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.90
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1766866802; cv=none; b=Fugq3IHjUxPDuaht4+u5VdUeiRSyeFiLQrq49jR2hUr6LaISUKvU6l7jGr6ErTW1Hszm13wJH52q4a+SxrkkBcWZ3TttMmnFt6EkAS9nHTgKhKVUgPGNjBhIM9AdzT0gIi4PUfcDlv3QkWFM6/YnZHR2Ltqq+3j/OfwQq2w1gHY=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1766866802; c=relaxed/relaxed; bh=n9wpqLlmP2rw9aZ07KWNJ//0oiFX50dj0LDbttNJArI=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=Hh7DC9Hlbb2JNTDRLs/mACwRaK2mlaUIl/iswABBWBf3VUDzhg98XruAwQNP96noFEwQftcpGzIG0Z9BKdQka/XXFHBkJ5keJ1IiKvYSolwPJ2VPS+Fl/jbWJYVobv8RhIy0flvZSVw3sngmHLhjYEdxLvI5P/1Y21dcYH47laU=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 427C04E40D1
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1766866802; bh=5wN23EHltCDNP2sBUHZDPE2UgDCAm1/gaQJF8lU5D1o=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=FoAF5demqQSqDbOmAteLnvkZ19PG3AaewtSuHB9ZrbxspRdoch6cJNoEy+BfF8bEa 7pG76CcdT4u7K+nlQ0lumHPri2mcAinHAbKvO/nzYkTcVGEAR6i+ToOwVe01SpxE5/ U4fuhTKzHIjpeHCzFJ3xY/PwxPWHEJyHTyZYycuU=
Received: from zimbra10.isc.org (localhost [127.0.0.1]) by zimbra10.isc.org (Postfix) with ESMTPS id 387CC2E6035E; Sat, 27 Dec 2025 20:20:02 +0000 (UTC)
Received: from zimbra10.isc.org (localhost [127.0.0.1]) by zimbra10.isc.org (Postfix) with ESMTPS id 1D2C02E6035C; Sat, 27 Dec 2025 20:20:02 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbra10.isc.org 1D2C02E6035C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1766866802; bh=n9wpqLlmP2rw9aZ07KWNJ//0oiFX50dj0LDbttNJArI=; h=Mime-Version:From:Date:Message-Id:To; b=osmSvwcSbN2NU/5Z7RIJDrA225g2Snn+ZrsBnuHg7KuRMCRGxq5GcWTzZve8yADhk C2WxtI7l6DM1bBqPaMrVWtOyYRu35nurqvMFsq7mi0WFNC9whLBBVULrhqkQzFfC5X pALOQQ1HPG6vzMxM5Nvwz48jhOW+9sPI0sUbbIyo=
Received: from smtpclient.apple (n49-187-18-238.bla1.nsw.optusnet.com.au [49.187.18.238]) by zimbra10.isc.org (Postfix) with ESMTPSA id 5C5FA2E60351; Sat, 27 Dec 2025 20:20:00 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.21\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <20251227024424.04416C000CD7@rfcpa.rfc-editor.org>
Date: Sun, 28 Dec 2025 07:19:46 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E3AD2511-013F-442C-B5F1-3AE8BC10EFA3@isc.org>
References: <20251227024424.04416C000CD7@rfcpa.rfc-editor.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>
X-Mailer: Apple Mail (2.3731.700.6.1.21)
Message-ID-Hash: D43WTIWMVTYEWVRZJEOZWQGUKXEGUSLO
X-Message-ID-Hash: D43WTIWMVTYEWVRZJEOZWQGUKXEGUSLO
X-MailFrom: marka@isc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipv6.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: martin@kurahaupo.gen.nz, bob.hinden@gmail.com, The IESG <iesg@ietf.org>, 6man WG <ipv6@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [IPv6]Re: [Errata Held for Document Update] RFC4291 (6596)
List-Id: "IPv6 Maintenance Working Group (6man)" <ipv6.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/UXUp0_kDUTGWsG-VV0CVlml2-7Q>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Owner: <mailto:ipv6-owner@ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Subscribe: <mailto:ipv6-join@ietf.org>
List-Unsubscribe: <mailto:ipv6-leave@ietf.org>

This just makes invalid every parser that correctly accepts "::0:0:0:0:0:0:1” today.
Fix the broken parsers, don’t break the working parsers.  

Add a note like.

Note “::” can be used to “compress” just the leading or trailing 16 bits leading to valid
but unusual IPv6 addresses like “::0:0:0:0:0:0:0” and “0:0:0:0:0:0:0::”.

> On 27 Dec 2025, at 13:44, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been held for document update 
> for RFC4291, "IP Version 6 Addressing Architecture". 
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6596
> 
> --------------------------------------
> Status: Held for Document Update
> Type: Technical
> 
> Reported by: Martin D Kealey <martin@kurahaupo.gen.nz>
> Date Reported: 2021-06-0
> Held by: Erik Kline (IESG)
> 
> Section: 2.2
> 
> Original Text
> -------------
>   2. Due to some methods of allocating certain styles of IPv6
>      addresses, it will be common for addresses to contain long strings
>      of zero bits.  In order to make writing addresses containing zero
>      bits easier, a special syntax is available to compress the zeros.
>      The use of "::" indicates one or more groups of 16 bits of zeros.
>      The "::" can only appear once in an address.  The "::" can also be
>      used to compress leading or trailing zeros in an address.
> 
> Corrected Text
> --------------
> EITHER
> 
>   2. Due to some methods of allocating certain styles of IPv6
>      addresses, it will be common for addresses to contain long strings
>      of zero bits.  In order to make writing addresses containing zero
>      bits easier, a special syntax is available to compress the zeros.
>      The use of "::" indicates one or more "0" pieces, or two or more when
>      leading or trailing. The "::" can only appear once in an address.
> 
> OR
> 
>   2. Due to some methods of allocating certain styles of IPv6
>      addresses, it will be common for addresses to contain long strings
>      of zero bits.  In order to make writing addresses containing zero
>      bits easier, a special syntax is available to compress the zeros.
>      The use of "::" indicates one or more pieces of 16 bits of zeros,
>      or two or more when leading or trailing. The "::" can only appear
>      once in an address.
> 
> 
> Notes
> -----
> 1. The existing wording would permit "::" to be used in leading or trailing position to compress a single 16-bit piece, leading to the conclusion that "::0:0:0:0:0:0:1" is a valid way to write the loopback address, with eight colons.
> 
> Many consumers of textual IPv6 addresses would reject this out of hand as "too many colons", and it seems questionable that such an interpretation was ever intended. Enforcing this on producers would improve interoperability.
> 
> 2. The preceding paragraphs defines "piece", but the undefined term "group" is used in this paragraph, so by changing that term I hope to clarify that this is a textual substitution, necessarily aligned to a multiple of 16 bits.
> 
> I am uncomfortable with the phrasing "pieces of 16 bits of zeros", but I offer it as a single-word change to effect my point (2); I leave it to the discretion of the editor which of my alternatives to adopt.
> 
> --->8 INT AD notes 8<---
> 
> Readers of this RFC and this erratum are directed to RFC 5952, specifically section 4.*.
> 
> --------------------------------------
> RFC4291 (draft-ietf-ipv6-addr-arch-v4-04)
> --------------------------------------
> Title               : IP Version 6 Addressing Architecture
> Publication Date    : February 2006
> Author(s)           : R. Hinden, S. Deering
> Category            : DRAFT STANDARD
> Source              : IP Version 6 Working Group
> Stream              : IETF
> Verifying Party     : IESG
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> List Info: https://mailman3.ietf.org/mailman3/lists/ipv6@ietf.org/
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org