[IPv6]Re: [v6ops] New draft: "The IPv6 Loopback Address Prefix"

Ole Trøan <otroan.ietf@gmail.com> Wed, 26 November 2025 07:13 UTC

Return-Path: <otroan.ietf@gmail.com>
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 90A3490DC6A6 for <ipv6@mail2.ietf.org>; Tue, 25 Nov 2025 23:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.205
X-Spam-Level:
X-Spam-Status: No, score=-1.205 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 CabQMlwB6um5 for <ipv6@mail2.ietf.org>; Tue, 25 Nov 2025 23:13:57 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 2456190DC6A3 for <ipv6@ietf.org>; Tue, 25 Nov 2025 23:13:57 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-5959d9a8eceso7656357e87.3 for <ipv6@ietf.org>; Tue, 25 Nov 2025 23:13:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764141236; x=1764746036; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=xIxwQBKsNQNscyGl+Gt6jceOUzb6l0V0T4RNMNhVqng=; b=IfnKHL4NyGIRCJZ+HLEE8ELwWyfltnYoxRyG8lC1WJ5KGiCZP+rmn1PhjOt0iwf2f+ x3scNFKOKCP2a2yTEcSRwkBFTV5rrpd1dwtDduyXAeqHZ72OfexKZkHmajpHzyt5o6a0 G8Qcj/W1DMKBkHhP9ALRPFhpnpdvXMP92zadETUNd2NpreVlSios4gfrIxvAx63azqPf DLDbctDiX+OA6b7yji/zKOoTnTiN6UgOw1Rjmgqw3qupq85tvnpae3cwXrHBYLkXc5hw y6CLFtqinnt3fecaaOPA573wTkZCk3LYJY7YF8XAxJh3RQVHLeBd6gKX3g3ZbhC73AbE nzJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764141236; x=1764746036; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=xIxwQBKsNQNscyGl+Gt6jceOUzb6l0V0T4RNMNhVqng=; b=JpsBmTFTCAwM68RkjkvRXI9jIlokO01TC02giG0YNCo9QyiG8pdog9HxSXW2DRf9Ae 8jjl2piV4C7zaPMRegwIOz1KGoorM05AIxxQevYM0jQifR9WbOSNVr141V1phP2xXelp qSU2vaatmrCMfa9WWcBbMe7mCaB161fyRYcN7+Q0zKWBpju1XL7zknWvqmBvi7DP6IuB oFuXCbo5suSfDb00bbTOTvf2LMzbqt1ojLH+EoKDngQo3poxQoQJcju/76bABZ8pD2Lx ECh5v3TdpfbpWr2Z9TYEoI8qC0345BF6/5yiAwi/zBRAHf4xHDgT2xsiKLDNri4pY5ss FDSQ==
X-Gm-Message-State: AOJu0Yy+v57Bh1tIU53h/HFM+2r204HgDVIOIlkRscz3O6I+Rpc4bdSP Xm04exrr1IoVrlWncuPHu+LjX33QlzyupVZ0fuQ9eawTOjx/hwmmxq4/jdSs0Q==
X-Gm-Gg: ASbGncuT1rkkBoAPjk0uqvUkldRhItjrbf1TEcOy9TUBRuW+SQwgrLgBd0CQWIl94r5 EPTWjBV3XZihPhpsCdyJrn+BzKGkdY0/PODFlQgqBWP0v+a7GcU/rprpP/FjFDph9Jt744StyY8 NukbYrf3eepF6qjjZD1iBfF3f52QKoL15n+7iJVs/Eaeti5qazSAFM2+FaiYWITtZcml//UKyoq mydDMvjWPJ8I+bZLEcCzTvCWHlyQu9CxRorh81z4GkFGmopY3cfDOrNOcKnpKMK8sLhtPndkbTI Ua4t5CRb8AhcY/ysc0Yql2ld0cGsWwKjBksN9e8AnR95zoNA6C+Ca912PlnVg1/UdvEyjHLErjT MQgO1Herhk3RUMYX3+GPQI2ZmTIHcBFq/JU2aB0MFgLR98pIMwc5Iyg/yASM77tErAru0tpGElB qpbEnSGBDpP/VBV1xIPQFIe5SoMhMkXsNAb9ei98SM6ZRX
X-Google-Smtp-Source: AGHT+IEHYugzNp3rS7F29FbXhmdsFeOMi6LKgXr8fK+wTOHyhkL+akffEEPIA4TgxWRtmJVC77rWXA==
X-Received: by 2002:a05:6512:224e:b0:593:f74:90c1 with SMTP id 2adb3069b0e04-596a3eddddemr6930474e87.42.1764141235523; Tue, 25 Nov 2025 23:13:55 -0800 (PST)
Received: from smtpclient.apple ([2001:4650:c3ed:37a:9e2a:f334:61dc:ff10]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-596a0d1493bsm5330049e87.73.2025.11.25.23.13.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Nov 2025 23:13:55 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-7CEA1F40-B0DA-4348-846B-EFB3C44EA75C"
Content-Transfer-Encoding: 7bit
From: Ole Trøan <otroan.ietf@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 26 Nov 2025 08:13:44 +0100
Message-Id: <0AAE012B-E468-4773-B1F4-98460CE111C0@gmail.com>
References: <CAHw9_i+b=uZozstCAm1Kr52Pj-_Y_aCndHc0e703rMUr9va=iA@mail.gmail.com>
In-Reply-To: <CAHw9_i+b=uZozstCAm1Kr52Pj-_Y_aCndHc0e703rMUr9va=iA@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
X-Mailer: iPhone Mail (23B85)
Message-ID-Hash: 7CNBBQTWMTPXMFMS4Z6GBT7VGY2T7HII
X-Message-ID-Hash: 7CNBBQTWMTPXMFMS4Z6GBT7VGY2T7HII
X-MailFrom: otroan.ietf@gmail.com
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: IPv6 <ipv6@ietf.org>, IPv6 Operations <v6ops@ietf.org>, Geoff Huston <gih902@gmail.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [IPv6]Re: [v6ops] New draft: "The IPv6 Loopback Address Prefix"
List-Id: "IPv6 Maintenance Working Group (6man)" <ipv6.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7Y_p5mxWKxl0DMPC6J7e351FDpM>
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>

Thanks for doing this!

Suggestions:
- say less about loopback mechanics. E.g. drop ingress queues etc. 
- ::/96 will likely still be treated as IPv4-compatible by address parsers and formatters. Resulting in ::127.0.0.1 f.ex. Don’t think that is a problem.
- SAS/DAS policy table needs updating as mentioned 
- DNS local use
- RFC4007 talks about the scope of ::1 quite a bit. Not sure if it needs updating. The prefix is having same scope as the address. Should be ok. 
- rfc4291 forwarding rules. This will require forwarding implementations to change. Which currently should have a drop-check for forwarding packets with a ::, ::1, … source. I presume we want the loopback prefix to have the same properties?
- probably other documents needing update?

Cheers,
Ole


On 25 Nov 2025, at 18:39, Warren Kumari <warren@kumari.net> wrote:


Dear 6MAN and V6OPS,

Geoff Huston and I have just submitted https://datatracker.ietf.org/doc/draft-kumari-ipv6-loopback/" rel="noopener noreferrer nofollow" class="">draft-kumari-ipv6-loopback - "The IPv6 Loopback Address Prefix"

We believe that it is within the 6MAN charter ("The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture."), but I have CCed V6OPS as well, as it is clearly operational as well.

Abstract: 
"This document updates the IP Version 6 Address Architecture to define the IPv6 address prefix ::/32 as the Loopback address prefix."

Basically, this document expands the single loopback address ::1/128 into a prefix.

Yes, we are aware that there have been some previous discussions[0] on the need (or lack thereof!) of a loopback prefix in IPv6, but we believe that they are worth revisiting. 

There are a number of situations in which having more than a single address is helpful; an obvious example of this is Dockers/k8s use of 127.0.0.11 for the DNS resolver, SPAM RBL use of the last octet on 127.0.0.x to encode the type of SPAM. It is also relatively common it use this for inter-service communication in container environments. 

It is also a common practice to bind different services to different addresses in the IPv4 loopback space to allow for scaling (avoiding the "Port already in use" issue), testing, etc.  Yes, these can be somewhat emulated with ULAs and / or additional interfaces and scopes, but they are all more complicated, and much more likely to result in leakage or collision. 

Another, more recent example is the ICANN Public Comment on "Name Collision IPv6 Research Study" and proposed use of ::ffff:7f00:3535 [1] - if there was a loopback prefix this would have been a better option[2]


We expect a fairly robust discussion :-), 
W

[0]: I know I've seen them, but I quick search of my mail was unable to find these — the authors are more than happy to link to previous documents, etc. 

[1]: See long threads on 6MAN https://mailarchive.ietf.org/arch/msg/ipv6/-HrYFMwHhsUWYxSXsFIkLpF_Qgk/" target="_blank" rel="noopener noreferrer nofollow" class="">https://mailarchive.ietf.org/arch/msg/ipv6/-HrYFMwHhsUWYxSXsFIkLpF_Qgk/ and V6OPS.

[2]: Solving the technical concerns, but not necessarily the policy ones.

_______________________________________________
v6ops mailing list -- v6ops@ietf.org
To unsubscribe send an email to v6ops-leave@ietf.org