<?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-01" 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-01"/>
    <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="November" day="14"/>
    <area>Operations and Management</area>
    <workgroup>V6OPS</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 40?>

<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 47?>

<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="filtering-and-appropriate-use">
      <name>Filtering and appropriate use</name>
      <t>Documentation prefixes are for the use or relaying configuration and documentation examples and as such
<bcp14>MUST NOT</bcp14> be used for actual traffic, <bcp14>MUST NOT</bcp14> be  globally advertised, and <bcp14>SHOULD NOT</bcp14> be used internally for routed production traffic or other connectivity.
Documentation prefixes should be considered bogon and filtered in routing advertisements as appropriate.</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.
The name of the reservation is “Documentation".</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 129?>

<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:
H4sIAD7HU2UAA41Y247cuBF951cwHQQBgr7MtCf2TGOzu+252IN4LukeZ7NY
7AMlUWpiJFJLSt3uNQbIh+Qh35JPyZfkFCmppfGsEb+MmhKLVadOnSp6Mpmw
SlW5XPDLT6XQidIZrzaSX99vX/MLE9eF1JWolNF8XYpYMhFFVm7/788TE2tR
wHxiRVpNlKzSyfa1Kd3EpvGr05OzSV0mopKTozmD1VfM1VGhnIOFal9i3/Xl
wxWLRbXgSqeGqdIueGVrV82Pjs6wSVgpFnx0V0rrz3UcbvEboUUmyZkR22UL
/vfXd/dr9riDPV1Jq2U1uSCHWKkW/KfKxGPujK2sTB2e9gU9/MyCaw5uwVHG
RF1tjF0w7v9Nmr8cjuGTd1P+Hl4Z3S2HuN9Jk6bPXxkLn5b3t9fn3ZIshMoX
PFOb70WpVTyFjy+fdDvlb2srslyZZ2fdqvjxy3f+sEstbbbn61hJHUvHb2W1
M/bx+fFRs/n71NidsJTfMhdaem+YNrYAyFtJGKyuzufHx2f0eL28XRID1vfL
VYCnEjaTyNmmqkq3mM12u91UISdTODMTSG+mKTluRosTVW5fT1wpYyXyiZWZ
cpXdf+XV9NOmKvJwUCDviFwILFw3H9/XtjRO8mWSWOkcXzWbR4wRk4aRUIKb
x5P52TE93q7u1qCyW8kSzHg5rLQqp1aVHp5ZWUczRztmtKTjeKatmYSVnHhU
+YVE5jLDzyS8GkSBM7k/lIdT4etkMuEiguMiRgYeUGtJU2Y8kS62KkI2qQQR
pLTbUHsmRRVwkSSKfoo8ICMaJEqwW31iwIDXAEjpzqTfPeUPL5jjs/lRs5OL
PDc71+2SCZOfRFHm5InBzjSXcYUtkTUikZZboTNJVlCrOZKgYh7X1oYYytzs
yQpzsdTCKuOmIepCJUkuGfs91aw1SR2TM4x9/twk7OkJvoc3MuHQg+NFEp0u
FrNX83ELTitQFCgc6LSqwYI1EfnNF2/DZi4gIg0AMNx88lW4WBAfkUv/XbVR
boDgTjTQkK/ei1w9ylxtjEnIr9joNFcEmk4Y/aid37aRGpvAHorjgDfv4x0g
xKLbu0oWBN8yUCLLTYTkHzCmo3z40qt30Eq5NflWQvcU9HyrkrrhC9NBI/r7
uxzxjdhKEMEZbIuRVwcHELRTv0pvFaakdaraj31McMdK+oCA/aVW1ouzB2uA
Zp9AHsWD9c4iI/suNqg7T1VjVaaI5cMs9vH3hsDFX2pUXgAt1A4rhN5/lZe8
z8sfFFpA3bjWq6+2tKgyYn/k+Flcw+KTjhoXNcWd5qk1Rfc+goFHMgSfkn1r
EOEDqSCceEYA8hM5rDMGRRVa/do0PyKf4TuZ5/xRGxi/Xt8jtQTz4SziRhNo
vue17g5hnZfG5FO+ruON53xLT8d3AKA7m8ymdVVb2QucfGA9ie8419p2NBj8
hsiktSWmeLHxHBzCdnD/XaD2R3RK4apO5Mlv7gWCZBwCAYKxYSLK0BcA8dYo
lICjILsAp6Q35w0Jll0UntLLLkZ+ISqBMotjY8MMZLxXBxT8hgMKHIOEwNER
aLZBAqO9/556EvGHtVNJ26UU6hFCN+xBT09jtC6+rDNMEyD7/BWGlkLy+Z+n
Z3/w+CHrr+fjN2+OgCy5hpM89HUDUz9LVJX9NBEfc+pvJF/UPTgVEc6jkg7p
KgxsxKYoKL5DqIN8BwXwhT6bn42JPglZmZ9MT72TcEQSzGQwNbUNh5JzPWcK
1KpnOVCEBdvoTSShh7PjMzA68lUI/rB+UDtSGb85kkh9kNrV9cr98YUSBVuQ
c0CNwLZE/p3YHxjWdAxwEuWa8NnJKUKDeDxj5IDahxBYa9vLHwFQ+XiJ8VJE
1CdC4ShEW2vfDYgTourJcKvArtVMOOpjCumZH035dUVYR2glknqVNyBebN5s
Z+o8Qfq2PsPymT5pKakf+MaxDz0noOebeNfC2UEqv2wPoXquVA4yU1X4GihL
a0qryBwgZWx4S2jl0NMvtM4Geuud2JMdqk6V1fZQWUPfu24Yis6XNLv5uH7g
t3cPACeQkKxjiKL2hmkqTRWG/v5HTbtEGkQCjCqFTSF76/d3Hz9cDIwpX7D+
a7Jr0RT8qNCOKe0RFIfxkoYgNLoaUlvtp7+Fgtv4JEVecp3C8ERiYbIm7NRD
GwqKjvQgt842Zez6kCMhpGdGb/Gyux1d4DTtW5cLdfiIlCOXIMCIEBmNw1+K
mJ5Xl3/7eL26vKDn9fvlhw/dA2u+CAgdng47z+9ubi5vL8JmQnCwxEY3yx9H
AeXR3f3D9d3t8sMolIs6TJieHZCDSAbggRfBLRxr+7iH5O35/X/+fXyCBvC7
5naCDhB+nB6/OcEPGqjCaUYjdeEnMZ4BNCksWSEVjUWpKkw3Y0+nDTVSGmAA
559+ImR+XvBvorg8Pvm2WaCAB4stZoNFj9mXK19sDiC+sPTCMR2ag/VnSA/9
Xf44+N3i3lv85rtcacknx6fffesptJYYGMBc4pLnpWjo09e//pBKyePaVM2g
iCErgYBhqlMF+j8mUd1dxek+ZtGeLEqHJNE1Z3k18Re7Lw6lRdWM1NToXroB
Pby9wCCIQaIR3+6KiMbav7E+PYXutkYziuUY1UHDTTPEXYV7MCn2mL1rBWIl
RbzxKk5UWjU3hUm0n9xbU5kYQ0iqZJ70C7rryGDtFagVemoYirXhD9IWzak0
XfTuEQATV15fp3TNb68xz8bb//7zXwNNGTW3qEjEj4TjMqZ5MJdJ5rPDPi90
XUQkJn8ZpeTO6MkfEf6TA53U+019iVAW3e7QFLYir338SpdoxL5p/oNuvRn+
CDPm5xsLp87rAkFlKKNVjfb4wwYNdMz/KrdIyc0ebX3MLxP+3thc4p7wACPn
Jk1lW6Pr2FQVXmcZ+x9gfsMcqRIAAA==

-->

</rfc>
