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="IPv6 CE Router LAN DHCPv6 Prefix">IPv6 Customer Edge (CE) Rou
ters LAN DHCPv6 Prefix Delegation</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> <!-- [rfced] How may this title be rephrased for clarity?
<t>This document defines requirements for IPv6 Customer Edge (CE) routers to Also, is "LAN" needed in this title? (Neither "LAN" nor "local" is mentioned
support DHCPv6 Prefix Delegation for distributing available prefixes that we in the abstract.) Do either of these options convey the intended meaning?
re Please feel free to suggest otherwise.
delegated to a IPv6 CE router. This document updates RFC 7084.</t>
</abstract> Original:
IPv6 CE Routers LAN DHCPv6 Prefix Delegation
</front> Current:
<middle> IPv6 Customer Edge (CE) Routers LAN DHCPv6 Prefix Delegation
<section title="Introduction">
<t>This document describes guidelines for DHCPv6 Prefix Delegation in IPv6 C Option A:
ustomer Edge (CE) DHCPv6 Prefix Delegation on IPv6 Customer Edge (CE) Routers in LANs
routers (<xref target="RFC7084" />) in order to properly utilize the IPv6 pr
efixes delegated by Option B:
DHCPv6 Prefix Delegation in LANs for IPv6 Customer Edge (CE) Routers
-->
<abstract>
<t>This document defines requirements for IPv6 Customer Edge (CE) routers
to
support DHCPv6 Prefix Delegation for distributing available prefixes that we
re
delegated to a IPv6 CE router. This document updates RFC 7084.</t>
</abstract>
</front>
<middle>
<section>
<name>Introduction</name>
<t>This document describes guidelines for DHCPv6 Prefix Delegation in IPv6
Customer Edge (CE)
routers <xref target="RFC7084"/> in order to properly utilize the IPv6 prefi
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 <!--[rfced] For clarity, how may this be rephrased? In particular,
supporting prefix delegation is designed to be a flat model to support zero the phrase "CE Router supporting prefix delegation" is unclear.
configuration networking.</t>
<t>This document does not cover dealing with multi-provisioned networks with Original:
more than one provider. The default configuration of CE Router supporting
Due to complexity of a solution that would require routing, provisioning and prefix delegation is designed to be a flat model to support zero
policy, this is out of scope of this document.</t> configuration networking.
</section>
<section anchor="Requirements Language" title="Requirements Language"> Perhaps:
For prefix delegation that supports CE routers, the default
configuration is designed to be a flat model to support
zero-configuration networking.
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", Or simply:
"SHALL&nbsp;NOT", "SHOULD", "SHOULD&nbsp;NOT", "RECOMMENDED", For prefix delegation that supports CE routers, the default
"NOT&nbsp;RECOMMENDED", "MAY", and "OPTIONAL" in this document configuration is a flat model to support zero-configuration
are to be interpreted as described in BCP&nbsp;14 networking.
<xref target="RFC2119"/> <xref target="RFC8174"/> when, -->
and only when, they appear in all capitals, as shown here.
This document uses these keywords not strictly for the purpose of interope <!--[rfced] Please clarify "multi-provisioned networks". Is there
rability, another term that is more common? The term "multi-provisioned"
does not appear in past RFCs or current Internet-Drafts.
Original:
This document does not cover dealing with multi-provisioned networks
with more than one provider.
-->
The default 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 wi
th 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">
<name>Requirements Language</name>
<t>
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&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 <!--[rfced] Which update do you prefer, as this definition is missing 'the',
ddressed to itself.</t> but perhaps you prefer to match the cited document?
<t>IPv6 host: An IPv6 node that is not a router.</t>
<t>ULA:Unique Local Address, as defined in <xref target='RFC4193'/>.</t> Original: IPv6 node: A device that implements IPv6 protocol.
<t>GUA:Global Unique Addresses, as defined in <xref target='RFC4291'/>.<
/t> Option A: IPv6 node: A device that implements IPv6.
</list> (to match RFC 8200, which is cited in the lead-in text)
</t>
Option B: IPv6 node: A device that implements the IPv6 protocol.
-->
<!-- [rfced] FYI, for expanding GUA, "Unique" has been changed to
"Unicast" in order to match RFC 4291. Please review.
Original:
* GUA:Global Unique Addresses, as defined in [RFC4291].
Current:
GUA: Global Unicast Address, as defined in [RFC4291].
-->
<dl spacing="normal" newline="false">
<dt>IPv6 node:</dt><dd>A device that implements IPv6 protocol.</dd>
<dt>IPv6 router:</dt><dd>An IPv6 node that forwards IPv6 packets not exp
licitly addressed to itself.</dd>
<dt>IPv6 host:</dt><dd>An IPv6 node that is not a router.</dd>
<dt>ULA:</dt><dd>Unique Local Address, as defined in <xref target="RFC41
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> <!--[rfced] Please clarify; how should this fragment be updated to
be a sentence?
<figure align="center" title="Example IPv6 End User Topology"> Original:
<artwork> The end-user network for IPv6 that is a stub network.
+-----------+ -->
| Service | <t>The end-user network for IPv6 that is a stub network. <xref target="fig
| Provider | -1"/> illustrates the model topology.</t>
| Router | <figure anchor="fig-1">
+-----+-----+ <name>Example IPv6 End-User Topology</name>
| <artwork align="center"><![CDATA[
| +-----------+
| Customer | Service |
| Internet Connection | Provider |
| | Router |
+-----v-----+ +-----+-----+
| IPv6 | |
| CE | |
| Router | | Customer
+-----+-----+ | Internet Connection
| |
+------+-------+ +-----v-----+
| | | IPv6 |
| | | CE |
+---+----+ +-----+-----+ | Router |
| IPv6 | | | +-----+-----+
| Host | | Router | |
| | | | +------+-------+
+--------+ +-----+-----+ | |
| | |
| +---+----+ +-----+-----+
+---+----+ | IPv6 | | |
| IPv6 | | Host | | Router |
| Host | | | | |
| | +--------+ +-----+-----+
+--------+ |
</artwork> |
</figure> +---+----+
| IPv6 |
| Host |
| |
+--------+]]></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"/> <!--[rfced] Please review this update for accuracy; due to "its",
the subject ("IPv6 CE routers") has been changed to singular. It
currently reads that a single router could have more than one LAN interface.
Original:
LPD-1: IPv6 CE routers MUST support IPv6 prefix assignment
according to Section 13.3 of [RFC8415] (Identity Association
for Prefix Delegation (IA_PD) option) on its LAN
interface(s).
Current:
LPD-1: Each IPv6 CE router MUST support IPv6 prefix assignment
according to Section 13.3 of [RFC8415] (Identity Association
for Prefix Delegation (IA_PD) option) on its LAN
interface(s).
Alternatively (both plural):
LPD-1: IPv6 CE routers MUST support IPv6 prefix assignment
according to Section 13.3 of [RFC8415] (Identity Association
for Prefix Delegation (IA_PD) option) on their LAN
interfaces.
-->
<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 <!--[rfced] Because the second sentence is singular, should the first
Section 4.3 of <xref target="RFC7084"/>. sentence be parallel?
If insufficient prefixes are available the IPv6 CE Router MUST log a
system management error.</t> Original:
<t>The prefix assigned to a link MUST NOT change in the absence of a LPD-2: IPv6 CE routers MUST assign a prefix from the delegated
local policy or a prefix as specified by L-2 in Section 4.3 of [RFC7084]. If
insufficient prefixes are available the IPv6 CE Router MUST
log a system management error.
Perhaps:
LPD-2: Each IPv6 CE router MUST assign a prefix from the delegated
prefix as specified by L-2 in Section 4.3 of [RFC7084]. If
insufficient prefixes are available, the IPv6 CE router MUST
log a system management error.
-->
<li>
<t>IPv6 CE routers <bcp14>MUST</bcp14> assign a prefix from the dele
gated prefix as specified by L-2 in
<xref target="RFC7084" section="4.3"/>.
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>
<t>IPv6 CE routers <bcp14>MUST</bcp14> maintain a local routing tabl
e that is dynamically updated with leases
and the associated next hops as they are delegated to clients. When a delegated prefix is released and the associated next hops as they are delegated to clients. When a delegated prefix is released
or expires, the associated route MUST be removed from the IPv6 CE rou ter's routing table. A delegated 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 <!--[rfced] Re: LPD-6, what does "that is not assigned" refer to?
As far as verb agreement, it does not match "packets".
Original:
IPv6 CE routers MUST continue to drop packets
including destination address that is not assigned to the
LAN or delegated.
Perhaps:
IPv6 CE routers MUST continue to drop packets,
including destination address, that are not assigned to the
LAN or delegated.
-->
<li>
<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 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 ad
ot assigned to the LAN or delegated.</t> dress that is 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
unless configured to use a different prefix-length by the CE router a
dministrator. The prefix
length of 64 is used as that is the current prefix length supported b y SLAAC <xref target="RFC4862"/>. For hierarchical length of 64 is used as that is the current prefix length supported b y SLAAC <xref target="RFC4862"/>. For hierarchical
prefix delegation a prefix-length shorter than 64 may be configured.< prefix delegation, a prefix-length shorter than 64 may be configured.
/t> </t>
<t>IPv6 CE routers configured to generate a ULA prefix as defined in </li>
ULA-1 of Section 4.3 of <xref target="RFC7084"/> <li>
MUST continue to provision available GUA IPv6 prefixes.</t> <t>IPv6 CE routers configured to generate a ULA prefix as defined in
<t>If an IPv6 CE router is provisioning both ULA and GUA via prefix d ULA-1 of <xref target="RFC7084" section="4.3"/>
elegation, the GUA SHOULD appear first in the DHCPv6 packets.</t> <bcp14>MUST</bcp14> continue to provision available GUA IPv6 prefixes
<t>IPv6 CE routers MUST NOT delegate prefixes via DHCPv6 on the LAN u .</t>
sing lifetimes that </li>
<li>
<!--[rfced] Should "both ULA and GUA" be both "ULAs and GUAs"? If so,
please review whether "the GUA" is accurate in the second phrase.
Original:
LPD-9: If an IPv6 CE router is provisioning both ULA and GUA via
prefix delegation, the GUA SHOULD appear first in the DHCPv6
packets.
Perhaps:
LPD-9: If an IPv6 CE router is provisioning both ULAs and GUAs via
prefix delegation, the GUA SHOULD appear first in the DHCPv6
packets.
Or (singular):
LPD-9: If an IPv6 CE router is provisioning both the ULA and the GUA via
prefix delegation, the GUA SHOULD appear first in the DHCPv6
packets.
-->
<t>If an IPv6 CE router is provisioning both ULA and GUA via prefix
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:
Marion Dillon, Erik Auerswald, Esko Dijk, Tim Carlin, Richard Patterson, Ted <!--[rfced] Terminology
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> a) This term appeared inconsistently and has been updated to the latter.
</section> Please let us know if you prefer otherwise.
</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>
<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"> CE Router vs. CE router [based on usage in RFC 7084]
<organization></organization>
</author>
<date month="February" year="2022" /> b) Capitalization of these terms is not consistent. Please let us
</front> know your preference.
</reference>
</references> Prefix Delegation vs. prefix delegation
</back>
Delegated Prefix (in LPD-6) vs. delegated prefix (in LPD-2, LPD-5)
c) Please review usage of this term and let us know if any updates are needed.
We note RFC 8415 uses the hyphen for the "prefix-length" field.
prefix-length (3 instances) vs. prefix length (2 instances)
-->
<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"/>
<!-- [rfced] FYI, the original URL provided for [eRouter] is to the most
recent version of this CableLabs specification, Version I22, which was
published in May 2024, so we updated the reference as follows.
Original:
[eRouter] CableLabs, "IPv4 and IPv6 eRouter Specification Version
I21", February 2022,
<https://www.cablelabs.com/specifications/CM-SP-eRouter>.
Current:
[eRouter] CableLabs, "IPv4 and IPv6 eRouter Specification", Data-
Over-Cable Service Interface Specifications, Version I22,
May 2024,
<https://www.cablelabs.com/specifications/CM-SP-eRouter>.
Re: "in Section 8.5 of CableLabs IPv6 eRouter specification [eRouter]",
we note that Section 8.5 has the same title in I21 and I122.
However, if you prefer to reference Version I21, please let us know
(and in that case, we recommend this URL:
https://www.cablelabs.com/specifications/CM-SP-eRouter?v=I21).
-->
<reference anchor="eRouter" target="https://www.cablelabs.com/specificat
ions/CM-SP-eRouter">
<front>
<title>IPv4 and IPv6 eRouter Specification</title>
<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>
<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> </rfc>
 End of changes. 39 change blocks. 
209 lines changed or deleted 438 lines changed or added

This html diff was produced by rfcdiff 1.48.