Summary

  • RFC 5007 defines a query-only exchange: even a successful reply with client data reports a DHCPv6 server’s binding view, not a live-presence, identity or authorization verdict.
  • A defensible operational claim must preserve which servers were queried, which reply variant arrived, how link fan-out and conflicting data were handled, what local state changed and what outcome was separately observed.

An operations console receives a successful LEASEQUERY-REPLY. Client data are present, the local row is refreshed and the indicator turns green: endpoint online.

Only the first two events follow from the protocol.

RFC 5007 defines DHCPv6 Leasequery as a lightweight way for a requestor to retrieve binding information held by DHCPv6 servers. Its motivating on-demand case is an access concentrator that has observed an IPv6 packet and wants to refresh its information about the client to which that address is currently leased. The document is explicit that LEASEQUERY is query-only: it changes neither address or prefix state nor the binding associated with it.

That boundary is easy to lose in an executive view. A server-held binding is an administrative fact about the server’s knowledge. A packet is a network observation. A route or filter is an enforcement state. A subscriber name is an identity claim. Authorization is a decision. These facts may inform one another, but RFC 5007 does not make them interchangeable.

The reply itself has more than one successful shape. If the server has bindings, it returns OPTION_CLIENT_DATA, which the requestor uses to update its local binding information. If the server finds bindings on several links, it returns OPTION_LQ_CLIENT_LINK; the requestor must query each returned link to obtain the bindings. If the server has no bindings, a successful reply contains neither client data nor the client-link option. “Protocol success” can therefore mean data, an index to more work or an empty answer.

Failure is also not a universal absence statement. An error can lead the requestor to try another server, correct the query, multicast to multiple servers or stop, according to local policy. RFC 5007 says a requestor should use the server known to hold authoritative information. If it cannot identify that server, it should query all servers it knows or is configured with. Stopping after one reply may be legitimate policy; it is not evidence that every relevant authority agreed.

Multi-server results create another boundary. Data can be disjoint—for example, an address from one server and a delegated prefix from another—and should be merged. The same binding reported by different servers is overlapping, or conflicting, data. The requestor should prefer the report with the most recent OPTION_CLT_TIME.

The verified RFC 5007 errata prevent a particularly damaging shortcut. The original text said client data without OPTION_CLT_TIME should be discarded. Technical Erratum 3763 removes that instruction. A failover partner may hold a valid binding without having the client’s last-transaction time. If another response carries the time, it should be preferred; if the untimed response is the only one available, its data can still be accepted. Editorial Erratum 4816 also corrects OPTION_CLIENT_LINK to the registered name OPTION_LQ_CLIENT_LINK.

OPTION_CLT_TIME still cannot prove presence. It is the server’s measure of elapsed time since its last transaction with the client when it builds the reply. It is not a packet timestamp from the endpoint, a physical-presence sensor, a credential, a subscriber identity or an access-control verdict. “More recent among the server reports received” is narrower than “online now.”

The reboot case shows why the distinction matters. On-demand Leasequery is triggered by an immediate need, often an observed packet. With delegated prefixes, however, traffic may never arrive after an access concentrator reboots because the concentrator cannot yet inject the required route. RFC 5007 discusses rebuilding a broader internal store in anticipation of traffic, then states that this anticipatory query is not specified there. Later work separates the mechanisms: RFC 5460 defines Bulk Leasequery, while RFC 7653 defines Active Leasequery notifications. A point response should not inherit the properties of a bulk recovery or continuing update channel.

Security controls make the returned view more trustworthy without making it complete or externally true. RFC 5007 discusses DHCP authentication and IPsec for appropriate requestors. It also notes that trusted relays can carry requests from untrusted origins, that servers may restrict relayed queries, and that even trusted requestors may receive reduced client information. A malicious server can return incorrect lease or route data. Authentication can establish who participated in an exchange; it cannot certify that the participant’s stored claim matches current reality.

Negative caching has a similarly narrow meaning. To protect DHCP servers from request floods, a requestor should cache the fact that a recent query failed to return client data and avoid querying addresses outside the attached network. The cache is a resource-control memory. It is not durable proof that no binding, device or authorized user exists.

A defensible binding-view receipt should preserve:

  1. the observed trigger, query type, address or DUID and link context;
  2. the intended authoritative server set and the reason each server was included or omitted;
  3. every request, response, authentication and relay context, retry and stop reason;
  4. the exact reply variant—client data, link list, empty success or error—and any field restriction;
  5. every follow-up link query, disjoint-data merge and overlapping-data decision;
  6. the presence or absence of OPTION_CLT_TIME and the preference rule actually applied;
  7. the negative-cache entry and the revision of the requestor’s retained binding state;
  8. the separate route, filter or authorization decision; and
  9. the packet or endpoint outcome observed after that decision.

This receipt is a governance recommendation, not an undisclosed requirement of RFC 5007. It applies Heng Lu’s reality-layer discipline: retain the server representation, the exchange, the local state, the enforcement act and the observed effect as separate objects until evidence joins them.

RFC 7513 shows why the separation is operationally useful. SAVI systems can use Leasequery while rebuilding binding state, but a protocol binding used by an enforcement function is still not a verified human identity or a proof that the endpoint is present. The original DHCPv6 and prefix-delegation context appears in RFC 3315 and RFC 3633; later DHCPv6 specifications, including RFC 8415 and RFC 9915, do not erase the evidence boundary of a captured RFC 5007 exchange.

The leadership question is therefore not “did Leasequery succeed?” It is “which server view was returned, what reconciliation remained, what local state changed, and what independent observation supports the claim we want to make?”

Sources