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

Mark Smith <markzzzsmith@gmail.com> Wed, 26 November 2025 00:03 UTC

Return-Path: <markzzzsmith@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 6642590A0653 for <ipv6@mail2.ietf.org>; Tue, 25 Nov 2025 16:03:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Level:
X-Spam-Status: No, score=-0.599 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, 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 hEZpXHWl5yl4 for <ipv6@mail2.ietf.org>; Tue, 25 Nov 2025 16:03:47 -0800 (PST)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 EA97E90A064D for <ipv6@ietf.org>; Tue, 25 Nov 2025 16:03:47 -0800 (PST)
Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-bd1ce1b35e7so4158538a12.0 for <ipv6@ietf.org>; Tue, 25 Nov 2025 16:03:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764115427; x=1764720227; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=wYmxiDxeggZYaaNpO1iUFmy2oUWzC2FeaXkXAogIZkM=; b=c3zA2SzIAdWxqhZOj0prYIYbtdnDKZMb9IXbWtUawLqMB/Bcq65z0zhXnzy00ByJfA M5UkIOFwr+kg9eIIVAWF3UzhsQb/X6RV/4or8szR0rDjWiMNbmMwGn4xpfq9NlxMFKco xgNQIwTJWC/SndAXcHUxdekPeowZlDSDHY3NPXQ7EvPHtRyoAIF8FRA4L+FGY43ksdj8 JFXMWjmNovdvWfXHFoQ/4hXmu8qc65/brPaJD2iQJX8AL7+LaHxm/UTUP86Nke7uDsDX /O7MzF8Ajg2PFJLT+/wuKpz8yNmVUB1wAtPnALS1PmutzzK03DxI0inb23B2W1/WIpvJ KQWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764115427; x=1764720227; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=wYmxiDxeggZYaaNpO1iUFmy2oUWzC2FeaXkXAogIZkM=; b=OPVGNSucS1tjOX3THkwr6OZa7NpBss9KyrtSez++jOlXgtb2+QrqU7SzLxeWZv+RJk x8HveCiGLMdh0BqJ8ZFco8yFJq/hSj4dKocJOtnFvN35HcEd9Aas8FcJjy0wJoeoOBDq QYjDryk0JltAw4AeyVlSdHEEFfCLGDKXyTgIeFd66o/y2jMArc5mfoC68lwkLX+j/6m1 CJkccfZVL9r9EwZkvIzAh/b0tEDigdWEhTQ8OQXltltuTYXGcn5B40mUFK34vxA3eDNh J2DE97ogOIVrK+rPW5/9kdl5xFrTk4MYiWk6JG0bUHWczcuqRzfiGy7eGUMQUy74FSv0 wtvA==
X-Forwarded-Encrypted: i=1; AJvYcCXySsA1e7Y9arXMThJ7y5FTHwRfo3GlI8VzOC2UUbSRPhJzfcEIT1jxtDt51gO95b2aSm1C@ietf.org
X-Gm-Message-State: AOJu0YyT++KYLvrvqf7b8ACh1tUM7yOPOSmw2/TR+k+RS30Pq4avi2u0 l/X7hAfoArJ5RUzS52N3R0CaIfwZNPsaqxAMzLG67uSD9CnvjMilm6NX3VrmRrfbxG43tSK0/sL EC2wpSSf0Fhxj74A/d6EyL9ZE2LbCUVP0EhIv
X-Gm-Gg: ASbGncvFFGLbeMmIpu7yivx7BJlaRC9GffFBZzhXu5XyItODOj0Y50fpQrcZtog/2co ag1rGYteCPJNPnRkobwCaHUoicU+5M2sWFv3XsIuRJQYWOhhttHt4cXXSPS8akqT9EQhDzE2Rt9 hgBZb1f+p0Adv6J0eVfOD2S18Ez7KoXop2StHU8EC6ebeuULY9hX3bMSvvgT6S41mPsGD1X8FYJ KX2f7U7EM7ht2K29bhmz5dlk5AzlqAxqRYPzDJ/SrT0tYu8ZmpLbQxxTGo8oBrvQ5tSTdQ=
X-Google-Smtp-Source: AGHT+IGaAhyzQ2HPo0hjAtcexfXMrzbqvTvAKG5lmh6UonWsq5WrzyHOIh8zIJl10s7FIjIR53YoKVgnCgnKzQPYVvE=
X-Received: by 2002:a05:7022:e17:b0:119:e56c:18ae with SMTP id a92af1059eb24-11c9d848290mr12078776c88.22.1764115426787; Tue, 25 Nov 2025 16:03:46 -0800 (PST)
MIME-Version: 1.0
References: <CAHw9_i+b=uZozstCAm1Kr52Pj-_Y_aCndHc0e703rMUr9va=iA@mail.gmail.com> <CAO42Z2xsGuZ+5V8SadxRRkeeL7owm35F9MO8owAcWwfi9Q6nFw@mail.gmail.com> <F04C4F2A-C664-4B68-875B-C4C6CF3B6C64@gmail.com>
In-Reply-To: <F04C4F2A-C664-4B68-875B-C4C6CF3B6C64@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 26 Nov 2025 11:03:20 +1100
X-Gm-Features: AWmQ_bmxaAGNGZnv5oX6Fr8og6mQFgmCI_xZc-PrgJy7HosHQqJVcoTw5nRd0iE
Message-ID: <CAO42Z2x85B3Cn87QZQqhDef28Pfp_ukWqNO71Ucg=Jyut_NEkA@mail.gmail.com>
To: Geoff Huston <gih902@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: TU2FCZPYVTLDEFM3IIK6EFJTRKTGGDJ3
X-Message-ID-Hash: TU2FCZPYVTLDEFM3IIK6EFJTRKTGGDJ3
X-MailFrom: markzzzsmith@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: Warren Kumari <warren@kumari.net>, IPv6 <ipv6@ietf.org>, IPv6 Operations <v6ops@ietf.org>
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/7bM5Hf86qd5JDumBxoV7O_bUSbk>
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 Geoff,

On Wed, 26 Nov 2025 at 10:19, Geoff Huston <gih902@gmail.com> wrote:
>
> thanks Mark - except that you should  substitute the /32 to a /96 as I got confused between my left and my right!
>

One of my use cases, which I think I hinted to but didn't specifically
state, was multiple loopback interfaces on a node.

On Cisco routers you can create multiple loopback interfaces. I've
done that so that I could have say a management loopback interface and
address, a BGP session loopback interface and address and then other
loopback interfaces and addresses for other functions such as an
L2TPv2 end point, RADIUS service client address etc.. Those loopback
interface addresses were all announced into the routing protocol (or
not depending on function).

I thought to do that so that if for some reason you might need to move
the L2TP end point to a different router you could do that without
disrupting your BGP sessions or management address for the router etc.
A dedicated address per function made moving that function/service
address to another router much easier than having to renumber other
devices to point to a new location for the service/function. You could
also configure different per interface packet filters for each of the
loopback interfaces based on their security needs.

>From that sort of experience I realised that having multiple loopback
interfaces on a host could also be useful for testing etc., because
you're able to simulate both the interface and address per interface
model.

 (Under Linux you can create additional "loopback" interfaces with the
dummy module e.g. modprobe dummy numdummies=16 to create 16 dummy
"loopback" interfaces).

A /48 for the loopback prefix would do the trick, you could allocate a
/64 to each of the loopback interfaces. However, for the purposes of
routing testing and simulation I thought possibly you might want to
have each loopback interface represent a subscriber CPE to which you
assign a /48. So a /32 seemed to me to be a better "Goldilocks" size
for the loopback prefix that would best and better accommodate all
likely testing scenarios on a host that you would use a loopback
prefix for, and it also aligned with the default RIR prefix assignment
size.

Regards,
Mark.


> :-)
>
> g
>
>
> > On 26 Nov 2025, at 10:16 am, Mark Smith <markzzzsmith@gmail.com> wrote:
> >
> > Hello,
> >
> > On Wed, 26 Nov 2025 at 04:40, Warren Kumari <warren@kumari.net> wrote:
> >>
> >> Dear 6MAN and V6OPS,
> >>
> >> Geoff Huston and I have just submitted 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]
> >>
> >
> > I fully agree that there is a need for a larger loopback prefix. I
> > also fully agree that /32 is the Goldilocks size.
> >
> > "A Larger Loopback Prefix for IPv6"
> > https://datatracker.ietf.org/doc/draft-smith-v6ops-larger-ipv6-loopback-prefix/04/
> >
> > Regards,
> > Mark.
> >
> >
> >>
> >> 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/ 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
>