DHCPv4 Lease Query by Relay Agent Remote ID

Query by Remote ID allows an access concentrator (e.g., DSLAM) to proactively retrieve consolidated lease information for all clients on a circuit immediately after reboot, rather than waiting for client traffic. The Remote ID is pre-provisioned per circuit and survives reboots, making it a stable query key.

Query by Remote ID greatly reduces the impact of negative caching compared to the data-driven approach. Because the response provides definitive information about all nodes behind a connection, there is no need to re-query for the same Remote ID, eliminating periodic lease queries triggered by DHCPLEASEUNKNOWN.

The existing RFC 4388 query types are data-driven, requiring upstream client traffic before a relay agent can query lease information. This approach causes increased client outage time after relay agent reboot, excessive negative caching under spoofing attacks, and forces antispoofing into the slow path instead of the fast path.

realtime

The lease-binding data in DHCP servers SHOULD be indexed by Remote ID to allow efficient generation of DHCPLEASEACTIVE replies without requiring a full scan of lease records when processing a query by Remote ID.

If a query by IP address, MAC address, or Client Identifier also carries option 82 with a Remote ID sub-option, the query type is still determined by the primary query key (IP/MAC/Client ID) as specified in RFC 4388, not as a Remote ID query.

RFC 4388 Section 6.4 states that a DHCPLEASEUNKNOWN message MUST NOT have any other option present, but RFC 6148 overrides this: for a query by Remote ID, option 82 MUST be present in the DHCPLEASEUNKNOWN reply. Implementers extending RFC 4388 must account for this change.

This document is backward compatible with RFC 4388: a client supporting this extension can work with a server that only supports RFC 4388 query types, and an RFC 6148 server can work with a client that does not use the Remote ID query type.

After receiving a DHCPLEASEUNKNOWN response, the access concentrator SHOULD NOT attempt another DHCPLEASEQUERY to the same DHCP server with the same Remote ID sub-option. It MAY store the negative result for future use.

If more than one IP address has been involved in DHCP exchanges with the client identified by the Remote ID, the list of all those IP addresses MUST be returned in the Associated-IP option of the DHCPLEASEACTIVE response, regardless of whether it was in the Parameter Request List.

If no active lease corresponds to the Remote ID in the DHCPLEASEQUERY, the server MUST reply with a DHCPLEASEUNKNOWN message. Servers that do not implement lease query by Remote ID SHOULD simply not respond.

In a DHCPLEASEQUERY message for query by Remote ID: the ciaddr field MUST be set to zero, the values of htype, hlen, and chaddr MUST be set to zero, and the Client Identifier option (option 61) MUST NOT appear in the packet.

In a DHCPLEASEUNKNOWN response, the DHCP server MUST echo the option 82 received in the DHCPLEASEQUERY message. No other option is included in the DHCPLEASEUNKNOWN message.

The DHCP server MUST reply with a DHCPLEASEACTIVE message if there is an active lease corresponding to the Remote ID present in the DHCPLEASEQUERY message.

The DHCPLEASEQUERY message MUST contain a Relay Agent Information option (option 82) with only a Remote ID sub-option (sub-option 2); no other sub-options should be included.

The DHCPLEASEQUERY message SHOULD be sent to a DHCP server known to possess authoritative information for the Remote ID. In the absence of such knowledge, it SHOULD be sent to all configured DHCP servers.

The IP address placed in the ciaddr field of a DHCPLEASEACTIVE message MUST be the IP address with the latest client-last-transaction-time associated with the client described by the queried Remote ID.

The Parameter Request List option MUST be populated by the access concentrator with the Associated-IP option code in the DHCPLEASEQUERY message.

The server unicasts the DHCPLEASEACTIVE or DHCPLEASEUNKNOWN response to the address specified in the giaddr field of the DHCPLEASEQUERY message.

Upon receiving a DHCPLEASEACTIVE response, the access concentrator SHOULD use the htype, hlen, and chaddr fields as well as the Relay Agent Information option in the packet to refresh its location information for the returned IP address.

When multiple IP addresses have been accessed by the client identified by the Remote ID, the DHCP server MUST return the IP address from the most recent transaction in the ciaddr field, unless the administrator has configured a different preference mechanism.

DHCPLEASEACTIVE is the positive response to a lease query by Remote ID, indicating an active lease exists for the queried Remote ID. It includes the most recently assigned IP in ciaddr and all associated IP addresses in the Associated-IP option.

DHCPLEASEUNKNOWN is the negative response to a lease query by Remote ID, indicating the server has no active lease for the queried Remote ID or does not manage the client. It MUST echo option 82 from the query and include no other options.

The DHCPLEASEQUERY message uses DHCP message format from RFC 2131 with message type number 10 (option 53). It carries option 82 with only the Remote ID sub-option (sub-option 2) to identify the circuit/connection being queried.

The Remote ID sub-option is sub-option 2 of the Relay Agent Information option (option 82), as defined by RFC 3046. It globally and uniquely identifies the remote node connected to the access concentrator and is pre-provisioned per circuit.

A query by Remote ID returns consolidated lease-binding information for all nodes behind a connection. If performed by an unauthorized source, this could expose significant lease-binding data. Implementations MUST deploy DHCP message authentication per RFC 3118 to prevent unauthorized lease queries.

security