<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3513 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3513.xml">
<!ENTITY RFC3701 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3701.xml">
<!ENTITY RFC3879 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3879.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC6724 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6724.xml">
<!ENTITY RFC6890 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6890.xml">
<!ENTITY RFC8200 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8200.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-horley-v6ops-expand-doc" ipr="trust200902">

<!-- ***** FRONT MATTER ***** -->

<front>

<title>Reserving Additional IPv6 Address Prefixes for Use in Documentation</title>

<author initials='E.' surname='Horley' fullname='Ed Horley'>
<organization>HexaBuild</organization>
<address>
<email>ed@hexabuild.io</email>
</address>
</author>

<author initials='T.' surname='Coffeen' fullname='Tom Coffeen'>
<organization>HexaBuild</organization>
<address>
<email>tom@hexabuild.io</email>
</address>
</author>

<author initials='S.' surname='Hogg' fullname='Scott Hogg'>
<organization>HexaBuild</organization>
<address>
<email>scott@hexabuild.io</email>
</address>
</author>

<author initials='N.' surname='Buraglio' fullname='Nick Buraglio'>
<organization>Energy Sciences Network</organization>
<address>
<email>buraglio@es.net</email>
</address>
</author>

<author initials='C.' surname='Cummings' fullname='Chris Cummings'>
<organization>Energy Sciences Network</organization>
<address>
<email>chriscummings@es.net</email>
</address>
</author>

<author initials='K.' surname='Myers' fullname='Kevin Myers'>
<organization>IP ArchiTechs</organization>
<address>
<email>kevin.myers@iparchitechs.com</email>
</address>
</author>

<author initials='R.' surname='White' fullname='Russ White'>
<organization>Juniper Networks</organization>
<address>
<email>russ@riw.us</email>
</address>
</author>

<date/>

<abstract>
<t>To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, the IPv6 unicast address prefix 2001:db8::/32 is reserved for use in examples in documentation including RFCs, books, articles, vendor manuals, etc.  This document proposes the reservation of additional IPv6 prefixes for this purpose; specifically, 3ffe::/16 (formerly 6bone) and fec0::/10 (formerly site-local).</t>
</abstract>

</front>

<middle>

<section title="Introduction" toc="default">

<t>The address architecture for IPv6 <xref target="RFC4291" /> does not specifically allocate any IPv6 address prefixes for documentation purposes. The current IPv6 documentation prefix of 2001:db8::/32 defined in <xref target="RFC6890" /> is not large enough for many design and documentation requirements. No additional documentation prefix(es) were allocated in the most recent IPv6 Specification <xref target="RFC8200" />.</t>

<t>These are example use cases that require a documentation IPv6 prefix larger than a /32:
    <list style="symbols">
        <t>Ability to document network architectures (including addressing plans) larger than a /32 (Service Providers, Enterprise, Government, IoT, Energy),</t>
        <t>Ability to document mergers and acquisitions designs for large networks (multiple /32 prefix space or larger, plus networks with multiple ASNs),</t>
        <t>Reduction of operational impacts by having sufficiently large IPv6 prefixes dedicated for documenting and sharing designs and best practices,</t>
        <t>Ability to depict unique IPv6 prefix identification (simple visual representation to identify separate networks)</t>
    </list>
</t>

<t>The following existing criteria are beneficially extended to the additional documentation prefixes:
    <list style="symbols">
        <t>Filters are already commonly in use to block the existing documentation prefix from the Internet.</t>
        <t>There are no operational impacts to IANA or the RIRs with documentation prefix space.</t>
    </list>
</t>

</section> <!-- end of introduction -->

<section title="Requirements Language" toc="default">

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to are to be interpreted as described in BCP 14 <xref target="RFC2119" /> when, and only when, they appear in all capitals, as shown here.</t>

</section> <!-- end of Requirements Language -->

<section title="Documentation IPv6 Address Prefixes" toc="default">

<t>The additional IPv6 address prefixes allocated for documentation purposes are 3ffe::/16 (formerly 6bone - <xref target="RFC3701" />) and fec0::/10 (formerly site-local - <xref target="RFC3879" />), resulting in the following prefixes for use in documentation:
    <list style="symbols">
        <t>fec0::/10</t>
        <t>3ffe::/16</t>
        <t>2001:db8::/32 - existing as defined in <xref target="RFC3879" /></t>
    </list>
</t>
</section> <!-- end of expanded documentation -->

<section title="Operational Implications" toc="default">

<t>The addition of IPv6 address prefixes for documentation implies that IPv6 network operators should add these address prefixes to their lists of non-routable/bogon IPv6 address space. If packet filters are deployed in live networks, these address prefixes should be added to those filters intended to prevent any public routing of such address space.</t>

<t>Because the 3ffe::/16 address prefix was previously used for the subsequently decommissioned 6bone network, this address prefix is included in many existing non-routable prefix filters and lists. Its precedence value per <xref target="RFC6724" /> is 1, which limits its usability in production networks. In addition, the 3ffe::/16 address prefix was returned to IANA and is available to be reserved for documentation purposes.</t>
    
<t>Similarly the fec0::/10 address prefix was previously used for site-local addressing, and thus is already included in many non-routable prefix filters and lists. Its precedence value per <xref target="RFC6724" /> is 1, which limits its usability in production networks.  In addition, the fec0::/10 address prefix was returned to IANA and is available to be reserved for documentation purposes.</t>

<t>As a documentation prefix, the former site-local scope of fec0::/10 is considered deprecated and filters may be required and used with any scope.</t>

</section> <!-- end of operational implications -->

<section title="IANA Considerations" toc="default">

<t>These documentation prefixes have limited impact on IANA and no impact on any RIRs.</t>

<t>IANA is to record the allocation of the IPv6 global unicast address prefix 3ffe::/16 and fec0::/10 as documentation-only prefixes in the IPv6 address registry.  No end-user or service provider/LIR is to be assigned these addresses.</t>

</section> <!-- end of iana considerations -->

<section title="Security Considerations" toc="default">

<t>IPv6 addressing documentation has no direct impact on Internet security.</t>

<t>However, the assignment of a new address space for documentation purposes does mean, as indicated above, that these addresses SHOULD be added to any filters required by individual operators to prevent their use for globally routed destinations.</t>

</section> <!-- end of security considerations -->

<section title="Acknowledgements" toc="default">

<t>The authors acknowledge the work of Geoff Huston, assisted by Anne Lord, and Philip Smith, in authoring the previous proposal for the IPv6 documentation prefix.</t>

</section> <!-- end of acknowledgements -->

</middle>

<back>

<references title="Normative References">

&RFC2119;
&RFC3701;
&RFC3879;
&RFC8200;

</references> <!-- end of normative references -->

<references title="Informative References">
&RFC3513;
&RFC4291;
&RFC6724;
&RFC6890;

</references> <!-- end of informative references -->

</back>

</rfc>
