<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.4) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-kumari-ipv6-loopback-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <front>
    <title abbrev="IPv6 Loopback Prefix">The IPv6 Loopback Address Prefix</title>
    <seriesInfo name="Internet-Draft" value="draft-kumari-ipv6-loopback-00"/>
    <author initials="G." surname="Huston" fullname="Geoff Huston">
      <organization>APNIC</organization>
      <address>
        <postal>
          <street>6 Cordelia St</street>
          <city>South Brisbane</city>
          <code>QLD 4101</code>
          <country>Australia</country>
        </postal>
        <email>gih@apnic.net</email>
      </address>
    </author>
    <author initials="W." surname="Kumari">
      <organization>Google, Inc.</organization>
      <address>
        <email>warren@kumari.net</email>
      </address>
    </author>
    <date year="2025" month="November" day="25"/>
    <area>Internet</area>
    <workgroup>WG Working Group</workgroup>
    <keyword>IPv6</keyword>
    <keyword>Loopback</keyword>
    <keyword>Documentation</keyword>
    <abstract>
      <?line 52?>

<t>This document updates the IP Version 6 Address Architecture to define the IPv6
address prefix ::/32 as the Loopback address prefix.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://wkumari.github.io/draft-kumari-ipv6-loopback/draft-kumari-ipv6-loopback.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-kumari-ipv6-loopback/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/wkumari/draft-kumari-ipv6-loopback"/>.</t>
    </note>
  </front>
  <middle>
    <?line 58?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>In the IP address architecture, a loopback address is a special IP address used
by hosts to send data to itself. Packets directed to a loopback address are
automatically routed back to the sending host’s network software stack without
ever reaching the physical network interface. This has use in some forms of
testing and is used to support a non-network method to facilitate local
inter-process communication within a host.</t>
      <t>This document updates the IP Version 6 Address Architecture to define the IPv6
address prefix ::/32 as the Loopback address prefix.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="loopback-addresses">
      <name>Loopback addresses</name>
      <t>The IPv4 network 127.0.0.0/8 was reserved by the IANA in <xref target="RFC791"/> where tha
class-based address architecture was described. It is understood that it was
the IANA's policy at the time to reserve the first and last network of each
class, and the address prefixes 0.0.0.0/8 and 127.0.0.0/8 from the Class A
space were reserved in accordance with this practice. <xref target="RFC990"/> listed the
127.0.0.0/8 address prefix as being used by the loopback function, and this
function was listed as a requirement for all Internet hosts in <xref target="RFC1122"/>.</t>
      <t>The "loopback" function is defined such that an outbound packet that triggers
this loopback function should loop back to the packet ingress queue for
processing by the same host. No packet that is addresses to a network 127
address should ever to passed to any network.</t>
      <t><xref target="RFC1884"/>, the original IPv6 Addressing Architecture document, allocates a
single local loopback address, ::1. This single address allocation has been
preserved in all subsequent revision to the IPv6 addressing specification
(<xref target="RFC2373"/>, <xref target="RFC3513"/>, <xref target="RFC4291"/>)</t>
      <t>These addresses enable localhost communication, network diagnostics, and
inter-process connections, making them essential for developers and IT
professionals.</t>
      <t>Multiple loopback addresses can increase the number of distinct sockets that
can be used for inter-process communication within a host. A larger local
loopback address in IPv6 can permit large numbers of distinct concurrent
loopback TCP connections within a single host, which is comparable the the
functionality supported in the IPv4 loopback address prefix.</t>
    </section>
    <section anchor="the-ipv6-loopback-prefix">
      <name>The IPv6 Loopback Prefix</name>
      <t>The IANA IPv6 Address registry denotes the address prefix ::/8 as being
reserved by the IETF in <xref target="RFC3513"/> <xref target="RFC4291"/>. This range has been partially
allocated with the prefix ::FFFF:0:0/32 being used in the context of an IPv6
transition technology to map IPv4 addresses into IPv6 addresses.</t>
      <t>The document expands the set of IPv6 loopback addresses to span the address
prefix range ::0 through to ::FFFFFFFF (or ::/32 in prefix notation).</t>
      <t>This RFC replaces section 2.5.2 and 2.5.3 of <xref target="RFC4291"/> as follows:</t>
      <ul empty="true">
        <li>
          <t>The Loopback prefix</t>
          <t>The unicast address prefix ::/32 is called the loopback address prefix.</t>
          <t>The first address of this address prefix block, 0:0:0:0:0:0:0:0, is also termed
the "unspecified address". This address <bcp14>MUST NOT</bcp14> be assigned to any node, as it
indicates the absence of an address. One example of the use of this address is
in the Source Address field of any IPv6 packets sent by an initializing host
before it has learned its own address.</t>
          <t>All other loopback addresses drawn from this prefix may be used by a node as a
destination address to send an IPv6 packet to itself. These addresses <bcp14>MUST NOT</bcp14>
be assigned to any physical interface. These addresses are treated as having
Link-Local scope, and may be thought of as the Link-Local unicast address
prefix of a virtual interface (typically called the "loopback interface") to an
imaginary link that goes nowhere.</t>
          <t>All loopback addresses other than the unspecified address <bcp14>MUST NOT</bcp14> be used as
the source address in IPv6 packets that are sent outside of a single node. An
IPv6 packet with a destination address of loopback address <bcp14>MUST NOT</bcp14> be sent
outside of a single node and must never be forwarded by an IPv6 router. A
packet received on an interface with a destination loopback address <bcp14>MUST</bcp14> be
dropped.</t>
        </li>
      </ul>
      <t>((Geoff: I have gone for a simple prefix that sits below the IPv4-mapped
address block of 0:0:0:0:0:FFFF::/32 - the complication is that the prefix then
includes the "unspecified address" as well.))</t>
      <t>((Geoff: this last sentence of the paragraph on the unspecified address, lifted
from RFC4291, strikes me as incorrect! If a packet is sent out an interface
with a source address of all zeros then nobody can respond and the packet has
no purpose. I'm inclined to drop this sentence from the proposed update, but as
I don't think I was paying attention to IPv6 when this text was originally
incorporated into the IPv6 Address Architecture so I have no idea what scenario
was being referenced in this case.))</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>IPv6 addressing documents do not have any direct impact on Internet
infrastructure security.</t>
      <t>((WK: I don't think that we need to add anything about the "Unspecified
Address", nor the behavior of "packets with source address of ::" since this is
already covered in RFC 4291, but figured I'd mention it here for
completeness.))</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>The IANA is requested to amend the IPv6 Address registry and the IPv6 Special
Purpose Address registry to record the designation of the IPv6 address prefix
::/32 as denoting the IPV6 Loopback function.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC4291">
          <front>
            <title>IP Version 6 Addressing Architecture</title>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <date month="February" year="2006"/>
            <abstract>
              <t>This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t>
              <t>This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4291"/>
          <seriesInfo name="DOI" value="10.17487/RFC4291"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC791">
          <front>
            <title>Internet Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="September" year="1981"/>
          </front>
          <seriesInfo name="STD" value="5"/>
          <seriesInfo name="RFC" value="791"/>
          <seriesInfo name="DOI" value="10.17487/RFC0791"/>
        </reference>
        <reference anchor="RFC990">
          <front>
            <title>Assigned numbers</title>
            <author fullname="J.K. Reynolds" initials="J.K." surname="Reynolds"/>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="November" year="1986"/>
            <abstract>
              <t>This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-997. Obsoletes RFC-960, 943, 923 and 900.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="990"/>
          <seriesInfo name="DOI" value="10.17487/RFC0990"/>
        </reference>
        <reference anchor="RFC1122">
          <front>
            <title>Requirements for Internet Hosts - Communication Layers</title>
            <author fullname="R. Braden" initials="R." role="editor" surname="Braden"/>
            <date month="October" year="1989"/>
            <abstract>
              <t>This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="3"/>
          <seriesInfo name="RFC" value="1122"/>
          <seriesInfo name="DOI" value="10.17487/RFC1122"/>
        </reference>
        <reference anchor="RFC1884">
          <front>
            <title>IP Version 6 Addressing Architecture</title>
            <author fullname="R. Hinden" initials="R." role="editor" surname="Hinden"/>
            <author fullname="S. Deering" initials="S." role="editor" surname="Deering"/>
            <date month="December" year="1995"/>
            <abstract>
              <t>This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1884"/>
          <seriesInfo name="DOI" value="10.17487/RFC1884"/>
        </reference>
        <reference anchor="RFC2373">
          <front>
            <title>IP Version 6 Addressing Architecture</title>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <date month="July" year="1998"/>
            <abstract>
              <t>This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2373"/>
          <seriesInfo name="DOI" value="10.17487/RFC2373"/>
        </reference>
        <reference anchor="RFC3513">
          <front>
            <title>Internet Protocol Version 6 (IPv6) Addressing Architecture</title>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <date month="April" year="2003"/>
            <abstract>
              <t>This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3513"/>
          <seriesInfo name="DOI" value="10.17487/RFC3513"/>
        </reference>
      </references>
    </references>
    <?line 188?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA81Z23IbNxJ9x1cg9IPtLZEWZcUXVlYJIzk2K7KlWHJcqa19
AGdAEqUhMAFmRDMuVe1v7Nt+y37KfsmebmCGQ5FOed/WfvAQ176c7j4N9/t9
ISpTFXoke9cLLSeXt8/kuXPlVGU3cpznXocgL72emU89oaZTr2+xdHtZM52p
Ss+dX49kqHIhcpdZtcTJuVezqn9TL5U3fVPePusXaWv/8FCEero0IRhnq3WJ
1ZNX1z8JWy+n2o9EjiNHInM2aBvqMJKVr7WACE+F8lphta20t7oSK+dv5t7V
5Uh+fC0/4pexc/maRsSNXmM6HwnZZw3p30Z6+j5zWb3UtlIVpBC32ta4VMoo
z/ZRUs5NtainI7mKCj35snZYXED+UI3koqrKMHryJG0axEMGxv3J9j+ZGiyq
ZSGEqquF86QWrpLSWBjo9UC+qUMFPWhoVhdFdMJr7Waz7pTzc2XNH6zzSI4v
301OeVwvlSlGUHPxgyqtyQZkXZoIldcaujyTpzCmLoySV3EmMxWcfuUgjvzR
mzBVVscJl+PqX87P5PHwcJiGalsRRsYQxSucsiX+x4H8mRXeI+Nr5+aFPoDP
s0FX1JXyXtsfkmlJXGGdX2LXLfvx/U+nx0cvhyP5oPmEz4Fh+av2hDtolJBO
fh77bGEqnVW11z0hhLGze4c9p7PiYc/TWQmFCAVXucwVvbjy5cvDZiU+aeUY
l8ytzmVEeEgLh8OjoyQffdLK9/r32nhNuAwSIrRQl29cwFAfblgua3iIzSPP
1bpz3osXx815+Px6fXn30dPnT9Nu+vwfdz/9dtjsps+v3z0YDITo9/tSTQka
Gfx4vTBB5ik8ZV1SPgiy4ky1e+TWebJyMkdisjqtR9yrtK7kjCVHoydPj6SK
B7bpbHsRRGKZlibPCy3EA/KDd3mdcbIQE9uI0+xTHSEOpJLF/YOhkpKh1JlR
RXdjHXQupmu5YP9CfCS9XEJlRT9MFXQxG8hLHKUxnwMcWQUkYW7PJUiPlB8c
ITdTRbGWyF+0nFdhD0lNF5Af6Mb//OOfQQJelEhlcLMKYYUVFS1fIV1ht9C3
2kvkXSiIXXRCuVgHOr/daQilM5XpgWTnLRQrhnEcutSE5GWQbiYoMdIpCjqa
qDzrXJel8xVUss72m1OXGgLwPI42hUGq1tAZFwu+sF96l5Ha2VZMkNy4WLGC
g/8TOD1A4FoUGZIwsPpndK7h3ySjlihYkipWkL23H66uewfxX/nugr/fv/rl
w+T9qzP6vnozPj9vP0RacfXm4sP52eZrs/P04u3bV+/O4maMyq0h0Xs7/g0z
JFXv4vJ6cvFufN4j51VbplPRIFMd/Q3dCFoqiFyHzJspfmDPj6eX//7X8Fh+
/vwNpZLh8OXdXfrxYvj8GD9WC23jbc4CovEnzLcWqiy18nQKwCszVcLnRTgg
84aFW1m50F7Dmn/5G1nm7yP53TQrh8cnaYAU3hpsbLY1yDbbHdnZHI24Z2jP
Na01t8bvWXpb3vFvW78bu3cGv/u+IOT1hy++PxEEofvw0gk5wOVxG4vDo+eD
Q/r75AWKZEDkBu1vKQesI4jH78Zk4c+fYymLDiHXLpTIChVCf6ooLvelNj6x
dfdATioOY5sjjCpHwbpQGKponWhue4g4cIXJ1hJzNFiZJSMpicZjM4MTGBQQ
oWq1cTNJmScKFkFDq7fjC+F82OpMS7o2mHm35D2ndIQci1AiUckVqdzahhCX
ZQg+ZWkOGSRiv6SKZCivsblQz2GuwgROwQstuhfdSwww1FRTruMkl4zfZuxZ
bbmWNCqZIJohtnG6Q1HV8BtSwJyAYqPlBbFuNP4kHnF3N4iw6DW39drryFsx
oeVIutki+ktZiUQ/BUnLZcmVJo5X3szn8KxgW+zITjFZFzlPbFWYdAaUZ4P8
Xuuaa4BICZuskgwSwFNjopbv3NblVDAbmMdy10F4m4WTCFyjKjogpJKi7LrZ
AHNE44AU3d1xqgHJNHNjuRTffpGdtKnvgGzuMi4cStC6IlWinRp8gIowTGUw
LWwDKZ5BllswOrSFRboQhGPRGQX4m3yNtstwcUpmZVHVRlRmE7NU9sQj1pGo
G+nIP4iJtT+IAt/dPWZoBN2xrbZq2qhDntgupwet2XOj5hbzJouBuFOErdWM
C0wv1U0iC0tJt6DuwVYE3hyuKlwJVDHyJ9cEipnmXhC5Hr56WxeVKQu9Y1rI
mgGqxmZgIyGmjcioKU3khqhFVoFxRK5EKBK0AQWLY5Cu/3riIMfIRB7wT5Rj
l9HZ6BG6AvoskfV4Q8Pyt4SCdbKaOpZqc9D16WXXapv7E25IjAMkZ4M4NSxs
qTz7ipMo0k8TieioqnXDoiKWqqYu7Mjd4SS73X9s61NZoUrRjQ8gcg6F/Bpe
tK5hUbuE6EWb/MRO9UGj32ariM8uPFPgeGVhxyZIENWe8FOAIKQwzJscrTfX
/oQ/o8PRIfGxTuZNtoChK/2pIqeo6DiBdsMGZmASAb+wrnDzNQXbUpXRdhvg
ATduKwB1SFm2pUf6UwlEh8Sx+SbesAfGRHmxuGs+kfSIqo9Gh5gEeZ8vaHFU
jv7IRwBx5JxQLO2BLxjBjxu2C3vCV2WBQocsFPEljwbfDo446OjrKcnXsTy5
bOZg3lUYCXFy3WWz8RpxEoc5YKhW7yPChFM4KZbHL2MvHZWKfpqEQFxo7h08
hctvDuThaOvvAReIIiA1IvbQQ53Qhb3apqy4ITC9BKrm2IYpUl5QTWfeVAyX
a6abphInBn1S1jYL6E81kYMIoHTYQF6AoelPakkJixXgZLOjC+r7SULilas9
zmliCqKigPGp6wiYMjV7lDYpbjjnGYoA80fTuImTqUY+08S1KE4K8GbSAw2j
JKLcyEeWHqOsONzs90Ex9wrLE0kyrdGXat3mTRKBLcN0RJzk3MTFnNno1zSu
KbbaSr5pYe+XncYNpMmOH9oOc6uz3D6A2xFUgsSTFuqWEs7JubE3/XOuzSFD
oYkMK+lDHe18EbNAatk2y+8BW5wkW9BieWt8VXcFko+qdZm67A7kW9K1Wdl7
HNUCApaKWAcSKJj9TeQ5cwddrFvF1ia5a4+jogexJaJoD9C3kM2eAwnnsAgR
cvcrVwO0SAK9jogDFQwmj0BvShF5HxURKnS9yzlYyX14wOad4O+KRzeJky9d
FV1Wcx9AzG7K9HGlfJ7gmBTg1w0PweCrKJLXmTZUb0gW2/HWHln3CzjVQLh3
6ERzpNNHj/gNdSQnBDANb1kdSTjk5aBPIGEbBgq/KfjNqq2//SU1tXlLWDmb
kcKbXMaFi7NnP5UqHNyQEpPc0yl1+LQgX1lR5yk37U17hPCVLorB48cdPSKV
J5iTC5qMFlm7V3OvygXZ7gsQOwBwZwg4wQkjFY8DeiU2N5BlySkCojlP71Tf
yAk5tmkHQouvLdeI5Jp7ICVMIBL+0N6xkhbImLp8zXwLK0rH6SbvdhzIhMKi
C6h96QIAO3m4JGkKk1IL+TVaoFW+bQ/BCWlTnl6IDuSU5AxiggpvH5IDKGQn
3J2Vas2vWFUVX3RkQw7oLSNewGSD1jadBtgLGwYUTUWO1qX1e1+fUNwS7KAU
4kThfEJZBsrujROrtscEMJA+oE/ePtsglWl2/QN5pcE9iSGegmbiHK/Ss9P9
jqLhMvToQ6wiXk4JOT48SkAeDTEBpP0/GGNnHnDydZI53cWx8/FnCpyu/RjL
KyikU7LPyYnrit8W1ZSwwYD+sMGeSLbpoRVxnqenmrK9Y97fa7IYw2gXRKNR
j1JLpqNZUIhVgapBQHLILdFiRJgilMnrMzOvaWLyEFkoeZjqLD0ZUBvLAarh
e6qw0cTMle+btyXRRGmpqQvN0+1SJ+Dup9eqO3sVH43FZUT17mp+SaHHC96D
nIBSGpNHiuyumxsy175bMpVvXnYnl792moGmvUgv9PzfW9B1nN2gXqHgzRkr
4vModjw6/2tvBkqme3fQ/eLsQqp2JUrbfwGGxhFneBwAAA==

-->

</rfc>
