<pre>Internet Engineering Task Force (IETF)                        K. Kinnear
Request for Comments: 7724                                      M. Stapp
Updates: <a href="./rfc6926">6926</a>                                                    B. Volz
Category: Standards Track                                  Cisco Systems
ISSN: 2070-1721                                               N. Russell
                                                                 Staples
                                                           December 2015


                       <span class="h1">Active DHCPv4 Lease Query</span>

Abstract

   The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been
   extended with a Leasequery capability that allows a requestor to
   request information about DHCPv4 bindings (<a href="./rfc4388">RFC 4388</a>).  That mechanism
   is limited to queries for individual bindings.  In some situations,
   individual binding queries may not be efficient, or even possible.
   In addition, continuous update of an external requestor with
   Leasequery data is sometimes desired.  This document expands on the
   DHCPv4 Leasequery protocol, and allows for active transfer of near
   real-time DHCPv4 binding information data via TCP.  This document
   updates <a href="./rfc6926">RFC 6926</a>, "DHCPv4 Bulk Leasequery".

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc7724">http://www.rfc-editor.org/info/rfc7724</a>.














<span class="grey">Kinnear, et al.              Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





































<span class="grey">Kinnear, et al.              Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-3">3</a>
   <a href="#section-2">2</a>.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-4">4</a>
   <a href="#section-3">3</a>.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-6">6</a>
   <a href="#section-4">4</a>.  Interaction Between Active Leasequery and Bulk Leasequery . .   <a href="#page-8">8</a>
   <a href="#section-5">5</a>.  Message and Option Definitions  . . . . . . . . . . . . . . .   <a href="#page-9">9</a>
     <a href="#section-5.1">5.1</a>.  Message Framing for TCP . . . . . . . . . . . . . . . . .   <a href="#page-9">9</a>
     <a href="#section-5.2">5.2</a>.  New or Changed Options  . . . . . . . . . . . . . . . . .   <a href="#page-9">9</a>
       <a href="#section-5.2.1">5.2.1</a>.  dhcp-message-type . . . . . . . . . . . . . . . . . .  <a href="#page-10">10</a>
       <a href="#section-5.2.2">5.2.2</a>.  dhcp-status-code  . . . . . . . . . . . . . . . . . .  <a href="#page-10">10</a>
     <a href="#section-5.3">5.3</a>.  Connection and Transmission Parameters  . . . . . . . . .  <a href="#page-11">11</a>
   <a href="#section-6">6</a>.  Information Communicated by Active Leasequery . . . . . . . .  <a href="#page-11">11</a>
   <a href="#section-7">7</a>.  Requestor Behavior  . . . . . . . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
     <a href="#section-7.1">7.1</a>.  General Processing  . . . . . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
     <a href="#section-7.2">7.2</a>.  Initiating a Connection . . . . . . . . . . . . . . . . .  <a href="#page-13">13</a>
     <a href="#section-7.3">7.3</a>.  Forming an Active Leasequery  . . . . . . . . . . . . . .  <a href="#page-14">14</a>
     <a href="#section-7.4">7.4</a>.  Processing Active Replies . . . . . . . . . . . . . . . .  <a href="#page-15">15</a>
       7.4.1.  Processing Replies from a Request Containing a
               query-start-time  . . . . . . . . . . . . . . . . . .  <a href="#page-17">17</a>
     <a href="#section-7.5">7.5</a>.  Closing Connections . . . . . . . . . . . . . . . . . . .  <a href="#page-19">19</a>
   <a href="#section-8">8</a>.  Server Behavior . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-19">19</a>
     <a href="#section-8.1">8.1</a>.  Accepting Connections . . . . . . . . . . . . . . . . . .  <a href="#page-19">19</a>
       <a href="#section-8.1.1">8.1.1</a>.  Update to <a href="./rfc6926">RFC 6926</a>  . . . . . . . . . . . . . . . . .  <a href="#page-21">21</a>
     <a href="#section-8.2">8.2</a>.  Replying to an Active Leasequery  . . . . . . . . . . . .  <a href="#page-21">21</a>
     <a href="#section-8.3">8.3</a>.  Multiple or Parallel Queries  . . . . . . . . . . . . . .  <a href="#page-23">23</a>
     <a href="#section-8.4">8.4</a>.  Closing Connections . . . . . . . . . . . . . . . . . . .  <a href="#page-24">24</a>
   <a href="#section-9">9</a>.  Security Considerations . . . . . . . . . . . . . . . . . . .  <a href="#page-24">24</a>
   <a href="#section-10">10</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  <a href="#page-25">25</a>
   <a href="#section-11">11</a>. References  . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-26">26</a>
     <a href="#section-11.1">11.1</a>.  Normative References . . . . . . . . . . . . . . . . . .  <a href="#page-26">26</a>
     <a href="#section-11.2">11.2</a>.  Informative References . . . . . . . . . . . . . . . . .  <a href="#page-27">27</a>
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-27">27</a>
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-28">28</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The DHCPv4 Leasequery capability [<a href="./rfc4388" title="&quot;Dynamic Host Configuration Protocol (DHCP) Leasequery&quot;">RFC4388</a>] extends the basic DHCPv4
   capability [<a href="./rfc2131" title="&quot;Dynamic Host Configuration Protocol&quot;">RFC2131</a>] [<a href="./rfc2132" title="&quot;DHCP Options and BOOTP Vendor Extensions&quot;">RFC2132</a>] to allow an external entity to query a
   DHCPv4 server to recover lease state information about a particular
   IPv4 address or client in near real-time.

   Continuous update of an external requestor with Leasequery data is
   sometimes desired.  These requestors need to keep up with the current
   binding activity of the DHCPv4 server.  Keeping up with these binding
   activities is termed "active" leasequery.





<span class="grey">Kinnear, et al.              Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   The DHCPv4 Bulk Leasequery [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] capability can be used to
   recover useful information from a DHCPv4 server when some external
   entity starts up.  This entity could be one that is directly involved
   in the DHCPv4 client-server transactions (e.g., a relay agent), or it
   could be an external process that needs information present in the
   DHCPv4 server's lease state database.

   The Active Leasequery capability documented here is designed to allow
   an entity not directly involved in DHCPv4 client-server transactions
   to nevertheless keep current with the state of the DHCPv4 lease state
   information in real-time.

   This document updates DHCPv4 Bulk Leasequery [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] in that it
   specifies the DHCPv4 server must close the TCP connection if it
   receives a DHCPv4 message that is not allowed over the TCP connection
   (for example, DHCPDISCOVER, DHCPLEASEQUERY).  See <a href="#section-8.1.1">Section 8.1.1</a>.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Terminology</span>

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

   This document uses the following terms:

   o  "Active Leasequery"

      Keeping up to date in real-time (or near real-time) with DHCPv4
      binding activity.

   o  "binding"

      The information that a DHCPv4 server keeps regarding the
      relationship between a DHCPv4 client and an IPv4 address.  This
      includes the identity of the DHCPv4 client and the expiration
      time, if any, of any lease that client has on a particular IPv4
      address.

   o  "Bulk Leasequery"

      Requesting and receiving the information about all or some of the
      existing DHCPv4 binding information in an efficient manner, as
      defined by [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>].








<span class="grey">Kinnear, et al.              Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   o  "blocked TCP connection"

      A TCP connection is considered blocked if the underlying TCP
      transport will not accept new messages to be sent without blocking
      the thread that is attempting to send the message.

   o  "catch-up information"

      If a DHCPv4 Active Leasequery requestor sends in a query-start-
      time option in a DHCPACTIVELEASEQUERY message, the DHCPv4 server
      will attempt to send the requestor the information that changed
      since the time specified in the query-start-time option.  The
      binding information sent to satisfy this request is the catch-up
      information.

   o  "catch-up phase"

      The period while the catch-up information is being sent is the
      catch-up phase.

   o  "clock skew"

      The difference between the absolute time on a DHCPv4 server and
      the absolute time on the system where a requestor of an Active or
      Bulk Leasequery is executing is termed the "clock skew" for that
      Active or Bulk Leasequery connection.  It is not absolutely
      constant but is likely to vary only slowly.  While it is easy to
      think that this can be calculated precisely after one packet is
      received by a requestor from a DHCPv4 server, a more accurate
      value is derived from continuously examining the instantaneous
      value developed from each packet received from a DHCPv4 server and
      using it to make small adjustments to the existing value held in
      the requestor.

   o  "DHCPv4 client"

      A DHCPv4 client is an IPv4 node using DHCP to obtain configuration
      parameters such as a network address.

   o  "DHCPv4 relay agent"

      A DHCPv4 relay agent is a third-party agent that transfers BOOTP
      and DHCPv4 messages between clients and servers residing on
      different subnets, per [<a href="./rfc951" title="&quot;Bootstrap Protocol&quot;">RFC951</a>] and [<a href="./rfc1542" title="&quot;Clarifications and Extensions for the Bootstrap Protocol&quot;">RFC1542</a>].







<span class="grey">Kinnear, et al.              Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   o  "DHCPv4 server"

      A DHCPv4 server is an IPv4 node that returns configuration
      parameters to DHCPv4 clients.

   o  "insecure mode"

      When operating in insecure mode, the TCP connection between the
      requestor and DHCPv4 server is not protected in any way.  In
      addition, the identity of the requestor is not validated by the
      server nor is the identity of the server validated by the
      requestor.

   o  "MAC address"

      In the context of a DHCP message, a Media Access Control (MAC)
      address consists of the fields: hardware type "htype", hardware
      length "hlen", and client hardware address "chaddr".

   o  "requestor"

      The node that sends LEASEQUERY messages to one or more servers to
      retrieve information on the bindings for a client.

   o  "secure mode"

      When operating in secure mode, the TCP connection between the
      requestor and the DHCPv4 server is protected by TLS [<a href="./rfc5246" title="&quot;The Transport Layer Security (TLS) Protocol Version 1.2&quot;">RFC5246</a>].  In
      addition, the requestor uses the certificates exchanged between it
      and the DHCPv4 server while setting up the TLS connection to
      validate the identity of the server.  The DHCPv4 server also uses
      these certificates to validate the identity of the requestor.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Protocol Overview</span>

   The Active Leasequery mechanism is modeled on the existing individual
   Leasequery protocol in [<a href="./rfc4388" title="&quot;Dynamic Host Configuration Protocol (DHCP) Leasequery&quot;">RFC4388</a>] as well as related work on DHCPv4
   Bulk Leasequery [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>]; most differences arise from the long-term
   nature of the TCP [<a href="./rfc7414" title="&quot;A Roadmap for Transmission Control Protocol (TCP) Specification Documents&quot;">RFC7414</a>] connection required for Active
   Leasequery.  In addition, a DHCPv4 server that supports Active
   Leasequery must support Bulk Leasequery [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] as well.  See
   <a href="#section-8">Section 8</a>.

   An Active Leasequery requestor opens a TCP connection to a DHCPv4
   Server, using the DHCPv4 port 67.  Note that this implies that the
   Leasequery requestor has the server IPv4 address(es) available via
   configuration or some other means, and that it has unicast IP




<span class="grey">Kinnear, et al.              Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   reachability to the DHCPv4 server.  The message framing for TCP is
   discussed in <a href="#section-5.1">Section 5.1</a>.  No relaying for Active Leasequery is
   specified.

   After establishing a connection, the requestor sends an
   DHCPACTIVELEASEQUERY message over the connection.  In response, the
   server sends updates to the requestor using DHCPLEASEACTIVE and
   DHCPLEASEUNASSIGNED messages that are extensions of these messages as
   defined in [<a href="./rfc4388" title="&quot;Dynamic Host Configuration Protocol (DHCP) Leasequery&quot;">RFC4388</a>] and [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>].  This response procedure is
   similar to the procedure specified in [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>], except that in the
   case of Active Leasequery the server sends updates whenever some
   activity occurs to change the binding state -- thus the need for the
   long-lived connection.  Additionally, the Active Leasequery server
   should provide a mechanism to control which data is allowed to be
   included in the messages sent to the requestor.  See <a href="#section-8.2">Section 8.2</a>.

   Since [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] did not specify what to do with an unknown message
   type received over the DHCP TCP connection, system administrators
   SHOULD NOT allow a DHCPACTIVELEASEQUERY message to be sent over a
   DHCP TCP connection to a DHCPv4 server that does not support Active
   Leasequery.

   Active Leasequery is designed to provide continuous updates of DHCPv4
   binding activity to an external entity.

   Active Leasequery has features that allow this external entity to
   lose its connection and then reconnect and receive the latest
   information concerning any IPv4 bindings changed while it was not
   connected.

   These capabilities are designed to allow the Active Leasequery
   requestor to efficiently become current with respect to the lease
   state database after it has been restarted or the machine on which it
   is running has been reinitialized.  It is easy to define a protocol
   that works when the requestor is always connected to the DHCPv4
   server.  Since that isn't sufficiently robust, much of the mechanism
   in this document is designed to deal efficiently with situations that
   occur when the Active Leasequery requestor becomes disconnected from
   the DHCPv4 server from which it is receiving updates and then becomes
   reconnected to that server.

   Central to this approach is the concept that, if the Active
   Leasequery requestor loses service, it is allowed to specify the time
   of its most recent update in a subsequent Active Leasequery request,
   and the DHCPv4 server will determine whether or not data was missed
   while the Active Leasequery requestor was not connected.





<span class="grey">Kinnear, et al.              Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   The DHCP server processing the Active Leasequery request MAY limit
   the amount of data saved, and methods exist for the DHCPv4 server to
   inform the Active Leasequery requestor that more data was missed than
   could be saved.  In this situation, the Active Leasequery requestor
   would issue a Bulk Leasequery [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] to recover information not
   available through an Active Leasequery.

   DHCPv4 servers are not required to keep any data corresponding to
   data missed on an Active Leasequery connection, but will typically
   choose to keep data corresponding to some recent activity available
   for subsequent queries by a DHCPv4 Active Leasequery requestor whose
   connection was temporarily interrupted.

   An Active Leasequery requestor would typically use Bulk Leasequery to
   initialize its database with all current data when that database
   contains no binding information.  In addition, it would use Bulk
   Leasequery to recover missed information in the event that its
   connection with the DHCPv4 server was lost for a longer time than the
   DHCPv4 server would keep track of the specific changes to the IPv4
   binding information.

   The messages sent by the server in response to an Active Leasequery
   request should be identical to the messages sent by the server to a
   Bulk Leasequery request regarding the way the data is encoded into
   the Active Leasequery responses.  In addition, the actions taken by
   the Active Leasequery requestor to interpret the responses to an
   Active Leasequery request should be identical to the way that the
   requestor interprets the responses to a Bulk Leasequery request.
   Thus, the handling of time, clock skew, data source, and other items
   discussed in the Bulk Leasequery specification [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] are to be
   followed when implementing Active Leasequery, with the exception that
   a server responding to an Active Leasequery request SHOULD be able to
   be configured to prevent specific data items from being included in
   the response to the requestor even if they were requested by
   inclusion in the dhcp-parameter-request-list option.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Interaction between Active Leasequery and Bulk Leasequery</span>

   Active Leasequery is an extension of the Bulk Leasequery protocol
   [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>].  The contents of messages returned to an Active Leasequery
   requestor are identical to those defined for the Bulk Leasequery
   protocol.

   Applications that employ Active Leasequery to keep a database up to
   date with respect to the DHCPv4 server's lease state database should
   use an initial Bulk Leasequery to bring their database into





<span class="grey">Kinnear, et al.              Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   equivalence with that of the DHCPv4 server, and then use Active
   Leasequery to keep that database current with respect to the DHCPv4
   server's lease state database.

   There are several differences between the Active and Bulk Leasequery
   protocols.  Active Leasequery defines only one qualifier (the query-
   start-time) and no query types, while Bulk Leasequery defines several
   query types and qualifiers.  An Active Leasequery connection sends
   all available updates to the requestor.

   An Active Leasequery connection does not ever "complete", though the
   DHCPv4 server can close the connection for a variety of reasons
   associated with some sort of exception condition.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Message and Option Definitions</span>

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Message Framing for TCP</span>

   The use of TCP for the Active Leasequery protocol permits one or more
   DHCPv4 messages to be sent in response to a single Active Leasequery
   request.  The receiver needs to be able to determine how large each
   message is.  The same framing technique used for Bulk Leasequery
   [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] is used for Active Leasequery.

   When using TLS to secure a connection [<a href="./rfc5246" title="&quot;The Transport Layer Security (TLS) Protocol Version 1.2&quot;">RFC5246</a>], the message framing
   for TLS uses the same format as that used for TCP.  One DHCP message
   is carried in one TLS record.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  New or Changed Options</span>

   The existing messages DHCPLEASEUNASSIGNED and DHCPLEASEACTIVE are
   used as the value of the dhcp-message-type option to indicate an IPv4
   address that is currently not leased or is currently leased to a
   DHCPv4 client, respectively.

   All of the message types and options defined for Bulk Leasequery
   [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] are also used by Active Leasequery.  In addition, new
   message types and option types are defined for Active Leasequery, as
   described below.












<span class="grey">Kinnear, et al.              Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>.  dhcp-message-type</span>

   The message type option (option 53) from [<a href="./rfc2132" title="&quot;DHCP Options and BOOTP Vendor Extensions&quot;">RFC2132</a>] requires
   additional values.  The values of these message types are shown below
   in an extension of the table from <a href="./rfc2132#section-9.6">Section&nbsp;9.6 of [RFC2132]</a>:

                     +-------+----------------------+
                     | Value | Message Type         |
                     +-------+----------------------+
                     | 16    | DHCPACTIVELEASEQUERY |
                     | 17    | DHCPLEASEQUERYSTATUS |
                     | 18    | DHCPTLS              |
                     +-------+----------------------+

<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>.  dhcp-status-code</span>

   The dhcp-status-code option defined in [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] allows greater
   detail to be returned regarding the status of a DHCP request.  While
   specified in the Bulk Leasequery document, this DHCPv4 option is also
   used in Active Leasequery.

   This option has two possible scopes when used with Active Leasequery,
   depending on the context in which it appears.  It refers to the
   information in a single leasequery reply if the value of the dhcp-
   message-type is DHCPLEASEACTIVE, DHCPLEASEUNASSIGNED, or DHCPTLS.  It
   refers to the message stream related to an entire request if the
   value of the dhcp-message-type is DHCPLEASEQUERYSTATUS.

   Additional status codes defined for support of Active Leasequery are:

   +----------------------+-------------+------------------------------+
   | Name                 | Status-Code | Description                  |
   +----------------------+-------------+------------------------------+
   | DataMissing          | 5           | Indicates that IPv4 binding  |
   |                      |             | information requested is not |
   |                      |             | available.                   |
   | ConnectionActive     | 6           | Indicates that this          |
   |                      |             | connection remains active.   |
   | CatchUpComplete      | 7           | Indicates that this Active   |
   |                      |             | Leasequery connection has    |
   |                      |             | completed sending all of the |
   |                      |             | saved data requested.        |
   | TLSConnectionRefused | 8           | Indicates that a TLS         |
   |                      |             | connection is not allowed.   |
   +----------------------+-------------+------------------------------+






<span class="grey">Kinnear, et al.              Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   A dhcp-status-code option MAY appear in the options field of a DHCP
   message.  If the dhcp-status-code option does not appear, it is
   assumed that the operation was successful.  The dhcp-status-code
   option SHOULD NOT appear in a message that is successful unless it is
   needed to convey some text message along with the Success status
   code.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Connection and Transmission Parameters</span>

   Active Leasequery uses the same port configuration as DHCPv4 Bulk
   Leasequery [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>].  It also uses other transmission parameters
   (BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>].

   This section presents a table of values used to control Active
   Leasequery behavior, including recommended defaults.  Implementations
   MAY make these values configurable.  However, configuring too-small
   timeout values may lead to harmful behavior both to this application
   as well as to other traffic in the network.  As a result, timeout
   values smaller than the default values SHOULD NOT be used.

   +------------------------+---------+-------------------------------+
   | Parameter              | Default | Description                   |
   +------------------------+---------+-------------------------------+
   | ACTIVE_LQ_RCV_TIMEOUT  | 120 s   | Active Leasequery receive     |
   |                        |         | timeout                       |
   | ACTIVE_LQ_SEND_TIMEOUT | 120 s   | Active Leasequery send        |
   |                        |         | timeout                       |
   | ACTIVE_LQ_IDLE_TIMEOUT | 60 s    | Active Leasequery idle        |
   |                        |         | timeout                       |
   +------------------------+---------+-------------------------------+

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Information Communicated by Active Leasequery</span>

   While the information communicated by a Bulk Leasequery [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] is
   taken directly from the DHCPv4 server's lease state database, the
   information communicated by an Active Leasequery is real-time
   information.  As such, it is the information that is currently
   associated with a particular binding in the DHCPv4 server's lease
   state database.

   This is of significance, because if the Active Leasequery requestor
   runs slowly or the requestor disconnects from the DHCPv4 server and
   then reconnects with a query-start-time (signaling a catch-up
   operation), the information communicated to the Active Leasequery
   requestor is only the most current information from the DHCPv4
   server's lease state database.





<span class="grey">Kinnear, et al.              Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   The requestor of an Active Leasequery MUST NOT assume that every
   lease state change is communicated across an Active Leasequery
   connection.  Even if the Active Leasequery requestor remains
   connected, the DHCPv4 server is only required to transmit information
   about a binding that is current when the packet is created and handed
   off to the TCP stack to send to the requestor.

   If the TCP connection blocks and the DHCPv4 server is waiting to send
   information down the connection, when the connection becomes
   available to be written, the DHCPv4 server MAY create the packet to
   send at this time.  The current state of the binding will be sent,
   and any transition in state or other information that occurred while
   the TCP connection was blocked will be lost.

   Thus, the Active Leasequery protocol does not allow the requestor to
   build a complete history of every activity on every lease.  An
   effective history of the important state changes for a lease can be
   created if the parameters of the DHCPv4 server are tuned to take into
   account the requirements of an Active Leasequery requestor.  For
   instance, the period after the expiration or release of a binding
   could be configured long enough (say, several minutes, well more than
   the receive timeout), so that an Active Leasequery requestor would
   never miss any changes in the binding.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Requestor Behavior</span>

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  General Processing</span>

   A requestor attempts to establish a TCP connection to a DHCPv4 server
   in order to initiate a Leasequery exchange.  If the attempt fails,
   the Requestor MAY retry.  Retries should not be more frequent than
   one every ACTIVE_LQ_IDLE_TIMEOUT.  See <a href="#section-5.3">Section 5.3</a>.

   If an Active Leasequery is terminated prematurely by a
   DHCPLEASEQUERYDONE with a dhcp-message status-code of QueryTerminated
   or by the failure of the connection over which it was being
   submitted, the requestor MAY retry the request after the creation of
   a new connection.  Retries should not be more frequent than one every
   ACTIVE_LQ_IDLE_TIMEOUT.  See <a href="#section-5.3">Section 5.3</a>.

   Messages from the DHCPv4 server come as multiple responses to a
   single DHCPACTIVELEASEQUERY message.  Thus, each DHCPACTIVELEASEQUERY
   or DHCPBULKLEASEQUERY request must have an xid (transaction-id)
   unique on the connection on which it is sent (see <a href="#section-7.3">Section 7.3</a>), and
   all of the messages that come as a response to it contain the same
   xid as the request.





<span class="grey">Kinnear, et al.              Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   Only one DHCPACTIVELEASEQUERY is allowed on any one TCP connection at
   a time.  Parallel DHCPACTIVELEASEQUERY requests on the same TCP
   connection are not allowed.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  Initiating a Connection</span>

   A requestor SHOULD be able to operate in either insecure or secure
   mode.  See <a href="#section-9">Section 9</a>.  This MAY be a feature that is administratively
   controlled.

   When operating in insecure mode, the requestor sends a
   DHCPACTIVELEASEQUERY request after the establishment of a TCP
   connection.

   When operating in secure mode, the requestor MUST attempt to
   negotiate a TLS [<a href="./rfc5246" title="&quot;The Transport Layer Security (TLS) Protocol Version 1.2&quot;">RFC5246</a>] connection over the TCP connection.  If
   this negotiation fails, the requestor MUST close the TCP connection.
   The recommendations in [<a href="./rfc7525" title="&quot;Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)&quot;">RFC7525</a>] apply when negotiating this
   connection.

   A requestor requests the establishment of a TLS connection by sending
   the DHCPTLS message to the DHCPv4 server as the first message over
   the TCP connection.  The DHCPTLS message SHOULD be sent without any
   options.  This message indicates to the DHCPv4 server that a TLS
   connection over this TCP connection is desired.  There are four
   possibilities after the requestor sends the DHCPTLS message to the
   DHCPV4 server:

   1.  No response from the DHCPv4 server.

   2.  The DHCPv4 server closes the TCP connection after it receives the
       DHCPTLS message.

   3.  DHCPv4 server responds with a DHCPTLS message with a dhcp-status-
       code of TLSConnectionRefused.

   4.  DHCPv4 server responds with DHCPTLS message with no dhcp-status-
       code, indicating success.

   In any of the first three possibilities, the DHCPv4 server can be
   assumed to not support TLS.  In this case, the requestor MUST close
   the connection.

   In the final possibility, where the DHCPv4 server has responded with
   a DHCPTLS message with no dhcp-status-code in response to the
   requestor's DHCPTLS message, the requestor SHOULD initiate the
   exchange of the messages involved in a TLS handshake [<a href="./rfc5246" title="&quot;The Transport Layer Security (TLS) Protocol Version 1.2&quot;">RFC5246</a>].




<span class="grey">Kinnear, et al.              Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   During the TLS handshake, the requestor MUST validate the DHCPv4
   server's digital certificates.

   If the handshake exchange yields a functioning TLS connection, then
   the requestor SHOULD transmit a DHCPACTIVELEASEQUERY message over
   that TLS connection and use that TLS connection for all further
   interactions in which it engages with the DHCPv4 server over this TCP
   connection.

   If the handshake exchange does not yield a functioning TLS
   connection, then the requestor MUST close the TCP connection.

<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>.  Forming an Active Leasequery</span>

   The Active Leasequery is designed to create a long-lived connection
   between the requestor and the DHCPv4 server processing the active
   query.  The DHCPv4 server SHOULD send binding information back across
   this connection with minimal delay after it learns of the binding
   information.  It will learn about the bindings either because it
   makes the bindings itself or because it has received information
   about a binding from another server.

   An Active Leasequery is a DHCPv4 request with a dhcp-message-type of
   DHCPACTIVELEASEQUERY.  The DHCPv4 request MUST NOT have a ciaddr, a
   chaddr, or a dhcp-client-identifier.  The DHCPv4 request MUST have an
   xid (transaction-id) unique on the connection on which it is sent.
   The DHCPv4 request SHOULD have a dhcp-parameter-request-list to
   inform the DHCPv4 server which DHCPv4 options are of interest to the
   requestor sending the DHCPACTIVELEASEQUERY message.

   An important capability of the Active Leasequery is that the
   requestor can specify that some recent data be sent immediately to
   the requestor in parallel with the transmission of the ongoing
   binding information in more or less real time.  This capability is
   used in order to allow an Active Leasequery requestor to recover
   missed information in the event that it temporarily loses
   connectivity with the DHCPv4 server processing a previous Active
   Leasequery.

   This capability is enabled by the transmission of a 4-octet base-time
   option with each Leasequery reply sent as the result of a previous
   Active Leasequery.  The requestor SHOULD keep track of the highest
   base-time received from a particular DHCPv4 server over an Active
   Leasequery connection, and in the event that the requestor finds it
   necessary (for whatever reason) to reestablish an Active Leasequery
   connection to that DHCPv4 server, the requestor should place this





<span class="grey">Kinnear, et al.              Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   highest base-time value into a query-start-time option in the new
   DHCPACTIVELEASEQUERY request.  (See Sections <a href="#section-6.2.5">6.2.5</a> and <a href="#section-7.2">7.2</a> of
   [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] for information on the query-start-time option.)

   Note that until all of the recent data (catch-up data) has been
   received, the requestor MUST NOT keep track of the base-time received
   in Leasequery reply messages to use later in a subsequent Bulk
   Leasequery or Active Leasequery request.

   If the requestor doesn't wish to request an update of information
   missed when it was not connected to the DHCPv4 server, then it does
   not include the query-start-time option in the DHCPACTIVELEASEQUERY
   request.

   If the TCP connection becomes blocked or stops being writable while
   the requestor is sending its query, the requestor SHOULD terminate
   the connection after BULK_LQ_DATA_TIMEOUT.  We make this
   recommendation to allow requestors to control the period of time they
   are willing to wait before abandoning a connection, independent of
   notifications from the TCP implementations they may be using.

<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>.  Processing Active Replies</span>

   The Requestor attempts to read a DHCPv4 leasequery reply message from
   the TCP connection.

   Note that the connection resulting from accepting a
   DHCPACTIVELEASEQUERY request may be long-lived and may not have data
   transferring continuously during its lifetime.  Therefore, the DHCPv4
   server SHOULD send a DHCPLEASEQUERYSTATUS message with a dhcp-status-
   code of ConnectionActive every ACTIVE_LQ_IDLE_TIMEOUT seconds
   (default 60) in order for the requestor to know that the connection
   remains alive.  This approach is followed only when the connection is
   idle (i.e., the server has no binding data to send).  During normal
   binding data exchange, receiving DHCPLEASEACTIVE or
   DHCPLEASEUNASSIGNED messages by the requestor itself signifies that
   the connection is active.  Note that the default for
   ACTIVE_LQ_RCV_TIMEOUT is 120 seconds, twice the value of the
   ACTIVE_LQ_IDLE_TIMEOUT's default of 60 seconds, which drives the
   DHCPv4 server to send messages.  Thus, ACTIVE_LQ_RCV_TIMEOUT controls
   how sensitive the requestor is to be to delays by the DHCPv4 server
   in sending updates or DHCPLEASEQUERYSTATUS messages.

   If the stream of replies becomes blocked with no messages being
   received, the Requestor SHOULD terminate the connection after
   ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured
   to do so.




<span class="grey">Kinnear, et al.              Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   A successful query that is returning binding data MUST include a non-
   zero ciaddr.  It may also include a non-zero chaddr, htype, and hlen
   as well as additional options.  If there are additional bindings to
   be returned, they will be carried in additional Active Leasequery
   messages.

   Any requestor of an Active Leasequery operation MUST be prepared to
   receive multiple copies of the binding information for a particular
   IPv4 address.  See the Bulk Leasequery document [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] for
   information on how to deal with this situation.

   A single Active Leasequery can and usually will result in a large
   number of replies.  The Requestor MUST be prepared to receive more
   than one reply with transaction-ids matching a single
   DHCPACTIVELEASEQUERY message from a single DHCPv4 server.

   A DHCPACTIVELEASEQUERY has two regimes -- during the catch-up phase,
   if any, and after any catch-up phase.  If the DHCPACTIVELASEQUERY
   request had a query-start-time, then the DHCPACTIVELEASEQUERY starts
   out in the catch-up phase.  See <a href="#section-7.4.1">Section 7.4.1</a> for information on
   processing during the catch-up phase, as well as how to determine
   when the catch-up phase is complete.

   After the catch-up phase, or during the entire series of messages
   received as the response to a DHCPACTIVELEASEQUERY request with no
   query-start-time (and therefore no catch-up phase), the base-time
   option of the most recent message SHOULD be saved as a record of the
   most recent time that data was received.  This base-time (in the
   context of the DHCPv4 server) can be used in a subsequent
   DHCPACTIVELEASEQUERY message's query-start-time or in a
   DHCPBULKLEASEQUERY message's query-start-time, if one is required,
   after a loss of the Active Leasequery connection.

   The DHCPLEASEQUERYSTATUS message MAY unilaterally terminate a
   successful DHCPACTIVELEASEQUERY request that is currently in progress
   in the event that the DHCPv4 server determines that it cannot
   continue processing a DHCPACTIVELEASEQUERY request.  For example,
   when a server is requested to shut down, it SHOULD send a
   DHCPLEASEQUERYSTATUS message with a dhcp-status-code of
   QueryTerminated and include in the message a base-time.  This MUST be
   the last message on that connection, and once the message has been
   transmitted, the server MUST close the connection.

   After receiving DHCPLEASEQUERYSTATUS with a QueryTerminated status
   from a server, the Requestor MAY close the TCP connection to that
   server.





<span class="grey">Kinnear, et al.              Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   The DHCPv4 Leasequery protocol uses the associated-ip option as an
   indicator that multiple bindings were present in response to a single
   client-based query.  For Active Leasequery, client-based queries are
   not supported, and so the associated-ip option is not used and MUST
   NOT be present in replies.

<span class="h4"><a class="selflink" id="section-7.4.1" href="#section-7.4.1">7.4.1</a>.  Processing Replies from a Request Containing a query-start-time</span>

   If the DHCPACTIVELEASEQUERY was requested with a query-start-time,
   the DHCPv4 server will attempt to send information about all bindings
   that changed since the time specified in the query-start-time.  This
   is the catch-up phase of the DHCPACTIVELEASEQUERY processing.  The
   DHCPv4 server MAY also begin immediate updates over the same
   connection of real-time binding information changes.  Thus, the
   catch-up phase can run in parallel with the normal updates generated
   by the DHCPACTIVELEASEQUERY request.

   A DHCPv4 server MAY keep only a limited amount of time-ordered
   information available to respond to a DHCPACTIVELEASEQUERY request
   containing a query-start-time.  Thus, it is possible that the time
   specified in the query-start-time represents a time not covered by
   the time-ordered information kept by the DHCPv4 server.  In such
   case, when there is not enough data saved in the DHCPv4 server to
   satisfy the request specified by the query-start-time option, the
   DHCPv4 server will reply immediately with a DHCPLEASEQUERYSTATUS
   message with a dhcp-status-code of DataMissing with a base-time
   option equal to the server's current time.  This will signal the end
   of the catch-up phase, and the only updates that will subsequently be
   received on this connection are the real-time updates from the
   DHCPACTIVELEASEQUERY request.

   If there is enough data saved to satisfy the request, then
   DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages will begin arrive
   from the DHCPv4 server.  Some of these messages will be related to
   the query-start-time request and be part of the catch-up phase.  Some
   of these messages will be real-time updates of binding changes taking
   place in the DHCPv4 server.  In general, there is no way to determine
   the source of each message.

   The updates sent by the DHCPv4 server during the catch-up phase are
   not in the order that the binding data was updated.  Therefore, until
   the catch-up phase is complete, the latest base-time value received
   from a DHCPv4 server processing an Active Leasequery request cannot
   be reset from the incoming messages (and used in a subsequent Active
   Leasequery's query-start-time option), because to do so would
   compromise the ability to recover lost information if the
   DHCPACTIVELEASEQUERY were to terminate prior to the completion of the
   catch-up phase.



<span class="grey">Kinnear, et al.              Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   The requestor will know that the catch-up phase is complete because
   the DHCPv4 server will transmit a DHCPLEASEQUERYSTATUS message with
   the dhcp-status-code of CatchUpComplete (or, as discussed above,
   DataMissing).  Once this message is transmitted, all additional
   DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages will relate to real-
   time ("new") binding changes in the DHCPv4 server.

   As discussed in <a href="#section-6.3">Section 6.3</a>, the requestor SHOULD keep track of the
   latest base-time option value received over a particular connection,
   to be used in a subsequent DHCPACTIVELEASEQUERY request -- but only
   if the catch-up phase is complete.  Prior to the completion of the
   catch-up phase, if the connection should go away or if the requestor
   receives a DHCPLEASEQUERYDONE message, then when it reconnects it
   MUST use the base-time value from the previous connection and not any
   base-time value received from the recently closed connection.

   In the event that there was enough data available to the DHCPv4
   server to begin to satisfy the request implied by the query-start-
   time option, but during the processing of that data the server found
   that it was unable to continue (perhaps there was barely enough, the
   connection was very slow, and the aging algorithm caused the saved
   data to become unavailable), the DHCPv4 server will terminate the
   catch-up phase of processing immediately by sending a
   DHCPLEASEQUERYSTATUS message with a dhcp-status-code of DataMissing
   and with a base-time option of the current time.

   The requestor must not assume that every individual state change of
   every binding during the period from the time specified in the query-
   start-time and the present is replicated in an Active Leasequery
   reply message.  See <a href="#section-6">Section 6</a>.  The requestor MAY assume that at
   least one Active Leasequery reply message will exist for every
   binding that had one or more changes of state during the period
   specified by the query-start-time and the current time.  The last
   message for each binding will contain the state at the current time,
   and there can be one or more messages concerning a single binding
   during the catch-up phase of processing.

   Bindings can change multiple times while the requestor is not
   connected.  The requestor will only receive information about the
   current state of the binding, not information about each state change
   that occurred during the period from the query-start-time to the
   present.

   If the DHCPLEASEQUERYSTATUS message containing a dhcp-status-code of
   DataMissing is received and the requestor is interested in keeping
   its database up to date with respect to the current state of the
   bindings in the DHCPv4 server, then the requestor SHOULD issue a
   DHCPBULKLEASEQUERY request to recover the information missing from



<span class="grey">Kinnear, et al.              Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   its database.  This DHCPBULKLEASEQUERY should include a query-start-
   time option, set to the same value as the query-start-time option
   previously included in the DHCPACTIVELEASEQUERY responses from the
   DHCPv4 server, and a query-end-time option equal to the base-time
   option returned by the DHCPv4 server in the DHCPLEASEQUERYSTATUS
   message with the dhcp-status-code of DataMissing.

   Typically, the requestor would have one connection open to a DHCPv4
   server for a DHCPACTIVELEASEQUERY request and possibly one additional
   connection open for a DHCPBULKLEASEQUERY request to the same DHCPv4
   server to fill in the data that might have been missed prior to the
   initiation of the DHCPACTIVELEASEQUERY.  The Bulk Leasequery
   connection would typically run to completion and be closed, leaving
   one Active Leasequery connection open to a single DHCPv4 server.

<span class="h3"><a class="selflink" id="section-7.5" href="#section-7.5">7.5</a>.  Closing Connections</span>

   The Requestor or DHCPv4 leasequery server MAY close its end of the
   TCP connection at any time.  The Requestor MAY choose to retain the
   connection if it intends to issue additional queries.  Note that this
   requestor behavior does not guarantee that the connection will be
   available for additional queries: the server might decide to close
   the connection based on its own configuration.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Server Behavior</span>

   A DHCPv4 server that supports Active Leasequery MUST support Bulk
   Leasequery [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] as well.

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Accepting Connections</span>

   DHCPv4 servers that implement DHCPv4 Active Leasequery listen for
   incoming TCP connections.  The approach used in accepting the
   requestor's connection is the same as specified in DHCPv4 Bulk
   Leasequery [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>], with the exception that support for Active
   Leasequery MUST NOT be enabled by default, and MUST require an
   explicit configuration step to be performed before it will operate.

   DHCPv4 servers SHOULD be able to operate in either insecure or secure
   mode.  See <a href="#section-9">Section 9</a>.  This MAY be a mode that is administratively
   controlled, where the server will require a TLS connection to operate
   or will only operate without a TLS connection.  In either case,
   operation in insecure mode MUST NOT be the default, even if operation
   in secure mode is not supported.  Operation in insecure mode MUST
   always require an explicit configuration step, separate from the
   configuration step required to enable support for Active Leasequery.





<span class="grey">Kinnear, et al.              Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   When operating in insecure mode, the DHCPv4 server simply waits for
   the requestor to send the Active Leasequery after the establishment
   of TCP connection.  If it receives a DHCPTLS message, it will respond
   with TLSConnectionRefused in a DHCPTLS message.

   When operating in secure mode, DHCPv4 servers MUST support TLS
   [<a href="./rfc5246" title="&quot;The Transport Layer Security (TLS) Protocol Version 1.2&quot;">RFC5246</a>] to protect the integrity and privacy of the data
   transmitted over the TCP connection.  When operating in secure mode,
   DHCPv4 servers MUST be configurable with regard to which requestors
   they will communicate.  The certificate presented by a requestor when
   initiating the TLS connection is used to distinguish between
   acceptable and unacceptable requestors.

   When operating in secure mode, a DHCPv4 server MUST begin to
   negotiate a TLS connection with a requestor who asks for one, and
   MUST close TCP connections that are not secured with TLS or for which
   the requestor's certificate is deemed unacceptable.  The
   recommendations in [<a href="./rfc7525" title="&quot;Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)&quot;">RFC7525</a>] apply when negotiating a TLS connection.

   A requestor will request a TLS connection by sending a DHCPTLS as the
   first message over a newly created TCP connection.  If the DHCPv4
   server supports TLS connections and has not been configured to not
   allow them on this link, the DHCPv4 server MUST respond to this
   DHCPTLS message by sending a DHCPTLS message with no dhcp-status-code
   back to the requestor.  This indicates to the requestor that the
   DHCPv4 server will support the negotiation of a TLS connection over
   this existing TCP connection.

   If a connection is to be rejected because of a limitation of the
   number of open connections, the TCP connection itself should be
   rejected, or the subsequent ACTIVELEASEQUERY message should be
   rejected.  Capacity-related rejections SHOULD NOT affect the response
   to the DHCPTLS message.

   Any options appearing in a DHCPTLS message received by a DHCPv4
   server SHOULD be ignored.  This is a "SHOULD" instead of a "MUST" in
   order to allow use of the DHCPTLS message in later documents,
   possibly with the use of options, without requiring those documents
   to update this document.

   If for some reason the DHCPv4 server cannot support or has been
   configured to not support a TLS connection, then it sends a DHCPTLS
   message with a dhcp-status-code of TLSConnectionRefused back to the
   requestor.

   In the event that the DHCPv4 server sends a DHCPTLS message with no
   dhcp-status-code option included (which indicates success), the
   requestor is supposed to initiate a TLS handshake [<a href="./rfc5246" title="&quot;The Transport Layer Security (TLS) Protocol Version 1.2&quot;">RFC5246</a>] (see



<span class="grey">Kinnear, et al.              Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   <a href="#section-7.2">Section 7.2</a>).  During the TLS handshake, the DHCPv4 server MUST
   validate the requestor's digital certificate.  In addition, the
   digital certificate presented by the requestor is used to decide if
   this requestor is allowed to perform an Active Leasequery.  If this
   requestor's certificate is deemed unacceptable, the server MUST abort
   the creation of the TLS connection.

   All TLS connections established between a requestor and a DHCPv4
   server for the purposes of supporting Active Leasequery MUST be
   mutually authenticated.

   If the TLS handshake is not successful in creating a TLS connection,
   the server MUST close the TCP connection.

   If the TCP connection becomes blocked while the server is accepting a
   connection or reading a query, it SHOULD terminate the connection
   after a BULK_LQ_DATA_TIMEOUT.  We make this recommendation to allow
   servers to control the period of time they are willing to wait before
   abandoning an inactive connection, independent of the TCP
   implementations they may be using.

<span class="h4"><a class="selflink" id="section-8.1.1" href="#section-8.1.1">8.1.1</a>.  Update to <a href="./rfc6926">RFC 6926</a></span>

   In an update to the DHCPv4 Bulk Leasequery protocol [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] (which
   didn't discuss this situation explicitly), if the DHCPv4 server
   receives a DHCPv4 message containing a dhcp-message-type option with
   a value that is not supported over a TCP connection, it MUST close
   the TCP connection.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  Replying to an Active Leasequery</span>

   If the connection becomes blocked while the server is attempting to
   send reply messages, the server SHOULD terminate the TCP connection
   after ACTIVE_LQ_SEND_TIMEOUT.  This timeout governs how long the
   DHCPv4 server is prepared to wait for the requestor to read and
   process enough information to unblock the TCP connection.  The
   default is two minutes, which means that if more than two minutes
   goes by without the requestor reading enough information to unblock
   the TCP connection, the DHCPv4 server SHOULD close the TCP
   connection.

   If the DHCPv4 server encounters an error during processing of the
   DHCPACTIVELEASEQUERY message, either during initial processing or
   later during the message processing, it SHOULD send a
   DHCPLEASEQUERYSTATUS containing an error code of some kind in a dhcp-
   status-code option.  It SHOULD close the connection after this error
   is signaled.




<span class="grey">Kinnear, et al.              Standards Track                   [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   Every reply to a DHCPACTIVELEASEQUERY request MUST contain the
   information specified in replies to a DHCPBULKLEASEQUERY request
   [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>], with the exception that a server implementing Active
   Leasequery SHOULD be able to be configured to prevent specific data
   items from being sent to the requestor even if these data items were
   requested in the dhcp-parameter-request-list option.

   Some servers can be configured to respond to a DHCPv4 Leasequery
   [<a href="./rfc4388" title="&quot;Dynamic Host Configuration Protocol (DHCP) Leasequery&quot;">RFC4388</a>] or a DHCPBULKLEASEQUERY [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] for an IPv4 binding that
   is reserved in such a way that it appears that the IPv4 binding is
   leased to the DHCP client for which it is reserved.  These servers
   SHOULD also respond to a DHCPACTIVELEASEQUERY request with the same
   information as they would to a DHCPBULKLEASEQUERY request when they
   first determine that the IPv4 binding is reserved to a DHCP client.

   If a DHCPACTIVELEASEQUERY request contains a query-start-time option,
   it indicates that the requestor would like the DHCPv4 server to send
   it not only messages that correspond to DHCPv4 binding activity that
   occurs subsequent to the receipt of the DHCPLEASEACTIVE request, but
   also messages that correspond to DHCPv4 binding activity that
   occurred prior to the DHCPACTIVELEASEQUERY request.

   If a query-end-time option appears in a DHCPACTIVELEASEQUERY the
   DHCPv4 server should send a DHCPLEASEQUERYSTATUS message with a dhcp-
   status-code of MalformedQuery and terminate the connection.

   In order to implement a meaningful response to this query, the DHCPv4
   server MAY keep track of the binding activity and associate changes
   with particular base-time values from the messages.  Then, when
   requested to do so by a DHCPACTIVELEASEQUERY request containing a
   query-start-time option, the DHCPv4 server can respond with replies
   for all binding activity occurring on that query-start-time or later
   times.

   These replies based on the query-start-time MAY be interleaved with
   the messages generated due to current binding activity.

   Once the transmission of the DHCPv4 Leasequery messages associated
   with the query-start-time option are complete, a DHCPLEASEQUERYSTATUS
   message MUST be sent with a dhcp-status-code value of
   CatchUpComplete.

   The DHCPv4 server SHOULD keep track of previous binding activity.  It
   SHOULD limit the amount of previous binding activity it keeps track
   of.  The DHCPv4 server MAY choose to only do this in the event that
   it has received at least one DHCPACTIVELEASEQUERY request in the
   past, as to do so will almost certainly entail some utilization of
   resources that would be wasted if there are no DHCPACTIVELEASEQUERY



<span class="grey">Kinnear, et al.              Standards Track                   [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   requestors for this DHCPv4 server.  The DHCPv4 server SHOULD make the
   amount of previous binding activity it retains configurable.  There
   is no requirement on the DHCPv4 server to retain this information
   over a server restart (or even to retain such information at all).

   Unless there is an error or some requirement to cease processing a
   DHCPACTIVELEASEQUERY request yielding a DHCPLEASEQUERYSTATUS message,
   such as a server shutdown, there will be no DHCPLEASEQUERYSTATUS
   message at the conclusion of the DHCPACTIVELEASEQUERY processing
   because that processing will not conclude but will continue until
   either the requestor or the server closes the connection.

   While the form of the data being sent by a DHCPACTIVELEASEQUERY is
   essentially the same as that being sent by a DHCPBULKLEASEQUERY, the
   reasons for sending information differs considerably between these
   two capabilities.  In the DHCPBULKLEASEQUERY context, the entire
   contents of the lease state database (subject to the constraints of
   the various query options) are returned to the requestor.  In the
   DHCPACTIVELEASEQUERY context, changes to the lease state database are
   returned to the requestor essentially as they happen.  For instance,
   when an IPv4 binding transitions from the leased state to some other
   state, the DHCPACTIVELEASEQUERY will send a DHCPLEASEUNASSIGNED
   packet with information regarding that binding.  The server may then
   entirely forget about that IPv4 binding (or not), but it is important
   to tell the DHCPACTIVELEASEQUERY requestor that a binding has
   transitioned away from the leased state.

   The relationship between the time that the server replies to a DHCP
   client request and the time that the DHCP server sends a reply to a
   DHCPACTIVELEASEQUERY message is a matter of implementation (and thus
   not defined by this document).  However, the server SHOULD NOT delay
   responding to the DHCP client in order to transmit a reply to a
   DHCPACTIVELEASEQUERY message, and the server SHOULD send the reply to
   the DHCPACTIVELASEQUERY message as soon as possible after responding
   to the client.

<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>.  Multiple or Parallel Queries</span>

   Every Active Leasequery request MUST be made on a single TCP
   connection where there is no other request active at the time the
   request is made.  Note that this is different than what was allowed
   in <a href="./rfc6926#section-7.7">Section&nbsp;7.7 of [RFC6926]</a> for Bulk Leasequery requests.

   Typically, a requestor of an Active Leasequery would not need to send
   a second Active Leasequery while the first is still active.  However,
   sending an Active Leasequery and a Bulk Leasequery in parallel would
   be possible and reasonable.  In case of parallel Active and Bulk
   Leasequery requests, the requestor MUST use different connections.



<span class="grey">Kinnear, et al.              Standards Track                   [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   This MAY be a feature that is administratively controlled.  Servers
   that are able to process queries in parallel SHOULD offer
   configuration that limits the number of simultaneous queries
   permitted from any one requestor, in order to control resource use if
   there are multiple requestors seeking service.

<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>.  Closing Connections</span>

   The server MAY end communication by sending a DHCPLEASEQUERYSTATUS
   message and then immediately closing the TCP connection.
   Alternatively, the server MAY retain the connection and wait for
   additional queries from the requestor.  The server SHOULD limit the
   number of connections it maintains and SHOULD close idle connections
   to enforce the limit.

   The server MUST close its end of the TCP connection if it encounters
   an error sending data on the connection.  The server MUST close its
   end of the TCP connection if it finds that it has to abort an in-
   process request.  A server aborting an in-process request SHOULD
   attempt to signal that to its requestors by using the QueryTerminated
   status code in the dhcp-status-code option in a DHCPLEASEQUERYSTATUS
   message.  If the server detects that the requestor end has been
   closed, the server MUST close its end of the connection.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Security Considerations</span>

   The Security Considerations section of [<a href="./rfc2131" title="&quot;Dynamic Host Configuration Protocol&quot;">RFC2131</a>] details the general
   threats to DHCPv4.  The DHCPv4 Leasequery specification [<a href="./rfc4388" title="&quot;Dynamic Host Configuration Protocol (DHCP) Leasequery&quot;">RFC4388</a>]
   describes recommendations for the Leasequery protocol, especially
   with regard to relayed LEASEQUERY messages, mitigation of packet-
   flooding DoS attacks, restriction to trusted requestors, and use of
   IPsec [<a href="./rfc4301" title="&quot;Security Architecture for the Internet Protocol&quot;">RFC4301</a>].

   The use of TCP introduces some additional concerns.  Attacks that
   attempt to exhaust the DHCPv4 server's available TCP connection
   resources can compromise the ability of legitimate clients to receive
   service.  Malicious requestors who succeed in establishing
   connections, but who then send invalid queries, partial queries, or
   no queries at all also can exhaust a server's pool of available
   connections.

   Two modes of operation exist for this protocol, insecure mode and
   secure mode.  These two modes exist because there are essentially two
   models of use for this protocol.  In one model, the requestor of an
   Active Leasequery is connected to the Internet in an arbitrary
   location, and the information transmitted needs to be protected





<span class="grey">Kinnear, et al.              Standards Track                   [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   during transmission.  In addition, the identities of both requestor
   and server need to be verified.  For this model of use, the secure
   mode is appropriate.

   The other model of use is where the requestor of the Active
   Leasequery resides in a network element that is essentially "next to"
   the element containing the DHCP server, and both of these elements
   are inside a protected environment.  For this model, the insecure
   mode is sufficient since there are other, more global, protections in
   place to protect this information.

   When operating in secure mode, TLS [<a href="./rfc5246" title="&quot;The Transport Layer Security (TLS) Protocol Version 1.2&quot;">RFC5246</a>] is used to secure the
   connection.  The recommendations in [<a href="./rfc7525" title="&quot;Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)&quot;">RFC7525</a>] apply when negotiating
   a TLS connection.

   Operating in insecure mode (see <a href="#section-8.1">Section 8.1</a>) does not provide any way
   to validate the authorization of requestors of a DHCPV4 Active
   Leasequery request.

   Servers SHOULD offer configuration parameters to limit the sources of
   incoming connections through validation and use of the digital
   certificates presented to create a TLS connection.  They SHOULD also
   limit the number of accepted connections and limit the period of time
   during which an idle connection will be left open.

   The data acquired by using an Active Leasequery is subject to the
   same potential abuse as the data held by the DHCPv4 server from which
   it was acquired and SHOULD be secured by mechanisms as strong as
   those used for the data held by that DHCPv4 server.  The data
   acquired by using an Active Leasequery SHOULD be deleted as soon as
   possible after the use for which it was acquired has passed.

   Servers that implement the Bulk Leasequery protocol [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] but do
   not implement the Active Leasequery protocol SHOULD implement the
   update to [<a href="./rfc6926" title="&quot;DHCPv4 Bulk Leasequery&quot;">RFC6926</a>] discussed in <a href="#section-8.1.1">Section 8.1.1</a>.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  IANA Considerations</span>

   IANA has assigned the following new DHCP message types from the
   registry "DHCP Message Type 53 Values" maintained at
   &lt;<a href="http://www.iana.org/assignments/bootp-dhcp-parameters">http://www.iana.org/assignments/bootp-dhcp-parameters</a>&gt;:

   1.  A dhcp-message-type of 16 for DHCPACTIVELEASEQUERY.

   2.  A dhcp-message-type of 17 for DHCPLEASEQUERYSTATUS.

   3.  A dhcp-message-type of 18 for DHCPTLS.




<span class="grey">Kinnear, et al.              Standards Track                   [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


   IANA has assigned the following new DHCP status codes from the
   registry "DHCP Status Code Type 151 Values" maintained at
   &lt;<a href="http://www.iana.org/assignments/bootp-dhcp-parameters">http://www.iana.org/assignments/bootp-dhcp-parameters</a>&gt;:

                  +----------------------+-------------+
                  | Name                 | Status-Code |
                  +----------------------+-------------+
                  | DataMissing          | 5           |
                  | ConnectionActive     | 6           |
                  | CatchUpComplete      | 7           |
                  | TLSConnectionRefused | 8           |
                  +----------------------+-------------+

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  References</span>

<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
              DOI 10.17487/RFC2119, March 1997,
              &lt;<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>&gt;.

   [<a id="ref-RFC2131">RFC2131</a>]  Droms, R., "Dynamic Host Configuration Protocol",
              <a href="./rfc2131">RFC 2131</a>, DOI 10.17487/RFC2131, March 1997,
              &lt;<a href="http://www.rfc-editor.org/info/rfc2131">http://www.rfc-editor.org/info/rfc2131</a>&gt;.

   [<a id="ref-RFC4388">RFC4388</a>]  Woundy, R. and K. Kinnear, "Dynamic Host Configuration
              Protocol (DHCP) Leasequery", <a href="./rfc4388">RFC 4388</a>,
              DOI 10.17487/RFC4388, February 2006,
              &lt;<a href="http://www.rfc-editor.org/info/rfc4388">http://www.rfc-editor.org/info/rfc4388</a>&gt;.

   [<a id="ref-RFC5246">RFC5246</a>]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>,
              DOI 10.17487/RFC5246, August 2008,
              &lt;<a href="http://www.rfc-editor.org/info/rfc5246">http://www.rfc-editor.org/info/rfc5246</a>&gt;.

   [<a id="ref-RFC6926">RFC6926</a>]  Kinnear, K., Stapp, M., Desetti, R., Joshi, B., Russell,
              N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery",
              <a href="./rfc6926">RFC 6926</a>, DOI 10.17487/RFC6926, April 2013,
              &lt;<a href="http://www.rfc-editor.org/info/rfc6926">http://www.rfc-editor.org/info/rfc6926</a>&gt;.

   [<a id="ref-RFC7525">RFC7525</a>]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", <a href="https://www.rfc-editor.org/bcp/bcp195">BCP 195</a>, <a href="./rfc7525">RFC 7525</a>, DOI 10.17487/RFC7525, May
              2015, &lt;<a href="http://www.rfc-editor.org/info/rfc7525">http://www.rfc-editor.org/info/rfc7525</a>&gt;.





<span class="grey">Kinnear, et al.              Standards Track                   [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>.  Informative References</span>

   [<a id="ref-RFC951">RFC951</a>]   Croft, W. and J. Gilmore, "Bootstrap Protocol", <a href="./rfc951">RFC 951</a>,
              DOI 10.17487/RFC0951, September 1985,
              &lt;<a href="http://www.rfc-editor.org/info/rfc951">http://www.rfc-editor.org/info/rfc951</a>&gt;.

   [<a id="ref-RFC1542">RFC1542</a>]  Wimer, W., "Clarifications and Extensions for the
              Bootstrap Protocol", <a href="./rfc1542">RFC 1542</a>, DOI 10.17487/RFC1542,
              October 1993, &lt;<a href="http://www.rfc-editor.org/info/rfc1542">http://www.rfc-editor.org/info/rfc1542</a>&gt;.

   [<a id="ref-RFC2132">RFC2132</a>]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", <a href="./rfc2132">RFC 2132</a>, DOI 10.17487/RFC2132, March 1997,
              &lt;<a href="http://www.rfc-editor.org/info/rfc2132">http://www.rfc-editor.org/info/rfc2132</a>&gt;.

   [<a id="ref-RFC4301">RFC4301</a>]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", <a href="./rfc4301">RFC 4301</a>, DOI 10.17487/RFC4301,
              December 2005, &lt;<a href="http://www.rfc-editor.org/info/rfc4301">http://www.rfc-editor.org/info/rfc4301</a>&gt;.

   [<a id="ref-RFC7414">RFC7414</a>]  Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
              Zimmermann, "A Roadmap for Transmission Control Protocol
              (TCP) Specification Documents", <a href="./rfc7414">RFC 7414</a>,
              DOI 10.17487/RFC7414, February 2015,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7414">http://www.rfc-editor.org/info/rfc7414</a>&gt;.

Acknowledgments

   The ideas in this document came in part from work in DHCPv6 and
   DHCPv4 Bulk Leasequery as well as from in depth discussions between
   the authors.  Useful review comments by Ted Lemon, Scott Bradner,
   Francis Dupont, and Stephen Farrell on drafts for DHCPv6 Active
   Leasequery were also included in this draft.  Brian Haberman's review
   brought this document into much closer alignment with DHCPv6 Active
   Leasequery.  Additional reviews by Alissa Cooper, Spencer Dawkins,
   Christer Holmberg, and Ben Campbell added clarity to this document.

















<span class="grey">Kinnear, et al.              Standards Track                   [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc7724">RFC 7724</a>                Active DHCPv4 Lease Query          December 2015</span>


Authors' Addresses

   Kim Kinnear
   Cisco Systems, Inc.
   1414 Massachusetts Ave
   Boxborough, MA  01719
   United States

   Email: kkinnear@cisco.com


   Mark Stapp
   Cisco Systems, Inc.
   1414 Massachusetts Ave
   Boxborough, MA  01719
   United States

   Email: mjs@cisco.com


   Bernie Volz
   Cisco Systems, Inc.
   1414 Massachusetts Ave
   Boxborough, MA  01719
   United States

   Email: volz@cisco.com


   Neil Russell
   Staples
   500 Staples Drive
   Framingham, MA  01702
   United States

   Email: neil.e.russell@gmail.com















Kinnear, et al.              Standards Track                   [Page 28]
</pre>