DHC Working Group                                            Kim Kinnear
Internet Draft                                               Bernie Volz
Intended Status: Standards Track                            Neil Russell
Expires: August 13, 2009 April 26, 2010                                       Mark Stapp
                                                     Cisco Systems, Inc.
                                                                  D. Rao
                                                                B. Joshi
                                                             P. Kurapati
                                               Infosys Technologies Ltd.
                                                       February 13,
                                                        October 26, 2009

                        Bulk DHCPv4 Lease Query
             <draft-ietf-dhc-dhcpv4-bulk-leasequery-00.txt>
             <draft-ietf-dhc-dhcpv4-bulk-leasequery-01.txt>

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 13, 2009 April 26, 2010

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) 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 BSD License.

Abstract

   The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been
   extended with a Leasequery capability that
   extension allows a requestor to request information about DHCPv4
   bindings.  That This mechanism is limited to queries for individual
   bindings. In some situations individual binding queries may not be
   efficient, or even possible. This document expands on extends the DHCPv4
   Leasequery protocol to allow for bulk transfer of DHCPv4 address
   binding data via TCP.

Table of Contents
    1.  Introduction................................................. 3
    2.  Terminology.................................................. 4
    3.  Motivation................................................... 6
    4.  Design Goals................................................. 8
    4.1. 6
    3.1.  Information Acquisition before Data Starts................. 8
    4.2. 7
    3.2.  Lessen need for Caching and Negative Caching............... 8
    4.3. 7
    3.3.  Antispoofing in 'Fast Path'................................ 8
    4.4. 7
    3.4.  Minimize data transmission................................. 8
    5. 7
    4.  Protocol Overview............................................ 9
    6. 8
    5.  Interaction Between UDP Leasequery and Bulk Leasequery....... 10
    7. 9
    6.  Message and Option Definitions............................... 11
    7.1. 10
    6.1.  Message Framing for TCP.................................... 11
    7.2. 10
    6.2.  New or Changed Options..................................... 12
    7.3. 11
    6.3.  Connection and Transmission Parameters..................... 20
    8. 19
    7.  Requestor Behavior........................................... 20
    8.1. 19
    7.1.  Connecting and General Processing.......................... 20
    8.2. 19
    7.2.  Forming a Bulk Leasequery.................................. 21
    8.3. 20
    7.3.  Processing Bulk Replies.................................... 23
    8.4. 22
    7.4.  Processing Time Values in Leasequery messages.............. 25
    8.5. 24
    7.5.  Querying Multiple Servers.................................. 27
    8.6. 24
    7.6.  Making Sense Out of Multiple Responses Concerning a Single. 27
    8.7. 25
    7.7.  Multiple Queries to a Single Server over One Connection.... 28
    8.8. 25
    7.8.  Closing Connections........................................ 29
    9. 27
    8.  Server Behavior.............................................. 29
    9.1. 27
    8.1.  Accepting Connections...................................... 29
    9.2. 27
    8.2.  Replying to a Bulk Leasequery.............................. 30
    9.3. 28
    8.3.  Building a Single Reply for Bulk Leasequery................ 34
    9.4. 31
    8.4.  Multiple or Parallel Queries............................... 35
    9.5. 33
    8.5.  Closing Connections........................................ 36
    10. 33
    9.  Security Considerations..................................... 36
    11. Considerations...................................... 33
    10.  IANA Considerations......................................... 36
    12. 34
    11.  Acknowledgements............................................ 38
    13. 35

    12.  References.................................................. 38
    13.1. 35
    12.1.  Normative References...................................... 38
    13.2. 35
    12.2.  Informative References.................................... 39 36
    Authors' Addresses............................................... 39
    Appendix -- Why a New Leasequery is Required..................... 41 37

1.  Introduction

   The DHCPv4 protocol [RFC2131] [RFC2132] specifies a mechanism for the
   assignment of IPv4 address and configuration information to IPv4
   nodes.  DHCPv4 servers maintain authoritative binding information.

      +--------+
      | DHCPv4 |     +--------------+
      | Server |-...-|    DSLAM     |
      |        |     |  Relay Agent |
      +--------+     +--------------+
                          |        |
                      +------+   +------+
                      |Modem1|   |Modem2|
                      +------+   +------+
                         |        |    |
                      +-----+  +-----+ +-----+
                      |Host1|  |Host2| |Host3|
                      +-----+  +-----+ +-----+

                  Figure 1:  Example DHCPv4 configuration

   DHCPv4 relay agents receive DHCPv4 messages and frequently append a
   relay agent information option [RFC3046] before relaying them to the
   configured DHCPv4 servers (see Figure 1). In this process, some relay
   agents also glean the lease information sent by the server and
   maintain this cache it
   locally. This information is used for a variety of
   purposes, including purposes.   Two
   examples are prevention of spoofing attempts from the DHCPv4
   clients clients,
   and to install installation of routes. When a relay agent reboots, this
   information is frequently lost.

   The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4
   capability to allow an external entity, such as a relay agent, to
   query a DHCPv4 server to recover lease state information about a
   particular IP address or client in near real-time.

   The existing query types in Leasequery are typically data driven; the
   relay agent initiates the Leasequery when it receives data traffic
   from or to the client.  This approach may not scale well when there
   are thousands of clients connected to the relay agent or when the
   relay agent has a need to rebuild its internal data store prior to
   processing traffic in one direction or another.

   Different query types are needed where a relay agent can

   Some applications require the ability to query the server without
   waiting for the traffic from or for the clients, as
   well as a different transmission technique to clients. This query capability in turn
   requires an underlying transport more conducive suitable to the bulk
   transmission of large quantities of data.

   This document extends the DHCPv4 Leasequery protocol to add support
   for queries that address these additional requirements.  There may be
   many thousands of DHCPv4 bindings returned as the result of a single
   request, so TCP [RFC4614] is specified for efficiency of data
   transfer.  We define several additional query types, each of which
   could return multiple responses, in order to meet a variety of
   requirements.

2.  Terminology

   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 RFC 2119 [RFC2119].

   This document uses the following terms:

      o "absolute time"

        A 32-bit quantity containing the number of seconds since Jan 1,
        1970.

      o "access concentrator"

        An access concentrator is a router or switch at the broadband
        access provider's edge of a public broadband access network.
        This document assumes that the access concentrator includes the
        DHCPv4 relay agent functionality.  For example, a CMTS (Cable
        Modem Termination System) in Cable environment or a DSLAM
        (Digital Subscriber Line Multiplexer) in a DSL environment.

      o "active binding"

        An IP address with an active binding refers to an IP address
        which is currently associated with a DHCPv4 client where that
        DHCPv4 client has the right to use the IP address.

      o "Bulk Leasequery"

        Requesting and receiving the existing DHCPv4 address binding
        information in an efficient manner.

      o "clock skew"

        The difference between the absolute time on a DHCPv4 server and
        the absolute time on the system where a requestor of a Bulk
        Leasequery is executing is termed the "clock skew" for that Bulk
        Leasequery connection.  It is not absolutely constant but is
        likely to vary only slowly.  It is possible that, when both
        systems run NTP, the clock skew is negligible, and this is not
        only acceptable, but desired.

        While it is easy to think that this can be calculated precisely
        after one message is received by a requestor from a DHCPv4
        server, a more accurate value is derived from continuously
        examining the instantaneous value developed from each message
        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 Internet host using DHCPv4 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 [RFC951] and [RFC1542].

      o "DHCPv4 server"

        A DHCPv4 server is an Internet host that returns configuration
        parameters to DHCPv4 clients.

      o "DSLAM"

        Digital Subscriber Line Multiplexer.

      o "downstream"

        Refers to a direction away from the central part of a network
        and toward the edge.  In a DHCPv4 context, typically refers to a
        network direction which is away from the DHCPv4 server.

      o "IP address"

        In this document, the term "IP address" refers to an IPv4 IP
        address.

      o "IP address binding"

        The information that a DHCPv4 server keeps regarding the
        relationship between a DHCPv4 client and an IPv4 IP 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.  In some contexts, this may include
        information on IP addresses that are currently associated with
        DHCPv4 clients, and in others it may also include IP addresses
        with no current association to a DHCPv4 client.

      o "MAC address"

        In the context of a DHCPv4 message, a MAC address consists of
        the fields: hardware type "htype", hardware length "hlen", and
        client hardware address "chaddr".

      o "upstream"

        Refers to a direction toward the central part of a network and
        away from the edge.  In a DHCPv4 context, typically refers to a
        network direction which is toward the DHCPv4 server.

      o "stable storage"

        Stable storage is used to hold information concerning IP address
        bindings (among other things) so that this information is not
        lost in the event of a failure which requires restart of the
        network element.  DHCPv4 servers are typically expected to have
        high speed access to stable storage, while relay agents and
        access concentrators usually do not have access to stable
        storage, although they may have periodic access to such storage.

      o "xid"

        Transaction-id.  The term "xid" refers to the DHCPv4 field
        containing the transaction-id of the message.

3.  Motivation

   Consider a typical DSLAM working also as a DHCPv4 relay agent (see
   Figure 1). Typically, both a "fast path" and a "slow path" exist in
   many network elements, including DSLAMs.  Fast path processing  Design Goals

   The goal of this document is
   done in to provide a network processor or in lightweight mechanism for
   an ASIC (Application Specific
   Integrated Circuit).  Slow path processing is done in a normal
   processor.  As much as possible, regular data handling code should be Access Concentrator or other network element to retrieve IP
   address binding information available in the fast path.  Slow path processing DHCPv4 server.  The
   mechanism should be reduced as it may
   become a bottleneck.

   For a DSLAM having multiple DSL ports, multiple IP addresses may be
   assigned using DHCPv4 to a single port and the number of DHCPv4
   clients on a port may be unknown.  The DSLAM may also not know the
   network portions of the IP addresses that are assigned allow an Access Concentrator to its DHCPv4
   clients.

   The DSLAM gleans retrieve
   consolidated IP address or other information from DHCP
   negotiations for antispoofing and for other purposes.  The
   antispoofing itself is done in the fast path. The DSLAM keeps track
   of only one list of IP addresses: the list of IP addresses that are
   assigned by a DHCPv4 server.  Traffic for all other IP addresses is
   dropped.  If a client starts its data transfer after its DHCPv4
   negotiations are gleaned by the DSLAM, no legitimate packets will be
   dropped because of antispoofing.  In other words, antispoofing is
   effective (no legitimate packets are dropped and all spoofed packets
   are dropped) and efficient (antispoofing is done in the fast path).
   The intention is to achieve similar effective and efficient
   antispoofing in the Leasequery scenario after a DSLAM loses its
   gleaned binding information (for example, because of reboot).

   After a deep analysis, we found that the three existing query types
   supported by [RFC4388] do not provide effective and efficient
   antispoofing for either the above scenario and entire
   access concentrator or a new mechanism is required. single connection/circuit.

3.1.  Information Acquisition before Data Starts

   The existing query types

      o necessitate a data driven approach: approach required by [RFC4388] means that
   the lease queries Leasequeries can only be done when the performed after an Access Concentrator
   receives data.  That
        results in increased outage time To implement antispoofing, the concentrator must drop
   packets for each client until it gets lease information from DHCPv4 clients;

      o result in excessive negative caching consuming lot of resources
        under a spoofing attack;

      o result in antispoofing being done in the slow path instead of
        the fast path;

      o do not support an Access Concentrator which periodically uploads
        its internal table to some form of stable storage.

   The deeper analysis, which led to the above conclusions, itself
   appears as an Appendix to this document.

4.  Design Goals

   The goal of this document is to provide a lightweight mechanism for
   an Access Concentrator or other network element to retrieve IP
   address binding information available in the DHCPv4 server.  The
   mechanism should also allow an Access Concentrator to retrieve
   consolidated IP address binding information for either the entire
   access concentrator or a single connection/circuit.

4.1.  Information Acquisition before Data Starts

   The existing data driven approach required by [RFC4388] means that
   the Leasequeries can only be performed after an Access Concentrator
   receives data.  To implement antispoofing, packets need to be dropped
   until it gets the lease information from DHCPv4 server.  If
   server for that client. If an Access Concentrator finishes the
   Leasequeries before it starts receiving data, then there is no need
   to drop legitimate packets. In this way, outage time may be reduced.

4.2.

3.2.  Lessen need for Caching and Negative Caching

   The result of a single Leasequery should be cached, whether that
   results in a positive or negative cache, in order to remember that
   the Leasequery was performed.  This caching is required to limit the
   traffic imposed upon a DHCPv4 server by Leasequeries for information
   already received.

   These caches not only consume precious resources, they also need to
   be managed.  Hence they should be avoided as much as possible.

4.3.

3.3.  Antispoofing in 'Fast Path'

   If Antispoofing is not done in the fast path, it will become a
   bottleneck and may lead to denial of service of the access
   concentrator.  The Leasequeries should make it possible to do
   antispoofing in the fast path.

4.4.

3.4.  Minimize data transmission

   It may be that a network element is able to periodically save its
   entire list of assigned IP addresses to some form of stable storage.
   In this case, it will wish to recover all of the updates to this
   information without duplicating the information it has recovered from
   its own stable storage.

   Bulk Leasequery allows the specification of a query-start-time as
   well as a query-end-time.  Use of query-times allows a network
   element that periodically commits information to stable storage to
   recover just what it lost since the last commit.

5.

4.  Protocol Overview

   The Bulk Leasequery mechanism is modeled on the existing individual
   Leasequery protocol in [RFC4388] as well as related work on DHCPv6
   Bulk Leasequery [DHCPv6Bulk]. [RFC5460]. A Bulk Leasequery requestor opens a TCP
   connection to a DHCPv4 Server, using the DHCPv4 port 67.  Note that
   this implies that the Leasequery requestor has server IP address(es)
   available via configuration or some other means, and that it has
   unicast IP reachability to the DHCPv4 server.  No relaying of Bulk
   Leasequery messages is specified.

   After establishing a connection, the requestor sends a
   DHCPBULKLEASEQUERY message over the connection.

   The server uses the message type and additional data in the DHCPv4
   DHCPBULKLEASEQUERY message to identify any relevant bindings.

   In order to support some query types, servers may have to maintain
   additional data structures or otherwise be able to locate bindings
   that have been requested by the Leasequery requestor.

   Relevant bindings are returned in DHCPv4 packets with either the
   DHCPLEASEACTIVE message type for an IP address with a currently
   active lease or, in some situations, a DHCPLEASEUNASSIGNED message
   type for an IP address which is controlled by the DHCPv4 server but
   which is not actively leased by a DHCPv4 client at the present time.

   The Bulk Leasequery mechanism is designed to provide an external
   entity with information concerning existing DHCPv4 IPv4 address
   bindings managed by the DHCPv4 server.  When complete, the DHCPv4
   server will send a DHCPLEASEQUERYDONE message.  If a connection is
   lost while processing a Bulk Leasequery, the Bulk Leasequery must be
   retried as there is no provision for determining the extent of data
   already received by the requestor for a Bulk Leasequery.

   Bulk Leasequery supports queries by MAC address and by Client
   Identifier in a way similar to [RFC4388].  The Bulk Leasequery
   protocol also adds several new queries.

      o Query by Relay Identifier

        This query asks a server for the bindings associated with a
        specific relay agent; the relay agent is identified by a DUID
        carried in a Relay-ID sub-option [RelayId]. Relay agents can
        include this sub-option while relaying messages to DHCPv4
        servers.  Servers can retain the Relay-ID and associate it with
        bindings made on behalf of the relay agent's clients. The
        bindings returned are only those for DHCPv4 clients with a
        currently active binding.

      o Query by Remote ID

        This query asks a server for the bindings associated with a
        Relay Agent Remote-ID sub-option [RFC3046] value. The bindings
        returned are only those for DHCPv4 clients with a currently
        active binding.

      o Query for All Configured IP Addresses

        This query asks a server for information concerning all IP
        addresses configured in that DHCPv4 server, by specifying no
        other type of query. In this case, the bindings returned are for
        all configured IP addresses, whether or not they contain a
        currently active binding to a DHCPv4 client, since one point of
        this type of query is to update an existing database with
        changes after a particular point in time.

   Any of the above queries can be qualified by the specification of a
   query-start-time or a query-end-time (or both). When these timers are
   used as qualifiers, they indicate that a binding should be included
   if it changed on or after the query-start-time and on or before the
   query-end-time.

   In addition, any of the above queries can be qualified by the
   specification of a vpn-id option [VpnId] to select the VPN on which
   the query should be processed.  The vpn-id option is also extended to
   allow queries across all available VPNs. By default, only the default
   VPN is used to satisfy the query.

6.

5.  Interaction Between UDP Leasequery and Bulk Leasequery

   Bulk Leasequery can be seen as an extension of the existing UDP
   Leasequery protocol [RFC4388].  This section clarifies the
   relationship between the two protocols.

   Only the DHCPBULKLEASEQUERY request is supported over the Bulk
   Leasequery connection. No other DHCPv4 requests are supported.  The
   Bulk Leasequery connection is not an alternative DHCPv4 communication
   option for clients seeking other DHCPv4 services.

   Two of the query-types introduced in the UDP Leasequery protocol can
   be used in the Bulk Leasequery protocol -- query by MAC address and
   query by client-id.

   The contents of the reply messages are similar between the existing
   UDP Leasequery protocol and the Bulk Leasequery protocol, though more
   information is returned in the Bulk Leasequery messages.

   One change in behavior for these existing queries is required when
   Bulk Leasequery is used.  [RFC4388], in sections 6.1, 6.4.1, and
   6.4.2 specifies the use of an associated-ip option in DHCPLEASEACTIVE
   messages in cases where multiple bindings were found.  When Bulk
   Leasequery is used, this mechanism is not necessary; a server
   returning multiple bindings simply does so directly as specified in
   this document.  The associated-ip option MUST NOT appear in Bulk
   Leasequery replies.

   Implementors should note that the TCP message framing defined in
   Section 5.1 4.1 is not compatible with the UDP message format.  If a TCP-
   framed request is sent as a UDP message, it may not be valid, because
   protocol fields will be offset by the message-size prefix.

7.

6.  Message and Option Definitions

7.1.

6.1.  Message Framing for TCP

   The use of TCP for the Bulk Leasequery protocol permits multiple
   messages to be sent from one end of the connection to the other
   without requiring a request/response paradigm as does UDP DHCPv4
   [RFC2131].  The receiver needs to be able to determine the size of
   each message it receives.  Two octets containing the message size in
   network byte-order are prepended to each DHCPv4 message sent on a
   Bulk Leasequery TCP connection. The two message-size octets 'frame'
   each DHCPv4 message.

   The maximum message size is 65535 octets.

   DHCPv4 message framed for TCP:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         message-size          |    op (1)     |   htype (1)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   hlen (1)    |   hops (1)    |              ....             |
      +---------------+---------------+                               +
      |                                                               |
      .                  remainder of DHCPv4 message,
      .                   from Figure 1 of [RFC2131]                  .
      .                                                               .
      .                           (variable)                          .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           message-size    the number of octets in the message that
                           follows, as a 16-bit integer in network
                           byte-order.

           All other fields are as specified in DHCPv4 [RFC2131].

                  Figure 2:  Format of a DHCPv4 message in TCP

   The intent in using this format is that code which currently knows
   how to deal with sending or receiving a message in [RFC2131] format
   will easily be able to deal with the message contained in the TCP
   framing.

7.2.

6.2.  New or Changed Options

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

   Additional options have also been defined to enable the Bulk
   Leasequery protocol to communicate useful information to the
   requestor.

7.2.1.

6.2.1.  dhcp-message-type

   The dhcp-message-type option (option 53) from Section 9.6 of
   [RFC2132] requires new values.  The values of these message types are
   shown below in an extension of the table from Section 9.6 of
   [RFC2132]:

            Value   Message Type
            -----   ------------
              14    DHCPBULKLEASEQUERY
              15    DHCPLEASEQUERYDONE

7.2.2.

6.2.2.  dhcp-message

   The dhcp-message option (option 56) from Section 9.9 of [RFC2132]
   requires additional definition for use in the context of a
   DHCPBULKLEASEQUERY.

   The format of the NVT ASCII message in the dhcp-message option is
   specified to have the first three characters appear in a constrained
   format.  The first three characters MUST be numeric (base 10)
   characters.

   Encoded in these first three characters is the decimal number
   corresponding to a variety of status codes defined below.

   The motivation for this constraint of the existing dhcp-message
   option is to reduce the number of top-level options used by this
   document.

   The status code returned in the dhcp-message option allows greater
   detail to be returned regarding the status of a DHCPBULKLEASEQUERY
   request.  While specified in the Bulk Leasequery document, this
   additional specification of the DHCPv4 dhcp-message option may well
   be valuable in other circumstances.  In those circumstances its scope
   should be explicitly defined.

   This option has two possible scopes when used with Bulk 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 or DHCPLEASEUNASSIGNED.  It refers to
   the message stream related to an entire request if the value of the
   dhcp-message-type is DHCPLEASEQUERYDONE.

   The code for this option is 56. The length of this option is at least
   3 octets.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  option-code  |  option-len   | left-number   | middle-number |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | right-number  |    status-message (if any)   ...              .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         option-code     56.

         option-len      3 + length of status-message (which may be 0).

         left-number     NVT ASCII encoded characters representing the
         middle-number   base-10 value of the status code, taken
         right-number    from the table below.

         status-message  An optional NVT ASCII encoded text string
                         suitable for display to an end user, which
                         MUST NOT be null-terminated.  It SHOULD
                         start with an NVT ASCII space.

     Name    status-code Description
     ----    ----------- -----------
     Success         000 Success.  Also signaled by absence of
                         a dhcp-message option.

     UnspecFail      001 Failure, reason unspecified.

     QueryTerminated 002 Indicates that the server is unable to
                         perform a query or has prematurely terminated
                         the query for some reason (which should be
                         communicated in the text message).

     MalformedQuery  003 The query was not understood.

     NotAllowed      004 The query or request was understood but was
                         not allowed in this context.

   A dhcp-message option MAY appear in the options field of a DHCPv4
   message.  If the dhcp-message option does not appear, it is assumed
   that the operation was successful.  The dhcp-message option SHOULD
   NOT appear in a message which is successful unless there is some text
   string that needs to be communicated to the requestor.

7.2.3.

6.2.3.  base-time

   The base-time option is the current time the message was created to
   be sent by the DHCPv4 server to the requestor of the Bulk Leasequery.
   This MUST be an absolute time. All of the other time based options in
   the reply message are relative to this time, including the dhcp-
   lease-time [RFC2132] and client-last-transaction-time [RFC4388].
   This time is in the context of the DHCPv4 server.

   This is an integer in network byte order.

   The code for this option is TBD1. The length of this option is 4
   octets.

                       DHCPv4 Server
       Code   Len        Base Time
      +-----+-----+-----+-----+-----+-----+
      | TBD1|  4  |  t1 |  t2 |  t3 |  t4 |
      +-----+-----+-----+-----+-----+-----+

7.2.4.

6.2.4.  start-time-of-state

   The start-time-of-state option allows the receiver to determine the
   time at which the IP address transitioned made the transition into its current
   state.

   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 specified in the
   base-time option in the same message that the IP address transitioned
   into its current state.  In the same way that the IP Address Lease
   Time option (option 51) encodes a lease time which is a number of
   seconds into the future from the time the message was sent, this
   option encodes a value which is a number of seconds into the past
   from the base-time option included in the same message.

   This is an integer in network byte order.

   The code for this option is TBD2. The length of this option is 4
   octets.

                     Seconds in the past
       Code   Len      from base-time
      +-----+-----+-----+-----+-----+-----+
      | TBD2|  4  |  t1 |  t2 |  t3 |  t4 |
      +-----+-----+-----+-----+-----+-----+

7.2.5.

6.2.5.  query-start-time

   The query-start-time option allows the requestor to specify specifies a start query time to the
   DHCPv4 server.  If specified, only bindings that have changed on or
   after the query-start-time should be included in the response to the
   query.

   This MUST be an absolute time.

   This

   The requester MUST be a time in the context of the DHCPv4 server.  In compute the
   absence of information query-start-time relative to a lease
   it has received from the contrary, the requestor SHOULD assume DHCPv4 server, and MUST specify that the time context in
   terms of the DHCPv4 server server's clock.

   Typically (though this is identical to not a requirement) the time
   context of query-start-time
   option will contain the requestor.

   It SHOULD NOT be a time value most recently received in a base-time
   option by the context of requestor, as this will indicate the requestor. last successful
   communication with the DHCP server.

   This MUST be an absolute time.

   This is an integer in network byte order.

   The code for this option is TBD3. The length of this option is 4
   octets.

                         DHCPv4 Server
       Code   Len      query-start-time
      +-----+-----+-----+-----+-----+-----+
      | TBD3|  4  |  t1 |  t2 |  t3 |  t4 |
      +-----+-----+-----+-----+-----+-----+

7.2.6.

6.2.6.  query-end-time

   The query-end-time option allows the requestor to specify specifies an end query time to the DHCPv4
   server.  If specified, only bindings that have changed on or before
   the query-end-time should be included in the response to the query.

   This MUST be an absolute time.

   This

   The requester MUST be a time in compute the context of the DHCPv4 query-end-time relative to a lease it
   has received from the DHCPv4 server, and MUST specify that time in
   terms of the DHCPv4 server's clock.

   This MUST be an absolute time.

   This MUST be a time in the context of the DHCPv4 server.  In the
   absence of information to the contrary, the requestor SHOULD assume
   that the time context of the DHCPv4 server is identical to the time
   context of the requestor.

   It SHOULD NOT be a time in the context of the requestor.

   This is an integer in network byte order.

   The code for this option is TBD4. The length of this option is 4
   octets.

                         DHCPv4 Server
       Code   Len       query-end-time
      +-----+-----+-----+-----+-----+-----+
      | TBD4|  4  |  t1 |  t2 |  t3 |  t4 |
      +-----+-----+-----+-----+-----+-----+

7.2.7.

6.2.7.  dhcp-state

   The dhcp-state option allows greater detail to be returned than
   allowed by the DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types.

   The code for this option is TBD6. The length of this option is 1
   octet.

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     TBD6      |    Length     |    State      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        TBD6     The option code.

        Length   The option length, 1 octet.

        State    The State of the IP address.

      Value  State
      -----  -----
        1   AVAILABLE   Address is available to local DHCPv4 server
        2   ACTIVE      Address is assigned to a DHCPv4 client
        3   EXPIRED     Lease has expired
        4   RELEASED    Lease has been released by DHCPv4 client
        5   ABANDONED   Server or client flagged address as unusable
        6   RESET       Lease was freed by some external agent
        7   REMOTE      Address is available to a remote DHCPv4 server
        8   TRANSITIONING Address is moving between states

   Note that some of these states may be transient and may not appear in
   normal use.   A DHCPv4 server MUST implement at least the AVAILABLE
   and ACTIVE states, and SHOULD implement at least the ABANDONED and
   RESET states.

   The dhcp-state option SHOULD contain ACTIVE when it appears in a
   DHCPLEASEACTIVE message.  A DHCPv4 server MAY choose to not send a
   dhcp-state option in a DHCPLEASEACTIVE message, and a requestor
   SHOULD assume that the dhcp-state is ACTIVE if no dhcp-state option
   appears in a DHCPLEASEACTIVE message.

   The reference to local and remote relate to possible use in an
   environment that includes multiple servers cooperating to provide an
   increased availability solution.  In this case, an IP address with
   the state of AVAILABLE is available to the local server, while one
   with the state of REMOTE is available to a remote server.  Usually,
   an IP address which is AVAILABLE on one server would be REMOTE on any
   remote server.  The TRANSITIONING state is also likely to be useful
   in multiple server deployments, where sometimes one server must
   interlock a state change with one or more other servers.  Should a
   Bulk Leasequery need to send information concerning the state of the
   IP address during this period, it SHOULD use the TRANSITIONING state,
   since the IP address is likely to be neither ACTIVE or AVAILABLE.

   There is no requirement for the state of an IP address to transition
   in a well defined way from state to state.  To put this another way,
   you cannot draw a simple state transition graph for the states of an
   IP address and the requestor of a Leasequery MUST NOT depend on one
   certain state always following a particular previous state.  In
   general, every state can (at times) follow every other state.

7.2.8.

6.2.8.  data-source

   The data-source option contains information about the source of the
   data in a DHCPLEASEACTIVE or a DHCPLEASEUNASSIGNED message.  It is
   used when there are two or more servers who might have information
   about a particular IP address binding.  Frequently two servers work
   together to provide an increased availability solution for the DHCPv4
   service, and in these cases, both servers will respond to Bulk
   Leasequery requests for the same IP address.

   The data contained in this option will allow an external process to
   better discriminate between the information provided by each of the
   servers servicing this IPv4 address.

   The code for this option is TBD5. The length of this option is 1
   octet.

         0                   1                   2
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     TBD5      |    Length     |     Flags     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          TBD5     The option code.

          Length   The option length, 1 octet.

          Flags    The Source information for this message.

                      0 1 2 3 4 5 6 7
                     +-+-+-+-+-+-+-+-+
                     |    MBZ      |R|
                     +-+-+-+-+-+-+-+-+

                     R:  REMOTE flag

                          remote = 1
                          local = 0

                     MBZ:  MUST BE ZERO (reserved for future use)

   The REMOTE flag is used to indicate where the most recent change of
   state (or other interesting change) concerning this IPv4 address took
   place.  If the value is local, then the change took place on the
   server from which this message was transmitted.  If the value is
   remote, then the change took place on some other server, and was made
   known to the server from which this message was transmitted.

   If this option was requested and it doesn't appear, the the requestor
   SHOULD consider that the data-source was local.

7.2.9.

6.2.9.  Virtual Subnet Selection Type and Information

   All of the (sub)options defined in [VpnId] carry identical payloads,
   consisting of a type and additional VSS (Virtual Subnet Selection)
   information.  The existing table is extended (see below) with a new
   type 254 to allow specification of a type code which indicates that
   all VPN's are to be used to process the Bulk Leasequery.

          Type     VSS Information format:
          ----     -----------------------
           0       NVT ASCII VPN identifier
           1       RFC2685 VPN-ID
           2-253   Not Allowed
    NEW -> 254     All VPN's (wildcard).
           255     Global, default VPN.

7.3.

6.3.  Connection and Transmission Parameters

   DHCPv4 servers that support Bulk Leasequery SHOULD listen for
   incoming TCP connections on the DHCPv4 server port 67.
   Implementations MAY offer to make the incoming port configurable, but
   port 67 MUST be the default.  Requestors SHOULD make TCP connections
   to port 67, and MAY offer to make the destination server port
   configurable.

   This section presents a table of values used to control Bulk
   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 are NOT RECOMMENDED.

   Parameter             Default   Description
   -------------------------------------------
   BULK_LQ_DATA_TIMEOUT  300 secs  Bulk Leasequery data timeout
   BULK_LQ_MAX_CONNS     10        Max Bulk Leasequery TCP connections

8.

7.  Requestor Behavior

8.1.

7.1.  Connecting and General Processing

   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.

   If Bulk 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.

   Messages from the DHCPv4 server come as multiple responses to a
   single DHCPBULKLEASEQUERY message. Thus, each DHCPBULKLEASEQUERY
   request MUST have a xid (transaction-id) unique on the connection on
   which it is sent, and all sent.   All of the messages which come as a response to
   it all
   that message will contain the same xid as the request. It is the xid
   which allows the data-streams of two different DHCPBULKLEASEQUERY
   requests to be demultiplexed by the requestor.

   A requestor MAY send a DHCPBULKLEASEQUERY request to a DHCPv4 server
   and immediately close the transmission side of its TCP connection,
   and then read the resulting response messages from the DHCPv4 server.
   This is not required, and the usual approach is to leave both sides
   of the TCP connection up until at least the conclusion of the Bulk
   Leasequery.

8.2.

7.2.  Forming a Bulk Leasequery

   Bulk Leasequery is designed to create a connection which will
   transfer the state of some subset (or possibly all) of the IP address
   bindings from the DHCPv4 server to the requestor.  The DHCPv4 server
   will send all of the requested IPv4 address bindings across this
   connection with minimal delay after it receives the request.  In this
   context, "all IP address binding information" means information about
   all IPv4 addresses configured within the DHCPv4 server which meet the
   specified query criteria.  For some query criteria, this may include
   IP address binding information for IP addresses which may not now
   have or ever had have an association with a specific DHCPv4 client.

   To form the Bulk query, a DHCPv4 request is constructed with a dhcp-
   message-type of DHCPBULKLEASEQUERY. The query SHOULD have a dhcp-
   parameter-request-list to inform the DHCPv4 server which DHCPv4
   options are of interest to the requestor sending the
   DHCPBULKLEASEQUERY message.  The dhcp-parameter-request-list in a
   DHCPBULKLEASEQUERY message SHOULD contain the codes for base-time,
   dhcp-lease-time, start-time-of-state, and client-last-transaction-
   time.

   A DHCPBULKLEASEQUERY request is constructed of one primary query and
   optionally one or more qualifiers for it.

   The possible primary queries are listed below.  Each
   DHCPBULKLEASEQUERY request MUST contain only one of these primary
   queries.

      o Query by MAC address

        In a Query by MAC address, the chaddr, htype, and hlen of the
        DHCPv4 packet are filled in with the values requested.

      o Query by Client-Id

        In a Query by Client-Id, the dhcp-client-id option containing
        the requested value is included in the DHCPBULKLEASEQUERY
        request.

      o Query by Remote-Id

        In a Query by Remote-Id, the remote-id sub-option of the relay-
        agent-information option containing the requested value is
        included in the DHCPBULKLEASEQUERY request.

      o Query by Relay-Id

        In a Query by Relay-Id, the relay-id sub-option [RelayId] of the
        relay-agent-information option containing the requested value is
        included in the DHCPBULKLEASEQUERY request.

      o Query for All Configured IP Addresses

        A Query for All Configured IP addresses is signaled by the
        absence of any other primary query.

   There are three qualifiers which can be applied to any of the above
   primary queries.  These qualifiers can appear individually or
   together in any combination, but only one of each can appear.

   o Query Start Time

     Inclusion of the query-start-time option specifies that only IP
     address bindings which have changed on or after the time specified
     in the query-start-time option should be returned.

   o Query End Time

     Inclusion of the query-end-time option specifies that only IP
     address bindings which have changed on or before the time specified
     in the query-end-time option should be returned.

   o VPN Id

     If no vpn-id option appears in the DHCPBULKLEASEQUERY, the default
     VPN is used to search to satisfy the query specified by the
     DHCPBULKLEASEQUERY. Using the vpn-id option [VpnId] allows the
     requestor to specify a single VPN other than the default VPN.  In
     addition, the vpn-id option has been extended as part of this
     document to allow specification that all configured VPN's be
     searched in order to satisfy the query specified in the
     DHCPBULKLEASEQUERY.

     In all cases, any message returned from a DHCPBULKLEASEQUERY
     request containing information about an IP address for other than
     the default VPN MUST contain a vpn-id option in the message.

   Both of the query-start-time and query-end-time options (if they
   appear) MUST be in the time context of the DHCPv4 server to which the
   Bulk Leasequery is directed.  In the absence of information to the
   contrary, the requestor SHOULD assume that the time context on the
   DHCPv4 server is identical to the time context on the requestor.  In
   the event that previous operations have determined that the time
   context on the DHCPv4 server to which the Bulk Leasequery is
   addressed differs from the time context of the requestor, the time
   context of the DHCPv4 server MUST be used.

   Use of the query-start-time or the query-end-time options or both can
   serve to reduce the amount of data transferred over the TCP
   connection by a considerable amount.

   If the

   The TCP connection becomes may become blocked or stops stop being writeable writable while
   the requestor is sending its query, query.   Should this happen, the requestor SHOULD be prepared
   to terminate
   implementation's behavior is controlled the connection after current value of
   BULK_LQ_DATA_TIMEOUT.  We make  The default value is given elsewhere in this
   recommendation to allow requestors to control the period
   document, and this value may be overridden by local configuration of time they
   are willing to wait before abandoning
   the operator.

   If this situation is detected, the requester SHOULD start a connection, independent timer
   using the current value of
   notifications from BULK_LQ_DATA_TIMEOUT.  If that timer
   expires, the TCP implementations they may be using.

8.3. requester SHOULD terminate the connection.

7.3.  Processing Bulk Replies

   The requestor attempts to read a DHCPv4 Leasequery message from the
   TCP connection. If the

   The TCP connection stops may stop delivering reply data (if (i.e., the
   connection stops being readable), readable).  Should this happen, the Requestor SHOULD
   implementation's behavior is controlled the current value of
   BULK_LQ_DATA_TIMEOUT.  The default value is given elsewhere in this
   document, and this value may be
   prepared to overridden by local configuration of
   the operator.

   If this situation is detected, the requester SHOULD start a timer
   using the current value of BULK_LQ_DATA_TIMEOUT.  If that timer
   expires, the requester SHOULD terminate the connection after BULK_LQ_DATA_TIMEOUT, and
   MAY begin retry processing if configured to do so. connection.

   A single Bulk Leasequery can and usually will result in a large
   number of replies.  The requestor MUST be prepared to receive more
   than one reply with an xid matching a single DHCPBULKLEASEQUERY
   message from a single DHCPv4 server. If the xid in the received
   message does not match an outstanding DHCPBULKLEASEQUERY message, the
   requestor MUST close the TCP connection.

   If a response message does not contain a

   The DHCPv4 server MUST send a server-identifier option (option 54), then the server-identifier option from the
   previous message should be used.  Thus, 54) in
   the first response to any DHCPBULKLEASEQUERY message.   The DHCPv4
   server MUST SHOULD NOT send server identifier options in subsequent
   responses to that DHCPBULKLEASEQUERY message.   The requester MUST
   cache the server-identifier option in from the first response message, and MAY
   send apply
   it in to any subsequent response message for the same request. responses.

   The response messages generated by a DHCPBULKLEASEQUERY request are:

      o DHCPLEASEACTIVE

        A Bulk Leasequery will generate DHCPLEASEACTIVE messages
        containing binding data for bound IP addresses which match the
        specified query criteria. The IP address which is bound to a
        DHCPv4 client will appear in the ciaddr field of the
        DHCPLEASEACTIVE message.  The message may contain a non-zero
        chaddr, htype, and hlen and possibly additional options.

      o DHCPLEASEUNASSIGNED

        Some queries will also generate DHCPLEASEUNASSIGNED messages for
        IP addresses which match the query criteria.  These messages
        indicate that the IP address is managed by the DHCPv4 server but
        is not currently bound to any DHCPv4 client.  The IP address to
        which this message refers will appear in the ciaddr field of the
        DHCPLEASEUNASSIGNED message.  A DHCPLEASEUNASSGINED message MAY
        also contain information about the last DHCPv4 client that was
        bound to this IP address. The message may contain a non-zero
        chaddr, htype, and hlen and possibly additional options.

      o DHCPLEASEQUERYDONE

        A response of DHCPLEASEQUERYDONE indicates that the server has
        completed its response to the query, and that no more messages
        will be sent in response to the DHCPBULKLEASEQUERY. More details
        will sometimes be available in the received dhcp-message option
        in the DHCPLEASEQUERYDONE message. If there is no dhcp-message
        option in the DHCPLEASEQUERYDONE message, then the query
        completed successfully.

        Note that a query which returned no data, that is a
        DHCPBULKLEASEQUERY request followed by a DHCPLEASEQUERYDONE
        response, is considered a successful query in that no errors
        occurred during the processing.  It is not considered an error
        to have no information to return to a DHCPBULKLEASEQUERY
        request.

   The DHCPLEASEUNKNOWN message MUST NOT appear in a response to a Bulk
   Leasequery.

   The requestor MUST NOT assume that there is any inherent order in the
   IP address binding information that is sent in response to a
   DHCPBULKLEASEQUERY.  While the base-time will tend to increase
   monotonically (as it is the current time on the DHCPv4 server), the
   actual time that any IP address binding information changed is
   unrelated to the base-time.

   The DHCPLEASEQUERYDONE message always ends a successful
   DHCPBULKLEASEQUERY request and any unsuccessful DHCPBULKLEASEQUERY
   requests not terminated by a dropped connection. After receiving
   DHCPLEASEQUERYDONE from a server, the requestor MAY close the TCP
   connection to that server if no other DHCPBULKLEASEQUERY is
   outstanding on that TCP connection.

   The DHCPv4 Leasequery protocol [RFC4388] uses the associated-ip
   option as an indicator that multiple bindings were present in
   response to a single DHCPv4 client based query.  For Bulk Leasequery,
   a separate message is returned for each binding, and so the
   associated-ip option is not used.

8.4.

7.4.  Processing Time Values in Leasequery messages

   Bulk Leasequery requests may be made to a DHCPv4 server whose
   absolute time may not be synchronized with the local time of the
   requestor.  Thus, there are at least two time contexts in even the
   simplest Bulk Leasequery response, and in the situation where
   multiple DHCPv4 servers are queried, the situation becomes even more
   complex.

   If the requestor of a Bulk Leasequery is saving the data returned in
   some form, it has a requirement to store a variety of time values,
   and some of these will be time in the context of the requestor and
   some will be time in the context of the DHCPv4 server.

   When receiving a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message from
   the DHCPv4 server, the message will contain a base-time option.  The
   time contained in this base-time option is in the context of the
   DHCPv4 server.  As such, it is an ideal time to save and use as input
   to a DHCPBULKLEASEQUERY in the query-start-time or query-end-time
   options, should the requestor need to ever issue a DHCPBULKLEASEQUERY
   message using those options as part of a later query.

   In addition to saving the base-time for possible future use in a
   query-start-time option, the base-time is used as part of the
   conversion of the other times in the Leasequery message to values
   which are meaningful in the context of the requestor.

   The requestor SHOULD use the base-time values received in Bulk
   Leasequery messages to develop a value which represents the clock
   skew between the DHCPv4 server and the requestor.

   In theory this
   clock skew would simply be the difference between the first base-time
   value and the current time on the requestor when the message
   containing the base-time value was received.  However, there may be
   transmission delays at the beginning or end or along the TCP
   connection, and so the actual clock skew may not be the same as any
   individual difference between a base-time value and the current time
   of the requestor.

   Moreover, in systems whose clocks are synchronized, perhaps using NTP, the
   clock skew will usually be zero, which is not only acceptable, but
   desired.

   The

7.5.  Querying Multiple Servers

   A Bulk Leasequery requestor SHOULD smooth the value which it uses as the clock skew
   by continuously examining the instantaneous value developed MAY be configured to attempt to connect
   to and query from the
   base-time of each message multiple DHCPv4 servers in parallel.  The DHCPv4
   Leasequery specification [RFC4388] includes a discussion about
   reconciling binding data received from a multiple DHCPv4 server and using
   this instantaneous value servers.

   In addition, the algorithm in the Section 7.6 should be used.

7.6.  Making Sense Out of clock skew Multiple Responses Concerning a Single IPv4
Address

   Any requestor of an Bulk Leasequery MUST be prepared for multiple
   responses to make small adjustments arrive for a particular IPv4 address from multiple
   different DHCPv4 servers. The following algorithm SHOULD be used to
   decide if the information just received is more up to date (i.e.,
   better) than the best existing value of information.  In the clock skew.  Thus, discussion below,
   the clock skew will vary
   only slowly and one slow message will not completely distort information that is received from a large
   number of future time calculations.

   Given the value of DHCPv4 server about a
   particular IPv4 address is termed a "record".  The times used in the clock skew on
   algorithm below SHOULD have been converted into the requestor, requestor's
   context and the requestor time comparisons SHOULD bring all of be performed in a manner
   consistent with the times information in Section 7.4.

      o If both the DHCPLEASEACTIVE existing and
   DHCPLEASEUNASSIGNED messages into the context new record contain client-last-
        transaction-time information, the record with the later client-
        last-transaction-time is considered better.

      o If one of the requestor.
   Except for records contains client-last-transaction-time
        information and the base-time value, other one doesn't, then compare the times client-
        last-transaction-time in the Leasequery message
   are all relative to the base-time.  These relative times SHOULD first
   be converted into absolute times in record that contains it against the context of
        other record's start-time-of-state.  The record with the DHCPv4 server
   using later
        time is considered better.

      o If neither record contains client-last-transaction-time
        information, compare their start-time-of-state information.  The
        record with the base-time value.  Once this stage later start-time-of-state is complete, considered better.

      o If none of the absolute
   times that result SHOULD be brought into comparisons above yield a clear answer as to
        which record is later, then compare the context value of the requestor
   by applying REMOTE flag
        from the calculated clock skew to data-source option for each of record.

        If the absolute times.

   After all values of this processing, the times REMOTE flag are in the context of different between the
   requestor.

   An alternative might appear to be to leave all of two
        records, the times in record with the
   context REMOTE flag value of local is
        considered better.

   The above algorithm does not necessarily determine which record is
   better.  In the DHCPv4 server, and if event that the requestor algorithm is dealing inconclusive with
   only one DHCPv4 server at regard
   to a time, this is an accurate and effective
   approach.  However, if record which was just received by the requestor, the requestor is dealing with DHCPLEASEACTIVE
   and DHCPLEASEUNASSIGNED messages from two or more different DHCPv4
   servers, then
   SHOULD use additional information in order the two records to make any sense of them, the times from each
   server SHOULD be converted into the time of the requestor.

   Since various transmission and processing delays may occur, a time
   converted into the requestor's context may be accurate
   determination as to only a few
   seconds, at best.  This which record is rarely an issue in the larger context of
   the use of the information derived from better.

7.7.  Multiple Queries to a Single Server over One Connection

   Bulk Leasequery request.
   However, time comparison is an important factor requestors may need to make multiple queries in determining which
   update order
   to the address recover binding information for information.  A requestor MAY use a particular IPv4
   address is the most recent and therefore worth remembering.  The next
   section discusses the single
   connection to issue of comparing two updates in some detail,
   but multiple queries to a key aspect of that comparison is server willing to support
   them. Each query MUST have a comparison unique xid.

   A server SHOULD allow configuration of the times in
   the two messages.

   The requestor SHOULD consider times converted into its context as
   effectively equivalent if they are within a small number of seconds
   of each other.  The precise number depends on the particular
   implementation involved, but 4 to 8 seconds is probably a good
   starting point.  Thus, if two times are 3 seconds apart after
   conversion to the requestor's context they should queries that can
   be considered processed simultaneously over a single connection.  A server
   SHOULD read the
   same for purposes number of comparison with each other.

8.5.  Querying Multiple Servers

   A Bulk Leasequery requestor MAY be queries it is configured to attempt to connect
   to process
   simultaneously and query from multiple DHCPv4 servers in parallel.  The DHCPv4
   Leasequery specification [RFC4388] includes a discussion about
   reconciling binding data received from only read any subsequent queries as current
   queries are processed.

   A server that is processing multiple DHCPv4 servers.

   In addition, queries simultaneously MUST
   interleave replies to the algorithm in multiple queries within the Section 8.6 should be used.

8.6.  Making Sense Out of Multiple Responses Concerning a Single IPv4
Address

   Any requestor stream of an Bulk Leasequery MUST reply
   messages it sends.  Requestors need to be prepared aware that replies for
   multiple
   responses to arrive for a particular IPv4 address from multiple
   different DHCPv4 servers. The following algorithm SHOULD queries may be used to
   decide if interleaved within the information just received is more up stream of reply
   messages.  Requestors that are not able to date (i.e.,
   better) process interleaved
   replies (based on xid) MUST NOT send more than one query over a
   single connection prior to the best existing information.  In the discussion below, completion of the information previous query.

   Requestors should be aware that is received from a DHCPv4 server about servers are not required to process
   more than one query over a
   particular IPv4 address is termed connection at a "record".  The times used in the
   algorithm below SHOULD have been converted into time (the limiting case
   for the requestor's
   context configuration described above), and that servers are likely
   to limit the time comparisons SHOULD be performed in rate at which they process queries from any one
   requestor.

7.7.1.  Example

   This example illustrates what a manner
   consistent with the information in Section 8.4.

      o If both the existing series of queries and responses might
   look like.  This is only an example - there is no requirement that
   this sequence must be followed, or that requestors or servers must
   support parallel queries.

   In the new record contain client-last-
        transaction-time information, example session, the record with client sends four queries after
   establishing a connection.  Query 1 returns no results; query 2
   returns 3 messages and the later client-
        last-transaction-time is considered better.

      o If one stream of replies concludes before the records contains client-last-transaction-time
        information
   client issues any new query. Query 3 and query 4 overlap, and the other one doesn't, then compare the client-
        last-transaction-time in the record that contains it against the
        other record's start-time-of-state.  The record with the later
        time is considered better.

      o If neither record contains client-last-transaction-time
        information, compare their start-time-of-state information.
   server interleaves its replies to those two queries.

      Requestor                                Server
      ---------                                ------
      DHCPBULKLEASEQUERY xid 1 ----->
                               <-----       DHCPLEASEQUERYDONE xid 1
      DHCPBULKLEASEQUERY xid 2 ----->
                               <-----       DHCPLEASEACTIVE xid 2
                               <-----       DHCPLEASEACTIVE xid 2
                               <-----       DHCPLEASEACTIVE xid 2
                               <-----       DHCPLEASEQUERYDONE xid 2
      DHCPBULKLEASEQUERY xid 3 ----->
      DHCPBULKLEASEQUERY xid 4 ----->
                               <-----       DHCPLEASEACTIVE xid 4
                               <-----       DHCPLEASEACTIVE xid 4
                               <-----       DHCPLEASEACTIVE xid 3
                               <-----       DHCPLEASEACTIVE xid 4
                               <-----       DHCPLEASEUNASSIGNED xid 3
                               <-----       DHCPLEASEACTIVE xid 4
                               <-----       DHCPLEASEACTIVE xid 3
                               <-----       DHCPLEASEQUERYDONE xid 3
                               <-----       DHCPLEASEACTIVE xid 4
                               <-----       DHCPLEASEQUERYDONE xid 4

7.8.  Closing Connections

   The
        record with requestor SHOULD close the later start-time-of-state is considered better.

      o If none of connection after the comparisons above yield a clear answer as to
        which record
   DHCPLEASEQUERYDONE message is later, then compare the value of the REMOTE flag
        from the data-source option received for each record.

        If the values of the REMOTE flag last outstanding query
   that it has sent.

8.  Server Behavior
8.1.  Accepting Connections

   Servers that implement DHCPv4 Bulk Leasequery listen for incoming TCP
   connections.  Port numbers are different between the two
        records, the record with discussed in Section 6.3.  Servers
   MUST be able to limit the REMOTE flag value number of local is
        considered better. currently accepted and active
   connections.  The above algorithm does not necessarily determine which record is
   better.  In value BULK_LQ_MAX_CONNS SHOULD be the event that default;
   implementations MAY permit the algorithm is inconclusive with regard value to a record which was just received by the requestor, the requestor be configurable.  Connections
   SHOULD use additional information in be accepted and, if the two records to make a
   determination as to which record number of connections is better.

8.7.  Multiple Queries to a Single Server over One Connection
   BULK_LQ_MAX_CONNS, they SHOULD be closed immediately.

   Servers MAY restrict Bulk Leasequery requestors may need to make multiple queries in order
   to recover binding information.  A requestor MAY use a single
   connection connections and
   DHCPBULKLEASEQUERY messages to issue multiple queries certain requestors.  Connections not
   from permitted requestors SHOULD be closed immediately, to a avoid
   server willing connection resource exhaustion. Servers MAY restrict some
   requestors to support
   them. Each certain query MUST have a unique xid.

   A server types.  Servers MAY process more than one query at a time. A server reply to queries that
   does
   are not support more than one query at a time on a single connection
   MUST return a permitted with the DHCPLEASEQUERYDONE message containing a dhcp-message
   option with a status-code dhcp-
   message status of NotAllowed to NotAllowed, or MAY simply close the connection.

   If the TCP connection becomes blocked while the unsupported queries.
   Alternatively, a server that does not support more than one query at
   a time on is accepting a single
   connection MAY chose or reading a query, it SHOULD be prepared to simply read one query and
   only read any subsequent queries after processing of terminate the current
   query is complete.

   A server that is willing
   connection after an BULK_LQ_DATA_TIMEOUT.  We make this
   recommendation to do so MAY interleave replies allow servers to control the
   multiple queries within the stream period of reply messages it sends.
   Requestors need time they
   are willing to be aware that replies for multiple queries may be
   interleaved within the stream wait before abandoning an inactive connection,
   independent of reply messages.  Requestors that are
   not able the TCP implementations they may be using.

8.2.  Replying to process interleaved replies (based on xid) MUST NOT send
   more than one query over a single Bulk Leasequery

   If the connection prior to becomes blocked while the completion
   of server is attempting to
   send reply messages, the previous query.  Requestors should server SHOULD be aware that servers are
   not required prepared to process more than one query over a terminate the
   TCP connection at after BULK_LQ_DATA_TIMEOUT.

   Every Bulk Leasequery request MUST be terminated by sending a
   time, and that servers are likely to limit the rate at which they
   process queries from any one requestor.

8.7.1.  Example

   This example illustrates what final
   DHCPLEASEQUERYDONE message if such a series of queries and responses might
   look like.  This is only an example - there is no requirement that
   this sequence must message can be followed, or that requestors or servers must
   support parallel queries.

   In the example session, the client sends four queries after
   establishing sent. The
   DHCPLEASEQUERYDONE message MUST have a connection.  Query 1 returns no results; query 2
   returns 3 messages and the stream of replies concludes before dhcp-message status if the
   client issues any new query. Query 3 and query 4 overlap,
   termination was other than successful, and SHOULD NOT contain a
   dhcp-message status if the termination was successful.

   If the DHCPv4 server interleaves its replies to those two queries.

      Requestor                                Server
      ---------                                ------
      DHCPBULKLEASEQUERY xid 1 ----->
                               <-----       DHCPLEASEQUERYDONE xid 1 encounters an error during processing of the
   DHCPBULKLEASEQUERY xid 2 ----->
                               <-----       DHCPLEASEACTIVE xid 2
                               <-----       DHCPLEASEACTIVE xid 2
                               <-----       DHCPLEASEACTIVE xid 2
                               <-----       DHCPLEASEQUERYDONE xid 2
      DHCPBULKLEASEQUERY xid 3 ----->
      DHCPBULKLEASEQUERY xid 4 ----->
                               <-----       DHCPLEASEACTIVE xid 4
                               <-----       DHCPLEASEACTIVE xid 4
                               <-----       DHCPLEASEACTIVE xid 3
                               <-----       DHCPLEASEACTIVE xid 4
                               <-----       DHCPLEASEUNASSIGNED xid 3
                               <-----       DHCPLEASEACTIVE xid 4
                               <-----       DHCPLEASEACTIVE xid 3
                               <-----       DHCPLEASEQUERYDONE xid 3
                               <-----       DHCPLEASEACTIVE xid 4
                               <-----       DHCPLEASEQUERYDONE xid 4

8.8.  Closing Connections

   Either the requestor message, either during initial processing or DHCPv4 server MAY close later
   during the TCP connection at
   any time.  The requestor message processing, it SHOULD send a DHCPLEASEQUERYDONE
   containing a status dhcp-message option. It MAY choose to retain close the connection if it
   intends to issue additional queries or if other queries are currently
   using the connection.  Note that
   after this requestor behavior error is signaled, but that is not required.

   If the server does not
   guarantee that find any bindings satisfying a query, it MUST
   send a DHCPLEASEQUERYDONE.  It SHOULD NOT include a dhcp-message
   option with a Success status unless there is a useful string to
   include in the connection will be available for additional
   queries: dhcp-message option.  Otherwise, the server might decide sends each
   binding's data in a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message.

   The response to close a DHCPBULKLEASEQUERY may involve examination of
   multiple DHCPv4 IP address bindings maintained by the connection based on its
   own configuration.

9.  Server Behavior

9.1.  Accepting Connections

   Servers that implement DHCPv4 server.
   The Bulk Leasequery listen for incoming TCP
   connections.  Port numbers are discussed protocol does not require any ordering of the IP
   addresses returned in Section 7.3.  Servers
   MUST be able DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED
   messages.

   When responding to limit a DHCPBULKLEASEQUERY message, the number of currently accepted and active
   connections.  The value BULK_LQ_MAX_CONNS SHOULD be the default;
   implementations MAY permit the value to be configurable.  Connections
   SHOULD be accepted and, DHCPv4 server
   MUST NOT send more than one message for each applicable IP address,
   even if the number state of connections is over
   BULK_LQ_MAX_CONNS, they SHOULD be closed immediately.

   Servers MAY restrict Bulk Leasequery connections and
   DHCPBULKLEASEQUERY messages to certain requestors.  Connections not
   from permitted requestors SHOULD be closed immediately, to avoid
   server connection resource exhaustion. Servers MAY restrict some
   requestors to certain query types.  Servers MAY reply to queries that
   are not permitted with the DHCPLEASEQUERYDONE message with a dhcp-
   message status of NotAllowed, or MAY simply close the connection.

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

9.2.  Replying message.   Updates to a Bulk Leasequery such IP address state are
   already handled by normal protocol processing, so no special effort
   is needed here. (I hope!)

   If the connection becomes blocked while the server ciaddr, yiaddr, or siaddr is attempting to
   send reply messages, the server SHOULD be prepared to terminate non-zero in a DHCPBULKLEASEQUERY
   request, the
   TCP connection after BULK_LQ_DATA_TIMEOUT.

   Every Bulk Leasequery request MUST must be terminated immediately by sending a final
   DHCPLEASEQUERYDONE message if such a message can be sent. The
   DHCPLEASEQUERYDONE message MUST have with a dhcp-message status if the
   termination was other of
   MalformedQuery.

   Any DHCPBULKLEASEQUERY which has more than successful, and SHOULD NOT contain one of the following
   primary query types specified MUST be terminated immediately by a
   DHCPLEASEQUERYDONE message with a dhcp-message status if code of
   NotAllowed.

   The allowable queries in a DHCPBULKLEASEQUERY message are processed
   as follows.  Note that the termination was successful.

   If descriptions of the DHCPv4 server encounters an error during processing primary queries below
   must be constrained by the actions of any of the
   DHCPBULKLEASEQUERY message, either during initial processing or later
   during three qualifiers
   described subsequently as well.

   The following table discusses how to process the message processing, it SHOULD send various queries.
   For information on how to identify the query, see the information in
   Section 7.2.

      o Query by MAC address

        Every IP address that has a DHCPLEASEQUERYDONE
   containing current binding to a status dhcp-message option. It MAY close DHCPv4 client
        matching the connection
   after this error is signaled, but that is not required.

   If chaddr, htype, and hlen in the server does not find any bindings satisfying a query, it DHCPBULKLEASEQUERY
        request MUST
   send a DHCPLEASEQUERYDONE.  It SHOULD NOT include a dhcp-message
   option with be returned in a Success status unless there is DHCPLEASEACTIVE message.

      o Query by Client-Id

        Every IP address that has a useful string current binding to
   include in a DHCPv4 client
        matching the dhcp-message option.  Otherwise, client-id option in the server sends each
   binding's data DHCPBULKLEASEQUERY request
        MUST be returned in a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message.

   The response

      o Query by Remote-Id

        Every IP address that has a current binding to a DHCPBULKLEASEQUERY may involve examination of
   multiple DHCPv4 IP address bindings maintained by client
        matching the DHCPv4 server.
   The Bulk Leasequery protocol does not require any ordering remote-id sub-option of the IP
   addresses relay-agent-information
        option in the DHCPBULKLEASEQUERY request MUST be returned in a
        DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED
   messages.

   A Bulk Leasequery response MUST contain no more than one message for
   each message.

      o Query by Relay-Id

        Every IP address configured in the DHCPv4 server.  In addition, that has a Bulk
   Leasequery may well take significant time between the beginning and
   end of the processing of all of the messages required current binding to satisfy the
   Bulk Leasequery query.  During this time, a DHCPv4 client
        matching the state of some relay-id sub-option of the IP
   addresses sent early relay-agent-information
        option in the response may change prior to DHCPBULKLEASEQUERY request MUST be returned in a
        DHCPLEASEACTIVE message.

      o Query for All Configured IP Addresses

        A Query for All Configured IP addresses is signaled by the
   completion
        absence of the entire response to the Bulk Leasequery.  This is
   normal and expected -- any other primary query.  That is, if there is no requirement for
        value in the entire
   response to a Bulk Leasequery to represent an instantaneous snapshot chaddr, hlen, htype, no client-id option, no
        remote-id sub-option or relay-id sub-option of the state of relay-agent-
        information option, then the request is a query for information
        concerning all configured IP addresses. In this case, every
        configured IP address bindings of that has a DHCPv4 server.  Quite
   the contrary -- as the cursor moves through the IP addresses in
   whatever order is convenient current binding to the a DHCPv4 server, the state of
        client MUST be returned in a DHCPLEASEACTIVE message.  In
        addition, every configured IP
   addresses already examined can change and address that does not have a
        current binding to a DHCPv4 server client MUST NOT
   try to examine IP addresses already scanned be returned in an attempt to "keep
   up" with the ongoing state changes a
        DHCPLEASEUNASSIGNED message.

        In this form of all of the IP addresses.  To do
   so would make it difficult to meet the requirement to send only one
   message per query, each configured IP address in response to a Bulk Leasequery and would
   also make it difficult to know when to finish the Bulk Leasequery.

   If the ciaddr, yiaddr, or siaddr is non-zero in a DHCPBULKLEASEQUERY
   request, the request must MUST be terminated immediately by a
   DHCPLEASEQUERYDONE message with a dhcp-message status of
   MalformedQuery.

   Any DHCPBULKLEASEQUERY which has more than
        returned at most one time.  If the absence of qualifiers
        restricting the following
   primary query types specified number of IP addresses returned, every
        configured IP address MUST be terminated immediately by a
   DHCPLEASEQUERYDONE message with a dhcp-message status code of
   NotAllowed.

   The allowable queries in a DHCPBULKLEASEQUERY message returned exactly once.

   There are processed
   as follows.  Note three qualifiers that the descriptions of the primary queries below
   must can be constrained by the actions of applied to any of the three qualifiers
   described subsequently as well.

   The following table discusses how to process the various above
   primary queries.
   For information on how to identify the query, see the information  These qualifiers can appear individually or
   together in
   Section 8.2. any combination, but only one of each can appear.

   o Query by MAC address

        Every Start Time

     If a query-start-time option appears in the DHCPBULKLEASEQUERY
     request, only IP address bindings that has a current binding to a DHCPv4 client
        matching have changed on or after the chaddr, htype, and hlen
     time specified in the DHCPBULKLEASEQUERY
        request MUST query-start-time option should be returned in a DHCPLEASEACTIVE message. returned.

   o Query by Client-Id

        Every End Time

     If a query-end-time option appears in the DHCPBULKLEASEQUERY
     request, only IP address bindings that has a current binding to a DHCPv4 client
        matching have changed on or before
     the client-id option time specified in the DHCPBULKLEASEQUERY request
        MUST query-end-time option should be returned in a DHCPLEASEACTIVE message. returned.

   o Query by Remote-Id

        Every IP address that has a current binding VPN Id
     If no vpn-id option appears in the DHCPBULKLEASEQUERY, the default
     VPN is used to satisfy the query.  A vpn-id option [VpnId] value
     other than the wildcard value (254) allows the requestor to specify
     a DHCPv4 client
        matching single VPN other than the remote-id sub-option of default VPN.  In addition, the relay-agent-information vpn-id
     option has been extended as part of this document to allow
     specification of a type 254 which indicates that all configured
     VPN's be searched in order to satisfy the DHCPBULKLEASEQUERY request MUST be primary query.

     In all cases, if the information returned in a DHCPLEASEACTIVE message.

      o Query by Relay-Id

        Every IP address that has a current binding to or
     DHCPLEASEUNASSIGNED message is for a DHCPv4 client
        matching the relay-id sub-option of VPN other than the relay-agent-information default, a
     vpn-id option MUST appear in the DHCPBULKLEASEQUERY request MUST be packet.

   The query-start-time and query-end-time qualifiers are used to
   constrain the amount of data returned in by a
        DHCPLEASEACTIVE message.

      o Query for All Configured IP Addresses

        A Query for All Configured Bulk Leasequery request by
   returning only IP addresses is signaled whose address bindings have changed in
   some way during the time window specified by the
        absence of any other primary query.  That is, query-start-time and
   query-end-time.

   A DHCPv4 server SHOULD consider an address binding to have changed
   during a specified time window if there is no
        value in either the chaddr, hlen, htype, no client-id option, no
        remote-id sub-option client-last-
   transaction-time or relay-id sub-option of the relay-agent-
        information option, then start-time-of-state of the request is a query for information
        concerning all configured IP addresses. In this case, every
        configured IP address that has a current binding to a
   changed during that time window.

   The DHCPv4
        client MUST be returned server MAY return address binding data in a DHCPLEASEACTIVE message.  In
        addition, every configured any order, as
   long as binding information for any given IP address that does is not have a
        current repeated.
   When all binding to data for a given DHCPBULKLEASEQUERY has been sent,
   the DHCPv4 client server MUST be returned in send a
        DHCPLEASEUNASSIGNED DHCPBULKLEASEQUERYDONE message.

        In this form of query, each configured IP address MUST be
        returned at most one time.  If

8.3.  Building a Single Reply for Bulk Leasequery

   The DHCPv4 Leasequery [RFC4388] specification describes the absence initial
   construction of qualifiers
        restricting DHCPLEASEQUERY reply messages using the number
   DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types in Section
   5.4.2.  All of IP addresses returned, every
        configured the reply messages in Bulk Leasequery are similar to
   the reply messages for an IP address query.  Message transmission and
   framing for TCP is described in this document in Section 6.1.

   [RFC2131] and [RFC4388] specify that every response message MUST be returned exactly once.

   There are three qualifiers
   contain the server-identifier option.  However, that can option will be applied to any of
   the above
   primary queries.  These qualifiers can appear individually or
   together in any combination, but only one of each can appear.

   o Query Start Time

     If same for every response from a query-start-time particular DHCPBULKLEASEQUERY
   request.  Thus, the DHCPv4 server MUST include the server-identifier
   option appears in the DHCPBULKLEASEQUERY
     request, only IP address bindings that have changed on or after first message sent in response to a DHCPBULKLEASEQUERY.
   It SHOULD NOT include the
     time specified server-identifier in later messages.

   The message type of DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED is based
   on the query-start-time option should be returned.

   o Query End Time value of the dhcp-state option.  If a query-end-time the dhcp-state option appears in
   value is ACTIVE, then the DHCPBULKLEASEQUERY
     request, only IP address bindings that have changed on or before message type is DHCPLEASEACTIVE, otherwise
   the time specified message type is DHCPLEASEUNASSIGNED.

   In addition to the basic message construction described in [RFC4388],
   the query-end-time option should be returned.

   o VPN Id following guidelines exist:

      1. If no vpn-id the dhcp-state option code appears in the DHCPBULKLEASEQUERY, the default
     VPN is used to satisfy dhcp-parameter-
         request-list, the query.  A vpn-id DHCPv4 server SHOULD include a dhcp-state
         option [VpnId] value
     other than the wildcard whose value (254) allows the requestor corresponds most closely to specify
     a single VPN other than the default VPN.  In addition, state held
         by the vpn-id
     option has been extended as part of DHCPv4 server for the IP address associated with this document to allow
     specification of a type 254 which indicates that all configured
     VPN's be searched in order to satisfy
         reply.  If the primary query.

     In all cases, if state is ACTIVE and the information message being returned in a
         is DHCPLEASEACTIVE, then the DHCPv4 server MAY choose to not
         send the dhcp-state option.  The requestor SHOULD assume that
         any DHCPLEASEACTIVE or
     DHCPLEASEUNASSIGNED message is for arriving without a VPN other than the default, requested dhcp-
         state option has a
     vpn-id dhcp-state of ACTIVE.

      2. If the base-time option MUST appear code appears in the packet.

   The query-start-time and query-end-time qualifiers are used to
   constrain dhcp-parameter-
         request-list, the amount of data returned by DHCPv4 server MUST include a Bulk Leasequery request by
   returning only IP addresses whose address bindings have changed in
   some way during base-time
         option, which is the current time window specified by in the query-start-time and
   query-end-time.

   A DHCPv4 server SHOULD consider an address binding to have changed
   during a specified server's
         context and the time window if either from which the client-last-
   transaction-time or start-time-of-state, dhcp-
         lease-time, client-last-transaction-time, and other duration-
         style times are based upon.

      3. If the start-time-of-state of option code appears in the dhcp-
         parameter-request-list, the address binding
   changed during that time window.

   A DHCPv4 server MAY always compare the address binding information
   for an IP address against MUST include a
         start-time-of-state option whose value represents the time window if it follows at
         which the following
   guidelines. dhcp-state option's state became valid.

      4. If there is no query-start-time, then the dhcp-lease-time option code appears in the dhcp-
         parameter-request-list, the DHCPv4 server MUST assume the query-start-time is equivalent to include a time prior to dhcp-
         lease-time option for any
   time state that resides in any IP address binding.  If there is no query-
   end-time, has a time-out value
         associated with it.  In the DHCPv4 server MUST assume that [RFC4388] Leasequery, the query-end-time is
   equivalent to dhcp-
         lease-time option appears only in a time that DHCPLEASEACTIVE message.
         Thus, the EXPIRED state, which is later than any time that resides sent in any
   IP address binding.

   Even a DHCPLEASEUNASSIGNED
         message, would have a dhcp-lease-time option in the message if
         the query-start-time or query-end-time option value is being
   used to limit EXPIRED state represented a grace-period and would be
         changed into the amount FREE state after the expiration of data flow from the DHCPv4 server to grace-
         period.

      5. If the
   requestor, there is no requirement placed on data-source option code appears in the dhcp-parameter-
         request-list, the DHCPv4 server to
   return address binding data MUST include the data-source
         option in any order and certainly not in situation where any
   order based on time.

   When the DHCPv4 server has no additional information to send to the
   requestor, it will send a DHCPLEASEQUERYDONE message.

9.3.  Building a Single Reply for Bulk Leasequery

   The DHCPv4 Leasequery [RFC4388] specification describes the initial
   construction of DHCPLEASEQUERY reply messages using the
   DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types bits would be non-
         zero.  Thus, in Section
   6.4.2.  All the absence of the reply messages in Bulk Leasequery are similar to data-source option, the reply messages for an IP address query.  Message transmission and
   framing for TCP
         assumption is described in this document in Section 7.1.

   [RFC2131] and [RFC4388] specify that every response message MUST
   contain all of the server-identifier option.  However, that option will be flags were zero.

      6. If the same for every response from a particular DHCPBULKLEASEQUERY
   request.  Thus, client-last-transaction-time option code appears in the
         dhcp-parameter-request-list, The DHCPv4 server MUST include the server-identifier
         client-last-transaction-time option in any situation where the first message sent in response to a DHCPBULKLEASEQUERY.
   It MAY include the server-identifier in later messages as well, but
         information is available.

      7. If there is no requirement for a dhcp-parameter-request-list in the initial
         DHCPBULKLEASEQUERY request, then it to do so.

   The message type should be used for all of DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED is based
   on
         the value of replies generated by that request.  Some options can be
         sent from a DHCPv4 client to the dhcp-state server or from the DHCPv4
         server to a DHCPv4 client. Option 125 is such an option.  If
         the dhcp-state option
   value is ACTIVE, then the message type is DHCPLEASEACTIVE, otherwise
   the message type is DHCPLEASEUNASSIGNED.

   In addition to the basic message construction described in [RFC4388],
   the following guidelines exist:

      1. If the dhcp-state option code for one of these options appears in the dhcp-parameter-
         request-list, the DHCPv4 server dhcp-
         parameter-request-list, it SHOULD include a dhcp-state
         option whose result in returning the value corresponds most closely to
         of the state held option sent by the DHCPv4 server for the IP address associated with this
         reply.  If the state is ACTIVE and the message being returned
         is DHCPLEASEACTIVE, then the DHCPv4 server MAY choose client to not
         send the dhcp-state option.  The requestor SHOULD assume server if one
         exists.

   Note that
         any DHCPLEASEACTIVE message arriving without there may be other requirements for a requested dhcp-
         state option reply to a
   DHCPBULKLEASEQUERY request discussed in Section 8.2.

8.4.  Multiple or Parallel Queries

   As discussed in Section 7.3, requestors may want to use a connection
   that has already been established when they need to make additional
   queries. Servers SHOULD support reading and processing multiple
   queries from a dhcp-state single connection and SHOULD allow configuration of ACTIVE.

      2. If the base-time option code appears in the dhcp-parameter-
         request-list,
   the DHCPv4 number of simultaneous queries it may process. A server MUST include NOT
   read more query messages from a base-time
         option, which connection than it is prepared to
   process simultaneously.

   This SHOULD be a feature that is administratively controlled.
   Servers SHOULD offer configuration that limits the current time in the DHCPv4 server's
         context and the time number of
   simultaneous queries permitted from which the start-time-of-state, dhcp-
         lease-time, client-last-transaction-time, and other duration-
         style times are based upon.

      3. If the start-time-of-state option code appears any one requestor, in the dhcp-
         parameter-request-list, the order to
   control resource use if there are multiple requestors seeking
   service.

8.5.  Closing Connections

   The DHCPv4 server MUST include SHOULD start a
         start-time-of-state option whose value represents timer for BULK_LQ_DATA_TIMEOUT
   seconds for a particular connection after it sends a
   DHCPLEASEQUERYDONE message over that connection and if there is no
   current outstanding query outstanding for that connection.  It should
   clear this timer if a query arrives over that connection.  If the time at
         which
   timer expires, the dhcp-state option's state became valid.

      4. If DHCPv4 server should close the dhcp-lease-time option code appears in connection.

   The server MUST close its end of the dhcp-
         parameter-request-list, TCP connection if it encounters
   an error sending data on the DHCPv4 connection.  The server MUST include a dhcp-
         lease-time option for any state close its
   end of the TCP connection if it finds that it has a time-out value
         associated with it.  In the [RFC4388] Leasequery, to abort an in-
   process request.  A server aborting an in-process request SHOULD
   attempt to signal that to its requestors by using the dhcp-
         lease-time option appears only QueryTerminated
   status code in a DHCPLEASEACTIVE message.
         Thus, the EXPIRED state, which is sent dhcp-message option in a DHCPLEASEUNASSIGNED DHCPLEASEQUERYDONE
   message, would have including a dhcp-lease-time option in the message if
         the EXPIRED state represented a grace-period and would be
         changed into the FREE state after the expiration string indicating details of the grace-
         period.

      5. If the data-source option code appears in reason
   for the dhcp-parameter-
         request-list, abort.   If the DHCPv4 server MUST include detects that the data-source
         option in any situation where any requesting end of the bits would be non-
         zero.  Thus, in
   connection has been closed, the absence server MUST close its end of the data-source option, the
         assumption is that all
   connection.

9.  Security Considerations

   The "Security Considerations" section of [RFC2131] details the flags were zero.

      6. If the client-last-transaction-time option code appears in the
         dhcp-parameter-request-list,
   general threats to DHCPv4.  The DHCPv4 server MUST include the
         client-last-transaction-time option in any situation where the
         information is available.

      7. If there is a dhcp-parameter-request-list in the initial
         DHCPBULKLEASEQUERY request, then it should be used Leasequery specification
   [RFC4388] describes recommendations for all of the replies generated by Leasequery protocol,
   especially with regard to authentication of LEASEQUERY messages,
   mitigation of packet-flooding DOS attacks, and restriction to trusted
   requestors.

   The use of TCP introduces some additional concerns.  Attacks that request.  Some options can be
         sent from a DHCPv4 client
   attempt to exhaust the server or from the DHCPv4
         server to a DHCPv4 client. Option 125 is server's available TCP connection
   resources, such an option.  If as SYN flooding attacks, can compromise the option code for one ability
   of these options appears in the dhcp-
         parameter-request-list, it SHOULD result legitimate requestors to receive service.  Malicious requestors
   who succeed in returning the value 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.  We recommend that servers
   offer configuration to limit the option sent by sources of incoming connections,
   that they limit the DHCPv4 client to number of accepted connections and the server if number of
   in-process queries from any one
         exists.

   Note connection, and that there may they limit the
   period of time during which an idle connection will be other requirements left open.

   [RFC4388] discusses security concerns and potential solutions for a reply to a
   DHCPBULKLEASEQUERY request discussed in Section 9.2.

9.4.  Multiple or Parallel Queries

   As discussed
   DHCPLEASEQUERY message exchanges in its Section 8.3, requestors may want to leverage an
   existing connection if they need to make multiple queries.  Servers
   MAY support reading 7, and processing multiple queries from a single
   connection.  A server MUST NOT read more query messages from a
   connection than it is prepared to process simultaneously.

   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 all of simultaneous queries
   permitted from any one requestor, in order to control resource use if the
   solutions discussed there are multiple requestors seeking service.

9.5.  Closing Connections

   The server MAY close its end of applicable to the TCP connection after sending its
   last message, a DHCPLEASEQUERYDONE DHCPLEASEQUERY
   message exchanges described in response this document.

10.  IANA Considerations

   IANA is requested to a query.
   Alternatively, the server MAY retain assign the connection and wait following new values for
   additional queries from the requestor.  The server SHOULD be prepared
   to limit the number this
   document.  See Section 6.2 for details.

      1. A dhcp-message-type of connections it maintains, and SHOULD be
   prepared to close idle connections to enforce the limit.

   The server MUST close its end 14 for DHCPBULKLEASEQUERY.

      2. A dhcp-message-type of the TCP connection if it encounters
   an error sending data on the connection.  The server MUST close its
   end 15 for DHCPLEASEQUERYDONE.

      3. An option code 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 TBD1 for base-time.

      4. An option code in the dhcp-message of TBD2 for start-time-of-state.

      5. An option in a DHCPLEASEQUERYDONE
   message, including a message string indicating details code of the reason TBD3 for the abort.   If the server detects that the requesting end query-start-time.

      6. An option code of the
   connection has been closed, the server MUST close its end TBD4 for query-end-time.

      7. An option code of TBD5 for data-source.

      8. An option code of TBD6 for dhcp-state.

      9. Values for dhcp-state:

           State
           -----
             1     AVAILABLE
             2     ACTIVE
             3     EXPIRED
             4     RELEASED
             5     ABANDONED
             6     RESET
             7     REMOTE
             8     TRANSITIONING

      10.Values for status code in a constrained dhcp-message option
         (option 53):

           Name    status-code
           ----    -----------
           Success         000
           UnspecFail      001
           QueryTerminated 002
           MalformedQuery  003
           NotAllowed      004

      11.Additional type field values for the
   connection after it has finished processing any outstanding requests.

   The server MUST send Virtual Subnet Selection
         Type and Information [VpnId]:

                Type     VSS Information format:

                 0       NVT ASCII VPN identifier
                 1       RFC2685 VPN-ID
                 2-253   Not Allowed
          NEW -> 254     All VPN's.  (wildcard)
                 255     Global, default VPN.

11.  Acknowledgements

   This draft is a DHCPLEASEQUERYDONE message at collaboration between the end authors of the
   data returned draft-dtv-dhc-
   dhcpv4-bulk-leasequery-00.txt and draft-kkinnear-dhc-dhcpv4-bulk-
   leasequery-00.txt.  Both documents acknowledged that significant text
   as well as important ideas were borrowed in whole or in part from a the
   DHCPv6 Bulk Leasequery request.

10.  Security Considerations

   The "Security Considerations" section of [RFC2131] details RFC, [RFC5460] written by Mark Stapp. Further
   suggestions and improvements were made by participants in the
   general threats to DHCPv4.  The DHCPv4 Leasequery specification
   [RFC4388] describes recommendations DHC
   working group, including Alfred Hoenes.

12.  References

12.1.  Normative References

   [RFC2119] Bradner, S., "Key words for the Leasequery protocol,
   especially with regard to authentication of LEASEQUERY messages,
   mitigation of packet-flooding DOS attacks, and restriction to trusted
   requestors.

   The use of TCP introduces some additional concerns.  Attacks that
   attempt in RFCs to exhaust the Indicate
      Requirement Levels", RFC 2119, March 1997.

   [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
      March 1997.

   [RFC2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
      Extensions", RFC 2132, March 1997.

   [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
      3046, January 2001.

   [RFC4388] Woundy, R., K. Kinnear, "Dynamic Host Configuration
      Protocol (DHCP) Leasequery", RFC 4388, February 2006.

   [RelayId] Stapp, M., "The DHCPv4 server's available TCP connection
   resources, such as SYN flooding attacks, can compromise the ability
   of legitimate requestors to receive service.  Malicious requestors
   who succeed Relay Agent Identifier Suboption",
      draft-ietf-dhc-relay-id-suboption-07.txt, (work 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.  We recommend that servers
   offer configuration to limit the sources of incoming connections,
   that they limit the number of accepted connections progress) July
      2009.

   [VpnId] Kinnear, K., R. Johnson, M. Stapp and the number of
   in-process queries from any one connection, J. Kumarasamy, "Virtual
      Subnet Selection Options for DHCPv4 and that they limit the
   period of time during which an idle connection will be left open.

11.  IANA Considerations

   IANA is requested to assign the following new values DHCPv6" draft-ietf-dhc-
      vpn-option-11.txt, (work in progress) March 2009.

12.2.  Informative References

   [RFC951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC
      951, September 1985.

   [RFC1542] Wimer, W., "Clarifications and Extensions for this
   document.  See Section 7.2 for details.

      1. A dhcp-message-type of 14 for DHCPBULKLEASEQUERY.

      2. A dhcp-message-type of 15 for DHCPLEASEQUERYDONE.

      3. An option code of TBD1 for base-time.

      4. An option code of TBD2 for start-time-of-state.

      5. An option code of TBD3 for query-start-time.

      6. An option code of TBD4 for query-end-time.

      7. An option code of TBD5 for data-source.

      8. An option code of TBD6 for dhcp-state.

      9. Values for dhcp-state:

           State
           -----
             1     AVAILABLE
             2     ACTIVE
             3     EXPIRED
             4     RELEASED
             5     ABANDONED
             6     RESET
             7     REMOTE
             8     TRANSITIONING

      10.Values for status code in a constrained dhcp-message option
         (option 53):

           Name    status-code
           ----    -----------
           Success         000
           UnspecFail      001
           QueryTerminated 002
           MalformedQuery  003
           NotAllowed      004

      11.Additional type field values for the Virtual Subnet Selection
         Type and Information [VpnId]:

                Type     VSS Information format:

                 0       NVT ASCII VPN identifier
                 1       RFC2685 VPN-ID
                 2-253   Not Allowed
          NEW -> 254     All VPN's.  (wildcard)
                 255     Global, default VPN.

12.  Acknowledgements

   This draft is a collaboration between the authors of draft-dtv-dhc-
   dhcpv4-bulk-leasequery-00.txt and draft-kkinnear-dhc-dhcpv4-bulk-
   leasequery-00.txt.  Both documents acknowledged that significant text
   as well as important ideas were borrowed in whole or in part from the
   DHCPv6 Bulk Leasequery RFC, [DHCPv6Bulk] written by Mark Stapp.
   Further suggestions and improvements were made by participants in the
   DHC working group, including Alfred Hoenes.

13.  References

13.1.  Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
      Requirement Levels", RFC 2119, March 1997.

   [RFC2131] Droms, R., "Dynamic Host Configuration Bootstrap
      Protocol", RFC 2131,
      March 1997.

   [RFC2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
      Extensions", RFC 2132, March 1997.

   [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
      3046, January 2001.

   [RFC4388] Woundy, R., K. Kinnear, "Dynamic Host Configuration
      Protocol (DHCP) Leasequery", RFC 4388, February 2006.

   [RelayId] Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption",
      draft-ietf-dhc-relay-id-suboption-06.txt, (work in progress)
      December 2008.

   [VpnId] Kinnear, K., R. Johnson, M. Stapp and J. Kumarasamy, "Virtual
      Subnet Selection Options for DHCPv4 and DHCPv6" draft-ietf-dhc-
      vpn-option-09.txt, (work in progress) July 2008.

13.2.  Informative References

   [RFC951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC
      951, September 1985.

   [RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap
      Protocol", RFC 1542, October 1993.

   [RFC4614] Duke, M., R. Braden, W. Eddy, 1542, October 1993.

   [RFC4614] Duke, M., R. Braden, W. Eddy, and E. Blanton, "A Roadmap
      for Transmission Control Protocol (TCP) Specification Documents",
      RFC 4614, September 2006.

   [DHCPv6Bulk]

   [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", draft-ietf-dhc-
      dhcpv6-bulk-leasequery-06.txt, (work in progress) January RFC 5460, February
      2009.

Authors' Addresses

      Kim Kinnear
      Cisco Systems
      1414 Massachusetts Ave.
      Boxborough, Massachusetts 01719

      Phone: (978) 936-0000

      EMail: kkinnear@cisco.com

      Bernie Volz
      Cisco Systems
      1414 Massachusetts Ave.
      Boxborough, Massachusetts 01719

      Phone: (978) 936-0000

      EMail: volz@cisco.com

      Neil Russell
      Cisco Systems
      1414 Massachusetts Ave.
      Boxborough, Massachusetts 01719
      Phone: (978) 936-0000
      10 Jordan Terrace
      Wakefield, MA 01880

      EMail: nrussell@cisco.com provng@gmail.com

      Mark Stapp
      Cisco Systems
      1414 Massachusetts Ave.
      Boxborough, Massachusetts 01719

      Phone: (978) 936-0000

      EMail: mjs@cisco.com

      Ramakrishna Rao DTV
      Infosys Technologies Ltd.
      44 Electronics City, Hosur Road
      Bangalore  560 100
      India

      EMail: ramakrishnadtv@infosys.com
      URI:   http://www.infosys.com/

      Bharat Joshi
      Infosys Technologies Ltd.
      44 Electronics City, Hosur Road
      Bangalore  560 100
      India

      EMail: bharat_joshi@infosys.com
      URI:   http://www.infosys.com/

      Pavan Kurapati
      Infosys Technologies Ltd.
      44 Electronics City, Hosur Road
      Bangalore  560 100
      India

      EMail: pavan_kurapati@infosys.com
      URI:   http://www.infosys.com/

Appendix -- Why a New Leasequery is Required

   The three existing query types supported by [RFC4388] do not provide
   effective and efficient antispoofing for the scenario discussed in
   Section 3.

   o  Query by Client Identifier

   Query by Client Identifier is not possible because the access
   concentrator would need to glean the client-identifier.  This is not
   possible since if we are using a Leasequery, it is because the
   gleaned information was lost. On the other hand, we can query by
   client-identifier when the client sends a DHCPv4 request, but then
   there may not be any need for Leasequery as such -- regular gleaning
   may be enough.

   o  Query by IP Address

   [RFC4388] suggests that it is preferable to use Query by IP Address
   when getting downstream traffic.

   Query by IP address is not very useful because downstream traffic may
   not exist for the clients on a DSL port.  (In most Internet
   applications, downstream traffic exists only when a client sends
   upstream traffic).  In other words, the client will be denied service
   until it gets downstream traffic, which may never arrive.

   Query by IP address may be used for upstream traffic.  Then whenever
   an upstream packet arrives whose IP address is unknown to the access
   concentrator, a Leasequery may be initiated.  A related question is
   what to do with that upstream traffic itself until the leasequery
   response arrives?  If the traffic is dropped, we may be dropping
   legitimate traffic.  If the traffic is forwarded, we may be
   forwarding spoofed packets.  Once the lease response arrives,
   subsequent traffic is handled depending on the response.  If a
   DHCPLEASEACTIVE response arrives, the access concentrator will accept
   the traffic.  If a DHCPLEASEUNASSIGNED response arrives, the access
   concentrator will drop the traffic corresponding to the IP address.
   If a DHCPLEASEUNKNOWN response arrives the access concentrator may
   drop the traffic corresponding to the IP address but will have to
   periodically send the Leasequery for that IP address again
   (additional overhead).  The process is triggered whenever an unknown
   IP address arrives.

   Note that the access concentrator needs to keep track of 4 lists of
   IP addresses: (1) List of IP addresses for which it got
   DHCPLEASEACTIVE responses; (2) List of IP addresses for which it got
   DHCPLEASEUNASSIGNED responses; (3) List of IP addresses for which it
   got DHCPLEASEUNKNOWN responses; (4) All other IP addresses.

   This approach may be acceptable if only legitimate traffic is
   received.  Consider the case when someone sends packets that uses
   spoofed IP addresses.  In that case, lease response will be
   DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN.  [RFC4388] suggests usage of
   negative caching in this regard (which involves additional
   resources).

   In a spoofing type of attack, negative caching information may grow
   considerably if the attacker varies the source IP address.  For each
   such new source IP address, traffic will arrive on the slow path, a
   new lease query needs to be initiated, the response will be
   processed, and negative caching needs to be done.  That will mean
   using many resources for negative caching.

   [RFC4388] suggests that if the access concentrator knows the network
   portion of the IP addresses that are assigned to its clients, then
   some amount of antispoofing can be done in the fast path and some
   lease queries may be avoided.  But as indicated before, that
   information may not always be available to access concentrators.

   Effectively, antispoofing support involves considerable slow path
   processing and considerable resources tied for negative caching.

   [RFC4388] says that DHCPv4 servers should be protected from being
   flooded with too many Leasequery requests and access concentrators
   also should not send too many Leasequery messages at a time.  This
   would mean that legitimate requestors may be excessively delayed
   getting their information in the face of spoofing attacks.

   It is concluded that antispoofing is neither effective nor efficient
   with this query type.

   o  Query by MAC Address

   Query by MAC address can also be used in a way similar to query by IP
   address described above.  Indeed, query by MAC address may be better
   than query by IP address in one sense because of the possible
   presence of the associated-ip option in lease responses. (Note that
   the associated-ip option does not appear in responses for a query by
   IP address).  With the associated-ip option access concentrator can
   get information not only about the IP address/MAC address that
   triggered the Leasequery but also about other IP addresses that are
   associated with the original MAC address.  That way, when traffic
   that uses the other IP addresses arrives, the access concentrator is
   already prepared to deal with them.

   Although query by MAC address is better than query by IP address in
   the above respect, it has a specific problem which is not shared by
   query by IP address.  For a query by MAC address, only two types of
   responses are possible: DHCPLEASEUNKNOWN and DHCPLEASEACTIVE;
   DHCPLEASEUNASSIGNED is not supported.  This is particularly
   troublesome when a DHCPv4 server indeed has definitive information
   that no IP addresses are associated with the specified MAC address in
   the Leasequery, but it is forced to respond with DHCPLEASEUNKNOWN
   instead of DHCPLEASEUNASSIGNED.  As we have seen above, unlike
   DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN requires periodic querying the
   DHCPv4 server, an additional overhead.

   Moreover, query by MAC address also shares all other issues we
   discussed above for query by IP address.

   We conclude that existing Leasequery types are not appropriate to
   achieve effective and efficient antispoofing in the environment
   discussed.