draft-ietf-dhc-dhcpv4-active-leasequery-00.txt   draft-ietf-dhc-dhcpv4-active-leasequery-01.txt 
Network Working Group K. Kinnear Network Working Group K. Kinnear
Internet-Draft M. Stapp Internet-Draft M. Stapp
Intended status: Standards Track B. Volz Intended status: Standards Track B. Volz
Expires: June 29, 2014 Cisco Systems Expires: December 5, 2014 Cisco Systems
N. Russell N. Russell
Staples Staples
December 26, 2013 June 3, 2014
Active DHCPv4 Lease Query Active DHCPv4 Lease Query
draft-ietf-dhc-dhcpv4-active-leasequery-00.txt draft-ietf-dhc-dhcpv4-active-leasequery-01.txt
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been
extended with a Leasequery capability that allows a client to request extended with a Leasequery capability that allows a client to request
information about DHCPv4 bindings. That mechanism is limited to information about DHCPv4 bindings. That mechanism is limited to
queries for individual bindings. In some situations individual queries for individual bindings. In some situations individual
binding queries may not be efficient, or even possible. In addition, binding queries may not be efficient, or even possible. In addition,
continuous update of an external client with Leasequery data is continuous update of an external client with Leasequery data is
sometimes desired. This document expands on the DHCPv4 Leasequery sometimes desired. This document expands on the DHCPv4 Leasequery
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on June 29, 2014. This Internet-Draft will expire on December 5, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Interaction Between Active Leasequery and Bulk Leasequery . . 6 4. Interaction Between Active Leasequery and Bulk Leasequery . . 6
5. Message and Option Definitions . . . . . . . . . . . . . . . 7 5. Message and Option Definitions . . . . . . . . . . . . . . . 7
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 7 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 7
5.2. New or Changed Options . . . . . . . . . . . . . . . . . 8 5.2. New or Changed Options . . . . . . . . . . . . . . . . . 7
5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 8 5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 7
5.2.2. dhcp-status-code . . . . . . . . . . . . . . . . . . 8 5.2.2. dhcp-status-code . . . . . . . . . . . . . . . . . . 8
5.3. Connection and Transmission Parameters . . . . . . . . . 9 5.3. Connection and Transmission Parameters . . . . . . . . . 9
6. Information Communicated by Active Leasequery . . . . . . . . 10 6. Information Communicated by Active Leasequery . . . . . . . . 9
7. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 11 7. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 10
7.1. Connecting and General Processing . . . . . . . . . . . . 11 7.1. Connecting and General Processing . . . . . . . . . . . . 10
7.2. Forming an Active Leasequery . . . . . . . . . . . . . . 11 7.2. Forming an Active Leasequery . . . . . . . . . . . . . . 11
7.3. Processing Active Replies . . . . . . . . . . . . . . . . 12 7.3. Processing Active Replies . . . . . . . . . . . . . . . . 12
7.3.1. Processing Replies from a Request Containing a query- 7.3.1. Processing Replies from a Request Containing a query-
start-time . . . . . . . . . . . . . . . . . . . . . 14 start-time . . . . . . . . . . . . . . . . . . . . . 14
7.4. Closing Connections . . . . . . . . . . . . . . . . . . . 17 7.4. Closing Connections . . . . . . . . . . . . . . . . . . . 16
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 17 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 17 8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 16
8.2. Replying to an Active Leasequery . . . . . . . . . . . . 17 8.2. Replying to an Active Leasequery . . . . . . . . . . . . 17
8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 19 8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 19
8.4. Closing Connections . . . . . . . . . . . . . . . . . . . 19 8.4. Closing Connections . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4 The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4
capability [RFC2131] [RFC2132] to allow an external entity to query a capability [RFC2131] [RFC2132] to allow an external entity to query a
DHCPv4 server to recover lease state information about a particular DHCPv4 server to recover lease state information about a particular
IP address or client in near real-time. IPv4 address or client in near real-time.
Requirements exist for external entities to keep up to date on the Requirements exist for external entities to keep up to date on the
correspondence between DHCPv4 clients and the IPv4 addresses for correspondence between DHCPv4 clients and the IPv4 addresses for
which they have leases. These requirements often stem from which they have leases. These requirements often stem from
regulatory requirements placed on service providers by governmental regulatory requirements placed on service providers by governmental
agencies. agencies.
These entities need to keep up with the current IPv4 address binding These entities need to keep up with the current IPv4 address binding
activity of the DHCPv4 server. Keeping up with address binding activity of the DHCPv4 server. Keeping up with address binding
activity is termed "active" leasequery. activity is termed "active" leasequery.
skipping to change at page 3, line 38 skipping to change at page 3, line 38
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses the following terms: This document uses the following terms:
o "address binding" o "address binding"
The information that a DHCPv4 server keeps regarding the The information that a DHCPv4 server keeps regarding the
relationship between a DHCPv4 client and an IPv4 IP address. This relationship between a DHCPv4 client and an IPv4 address. This
includes the identity of the DHCPv4 client and the expiration includes the identity of the DHCPv4 client and the expiration
time, if any, of any lease that client has on a particular IPv4 time, if any, of any lease that client has on a particular IPv4
address. address.
o "Active Leasequery" o "Active Leasequery"
Keeping up to date in real-time (or near real-time) with DHCPv4 Keeping up to date in real-time (or near real-time) with DHCPv4
address binding activity. address binding activity.
o "Bulk Leasequery" o "Bulk Leasequery"
Requesting and receiving the existing DHCPv4 address binding Requesting and receiving the information about all or some of the
information in an efficient manner. existing DHCPv4 address binding information in an efficient
manner, as defined by [RFC6926].
o "catch-up information, catch-up phase" o "catch-up information, catch-up phase"
If a DHCPv4 Active Leasequery requestor sends in a query-start- If a DHCPv4 Active Leasequery requestor sends in a query-start-
time option in a DHCPACTIVELEASEQUERY message, the DHCPv4 server time option in a DHCPACTIVELEASEQUERY message, the DHCPv4 server
will attempt to send the requestor the information that changed will attempt to send the requestor the information that changed
since the time specified in the query-start-time option. The since the time specified in the query-start-time option. The
address binding information sent to satisfy this request is the address binding information sent to satisfy this request is the
catch-up information, and the period while it is being sent is the catch-up information, and the period while it is being sent is the
catch-up phase. catch-up phase.
skipping to change at page 4, line 31 skipping to change at page 4, line 31
constant but is likely to vary only slowly. While it is easy to constant but is likely to vary only slowly. While it is easy to
think that this can be calculated precisely after one packet is think that this can be calculated precisely after one packet is
received by a requestor from a DHCPv4 server, a more accurate received by a requestor from a DHCPv4 server, a more accurate
value is derived from continuously examining the instantaneous value is derived from continuously examining the instantaneous
value developed from each packet received from a DHCPv4 server and value developed from each packet received from a DHCPv4 server and
using it to make small adjustments to the existing value held in using it to make small adjustments to the existing value held in
the requestor. the requestor.
o "DHCPv4 client" o "DHCPv4 client"
A DHCPv4 client is an Internet host using DHCP to obtain A DHCPv4 client is an IPv4 node using DHCP to obtain configuration
configuration parameters such as a network address. parameters such as a network address.
o "DHCPv4 relay agent" o "DHCPv4 relay agent"
A DHCPv4 relay agent is a third-party agent that transfers BOOTP A DHCPv4 relay agent is a third-party agent that transfers BOOTP
and DHCPv4 messages between clients and servers residing on and DHCPv4 messages between clients and servers residing on
different subnets, per [RFC0951] and [RFC1542]. different subnets, per [RFC0951] and [RFC1542].
o "DHCPv4 server" o "DHCPv4 server"
A DHCPv4 server is an Internet host that returns configuration A DHCPv4 server is an IPv4 node that returns configuration
parameters to DHCPv4 clients. parameters to DHCPv4 clients.
o "IP address binding" o "IP address binding"
The information that a DHCPv4 server keeps regarding the The information that a DHCPv4 server keeps regarding the
relationship between a DHCPv4 client and an IPv4 IP address. This relationship between a DHCPv4 client and an IPv4 address. This
includes the identity of the DHCPv4 client and the expiration includes the identity of the DHCPv4 client and the expiration
time, if any, of any lease that client has on a particular IPv4 time, if any, of any lease that client has on a particular IPv4
address. address.
o "MAC address" o "MAC address"
In the context of a DHCP message, a MAC address consists of the In the context of a DHCP message, a MAC address consists of the
fields: hardware type "htype", hardware length "hlen", and client fields: hardware type "htype", hardware length "hlen", and client
hardware address "chaddr". hardware address "chaddr".
o "requestor"
The node that sends LEASEQUERY messages to one or more servers to
retrieve information on the bindings for a client.
3. Protocol Overview 3. Protocol Overview
The Active Leasequery mechanism is modeled on the existing individual The Active Leasequery mechanism is modeled on the existing individual
Leasequery protocol in [RFC4388] as well as related work on DHCPv4 Leasequery protocol in [RFC4388] as well as related work on DHCPv4
Bulk Leasequery [RFC6926]; most differences arise from the long term Bulk Leasequery [RFC6926]; most differences arise from the long term
nature of the TCP connection required for Active Leasequery. In nature of the TCP connection required for Active Leasequery. In
addition, a DHCPv4 server which supports Active Leasequery MUST addition, a DHCPv4 server which supports Active Leasequery MUST
support Bulk Leasequery [RFC6926] as well. support Bulk Leasequery [RFC6926] as well.
An Active Leasequery client opens a TCP connection to a DHCPv4 An Active Leasequery client opens a TCP connection to a DHCPv4
Server, using the DHCPv4 port 67. Note that this implies that the Server, using the DHCPv4 port 67. Note that this implies that the
Leasequery client has server IP address(es) available via Leasequery client has the server IPv4 address(es) available via
configuration or some other means, and that it has unicast IP configuration or some other means, and that it has unicast IP
reachability to the DHCPv4 server. No relaying for Active Leasequery reachability to the DHCPv4 server. The message framing for TCP is
is specified. discusssed in Section 5.1. No relaying for Active Leasequery is
specified.
After establishing a connection, the client sends an After establishing a connection, the client sends an
DHCPACTIVELEASEQUERY message over the connection. In response, the DHCPACTIVELEASEQUERY message over the connection. In response, the
server sends updates to the requestor using DHCPLEASEACTIVE and server sends updates to the requestor using DHCPLEASEACTIVE and
DHCPLEASEUNASSIGNED messages which are extensions of these messages DHCPLEASEUNASSIGNED messages which are extensions of these messages
as defined in [RFC4388] and [RFC6926]. as defined in [RFC4388] and [RFC6926].
Active Leasequery is designed to provide continuous updates of DHCPv4 Active Leasequery is designed to provide continuous updates of DHCPv4
IPv4 address binding activity to an external entity. IPv4 address binding activity to an external entity.
Active Leasequery has features which allow this external entity to Active Leasequery has features which allow this external entity to
lose its connection and then reconnect and receive the latest lose its connection and then reconnect and receive the latest
information concerning any IP addresses changed while it was not information concerning any IPv4 addresses changed while it was not
connected. connected.
These capabilities are designed to allow the Active Leasequery These capabilities are designed to allow the Active Leasequery
requestor to efficiently become current with respect to the lease requestor to efficiently become current with respect to the lease
state database after it has been restarted or the machine on which it state database after it has been restarted or the machine on which it
is running has been reinitialized. It is easy to define a protocol is running has been reinitialized. It is easy to define a protocol
which works when the requestor is always connected to the DHCPv4 which works when the requestor is always connected to the DHCPv4
server. Since that isn't sufficiently robust, much of the mechanism server. Since that isn't sufficiently robust, much of the mechanism
in this document is designed to deal efficiently with situations that in this document is designed to deal efficiently with situations that
occur when the Active Leasequery requestor becomes disconnected from occur when the Active Leasequery requestor becomes disconnected from
skipping to change at page 6, line 29 skipping to change at page 6, line 33
data missed on a Active Leasequery connection, but will typically data missed on a Active Leasequery connection, but will typically
choose to keep data corresponding to some recent activity available choose to keep data corresponding to some recent activity available
for subsequent queries by a DHCPv4 Active Leasequery client whose for subsequent queries by a DHCPv4 Active Leasequery client whose
connection was temporarily interrupted. connection was temporarily interrupted.
An Active Leasequery requestor would typically use Bulk Leasequery to An Active Leasequery requestor would typically use Bulk Leasequery to
initialize its database with all current data when that database initialize its database with all current data when that database
contains no address binding information. In addition, it would use contains no address binding information. In addition, it would use
Bulk Leasequery to recover missed information in the event that its Bulk Leasequery to recover missed information in the event that its
connection with the DHCPv4 server was lost for a longer time than the connection with the DHCPv4 server was lost for a longer time than the
DHCPv4 server would keep track of the specific changes to the IP DHCPv4 server would keep track of the specific changes to the IPv4
address binding information. address binding information.
The messages sent by the server in response to an Active Leasequery The messages sent by the server in response to an Active Leasequery
request SHOULD be identical to the messages sent by the server to a request SHOULD be identical to the messages sent by the server to a
Bulk Leasequery request regarding the way the data is encoded into Bulk Leasequery request regarding the way the data is encoded into
the Active Leasequery responses. In addition, the actions taken by the Active Leasequery responses. In addition, the actions taken by
the Active Leasequery requestor to interpret the responses to an the Active Leasequery requestor to interpret the responses to an
Active Leasequery request SHOULD be identical to the way that the Active Leasequery request SHOULD be identical to the way that the
requestor interprets the responses to a Bulk Leasequery request. requestor interprets the responses to a Bulk Leasequery request.
Thus, the handling of time, clock skew, data source, and other items Thus, the handling of time, clock skew, data source, and other items
skipping to change at page 7, line 27 skipping to change at page 7, line 33
5. Message and Option Definitions 5. Message and Option Definitions
5.1. Message Framing for TCP 5.1. Message Framing for TCP
The use of TCP for the Active Leasequery protocol permits one or more The use of TCP for the Active Leasequery protocol permits one or more
DHCPv4 messages to be sent at a time. The receiver needs to be able DHCPv4 messages to be sent at a time. The receiver needs to be able
to determine how large each message is. The same framing technique to determine how large each message is. The same framing technique
used for Bulk Leasequery [RFC6926] is used for Active Leasequery. used for Bulk Leasequery [RFC6926] is used for Active Leasequery.
Two octets containing the message size in network byte-order are
prepended to each DHCPv4 message sent on an Active Leasequery TCP
connection. The two message-size octets 'frame' each DHCPv4 message.
DHCPv4 message framed for TCP:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message-size | op (1) | htype (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hlen (1) | hops (1) | .... |
+---------------+---------------+ +
| |
. remainder of DHCPv4 message, .
. from Figure 1 of [RFC2131] .
. .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of a DHCPv4 message in TCP
message-size the number of octets in the message that follows,
as a 16-bit integer in network byte-order.
All other fields are as specified in DHCPv4 [RFC2131].
The intent in using this format is that code which currently knows
how to deal with a message returned from DHCPv4 Leasequery [RFC4388]
will be able to deal with the message held inside of the TCP framing.
5.2. New or Changed Options 5.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 IPv4
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. client, respectively.
All of the message types and options defined for Bulk Leasequery All of the message types and options defined for Bulk Leasequery
[RFC6926] are also used by Active Leasequery. In addition, new [RFC6926] are also used by Active Leasequery. In addition, new
message types and option types are defined for Active Leasequery, as message types and option types are defined for Active Leasequery, as
described below. described below.
5.2.1. dhcp-message-type 5.2.1. dhcp-message-type
skipping to change at page 9, line 8 skipping to change at page 8, line 31
information in a single leasequery reply if the value of the dhcp- information in a single leasequery reply if the value of the dhcp-
message-type is DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED. It refers to message-type is DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED. It refers to
the message stream related to an entire request if the value of the the message stream related to an entire request if the value of the
dhcp-message-type is DHCPLEASEQUERYSTATUS. dhcp-message-type is DHCPLEASEQUERYSTATUS.
Additional status codes defined for support of Active Leasequery are: Additional status codes defined for support of Active Leasequery are:
+------------------+-------------+----------------------------------+ +------------------+-------------+----------------------------------+
| Name | status-code | Description | | Name | status-code | Description |
+------------------+-------------+----------------------------------+ +------------------+-------------+----------------------------------+
| DataMissing | TBD3 | Indicates that IP address | | DataMissing | TBD3 | Indicates that IPv4 address |
| | | binding information requested is | | | | binding information requested is |
| | | not available. | | | | not available. |
| ConnectionActive | TBD4 | Indicates that this connection | | ConnectionActive | TBD4 | Indicates that this connection |
| | | remains active. | | | | remains active. |
| CatchUpComplete | TBD5 | Indicates that this Active | | CatchUpComplete | TBD5 | Indicates that this Active |
| | | Leasequery connection has | | | | Leasequery connection has |
| | | completed sending all of the | | | | completed sending all of the |
| | | saved data requested. | | | | saved data requested. |
+------------------+-------------+----------------------------------+ +------------------+-------------+----------------------------------+
A dhcp-status-code option MAY appear in the options field of a DHCP A dhcp-status-code option MAY appear in the options field of a DHCP
message. If the dhcp-status-code option does not appear, it is message. If the dhcp-status-code option does not appear, it is
assumed that the operation was successful. The dhcp-status-code assumed that the operation was successful. The dhcp-status-code
option SHOULD NOT appear in a message which is successful unless it option SHOULD NOT appear in a message which is successful unless it
is needed to convey some text message along with the Success status is needed to convey some text message along with the Success status
code. code.
5.3. Connection and Transmission Parameters 5.3. Connection and Transmission Parameters
DHCPv4 servers that support Active Leasequery SHOULD listen for DHCPv4 servers that support Active Leasequery SHOULD listen for
incoming TCP connections on the DHCPv4 server port 67. incoming TCP connections on port 67. Implementations MAY offer to
Implementations MAY offer to make the incoming port configurable, but make the incoming port configurable, but port 67 MUST be the default.
port 67 MUST be the default. Requestors SHOULD make TCP connections Requestors SHOULD make TCP connections to port 67, and MAY offer to
to port 67, and MAY offer to make the destination server port make the destination server port configurable.
configurable.
This section presents a table of values used to control Active This section presents a table of values used to control Active
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 SHOULD NOT be used. values smaller than the default values SHOULD NOT be used.
+------------------------+---------+--------------------------------+ +------------------------+---------+--------------------------------+
| Parameter | Default | Description | | Parameter | Default | Description |
+------------------------+---------+--------------------------------+ +------------------------+---------+--------------------------------+
| BULK_LQ_DATA_TIMEOUT | 300 | Bulk Leasequery data timeout | | BULK_LQ_DATA_TIMEOUT | * | Bulk Leasequery data timeout |
| | secs | | | BULK_LQ_MAX_CONNS | * | Max Bulk Leasequery TCP |
| BULK_LQ_MAX_CONNS | 10 | Max Bulk Leasequery TCP |
| | | connections | | | | connections |
| ACTIVE_LQ_RCV_TIMEOUT | 120 | Active Leasequery receive | | ACTIVE_LQ_RCV_TIMEOUT | 120 | Active Leasequery receive |
| | secs | timeout | | | secs | timeout |
| ACTIVE_LQ_SEND_TIMEOUT | 120 | Active Leasequery send timeout | | ACTIVE_LQ_SEND_TIMEOUT | 120 | Active Leasequery send timeout |
| | secs | | | | secs | |
| ACTIVE_LQ_IDLE_TIMEOUT | 60 secs | Active Leasequery idle timeout | | ACTIVE_LQ_IDLE_TIMEOUT | 60 secs | Active Leasequery idle timeout |
+------------------------+---------+--------------------------------+ +------------------------+---------+--------------------------------+
* See Section 6.3 of [RFC6926] for specific default values.
6. Information Communicated by Active Leasequery 6. Information Communicated by Active Leasequery
While the information communicated by a Bulk Leasequery [RFC6926] is While the information communicated by a Bulk Leasequery [RFC6926] is
taken directly from the DHCPv4 server's lease state database, the taken directly from the DHCPv4 server's lease state database, the
information communicated by an Active Leasequery is real-time information communicated by an Active Leasequery is real-time
information. As such, it is the information which is currently information. As such, it is the information which is currently
associated with a particular IP address in the DHCPv4 server's lease associated with a particular IPv4 address in the DHCPv4 server's
state database. lease state database.
This is of significance, because if the Active Leasequery requestor This is of significance, because if the Active Leasequery requestor
runs slowly or the requestor disconnects from the DHCPv4 server and runs slowly or the requestor disconnects from the DHCPv4 server and
then reconnects with a query-start-time (signaling a catch-up then reconnects with a query-start-time (signaling a catch-up
operation), the information communicated to the Active Leasequery operation), the information communicated to the Active Leasequery
requestor is only the most current information from the DHCPv4 requestor is only the most current information from the DHCPv4
server's lease state database. server's lease state database.
The requestor of an Active Leasequery MUST NOT assume that every The requestor of an Active Leasequery MUST NOT assume that every
lease state change is communicated across an Active Leasequery lease state change is communicated across an Active Leasequery
connection. Even if the Active Leasequery requestor remains connection. Even if the Active Leasequery requestor remains
connected, the DHCPv4 server is only required to transmit information connected, the DHCPv4 server is only required to transmit information
about an IP address that is current when the packet is created and about an IPv4 address that is current when the packet is created and
handed off to the TCP stack to send to the requestor. handed off to the TCP stack to send to the requestor.
If the TCP connection blocks and the DHCPv4 server is waiting to send If the TCP connection blocks and the DHCPv4 server is waiting to send
information down the connection, when the connection becomes information down the connection, when the connection becomes
available to be written the DHCPv4 server MAY create the packet to available to be written the DHCPv4 server MAY create the packet to
send at this time. The current state of the IP address will be sent, send at this time. The current state of the IPv4 address will be
and any transition in state or other information that occurred while sent, and any transition in state or other information that occurred
the TCP connection was blocked will be lost. while the TCP connection was blocked will be lost.
Thus, the Active Leasequery protocol does not allow the requestor to Thus, the Active Leasequery protocol does not allow the requestor to
build a complete history of every activity on every lease. An build a complete history of every activity on every lease. An
effective history of the important state changes for a lease can be effective history of the important state changes for a lease can be
created if the parameters of the DHCPv4 server are tuned to take into created if the parameters of the DHCPv4 server are tuned to take into
account the requirements of an Active Leasequery requestor. For account the requirements of an Active Leasequery requestor. For
instance, the period after the expiration or release of an IP address instance, the period after the expiration or release of an IPv4
could be configured long enough (say several minutes, well more than address could be configured long enough (say several minutes, well
the receive timeout), so that an Active Leasequery requestor would more than the receive timeout), so that an Active Leasequery
never miss any changes in the client to IP address binding. requestor would never miss any changes in the client to IPv4 address
binding.
7. Requestor Behavior 7. Requestor Behavior
7.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 an Active Leasequery is terminated prematurely by a If an Active Leasequery is terminated prematurely by a
skipping to change at page 12, line 33 skipping to change at page 11, line 50
Leasequery or Active Leasequery request. Leasequery or Active Leasequery request.
This capability is enabled by the transmission of a 4 octet base-time This capability is enabled by the transmission of a 4 octet base-time
option with each Leasequery reply sent as the result of a previous option with each Leasequery reply sent as the result of a previous
Active Leasequery. The requestor will typically keep track of the Active Leasequery. The requestor will typically keep track of the
highest base-time received from a particular DHCPv4 server over an highest base-time received from a particular DHCPv4 server over an
Active Leasequery connection, and in the event that the requestor Active Leasequery connection, and in the event that the requestor
finds it necessary (for whatever reason) to reestablish an Active finds it necessary (for whatever reason) to reestablish an Active
Leasequery connection to that DHCPv4 server, the requestor will place Leasequery connection to that DHCPv4 server, the requestor will place
this highest base-time value into a query-start-time option in the this highest base-time value into a query-start-time option in the
new DHCPACTIVELEASEQUERY request. new DHCPACTIVELEASEQUERY request. (See Sections 6.2.5 and 7.2 of
[RFC6926] for information on the query-start-time option.)
If the requestor doesn't wish to request an update of information If the requestor doesn't wish to request an update of information
missed when it was not connected to the DHCPv4 server, then it does missed when it was not connected to the DHCPv4 server, then it does
not include the query-start-time option in the DHCPACTIVELEASEQUERY not include the query-start-time option in the DHCPACTIVELEASEQUERY
request. request.
If the TCP connection becomes blocked or stops being writable while If the TCP connection becomes blocked or stops being writable while
the requestor is sending its query, the requestor SHOULD be prepared the requestor is sending its query, the requestor SHOULD be prepared
to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this
recommendation to allow requestors to control the period of time they recommendation to allow requestors to control the period of time they
are willing to wait before abandoning a connection, independent of are willing to wait before abandoning a connection, independent of
skipping to change at page 14, line 35 skipping to change at page 14, line 8
The DHCPv4 Leasequery protocol uses the associated-ip option as an The DHCPv4 Leasequery protocol uses the associated-ip option as an
indicator that multiple bindings were present in response to a single indicator that multiple bindings were present in response to a single
client based query. For Active Leasequery, client-based queries are client based query. For Active Leasequery, client-based queries are
not supported and so the associated-ip option is not used, and MUST not supported and so the associated-ip option is not used, and MUST
NOT be present in replies. NOT be present in replies.
7.3.1. Processing Replies from a Request Containing a query-start-time 7.3.1. Processing Replies from a Request Containing a query-start-time
If the DHCPACTIVELEASEQUERY was requested with a query-start-time, If the DHCPACTIVELEASEQUERY was requested with a query-start-time,
the DHCPv4 server will attempt to send information about all IP the DHCPv4 server will attempt to send information about all IPv4
address bindings that changed since the time specified in the query- address bindings that changed since the time specified in the query-
start-time. This is the catch-up phase of the DHCPACTIVELEASEQUERY start-time. This is the catch-up phase of the DHCPACTIVELEASEQUERY
processing. The DHCPv4 server MAY also begin immediate updates over processing. The DHCPv4 server MAY also begin immediate updates over
the same connection of real-time IP address binding information the same connection of real-time IPv4 address binding information
changes. Thus, the catch-up phase may run in parallel with the changes. Thus, the catch-up phase may run in parallel with the
normal updates generated by the DHCPACTIVELEASEQUERY request. normal updates generated by the DHCPACTIVELEASEQUERY request.
A DHCPv4 server MAY keep only a limited amount of time ordered A DHCPv4 server MAY keep only a limited amount of time ordered
information available to respond to a DHCPACTIVELEASEQUERY request information available to respond to a DHCPACTIVELEASEQUERY request
containing a query-start-time. Thus, it is possible that the time containing a query-start-time. Thus, it is possible that the time
specified in the query-start-time represents a time not covered by specified in the query-start-time represents a time not covered by
the time ordered information kept by the DHCPv4 server. If this the time ordered information kept by the DHCPv4 server. If this
should occur, and there is not enough data saved in the DHCPv4 server should occur, and there is not enough data saved in the DHCPv4 server
to satisfy the request specified by the query-start-time option, the to satisfy the request specified by the query-start-time option, the
skipping to change at page 15, line 13 skipping to change at page 14, line 34
message with a dhcp-status-code of DataMissing with a base-time message with a dhcp-status-code of DataMissing with a base-time
option equal to the server's current time. This will signal the end option equal to the server's current time. This will signal the end
of the catch-up phase, and the only updates that will subsequently be of the catch-up phase, and the only updates that will subsequently be
received on this connection are the real-time updates from the received on this connection are the real-time updates from the
DHCPACTIVELEASEQUERY request. DHCPACTIVELEASEQUERY request.
If there is enough data saved to satisfy the request, then If there is enough data saved to satisfy the request, then
DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages will begin arrive DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages will begin arrive
from the DHCPv4 server. Some of these messages will be related to from the DHCPv4 server. Some of these messages will be related to
the query-start-time request and be part of the catch-up phase. Some the query-start-time request and be part of the catch-up phase. Some
of these messages will be real-time updates of IP address binding of these messages will be real-time updates of IPv4 address binding
changes taking place in the DHCPv4 server. In general, there is no changes taking place in the DHCPv4 server. In general, there is no
way to determine the source each message. way to determine the source each message.
Until the catch-up phase is complete, the latest base-time value Until the catch-up phase is complete, the latest base-time value
received from a DHCPv4 server processing an Active Leasequery request received from a DHCPv4 server processing an Active Leasequery request
cannot be reset from the incoming messages because to do so would cannot be reset from the incoming messages because to do so would
compromise the ability to recover lost information if the compromise the ability to recover lost information if the
DHCPACTIVELEASEQUERY were to terminate prior to the completion of the DHCPACTIVELEASEQUERY were to terminate prior to the completion of the
catch-up phase. catch-up phase.
The requestor will know that the catch-up phase is complete because The requestor will know that the catch-up phase is complete because
the DHCPv4 server will transmit a DHCPLEASEQUERYSTATUS message with the DHCPv4 server will transmit a DHCPLEASEQUERYSTATUS message with
the dhcp-status-code of CatchUpComplete. Once this message is the dhcp-status-code of CatchUpComplete. Once this message is
transmitted, all additional DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED transmitted, all additional DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED
messages will relate to real-time ("new") IP address binding changes messages will relate to real-time ("new") IPv4 address binding
in the DHCPv4 server. changes in the DHCPv4 server.
As discussed in Section 6.3, the requestor SHOULD keep track of the As discussed in Section 6.3, the requestor SHOULD keep track of the
latest base-time option value received over a particular connection, latest base-time option value received over a particular connection,
to be used in a subsequent DHCPACTIVELEASEQUERY request -- but only to be used in a subsequent DHCPACTIVELEASEQUERY request -- but only
if the catch-up phase is complete. Prior to the completion of the if the catch-up phase is complete. Prior to the completion of the
catch-up phase, if the connection should go away or if the requestor catch-up phase, if the connection should go away or if the requestor
receives a DHCPLEASEQUERYDONE message, then when it reconnects it receives a DHCPLEASEQUERYDONE message, then when it reconnects it
MUST use the base-time value from the previous connection and not any MUST use the base-time value from the previous connection and not any
base-time value received from the recently closed connection. base-time value received from the recently closed connection.
skipping to change at page 15, line 51 skipping to change at page 15, line 25
server to begin to satisfy the request implied by the query-start- server to begin to satisfy the request implied by the query-start-
time option, but during the processing of that data the server found time option, but during the processing of that data the server found
that it was unable to continue (perhaps there was barely enough, the that it was unable to continue (perhaps there was barely enough, the
connection is very slow, and the aging algorithm causes the saved connection is very slow, and the aging algorithm causes the saved
data to become unavailable) the DHCPv4 server will terminate the data to become unavailable) the DHCPv4 server will terminate the
catch-up phase of processing immediately by sending a catch-up phase of processing immediately by sending a
DHCPLEASEQUERYSTATUS message with a dhcp-status-code of DataMissing DHCPLEASEQUERYSTATUS message with a dhcp-status-code of DataMissing
and with a base-time option of the current time. and with a base-time option of the current time.
The requestor MUST NOT assume that every individual state change of The requestor MUST NOT assume that every individual state change of
every IP address during the period from the time specified in the every IPv4 address during the period from the time specified in the
query-start-time and the present is replicated in an Active query-start-time and the present is replicated in an Active
Leasequery reply message. The requestor MAY assume that at least one Leasequery reply message. The requestor MAY assume that at least one
Active Leasequery reply message will exist for every IP address which Active Leasequery reply message will exist for every IPv4 address
had one or more changes of state during the period specified by the which had one or more changes of state during the period specified by
query-start-time and the current time. The last message for each IP the query-start-time and the current time. The last message for each
address will contain the state at the current time, and there may be IPv4 address will contain the state at the current time, and there
one or more messages concerning a single IP address during the catch- may be one or more messages concerning a single IPv4 address during
up phase of processing. the catch-up phase of processing.
If an IP address changed state multiple times during the time that If an IPv4 address changed state multiple times during the time that
the requestor was not connected (that is, during the time from the the requestor was not connected (that is, during the time from the
query-start-time and the present), then only the current IP address query-start-time and the present), then only the current IPv4 address
binding information will be sent during the catch-up phase. Thus, binding information will be sent during the catch-up phase. Thus,
the requestor MUST NOT assume that every intermediate state change the requestor MUST NOT assume that every intermediate state change
that occurred during the period from the query-start-time to the that occurred during the period from the query-start-time to the
present will be represented by an individual Leasequery message. present will be represented by an individual Leasequery message.
If the DHCPLEASEQUERYSTATUS message containing a dhcp-status-code of If the DHCPLEASEQUERYSTATUS message containing a dhcp-status-code of
DataMissing is received and the requestor is interested in keeping DataMissing is received and the requestor is interested in keeping
its database up to date with respect to the current state of IP its database up to date with respect to the current state of IPv4
address bindings in the DHCPv4 server, then the requestor SHOULD address bindings in the DHCPv4 server, then the requestor SHOULD
issue a DHCPBULKLEASEQUERY request to recover the information missing issue a DHCPBULKLEASEQUERY request to recover the information missing
from its database. This DHCPBULKLEASEQUERY should include a query- from its database. This DHCPBULKLEASEQUERY should include a query-
start-time, set to be the same as its query-start-time previously start-time, set to be the same as its query-start-time previously
included in the DHCPACTIVELEASEQUERY responses from the DHCPv4 included in the DHCPACTIVELEASEQUERY responses from the DHCPv4
server, and a query-end-time equal to the base-time returned by the server, and a query-end-time equal to the base-time returned by the
DHCPv4 server in the DHCPLEASEQUERYSTATUS message with the dhcp- DHCPv4 server in the DHCPLEASEQUERYSTATUS message with the dhcp-
status-code of DataMissing. status-code of DataMissing.
In the event that the requestor receives a DHCPLEASEQUERYSTATUS In the event that the requestor receives a DHCPLEASEQUERYSTATUS
message with a dhcp-status-code of DataMissing, it is a reasonable message with a dhcp-status-code of DataMissing, it is a reasonable
assumption that it is interested in keeping its database up to date assumption that it is interested in keeping its database up to date
with respect to the DHCPv4 server's internal IP address binding with respect to the DHCPv4 server's internal IPv4 address binding
database or it would not have included the query-start-time in the database or it would not have included the query-start-time in the
DHCPACTIVELEASEQUERY message. DHCPACTIVELEASEQUERY message.
Typically, the requestor would have one connection open to a DHCPv4 Typically, the requestor would have one connection open to a DHCPv4
server for a DHCPACTIVELEASEQUERY request and possibly one additional server for a DHCPACTIVELEASEQUERY request and possibly one additional
connection open for a DHCPBULKLEASEQUERY request to the same DHCPv4 connection open for a DHCPBULKLEASEQUERY request to the same DHCPv4
server to fill in the data that might have been missed prior to the server to fill in the data that might have been missed prior to the
initiation of the DHCPACTIVELEASEQUERY. The Bulk Leasequery initiation of the DHCPACTIVELEASEQUERY. The Bulk Leasequery
connection would typically run to completion and be closed, leaving connection would typically run to completion and be closed, leaving
one Active Leasequery connection open to a single DHCPv4 server. one Active Leasequery connection open to a single DHCPv4 server.
skipping to change at page 18, line 16 skipping to change at page 17, line 34
DHCPACTIVELEASEQUERY message, either during initial processing or DHCPACTIVELEASEQUERY message, either during initial processing or
later during the message processing, it SHOULD send a later during the message processing, it SHOULD send a
DHCPLEASEQUERYSTATUS containing an error code of some kind in a dhcp- DHCPLEASEQUERYSTATUS containing an error code of some kind in a dhcp-
status-code option. It SHOULD close the connection after this error status-code option. It SHOULD close the connection after this error
is signaled. is signaled.
Every reply to a DHCPACTIVELEASEQUERY request MUST contain the Every reply to a DHCPACTIVELEASEQUERY request MUST contain the
information specified in replies to a DHCPBULKLEASEQUERY request information specified in replies to a DHCPBULKLEASEQUERY request
[RFC6926]. [RFC6926].
Some servers can be configured to respond to a DHCPv4 Leasequery
[RFC4388] or a DHCPBULKLEASEQUERY [RFC6926] for an IPv4 address which
is reserved in such a way that it appears that the IPv4 address is
leased to the DHCP client for which it is reserved. These servers
SHOULD also respond to a DHCPACTIVELEASEQUERY request with the same
information as they would to a DHCPBULKLEASEQUERY request when they
first determine that the IPv4 address is reserved to a DHCP client.
If a DHCPACTIVELEASEQUERY request contains a query-start-time option, If a DHCPACTIVELEASEQUERY request contains a query-start-time option,
it indicates that the requestor would like the DHCPv4 server to send it indicates that the requestor would like the DHCPv4 server to send
it not only messages that correspond to DHCPv4 address binding it not only messages that correspond to DHCPv4 address binding
activity that occurs subsequent to the receipt of the DHCPLEASEACTIVE activity that occurs subsequent to the receipt of the DHCPLEASEACTIVE
request, but also messages that correspond to DHCPv4 address binding request, but also messages that correspond to DHCPv4 address binding
activity that occurred prior to the DHCPACTIVELEASEQUERY request. activity that occurred prior to the DHCPACTIVELEASEQUERY request.
If a query-end-time option appears in a DHCPACTIVELEASEQUERY the If a query-end-time option appears in a DHCPACTIVELEASEQUERY the
DHCPv4 server should send a DHCPLEASEQUERYSTATUS message with a dhcp- DHCPv4 server should send a DHCPLEASEQUERYSTATUS message with a dhcp-
status-code of MalformedQuery and terminate the connection. status-code of MalformedQuery and terminate the connection.
In order to implement a meaningful response to this query, the DHCPv4 In order to implement a meaningful response to this query, the DHCPv4
server MAY keep track of the address binding activity and associate server MAY keep track of the address binding activity and associate
changes with particular base-time values from the messages. Then, changes with particular base-time values from the messages. Then,
when requested to do so by a DHCPACTIVELEASEQUERY request containing when requested to do so by a DHCPACTIVELEASEQUERY request containing
a query-start-time option, the DHCPv4 server can respond with replies a query-start-time option, the DHCPv4 server can respond with replies
for all address binding activity occurring on that query-start-time for all address binding activity occurring on that query-start-time
or later times. or later times.
These replies based on the query-start-time MAY be interleaved with These replies based on the query-start-time MAY be interleaved with
the messages generated due to current IP address binding activity. the messages generated due to current IPv4 address binding activity.
Once the transmission of the DHCPv4 Leasequery messages associated Once the transmission of the DHCPv4 Leasequery messages associated
with the query-start-time option are complete, a DHCPLEASEQUERYSTATUS with the query-start-time option are complete, a DHCPLEASEQUERYSTATUS
message MUST be sent with a dhcp-status-code value of message MUST be sent with a dhcp-status-code value of
CatchUpComplete. CatchUpComplete.
The DHCPv4 server SHOULD keep track of a limited amount of previous The DHCPv4 server SHOULD, but is not required to, keep track of a
address binding activity and associate it with base-time values. The limited amount of previous address binding activity and associate it
DHCPv4 server MAY choose to only do this in the event that it has with base-time values. The DHCPv4 server MAY choose to only do this
received at least one DHCPACTIVELEASEQUERY request in the past, as to in the event that it has received at least one DHCPACTIVELEASEQUERY
do so will almost certainly entail some utilization of resources request in the past, as to do so will almost certainly entail some
which would be wasted if there are no DHCPACTIVELEASEQUERY clients utilization of resources which would be wasted if there are no
for this DHCPv4 server. The DHCPv4 server SHOULD make the amount of DHCPACTIVELEASEQUERY clients for this DHCPv4 server. The DHCPv4
previous address binding activity it retains configurable. There is server SHOULD make the amount of previous address binding activity it
no requirement on the DHCPv4 server to retain this information over a retains configurable. There is no requirement on the DHCPv4 server
server restart (or even to retain such information at all). to retain this information over a server restart (or even to retain
such information at all).
Unless there is an error or some requirement to cease processing a Unless there is an error or some requirement to cease processing a
DHCPACTIVELEASEQUERY request yielding a DHCPLEASEQUERYSTATUS message, DHCPACTIVELEASEQUERY request yielding a DHCPLEASEQUERYSTATUS message,
such as a server shutdown, there will be no DHCPLEASEQUERYSTATUS such as a server shutdown, there will be no DHCPLEASEQUERYSTATUS
message at the conclusion of the DHCPACTIVELEASEQUERY processing message at the conclusion of the DHCPACTIVELEASEQUERY processing
because that processing will not conclude but will continue until because that processing will not conclude but will continue until
either the client or the server drops the connection. either the client or the server drops the connection.
While the form of the data being sent by a DHCPACTIVELEASEQUERY is
essentially the same as that being sent by a DHCPBULKLEASEQUERY, the
reasons for sending information differs considerably between these
two capabilities. In the DHCPBULKLEASEQUERY context, the entire
contents of the lease state database (subject to the constraints of
the various query options) are returned to the requestor. In the
DHCPACTIVELEASEQUERY context, changes to the lease state database are
returned to the requestor essentially as they happen. For instance,
when an IPv4 address transitions from the leased state to some other
state, the DHCPACTIVELEASEQUERY will send a DHCPLEASEUNASSIGNED
packet with information regarding that IPv4 address. The server may
then entirely forget about that IPv4 address (or not), but it is
important to tell the DHCPACTIVELEASEQUERY client that an IPv4
address has transitioned away from the leased state.
The relationship between the time that the server replies to a DHCP
client request and the time that the DHCP server sends a reply to a
DHCPACTIVELEASEQUERY message is a matter of implementation (and thus
not something defined by this document). However, the server SHOULD
NOT delay responding to the DHCP client in order to transmit a reply
to a DHCPACTIVELEASEQUERY message, and the server SHOULD send the
reply to the DHCPACTIVELASEQUERY message as soon as possible after
responding to the client.
8.3. Multiple or Parallel Queries 8.3. Multiple or Parallel Queries
Requestors may want to use an existing connection if they need to Requestors may want to use an existing connection if they need to
make multiple queries. Servers MAY support reading and processing make multiple queries. Servers MAY support reading and processing
multiple queries from a single connection. A server MUST NOT read multiple queries from a single connection. A server MUST NOT read
more query messages from a connection than it is prepared to process more query messages from a connection than it is prepared to process
simultaneously. simultaneously.
Typically, a requestor of a Active Leasequery would not need to send Typically, a requestor of a Active Leasequery would not need to send
a second Active Leasequery while the first is still active. However, a second Active Leasequery while the first is still active. However,
skipping to change at page 20, line 14 skipping to change at page 20, line 16
9. 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 relayed LEASEQUERY messages, mitigation of especially with regard to relayed LEASEQUERY messages, mitigation of
packet-flooding DOS attacks, restriction to trusted clients, and use packet-flooding DOS attacks, restriction to trusted clients, and use
of IPsec [RFC4301]. of IPsec [RFC4301].
This capability SHOULD be disabled by default.
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 clients to receive service. Malicious clients who of legitimate clients to receive service. Malicious clients who
succeed in establishing connections, but who then send invalid 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.
10. IANA Considerations 10. IANA Considerations
IANA is requested to assign the following new DHCP message types from IANA is requested to assign the following new DHCP message types from
the registry "DHCP Message Type 53 Values" maintained at http:// the registry "DHCP Message Type 53 Values" maintained at
www.iana.org/assignments/bootp-dhcp-parameters: http://www.iana.org/assignments/bootp-dhcp-parameters:
1. A dhcp-message-type of TBD1 for DHCPACTIVELEASEQUERY. 1. A dhcp-message-type of TBD1 for DHCPACTIVELEASEQUERY.
2. A dhcp-message-type of TBD2 for DHCPLEASEQUERYSTATUS. 2. A dhcp-message-type of TBD2 for DHCPLEASEQUERYSTATUS.
IANA is requested to assign the following new DHCP status codes from IANA is requested to assign the following new DHCP status codes from
the registry "DHCP Status Code Type 151 Values" maintained at http:// the registry "DHCP Status Code Type 151 Values" maintained at
www.iana.org/assignments/bootp-dhcp-parameters: http://www.iana.org/assignments/bootp-dhcp-parameters:
+------------------+-------------+ +------------------+-------------+
| Name | status-code | | Name | status-code |
+------------------+-------------+ +------------------+-------------+
| DataMissing | TBD3 | | DataMissing | TBD3 |
| ConnectionActive | TBD4 | | ConnectionActive | TBD4 |
| CatchUpComplete | TBD5 | | CatchUpComplete | TBD5 |
+------------------+-------------+ +------------------+-------------+
11. Acknowledgements 11. Acknowledgements
 End of changes. 48 change blocks. 
112 lines changed or deleted 123 lines changed or added

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