rfc9818xml2.original.xml   rfc9818.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!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 category="info" ipr="trust200902" updates="7084" docName="draft-ietf-v6ops-
cpe-lan-pd-09" submissionType="IETF">
<front>
<title>IPv6 CE Routers LAN DHCPv6 Prefix Delegation</title>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902
" updates="7084" obsoletes="" docName="draft-ietf-v6ops-cpe-lan-pd-09" number="9
818" consensus="true" xml:lang="en" submissionType="IETF" tocInclude="true" sort
Refs="false" symRefs="true" version="3">
<front>
<title abbrev="DHCPv6 PD on IPv6 CE Routers in LANs">DHCPv6 Prefix Delegatio
n on IPv6 Customer Edge (CE) Routers in LANs</title>
<seriesInfo name="RFC" value="9818"/>
<author fullname="Timothy Winters" initials="T." surname="Winters"> <author fullname="Timothy Winters" initials="T." surname="Winters">
<organization abbrev="QA Cafe">QA Cafe</organization> <organization abbrev="QA Cafe">QA Cafe</organization>
<address> <address>
<postal> <postal>
<street>100 Main Street, Suite #212</street> <street>100 Main Street, Suite #212</street>
<city>Dover</city> <city>Dover</city>
<region>NH</region> <region>NH</region>
<code>03820</code> <code>03820</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>tim@qacafe.com</email> <email>tim@qacafe.com</email>
</address> </address>
</author> </author>
<date year="2025" /> <date month="July" year="2025"/>
<area> Internet </area> <area>OPS</area>
<workgroup>Internet Engineering Task Force</workgroup> <workgroup>v6ops</workgroup>
<keyword>IPv6</keyword> <keyword>IPv6</keyword>
<keyword>Internet Protocol Version 6</keyword> <keyword>Internet Protocol Version 6</keyword>
<keyword>DHCPv6</keyword> <keyword>DHCPv6</keyword>
<abstract> <abstract>
<t>This document defines requirements for IPv6 Customer Edge (CE) routers to <t>This document defines requirements for IPv6 Customer Edge (CE) routers
support DHCPv6 Prefix Delegation for distributing available prefixes that we to
re support DHCPv6 Prefix Delegation for distributing available prefixes to LAN
delegated to a IPv6 CE router. This document updates RFC 7084.</t> devices that were
delegated to an IPv6 CE router. This document updates RFC 7084.</t>
</abstract> </abstract>
</front>
</front> <middle>
<middle> <section>
<section title="Introduction"> <name>Introduction</name>
<t>This document describes guidelines for DHCPv6 Prefix Delegation in IPv6 C <t>This document describes guidelines for DHCPv6 Prefix Delegation in IPv6
ustomer Edge (CE) Customer Edge (CE)
routers (<xref target="RFC7084" />) in order to properly utilize the IPv6 pr routers <xref target="RFC7084"/> in order to properly utilize the IPv6 prefi
efixes delegated by xes delegated by
service providers. Many service providers assign larger address blocks than /64 to CE routers, service providers. Many service providers assign larger address blocks than /64 to CE routers,
as recommended in <xref target="RFC6177" />. If an IPv6 CE router does not s upport the as recommended in <xref target="RFC6177"/>. If an IPv6 CE router does not su pport the
Identity Association for Prefix Delegation (IA_PD) Prefix Option Identity Association for Prefix Delegation (IA_PD) Prefix Option
(Section 21.21 of <xref target="RFC8415" />) on the LAN, it will not be able to assign any prefixes beyond its local (<xref target="RFC8415" section="21.21"/>) on the LAN, it will not be able t o assign any prefixes beyond its local
interfaces, limiting the usefulness of assigning prefixes larger than /64 by the operator. Supporting 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 IA_PD on the LAN interfaces of a CE router will allow those unused prefixes
to be distributed to be distributed
into a network. Note that efforts such as Stub Networking Auto Configuratio into a network. Note that efforts such as those of the Stub Networking Auto
n Configuration
(SNAC) Working Group depend on IPv6 prefixes being properly distributed in t he LAN.</t> (SNAC) Working Group depend on IPv6 prefixes being properly distributed in t he LAN.</t>
<t>Two models, hierarchical prefix and flat, were proposed in the past for
<t>Two models, hierarchical prefix and flat, were proposed in the past for p prefix sub-delegation beyond
refix sub-delegation beyond
an IPv6 CE router. an IPv6 CE router.
Hierarchical prefix delegation requires an IPv6 CE router to sub delegate IP Hierarchical prefix delegation requires an IPv6 CE router to sub-delegate IP
v6 prefixes v6 prefixes
based on set of rules. If more than one router uses hierarchical prefix dele based on a set of rules. If more than one router uses hierarchical prefix de
gation, an IPv6 prefix tree is created. legation, an IPv6 prefix tree is created.
When no routing protocol is enabled to discover the network topology, it is When no routing protocol is enabled to discover the network topology, it is
possible to have unbalanced possible to have an unbalanced
prefix delegation tree which leads to running out of prefixes. More informa prefix delegation tree, which leads to running out of prefixes. More inform
tion on hierarchical prefix ation on hierarchical prefix
delegation can be found, e.g., in Section 8.5 of CableLabs IPv6 eRouter Spec delegation can be found, e.g., in Section 8.5 of CableLabs IPv6 eRouter spec
ifiction <xref target="eRouter"></xref>. ification <xref target="eRouter"/>.
A flat prefix delegation requires the router to be provisioned with the init ial prefix and to assign /64 prefixes A flat prefix delegation requires the router to be provisioned with the init ial prefix and to assign /64 prefixes
to all other prefix requests from routers in the LAN-facing interface. The d to all other prefix requests from routers in the LAN-facing interface.
efault configuration of CE Router
supporting prefix delegation is designed to be a flat model to support zero
configuration networking.</t>
<t>This document does not cover dealing with multi-provisioned networks with The default configuration of CE routers is designed to be a flat model to suppor
more than one provider. t zero-configuration networking.</t>
Due to complexity of a solution that would require routing, provisioning and <t>This document does not cover dealing with multi-prefix networks with mo
policy, this is out of scope of this document.</t> re 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>
<section anchor="Requirements_Language">
<section anchor="Requirements Language" title="Requirements Language"> <name>Requirements Language</name>
<t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHALL&nbsp;NOT", "SHOULD", "SHOULD&nbsp;NOT", "RECOMMENDED", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
"NOT&nbsp;RECOMMENDED", "MAY", and "OPTIONAL" in this document ",
are to be interpreted as described in BCP&nbsp;14 "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
<xref target="RFC2119"/> <xref target="RFC8174"/> when, "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
and only when, they appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
This document uses these keywords not strictly for the purpose of interope be
rability, 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.
</t>
<t>This document uses these keywords not strictly for the purpose of inter
operability,
but rather for the purpose of establishing industry-common baseline functi onality. As but rather for the purpose of establishing industry-common baseline functi onality. As
such, the document points to several other specifications (preferable such, the document points to several other specifications to provide addit
in RFC or stable form) to provide additional guidance to implementers ional guidance to implementers
regarding any protocol implementation required to produce a regarding any protocol implementation required to produce a
successful CE router that interoperates successfully with a successful CE router that interoperates successfully with a
particular subset of currently deploying and planned common IPv6 particular subset of currently deployed and planned common IPv6
access networks.</t> access networks.</t>
</section> </section>
<section anchor="Terminology" title="Terminology"> <section anchor="Terminology">
<t>The document makes use of the following terms from Section 2 <xref target <name>Terminology</name>
='RFC8200'/> <t>The document makes use of the following terms, some of which are from <
<list style="symbols"> xref target="RFC8200" section="2"/>
<t>IPv6 node: A device that implements IPv6 protocol.</t> </t>
<t>IPv6 router: An IPv6 node that forwards IPv6 packets not explicitly a
ddressed to itself.</t> <dl spacing="normal" newline="false">
<t>IPv6 host: An IPv6 node that is not a router.</t> <dt>IPv6 node:</dt><dd>A device that implements IPv6.</dd>
<t>ULA:Unique Local Address, as defined in <xref target='RFC4193'/>.</t> <dt>IPv6 router:</dt><dd>An IPv6 node that forwards IPv6 packets not exp
<t>GUA:Global Unique Addresses, as defined in <xref target='RFC4291'/>.< licitly addressed to itself.</dd>
/t> <dt>IPv6 host:</dt><dd>An IPv6 node that is not a router.</dd>
</list> <dt>ULA:</dt><dd>Unique Local Address, as defined in <xref target="RFC41
</t> 93"/>.</dd>
<dt>GUA:</dt><dd>Global Unicast Address, as defined in <xref target="RFC
4291"/>.</dd>
</dl>
</section> </section>
<section title="IPv6 End-User Network Architecture"> <section>
<t>The end-user network for IPv6 that is a stub network. Figure 1 illustrate <name>IPv6 End-User Network Architecture</name>
s the model topology.</t>
<figure align="center" title="Example IPv6 End User Topology"> <t>The end-user network for IPv6 contains stub networks. <xref target="fig
<artwork> -1"/> illustrates the model topology.</t>
+-----------+ <figure anchor="fig-1">
| Service | <name>Example IPv6 End-User Topology</name>
| Provider | <artwork align="center"><![CDATA[
| Router | +-----------+
+-----+-----+ | Service |
| | Provider |
| | Router |
| Customer +-----+-----+
| Internet Connection |
| |
+-----v-----+ | Customer
| IPv6 | | Internet Connection
| CE | |
| Router | +-----v-----+
+-----+-----+ | IPv6 |
| | CE |
+------+-------+ | Router |
| | +-----+-----+
| | |
+---+----+ +-----+-----+ +------+-------+
| IPv6 | | | | |
| Host | | Router | | |
| | | | +---+----+ +-----+-----+
+--------+ +-----+-----+ | IPv6 | | |
| | Host | | Router |
| | | | |
+---+----+ +--------+ +-----+-----+
| IPv6 | |
| Host | |
| | +---+----+
+--------+ | IPv6 |
</artwork> | Host |
</figure> | |
+--------+]]></artwork>
</figure>
</section> </section>
<section anchor="Requirements" title="Requirements"> <section anchor="Requirements">
<t> IPv6 CE routers distribute configuration information obtained during WAN <name>Requirements</name>
interface <t> IPv6 CE routers distribute configuration information obtained during W
provisioning to LAN-facing IPv6 hosts and routers. An <xref target="RFC7084 AN interface
"/> compliant CE router provisioning to LAN-facing IPv6 hosts and routers. A CE router that is comp
liant with <xref target="RFC7084"/>
would only provide IPv6 hosts with configuration information. This document allows for addressing and routing of IPv6 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 th prefixes to both hosts and routers. These requirements are in addition to th
e ones in Section 4.3 of e ones in
<xref target="RFC7084"/>.</t> <xref target="RFC7084" section="4.3"/>.</t>
<section title="LAN Prefix Delegation Requirements (LPD)"> <section>
<t><list style="format LPD-%d:"> <name>LAN Prefix Delegation Requirements (LPD)</name>
<t>IPv6 CE routers MUST support IPv6 prefix assignment according to S <ol spacing="normal" type="LPD-%d:" indent="9"><li>
ection 13.3 of <xref target="RFC8415"/>
<t>Each IPv6 CE router <bcp14>MUST</bcp14> support IPv6 prefix assig
nment according to <xref target="RFC8415" section="13.3"/>
(Identity Association for Prefix Delegation (IA_PD) option) on its LA N interface(s).</t> (Identity Association for Prefix Delegation (IA_PD) option) on its LA N interface(s).</t>
<t>IPv6 CE routers MUST assign a prefix from the delegated prefix as </li>
specified by L-2 in
Section 4.3 of <xref target="RFC7084"/>. <li>
If insufficient prefixes are available the IPv6 CE Router MUST log a <t>Each IPv6 CE routers <bcp14>MUST</bcp14> assign a prefix from the
system management error.</t> delegated prefix as specified by L-2 in
<t>The prefix assigned to a link MUST NOT change in the absence of a <xref target="RFC7084" section="4.3"/>.
local policy or a If insufficient prefixes are available, the IPv6 CE router <bcp14>MUS
T</bcp14> log a system management error.</t>
</li>
<li>
<t>The prefix assigned to a link <bcp14>MUST NOT</bcp14> change in t
he absence of a local policy or a
topology change.</t> topology change.</t>
<t>After LAN link prefix assignments, the IPv6 CE router MUST keep th </li>
e remaining IPv6 prefixes <li>
<t>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> available to other routers via Prefix Delegation.</t>
<t>IPv6 CE routers MUST maintain a local routing table that is dynami </li>
cally updated with leases <li>
and the associated next hops as they are delegated to clients. When a <t>IPv6 CE routers <bcp14>MUST</bcp14> maintain a local routing tabl
delegated prefix is released e that is dynamically updated with leases
or expires, the associated route MUST be removed from the IPv6 CE rou and the associated next hops as they are delegated to clients. Absent
ter's routing table. A delegated 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 prefix expires when the valid lifetime assigned in the IA_PD expires without being renewed. When a prefix
is released or expires it MUST be returned the pool of available pref is released or expires, it <bcp14>MUST</bcp14> be returned the pool o
ixes.</t> f available prefixes.</t>
<t>By default, the IPv6 CE router filtering rules MUST allow forwardi </li>
ng of packets with an outer
IPv6 header containing a source address belonging to Delegated Prefix <li>
es, along with reciprocal <t>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 prefix
es, along with reciprocal
packets from the same flow, following the recommendations of <xref ta rget="RFC6092"/>. This updates WPD-5 of packets from the same flow, following the recommendations of <xref ta rget="RFC6092"/>. This updates WPD-5 of
<xref target="RFC7084"/> to not drop packets from prefixes that have been delegated. IPv6 CE routers <xref target="RFC7084"/> to not drop packets from prefixes that have been delegated. IPv6 CE routers
MUST continue to drop packets including destination address that is n <bcp14>MUST</bcp14> continue to drop packets, including destination a
ot assigned to the LAN or delegated.</t> ddress, that are not assigned to the LAN or delegated.</t>
<t>The IPv6 CE routers MUST provision IA_PD prefixes with a prefix-le </li>
ngth of 64 on the LAN-facing interface <li>
unless configured to use a different prefix-length by the CE Router a <t>The IPv6 CE routers <bcp14>MUST</bcp14> provision IA_PD prefixes
dministrator. The prefix with a prefix-length of 64 on the LAN-facing interface
length of 64 is used as that is the current prefix length supported b unless configured to use a different prefix-length by the CE router a
y SLAAC <xref target="RFC4862"/>. For hierarchical dministrator. The prefix-length
prefix delegation a prefix-length shorter than 64 may be configured.< of 64 is used as that is the current prefix-length supported by SLAAC
/t> <xref target="RFC4862"/>. For hierarchical
<t>IPv6 CE routers configured to generate a ULA prefix as defined in prefix delegation, a prefix-length shorter than 64 may be configured.
ULA-1 of Section 4.3 of <xref target="RFC7084"/> </t>
MUST continue to provision available GUA IPv6 prefixes.</t> </li>
<t>If an IPv6 CE router is provisioning both ULA and GUA via prefix d <li>
elegation, the GUA SHOULD appear first in the DHCPv6 packets.</t> <t>IPv6 CE routers configured to generate a ULA prefix as defined in
<t>IPv6 CE routers MUST NOT delegate prefixes via DHCPv6 on the LAN u ULA-1 of <xref target="RFC7084" section="4.3"/>
sing lifetimes that <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 prefi
x delegation, the GUA <bcp14>SHOULD</bcp14> appear first in the DHCPv6 packets.<
/t>
</li>
<li>
<t>IPv6 CE routers <bcp14>MUST NOT</bcp14> delegate prefixes via DHC
Pv6 on the LAN using lifetimes that
exceed the remaining lifetimes of the corresponding prefixes learned on the WAN.</t> exceed the remaining lifetimes of the corresponding prefixes learned on the WAN.</t>
</list></t> </li>
</section> </ol>
</section>
</section> </section>
<section anchor="Security" title="Security Considerations"> <section anchor="Security">
<t>This document does not add any new security considerations beyond tho <name>Security Considerations</name>
se mentioned in <t>This document does not add any new security considerations beyond those
Section 4 of <xref target="RFC8213"/>, Section 22 of <xref target="RFC84 mentioned in
15"/> and <xref target="RFC6092"/>.</t> <xref target="RFC8213" section="4"/>, <xref target="RFC8415" section="22
"/>, and <xref target="RFC6092" section="6"/>.</t>
</section> </section>
<section anchor="IANA" title="IANA Considerations"> <section anchor="IANA">
<t> This document makes no request of IANA.</t> <name>IANA Considerations</name>
<t> This document has no IANA actions.</t>
</section> </section>
<section anchor="Acknowledgements" title="Acknowledgements"> </middle>
<t> Thanks to the following people for their guidance and feedback: <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
193.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
291.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
084.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
200.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
213.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
415.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
862.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
092.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
177.xml"/>
Marion Dillon, Erik Auerswald, Esko Dijk, Tim Carlin, Richard Patterson, Ted <reference anchor="eRouter" target="https://www.cablelabs.com/specificat
Lemon, ions/CM-SP-eRouter">
Michael Richardson, Martin Huneki, Gabor Lencse, Ole Troan, Brian Carpenter, <front>
David Farmer, <title>IPv4 and IPv6 eRouter Specification</title>
Kyle Rose, Mohamed Boucadair, Tim Chown, Ron Bonica, and Erica Johnson. <author fullname="CableLabs" surname="CableLabs">
<organization/>
</author>
<date month="May" year="2024"/>
</front>
<refcontent>Data-Over-Cable Service Interface Specifications, Version
I22</refcontent>
</reference>
</references>
</references>
</t> <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> </section>
</middle> </back>
<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>
<references title="Informative References">
<?rfc include='reference.RFC.4862.xml'?>
<?rfc include='reference.RFC.6092.xml'?>
<?rfc include='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>
<author fullname="CableLabs" surname="CableLabs">
<organization></organization>
</author>
<date month="February" year="2022" />
</front>
</reference>
</references>
</back>
</rfc> </rfc>
 End of changes. 33 change blocks. 
220 lines changed or deleted 278 lines changed or added

This html diff was produced by rfcdiff 1.48.