Summary
- RFC 9818 requires an IPv6 customer-edge router to offer DHCPv6 Prefix Delegation on its LAN, install a route toward each delegated client, admit the delegated source range under its default filtering policy, and remove the route when the lease is released or expires.
- A downstream valid lifetime may never exceed the remaining lifetime of the corresponding upstream prefix. A lease can therefore look valid in one database while the authority that sustains it has already contracted elsewhere.
- A local prefix-custody receipt should join parent delegation, client identity, next hop, route, filter, timers, packet observation and the exit from custody. This is Daniel Kade’s editorial proposal, not an RFC field or IETF requirement.
The easy inventory says that the router received a prefix. The useful question is whether any downstream router can carry traffic with a portion of it now.
Those statements are not equivalent. An access provider may delegate a block larger than /64 to a customer-edge router. The CE router can consume one part on its own LAN and still have space left. If it cannot act as a DHCPv6 Prefix Delegation server on its LAN-facing interfaces, however, that remainder cannot be handed to another router through the mechanism RFC 9818 describes. Capacity exists in the parent allocation and fails to exist at the point where a child needs it.
RFC 9818 closes that particular operational gap. It does not merely ask the CE router to emit an IA_PD lease. It binds delegation to route installation, forwarding treatment, expiry and pool reuse. The document’s ten LAN Prefix Delegation requirements turn one resource label into a sequence of state transitions controlled by different subsystems.
That sequence is the governance surface. If a dashboard records only the prefix or only the lease, it can tell the truth about one subsystem while giving a false answer about usable service.
The parent allocation and the child delegation are different claims
The upstream provider decides what block reaches the CE router and for how long. The CE router then decides which part serves a directly attached link and which remaining parts are available for downstream routers. RFC 9818’s default model is flat: after local link assignments, the router makes available prefixes directly to other routers on the LAN. A hierarchical model is possible when configured, but an unmanaged tree can become unbalanced and exhaust prefixes in one branch.
The distinction matters because “we delegated a /56” describes the provider-to-CE boundary, not the CE-to-child boundary. LPD-1 requires IA_PD support on LAN interfaces precisely because ordinary host configuration is not enough. LPD-2 requires each child assignment to come from the delegated parent and requires a system-management error when insufficient prefixes remain. An upstream lease can therefore be healthy while a downstream request legitimately fails.
LPD-3 adds conditional stability. A prefix assigned to a link must not change unless local policy or topology changes. That protects downstream identity from gratuitous renumbering, but it is not a promise of permanence. The evidence must preserve which policy or topology event justified a change instead of treating every change as a fault or every stable row as current.
LPD-4 keeps the unconsumed space available for other routers after link prefixes are assigned. This is a custody rule: the CE router may reserve what it needs, but must not silently strand the remainder. An address-management screen that subtracts allocated ranges can measure arithmetic availability. It still cannot prove that the DHCPv6 server, routing table and filters can make the remainder operational.
The route is part of the lease’s meaning
LPD-5 supplies the decisive join. The CE router maintains a local routing table that is dynamically updated with leases and their associated next hops. A child’s prefix is not merely a value in DHCP state. It is a destination that the parent must forward toward the router that received it.
That produces at least four separate observations: the server accepted the IA_PD exchange; the lease names a prefix and client context; a route for that prefix points to the correct next hop; and packets actually follow that route. None can stand in for the others. A Reply can be captured even if route installation fails. A route can outlive the lease because cleanup failed. A route can point at yesterday’s next hop after a topology change. Counters can rise on a broader aggregate without proving the child route carried the traffic.
Release and expiry make the obligation reversible. When a delegated prefix is released or its valid lifetime expires without renewal, RFC 9818 requires removal of the associated route and return of the prefix to the available pool. Those are two state changes, not one database delete. If the route disappears but the allocator does not reclaim the prefix, capacity leaks. If the allocator reissues it while the old route remains, custody overlaps. If both happen but a stale filter exception persists, the security surface no longer matches the resource surface.
A reliable account therefore needs the lease event and the route event with their own timestamps, result codes and observation sources. “Expired” should be a causal transition, not a label applied after reconciliation.
A filter can invalidate an otherwise correct delegation
RFC 9818 updates the default filtering requirement inherited from the CE-router baseline. Packets whose outer IPv6 source belongs to a delegated prefix, along with reciprocal packets in the same flow, must be permitted by default. Packets using addresses that are neither assigned to the LAN nor delegated must continue to be dropped.
This is more precise than saying the firewall is open. The permitted set is derived from current delegation state, and its legitimacy ends with that state. The same prefix can move from unavailable, to delegated, to expired. A static allow-list cannot express that lifecycle without an external join.
Filtering and routing can also disagree. A correct child route with a stale deny rule makes the lease unusable. A permissive rule with no current route can admit a source identity that the router no longer knows how to return to. A lease, route and filter may each pass their local health checks while their versions refer to different moments.
That is why a connectivity probe matters but cannot replace the control records. A successful packet proves one path at one time. It does not explain which lease authorized the source, whether the route was installed from that lease, how much lifetime remained or whether the apparent success used a different route. Running code closes the loop; it does not erase provenance.
The child clock cannot outrun the parent clock
LPD-10 establishes the temporal invariant: a CE router must not delegate a prefix on the LAN with lifetimes longer than the remaining lifetimes of the corresponding prefix learned on the WAN. A child cannot receive more durable authority than its parent still holds.
That rule is simple to state and easy to lose in distributed evidence. The parent valid lifetime is observed at one exchange and decreases with time. The child lease may be written by another process. Renewal, rebind, restart and clock behavior can change what each component believes. A stored duration without its observation time cannot be compared honestly with another stored duration.
The correct comparison is not “child value less than original parent value.” It is “child expiry no later than the current parent expiry derived from the same custody chain.” When the upstream prefix is renewed, downstream leases may be extended through their own valid exchanges. When the upstream lifetime contracts or renewal fails, the downstream system must not continue advertising an authority that the CE router no longer possesses.
LPD-7 adds another boundary. The default child length is /64, matching the current SLAAC model, unless the administrator chooses another length; a shorter prefix can support hierarchical delegation. Prefix length is therefore a policy input with architectural consequences, not a cosmetic field. LPD-8 and LPD-9 likewise keep GUA provisioning distinct from ULA generation and recommend placing GUA first when both appear. Local addressing does not substitute for global reachability.
A receipt for prefix custody
The prefix-custody receipt proposed here begins with the parent: WAN interface, delegated prefix, server and client identifiers, IA identity, preferred and valid expiry instants, renewal evidence and observation clock. It records the local link ranges taken from that parent and the remaining pool from which child delegations may be made.
For each child, the receipt binds the request and Reply to client identity, IA_PD, exact prefix and length, preferred and valid lifetimes, LAN interface and next-hop address. It then records the route-install transaction separately: table or routing domain, prefix, next hop, installation result, version and removal condition. The filtering record names the effective rule or derived state that admits the delegated source and reciprocal flow without preserving more traffic detail than the decision requires.
The outcome layer is deliberately modest: a bounded probe or packet observation, its direction, time and result. It is not a claim of permanent reachability. The exit layer is equally important: release, expiry, parent contraction, topology change or policy action; route removal; filter withdrawal; pool return; and confirmation that the prefix was not reissued before prior custody ended.
This receipt should remain local and access controlled. DHCP identifiers, topology and traffic observations can expose household or enterprise structure. The proposal does not require a central registry or a new wire format. It requires only that an operator stop promoting one subsystem’s success into an end-to-end verdict.
The RFC standardizes a baseline, not every network policy
RFC 9818 is Informational even though it uses normative language to establish common industry baseline functionality. It explicitly excludes multi-prefix networks with more than one provider because solving them requires additional routing, provisioning and policy. That is a scope boundary, not evidence that such networks are invalid.
The IETF defines the interoperable behavior described here. The provider controls the parent delegation. The CE-router software coordinates DHCPv6, routing and filtering. The administrator may choose prefix length, hierarchy and local policy. The downstream router operates the child network. Each actor has a different decision and a different proof burden.
Heng Lu’s running-code doctrine is useful because it prevents the RFC, the lease and the packet trace from being mistaken for one another. A standard can require a join. Only the implementation can perform it. Only observation can show that it happened in a specific system. Only the local authority can decide the acceptable policy when the join fails.
The durable conclusion is not that delegation is unreliable. It is that delegation is composite. Address space becomes usable capacity only when custody, forwarding permission and time agree—and it stops being capacity as soon as that agreement dissolves.
Sources
- IETF Datatracker record for RFC 9818
- Heng Lu: Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
- Heng Lu: On Why BTW Media Exists
- Heng Lu: The Policy Mirror
- RFC Editor record for RFC 9818
- RFC 4862: IPv6 Stateless Address Autoconfiguration
- RFC 6092: Recommended Simple Security Capabilities in CPE
- RFC 6177: IPv6 Address Assignment to End Sites
- RFC 7084: Basic Requirements for IPv6 CE Routers
- RFC 8200: Internet Protocol Version 6
- RFC 8213: Security of DHCPv6 Server-Relay Messages
- RFC 8415: DHCP for IPv6
- RFC 9818: DHCPv6 Prefix Delegation on CE-Router LANs
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
