DHCPv6 Active Leasequery
updates
- rfc-5460 — DHCPv6 Bulk Leasequery
Extracted elements (31)
Active Leasequery sends only the current binding state rather than a complete history of all state transitions. If the TCP connection blocks, the server may create the message at the moment the connection becomes writable, discarding intermediate state changes — this is a deliberate trade-off favouring simplicity and real-time accuracy over completeness.
OPTION_LQ_BASE_TIME uses absolute time anchored to January 1, 2000 UTC (not Unix epoch) so that requestors can pass server-context timestamps back in OPTION_LQ_START_TIME without needing to know or correct for clock skew between requestor and server.
A DHCPv6 server supporting Bulk Leasequery but not Active Leasequery SHOULD respond to an ACTIVELEASEQUERY request with a LEASEQUERY-REPLY bearing status NotSupported and SHOULD close the connection.
A DHCPv6 server that supports Active Leasequery MUST support Bulk Leasequery (RFC 5460) as well.
All TLS connections established between a requestor and a DHCPv6 server for Active Leasequery MUST be mutually authenticated.
An ACTIVELEASEQUERY request MUST contain a transaction-id, and that transaction-id MUST be locally unique on the TCP connection on which it is sent.
Authentication for DHCP messages (RFC 3315) MUST NOT be used to attempt to secure transmission of the messages described in this document; TLS is the required security mechanism.
During catch-up phase, the requestor MUST NOT save OPTION_LQ_BASE_TIME values from received messages to use as a future OPTION_LQ_START_TIME, because catch-up data is not time-ordered.
Every Active Leasequery request MUST be made on a single TCP connection where there is no other request active at the time; parallel Active and Bulk Leasequeries MUST use different TCP connections.
If an Active or Bulk Leasequery request contains OPTION_LQ_BASE_TIME in OPTION_ORO, the DHCPv6 server MUST include OPTION_LQ_BASE_TIME in every reply for that request.
Once the transmission of messages associated with OPTION_LQ_START_TIME is complete, a LEASEQUERY-DATA message MUST be sent with a DHCPv6 status code of CatchUpComplete.
Operation in insecure mode MUST NOT be the default, even if secure mode is not supported; insecure mode MUST always require an explicit, separate configuration step.
OPTION_LQ_END_TIME MUST NOT be used in an Active Leasequery request; if it appears, the server SHOULD send a LEASEQUERY-REPLY with status MalformedQuery and terminate the connection.
Support for Active Leasequery MUST NOT be enabled by default and MUST require an explicit configuration step before it will operate.
The requestor MUST determine OPTION_LQ_START_TIME using lease information received from the DHCPv6 server; it MUST be an absolute time in the DHCPv6 server's context.
When operating in secure mode, the requestor MUST attempt to negotiate a TLS connection; if negotiation fails, the requestor MUST close the TCP connection. The requestor MUST validate the DHCPv6 server's digital certificate during the TLS handshake.
Active Leasequery uses a long-lived TCP connection to port 547 between the requestor and DHCPv6 server. The requestor sends a single ACTIVELEASEQUERY message and receives an unbounded stream of LEASEQUERY-REPLY and LEASEQUERY-DATA messages until the connection is closed.
The ACTIVELEASEQUERY message (type 22) requests real-time binding updates. If the requestor includes OPTION_LQ_START_TIME, the server enters a catch-up phase to send historical binding data before streaming live updates; omitting OPTION_LQ_QUERY receives all binding updates.
The catch-up phase occurs when ACTIVELEASEQUERY includes OPTION_LQ_START_TIME. The server sends historical binding data (possibly interleaved with real-time updates) until it signals completion with a LEASEQUERY-DATA containing status CatchUpComplete or DataMissing.
The STARTTLS message (type 23) is sent as the first message over a TCP connection to request TLS negotiation. It SHOULD be sent without options; any options received in it SHOULD be ignored.
Four new DHCPv6 status codes registered: DataMissing (12), CatchUpComplete (13), NotSupported (14), TLSConnectionRefused (15) in the IANA DHCPv6 'Status Codes' registry.
Three new DHCPv6 option codes registered: OPTION_LQ_BASE_TIME (100), OPTION_LQ_START_TIME (101), OPTION_LQ_END_TIME (102) in the IANA DHCPv6 'Option Codes' registry.
Two new DHCPv6 message types registered: ACTIVELEASEQUERY (22) and STARTTLS (23) in the IANA DHCPv6 'Message Types' registry.
Data acquired via Active Leasequery is as sensitive as the DHCPv6 server's lease database and SHOULD be secured by equally strong mechanisms; it SHOULD be deleted as soon as possible after use.
Servers SHOULD offer configuration to limit connection sources via TLS certificate validation and SHOULD limit simultaneous accepted connections and idle connection lifetime to mitigate resource exhaustion.
TCP-based Active Leasequery is vulnerable to connection exhaustion attacks: malicious requestors can establish connections but send invalid, partial, or no queries to exhaust the server's connection pool. Servers SHOULD limit the number of accepted connections and the duration idle connections remain open.
Active Leasequery connection lifecycle: TCP connect → optional TLS → send ACTIVELEASEQUERY → receive LEASEQUERY-REPLY (success or error) → receive stream of LEASEQUERY-DATA messages → connection closed by either side or LEASEQUERY-DONE with QueryTerminated ends the session.
TLS negotiation state for a new TCP connection: (1) requestor sends STARTTLS → (2a) no response / server closes / TLSConnectionRefused → requestor MUST close TCP; or (2b) server replies with REPLY (no status code) → (3) TLS handshake with mutual certificate validation → (4) if handshake fails requestor MUST close TCP; if succeeds, send ACTIVELEASEQUERY.
OPTION_LQ_BASE_TIME (code 100): option-len=4, base-time field is a 32-bit unsigned integer in network byte order representing seconds since midnight UTC January 1, 2000 (absolute time).
OPTION_LQ_END_TIME (code 102): option-len=4, query-end-time field is a 32-bit unsigned integer in network byte order; usable only in Bulk Leasequery requests to bound the time range of returned bindings.
OPTION_LQ_START_TIME (code 101): option-len=4, query-start-time field is a 32-bit unsigned integer in network byte order representing an absolute time in the DHCPv6 server's context; only bindings changed on or after this time are returned.