<?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-01" 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-01"/>
    <author initials="G." surname="Huston" fullname="Geoff Huston">
      <organization>APNIC</organization>
      <address>
        <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="26"/>
    <area>Internet</area>
    <workgroup>WG Working Group</workgroup>
    <keyword>IPv6</keyword>
    <keyword>Loopback</keyword>
    <keyword>Documentation</keyword>
    <abstract>
      <?line 48?>

<t>This document updates the IP Version 6 Address Architecture to define the IPv6
address prefix ::/96 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 54?>

<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 a 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 ::/96 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 the
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 whose
destination address triggers this loopback function should loop the packet back
to the packet ingress queue for processing by the same host. No packet that is
addresses to a loopback address should ever to passed to any physical 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>Loopback addresses enable localhost communication, network diagnostics, and
inter-process connections, making them essential for various local functions.</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 prefix in IPv6 can permit large numbers of distinct concurrent
loopback TCP connections within a single host, which is comparable to the
functionality supported by 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/96 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 through ::FFFF:FFFF (or ::/96 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 ::/96 is called the loopback address prefix.</t>
          <t>The first address of this address prefix block, 0:0:0:0:0:0:0:0 (::/128), 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 loopback address 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 proposing a simple prefix that sits below the
IPv4-mapped address block of 0:0:0:0:0:FFFF::/96 - the complication is that the
prefix then includes the "unspecified address" as well, so the RFC4291 text
relating to the unspecificed address is reproduced in this proposed amendment,
as this text proposes replacing the entirety of sections 2.5.2 and 2.5.3 of
RFC4291.))</t>
      <t>((Geoff: David Farmer has proposed adding additional text noting that this
proposed address designation clashes with the now deprecated IPv4-Compatible
IPv6 Address designation in section 2.5.5.1. It is noted that this was
deprecated in RFC4291 twenty years ago and I'm proposing no further mention of
this deprecated historic address designation. David  suggests that this old
designation should be explicity noted in this text.))</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>((heas: ::1/32 remains the primary loopback address and <bcp14>MUST</bcp14> (<bcp14>SHOULD</bcp14>?) be
assigned to a loopback interface.))</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
::/96 as denoting the IPV6 Loopback function.</t>
      <t>The IANA is also requested to add an entry to the IPv6 Locally-Served DNS Zone
Registry for the entry 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</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 191?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>The authors would like to thank Alejandro Acosta, Brian Carpenter, Antonis
Chariton, Owen DeLong, Gert Doering, Jeremy Duncan, David Farmer, Steinar Haug,
Gábor Lencse, Terry Sweetser, Ole Trøan, and Maciej Żenczykowski for their
comments, discussions, and suggestions on this topic.</t>
      <t>Additional thanks to John Heasley for submitting Pull Requests.</t>
      <t>We would also like to speciofically thank Mark Smith for an earlier (2013)
effort: draft-smith-v6ops-larger-ipv6-loopback-prefix-04, which proposed a /32
designation.</t>
      <t>The need for a loopback address prefix has long been a topic of discussion in
various forums, and we would like to acknowledge the contributions of many
individuals who have participated in these discussions over the years.
Unfortunately, at least one of the authors has a terrible memory, and has lost
track of all those who have contributed to this topic over the years, and will
be more than happy to acknowledge their input if reminded of this :-)</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA81Z23IbxxF9n6+YQA8iUwBEULIuKIc2TOpCmxIZkbLKSeVh
sDsAxtzdWc/sEoJV/JfkL1KVt7jyXzndM7tYEKBLeYtVZQK7Mz19OX26ezAY
DISoTJXpsexdLbQ8vbh5Ks+sLacquZaTNHXae3nh9Mx86gk1nTp9g6Wby5rX
iar03LrVWPoqFSK1SaFySE6dmlWD6zpXzgxMefN0kMWtg4OR8PU0N94bW1Sr
EqtPX169EkWdT7UbixQixyKxhdeFr/1YVq7WAio8FspphdVFpV2hK7G07nru
bF2O5cfX8iO+mWIuX9MTca1XeJ2OhRywhfS30Z4+n9ikznVRqQpaiBtd1DhU
yqDPpigp56Za1NOxXAaDHt1vHRZn0N9XY7moqtKPHz2Km4ZByNDY39n+O6+G
iyrPhFB1tbCOzMJRUpoCDno9lG9qX8EOejSrsywE4bW2s1n3lXVzVZhf2eax
nFy8Oz3m5zpXJhvDzMW3qixMMiTvdk/4OJQ/sE47xLy2dp7pPsKSDLvSlso5
XXwbrSeJorAux64bdvX7V8dPDl+MxvJB8xFhAczkj9oRNOTTBowUiolLFqbS
SVU73RNCmGJ2R9gzkhWEPYuyIlCAVlvZxGa9sPLFi4NmJT7SygkOmRc6lQGE
Pi4cjQ4Po370kVa+17/UxmmCjpdQoUWjfGM9Hg3ksc3zGk5k98gzterIe/78
SSMPH7/cXt59+PjZ47ibPv6Pux9/NWp208cv3z0cDoUYDAZSTX3lVII4Xi2M
l2nMIFmXlLJeVkwm2yI35MnKyhTcUei4Hqmp4rqSSUWOx49ePJUqCGwZZ3MR
VGKdcpOmmRbiAcXB2bROOJ/FadGo0+xTHSX6UsnsrmCYpKQvdWJU1t1Ye52K
6UouOL5QH7yUSpis6IupvM5mQ3kBURrvU4AjqYAkvNtxCBiMUtgSchOVZSsJ
iqHlvAp7SGs6gOJAJz70EuAippPeziokFd5XtHgJPsFeoW+0kyBGmIc9SpaL
lSfZ7T5DCJ2pRA8lB26h2Cg8h8hcE4pzL+1MEG+xDNhnguFsb12W1lUQXdhi
0EjNNY7n9xBtMgMm1bAXBws+cFA6m5DJyUY+kNY4WLFxw/8TKD1A0haoAaSh
Z/NPSK7h76SjlqgnkgqKl723Hy6vev3wV74758/vX/75w+n7lyf0+fLN5Oys
/SDiiss35x/OTtaf1juPz9++ffnuJGzGU7nxSPTeTn7CG9Kqd35xdXr+bnLW
o+BVG65TwSFTHeIN2whWyotU+8SZKb5gz3fHF//+++iJ/Pz5D0Qjo9GL29v4
5fno2RN8WS50EU6zBeAZvsJ9K6HKUitHUgBcmagSMc98n9zrF3ZZyIV2Gt78
41/JM38by6+nSTl6chQfkMEbDxufbTxkn20/2docnLjj0Y5jWm9uPL/j6U19
Jz9tfG/83nn49TcZIW8wev7NkSAI3YWXjsgBLp+0uTg6fDY8oH+PnqNAeuSt
1+6G8n8VQDx5NyEPf/4cylgIiGOEiyRT3g+mivJyF62xxDbcQ3lacRoXKdKo
spSsC4VHFa0TzWkgmNJmJllJvKOHlckZSVE1fjYzkMCggApVa42dSeKdoFgA
Da3ezC+k80FrMy3p+mDmbM57jkmEnAhfgqjkkkxufUOISxIknyroHRgkYL+k
amSI19hdqOVwV2Y80y/81T3oDjHAUVNNXMckF53fsvWsLriONCYZL5pH7ON4
hqKK4dYNAfcDlBttTxBqRhNP6iFub4cBFr3mtF57HEUrEFoK0k0WIV6qkKD5
qUUcZclVBpCwXlNig64DrTbmVc7M5wh3cNCWQZSodZbyCzY5CuTWNVaf+AjO
YYm/1LrmGiEjoZPXosM82sxA5PKdbTYGkHnRpsE9pTCqwuWrot0+1htVrLaK
GJwWXIi26faWCQltqJnD/ixMMPf0Ly1B9ikyNuHyogSty2K92lKtj7oxisUy
LmzTLcggVy4YQ7oQ5QZQEX6MNx6oIERgdjJcwqJzWVW1VpX7jVksjmKPbaTm
jmzkL9SrtV+oSb693Rdim2ukLtS0sYhCsll3+23OpkbNC7w3ScjYrWpdFJqx
gte54jEIiueSTkGBhLsICzfo6W3towMbeHmE6W2dVabM9JZXoWMCLJsiQbPi
A6+Edpt4JDUE5qRCSxIaKYKRoA2oaJykdOyXdxZyAqpySIXYk7TaRALASo4F
nVBql4MVeX0zAWzoBKckNU0z1VrO1fFF11nr4yNiSIs+MtUgjw3rWirHIQpQ
aBlFoXdaNU1WpxJQ2dhKmk7Lsj27h6E8Vh0qJN3EABTnsMetQDGFbZqs7X7p
ecuNYqs4YUxvySwAs4vLmDFOFXBjkx3Ia0eoydA/xPxLGwrX62Nf4b/xwfiA
2rUOMZvQxsPPlf5UUUxUiJvAJFJ4btAkMn1R2MzOV+TaXJXBd2vYATV2I/O0
jyTcdk/6U4lc8LH95pN4ww4QU0eMxV33iWhHMH08PsBL9PXzRfs3Wkj/k3sA
cmhMYV7ciYgwiveblhheRcTKDNUQJBRAJg+HXw0PuSbRp8ekZcf/FLiZhZOX
fizE0VW35Q3HiKPwmJOGCvqubpnAilCFGno/AqOo2BnEl1CIC88dwVME/rov
D8Yb/+QeDhwdPt/vU7k4Qi+JxEAqxpN7dRHZcd3u9CLGGvlNX0kkoZoZvrIQ
hhpS2FRzd2qomqUmaUcLTLKaWomApyhsKM/Rz+lPKif2YkuYeWgyOtqwyvgG
mJe2dpDTpBhURUVjqauAnzKOhcSdlEaqEEc8WCDrf21mPGgPctOkJ6VNhi6b
7MBoKamtbvQjl09QXixOdruQmTqF5bGl6pb/O+HI1QpHiqOm91HsqtDO7Gwq
4swbc68t9O30y1DwuqPKPYHZrO0bgyn2I2ytAB5nUChin7VQN+StM1NcD864
5vjEljo0aMEeSePwfBFYguMsjjrr78E8LZY3xlV1VyG5V63KOKCvk0EctU3b
emlvP9glTa6oHQHBYjC4Dm3Q3MKUwi7DZBTjtyNyIaTYEmC1A/kbHuXAoYc/
YroKGGzBWWwiL/SQTgcIopP0Jg3IbyoVBR/1EsjsRpc5ejcesHkLWl316CRx
dN9RIWQ1jxHU+025u1wql0Y0RgP4YsRBMXEUVXI60YbqEelSdKK1Q9fdChLq
U2cxyKYg2r09viEdy1PCl0a0irbTLa0P1yneMB9EuLA3PWXmVINoGRVUbQY5
TcfraDHjkelrvuMCwAw7iEUNgpvmxcRAkbz2KM3dUlankbZ2MiJhfamzrC99
aDGby1SqmCjhmeI7ndh/thKSjrJUtHXJt2dNzeXpipxAy1AhU26hhYqDBVfj
uMDHOhU7RUldotNoaWC9b7qj7colop7D/f1OJE6Q56l8pVAFHJPhWouU78To
T+iaghIonOFgdp6hUrzewNbBe6Cf4GYaVME06wYEuYkF8HhoTDiUx9SqVQat
mthooLqC6O6sU5S/Go6acZt6q3StD8/anROwsQ3QEq5ayRXoHnw3t+ye04d5
B36FRW/tmBzycD3F93R88bOWia8VhqFkl8nD6FI0mBgMfeU7qtksFV2j4kQ2
pSpI0KS+NJjTYIJczgF7IC81WmJacYz4Is+dirdld0ecpseiuyoSF3KNCkG4
KwVxIr8rSur2lx1TzBzI2tVhhvPxLM7ZBaaHMU1ojx4fAnq5MoWPzSQomOh3
69IVfuX03wtXRN/sExFslCW5TewRmB9/IH5IbfGQvdYw+xLY0XFzSqVxVYX7
Vwzq4R6l92GdrSJiqIc5zDp+PdVU0ywPP72GrBmXdwgd78fjHjFookMUaLjO
UBtTFCcLCm1hJQlXfTmFBjMzr+nF6cO0hQ71F3SxAooTzD660gV1FiGiPDLc
jWY7SzBJYKj1zeU2scJ6pt2aMlT37WW4VhcXtaPk3F7N9010xcN7uqCMjVgX
VU03297u8kTT8M/pxY+dmaiZsoabpnCzuWkPR5HYK6jTHsrtQ7YaXIZZ6OTd
pfwLCoV43+g+ixENW+Nd1xf/O714Opy8v5iE3zP4IgaxmCTXoCb0HXNOHfF5
HOZSnf6pN4PyuncbDAq/BwI54V7HXMf5UgGok0z/jDA4C3FoM1VffucMbDxW
rtQE8z6qfmUL4Ol4gYG+onuCc7CSPNFntpj35WvtKnlitTP07Xucn6/kCVyq
sLLL1X15WWnqfuQbVc/74vVv/5jCLWdosz26tCvt4JrLpQbIafE5KuqV++2f
Kl6xvUX50D/L//wL639dXWOCuTaNXw2Dld3Qp5E8qfmX43jfGGmNi4xtWMqi
d0PAJ51aQQ7hTvZ7uyjkG3BIpkPo+MfoiuFzUaM9ex9QQSPiRx39ynBpnMtZ
bWexPQyufqvctbzMKX35EhBAUi4z4O29w4PR432hZ3heNT+Me1o5uHlqSz8I
1xR3fiQPCB8cPGmuENZlTYL3urQdkc1sxGff2/fzcGHp+o4GcxX8FC86oldB
JKK524GwOo9uXuo7CFMtQHU7ojsD5gmRmKEpL1aCxi6ABL21p0vLQP18I5CY
UrWVhWaHTmSl5TtBSOXaOBQf6Mfeqoa9Olv16aIaM5KnktEOak0eLHiKAbYd
FXBQX27dKtgQzPcV3R2E5owu6yq6S10r19oRWGGNpztKRbeYLBOol7nlK3pF
t4JludrhIEOXVyWI2cyoaMExOm3H5fFgX/wXq1ZFJpghAAA=

-->

</rfc>
