RFC 9818 INFORMATIONAL IPV6 · DHCPV6 · ROUTERS
CE router PD: DHCPv6 Prefix Delegation on IPv6 Customer Edge (CE) Routers in LANs
Rules for home and small-office routers to hand spare IPv6 prefixes on to other routers behind them.
RFC EDITOR
Winters, T., "DHCPv6 Prefix Delegation on IPv6 Customer Edge (CE) Routers in LANs", RFC 9818, DOI 10.17487/RFC9818, July 2025, <https://www.rfc-editor.org/info/rfc9818>.
BIBTEX
@misc{rfc9818,
series = {Request for Comments},
number = 9818,
howpublished = {RFC 9818},
publisher = {RFC Editor},
doi = {10.17487/RFC9818},
url = {https://www.rfc-editor.org/info/rfc9818},
author = {T. Winters},
title = {{DHCPv6 Prefix Delegation on IPv6 Customer Edge (CE) Routers in LANs}},
pagetotal = 7,
year = 2025,
month = jul,
} LINEAGE · FROM THE RFC INDEXOpen full graph →
RFC text
Contents
Internet Engineering Task Force (IETF) T. Winters Request for Comments: 9818 QA Cafe Updates: 7084 July 2025 Category: Informational ISSN: 2070-1721 DHCPv6 Prefix Delegation on IPv6 Customer Edge (CE) Routers in LANs Abstract This document defines requirements for IPv6 Customer Edge (CE) routers to support DHCPv6 Prefix Delegation for distributing available prefixes to LAN devices that were delegated to an IPv6 CE router. This document updates RFC 7084. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. 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 (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 2. Requirements Language 3. Terminology 4. IPv6 End-User Network Architecture 5. Requirements 5.1. LAN Prefix Delegation Requirements (LPD) 6. Security Considerations 7. IANA Considerations 8. References 8.1. Normative References 8.2. Informative References Acknowledgements Author's Address 1. Introduction This document describes guidelines for DHCPv6 Prefix Delegation in IPv6 Customer Edge (CE) routers [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 [RFC6177]. If an IPv6 CE router does not support the Identity Association for Prefix Delegation (IA_PD) Prefix Option (Section 21.21 of [RFC8415]) on the LAN, it will not be able to assign any prefixes beyond its local interfaces, limiting the usefulness of assigning prefixes larger than /64 by the operator. Supporting IA_PD on the LAN interfaces of a CE router will allow those unused prefixes to be distributed into a network. Note that efforts such as those of the Stub Networking Auto Configuration (SNAC) Working Group depend on IPv6 prefixes being properly distributed in the LAN. Two models, hierarchical prefix and flat, were proposed in the past for prefix sub-delegation beyond an IPv6 CE router. Hierarchical prefix delegation requires an IPv6 CE router to sub-delegate IPv6 prefixes based on a set of rules. If more than one router uses hierarchical prefix delegation, an IPv6 prefix tree is created. When no routing protocol is enabled to discover the network topology, it is possible to have an unbalanced prefix delegation tree, which leads to running out of prefixes. More information on hierarchical prefix delegation can be found, e.g., in Section 8.5 of CableLabs IPv6 eRouter specification [eRouter]. A flat prefix delegation requires the router to be provisioned with the initial prefix and to assign /64 prefixes to all other prefix requests from routers in the LAN- facing interface. The default configuration of CE routers is designed to be a flat model to support zero-configuration networking. This document does not cover dealing with multi-prefix networks with more than one provider. Due to the complexity of a solution that would require routing, provisioning, and policy, this is out of scope of this document. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses these keywords not strictly for the purpose of interoperability, but rather for the purpose of establishing industry-common baseline functionality. As such, the document points to several other specifications to provide additional guidance to implementers regarding any protocol implementation required to produce a successful CE router that interoperates successfully with a particular subset of currently deployed and planned common IPv6 access networks. 3. Terminology The document makes use of the following terms, some of which are from Section 2 of [RFC8200]. IPv6 node: A device that implements IPv6. IPv6 router: An IPv6 node that forwards IPv6 packets not explicitly addressed to itself. IPv6 host: An IPv6 node that is not a router. ULA: Unique Local Address, as defined in [RFC4193]. GUA: Global Unicast Address, as defined in [RFC4291]. 4. IPv6 End-User Network Architecture The end-user network for IPv6 contains stub networks. Figure 1 illustrates the model topology. +-----------+ | Service | | Provider | | Router | +-----+-----+ | | | Customer | Internet Connection | +-----v-----+ | IPv6 | | CE | | Router | +-----+-----+ | +------+-------+ | | | | +---+----+ +-----+-----+ | IPv6 | | | | Host | | Router | | | | | +--------+ +-----+-----+ | | +---+----+ | IPv6 | | Host | | | +--------+ Figure 1: Example IPv6 End-User Topology 5. Requirements IPv6 CE routers distribute configuration information obtained during WAN interface provisioning to LAN-facing IPv6 hosts and routers. A CE router that is compliant with [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 [RFC7084]. 5.1. LAN Prefix Delegation Requirements (LPD) 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). LPD-2: Each IPv6 CE routers 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. LPD-3: The prefix assigned to a link MUST NOT change in the absence of a local policy or a topology change. LPD-4: After LAN link prefix assignments, the IPv6 CE router MUST keep the remaining IPv6 prefixes available to other routers via Prefix Delegation. LPD-5: IPv6 CE routers MUST maintain a local routing table that is dynamically updated with leases and the associated next hops as they are delegated to clients. Absent explicit filtering, packets with destination addresses in a delegated prefix MUST be forwarded to that prefix regardless of which interface they are received on. When a delegated prefix is released or expires, the associated route MUST be removed from the IPv6 CE router's routing table. A delegated prefix expires when the valid lifetime assigned in the IA_PD expires without being renewed. When a prefix is released or expires, it MUST be returned the pool of available prefixes. LPD-6: By default, the IPv6 CE router filtering rules MUST allow forwarding of packets with an outer IPv6 header containing a source address belonging to delegated prefixes, along with reciprocal packets from the same flow, following the recommendations of [RFC6092]. This updates WPD-5 of [RFC7084] to not drop packets from prefixes that have been delegated. IPv6 CE routers MUST continue to drop packets, including destination address, that are not assigned to the LAN or delegated. LPD-7: The IPv6 CE routers MUST provision IA_PD prefixes with a prefix-length of 64 on the LAN-facing interface unless configured to use a different prefix-length by the CE router administrator. The prefix-length of 64 is used as that is the current prefix-length supported by SLAAC [RFC4862]. For hierarchical prefix delegation, a prefix-length shorter than 64 may be configured. LPD-8: IPv6 CE routers configured to generate a ULA prefix as defined in ULA-1 of Section 4.3 of [RFC7084] MUST continue to provision available GUA IPv6 prefixes. LPD-9: If an IPv6 CE router is provisioning both a ULA and GUA via prefix delegation, the GUA SHOULD appear first in the DHCPv6 packets. LPD-10: IPv6 CE routers MUST NOT delegate prefixes via DHCPv6 on the LAN using lifetimes that exceed the remaining lifetimes of the corresponding prefixes learned on the WAN. 6. Security Considerations This document does not add any new security considerations beyond those mentioned in Section 4 of [RFC8213], Section 22 of [RFC8415], and Section 6 of [RFC6092]. 7. IANA Considerations This document has no IANA actions. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>. [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <https://www.rfc-editor.org/info/rfc7084>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>. [RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged between Servers and Relay Agents", RFC 8213, DOI 10.17487/RFC8213, August 2017, <https://www.rfc-editor.org/info/rfc8213>. [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>. 8.2. Informative References [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>. [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, <https://www.rfc-editor.org/info/rfc6092>. [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, DOI 10.17487/RFC6177, March 2011, <https://www.rfc-editor.org/info/rfc6177>. [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>. 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 Timothy Winters QA Cafe 100 Main Street, Suite #212 Dover, NH 03820 United States of America Email: tim@qacafe.com
AI ELI5
On this page
PROBLEMService providers often delegate more than a /64 to a CE router, but if the router cannot delegate prefixes on its LAN, the extra space goes unused.
MECHANISMThe RFC adds ten requirements (LPD-1 to LPD-10): CE routers MUST support DHCPv6 Prefix Delegation (IA_PD) on the LAN, assign /64 prefixes by default, keep a routing table for delegated prefixes, and not delegate lifetimes beyond those learned on the WAN.
WHY IT MATTERSIt updates RFC 7084 and sets an industry-common baseline for CE routers. Multi-provider (multi-prefix) networks are out of scope.
§1Why CE Routers Must Delegate Prefixes
Many service providers assign address blocks larger than /64 to an IPv6 Customer Edge (CE) router, as recommended in RFC 6177. If the router does not support the Identity Association for Prefix Delegation (IA_PD) Prefix Option from RFC 8415 on the LAN, it cannot assign any prefixes beyond its own interfaces, and the larger allocation is of limited use.
Supporting IA_PD on the LAN lets those unused prefixes be distributed into the network. The RFC notes that work by the Stub Networking Auto Configuration (SNAC) Working Group depends on prefixes being properly distributed in the LAN.
If you get a whole box of numbered stickers but can only use the ones on your own door, the rest are wasted. Sharing them with other rooms makes the box useful.
§1.1Hierarchical and Flat Models
Two models were proposed for sub-delegation beyond a CE router. Hierarchical prefix delegation has the router sub-delegate prefixes by a set of rules. If more than one router does this, a prefix tree forms, and with no routing protocol to discover the topology the tree can become unbalanced and run out of prefixes.
A flat model provisions the router with the initial prefix and assigns /64 prefixes to every other prefix request arriving on the LAN-facing interface. The default configuration of CE routers is designed to be flat, to support zero-configuration networking.
Networks with more than one provider are out of scope, because a solution would need routing, provisioning and policy.
Either each helper splits its share again and again, which can leave some helpers with nothing, or one person hands out small equal pieces to everyone. The default is the simple, equal pieces.
§4The End-User Network
The model topology (Figure 1) has a service provider router, connected over the customer Internet connection to an IPv6 CE router. Behind the CE router are IPv6 hosts and another router, which in turn serves more IPv6 hosts. A CE router that follows only RFC 7084 gives configuration information to hosts. This document extends that so prefixes can be addressed and routed to both hosts and routers.
The new requirements are in addition to those in Section 4.3 of RFC 7084.
The internet company talks to your home router, and the home router talks to computers and to other routers that may have their own computers behind them.
- Service Provider Router
- IPv6 CE Router Customer Internet connection to the provider
- IPv6 Host
- Router
- IPv6 Host
- IPv6 CE Router Customer Internet connection to the provider
§5Assigning and Tracking Prefixes
The first group of LAN Prefix Delegation requirements says what the router does with the prefixes it holds.
- LPD-1: MUST support IA_PD prefix assignment (Section 13.3 of RFC 8415) on its LAN interfaces.
- LPD-2: MUST assign a prefix from the delegated prefix as in L-2 of RFC 7084, and MUST log a system management error if too few prefixes are available.
- LPD-3: the prefix assigned to a link MUST NOT change without a local policy or topology change.
- LPD-4: after assigning LAN links, MUST keep the remaining prefixes available to other routers via Prefix Delegation.
- LPD-5: MUST keep a local routing table updated with leases and next hops. Packets to a delegated prefix MUST be forwarded to it regardless of arrival interface, and the route MUST be removed, and the prefix returned to the pool, when it is released or its valid lifetime expires.
The router must be able to give out blocks, keep each room's block the same, save leftovers for other routers, and write down where each block went so mail finds the right door.
§5.1Filtering, Prefix Length and Lifetimes
The second group covers safety and details.
- LPD-6: by default, filtering MUST allow forwarding of packets whose source address is in a delegated prefix, with reciprocal packets of the same flow, following RFC 6092. This updates WPD-5 of RFC 7084. Packets whose addresses are neither assigned to the LAN nor delegated MUST still be dropped.
- LPD-7: MUST provision IA_PD prefixes with prefix-length 64 on the LAN unless an administrator configures otherwise, since 64 is what SLAAC supports. Hierarchical delegation may use a shorter length.
- LPD-8: a router generating a ULA prefix MUST continue to provision available GUA prefixes.
- LPD-9: when provisioning both ULA and GUA, the GUA SHOULD appear first in the DHCPv6 packets.
- LPD-10: MUST NOT delegate prefixes with lifetimes longer than the remaining lifetimes of the corresponding WAN prefixes.
Mail from handed-out blocks must be let through, blocks are normally one standard size, the public address is listed before the private one, and a block is never lent for longer than the router itself holds it.
- LPD-1IA_PD on LAN — MUST support prefix assignment on LAN interfaces.
- LPD-2Assign prefixes — MUST assign from the delegated prefix; log an error if short.
- LPD-3Stable prefixes — Link prefix MUST NOT change without policy or topology change.
- LPD-4Keep the rest — MUST keep remaining prefixes available for delegation.
- LPD-5Routing table — MUST track leases and next hops; remove routes on expiry.
- LPD-6Filtering — MUST allow delegated-prefix traffic; drop unassigned.
- LPD-7Prefix length 64 — MUST use /64 unless an administrator configures otherwise.
- LPD-8ULA and GUA — MUST continue to provision GUA prefixes with a ULA.
- LPD-9GUA first — GUA SHOULD appear first in the DHCPv6 packets.
- LPD-10Lifetimes — MUST NOT exceed remaining WAN prefix lifetimes.
§6Security Considerations
The document adds no new security considerations beyond those in Section 4 of RFC 8213, Section 22 of RFC 8415 and Section 6 of RFC 6092. It has no IANA actions. It also uses its keywords for establishing industry-common baseline functionality rather than strictly for interoperability.
Nothing new is risky here beyond what the older rules already cover.
§7References
[RFC7084]RFC 7084Singh, H., Beebee, W., Donley, C., and B. Stark, Basic Requirements for IPv6 Customer Edge Routers, RFC 7084, November 2013.November 2013[RFC8415]RFC 8415Mrugalski, T., et al., Dynamic Host Configuration Protocol for IPv6 (DHCPv6), RFC 8415, November 2018.November 2018[RFC6177]RFC 6177Narten, T., Huston, G., and L. Roberts, IPv6 Address Assignment to End Sites, BCP 157, RFC 6177, March 2011.March 2011[RFC6092]RFC 6092Woodyatt, J., Ed., Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service, RFC 6092, January 2011.January 2011[RFC4862]RFC 4862Thomson, S., Narten, T., and T. Jinmei, IPv6 Stateless Address Autoconfiguration, RFC 4862, September 2007.September 2007[RFC4193]RFC 4193Hinden, R. and B. Haberman, Unique Local IPv6 Unicast Addresses, RFC 4193, October 2005.October 2005