<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-v6ops-rfc3849-update-05" number="9637" consensus="true" category="info" submissionType="IETF" updates="3849" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" prepTime="2024-08-27T14:29:15" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3849-update-05" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9637" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Expanding the IPv6 Documentation Space">Expanding the IPv6 Documentation Space</title>
    <seriesInfo name="RFC" value="9637" stream="IETF"/>
    <author initials="G." surname="Huston" fullname="Geoff Huston">
      <organization showOnFrontPage="true">APNIC</organization>
      <address>
        <email>gih@apnic.net</email>
      </address>
    </author>
    <author initials="N." surname="Buraglio" fullname="Nick Buraglio">
      <organization showOnFrontPage="true">Energy Sciences Network</organization>
      <address>
        <email>buraglio@forwardingplane.net</email>
      </address>
    </author>
    <date month="08" year="2024"/>
    <area>OPS</area>
    <workgroup>v6ops</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">The document describes the reservation of an additional IPv6 address
      prefix for use in documentation. This update to RFC 3849 expands on the
      existing 2001:db8::/32 address block with the reservation of an
      additional, larger prefix.  The addition of a /20 prefix allows
      documented examples to more closely reflect a broader range of
      realistic, current deployment scenarios and more closely aligns with
      contemporary allocation models for large networks.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9637" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2024 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-current-assignment-and-allo">Current Assignment and Allocation Data</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-filtering-and-appropriate-u">Filtering and Appropriate Use</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1"><xref target="RFC3849" format="default" sectionFormat="of" derivedContent="RFC3849"/> introduced 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 indent="0" pn="section-1-2">As the global deployment of IPv6 expands and evolves, individual IPv6
network deployment scenarios have also increased in 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 indent="0" pn="section-1-3">Without this additional address allocation, documentation prefixes
are drawn from address blocks already allocated or assigned to existing
organizations or well-known ISPs, or they are 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 /20 IPv6
address prefix from the Global Unicast Address pool <xref target="RFC4291" format="default" sectionFormat="of" derivedContent="RFC4291"/> for
documentation purposes allows such conflicts to be avoided.</t>
    </section>
    <section anchor="term2119" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-requirements-language">Requirements Language</name>
      <t indent="0" pn="section-2-1">
    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" format="default" sectionFormat="of" derivedContent="RFC2119"/>
        <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
      </t>
    </section>
    <section anchor="current-assignment-and-allocation-data" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-current-assignment-and-allo">Current Assignment and Allocation Data</name>
      <t indent="0" pn="section-3-1">According to the allocation and assignment data published by the Regional
Internet Registries (RIRs) (see
<xref target="NROStatsReport" format="default" sectionFormat="of" derivedContent="NROStatsReport"/>),
in August 2023, 25.9% of the 62,770 recorded IPv6 unicast allocations and
assignments were larger than a /32 in size. The most common allocation or
assignment size was a /29, used in 24.8% of cases.</t>
      <t indent="0" pn="section-3-2">The four largest assignments made to end users have been /19s, but these
allocations were made before the RIRs moved away from the use of a fixed /48
site address prefix in IPv6 address assignment policies, and in the
foreseeable future, it is unlikely that individual networks will require more
than a /20.  It is believed that reservation of a /20 will cover the
documentation needs as they relate to the broad range of realistic network
deployments.</t>
    </section>
    <section anchor="filtering-and-appropriate-use" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-filtering-and-appropriate-u">Filtering and Appropriate Use</name>
      <t indent="0" pn="section-4-1">Documentation prefixes are for the use of relaying configuration and
      documentation examples, and as such, they <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 <xref target="BOGON" format="default" sectionFormat="of" derivedContent="BOGON"/> and filtered in routing
      advertisements as appropriate.</t>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">This special-use prefix should be marked as and considered bogon
      <xref target="BOGON" format="default" sectionFormat="of" derivedContent="BOGON"/>.  As is appropriate with bogon prefixes, packets
      whose source or destination belongs to this prefix should be dropped and
      disallowed over the public Internet.
      </t>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-6-1">IANA has registered the following in the "IANA IPv6 Special-Purpose Address Registry"
      <xref target="IANA-IPv6-SPAR" format="default" sectionFormat="of" derivedContent="IANA-IPv6-SPAR"/>.</t>
      <dl spacing="compact" indent="3" newline="false" pn="section-6-2">
        <dt pn="section-6-2.1">Address Block:</dt>
        <dd pn="section-6-2.2">3fff::/20</dd>
        <dt pn="section-6-2.3">Name:</dt>
        <dd pn="section-6-2.4">Documentation</dd>
        <dt pn="section-6-2.5">RFC:</dt>
        <dd pn="section-6-2.6">RFC 9637</dd>
        <dt pn="section-6-2.7">Allocation Date</dt>
        <dd pn="section-6-2.8">2024-07</dd>
        <dt pn="section-6-2.9">Termination Date:</dt>
        <dd pn="section-6-2.10">N/A</dd>
        <dt pn="section-6-2.11">Source:</dt>
        <dd pn="section-6-2.12">False</dd>
        <dt pn="section-6-2.13">Destination:</dt>
        <dd pn="section-6-2.14">False</dd>
        <dt pn="section-6-2.15">Forwardable:</dt>
        <dd pn="section-6-2.16">False</dd>
        <dt pn="section-6-2.17">Globally Reachable :</dt>
        <dd pn="section-6-2.18">False</dd>
        <dt pn="section-6-2.19">Reserved-by-Protocol:</dt>
        <dd pn="section-6-2.20">False</dd>
      </dl>
    </section>
  </middle>
  <back>
    <references pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references pn="section-7.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="IANA-IPv6-SPAR" target="https://www.iana.org/assignments/iana-ipv6-special-registry" quoteTitle="true" derivedAnchor="IANA-IPv6-SPAR">
          <front>
            <title>IANA IPv6 Special-Purpose Address Registry</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="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 indent="0">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 pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="BOGON" target="https://www.team-cymru.com/post/unravelling-the-mystery-of-bogons-a-senior-stakeholder-and-it-professional-guide" quoteTitle="true" derivedAnchor="BOGON">
          <front>
            <title>Unravelling the Mystery of Bogons: A senior stakeholder and IT professional guide</title>
            <author>
              <organization showOnFrontPage="true">Team Cymru</organization>
            </author>
            <date month="July" year="2023"/>
          </front>
        </reference>
        <reference anchor="NROStatsReport" target="https://ftp.ripe.net/pub/stats/ripencc/nro-stats" quoteTitle="true" derivedAnchor="NROStatsReport">
          <front>
            <title>NRO Stats Reports</title>
            <author>
              <organization showOnFrontPage="true"/>
            </author>
          </front>
        </reference>
        <reference anchor="RFC3849" target="https://www.rfc-editor.org/info/rfc3849" quoteTitle="true" derivedAnchor="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 indent="0">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" target="https://www.rfc-editor.org/info/rfc4291" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to acknowledge the valuable input from <contact fullname="XiPeng       Xiao"/>, <contact fullname="Chris Cummings"/>, <contact fullname="Russ White"/>, <contact fullname="Kevin Myers"/>, <contact fullname="Ed Horley"/>, <contact fullname="Tom Coffeen"/>,
      and <contact fullname="Scott Hogg"/>.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="G." surname="Huston" fullname="Geoff Huston">
        <organization showOnFrontPage="true">APNIC</organization>
        <address>
          <email>gih@apnic.net</email>
        </address>
      </author>
      <author initials="N." surname="Buraglio" fullname="Nick Buraglio">
        <organization showOnFrontPage="true">Energy Sciences Network</organization>
        <address>
          <email>buraglio@forwardingplane.net</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
