draft-ietf-dhc-dhcpv4-active-leasequery-05.txt   draft-ietf-dhc-dhcpv4-active-leasequery-06.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: February 25, 2016 N. Russell Expires: March 17, 2016 N. Russell
Staples Staples
August 24, 2015 September 14, 2015
Active DHCPv4 Lease Query Active DHCPv4 Lease Query
draft-ietf-dhc-dhcpv4-active-leasequery-05.txt draft-ietf-dhc-dhcpv4-active-leasequery-06.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. That mechanism is limited request information about DHCPv4 bindings [RFC4388]. That mechanism
to queries for individual bindings. In some situations individual is limited to queries for individual bindings. In some situations
binding queries may not be efficient, or even possible. In addition, individual binding queries may not be efficient, or even possible.
continuous update of an external requestor with Leasequery data is In addition, continuous update of an external requestor with
sometimes desired. This document expands on the DHCPv4 Leasequery Leasequery data is sometimes desired. This document expands on the
protocol, and allows for active transfer of near real-time DHCPv4 DHCPv4 Leasequery protocol, and allows for active transfer of near
binding information data via TCP. This document updates RFC6926, real-time DHCPv4 binding information data via TCP. This document
DHCPv4 Bulk Leasequery. updates RFC6926, DHCPv4 Bulk Leasequery.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 25, 2016. This Internet-Draft will expire on March 17, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Interaction Between Active Leasequery and Bulk Leasequery . . 7 4. Interaction Between Active Leasequery and Bulk Leasequery . . 7
5. Message and Option Definitions . . . . . . . . . . . . . . . 8 5. Message and Option Definitions . . . . . . . . . . . . . . . 8
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 8 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 8
5.2. New or Changed Options . . . . . . . . . . . . . . . . . 8 5.2. New or Changed Options . . . . . . . . . . . . . . . . . 8
5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 8 5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 8
5.2.2. dhcp-status-code . . . . . . . . . . . . . . . . . . 8 5.2.2. dhcp-status-code . . . . . . . . . . . . . . . . . . 9
5.3. Connection and Transmission Parameters . . . . . . . . . 9 5.3. Connection and Transmission Parameters . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 11
7.3. Forming an Active Leasequery . . . . . . . . . . . . . . 12 7.3. Forming an Active Leasequery . . . . . . . . . . . . . . 13
7.4. Processing Active Replies . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . 15
7.5. Closing Connections . . . . . . . . . . . . . . . . . . . 17 7.5. Closing Connections . . . . . . . . . . . . . . . . . . . 18
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 17 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 18 8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 18
8.2. Replying to an Active Leasequery . . . . . . . . . . . . 19 8.1.1. Update to RFC 6926 . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 25 12.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4 The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4
capability [RFC2131] [RFC2132] to allow an external entity to query a capability [RFC2131] [RFC2132] to allow an external entity to query a
DHCPv4 server to recover lease state information about a particular DHCPv4 server to recover lease state information about a particular
IPv4 address or client in near real-time. IPv4 address or client in near real-time.
Requirements exist for external entities to keep up to date on the Continuous update of an external requestor with Leasequery data is
correspondence between DHCPv4 clients and their bindings. These sometimes desired. These requestors need to keep up with the current
entities need to keep up with the current binding activity of the binding activity of the DHCPv4 server. Keeping up with these binding
DHCPv4 server. Keeping up with these binding activities is termed activities is termed "active" leasequery.
"active" leasequery.
The DHCPv4 Bulk Leasequery [RFC6926] capability can be used to The DHCPv4 Bulk Leasequery [RFC6926] capability can be used to
recover useful information from a DHCPv4 server when some external recover useful information from a DHCPv4 server when some external
entity starts up. This entity could be one which is directly entity starts up. This entity could be one which is directly
involved in the DHCPv4 client - server transactions (e.g., a relay involved in the DHCPv4 client - server transactions (e.g., a relay
agent), or it could be an external process which needs information agent), or it could be an external process which needs information
present in the DHCPv4 server's lease state database. present in the DHCPv4 server's lease state database.
The Active Leasequery capability documented here is designed to allow The Active Leasequery capability documented here is designed to allow
an entity not directly involved in DHCPv4 client - server an entity not directly involved in DHCPv4 client - server
transactions to nevertheless keep current with the state of the transactions to nevertheless keep current with the state of the
DHCPv4 lease state information in real-time. DHCPv4 lease state information in real-time.
This document updates DHCPv4 Bulk Leasequery [RFC6926] in that it 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 should 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. (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:
o "Active Leasequery" o "Active Leasequery"
skipping to change at page 5, line 16 skipping to change at page 5, line 16
A DHCPv4 relay agent is a third-party agent that transfers BOOTP A DHCPv4 relay agent is a third-party agent that transfers BOOTP
and DHCPv4 messages between clients and servers residing on and DHCPv4 messages between clients and servers residing on
different subnets, per [RFC0951] and [RFC1542]. different subnets, per [RFC0951] and [RFC1542].
o "DHCPv4 server" o "DHCPv4 server"
A DHCPv4 server is an IPv4 node that returns configuration A DHCPv4 server is an IPv4 node that returns configuration
parameters to DHCPv4 clients. parameters to DHCPv4 clients.
o "insecure mode"
When operating in insecure mode, the TCP connection between the
requestor and DHCPv4 server is not protected in any way. In
addition, the identity of the requestor is not validated by the
server nor is the identity of the server validated by the
requestor.
o "MAC address" o "MAC address"
In the context of a DHCP message, a MAC address consists of the In the context of a DHCP message, a MAC address consists of the
fields: hardware type "htype", hardware length "hlen", and client fields: hardware type "htype", hardware length "hlen", and client
hardware address "chaddr". hardware address "chaddr".
o "requestor" o "requestor"
The node that sends LEASEQUERY messages to one or more servers to The node that sends LEASEQUERY messages to one or more servers to
retrieve information on the bindings for a client. retrieve information on the bindings for a client.
o "secure mode"
When operating in secure mode, the TCP connection between the
requestor and the DHCPv4 server is protected by TLS [RFC5246]. In
addition, the requestor uses the certificates exchanged between it
and the DHCPv4 server while setting up the TLS connection to
validate the identity of the server. The DHCPv4 server also uses
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.
An Active Leasequery requestor opens a TCP connection to a DHCPv4 An Active Leasequery requestor opens a TCP connection to a DHCPv4
skipping to change at page 19, line 30 skipping to change at page 19, line 42
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.
In an update to the DHCPv4 Bulk Leasequery protocol [RFC6926] (which
didn't discuss this situation explicitly), if the DHCPv4 server
receives a DHCPv4 message containing a dhcp-message-type option with
a value that is not supported over a TCP connection, it SHOULD close
the TCP connection.
If the TCP connection becomes blocked while the server is accepting a If the TCP connection becomes blocked while the server is accepting a
connection or reading a query, it SHOULD terminate the connection connection or reading a query, it SHOULD terminate the connection
after a BULK_LQ_DATA_TIMEOUT. We make this recommendation to allow after a BULK_LQ_DATA_TIMEOUT. We make this recommendation to allow
servers to control the period of time they are willing to wait before servers to control the period of time they are willing to wait before
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
In an update to the DHCPv4 Bulk Leasequery protocol [RFC6926] (which
didn't discuss this situation explicitly), if the DHCPv4 server
receives a DHCPv4 message containing a dhcp-message-type option with
a value that is not supported over a TCP connection, it SHOULD close
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
goes by without the requestor reading enough information to unblock goes by without the requestor reading enough information to unblock
the TCP connection, the DHCPv4 server SHOULD close the TCP the TCP connection, the DHCPv4 server SHOULD close the TCP
skipping to change at page 23, line 29 skipping to change at page 23, line 44
The data acquired by using an Active Leasequery is subject to the The data acquired by using an Active Leasequery is subject to the
same potential abuse as the data held by the DHCPv4 server from which same potential abuse as the data held by the DHCPv4 server from which
it was acquired, and SHOULD be secured by mechanisms as strong as it was acquired, and SHOULD be secured by mechanisms as strong as
those used for the data held by that DHCPv4 server. The data those used for the data held by that DHCPv4 server. The data
acquired by using an Active Leasequery SHOULD be deleted as soon as acquired by using an Active Leasequery SHOULD be deleted as soon as
possible after the use for which it was acquired has passed. possible after the use for which it was acquired has passed.
Servers which implement the Bulk Leasequery protocol [RFC6926] but do Servers which implement the Bulk Leasequery protocol [RFC6926] but do
not implement the Active Leasequery protocol SHOULD implement the not implement the Active Leasequery protocol SHOULD implement the
update to [RFC6926] discussed in Section 8.1. update to [RFC6926] discussed in Section 8.1.1.
10. IANA Considerations 10. IANA Considerations
IANA is requested to assign the following new DHCP message types from IANA is requested to assign the following new DHCP message types from
the registry "DHCP Message Type 53 Values" maintained at the registry "DHCP Message Type 53 Values" maintained at
http://www.iana.org/assignments/bootp-dhcp-parameters: http://www.iana.org/assignments/bootp-dhcp-parameters:
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. 17 change blocks. 
33 lines changed or deleted 52 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/