Dynamic Host Configuration Protocol (DHCP) Leasequery
updated by
- rfc-6148 — DHCPv4 Lease Query by Relay Agent Remote ID
Extracted elements (31)
Broadcast ARP was rejected as an alternative because it burdens the access concentrator with transmitting over multiple ports/circuits, burdens subscriber hosts with processing broadcasts, and is easily defeated by malicious hosts masquerading as the legitimate IP endpoint.
Query by IP address is identified as the most efficient form of leasequery for most DHCP servers and SHOULD be used when possible, because the server can directly look up the binding by IP rather than searching by MAC or Client-identifier.
SNMP and LDAP were rejected because access concentrators typically do not implement SNMP management client interfaces or LDAP client interfaces, and the DHCP Server MIB targets aggregate server statistics rather than per-lease detail. DHCPLEASEQUERY is also optional and would be awkward to define as an optional MIB object.
The protocol is deliberately restricted to DHCPv4 only. At the time of writing, DHCPv6 was not widely deployed and the needs of access concentrators in DHCPv6 scenarios were too speculative to design for; designing protocol capabilities for an imagined consumer was considered inadvisable.
Servers that do not implement the DHCPLEASEQUERY message SHOULD simply not respond. When an access concentrator receives no response, it cannot distinguish between packet loss and a non-supporting server, and SHOULD use exponential backoff per RFC 2131 Section 4.1 for retransmission.
A DHCPLEASEQUERY message MUST have a non-zero giaddr, and MUST have exactly one of the following: a non-zero ciaddr, a non-zero htype/hlen/chaddr, or a Client-identifier option (option 61).
A server that implements the DHCPLEASEQUERY message MUST implement all three query regimes: query by IP address, query by MAC address, and query by Client-identifier option.
DHCP server implementations supporting DHCPLEASEQUERY MUST save the most recent Relay Agent Information option (option 82) and client-last-transaction-time with each binding; vendor-class-id (option 60) SHOULD also be stored.
DHCP servers SHOULD be configurable with a list of 'non-sensitive options' returnable via DHCPLEASEQUERY; any option not on this list SHOULD NOT be returned even if requested, to limit information exposure.
For query by Client-identifier, a Client-identifier option (option 61) MUST appear in the DHCPLEASEQUERY message, ciaddr MUST be zero, and htype/hlen/chaddr MUST be zero.
For query by IP address, htype/hlen/chaddr MUST be zero, ciaddr MUST be set to the lease IP address to query, and the Client-identifier option MUST NOT appear in the packet.
For query by MAC address, htype/hlen/chaddr MUST carry the MAC address to search for, ciaddr MUST be zero, and the Client-identifier option MUST NOT appear in the packet.
If the giaddr field is zero in a received DHCPLEASEQUERY message, the DHCP server MUST NOT reply.
If the IP Address Lease Time option (option 51) is requested and a currently valid lease exists, the server MUST return this option with the remaining time until expiration; if no valid lease exists, the server MUST NOT return it.
The client-last-transaction-time option MUST NOT be an absolute time and MUST NOT be seconds since January 1, 1970; it MUST be an integer number of seconds into the past from when the DHCPLEASEACTIVE message is sent.
The giaddr in a DHCPLEASEQUERY MUST NOT be used to restrict query processing in any way and MUST NOT be used to locate a subnet to which the ciaddr must belong; it serves only as the return address for the server's response.
When more than one IP address has been involved in a DHCP exchange with the specified client, the list of all IP addresses MUST be returned in the associated-ip option, whether or not it was requested in the Parameter Request List.
When responding with DHCPLEASEUNKNOWN, the DHCP server MUST NOT include other DHCP options in the response.
When the DHCP server responds to a DHCPLEASEQUERY, it MUST use the saved Relay Agent Information option in the same manner it did when originally responding to the DHCP client, in order to return consistent option values.
When two DHCP servers cooperate for high availability, they MUST ensure that Relay Agent Information option data is communicated between them in addition to other IP address binding information, to properly support DHCPLEASEQUERY.
The DHCPLEASEQUERY response can expose sensitive location information, specifically the mapping of a hardware (MAC) address to an IP address lease, which constitutes an invasion of broadband subscriber privacy. Servers should use RFC 3118 authentication and non-sensitive option lists to limit this exposure.
Four new DHCP message types are defined: DHCPLEASEQUERY (value 10), DHCPLEASEUNASSIGNED (value 11), DHCPLEASEUNKNOWN (value 12), and DHCPLEASEACTIVE (value 13), extending the message type option (option 53) table from RFC 2132.
The DHCPLEASEQUERY message is transmitted from a relay agent (access concentrator) to a DHCP server using UDP on port 67, reusing the standard DHCP message format from RFC 2131. It is a query-only message and does not affect the state of IP address bindings.
Three query regimes are defined: query by IP address (ciaddr set, MAC and Client-identifier absent), query by MAC address (htype/hlen/chaddr set, ciaddr zero), and query by Client-identifier option (option 61 present, ciaddr and MAC zero). A server MUST implement all three.
IANA assigned four new DHCP message type values (option 53 extension): DHCPLEASEQUERY=10, DHCPLEASEUNASSIGNED=11, DHCPLEASEUNKNOWN=12, DHCPLEASEACTIVE=13; and two new DHCP option codes: client-last-transaction-time=91 and associated-ip=92.
Access concentrators SHOULD minimize potential DoS attacks on DHCP servers by employing negative caching of DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses, and by restricting ciaddr values to the range of attached broadband networks, limiting traffic to at most one DHCPLEASEQUERY per legitimate IP address after a reboot.
DHCP servers MAY be configured with the IP addresses of authorized relay agents permitted to send DHCPLEASEQUERY messages, to thwart unsophisticated attacks, though this does not provide cryptographic security.
DHCP servers SHOULD prevent unauthorized exposure of location information (hardware address to IP address mappings, which can invade subscriber privacy) by employing RFC 3118 authentication for DHCP messages; DHCPLEASEQUERY senders are treated as DHCP clients for this purpose.
The access concentrator maintains a per-server timer for DHCPLEASEQUERY retransmission. In the initial/expired state, only one outstanding message is allowed; after receiving a response the timer starts (1 minute), allowing up to 100-200 parallel queries using RFC 2131 exponential backoff. When the timer expires, all outstanding queries are dropped except one polling query sent at ~64-second intervals.
The associated-ip option (code 92, minimum 4 octets, length always a multiple of 4) returns all IP addresses associated with the queried DHCP client, with each address encoded as 4 octets.
The client-last-transaction-time option (code 91, length 4 octets) encodes the number of seconds in the past from message-send time when the client last transacted with the server about this IP address. It MUST NOT be an absolute time or seconds-since-epoch value.