DHCPv6 Leasequery
Extracted elements (25)
The on-demand query model (single request/response triggered by received traffic) has limitations with prefix delegation because an access concentrator after a reboot may not receive traffic to trigger queries, as it cannot inject routing for delegated prefixes without prior knowledge. This motivated discussion of an anticipatory query mode (not specified here, left as future work).
The leasequery capability parallels DHCPv4 leasequery (RFC 4388) and shares its design goals; differences arise from IPv6/DHCPv6 specifics such as using Neighbor Discovery instead of ARP and DOCSIS 3.0 IPv6 support for cable modem environments.
An OPTION_CLIENT_DATA in a LEASEQUERY-REPLY MUST minimally contain OPTION_CLIENTID, OPTION_IAADDR and/or OPTION_IAPREFIX, and OPTION_CLT_TIME. The server MUST return all statefully assigned addresses and delegated prefixes with non-zero valid lifetime on the link.
DHCPv6 servers SHOULD be configurable with a list of sensitive options that MUST NOT be returned to any requestor, even if explicitly requested via OPTION_ORO.
For QUERY_BY_CLIENTID with a 0::0 link-address, the server MUST search all links. If the client is on multiple links, the server MUST return OPTION_LQ_CLIENT_LINK and MUST NOT return any client data in OPTION_CLIENT_DATA.
If an OPTION_CLIENT_DATA received in a LEASEQUERY-REPLY contains no OPTION_CLT_TIME, the requestor SHOULD silently discard that OPTION_CLIENT_DATA.
OPTION_LQ_RELAY_DATA MUST NOT be returned if the server lacks relay agent information (client communicated directly or server did not retain the information). If returned, the DHCP-relay-message MUST be a valid RELAY-FORW message with the innermost OPTION_RELAY_MSG removed.
Requestors and clients MUST discard any received LEASEQUERY messages. Servers MUST discard received LEASEQUERY-REPLY messages.
Requestors MUST discard LEASEQUERY-REPLY messages that lack OPTION_SERVERID, lack or have a mismatched OPTION_CLIENTID, or have a mismatched transaction-id.
Servers MUST discard LEASEQUERY messages that lack OPTION_CLIENTID, include a non-matching OPTION_SERVERID, or lack OPTION_LQ_QUERY.
The requestor MUST include OPTION_CLIENTID to identify itself and MUST include OPTION_LQ_QUERY with appropriate query-type, link-address, and query-options when creating a LEASEQUERY message.
When resolving conflicting client data from different servers, the requestor SHOULD use OPTION_CLT_TIME and SHOULD accept the data with the most recent value.
Four new status codes are defined: UnknownQueryType (7), MalformedQuery (8), NotConfigured (9), and NotAllowed (10), used in OPTION_STATUS_CODE to convey leasequery-specific error conditions.
Retransmission parameters for LEASEQUERY: LQ_TIMEOUT = 1 second initial timeout, LQ_MAX_RT = 10 seconds maximum timeout, LQ_MAX_RC = 5 maximum retry attempts.
Two new DHCPv6 message types are defined: LEASEQUERY (14), sent by a requestor to obtain information on a client's leases, and LEASEQUERY-REPLY (15), sent by a server containing client data in response.
Two query types are defined: QUERY_BY_ADDRESS (1), which requires an OPTION_IAADDR in query-options and returns bindings for the client holding that address or delegated prefix; and QUERY_BY_CLIENTID (2), which requires an OPTION_CLIENTID and returns bindings for the specified client on a given or all links.
IANA assigned two new DHCPv6 message type codes (LEASEQUERY=14, LEASEQUERY-REPLY=15), five new option codes (OPTION_LQ_QUERY=44, OPTION_CLIENT_DATA=45, OPTION_CLT_TIME=46, OPTION_LQ_RELAY_DATA=47, OPTION_LQ_CLIENT_LINK=48), four new status codes (UnknownQueryType=7, MalformedQuery=8, NotConfigured=9, NotAllowed=10), and created a new query-type code registry (QUERY_BY_ADDRESS=1, QUERY_BY_CLIENTID=2) with Standards Action policy.
Access concentrators SHOULD minimize denial-of-service risk to DHCPv6 servers by employing negative caching (cache failed queries) and address restrictions (don't query for addresses outside attached broadband networks). Rate limiting by relay agents, network elements, or servers is also recommended.
LEASEQUERY and LEASEQUERY-REPLY messages should be secured using DHCPv6 authentication (RFC 3315 Section 21). For access concentrator requestors, IPsec-based security per RFC 3315 Section 21.1 SHOULD be used to prevent malicious servers from injecting incorrect lease or routing information.
Relay agents SHOULD prevent untrusted sources from relaying LEASEQUERY messages, at minimum at perimeter relay agents. DHCPv6 servers MAY discard relayed LEASEQUERY messages or restrict relay chaining to limit exposure.
OPTION_CLIENT_DATA (option code 45) encapsulates lease data for a single client on a single link in a LEASEQUERY-REPLY. Its option-len is the length in octets of the encapsulated client-options field.
OPTION_CLT_TIME (option code 46) encodes the Client Last Transaction Time as a 4-octet unsigned integer representing seconds since the server last communicated with the client on that link.
OPTION_LQ_CLIENT_LINK (option code 48) contains a list of 16-octet IPv6 link-addresses; option-len must be a multiple of 16. Used to indicate multiple links on which a client has bindings.
OPTION_LQ_QUERY (option code 44) carries the leasequery request. It contains a 1-octet query-type, a 16-octet link-address (IPv6), and variable-length query-options. Total option-len is 17 plus the length of query-options.
OPTION_LQ_RELAY_DATA (option code 47) contains a 16-octet peer-address (IPv6) followed by a variable-length DHCP-relay-message field holding the last RELAY-FORW message received by the server for the client, with the innermost OPTION_RELAY_MSG removed.