rfc9818.original   rfc9818.txt 
Internet Engineering Task Force T. Winters Internet Engineering Task Force (IETF) T. Winters
Internet-Draft QA Cafe Request for Comments: 9818 QA Cafe
Updates: 7084 (if approved) 22 May 2025 Updates: 7084 July 2025
Intended status: Informational Category: Informational
Expires: 23 November 2025 ISSN: 2070-1721
IPv6 CE Routers LAN DHCPv6 Prefix Delegation IPv6 Customer Edge (CE) Routers LAN DHCPv6 Prefix Delegation
draft-ietf-v6ops-cpe-lan-pd-09
Abstract Abstract
This document defines requirements for IPv6 Customer Edge (CE) This document defines requirements for IPv6 Customer Edge (CE)
routers to support DHCPv6 Prefix Delegation for distributing routers to support DHCPv6 Prefix Delegation for distributing
available prefixes that were delegated to a IPv6 CE router. This available prefixes that were delegated to a IPv6 CE router. This
document updates RFC 7084. document updates RFC 7084.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 23 November 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9818.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology
4. IPv6 End-User Network Architecture . . . . . . . . . . . . . 3 4. IPv6 End-User Network Architecture
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Requirements
5.1. LAN Prefix Delegation Requirements (LPD) . . . . . . . . 5 5.1. LAN Prefix Delegation Requirements (LPD)
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgements
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address
1. Introduction 1. Introduction
This document describes guidelines for DHCPv6 Prefix Delegation in This document describes guidelines for DHCPv6 Prefix Delegation in
IPv6 Customer Edge (CE) routers ([RFC7084]) in order to properly IPv6 Customer Edge (CE) routers [RFC7084] in order to properly
utilize the IPv6 prefixes delegated by service providers. Many utilize the IPv6 prefixes delegated by service providers. Many
service providers assign larger address blocks than /64 to CE service providers assign larger address blocks than /64 to CE
routers, as recommended in [RFC6177]. If an IPv6 CE router does not routers, as recommended in [RFC6177]. If an IPv6 CE router does not
support the Identity Association for Prefix Delegation (IA_PD) Prefix support the Identity Association for Prefix Delegation (IA_PD) Prefix
Option (Section 21.21 of [RFC8415]) on the LAN, it will not be able Option (Section 21.21 of [RFC8415]) on the LAN, it will not be able
to assign any prefixes beyond its local interfaces, limiting the to assign any prefixes beyond its local interfaces, limiting the
usefulness of assigning prefixes larger than /64 by the operator. usefulness of assigning prefixes larger than /64 by the operator.
Supporting IA_PD on the LAN interfaces of a CE Router will allow Supporting IA_PD on the LAN interfaces of a CE router will allow
those unused prefixes to be distributed into a network. Note that those unused prefixes to be distributed into a network. Note that
efforts such as Stub Networking Auto Configuration (SNAC) Working efforts such as those of the Stub Networking Auto Configuration
Group depend on IPv6 prefixes being properly distributed in the LAN. (SNAC) Working Group depend on IPv6 prefixes being properly
distributed in the LAN.
Two models, hierarchical prefix and flat, were proposed in the past Two models, hierarchical prefix and flat, were proposed in the past
for prefix sub-delegation beyond an IPv6 CE router. Hierarchical for prefix sub-delegation beyond an IPv6 CE router. Hierarchical
prefix delegation requires an IPv6 CE router to sub delegate IPv6 prefix delegation requires an IPv6 CE router to sub-delegate IPv6
prefixes based on set of rules. If more than one router uses prefixes based on a set of rules. If more than one router uses
hierarchical prefix delegation, an IPv6 prefix tree is created. When hierarchical prefix delegation, an IPv6 prefix tree is created. When
no routing protocol is enabled to discover the network topology, it no routing protocol is enabled to discover the network topology, it
is possible to have unbalanced prefix delegation tree which leads to is possible to have an unbalanced prefix delegation tree, which leads
running out of prefixes. More information on hierarchical prefix to running out of prefixes. More information on hierarchical prefix
delegation can be found, e.g., in Section 8.5 of CableLabs IPv6 delegation can be found, e.g., in Section 8.5 of CableLabs IPv6
eRouter Specifiction [eRouter]. A flat prefix delegation requires eRouter specification [eRouter]. A flat prefix delegation requires
the router to be provisioned with the initial prefix and to assign the router to be provisioned with the initial prefix and to assign
/64 prefixes to all other prefix requests from routers in the LAN- /64 prefixes to all other prefix requests from routers in the LAN-
facing interface. The default configuration of CE Router supporting facing interface. The default configuration of CE router supporting
prefix delegation is designed to be a flat model to support zero prefix delegation is designed to be a flat model to support zero-
configuration networking. configuration networking.
This document does not cover dealing with multi-provisioned networks This document does not cover dealing with multi-provisioned networks
with more than one provider. Due to complexity of a solution that with more than one provider. Due to the complexity of a solution
would require routing, provisioning and policy, this is out of scope that would require routing, provisioning, and policy, this is out of
of this document. scope of this document.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. This document uses these keywords not capitals, as shown here.
strictly for the purpose of interoperability, but rather for the
purpose of establishing industry-common baseline functionality. As This document uses these keywords not strictly for the purpose of
such, the document points to several other specifications (preferable interoperability, but rather for the purpose of establishing
in RFC or stable form) to provide additional guidance to implementers industry-common baseline functionality. As such, the document points
regarding any protocol implementation required to produce a to several other specifications to provide additional guidance to
successful CE router that interoperates successfully with a implementers regarding any protocol implementation required to
particular subset of currently deploying and planned common IPv6 produce a successful CE router that interoperates successfully with a
particular subset of currently deployed and planned common IPv6
access networks. access networks.
3. Terminology 3. Terminology
The document makes use of the following terms from Section 2 The document makes use of the following terms, some of which are from
[RFC8200] Section 2 of [RFC8200]
* IPv6 node: A device that implements IPv6 protocol. IPv6 node: A device that implements IPv6 protocol.
* IPv6 router: An IPv6 node that forwards IPv6 packets not IPv6 router: An IPv6 node that forwards IPv6 packets not explicitly
explicitly addressed to itself. addressed to itself.
* IPv6 host: An IPv6 node that is not a router. IPv6 host: An IPv6 node that is not a router.
* ULA:Unique Local Address, as defined in [RFC4193]. ULA: Unique Local Address, as defined in [RFC4193].
* GUA:Global Unique Addresses, as defined in [RFC4291]. GUA: Global Unicast Address, as defined in [RFC4291].
4. IPv6 End-User Network Architecture 4. IPv6 End-User Network Architecture
The end-user network for IPv6 that is a stub network. Figure 1 The end-user network for IPv6 that is a stub network. Figure 1
illustrates the model topology. illustrates the model topology.
+-----------+ +-----------+
| Service | | Service |
| Provider | | Provider |
| Router | | Router |
+-----+-----+ +-----+-----+
| |
| |
| Customer | Customer
| Internet Connection | Internet Connection
|
+-----v-----+
| IPv6 |
| CE |
| Router |
+-----+-----+
|
+------+-------+
| |
| |
+---+----+ +-----+-----+
| IPv6 | | |
| Host | | Router |
| | | |
+--------+ +-----+-----+
| |
+-----v-----+
| IPv6 |
| CE |
| Router |
+-----+-----+
| |
+------+-------+ +---+----+
| | | IPv6 |
| | | Host |
+---+----+ +-----+-----+ | |
| IPv6 | | | +--------+
| Host | | Router |
| | | |
+--------+ +-----+-----+
|
|
+---+----+
| IPv6 |
| Host |
| |
+--------+
Figure 1: Example IPv6 End User Topology Figure 1: Example IPv6 End-User Topology
5. Requirements 5. Requirements
IPv6 CE routers distribute configuration information obtained during IPv6 CE routers distribute configuration information obtained during
WAN interface provisioning to LAN-facing IPv6 hosts and routers. An WAN interface provisioning to LAN-facing IPv6 hosts and routers. A
[RFC7084] compliant CE router would only provide IPv6 hosts with CE router that is compliant with [RFC7084] would only provide IPv6
configuration information. This document allows for addressing and hosts with configuration information. This document allows for
routing of IPv6 prefixes to both hosts and routers. These addressing and routing of IPv6 prefixes to both hosts and routers.
requirements are in addition to the ones in Section 4.3 of [RFC7084]. These requirements are in addition to the ones in Section 4.3 of
[RFC7084].
5.1. LAN Prefix Delegation Requirements (LPD) 5.1. LAN Prefix Delegation Requirements (LPD)
LPD-1: IPv6 CE routers MUST support IPv6 prefix assignment LPD-1: Each IPv6 CE router MUST support IPv6 prefix assignment
according to Section 13.3 of [RFC8415] (Identity Association according to Section 13.3 of [RFC8415] (Identity Association
for Prefix Delegation (IA_PD) option) on its LAN for Prefix Delegation (IA_PD) option) on its LAN
interface(s). interface(s).
LPD-2: IPv6 CE routers MUST assign a prefix from the delegated LPD-2: IPv6 CE routers MUST assign a prefix from the delegated
prefix as specified by L-2 in Section 4.3 of [RFC7084]. If prefix as specified by L-2 in Section 4.3 of [RFC7084]. If
insufficient prefixes are available the IPv6 CE Router MUST insufficient prefixes are available, the IPv6 CE router MUST
log a system management error. log a system management error.
LPD-3: The prefix assigned to a link MUST NOT change in the absence LPD-3: The prefix assigned to a link MUST NOT change in the absence
of a local policy or a topology change. of a local policy or a topology change.
LPD-4: After LAN link prefix assignments, the IPv6 CE router MUST LPD-4: After LAN link prefix assignments, the IPv6 CE router MUST
keep the remaining IPv6 prefixes available to other routers keep the remaining IPv6 prefixes available to other routers
via Prefix Delegation. via Prefix Delegation.
LPD-5: IPv6 CE routers MUST maintain a local routing table that is LPD-5: IPv6 CE routers MUST maintain a local routing table that is
dynamically updated with leases and the associated next hops dynamically updated with leases and the associated next hops
as they are delegated to clients. When a delegated prefix as they are delegated to clients. When a delegated prefix
is released or expires, the associated route MUST be removed is released or expires, the associated route MUST be removed
from the IPv6 CE router's routing table. A delegated prefix from the IPv6 CE router's routing table. A delegated prefix
expires when the valid lifetime assigned in the IA_PD expires when the valid lifetime assigned in the IA_PD
expires without being renewed. When a prefix is released or expires without being renewed. When a prefix is released or
expires it MUST be returned the pool of available prefixes. expires, it MUST be returned the pool of available prefixes.
LPD-6: By default, the IPv6 CE router filtering rules MUST allow LPD-6: By default, the IPv6 CE router filtering rules MUST allow
forwarding of packets with an outer IPv6 header containing a forwarding of packets with an outer IPv6 header containing a
source address belonging to Delegated Prefixes, along with source address belonging to Delegated Prefixes, along with
reciprocal packets from the same flow, following the reciprocal packets from the same flow, following the
recommendations of [RFC6092]. This updates WPD-5 of recommendations of [RFC6092]. This updates WPD-5 of
[RFC7084] to not drop packets from prefixes that have been [RFC7084] to not drop packets from prefixes that have been
delegated. IPv6 CE routers MUST continue to drop packets delegated. IPv6 CE routers MUST continue to drop packets
including destination address that is not assigned to the including destination address that is not assigned to the
LAN or delegated. LAN or delegated.
LPD-7: The IPv6 CE routers MUST provision IA_PD prefixes with a LPD-7: The IPv6 CE routers MUST provision IA_PD prefixes with a
prefix-length of 64 on the LAN-facing interface unless prefix-length of 64 on the LAN-facing interface unless
configured to use a different prefix-length by the CE Router configured to use a different prefix-length by the CE router
administrator. The prefix length of 64 is used as that is administrator. The prefix length of 64 is used as that is
the current prefix length supported by SLAAC [RFC4862]. For the current prefix length supported by SLAAC [RFC4862]. For
hierarchical prefix delegation a prefix-length shorter than hierarchical prefix delegation, a prefix-length shorter than
64 may be configured. 64 may be configured.
LPD-8: IPv6 CE routers configured to generate a ULA prefix as LPD-8: IPv6 CE routers configured to generate a ULA prefix as
defined in ULA-1 of Section 4.3 of [RFC7084] MUST continue defined in ULA-1 of Section 4.3 of [RFC7084] MUST continue
to provision available GUA IPv6 prefixes. to provision available GUA IPv6 prefixes.
LPD-9: If an IPv6 CE router is provisioning both ULA and GUA via LPD-9: If an IPv6 CE router is provisioning both ULA and GUA via
prefix delegation, the GUA SHOULD appear first in the DHCPv6 prefix delegation, the GUA SHOULD appear first in the DHCPv6
packets. packets.
LPD-10: IPv6 CE routers MUST NOT delegate prefixes via DHCPv6 on the LPD-10: IPv6 CE routers MUST NOT delegate prefixes via DHCPv6 on the
LAN using lifetimes that exceed the remaining lifetimes of LAN using lifetimes that exceed the remaining lifetimes of
the corresponding prefixes learned on the WAN. the corresponding prefixes learned on the WAN.
6. Security Considerations 6. Security Considerations
This document does not add any new security considerations beyond This document does not add any new security considerations beyond
those mentioned in Section 4 of [RFC8213], Section 22 of [RFC8415] those mentioned in Section 4 of [RFC8213], Section 22 of [RFC8415],
and [RFC6092]. and Section 6 of [RFC6092].
7. IANA Considerations 7. IANA Considerations
This document makes no request of IANA. This document has no IANA actions.
8. Acknowledgements
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.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
skipping to change at page 7, line 30 skipping to change at line 294
between Servers and Relay Agents", RFC 8213, between Servers and Relay Agents", RFC 8213,
DOI 10.17487/RFC8213, August 2017, DOI 10.17487/RFC8213, August 2017,
<https://www.rfc-editor.org/info/rfc8213>. <https://www.rfc-editor.org/info/rfc8213>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
9.2. Informative References 8.2. Informative References
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
Capabilities in Customer Premises Equipment (CPE) for Capabilities in Customer Premises Equipment (CPE) for
Providing Residential IPv6 Internet Service", RFC 6092, Providing Residential IPv6 Internet Service", RFC 6092,
DOI 10.17487/RFC6092, January 2011, DOI 10.17487/RFC6092, January 2011,
<https://www.rfc-editor.org/info/rfc6092>. <https://www.rfc-editor.org/info/rfc6092>.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177, Assignment to End Sites", BCP 157, RFC 6177,
DOI 10.17487/RFC6177, March 2011, DOI 10.17487/RFC6177, March 2011,
<https://www.rfc-editor.org/info/rfc6177>. <https://www.rfc-editor.org/info/rfc6177>.
[eRouter] CableLabs, "IPv4 and IPv6 eRouter Specification Version [eRouter] CableLabs, "IPv4 and IPv6 eRouter Specification", Data-
I21", February 2022, Over-Cable Service Interface Specifications, Version I22,
May 2024,
<https://www.cablelabs.com/specifications/CM-SP-eRouter>. <https://www.cablelabs.com/specifications/CM-SP-eRouter>.
Acknowledgements
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.
Author's Address Author's Address
Timothy Winters Timothy Winters
QA Cafe QA Cafe
100 Main Street, Suite #212 100 Main Street, Suite #212
Dover, NH 03820 Dover, NH 03820
United States of America United States of America
Email: tim@qacafe.com Email: tim@qacafe.com
 End of changes. 39 change blocks. 
125 lines changed or deleted 128 lines changed or added

This html diff was produced by rfcdiff 1.48.