return any information that it has on the IP address most
recently accessed by a client with that Client-identifier. In
addition, it may supply additional IP addresses that have been
associated with Client-identifier in different subnets.
Information about these bindings can then be found using the
Query by IP Address, described above.
The DHCP server replies with a DHCPLEASEACTIVE message if the
Client-identifier in the DHCPLEASEQUERY message currently has an
active lease on an IP address in this DHCP server. The server
replies with a DHCPLEASEUNKNOWN message if the server does not
have an active lease by a client with this Client-identifier.
For many DHCP servers, the query by IP address is likely to be the
most efficient form of leasequery. This is the form of
DHCPLEASEQUERY that SHOULD be used if possible.
The DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message reply must always
contain the IP address in the "ciaddr" field. The DHCPLEASEACTIVE
message SHOULD contain the physical address of the IP address lease
owner in the "htype", "hlen", and "chaddr" fields. The Parameter
Request List (option 55) can be used to request specific options to
be returned about the IP address in the ciaddr. The reply often
contains the time until expiration of the lease, and the original
contents of the Relay Agent Information option [RFC3046]. The access
concentrator uses the "chaddr" field and Relay Agent Information
option to construct location information, which can be cached on the
access concentrator until lease expiration.
Any DHCP server that supports the DHCPLEASEQUERY message SHOULD save
the information from the most recent Relay Agent Information option
(option 82) [RFC3046] associated with every IP address that it
serves. It is assumed that most clients that generate the
DHCPLEASEQUERY message will ask for the Relay Agent Information
option (option 82) in the Parameter Request List (option 55), and so
supporting the DHCPLEASEQUERY message without having the Relay Agent
Information option around to return to the client is likely to be
less than helpful.
A server that implements DHCPLEASEQUERY SHOULD also save the
information on the most recent Vendor class identifier, option 60,
associated with each IP address, since this option is also likely to
be requested by clients sending the DHCPLEASEQUERY message.
6. Protocol Details
6.1. Definitions Required for DHCPLEASEQUERY Processing
The operation of the DHCPLEASEQUERY message requires the definition
of the following new and extended values for the DHCP packet beyond
those defined by [RFC2131] and [RFC2132]. See also Section 8, IANA
Considerations.
1. The message type option (option 53) from [RFC2132] requires
four new values: one for the DHCPLEASEQUERY message itself and
one for each of its three possible responses
DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, DHCPLEASEUNKNOWN. The
values of these message types are shown below in an extension
of the table from section 9.6 of [RFC2132]:
Value Message Type
----- ------------
10 DHCPLEASEQUERY
11 DHCPLEASEUNASSIGNED
12 DHCPLEASEUNKNOWN
13 DHCPLEASEACTIVE
2. There is a new option, the client-last-transaction-time:
client-last-transaction-time
This option allows the receiver to determine the time of the
most recent access of the client. It is particularly useful
when DHCPLEASEACTIVE messages from two different DHCP servers
need to be compared, although it can be useful in other
situations. The value is a duration in seconds from the
current time into the past when this IP address was most
recently the subject of communication between the client and
the DHCP server.
This MUST NOT be an absolute time. This MUST NOT be an
absolute number of seconds since Jan. 1, 1970. Instead, this
MUST be an integer number of seconds in the past from the time
the DHCPLEASEACTIVE message is sent that the client last dealt
with this server about this IP address. In the same way that
the IP Address Lease Time option (option 51) encodes a lease
time that is a number of seconds into the future from the time
the message was sent, this option encodes a value that is a
number of seconds into the past from when the message was
sent.
The code for the this option is 91. The length of the this
option is 4 octets.
Code Len Seconds in the past
+-----+-----+-----+-----+-----+-----+
| 91 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
3. There in a second new option, the associated-ip option:
associated-ip
This option is used to return all of the IP addresses
associated with the DHCP client specified in a particular
DHCPLEASEQUERY message.
The code for this option is 92. The minimum length for this
option is 4 octets, and the length MUST always be a multiple
of 4.
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 92 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
6.2. Sending the DHCPLEASEQUERY Message
The DHCPLEASEQUERY message is typically sent by an access
concentrator. The DHCPLEASEQUERY message uses the DHCP message
format as described in [RFC2131], and uses message number 10 in the
DHCP Message Type option (option 53). The DHCPLEASEQUERY message has
the following pertinent message contents:
o The giaddr MUST be set to the IP address of the requester (i.e.,
the access concentrator). The giaddr is independent of the
"ciaddr" field to be searched -- it is simply the return address
of the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN
message from the DHCP server.
Note that this use of the giaddr is consistent with the
definition of giaddr in [RFC2131], where the giaddr is always
used as the return address of the DHCP response message. In some
(but not all) contexts in RFC 2131, the giaddr is used as the
"key" to access the appropriate address pool. The DHCPLEASEQUERY
message is one of those cases where the giaddr MUST NOT be used
as such a "key".
o The Parameter Request List option (option 55) SHOULD be set to
the options of interest to the requester. The interesting
options are likely to include the IP Address Lease Time option
(option 51), the Relay Agent Information option (option 82), and
possibly the Vendor class identifier option (option 60). In the
absence of a Parameter Request List option, the server SHOULD
return the same options it would return for a DHCPREQUEST message
that didn’t contain a DHCPLEASEQUERY message, which includes
those mandated by Section 4.3.1 of [RFC2131] as well as any
options that the server was configured to always return to a
client.
Additional details concerning different query types are:
o Query by IP address:
The values of htype, hlen, and chaddr MUST be set to zero.
The "ciaddr" field MUST be set to the IP address of the lease to
be queried.
The Client-identifier option (option 61) MUST NOT appear in the
packet.
o Query by MAC address:
The values of htype, hlen, and chaddr MUST be set to the value
of the MAC address to search for.
The "ciaddr" field MUST be set to zero.
The Client-identifier option (option 61) MUST NOT appear in the
packet.
o Query by Client-identifier option:
There MUST be a Client-identifier option (option 61) in the
DHCPLEASEQUERY message.
The "ciaddr" field MUST be set to zero.
The values of htype, hlen, and chaddr MUST be set to zero.
The DHCPLEASEQUERY message SHOULD be sent to a DHCP server which is
known to possess authoritative information concerning the IP address.
The DHCPLEASEQUERY message MAY be sent to more than one DHCP server,
and in the absence of information concerning which DHCP server might
possess authoritative information concerning the IP address, it
SHOULD be sent to all DHCP servers configured for the associated
relay agent (if any are known).
Any device expecting to use a DHCPLEASEQUERY message SHOULD ensure
that the Relay Agent Info option that it uses contains information
that unambiguously identifies the device.
6.3. Receiving the DHCPLEASEQUERY Message
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.
A DHCPLEASEQUERY message MUST have a non-zero giaddr. The
DHCPLEASEQUERY message MUST have exactly one of the following: a
non-zero ciaddr, a non-zero htype/hlen/chaddr, or a Client-identifier
option.
The DHCP server that receives a DHCPLEASEQUERY message MUST base its
response on the particular data item used in the query.
The giaddr is used only for the destination address of any generated
response and, while required, is not otherwise used in generating the
response to the DHCPLEASEQUERY message. It MUST NOT be used to
restrict the processing of the query in any way, and MUST NOT be used
locate a subnet to which the ciaddr (if any) must belong.
Note that this use of the giaddr is consistent with the definition of
giaddr in [RFC2131], where the giaddr is always used as the return
address of the DHCP response message. In some (but not all) contexts
in RFC 2131, the giaddr is used as the "key" to access the
appropriate address pool. The DHCPLEASEQUERY message is one of those
cases where the giaddr MUST NOT be used as such a "key".
6.4. Responding to the DHCPLEASEQUERY Message
There are three possible responses to a DHCPLEASEQUERY message:
o DHCPLEASEUNASSIGNED
The server MUST respond with a DHCPLEASEUNASSIGNED message if
this server has information about the IP address, but there is
no active lease for the IP address. The DHCPLEASEUNASSIGNED
message is only returned for a query by IP address, and
indicates that the server manages this IP address, but there is
no currently active lease on this IP address.
o DHCPLEASEUNKNOWN
The DHCPLEASEUNKNOWN message indicates that the server does not
manage the IP address or the client specified in the
DHCPLEASEQUERY message does not currently have a lease on an IP
address.
When responding with a DHCPLEASEUNKNOWN, the DHCP server MUST
NOT include other DHCP options in the response.
o DHCPLEASEACTIVE
The DHCPLEASEACTIVE message indicates that the server not only
knows about the IP address and client specified in the
DHCPLEASEACTIVE message, but also knows that there is an active
lease by that client for that IP address.
The server MUST respond with a DHCPLEASEACTIVE message when the
IP address returned in the "ciaddr" field is currently leased.
6.4.1. Determining the IP address about Which to Respond
Since the response to a DHCPLEASEQUERY request can only contain full
information about one IP address -- the one that appears in the
"ciaddr" field -- determination of which IP address about which to
respond is a key issue. Of course, the values of additional IP
addresses for which a client has a lease must also be returned in the
associated-ip option (Section 6.1, #3). This is the only information
returned not directly associated with the IP address in the "ciaddr"
field.
In the event that an IP address appears in the "ciaddr" field of a
DHCPLEASEQUERY message, if that IP address is one managed by the DHCP
server, then that IP address MUST be set in the "ciaddr" field of a
DHCPLEASEUNASSIGNED message.
If the IP address is not managed by the DHCP server, then a
DHCPLEASEUNKNOWN message must be returned.
If the "ciaddr" field of the DHCPLEASEQUERY is zero, then the
DHCPLEASEQUERY message is a query by Client-identifier or MAC
address. In this case, the client’s identity is any client that has
proffered an identical Client-identifier option (if the Client-
identifier option appears in the DHCPLEASEQUERY message), or an
identical MAC address (if the MAC address fields in the
DHCPLEASEQUERY message are non-zero). This client matching approach
will, for the purposes of this section, be described as "Client-
identifier or MAC address".
If the "ciaddr" field is zero in a DHCPLEASEQUERY message, then the
IP address placed in the "ciaddr" field of a DHCPLEASEACTIVE message
MUST be that of an IP address for which the client that most recently
used the IP address matches the Client-identifier or MAC address
specified in the DHCPLEASEQUERY message.
If there is only a single IP address that fulfills this criteria,
then it MUST be placed in the "ciaddr" field of the DHCPLEASEACTIVE
message.
In the case where more than one IP address has been accessed by the
client specified by the MAC address or Client-identifier option, then
the DHCP server MUST return the IP address returned to the client in
the most recent transaction with the client unless the DHCP server
has been configured by the server administrator to use some other
preference mechanism.
If, after all of the above processing, no value is set in the
"ciaddr" field of the DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message,
then a DHCPLEASEUNKNOWN message MUST be returned instead.
6.4.2. Building a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE Message Once
the "ciaddr" Field Is Set
Once the "ciaddr" field of the DHCPLEASEUNASSIGNED is set, the
processing for a DHCPLEASEUNASSIGNED message is complete. No other
options are returned for the DHCPLEASEUNASSIGNED message.
For the DHCPLEASEACTIVE message, the rest of the processing largely
involves returning information about the IP address specified in the
"ciaddr" field.
The IP address in the "ciaddr" field of the DHCPLEASEUNASSIGNED or
DHCPLEASEACTIVE message MUST be one for which this server is
responsible (or a DHCPLEASEUNKNOWN message would be have already been
returned early in the processing described in the previous section).
The MAC address of the DHCPLEASEACTIVE message MUST be set to the
values that identify the client associated with the IP address in the
"ciaddr" field of the DHCPLEASEUNASSIGNED message.
If the Client-identifier option (option 61) is specified in the
Parameter Request List option (option 55), then the Client-identifier
(if any) of the client associated with the IP address in the "ciaddr"
field SHOULD be returned in the DHCPLEASEACTIVE message.
In the case where more than one IP address has been involved in a
DHCP message exchange with the client specified by the MAC address
and/or Client-identifier option, then the list of all of the IP
addresses MUST be returned in the associated-ip option, whether or
not that option was requested as part of the Parameter Request List
option.
If the IP Address Lease Time option (option 51) is specified in the
Parameter Request List and if there is a currently valid lease for
the IP address specified in the ciaddr, then the DHCP server MUST
return this option in the DHCPLEASEACTIVE message with its value
equal to the time remaining until lease expiration. If there is no
valid lease for the IP address, then the server MUST NOT return the
IP Address Lease Time option (option 51).
A request for the Renewal (T1) Time Value option or the Rebinding
(T2) Time Value option in the Parameter Request List of the
DHCPLEASEQUERY message MUST be handled like the IP Address Lease Time
option is handled. If there is a valid lease and these times are not
yet in the past, then the DHCP server SHOULD return these options
(when requested) with the remaining time until renewal or rebinding,
respectively. If these times are already in the past, or if there is
not currently a valid lease for this IP address, the DHCP server MUST
NOT return these options.
If the Relay Agent Information (option 82) is specified in the
Parameter Request List, then the information contained in the most
recent Relay Agent Information option received from the relay agent
associated with this IP address MUST be included in the
DHCPLEASEACTIVE message.
The DHCPLEASEACTIVE message SHOULD include the values of all other
options not specifically discussed above that were requested in the
Parameter Request List of the DHCPLEASEQUERY message and that are
acceptable to return based on the list of "non-sensitive options",
discussed below.
DHCP servers SHOULD be configurable with a list of "non-sensitive
options" that can be returned to the client when specified in the
Parameter Request List of the DHCPLEASEQUERY message. Any option not
on this list SHOULD NOT be returned to a client, even if requested by
that client.
The DHCP server uses information from its lease binding database to
supply the DHCPLEASEACTIVE option values. The values of the options
that were returned to the DHCP client would generally be preferred,
but in the absence of those, options that were sent in DHCP client
requests would be acceptable.
In some cases, the Relay Agent Information option in an incoming
DHCPREQUEST packet is used to help determine the options returned to
the DHCP client that sent the DHCPREQUEST. When responding to a
DHCPLEASEQUERY message, the DHCP server MUST use the saved Relay
Agent Information option just like it did when responding to the DHCP
client in order to determine the values of any options requested by
the DHCPLEASEQUERY message. The goal is to return the same option
values to the DHCPLEASEQUERY as those that were returned to the
DHCPDISCOVER or DHCPREQUEST from the DHCP client (unless otherwise
specified, above).
In the event that two servers are cooperating to provide a high-
availability DHCP server, as supported by [RFC2131], they would have
to communicate some information about IP address bindings to each
other. In order to properly support the DHCPLEASEQUERY message,
these servers MUST ensure that they communicate the Relay Agent
Information option information to each other in addition to any other
IP address binding information.
6.4.3. Sending a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
DHCPLEASEUNKNOWN Message
The server expects a giaddr in the DHCPLEASEQUERY message, and
unicasts the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
DHCPLEASEUNKNOWN message to the giaddr. If the "giaddr" field is
zero, then the DHCP server MUST NOT reply to the DHCPLEASEQUERY
message.
6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
DHCPLEASEUNKNOWN Message
When a DHCPLEASEACTIVE message is received in response to the
DHCPLEASEQUERY message, it means that there is a currently active
lease for this IP address in this DHCP server. The access
concentrator SHOULD use the information in the "htype", "hlen", and
"chaddr" fields of the DHCPLEASEACTIVE as well as any Relay Agent
Information option information included in the packet to refresh its
location information for this IP address.
When a DHCPLEASEUNASSIGNED message is received in response to the
DHCPLEASEQUERY message, that means that there is no currently active
lease for the IP address present in the DHCP server, but that this
server does in fact manage that IP address. In this case, the access
concentrator SHOULD cache this information in order to prevent
unacceptable loads on the access concentrator and the DHCP server in
the face of a malicious or seriously compromised device downstream of
the access concentrator. This caching could be as simple as simply
setting a bit saying that a response was received from a server that
knew about this IP address but that there was no current lease. This
would, of course, need to be cleared when the access concentrator
next "gleaned" that a lease for this IP address came into existence.
In either case, when a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message
is received in response to a DHCPLEASEQUERY message, it means that
the DHCP server that responded is a DHCP server that manages the IP
address present in the ciaddr, and the Relay Agent SHOULD cache this
information for later use.
When a DHCPLEASEUNKNOWN message is received by an access concentrator
that has sent out a DHCPLEASEQUERY message, it means that the DHCP
server contacted supports the DHCPLEASEQUERY message but that the
DHCP server does not have definitive information concerning the IP
address contained in the "ciaddr" field of the DHCPLEASEQUERY
message. If there is no IP address in the "ciaddr" field of the
DHCPLEASEQUERY message, then a DHCPLEASEUNKNOWN message means that
the DHCP server does not have definitive information concerning the
DHCP client specified in the "hlen", "htype", and "chaddr" fields or
the Client-identifier option of the DHCPLEASEQUERY message.
The access concentrator SHOULD cache this information, but only for a
relatively short lifetime, approximately 5 minutes.
Having cached this information, the access concentrator SHOULD only
infrequently direct a DHCPLEASEQUERY message to a DHCP server that
responded to a DHCPLEASEQUERY message for a particular "ciaddr" field
with a DHCPLEASEUNKNOWN.
6.6. Receiving No Response to the DHCPLEASEQUERY Message
When an access concentrator receives no response to a DHCPLEASEQUERY
message, there are several possible reasons:
o The DHCPLEASEQUERY or a corresponding DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN was lost during transmission
or the DHCPLEASEQUERY arrived at the DHCP server but it was
dropped because the server was too busy.
o The DHCP server doesn’t support DHCPLEASEQUERY.
In the first of the cases above, a retransmission of the
DHCPLEASEQUERY would be appropriate, but in the second of the two
cases, a retransmission would not be appropriate. There is no way to
tell these two cases apart (other than, perhaps, because of a DHCP
server’s response to other DHCPLEASEQUERY messages indicating that it
does or does not support the DHCPLEASEQUERY message).
An access concentrator that utilizes the DHCPLEASEQUERY message
SHOULD attempt to resend DHCPLEASEQUERY messages to servers that do
not respond to them using a backoff algorithm for the retry time that
approximates an exponential backoff. The access concentrator SHOULD
adjust the backoff approach such that DHCPLEASEQUERY messages do not