draft-ietf-dhc-dhcpv4-active-leasequery-02.txt   draft-ietf-dhc-dhcpv4-active-leasequery-03.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: September 3, 2015 N. Russell Expires: December 12, 2015 N. Russell
Staples Staples
March 2, 2015 June 10, 2015
Active DHCPv4 Lease Query Active DHCPv4 Lease Query
draft-ietf-dhc-dhcpv4-active-leasequery-02.txt draft-ietf-dhc-dhcpv4-active-leasequery-03.txt
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been
extended with a Leasequery capability that allows a client to request extended with a Leasequery capability that allows a client to request
information about DHCPv4 bindings. That mechanism is limited to information about DHCPv4 bindings. That mechanism is limited to
queries for individual bindings. In some situations individual queries for individual bindings. In some situations individual
binding queries may not be efficient, or even possible. In addition, binding queries may not be efficient, or even possible. In addition,
continuous update of an external client with Leasequery data is continuous update of an external client with Leasequery data is
sometimes desired. This document expands on the DHCPv4 Leasequery sometimes desired. This document expands on the DHCPv4 Leasequery
skipping to change at page 1, line 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 September 3, 2015. This Internet-Draft will expire on December 12, 2015.
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 21 skipping to change at page 2, line 21
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Interaction Between Active Leasequery and Bulk Leasequery . . 7 4. Interaction Between Active Leasequery and Bulk Leasequery . . 7
5. Message and Option Definitions . . . . . . . . . . . . . . . 7 5. Message and Option Definitions . . . . . . . . . . . . . . . 8
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 8 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 8
5.2. New or Changed Options . . . . . . . . . . . . . . . . . 8 5.2. New or Changed Options . . . . . . . . . . . . . . . . . 8
5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 8 5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 8
5.2.2. dhcp-status-code . . . . . . . . . . . . . . . . . . 8 5.2.2. dhcp-status-code . . . . . . . . . . . . . . . . . . 8
5.3. Connection and Transmission Parameters . . . . . . . . . 9 5.3. Connection and Transmission Parameters . . . . . . . . . 9
6. Information Communicated by Active Leasequery . . . . . . . . 10 6. Information Communicated by Active Leasequery . . . . . . . . 10
7. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 11 7. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 11
7.1. General Processing . . . . . . . . . . . . . . . . . . . 11 7.1. General Processing . . . . . . . . . . . . . . . . . . . 11
7.2. Initiating a Connection . . . . . . . . . . . . . . . . . 11 7.2. Initiating a Connection . . . . . . . . . . . . . . . . . 11
7.3. Forming an Active Leasequery . . . . . . . . . . . . . . 12 7.3. Forming an Active Leasequery . . . . . . . . . . . . . . 12
7.4. Processing Active Replies . . . . . . . . . . . . . . . . 13 7.4. Processing Active Replies . . . . . . . . . . . . . . . . 13
7.4.1. Processing Replies from a Request Containing a query- 7.4.1. Processing Replies from a Request Containing a query-
start-time . . . . . . . . . . . . . . . . . . . . . 15 start-time . . . . . . . . . . . . . . . . . . . . . 15
7.5. Closing Connections . . . . . . . . . . . . . . . . . . . 17 7.5. Closing Connections . . . . . . . . . . . . . . . . . . . 17
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 17 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 17 8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 17
8.2. Replying to an Active Leasequery . . . . . . . . . . . . 19 8.2. Replying to an Active Leasequery . . . . . . . . . . . . 19
8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 21 8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 21
8.4. Closing Connections . . . . . . . . . . . . . . . . . . . 21 8.4. Closing Connections . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4 The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4
skipping to change at page 4, line 19 skipping to change at page 4, line 19
Requesting and receiving the information about all or some of the Requesting and receiving the information about all or some of the
existing DHCPv4 address binding information in an efficient existing DHCPv4 address binding information in an efficient
manner, as defined by [RFC6926]. manner, as defined by [RFC6926].
o "blocked TCP connection" o "blocked TCP connection"
A TCP connection is considered blocked if the underlying TCP A TCP connection is considered blocked if the underlying TCP
transport will not accept new messages to be sent without blocking transport will not accept new messages to be sent without blocking
the thread that is attempting to send the message. the thread that is attempting to send the message.
o "catch-up information, catch-up phase" o "catch-up information"
If a DHCPv4 Active Leasequery requestor sends in a query-start- If a DHCPv4 Active Leasequery requestor sends in a query-start-
time option in a DHCPACTIVELEASEQUERY message, the DHCPv4 server time option in a DHCPACTIVELEASEQUERY message, the DHCPv4 server
will attempt to send the requestor the information that changed will attempt to send the requestor the information that changed
since the time specified in the query-start-time option. The since the time specified in the query-start-time option. The
address binding information sent to satisfy this request is the address binding information sent to satisfy this request is the
catch-up information, and the period while it is being sent is the catch-up information.
o "catch-up phase"
The period while the catch-up information is being sent is the
catch-up phase. catch-up phase.
o "clock skew" o "clock skew"
The difference between the absolute time on a DHCPv4 server and The difference between the absolute time on a DHCPv4 server and
the absolute time on the system where a requestor of an Active or the absolute time on the system where a requestor of an Active or
Bulk Leasequery is executing is termed the "clock skew" for that Bulk Leasequery is executing is termed the "clock skew" for that
Active or Bulk Leasequery connection. It is not absolutely Active or Bulk Leasequery connection. It is not absolutely
constant but is likely to vary only slowly. While it is easy to constant but is likely to vary only slowly. While it is easy to
think that this can be calculated precisely after one packet is think that this can be calculated precisely after one packet is
skipping to change at page 5, line 46 skipping to change at page 5, line 49
Bulk Leasequery [RFC6926]; most differences arise from the long term Bulk Leasequery [RFC6926]; most differences arise from the long term
nature of the TCP connection required for Active Leasequery. In nature of the TCP connection required for Active Leasequery. In
addition, a DHCPv4 server which supports Active Leasequery MUST addition, a DHCPv4 server which supports Active Leasequery MUST
support Bulk Leasequery [RFC6926] as well. support Bulk Leasequery [RFC6926] as well.
An Active Leasequery client opens a TCP connection to a DHCPv4 An Active Leasequery client opens a TCP connection to a DHCPv4
Server, using the DHCPv4 port 67. Note that this implies that the Server, using the DHCPv4 port 67. Note that this implies that the
Leasequery client has the server IPv4 address(es) available via Leasequery client has the server IPv4 address(es) available via
configuration or some other means, and that it has unicast IP configuration or some other means, and that it has unicast IP
reachability to the DHCPv4 server. The message framing for TCP is reachability to the DHCPv4 server. The message framing for TCP is
discusssed in Section 5.1. No relaying for Active Leasequery is discussed in Section 5.1. No relaying for Active Leasequery is
specified. specified.
After establishing a connection, the client sends an After establishing a connection, the client sends an
DHCPACTIVELEASEQUERY message over the connection. In response, the DHCPACTIVELEASEQUERY message over the connection. In response, the
server sends updates to the requestor using DHCPLEASEACTIVE and server sends updates to the requestor using DHCPLEASEACTIVE and
DHCPLEASEUNASSIGNED messages which are extensions of these messages DHCPLEASEUNASSIGNED messages which are extensions of these messages
as defined in [RFC4388] and [RFC6926]. as defined in [RFC4388] and [RFC6926].
Since [RFC6926] did not specify what to do with an unknown message 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
skipping to change at page 7, line 14 skipping to change at page 7, line 16
An Active Leasequery requestor would typically use Bulk Leasequery to An Active Leasequery requestor would typically use Bulk Leasequery to
initialize its database with all current data when that database initialize its database with all current data when that database
contains no address binding information. In addition, it would use contains no address binding information. In addition, it would use
Bulk Leasequery to recover missed information in the event that its Bulk Leasequery to recover missed information in the event that its
connection with the DHCPv4 server was lost for a longer time than the connection with the DHCPv4 server was lost for a longer time than the
DHCPv4 server would keep track of the specific changes to the IPv4 DHCPv4 server would keep track of the specific changes to the IPv4
address binding information. address binding information.
The messages sent by the server in response to an Active Leasequery The messages sent by the server in response to an Active Leasequery
request SHOULD be identical to the messages sent by the server to a request should be identical to the messages sent by the server to a
Bulk Leasequery request regarding the way the data is encoded into Bulk Leasequery request regarding the way the data is encoded into
the Active Leasequery responses. In addition, the actions taken by the Active Leasequery responses. In addition, the actions taken by
the Active Leasequery requestor to interpret the responses to an the Active Leasequery requestor to interpret the responses to an
Active Leasequery request SHOULD be identical to the way that the Active Leasequery request should be identical to the way that the
requestor interprets the responses to a Bulk Leasequery request. requestor interprets the responses to a Bulk Leasequery request.
Thus, the handling of time, clock skew, data source, and other items Thus, the handling of time, clock skew, data source, and other items
discussed in the Bulk Leasequery specification [RFC6926] are to be discussed in the Bulk Leasequery specification [RFC6926] are to be
followed when implementing Active Leasequery. followed when implementing Active Leasequery.
4. Interaction Between Active Leasequery and Bulk Leasequery 4. Interaction Between Active Leasequery and Bulk Leasequery
Active Leasequery is an extension of the Bulk Leasequery protocol Active Leasequery is an extension of the Bulk Leasequery protocol
[RFC6926]. The contents of packets returned to an Active Leasequery [RFC6926]. The contents of packets returned to an Active Leasequery
requestor are identical to that defined for the Bulk Leasequery requestor are identical to that defined for the Bulk Leasequery
protocol. protocol.
Applications which employ Active Leasequery to keep a database up to Applications which employ Active Leasequery to keep a database up to
date with respect to the DHCPv4 server's lease state database will date with respect to the DHCPv4 server's lease state database should
usually 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
all available updates to the requestor. all available updates to the requestor.
skipping to change at page 9, line 32 skipping to change at page 9, line 34
A dhcp-status-code option MAY appear in the options field of a DHCP A dhcp-status-code option MAY appear in the options field of a DHCP
message. If the dhcp-status-code option does not appear, it is message. If the dhcp-status-code option does not appear, it is
assumed that the operation was successful. The dhcp-status-code assumed that the operation was successful. The dhcp-status-code
option SHOULD NOT appear in a message which is successful unless it option SHOULD NOT appear in a message which is successful unless it
is needed to convey some text message along with the Success status is needed to convey some text message along with the Success status
code. code.
5.3. Connection and Transmission Parameters 5.3. Connection and Transmission Parameters
DHCPv4 servers that support Active Leasequery SHOULD listen for Active Leasequery uses the same port configuration as DHCPv4 Bulk
incoming TCP connections on port 67. Implementations MAY offer to Leasequery [RFC6926]. It also uses other transmission parameters
make the incoming port configurable, but port 67 MUST be the default. (BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [RFC6926].
Requestors SHOULD make TCP connections to port 67, and MAY offer to
make the destination server port configurable.
This section presents a table of values used to control Active This section presents a table of values used to control Active
Leasequery behavior, including recommended defaults. Implementations Leasequery behavior, including recommended defaults. Implementations
MAY make these values configurable. However, configuring too-small MAY make these values configurable. However, configuring too-small
timeout values may lead to harmful behavior both to this application timeout values may lead to harmful behavior both to this application
as well as to other traffic in the network. As a result, timeout as well as to other traffic in the network. As a result, timeout
values smaller than the default values SHOULD NOT be used. values smaller than the default values SHOULD NOT be used.
+------------------------+---------+--------------------------------+ +------------------------+----------+-------------------------------+
| Parameter | Default | Description | | Parameter | Default | Description |
+------------------------+---------+--------------------------------+ +------------------------+----------+-------------------------------+
| BULK_LQ_DATA_TIMEOUT | * | Bulk Leasequery data timeout | | ACTIVE_LQ_RCV_TIMEOUT | 120 secs | Active Leasequery receive |
| BULK_LQ_MAX_CONNS | * | Max Bulk Leasequery TCP | | | | timeout |
| | | connections | | ACTIVE_LQ_SEND_TIMEOUT | 120 secs | Active Leasequery send |
| ACTIVE_LQ_RCV_TIMEOUT | 120 | Active Leasequery receive | | | | timeout |
| | secs | timeout | | ACTIVE_LQ_IDLE_TIMEOUT | 60 secs | Active Leasequery idle |
| ACTIVE_LQ_SEND_TIMEOUT | 120 | Active Leasequery send timeout | | | | timeout |
| | secs | | +------------------------+----------+-------------------------------+
| ACTIVE_LQ_IDLE_TIMEOUT | 60 secs | Active Leasequery idle timeout |
+------------------------+---------+--------------------------------+
* See Section 6.3 of [RFC6926] for specific default values.
6. Information Communicated by Active Leasequery 6. Information Communicated by Active Leasequery
While the information communicated by a Bulk Leasequery [RFC6926] is While the information communicated by a Bulk Leasequery [RFC6926] is
taken directly from the DHCPv4 server's lease state database, the taken directly from the DHCPv4 server's lease state database, the
information communicated by an Active Leasequery is real-time information communicated by an Active Leasequery is real-time
information. As such, it is the information which is currently information. As such, it is the information which is currently
associated with a particular IPv4 address in the DHCPv4 server's associated with a particular IPv4 address in the DHCPv4 server's
lease state database. lease state database.
skipping to change at page 11, line 37 skipping to change at page 11, line 33
single DHCPACTIVELEASEQUERY message. Thus, each DHCPACTIVELEASEQUERY single DHCPACTIVELEASEQUERY message. Thus, each DHCPACTIVELEASEQUERY
or DHCPBULKLEASEQUERY request MUST have an xid (transaction-id) or DHCPBULKLEASEQUERY request MUST have an xid (transaction-id)
unique on the connection on which it is sent, and all of the messages unique on the connection on which it is sent, and all of the messages
which come as a response to it all contain the same xid as the which come as a response to it all contain the same xid as the
request. It is the xid which allows the data-streams of two or more request. It is the xid which allows the data-streams of two or more
different DHCPACTIVELEASEQUERY or DHCPBULKLEASEQUERY requests to be different DHCPACTIVELEASEQUERY or DHCPBULKLEASEQUERY requests to be
demultiplexed by the requestor. demultiplexed by the requestor.
7.2. Initiating a Connection 7.2. Initiating a Connection
A requestor SHOULD attempt to negotiate a TLS [RFC5246] connection A requestor should be able to operate in either insecure or secure
over the TCP connection. If this negotiation fails, a requestor MAY mode. This MAY be a feature that is administratively controlled.
choose to proceed with the Active Leasequery request without TLS.
When operating in insecure mode, the requestor should proceed with
the Active Leasequery request after the establishment of a TCP
connection.
When operating in secure mode, the requestor MUST attempt to
negotiate a TLS [RFC5246] connection over the TCP connection. If
this negotiation fails, the requestor must drop the TCP connection.
A requestor requests the establishment of a TLS connection by sending A requestor requests the establishment of a TLS connection by sending
the DHCPTLS message to the DHCPv4 server as the first message over the DHCPTLS message to the DHCPv4 server as the first message over
the TCP connection. This message indicates to the DHCPv4 server that the TCP connection. This message indicates to the DHCPv4 server that
a TLS connection over this TCP connection is desired. There are four a TLS connection over this TCP connection is desired. There are four
possibilities after the requestor sends the DHCPTLS message to the possibilities after the requestor sends the DHCPTLS message to the
DHCPV4 server: DHCPV4 server:
1. No response from the DHCPv4 server. 1. No response from the DHCPv4 server.
2. The DHCPv4 server drops the TCP connection after it receives the 2. The DHCPv4 server drops the TCP connection after it receives the
DHCPTLS message. DHCPTLS message.
3. DHCPv4 server responds with DHCPTLS message with a dhcp-status- 3. DHCPv4 server responds with a DHCPTLS message with a dhcp-status-
code of TLSConnectionRefused. code of TLSConnectionRefused.
4. DHCPv4 server responds with DHCPTLS message with no dhcp-status- 4. DHCPv4 server responds with DHCPTLS message with no dhcp-status-
code, indicating success. code, indicating success.
In any of the first three possibilities, the DHCPv4 server can be In any of the first three possibilities, the DHCPv4 server can be
assumed to not support TLS. In this case, the requestor MAY choose assumed to not support TLS. In this case, the requestor MUST drop
to proceed with the Active Leasequery request without having it the connection.
protected by TLS.
In the final possibility, where the DHCPv4 server has responded with In the final possibility, where the DHCPv4 server has responded with
a DHCPTLS message with no dhcp-status-code in response to the a DHCPTLS message with no dhcp-status-code in response to the
requestor's DHCPTLS message, the requestor SHOULD initiate the requestor's DHCPTLS message, the requestor SHOULD initiate the
exchange of the messages involved in a TLS handshake [RFC5246]. exchange of the messages involved in a TLS handshake [RFC5246].
During the TLS handshake, the requestor MUST verify the DHCPv4
server's digital certificates.
If the handshake exchange yields a functioning TLS connection, then If the handshake exchange yields a functioning TLS connection, then
the requestor SHOULD transmit an Active Leasequery message message the requestor SHOULD transmit an Active Leasequery message over that
over that TLS connection and use that TLS connection for all further TLS connection and use that TLS connection for all further
interactions in which it engages with the DHCPv4 server over this TCP interactions in which it engages with the DHCPv4 server over this TCP
connection. connection.
If the handshake exchange does not yield a functioning TLS If the handshake exchange does not yield a functioning TLS
connection, then the requestor MUST drop the TCP connection. The connection, then the requestor MUST drop the TCP connection.
requestor MAY create a new TCP connection and MAY choose to proceed
with an Active Leasequery request without using TLS.
7.3. Forming an Active Leasequery 7.3. Forming an Active Leasequery
The Active Leasequery is designed to create a long lived connection The Active Leasequery is designed to create a long lived connection
between the requestor and the DHCPv4 server processing the active between the requestor and the DHCPv4 server processing the active
query. The DHCPv4 server SHOULD send IPv4 address binding query. The DHCPv4 server SHOULD send IPv4 address binding
information back across this connection with minimal delay after it information back across this connection with minimal delay after it
learns of the binding information. It will learn about IPv4 address learns of the binding information. It will learn about IPv4 address
bindings either because it makes the bindings itself or because it bindings either because it makes the bindings itself or because it
has received information about a binding from another server. has received information about a binding from another server.
skipping to change at page 15, line 5 skipping to change at page 15, line 7
after a loss of the Active Leasequery connection. after a loss of the Active Leasequery connection.
The DHCPLEASEQUERYSTATUS message MAY unilaterally terminate a The DHCPLEASEQUERYSTATUS message MAY unilaterally terminate a
successful DHCPACTIVELEASEQUERY request which is currently in successful DHCPACTIVELEASEQUERY request which is currently in
progress in the event that the DHCPv4 server determines that it progress in the event that the DHCPv4 server determines that it
cannot continue processing a DHCPACTIVELEASEQUERY request. For cannot continue processing a DHCPACTIVELEASEQUERY request. For
example, when a server is requested to shut down it SHOULD send a example, when a server is requested to shut down it SHOULD send a
DHCPLEASEQUERYSTATUS message with a dhcp-status-code of DHCPLEASEQUERYSTATUS message with a dhcp-status-code of
QueryTerminated and include in the message a base time. This SHOULD QueryTerminated and include in the message a base time. This SHOULD
be the last message on that connection, and once the message has been be the last message on that connection, and once the message has been
transmistted, the server should close the connection. transmitted, the server should close the connection.
After receiving DHCPLEASEQUERYSTATUS with a QueryTerminated status After receiving DHCPLEASEQUERYSTATUS with a QueryTerminated status
from a server, the Requestor MAY close the TCP connection to that from a server, the Requestor MAY close the TCP connection to that
server. server.
The DHCPv4 Leasequery protocol uses the associated-ip option as an The DHCPv4 Leasequery protocol uses the associated-ip option as an
indicator that multiple bindings were present in response to a single indicator that multiple bindings were present in response to a single
client based query. For Active Leasequery, client-based queries are client based query. For Active Leasequery, client-based queries are
not supported and so the associated-ip option is not used, and MUST not supported and so the associated-ip option is not used, and MUST
NOT be present in replies. NOT be present in replies.
skipping to change at page 17, line 46 skipping to change at page 17, line 50
the connection based on its own configuration. the connection based on its own configuration.
8. Server Behavior 8. Server Behavior
A DHCPv4 server which supports Active Leasequery MUST support Bulk A DHCPv4 server which supports Active Leasequery MUST support Bulk
Leasequery [RFC6926] as well. Leasequery [RFC6926] as well.
8.1. Accepting Connections 8.1. Accepting Connections
DHCPv4 servers that implement DHCPv4 Active Leasequery listen for DHCPv4 servers that implement DHCPv4 Active Leasequery listen for
incoming TCP connections. Port numbers are discussed in Section 5.3. incoming TCP connections. The approach used in accepting the
DHCPv4 servers MUST be able to limit the number of currently accepted requestor's connection is the same as specified in DHCPv4 Bulk
and active connections. The value BULK_LQ_MAX_CONNS MUST be the Leasequery [RFC6926].
default; implementations MAY permit the value to be configurable.
Connections SHOULD be accepted and, if the number of connections is
over BULK_LQ_MAX_CONNS, they SHOULD be closed immediately.
DHCPv4 servers MAY restrict Active Leasequery connections and DHCPv4 servers SHOULD be able to operate in either an insecure or
DHCPACTIVELEASEQUERY messages to certain clients. Connections not secure mode. This MAY be a mode that is administratively controlled,
from permitted clients SHOULD be closed immediately, to avoid server where the server will require a TLS connection to operate or will
connection resource exhaustion. only operate without a TLS connection. Alternatively, the server MAY
allow the client to select the mode through transmission of a DHCPTLS
to select the secure mode or transmission of an Active Leasequery
request to select the insecure mode.
DHCPv4 servers SHOULD support TLS [RFC5246] to protect the integrity When operating in insecure mode, the DHCPv4 server simply waits for
and privacy of the data transmitted over the TCP connection. DHCPv4 the requestor to send the Active Leasequery after the establishment
servers SHOULD negotiate a TLS connection with a requestor who asks of TCP connection. If it receives a DHCPTLS message, it will respond
for one, and MAY choose to accept DHCPACTIVELEASEQUERY messages over with TLSConnectionRefused in a DHCPTLS message.
connections which are not secured with TLS.
When operating in secure mode, DHCPv4 servers MUST support TLS
[RFC5246] to protect the integrity and privacy of the data
transmitted over the TCP connection. DHCPv4 servers SHOULD negotiate
a TLS connection with the requestor who asks for one, and MUST drop
the TCP connections which are not secured with TLS.
When allowing the requestor to select the mode, the DHCPv4 server
will accept either an Active Leasequery request or a DHCPTLS message
after the establishment of the TCP connection, and continue its
processing based on the message received.
A requestor will request a TLS connection by sending a DHCPTLS as the A requestor will request a TLS connection by sending a DHCPTLS as the
first message over a newly created TCP connection. If the DHCPv4 first message over a newly created TCP connection. If the DHCPv4
server supports TLS connections and has not been configured to not server supports TLS connections and has not been configured to not
allow them on this link, the DHCPv4 server SHOULD respond to this allow them on this link, the DHCPv4 server SHOULD 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 for some reason the DHCPv4 server cannot or has been configured to If for some reason the DHCPv4 server cannot or has been configured to
not support a TLS connection, then it SHOULD send a DHCPTLS message not support a TLS connection, then it SHOULD send a DHCPTLS message
with a dhcp-status-code of TLSConnectionRefused back to the with a dhcp-status-code of TLSConnectionRefused back to the
requestor. requestor.
In the event that the DHCPv4 server sends a DHCPTLS message with no In the event that the DHCPv4 server sends a DHCPTLS message with no
dhcp-status-code option included (which indicates success), the dhcp-status-code option included (which indicates success), the
requestor is supposed to initiate a TLS handshake [RFC5246] (see requestor is supposed to initiate a TLS handshake [RFC5246] (see
Section 7.2). Section 7.2). During the TLS handshake, the DHCPv4 server MUST
verify the requestor's digital certificate.
If the TLS handshake is not successful in creating a TLS connection, If the TLS handshake is not successful in creating a TLS connection,
the server MUST drop the TCP connection. the server MUST drop the TCP connection.
In an update to the DHCPv4 Bulk Leasequery protocol [RFC6926] (which In an update to the DHCPv4 Bulk Leasequery protocol [RFC6926] (which
didn't discuss this situation explicitly), if the DHCPv4 server didn't discuss this situation explicitly), if the DHCPv4 server
receives a DHCPv4 message containing a dhcp-message-type option with receives a DHCPv4 message containing a dhcp-message-type option with
a value that is not supported over a TCP connection, it SHOULD drop a value that is not supported over a TCP connection, it SHOULD drop
the TCP connection. the TCP connection.
skipping to change at page 21, line 9 skipping to change at page 21, line 24
client request and the time that the DHCP server sends a reply to a client request and the time that the DHCP server sends a reply to a
DHCPACTIVELEASEQUERY message is a matter of implementation (and thus DHCPACTIVELEASEQUERY message is a matter of implementation (and thus
not something defined by this document). However, the server SHOULD not something defined by this document). However, the server SHOULD
NOT delay responding to the DHCP client in order to transmit a reply NOT delay responding to the DHCP client in order to transmit a reply
to a DHCPACTIVELEASEQUERY message, and the server SHOULD send the to a DHCPACTIVELEASEQUERY message, and the server SHOULD send the
reply to the DHCPACTIVELASEQUERY message as soon as possible after reply to the DHCPACTIVELASEQUERY message as soon as possible after
responding to the client. responding to the client.
8.3. Multiple or Parallel Queries 8.3. Multiple or Parallel Queries
Requestors may want to use an existing connection if they need to Every Active Leasequery request MUST be made on a single TCP
make multiple queries. Servers MAY support reading and processing connection where there is no other request active at the time the
multiple queries from a single connection. A server MUST NOT read request is made. Note that this is different than what was allowed
more query messages from a connection than it is prepared to process in [RFC6926] section 7.7 for Bulk Leasequery requests.
simultaneously.
Typically, a requestor of a Active Leasequery would not need to send Typically, a requestor of a Active Leasequery would not need to send
a second Active Leasequery while the first is still active. However, a second Active Leasequery while the first is still active. However,
sending an Active Leasequery and a Bulk Leasequery over the same sending an Active Leasequery and a Bulk Leasequery in parallel would
connection would be possible and reasonable. be possible and reasonable. In case of parallel Active and Bulk
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 close its end of the TCP connection after sending its
skipping to change at page 21, line 42 skipping to change at page 22, line 9
number of connections it maintains, and SHOULD close idle connections number of connections it maintains, and SHOULD close idle connections
to enforce the limit. to enforce the limit.
The server MUST close its end of the TCP connection if it encounters The server MUST close its end of the TCP connection if it encounters
an error sending data on the connection. The server MUST close its an error sending data on the connection. The server MUST close its
end of the TCP connection if it finds that it has to abort an in- end of the TCP connection if it finds that it has to abort an in-
process request. A server aborting an in-process request SHOULD process request. A server aborting an in-process request SHOULD
attempt to signal that to its clients by using the QueryTerminated attempt to signal that to its clients by using the QueryTerminated
status code in the dhcp-status-code option in a DHCPLEASEQUERYSTATUS status code in the dhcp-status-code option in a DHCPLEASEQUERYSTATUS
message. If the server detects that the client end has been closed, message. If the server detects that the client end has been closed,
the server MUST close its end of the connection after it has finished the server MUST close its end of the connection.
processing any outstanding requests.
9. Security Considerations 9. Security Considerations
The "Security Considerations" section of [RFC2131] details the The "Security Considerations" section of [RFC2131] details the
general threats to DHCPv4. The DHCPv4 Leasequery specification general threats to DHCPv4. The DHCPv4 Leasequery specification
[RFC4388] describes recommendations for the Leasequery protocol, [RFC4388] describes recommendations for the Leasequery protocol,
especially with regard to relayed LEASEQUERY messages, mitigation of especially with regard to relayed LEASEQUERY messages, mitigation of
packet-flooding DOS attacks, restriction to trusted clients, and use packet-flooding DOS attacks, restriction to trusted clients, and use
of IPsec [RFC4301]. of IPsec [RFC4301].
This capability SHOULD be disabled by default. This capability SHOULD be disabled by default.
The use of TCP introduces some additional concerns. Attacks that The use of TCP introduces some additional concerns. Attacks that
attempt to exhaust the DHCPv4 server's available TCP connection attempt to exhaust the DHCPv4 server's available TCP connection
resources, such as SYN flooding attacks, can compromise the ability resources can compromise the ability of legitimate clients to receive
of legitimate clients to receive service. Malicious clients who service. Malicious clients who succeed in establishing connections,
succeed in establishing connections, but who then send invalid but who then send invalid queries, partial queries, or no queries at
queries, partial queries, or no queries at all also can exhaust a all also can exhaust a server's pool of available connections. We
server's pool of available connections. We recommend that servers recommend that servers offer configuration to limit the sources of
offer configuration to limit the sources of incoming connections, incoming connections, that they limit the number of accepted
that they limit the number of accepted connections and the number of connections, and that they limit the period of time during which an
in-process queries from any one connection, and that they limit the idle connection will be left open.
period of time during which an idle connection will be left open.
Servers which implement the Bulk Leasequery protocol [RFC6926] but do Servers which implement the Bulk Leasequery protocol [RFC6926] but do
not implement the Active Leasequery protocol SHOULD implement the not implement the Active Leasequery protocol SHOULD implement the
update to [RFC6926] discussed in section Section 8.1. update to [RFC6926] discussed in Section 8.1.
There are two specific issues regarding Active Leasequery security
that deserve explicit mention. The first is preventing information
that Active Leasequery can provide from reaching requestors who are
not authorized to receive such information. The second is ensuring
that authorized requestors of the Active Leasequery capability
receive accurate information from the Server (and that this
information is not disrupted in transit).
Requestors and servers SHOULD use TLS [RFC5246] to protect the
integrity and privacy of the Active Leasequery data transmitted over
the TCP connection.
10. IANA Considerations 10. IANA Considerations
IANA is requested to assign the following new DHCP message types from IANA is requested to assign the following new DHCP message types from
the registry "DHCP Message Type 53 Values" maintained at the registry "DHCP Message Type 53 Values" maintained at
http://www.iana.org/assignments/bootp-dhcp-parameters: http://www.iana.org/assignments/bootp-dhcp-parameters:
1. A dhcp-message-type of TBD1 for DHCPACTIVELEASEQUERY. 1. A dhcp-message-type of TBD1 for DHCPACTIVELEASEQUERY.
2. A dhcp-message-type of TBD2 for DHCPLEASEQUERYSTATUS. 2. A dhcp-message-type of TBD2 for DHCPLEASEQUERYSTATUS.
 End of changes. 30 change blocks. 
92 lines changed or deleted 93 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/