<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" ipr="trust200902" updates="7084" obsoletes="" docName="draft-ietf-v6ops-cpe-lan-pd-09" number="9818" consensus="true" xml:lang="en" submissionType="IETF" tocInclude="true" sortRefs="false" symRefs="true" prepTime="2025-07-28T14:30:44" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-lan-pd-09" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9818" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="DHCPv6 PD on IPv6 CE Routers in LANs">DHCPv6 Prefix Delegation on IPv6 Customer Edge (CE) Routers in LANs</title>
    <seriesInfo name="RFC" value="9818" stream="IETF"/>
    <author fullname="Timothy Winters" initials="T." surname="Winters">
      <organization abbrev="QA Cafe" showOnFrontPage="true">QA Cafe</organization>
      <address>
        <postal>
          <street>100 Main Street, Suite #212</street>
          <city>Dover</city>
          <region>NH</region>
          <code>03820</code>
          <country>United States of America</country>
        </postal>
        <email>tim@qacafe.com</email>
      </address>
    </author>
    <date month="07" year="2025"/>
    <area>OPS</area>
    <workgroup>v6ops</workgroup>
    <keyword>IPv6</keyword>
    <keyword>Internet Protocol Version 6</keyword>
    <keyword>DHCPv6</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document defines requirements for IPv6 Customer Edge (CE) routers to 
    support DHCPv6 Prefix Delegation for distributing available prefixes to LAN devices that were 
    delegated to an IPv6 CE router.  This document updates RFC 7084.</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/rfc9818" 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) 2025 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-terminology">Terminology</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-ipv6-end-user-network-archi">IPv6 End-User Network Architecture</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-requirements">Requirements</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-lan-prefix-delegation-requi">LAN Prefix Delegation Requirements (LPD)</xref></t>
              </li>
            </ul>
          </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-security-considerations">Security 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-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <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.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </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.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">This document describes guidelines for DHCPv6 Prefix Delegation in IPv6 Customer Edge (CE) 
    routers <xref target="RFC7084" format="default" sectionFormat="of" derivedContent="RFC7084"/> in order to properly utilize the IPv6 prefixes delegated by 
    service providers. Many service providers assign larger address blocks than /64 to CE routers, 
    as recommended in <xref target="RFC6177" format="default" sectionFormat="of" derivedContent="RFC6177"/>. If an IPv6 CE router does not support the 
    Identity Association for Prefix Delegation (IA_PD) Prefix Option 
    (<xref target="RFC8415" section="21.21" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8415#section-21.21" derivedContent="RFC8415"/>) on the LAN, it will not be able to assign any prefixes beyond its local 
    interfaces, limiting the usefulness of assigning prefixes larger than /64 by the operator.  Supporting 
    IA_PD on the LAN interfaces of a CE router will allow those unused prefixes to be distributed 
    into a network.  Note that efforts such as those of the Stub Networking Auto Configuration 
    (SNAC) Working Group depend on IPv6 prefixes being properly distributed in the LAN.</t>
      <t indent="0" pn="section-1-2">Two models, hierarchical prefix and flat, were proposed in the past for prefix sub-delegation beyond 
    an IPv6 CE router. 
    
    Hierarchical prefix delegation requires an IPv6 CE router to sub-delegate IPv6 prefixes 
    based on a set of rules. If more than one router uses hierarchical prefix delegation, an IPv6 prefix tree is created.  
    When no routing protocol is enabled to discover the network topology, it is possible to have an unbalanced 
    prefix delegation tree, which leads to running out of prefixes.  More information on hierarchical prefix 
    delegation can be found, e.g., in Section 8.5 of CableLabs IPv6 eRouter specification <xref target="eRouter" format="default" sectionFormat="of" derivedContent="eRouter"/>. 

    A flat prefix delegation requires the router to be provisioned with the initial prefix and to assign /64 prefixes 
    to all other prefix requests from routers in the LAN-facing interface. 

The default configuration of CE routers is designed to be a flat model to support zero-configuration networking.</t>
      <t indent="0" pn="section-1-3">This document does not cover dealing with multi-prefix networks with more than one provider. 
    Due to the complexity of a solution that would require routing, provisioning, and policy, this is out of scope of this document.</t>
    </section>
    <section anchor="Requirements_Language" 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>
      <t indent="0" pn="section-2-2">This document uses these keywords not strictly for the purpose of interoperability, 
      but rather for the purpose of establishing industry-common baseline functionality.  As
      such, the document points to several other specifications to provide additional guidance to implementers
      regarding any protocol implementation required to produce a
      successful CE router that interoperates successfully with a
      particular subset of currently deployed and planned common IPv6
      access networks.</t>
    </section>
    <section anchor="Terminology" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-3-1">The document makes use of the following terms, some of which are from <xref target="RFC8200" section="2" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8200#section-2" derivedContent="RFC8200"/>.
      </t>
      <dl spacing="normal" newline="false" indent="3" pn="section-3-2">
        <dt pn="section-3-2.1">IPv6 node:</dt>
        <dd pn="section-3-2.2">A device that implements IPv6.</dd>
        <dt pn="section-3-2.3">IPv6 router:</dt>
        <dd pn="section-3-2.4">An IPv6 node that forwards IPv6 packets not explicitly addressed to itself.</dd>
        <dt pn="section-3-2.5">IPv6 host:</dt>
        <dd pn="section-3-2.6">An IPv6 node that is not a router.</dd>
        <dt pn="section-3-2.7">ULA:</dt>
        <dd pn="section-3-2.8">Unique Local Address, as defined in <xref target="RFC4193" format="default" sectionFormat="of" derivedContent="RFC4193"/>.</dd>
        <dt pn="section-3-2.9">GUA:</dt>
        <dd pn="section-3-2.10">Global Unicast Address, as defined in <xref target="RFC4291" format="default" sectionFormat="of" derivedContent="RFC4291"/>.</dd>
      </dl>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-ipv6-end-user-network-archi">IPv6 End-User Network Architecture</name>
      <t indent="0" pn="section-4-1">The end-user network for IPv6 contains stub networks. <xref target="fig-1" format="default" sectionFormat="of" derivedContent="Figure 1"/> illustrates the model topology.</t>
      <figure anchor="fig-1" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-example-ipv6-end-user-topol">Example IPv6 End-User Topology</name>
        <artwork align="center" pn="section-4-2.1">
     +-----------+
     |  Service  |
     |  Provider |
     |   Router  |
     +-----+-----+
           |
           |
           |  Customer
           |  Internet Connection
           |
     +-----v-----+
     |   IPv6    |
     |    CE     |
     |  Router   |
     +-----+-----+
           |
    +------+-------+
    |              |
    |              |
+---+----+   +-----+-----+
|  IPv6  |   |           |
|  Host  |   |   Router  |
|        |   |           |
+--------+   +-----+-----+
                   |
                   |
               +---+----+
               |  IPv6  |
               |  Host  |
               |        |
               +--------+</artwork>
      </figure>
    </section>
    <section anchor="Requirements" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-requirements">Requirements</name>
      <t indent="0" pn="section-5-1"> IPv6 CE routers distribute configuration information obtained during WAN interface
    provisioning to LAN-facing IPv6 hosts and routers.  A CE router that is compliant with <xref target="RFC7084" format="default" sectionFormat="of" derivedContent="RFC7084"/> 
    would only provide IPv6 hosts with configuration information. This document allows for addressing and routing of IPv6 
    prefixes to both hosts and routers. These requirements are in addition to the ones in 
    <xref target="RFC7084" section="4.3" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7084#section-4.3" derivedContent="RFC7084"/>.</t>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-lan-prefix-delegation-requi">LAN Prefix Delegation Requirements (LPD)</name>
        <ol spacing="normal" type="LPD-%d:" indent="9" start="1" pn="section-5.1-1"><li pn="section-5.1-1.1" derivedCounter="LPD-1:">
            <t indent="0" pn="section-5.1-1.1.1">Each IPv6 CE router <bcp14>MUST</bcp14> support IPv6 prefix assignment according to <xref target="RFC8415" section="13.3" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8415#section-13.3" derivedContent="RFC8415"/> 
           (Identity Association for Prefix Delegation (IA_PD) option) on its LAN interface(s).</t>
          </li>
          <li pn="section-5.1-1.2" derivedCounter="LPD-2:">
            <t indent="0" pn="section-5.1-1.2.1">Each IPv6 CE routers <bcp14>MUST</bcp14> assign a prefix from the delegated prefix as specified by L-2 in 
           <xref target="RFC7084" section="4.3" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7084#section-4.3" derivedContent="RFC7084"/>. 
           If insufficient prefixes are available, the IPv6 CE router <bcp14>MUST</bcp14> log a system management error.</t>
          </li>
          <li pn="section-5.1-1.3" derivedCounter="LPD-3:">
            <t indent="0" pn="section-5.1-1.3.1">The prefix assigned to a link <bcp14>MUST NOT</bcp14> change in the absence of a local policy or a 
           topology change.</t>
          </li>
          <li pn="section-5.1-1.4" derivedCounter="LPD-4:">
            <t indent="0" pn="section-5.1-1.4.1">After LAN link prefix assignments, the IPv6 CE router <bcp14>MUST</bcp14> keep the remaining IPv6 prefixes
           available to other routers via Prefix Delegation.</t>
          </li>
          <li pn="section-5.1-1.5" derivedCounter="LPD-5:">
            <t indent="0" pn="section-5.1-1.5.1">IPv6 CE routers <bcp14>MUST</bcp14> maintain a local routing table that is dynamically updated with leases 
           and the associated next hops as they are delegated to clients. Absent explicit filtering, packets with destination addresses in a delegated 
           prefix <bcp14>MUST</bcp14> be forwarded to that prefix regardless of which interface they are received on. When a delegated prefix is released 
           or expires, the associated route <bcp14>MUST</bcp14> be removed from the IPv6 CE router's routing table. A delegated 
           prefix expires when the valid lifetime assigned in the IA_PD expires without being renewed. When a prefix
           is released or expires, it <bcp14>MUST</bcp14> be returned the pool of available prefixes.</t>
          </li>
          <li pn="section-5.1-1.6" derivedCounter="LPD-6:">
            <t indent="0" pn="section-5.1-1.6.1">By default, the IPv6 CE router filtering rules <bcp14>MUST</bcp14> allow forwarding of packets with an outer 
           IPv6 header containing a source address belonging to delegated prefixes, along with reciprocal 
           packets from the same flow, following the recommendations of <xref target="RFC6092" format="default" sectionFormat="of" derivedContent="RFC6092"/>. This updates WPD-5 of 
           <xref target="RFC7084" format="default" sectionFormat="of" derivedContent="RFC7084"/> to not drop packets from prefixes that have been delegated. IPv6 CE routers
           <bcp14>MUST</bcp14> continue to drop packets, including destination address, that are not assigned to the LAN or delegated.</t>
          </li>
          <li pn="section-5.1-1.7" derivedCounter="LPD-7:">
            <t indent="0" pn="section-5.1-1.7.1">The IPv6 CE routers <bcp14>MUST</bcp14> provision IA_PD prefixes with a prefix-length of 64 on the LAN-facing interface 
           unless configured to use a different prefix-length by the CE router administrator. The prefix-length
           of 64 is used as that is the current prefix-length supported by SLAAC <xref target="RFC4862" format="default" sectionFormat="of" derivedContent="RFC4862"/>. For hierarchical 
           prefix delegation, a prefix-length shorter than 64 may be configured.</t>
          </li>
          <li pn="section-5.1-1.8" derivedCounter="LPD-8:">
            <t indent="0" pn="section-5.1-1.8.1">IPv6 CE routers configured to generate a ULA prefix as defined in ULA-1 of <xref target="RFC7084" section="4.3" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7084#section-4.3" derivedContent="RFC7084"/>
              <bcp14>MUST</bcp14> continue to provision available GUA IPv6 prefixes.</t>
          </li>
          <li pn="section-5.1-1.9" derivedCounter="LPD-9:">
            <t indent="0" pn="section-5.1-1.9.1">If an IPv6 CE router is provisioning both a ULA and GUA via prefix delegation, the GUA <bcp14>SHOULD</bcp14> appear first in the DHCPv6 packets.</t>
          </li>
          <li pn="section-5.1-1.10" derivedCounter="LPD-10:">
            <t indent="0" pn="section-5.1-1.10.1">IPv6 CE routers <bcp14>MUST NOT</bcp14> delegate prefixes via DHCPv6 on the LAN using lifetimes that
           exceed the remaining lifetimes of the corresponding prefixes learned on the WAN.</t>
          </li>
        </ol>
      </section>
    </section>
    <section anchor="Security" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">This document does not add any new security considerations beyond those mentioned in 
        <xref target="RFC8213" section="4" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8213#section-4" derivedContent="RFC8213"/>, <xref target="RFC8415" section="22" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8415#section-22" derivedContent="RFC8415"/>, and <xref target="RFC6092" section="6" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc6092#section-6" derivedContent="RFC6092"/>.</t>
    </section>
    <section anchor="IANA" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-7-1"> This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <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="RFC4193" target="https://www.rfc-editor.org/info/rfc4193" quoteTitle="true" derivedAnchor="RFC4193">
          <front>
            <title>Unique Local IPv6 Unicast Addresses</title>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <author fullname="B. Haberman" initials="B." surname="Haberman"/>
            <date month="October" year="2005"/>
            <abstract>
              <t indent="0">This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4193"/>
          <seriesInfo name="DOI" value="10.17487/RFC4193"/>
        </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>
        <reference anchor="RFC7084" target="https://www.rfc-editor.org/info/rfc7084" quoteTitle="true" derivedAnchor="RFC7084">
          <front>
            <title>Basic Requirements for IPv6 Customer Edge Routers</title>
            <author fullname="H. Singh" initials="H." surname="Singh"/>
            <author fullname="W. Beebee" initials="W." surname="Beebee"/>
            <author fullname="C. Donley" initials="C." surname="Donley"/>
            <author fullname="B. Stark" initials="B." surname="Stark"/>
            <date month="November" year="2013"/>
            <abstract>
              <t indent="0">This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the document. The document obsoletes RFC 6204.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7084"/>
          <seriesInfo name="DOI" value="10.17487/RFC7084"/>
        </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>
        <reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc8200" quoteTitle="true" derivedAnchor="RFC8200">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <date month="July" year="2017"/>
            <abstract>
              <t indent="0">This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="86"/>
          <seriesInfo name="RFC" value="8200"/>
          <seriesInfo name="DOI" value="10.17487/RFC8200"/>
        </reference>
        <reference anchor="RFC8213" target="https://www.rfc-editor.org/info/rfc8213" quoteTitle="true" derivedAnchor="RFC8213">
          <front>
            <title>Security of Messages Exchanged between Servers and Relay Agents</title>
            <author fullname="B. Volz" initials="B." surname="Volz"/>
            <author fullname="Y. Pal" initials="Y." surname="Pal"/>
            <date month="August" year="2017"/>
            <abstract>
              <t indent="0">The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents but does not require encryption. With recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay-to-relay and relay-to-server communication for DHCPv6 and relay-to-server communication for DHCPv4.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8213"/>
          <seriesInfo name="DOI" value="10.17487/RFC8213"/>
        </reference>
        <reference anchor="RFC8415" target="https://www.rfc-editor.org/info/rfc8415" quoteTitle="true" derivedAnchor="RFC8415">
          <front>
            <title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
            <author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/>
            <author fullname="M. Siodelski" initials="M." surname="Siodelski"/>
            <author fullname="B. Volz" initials="B." surname="Volz"/>
            <author fullname="A. Yourtchenko" initials="A." surname="Yourtchenko"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="S. Jiang" initials="S." surname="Jiang"/>
            <author fullname="T. Lemon" initials="T." surname="Lemon"/>
            <author fullname="T. Winters" initials="T." surname="Winters"/>
            <date month="November" year="2018"/>
            <abstract>
              <t indent="0">This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).</t>
              <t indent="0">This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8415"/>
          <seriesInfo name="DOI" value="10.17487/RFC8415"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc4862" quoteTitle="true" derivedAnchor="RFC4862">
          <front>
            <title>IPv6 Stateless Address Autoconfiguration</title>
            <author fullname="S. Thomson" initials="S." surname="Thomson"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <author fullname="T. Jinmei" initials="T." surname="Jinmei"/>
            <date month="September" year="2007"/>
            <abstract>
              <t indent="0">This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4862"/>
          <seriesInfo name="DOI" value="10.17487/RFC4862"/>
        </reference>
        <reference anchor="RFC6092" target="https://www.rfc-editor.org/info/rfc6092" quoteTitle="true" derivedAnchor="RFC6092">
          <front>
            <title>Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service</title>
            <author fullname="J. Woodyatt" initials="J." role="editor" surname="Woodyatt"/>
            <date month="January" year="2011"/>
            <abstract>
              <t indent="0">This document identifies a set of recommendations for the makers of devices and describes how to provide for "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6092"/>
          <seriesInfo name="DOI" value="10.17487/RFC6092"/>
        </reference>
        <reference anchor="RFC6177" target="https://www.rfc-editor.org/info/rfc6177" quoteTitle="true" derivedAnchor="RFC6177">
          <front>
            <title>IPv6 Address Assignment to End Sites</title>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <author fullname="G. Huston" initials="G." surname="Huston"/>
            <author fullname="L. Roberts" initials="L." surname="Roberts"/>
            <date month="March" year="2011"/>
            <abstract>
              <t indent="0">RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177. Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.</t>
              <t indent="0">This document obsoletes RFC 3177. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="157"/>
          <seriesInfo name="RFC" value="6177"/>
          <seriesInfo name="DOI" value="10.17487/RFC6177"/>
        </reference>
        <reference anchor="eRouter" target="https://www.cablelabs.com/specifications/CM-SP-eRouter" quoteTitle="true" derivedAnchor="eRouter">
          <front>
            <title>IPv4 and IPv6 eRouter Specification</title>
            <author fullname="CableLabs" surname="CableLabs">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="May" year="2024"/>
          </front>
          <refcontent>Data-Over-Cable Service Interface Specifications, Version I22</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1"> Thanks to the following people for their guidance and feedback:
      <contact fullname="Marion Dillon"/>, <contact fullname="Erik       Auerswald"/>, <contact fullname="Esko Dijk"/>, <contact fullname="Tim       Carlin"/>, <contact fullname="Richard Patterson"/>, <contact fullname="Ted Lemon"/>, <contact fullname="Michael Richardson"/>,
      <contact fullname="Martin Huneki"/>, <contact fullname="Gabor Lencse"/>,
      <contact fullname="Ole Troan"/>, <contact fullname="Brian Carpenter"/>,
      <contact fullname="David Farmer"/>, <contact fullname="Kyle Rose"/>,
      <contact fullname="Mohamed Boucadair"/>, <contact fullname="Tim       Chown"/>, <contact fullname="Ron Bonica"/>, and <contact fullname="Erica       Johnson"/>.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author fullname="Timothy Winters" initials="T." surname="Winters">
        <organization abbrev="QA Cafe" showOnFrontPage="true">QA Cafe</organization>
        <address>
          <postal>
            <street>100 Main Street, Suite #212</street>
            <city>Dover</city>
            <region>NH</region>
            <code>03820</code>
            <country>United States of America</country>
          </postal>
          <email>tim@qacafe.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
