Summary

  • A valid DHCPv6 Reply with IA_PD and IAPREFIX data establishes a prefix binding and its lifetimes; it does not observe a route, a forwarding entry or a working subscriber LAN.
  • Operational acceptance should join the DHCP transaction to access-network routing, CE state, LAN advertisements and prefix-specific traffic tests under one expiring generation.

The status screen looks reassuring. A residential gateway has received a /56, T1 and T2 are counting down, and the DHCPv6 client reports success. Yet a host on the LAN has no globally usable path. From outside the network, traffic toward an address inside the delegated block never reaches the customer edge. Nothing in the word “Reply” identifies which downstream step failed.

That ambiguity is built into the protocol boundary. RFC 8415 defines a Reply as the server message that carries assigned leases and configuration for several exchanges. For Prefix Delegation, an IA_PD holds one or more prefixes and the renewal timers T1 and T2; each IA Prefix adds a preferred lifetime and a valid lifetime. Those fields answer a precise question: what prefix may this client use, and for how long?

They do not answer whether the prefix is forwarding.

Delegation and routing are separate state

RFC 8415 is unusually helpful on this distinction. Prefix delegation does not itself require the client to forward packets not addressed to itself. After the server chooses and returns a prefix, the client becomes responsible for it. The client may divide the block into longer prefixes, assign them to downstream links and send Router Advertisements. Those are actions after the lease exchange, not facts contained in the Reply.

The access side also has work to do. When a DHCPv6 server reaches a client through a relay, RFC 8415 says another protocol or out-of-band communication may be needed to configure routing information on routers through which the client will forward traffic. A fully valid exchange can therefore coexist with a missing, stale or wrongly pointed route.

RFC 7084 adds the CE-router obligations. The router must support prefix delegation, cope with a delegated size different from its hint, and advertise derived prefixes on the LAN. It must also obtain and maintain appropriate WAN routing state. These are related requirements, but they are not one atomic transaction. A process can commit the IA_PD while another process fails to install a route, select a downstream /64 or emit a usable RA.

Even the aggregate is not a blanket reachability promise. RFC 7084 requires traffic for portions of the delegated block that the CE has not assigned to a LAN to resolve to a null destination and be dropped. Testing any arbitrary address inside the /56 would therefore confuse delegation scope with assigned-subnet reachability.

Read the complete receipt

A useful record starts with the actual exchange: client and server identifiers, transaction context, IAID, prefix and prefix length, status, T1, T2, preferred lifetime, valid lifetime and receipt time. It then records the access router that owns the route, the selected next hop, the RIB and FIB generation, and the subscriber session to which that state is attached.

At the CE, the record names the installed WAN default route, the delegated aggregate, the chosen LAN /64, the RA prefix-information lifetimes and the forwarding generation. Finally, it adds traffic observations in both directions. The probes must use an address inside the assigned LAN subnet, name their vantages and distinguish failure of the forward path from failure of the return path.

The receipt expires. RFC 9096 shows why restart and lifetime handling matter: stable IAID behavior reduces accidental renumbering, downstream lifetimes cannot exceed the remaining delegated lifetimes, and stale configuration must be signalled. A Renew, Rebind, restart, prefix change, route replacement or lifetime boundary invalidates evidence from the previous generation.

Sources