<?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.6.39 (Ruby 2.6.10) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-v6ops-rfc3849-update-00" category="info" submissionType="IETF" updates="3849" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.5 -->
  <front>
    <title abbrev="Expanding the IPv6 Documentation Space">Expanding the IPv6 Documentation Space</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-v6ops-rfc3849-update-00"/>
    <author initials="G." surname="Huston" fullname="Geoff Huston">
      <organization>APNIC</organization>
      <address>
        <email>gih@apnic.net</email>
      </address>
    </author>
    <author initials="N." surname="Buraglio" fullname="Nick Buraglio">
      <organization>Energy Sciences Network</organization>
      <address>
        <email>buraglio@forwardingplane.net</email>
      </address>
    </author>
    <date year="2023" month="October" day="20"/>
    <area>Operations and Management</area>
    <workgroup>V6OPS</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 39?>

<t>The document describes the reservation of an additional IPv6 address prefix
for use in documentation. The reservation of a /20 prefix allows documented
examples to reflect a broader range of realistic current deployment
scenarios.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    IPv6 Operations Working Group mailing list (v6ops@ietf.org),
    which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/v6ops/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/buraglio/draft-ghnb-v6ops-rfc3849-update"/>.</t>
    </note>
  </front>
  <middle>
    <?line 46?>

<section anchor="introduction">
      <name>Introduction</name>
      <t><xref target="RFC3849"/> introduced 2001:db8::/32, describing the use of the IPv6 address
prefix 2001:DB8::/32 as a reserved prefix for use in documentation. The
rationale for this reservation was to reduce the likelihood of conflict and
confusion when relating documented examples to deployed systems.</t>
      <t>As the global deployment of IPv6 expands and evolves, individual IPv6
network deployment scenarios have also increased is size and diversity, and
there is a requirement for documentation to reflect this increased diversity
and scope. The original 2001:DB8::/32 reservation is inadequate to describe
many realistic current deployment scenarios.</t>
      <t>Without this additional address allocation, documentation address prefixes
are drawn from address blocks already allocated or assigned to existing
organizations or to well known ISPs, or drawn from the currently unallocated
address pool. Such use conflicts with existing or future allocations or
assignments of IPv6 address space. The reservation of a further /20 IPv6
address prefix from the Global Unicast Address pool <xref target="RFC4291"/> for
documentation purposes avoids such conflicts.</t>
    </section>
    <section anchor="current-assignment-and-allocation-data">
      <name>Current Assignment and Allocation Data</name>
      <t>According to the allocation and assignment data published by the Regional
Internet Registries,
<xref target="NROStatsReport"/>,
in August 2023 some 25.9% of all 62,770 recorded IPv6 unicast allocations and
assignments are larger than a /32 in size. The most common allocation or
assignment size is a /29, used in 24.8% of cases.</t>
      <t>The four largest assignments made to end users have been /19s, but these
allocations were made before the RIRs' address allocation policies moved
away from the use of a fixed /48 site address prefix IPv6 address assignment
policies, and in the foreseeable future its unlikely that individual
networks require more than a /20. It is believed that a reservation of a /20
would cover the documentation needs as they relate the broad range of
realistic network deployments.</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="security-considerations">
      <name>Security Considerations</name>
      <t>IPv6 addressing documents do not have any direct impact on Internet
infrastructure security.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is to record the reservation of TBD::/20 in the IANA IPv6
<xref target="IANAIPv6SPAR"/>. The Source, Destination, Forwardable,
Globally Reachable and Reserved-by-Protocol fields should be recorded as
False. There is no Termination Date for this entry.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <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="IANAIPv6SPAR" target="https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml">
          <front>
            <title>IANA IPv6 Special-Purpose Address Registry</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </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>
        <name>Informative References</name>
        <reference anchor="RFC3849">
          <front>
            <title>IPv6 Address Prefix Reserved for Documentation</title>
            <author fullname="G. Huston" initials="G." surname="Huston"/>
            <author fullname="A. Lord" initials="A." surname="Lord"/>
            <author fullname="P. Smith" initials="P." surname="Smith"/>
            <date month="July" year="2004"/>
            <abstract>
              <t>To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3849"/>
          <seriesInfo name="DOI" value="10.17487/RFC3849"/>
        </reference>
        <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="NROStatsReport" target="https://ftp.ripe.net/pub/stats/ripencc/nro-stats/latest/nro-delegated-stats">
          <front>
            <title>NRO Stats Report</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
      </references>
    </references>
    <?line 120?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>The authors would like to acknowledge the valuable input from Xipeng Xiao, Chris Cummings, Russ White, Kevin Myers, Ed Horley, Tom Coffeen, and Scott Hogg</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAESZMmUAA41X7W7juBX9z6dgvSgKFJadeNJMYuyXJ87MBJ18rJ3pdrHo
D0qiZSISqSUpO95B3qXPsk+255KybCfpoP5jiRLvx7nnnkslScK88qUc88vH
Wuhc6YL7peRXd6tTPjVZU0nthVdG83ktMslEmlq5+r9fz02mRQXzuRULnyjp
F8nq1NQusYvszdnJedLUufAyOTpisPqGuSatlHOw4Dc19l1d3r9nmfBjrvTC
MFXbMfe2cX50dHR+NGLCSjHmvdta2uDXcYTFr4UWhaRgemxdjPm/Tm/v5uxh
DXvaS6ulT6YUEIveHTwjFsZE45fGjhkPv6T95/CNVz4M+Ec4Nrpbjql9kGax
eP7IWLid3N1cXXRLshKqHPNCLX8UtVbZAGG87ulmwN81VhSlMs983ajs4eWz
4OxSS1ts+DxTUmfS8Rvp18Y+PHeftpt/XBi7FpZKWJdCyxAN08ZWwHElCYPZ
+4vR8fE5XV5NbiZU5PndZBbh8cIWEmVZel+78XC4Xq8HCrAPEMxQoIKFJvzd
kBYTVa9OE1fLTIkysbJQztvNVx4NHpe+KqOjyM8ehRCJNm9fvmtsbZzkkzy3
0jk+azf3GCOyHGZCBW4vT0bnx3R5M7udg61uJmtj/etpLXw9sKoO8AzrJh06
2jGkJZ1lQ21NEldK4pEPC7ksZYHbPD46yAI+eXDKo1fEmiQJFykCFxkqcI92
yttO4rl0mVUpqkldhiSlXcX2MgsQnYs8V3QryoiMaJGorVyoRwYMeAOAlO5M
ht0Dfv+KOT4cHbU7uShLs3bdLpkz+SiquqRIDHYuSpl5bEmtEbm03ApdSLKC
dixRBJXxrLE25lCXZkNWmMukFlYZN4hZVyrPS8nYN9SW1uRNRsEw9uVLW7Cn
J8Qen8ico+WPx3l6Nh4P34z6W3C2GkSJIoBOjlosWJtR2Dx9FzdzAZ1oAYDh
9pWvwsWivohShvf8UrkDBNeihYZiDVGU6kGWamlMTnFlRi9KRaDpnNFN48K2
pdTYBPZQHju8+T7eEUIsuo3zsiL4JpESRWlSFH+HMbkK6csg0FEO5cqUK+n6
yCxXK5U3LV+Yjhqxv7+rEV+KlQQRnMG2DHV1CABJO/W7DFZhSlqn/KYfckI4
VtILBOxvjbJBfwNYB2juEyiguLPeWWRk32UGfReoaqwqFLH8sIr7+AdD4OJv
DTovghZ7h1VCb77KS77Py58VRkDThrbXX9vWos7Igsv+s7wOm086mk0099aa
L6ypuucpDDyQIcSUb7YGkT6QisKJayQgHylgXTAoqtDq93a+EfkMX8uy5A/a
wPjV/A6lJZh3vogbbaLlhje6c8K6KI0pB3zeZMvA+S09HV8DgM43mV00vrFy
L3GKge1JfMe5rW1Hs/9/iMyiscSUIDaBg4ew7cL/EKn9GZNSON+JPMXNg0CQ
jEMgQDB2WIg6zgVAvDIKLeAoyS7BAenNRUuCSZdFoPSky5FPhRdosywzNh5z
TIhqh0LYsEOB4yAh4DoFzZYoYLoJ79NMIv6w7cFjO6UU+hFCdziDnp76GF18
0hQ4TYDsozfcmUry0T8G538N+KHqp6P+27dHQJZCg6cAfdPCtF8l6sr9MhEf
S5pvJF80PTg1EfxRS8dyVQY2MlNVlN8u1YN6RwUIjT4cnfeJPjlZGZ0MzkKQ
CEQSzGRwYRobnVJwe8FU6NXAcqAIC7bVm1RCD4fH52B0GroQ/GH7Sa1JZcLm
VKL0UWpnVzP3t1daFGxBzQE1ElsR+ddis2NYOzHASbRrzocnZ0gN4vGMkQfU
3qXAtraD/BEAPuRLjJcipTkRG0ch20aHaUCcEH5PhrcK7LaaiUBDTrE8o6MB
v/KEdYpRImlWBQPi1eHN1qYpc5RvFSosn+mTlpLmQRgcmzhzInphiHcjnO2k
8uV4aLvH6BVuuuP2FDjpIJQuVv0BDrAT7nrXn+f3vX785ze34Xp2+dPnq9nl
lK7nHyefPnUXrH1j/vH286fp7mq38+L2+vryZho3Y5UfLLHe9eSXXqxI7/bu
/ur2ZvKpF4ujdueZ0AogX0rDHn2JSpMAC8e2UyMU9N3F3R//PT6B3PylPQtD
b+LN2fHbE9zQ+I7ejEZ14y3hy0RdS2HJCvVsJmrlMUv7hL9bkmzTuASaf/+V
kPnPmH+bZvXxyfftAiV8sLjF7GAxYPZy5cXmCOIrS6+46dA8WH+G9GG8k18O
7re47y1++0OptOTJ8dkP3zOi0FxiPGHSE5ecyrdfb4ztd9v+kYiKx7Xx7bEE
Iz1Hu+AMoSpMG5x7dPdtR6d/CzG0OE9SA7rWV+Bu+Ix44ZQWVXuAI1l97bx9
/26KYwfGVtvq3QcJZHz/++jpKWrpHNKXyT66g0Zpe2R4H7+6SB/6LI448GYm
RbYMmkFUmrXn0iTdJHfWeJNh5C2ULPPAHerxVO70H6x9D2pFBY9HMG34vbRV
65Vm2d6pFWDaTXsCT0X2QKhMMjpLlDIvAtbsy1g3VQpr+Xe9BRnvPYXGjh/I
UOEQBWkaYSa63VFQVqJsQjZK1xDxILj/pi+mAn/C9PnF0iKQi6ZCiAWaYtZA
Wn9eQnz7/J9yBYCvNxgJfX6Z84/GlhJnzHsYucCXttx23Dwz3uNxUbA/ASWk
ljPIEAAA

-->

</rfc>
