<?xml version="1.0" encoding="US-ASCII"?> 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' ?>
<?rfc toc="yes"?>
<?rfc sortrefs="no"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902" updates="7084" obsoletes="" docName="draft-ietf-v6ops-cpe-lan-pd-09" submissionType="IETF"> number="9818" consensus="true" xml:lang="en" submissionType="IETF" tocInclude="true" sortRefs="false" symRefs="true" version="3">

  <front>
    <title>IPv6
    <title abbrev="DHCPv6 PD on IPv6 CE Routers LAN DHCPv6 in LANs">DHCPv6 Prefix Delegation</title> Delegation on IPv6 Customer Edge (CE) Routers in LANs</title>
    <seriesInfo name="RFC" value="9818"/>
    <author fullname="Timothy Winters" initials="T." surname="Winters">
      <organization abbrev="QA Cafe">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 year="2025" />
    <area> Internet </area>
    <workgroup>Internet Engineering Task Force</workgroup> month="July" year="2025"/>
    <area>OPS</area>
    <workgroup>v6ops</workgroup>

    <keyword>IPv6</keyword>
    <keyword>Internet Protocol Version 6</keyword>
    <keyword>DHCPv6</keyword>

    <abstract>
      <t>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 a IPv6 CE router.  This document updates RFC 7084.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
    <section>
      <name>Introduction</name>
      <t>This document describes guidelines for DHCPv6 Prefix Delegation in IPv6 Customer Edge (CE)
    routers (<xref target="RFC7084" />) <xref target="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" />. target="RFC6177"/>. If an IPv6 CE router does not support the
    Identity Association for Prefix Delegation (IA_PD) Prefix Option
    (Section 21.21 of <xref
    (<xref target="RFC8415" />) section="21.21"/>) 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 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>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 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 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 Specifiction specification <xref target="eRouter"></xref>. target="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 Router
    supporting prefix delegation routers is designed to be a flat model to support zero configuration zero-configuration networking.</t>
      <t>This document does not cover dealing with multi-provisioned multi-prefix networks with more than one provider.
    Due to the complexity of a solution that would require routing, provisioning provisioning, and policy, this is out of scope of this document.</t>
    </section>
    <section anchor="Requirements Language" title="Requirements Language">

      <t>The anchor="Requirements_Language">
      <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
      "SHALL&nbsp;NOT", "SHOULD", "SHOULD&nbsp;NOT", "RECOMMENDED",
      "NOT&nbsp;RECOMMENDED", "MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
      This
        </t>
      <t>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 (preferable
      in RFC or stable form) 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 deploying deployed and planned common IPv6
      access networks.</t>
    </section>
    <section anchor="Terminology" title="Terminology"> anchor="Terminology">
      <name>Terminology</name>
      <t>The document makes use of the following terms terms, some of which are from Section 2 <xref target='RFC8200'/>
    <list style="symbols">
        <t>IPv6 node: A target="RFC8200" section="2"/>
      </t>

      <dl spacing="normal" newline="false">
        <dt>IPv6 node:</dt><dd>A device that implements IPv6 protocol.</t>
        <t>IPv6 router: An IPv6.</dd>
        <dt>IPv6 router:</dt><dd>An IPv6 node that forwards IPv6 packets not explicitly addressed to itself.</t>
        <t>IPv6 host: An itself.</dd>
        <dt>IPv6 host:</dt><dd>An IPv6 node that is not a router.</t>
        <t>ULA:Unique router.</dd>
        <dt>ULA:</dt><dd>Unique Local Address, as defined in <xref target='RFC4193'/>.</t>
        <t>GUA:Global Unique Addresses, target="RFC4193"/>.</dd>
        <dt>GUA:</dt><dd>Global Unicast Address, as defined in <xref target='RFC4291'/>.</t>
    </list>
    </t> target="RFC4291"/>.</dd>
      </dl>
    </section>
    <section title="IPv6
    <section>
      <name>IPv6 End-User Network Architecture"> Architecture</name>

      <t>The end-user network for IPv6 that is a contains stub network. Figure 1 networks. <xref target="fig-1"/> illustrates the model topology.</t>
      <figure align="center" title="Example anchor="fig-1">
        <name>Example IPv6 End User Topology">
                 <artwork> End-User Topology</name>
        <artwork align="center"><![CDATA[
     +-----------+
     |  Service  |
     |  Provider |
     |   Router  |
     +-----+-----+
           |
           |
           |  Customer
           |  Internet Connection
           |
     +-----v-----+
     |   IPv6    |
     |    CE     |
     |  Router   |
     +-----+-----+
           |
    +------+-------+
    |              |
    |              |
+---+----+   +-----+-----+
|  IPv6  |   |           |
|  Host  |   |   Router  |
|        |   |           |
+--------+   +-----+-----+
                   |
                   |
               +---+----+
               |  IPv6  |
               |  Host  |
               |        |
                                +--------+
                 </artwork>
               +--------+]]></artwork>
      </figure>
    </section>
    <section anchor="Requirements" title="Requirements"> anchor="Requirements">
      <name>Requirements</name>
      <t> IPv6 CE routers distribute configuration information obtained during WAN interface
    provisioning to LAN-facing IPv6 hosts and routers.  An <xref target="RFC7084"/> compliant  A CE router that is compliant with <xref target="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 Section 4.3 of
    <xref target="RFC7084"/>.</t>
       <section title="LAN target="RFC7084" section="4.3"/>.</t>
      <section>
        <name>LAN Prefix Delegation Requirements (LPD)">
        <t><list style="format LPD-%d:">
           <t>IPv6 (LPD)</name>
        <ol spacing="normal" type="LPD-%d:" indent="9"><li>

            <t>Each IPv6 CE routers MUST router <bcp14>MUST</bcp14> support IPv6 prefix assignment according to Section 13.3 of <xref target="RFC8415"/> target="RFC8415" section="13.3"/>
           (Identity Association for Prefix Delegation (IA_PD) option) on its LAN interface(s).</t>
           <t>IPv6
          </li>

          <li>
            <t>Each IPv6 CE routers MUST <bcp14>MUST</bcp14> assign a prefix from the delegated prefix as specified by L-2 in
           Section 4.3 of
           <xref target="RFC7084"/>. target="RFC7084" section="4.3"/>.
           If insufficient prefixes are available available, the IPv6 CE Router MUST router <bcp14>MUST</bcp14> log a system management error.</t>
          </li>
          <li>
            <t>The prefix assigned to a link MUST NOT <bcp14>MUST NOT</bcp14> change in the absence of a local policy or a
           topology change.</t>
          </li>
          <li>
            <t>After LAN link prefix assignments, the IPv6 CE router MUST <bcp14>MUST</bcp14> keep the remaining IPv6 prefixes
           available to other routers via Prefix Delegation.</t>
          </li>
          <li>
            <t>IPv6 CE routers MUST <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. Packets with destination addresses in a delegated
           prefix MUST be routed to that prefix regardless of which interface they are received on. When a delegated prefix is released
           or expires, the associated route MUST <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 expires, it MUST <bcp14>MUST</bcp14> be returned the pool of available prefixes.</t>
          </li>

          <li>
            <t>By default, the IPv6 CE router filtering rules MUST <bcp14>MUST</bcp14> allow forwarding of packets with an outer
           IPv6 header containing a source address belonging to Delegated Prefixes, delegated prefixes, along with reciprocal
           packets from the same flow, following the recommendations of <xref target="RFC6092"/>. This updates WPD-5 of
           <xref target="RFC7084"/> to not drop packets from prefixes that have been delegated. IPv6 CE routers
           MUST
           <bcp14>MUST</bcp14> continue to drop packets packets, including destination address address, that is are not assigned to the LAN or delegated.</t>
          </li>
          <li>
            <t>The IPv6 CE routers MUST <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 router administrator. The prefix
           length prefix-length
           of 64 is used as that is the current prefix length prefix-length supported by SLAAC <xref target="RFC4862"/>. For hierarchical
           prefix delegation delegation, a prefix-length shorter than 64 may be configured.</t>
          </li>
          <li>
            <t>IPv6 CE routers configured to generate a ULA prefix as defined in ULA-1 of Section 4.3 of <xref target="RFC7084"/>
           MUST target="RFC7084" section="4.3"/>
           <bcp14>MUST</bcp14> continue to provision available GUA IPv6 prefixes.</t>
          </li>
          <li>

            <t>If an IPv6 CE router is provisioning both a ULA and GUA via prefix delegation, the GUA SHOULD <bcp14>SHOULD</bcp14> appear first in the DHCPv6 packets.</t>
          </li>
          <li>
            <t>IPv6 CE routers MUST NOT <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>
        </list></t>
          </li>
        </ol>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> anchor="Security">
      <name>Security Considerations</name>
      <t>This document does not add any new security considerations beyond those mentioned in
        Section 4 of
        <xref target="RFC8213"/>, Section 22 of target="RFC8213" section="4"/>, <xref target="RFC8415"/> target="RFC8415" section="22"/>, and <xref target="RFC6092"/>.</t> target="RFC6092" section="6"/>.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> anchor="IANA">
      <name>IANA Considerations</name>
      <t> This document makes has no request of IANA.</t>
    </section>
    <section anchor="Acknowledgements" title="Acknowledgements">
    <t> Thanks to the following people for their guidance and feedback:

    Marion Dillon, Erik Auerswald, Esko Dijk, Tim Carlin, Richard Patterson, Ted Lemon,
    Michael Richardson, Martin Huneki, Gabor Lencse, Ole Troan, Brian Carpenter, David Farmer,
    Kyle Rose, Mohamed Boucadair, Tim Chown, Ron Bonica, and Erica Johnson.

    </t> IANA actions.</t>
    </section>
  </middle>
  <back>
 <references title="Normative References">
     <?rfc include='reference.RFC.2119.xml'?>
     <?rfc include='reference.RFC.4193.xml'?>
     <?rfc include='reference.RFC.4291.xml'?>
     <?rfc include='reference.RFC.7084.xml'?>
     <?rfc include='reference.RFC.8174.xml'?>
     <?rfc include='reference.RFC.8200.xml'?>
     <?rfc include='reference.RFC.8213.xml'?>
     <?rfc include='reference.RFC.8415.xml'?>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4193.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7084.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8213.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/>
      </references>
 <references title="Informative References">
    <?rfc include='reference.RFC.4862.xml'?>
    <?rfc include='reference.RFC.6092.xml'?>
    <?rfc include='reference.RFC.6177.xml'?>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6092.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6177.xml"/>

        <reference anchor="eRouter" target="https://www.cablelabs.com/specifications/CM-SP-eRouter">
          <front>
            <title>IPv4 and IPv6 eRouter Specification Version I21</title> Specification</title>
            <author fullname="CableLabs" surname="CableLabs">
            <organization></organization>
              <organization/>
            </author>
            <date month="February" year="2022" /> month="May" year="2024"/>
          </front>
          <refcontent>Data-Over-Cable Service Interface Specifications, Version I22</refcontent>
        </reference>
      </references>
    </references>

    <section anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t> 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>
  </back>
</rfc>