draft-ietf-dhc-dhcpv4-active-leasequery-07.txt   rfc7724.txt 
Network Working Group K. Kinnear Internet Engineering Task Force (IETF) K. Kinnear
Internet-Draft M. Stapp Request for Comments: 7724 M. Stapp
Updates: 6926 (if approved) B. Volz Updates: 6926 B. Volz
Intended status: Standards Track Cisco Systems Category: Standards Track Cisco Systems
Expires: April 8, 2016 N. Russell ISSN: 2070-1721 N. Russell
Staples Staples
October 6, 2015 December 2015
Active DHCPv4 Lease Query Active DHCPv4 Lease Query
draft-ietf-dhc-dhcpv4-active-leasequery-07.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 requestor to extended with a Leasequery capability that allows a requestor to
request information about DHCPv4 bindings [RFC4388]. That mechanism request information about DHCPv4 bindings (RFC 4388). That mechanism
is limited to queries for individual bindings. In some situations is limited to queries for individual bindings. In some situations,
individual binding queries may not be efficient, or even possible. individual binding queries may not be efficient, or even possible.
In addition, continuous update of an external requestor with In addition, continuous update of an external requestor with
Leasequery data is sometimes desired. This document expands on the Leasequery data is sometimes desired. This document expands on the
DHCPv4 Leasequery protocol, and allows for active transfer of near DHCPv4 Leasequery protocol, and allows for active transfer of near
real-time DHCPv4 binding information data via TCP. This document real-time DHCPv4 binding information data via TCP. This document
updates RFC6926, DHCPv4 Bulk Leasequery. updates RFC 6926, "DHCPv4 Bulk Leasequery".
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on April 8, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7724.
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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4. Interaction Between Active Leasequery and Bulk Leasequery . . 7 4. Interaction Between Active Leasequery and Bulk Leasequery . . 8
5. Message and Option Definitions . . . . . . . . . . . . . . . 8 5. Message and Option Definitions . . . . . . . . . . . . . . . 9
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 8 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 9
5.2. New or Changed Options . . . . . . . . . . . . . . . . . 8 5.2. New or Changed Options . . . . . . . . . . . . . . . . . 9
5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 8 5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 10
5.2.2. dhcp-status-code . . . . . . . . . . . . . . . . . . 9 5.2.2. dhcp-status-code . . . . . . . . . . . . . . . . . . 10
5.3. Connection and Transmission Parameters . . . . . . . . . 10 5.3. Connection and Transmission Parameters . . . . . . . . . 11
6. Information Communicated by Active Leasequery . . . . . . . . 10 6. Information Communicated by Active Leasequery . . . . . . . . 11
7. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 11 7. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 12
7.1. General Processing . . . . . . . . . . . . . . . . . . . 11 7.1. General Processing . . . . . . . . . . . . . . . . . . . 12
7.2. Initiating a Connection . . . . . . . . . . . . . . . . . 12 7.2. Initiating a Connection . . . . . . . . . . . . . . . . . 13
7.3. Forming an Active Leasequery . . . . . . . . . . . . . . 13 7.3. Forming an Active Leasequery . . . . . . . . . . . . . . 14
7.4. Processing Active Replies . . . . . . . . . . . . . . . . 14 7.4. Processing Active Replies . . . . . . . . . . . . . . . . 15
7.4.1. Processing Replies from a Request Containing a query- 7.4.1. Processing Replies from a Request Containing a
start-time . . . . . . . . . . . . . . . . . . . . . 16 query-start-time . . . . . . . . . . . . . . . . . . 17
7.5. Closing Connections . . . . . . . . . . . . . . . . . . . 18 7.5. Closing Connections . . . . . . . . . . . . . . . . . . . 19
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 18 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 18 8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 19
8.1.1. Update to RFC 6926 . . . . . . . . . . . . . . . . . 20 8.1.1. Update to RFC 6926 . . . . . . . . . . . . . . . . . 21
8.2. Replying to an Active Leasequery . . . . . . . . . . . . 20 8.2. Replying to an Active Leasequery . . . . . . . . . . . . 21
8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 22 8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 23
8.4. Closing Connections . . . . . . . . . . . . . . . . . . . 23 8.4. Closing Connections . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 26 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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.
Continuous update of an external requestor with Leasequery data is Continuous update of an external requestor with Leasequery data is
sometimes desired. These requestors need to keep up with the current sometimes desired. These requestors need to keep up with the current
binding activity of the DHCPv4 server. Keeping up with these binding binding activity of the DHCPv4 server. Keeping up with these binding
activities is termed "active" leasequery. activities 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 that is directly involved
involved in the DHCPv4 client - server transactions (e.g., a relay in the DHCPv4 client-server transactions (e.g., a relay agent), or it
agent), or it could be an external process which needs information could be an external process that needs information present in the
present in the DHCPv4 server's lease state database. 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
transactions to nevertheless keep current with the state of the to nevertheless keep current with the state of the DHCPv4 lease state
DHCPv4 lease state information in real-time. information in real-time.
This document updates DHCPv4 Bulk Leasequery [RFC6926] in that it This document updates DHCPv4 Bulk Leasequery [RFC6926] in that it
specifies the DHCPv4 server must close the TCP connection if it specifies the DHCPv4 server must close the TCP connection if it
receives a DHCPv4 message that is not allowed over the TCP connection receives a DHCPv4 message that is not allowed over the TCP connection
(for example, DHCPDISCOVER, DHCPLEASEQUERY). See Section 8.1.1. (for example, DHCPDISCOVER, DHCPLEASEQUERY). See Section 8.1.1.
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
skipping to change at page 5, line 9 skipping to change at page 5, line 48
o "DHCPv4 client" o "DHCPv4 client"
A DHCPv4 client is an IPv4 node using DHCP to obtain configuration A DHCPv4 client is an IPv4 node using DHCP to obtain configuration
parameters such as a network address. parameters such as a network address.
o "DHCPv4 relay agent" o "DHCPv4 relay agent"
A DHCPv4 relay agent is a third-party agent that transfers BOOTP A DHCPv4 relay agent is a third-party agent that transfers BOOTP
and DHCPv4 messages between clients and servers residing on and DHCPv4 messages between clients and servers residing on
different subnets, per [RFC0951] and [RFC1542]. different subnets, per [RFC951] and [RFC1542].
o "DHCPv4 server" o "DHCPv4 server"
A DHCPv4 server is an IPv4 node that returns configuration A DHCPv4 server is an IPv4 node that returns configuration
parameters to DHCPv4 clients. parameters to DHCPv4 clients.
o "insecure mode" o "insecure mode"
When operating in insecure mode, the TCP connection between the When operating in insecure mode, the TCP connection between the
requestor and DHCPv4 server is not protected in any way. In requestor and DHCPv4 server is not protected in any way. In
addition, the identity of the requestor is not validated by the addition, the identity of the requestor is not validated by the
server nor is the identity of the server validated by the server nor is the identity of the server validated by the
requestor. requestor.
o "MAC address" o "MAC address"
In the context of a DHCP message, a MAC address consists of the In the context of a DHCP message, a Media Access Control (MAC)
fields: hardware type "htype", hardware length "hlen", and client address consists of the fields: hardware type "htype", hardware
hardware address "chaddr". length "hlen", and client hardware address "chaddr".
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.
o "secure mode" o "secure mode"
When operating in secure mode, the TCP connection between the When operating in secure mode, the TCP connection between the
requestor and the DHCPv4 server is protected by TLS [RFC5246]. In requestor and the DHCPv4 server is protected by TLS [RFC5246]. In
addition, the requestor uses the certificates exchanged between it addition, the requestor uses the certificates exchanged between it
and the DHCPv4 server while setting up the TLS connection to and the DHCPv4 server while setting up the TLS connection to
validate the identity of the server. The DHCPv4 server also uses validate the identity of the server. The DHCPv4 server also uses
these certificates to validate the identity of the requestor. these certificates to validate the identity of the requestor.
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 [RFC7414] connection required for Active nature of the TCP [RFC7414] connection required for Active
Leasequery. In addition, a DHCPv4 server which supports Active Leasequery. In addition, a DHCPv4 server that supports Active
Leasequery must support Bulk Leasequery [RFC6926] as well. See Leasequery must support Bulk Leasequery [RFC6926] as well. See
Section 8. Section 8.
An Active Leasequery requestor 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 requestor 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 requestor 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 that are extensions of these messages as
as defined in [RFC4388] and [RFC6926]. This response procedure is defined in [RFC4388] and [RFC6926]. This response procedure is
similar to the procedure specified in [RFC6926], except that in the similar to the procedure specified in [RFC6926], except that in the
case of Active Leasequery the server sends updates whenever some case of Active Leasequery the server sends updates whenever some
activity occurs to change the binding state -- thus the need for the activity occurs to change the binding state -- thus the need for the
long lived connection. Additionally, the Active Leasequery server long-lived connection. Additionally, the Active Leasequery server
should provide a mechanism to control which data is allowed to be should provide a mechanism to control which data is allowed to be
included in the messages sent to the requestor. See Section 8.2. 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 a 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 that 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
binding activity to an external entity. binding activity to an external entity.
Active Leasequery has features which allow this external entity to Active Leasequery has features that 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 bindings changed while it was not information concerning any IPv4 bindings changed while it was not
connected. connected.
These capabilities are designed to allow the Active Leasequery These capabilities are designed to allow the Active Leasequery
requestor to efficiently become current with respect to the lease requestor to efficiently become current with respect to the lease
state database after it has been restarted or the machine on which it state database after it has been restarted or the machine on which it
is running has been reinitialized. It is easy to define a protocol is running has been reinitialized. It is easy to define a protocol
which works when the requestor is always connected to the DHCPv4 that works when the requestor is always connected to the DHCPv4
server. Since that isn't sufficiently robust, much of the mechanism server. Since that isn't sufficiently robust, much of the mechanism
in this document is designed to deal efficiently with situations that in this document is designed to deal efficiently with situations that
occur when the Active Leasequery requestor becomes disconnected from occur when the Active Leasequery requestor becomes disconnected from
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 is the concept that, if the Active
service, it is allowed to specify the time of its most recent update Leasequery requestor loses service, it is allowed to specify the time
in a subsequent Active Leasequery request and the DHCPv4 server will of its most recent update in a subsequent Active Leasequery request,
determine whether or not data was missed while the Active Leasequery and the DHCPv4 server will determine whether or not data was missed
requestor was not connected. while the Active Leasequery 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 an 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 requestor 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 binding information. In addition, it would use Bulk contains no binding information. In addition, it would use Bulk
Leasequery to recover missed information in the event that its 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
skipping to change at page 7, line 43 skipping to change at page 8, line 41
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, with the exception that followed when implementing Active Leasequery, with the exception that
a server responding to an Active Leasequery request SHOULD be able to a server responding to an Active Leasequery request SHOULD be able to
be configured to prevent specific data items from being included in be configured to prevent specific data items from being included in
the response to the requestor even if they were requested by the response to the requestor even if they were requested by
inclusion in the dhcp-parameter-request-list option. 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 messages returned to an Active Leasequery [RFC6926]. The contents of messages returned to an Active Leasequery
requestor are identical to that defined for the Bulk Leasequery requestor are identical to those defined for the Bulk Leasequery
protocol. protocol.
Applications which employ Active Leasequery to keep a database up to Applications that 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
use an initial Bulk Leasequery to bring their database into 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-
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
skipping to change at page 8, line 37 skipping to change at page 9, line 36
[RFC6926] is used for Active Leasequery. [RFC6926] is used for Active Leasequery.
When using TLS to secure a connection [RFC5246], the message framing 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 for TLS uses the same format as that used for TCP. One DHCP message
is carried in one TLS record. 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 that is currently not leased or is currently leased to a
client, respectively. DHCPv4 client, respectively.
All of the message types and options defined for Bulk Leasequery All of the message types and options defined for Bulk Leasequery
[RFC6926] are also used by Active Leasequery. In addition, new [RFC6926] are also used by Active Leasequery. In addition, new
message types and option types are defined for Active Leasequery, as message types and option types are defined for Active Leasequery, as
described below. described below.
5.2.1. dhcp-message-type 5.2.1. dhcp-message-type
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 | | 16 | DHCPACTIVELEASEQUERY |
| TBD2 | DHCPLEASEQUERYSTATUS | | 17 | DHCPLEASEQUERYSTATUS |
| TBD3 | DHCPTLS | | 18 | 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, DHCPLEASEUNASSIGNED or DHCPTLS. It message-type is DHCPLEASEACTIVE, DHCPLEASEUNASSIGNED, or DHCPTLS. It
refers to the message stream related to an entire request if the refers to the message stream related to an entire request if the
value of 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 | TBD4 | Indicates that IPv4 binding | | DataMissing | 5 | Indicates that IPv4 binding |
| | | information requested is not | | | | information requested is not |
| | | available. | | | | available. |
| ConnectionActive | TBD5 | Indicates that this | | ConnectionActive | 6 | Indicates that this |
| | | connection remains active. | | | | connection remains active. |
| CatchUpComplete | TBD6 | Indicates that this Active | | CatchUpComplete | 7 | 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 | | TLSConnectionRefused | 8 | Indicates that a TLS |
| | | connection is not allowed. | | | | 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 that is successful unless it is
is needed to convey some text message along with the Success status 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
Active Leasequery uses the same port configuration as DHCPv4 Bulk Active Leasequery uses the same port configuration as DHCPv4 Bulk
Leasequery [RFC6926]. It also uses other transmission parameters Leasequery [RFC6926]. It also uses other transmission parameters
(BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [RFC6926]. (BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [RFC6926].
This section presents a table of values used to control Active This section presents a table of values used to control Active
Leasequery behavior, including recommended defaults. Implementations Leasequery behavior, including recommended defaults. Implementations
MAY make these values configurable. However, configuring too-small MAY make these values configurable. However, configuring too-small
timeout values may lead to harmful behavior both to this application timeout values may lead to harmful behavior both to this application
as well as to other traffic in the network. As a result, timeout as well as to other traffic in the network. As a result, timeout
values smaller than the default values SHOULD NOT be used. values smaller than the default values SHOULD NOT be used.
+------------------------+----------+-------------------------------+ +------------------------+---------+-------------------------------+
| Parameter | Default | Description | | Parameter | Default | Description |
+------------------------+----------+-------------------------------+ +------------------------+---------+-------------------------------+
| ACTIVE_LQ_RCV_TIMEOUT | 120 secs | Active Leasequery receive | | ACTIVE_LQ_RCV_TIMEOUT | 120 s | Active Leasequery receive |
| | | timeout | | | | timeout |
| ACTIVE_LQ_SEND_TIMEOUT | 120 secs | Active Leasequery send | | ACTIVE_LQ_SEND_TIMEOUT | 120 s | Active Leasequery send |
| | | timeout | | | | timeout |
| ACTIVE_LQ_IDLE_TIMEOUT | 60 secs | Active Leasequery idle | | ACTIVE_LQ_IDLE_TIMEOUT | 60 s | Active Leasequery idle |
| | | timeout | | | | timeout |
+------------------------+----------+-------------------------------+ +------------------------+---------+-------------------------------+
6. Information Communicated by Active Leasequery 6. Information Communicated by Active Leasequery
While the information communicated by a Bulk Leasequery [RFC6926] is While the information communicated by a Bulk Leasequery [RFC6926] is
taken directly from the DHCPv4 server's lease state database, the taken directly from the DHCPv4 server's lease state database, the
information communicated by an Active Leasequery is real-time information communicated by an Active Leasequery is real-time
information. As such, it is the information which is currently information. As such, it is the information that is currently
associated with a particular binding in the DHCPv4 server's lease associated with a particular binding in the DHCPv4 server's lease
state database. state database.
This is of significance, because if the Active Leasequery requestor This is of significance, because if the Active Leasequery requestor
runs slowly or the requestor disconnects from the DHCPv4 server and runs slowly or the requestor disconnects from the DHCPv4 server and
then reconnects with a query-start-time (signaling a catch-up then reconnects with a query-start-time (signaling a catch-up
operation), the information communicated to the Active Leasequery operation), the information communicated to the Active Leasequery
requestor is only the most current information from the DHCPv4 requestor is only the most current information from the DHCPv4
server's lease state database. server's lease state database.
The requestor of an Active Leasequery MUST NOT assume that every The requestor of an Active Leasequery MUST NOT assume that every
lease state change is communicated across an Active Leasequery lease state change is communicated across an Active Leasequery
connection. Even if the Active Leasequery requestor remains connection. Even if the Active Leasequery requestor remains
connected, the DHCPv4 server is only required to transmit information connected, the DHCPv4 server is only required to transmit information
about a binding that is current when the packet is created and handed about a binding that is current when the packet is created and handed
off to the TCP stack to send to the requestor. off to the TCP stack to send to the requestor.
If the TCP connection blocks and the DHCPv4 server is waiting to send If the TCP connection blocks and the DHCPv4 server is waiting to send
information down the connection, when the connection becomes information down the connection, when the connection becomes
available to be written the DHCPv4 server MAY create the packet to available to be written, the DHCPv4 server MAY create the packet to
send at this time. The current state of the binding will be sent, send at this time. The current state of the binding will be sent,
and any transition in state or other information that occurred while and any transition in state or other information that occurred while
the TCP connection was blocked will be lost. the TCP connection was blocked will be lost.
Thus, the Active Leasequery protocol does not allow the requestor to Thus, the Active Leasequery protocol does not allow the requestor to
build a complete history of every activity on every lease. An build a complete history of every activity on every lease. An
effective history of the important state changes for a lease can be effective history of the important state changes for a lease can be
created if the parameters of the DHCPv4 server are tuned to take into created if the parameters of the DHCPv4 server are tuned to take into
account the requirements of an Active Leasequery requestor. For account the requirements of an Active Leasequery requestor. For
instance, the period after the expiration or release of a binding instance, the period after the expiration or release of a binding
could be configured long enough (say several minutes, well more than could be configured long enough (say, several minutes, well more than
the receive timeout), so that an Active Leasequery requestor would the receive timeout), so that an Active Leasequery requestor would
never miss any changes in the binding. never miss any changes in the binding.
7. Requestor Behavior 7. Requestor Behavior
7.1. 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. Retries should not be more frequent than the Requestor MAY retry. Retries should not be more frequent than
one every ACTIVE_LQ_IDLE_TIMEOUT. See Section 5.3. one every ACTIVE_LQ_IDLE_TIMEOUT. See Section 5.3.
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. Retries should not be more frequent than one every a new connection. Retries should not be more frequent than one every
ACTIVE_LQ_IDLE_TIMEOUT. See Section 5.3. ACTIVE_LQ_IDLE_TIMEOUT. See Section 5.3.
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 (see Section 7.3), and unique on the connection on which it is sent (see Section 7.3), and
all of the messages which come as a response to it all contain the all of the messages that come as a response to it contain the same
same xid as the request. xid as the request.
Only one DHCPACTIVELEASEQUERY is allowed on any one TCP connection at Only one DHCPACTIVELEASEQUERY is allowed on any one TCP connection at
a time. Parallel DHCPACTIVELEASEQUERY requests on the same TCP are a time. Parallel DHCPACTIVELEASEQUERY requests on the same TCP
not allowed. connection are not allowed.
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. See Section 9. This MAY be a feature that is administratively mode. See Section 9. This MAY be a feature that is administratively
controlled. controlled.
When operating in insecure mode, the requestor sends a When operating in insecure mode, the requestor sends a
DHCPACTIVELEASEQUERY request after the establishment of a TCP DHCPACTIVELEASEQUERY request after the establishment of a TCP
connection. connection.
skipping to change at page 12, line 48 skipping to change at page 14, line 4
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 close 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 validate 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 DHCPACTIVELEASEQUERY message over the requestor SHOULD transmit a DHCPACTIVELEASEQUERY message over
that 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 close 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 binding information back across query. The DHCPv4 server SHOULD send binding information back across
this connection with minimal delay after it learns of the binding this connection with minimal delay after it learns of the binding
information. It will learn about the bindings either because it information. It will learn about the bindings either because it
makes the bindings itself or because it has received information makes the bindings itself or because it has received information
about a binding from another server. about a binding from another server.
An Active Leasequery is a DHCPv4 request with a dhcp-message-type of An Active Leasequery is a DHCPv4 request with a dhcp-message-type of
DHCPACTIVELEASEQUERY. The DHCPv4 request MUST NOT have a ciaddr, a DHCPACTIVELEASEQUERY. The DHCPv4 request MUST NOT have a ciaddr, a
chaddr, or a dhcp-client-identifier. The DHCPv4 request MUST have an chaddr, or a dhcp-client-identifier. The DHCPv4 request MUST have an
xid (transaction-id) unique on the connection on which it is sent. xid (transaction-id) unique on the connection on which it is sent.
The DHCPv4 request SHOULD have a dhcp-parameter-request-list to The DHCPv4 request SHOULD have a dhcp-parameter-request-list to
inform the DHCPv4 server which DHCPv4 options are of interest to the inform 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 that the
the requestor to specify that some recent data be sent immediately to requestor can specify that some recent data be sent immediately to
the requestor in parallel with the transmission of the ongoing the requestor in parallel with the transmission of the ongoing
binding information in more or less real time. This capability is binding information in more or less real time. This capability is
used in order to allow an Active Leasequery requestor to recover used in order to allow an Active Leasequery requestor to recover
missed information in the event that it temporarily loses 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.
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 SHOULD keep track of the highest Active Leasequery. The requestor SHOULD keep track of the highest
base-time received from a particular DHCPv4 server over an Active base-time received from a particular DHCPv4 server over an Active
Leasequery connection, and in the event that the requestor finds it Leasequery connection, and in the event that the requestor finds it
necessary (for whatever reason) to reestablish an Active Leasequery necessary (for whatever reason) to reestablish an Active Leasequery
connection to that DHCPv4 server, the requestor should place this connection to that DHCPv4 server, the requestor should place this
highest base-time value into a query-start-time option in the new highest base-time value into a query-start-time option in the 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.)
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.
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 terminate the requestor is sending its query, the requestor SHOULD terminate
skipping to change at page 14, line 25 skipping to change at page 15, line 31
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.4. 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. the TCP connection.
Note that the connection resulting from accepting a Note that the connection resulting from accepting a
DHCPACTIVELEASEQUERY request may be long-lived, and may not have data DHCPACTIVELEASEQUERY request may be long-lived and may not have data
transferring continuously during its lifetime. Therefore the DHCPv4 transferring continuously during its lifetime. Therefore, the DHCPv4
server SHOULD send a DHCPLEASEQUERYSTATUS message with a dhcp-status- server SHOULD send a DHCPLEASEQUERYSTATUS message with a dhcp-status-
code of ConnectionActive every ACTIVE_LQ_IDLE_TIMEOUT seconds 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. This approach is followed only when the connection is remains alive. This approach is followed only when the connection is
idle (i.e., the server has no binding data to send). During normal idle (i.e., the server has no binding data to send). During normal
binding data exchange, receiving DHCPLEASEACTIVE or binding data exchange, receiving DHCPLEASEACTIVE or
DHCPLEASEUNASSIGNED messages by the requestor itself signifies that DHCPLEASEUNASSIGNED messages by the requestor itself signifies that
the connection is active. Note that the default for the connection is active. Note that the default for
ACTIVE_LQ_RCV_TIMEOUT is 120 seconds, twice the value of the ACTIVE_LQ_RCV_TIMEOUT is 120 seconds, twice the value of the
ACTIVE_LQ_IDLE_TIMEOUT's default of 60 seconds which drives the ACTIVE_LQ_IDLE_TIMEOUT's default of 60 seconds, which drives the
DHCPv4 server to send messages. Thus ACTIVE_LQ_RCV_TIMEOUT controls DHCPv4 server to send messages. Thus, ACTIVE_LQ_RCV_TIMEOUT controls
how sensitive the requestor is to be to delays by the DHCPv4 server how sensitive the requestor is to be to delays by the DHCPv4 server
in sending updates or DHCPLEASEQUERYSTATUS messages. in sending updates or DHCPLEASEQUERYSTATUS messages.
If the stream of replies becomes blocked with no messages being If the stream of replies becomes blocked with no messages being
received, the Requestor SHOULD terminate the connection after received, the 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.
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
skipping to change at page 15, line 28 skipping to change at page 16, line 34
out in the catch-up phase. See Section 7.4.1 for information on out in the catch-up phase. See Section 7.4.1 for information on
processing during the catch-up phase, as well as how to determine processing during the catch-up phase, as well as how to determine
when the catch-up phase is complete. when the catch-up phase is complete.
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.
The DHCPLEASEQUERYSTATUS message MAY unilaterally terminate a The DHCPLEASEQUERYSTATUS message MAY unilaterally terminate a
successful DHCPACTIVELEASEQUERY request which is currently in successful DHCPACTIVELEASEQUERY request that is currently in progress
progress in the event that the DHCPv4 server determines that it in the event that the DHCPv4 server determines that it cannot
cannot continue processing a DHCPACTIVELEASEQUERY request. For continue processing a DHCPACTIVELEASEQUERY request. For example,
example, when a server is requested to shut down it SHOULD send a 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 MUST be QueryTerminated and include in the message a base-time. This MUST be
the last message on that connection, and once the message has been the last message on that connection, and once the message has been
transmitted, the server MUST close the connection. transmitted, the server MUST 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 bindings the DHCPv4 server will attempt to send information about all bindings
that changed since the time specified in the query- start-time. This that changed since the time specified in the query-start-time. This
is the catch-up phase of the DHCPACTIVELEASEQUERY processing. The is the catch-up phase of the DHCPACTIVELEASEQUERY processing. The
DHCPv4 server MAY also begin immediate updates over the same DHCPv4 server MAY also begin immediate updates over the same
connection of real-time binding information changes. Thus, the connection of real-time binding information changes. Thus, the
catch-up phase can run in parallel with the normal updates generated catch-up phase can run in parallel with the normal updates generated
by the DHCPACTIVELEASEQUERY request. 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. In such the time-ordered information kept by the DHCPv4 server. In such
case, when there is not enough data saved in the DHCPv4 server to case, when there is not enough data saved in the DHCPv4 server 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
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 binding changes taking of these messages will be real-time updates of binding changes taking
place in the DHCPv4 server. In general, there is no way to determine place in the DHCPv4 server. In general, there is no way to determine
the source each message. the source of each message.
The updates sent by the DHCPv4 server during the catch-up phase are The updates sent by the DHCPv4 server during the catch-up phase are
not in the order that the binding data was updated. Therefore, until not in the order that the binding data was updated. Therefore, until
the catch-up phase is complete, the latest base-time value received the catch-up phase is complete, the latest base-time value received
from a DHCPv4 server processing an Active Leasequery request cannot from a DHCPv4 server processing an Active Leasequery request cannot
be reset from the incoming messages (and used in a subsequent Active be reset from the incoming messages (and used in a subsequent Active
Leasequery's query-start-time option), because to do so would 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.
skipping to change at page 17, line 20 skipping to change at page 18, line 25
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.
In the event that there was enough data available to the DHCPv4 In the event that there was enough data available to the DHCPv4
server to begin to satisfy the request implied by the query-start- server to begin to satisfy the request implied by the query-start-
time option, but during the processing of that data the server found time option, but during the processing of that data the server found
that it was unable to continue (perhaps there was barely enough, the that it was unable to continue (perhaps there was barely enough, the
connection is very slow, and the aging algorithm causes the saved connection was very slow, and the aging algorithm caused the saved
data to become unavailable) the DHCPv4 server will terminate the data to become unavailable), the DHCPv4 server will terminate the
catch-up phase of processing immediately by sending a catch-up phase of processing immediately by sending a
DHCPLEASEQUERYSTATUS message with a dhcp-status-code of DataMissing DHCPLEASEQUERYSTATUS message with a dhcp-status-code of DataMissing
and with a base-time option of the current time. and with a base-time option of the current time.
The requestor must not assume that every individual state change of The requestor must not assume that every individual state change of
every binding during the period from the time specified in the query- every binding during the period from the time specified in the query-
start-time and the present is replicated in an Active Leasequery start-time and the present is replicated in an Active Leasequery
reply message. See Section 6. The requestor MAY assume that at reply message. See Section 6. The requestor MAY assume that at
least one Active Leasequery reply message will exist for every least one Active Leasequery reply message will exist for every
binding which had one or more changes of state during the period binding that had one or more changes of state during the period
specified by the query-start-time and the current time. The last specified by the query-start-time and the current time. The last
message for each binding will contain the state at the current time, message for each binding will contain the state at the current time,
and there can be one or more messages concerning a single binding and there can be one or more messages concerning a single binding
during the catch-up phase of processing. during 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.
skipping to change at page 18, line 26 skipping to change at page 19, line 30
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
requestor 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 that 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], with the exception that support for Active Leasequery [RFC6926], with the exception that support for Active
Leasequery MUST NOT be enabled by default, and MUST require an Leasequery MUST NOT be enabled by default, and MUST require an
explicit configuration step to be performed before it will operate. explicit configuration step to be performed before it will operate.
skipping to change at page 19, line 15 skipping to change at page 20, line 20
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. When operating in secure mode, transmitted over the TCP connection. When operating in secure mode,
DHCPv4 servers MUST be configurable with regard to which requestors DHCPv4 servers MUST be configurable with regard to which requestors
they will communicate. The certificate presented by a requestor when they will communicate. The certificate presented by a requestor when
initiating the TLS connection is used to distinguish between initiating the TLS connection is used to distinguish between
acceptable and unacceptable requestors. acceptable and unacceptable requestors.
When operating in secure mode, a DHCPv4 server MUST begin to When operating in secure mode, a DHCPv4 server MUST begin to
negotiate a TLS connection with a requestor who asks for one, and negotiate a TLS connection with a requestor who asks for one, and
MUST close TCP connections which are not secured with TLS or for MUST close TCP connections that are not secured with TLS or for which
which the requestor's certificate is deemed unacceptable. The the requestor's certificate is deemed unacceptable. The
recommendations in [RFC7525] apply when negotiating a TLS connection. recommendations in [RFC7525] apply 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 MUST 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.
If a connection is to be rejected because of a limitation of the If a connection is to be rejected because of a limitation of the
number of open connections, the TCP connection itself should be number of open connections, the TCP connection itself should be
rejected, or the subsequent ACTIVELEASEQUERY message should be rejected, or the subsequent ACTIVELEASEQUERY message should be
rejected. Capacity related rejections SHOULD NOT affect the response rejected. Capacity-related rejections SHOULD NOT affect the response
to the DHCPTLS message. to the DHCPTLS message.
Any options appearing in a DHCPTLS message received by a DHCPv4 Any options appearing in a DHCPTLS message received by a DHCPv4
server SHOULD be ignored. This is a SHOULD instead of a MUST in server SHOULD be ignored. This is a "SHOULD" instead of a "MUST" in
order to allow use of the DHCPTLS message in later documents, order to allow use of the DHCPTLS message in later documents,
possibly with the use of options, without requiring those documents possibly with the use of options, without requiring those documents
to update this document. to update this document.
If for some reason the DHCPv4 server cannot or has been configured to If for some reason the DHCPv4 server cannot support or has been
not support a TLS connection, then it sends a DHCPTLS message with a configured to not support a TLS connection, then it sends a DHCPTLS
dhcp-status-code of TLSConnectionRefused back to the requestor. 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 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
validate the requestor's digital certificate. In addition, the validate the requestor's digital certificate. In addition, the
digital certificate presented by the requestor is used to decide if digital certificate presented by the requestor is used to decide if
this requestor is allowed to perform an Active Leasequery. If this this requestor is allowed to perform an Active Leasequery. If this
requestor's certificate is deemed unacceptable, the server MUST abort requestor's certificate is deemed unacceptable, the server MUST abort
the creation of the TLS connection. the creation of the TLS connection.
All TLS connections established between the a requestor and a DHCPv4 All TLS connections established between a requestor and a DHCPv4
server for the purposes of supporting Active Leasequery MUST be server for the purposes of supporting Active Leasequery MUST be
mutually authenticated. mutually authenticated.
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 close the TCP connection. the server MUST close 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
skipping to change at page 20, line 51 skipping to change at page 22, line 10
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], with the exception that a server implementing Active [RFC6926], with the exception that a server implementing Active
Leasequery SHOULD be able to be configured to prevent specific data Leasequery SHOULD be able to be configured to prevent specific data
items from being sent to the requestor even if these data items were items from being sent to the requestor even if these data items were
requested in the dhcp-parameter-request-list option.. 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 binding which [RFC4388] or a DHCPBULKLEASEQUERY [RFC6926] for an IPv4 binding that
is reserved in such a way that it appears that the IPv4 binding is is reserved in such a way that it appears that the IPv4 binding 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 binding is reserved to a DHCP client. first determine that the IPv4 binding is reserved to a DHCP client.
If a DHCPACTIVELEASEQUERY request contains a query-start-time option, If a DHCPACTIVELEASEQUERY request contains a query-start-time option,
it indicates that the requestor would like the DHCPv4 server to send it indicates that the requestor would like the DHCPv4 server to send
it not only messages that correspond to DHCPv4 binding activity that it not only messages that correspond to DHCPv4 binding activity that
occurs subsequent to the receipt of the DHCPLEASEACTIVE request, but occurs subsequent to the receipt of the DHCPLEASEACTIVE request, but
skipping to change at page 21, line 45 skipping to change at page 22, line 52
Once the transmission of the DHCPv4 Leasequery messages associated Once the transmission of the DHCPv4 Leasequery messages associated
with the query-start-time option are complete, a DHCPLEASEQUERYSTATUS with the query-start-time option are complete, a DHCPLEASEQUERYSTATUS
message MUST be sent with a dhcp-status-code value of message MUST be sent with a dhcp-status-code value of
CatchUpComplete. CatchUpComplete.
The DHCPv4 server SHOULD keep track of previous binding activity. It The DHCPv4 server SHOULD keep track of previous binding activity. It
SHOULD limit the amount of previous binding activity it keeps track SHOULD limit the amount of previous binding activity it keeps track
of. The DHCPv4 server MAY choose to only do this in the event that of. The DHCPv4 server MAY choose to only do this in the event that
it has received at least one DHCPACTIVELEASEQUERY request in the it has received at least one DHCPACTIVELEASEQUERY request in the
past, as to do so will almost certainly entail some utilization of past, as to do so will almost certainly entail some utilization of
resources which would be wasted if there are no DHCPACTIVELEASEQUERY resources that would be wasted if there are no DHCPACTIVELEASEQUERY
requestors for this DHCPv4 server. The DHCPv4 server SHOULD make the requestors for this DHCPv4 server. The DHCPv4 server SHOULD make the
amount of previous binding activity it retains configurable. There amount of previous binding activity it retains configurable. There
is no requirement on the DHCPv4 server to retain this information is no requirement on the DHCPv4 server to retain this information
over a server restart (or even to retain such information at all). over a server restart (or even to retain such information at all).
Unless there is an error or some requirement to cease processing a Unless there is an error or some requirement to cease processing a
DHCPACTIVELEASEQUERY request yielding a DHCPLEASEQUERYSTATUS message, DHCPACTIVELEASEQUERY request yielding a DHCPLEASEQUERYSTATUS message,
such as a server shutdown, there will be no DHCPLEASEQUERYSTATUS such as a server shutdown, there will be no DHCPLEASEQUERYSTATUS
message at the conclusion of the DHCPACTIVELEASEQUERY processing message at the conclusion of the DHCPACTIVELEASEQUERY processing
because that processing will not conclude but will continue until because that processing will not conclude but will continue until
skipping to change at page 22, line 21 skipping to change at page 23, line 28
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 binding transitions from the leased state to some other when an IPv4 binding 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 binding. The server may then packet with information regarding that binding. The server may then
entirely forget about that IPv4 binding (or not), but it is important entirely forget about that IPv4 binding (or not), but it is important
to tell the DHCPACTIVELEASEQUERY requestor that an binding has to tell the DHCPACTIVELEASEQUERY requestor that a binding has
transitioned away from the leased state. 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 defined by this document). However, the server SHOULD NOT delay
NOT delay responding to the DHCP client in order to transmit a reply responding to the DHCP client in order to transmit a reply to a
to a DHCPACTIVELEASEQUERY message, and the server SHOULD send the DHCPACTIVELEASEQUERY message, and the server SHOULD send the reply to
reply to the DHCPACTIVELASEQUERY message as soon as possible after the DHCPACTIVELASEQUERY message as soon as possible after responding
responding to the client. to the client.
8.3. Multiple or Parallel Queries 8.3. Multiple or Parallel Queries
Every Active Leasequery request MUST be made on a single TCP Every Active Leasequery request MUST be made on a single TCP
connection where there is no other request active at the time the connection where there is no other request active at the time the
request is made. Note that this is different than what was allowed request is made. Note that this is different than what was allowed
in [RFC6926] section 7.7 for Bulk Leasequery requests. in Section 7.7 of [RFC6926] for Bulk Leasequery requests.
Typically, a requestor of a Active Leasequery would not need to send Typically, a requestor of an Active Leasequery would not need to send
a second Active Leasequery while the first is still active. However, a second Active Leasequery while the first is still active. However,
sending an Active Leasequery and a Bulk Leasequery in parallel would sending an Active Leasequery and a Bulk Leasequery in parallel would
be possible and reasonable. In case of parallel Active and Bulk be possible and reasonable. In case of parallel Active and Bulk
Leasequery requests, the requestor MUST use different connections. Leasequery requests, the requestor MUST use different connections.
This MAY be a feature that is administratively controlled. Servers This MAY be a feature that is administratively controlled. Servers
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 end communication by sending a DHCPLEASEQUERYSTATUS The server MAY end communication by sending a DHCPLEASEQUERYSTATUS
message and then immediately closing the TCP connection. message and then immediately closing the TCP connection.
Alternatively, the server MAY retain the connection and wait for Alternatively, the server MAY retain the connection and wait for
additional queries from the requestor. 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 requestors 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 requestor end has been message. If the server detects that the requestor end has been
closed, 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
general threats to DHCPv4. The DHCPv4 Leasequery specification threats to DHCPv4. The DHCPv4 Leasequery specification [RFC4388]
[RFC4388] describes recommendations for the Leasequery protocol, describes recommendations for the Leasequery protocol, especially
especially with regard to relayed LEASEQUERY messages, mitigation of with regard to relayed LEASEQUERY messages, mitigation of packet-
packet-flooding DOS attacks, restriction to trusted requestors, and flooding DoS attacks, restriction to trusted requestors, and use of
use of IPsec [RFC4301]. IPsec [RFC4301].
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 requestors who succeed in establishing service. Malicious requestors who succeed in establishing
connections, but who then send invalid queries, partial queries, or connections, but who then send invalid queries, partial queries, or
no queries at all also can exhaust a server's pool of available no queries at all also can exhaust a server's pool of available
connections. connections.
Two modes of operation exist for this protocol, insecure mode and Two modes of operation exist for this protocol, insecure mode and
secure mode. These two modes exists because there are essentially secure mode. These two modes exist because there are essentially two
two models of use for this protocol. In one model, the requestor of models of use for this protocol. In one model, the requestor of an
an Active Leasequery is connected to the internet in an arbitrary Active Leasequery is connected to the Internet in an arbitrary
location, and the information transmitted needs to be protected location, and the information transmitted needs to be protected
during transmission. In addition, the identity of both requestor and during transmission. In addition, the identities of both requestor
server need to be verified. For this model of use, the secure mode and server need to be verified. For this model of use, the secure
is appropriate. mode is appropriate.
The other model of use is where the requestor of the Active The other model of use is where the requestor of the Active
Leasequery resides in a network element that is essentially "next to" Leasequery resides in a network element that is essentially "next to"
the element containing the DHCP server, and both of these elements the element containing the DHCP server, and both of these elements
are inside a protected environment. For this model, the insecure are inside a protected environment. For this model, the insecure
mode is sufficient since there are other, more global, protections in mode is sufficient since there are other, more global, protections in
place to protect this information. place to protect this information.
When operating in secure mode, TLS [RFC5246] is used to secure the When operating in secure mode, TLS [RFC5246] is used to secure the
connection. The recommendations in [RFC7525] apply when negotiating connection. The recommendations in [RFC7525] apply when negotiating
a TLS connection. a TLS connection.
Operating in insecure mode (see Section 8.1 does not provide any way Operating in insecure mode (see Section 8.1) does not provide any way
to validate the authorization of requestors of a DHCPV4 Active to validate the authorization of requestors of a DHCPV4 Active
Leasequery request. Leasequery request.
Servers SHOULD offer configuration parameters to limit the sources of Servers SHOULD offer configuration parameters to limit the sources of
incoming connections through validation and use of the digital incoming connections through validation and use of the digital
certificates presented to create a TLS connection. They SHOULD also certificates presented to create a TLS connection. They SHOULD also
limit the number of accepted connections, and limit the period of limit the number of accepted connections and limit the period of time
time during which an idle connection will be left open. during which an idle connection will be left open.
The data acquired by using an Active Leasequery is subject to the 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 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 it was acquired and SHOULD be secured by mechanisms as strong as
those used for the data held by that DHCPv4 server. The data those used for the data held by that DHCPv4 server. The data
acquired by using an Active Leasequery SHOULD be deleted as soon as acquired by using an Active Leasequery SHOULD be deleted as soon as
possible after the use for which it was acquired has passed. possible after the use for which it was acquired has passed.
Servers which implement the Bulk Leasequery protocol [RFC6926] but do Servers that 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.1. update to [RFC6926] discussed in Section 8.1.1.
10. IANA Considerations 10. IANA Considerations
IANA is requested to assign the following new DHCP message types from IANA has assigned the following new DHCP message types from the
the registry "DHCP Message Type 53 Values" maintained at 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 16 for DHCPACTIVELEASEQUERY.
2. A dhcp-message-type of TBD2 for DHCPLEASEQUERYSTATUS. 2. A dhcp-message-type of 17 for DHCPLEASEQUERYSTATUS.
3. A dhcp-message-type of TBD3 for DHCPTLS. 3. A dhcp-message-type of 18 for DHCPTLS.
IANA is requested to assign the following new DHCP status codes from IANA has assigned the following new DHCP status codes from the
the registry "DHCP Status Code Type 151 Values" maintained at 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 | TBD4 | | DataMissing | 5 |
| ConnectionActive | TBD5 | | ConnectionActive | 6 |
| CatchUpComplete | TBD6 | | CatchUpComplete | 7 |
| TLSConnectionRefused | TBD7 | | TLSConnectionRefused | 8 |
+----------------------+-------------+ +----------------------+-------------+
11. Acknowledgments 11. References
The ideas in this document came in part from work in DHCPv6 and
DHCPv4 Bulk Leasequery as well as from in depth discussions between
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. Brian Haberman's review
brought this document into much closer alignment with DHCPv6 Active
Leasequery. Additional reviews by Alissa Cooper, Spencer Dawkins,
Christer Holmberg, and Ben Campbell added clarity to this document.
12. References
12.1. Normative References 11.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>. <http://www.rfc-editor.org/info/rfc2131>.
skipping to change at page 26, line 11 skipping to change at page 27, line 5
N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery", N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery",
RFC 6926, DOI 10.17487/RFC6926, April 2013, RFC 6926, DOI 10.17487/RFC6926, April 2013,
<http://www.rfc-editor.org/info/rfc6926>. <http://www.rfc-editor.org/info/rfc6926>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <http://www.rfc-editor.org/info/rfc7525>.
12.2. Informative References 11.2. Informative References
[RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, [RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
DOI 10.17487/RFC0951, September 1985, DOI 10.17487/RFC0951, September 1985,
<http://www.rfc-editor.org/info/rfc951>. <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, DOI 10.17487/RFC1542, Bootstrap Protocol", RFC 1542, DOI 10.17487/RFC1542,
October 1993, <http://www.rfc-editor.org/info/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, DOI 10.17487/RFC2132, March 1997, Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<http://www.rfc-editor.org/info/rfc2132>. <http://www.rfc-editor.org/info/rfc2132>.
skipping to change at page 26, line 35 skipping to change at page 27, line 29
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>. December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
Zimmermann, "A Roadmap for Transmission Control Protocol Zimmermann, "A Roadmap for Transmission Control Protocol
(TCP) Specification Documents", RFC 7414, (TCP) Specification Documents", RFC 7414,
DOI 10.17487/RFC7414, February 2015, DOI 10.17487/RFC7414, February 2015,
<http://www.rfc-editor.org/info/rfc7414>. <http://www.rfc-editor.org/info/rfc7414>.
Acknowledgments
The ideas in this document came in part from work in DHCPv6 and
DHCPv4 Bulk Leasequery as well as from in depth discussions between
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. Brian Haberman's review
brought this document into much closer alignment with DHCPv6 Active
Leasequery. Additional reviews by Alissa Cooper, Spencer Dawkins,
Christer Holmberg, and Ben Campbell added clarity to this document.
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 United States
Email: kkinnear@cisco.com Email: kkinnear@cisco.com
Mark Stapp Mark Stapp
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
USA United States
Email: mjs@cisco.com Email: mjs@cisco.com
Bernie Volz Bernie Volz
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
USA United States
Email: volz@cisco.com Email: volz@cisco.com
Neil Russell Neil Russell
Staples Staples
500 Staples Drive 500 Staples Drive
Framingham, MA 01702 Framingham, MA 01702
USA United States
Email: neil.e.russell@gmail.com Email: neil.e.russell@gmail.com
 End of changes. 98 change blocks. 
211 lines changed or deleted 209 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/