draft-ietf-dhc-dhcpv4-active-leasequery-03.txt   draft-ietf-dhc-dhcpv4-active-leasequery-04.txt 
Network Working Group K. Kinnear Network Working Group K. Kinnear
Internet-Draft M. Stapp Internet-Draft M. Stapp
Updates: 6926 (if approved) B. Volz Updates: 6926 (if approved) B. Volz
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: December 12, 2015 N. Russell Expires: February 12, 2016 N. Russell
Staples Staples
June 10, 2015 August 11, 2015
Active DHCPv4 Lease Query Active DHCPv4 Lease Query
draft-ietf-dhc-dhcpv4-active-leasequery-03.txt draft-ietf-dhc-dhcpv4-active-leasequery-04.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 requestor to
information about DHCPv4 bindings. That mechanism is limited to request information about DHCPv4 bindings. That mechanism is limited
queries for individual bindings. In some situations individual to 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 requestor 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. This document updates address binding information data via TCP. This document updates
RFC6926, DHCPv4 Bulk Leasequery. 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 12, 2015. This Internet-Draft will expire on February 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . 7 4. Interaction Between Active Leasequery and Bulk Leasequery . . 7
5. Message and Option Definitions . . . . . . . . . . . . . . . 8 5. Message and Option Definitions . . . . . . . . . . . . . . . 8
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 8 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 8
5.2. New or Changed Options . . . . . . . . . . . . . . . . . 8 5.2. New or Changed Options . . . . . . . . . . . . . . . . . 8
5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 8 5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 8
5.2.2. dhcp-status-code . . . . . . . . . . . . . . . . . . 8 5.2.2. dhcp-status-code . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . 10
7. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 11 7. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 11
7.1. General Processing . . . . . . . . . . . . . . . . . . . 11 7.1. General Processing . . . . . . . . . . . . . . . . . . . 11
7.2. Initiating a Connection . . . . . . . . . . . . . . . . . 11 7.2. Initiating a Connection . . . . . . . . . . . . . . . . . 11
7.3. Forming an Active Leasequery . . . . . . . . . . . . . . 12 7.3. Forming an Active Leasequery . . . . . . . . . . . . . . 12
7.4. Processing Active Replies . . . . . . . . . . . . . . . . 13 7.4. Processing Active Replies . . . . . . . . . . . . . . . . 13
7.4.1. Processing Replies from a Request Containing a query- 7.4.1. Processing Replies from a Request Containing a query-
start-time . . . . . . . . . . . . . . . . . . . . . 15 start-time . . . . . . . . . . . . . . . . . . . . . 15
7.5. Closing Connections . . . . . . . . . . . . . . . . . . . 17 7.5. Closing Connections . . . . . . . . . . . . . . . . . . . 17
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 17 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 17 8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 18
8.2. Replying to an Active Leasequery . . . . . . . . . . . . 19 8.2. Replying to an Active Leasequery . . . . . . . . . . . . 19
8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 21 8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 22
8.4. Closing Connections . . . . . . . . . . . . . . . . . . . 21 8.4. Closing Connections . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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
skipping to change at page 5, line 40 skipping to change at page 5, line 40
o "requestor" o "requestor"
The node that sends LEASEQUERY messages to one or more servers to The node that sends LEASEQUERY messages to one or more servers to
retrieve information on the bindings for a client. 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 [RFC7414] connection required for Active
addition, a DHCPv4 server which supports Active Leasequery MUST Leasequery. In addition, a DHCPv4 server which supports Active
support Bulk Leasequery [RFC6926] as well. Leasequery MUST support Bulk Leasequery [RFC6926] as well.
An Active Leasequery client opens a TCP connection to a DHCPv4 An Active Leasequery requestor 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 the server IPv4 address(es) available via Leasequery requestor 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. The message framing for TCP is reachability to the DHCPv4 server. The message framing for TCP is
discussed in Section 5.1. No relaying for Active Leasequery is discussed 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 requestor 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]. This response procedure is
similar to the procedure specified in [RFC6926], except that in the
case of Active Leasequery the server sends updates whenever some
activity occurs to change the binding state -- thus the need for the
long lived connection. Additionally, the Active Leasequery server
SHOULD provide a mechanism to control which data is allowed to be
included in the messages sent to the requestor. See Section 8.2.
Since [RFC6926] did not specify what to do with an unknown message Since [RFC6926] did not specify what to do with an unknown message
type received over the DHCP TCP connection, system administrators type received over the DHCP TCP connection, system administrators
SHOULD NOT allow an DHCPACTIVELEASEQUERY message to be sent over a SHOULD NOT allow an DHCPACTIVELEASEQUERY message to be sent over a
DHCP TCP connection to a DHCPv4 server which does not support Active DHCP TCP connection to a DHCPv4 server which does not support Active
Leasequery. 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.
skipping to change at page 6, line 42 skipping to change at page 6, line 48
occur when the Active Leasequery requestor becomes disconnected from occur when the Active Leasequery requestor becomes disconnected from
the DHCPv4 server from which it is receiving updates and then becomes the DHCPv4 server from which it is receiving updates and then becomes
reconnected to that server. reconnected to that server.
Central to this approach, if the Active Leasequery requestor loses Central to this approach, if the Active Leasequery requestor loses
service, it is allowed to specify the time of its most recent update service, it is allowed to specify the time of its most recent update
in a subsequent Active Leasequery request and the DHCPv4 server will in a subsequent Active Leasequery request and the DHCPv4 server will
determine whether or not data was missed while the Active Leasequery determine whether or not data was missed while the Active Leasequery
requestor was not connected. requestor was not connected.
The DHCP server processing the Active Leasequery request may limit The DHCP server processing the Active Leasequery request MAY limit
the amount of data saved, and methods exist for the DHCPv4 server to the amount of data saved, and methods exist for the DHCPv4 server to
inform the Active Leasequery requestor that more data was missed than inform the Active Leasequery requestor that more data was missed than
could be saved. In this situation, the Active Leasequery requestor could be saved. In this situation, the Active Leasequery requestor
would issue a Bulk Leasequery [RFC6926] to recover information not would issue a Bulk Leasequery [RFC6926] to recover information not
available through an Active Leasequery. available through an Active Leasequery.
DHCPv4 servers are not required to keep any data corresponding to DHCPv4 servers are not required to keep any data corresponding to
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 requestor 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 IPv4 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
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, with the exception that
a server responding to an Active Leasequery request SHOULD be able to
be configured to prevent specific data items from being included in
the response to the requestor even if they were requested by
inclusion in the dhcp-parameter-request-list option.
4. Interaction Between Active Leasequery and Bulk Leasequery 4. Interaction Between Active Leasequery and Bulk Leasequery
Active Leasequery is an extension of the Bulk Leasequery protocol Active Leasequery is an extension of the Bulk Leasequery protocol
[RFC6926]. The contents of packets returned to an Active Leasequery [RFC6926]. The contents of packets returned to an Active Leasequery
requestor are identical to that defined for the Bulk Leasequery requestor are identical to that defined for the Bulk 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 should date with respect to the DHCPv4 server's lease state database should
skipping to change at page 7, line 47 skipping to change at page 8, line 9
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-
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 can close 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 in response to a single Active Leasequery DHCPv4 messages to be sent in response to a single Active Leasequery
request. The receiver needs to be able to determine how large each request. The receiver needs to be able to determine how large each
message is. The same framing technique used for Bulk Leasequery message is. The same framing technique used for Bulk Leasequery
[RFC6926] is used for Active Leasequery. [RFC6926] is used for Active Leasequery.
When using TLS to secure a connection [RFC5246], the message framing
for TLS uses the same format as that used for TCP. One DHCP message
is carried in one TLS record.
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
message types and option types are defined for Active Leasequery, as message types and option types are defined for Active Leasequery, as
skipping to change at page 11, line 27 skipping to change at page 11, line 31
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.
different DHCPACTIVELEASEQUERY or DHCPBULKLEASEQUERY requests to be
demultiplexed by the requestor.
7.2. Initiating a Connection 7.2. Initiating a Connection
A requestor should be able to operate in either insecure or secure A requestor should be able to operate in either insecure or secure
mode. This MAY be a feature that is administratively controlled. mode. This MAY be a feature that is administratively controlled.
When operating in insecure mode, the requestor should proceed with When operating in insecure mode, the requestor SHOULD proceed to send
the Active Leasequery request after the establishment of a TCP a DHCPACTIVELEASEQUERY request after the establishment of a TCP
connection. connection.
When operating in secure mode, the requestor MUST attempt to When operating in secure mode, the requestor MUST attempt to
negotiate a TLS [RFC5246] connection over the TCP connection. If negotiate a TLS [RFC5246] connection over the TCP connection. If
this negotiation fails, the requestor must drop the TCP connection. this negotiation fails, the requestor must close the TCP connection.
The recommendations in [RFC7525] SHOULD be followed when negotiating
this connection.
A requestor requests the establishment of a TLS connection by sending A requestor requests the establishment of a TLS connection by sending
the DHCPTLS message to the DHCPv4 server as the first message over the DHCPTLS message to the DHCPv4 server as the first message over
the TCP connection. This message indicates to the DHCPv4 server that the TCP connection. The DHCPTLS message SHOULD be sent without any
a TLS connection over this TCP connection is desired. There are four options. 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 possibilities after the requestor sends the DHCPTLS message to the
DHCPV4 server: DHCPV4 server:
1. No response from the DHCPv4 server. 1. No response from the DHCPv4 server.
2. The DHCPv4 server drops the TCP connection after it receives the 2. The DHCPv4 server closes the TCP connection after it receives the
DHCPTLS message. DHCPTLS message.
3. DHCPv4 server responds with a DHCPTLS message with a dhcp-status- 3. DHCPv4 server responds with a DHCPTLS message with a dhcp-status-
code of TLSConnectionRefused. code of TLSConnectionRefused.
4. DHCPv4 server responds with DHCPTLS message with no dhcp-status- 4. DHCPv4 server responds with DHCPTLS message with no dhcp-status-
code, indicating success. code, indicating success.
In any of the first three possibilities, the DHCPv4 server can be In any of the first three possibilities, the DHCPv4 server can be
assumed to not support TLS. In this case, the requestor MUST drop assumed to not support TLS. In this case, the requestor MUST close
the connection. the connection.
In the final possibility, where the DHCPv4 server has responded with In the final possibility, where the DHCPv4 server has responded with
a DHCPTLS message with no dhcp-status-code in response to the a DHCPTLS message with no dhcp-status-code in response to the
requestor's DHCPTLS message, the requestor SHOULD initiate the requestor's DHCPTLS message, the requestor SHOULD initiate the
exchange of the messages involved in a TLS handshake [RFC5246]. exchange of the messages involved in a TLS handshake [RFC5246].
During the TLS handshake, the requestor MUST verify the DHCPv4 During the TLS handshake, the requestor MUST validate the DHCPv4
server's digital certificates. server's digital certificates.
If the handshake exchange yields a functioning TLS connection, then If the handshake exchange yields a functioning TLS connection, then
the requestor SHOULD transmit an Active Leasequery message over that the requestor SHOULD transmit an DHCPACTIVELEASEQUERY message over
TLS connection and use that TLS connection for all further that TLS connection and use that TLS connection for all further
interactions in which it engages with the DHCPv4 server over this TCP interactions in which it engages with the DHCPv4 server over this TCP
connection. connection.
If the handshake exchange does not yield a functioning TLS If the handshake exchange does not yield a functioning TLS
connection, then the requestor MUST drop the TCP connection. connection, then the requestor MUST close the TCP connection.
7.3. Forming an Active Leasequery 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 SHOULD send IPv4 address binding query. The DHCPv4 server SHOULD send IPv4 address binding
information back across this connection with minimal delay after it information back across this connection with minimal delay after it
learns of the binding information. It will learn about IPv4 address learns of the binding information. It will learn about IPv4 address
bindings either because it makes the bindings itself or because it bindings either because it makes the bindings itself or because it
has received information about a binding from another server. has received information about a binding from another server.
skipping to change at page 14, line 4 skipping to change at page 14, line 10
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 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 SHOULD 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. This approach is followed only when the connection is
120 seconds, twice the value of the ACTIVE_LQ_IDLE_TIMEOUT's default idle (i.e., the server has no binding data to send). During normal
of 60 seconds which drives the DHCPv4 server to send messages. Thus binding data exchange, receiving DHCPLEASEACTIVE or
ACTIVE_LQ_RCV_TIMEOUT controls how sensitive the requestor is to be DHCPLEASEUNASSIGNED messages by the requestor itself signifies that
to delays by the DHCPv4 server in sending updates or the connection is active. Note that the default for
DHCPLEASEQUERYSTATUS messages. ACTIVE_LQ_RCV_TIMEOUT is 120 seconds, twice the value of the
ACTIVE_LQ_IDLE_TIMEOUT's default of 60 seconds which drives the
DHCPv4 server to send messages. Thus ACTIVE_LQ_RCV_TIMEOUT controls
how sensitive the requestor is to be to delays by the DHCPv4 server
in sending updates or DHCPLEASEQUERYSTATUS messages.
A successful query that is returning binding data MUST include a non- A successful query that is returning binding data MUST include a non-
zero ciaddr. It may also include a non-zero chaddr, htype, and hlen zero ciaddr. It may also include a non-zero chaddr, htype, and hlen
as well as additional options. If there are additional bindings to as well as additional options. If there are additional bindings to
be returned, they will be carried in additional Active Leasequery be returned, they will be carried in additional Active Leasequery
messages. messages.
Any requestor of an Active Leasequery operation MUST be prepared to Any requestor of an Active Leasequery operation MUST be prepared to
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]
skipping to change at page 15, line 7 skipping to change at page 15, line 17
after a loss of the Active Leasequery connection. after a loss of the Active Leasequery connection.
The DHCPLEASEQUERYSTATUS message MAY unilaterally terminate a The DHCPLEASEQUERYSTATUS message MAY unilaterally terminate a
successful DHCPACTIVELEASEQUERY request which is currently in successful DHCPACTIVELEASEQUERY request which is currently in
progress in the event that the DHCPv4 server determines that it progress in the event that the DHCPv4 server determines that it
cannot continue processing a DHCPACTIVELEASEQUERY request. For cannot continue processing a DHCPACTIVELEASEQUERY request. For
example, when a server is requested to shut down it SHOULD send a example, when a server is requested to shut down it SHOULD send a
DHCPLEASEQUERYSTATUS message with a dhcp-status-code of DHCPLEASEQUERYSTATUS message with a dhcp-status-code of
QueryTerminated and include in the message a base time. This SHOULD QueryTerminated and include in the message a base time. This SHOULD
be the last message on that connection, and once the message has been be the last message on that connection, and once the message has been
transmitted, the server should close the connection. transmitted, the server SHOULD close the connection.
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.4.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 can 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. In such
should occur, and there is not enough data saved in the DHCPv4 server case, when there is not enough data saved in the DHCPv4 server to
to satisfy the request specified by the query-start-time option, the satisfy the request specified by the query-start-time option, the
DHCPv4 server will reply immediately with a DHCPLEASEQUERYSTATUS DHCPv4 server will reply immediately with a DHCPLEASEQUERYSTATUS
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
skipping to change at page 16, line 49 skipping to change at page 17, line 13
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 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 can be one or more messages concerning a single IPv4 address during
the catch-up phase of processing. the catch-up phase of processing.
Bindings can change multiple times while the requestor is not Bindings can change multiple times while the requestor is not
connected. The requestor will only receive information about the connected. The requestor will only receive information about the
current state of the binding, not information about each state change current state of the binding, not information about each 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. 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 option, set to the same value as the query-start-time
included in the DHCPACTIVELEASEQUERY responses from the DHCPv4 option previously included in the DHCPACTIVELEASEQUERY responses from
server, and a query-end-time equal to the base-time returned by the the DHCPv4 server, and a query-end-time option equal to the base-time
DHCPv4 server in the DHCPLEASEQUERYSTATUS message with the dhcp- option returned by the DHCPv4 server in the DHCPLEASEQUERYSTATUS
status-code of DataMissing. message with the dhcp-status-code of DataMissing.
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
connection.
7.5. 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 requestor 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
DHCPv4 servers that implement DHCPv4 Active Leasequery listen for DHCPv4 servers that implement DHCPv4 Active Leasequery listen for
incoming TCP connections. The approach used in accepting the incoming TCP connections. The approach used in accepting the
requestor's connection is the same as specified in DHCPv4 Bulk requestor's connection is the same as specified in DHCPv4 Bulk
Leasequery [RFC6926]. Leasequery [RFC6926], with the exception that support for Active
Leasequery MUST NOT be enabled by default, and MUST require an
explicit configuration step to be performed before it will operate.
DHCPv4 servers SHOULD be able to operate in either an insecure or DHCPv4 servers SHOULD be able to operate in either insecure or secure
secure mode. This MAY be a mode that is administratively controlled, mode. This MAY be a mode that is administratively controlled, where
where the server will require a TLS connection to operate or will the server will require a TLS connection to operate or will only
only operate without a TLS connection. Alternatively, the server MAY operate without a TLS connection. In either case, operation in
allow the client to select the mode through transmission of a DHCPTLS insecure mode MUST NOT be the default, even if operation in secure
to select the secure mode or transmission of an Active Leasequery mode is not supported. Operation in insecure mode MUST always
request to select the insecure mode. require an explicit configuration step, separate from the
configuration step required to enable support for Active Leasequery.
When operating in insecure mode, the DHCPv4 server simply waits for When operating in insecure mode, the DHCPv4 server simply waits for
the requestor to send the Active Leasequery after the establishment the requestor to send the Active Leasequery after the establishment
of TCP connection. If it receives a DHCPTLS message, it will respond of TCP connection. If it receives a DHCPTLS message, it will respond
with TLSConnectionRefused in a DHCPTLS message. with TLSConnectionRefused in a DHCPTLS message.
When operating in secure mode, DHCPv4 servers MUST support TLS When operating in secure mode, DHCPv4 servers MUST support TLS
[RFC5246] to protect the integrity and privacy of the data [RFC5246] to protect the integrity and privacy of the data
transmitted over the TCP connection. DHCPv4 servers SHOULD negotiate transmitted over the TCP connection. When operating in secure mode,
a TLS connection with the requestor who asks for one, and MUST drop DHCPv4 servers MUST be configurable with regard to which requestors
the TCP connections which are not secured with TLS. they will communicate. The certificate presented by a requestor when
initiating the TLS connection is used to distinguish between
acceptable and unacceptable requestors.
When allowing the requestor to select the mode, the DHCPv4 server When operating in secure mode, a DHCPv4 server MUST begin to
will accept either an Active Leasequery request or a DHCPTLS message negotiate a TLS connection with a requestor who asks for one, and
after the establishment of the TCP connection, and continue its MUST close TCP connections which are not secured with TLS or for
processing based on the message received. which the requestor's certificate is deemed unacceptable. The
recommendations in [RFC7525] SHOULD be followed when negotiating a
TLS connection.
A requestor will request a TLS connection by sending a DHCPTLS as the A requestor will request a TLS connection by sending a DHCPTLS as the
first message over a newly created TCP connection. If the DHCPv4 first message over a newly created TCP connection. If the DHCPv4
server supports TLS connections and has not been configured to not server supports TLS connections and has not been configured to not
allow them on this link, the DHCPv4 server SHOULD respond to this allow them on this link, the DHCPv4 server MUST respond to this
DHCPTLS message by sending a DHCPTLS message with no dhcp-status-code DHCPTLS message by sending a DHCPTLS message with no dhcp-status-code
back to the requestor. This indicates to the requestor that the back to the requestor. This indicates to the requestor that the
DHCPv4 server will support the negotiation of a TLS connection over DHCPv4 server will support the negotiation of a TLS connection over
this existing TCP connection. this existing TCP connection.
Any options appearing in a DHCPTLS message received by a DHCPv4
server SHOULD be ignored.
If for some reason the DHCPv4 server cannot or has been configured to 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 not support a TLS connection, then it SHOULD send a DHCPTLS message
with a dhcp-status-code of TLSConnectionRefused back to the with a dhcp-status-code of TLSConnectionRefused back to the
requestor. requestor.
In the event that the DHCPv4 server sends a DHCPTLS message with no In the event that the DHCPv4 server sends a DHCPTLS message with no
dhcp-status-code option included (which indicates success), the dhcp-status-code option included (which indicates success), the
requestor is supposed to initiate a TLS handshake [RFC5246] (see requestor is supposed to initiate a TLS handshake [RFC5246] (see
Section 7.2). During the TLS handshake, the DHCPv4 server MUST Section 7.2). During the TLS handshake, the DHCPv4 server MUST
verify the requestor's digital certificate. validate the requestor's digital certificate. In addition, the
digitial certificate presented by the requestor is used to decide if
this requestor is allowed to perform an Active Leasequery. If this
requestor's certificate is deemed unacceptable, the server MUST abort
the creation of the TLS connection.
If the TLS handshake is not successful in creating a TLS connection, If the TLS handshake is not successful in creating a TLS connection,
the server MUST drop the TCP connection. the server MUST close the TCP connection.
In an update to the DHCPv4 Bulk Leasequery protocol [RFC6926] (which In an update to the DHCPv4 Bulk Leasequery protocol [RFC6926] (which
didn't discuss this situation explicitly), if the DHCPv4 server didn't discuss this situation explicitly), if the DHCPv4 server
receives a DHCPv4 message containing a dhcp-message-type option with receives a DHCPv4 message containing a dhcp-message-type option with
a value that is not supported over a TCP connection, it SHOULD drop a value that is not supported over a TCP connection, it SHOULD close
the TCP connection. 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 terminate the connection connection or reading a query, it SHOULD terminate the connection
after a BULK_LQ_DATA_TIMEOUT. We make this recommendation to allow after a BULK_LQ_DATA_TIMEOUT. We make this recommendation to allow
servers to control the period of time they are willing to wait before servers to control the period of time they are willing to 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 terminate the TCP connection send reply messages, the server SHOULD terminate the TCP connection
after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs how long the after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs how long the
DHCPv4 server is prepared to wait for the requestor to read and DHCPv4 server is prepared to wait for the requestor to read and
process enough information to unblock the TCP connection. The process enough information to unblock the TCP connection. The
default is two minutes, which means that if more than two minutes default is two minutes, which means that if more than two minutes
goes by without the requestor reading enough information to unblock goes by without the requestor reading enough information to unblock
the TCP connection, the DHCPv4 server SHOULD drop the TCP connection. the TCP connection, the DHCPv4 server SHOULD close 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
[RFC6926]. [RFC6926], with the exception that a server implementing Active
Leasequery SHOULD be able to be configured to prevent specific data
items from being sent to the requestor even if these data items were
requested in the dhcp-parameter-request-list option..
Some servers can be configured to respond to a DHCPv4 Leasequery Some servers can be configured to respond to a DHCPv4 Leasequery
[RFC4388] or a DHCPBULKLEASEQUERY [RFC6926] for an IPv4 address which [RFC4388] or a DHCPBULKLEASEQUERY [RFC6926] for an IPv4 address which
is reserved in such a way that it appears that the IPv4 address is 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 leased to the DHCP client for which it is reserved. These servers
SHOULD also respond to a DHCPACTIVELEASEQUERY request with the same SHOULD also respond to a DHCPACTIVELEASEQUERY request with the same
information as they would to a DHCPBULKLEASEQUERY request when they information as they would to a DHCPBULKLEASEQUERY request when they
first determine that the IPv4 address is reserved to a DHCP client. 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,
skipping to change at page 20, line 33 skipping to change at page 21, line 16
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, but is not required to, keep track of a The DHCPv4 server SHOULD, but is not required to, keep track of a
limited amount of previous address binding activity and associate it limited amount of previous address binding activity and associate it
with base-time values. The DHCPv4 server MAY choose to only do this with base-time values. The DHCPv4 server MAY choose to only do this
in the event that it has received at least one DHCPACTIVELEASEQUERY in the event that it has received at least one DHCPACTIVELEASEQUERY
request in the past, as to do so will almost certainly entail some request in the past, as to do so will almost certainly entail some
utilization of resources which would be wasted if there are no utilization of resources which would be wasted if there are no
DHCPACTIVELEASEQUERY clients for this DHCPv4 server. The DHCPv4 DHCPACTIVELEASEQUERY requestors for this DHCPv4 server. The DHCPv4
server SHOULD make the amount of previous address binding activity it server SHOULD make the amount of previous address binding activity it
retains configurable. There is no requirement on the DHCPv4 server retains configurable. There is no requirement on the DHCPv4 server
to retain this information over a server restart (or even to retain to retain this information over a server restart (or even to retain
such information at all). 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 requestor or the server closes the connection.
While the form of the data being sent by a DHCPACTIVELEASEQUERY is While the form of the data being sent by a DHCPACTIVELEASEQUERY is
essentially the same as that being sent by a DHCPBULKLEASEQUERY, the essentially the same as that being sent by a DHCPBULKLEASEQUERY, the
reasons for sending information differs considerably between these reasons for sending information differs considerably between these
two capabilities. In the DHCPBULKLEASEQUERY context, the entire two capabilities. In the DHCPBULKLEASEQUERY context, the entire
contents of the lease state database (subject to the constraints of contents of the lease state database (subject to the constraints of
the various query options) are returned to the requestor. In the the various query options) are returned to the requestor. In the
DHCPACTIVELEASEQUERY context, changes to the lease state database are DHCPACTIVELEASEQUERY context, changes to the lease state database are
returned to the requestor essentially as they happen. For instance, returned to the requestor essentially as they happen. For instance,
when an IPv4 address transitions from the leased state to some other when an IPv4 address transitions from the leased state to some other
state, the DHCPACTIVELEASEQUERY will send a DHCPLEASEUNASSIGNED state, the DHCPACTIVELEASEQUERY will send a DHCPLEASEUNASSIGNED
packet with information regarding that IPv4 address. The server may packet with information regarding that IPv4 address. The server may
then entirely forget about that IPv4 address (or not), but it is then entirely forget about that IPv4 address (or not), but it is
important to tell the DHCPACTIVELEASEQUERY client that an IPv4 important to tell the DHCPACTIVELEASEQUERY requestor that an IPv4
address has transitioned away from the leased state. address has transitioned away from the leased state.
The relationship between the time that the server replies to a DHCP 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 client request and the time that the DHCP server sends a reply to a
DHCPACTIVELEASEQUERY message is a matter of implementation (and thus DHCPACTIVELEASEQUERY message is a matter of implementation (and thus
not something defined by this document). However, the server SHOULD not something defined by this document). However, the server SHOULD
NOT delay responding to the DHCP client in order to transmit a reply NOT delay responding to the DHCP client in order to transmit a reply
to a DHCPACTIVELEASEQUERY message, and the server SHOULD send the to a DHCPACTIVELEASEQUERY message, and the server SHOULD send the
reply to the DHCPACTIVELASEQUERY message as soon as possible after reply to the DHCPACTIVELASEQUERY message as soon as possible after
responding to the client. responding to the client.
skipping to change at page 21, line 46 skipping to change at page 22, line 29
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 limit the additional queries from the requestor. The server SHOULD limit the
number of connections it maintains, and SHOULD close idle connections number of connections it maintains, and SHOULD 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 requestors 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 requestor end has been
the server MUST close its end of the connection. closed, the server MUST close its end of the connection.
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 requestors, and
of IPsec [RFC4301]. use 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 can compromise the ability of legitimate clients to receive resources can compromise the ability of legitimate clients to receive
service. Malicious clients who succeed in establishing connections, service. Malicious requestors who succeed in establishing
but who then send invalid queries, partial queries, or no queries at connections, but who then send invalid queries, partial queries, or
all also can exhaust a server's pool of available connections. We no queries at all also can exhaust a server's pool of available
recommend that servers offer configuration to limit the sources of connections.
incoming connections, that they limit the number of accepted
connections, and that they limit the period of time during which an When operating in secure mode, TLS [RFC5246] is used to secure the
idle connection will be left open. connection. The recommendations in [RFC7525] SHOULD be followed when
negotiating a TLS connection.
Servers SHOULD offer configuration parameters to limit the sources of
incoming connections through validation and use of the digital
certificates presented to create a TLS connection. They SHOULD also
limit the number of accepted connections, and limit the period of
time during which an idle connection will be left open.
The data acquired by using an Active Leasequery is subject to the
same potential abuse as the data held by the DHCPv4 server from which
it was acquired, and SHOULD be secured by mechanisms as strong as
those used for the data held by that DHCPv4 server. The data
acquired by using an Active Leasequery SHOULD be deleted as soon as
possible after the use for which it was acquired has passed.
Servers which implement the Bulk Leasequery protocol [RFC6926] but do Servers which implement the Bulk Leasequery protocol [RFC6926] but do
not implement the Active Leasequery protocol SHOULD implement the not implement the Active Leasequery protocol SHOULD implement the
update to [RFC6926] discussed in Section 8.1. update to [RFC6926] discussed in Section 8.1.
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:
skipping to change at page 23, line 14 skipping to change at page 24, line 14
+----------------------+-------------+ +----------------------+-------------+
| Name | status-code | | Name | status-code |
+----------------------+-------------+ +----------------------+-------------+
| DataMissing | TBD4 | | DataMissing | TBD4 |
| ConnectionActive | TBD5 | | ConnectionActive | TBD5 |
| CatchUpComplete | TBD6 | | CatchUpComplete | TBD6 |
| TLSConnectionRefused | TBD7 | | TLSConnectionRefused | TBD7 |
+----------------------+-------------+ +----------------------+-------------+
11. Acknowledgements 11. Acknowledgments
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. Useful review comments by Ted Lemon, Scott Bradner,
Francis Dupont, and Stephen Farrell on drafts for DHCPv6 Active
Leasequery were also included in this draft.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC <http://www.rfc-editor.org/info/rfc2119>.
2131, March 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
Internet Protocol", RFC 4301, December 2005. RFC 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>.
[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,
DOI 10.17487/RFC4388, February 2006,
<http://www.rfc-editor.org/info/rfc4388>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[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, DOI 10.17487/RFC6926, April 2013,
<http://www.rfc-editor.org/info/rfc6926>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
12.2. Informative References 12.2. Informative References
[RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, [RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985. DOI 10.17487/RFC0951, September 1985,
<http://www.rfc-editor.org/info/rfc951>.
[RFC1542] Wimer, W., "Clarifications and Extensions for the [RFC1542] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", RFC 1542, October 1993. Bootstrap Protocol", RFC 1542, DOI 10.17487/RFC1542,
October 1993, <http://www.rfc-editor.org/info/rfc1542>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<http://www.rfc-editor.org/info/rfc2132>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
Zimmermann, "A Roadmap for Transmission Control Protocol
(TCP) Specification Documents", RFC 7414,
DOI 10.17487/RFC7414, February 2015,
<http://www.rfc-editor.org/info/rfc7414>.
Authors' Addresses Authors' Addresses
Kim Kinnear Kim Kinnear
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: kkinnear@cisco.com Email: kkinnear@cisco.com
 End of changes. 67 change blocks. 
119 lines changed or deleted 192 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/