draft-ietf-dhc-dhcpv4-bulk-leasequery-00.txt   draft-ietf-dhc-dhcpv4-bulk-leasequery-01.txt 
DHC Working Group Kim Kinnear DHC Working Group Kim Kinnear
Internet Draft Bernie Volz Internet Draft Bernie Volz
Intended Status: Standards Track Neil Russell Intended Status: Standards Track Neil Russell
Expires: August 13, 2009 Mark Stapp Expires: April 26, 2010 Mark Stapp
Cisco Systems, Inc. Cisco Systems, Inc.
D. Rao D. Rao
B. Joshi B. Joshi
P. Kurapati P. Kurapati
Infosys Technologies Ltd. Infosys Technologies Ltd.
February 13, 2009 October 26, 2009
Bulk DHCPv4 Lease Query Bulk DHCPv4 Lease Query
<draft-ietf-dhc-dhcpv4-bulk-leasequery-00.txt> <draft-ietf-dhc-dhcpv4-bulk-leasequery-01.txt>
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2009 This Internet-Draft will expire on April 26, 2010
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. 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 Abstract
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery
extended with a Leasequery capability that allows a requestor to extension allows a requestor to request information about DHCPv4
request information about DHCPv4 bindings. That mechanism is limited bindings. This mechanism is limited to queries for individual
to queries for individual bindings. In some situations individual bindings. In some situations individual binding queries may not be
binding queries may not be efficient, or even possible. This efficient, or even possible. This document extends the DHCPv4
document expands on the DHCPv4 Leasequery protocol to allow for bulk Leasequery protocol to allow for bulk transfer of DHCPv4 address
transfer of DHCPv4 address binding data via TCP. binding data via TCP.
Table of Contents Table of Contents
1. Introduction................................................. 3 1. Introduction................................................. 3
2. Terminology.................................................. 4 2. Terminology.................................................. 4
3. Motivation................................................... 6 3. Design Goals................................................. 6
4. Design Goals................................................. 8 3.1. Information Acquisition before Data Starts................. 7
4.1. Information Acquisition before Data Starts................. 8 3.2. Lessen need for Caching and Negative Caching............... 7
4.2. Lessen need for Caching and Negative Caching............... 8 3.3. Antispoofing in 'Fast Path'................................ 7
4.3. Antispoofing in 'Fast Path'................................ 8 3.4. Minimize data transmission................................. 7
4.4. Minimize data transmission................................. 8 4. Protocol Overview............................................ 8
5. Protocol Overview............................................ 9 5. Interaction Between UDP Leasequery and Bulk Leasequery....... 9
6. Interaction Between UDP Leasequery and Bulk Leasequery....... 10 6. Message and Option Definitions............................... 10
7. Message and Option Definitions............................... 11 6.1. Message Framing for TCP.................................... 10
7.1. Message Framing for TCP.................................... 11 6.2. New or Changed Options..................................... 11
7.2. New or Changed Options..................................... 12 6.3. Connection and Transmission Parameters..................... 19
7.3. Connection and Transmission Parameters..................... 20 7. Requestor Behavior........................................... 19
8. Requestor Behavior........................................... 20 7.1. Connecting and General Processing.......................... 19
8.1. Connecting and General Processing.......................... 20 7.2. Forming a Bulk Leasequery.................................. 20
8.2. Forming a Bulk Leasequery.................................. 21 7.3. Processing Bulk Replies.................................... 22
8.3. Processing Bulk Replies.................................... 23 7.4. Processing Time Values in Leasequery messages.............. 24
8.4. Processing Time Values in Leasequery messages.............. 25 7.5. Querying Multiple Servers.................................. 24
8.5. Querying Multiple Servers.................................. 27 7.6. Making Sense Out of Multiple Responses Concerning a Single. 25
8.6. Making Sense Out of Multiple Responses Concerning a Single. 27 7.7. Multiple Queries to a Single Server over One Connection.... 25
8.7. Multiple Queries to a Single Server over One Connection.... 28 7.8. Closing Connections........................................ 27
8.8. Closing Connections........................................ 29 8. Server Behavior.............................................. 27
9. Server Behavior.............................................. 29 8.1. Accepting Connections...................................... 27
9.1. Accepting Connections...................................... 29 8.2. Replying to a Bulk Leasequery.............................. 28
9.2. Replying to a Bulk Leasequery.............................. 30 8.3. Building a Single Reply for Bulk Leasequery................ 31
9.3. Building a Single Reply for Bulk Leasequery................ 34 8.4. Multiple or Parallel Queries............................... 33
9.4. Multiple or Parallel Queries............................... 35 8.5. Closing Connections........................................ 33
9.5. Closing Connections........................................ 36 9. Security Considerations...................................... 33
10. Security Considerations..................................... 36 10. IANA Considerations......................................... 34
11. IANA Considerations......................................... 36 11. Acknowledgements............................................ 35
12. Acknowledgements............................................ 38
13. References.................................................. 38 12. References.................................................. 35
13.1. Normative References...................................... 38 12.1. Normative References...................................... 35
13.2. Informative References.................................... 39 12.2. Informative References.................................... 36
Authors' Addresses............................................... 39 Authors' Addresses............................................... 37
Appendix -- Why a New Leasequery is Required..................... 41
1. Introduction 1. Introduction
The DHCPv4 protocol [RFC2131] [RFC2132] specifies a mechanism for the The DHCPv4 protocol [RFC2131] [RFC2132] specifies a mechanism for the
assignment of IPv4 address and configuration information to IPv4 assignment of IPv4 address and configuration information to IPv4
nodes. DHCPv4 servers maintain authoritative binding information. nodes. DHCPv4 servers maintain authoritative binding information.
+--------+ +--------+
| DHCPv4 | +--------------+ | DHCPv4 | +--------------+
| Server |-...-| DSLAM | | Server |-...-| DSLAM |
skipping to change at page 3, line 34 skipping to change at page 4, line 23
+------+ +------+ +------+ +------+
| | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|Host1| |Host2| |Host3| |Host1| |Host2| |Host3|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 1: Example DHCPv4 configuration Figure 1: Example DHCPv4 configuration
DHCPv4 relay agents receive DHCPv4 messages and frequently append a DHCPv4 relay agents receive DHCPv4 messages and frequently append a
relay agent information option [RFC3046] before relaying them to the relay agent information option [RFC3046] before relaying them to the
configured DHCPv4 servers (see Figure 1). In this process, some configured DHCPv4 servers (see Figure 1). In this process, some relay
relay agents also glean the lease information sent by the server and agents also glean lease information sent by the server and cache it
maintain this locally. This information is used for a variety of locally. This information is used for a variety of purposes. Two
purposes, including prevention of spoofing attempts from the DHCPv4 examples are prevention of spoofing attempts from the DHCPv4 clients,
clients and to install routes. When a relay agent reboots, this and installation of routes. When a relay agent reboots, this
information is frequently lost. information is frequently lost.
The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4 The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4
capability to allow an external entity, such as a relay agent, to capability to allow an external entity, such as a relay agent, to
query a DHCPv4 server to recover lease state information about a query a DHCPv4 server to recover lease state information about a
particular IP address or client in near real-time. particular IP address or client in near real-time.
The existing query types in Leasequery are typically data driven; the The existing query types in Leasequery are typically data driven; the
relay agent initiates the Leasequery when it receives data traffic relay agent initiates the Leasequery when it receives data traffic
from or to the client. This approach may not scale well when there 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 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 relay agent has a need to rebuild its internal data store prior to
processing traffic in one direction or another. processing traffic in one direction or another.
Different query types are needed where a relay agent can query the Some applications require the ability to query the server without
server without waiting for the traffic from or for the clients, as waiting for traffic from or to clients. This query capability in turn
well as a different transmission technique more conducive to the requires an underlying transport more suitable to the bulk
transmission of large quantities of data. transmission of data.
This document extends the DHCPv4 Leasequery protocol to add support This document extends the DHCPv4 Leasequery protocol to add support
for queries that address these additional requirements. There may be for queries that address these additional requirements. There may be
many thousands of DHCPv4 bindings returned as the result of a single many thousands of DHCPv4 bindings returned as the result of a single
request, so TCP [RFC4614] is specified for efficiency of data request, so TCP [RFC4614] is specified for efficiency of data
transfer. We define several additional query types, each of which transfer. We define several additional query types, each of which
could return multiple responses, in order to meet a variety of could return multiple responses, in order to meet a variety of
requirements. requirements.
2. Terminology 2. Terminology
skipping to change at page 6, line 45 skipping to change at page 7, line 32
network element. DHCPv4 servers are typically expected to have network element. DHCPv4 servers are typically expected to have
high speed access to stable storage, while relay agents and high speed access to stable storage, while relay agents and
access concentrators usually do not have access to stable access concentrators usually do not have access to stable
storage, although they may have periodic access to such storage. storage, although they may have periodic access to such storage.
o "xid" o "xid"
Transaction-id. The term "xid" refers to the DHCPv4 field Transaction-id. The term "xid" refers to the DHCPv4 field
containing the transaction-id of the message. containing the transaction-id of the message.
3. Motivation 3. Design Goals
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 is
done in a network processor or in 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 the 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 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 to its DHCPv4
clients.
The DSLAM gleans 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 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 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 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 The goal of this document is to provide a lightweight mechanism for
an Access Concentrator or other network element to retrieve IP an Access Concentrator or other network element to retrieve IP
address binding information available in the DHCPv4 server. The address binding information available in the DHCPv4 server. The
mechanism should also allow an Access Concentrator to retrieve mechanism should also allow an Access Concentrator to retrieve
consolidated IP address binding information for either the entire consolidated IP address binding information for either the entire
access concentrator or a single connection/circuit. access concentrator or a single connection/circuit.
4.1. Information Acquisition before Data Starts 3.1. Information Acquisition before Data Starts
The existing data driven approach required by [RFC4388] means that The existing data driven approach required by [RFC4388] means that
the Leasequeries can only be performed after an Access Concentrator the Leasequeries can only be performed after an Access Concentrator
receives data. To implement antispoofing, packets need to be dropped receives data. To implement antispoofing, the concentrator must drop
until it gets the lease information from DHCPv4 server. If an Access packets for each client until it gets lease information from DHCPv4
Concentrator finishes the Leasequeries before it starts receiving server for that client. If an Access Concentrator finishes the
data, then there is no need to drop legitimate packets. In this way, Leasequeries before it starts receiving data, then there is no need
outage time may be reduced. to drop legitimate packets. In this way, outage time may be reduced.
4.2. Lessen need for Caching and Negative Caching 3.2. Lessen need for Caching and Negative Caching
The result of a single Leasequery should be cached, whether that The result of a single Leasequery should be cached, whether that
results in a positive or negative cache, in order to remember that results in a positive or negative cache, in order to remember that
the Leasequery was performed. This caching is required to limit the the Leasequery was performed. This caching is required to limit the
traffic imposed upon a DHCPv4 server by Leasequeries for information traffic imposed upon a DHCPv4 server by Leasequeries for information
already received. already received.
These caches not only consume precious resources, they also need to These caches not only consume precious resources, they also need to
be managed. Hence they should be avoided as much as possible. be managed. Hence they should be avoided as much as possible.
4.3. Antispoofing in 'Fast Path' 3.3. Antispoofing in 'Fast Path'
If Antispoofing is not done in the fast path, it will become a If Antispoofing is not done in the fast path, it will become a
bottleneck and may lead to denial of service of the access bottleneck and may lead to denial of service of the access
concentrator. The Leasequeries should make it possible to do concentrator. The Leasequeries should make it possible to do
antispoofing in the fast path. antispoofing in the fast path.
4.4. Minimize data transmission 3.4. Minimize data transmission
It may be that a network element is able to periodically save its 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. 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 In this case, it will wish to recover all of the updates to this
information without duplicating the information it has recovered from information without duplicating the information it has recovered from
its own stable storage. its own stable storage.
Bulk Leasequery allows the specification of a query-start-time as Bulk Leasequery allows the specification of a query-start-time as
well as a query-end-time. Use of query-times allows a network well as a query-end-time. Use of query-times allows a network
element that periodically commits information to stable storage to element that periodically commits information to stable storage to
recover just what it lost since the last commit. recover just what it lost since the last commit.
5. Protocol Overview 4. Protocol Overview
The Bulk Leasequery mechanism is modeled on the existing individual The Bulk Leasequery mechanism is modeled on the existing individual
Leasequery protocol in [RFC4388] as well as related work on DHCPv6 Leasequery protocol in [RFC4388] as well as related work on DHCPv6
Bulk Leasequery [DHCPv6Bulk]. A Bulk Leasequery requestor opens a TCP Bulk Leasequery [RFC5460]. A Bulk Leasequery requestor opens a TCP
connection to a DHCPv4 Server, using the DHCPv4 port 67. Note that connection to a DHCPv4 Server, using the DHCPv4 port 67. Note that
this implies that the Leasequery requestor has server IP address(es) this implies that the Leasequery requestor has server IP address(es)
available via configuration or some other means, and that it has available via configuration or some other means, and that it has
unicast IP reachability to the DHCPv4 server. No relaying of Bulk unicast IP reachability to the DHCPv4 server. No relaying of Bulk
Leasequery messages is specified. Leasequery messages is specified.
After establishing a connection, the requestor sends a After establishing a connection, the requestor sends a
DHCPBULKLEASEQUERY message over the connection. DHCPBULKLEASEQUERY message over the connection.
The server uses the message type and additional data in the DHCPv4 The server uses the message type and additional data in the DHCPv4
skipping to change at page 10, line 42 skipping to change at page 10, line 21
used as qualifiers, they indicate that a binding should be included 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 if it changed on or after the query-start-time and on or before the
query-end-time. query-end-time.
In addition, any of the above queries can be qualified by the 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 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 the query should be processed. The vpn-id option is also extended to
allow queries across all available VPNs. By default, only the default allow queries across all available VPNs. By default, only the default
VPN is used to satisfy the query. VPN is used to satisfy the query.
6. Interaction Between UDP Leasequery and Bulk Leasequery 5. Interaction Between UDP Leasequery and Bulk Leasequery
Bulk Leasequery can be seen as an extension of the existing UDP Bulk Leasequery can be seen as an extension of the existing UDP
Leasequery protocol [RFC4388]. This section clarifies the Leasequery protocol [RFC4388]. This section clarifies the
relationship between the two protocols. relationship between the two protocols.
Only the DHCPBULKLEASEQUERY request is supported over the Bulk Only the DHCPBULKLEASEQUERY request is supported over the Bulk
Leasequery connection. No other DHCPv4 requests are supported. The Leasequery connection. No other DHCPv4 requests are supported. The
Bulk Leasequery connection is not an alternative DHCPv4 communication Bulk Leasequery connection is not an alternative DHCPv4 communication
option for clients seeking other DHCPv4 services. option for clients seeking other DHCPv4 services.
skipping to change at page 11, line 24 skipping to change at page 10, line 50
One change in behavior for these existing queries is required when One change in behavior for these existing queries is required when
Bulk Leasequery is used. [RFC4388], in sections 6.1, 6.4.1, and 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 6.4.2 specifies the use of an associated-ip option in DHCPLEASEACTIVE
messages in cases where multiple bindings were found. When Bulk messages in cases where multiple bindings were found. When Bulk
Leasequery is used, this mechanism is not necessary; a server Leasequery is used, this mechanism is not necessary; a server
returning multiple bindings simply does so directly as specified in returning multiple bindings simply does so directly as specified in
this document. The associated-ip option MUST NOT appear in Bulk this document. The associated-ip option MUST NOT appear in Bulk
Leasequery replies. Leasequery replies.
Implementors should note that the TCP message framing defined in Implementors should note that the TCP message framing defined in
Section 5.1 is not compatible with the UDP message format. If a TCP- Section 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 framed request is sent as a UDP message, it may not be valid, because
protocol fields will be offset by the message-size prefix. protocol fields will be offset by the message-size prefix.
7. Message and Option Definitions 6. Message and Option Definitions
7.1. Message Framing for TCP 6.1. Message Framing for TCP
The use of TCP for the Bulk Leasequery protocol permits multiple The use of TCP for the Bulk Leasequery protocol permits multiple
messages to be sent from one end of the connection to the other messages to be sent from one end of the connection to the other
without requiring a request/response paradigm as does UDP DHCPv4 without requiring a request/response paradigm as does UDP DHCPv4
[RFC2131]. The receiver needs to be able to determine the size of [RFC2131]. The receiver needs to be able to determine the size of
each message it receives. Two octets containing the message size in each message it receives. Two octets containing the message size in
network byte-order are prepended to each DHCPv4 message sent on a network byte-order are prepended to each DHCPv4 message sent on a
Bulk Leasequery TCP connection. The two message-size octets 'frame' Bulk Leasequery TCP connection. The two message-size octets 'frame'
each DHCPv4 message. each DHCPv4 message.
skipping to change at page 12, line 33 skipping to change at page 12, line 8
All other fields are as specified in DHCPv4 [RFC2131]. All other fields are as specified in DHCPv4 [RFC2131].
Figure 2: Format of a DHCPv4 message in TCP Figure 2: Format of a DHCPv4 message in TCP
The intent in using this format is that code which currently knows The intent in using this format is that code which currently knows
how to deal with sending or receiving a message in [RFC2131] format 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 will easily be able to deal with the message contained in the TCP
framing. framing.
7.2. New or Changed Options 6.2. New or Changed Options
The existing messages DHCPLEASEUNASSIGNED and DHCPLEASEACTIVE are The existing messages DHCPLEASEUNASSIGNED and DHCPLEASEACTIVE are
used as the value of the dhcp-message-type option to indicate an IP 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 address which is currently not leased or currently leased to a DHCPv4
client, respectively [RFC4388]. client, respectively [RFC4388].
Additional options have also been defined to enable the Bulk Additional options have also been defined to enable the Bulk
Leasequery protocol to communicate useful information to the Leasequery protocol to communicate useful information to the
requestor. requestor.
7.2.1. dhcp-message-type 6.2.1. dhcp-message-type
The dhcp-message-type option (option 53) from Section 9.6 of The dhcp-message-type option (option 53) from Section 9.6 of
[RFC2132] requires new values. The values of these message types are [RFC2132] requires new values. The values of these message types are
shown below in an extension of the table from Section 9.6 of shown below in an extension of the table from Section 9.6 of
[RFC2132]: [RFC2132]:
Value Message Type Value Message Type
----- ------------ ----- ------------
14 DHCPBULKLEASEQUERY 14 DHCPBULKLEASEQUERY
15 DHCPLEASEQUERYDONE 15 DHCPLEASEQUERYDONE
7.2.2. dhcp-message 6.2.2. dhcp-message
The dhcp-message option (option 56) from Section 9.9 of [RFC2132] The dhcp-message option (option 56) from Section 9.9 of [RFC2132]
requires additional definition for use in the context of a requires additional definition for use in the context of a
DHCPBULKLEASEQUERY. DHCPBULKLEASEQUERY.
The format of the NVT ASCII message in the dhcp-message option is The format of the NVT ASCII message in the dhcp-message option is
specified to have the first three characters appear in a constrained specified to have the first three characters appear in a constrained
format. The first three characters MUST be numeric (base 10) format. The first three characters MUST be numeric (base 10)
characters. characters.
skipping to change at page 15, line 5 skipping to change at page 14, line 28
NotAllowed 004 The query or request was understood but was NotAllowed 004 The query or request was understood but was
not allowed in this context. not allowed in this context.
A dhcp-message option MAY appear in the options field of a DHCPv4 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 message. If the dhcp-message option does not appear, it is assumed
that the operation was successful. The dhcp-message option SHOULD that the operation was successful. The dhcp-message option SHOULD
NOT appear in a message which is successful unless there is some text NOT appear in a message which is successful unless there is some text
string that needs to be communicated to the requestor. string that needs to be communicated to the requestor.
7.2.3. base-time 6.2.3. base-time
The base-time option is the current time the message was created to 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. 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 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- the reply message are relative to this time, including the dhcp-
lease-time [RFC2132] and client-last-transaction-time [RFC4388]. lease-time [RFC2132] and client-last-transaction-time [RFC4388].
This time is in the context of the DHCPv4 server. This time is in the context of the DHCPv4 server.
This is an integer in network byte order. This is an integer in network byte order.
The code for this option is TBD1. The length of this option is 4 The code for this option is TBD1. The length of this option is 4
octets. octets.
DHCPv4 Server DHCPv4 Server
Code Len Base Time Code Len Base Time
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD1| 4 | t1 | t2 | t3 | t4 | | TBD1| 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
7.2.4. start-time-of-state 6.2.4. start-time-of-state
The start-time-of-state option allows the receiver to determine the The start-time-of-state option allows the receiver to determine the
time at which the IP address transitioned into its current state. time at which the IP address made the transition into its current
state.
This MUST NOT be an absolute time. This MUST NOT be an absolute 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 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 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 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 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 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 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 option encodes a value which is a number of seconds into the past
from the base-time option included in the same message. from the base-time option included in the same message.
skipping to change at page 16, line 5 skipping to change at page 15, line 32
The code for this option is TBD2. The length of this option is 4 The code for this option is TBD2. The length of this option is 4
octets. octets.
Seconds in the past Seconds in the past
Code Len from base-time Code Len from base-time
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD2| 4 | t1 | t2 | t3 | t4 | | TBD2| 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
7.2.5. query-start-time 6.2.5. query-start-time
The query-start-time option allows the requestor to specify a start The query-start-time option specifies a start query time to the
query time to the DHCPv4 server. If specified, only bindings that DHCPv4 server. If specified, only bindings that have changed on or
have changed on or after the query-start-time should be included in after the query-start-time should be included in the response to the
the response to the query. query.
This MUST be an absolute time. The requester MUST compute the query-start-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 a time in the context of the DHCPv4 server. In the Typically (though this is not a requirement) the query-start-time
absence of information to the contrary, the requestor SHOULD assume option will contain the value most recently received in a base-time
that the time context of the DHCPv4 server is identical to the time option by the requestor, as this will indicate the last successful
context of the requestor. communication with the DHCP server.
It SHOULD NOT be a time in the context of the requestor. This MUST be an absolute time.
This is an integer in network byte order. This is an integer in network byte order.
The code for this option is TBD3. The length of this option is 4 The code for this option is TBD3. The length of this option is 4
octets. octets.
DHCPv4 Server DHCPv4 Server
Code Len query-start-time Code Len query-start-time
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD3| 4 | t1 | t2 | t3 | t4 | | TBD3| 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
7.2.6. query-end-time 6.2.6. query-end-time
The query-end-time option allows the requestor to specify an end The query-end-time option specifies an end query time to the DHCPv4
query time to the DHCPv4 server. If specified, only bindings that server. If specified, only bindings that have changed on or before
have changed on or before the query-end-time should be included in the query-end-time should be included in the response to the query.
the response to the query.
The requester MUST compute the 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 an absolute time.
This MUST be a time in the context of the DHCPv4 server. In the This MUST be a time in the context of the DHCPv4 server. In the
absence of information to the contrary, the requestor SHOULD assume absence of information to the contrary, the requestor SHOULD assume
that the time context of the DHCPv4 server is identical to the time that the time context of the DHCPv4 server is identical to the time
context of the requestor. context of the requestor.
It SHOULD NOT be a time in the context of the requestor. It SHOULD NOT be a time in the context of the requestor.
skipping to change at page 17, line 11 skipping to change at page 16, line 44
The code for this option is TBD4. The length of this option is 4 The code for this option is TBD4. The length of this option is 4
octets. octets.
DHCPv4 Server DHCPv4 Server
Code Len query-end-time Code Len query-end-time
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD4| 4 | t1 | t2 | t3 | t4 | | TBD4| 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
7.2.7. dhcp-state 6.2.7. dhcp-state
The dhcp-state option allows greater detail to be returned than The dhcp-state option allows greater detail to be returned than
allowed by the DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types. allowed by the DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types.
The code for this option is TBD6. The length of this option is 1 The code for this option is TBD6. The length of this option is 1
octet. octet.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 26 skipping to change at page 18, line 12
IP address during this period, it SHOULD use the TRANSITIONING state, IP address during this period, it SHOULD use the TRANSITIONING state,
since the IP address is likely to be neither ACTIVE or AVAILABLE. 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 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, 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 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 IP address and the requestor of a Leasequery MUST NOT depend on one
certain state always following a particular previous state. In certain state always following a particular previous state. In
general, every state can (at times) follow every other state. general, every state can (at times) follow every other state.
7.2.8. data-source 6.2.8. data-source
The data-source option contains information about the source of the The data-source option contains information about the source of the
data in a DHCPLEASEACTIVE or a DHCPLEASEUNASSIGNED message. It is data in a DHCPLEASEACTIVE or a DHCPLEASEUNASSIGNED message. It is
used when there are two or more servers who might have information used when there are two or more servers who might have information
about a particular IP address binding. Frequently two servers work about a particular IP address binding. Frequently two servers work
together to provide an increased availability solution for the DHCPv4 together to provide an increased availability solution for the DHCPv4
service, and in these cases, both servers will respond to Bulk service, and in these cases, both servers will respond to Bulk
Leasequery requests for the same IP address. Leasequery requests for the same IP address.
The data contained in this option will allow an external process to The data contained in this option will allow an external process to
skipping to change at page 19, line 39 skipping to change at page 19, line 15
The REMOTE flag is used to indicate where the most recent change of The REMOTE flag is used to indicate where the most recent change of
state (or other interesting change) concerning this IPv4 address took state (or other interesting change) concerning this IPv4 address took
place. If the value is local, then the change took place on the place. If the value is local, then the change took place on the
server from which this message was transmitted. If the value is server from which this message was transmitted. If the value is
remote, then the change took place on some other server, and was made remote, then the change took place on some other server, and was made
known to the server from which this message was transmitted. known to the server from which this message was transmitted.
If this option was requested and it doesn't appear, the the requestor If this option was requested and it doesn't appear, the the requestor
SHOULD consider that the data-source was local. SHOULD consider that the data-source was local.
7.2.9. Virtual Subnet Selection Type and Information 6.2.9. Virtual Subnet Selection Type and Information
All of the (sub)options defined in [VpnId] carry identical payloads, All of the (sub)options defined in [VpnId] carry identical payloads,
consisting of a type and additional VSS (Virtual Subnet Selection) consisting of a type and additional VSS (Virtual Subnet Selection)
information. The existing table is extended (see below) with a new information. The existing table is extended (see below) with a new
type 254 to allow specification of a type code which indicates that type 254 to allow specification of a type code which indicates that
all VPN's are to be used to process the Bulk Leasequery. all VPN's are to be used to process the Bulk Leasequery.
Type VSS Information format: Type VSS Information format:
---- ----------------------- ---- -----------------------
0 NVT ASCII VPN identifier 0 NVT ASCII VPN identifier
1 RFC2685 VPN-ID 1 RFC2685 VPN-ID
2-253 Not Allowed 2-253 Not Allowed
NEW -> 254 All VPN's (wildcard). NEW -> 254 All VPN's (wildcard).
255 Global, default VPN. 255 Global, default VPN.
7.3. Connection and Transmission Parameters 6.3. Connection and Transmission Parameters
DHCPv4 servers that support Bulk Leasequery SHOULD listen for DHCPv4 servers that support Bulk Leasequery SHOULD listen for
incoming TCP connections on the DHCPv4 server port 67. incoming TCP connections on the DHCPv4 server port 67.
Implementations MAY offer to make the incoming port configurable, but Implementations MAY offer to make the incoming port configurable, but
port 67 MUST be the default. Requestors SHOULD make TCP connections port 67 MUST be the default. Requestors SHOULD make TCP connections
to port 67, and MAY offer to make the destination server port to port 67, and MAY offer to make the destination server port
configurable. configurable.
This section presents a table of values used to control Bulk This section presents a table of values used to control Bulk
Leasequery behavior, including recommended defaults. Implementations Leasequery behavior, including recommended defaults. Implementations
MAY make these values configurable. However, configuring too-small MAY make these values configurable. However, configuring too-small
timeout values may lead to harmful behavior both to this application timeout values may lead to harmful behavior both to this application
as well as to other traffic in the network. As a result, timeout as well as to other traffic in the network. As a result, timeout
values smaller than the default values are NOT RECOMMENDED. values smaller than the default values are NOT RECOMMENDED.
Parameter Default Description Parameter Default Description
------------------------------------------- -------------------------------------------
BULK_LQ_DATA_TIMEOUT 300 secs Bulk Leasequery data timeout BULK_LQ_DATA_TIMEOUT 300 secs Bulk Leasequery data timeout
BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections
8. Requestor Behavior 7. Requestor Behavior
8.1. Connecting and General Processing 7.1. Connecting and General Processing
A Requestor attempts to establish a TCP connection to a DHCPv4 Server A Requestor attempts to establish a TCP connection to a DHCPv4 Server
in order to initiate a Leasequery exchange. If the attempt fails, in order to initiate a Leasequery exchange. If the attempt fails,
the Requestor MAY retry. the Requestor MAY retry.
If Bulk Leasequery is terminated prematurely by a DHCPLEASEQUERYDONE If Bulk Leasequery is terminated prematurely by a DHCPLEASEQUERYDONE
with a dhcp-message status-code of QueryTerminated or by the failure with a dhcp-message status-code of QueryTerminated or by the failure
of the connection over which it was being submitted, the requestor of the connection over which it was being submitted, the requestor
MAY retry the request after the creation of a new connection. MAY retry the request after the creation of a new connection.
Messages from the DHCPv4 server come as multiple responses to a Messages from the DHCPv4 server come as multiple responses to a
single DHCPBULKLEASEQUERY message. Thus, each DHCPBULKLEASEQUERY single DHCPBULKLEASEQUERY message. Thus, each DHCPBULKLEASEQUERY
request MUST have a xid (transaction-id) unique on the connection on request MUST have a xid (transaction-id) unique on the connection on
which it is sent, and all of the messages which come as a response to which it is sent. All of the messages which come as a response to
it all contain the same xid as the request. It is the xid which that message will contain the same xid as the request. It is the xid
allows the data-streams of two different DHCPBULKLEASEQUERY requests which allows the data-streams of two different DHCPBULKLEASEQUERY
to be demultiplexed by the requestor. 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. Forming a Bulk Leasequery 7.2. Forming a Bulk Leasequery
Bulk Leasequery is designed to create a connection which will Bulk Leasequery is designed to create a connection which will
transfer the state of some subset (or possibly all) of the IP address transfer the state of some subset (or possibly all) of the IP address
bindings from the DHCPv4 server to the requestor. The DHCPv4 server bindings from the DHCPv4 server to the requestor. The DHCPv4 server
will send all of the requested IPv4 address bindings across this will send all of the requested IPv4 address bindings across this
connection with minimal delay after it receives the request. In this connection with minimal delay after it receives the request. In this
context, "all IP address binding information" means information about context, "all IP address binding information" means information about
all IPv4 addresses configured within the DHCPv4 server which meet the all IPv4 addresses configured within the DHCPv4 server which meet the
specified query criteria. For some query criteria, this may include specified query criteria. For some query criteria, this may include
IP address binding information for IP addresses which may not now IP address binding information for IP addresses which may not now
skipping to change at page 23, line 10 skipping to change at page 22, line 26
requestor to specify a single VPN other than the default VPN. In requestor to specify a single VPN other than the default VPN. In
addition, the vpn-id option has been extended as part of this addition, the vpn-id option has been extended as part of this
document to allow specification that all configured VPN's be document to allow specification that all configured VPN's be
searched in order to satisfy the query specified in the searched in order to satisfy the query specified in the
DHCPBULKLEASEQUERY. DHCPBULKLEASEQUERY.
In all cases, any message returned from a DHCPBULKLEASEQUERY In all cases, any message returned from a DHCPBULKLEASEQUERY
request containing information about an IP address for other than request containing information about an IP address for other than
the default VPN MUST contain a vpn-id option in the message. 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 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 serve to reduce the amount of data transferred over the TCP
connection by a considerable amount. connection by a considerable amount.
If the TCP connection becomes blocked or stops being writeable while The TCP connection may become blocked or stop being writable while
the requestor is sending its query, the requestor SHOULD be prepared the requestor is sending its query. Should this happen, the
to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this implementation's behavior is controlled the current value of
recommendation to allow requestors to control the period of time they BULK_LQ_DATA_TIMEOUT. The default value is given elsewhere in this
are willing to wait before abandoning a connection, independent of document, and this value may be overridden by local configuration of
notifications from the TCP implementations they may be using. the operator.
8.3. Processing Bulk Replies 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.
7.3. Processing Bulk Replies
The requestor attempts to read a DHCPv4 Leasequery message from the The requestor attempts to read a DHCPv4 Leasequery message from the
TCP connection. If the TCP connection stops delivering reply data (if TCP connection.
the connection stops being readable), the Requestor SHOULD be
prepared to terminate the connection after BULK_LQ_DATA_TIMEOUT, and The TCP connection may stop delivering reply data (i.e., the
MAY begin retry processing if configured to do so. connection stops being readable). Should this happen, the
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 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.
A single Bulk Leasequery can and usually will result in a large A single Bulk Leasequery can and usually will result in a large
number of replies. The requestor MUST be prepared to receive more number of replies. The requestor MUST be prepared to receive more
than one reply with an xid matching a single DHCPBULKLEASEQUERY than one reply with an xid matching a single DHCPBULKLEASEQUERY
message from a single DHCPv4 server. If the xid in the received message from a single DHCPv4 server. If the xid in the received
message does not match an outstanding DHCPBULKLEASEQUERY message, the message does not match an outstanding DHCPBULKLEASEQUERY message, the
requestor MUST close the TCP connection. requestor MUST close the TCP connection.
If a response message does not contain a DHCPv4 server-identifier The DHCPv4 server MUST send a server-identifier option (option 54) in
option (option 54), then the server-identifier option from the the first response to any DHCPBULKLEASEQUERY message. The DHCPv4
previous message should be used. Thus, the DHCPv4 server MUST send server SHOULD NOT send server identifier options in subsequent
the server-identifier option in the first response message, and MAY responses to that DHCPBULKLEASEQUERY message. The requester MUST
send it in subsequent response message for the same request. cache the server-identifier option from the first response and apply
it to any subsequent responses.
The response messages generated by a DHCPBULKLEASEQUERY request are: The response messages generated by a DHCPBULKLEASEQUERY request are:
o DHCPLEASEACTIVE o DHCPLEASEACTIVE
A Bulk Leasequery will generate DHCPLEASEACTIVE messages A Bulk Leasequery will generate DHCPLEASEACTIVE messages
containing binding data for bound IP addresses which match the containing binding data for bound IP addresses which match the
specified query criteria. The IP address which is bound to a specified query criteria. The IP address which is bound to a
DHCPv4 client will appear in the ciaddr field of the DHCPv4 client will appear in the ciaddr field of the
DHCPLEASEACTIVE message. The message may contain a non-zero DHCPLEASEACTIVE message. The message may contain a non-zero
skipping to change at page 25, line 19 skipping to change at page 24, line 37
DHCPLEASEQUERYDONE from a server, the requestor MAY close the TCP DHCPLEASEQUERYDONE from a server, the requestor MAY close the TCP
connection to that server if no other DHCPBULKLEASEQUERY is connection to that server if no other DHCPBULKLEASEQUERY is
outstanding on that TCP connection. outstanding on that TCP connection.
The DHCPv4 Leasequery protocol [RFC4388] uses the associated-ip The DHCPv4 Leasequery protocol [RFC4388] uses the associated-ip
option as an indicator that multiple bindings were present in option as an indicator that multiple bindings were present in
response to a single DHCPv4 client based query. For Bulk Leasequery, response to a single DHCPv4 client based query. For Bulk Leasequery,
a separate message is returned for each binding, and so the a separate message is returned for each binding, and so the
associated-ip option is not used. associated-ip option is not used.
8.4. Processing Time Values in Leasequery messages 7.4. Processing Time Values in Leasequery messages
Bulk Leasequery requests may be made to a DHCPv4 server whose Bulk Leasequery requests may be made to a DHCPv4 server whose
absolute time may not be synchronized with the local time of the absolute time may not be synchronized with the local time of the
requestor. Thus, there are at least two time contexts in even the requestor. Thus, there are at least two time contexts in even the
simplest Bulk Leasequery response, and in the situation where simplest Bulk Leasequery response, and in the situation where
multiple DHCPv4 servers are queried, the situation becomes even more multiple DHCPv4 servers are queried, the situation becomes even more
complex. complex.
If the requestor of a Bulk Leasequery is saving the data returned in 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, some form, it has a requirement to store a variety of time values,
skipping to change at page 25, line 46 skipping to change at page 25, line 16
DHCPv4 server. As such, it is an ideal time to save and use as input 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 to a DHCPBULKLEASEQUERY in the query-start-time or query-end-time
options, should the requestor need to ever issue a DHCPBULKLEASEQUERY options, should the requestor need to ever issue a DHCPBULKLEASEQUERY
message using those options as part of a later query. message using those options as part of a later query.
In addition to saving the base-time for possible future use in a 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 query-start-time option, the base-time is used as part of the
conversion of the other times in the Leasequery message to values conversion of the other times in the Leasequery message to values
which are meaningful in the context of the requestor. which are meaningful in the context of the requestor.
The requestor SHOULD use the base-time values received in Bulk In systems whose clocks are synchronized, perhaps using NTP, the
Leasequery messages to develop a value which represents the clock clock skew will usually be zero, which is not only acceptable, but
skew between the DHCPv4 server and the requestor. In theory this desired.
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 requestor SHOULD smooth the value which it uses as the clock skew
by continuously examining the instantaneous value developed from the
base-time of each message received from a DHCPv4 server and using
this instantaneous value of clock skew to make small adjustments to
the existing value of the clock skew. Thus, the clock skew will vary
only slowly and one slow message will not completely distort a large
number of future time calculations.
Given the value of the clock skew on the requestor, the requestor
SHOULD bring all of the times in the DHCPLEASEACTIVE and
DHCPLEASEUNASSIGNED messages into the context of the requestor.
Except for the base-time value, the times in the Leasequery message
are all relative to the base-time. These relative times SHOULD first
be converted into absolute times in the context of the DHCPv4 server
using the base-time value. Once this stage is complete, the absolute
times that result SHOULD be brought into the context of the requestor
by applying the calculated clock skew to each of the absolute times.
After all of this processing, the times are in the context of the
requestor.
An alternative might appear to be to leave all of the times in the
context of the DHCPv4 server, and if the requestor is dealing with
only one DHCPv4 server at a time, this is an accurate and effective
approach. However, if the requestor is dealing with DHCPLEASEACTIVE
and DHCPLEASEUNASSIGNED messages from two or more different DHCPv4
servers, then in order 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 to only a few
seconds, at best. This is rarely an issue in the larger context of
the use of the information derived from a Bulk Leasequery request.
However, time comparison is an important factor in determining which
update to the address binding information for a particular IPv4
address is the most recent and therefore worth remembering. The next
section discusses the issue of comparing two updates in some detail,
but a key aspect of that comparison is a comparison 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 be considered the
same for purposes of comparison with each other.
8.5. Querying Multiple Servers 7.5. Querying Multiple Servers
A Bulk Leasequery requestor MAY be configured to attempt to connect A Bulk Leasequery requestor MAY be configured to attempt to connect
to and query from multiple DHCPv4 servers in parallel. The DHCPv4 to and query from multiple DHCPv4 servers in parallel. The DHCPv4
Leasequery specification [RFC4388] includes a discussion about Leasequery specification [RFC4388] includes a discussion about
reconciling binding data received from multiple DHCPv4 servers. reconciling binding data received from multiple DHCPv4 servers.
In addition, the algorithm in the Section 8.6 should be used. In addition, the algorithm in the Section 7.6 should be used.
8.6. Making Sense Out of Multiple Responses Concerning a Single IPv4 7.6. Making Sense Out of Multiple Responses Concerning a Single IPv4
Address Address
Any requestor of an Bulk Leasequery MUST be prepared for multiple Any requestor of an Bulk Leasequery MUST be prepared for multiple
responses to arrive for a particular IPv4 address from multiple responses to arrive for a particular IPv4 address from multiple
different DHCPv4 servers. The following algorithm SHOULD be used to different DHCPv4 servers. The following algorithm SHOULD be used to
decide if the information just received is more up to date (i.e., decide if the information just received is more up to date (i.e.,
better) than the best existing information. In the discussion below, better) than the best existing information. In the discussion below,
the information that is received from a DHCPv4 server about a the information that is received from a DHCPv4 server about a
particular IPv4 address is termed a "record". The times used in the particular IPv4 address is termed a "record". The times used in the
algorithm below SHOULD have been converted into the requestor's algorithm below SHOULD have been converted into the requestor's
context and the time comparisons SHOULD be performed in a manner context and the time comparisons SHOULD be performed in a manner
consistent with the information in Section 8.4. consistent with the information in Section 7.4.
o If both the existing and the new record contain client-last- o If both the existing and the new record contain client-last-
transaction-time information, the record with the later client- transaction-time information, the record with the later client-
last-transaction-time is considered better. last-transaction-time is considered better.
o If one of the records contains client-last-transaction-time o If one of the records contains client-last-transaction-time
information and the other one doesn't, then compare the client- information and the other one doesn't, then compare the client-
last-transaction-time in the record that contains it against the last-transaction-time in the record that contains it against the
other record's start-time-of-state. The record with the later other record's start-time-of-state. The record with the later
time is considered better. time is considered better.
skipping to change at page 28, line 15 skipping to change at page 26, line 23
If the values of the REMOTE flag are different between the two If the values of the REMOTE flag are different between the two
records, the record with the REMOTE flag value of local is records, the record with the REMOTE flag value of local is
considered better. considered better.
The above algorithm does not necessarily determine which record is The above algorithm does not necessarily determine which record is
better. In the event that the algorithm is inconclusive with regard better. In the event that the algorithm is inconclusive with regard
to a record which was just received by the requestor, the requestor to a record which was just received by the requestor, the requestor
SHOULD use additional information in the two records to make a SHOULD use additional information in the two records to make a
determination as to which record is better. determination as to which record is better.
8.7. Multiple Queries to a Single Server over One Connection 7.7. Multiple Queries to a Single Server over One Connection
Bulk Leasequery requestors may need to make multiple queries in order Bulk Leasequery requestors may need to make multiple queries in order
to recover binding information. A requestor MAY use a single to recover binding information. A requestor MAY use a single
connection to issue multiple queries to a server willing to support connection to issue multiple queries to a server willing to support
them. Each query MUST have a unique xid. them. Each query MUST have a unique xid.
A server MAY process more than one query at a time. A server that A server SHOULD allow configuration of the number of queries that can
does not support more than one query at a time on a single connection be processed simultaneously over a single connection. A server
MUST return a DHCPLEASEQUERYDONE message containing a dhcp-message SHOULD read the number of queries it is configured to process
option with a status-code of NotAllowed to the unsupported queries. simultaneously and only read any subsequent queries as current
Alternatively, a server that does not support more than one query at queries are processed.
a time on a single connection MAY chose to simply read one query and
only read any subsequent queries after processing of the current
query is complete.
A server that is willing to do so MAY interleave replies to the A server that is processing multiple queries simultaneously MUST
multiple queries within the stream of reply messages it sends. interleave replies to the multiple queries within the stream of reply
Requestors need to be aware that replies for multiple queries may be messages it sends. Requestors need to be aware that replies for
interleaved within the stream of reply messages. Requestors that are multiple queries may be interleaved within the stream of reply
not able to process interleaved replies (based on xid) MUST NOT send messages. Requestors that are not able to process interleaved
more than one query over a single connection prior to the completion replies (based on xid) MUST NOT send more than one query over a
of the previous query. Requestors should be aware that servers are single connection prior to the completion of the previous query.
not required to process more than one query over a connection at a
time, and that servers are likely to limit the rate at which they
process queries from any one requestor.
8.7.1. Example Requestors should be aware that servers are not required to process
more than one query over a connection at a time (the limiting case
for the configuration described above), and that servers are likely
to limit the rate at which they process queries from any one
requestor.
7.7.1. Example
This example illustrates what a series of queries and responses might This example illustrates what a series of queries and responses might
look like. This is only an example - there is no requirement that look like. This is only an example - there is no requirement that
this sequence must be followed, or that requestors or servers must this sequence must be followed, or that requestors or servers must
support parallel queries. support parallel queries.
In the example session, the client sends four queries after In the example session, the client sends four queries after
establishing a connection. Query 1 returns no results; query 2 establishing a connection. Query 1 returns no results; query 2
returns 3 messages and the stream of replies concludes before the returns 3 messages and the stream of replies concludes before the
client issues any new query. Query 3 and query 4 overlap, and the client issues any new query. Query 3 and query 4 overlap, and the
skipping to change at page 29, line 29 skipping to change at page 27, line 40
<----- DHCPLEASEACTIVE xid 4 <----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEACTIVE xid 3 <----- DHCPLEASEACTIVE xid 3
<----- DHCPLEASEACTIVE xid 4 <----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEUNASSIGNED xid 3 <----- DHCPLEASEUNASSIGNED xid 3
<----- DHCPLEASEACTIVE xid 4 <----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEACTIVE xid 3 <----- DHCPLEASEACTIVE xid 3
<----- DHCPLEASEQUERYDONE xid 3 <----- DHCPLEASEQUERYDONE xid 3
<----- DHCPLEASEACTIVE xid 4 <----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEQUERYDONE xid 4 <----- DHCPLEASEQUERYDONE xid 4
8.8. Closing Connections 7.8. Closing Connections
Either the requestor or DHCPv4 server MAY close the TCP connection at
any time. The requestor MAY choose to retain the connection if it
intends to issue additional queries or if other queries are currently
using the connection. Note that this requestor behavior does not
guarantee that the connection will be available for additional
queries: the server might decide to close the connection based on its
own configuration.
9. Server Behavior The requestor SHOULD close the connection after the
DHCPLEASEQUERYDONE message is received for the last outstanding query
that it has sent.
9.1. Accepting Connections 8. Server Behavior
8.1. Accepting Connections
Servers that implement DHCPv4 Bulk Leasequery listen for incoming TCP Servers that implement DHCPv4 Bulk Leasequery listen for incoming TCP
connections. Port numbers are discussed in Section 7.3. Servers connections. Port numbers are discussed in Section 6.3. Servers
MUST be able to limit the number of currently accepted and active MUST be able to limit the number of currently accepted and active
connections. The value BULK_LQ_MAX_CONNS SHOULD be the default; connections. The value BULK_LQ_MAX_CONNS SHOULD be the default;
implementations MAY permit the value to be configurable. Connections implementations MAY permit the value to be configurable. Connections
SHOULD be accepted and, if the number of connections is over SHOULD be accepted and, if the number of connections is over
BULK_LQ_MAX_CONNS, they SHOULD be closed immediately. BULK_LQ_MAX_CONNS, they SHOULD be closed immediately.
Servers MAY restrict Bulk Leasequery connections and Servers MAY restrict Bulk Leasequery connections and
DHCPBULKLEASEQUERY messages to certain requestors. Connections not DHCPBULKLEASEQUERY messages to certain requestors. Connections not
from permitted requestors SHOULD be closed immediately, to avoid from permitted requestors SHOULD be closed immediately, to avoid
server connection resource exhaustion. Servers MAY restrict some server connection resource exhaustion. Servers MAY restrict some
skipping to change at page 30, line 21 skipping to change at page 28, line 29
are not permitted with the DHCPLEASEQUERYDONE message with a dhcp- are not permitted with the DHCPLEASEQUERYDONE message with a dhcp-
message status of NotAllowed, or MAY simply close the connection. message status of NotAllowed, or MAY simply close the connection.
If the TCP connection becomes blocked while the server is accepting a 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 or reading a query, it SHOULD be prepared to terminate the
connection after an BULK_LQ_DATA_TIMEOUT. We make this connection after an BULK_LQ_DATA_TIMEOUT. We make this
recommendation to allow servers to control the period of time they recommendation to allow servers to control the period of time they
are willing to wait before abandoning an inactive connection, are willing to wait before abandoning an inactive connection,
independent of the TCP implementations they may be using. independent of the TCP implementations they may be using.
9.2. Replying to a Bulk Leasequery 8.2. Replying to a Bulk Leasequery
If the connection becomes blocked while the server is attempting to If the connection becomes blocked while the server is attempting to
send reply messages, the server SHOULD be prepared to terminate the send reply messages, the server SHOULD be prepared to terminate the
TCP connection after BULK_LQ_DATA_TIMEOUT. TCP connection after BULK_LQ_DATA_TIMEOUT.
Every Bulk Leasequery request MUST be terminated by sending a final Every Bulk Leasequery request MUST be terminated by sending a final
DHCPLEASEQUERYDONE message if such a message can be sent. The DHCPLEASEQUERYDONE message if such a message can be sent. The
DHCPLEASEQUERYDONE message MUST have a dhcp-message status if the DHCPLEASEQUERYDONE message MUST have a dhcp-message status if the
termination was other than successful, and SHOULD NOT contain a termination was other than successful, and SHOULD NOT contain a
dhcp-message status if the termination was successful. dhcp-message status if the termination was successful.
skipping to change at page 30, line 51 skipping to change at page 29, line 11
option with a Success status unless there is a useful string to option with a Success status unless there is a useful string to
include in the dhcp-message option. Otherwise, the server sends each include in the dhcp-message option. Otherwise, the server sends each
binding's data in a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message. binding's data in a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message.
The response to a DHCPBULKLEASEQUERY may involve examination of The response to a DHCPBULKLEASEQUERY may involve examination of
multiple DHCPv4 IP address bindings maintained by the DHCPv4 server. multiple DHCPv4 IP address bindings maintained by the DHCPv4 server.
The Bulk Leasequery protocol does not require any ordering of the IP The Bulk Leasequery protocol does not require any ordering of the IP
addresses returned in DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED addresses returned in DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED
messages. messages.
A Bulk Leasequery response MUST contain no more than one message for When responding to a DHCPBULKLEASEQUERY message, the DHCPv4 server
each IP address configured in the DHCPv4 server. In addition, a Bulk MUST NOT send more than one message for each applicable IP address,
Leasequery may well take significant time between the beginning and even if the state of some of those IP addresses changes during the
end of the processing of all of the messages required to satisfy the processing of the message. Updates to such IP address state are
Bulk Leasequery query. During this time, the state of some of the IP already handled by normal protocol processing, so no special effort
addresses sent early in the response may change prior to the is needed here. (I hope!)
completion of the entire response to the Bulk Leasequery. This is
normal and expected -- there is no requirement for the entire
response to a Bulk Leasequery to represent an instantaneous snapshot
of the state of the IP address bindings of a DHCPv4 server. Quite
the contrary -- as the cursor moves through the IP addresses in
whatever order is convenient to the DHCPv4 server, the state of IP
addresses already examined can change and a DHCPv4 server MUST NOT
try to examine IP addresses already scanned in an attempt to "keep
up" with the ongoing state changes of all of the IP addresses. To do
so would make it difficult to meet the requirement to send only one
message per 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 If the ciaddr, yiaddr, or siaddr is non-zero in a DHCPBULKLEASEQUERY
request, the request must be terminated immediately by a request, the request must be terminated immediately by a
DHCPLEASEQUERYDONE message with a dhcp-message status of DHCPLEASEQUERYDONE message with a dhcp-message status of
MalformedQuery. MalformedQuery.
Any DHCPBULKLEASEQUERY which has more than one of the following Any DHCPBULKLEASEQUERY which has more than one of the following
primary query types specified MUST be terminated immediately by a primary query types specified MUST be terminated immediately by a
DHCPLEASEQUERYDONE message with a dhcp-message status code of DHCPLEASEQUERYDONE message with a dhcp-message status code of
NotAllowed. NotAllowed.
The allowable queries in a DHCPBULKLEASEQUERY message are processed The allowable queries in a DHCPBULKLEASEQUERY message are processed
as follows. Note that the descriptions of the primary queries below as follows. Note that the descriptions of the primary queries below
must be constrained by the actions of any of the three qualifiers must be constrained by the actions of any of the three qualifiers
described subsequently as well. described subsequently as well.
The following table discusses how to process the various queries. The following table discusses how to process the various queries.
For information on how to identify the query, see the information in For information on how to identify the query, see the information in
Section 8.2. Section 7.2.
o Query by MAC address o Query by MAC address
Every IP address that has a current binding to a DHCPv4 client Every IP address that has a current binding to a DHCPv4 client
matching the chaddr, htype, and hlen in the DHCPBULKLEASEQUERY matching the chaddr, htype, and hlen in the DHCPBULKLEASEQUERY
request MUST be returned in a DHCPLEASEACTIVE message. request MUST be returned in a DHCPLEASEACTIVE message.
o Query by Client-Id o Query by Client-Id
Every IP address that has a current binding to a DHCPv4 client Every IP address that has a current binding to a DHCPv4 client
skipping to change at page 33, line 32 skipping to change at page 31, line 27
constrain the amount of data returned by a Bulk Leasequery request by constrain the amount of data returned by a Bulk Leasequery request by
returning only IP addresses whose address bindings have changed in returning only IP addresses whose address bindings have changed in
some way during the time window specified by the query-start-time and some way during the time window specified by the query-start-time and
query-end-time. query-end-time.
A DHCPv4 server SHOULD consider an address binding to have changed A DHCPv4 server SHOULD consider an address binding to have changed
during a specified time window if either the client-last- during a specified time window if either the client-last-
transaction-time or the start-time-of-state of the address binding transaction-time or the start-time-of-state of the address binding
changed during that time window. changed during that time window.
A DHCPv4 server MAY always compare the address binding information The DHCPv4 server MAY return address binding data in any order, as
for an IP address against a time window if it follows the following long as binding information for any given IP address is not repeated.
guidelines. If there is no query-start-time, then the DHCPv4 server When all binding data for a given DHCPBULKLEASEQUERY has been sent,
MUST assume the query-start-time is equivalent to a time prior to any the DHCPv4 server MUST send a DHCPBULKLEASEQUERYDONE message.
time that resides in any IP address binding. If there is no query-
end-time, the DHCPv4 server MUST assume that the query-end-time is
equivalent to a time that is later than any time that resides in any
IP address binding.
Even if the query-start-time or query-end-time option value is being
used to limit the amount of data flow from the DHCPv4 server to the
requestor, there is no requirement placed on the DHCPv4 server to
return address binding data in any order and certainly not in 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 8.3. Building a Single Reply for Bulk Leasequery
The DHCPv4 Leasequery [RFC4388] specification describes the initial The DHCPv4 Leasequery [RFC4388] specification describes the initial
construction of DHCPLEASEQUERY reply messages using the construction of DHCPLEASEQUERY reply messages using the
DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types in Section DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types in Section
6.4.2. All of the reply messages in Bulk Leasequery are similar to 5.4.2. All of the reply messages in Bulk Leasequery are similar to
the reply messages for an IP address query. Message transmission and the reply messages for an IP address query. Message transmission and
framing for TCP is described in this document in Section 7.1. framing for TCP is described in this document in Section 6.1.
[RFC2131] and [RFC4388] specify that every response message MUST [RFC2131] and [RFC4388] specify that every response message MUST
contain the server-identifier option. However, that option will be contain the server-identifier option. However, that option will be
the same for every response from a particular DHCPBULKLEASEQUERY the same for every response from a particular DHCPBULKLEASEQUERY
request. Thus, the DHCPv4 server MUST include the server-identifier request. Thus, the DHCPv4 server MUST include the server-identifier
option in the first message sent in response to a DHCPBULKLEASEQUERY. option in the first message sent in response to a DHCPBULKLEASEQUERY.
It MAY include the server-identifier in later messages as well, but It SHOULD NOT include the server-identifier in later messages.
there is no requirement for it to do so.
The message type of DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED is based The message type of DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED is based
on the value of the dhcp-state option. If the dhcp-state option on the value of the dhcp-state option. If the dhcp-state option
value is ACTIVE, then the message type is DHCPLEASEACTIVE, otherwise value is ACTIVE, then the message type is DHCPLEASEACTIVE, otherwise
the message type is DHCPLEASEUNASSIGNED. the message type is DHCPLEASEUNASSIGNED.
In addition to the basic message construction described in [RFC4388], In addition to the basic message construction described in [RFC4388],
the following guidelines exist: the following guidelines exist:
1. If the dhcp-state option code appears in the dhcp-parameter- 1. If the dhcp-state option code appears in the dhcp-parameter-
skipping to change at page 35, line 36 skipping to change at page 33, line 14
DHCPBULKLEASEQUERY request, then it should be used for all of DHCPBULKLEASEQUERY request, then it should be used for all of
the replies generated by that request. Some options can be the replies generated by that request. Some options can be
sent from a DHCPv4 client to the server or from the DHCPv4 sent from a DHCPv4 client to the server or from the DHCPv4
server to a DHCPv4 client. Option 125 is such an option. If server to a DHCPv4 client. Option 125 is such an option. If
the option code for one of these options appears in the dhcp- the option code for one of these options appears in the dhcp-
parameter-request-list, it SHOULD result in returning the value parameter-request-list, it SHOULD result in returning the value
of the option sent by the DHCPv4 client to the server if one of the option sent by the DHCPv4 client to the server if one
exists. exists.
Note that there may be other requirements for a reply to a Note that there may be other requirements for a reply to a
DHCPBULKLEASEQUERY request discussed in Section 9.2. DHCPBULKLEASEQUERY request discussed in Section 8.2.
9.4. Multiple or Parallel Queries 8.4. Multiple or Parallel Queries
As discussed in Section 8.3, requestors may want to leverage an As discussed in Section 7.3, requestors may want to use a connection
existing connection if they need to make multiple queries. Servers that has already been established when they need to make additional
MAY support reading and processing multiple queries from a single queries. Servers SHOULD support reading and processing multiple
connection. A server MUST NOT read more query messages from a queries from a single connection and SHOULD allow configuration of
connection than it is prepared to process simultaneously. the number of simultaneous queries it may process. 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 This SHOULD be a feature that is administratively controlled.
that are able to process queries in parallel SHOULD offer Servers SHOULD offer configuration that limits the number of
configuration that limits the number of simultaneous queries simultaneous queries permitted from any one requestor, in order to
permitted from any one requestor, in order to control resource use if control resource use if there are multiple requestors seeking
there are multiple requestors seeking service. service.
9.5. Closing Connections 8.5. Closing Connections
The server MAY close its end of the TCP connection after sending its The DHCPv4 server SHOULD start a timer for BULK_LQ_DATA_TIMEOUT
last message, a DHCPLEASEQUERYDONE message in response to a query. seconds for a particular connection after it sends a
Alternatively, the server MAY retain the connection and wait for DHCPLEASEQUERYDONE message over that connection and if there is no
additional queries from the requestor. The server SHOULD be prepared current outstanding query outstanding for that connection. It should
to limit the number of connections it maintains, and SHOULD be clear this timer if a query arrives over that connection. If the
prepared to close idle connections to enforce the limit. timer expires, the DHCPv4 server should close the connection.
The server MUST close its end of the TCP connection if it encounters 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 an error sending data on the connection. The server MUST close its
end of the TCP connection if it finds that it has to abort an in- end of the TCP connection if it finds that it has to abort an in-
process request. A server aborting an in-process request SHOULD process request. A server aborting an in-process request SHOULD
attempt to signal that to its requestors by using the QueryTerminated attempt to signal that to its requestors by using the QueryTerminated
status code in the dhcp-message option in a DHCPLEASEQUERYDONE status code in the dhcp-message option in a DHCPLEASEQUERYDONE
message, including a message string indicating details of the reason message, including a message string indicating details of the reason
for the abort. If the server detects that the requesting end of the for the abort. If the server detects that the requesting end of the
connection has been closed, the server MUST close its end of the connection has been closed, the server MUST close its end of the
connection after it has finished processing any outstanding requests. connection.
The server MUST send a DHCPLEASEQUERYDONE message at the end of the
data returned from a Bulk Leasequery request.
10. Security Considerations 9. Security Considerations
The "Security Considerations" section of [RFC2131] details the The "Security Considerations" section of [RFC2131] details the
general threats to DHCPv4. The DHCPv4 Leasequery specification general threats to DHCPv4. The DHCPv4 Leasequery specification
[RFC4388] describes recommendations for the Leasequery protocol, [RFC4388] describes recommendations for the Leasequery protocol,
especially with regard to authentication of LEASEQUERY messages, especially with regard to authentication of LEASEQUERY messages,
mitigation of packet-flooding DOS attacks, and restriction to trusted mitigation of packet-flooding DOS attacks, and restriction to trusted
requestors. requestors.
The use of TCP introduces some additional concerns. Attacks that The use of TCP introduces some additional concerns. Attacks that
attempt to exhaust the DHCPv4 server's available TCP connection attempt to exhaust the DHCPv4 server's available TCP connection
resources, such as SYN flooding attacks, can compromise the ability resources, such as SYN flooding attacks, can compromise the ability
of legitimate requestors to receive service. Malicious requestors of legitimate requestors to receive service. Malicious requestors
who succeed in establishing connections, but who then send invalid who succeed in establishing connections, but who then send invalid
queries, partial queries, or no queries at all also can exhaust a queries, partial queries, or no queries at all also can exhaust a
server's pool of available connections. We recommend that servers server's pool of available connections. We recommend that servers
offer configuration to limit the sources of incoming connections, offer configuration to limit the sources of incoming connections,
that they limit the number of accepted connections and the number of that they limit the number of accepted connections and the number of
in-process queries from any one connection, and that they limit the in-process queries from any one connection, and that they limit the
period of time during which an idle connection will be left open. period of time during which an idle connection will be left open.
11. IANA Considerations [RFC4388] discusses security concerns and potential solutions for
DHCPLEASEQUERY message exchanges in its Section 7, and all of the
solutions discussed there are applicable to the DHCPLEASEQUERY
message exchanges described in this document.
10. IANA Considerations
IANA is requested to assign the following new values for this IANA is requested to assign the following new values for this
document. See Section 7.2 for details. document. See Section 6.2 for details.
1. A dhcp-message-type of 14 for DHCPBULKLEASEQUERY. 1. A dhcp-message-type of 14 for DHCPBULKLEASEQUERY.
2. A dhcp-message-type of 15 for DHCPLEASEQUERYDONE. 2. A dhcp-message-type of 15 for DHCPLEASEQUERYDONE.
3. An option code of TBD1 for base-time. 3. An option code of TBD1 for base-time.
4. An option code of TBD2 for start-time-of-state. 4. An option code of TBD2 for start-time-of-state.
5. An option code of TBD3 for query-start-time. 5. An option code of TBD3 for query-start-time.
skipping to change at page 38, line 13 skipping to change at page 35, line 38
Type and Information [VpnId]: Type and Information [VpnId]:
Type VSS Information format: Type VSS Information format:
0 NVT ASCII VPN identifier 0 NVT ASCII VPN identifier
1 RFC2685 VPN-ID 1 RFC2685 VPN-ID
2-253 Not Allowed 2-253 Not Allowed
NEW -> 254 All VPN's. (wildcard) NEW -> 254 All VPN's. (wildcard)
255 Global, default VPN. 255 Global, default VPN.
12. Acknowledgements 11. Acknowledgements
This draft is a collaboration between the authors of draft-dtv-dhc- This draft is a collaboration between the authors of draft-dtv-dhc-
dhcpv4-bulk-leasequery-00.txt and draft-kkinnear-dhc-dhcpv4-bulk- dhcpv4-bulk-leasequery-00.txt and draft-kkinnear-dhc-dhcpv4-bulk-
leasequery-00.txt. Both documents acknowledged that significant text leasequery-00.txt. Both documents acknowledged that significant text
as well as important ideas were borrowed in whole or in part from the as well as important ideas were borrowed in whole or in part from the
DHCPv6 Bulk Leasequery RFC, [DHCPv6Bulk] written by Mark Stapp. DHCPv6 Bulk Leasequery RFC, [RFC5460] written by Mark Stapp. Further
Further suggestions and improvements were made by participants in the suggestions and improvements were made by participants in the DHC
DHC working group, including Alfred Hoenes. working group, including Alfred Hoenes.
13. References 12. References
13.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[RFC2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001. 3046, January 2001.
[RFC4388] Woundy, R., K. Kinnear, "Dynamic Host Configuration [RFC4388] Woundy, R., K. Kinnear, "Dynamic Host Configuration
Protocol (DHCP) Leasequery", RFC 4388, February 2006. Protocol (DHCP) Leasequery", RFC 4388, February 2006.
[RelayId] Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption", [RelayId] Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption",
draft-ietf-dhc-relay-id-suboption-06.txt, (work in progress) draft-ietf-dhc-relay-id-suboption-07.txt, (work in progress) July
December 2008. 2009.
[VpnId] Kinnear, K., R. Johnson, M. Stapp and J. Kumarasamy, "Virtual [VpnId] Kinnear, K., R. Johnson, M. Stapp and J. Kumarasamy, "Virtual
Subnet Selection Options for DHCPv4 and DHCPv6" draft-ietf-dhc- Subnet Selection Options for DHCPv4 and DHCPv6" draft-ietf-dhc-
vpn-option-09.txt, (work in progress) July 2008. vpn-option-11.txt, (work in progress) March 2009.
13.2. Informative References 12.2. Informative References
[RFC951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC [RFC951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC
951, September 1985. 951, September 1985.
[RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap [RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, October 1993. Protocol", RFC 1542, October 1993.
[RFC4614] Duke, M., R. Braden, W. Eddy, and E. Blanton, "A Roadmap [RFC4614] Duke, M., R. Braden, W. Eddy, and E. Blanton, "A Roadmap
for Transmission Control Protocol (TCP) Specification Documents", for Transmission Control Protocol (TCP) Specification Documents",
RFC 4614, September 2006. RFC 4614, September 2006.
[DHCPv6Bulk] Stapp, M., "DHCPv6 Bulk Leasequery", draft-ietf-dhc- [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February
dhcpv6-bulk-leasequery-06.txt, (work in progress) January 2009. 2009.
Authors' Addresses Authors' Addresses
Kim Kinnear Kim Kinnear
Cisco Systems Cisco Systems
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, Massachusetts 01719 Boxborough, Massachusetts 01719
Phone: (978) 936-0000 Phone: (978) 936-0000
skipping to change at page 39, line 42 skipping to change at page 37, line 26
Bernie Volz Bernie Volz
Cisco Systems Cisco Systems
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, Massachusetts 01719 Boxborough, Massachusetts 01719
Phone: (978) 936-0000 Phone: (978) 936-0000
EMail: volz@cisco.com EMail: volz@cisco.com
Neil Russell Neil Russell
Cisco Systems 10 Jordan Terrace
1414 Massachusetts Ave. Wakefield, MA 01880
Boxborough, Massachusetts 01719
Phone: (978) 936-0000
EMail: nrussell@cisco.com EMail: provng@gmail.com
Mark Stapp Mark Stapp
Cisco Systems Cisco Systems
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, Massachusetts 01719 Boxborough, Massachusetts 01719
Phone: (978) 936-0000 Phone: (978) 936-0000
EMail: mjs@cisco.com EMail: mjs@cisco.com
skipping to change at page 41, line 4 skipping to change at line 1693
URI: http://www.infosys.com/ URI: http://www.infosys.com/
Pavan Kurapati Pavan Kurapati
Infosys Technologies Ltd. Infosys Technologies Ltd.
44 Electronics City, Hosur Road 44 Electronics City, Hosur Road
Bangalore 560 100 Bangalore 560 100
India India
EMail: pavan_kurapati@infosys.com EMail: pavan_kurapati@infosys.com
URI: http://www.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.
 End of changes. 92 change blocks. 
377 lines changed or deleted 239 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/