draft-ietf-dhc-dhcpv4-active-leasequery-04.txt   draft-ietf-dhc-dhcpv4-active-leasequery-05.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 12, 2016 N. Russell Expires: February 25, 2016 N. Russell
Staples Staples
August 11, 2015 August 24, 2015
Active DHCPv4 Lease Query Active DHCPv4 Lease Query
draft-ietf-dhc-dhcpv4-active-leasequery-04.txt draft-ietf-dhc-dhcpv4-active-leasequery-05.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. That mechanism is limited
to queries for individual bindings. In some situations individual to queries for individual bindings. In some situations individual
binding queries may not be efficient, or even possible. In addition, binding queries may not be efficient, or even possible. In addition,
continuous update of an external requestor with Leasequery data is continuous update of an external requestor with Leasequery data is
sometimes desired. This document expands on the DHCPv4 Leasequery sometimes desired. This document expands on the DHCPv4 Leasequery
protocol, and allows for active transfer of near real-time DHCPv4 protocol, and allows for active transfer of near real-time DHCPv4
address binding information data via TCP. This document updates binding information data via TCP. This document updates RFC6926,
RFC6926, DHCPv4 Bulk Leasequery. 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 12, 2016. This Internet-Draft will expire on February 25, 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 . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . 18 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 18 8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 18
8.2. Replying to an Active Leasequery . . . . . . . . . . . . 19 8.2. Replying to an Active Leasequery . . . . . . . . . . . . 19
8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 22
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 Requirements exist for external entities to keep up to date on the
correspondence between DHCPv4 clients and the IPv4 addresses for correspondence between DHCPv4 clients and their bindings. These
which they have leases. These entities need to keep up with the entities need to keep up with the current binding activity of the
current IPv4 address binding activity of the DHCPv4 server. Keeping DHCPv4 server. Keeping up with these binding activities is termed
up with address binding activity 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). (for example, DHCPDISCOVER, DHCPLEASEQUERY). See Section 8.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 "address binding" o "Active Leasequery"
Keeping up to date in real-time (or near real-time) with DHCPv4
binding activity.
o "binding"
The information that a DHCPv4 server keeps regarding the The information that a DHCPv4 server keeps regarding the
relationship between a DHCPv4 client and an IPv4 address. This relationship between a DHCPv4 client and an IPv4 address. This
includes the identity of the DHCPv4 client and the expiration includes the identity of the DHCPv4 client and the expiration
time, if any, of any lease that client has on a particular IPv4 time, if any, of any lease that client has on a particular IPv4
address. address.
o "Active Leasequery"
Keeping up to date in real-time (or near real-time) with DHCPv4
address binding activity.
o "Bulk Leasequery" o "Bulk Leasequery"
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 binding information in an efficient manner, as
manner, as defined by [RFC6926]. 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" 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 binding information sent to satisfy this request is the catch-up
catch-up information. information.
o "catch-up phase" o "catch-up phase"
The period while the catch-up information is being sent is the 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
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 "IP address binding"
The information that a DHCPv4 server keeps regarding the
relationship between a DHCPv4 client and an IPv4 address. This
includes the identity of the DHCPv4 client and the expiration
time, if any, of any lease that client has on a particular IPv4
address.
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.
skipping to change at page 6, line 24 skipping to change at page 6, line 14
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
IPv4 address binding activity to an external entity. binding activity to an external entity.
Active Leasequery has features which allow this external entity to Active Leasequery has features which allow this external entity to
lose its connection and then reconnect and receive the latest lose its connection and then reconnect and receive the latest
information concerning any IPv4 addresses changed while it was not information concerning any IPv4 bindings changed while it was not
connected. connected.
These capabilities are designed to allow the Active Leasequery These capabilities are designed to allow the Active Leasequery
requestor to efficiently become current with respect to the lease requestor to efficiently become current with respect to the lease
state database after it has been restarted or the machine on which it state database after it has been restarted or the machine on which it
is running has been reinitialized. It is easy to define a protocol is running has been reinitialized. It is easy to define a protocol
which works when the requestor is always connected to the DHCPv4 which works when the requestor is always connected to the DHCPv4
server. Since that isn't sufficiently robust, much of the mechanism server. Since that isn't sufficiently robust, much of the mechanism
in this document is designed to deal efficiently with situations that in this document is designed to deal efficiently with situations that
occur when the Active Leasequery requestor becomes disconnected from occur when the Active Leasequery requestor becomes disconnected from
skipping to change at page 7, line 15 skipping to change at page 7, line 7
available through an Active Leasequery. available through an Active Leasequery.
DHCPv4 servers are not required to keep any data corresponding to DHCPv4 servers are not required to keep any data corresponding to
data missed on a Active Leasequery connection, but will typically data missed on a Active Leasequery connection, but will typically
choose to keep data corresponding to some recent activity available choose to keep data corresponding to some recent activity available
for subsequent queries by a DHCPv4 Active Leasequery requestor whose for subsequent queries by a DHCPv4 Active Leasequery requestor whose
connection was temporarily interrupted. connection was temporarily interrupted.
An Active Leasequery requestor would typically use Bulk Leasequery to An Active Leasequery requestor would typically use Bulk Leasequery to
initialize its database with all current data when that database initialize its database with all current data when that database
contains no address binding information. In addition, it would use contains no binding information. In addition, it would use Bulk
Bulk Leasequery to recover missed information in the event that its Leasequery to recover missed information in the event that its
connection with the DHCPv4 server was lost for a longer time than the connection with the DHCPv4 server was lost for a longer time than the
DHCPv4 server would keep track of the specific changes to the IPv4 DHCPv4 server would keep track of the specific changes to the IPv4
address binding information. 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, with the exception that followed when implementing Active Leasequery, with the exception that
a server responding to an Active Leasequery request SHOULD be able to a server responding to an Active Leasequery request SHOULD be able to
be configured to prevent specific data items from being included in be configured to prevent specific data items from being included in
the response to the requestor even if they were requested by the response to the requestor even if they were requested by
inclusion in the dhcp-parameter-request-list option. inclusion in the dhcp-parameter-request-list option.
4. Interaction Between Active Leasequery and Bulk Leasequery 4. Interaction Between Active Leasequery and Bulk Leasequery
Active Leasequery is an extension of the Bulk Leasequery protocol Active Leasequery is an extension of the Bulk Leasequery protocol
[RFC6926]. The contents of packets returned to an Active Leasequery [RFC6926]. The contents of messages returned to an Active Leasequery
requestor are identical to that defined for the Bulk Leasequery requestor are identical to that defined for the Bulk Leasequery
protocol. protocol.
Applications which employ Active Leasequery to keep a database up to Applications which employ Active Leasequery to keep a database up to
date with respect to the DHCPv4 server's lease state database should date with respect to the DHCPv4 server's lease state database should
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.
skipping to change at page 9, line 24 skipping to change at page 9, line 17
information in a single leasequery reply if the value of the dhcp- information in a single leasequery reply if the value of the dhcp-
message-type is DHCPLEASEACTIVE, DHCPLEASEUNASSIGNED or DHCPTLS. It message-type is DHCPLEASEACTIVE, DHCPLEASEUNASSIGNED or DHCPTLS. It
refers to the message stream related to an entire request if the refers to the message stream related to an entire request if the
value of the dhcp-message-type is DHCPLEASEQUERYSTATUS. value of the dhcp-message-type is DHCPLEASEQUERYSTATUS.
Additional status codes defined for support of Active Leasequery are: Additional status codes defined for support of Active Leasequery are:
+----------------------+-------------+------------------------------+ +----------------------+-------------+------------------------------+
| Name | status-code | Description | | Name | status-code | Description |
+----------------------+-------------+------------------------------+ +----------------------+-------------+------------------------------+
| DataMissing | TBD4 | Indicates that IPv4 address | | DataMissing | TBD4 | Indicates that IPv4 binding |
| | | binding information | | | | information requested is not |
| | | requested is not available. | | | | available. |
| ConnectionActive | TBD5 | Indicates that this | | ConnectionActive | TBD5 | Indicates that this |
| | | connection remains active. | | | | connection remains active. |
| CatchUpComplete | TBD6 | Indicates that this Active | | CatchUpComplete | TBD6 | Indicates that this Active |
| | | Leasequery connection has | | | | Leasequery connection has |
| | | completed sending all of the | | | | completed sending all of the |
| | | saved data requested. | | | | saved data requested. |
| TLSConnectionRefused | TBD7 | Indicates that a TLS | | TLSConnectionRefused | TBD7 | Indicates that a TLS |
| | | connection is not allowed. | | | | connection is not allowed. |
+----------------------+-------------+------------------------------+ +----------------------+-------------+------------------------------+
skipping to change at page 10, line 25 skipping to change at page 10, line 22
| ACTIVE_LQ_IDLE_TIMEOUT | 60 secs | Active Leasequery idle | | ACTIVE_LQ_IDLE_TIMEOUT | 60 secs | Active Leasequery idle |
| | | timeout | | | | timeout |
+------------------------+----------+-------------------------------+ +------------------------+----------+-------------------------------+
6. Information Communicated by Active Leasequery 6. Information Communicated by Active Leasequery
While the information communicated by a Bulk Leasequery [RFC6926] is While the information communicated by a Bulk Leasequery [RFC6926] is
taken directly from the DHCPv4 server's lease state database, the taken directly from the DHCPv4 server's lease state database, the
information communicated by an Active Leasequery is real-time information communicated by an Active Leasequery is real-time
information. As such, it is the information which is currently information. As such, it is the information which is currently
associated with a particular IPv4 address in the DHCPv4 server's associated with a particular binding in the DHCPv4 server's lease
lease state database. state database.
This is of significance, because if the Active Leasequery requestor This is of significance, because if the Active Leasequery requestor
runs slowly or the requestor disconnects from the DHCPv4 server and runs slowly or the requestor disconnects from the DHCPv4 server and
then reconnects with a query-start-time (signaling a catch-up then reconnects with a query-start-time (signaling a catch-up
operation), the information communicated to the Active Leasequery operation), the information communicated to the Active Leasequery
requestor is only the most current information from the DHCPv4 requestor is only the most current information from the DHCPv4
server's lease state database. server's lease state database.
The requestor of an Active Leasequery MUST NOT assume that every The requestor of an Active Leasequery MUST NOT assume that every
lease state change is communicated across an Active Leasequery lease state change is communicated across an Active Leasequery
connection. Even if the Active Leasequery requestor remains connection. Even if the Active Leasequery requestor remains
connected, the DHCPv4 server is only required to transmit information connected, the DHCPv4 server is only required to transmit information
about an IPv4 address that is current when the packet is created and about a binding that is current when the packet is created and handed
handed off to the TCP stack to send to the requestor. off to the TCP stack to send to the requestor.
If the TCP connection blocks and the DHCPv4 server is waiting to send If the TCP connection blocks and the DHCPv4 server is waiting to send
information down the connection, when the connection becomes information down the connection, when the connection becomes
available to be written the DHCPv4 server MAY create the packet to available to be written the DHCPv4 server MAY create the packet to
send at this time. The current state of the IPv4 address will be send at this time. The current state of the binding will be sent,
sent, and any transition in state or other information that occurred and any transition in state or other information that occurred while
while the TCP connection was blocked will be lost. the TCP connection was blocked will be lost.
Thus, the Active Leasequery protocol does not allow the requestor to Thus, the Active Leasequery protocol does not allow the requestor to
build a complete history of every activity on every lease. An build a complete history of every activity on every lease. An
effective history of the important state changes for a lease can be effective history of the important state changes for a lease can be
created if the parameters of the DHCPv4 server are tuned to take into created if the parameters of the DHCPv4 server are tuned to take into
account the requirements of an Active Leasequery requestor. For account the requirements of an Active Leasequery requestor. For
instance, the period after the expiration or release of an IPv4 instance, the period after the expiration or release of a binding
address could be configured long enough (say several minutes, well could be configured long enough (say several minutes, well more than
more than the receive timeout), so that an Active Leasequery the receive timeout), so that an Active Leasequery requestor would
requestor would never miss any changes in the client to IPv4 address never miss any changes in the binding.
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.
If an Active Leasequery is terminated prematurely by a If an Active Leasequery is terminated prematurely by a
skipping to change at page 11, line 35 skipping to change at page 11, line 30
Messages from the DHCPv4 server come as multiple responses to a Messages from the DHCPv4 server come as multiple responses to a
single DHCPACTIVELEASEQUERY message. Thus, each DHCPACTIVELEASEQUERY single DHCPACTIVELEASEQUERY message. Thus, each DHCPACTIVELEASEQUERY
or DHCPBULKLEASEQUERY request MUST have an xid (transaction-id) or DHCPBULKLEASEQUERY request MUST have an xid (transaction-id)
unique on the connection on which it is sent, and all of the messages unique on the connection on which it is sent, and all of the messages
which come as a response to it all contain the same xid as the which come as a response to it all contain the same xid as the
request. request.
7.2. Initiating a Connection 7.2. Initiating a Connection
A requestor should be able to operate in either insecure or secure A requestor SHOULD be able to operate in either insecure or secure
mode. This MAY be a feature that is administratively controlled. mode. This MAY be a feature that is administratively controlled.
When operating in insecure mode, the requestor SHOULD proceed to send When operating in insecure mode, the requestor SHOULD proceed to send
a DHCPACTIVELEASEQUERY request after the establishment of a TCP a DHCPACTIVELEASEQUERY request after the establishment of a TCP
connection. connection.
When operating in secure mode, the requestor MUST attempt to When operating in secure mode, the requestor MUST attempt to
negotiate a TLS [RFC5246] connection over the TCP connection. If negotiate a TLS [RFC5246] connection over the TCP connection. If
this negotiation fails, the requestor must 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] SHOULD be followed when negotiating
this connection. this connection.
A requestor requests the establishment of a TLS connection by sending A requestor requests the establishment of a TLS connection by sending
the DHCPTLS message to the DHCPv4 server as the first message over the DHCPTLS message to the DHCPv4 server as the first message over
the TCP connection. 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:
skipping to change at page 12, line 43 skipping to change at page 12, line 38
interactions in which it engages with the DHCPv4 server over this TCP interactions in which it engages with the DHCPv4 server over this TCP
connection. connection.
If the handshake exchange does not yield a functioning TLS If the handshake exchange does not yield a functioning TLS
connection, then the requestor MUST close the TCP connection. connection, then the requestor MUST close the TCP connection.
7.3. Forming an Active Leasequery 7.3. Forming an Active Leasequery
The Active Leasequery is designed to create a long lived connection The Active Leasequery is designed to create a long lived connection
between the requestor and the DHCPv4 server processing the active between the requestor and the DHCPv4 server processing the active
query. The DHCPv4 server SHOULD send IPv4 address binding query. The DHCPv4 server SHOULD send binding information back across
information back across this connection with minimal delay after it this connection with minimal delay after it learns of the binding
learns of the binding information. It will learn about IPv4 address information. It will learn about the bindings either because it
bindings either because it makes the bindings itself or because it makes the bindings itself or because it has received information
has received information about a binding from another server. about a binding from another server.
An Active Leasequery is a DHCPv4 request with a dhcp-message-type of An Active Leasequery is a DHCPv4 request with a dhcp-message-type of
DHCPACTIVELEASEQUERY. The DHCPv4 request MUST NOT have a ciaddr, a DHCPACTIVELEASEQUERY. The DHCPv4 request MUST NOT have a ciaddr, a
chaddr, or a dhcp-client-identifier. The DHCPv4 request MUST have an chaddr, or a dhcp-client-identifier. The DHCPv4 request MUST have an
xid (transaction-id) unique on the connection on which it is sent. xid (transaction-id) unique on the connection on which it is sent.
The DHCPv4 request SHOULD have a dhcp-parameter-request-list to The DHCPv4 request SHOULD have a dhcp-parameter-request-list to
inform the DHCPv4 server which DHCPv4 options are of interest to the inform the DHCPv4 server which DHCPv4 options are of interest to the
requestor sending the DHCPACTIVELEASEQUERY message. requestor sending the DHCPACTIVELEASEQUERY message.
An important capability of the Active Leasequery is the ability of An important capability of the Active Leasequery is 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 IPv4 the requestor in parallel with the transmission of the ongoing
address binding information in more or less real time. This binding information in more or less real time. This capability is
capability is used in order to allow an Active Leasequery requestor used in order to allow an Active Leasequery requestor to recover
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 Note that until all of the recent data (catch-up data) has been
received, the requestor MUST NOT keep track of the base time received received, the requestor MUST NOT keep track of the base time received
in Leasequery reply messages to use later in a subsequent Bulk in Leasequery reply messages to use later in a subsequent Bulk
Leasequery or Active Leasequery request. Leasequery or Active Leasequery request.
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
skipping to change at page 14, line 31 skipping to change at page 14, line 25
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.
A successful query that is returning binding data MUST include a non- A successful query that is returning binding data MUST include a non-
zero ciaddr. It may also include a non-zero chaddr, htype, and hlen zero ciaddr. It may also include a non-zero chaddr, htype, and hlen
as well as additional options. If there are additional bindings to as well as additional options. If there are additional bindings to
be returned, they will be carried in additional Active Leasequery be returned, they will be carried in additional Active Leasequery
messages. messages.
Any requestor of an Active Leasequery operation MUST be prepared to Any requestor of an Active Leasequery operation MUST be prepared to
receive multiple copies of the IPv4 address binding information for a receive multiple copies of the binding information for a particular
particular IPv4 address. See the Bulk Leasequery document [RFC6926] IPv4 address. See the Bulk Leasequery document [RFC6926] for
for information on how to deal with this situation. information on how to deal with this situation.
A single Active Leasequery can and usually will result in a large A single Active Leasequery can and usually will result in a large
number of replies. The Requestor MUST be prepared to receive more number of replies. The Requestor MUST be prepared to receive more
than one reply with transaction-ids matching a single than one reply with transaction-ids matching a single
DHCPACTIVELEASEQUERY message from a single DHCPv4 server. DHCPACTIVELEASEQUERY message from a single DHCPv4 server.
A DHCPACTIVELEASEQUERY has two regimes -- during the catch-up phase, A DHCPACTIVELEASEQUERY has two regimes -- during the catch-up phase,
if any, and after any catch-up phase. If the DHCPACTIVELASEQUERY if any, and after any catch-up phase. If the DHCPACTIVELASEQUERY
request had a query-start-time, then the DHCPACTIVELEASEQUERY starts request had a query-start-time, then the DHCPACTIVELEASEQUERY starts
out in the catch-up phase. See Section 7.4.1 for information on out in the catch-up phase. See Section 7.4.1 for information on
skipping to change at page 15, line 32 skipping to change at page 15, line 28
The DHCPv4 Leasequery protocol uses the associated-ip option as an The DHCPv4 Leasequery protocol uses the associated-ip option as an
indicator that multiple bindings were present in response to a single indicator that multiple bindings were present in response to a single
client based query. For Active Leasequery, client-based queries are client based query. For Active Leasequery, client-based queries are
not supported and so the associated-ip option is not used, and MUST not supported and so the associated-ip option is not used, and MUST
NOT be present in replies. NOT be present in replies.
7.4.1. Processing Replies from a Request Containing a query-start-time 7.4.1. Processing Replies from a Request Containing a query-start-time
If the DHCPACTIVELEASEQUERY was requested with a query-start-time, If the DHCPACTIVELEASEQUERY was requested with a query-start-time,
the DHCPv4 server will attempt to send information about all IPv4 the DHCPv4 server will attempt to send information about all bindings
address bindings that changed since the time specified in the query- that changed since the time specified in the query- start-time. This
start-time. This is the catch-up phase of the DHCPACTIVELEASEQUERY is the catch-up phase of the DHCPACTIVELEASEQUERY processing. The
processing. The DHCPv4 server MAY also begin immediate updates over DHCPv4 server MAY also begin immediate updates over the same
the same connection of real-time IPv4 address binding information connection of real-time binding information changes. Thus, the
changes. Thus, the catch-up phase can run in parallel with the catch-up phase can run in parallel with the normal updates generated
normal updates generated by the DHCPACTIVELEASEQUERY request. by the DHCPACTIVELEASEQUERY request.
A DHCPv4 server MAY keep only a limited amount of time ordered A DHCPv4 server MAY keep only a limited amount of time ordered
information available to respond to a DHCPACTIVELEASEQUERY request information available to respond to a DHCPACTIVELEASEQUERY request
containing a query-start-time. Thus, it is possible that the time containing a query-start-time. Thus, it is possible that the time
specified in the query-start-time represents a time not covered by specified in the query-start-time represents a time not covered by
the time ordered information kept by the DHCPv4 server. In such the time ordered information kept by the DHCPv4 server. In such
case, when there is not enough data saved in the DHCPv4 server to case, when there is not enough data saved in the DHCPv4 server to
satisfy the request specified by the query-start-time option, the satisfy the request specified by the query-start-time option, the
DHCPv4 server will reply immediately with a DHCPLEASEQUERYSTATUS DHCPv4 server will reply immediately with a DHCPLEASEQUERYSTATUS
message with a dhcp-status-code of DataMissing with a base-time message with a dhcp-status-code of DataMissing with a base-time
option equal to the server's current time. This will signal the end option equal to the server's current time. This will signal the end
of the catch-up phase, and the only updates that will subsequently be of the catch-up phase, and the only updates that will subsequently be
received on this connection are the real-time updates from the received on this connection are the real-time updates from the
DHCPACTIVELEASEQUERY request. DHCPACTIVELEASEQUERY request.
If there is enough data saved to satisfy the request, then If there is enough data saved to satisfy the request, then
DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages will begin arrive DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages will begin arrive
from the DHCPv4 server. Some of these messages will be related to from the DHCPv4 server. Some of these messages will be related to
the query-start-time request and be part of the catch-up phase. Some the query-start-time request and be part of the catch-up phase. Some
of these messages will be real-time updates of IPv4 address binding of these messages will be real-time updates of binding changes taking
changes taking place in the DHCPv4 server. In general, there is no place in the DHCPv4 server. In general, there is no way to determine
way to determine the source each message. the source each message.
The updates sent by the DHCPv4 server during the catch-up phase are The updates sent by the DHCPv4 server during the catch-up phase are
not in the order that the lease state data was updated. Therefore, not in the order that the binding data was updated. Therefore, until
until the catch-up phase is complete, the latest base-time value the catch-up phase is complete, the latest base-time value received
received from a DHCPv4 server processing an Active Leasequery request from a DHCPv4 server processing an Active Leasequery request cannot
cannot be reset from the incoming messages (and used in a subsequent be reset from the incoming messages (and used in a subsequent Active
Active Leasequery's query-start-time option), because to do so would Leasequery's query-start-time option), because to do so would
compromise the ability to recover lost information if the compromise the ability to recover lost information if the
DHCPACTIVELEASEQUERY were to terminate prior to the completion of the DHCPACTIVELEASEQUERY were to terminate prior to the completion of the
catch-up phase. catch-up phase.
The requestor will know that the catch-up phase is complete because The requestor will know that the catch-up phase is complete because
the DHCPv4 server will transmit a DHCPLEASEQUERYSTATUS message with the DHCPv4 server will transmit a DHCPLEASEQUERYSTATUS message with
the dhcp-status-code of CatchUpComplete (or, as discussed above, the dhcp-status-code of CatchUpComplete (or, as discussed above,
DataMissing). Once this message is transmitted, all additional DataMissing). Once this message is transmitted, all additional
DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages will relate to real- DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages will relate to real-
time ("new") IPv4 address binding changes in the DHCPv4 server. time ("new") binding changes in the DHCPv4 server.
As discussed in Section 6.3, the requestor SHOULD keep track of the As discussed in Section 6.3, the requestor SHOULD keep track of the
latest base-time option value received over a particular connection, latest base-time option value received over a particular connection,
to be used in a subsequent DHCPACTIVELEASEQUERY request -- but only to be used in a subsequent DHCPACTIVELEASEQUERY request -- but only
if the catch-up phase is complete. Prior to the completion of the if the catch-up phase is complete. Prior to the completion of the
catch-up phase, if the connection should go away or if the requestor catch-up phase, if the connection should go away or if the requestor
receives a DHCPLEASEQUERYDONE message, then when it reconnects it receives a DHCPLEASEQUERYDONE message, then when it reconnects it
MUST use the base-time value from the previous connection and not any MUST use the base-time value from the previous connection and not any
base-time value received from the recently closed connection. base-time value received from the recently closed connection.
skipping to change at page 17, line 6 skipping to change at page 16, line 46
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 IPv4 address during the period from the time specified in the every binding during the period from the time specified in the query-
query-start-time and the present is replicated in an Active start-time and the present is replicated in an Active Leasequery
Leasequery reply message. The requestor MAY assume that at least one reply message. The requestor MAY assume that at least one Active
Active Leasequery reply message will exist for every IPv4 address Leasequery reply message will exist for every binding which had one
which had one or more changes of state during the period specified by or more changes of state during the period specified by the query-
the query-start-time and the current time. The last message for each start-time and the current time. The last message for each binding
IPv4 address will contain the state at the current time, and there will contain the state at the current time, and there can be one or
can be one or more messages concerning a single IPv4 address during more messages concerning a single binding during the catch-up phase
the catch-up phase of processing. of processing.
Bindings can change multiple times while the requestor is not Bindings can change multiple times while the requestor is not
connected. The requestor will only receive information about the connected. The requestor will only receive information about the
current state of the binding, not information about each state change current state of the binding, not information about each state change
that occurred during the period from the query-start-time to the that occurred during the period from the query-start-time to the
present. present.
If the DHCPLEASEQUERYSTATUS message containing a dhcp-status-code of If the DHCPLEASEQUERYSTATUS message containing a dhcp-status-code of
DataMissing is received and the requestor is interested in keeping DataMissing is received and the requestor is interested in keeping
its database up to date with respect to the current state of IPv4 its database up to date with respect to the current state of the
address bindings in the DHCPv4 server, then the requestor SHOULD bindings in the DHCPv4 server, then the requestor SHOULD issue a
issue a DHCPBULKLEASEQUERY request to recover the information missing DHCPBULKLEASEQUERY request to recover the information missing from
from its database. This DHCPBULKLEASEQUERY should include a query- its database. This DHCPBULKLEASEQUERY should include a query-start-
start-time option, set to the same value as the query-start-time time option, set to the same value as the query-start-time option
option previously included in the DHCPACTIVELEASEQUERY responses from previously included in the DHCPACTIVELEASEQUERY responses from the
the DHCPv4 server, and a query-end-time option equal to the base-time DHCPv4 server, and a query-end-time option equal to the base-time
option returned by the DHCPv4 server in the DHCPLEASEQUERYSTATUS option returned by the DHCPv4 server in the DHCPLEASEQUERYSTATUS
message with the dhcp-status-code of DataMissing. message with the dhcp-status-code of DataMissing.
Typically, the requestor would have one connection open to a DHCPv4 Typically, the requestor would have one connection open to a DHCPv4
server for a DHCPACTIVELEASEQUERY request and possibly one additional server for a DHCPACTIVELEASEQUERY request and possibly one additional
connection open for a DHCPBULKLEASEQUERY request to the same DHCPv4 connection open for a DHCPBULKLEASEQUERY request to the same DHCPv4
server to fill in the data that might have been missed prior to the server to fill in the data that might have been missed prior to the
initiation of the DHCPACTIVELEASEQUERY. The Bulk Leasequery initiation of the DHCPACTIVELEASEQUERY. The Bulk Leasequery
connection would typically run to completion and be closed, leaving connection would typically run to completion and be closed, leaving
one Active Leasequery connection open to a single DHCPv4 server. one Active Leasequery connection open to a single DHCPv4 server.
skipping to change at page 19, line 26 skipping to change at page 19, line 23
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 digitial 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
server for the purposes of supporting Active Leasequery MUST be
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 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 SHOULD close
the TCP connection. the TCP connection.
If the TCP connection becomes blocked while the server is accepting a If the TCP connection becomes blocked while the server is accepting a
skipping to change at page 20, line 22 skipping to change at page 20, line 22
is signaled. is signaled.
Every reply to a DHCPACTIVELEASEQUERY request MUST contain the Every reply to a DHCPACTIVELEASEQUERY request MUST contain the
information specified in replies to a DHCPBULKLEASEQUERY request information specified in replies to a DHCPBULKLEASEQUERY request
[RFC6926], with the exception that a server implementing Active [RFC6926], with the exception that a server implementing Active
Leasequery SHOULD be able to be configured to prevent specific data Leasequery SHOULD be able to be configured to prevent specific data
items from being sent to the requestor even if these data items were items from being sent to the requestor even if these data items were
requested in the dhcp-parameter-request-list option.. requested in the dhcp-parameter-request-list option..
Some servers can be configured to respond to a DHCPv4 Leasequery Some servers can be configured to respond to a DHCPv4 Leasequery
[RFC4388] or a DHCPBULKLEASEQUERY [RFC6926] for an IPv4 address which [RFC4388] or a DHCPBULKLEASEQUERY [RFC6926] for an IPv4 binding which
is reserved in such a way that it appears that the IPv4 address is is reserved in such a way that it appears that the IPv4 binding is
leased to the DHCP client for which it is reserved. These servers leased to the DHCP client for which it is reserved. These servers
SHOULD also respond to a DHCPACTIVELEASEQUERY request with the same SHOULD also respond to a DHCPACTIVELEASEQUERY request with the same
information as they would to a DHCPBULKLEASEQUERY request when they information as they would to a DHCPBULKLEASEQUERY request when they
first determine that the IPv4 address is reserved to a DHCP client. first determine that the IPv4 binding is reserved to a DHCP client.
If a DHCPACTIVELEASEQUERY request contains a query-start-time option, If a DHCPACTIVELEASEQUERY request contains a query-start-time option,
it indicates that the requestor would like the DHCPv4 server to send it indicates that the requestor would like the DHCPv4 server to send
it not only messages that correspond to DHCPv4 address binding it not only messages that correspond to DHCPv4 binding activity that
activity that occurs subsequent to the receipt of the DHCPLEASEACTIVE occurs subsequent to the receipt of the DHCPLEASEACTIVE request, but
request, but also messages that correspond to DHCPv4 address binding also messages that correspond to DHCPv4 binding activity that
activity that occurred prior to the DHCPACTIVELEASEQUERY request. occurred prior to the DHCPACTIVELEASEQUERY request.
If a query-end-time option appears in a DHCPACTIVELEASEQUERY the If a query-end-time option appears in a DHCPACTIVELEASEQUERY the
DHCPv4 server should send a DHCPLEASEQUERYSTATUS message with a dhcp- DHCPv4 server should send a DHCPLEASEQUERYSTATUS message with a dhcp-
status-code of MalformedQuery and terminate the connection. status-code of MalformedQuery and terminate the connection.
In order to implement a meaningful response to this query, the DHCPv4 In order to implement a meaningful response to this query, the DHCPv4
server MAY keep track of the address binding activity and associate server MAY keep track of the binding activity and associate changes
changes with particular base-time values from the messages. Then, with particular base-time values from the messages. Then, when
when requested to do so by a DHCPACTIVELEASEQUERY request containing requested to do so by a DHCPACTIVELEASEQUERY request containing a
a query-start-time option, the DHCPv4 server can respond with replies query-start-time option, the DHCPv4 server can respond with replies
for all address binding activity occurring on that query-start-time for all binding activity occurring on that query-start-time or later
or later 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 IPv4 address 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, but is not required to, keep track of a
limited amount of previous address binding activity and associate it limited amount of previous binding activity and associate it with
with base-time values. The DHCPv4 server MAY choose to only do this base-time values. The DHCPv4 server MAY choose to only do this in
in the event that it has received at least one DHCPACTIVELEASEQUERY the event that it has received at least one DHCPACTIVELEASEQUERY
request in the past, as to do so will almost certainly entail some request in the past, as to do so will almost certainly entail some
utilization of resources which would be wasted if there are no utilization of resources which would be wasted if there are no
DHCPACTIVELEASEQUERY requestors for this DHCPv4 server. The DHCPv4 DHCPACTIVELEASEQUERY requestors for this DHCPv4 server. The DHCPv4
server SHOULD make the amount of previous address binding activity it server SHOULD make the amount of previous binding activity it retains
retains configurable. There is no requirement on the DHCPv4 server configurable. There is no requirement on the DHCPv4 server to retain
to retain this information over a server restart (or even to retain this information over a server restart (or even to retain such
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
reasons for sending information differs considerably between these reasons for sending information differs considerably between these
two capabilities. In the DHCPBULKLEASEQUERY context, the entire two capabilities. In the DHCPBULKLEASEQUERY context, the entire
contents of the lease state database (subject to the constraints of contents of the lease state database (subject to the constraints of
the various query options) are returned to the requestor. In the the various query options) are returned to the requestor. In the
DHCPACTIVELEASEQUERY context, changes to the lease state database are DHCPACTIVELEASEQUERY context, changes to the lease state database are
returned to the requestor essentially as they happen. For instance, returned to the requestor essentially as they happen. For instance,
when an IPv4 address transitions from the leased state to some other when an IPv4 binding transitions from the leased state to some other
state, the DHCPACTIVELEASEQUERY will send a DHCPLEASEUNASSIGNED state, the DHCPACTIVELEASEQUERY will send a DHCPLEASEUNASSIGNED
packet with information regarding that IPv4 address. The server may packet with information regarding that binding. The server may then
then entirely forget about that IPv4 address (or not), but it is entirely forget about that IPv4 binding (or not), but it is important
important to tell the DHCPACTIVELEASEQUERY requestor that an IPv4 to tell the DHCPACTIVELEASEQUERY requestor that an binding has
address has transitioned away from the leased state. transitioned away from the leased state.
The relationship between the time that the server replies to a DHCP The relationship between the time that the server replies to a DHCP
client request and the time that the DHCP server sends a reply to a client request and the time that the DHCP server sends a reply to a
DHCPACTIVELEASEQUERY message is a matter of implementation (and thus DHCPACTIVELEASEQUERY message is a matter of implementation (and thus
not something defined by this document). However, the server SHOULD not something defined by this document). However, the server SHOULD
NOT delay responding to the DHCP client in order to transmit a reply NOT delay responding to the DHCP client in order to transmit a reply
to a DHCPACTIVELEASEQUERY message, and the server SHOULD send the to a DHCPACTIVELEASEQUERY message, and the server SHOULD send the
reply to the DHCPACTIVELASEQUERY message as soon as possible after reply to the DHCPACTIVELASEQUERY message as soon as possible after
responding to the client. responding to the client.
skipping to change at page 24, line 20 skipping to change at page 24, line 20
| CatchUpComplete | TBD6 | | CatchUpComplete | TBD6 |
| TLSConnectionRefused | TBD7 | | TLSConnectionRefused | TBD7 |
+----------------------+-------------+ +----------------------+-------------+
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. Leasequery were also included in this draft. Brian Haberman's review
brought this document into much closer alignment with DHCPv6 Active
Leasequery.
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. 47 change blocks. 
125 lines changed or deleted 123 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/