draft-ietf-dhc-dhcpv4-active-leasequery-06.txt   draft-ietf-dhc-dhcpv4-active-leasequery-07.txt 
Network Working Group K. Kinnear Network Working Group K. Kinnear
Internet-Draft M. Stapp Internet-Draft M. Stapp
Updates: 6926 (if approved) B. Volz Updates: 6926 (if approved) B. Volz
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: March 17, 2016 N. Russell Expires: April 8, 2016 N. Russell
Staples Staples
September 14, 2015 October 6, 2015
Active DHCPv4 Lease Query Active DHCPv4 Lease Query
draft-ietf-dhc-dhcpv4-active-leasequery-06.txt 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 [RFC4388]. 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
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 17, 2016. This Internet-Draft will expire on April 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4. Interaction Between Active Leasequery and Bulk Leasequery . . 7 4. Interaction Between Active Leasequery and Bulk Leasequery . . 7
5. Message and Option Definitions . . . . . . . . . . . . . . . 8 5. Message and Option Definitions . . . . . . . . . . . . . . . 8
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 8 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 8
5.2. New or Changed Options . . . . . . . . . . . . . . . . . 8 5.2. New or Changed Options . . . . . . . . . . . . . . . . . 8
5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 8 5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 8
5.2.2. dhcp-status-code . . . . . . . . . . . . . . . . . . 9 5.2.2. dhcp-status-code . . . . . . . . . . . . . . . . . . 9
5.3. Connection and Transmission Parameters . . . . . . . . . 10 5.3. Connection and Transmission Parameters . . . . . . . . . 10
6. Information Communicated by Active Leasequery . . . . . . . . 10 6. Information Communicated by Active Leasequery . . . . . . . . 10
7. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 11 7. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 11
7.1. General Processing . . . . . . . . . . . . . . . . . . . 11 7.1. General Processing . . . . . . . . . . . . . . . . . . . 11
7.2. Initiating a Connection . . . . . . . . . . . . . . . . . 11 7.2. Initiating a Connection . . . . . . . . . . . . . . . . . 12
7.3. Forming an Active Leasequery . . . . . . . . . . . . . . 13 7.3. Forming an Active Leasequery . . . . . . . . . . . . . . 13
7.4. Processing Active Replies . . . . . . . . . . . . . . . . 14 7.4. Processing Active Replies . . . . . . . . . . . . . . . . 14
7.4.1. Processing Replies from a Request Containing a query- 7.4.1. Processing Replies from a Request Containing a query-
start-time . . . . . . . . . . . . . . . . . . . . . 15 start-time . . . . . . . . . . . . . . . . . . . . . 16
7.5. Closing Connections . . . . . . . . . . . . . . . . . . . 18 7.5. Closing Connections . . . . . . . . . . . . . . . . . . . 18
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 18 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 18 8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 18
8.1.1. Update to RFC 6926 . . . . . . . . . . . . . . . . . 20 8.1.1. Update to RFC 6926 . . . . . . . . . . . . . . . . . 20
8.2. Replying to an Active Leasequery . . . . . . . . . . . . 20 8.2. Replying to an Active Leasequery . . . . . . . . . . . . 20
8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 22 8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 22
8.4. Closing Connections . . . . . . . . . . . . . . . . . . . 22 8.4. Closing Connections . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 25 12.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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
skipping to change at page 3, line 30 skipping to change at page 3, line 30
involved in the DHCPv4 client - server transactions (e.g., a relay involved in the DHCPv4 client - server transactions (e.g., a relay
agent), or it could be an external process which needs information agent), or it could be an external process which needs information
present in the DHCPv4 server's lease state database. present in the DHCPv4 server's lease state database.
The Active Leasequery capability documented here is designed to allow The Active Leasequery capability documented here is designed to allow
an entity not directly involved in DHCPv4 client - server an entity not directly involved in DHCPv4 client - server
transactions to nevertheless keep current with the state of the transactions to nevertheless keep current with the state of the
DHCPv4 lease state information in real-time. DHCPv4 lease state information in real-time.
This document updates DHCPv4 Bulk Leasequery [RFC6926] in that it This document updates DHCPv4 Bulk Leasequery [RFC6926] in that it
specifies the DHCPv4 server should 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
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses the following terms: This document uses the following terms:
skipping to change at page 5, line 51 skipping to change at page 5, line 51
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 which supports Active
Leasequery MUST support Bulk Leasequery [RFC6926] as well. Leasequery must support Bulk Leasequery [RFC6926] as well. See
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 which are extensions of these messages
as defined in [RFC4388] and [RFC6926]. This response procedure is as 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 an DHCPACTIVELEASEQUERY message to be sent over a
DHCP TCP connection to a DHCPv4 server which does not support Active DHCP TCP connection to a DHCPv4 server which does not support Active
Leasequery. Leasequery.
Active Leasequery is designed to provide continuous updates of DHCPv4 Active Leasequery is designed to provide continuous updates of DHCPv4
binding activity to an external entity. binding activity to an external entity.
skipping to change at page 11, line 28 skipping to change at page 11, line 28
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. the Requestor MAY retry. Retries should not be more frequent than
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. a new connection. Retries should not be more frequent than one every
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, and all of the messages unique on the connection on which it is sent (see Section 7.3), and
which come as a response to it all contain the same xid as the all of the messages which come as a response to it all contain the
request. same xid as the request.
Only one DHCPACTIVELEASEQUERY is allowed on any one TCP connection at
a time. Parallel DHCPACTIVELEASEQUERY requests on the same TCP 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. This MAY be a feature that is administratively controlled. mode. See Section 9. This MAY be a feature that is administratively
controlled.
When operating in insecure mode, the requestor SHOULD proceed to send When operating in insecure mode, the requestor sends a
a DHCPACTIVELEASEQUERY request after the establishment of a TCP DHCPACTIVELEASEQUERY request after the establishment of a TCP
connection. connection.
When operating in secure mode, the requestor MUST attempt to When operating in secure mode, the requestor MUST attempt to
negotiate a TLS [RFC5246] connection over the TCP connection. If negotiate a TLS [RFC5246] connection over the TCP connection. If
this negotiation fails, the requestor MUST close the TCP connection. this negotiation fails, the requestor MUST close the TCP connection.
The recommendations in [RFC7525] SHOULD be followed when negotiating The recommendations in [RFC7525] apply when negotiating this
this connection. connection.
A requestor requests the establishment of a TLS connection by sending A requestor requests the establishment of a TLS connection by sending
the DHCPTLS message to the DHCPv4 server as the first message over the DHCPTLS message to the DHCPv4 server as the first message over
the TCP connection. The DHCPTLS message SHOULD be sent without any the TCP connection. The DHCPTLS message SHOULD be sent without any
options. This message indicates to the DHCPv4 server that a TLS options. This message indicates to the DHCPv4 server that a TLS
connection over this TCP connection is desired. There are four connection over this TCP connection is desired. There are four
possibilities after the requestor sends the DHCPTLS message to the possibilities after the requestor sends the DHCPTLS message to the
DHCPV4 server: DHCPV4 server:
1. No response from the DHCPv4 server. 1. No response from the DHCPv4 server.
skipping to change at page 13, line 32 skipping to change at page 13, line 38
An important capability of the Active Leasequery is the ability of An important capability of the Active Leasequery is the ability of
the requestor to specify that some recent data be sent immediately to the requestor to specify that some recent data be sent immediately to
the requestor in parallel with the transmission of the ongoing 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.
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
in Leasequery reply messages to use later in a subsequent Bulk
Leasequery or Active Leasequery request.
This capability is enabled by the transmission of a 4 octet base-time This capability is enabled by the transmission of a 4 octet base-time
option with each Leasequery reply sent as the result of a previous option with each Leasequery reply sent as the result of a previous
Active Leasequery. The requestor 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
received, the requestor MUST NOT keep track of the base time received
in Leasequery reply messages to use later in a subsequent Bulk
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
the connection after BULK_LQ_DATA_TIMEOUT. We make this the connection after BULK_LQ_DATA_TIMEOUT. We make this
recommendation to allow requestors to control the period of time they recommendation to allow requestors to control the period of time they
are willing to wait before abandoning a connection, independent of are willing to wait before abandoning a connection, independent of
notifications from the TCP implementations they may be using. notifications from the TCP implementations they may be using.
7.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. If the stream of replies becomes blocked, the the TCP connection.
Requestor SHOULD terminate the connection after
ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured
to do so.
Note that a DHCPACTIVELEASEQUERY request specifically requests the Note that the connection resulting from accepting a
DHCPv4 server to create a long-lived connection which may not have DHCPACTIVELEASEQUERY request may be long-lived, and may not have data
data transferring continuously during its lifetime. Therefore the transferring continuously during its lifetime. Therefore the DHCPv4
DHCPv4 server SHOULD send a DHCPLEASEQUERYSTATUS message with a dhcp- server SHOULD send a DHCPLEASEQUERYSTATUS message with a dhcp-status-
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
received, the Requestor SHOULD terminate the connection after
ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured
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
as well as additional options. If there are additional bindings to as well as additional options. If there are additional bindings to
be returned, they will be carried in additional Active Leasequery be returned, they will be carried in additional Active Leasequery
messages. messages.
Any requestor of an Active Leasequery operation MUST be prepared to Any requestor of an Active Leasequery operation MUST be prepared to
receive multiple copies of the binding information for a particular receive multiple copies of the binding information for a particular
IPv4 address. See the Bulk Leasequery document [RFC6926] for IPv4 address. See the Bulk Leasequery document [RFC6926] for
information on how to deal with this situation. information on how to deal with this situation.
skipping to change at page 15, line 28 skipping to change at page 15, line 38
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 which is currently in
progress in the event that the DHCPv4 server determines that it progress in the event that the DHCPv4 server determines that it
cannot continue processing a DHCPACTIVELEASEQUERY request. For cannot continue processing a DHCPACTIVELEASEQUERY request. For
example, when a server is requested to shut down it SHOULD send a example, when a server is requested to shut down it SHOULD send a
DHCPLEASEQUERYSTATUS message with a dhcp-status-code of DHCPLEASEQUERYSTATUS message with a dhcp-status-code of
QueryTerminated and include in the message a base time. This SHOULD QueryTerminated and include in the message a base time. This MUST be
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 SHOULD 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.
skipping to change at page 17, line 15 skipping to change at page 17, line 26
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 is very slow, and the aging algorithm causes the saved
data to become unavailable) the DHCPv4 server will terminate the data to become unavailable) the DHCPv4 server will terminate the
catch-up phase of processing immediately by sending a catch-up phase of processing immediately by sending a
DHCPLEASEQUERYSTATUS message with a dhcp-status-code of DataMissing DHCPLEASEQUERYSTATUS message with a dhcp-status-code of DataMissing
and with a base-time option of the current time. and with a base-time option of the current time.
The requestor MUST NOT assume that every individual state change of The requestor must not assume that every individual state change of
every 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. The requestor MAY assume that at least one Active reply message. See Section 6. The requestor MAY assume that at
Leasequery reply message will exist for every binding which had one least one Active Leasequery reply message will exist for every
or more changes of state during the period specified by the query- binding which had one or more changes of state during the period
start-time and the current time. The last message for each binding specified by the query-start-time and the current time. The last
will contain the state at the current time, and there can be one or message for each binding will contain the state at the current time,
more messages concerning a single binding during the catch-up phase and there can be one or more messages concerning a single binding
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.
If the DHCPLEASEQUERYSTATUS message containing a dhcp-status-code of If the DHCPLEASEQUERYSTATUS message containing a dhcp-status-code of
DataMissing is received and the requestor is interested in keeping DataMissing is received and the requestor is interested in keeping
its database up to date with respect to the current state of the its database up to date with respect to the current state of the
skipping to change at page 18, line 29 skipping to change at page 18, line 39
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.
DHCPv4 servers SHOULD be able to operate in either insecure or secure DHCPv4 servers SHOULD be able to operate in either insecure or secure
mode. This MAY be a mode that is administratively controlled, where mode. See Section 9. This MAY be a mode that is administratively
the server will require a TLS connection to operate or will only controlled, where the server will require a TLS connection to operate
operate without a TLS connection. In either case, operation in or will only operate without a TLS connection. In either case,
insecure mode MUST NOT be the default, even if operation in secure operation in insecure mode MUST NOT be the default, even if operation
mode is not supported. Operation in insecure mode MUST always in secure mode is not supported. Operation in insecure mode MUST
require an explicit configuration step, separate from the always require an explicit configuration step, separate from the
configuration step required to enable support for Active Leasequery. configuration step required to enable support for Active Leasequery.
When operating in insecure mode, the DHCPv4 server simply waits for When operating in insecure mode, the DHCPv4 server simply waits for
the requestor to send the Active Leasequery after the establishment the requestor to send the Active Leasequery after the establishment
of TCP connection. If it receives a DHCPTLS message, it will respond of TCP connection. If it receives a DHCPTLS message, it will respond
with TLSConnectionRefused in a DHCPTLS message. with TLSConnectionRefused in a DHCPTLS message.
When operating in secure mode, DHCPv4 servers MUST support TLS When operating in secure mode, DHCPv4 servers MUST support TLS
[RFC5246] to protect the integrity and privacy of the data [RFC5246] to protect the integrity and privacy of the data
transmitted over the TCP connection. 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 which are not secured with TLS or for
which the requestor's certificate is deemed unacceptable. The which the requestor's certificate is deemed unacceptable. The
recommendations in [RFC7525] SHOULD be followed when negotiating a recommendations in [RFC7525] apply when negotiating a TLS connection.
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
number of open connections, the TCP connection itself should be
rejected, or the subsequent ACTIVELEASEQUERY message should be
rejected. Capacity related rejections SHOULD NOT affect the response
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. server SHOULD be ignored. This is a SHOULD instead of a MUST in
order to allow use of the DHCPTLS message in later documents,
possibly with the use of options, without requiring those documents
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 or has been configured to
not support a TLS connection, then it SHOULD send a DHCPTLS message not support a TLS connection, then it sends a DHCPTLS message with a
with a dhcp-status-code of TLSConnectionRefused back to the dhcp-status-code of TLSConnectionRefused back to the requestor.
requestor.
In the event that the DHCPv4 server sends a DHCPTLS message with no In the event that the DHCPv4 server sends a DHCPTLS message with no
dhcp-status-code option included (which indicates success), the dhcp-status-code option included (which indicates success), the
requestor is supposed to initiate a TLS handshake [RFC5246] (see requestor is supposed to initiate a TLS handshake [RFC5246] (see
Section 7.2). During the TLS handshake, the DHCPv4 server MUST Section 7.2). During the TLS handshake, the DHCPv4 server MUST
validate the requestor's digital certificate. In addition, the validate the requestor's digital certificate. In addition, the
digitial 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 the 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.
skipping to change at page 20, line 10 skipping to change at page 20, line 24
after a BULK_LQ_DATA_TIMEOUT. We make this recommendation to allow after a BULK_LQ_DATA_TIMEOUT. We make this recommendation to allow
servers to control the period of time they are willing to wait before servers to control the period of time they are willing to wait before
abandoning an inactive connection, independent of the TCP abandoning an inactive connection, independent of the TCP
implementations they may be using. implementations they may be using.
8.1.1. Update to RFC 6926 8.1.1. Update to RFC 6926
In an update to the DHCPv4 Bulk Leasequery protocol [RFC6926] (which In an update to the DHCPv4 Bulk Leasequery protocol [RFC6926] (which
didn't discuss this situation explicitly), if the DHCPv4 server didn't discuss this situation explicitly), if the DHCPv4 server
receives a DHCPv4 message containing a dhcp-message-type option with receives a DHCPv4 message containing a dhcp-message-type option with
a value that is not supported over a TCP connection, it SHOULD close a value that is not supported over a TCP connection, it MUST close
the TCP connection. the TCP connection.
8.2. Replying to an Active Leasequery 8.2. Replying to an Active Leasequery
If the connection becomes blocked while the server is attempting to If the connection becomes blocked while the server is attempting to
send reply messages, the server SHOULD terminate the TCP connection send reply messages, the server SHOULD terminate the TCP connection
after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs how long the after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs how long the
DHCPv4 server is prepared to wait for the requestor to read and DHCPv4 server is prepared to wait for the requestor to read and
process enough information to unblock the TCP connection. The process enough information to unblock the TCP connection. The
default is two minutes, which means that if more than two minutes default is two minutes, which means that if more than two minutes
skipping to change at page 21, line 25 skipping to change at page 21, line 40
times. times.
These replies based on the query-start-time MAY be interleaved with These replies based on the query-start-time MAY be interleaved with
the messages generated due to current binding activity. the messages generated due to current binding activity.
Once the transmission of the DHCPv4 Leasequery messages associated Once the transmission of the DHCPv4 Leasequery messages associated
with the query-start-time option are complete, a DHCPLEASEQUERYSTATUS with the query-start-time option are complete, a DHCPLEASEQUERYSTATUS
message MUST be sent with a dhcp-status-code value of message MUST be sent with a dhcp-status-code value of
CatchUpComplete. CatchUpComplete.
The DHCPv4 server SHOULD, but is not required to, keep track of a The DHCPv4 server SHOULD keep track of previous binding activity. It
limited amount of previous binding activity and associate it with SHOULD limit the amount of previous binding activity it keeps track
base-time values. The DHCPv4 server MAY choose to only do this in of. The DHCPv4 server MAY choose to only do this in the event that
the event that it has received at least one DHCPACTIVELEASEQUERY it has received at least one DHCPACTIVELEASEQUERY request in the
request in the past, as to do so will almost certainly entail some past, as to do so will almost certainly entail some utilization of
utilization of resources which would be wasted if there are no resources which would be wasted if there are no DHCPACTIVELEASEQUERY
DHCPACTIVELEASEQUERY requestors for this DHCPv4 server. The DHCPv4 requestors for this DHCPv4 server. The DHCPv4 server SHOULD make the
server SHOULD make the amount of previous binding activity it retains amount of previous binding activity it retains configurable. There
configurable. There is no requirement on the DHCPv4 server to retain is no requirement on the DHCPv4 server to retain this information
this information over a server restart (or even to retain such over a server restart (or even to retain such information at all).
information at all).
Unless there is an error or some requirement to cease processing a Unless there is an error or some requirement to cease processing a
DHCPACTIVELEASEQUERY request yielding a DHCPLEASEQUERYSTATUS message, DHCPACTIVELEASEQUERY request yielding a DHCPLEASEQUERYSTATUS message,
such as a server shutdown, there will be no DHCPLEASEQUERYSTATUS such as a server shutdown, there will be no DHCPLEASEQUERYSTATUS
message at the conclusion of the DHCPACTIVELEASEQUERY processing message at the conclusion of the DHCPACTIVELEASEQUERY processing
because that processing will not conclude but will continue until because that processing will not conclude but will continue until
either the requestor or the server closes the connection. either the requestor or the server closes the connection.
While the form of the data being sent by a DHCPACTIVELEASEQUERY is While the form of the data being sent by a DHCPACTIVELEASEQUERY is
essentially the same as that being sent by a DHCPBULKLEASEQUERY, the essentially the same as that being sent by a DHCPBULKLEASEQUERY, the
skipping to change at page 22, line 40 skipping to change at page 23, line 7
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 close its end of the TCP connection after sending its The server MAY end communication by sending a DHCPLEASEQUERYSTATUS
last message, a DHCPLEASEQUERYSTATUS message in response to a query. 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
skipping to change at page 23, line 25 skipping to change at page 23, line 40
use of IPsec [RFC4301]. use of 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
secure mode. These two modes exists because there are essentially
two models of use for this protocol. In one model, the requestor of
an Active Leasequery is connected to the internet in an arbitrary
location, and the information transmitted needs to be protected
during transmission. In addition, the identity of both requestor and
server need to be verified. For this model of use, the secure mode
is appropriate.
The other model of use is where the requestor of the Active
Leasequery resides in a network element that is essentially "next to"
the element containing the DHCP server, and both of these elements
are inside a protected environment. For this model, the insecure
mode is sufficient since there are other, more global, protections in
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] SHOULD be followed when connection. The recommendations in [RFC7525] apply when negotiating
negotiating a TLS connection. a TLS connection.
Operating in insecure mode (see Section 8.1 does not provide any way
to validate the authorization of requestors of a DHCPV4 Active
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 during which an idle connection will be left open. time 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
skipping to change at page 24, line 32 skipping to change at page 25, line 22
+----------------------+-------------+ +----------------------+-------------+
11. Acknowledgments 11. Acknowledgments
The ideas in this document came in part from work in DHCPv6 and The ideas in this document came in part from work in DHCPv6 and
DHCPv4 Bulk Leasequery as well as from in depth discussions between DHCPv4 Bulk Leasequery as well as from in depth discussions between
the authors. Useful review comments by Ted Lemon, Scott Bradner, the authors. Useful review comments by Ted Lemon, Scott Bradner,
Francis Dupont, and Stephen Farrell on drafts for DHCPv6 Active Francis Dupont, and Stephen Farrell on drafts for DHCPv6 Active
Leasequery were also included in this draft. Brian Haberman's review Leasequery were also included in this draft. Brian Haberman's review
brought this document into much closer alignment with DHCPv6 Active brought this document into much closer alignment with DHCPv6 Active
Leasequery. Leasequery. Additional reviews by Alissa Cooper, Spencer Dawkins,
Christer Holmberg, and Ben Campbell added clarity to this document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 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>.
 End of changes. 38 change blocks. 
83 lines changed or deleted 120 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/