DHCPv6 Bulk Leasequery
updated by
- rfc-7653 — DHCPv6 Active Leasequery
Extracted elements (29)
LEASEQUERY-DATA messages are introduced to reduce redundant data when returning multiple bindings: the LEASEQUERY-REPLY carries common fields (Server-ID, Client-ID, status), and each LEASEQUERY-DATA carries only per-client binding data without repeating the common header.
TCP is used instead of UDP for Bulk Leasequery because at service-provider edges there may be many thousands of delegated prefixes per relay, making individual UDP queries inefficient or infeasible. TCP enables efficient bulk data transfer for large result sets.
The Relay-ID option uses a DUID rather than an IP address to identify relay agents because a relay may have multiple addresses or its address may change, while a DUID provides stable long-term identity suitable for associating bindings across relay replacements.
The TCP message framing defined in Section 5.1 (2-octet size prefix) is not compatible with the UDP message format. A TCP-framed request sent as a UDP message will have all protocol fields offset by the 2-byte message-size prefix and may not be valid.
A LEASEQUERY-REPLY without any bindings MUST NOT be followed by a LEASEQUERY-DONE message for the same transaction-id. If the transaction-id in a received LEASEQUERY-DONE does not match an outstanding LEASEQUERY, the client MUST close the TCP connection.
A relay SHOULD be able to generate a DUID for use in the Relay-ID option and store it in stable storage. A relay SHOULD also allow the DUID value to be configurable to preserve relay-to-binding associations when a relay agent is replaced.
Clients that are not able to process interleaved replies (based on transaction-id) MUST NOT send more than one query at a time on a single connection.
DHCPv6 servers that support Bulk Leasequery SHOULD listen for incoming TCP connections on port 547, which MUST be the default. Client implementations SHOULD connect to port 547.
Each query sent over a single connection MUST have a unique transaction-id. A server MUST NOT read more query messages from a connection than it is prepared to process simultaneously.
If the TCP connection becomes blocked while requestor is sending or receiving, the requestor SHOULD be prepared to terminate the connection after BULK_LQ_DATA_TIMEOUT (default 300 seconds). Same timeout applies to servers accepting connections or reading queries.
LEASEQUERY-DATA MUST ONLY be sent in response to a successful LEASEQUERY and only if more than one client's data is to be sent. The transaction-id field MUST match the originating LEASEQUERY request.
Only LEASEQUERY, LEASEQUERY-REPLY, LEASEQUERY-DATA, and LEASEQUERY-DONE messages are allowed over the Bulk Leasequery TCP connection. No other DHCPv6 messages are supported.
Requestors MUST NOT send the new Bulk Leasequery query-types (QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS, QUERY_BY_REMOTE_ID) in RFC 5007 UDP Leasequery query messages.
Servers MUST be able to limit the number of currently accepted and active connections; BULK_LQ_MAX_CONNS (default 10) MUST be the default. Implementations MAY permit the value to be configurable.
Servers that implement Bulk Leasequery and also permit UDP queries MUST NOT accept Bulk Leasequery query-types (QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS, QUERY_BY_REMOTE_ID) in UDP Leasequery messages, and MUST respond with a NotAllowed error status code.
The Client Link option MUST NOT appear in Bulk Leasequery replies. When multiple bindings are returned, the server uses LEASEQUERY-REPLY followed by LEASEQUERY-DATA messages instead of the Client Link option mechanism specified in RFC 5007.
The server MUST close its end of the TCP connection if it encounters an error sending data, or if it finds it must abort an in-process request. If the server detects the client end has been closed, it MUST close its end after finishing any outstanding requests.
QUERY_BY_LINK_ADDRESS asks the server to return bindings on a network segment identified by a link-address value from a relay's Relay-Forward message. The server locates bindings on the same network segment as the specified link-address.
QUERY_BY_RELAY_ID asks the server to return bindings associated with a relay identified by a DUID in a Relay-ID option. If link-address is 0::0, all bindings for that relay are returned; if link-address is specified, only bindings on that link are returned.
QUERY_BY_REMOTE_ID asks the server to return bindings associated with a Relay Agent Remote-ID option value. The query-options MUST include a Relay Agent Remote-ID option (RFC 4649). The server must have recorded Remote-ID values with its bindings to support this query.
The LEASEQUERY-DATA message carries binding data for a single DHCPv6 client on a single link and MUST be preceded by a LEASEQUERY-REPLY. It MUST contain an OPTION_CLIENT_DATA option; if absent, the message MUST be discarded. Its transaction-id MUST match the originating LEASEQUERY.
The LEASEQUERY-DONE message signals end of a group of related Leasequery replies. Its transaction-id MUST match the originating LEASEQUERY, and a single LEASEQUERY-DONE MUST be sent after all replies to a successful query that returned at least one binding. It MAY carry an OPTION_STATUS_CODE to indicate a server error.
The QueryTerminated status code (value 11) indicates the server is unable to perform or has prematurely terminated a query due to resource constraints or shutdown. The requestor may retry after a short wait interval.
IANA assignments for this document: OPTION_RELAY_ID (option code 53); QueryTerminated status code (11); LEASEQUERY-DONE message type (16); LEASEQUERY-DATA message type (17); query-types QUERY_BY_RELAY_ID (3), QUERY_BY_LINK_ADDRESS (4), QUERY_BY_REMOTE_ID (5) in the DHCPv6 OPTION_LQ_QUERY registry.
Servers MAY restrict Bulk Leasequery connections and LEASEQUERY messages to certain trusted clients. Connections from non-permitted clients SHOULD be closed immediately to avoid server connection resource exhaustion. Servers MAY also restrict clients to specific query types.
TCP connection exhaustion attacks — including SYN flooding and connections from malicious clients that send invalid, partial, or no queries — can exhaust server connection resources. Servers should limit connection sources, cap accepted connections and in-process queries, and enforce idle connection timeouts.
A Bulk Leasequery reply is complete under three conditions: (1) the LEASEQUERY-REPLY had no OPTION_CLIENT_DATA — complete on receipt of LEASEQUERY-REPLY; (2) LEASEQUERY-REPLY had OPTION_CLIENT_DATA — complete on receipt of LEASEQUERY-DONE; (3) otherwise — complete when the connection is closed.
Each DHCPv6 message sent over a Bulk Leasequery TCP connection is prefixed with a 2-octet message-size field in network byte order, followed by the standard DHCPv6 message (msg-type, transaction-id, options). The message-size field contains the count of octets in the following message.
The Relay-ID option (OPTION_RELAY_ID, code 53) carries a variable-length DUID identifying a relay agent. The format is: 2-octet option-code, 2-octet option-len (length of DUID in octets), followed by the DUID value.