draft-ietf-dhc-dhcpv4-active-leasequery-01.txt   draft-ietf-dhc-dhcpv4-active-leasequery-02.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 Updates: 6926 (if approved) B. Volz
Expires: December 5, 2014 Cisco Systems Intended status: Standards Track Cisco Systems
N. Russell Expires: September 3, 2015 N. Russell
Staples Staples
June 3, 2014 March 2, 2015
Active DHCPv4 Lease Query Active DHCPv4 Lease Query
draft-ietf-dhc-dhcpv4-active-leasequery-01.txt draft-ietf-dhc-dhcpv4-active-leasequery-02.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
protocol, and allows for active transfer of near real-time DHCPv4 protocol, and allows for active transfer of near real-time DHCPv4
address binding information data via TCP. address binding information data via TCP. This document updates
RFC6926, DHCPv4 Bulk Leasequery.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). 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 December 5, 2014. This Internet-Draft will expire on September 3, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . 7
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 . . . . . . . . . . . . . . . . . 8
5.2. New or Changed Options . . . . . . . . . . . . . . . . . 7 5.2. New or Changed Options . . . . . . . . . . . . . . . . . 8
5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 7 5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . 9 6. Information Communicated by Active Leasequery . . . . . . . . 10
7. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 10 7. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 11
7.1. Connecting and General Processing . . . . . . . . . . . . 10 7.1. General Processing . . . . . . . . . . . . . . . . . . . 11
7.2. Forming an Active Leasequery . . . . . . . . . . . . . . 11 7.2. Initiating a Connection . . . . . . . . . . . . . . . . . 11
7.3. Processing Active Replies . . . . . . . . . . . . . . . . 12 7.3. Forming an Active Leasequery . . . . . . . . . . . . . . 12
7.3.1. Processing Replies from a Request Containing a query- 7.4. Processing Active Replies . . . . . . . . . . . . . . . . 13
start-time . . . . . . . . . . . . . . . . . . . . . 14 7.4.1. Processing Replies from a Request Containing a query-
7.4. Closing Connections . . . . . . . . . . . . . . . . . . . 16 start-time . . . . . . . . . . . . . . . . . . . . . 15
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 16 7.5. Closing Connections . . . . . . . . . . . . . . . . . . . 17
8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 16 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Replying to an Active Leasequery . . . . . . . . . . . . 17 8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 17
8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 19 8.2. Replying to an Active Leasequery . . . . . . . . . . . . 19
8.4. Closing Connections . . . . . . . . . . . . . . . . . . . 19 8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8.4. Closing Connections . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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
IPv4 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 entities need to keep up with the
regulatory requirements placed on service providers by governmental current IPv4 address binding activity of the DHCPv4 server. Keeping
agencies. up with address binding activity is termed "active" leasequery.
These entities need to keep up with the current IPv4 address binding
activity of the DHCPv4 server. Keeping up with address binding
activity is termed "active" leasequery.
The DHCPv4 Bulk Leasequery [RFC6926] capability can be used to The DHCPv4 Bulk Leasequery [RFC6926] capability can be used to
recover useful information from a DHCPv4 server when some external recover useful information from a DHCPv4 server when some external
entity starts up. This entity could be one which is directly entity starts up. This entity could be one which is directly
involved in the DHCPv4 client - server transactions (e.g., a relay involved in the DHCPv4 client - server transactions (e.g., a relay
agent), or it could be an external process which needs information agent), or it could be an external process which needs information
present in the DHCPv4 server's lease state database. present in the DHCPv4 server's lease state database.
The Active Leasequery capability documented here is designed to allow The Active Leasequery capability documented here is designed to allow
an entity not directly involved in DHCPv4 client - server an entity not directly involved in DHCPv4 client - server
transactions to nevertheless keep current with the state of the transactions to nevertheless keep current with the state of the
DHCPv4 lease state information in real-time. DHCPv4 lease state information in real-time.
This document updates DHCPv4 Bulk Leasequery [RFC6926] in that it
specifies the DHCPv4 server SHOULD close the TCP connection if it
receives a DHCPv4 message that is not allowed over the TCP connection
(for example, DHCPDISCOVER, DHCPLEASEQUERY).
2. Terminology 2. Terminology
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"
skipping to change at page 3, line 44 skipping to change at page 4, line 4
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 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 information about all or some of the Requesting and receiving the information about all or some of the
existing DHCPv4 address binding information in an efficient existing DHCPv4 address binding information in an efficient
manner, as defined by [RFC6926]. manner, as defined by [RFC6926].
o "blocked TCP connection"
A TCP connection is considered blocked if the underlying TCP
transport will not accept new messages to be sent without blocking
the thread that is attempting to send the message.
o "catch-up information, 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 5, line 39 skipping to change at page 6, line 7
reachability to the DHCPv4 server. The message framing for TCP is reachability to the DHCPv4 server. The message framing for TCP is
discusssed in Section 5.1. No relaying for Active Leasequery is discusssed in Section 5.1. No relaying for Active Leasequery is
specified. 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].
Since [RFC6926] did not specify what to do with an unknown message
type received over the DHCP TCP connection, system administrators
SHOULD NOT allow an DHCPACTIVELEASEQUERY message to be sent over a
DHCP TCP connection to a DHCPv4 server which does not support Active
Leasequery.
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 IPv4 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
skipping to change at page 6, line 49 skipping to change at page 7, line 26
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
discussed in the Bulk Leasequery specification [RFC6926] are to be discussed in the Bulk Leasequery specification [RFC6926] are to be
followed when implementing Active Leasequery. followed when implementing Active Leasequery.
4. Interaction Between Active Leasequery and Bulk Leasequery 4. Interaction Between Active Leasequery and Bulk Leasequery
Active Leasequery can be seen as an extension of the Bulk Leasequery Active Leasequery is an extension of the Bulk Leasequery protocol
protocol [RFC6926]. The contents of packets returned to an Active [RFC6926]. The contents of packets returned to an Active Leasequery
Leasequery requestor are identical to that defined for the Bulk requestor are identical to that defined for the Bulk Leasequery
Leasequery protocol. protocol.
Applications which employ Active Leasequery to keep a database up to Applications which employ Active Leasequery to keep a database up to
date with respect to the DHCPv4 server's lease state database will date with respect to the DHCPv4 server's lease state database will
usually use an initial Bulk Leasequery to bring their database into usually use an initial Bulk Leasequery to bring their database into
equivalence with that of the DHCPv4 server, and then use Active equivalence with that of the DHCPv4 server, and then use Active
Leasequery to keep that database current with respect to the DHCPv4 Leasequery to keep that database current with respect to the DHCPv4
server's lease state database. server's lease state database.
There are several differences between the Active and Bulk Leasequery There are several differences between the Active and Bulk Leasequery
protocols. Active Leasequery defines only one qualifier (the query- protocols. Active Leasequery defines only one qualifier (the query-
skipping to change at page 7, line 25 skipping to change at page 8, line 4
protocols. Active Leasequery defines only one qualifier (the query- protocols. Active Leasequery defines only one qualifier (the query-
start-time) and no query types, while Bulk Leasequery defines several start-time) and no query types, while Bulk Leasequery defines several
query types and qualifiers. An Active Leasequery connection sends query types and qualifiers. An Active Leasequery connection sends
all available updates to the requestor. all available updates to the requestor.
An Active Leasequery connection does not ever "complete", though the An Active Leasequery connection does not ever "complete", though the
DHCPv4 server may drop the connection for a variety of reasons DHCPv4 server may drop the connection for a variety of reasons
associated with some sort of exception condition. associated with some sort of exception condition.
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 in response to a single Active Leasequery
to determine how large each message is. The same framing technique request. The receiver needs to be able to determine how large each
used for Bulk Leasequery [RFC6926] is used for Active Leasequery. message is. The same framing technique used for Bulk Leasequery
[RFC6926] is used for Active Leasequery.
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 IPv4 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
skipping to change at page 8, line 10 skipping to change at page 8, line 35
The message type option (option 53) from [RFC2132] requires The message type option (option 53) from [RFC2132] requires
additional values. The values of these message types are shown below additional values. The values of these message types are shown below
in an extension of the table from Section 9.6 of [RFC2132]: in an extension of the table from Section 9.6 of [RFC2132]:
+-------+----------------------+ +-------+----------------------+
| Value | Message Type | | Value | Message Type |
+-------+----------------------+ +-------+----------------------+
| TBD1 | DHCPACTIVELEASEQUERY | | TBD1 | DHCPACTIVELEASEQUERY |
| TBD2 | DHCPLEASEQUERYSTATUS | | TBD2 | DHCPLEASEQUERYSTATUS |
| TBD3 | DHCPTLS |
+-------+----------------------+ +-------+----------------------+
5.2.2. dhcp-status-code 5.2.2. dhcp-status-code
The dhcp-status-code option defined in [RFC6926] allows greater The dhcp-status-code option defined in [RFC6926] allows greater
detail to be returned regarding the status of a DHCP request. While detail to be returned regarding the status of a DHCP request. While
specified in the Bulk Leasequery document, this DHCPv4 option is also specified in the Bulk Leasequery document, this DHCPv4 option is also
used in Active Leasequery. used in Active Leasequery.
This option has two possible scopes when used with Active Leasequery, This option has two possible scopes when used with Active Leasequery,
depending on the context in which it appears. It refers to the depending on the context in which it appears. It refers to the
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, DHCPLEASEUNASSIGNED or DHCPTLS. It
the message stream related to an entire request if the value of the refers to the message stream related to an entire request if the
dhcp-message-type is DHCPLEASEQUERYSTATUS. value of the 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 IPv4 address | | DataMissing | TBD4 | Indicates that IPv4 address |
| | | binding information requested is | | | | binding information |
| | | not available. | | | | requested is not available. |
| ConnectionActive | TBD4 | Indicates that this connection | | ConnectionActive | TBD5 | Indicates that this |
| | | remains active. | | | | connection remains active. |
| CatchUpComplete | TBD5 | Indicates that this Active | | CatchUpComplete | TBD6 | 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. |
+------------------+-------------+----------------------------------+ | TLSConnectionRefused | TBD7 | Indicates that a TLS |
| | | connection is not allowed. |
+----------------------+-------------+------------------------------+
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
skipping to change at page 10, line 29 skipping to change at page 11, line 14
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 IPv4 instance, the period after the expiration or release of an IPv4
address could be configured long enough (say several minutes, well address could be configured long enough (say several minutes, well
more than the receive timeout), so that an Active Leasequery more than the receive timeout), so that an Active Leasequery
requestor would never miss any changes in the client to IPv4 address requestor would never miss any changes in the client to IPv4 address
binding. binding.
7. Requestor Behavior 7. Requestor Behavior
7.1. Connecting and General Processing 7.1. 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
DHCPLEASEQUERYDONE with a dhcp-message status-code of QueryTerminated DHCPLEASEQUERYDONE with a dhcp-message status-code of QueryTerminated
or by the failure of the connection over which it was being or by the failure of the connection over which it was being
submitted, the requestor MAY retry the request after the creation of submitted, the requestor MAY retry the request after the creation of
a new connection. 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 DHCPACTIVELEASEQUERY message. Thus, each DHCPACTIVELEASEQUERY single DHCPACTIVELEASEQUERY message. Thus, each DHCPACTIVELEASEQUERY
or DHCPBULKLEASEQUERY request MUST have an xid (transaction-id) or DHCPBULKLEASEQUERY request MUST have an xid (transaction-id)
unique on the connection on which it is sent, and all of the messages unique on the connection on which it is sent, and all of the messages
which come as a response to it all contain the same xid as the which come as a response to it all contain the same xid as the
request. It is the xid which allows the data-streams of two or more request. It is the xid which allows the data-streams of two or more
different DHCPACTIVELEASEQUERY or DHCPBULKLEASEQUERY requests to be different DHCPACTIVELEASEQUERY or DHCPBULKLEASEQUERY requests to be
demultiplexed by the requestor. demultiplexed by the requestor.
A requestor MAY send a DHCPACTIVELEASEQUERY request to a DHCPv4 7.2. Initiating a Connection
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 Active Leasequery.
7.2. Forming an Active Leasequery A requestor SHOULD attempt to negotiate a TLS [RFC5246] connection
over the TCP connection. If this negotiation fails, a requestor MAY
choose to proceed with the Active Leasequery request without TLS.
A requestor requests the establishment of a TLS connection by sending
the DHCPTLS message to the DHCPv4 server as the first message over
the TCP connection. This message indicates to the DHCPv4 server that
a TLS connection over this TCP connection is desired. There are four
possibilities after the requestor sends the DHCPTLS message to the
DHCPV4 server:
1. No response from the DHCPv4 server.
2. The DHCPv4 server drops the TCP connection after it receives the
DHCPTLS message.
3. DHCPv4 server responds with DHCPTLS message with a dhcp-status-
code of TLSConnectionRefused.
4. DHCPv4 server responds with DHCPTLS message with no dhcp-status-
code, indicating success.
In any of the first three possibilities, the DHCPv4 server can be
assumed to not support TLS. In this case, the requestor MAY choose
to proceed with the Active Leasequery request without having it
protected by TLS.
In the final possibility, where the DHCPv4 server has responded with
a DHCPTLS message with no dhcp-status-code in response to the
requestor's DHCPTLS message, the requestor SHOULD initiate the
exchange of the messages involved in a TLS handshake [RFC5246].
If the handshake exchange yields a functioning TLS connection, then
the requestor SHOULD transmit an Active Leasequery message message
over that TLS connection and use that TLS connection for all further
interactions in which it engages with the DHCPv4 server over this TCP
connection.
If the handshake exchange does not yield a functioning TLS
connection, then the requestor MUST drop the TCP connection. The
requestor MAY create a new TCP connection and MAY choose to proceed
with an Active Leasequery request without using TLS.
7.3. Forming an Active Leasequery
The Active Leasequery is designed to create a long lived connection The Active Leasequery is designed to create a long lived connection
between the requestor and the DHCPv4 server processing the active between the requestor and the DHCPv4 server processing the active
query. The DHCPv4 server will send IPv4 address binding information query. The DHCPv4 server SHOULD send IPv4 address binding
back across this connection with minimal delay after it learns of the information back across this connection with minimal delay after it
binding information. It will learn about IPv4 address bindings learns of the binding information. It will learn about IPv4 address
either because it makes the bindings itself or because it has bindings either because it makes the bindings itself or because it
received information about a binding from another server. has received information about a binding from another server.
To form the Active query, a DHCPv4 request is constructed with a An Active Leasequery is a DHCPv4 request with a dhcp-message-type of
dhcp-message-type of DHCPACTIVELEASEQUERY. This DHCPv4 request MUST DHCPACTIVELEASEQUERY. The DHCPv4 request MUST NOT have a ciaddr, a
NOT have a ciaddr, a chaddr, or a dhcp-client-identifier. The DHCPv4 chaddr, or a dhcp-client-identifier. The DHCPv4 request MUST have an
request MUST contain a transaction-id, and that transaction-id MUST xid (transaction-id) unique on the connection on which it is sent.
be locally unique to the TCP connection to the DHCPv4 server. The The DHCPv4 request SHOULD have a dhcp-parameter-request-list to
DHCPv4 request SHOULD have a dhcp-parameter-request-list to inform inform the DHCPv4 server which DHCPv4 options are of interest to the
the DHCPv4 server which DHCPv4 options are of interest to the
requestor sending the DHCPACTIVELEASEQUERY message. requestor sending the DHCPACTIVELEASEQUERY message.
An important capability of the Active Leasequery is the ability of An important capability of the Active Leasequery is the ability of
the requestor to specify that some recent data be sent immediately to the requestor to specify that some recent data be sent immediately to
the requestor in parallel with the transmission of the ongoing IPv4 the requestor in parallel with the transmission of the ongoing IPv4
address binding information in more or less real time. This address binding information in more or less real time. This
capability is used in order to allow an Active Leasequery requestor capability is used in order to allow an Active Leasequery requestor
to recover missed information in the event that it temporarily loses to recover missed information in the event that it temporarily loses
connectivity with the DHCPv4 server processing a previous Active connectivity with the DHCPv4 server processing a previous Active
Leasequery. Leasequery.
Note that until all of the recent data (catch-up data) has been Note that until all of the recent data (catch-up data) has been
received, the requestor MUST NOT keep track of the base time received received, the requestor MUST NOT keep track of the base time received
in Leasequery reply messages to use later in a subsequent Bulk in Leasequery reply messages to use later in a subsequent Bulk
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 SHOULD keep track of the highest
highest base-time received from a particular DHCPv4 server over an base-time received from a particular DHCPv4 server over an Active
Active Leasequery connection, and in the event that the requestor Leasequery connection, and in the event that the requestor finds it
finds it necessary (for whatever reason) to reestablish an Active necessary (for whatever reason) to reestablish an Active Leasequery
Leasequery connection to that DHCPv4 server, the requestor will place connection to that DHCPv4 server, the requestor SHOULD place this
this highest base-time value into a query-start-time option in the highest base-time value into a query-start-time option in the new
new DHCPACTIVELEASEQUERY request. (See Sections 6.2.5 and 7.2 of DHCPACTIVELEASEQUERY request. (See Sections 6.2.5 and 7.2 of
[RFC6926] for information on the query-start-time option.) [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 terminate
to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this 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
notifications from the TCP implementations they may be using. notifications from the TCP implementations they may be using.
7.3. Processing Active Replies 7.4. Processing Active Replies
The Requestor attempts to read a DHCPv4 leasequery reply message from The Requestor attempts to read a DHCPv4 leasequery reply message from
the TCP connection. If the stream of replies becomes blocked, the the TCP connection. If the stream of replies becomes blocked, the
Requestor SHOULD be prepared to terminate the connection after Requestor SHOULD terminate the connection after
ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured
to do so. to do so.
Note that a DHCPACTIVELEASEQUERY request specifically requests the Note that a DHCPACTIVELEASEQUERY request specifically requests the
DHCPv4 server to create a long-lived connection which may not have DHCPv4 server to create a long-lived connection which may not have
data transferring continuously during its lifetime. Therefore the data transferring continuously during its lifetime. Therefore the
DHCPv4 server will send a DHCPLEASEQUERYSTATUS message with a dhcp- DHCPv4 server will send a DHCPLEASEQUERYSTATUS message with a dhcp-
status-code of ConnectionActive every ACTIVE_LQ_IDLE_TIMEOUT seconds status-code of ConnectionActive every ACTIVE_LQ_IDLE_TIMEOUT seconds
(default 60) in order for the requestor to know that the connection (default 60) in order for the requestor to know that the connection
remains alive. Note that the default for ACTIVE_LQ_RCV_TIMEOUT is remains alive. Note that the default for ACTIVE_LQ_RCV_TIMEOUT is
skipping to change at page 13, line 6 skipping to change at page 14, line 28
receive multiple copies of the IPv4 address binding information for a receive multiple copies of the IPv4 address binding information for a
particular IPv4 address. See the Bulk Leasequery document [RFC6926] particular IPv4 address. See the Bulk Leasequery document [RFC6926]
for information on how to deal with this situation. for information on how to deal with this situation.
A single Active Leasequery can and usually will result in a large A single Active 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 transaction-ids matching a single than one reply with transaction-ids matching a single
DHCPACTIVELEASEQUERY message from a single DHCPv4 server. DHCPACTIVELEASEQUERY message from a single DHCPv4 server.
A DHCPACTIVELEASEQUERY has two regimes -- during the catch-up phase, A DHCPACTIVELEASEQUERY has two regimes -- during the catch-up phase,
if any, and after any catch-up phase. During the catch-up phase (if if any, and after any catch-up phase. If the DHCPACTIVELASEQUERY
one exists), the data returned in the base-time option in a request had a query-start-time, then the DHCPACTIVELEASEQUERY starts
DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message may appear to be out in the catch-up phase. See Section 7.4.1 for information on
ordered, but the most recent change in the lease state data being processing during the catch-up phase, as well as how to determine
returned is not related to the base-time option value in the when the catch-up phase is complete.
messages. Another way to say this is that the ordering of the
updates sent by the DHCPv4 server during the catch-up phase is
independent of the ordering in the changes in the lease state data.
The base-time option from messages during this phase MUST NOT be
saved and used in a subsequent DHCPACTIVELEASEQUERY message's query-
start-time option as it does not represent the extent of progress of
the catch-up activity.
After the catch-up phase, or during the entire series of messages After the catch-up phase, or during the entire series of messages
received as the response to a DHCPACTIVELEASEQUERY request with no received as the response to a DHCPACTIVELEASEQUERY request with no
query-start-time (and therefore no catch-up phase), the base-time query-start-time (and therefore no catch-up phase), the base-time
option of the most recent message SHOULD be saved as a record of the option of the most recent message SHOULD be saved as a record of the
most recent time that data was received. This base-time (in the most recent time that data was received. This base-time (in the
context of the DHCPv4 server) can be used in a subsequent context of the DHCPv4 server) can be used in a subsequent
DHCPACTIVELEASEQUERY message's query-start-time, or in a DHCPACTIVELEASEQUERY message's query-start-time, or in a
DHCPBULKLEASEQUERY message's query-start-time if one is required, DHCPBULKLEASEQUERY message's query-start-time if one is required,
after a loss of the Active Leasequery connection. after a loss of the Active Leasequery connection.
skipping to change at page 14, line 5 skipping to change at page 15, line 17
After receiving DHCPLEASEQUERYSTATUS with a QueryTerminated status After receiving DHCPLEASEQUERYSTATUS with a QueryTerminated status
from a server, the Requestor MAY close the TCP connection to that from a server, the Requestor MAY close the TCP connection to that
server. server.
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.4.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 IPv4 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 IPv4 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.
skipping to change at page 14, line 38 skipping to change at page 15, line 50
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 IPv4 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 The updates sent by the DHCPv4 server during the catch-up phase are
not in the order that the lease state data was updated. Therefore,
until the catch-up phase is complete, the latest base-time value
received from a DHCPv4 server processing an Active Leasequery request 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 (and used in a subsequent
Active Leasequery's query-start-time option), because to do so would
compromise the ability to recover lost information if the 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 (or, as discussed above,
transmitted, all additional DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED DataMissing). Once this message is transmitted, all additional
messages will relate to real-time ("new") IPv4 address binding DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages will relate to real-
changes in the DHCPv4 server. time ("new") IPv4 address binding 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 35 skipping to change at page 16, line 49
every IPv4 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 IPv4 address Active Leasequery reply message will exist for every IPv4 address
which had one or more changes of state during the period specified by which had one or more changes of state during the period specified by
the query-start-time and the current time. The last message for each the query-start-time and the current time. The last message for each
IPv4 address will contain the state at the current time, and there IPv4 address will contain the state at the current time, and there
may be one or more messages concerning a single IPv4 address during may be one or more messages concerning a single IPv4 address during
the catch-up phase of processing. the catch-up phase of processing.
If an IPv4 address changed state multiple times during the time that Bindings can change multiple times while the requestor is not
the requestor was not connected (that is, during the time from the connected. The requestor will only receive information about the
query-start-time and the present), then only the current IPv4 address current state of the binding, not information about each state change
binding information will be sent during the catch-up phase. Thus,
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.
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 IPv4 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
message with a dhcp-status-code of DataMissing, it is a reasonable
assumption that it is interested in keeping its database up to date
with respect to the DHCPv4 server's internal IPv4 address binding
database or it would not have included the query-start-time in the
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.
Alternatively, both requests could be issued over a single Alternatively, both requests could be issued over a single
connection. connection.
7.4. Closing Connections 7.5. Closing Connections
The Requestor or DHCPv4 leasequery server MAY close its end of the The Requestor or DHCPv4 leasequery server MAY close its end of the
TCP connection at any time. The Requestor MAY choose to retain the TCP connection at any time. The Requestor MAY choose to retain the
connection if it intends to issue additional queries. Note that this connection if it intends to issue additional queries. Note that this
client behavior does not guarantee that the connection will be client behavior does not guarantee that the connection will be
available for additional queries: the server might decide to close available for additional queries: the server might decide to close
the connection based on its own configuration. the connection based on its own configuration.
8. Server Behavior 8. Server Behavior
A DHCPv4 server which supports Active Leasequery MUST support Bulk A DHCPv4 server which supports Active Leasequery MUST support Bulk
Leasequery [RFC6926] as well. Leasequery [RFC6926] as well.
8.1. Accepting Connections 8.1. Accepting Connections
Servers that implement DHCPv4 Active Leasequery listen for incoming DHCPv4 servers that implement DHCPv4 Active Leasequery listen for
TCP connections. Port numbers are discussed in Section 5.3. Servers incoming TCP connections. Port numbers are discussed in Section 5.3.
MUST be able to limit the number of currently accepted and active DHCPv4 servers MUST be able to limit the number of currently accepted
connections. The value BULK_LQ_MAX_CONNS MUST be the default; and active connections. The value BULK_LQ_MAX_CONNS MUST be the
implementations MAY permit the value to be configurable. Connections default; implementations MAY permit the value to be configurable.
SHOULD be accepted and, if the number of connections is over Connections SHOULD be accepted and, if the number of connections is
BULK_LQ_MAX_CONNS, they SHOULD be closed immediately. over BULK_LQ_MAX_CONNS, they SHOULD be closed immediately.
Servers MAY restrict Active Leasequery connections and DHCPv4 servers MAY restrict Active Leasequery connections and
DHCPACTIVELEASEQUERY messages to certain clients. Connections not DHCPACTIVELEASEQUERY messages to certain clients. Connections not
from permitted clients SHOULD be closed immediately, to avoid server from permitted clients SHOULD be closed immediately, to avoid server
connection resource exhaustion. connection resource exhaustion.
DHCPv4 servers SHOULD support TLS [RFC5246] to protect the integrity
and privacy of the data transmitted over the TCP connection. DHCPv4
servers SHOULD negotiate a TLS connection with a requestor who asks
for one, and MAY choose to accept DHCPACTIVELEASEQUERY messages over
connections which are not secured with TLS.
A requestor will request a TLS connection by sending a DHCPTLS as the
first message over a newly created TCP connection. If the DHCPv4
server supports TLS connections and has not been configured to not
allow them on this link, the DHCPv4 server SHOULD respond to this
DHCPTLS message by sending a DHCPTLS message with no dhcp-status-code
back to the requestor. This indicates to the requestor that the
DHCPv4 server will support the negotiation of a TLS connection over
this existing TCP connection.
If for some reason the DHCPv4 server cannot or has been configured to
not support a TLS connection, then it SHOULD send a DHCPTLS message
with a dhcp-status-code of TLSConnectionRefused back to the
requestor.
In the event that the DHCPv4 server sends a DHCPTLS message with no
dhcp-status-code option included (which indicates success), the
requestor is supposed to initiate a TLS handshake [RFC5246] (see
Section 7.2).
If the TLS handshake is not successful in creating a TLS connection,
the server MUST drop the TCP connection.
In an update to the DHCPv4 Bulk Leasequery protocol [RFC6926] (which
didn't discuss this situation explicitly), if the DHCPv4 server
receives a DHCPv4 message containing a dhcp-message-type option with
a value that is not supported over a TCP connection, it SHOULD drop
the TCP 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 terminate the connection
connection after a BULK_LQ_DATA_TIMEOUT. We make this recommendation after a BULK_LQ_DATA_TIMEOUT. We make this recommendation to allow
to allow servers to control the period of time they are willing to servers to control the period of time they are willing to wait before
wait before abandoning an inactive connection, independent of the TCP abandoning an inactive connection, independent of the TCP
implementations they may be using. implementations they may be using.
8.2. Replying to an Active Leasequery 8.2. Replying to an Active 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 terminate the TCP connection
TCP connection after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs how long the
how much congestion the DHCPv4 server is prepared to tolerate over DHCPv4 server is prepared to wait for the requestor to read and
any Active Leasequery connection. The default is two minutes, which process enough information to unblock the TCP connection. The
means that if more than two minutes goes by without the requestor default is two minutes, which means that if more than two minutes
reading enough information to unblock the TCP connection, the DHCPv4 goes by without the requestor reading enough information to unblock
server will drop the TCP connection. the TCP connection, the DHCPv4 server SHOULD drop the TCP connection.
If the DHCPv4 server encounters an error during processing of the If the DHCPv4 server encounters an error during processing of the
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
skipping to change at page 19, line 40 skipping to change at page 21, line 31
that are able to process queries in parallel SHOULD offer that are able to process queries in parallel SHOULD offer
configuration that limits the number of simultaneous queries configuration that limits the number of simultaneous queries
permitted from any one requestor, in order to control resource use if permitted from any one requestor, in order to control resource use if
there are multiple requestors seeking service. there are multiple requestors seeking service.
8.4. Closing Connections 8.4. Closing Connections
The server MAY close its end of the TCP connection after sending its The server MAY close its end of the TCP connection after sending its
last message, a DHCPLEASEQUERYSTATUS message in response to a query. last message, a DHCPLEASEQUERYSTATUS message in response to a query.
Alternatively, the server MAY retain the connection and wait for Alternatively, the server MAY retain the connection and wait for
additional queries from the client. The server SHOULD be prepared to additional queries from the client. The server SHOULD limit the
limit the number of connections it maintains, and SHOULD be prepared number of connections it maintains, and SHOULD close idle connections
to close idle connections to enforce the limit. to enforce the limit.
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 clients by using the QueryTerminated attempt to signal that to its clients by using the QueryTerminated
status code in the dhcp-status-code option in a DHCPLEASEQUERYSTATUS status code in the dhcp-status-code option in a DHCPLEASEQUERYSTATUS
message. If the server detects that the client end has been closed, message. If the server detects that the client end has been closed,
the server MUST close its end of the connection after it has finished the server MUST close its end of the connection after it has finished
processing any outstanding requests. processing any outstanding requests.
skipping to change at page 20, line 30 skipping to change at page 22, line 21
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.
Servers which implement the Bulk Leasequery protocol [RFC6926] but do
not implement the Active Leasequery protocol SHOULD implement the
update to [RFC6926] discussed in section Section 8.1.
There are two specific issues regarding Active Leasequery security
that deserve explicit mention. The first is preventing information
that Active Leasequery can provide from reaching requestors who are
not authorized to receive such information. The second is ensuring
that authorized requestors of the Active Leasequery capability
receive accurate information from the Server (and that this
information is not disrupted in transit).
Requestors and servers SHOULD use TLS [RFC5246] to protect the
integrity and privacy of the Active Leasequery data transmitted over
the TCP connection.
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 the registry "DHCP Message Type 53 Values" maintained at
http://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.
3. A dhcp-message-type of TBD3 for DHCPTLS.
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 the registry "DHCP Status Code Type 151 Values" maintained at
http://www.iana.org/assignments/bootp-dhcp-parameters: http://www.iana.org/assignments/bootp-dhcp-parameters:
+------------------+-------------+ +----------------------+-------------+
| Name | status-code | | Name | status-code |
+------------------+-------------+ +----------------------+-------------+
| DataMissing | TBD3 | | DataMissing | TBD4 |
| ConnectionActive | TBD4 | | ConnectionActive | TBD5 |
| CatchUpComplete | TBD5 | | CatchUpComplete | TBD6 |
+------------------+-------------+ | TLSConnectionRefused | TBD7 |
+----------------------+-------------+
11. Acknowledgements 11. Acknowledgements
The ideas in this document came in part from work in DHCPv6 and The ideas in this document came in part from work in DHCPv6 and
DHCPv4 Bulk Leasequery as well as from in depth discussions between DHCPv4 Bulk Leasequery as well as from in depth discussions between
the authors. the authors.
12. References 12. References
12.1. Normative References 12.1. Normative References
skipping to change at page 21, line 27 skipping to change at page 23, line 36
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
Protocol (DHCP) Leasequery", RFC 4388, February 2006. Protocol (DHCP) Leasequery", RFC 4388, February 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6926] Kinnear, K., Stapp, M., Desetti, R., Joshi, B., Russell, [RFC6926] Kinnear, K., Stapp, M., Desetti, R., Joshi, B., Russell,
N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery", N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery",
RFC 6926, April 2013. RFC 6926, April 2013.
12.2. Informative References 12.2. Informative References
[RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985. September 1985.
[RFC1542] Wimer, W., "Clarifications and Extensions for the [RFC1542] Wimer, W., "Clarifications and Extensions for the
 End of changes. 51 change blocks. 
159 lines changed or deleted 257 lines changed or added

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