DHC Working Group                                                 D. Rao
Internet-Draft                                                  B. Joshi
Expires: January 2, 2009                                     P. Kurapati
                                               Infosys Technologies Ltd.
                                                            July 1, 2008


                        DHCPv4 bulk lease query
              draft-dtv-dhc-dhcpv4-bulk-leasequery-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 January 2, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been
   extended with a Leasequery capability that allows a client to request
   information about DHCPv4 bindings.  That 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 the Leasequery protocol, adding new query types
   and allowing for bulk transfer of DHCPv4 binding data via TCP.



Rao, et al.              Expires January 2, 2009                [Page 1]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Design Goals . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Information Acquisition before Data Starts . . . . . . . .  6
     4.2.  Lessen Negative Caching  . . . . . . . . . . . . . . . . .  6
     4.3.  Antispoofing in 'Fast Path'  . . . . . . . . . . . . . . .  6
   5.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Interaction Between UDP Leasequery and Bulk Leasequery . . . .  9
   7.  Message and Option Definitions . . . . . . . . . . . . . . . . 10
     7.1.  Message Framing for TCP  . . . . . . . . . . . . . . . . . 10
     7.2.  Messages . . . . . . . . . . . . . . . . . . . . . . . . . 11
       7.2.1.  DHCPLEASEDATA  . . . . . . . . . . . . . . . . . . . . 12
       7.2.2.  DHCPLEASEDONE  . . . . . . . . . . . . . . . . . . . . 12
       7.2.3.  DHCPLEASEQUERYFAIL . . . . . . . . . . . . . . . . . . 12
     7.3.  Query Types  . . . . . . . . . . . . . . . . . . . . . . . 13
       7.3.1.  QUERY_BY_RELAYID . . . . . . . . . . . . . . . . . . . 13
       7.3.2.  QUERY_BY_REMOTE_ID . . . . . . . . . . . . . . . . . . 14
     7.4.  Options  . . . . . . . . . . . . . . . . . . . . . . . . . 14
       7.4.1.  STATUS-CODE option . . . . . . . . . . . . . . . . . . 14
     7.5.  Connection and Transmission Parameters . . . . . . . . . . 16
   8.  Requestor Behavior . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Connecting . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.2.  Forming Queries  . . . . . . . . . . . . . . . . . . . . . 17
     8.3.  Processing Replies . . . . . . . . . . . . . . . . . . . . 17
     8.4.  Leasequery Request Completion Criteria . . . . . . . . . . 18
     8.5.  Querying Multiple Servers  . . . . . . . . . . . . . . . . 19
     8.6.  Multiple Queries to a Single Server  . . . . . . . . . . . 19
       8.6.1.  Example  . . . . . . . . . . . . . . . . . . . . . . . 19
     8.7.  Closing Connections  . . . . . . . . . . . . . . . . . . . 20
   9.  Server Behavior  . . . . . . . . . . . . . . . . . . . . . . . 21
     9.1.  Accepting Connections  . . . . . . . . . . . . . . . . . . 21
     9.2.  Forming Replies  . . . . . . . . . . . . . . . . . . . . . 21
     9.3.  Multiple or Parallel Queries . . . . . . . . . . . . . . . 22
     9.4.  Closing Connections  . . . . . . . . . . . . . . . . . . . 22
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 26
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     13.1. Normative Reference  . . . . . . . . . . . . . . . . . . . 27
     13.2. Informative Reference  . . . . . . . . . . . . . . . . . . 27
   Appendix 1.  Why a New Leasequery is Required? . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
   Intellectual Property and Copyright Statements . . . . . . . . . . 32





Rao, et al.              Expires January 2, 2009                [Page 2]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


1.  Introduction

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

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

   Figure 1

   DHCP relay agents snoop DHCP messages and append relay agent
   information option before relaying it to the configured DHCP Servers
   (see Figure 1).  In this process, some relay agents also glean the
   lease information sent by the server and maintain this locally.  This
   information is used for prevention of spoofing attempts from the
   clients and to install routes.  When a relay agent reboots, this
   information is lost.  RFC 4388 [5] has defined a mechanism to obtain
   this lease information from the server.  The existing query types in
   leasequery are data driven; relay agent initiates the leasequery when
   it receives data traffic from/for the client.  This approach does not
   scale well when there are thousands of clients connected to the relay
   agent.  Different query types are needed where a relay agent can
   query the server without waiting for the traffic from/for the
   clients.

   This document extends the DHCPv4 Leasequery protocol to add support
   for queries that address these requirements.  There may be many
   thousands of DHCPv4 bindings per relay agent, so we specify the use
   of TCP [4] for efficiency of data transfer.  We specify a new query
   type that uses the Relay Identifier sub-option to support efficient
   recovery of all data associated with a specific relay agent.  We also
   specify query-type by Remote-ID sub-option value, to assist a relay
   agent that needs to recover a subset of its clients' bindings.






Rao, et al.              Expires January 2, 2009                [Page 3]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


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 [1].

   DHCPv4 terminology is defined in [2].  DHCPv4 Leasequery terminology
   is defined in [5].  DUID terminology is in defined in [7].  Relay
   agent terminalogy is defined in [3].










































Rao, et al.              Expires January 2, 2009                [Page 4]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


3.  Motivation

   Consider a typical DSLAM working also as a DHCP relay agent (see
   Figure 1).  "Fast path" and "slow path" generally exist in most
   networking boxes including DSLAMs.  Fast path processing is done in
   network processor or 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 in fast path.
   Slow path processing should be reduced as it may become a bottleneck.

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

   The DSLAM gleans IP address or other information from DHCP
   negotiations for antispoofing and for other purposes.  The
   antispoofing itself is done in fast path.  DSLAM keeps track of only
   one list of IP addresses: list of IP addresses that are assigned by
   DHCP server.  Traffic for all other IP addresses is dropped.  If
   client starts its data transfer after its DHCP negotiations are
   gleaned by 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 fast path).  The intention is
   to achieve similar effective and efficient antispoofing in the lease
   query scenario also when a DSLAM loses its gleaned information (for
   example, because of reboot).

   After a deep analysis, we found that the three existing query types
   supported by RFC 4388 [5] do not provide effective and efficient
   antispoofing for the above scenario and a new mechanism is required.

   The existing query types

   o  necessitate a data driven approach: the lease queries can only be
      done when the Access Concentrator receives data.  That results in
      increased outage time for clients.

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

   o  result in antispoofing being done in slow path instead of fast
      path.

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




Rao, et al.              Expires January 2, 2009                [Page 5]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


4.  Design Goals

   The goal of this document is to provide a lightweight mechanism for
   an Access Concentrator to retrieve lease information available in the
   DHCP server.  The mechanism should also support an Access
   Concentrator to retrieve consolidated lease information for the
   entire access concentrator or for a connection/circuit.

4.1.  Information Acquisition before Data Starts

   Existing data driven approach by RFC 4388 [5] means that the lease
   queries can only be done when an Access Concentrator receives data.
   For antispoofing, packets need to be dropped until it gets the lease
   information from DHCP server.  If an Access Concentrator finishes the
   lease queries before it starts receiving data, then there is no need
   to drop legitimate packets.  So, effectively outage time may be
   reduced.

4.2.  Lessen Negative Caching

   If lease queries result in negative caches, then that puts additional
   overhead on the access concentrator.  The negative caches not only
   consume precious resources they also need to be managed.  Hence they
   should be avoided as much as possible.  The lease queries should
   reduce the need for negative caching as far as possible.

4.3.  Antispoofing in 'Fast Path'

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



















Rao, et al.              Expires January 2, 2009                [Page 6]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


5.  Protocol Overview

   The Bulk Leasequery mechanism is modeled on the existing individual
   Leasequery protocol described in RFC 4388[5]; most differences arise
   from the use of TCP.  A Bulk Leasequery client opens a TCP connection
   to a DHCPv4 Server, using the DHCPv4 port 67.  Note that this implies
   that the Leasequery client has server IP address(es) available via
   configuration or some other means, and that it has unicast IP
   reachability to the server.  No relaying for bulk leasequery is
   specified.

   After establishing a connection, the client sends a DHCPLEASEQUERY
   message containing a query-type and data about bindings it is
   interested in.  The server uses the query-type and the data to
   identify any relevant bindings.  In order to support some query-
   types, servers may have to maintain additional data structures or be
   able to locate bindings based on specific option data.  The server
   replies with a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE,
   DHCPLEASEQUERYFAIL, or DHCPLEASEUNKNOWN.  The reasons why a
   DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message
   might be generated are explained in [5] and below.  The reasons why a
   DHCPLEASEQUERYFAIL message might be generated are explained below.
   If the query was successful, the server includes the first client's
   binding data in a DHCPLEASEACTIVE message.  If more than one client's
   bindings are being returned, the server then transmits the additional
   client bindings in a series of DHCPLEASEDATA messages.  If the server
   has sent at least one client's bindings, it sends a DHCPLEASEDONE
   message when it has finished sending its replies.  The client may
   reuse the connection to send additional queries.  Each end of the TCP
   connection can be closed after all data has been sent.

   The Relay-ID sub-option is defined in [6].  The sub-option contains a
   DUID identifying a DHCPv4 relay agent.  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.  A relay agent can then recover binding
   information about downstream clients by using the Relay-ID in a
   DHCPLEASEQUERY message.

   Bulk Leasequery supports the queries by IPv4 address, MAC address,
   and Client Identifier as specified in RFC4388 [5].  The Bulk
   Leasequery protocol also adds two 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.



Rao, et al.              Expires January 2, 2009                [Page 7]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


   o  Query by Remote ID

   This query asks a server for the bindings associated with a Relay
   Agent Remote-ID sub-option [3] value.















































Rao, et al.              Expires January 2, 2009                [Page 8]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


6.  Interaction Between UDP Leasequery and Bulk Leasequery

   Bulk Leasequery can be seen as an extension of the existing UDP
   Leasequery protocol [5].  This section tries to clarify the
   relationship between the two protocols.

   The query-types introduced in the UDP Leasequery protocol can be used
   in the Bulk Leasequery protocol.  One change in behavior is required
   when Bulk Leasequery is used.  RFC4388 [5], 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.

   Only DHCPLEASEQUERY, DHCPLEASEACTIVE, DHCPLEASEUNASSIGNED,
   DHCPLEASEUNKNOWN, DHCPLEASEDATA, DHCPLEASEQUERYFAIL, and
   DHCPLEASEDONE messages are allowed over the Bulk Leasequery
   connection.  No other DHCPv4 messages are supported.  The Bulk
   Leasequery connection is not an alternative DHCPv4 communication
   option for clients seeking DHCPv4 service.





























Rao, et al.              Expires January 2, 2009                [Page 9]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


7.  Message and Option Definitions

7.1.  Message Framing for TCP

   The use of TCP for the Bulk Leasequery protocol permits one or more
   DHCPv4 messages to be sent at a time.  The receiver needs to be able
   to determine how large each message is.  Four octets, out of which
   the first two octets contain the message size in network byte-order,
   are prepended to each DHCPv4 message sent on a Bulk Leasequery TCP
   connection.  The four octets 'frame' each DHCPv4 message.

   DHCPv4 message framed for TCP:







































Rao, et al.              Expires January 2, 2009               [Page 10]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


   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            |         unused                |
   +---------------+---------------+---------------+---------------+
   |     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
   +---------------+---------------+---------------+---------------+
   |                            xid (4)                            |
   +-------------------------------+-------------------------------+
   |           secs (2)            |           flags (2)           |
   +-------------------------------+-------------------------------+
   |                          ciaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          yiaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          siaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          giaddr  (4)                          |
   +---------------------------------------------------------------+
   |                                                               |
   |                          chaddr  (16)                         |
   |                                                               |
   |                                                               |
   +---------------------------------------------------------------+
   |                                                               |
   |                          sname   (64)                         |
   +---------------------------------------------------------------+
   |                                                               |
   |                          file    (128)                        |
   +---------------------------------------------------------------+
   |                                                               |
   |                          options (variable)                   |
   +---------------------------------------------------------------+

      message-size    the number of octets in the message that
                      follows (excluding the two unused bytes), as a
                      16-bit integer in network byte-order.
      unused          these 16 bits are unused; they should be set to
                      zero by sender and ignored by receiver.

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

7.2.  Messages

   The DHCPLEASEQUERY, DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN, and
   DHCPLEASEACTIVE messages are defined in RFC4388 [5].  In a Bulk
   Leasequery exchange, a single DHCPLEASEUNASSIGNED,
   DHCPLEASEQUERYFAIL, or DHCPLEASEUNKNOWN message is used to indicate



Rao, et al.              Expires January 2, 2009               [Page 11]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


   the failure of a query.  A single DHCPLEASEACTIVE message is used to
   indicate the success of a query, and contains the first client's
   binding data.  It also carries data that do not change in the context
   of a single query and answer, such as the Server Identifier (option
   54) option.

7.2.1.  DHCPLEASEDATA

   The DHCPLEASEDATA message (message type TBD) carries data about a
   single DHCPv4 client's leases and bindings.  The purpose of the
   message is to reduce redundant data when there are multiple bindings
   to be sent.  The DHCPLEASEDATA message MUST be preceded by a
   DHCPLEASEACTIVE message.  The DHCPLEASEACTIVE carries the
   Leasequery's Server Identifier options, and carries the first
   client's binding data if the query was successful.

   DHCPLEASEDATA MUST ONLY be sent in response to a successful
   DHCPLEASEQUERY, and only if more than one client's data is to be
   sent.  The DHCPLEASEDATA message's xid field MUST match the xid of
   the DHCPLEASEQUERY request message.  The Server Identifier option
   SHOULD NOT be included: that data should be constant for any one Bulk
   Leasequery reply, and should have been conveyed in the
   DHCPLEASEACTIVE message.

7.2.2.  DHCPLEASEDONE

   The DHCPLEASEDONE message (message type TBD) indicates the end of a
   group of related Leasequery replies.  The DHCPLEASEDONE message's xid
   field MUST match the xid of the DHCPLEASEQUERY request message.  The
   presence of the message itself signals the end of a stream of reply
   messages.  A single DHCPLEASEDONE MUST be sent after all replies (a
   DHCPLEASEACTIVE and zero or more DHCPLEASEDATA messages) to a
   successful Bulk Leasequery request that returned at least one
   binding.  Other DHCPv4 options SHOULD NOT be included in the
   DHCPLEASEDONE message.

7.2.3.  DHCPLEASEQUERYFAIL

   A server may encounter an error condition while processing a
   DHCPLEASEQUERY message but before it has sent any response.  A server
   may also encounter an error condition after it has sent the initial
   DHCPLEASEACTIVE.  In these cases, it SHOULD attempt to send a
   DHCPLEASEQUERYFAIL (message type TBD) with STATUS_CODE option
   indicating the error condition to the requestor.  Other DHCPv4
   options SHOULD NOT be included in the DHCPLEASEQUERYFAIL message.






Rao, et al.              Expires January 2, 2009               [Page 12]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


7.3.  Query Types

   We introduce the following new query-types: QUERY_BY_RELAYID and
   QUERY_BY_REMOTE_ID.  These queries are designed to assist relay
   agents in recovering binding data in circumstances where some or all
   of the relay agent's binding data has been lost.

7.3.1.  QUERY_BY_RELAYID

   This query asks the server to return bindings associated with the
   specified relay DUID.  A relay agent MAY include the option in the
   messages it relays.  Obviously, it will not be possible for a server
   to respond to QUERY_BY_RELAYID queries unless the relay agent has
   included this option.  A relay agent SHOULD be able to generate a
   DUID for this purpose, and capture the result in stable storage.  A
   relay agent SHOULD also allow the DUID value to be configurable:
   doing so allows an administrator to replace a relay agent while
   retaining the association between the relay agent and existing DHCPv4
   bindings.

   A DHCPv4 Server MAY associate Relay-ID sub-options from relayed
   messages it processes with lease bindings that result.  Doing so
   allows it to respond to QUERY_BY_RELAYID Leasequeries.

   QUERY_BY_RELAYID message is formatted as follows:

   o  The requester supplies only an option 82 which will include only
      an Agent Relay ID sub-option in the DHCPLEASEQUERY message.  The
      query options MUST contain a RELAYID sub-option.

   o  The "ciaddr" field MUST be set to zero.

   o  The values of htype, hlen, and chaddr MUST be set to zero.

   o  The Client-identifier option (option 61) MUST NOT appear in the
      packet.

   The DHCP server replies with a DHCPLEASEACTIVE message if the DHCP
   server has one or multiple active leases which were assigned through
   the Relay Agent identified by Relay ID in the DHCPLEASEQUERY message.
   If the Server has recorded Relay-ID values with its bindings, it uses
   the sub-option's value to identify bindings to return.  Server
   replies with a DHCPLEASEUNASSIGNED if it has information of the said
   relay ID but no lease is associated with the same.  Server replies
   with a DHCPLEASEUNKNOWN message if it has no information of the said
   relay ID.





Rao, et al.              Expires January 2, 2009               [Page 13]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


7.3.2.  QUERY_BY_REMOTE_ID

   The QUERY_BY_REMOTE_ID is used to ask the server to return bindings
   associated with a Remote-ID sub-option value from a relayed message.
   QUERY_BY_REMOTE_ID for TCP defined in this draft is consistent with
   QUERY_BY_REMOTE_ID for UDP defined in [9].

   In order to support this query, a server needs to record the most-
   recent Remote-ID sub-option value seen in a relayed message along
   with its other binding data.

   QUERY_BY_REMOTE_ID message is formatted as follows:

   o  There MUST be only a Relay Agent Information option (option 82)
      with only Agent Remote ID sub-option (sub-option 2) in the
      DHCPLEASEQUERY message.

   o  The "ciaddr" field MUST be set to zero.

   o  The values of htype, hlen, and chaddr MUST be set to zero.

   o  The Client-identifier option (option 61) MUST NOT appear in the
      packet.

   The DHCP server replies with a DHCPLEASEACTIVE message if the Agent
   Remote ID in the DHCPLEASEQUERY message currently has an active lease
   on an IP address in this DHCP server.  Server replies with a
   DHCPLEASEUNASSIGNED if it has information of the said remote ID but
   no lease is associated with the same.  Server replies with a
   DHCPLEASEUNKNOWN message if it has no information of the said remote
   ID.  If the Server has recorded Remote-ID values with its bindings,
   it uses the sub-option's value to identify bindings to return.

7.4.  Options

7.4.1.  STATUS-CODE option

   This option returns a status indication related to the DHCP message.
   Currently it is used along with DHCPLEASEQUERYFAIL message.

   The format of the Status Code option is:


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              STATUS_CODE      |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Rao, et al.              Expires January 2, 2009               [Page 14]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


   |          status-code          |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   .                                                               .
   .                        status-message                         .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code      STATUS_CODE (TBD).

    option-len       2 + length of status-message.

    status-code      The numeric code for the status encoded in
                     this option.  The status codes are defined below.

    status-message   A UTF-8 encoded text string suitable for
                     display to an end user, which MUST NOT be
                     null-terminated.

    A Status Code option may appear in the options field of a DHCP
    message. If the Status Code option does not appear in a message
    in which the option could appear, the status of the message is
    assumed to be Success.

    The following status codes are defined:

   Name             Code Description
   ----------       ---- -----------
   Success            0  Success.
   UnspecFail         1  Failure, reason unspecified; this
                         status code is sent by either a client
                         or a server to indicate a failure
                         not explicitly specified in this
                         document.
   UnknownQueryType   2  The query-type is unknown to or not supported
                         by the server.
   MalformedQuery     3  The query is not valid; for example, a
                         required query option is missing.
   NotAllowed         4  The server does not allow the requestor to
                         issue this DHCPLEASEQUERY
   QueryTerminated    5  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). This may be because the
                         server is short of resources or is being shut
                         down. The requestor may retry the query at a
                         later time. The requestor should wait at least
                         a short interval before retrying. Note that
                         while a server may simply prematurely close



Rao, et al.              Expires January 2, 2009               [Page 15]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


                         its end of the connection, it is preferable
                         for the server to send a DHCPLEASEQUERYFAIL
                         with this status-code to notify the requestor
                         of the condition.

7.5.  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.  Client implementations 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.

   Parameter             Default  Description
   ------------------------------------------------------------------
   BULK_LQ_CONN_TIMEOUT  30 secs  Bulk Leasequery connection timeout
   BULK_LQ_DATA_TIMEOUT  30 secs  Bulk Leasequery data timeout
   BULK_LQ_MAX_RETRY     60 secs  Max Bulk Leasequery retry timeout
   BULK_LQ_MAX_CONNS     10       Max Bulk Leasequery TCP connections



























Rao, et al.              Expires January 2, 2009               [Page 16]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


8.  Requestor Behavior

8.1.  Connecting

   A Requestor attempts to establish a TCP connection to a DHCPv4 Server
   in order to initiate a Leasequery exchange.  The Requestor SHOULD be
   prepared to abandon the connection attempt after
   BULK_LQ_CONN_TIMEOUT.  If the attempt fails, the Requestor MAY retry.
   Retries MUST use an exponential backoff timer, increasing the
   interval between attempts up to BULK_LQ_MAX_RETRY.

8.2.  Forming Queries

   After a connection is established, the Requestor constructs a
   Leasequery message, as specified in [5].  The query may have any of
   the defined query-types, and includes the options and data required
   by the query-type chosen.  The Requestor sends the message size, 16
   reserved bits (zeroes), and then sends the actual DHCPv4 message, as
   described in Section 7.1.

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

8.3.  Processing Replies

   The Requestor attempts to read a DHCPLEASEACTIVE, DHCPLEASEUNKNOWN,
   DHCPLEASEQUERYFAIL, or DHCPLEASEUNASSIGNED message from the TCP
   connection.  If the stream of replies becomes blocked, the Requestor
   SHOULD be prepared to terminate the connection after
   BULK_LQ_DATA_TIMEOUT, and MAY begin retry processing if configured to
   do so.

   The Requestor examines the DHCPLEASEACTIVE, DHCPLEASEUNKNOWN,
   DHCPLEASEQUERYFAIL, or DHCPLEASEUNASSIGNED message, and determines
   how to proceed.  If the xid in the received message does not match an
   outstanding DHCPLEASEQUERY message, the client MUST close the TCP
   connection.  Message processing rules for DHCPLEASEACTIVE are
   specified in DHCPv4 Leasequery [5].  DHCPLEASEUNKNOWN and
   DHCPLEASEUNASSIGNED replies indicate that the target server had no
   bindings matching the query.  DHCPLEASEQUERYFAIL indicates that the
   server failed to serve the client.  More details will be available in
   the received STATUS_CODE option.

   The Leasequery protocol [5] uses the associated-ip option as an



Rao, et al.              Expires January 2, 2009               [Page 17]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


   indicator that multiple bindings were present in response to a single
   query.  For Bulk Leasequery, the associated-ip option is not used,
   and MUST NOT be present in replies.

   A successful DHCPLEASEACTIVE that is returning binding data is
   created as specified in [5].  If there are additional bindings to be
   returned, they will be carried in DHCPLEASEDATA messages.  Each
   DHCPLEASEDATA message returns binding data and is prepared just like
   the DHCPLEASEACTIVE message described in [5] except for the new
   message type.

   A single bulk query can result in a large number of replies.  For
   example, a single relay agent might be responsible for thousands of
   DHCP clients.  The Requestor MUST be prepared to receive more than
   one DHCPLEASEDATA with xids matching a single DHCPLEASEQUERY message.

   The DHCPLEASEDONE message ends a successful Bulk Leasequery request
   that returned at least one binding.  DHCPLEASEUNKNOWN and
   DHCPLEASEUNASSIGNED MUST NOT be followed by a DHCPLEASEDONE message
   for the same xid.  After receiving DHCPLEASEDONE from a server, the
   Requestor MAY close the TCP connection to that server.  If the xid in
   the DHCPLEASEDONE does not match an outstanding DHCPLEASEQUERY
   message, the client MUST close the TCP connection.

   The DHCPLEASEQUERYFAIL message ends a Bulk Leasequery request in
   failure.  Depending on the status code, the requestor may try a
   different server (such as for NotAllowed and UnknownQueryType), try a
   different or corrected query (such as for UnknownQueryType and
   MalformedQuery), or terminate the query.  If the xid in the
   DHCPLEASEQUERYFAIL does not match an outstanding DHCPLEASEQUERY
   message, the client MUST close the TCP connection.

8.4.  Leasequery Request Completion Criteria

   This section provides rules for when a DHCPLEASEQUERY request is
   complete.

   A DHCPLEASEQUERY request is complete for a requestor (i.e., no
   further messages for that request will be received):

   o  If it receives a DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN,
      DHCPLEASEDONE, or DHCPLEASEQUERYFAIL message.

   o  If the connection is closed.







Rao, et al.              Expires January 2, 2009               [Page 18]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


8.5.  Querying Multiple Servers

   A Bulk Leasequery client MAY be configured to attempt to connect to
   and query from multiple DHCPv4 servers in parallel.  Binding data
   received from multiple DHCPv4 servers may need to be reconciled.

   The client data from the different servers may be disjoint or
   overlapping.

   When using the DHCPLEASEQUERY message in an environment where
   multiple DHCP servers may contain authoritative information about the
   same IP address (such as when two DHCP servers are cooperating to
   provide a high-availability DHCP service), multiple, possibly
   conflicting, responses might be received.

   In this case, some information in the response packet SHOULD be used
   to decide among the various responses.  The client-last-transaction-
   time (if it is available) can be used to decide which server has more
   recent information concerning the IP address returned in the "ciaddr"
   field.

   If the requestor receives disjoint client data from different
   sources, it SHOULD merge them.

8.6.  Multiple Queries to a Single Server

   Bulk Leasequery clients may need to make multiple queries in order to
   recover binding information.  A Requestor MAY use a single connection
   to issue multiple queries.  Each query MUST have a unique xid.  A
   server MAY process more than one query at a time.  A server that is
   willing to do so MAY interleave replies to the multiple queries
   within the stream of reply messages it sends.  Clients need to be
   aware that replies for multiple queries may be interleaved within the
   stream of reply messages.  Clients that are not able to process
   interleaved replies (based on xid) MUST NOT send more than one query
   at a time.  Requestors should be aware that servers are not required
   to process queries in parallel, and that servers are likely to limit
   the rate at which they process queries from any one Requestor.

8.6.1.  Example

   This example illustrates what a 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 clients or servers must
   support parallel queries.

   In the example session, the client sends four queries after
   establishing a connection.  Query 1 results in a failure; query 2



Rao, et al.              Expires January 2, 2009               [Page 19]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


   succeeds and the stream of replies concludes before the client issues
   any new query.  Query 3 and query 4 overlap, and the server
   interleaves its replies to those two queries.

   Client                        Server
   ------                        ------
   DHCPLEASEQUERY xid 1 ----->
                        <-----       DHCPLEASEUNKNOWN xid 1
   DHCPLEASEQUERY xid 2 ----->
                        <-----       DHCPLEASEACTIVE xid 2
                        <-----       DHCPLEASEDATA xid 2
                        <-----       DHCPLEASEDATA xid 2
                        <-----       DHCPLEASEDONE xid 2
   DHCPLEASEQUERY xid 3 ----->
   DHCPLEASEQUERY xid 4 ----->
                        <-----       DHCPLEASEACTIVE xid 4
                        <-----       DHCPLEASEDATA xid 4
                        <-----       DHCPLEASEACTIVE xid 3
                        <-----       DHCPLEASEDATA xid 4
                        <-----       DHCPLEASEDATA xid 3
                        <-----       DHCPLEASEDONE xid 3
                        <-----       DHCPLEASEDATA xid 4
                        <-----       DHCPLEASEDONE xid 4

8.7.  Closing Connections

   The Requestor MAY close its end of the TCP connection after sending a
   DHCPLEASEQUERY message to the server.  The Requestor MAY choose to
   retain the connection if it intends to issue additional queries.
   Note that this client behavior does not guarantee that the connection
   will be available for additional queries: the server might decide to
   close the connection based on its own configuration.



















Rao, et al.              Expires January 2, 2009               [Page 20]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


9.  Server Behavior

9.1.  Accepting Connections

   Servers that implement DHCPv4 Bulk Leasequery listen for incoming TCP
   connections.  Port numbers are discussed in Section 7.5.  Servers
   MUST be able to limit the number of currently accepted and active
   connections.  The value BULK_LQ_MAX_CONNS MUST be the default;
   implementations MAY permit the value to be configurable.

   Servers MAY restrict Bulk Leasequery connections and DHCPLEASEQUERY
   messages to certain clients.  Connections not from permitted clients
   SHOULD be closed immediately, to avoid server connection resource
   exhaustion.  Servers MAY restrict some clients to certain query
   types.  Servers MAY reply to queries that are not permitted with the
   DHCPLEASEQUERYFAIL message with the NotAllowed status code, or MAY
   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 BULK_LQ_DATA_TIMEOUT.  We make this recommendation
   to allow Servers to control the period of time they are willing to
   wait before abandoning an inactive connection, independent of the TCP
   implementations they may be using.

9.2.  Forming Replies

   The DHCPv4 Leasequery [5] specification describes the initial
   construction of DHCPLEASEACTIVE, DHCPLEASEUNKNOWN, and
   DHCPLEASEUNASSIGNED messages and the processing of
   QUERY_BY_IP_ADDRESS, QUERY_BY_MAC_ADDRESS, and
   QUERY_BY_CLIENTIDENTIFIER.  Use of the DHCPLEASEACTIVE and
   DHCPLEASEDATA messages to carry multiple bindings are described in
   Section 7.2.  Message transmission and framing for TCP is described
   in Section 7.1.  If the connection becomes blocked while the server
   is attempting to send reply messages, the server SHOULD be prepared
   to terminate the TCP connection after BULK_LQ_DATA_TIMEOUT.

   If the server encounters an error during initial query processing,
   before any reply has been sent, it SHOULD send a DHCPLEASEQUERYFAIL
   containing an appropriate STATUS_CODE option.  This signals to the
   requestor that no data will be returned.  If the server encounters an
   error while processing a query that has already resulted in one or
   more reply messages, the server SHOULD send a DHCPLEASEQUERYFAIL
   containing an appropriate STATUS_CODE option.  The server SHOULD
   close its end of the connection as an indication that it was not able
   to complete query processing.




Rao, et al.              Expires January 2, 2009               [Page 21]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


   If the server does not recognize the identifier (relay id or remote
   id) in a query, it SHOULD send a DHCPLEASEUNKNOWN.  If the server
   recognizes the identifier in a query but does not find any bindings
   satisfying a query, it SHOULD send a DHCPLEASEUNASSIGNED.  Otherwise,
   the server sends each binding's data in a reply message.  The first
   reply message is a DHCPLEASEACTIVE.  The binding data is carried as
   specified in [5] and extended below.  The server returns subsequent
   bindings in DHCPLEASEDATA messages.

   For QUERY_BY_RELAYID, the server locates each binding associated with
   the query's Relay-ID sub-option value.  In order to give a meaningful
   reply to a QUERY_BY_RELAYID, the server has to be able to maintain
   this association in its DHCPv4 binding data.

   For QUERY_BY_REMOTE_ID, the server locates each binding associated
   with the query's Relay Remote-ID sub-option value.  In order to be
   able to give meaningful replies to this query, the server has to be
   able to maintain this association in its binding database.

   The server sends the DHCPLEASEDONE message as specified in Section
   7.2.

9.3.  Multiple or Parallel Queries

   As discussed in Section 6.5, Requestors may want to leverage an
   existing connection if they need to make multiple queries.  Servers
   MAY support reading 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 of simultaneous queries
   permitted from any one Requestor, in order to control resource use if
   there are multiple Requestors seeking service.

9.4.  Closing Connections

   The server MAY close its end of the TCP connection after sending its
   last message (a DHCPLEASEUNASSIGNED, a DHCPLEASEUNKNOWN,
   DHCPLEASEQUERYFAIL, or a DHCPLEASEDONE) in response to a query.
   Alternatively, the server MAY retain the connection and wait for
   additional queries from the client.  The server SHOULD be prepared to
   limit the number of connections it maintains, and SHOULD be prepared
   to close idle connections to enforce the limit.

   The server MUST close its end of the TCP connection if it encounters
   an error sending data on the connection.  The server MUST close its



Rao, et al.              Expires January 2, 2009               [Page 22]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


   end of the TCP connection if it finds that it has to abort an in-
   process request.  A server aborting an in-process request MAY attempt
   to signal that to its clients by using the DHCPLEASEQUERYFAIL message
   type (Section 7.2.3).  If the server detects that the client end has
   been closed, the server MUST close its end of the connection after it
   has finished processing any outstanding requests from the client.













































Rao, et al.              Expires January 2, 2009               [Page 23]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


10.  Security Considerations

   The "Security Considerations" section of [2] details the general
   threats to DHCPv4.  The DHCPv4 Leasequery specification [5] describes
   recommendations for the Leasequery protocol, especially with regard
   to DHCPLEASEQUERY messages, mitigation of packet-flooding DOS
   attacks, and restriction to trusted clients.

   The use of TCP introduces some additional concerns.  Attacks that
   attempt to exhaust the DHCPv4 server's available TCP connection
   resources, such as SYN flooding attacks, can compromise the ability
   of legitimate clients to receive service.  Malicious clients who
   succeed in establishing connections, but who then send invalid
   queries, partial queries, or no queries at all also can exhaust a
   server's pool of available connections.  We recommend that servers
   offer configuration to limit the sources of incoming connections,
   that they limit the number of accepted connections and the number of
   in-process queries from any one connection, and that they limit the
   period of time during which an idle connection will be left open.
































Rao, et al.              Expires January 2, 2009               [Page 24]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


11.  IANA Considerations

   IANA is requested to assign a new DHCPv4 Option Code in the registry
   maintained in http://www.iana.org/assignments/bootp-dhcp-parameters:

   o  STATUS_CODE

   IANA is requested to assign the following values for the STATUS_CODE
   option maintained in
   http://www.iana.org/assignments/bootp-dhcp-parameters:

   Success          0
   UnspecFail       1
   UnknownQueryType 2
   MalformedQuery   3
   NotAllowed       4
   QueryTerminated  5

   IANA is requested to assign values for the following new DHCPv4
   Message types in the Message Type option (option 53) in the registry
   maintained in http://www.iana.org/assignments/bootp-dhcp-parameters:

   o DHCPLEASEDONE
   o DHCPLEASEDATA
   o DHCPLEASEQUERYFAIL


























Rao, et al.              Expires January 2, 2009               [Page 25]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


12.  Acknowledgments

   The bulk lease query protocol for DHCPv4 described in this draft is
   inspired by the bulk lease query protocol defined for DHCPv6 [8] by
   Mark Stapp and liberally borrows from that draft.  We also use the
   protocol mechanisms proposed in RFC 4388 [5] by R. Woundy and K.
   Kinnear.












































Rao, et al.              Expires January 2, 2009               [Page 26]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


13.  References

13.1.  Normative Reference

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

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

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

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

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

   [6]  Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption",
        IETF draft, June 2008.

   [7]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
        Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
        RFC 31315, July 2003.

13.2.  Informative Reference

   [8]  Stapp, M., "DHCPv6 Bulk Leasequery", IETF draft, June 2008.

   [9]  Kurapati, P., Desetti, R., and B. Joshi, "DHCPv4 Leasequery by
        relay agent remote ID", IETF draft, June 2008.


















Rao, et al.              Expires January 2, 2009               [Page 27]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


1.  Why a New Leasequery is Required?

   The three existing query types supported by RFC 4388 [5] do not
   provide effective and efficient antispoofing for the above scenario.

   o  Query by Client Identifier

   Query by Client Identifier is not possible because to use that DSLAM
   need to glean client identifier also but the whole issue is that we
   need leasequeries because the gleaned information was lost.  On the
   other hand, we can query by client identifier when client sends a
   DHCP request, but then there may not be any need for lease query as
   such -- regular gleaning may be enough.

   o  Query by IP Address

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

   Query by IP address is not very useful in downstream traffic 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
   come.

   Query by IP address may be used for upstream traffic.  Then whenever
   an upstream packet comes whose IP address is unknown to the DSLAM, a
   lease query may be initiated.  A related question is what to do with
   that upstream traffic itself until lease query response comes?  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 comes, subsequent traffic is handled depending on
   the response.  If a DHCPLEASEACTIVE response comes, DSLAM will accept
   the traffic.  If a DHCPLEASEUNASSIGNED response comes, DSLAM will
   drop the traffic corresponding to the IP address.  If a
   DHCPLEASEUNKNOWN response comes DSLAM may drop the traffic
   corresponding to the IP address but will have to periodically send
   the lease query for that IP address again (additional overhead).  The
   process is triggered whenever an unknown IP address comes.

   Note that DSLAM 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



Rao, et al.              Expires January 2, 2009               [Page 28]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


   received.  Consider the case when someone sends packets that uses
   spoofed IP addresses.  In that case, lease response will be
   DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN.  RFC 4388 [5] 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 attacker varies the source IP address.  For each such
   new source IP address, traffic will come to slow path, a new lease
   query needs to be initiated, response will be processed, and negative
   caching to be done.  That will mean using many resources for negative
   caching.

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

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

   RFC 4388 [5] says that DHCP server should be protected from being
   flooded with too many leasequery requests and DSLAM also should not
   send too many lease query messages at a time.  This would mean that
   legitimate clients may be excessively delayed getting their
   information in the face of antispoofing 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 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
   associated-ip option in lease responses (Note that associated-ip
   option does not appear in responses for query by IP address).  With
   associated-ip option DSLAM can get information not only about the IP
   address/MAC address that triggered the lease query but also about
   other IP addresses that are associated with the original MAC address.
   That way, when traffic that uses the other IP addresses comes along,
   DSLAM 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;



Rao, et al.              Expires January 2, 2009               [Page 29]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


   DHCPLEASEUNASSIGNED is not supported.  This is particularly
   troublesome when a DHCP 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 with
   DHCP 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 lease query types are not appropriate to
   achieve effective and efficient antispoofing.






































Rao, et al.              Expires January 2, 2009               [Page 30]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


Authors' Addresses

   Ramakrishna Rao D. T. V.
   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/





















Rao, et al.              Expires January 2, 2009               [Page 31]


Internet-Draft           DHCPv4 Bulk Leasequery                July 2008


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The IETF Trust (2008).  This document is subject to the
   rights, licenses and restrictions contained in BCP 78, and except as
   set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Rao, et al.              Expires January 2, 2009               [Page 32]