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

[Warren Kumari <[e-mail]>]

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/ and
V6OPS.

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