Summary

  • DHCPv6 Prefix Delegation transfers use of a prefix to a requesting router; it does not tell the delegating router how the downstream topology is built.
  • The requesting router must turn the lease into stable link assignments, bounded lifetimes and routing state, while the CE router must keep lease-to-next-hop routes current.
  • Operations should close the gap with a delegation-to-route receipt that joins protocol state to bidirectional packet evidence.

The lease is green; the LAN is dark

Imagine a support console showing a successful IA_PD exchange. A downstream router has received a prefix, its preferred and valid lifetimes are counting down normally, and no DHCPv6 error is visible. Yet packets sent toward a server behind that router stop at the customer-edge device. The CE never installed the delegated prefix with the downstream router as next hop—or removed the route before the client stopped using the prefix.

Both dashboards can be internally truthful. DHCPv6 can report a valid delegation while the forwarding path is incomplete. The mistake is not a malformed lease. It is treating the lease as if it also attested to pool allocation, link assignment, Router Advertisement state, forwarding installation and reachability.

RFC 8415 draws the boundary clearly. Prefix Delegation is designed for cases in which the delegating router does not know the topology behind the requesting router. The server chooses a prefix and returns it; the client then becomes responsible for that prefix. It may subnet the block, assign subnets to interfaces and advertise them on downstream links. Those are subsequent acts, not properties carried by the IA_PD success state.

A delegation is a bounded transfer of responsibility

The useful operational unit is not merely “prefix present.” It is a tuple: client identity, IAID, delegated prefix, delegating server, T1, T2, preferred lifetime, valid lifetime and observation time. A renewal may extend those lifetimes, but RFC 8415 also allows a server to return a changed prefix set or to return an unsuitable prefix with zero lifetimes. A green renewal counter therefore needs its exact contents, not just a success label.

The lifetime hierarchy matters downstream. If the requesting router derives addresses or subprefixes from the delegation, their advertised preferred and valid lifetimes cannot exceed the remaining lifetimes of the parent prefix. Otherwise the LAN can retain apparently usable addresses after the upstream authority has expired. The resulting outage looks like a routing fault to users even though its cause is a broken time boundary.

RFC 9818 adds a second operational boundary for CE routers that delegate prefixes on LAN interfaces. The CE must support IA_PD toward downstream routers, assign from the available delegated pool and log a management error when the pool is insufficient. It must avoid changing a link prefix in the absence of policy or topology change. Most importantly for reachability, it must maintain a local route that follows each delegated lease and associated next hop, and remove that route when the lease is released or expires.

That sequence contains several independent failure points:

  1. The upstream ISP can delegate a block that is too small for the CE’s intended downstream topology.
  2. The CE can grant a subprefix but fail to reserve it consistently in its pool.
  3. The downstream router can receive the subprefix but fail to advertise it on the intended link.
  4. The CE can hold the lease record while lacking the matching next-hop route.
  5. Hosts can retain addresses whose advertised lifetime no longer fits within the parent delegation.
  6. Forward and return traffic can follow different policy or filtering paths.

None of those conditions is resolved by re-reading only the DHCP Reply.

Build the receipt from both sides of the boundary

A practical receipt begins with immutable observations rather than a synthetic “healthy” verdict. On the delegating side, record the server identity, client DUID, IAID, exact prefix and length, transaction time, T1/T2, preferred and valid lifetimes, and whether the response was an initial assignment, Renew, Rebind, Release or expiry. On the requesting side, record the received tuple, the child prefixes actually assigned to links or routers, the inherited lifetime values and the configuration generation that made the decision.

Then attach forwarding evidence. Capture the CE route for each child prefix, its next hop and interface, the time it was installed, the policy or filter that can suppress it, and the event that removes it. On the downstream router, record the connected or delegated route, Router Advertisement state and the address-selection state that clients are expected to use. Finally, run packet tests in both directions from the relevant service boundary. A ping from the CE is not enough if the service depends on DNS, stateful filtering, source-address selection or an asymmetric return path.

The receipt should be evaluated at four moments: initial delegation, renewal, topology or policy change, and withdrawal or expiry. The same prefix string at two timestamps does not mean the same operational state. Next hop, pool ownership, lifetimes, advertisements and filters may have changed around it.

Keep the scope honest

This control does not turn DHCPv6 into a topology protocol. It respects the protocol’s division of labour: the delegating router can issue a prefix without knowing the downstream network, while the requesting router decides how to use it. The receipt joins evidence held by different systems without pretending that one system owns the whole truth.

It also does not solve multi-provider source selection or routing policy. RFC 9818 explicitly leaves multi-prefix networks with more than one provider outside its scope because routing, provisioning and policy make them more complex. An operator using several upstreams must add its own source-address selection, egress policy, failure-domain and return-path evidence rather than stretching a single-provider receipt beyond its facts.

Sources