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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 25 November 2025 20:17 UTC

Return-Path: <brian.e.carpenter@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 EB7699081EEF for <ipv6@mail2.ietf.org>; Tue, 25 Nov 2025 12:17:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 hXiL47HS5A30 for <ipv6@mail2.ietf.org>; Tue, 25 Nov 2025 12:17:17 -0800 (PST)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 7E72A9081EE7 for <ipv6@ietf.org>; Tue, 25 Nov 2025 12:17:17 -0800 (PST)
Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-297dd95ffe4so53163385ad.3 for <ipv6@ietf.org>; Tue, 25 Nov 2025 12:17:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764101836; x=1764706636; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=dqyvnJu7GM5yxMBt2HZG9SPbw4o/0jKq2ZZwDip+bDg=; b=Dna5c3YpbT54/2d8IOPzyuEyXbzcYIJuzXpQoqOYqkUgdQ5+YBaNn4yEbSYYCVQyRn dKN2muTAXgj0fhFSpF/PUF69KUdZl7vTCQPO7qRQx+mtqe7YJrmnHDgkpjO9xbSr6mCU mu6wm1enauV+uFkRZ8A5YCR2lvKTiIow2fsLGaSWPdY3+9Txm6x1RHw/BGNhhyfym3Sw XdanOyLs9wZ65Eth2ASJRYnutYl9HHhZI+DQY8dLbIGOSha5rRmXl/jXxnMJfg0NWISr t96vF9KhpZY3nTAvTF6lqvErBmrApg9SzG4jOkVr5Iax9Pr8WWTB7o1DAuhpdRcqwD5k A8Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764101836; x=1764706636; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dqyvnJu7GM5yxMBt2HZG9SPbw4o/0jKq2ZZwDip+bDg=; b=EPuORYGR+3RtfadSOuoggF8BbZoOC7EHzjj7mW12wY1t1ntVyaPgUF5FZzR4ITOgSS 7fjLONOv70NAoNtO81DV82+yvcoD0ELek8kYQaesnC3FgWcXuHJsgwpSAuDbmYuX9U01 dnhLi776xaBFR69fHSwk7iqk7QS4zNYVTy5ttSQ+h8zrGHcXp2UPXbD/JElePc4GkG/9 6Z0hIXMe41s034hujsTEP+Hj8lvq7BriPhKlfwlPKOlMTWbTsCiuHFy8WGQZOSBQFPlm sB3cV2XfNOBg3c38gdFx/klW44sGpBtck7zzK2mwRJlcu9XL/JupW0AmY0GH9ihRe040 mcbw==
X-Forwarded-Encrypted: i=1; AJvYcCV5qAp3EFLVozkb3Vp40yXyuvA1XpmJWAaFh4S4WVcB8o+z5u/1bMleNyB7Qv4qZLC8mPAv@ietf.org
X-Gm-Message-State: AOJu0YzlXvUwaPI4nY7EP4QeTd8BSfAJPSuY9QXVHOHEGMNgOMM52WqO wDbOfRWesH8nLfD0Cpoiyl2rh2G43/9bzhj+7nEukM9Cc/VSTH2fynK2
X-Gm-Gg: ASbGnct7zQoLWr4NAZHB0Uo/f+AZ0pk3Lo9h7q8c0PFXNvA/KklvGMk+fXV+FTE4Ff6 Myelfle9m0MRBFPt991VSfxWfU1tebeUjow1pU/Lf8DLI5FH6aU/+ourD6ogI0O5o4kdc+7ThoQ cynNKa6WvYPMn29W1+TlXX18p3wtkAWM9+d2MP8fVnR4FozqeWzMzcrWuFaQRa6dpmevfmBSt/1 LHUcw2wHv4ALf5f7Dsya3gs/CP1ZjCCkTLfuRaT04H4JFLvfUdQmiWiNbcFLKG2wAqPCEOf8Y7f RyMW0qtQT2St7oEkk5/V+YUlGeQDUpqaXap5jB7WRlWuK31BNMLUwHjrgWicNf4PatVTqJpxtap cXQcgF/JkC424sknNZCM9LiecELW+8HrArb+m5dioWlrr/fAq4v9q17hyE2/hTHcpCFEZ+jEumV O8HFEMw7MhV16oXbKUgSgdm6FpLVgQ22VxChNwgtjgeL5xOtZpvet7bksNiM3PtTB0WGHqvE+q/ X8=
X-Google-Smtp-Source: AGHT+IHMT87qXURytGX7niSdutJ5eZjmBm9tEQ7i9LIXOyh39l+6ShuKnPZ5s+38O5eP79vJhWJlXA==
X-Received: by 2002:a17:903:8ce:b0:295:5a06:308d with SMTP id d9443c01a7336-29baaf75c70mr53058515ad.14.1764101836397; Tue, 25 Nov 2025 12:17:16 -0800 (PST)
Received: from ?IPV6:2404:4400:540a:800:8bdd:3b5f:46ae:fd4c? ([2404:4400:540a:800:8bdd:3b5f:46ae:fd4c]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-29b5b13965csm176535645ad.30.2025.11.25.12.17.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Nov 2025 12:17:15 -0800 (PST)
Message-ID: <7a79a3df-c385-469d-a5f2-4a13eb15c62b@gmail.com>
Date: Wed, 26 Nov 2025 09:17:11 +1300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Warren Kumari <warren@kumari.net>, IPv6 <ipv6@ietf.org>, IPv6 Operations <v6ops@ietf.org>, Geoff Huston <gih902@gmail.com>
References: <CAHw9_i+b=uZozstCAm1Kr52Pj-_Y_aCndHc0e703rMUr9va=iA@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <CAHw9_i+b=uZozstCAm1Kr52Pj-_Y_aCndHc0e703rMUr9va=iA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Message-ID-Hash: 6ARJHUWBY4IA4PXSLZ3HMCEKB2EGVYYI
X-Message-ID-Hash: 6ARJHUWBY4IA4PXSLZ3HMCEKB2EGVYYI
X-MailFrom: brian.e.carpenter@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
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/Z_BRmT_cRwo6WSy1ffUbUBYX_PY>
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>

Hi,

I've always felt that there was some confused thinking behind the use of the term "loopback" and the way the loopback address or prefix became a sort of a rubbish bin for other internal usage.

If the problem to be solved is a lack of addresses for arbitrary purposes, a host could self-assign a ULA prefix today, providing a whole /48 for internal use, so do we really need a new range?

By the way, there is a difference between IPv4 and IPv6 that the draft doesn't mention. IPv4 addresses are assigned to the host. IPv6 addresses are assigned to a specific interface. There's a virtual loopback interface in IPv6 implementations, which presumably will "own" the whole proposed /96. That should be mentioned.

I also think there would be a need for a sort of blanket update to RFC 4291, saying something like:

   Wherever the phrase "the loopback address" is used in RFC 4291,
   it must be read as "any address in ::/96 except for the unspecified
   address".

Regards/Ngā mihi
    Brian Carpenter

On 26-Nov-25 06:38, Warren Kumari wrote:
> Dear 6MAN and V6OPS,
> 
> Geoff Huston and I have just submitted draft-kumari-ipv6-loopback - "The IPv6 Loopback Address Prefix" <https://datatracker.ietf.org/doc/draft-kumari-ipv6-loopback/>
> 
> 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/ <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