Active DHCPv4 Lease Query
updates
- rfc-6926 — DHCPv4 Bulk Leasequery
Extracted elements (31)
Active Leasequery transmits only the current binding state when the packet is created, not a full history of state changes. This is intentional: it avoids complexity while still allowing requestors to reconstruct important transitions if DHCP server lease-expiry and release hold-times are tuned to exceed the receive timeout.
The catch-up phase base-time must not be updated until CatchUpComplete is received because catch-up replies are not delivered in the order binding changes occurred; using an intermediate base-time would leave gaps in recovery if the connection drops mid-catch-up.
Two operational modes (secure/insecure) are provided because two distinct deployment models exist: requestors on arbitrary Internet locations need TLS with mutual certificate authentication; requestors co-located with the DHCP server inside a protected network can rely on perimeter security instead.
Active Leasequery reuses all message types and options defined for Bulk Leasequery (RFC 6926), including query-start-time, base-time, and dhcp-status-code, applying the same data encoding and clock-skew handling rules.
Applications should use an initial Bulk Leasequery (RFC 6926) to populate their binding database and then switch to Active Leasequery for continuous updates. If DataMissing is received during catch-up, the requestor SHOULD issue a DHCPBULKLEASEQUERY with query-start-time matching the original and query-end-time equal to the server's base-time from the DataMissing response.
System administrators SHOULD NOT allow a DHCPACTIVELEASEQUERY message to be sent over a DHCP TCP connection to a server that does not support Active Leasequery, because RFC 6926 did not specify behavior for unknown message types over TCP.
A DHCPACTIVELEASEQUERY request MUST NOT contain a ciaddr, chaddr, or dhcp-client-identifier, and MUST carry an xid unique on the connection.
A DHCPv4 server that supports Active Leasequery MUST also support Bulk Leasequery (RFC 6926).
A successful Active Leasequery reply carrying binding data MUST include a non-zero ciaddr. The requestor MUST be prepared to receive multiple replies per transaction and multiple copies of binding information for a single IPv4 address.
All TLS connections established between a requestor and a DHCPv4 server for Active Leasequery MUST be mutually authenticated using digital certificates.
During the catch-up phase, the requestor MUST NOT update the saved base-time from incoming messages; if the connection is lost before CatchUpComplete, the requestor MUST use the base-time from the previous connection in its subsequent DHCPACTIVELEASEQUERY request.
If the DHCPv4 server receives a DHCPv4 message with a dhcp-message-type that is not supported over a TCP connection (e.g., DHCPDISCOVER, DHCPLEASEQUERY), it MUST close the TCP connection. This updates RFC 6926.
Once catch-up data transmission is complete, the server MUST send a DHCPLEASEQUERYSTATUS with dhcp-status-code CatchUpComplete. A DHCPLEASEQUERYSTATUS with QueryTerminated MUST be the last message on the connection before the server closes it.
Only one DHCPACTIVELEASEQUERY is allowed on any one TCP connection at a time; parallel DHCPACTIVELEASEQUERY requests on the same TCP connection are not allowed. Parallel Active and Bulk Leasequery requests MUST use different connections.
Operation in insecure mode MUST NOT be the default even if secure mode is not supported; enabling insecure mode MUST always require an explicit, separate configuration step.
Support for Active Leasequery MUST NOT be enabled by default and MUST require an explicit configuration step before it will operate.
The associated-ip option MUST NOT be present in replies to Active Leasequery, since client-based queries (which trigger multiple bindings) are not supported.
The requestor MUST NOT assume that every lease state change is communicated across an Active Leasequery connection; the server is only required to transmit the current binding state when a packet is handed to TCP, so intermediate transitions may be lost.
When a requestor operates in secure mode, it MUST attempt TLS negotiation and MUST close the TCP connection if the TLS handshake fails or if the server does not support TLS. The requestor MUST validate the server's digital certificate during the TLS handshake.
Active Leasequery uses three new DHCPv4 message types: DHCPACTIVELEASEQUERY (16), DHCPLEASEQUERYSTATUS (17), and DHCPTLS (18), added to the dhcp-message-type option (option 53).
Four new dhcp-status-code values are defined: DataMissing (5), indicating requested binding data is unavailable; ConnectionActive (6), sent as a keepalive; CatchUpComplete (7), signaling end of the catch-up phase; and TLSConnectionRefused (8), indicating TLS is not permitted.
The DHCPTLS message initiates TLS negotiation over an existing TCP connection. The requestor sends DHCPTLS first; the server replies with DHCPTLS (no status code = success) or DHCPTLS with TLSConnectionRefused, or closes the connection. A successful exchange is followed by a TLS handshake.
The query-start-time option included in a DHCPACTIVELEASEQUERY request instructs the server to send binding changes that occurred since the specified time (catch-up information), in addition to real-time updates. The requestor SHOULD track the highest base-time received and place it in query-start-time upon reconnection.
Three connection and transmission parameters govern Active Leasequery behavior: ACTIVE_LQ_RCV_TIMEOUT (120 s, requestor's deadline for receiving any message), ACTIVE_LQ_SEND_TIMEOUT (120 s, server's deadline for unblocking a write), and ACTIVE_LQ_IDLE_TIMEOUT (60 s, idle keepalive interval).
IANA assigned four new values in the 'DHCP Status Code Type 151 Values' registry: DataMissing (5), ConnectionActive (6), CatchUpComplete (7), and TLSConnectionRefused (8).
IANA assigned three new values in the 'DHCP Message Type 53 Values' registry: DHCPACTIVELEASEQUERY (16), DHCPLEASEQUERYSTATUS (17), and DHCPTLS (18).
Data acquired via Active Leasequery is subject to the same abuse potential as the DHCP server's own lease state database and SHOULD be protected with equally strong mechanisms; it SHOULD be deleted as soon as its intended use has passed.
In insecure mode, the identity of the requestor is not validated, providing no authorization mechanism. Insecure mode is intended only for requestors co-located in protected network environments with the DHCP server.
TCP-based Active Leasequery is vulnerable to connection exhaustion attacks: malicious requestors can open connections and then send invalid, partial, or no queries to exhaust the server's connection pool. Servers SHOULD limit accepted connections and idle connection lifetime.
A DHCPACTIVELEASEQUERY connection has two phases. If query-start-time is present, it enters the catch-up phase (historical binding data, possibly interleaved with real-time updates); the catch-up phase ends when the server sends DHCPLEASEQUERYSTATUS with CatchUpComplete or DataMissing. After that (or immediately if no query-start-time), only real-time DHCPLEASEACTIVE/DHCPLEASEUNASSIGNED updates flow until the connection is closed or QueryTerminated is received.
Message framing for Active Leasequery over TCP uses the same 2-byte length-prefixed format defined for Bulk Leasequery (RFC 6926). When TLS is used, one DHCP message is carried per TLS record using the same framing.