draft-ietf-dhc-dhcpv6-active-leasequery-01.txt   draft-ietf-dhc-dhcpv6-active-leasequery-02.txt 
DHC Working Group D. Raghuvanshi DHC Working Group D. Raghuvanshi
Internet-Draft K. Kinnear Internet-Draft K. Kinnear
Intended status: Standards Track D. Kukrety Updates: 5460 (if approved) D. Kukrety
Expires: September 29, 2014 Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
March 28, 2014 Expires: September 3, 2015 March 2, 2015
DHCPv6 Active Leasequery DHCPv6 Active Leasequery
draft-ietf-dhc-dhcpv6-active-leasequery-01 draft-ietf-dhc-dhcpv6-active-leasequery-02
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 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 DHCPv6 bindings. That mechanism is limited request information about DHCPv6 bindings. That mechanism is limited
to queries for DHCPv6 binding data updates prior to the time the to queries for DHCPv6 binding data updates prior to the time the
DHCPv6 server receives the Leasequery request. Continuous update of DHCPv6 server receives the Leasequery request. Continuous update of
an external requestor with Leasequery data is sometimes desired. an external requestor with Leasequery data is sometimes desired.
This document expands on the DHCPv6 Leasequery protocol, and allows This document expands on the DHCPv6 Leasequery protocol, and allows
for active transfer of real-time DHCPv6 binding information data via for active transfer of real-time DHCPv6 binding information data via
TCP. This document also extends DHCPv6 Bulk Leasequery by adding new TCP. This document also updates DHCPv6 Bulk Leasequery (RFC5460) by
options. adding new options.
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 September 29, 2014. This Internet-Draft will expire on September 3, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Interaction Between Active Leasequery and Bulk Leasequery . . 6 4. Interaction Between Active Leasequery and Bulk Leasequery . . 7
5. Extension to DHCPv6 Bulk Leasequery . . . . . . . . . . . . . 7 5. Extension to DHCPv6 Bulk Leasequery . . . . . . . . . . . . . 7
6. Message and Option Definitions . . . . . . . . . . . . . . . 7 6. Message and Option Definitions . . . . . . . . . . . . . . . 8
6.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 7 6.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 8
6.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2.1. ACTIVELEASEQUERY . . . . . . . . . . . . . . . . . . 8 6.2.1. ACTIVELEASEQUERY . . . . . . . . . . . . . . . . . . 8
6.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2.2. STARTTLS . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3.1. OPTION_LQ_BASE_TIME . . . . . . . . . . . . . . . . . 9 6.3.1. OPTION_LQ_BASE_TIME . . . . . . . . . . . . . . . . . 9
6.3.2. OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 9 6.3.2. OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 10
6.3.3. OPTION_LQ_END_TIME . . . . . . . . . . . . . . . . . 10 6.3.3. OPTION_LQ_END_TIME . . . . . . . . . . . . . . . . . 11
6.4. Connection and Transmission Parameters . . . . . . . . . 11 6.4. Connection and Transmission Parameters . . . . . . . . . 11
7. Information Communicated by Active Leasequery . . . . . . . . 11 7. Information Communicated by Active Leasequery . . . . . . . . 12
8. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 12 8. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 13
8.1. Connecting and General Processing . . . . . . . . . . . . 12 8.1. General Processing . . . . . . . . . . . . . . . . . . . 13
8.2. Forming an Active Leasequery . . . . . . . . . . . . . . 13 8.2. Initiating a Connection . . . . . . . . . . . . . . . . . 13
8.3. Processing Active Replies . . . . . . . . . . . . . . . . 14 8.3. Forming an Active Leasequery . . . . . . . . . . . . . . 14
8.3.1. Processing Replies from a Request Containing a 8.4. Processing Active Replies . . . . . . . . . . . . . . . . 15
OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 15 8.4.1. Processing Replies from a Request Containing a
8.4. Processing Time Values in Leasequery messages . . . . . . 18 OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 17
8.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 18 8.5. Processing Time Values in Leasequery messages . . . . . . 19
8.5.1. Query Failure . . . . . . . . . . . . . . . . . . . . 19 8.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 20
8.5.2. Data Missing on Server . . . . . . . . . . . . . . . 19 8.6.1. Query Failure . . . . . . . . . . . . . . . . . . . . 20
8.5.3. Successful Query . . . . . . . . . . . . . . . . . . 19 8.6.2. Data Missing on Server . . . . . . . . . . . . . . . 20
8.6. Closing Connections . . . . . . . . . . . . . . . . . . . 20 8.6.3. Successful Query . . . . . . . . . . . . . . . . . . 20
9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 20 8.7. Closing Connections . . . . . . . . . . . . . . . . . . . 21
9.1. Accepting Connections . . . . . . . . . . . . . . . . . . 20 9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Replying to an Active Leasequery . . . . . . . . . . . . 20 9.1. Accepting Connections . . . . . . . . . . . . . . . . . . 21
9.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 22 9.2. Rejecting Connections . . . . . . . . . . . . . . . . . . 22
9.4. Closing Connections . . . . . . . . . . . . . . . . . . . 23 9.3. Replying to an Active Leasequery . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9.4. Multiple or Parallel Queries . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9.5. Closing Connections . . . . . . . . . . . . . . . . . . . 25
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
13. Modification History . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
14.1. Normative References . . . . . . . . . . . . . . . . . . 25 13. Modification History . . . . . . . . . . . . . . . . . . . . 27
14.2. Informative References . . . . . . . . . . . . . . . . . 25 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1. Normative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 14.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
The DHCPv6 [RFC3315] protocol specifies a mechanism for the The DHCPv6 [RFC3315] protocol specifies a mechanism for the
assignment of IPv6 address and configuration information to IPv6 assignment of IPv6 address and configuration information to IPv6
nodes. IPv6 Prefix Delegation for DHCPv6 (PD) [RFC3633] specifies a nodes. IPv6 Prefix Delegation for DHCPv6 (PD) [RFC3633] specifies a
mechanism for DHCPv6 delegation of IPv6 prefixes and related data. mechanism for DHCPv6 delegation of IPv6 prefixes and related data.
DHCPv6 servers maintain authoritative information including binding DHCPv6 servers maintain authoritative information including binding
information for delegated IPv6 prefixes. information for delegated IPv6 prefixes.
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 DHCPv6 clients and their bindings. These correspondence between DHCPv6 clients and their bindings. These
requirements often stem from regulatory requirements placed on entities need to keep up with the current binding activity of the
service providers by governmental agencies. DHCPv6 server. Keeping up with these binding activity is termed
These entities need to keep up with the current binding activity of
the DHCPv6 server. Keeping up with these binding activity is termed
"active" leasequery. "active" leasequery.
The DHCPv6 Bulk Leasequery [RFC5460] capability can be used to The DHCPv6 Bulk Leasequery [RFC5460] capability can be used to
recover useful information from a DHCPv6 server when some external recover useful information from a DHCPv6 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 DHCPv6 client - server transactions (e.g., a relay involved in the DHCPv6 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 DHCPv6 server's lease state database. present in the DHCPv6 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 DHCPv6 client - server an entity not directly involved in DHCPv6 client - server
transactions to nevertheless keep current with the state of the transactions to nevertheless keep current with the state of the
DHCPv6 lease state information in real-time. DHCPv6 lease state information in real-time.
This document updates DHCPv6 Bulk Leasequery [RFC5460] by adding new
options, as described in Section 6.2.1. For the DHCPv6 servers,
supporting Bulk Leasequery and not Active Leasequery, Section 9.2
specifies the mechanism to reject incoming Active Leasequery
requests.
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
DHCPv6 terminology is defined in [RFC3315]. Terminology specific to DHCPv6 terminology is defined in [RFC3315]. Terminology specific to
DHCPv6 Active Leasequery can be found below: DHCPv6 Active Leasequery can be found below:
o "Absolute Time" o "Absolute Time"
skipping to change at page 4, line 12 skipping to change at page 4, line 14
A 32-bit quantity containing the number of seconds since midnight A 32-bit quantity containing the number of seconds since midnight
January 1, 2000 UTC. January 1, 2000 UTC.
o "Active Leasequery" o "Active Leasequery"
Keeping up to date in real-time (or near real-time) with DHCPv6 Keeping up to date in real-time (or near real-time) with DHCPv6
binding activity. binding activity.
o "Bulk Leasequery" o "Bulk Leasequery"
Requesting and receiving the existing DHCPv6 binding information Requesting and receiving the information about all or some of the
in an efficient manner. existing DHCPv6 binding information in an efficient manner, as
defined by [RFC5460].
o "blocked TCP connection"
A TCP connection is considered blocked if the underlying TCP
transport will not accept new messages to be sent without blocking
the thread that is attempting to send the message.
o "binding change/update" o "binding change/update"
Any change in the DHCPv6 binding state or data stored on the Any change in the DHCPv6 binding state or data stored on the
DHCPv6 server related to binding. This also includes expiration DHCPv6 server related to binding. This also includes expiration
or deletion of the binding. or deletion of the binding.
o "catch-up information, catch-up phase" o "catch-up information, catch-up phase"
If a DHCPv6 Active Leasequery requestor sends OPTION_LQ_START_TIME If a DHCPv6 Active Leasequery requestor sends OPTION_LQ_START_TIME
skipping to change at page 4, line 38 skipping to change at page 5, line 12
information, and the period while it is being sent is the catch-up information, and the period while it is being sent is the catch-up
phase. phase.
o "clock skew" o "clock skew"
The difference between the absolute time on a DHCPv6 server and The difference between the absolute time on a DHCPv6 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 message is
received by a requestor from a DHCPv6 server, a more accurate received by a requestor from a DHCPv6 server, a more accurate
value is derived from continuously examining the instantaneous value is derived from continuously examining the instantaneous
value developed from each packet received from a DHCPv6 server and value developed from each message received from a DHCPv6 server
using it to make small adjustments to the existing value held in and using it to make small adjustments to the existing value held
the requestor. in the requestor.
o "requestor"
The node that sends LEASEQUERY messages to one or more servers to
retrieve information on the bindings for a client.
o "Transaction ID" o "Transaction ID"
An opaque value used to match responses with queries initiated by An opaque value used to match responses with queries initiated by
an Active Leasequery requestor. an Active Leasequery requestor.
3. Protocol Overview 3. Protocol Overview
The Active Leasequery mechanism is modeled on the existing DHCPv6 The Active Leasequery mechanism is modeled on the existing DHCPv6
Bulk Leasequery [RFC5460]; most differences arise from the long term Bulk Leasequery [RFC5460]; most differences arise from the long term
nature of the TCP [RFC4614] connection required for Active nature of the TCP [RFC4614] connection required for Active
Leasequery. In addition, a DHCPv6 server which supports Active Leasequery. A DHCPv6 server which supports Active Leasequery MUST
Leasequery MUST support Bulk Leasequery [RFC5460] as well. support Bulk Leasequery [RFC5460] as well.
An Active Leasequery requestor opens a TCP connection to a DHCPv6 An Active Leasequery requestor opens a TCP connection to a DHCPv6
Server, using the DHCPv6 port 547. Note that this implies that the Server, using the DHCPv6 port 547. Note that this implies that the
Leasequery requestor has server IP address(es) available via Leasequery requestor has server IP 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 DHCPv6 server. No relaying for Active Leasequery reachability to the DHCPv6 server. No relaying for Active Leasequery
is specified. is specified.
After establishing a connection, the requestor sends an After establishing a connection, the requestor sends an
ACTIVELEASEQUERY message over the connection. In response, the ACTIVELEASEQUERY message over the connection. In response, the
skipping to change at page 5, line 38 skipping to change at page 6, line 12
LEASEQUERY-DATA messages. This response procedure is identical to LEASEQUERY-DATA messages. This response procedure is identical to
[RFC5460], except that in the case of Active Leasequery the server [RFC5460], except that in the case of Active Leasequery the server
sends updates whenever some activity occurs to change the binding sends updates whenever some activity occurs to change the binding
state - thus the need for long lived connection. state - thus the need for long lived connection.
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 IPv6 bindings changed while it was not information concerning any IPv6 bindings changed while it was not
connected. connected.
These capabilities are designed to allow the Active Leasequery These features are designed to allow the Active Leasequery requestor
requestor to efficiently become current with respect to the lease to efficiently become current with respect to the lease state
state database after it has been restarted or the machine on which it database after it has been restarted or the machine on which it is
is running has been reinitialized. It is easy to define a protocol running has been reinitialized. It is easy to define a protocol
which works when the requestor is always connected to the DHCPv6 which works when the requestor is always connected to the DHCPv6
server. Since that isn't sufficiently robust, much of the mechanism server. Since that isn't sufficiently robust, much of the mechanism
in this document is designed to deal efficiently with situations that in this document is designed to deal efficiently with situations that
occur when the Active Leasequery requestor becomes disconnected from occur when the Active Leasequery requestor becomes disconnected from
the DHCPv6 server from which it is receiving updates and then becomes the DHCPv6 server from which it is receiving updates and then
reconnected to that server. reconnects to that server.
Central to this approach, if the Active Leasequery requestor loses Central to this approach, if the Active Leasequery requestor loses
service, it is allowed to specify the time of its most recent update service, it is allowed to specify the time of its most recent update
in a subsequent Active Leasequery request and the DHCPv6 server will in a subsequent Active Leasequery request and the DHCPv6 server will
determine whether or not data was missed while the Active Leasequery determine whether or not data was missed while the Active Leasequery
requestor was not connected. requestor was not connected.
The DHCPv6 server processing the Active Leasequery request may limit The DHCPv6 server processing the Active Leasequery request may limit
the amount of data saved, and methods exist for the DHCPv6 server to the amount of data saved, and methods exist for the DHCPv6 server to
inform the Active Leasequery requestor that more data was missed than inform the Active Leasequery requestor that data was missed - not all
could be saved. In this situation, the Active Leasequery requestor could be saved. In this situation, the Active Leasequery requestor
would issue a Bulk Leasequery [RFC5460] to recover information not should issue a Bulk Leasequery [RFC5460] to recover information not
available through an Active Leasequery. available through an Active Leasequery.
DHCPv6 servers are not required to keep any data corresponding to DHCPv6 servers are not required to keep any data corresponding to
data missed on an Active Leasequery connection, but will typically data missed on an Active Leasequery connection, but will typically
choose to keep data corresponding to some recent activity available choose to keep data corresponding to some recent activity available
for subsequent queries by a DHCPv6 Active Leasequery requestor whose for subsequent queries by a DHCPv6 Active Leasequery requestor whose
connection was temporarily interrupted. In other words, DHCPv6 connection was temporarily interrupted. In other words, DHCPv6
servers supporting catch-up are required to have some mechanism to servers supporting catch-up are required to have some mechanism to
keep/save historic information of bindings. keep/save historic information of bindings.
skipping to change at page 6, line 43 skipping to change at page 7, line 18
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 OPTION_CLIENT_DATA and additional options Thus, the handling of OPTION_CLIENT_DATA and additional options
discussed in the Bulk Leasequery specification [RFC5460] are to be discussed in the Bulk Leasequery specification [RFC5460] 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 can be seen as an extension of the Bulk Leasequery Active Leasequery is an extension of the Bulk Leasequery protocol
protocol [RFC5460]. The format of packets returned to an Active [RFC5460]. The format of messages returned to an Active Leasequery
Leasequery requestor are identical to that defined for the Bulk requestor are identical to that defined for the Bulk Leasequery
Leasequery protocol [RFC5460]. protocol [RFC5460].
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 DHCPv6 server's lease state database will date with respect to the DHCPv6 server's lease state database will
usually use an initial Bulk Leasequery to bring their database into usually use an initial Bulk Leasequery to bring their database into
equivalence with that of the DHCPv6 server, and then use Active equivalence with that of the DHCPv6 server, and then use Active
Leasequery to keep that database current with respect to the DHCPv6 Leasequery to keep that database current with respect to the DHCPv6
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 a new message protocols. Active Leasequery defines a new message
skipping to change at page 7, line 34 skipping to change at page 8, line 10
ask for the same in Bulk Leasequery request. OPTION_LQ_START_TIME ask for the same in Bulk Leasequery request. OPTION_LQ_START_TIME
and OPTION_LQ_END_TIME can be used in Bulk Leasequery request made to and OPTION_LQ_END_TIME can be used in Bulk Leasequery request made to
DHCPv6 server. More details about these options are specified in DHCPv6 server. More details about these options are specified in
Section 6.3. Section 6.3.
6. Message and Option Definitions 6. Message and Option Definitions
6.1. Message Framing for TCP 6.1. Message Framing for TCP
The use of TCP for the Active Leasequery protocol permits one or more The use of TCP for the Active Leasequery protocol permits one or more
DHCPv6 messages to be sent at a time. The receiver needs to be able DHCPv6 messages to be sent in response to single Active Leasequery
to determine how large each message is. The same message framing request. The receiver needs to be able to determine how large each
technique used for DHCPv6 Bulk Leasequery [RFC5460] is used for message is. The same message framing technique used for DHCPv6 Bulk
Active Leasequery as well. Leasequery [RFC5460] is used for Active Leasequery as well.
The intent in using the same format is that code which currently The intent in using the same format is that code which currently
knows how to deal with a message returned from DHCPv6 Bulk Leasequery knows how to deal with a message returned from DHCPv6 Bulk Leasequery
[RFC5460] will be able to deal with the message held inside of the [RFC5460] will be able to deal with the message held inside of the
TCP framing. TCP framing.
6.2. Messages 6.2. Messages
The LEASEQUERY-REPLY message is defined in [RFC5007]. The The LEASEQUERY-REPLY message is defined in [RFC5007]. The
LEASEQUERY-DATA and LEASEQUERY-DONE messages are defined in LEASEQUERY-DATA and LEASEQUERY-DONE messages are defined in
[RFC5460]. [RFC5460].
In an Active Leasequery exchange, a single LEASEQUERY-REPLY message In an Active Leasequery exchange, a single LEASEQUERY-REPLY message
is used to indicate the success or failure of a query, and to carry is used to indicate the success or failure of a query, and to carry
data that do not change in the context of a single query and answer, data that do not change in the context of a single query and answer,
such as the Server-ID and Client-ID options. If a query is such as the Server-ID and Client-ID options. If a query is
successful, only a single LEASEQUERY-REPLY message MUST appear. If successful, the DHCPv6 server MUST respond to it with exactly one
the server is returning binding data, the LEASEQUERY-REPLY also LEASEQUERY-REPLY message. If the server is returning binding data,
contains the first client's binding data in an OPTION_CLIENT_DATA the LEASEQUERY-REPLY also contains the first client's binding data in
option. Additional binding data is returned using LEASEQUERY-DATA an OPTION_CLIENT_DATA option. Additional binding data is returned
message as explained in DHCPv6 Bulk Leasequery [RFC5460]. In case of using LEASEQUERY-DATA message as explained in DHCPv6 Bulk Leasequery
failure query, single LEASEQUERY-REPLY message is returned without [RFC5460]. In case of failure query, single LEASEQUERY-REPLY message
any binding data. is returned without any binding data.
6.2.1. ACTIVELEASEQUERY 6.2.1. ACTIVELEASEQUERY
The new message type (ACTIVELEASEQUERY) is designed for keeping the The new message type (ACTIVELEASEQUERY) is designed for keeping the
requestor up to date in real-time (or near real-time) with DHCPv6 requestor up to date in real-time (or near real-time) with DHCPv6
bindings. It asks the server to return DHCPv6 bindings activity that bindings. It asks the server to return DHCPv6 bindings activity that
occurs subsequent to the receipt of the Active Leasequery request. occurs subsequent to the receipt of the Active Leasequery request.
An ACTIVELEASEQUERY request MUST contain a transaction-id, and that An ACTIVELEASEQUERY request MUST contain a transaction-id, and that
transaction-id MUST BE locally unique to the TCP connection to the transaction-id MUST BE locally unique on the TCP connection on which
DHCPv6 server. it is sent to the DHCPv6 server.
When sending an Active Leasequery request, the requestor MAY include When sending an Active Leasequery request, the requestor MAY include
the OPTION_LQ_START_TIME option in the ACTIVELEASEQUERY request. In the OPTION_LQ_START_TIME option in the ACTIVELEASEQUERY request. In
this case, DHCPv6 server returns all the bindings changed on or after this case, DHCPv6 server returns all the bindings changed on or after
the OPTION_LQ_START_TIME. the OPTION_LQ_START_TIME.
If the requestor is interested in receiving all binding updates from If the requestor is interested in receiving all binding updates from
the DHCPv6 server, it MUST NOT include the OPTION_LQ_QUERY option in the DHCPv6 server, it MUST NOT include the OPTION_LQ_QUERY option in
the ACTIVELEASEQUERY message. But if the requestor is only the ACTIVELEASEQUERY message. But if the requestor is only
interested in specific binding updates, it MAY include an interested in specific binding updates, it MAY include an
OPTION_LQ_QUERY option along with a query-types defined in [RFC5007] OPTION_LQ_QUERY option along with a query-types defined in [RFC5007]
and [RFC5460]. and [RFC5460].
Other DHCPv6 options used in the LEASEQUERY message (as specified in Other DHCPv6 options used in the LEASEQUERY message (as specified in
[RFC5460]) can also be used in the ACTIVELEASEQUERY request. [RFC5460]) can also be used in the ACTIVELEASEQUERY request.
6.2.2. STARTTLS
The new message type (STARTTLS) is designed for establishment of a
TLS connection between requestor and DHCPv6 server.
More details about this message are specified in Section 8.2.
6.3. Options 6.3. Options
New options (OPTION_LQ_BASE_TIME, OPTION_LQ_START_TIME and New options (OPTION_LQ_BASE_TIME, OPTION_LQ_START_TIME and
OPTION_LQ_END_TIME) are defined as an extension to DHCPv6 Bulk OPTION_LQ_END_TIME) are defined as an extension to DHCPv6 Bulk
Leasequery [RFC5460]. The reply messages for Active Leasequery uses Leasequery [RFC5460]. The reply messages for Active Leasequery uses
these options along with the options defined in [RFC3315], [RFC5007] these options along with the options defined in [RFC3315], [RFC5007]
and [RFC5460]. and [RFC5460].
6.3.1. OPTION_LQ_BASE_TIME 6.3.1. OPTION_LQ_BASE_TIME
skipping to change at page 9, line 42 skipping to change at page 10, line 27
6.3.2. OPTION_LQ_START_TIME 6.3.2. OPTION_LQ_START_TIME
The OPTION_LQ_START_TIME option specifies a query start time to the The OPTION_LQ_START_TIME option specifies a query start time to the
DHCPv6 server. If specified, only bindings that have changed on or DHCPv6 server. If specified, only bindings that have changed on or
after the OPTION_LQ_START_TIME should be included in the response to after the OPTION_LQ_START_TIME should be included in the response to
the query. This option MAY be used in Active or Bulk Leasequery the query. This option MAY be used in Active or Bulk Leasequery
requests made to a DHCPv6 server. requests made to a DHCPv6 server.
The requestor MUST determine the OPTION_LQ_START_TIME using lease The requestor MUST determine the OPTION_LQ_START_TIME using lease
information it has received from the DHCPv6 server. This MUST be an information it has received from the DHCPv6 server. This MUST be an
absolute time in the DHCPv6 server's context (see Section 8.4). absolute time in the DHCPv6 server's context (see Section 8.5).
Typically (though this is not a requirement) the OPTION_LQ_START_TIME Typically (though this is not a requirement) the OPTION_LQ_START_TIME
option will contain the value most recently received in a option will contain the value most recently received in a
OPTION_LQ_BASE_TIME option by the requestor, as this will indicate OPTION_LQ_BASE_TIME option by the requestor, as this will indicate
the last successful communication with the DHCPv6 server. the last successful communication with the DHCPv6 server.
This is an unsigned integer in network byte order. This is an unsigned integer in network byte order.
The code for this option is TBD. The code for this option is TBD.
skipping to change at page 10, line 33 skipping to change at page 11, line 19
before the OPTION_LQ_END_TIME should be included in the response to before the OPTION_LQ_END_TIME should be included in the response to
the query. This option MAY be used in a Bulk Leasequery request. the query. This option MAY be used in a Bulk Leasequery request.
But it MUST NOT be used in an Active Leasequery request. But it MUST NOT be used in an Active Leasequery request.
The requestor MUST determine the OPTION_LQ_END_TIME based on lease The requestor MUST determine the OPTION_LQ_END_TIME based on lease
information it has received from the DHCPv6 server. This MUST be an information it has received from the DHCPv6 server. This MUST be an
absolute time in the context of the DHCPv6 server. absolute time in the context of the DHCPv6 server.
In the absence of information to the contrary, the requestor SHOULD In the absence of information to the contrary, the requestor SHOULD
assume that the time context of the DHCPv6 server is identical to the assume that the time context of the DHCPv6 server is identical to the
time context of the requestor (see Section 8.4). time context of the requestor (see Section 8.5).
This is an unsigned integer in network byte order. This is an unsigned integer in network byte order.
The code for this option is TBD. The code for this option is TBD.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LQ_END_TIME | option-len | | OPTION_LQ_END_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 13 skipping to change at page 12, line 36
runs slowly or the requestor disconnects from the DHCPv6 server and runs slowly or the requestor disconnects from the DHCPv6 server and
then reconnects with an OPTION_LQ_START_TIME option (signaling a then reconnects with an OPTION_LQ_START_TIME option (signaling a
catch-up operation), the information communicated to the Active catch-up operation), the information communicated to the Active
Leasequery requestor is only the most current information from the Leasequery requestor is only the most current information from the
DHCPv6 server's lease state database. DHCPv6 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 DHCPv6 server is only required to transmit information connected, the DHCPv6 server is only required to transmit information
about a binding that is current when the packet is created and handed about a binding that is current when the message is created and
off to the TCP stack to send to the requestor. handed off to the TCP stack to send to the requestor.
If the TCP connection blocks and the DHCPv6 server is waiting to send If the TCP connection blocks and the DHCPv6 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 DHCPv6 server MAY create the packet to available to be written the DHCPv6 server MAY create the message to
send at this time. The current state of the binding will be sent, send at this time. The current state of the binding will be sent,
and any transition in state or other information that occurred while and any transition in state or other information that occurred while
the TCP connection was blocked will be lost. the TCP connection was blocked will be lost.
Thus, the Active Leasequery protocol does not allow the requestor to Thus, the Active Leasequery protocol does not allow the requestor to
build a complete history of every activity on every lease. An build a complete history of every activity on every lease. An
effective history of the important state changes for a lease can be effective history of the important state changes for a lease can be
created if the parameters of the DHCPv6 server are tuned to take into created if the parameters of the DHCPv6 server are tuned to take into
account the requirements of an Active Leasequery requestor. For account the requirements of an Active Leasequery requestor. For
instance, the period after the expiration or release of a binding instance, the period after the expiration or release of a binding
could be configured long enough (say several minutes, well more than could be configured long enough (say several minutes, well more than
the receive timeout), so that an Active Leasequery requestor would be the receive timeout), so that an Active Leasequery requestor would be
less likely to miss any changes in the binding. less likely to miss any changes in the binding.
8. Requestor Behavior 8. Requestor Behavior
8.1. Connecting and General Processing 8.1. General Processing
A Requestor attempts to establish a TCP connection to a DHCPv6 Server A requestor attempts to establish a TCP connection to a DHCPv6 Server
in order to initiate an Active Leasequery exchange. If the attempt in order to initiate an Active Leasequery exchange. If the attempt
fails, the Requestor MAY retry. fails, the Requestor MAY retry.
If an Active Leasequery is terminated prematurely by a LEASEQUERY- If an Active Leasequery is terminated prematurely by a LEASEQUERY-
DONE with a DHCPv6 status code (carried in an OPTION_STATUS_CODE DONE with a DHCPv6 status code (carried in an OPTION_STATUS_CODE
option) of QueryTerminated or by the failure of the connection over option) of QueryTerminated or by the failure of the connection over
which it was being submitted, the requestor MAY retry the request which it was being submitted, the requestor MAY retry the request
after the creation of a new connection. after the creation of a new connection.
Messages from the DHCPv6 server come as multiple responses to a Messages from the DHCPv6 server come as multiple responses to a
single ACTIVELEASEQUERY message. Thus, each ACTIVELEASEQUERY request single ACTIVELEASEQUERY message. Thus, each ACTIVELEASEQUERY request
MUST have an xid (transaction-id) unique on the connection on which MUST have an xid (transaction-id) unique on the connection on which
it is sent, and all of the messages which come as a response to it it is sent, and all of the messages which come as a response to it
contain the same xid as the request. It is the xid which allows the contain the same xid as the request. It is the xid which allows the
data-streams of two or more different ACTIVELEASEQUERY requests to be data-streams of two or more different ACTIVELEASEQUERY requests to be
de-multiplexed by the requestor. de-multiplexed by the requestor.
A requestor MAY send an ACTIVELEASEQUERY request to a DHCPv6 server 8.2. Initiating a Connection
and immediately close the transmission side of its TCP connection,
and then read the resulting response messages from the DHCPv6 server.
This is not required, and the usual approach is to leave both sides
of the TCP connection up until at least the conclusion of the Active
Leasequery.
8.2. Forming an Active Leasequery A Requestor SHOULD attempt to negotiate a TLS [RFC5246] connection
over the TCP connection. If this negotiation fails, a requestor MAY
choose to proceed with the Active Leasequery request without TLS.
A requestor requests the establishment of a TLS connection by sending
the STARTTLS message to the DHCPv6 server as the first message over
the TCP connection. This message indicates to the DHCPv6 server that
a TLS connection over this TCP connection is desired. There are four
possibilities after the requestor sends the STARTTLS message to the
DHCPv6 server:
1. No response from the DHCPv6 server.
2. The DHCPv6 server drops the TCP connection after it receives the
STARTTLS message.
3. DHCPv6 server responds with REPLY [RFC3315] message with DHCPv6
status code of TLSConnectionRefused.
4. DHCPv6 server responds with REPLY [RFC3315] message without
DHCPv6 status code, indicating success.
In any of the first three possibilities, the DHCPv6 server can be
assumed to not support TLS. In this case, the requestor MAY choose
to proceed with the Active Leasequery request without having it
protected by TLS.
In the final possibility, where the DHCPv6 server has responded with
a REPLY message without DHCPv6 status code in response to the
requestor's STARTTLS message, the requestor SHOULD initiate the
exchange of the messages involved in a TLS handshake [RFC5246].
If the handshake exchange yields a functioning TLS connection, then
the requestor SHOULD transmit an Active Leasequery message over that
TLS connection and use that TLS connection for all further
interactions in which it engages with the DHCPv6 server over this TCP
connection.
If the handshake exchange does not yield a functioning TLS
connection, then the requestor MUST drop the TCP connection. The
requestor MAY create a new TCP connection and MAY choose to proceed
with an Active Leasequery request without using TLS.
8.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 DHCPv6 server processing the active between the requestor and the DHCPv6 server processing the active
query. The DHCPv6 server will send binding information back across query. The DHCPv6 server SHOULD send binding information back across
this connection with minimal delay after it learns of the binding this connection with minimal delay after it learns of the binding
information. It will learn about bindings either because it makes information. It learns about bindings either because it makes the
the bindings itself or because it has received information about a bindings itself or because it has received information about a
binding from another server. binding from another server.
To form the Active Leasequery, a DHCPv6 request is constructed with a
message type of ACTIVELEASEQUERY. The DHCPv6 request MUST contain a
transaction-id, and that transaction-id MUST BE locally unique to the
TCP connection to the DHCPv6 server.
An important capability of the Active Leasequery is the ability of An important capability of the Active Leasequery is the ability of
the requestor to specify that some recent data be sent immediately to the requestor to specify that some recent data be sent immediately to
the requestor in parallel with the transmission of the ongoing the requestor in parallel with the transmission of the ongoing
binding information in more or less real time. This capability is binding information in more or less real time. This capability is
used in order to allow an Active Leasequery requestor to recover used in order to allow an Active Leasequery requestor to recover
missed information in the event that it temporarily loses missed information in the event that it temporarily loses
connectivity with the DHCPv6 server processing a previous Active connectivity with the DHCPv6 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, the requestor MUST NOT keep track of the base-time
(OPTION_LQ_BASE_TIME) received in Leasequery reply messages to use (OPTION_LQ_BASE_TIME) received in Leasequery reply messages to use
later in a subsequent Active Leasequery request. later in a subsequent Active Leasequery request.
This capability is enabled by the transmission of an This capability is enabled by the transmission of an
OPTION_LQ_BASE_TIME option with each Leasequery reply sent as the OPTION_LQ_BASE_TIME option with each Leasequery reply sent as the
result of a previous Active Leasequery. The requestor will typically result of a previous Active Leasequery. The requestor SHOULD keep
keep track of the highest base-time received from a particular DHCPv6 track of the highest base-time received from a particular DHCPv6
server over an Active Leasequery connection, and in the event that server over an Active Leasequery connection, and in the event that
the requestor finds it necessary (for whatever reason) to reestablish the requestor finds it necessary (for whatever reason) to reestablish
an Active Leasequery connection to that DHCPv6 server, the requestor an Active Leasequery connection to that DHCPv6 server, the requestor
will place this highest base-time value into an OPTION_LQ_START_TIME SHOULD place this highest base-time value into an
option in the new Active Leasequery request. OPTION_LQ_START_TIME option in the new Active Leasequery request.
If the requestor doesn't wish to request an update of information If the requestor doesn't wish to request an update of information
missed when it was not connected to the DHCPv6 server, then it does missed when it was not connected to the DHCPv6 server, then it SHOULD
not include the OPTION_LQ_START_TIME option in the Active Leasequery NOT include the OPTION_LQ_START_TIME option in the Active Leasequery
request. request.
If the TCP connection becomes blocked or stops being writable while If the TCP connection becomes blocked or stops being writable while
the requestor is sending its query, the requestor SHOULD be prepared the requestor is sending its query, the requestor SHOULD terminate
to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this the connection after BULK_LQ_DATA_TIMEOUT. We make this
recommendation to allow requesters to control the period of time they recommendation to allow requesters to control the period of time they
are willing to wait before abandoning a connection, independent of are willing to wait before abandoning a connection, independent of
notifications from the TCP implementations they may be using. notifications from the TCP implementations they may be using.
8.3. Processing Active Replies 8.4. Processing Active Replies
The Requestor attempts to read a DHCPv6 LEASEQUERY-REPLY message from The Requestor attempts to read a DHCPv6 LEASEQUERY-REPLY message from
the TCP connection. If the stream of replies becomes blocked, the the TCP connection. If the stream of replies becomes blocked, the
Requestor SHOULD be prepared to terminate the connection after Requestor SHOULD terminate the connection after
ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured
to do so. to do so.
The requestor examines the LEASEQUERY-REPLY message, and determines The requestor examines the LEASEQUERY-REPLY message, and determines
how to proceed. Message validation rules are specified in DHCPv6 how to proceed. Message validation rules are specified in DHCPv6
Leasequery [RFC5007] and DHCPv6 Bulk Leasequery [RFC5460]. If the Leasequery [RFC5007] and DHCPv6 Bulk Leasequery [RFC5460]. If the
reply contains an DHCPv6 status code (carried in an reply contains an DHCPv6 status code (carried in an
OPTION_STATUS_CODE option), the requestor follows the recommendations OPTION_STATUS_CODE option), the requestor should follow the
in [RFC5007]. recommendations in [RFC5007].
Note that an Active Leasequery request specifically requests the Note that an Active Leasequery request specifically requests the
DHCPv6 server to create a long-lived connection which may not have DHCPv6 server to create a long-lived connection which may not have
data transferring continuously during its lifetime. Therefore the data transferring continuously during its lifetime. Therefore the
DHCPv6 server will send a LEASEQUERY-DATA message without binding DHCPv6 server SHOULD send a LEASEQUERY-DATA message without binding
data (OPTION_CLIENT_DATA) every ACTIVE_LQ_IDLE_TIMEOUT seconds data (OPTION_CLIENT_DATA) every ACTIVE_LQ_IDLE_TIMEOUT seconds
(default 60) in order for the requestor to know that the connection (default 60) in order for the requestor to know that the connection
remains alive. This approach is followed only when connection is remains alive. This approach is followed only when connection is
idle (i.e. server has no binding data to send). During normal idle (i.e. server has no binding data to send). During normal
binding data exchange, receiving of LEASEQUERY-DATA message by binding data exchange, receiving of LEASEQUERY-DATA message by
requestor itself signifies that connection is active. Note that the requestor itself signifies that connection is active. Note that the
default for ACTIVE_LQ_RCV_TIMEOUT is 120 seconds, twice the value of default for ACTIVE_LQ_RCV_TIMEOUT is 120 seconds, twice the value of
the ACTIVE_LQ_IDLE_TIMEOUT's default of 60 seconds which drives the the ACTIVE_LQ_IDLE_TIMEOUT's default of 60 seconds which drives the
DHCPv6 server to send messages. Thus ACTIVE_LQ_RCV_TIMEOUT controls DHCPv6 server to send messages. Thus ACTIVE_LQ_RCV_TIMEOUT controls
how sensitive the requestor is to be to delays by the DHCPv6 server how sensitive the requestor is to be to delays by the DHCPv6 server
in sending updates or LEASEQUERY-DATA messages. in sending updates or LEASEQUERY-DATA messages.
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
ACTIVELEASEQUERY message from a single DHCPv6 server. ACTIVELEASEQUERY message from a single DHCPv6 server.
An Active Leasequery has two regimes -- during the catch-up phase, if An Active Leasequery has two regimes -- during the catch-up phase, if
any, and after any catch-up phase. During the catch-up phase (if one any, and after any catch-up phase. If the Active Leasequery was
exists), the data returned in the OPTION_LQ_BASE_TIME option in a requested with an OPTION_LQ_START_TIME option, the Active Leasequery
LEASEQUERY-REPLY or LEASEQUERY-DATA message may appear to be ordered, starts out in the catch-up phase. See Section 8.4.1 for information
but the most recent change in the lease state data being returned is on processing during the catch-up phase, as well as how to determine
not related to the OPTION_LQ_BASE_TIME option value in the messages. when the catch-up phase is complete.
Another way to say this is that the ordering of the updates sent by
the DHCPv6 server during the catch-up phase is independent of the The updates sent by the DHCPv6 server during the catch-up phase are
ordering in the changes in the lease state data. The not in the order that the lease state data was updated. Therefore,
OPTION_LQ_BASE_TIME option from messages during this phase MUST NOT the OPTION_LQ_BASE_TIME option from messages during this phase MUST
be saved and used in a subsequent ACTIVELEASEQUERY message's NOT be saved and used to compute the subsequent ACTIVELEASEQUERY
OPTION_LQ_START_TIME option as it does not represent the extent of message's OPTION_LQ_START_TIME option.
progress of the catch-up activity.
After the catch-up phase, or during the entire series of messages After the catch-up phase, or during the entire series of messages
received as the response to an Active Leasequery request with no received as the response to an Active Leasequery request with no
OPTION_LQ_START_TIME (and therefore no catch-up phase), the OPTION_LQ_START_TIME (and therefore no catch-up phase), the
OPTION_LQ_BASE_TIME option of the most recent message SHOULD be saved OPTION_LQ_BASE_TIME option of the most recent message SHOULD be saved
as a record of the most recent time that data was received. This as a record of the most recent time that data was received. This
base-time (in the context of the DHCPv6 server) can be used in a base-time (in the context of the DHCPv6 server) can be used in a
subsequent Active Leasequery message's OPTION_LQ_START_TIME after a subsequent Active Leasequery message's OPTION_LQ_START_TIME after a
loss of the Active Leasequery connection. loss of the Active Leasequery connection.
skipping to change at page 15, line 41 skipping to change at page 17, line 5
a ACTIVELEASEQUERY request. For example, when a server is requested a ACTIVELEASEQUERY request. For example, when a server is requested
to shut down it SHOULD send a LEASEQUERY-DONE message with a DHCPv6 to shut down it SHOULD send a LEASEQUERY-DONE message with a DHCPv6
status code of QueryTerminated and include OPTION_LQ_BASE_TIME option status code of QueryTerminated and include OPTION_LQ_BASE_TIME option
in the message. This SHOULD be the last message on that connection, in the message. This SHOULD be the last message on that connection,
and once the message has been transmitted, the server should close and once the message has been transmitted, the server should close
the connection. the connection.
After receiving LEASEQUERY-DONE with a QueryTerminated status from a After receiving LEASEQUERY-DONE with a QueryTerminated status from a
server, the Requestor MAY close the TCP connection to that server. server, the Requestor MAY close the TCP connection to that server.
8.3.1. Processing Replies from a Request Containing a 8.4.1. Processing Replies from a Request Containing a
OPTION_LQ_START_TIME OPTION_LQ_START_TIME
If the Active Leasequery was requested with an OPTION_LQ_START_TIME If the Active Leasequery was requested with an OPTION_LQ_START_TIME
option, the DHCPv6 server will attempt to send information about all option, the DHCPv6 server will attempt to send information about all
bindings that changed since the time specified in the bindings that changed since the time specified in the
OPTION_LQ_START_TIME. This is the catch-up phase of the Active OPTION_LQ_START_TIME. This is the catch-up phase of the Active
Leasequery processing. The DHCPv6 server MAY also begin immediate Leasequery processing. The DHCPv6 server MAY also begin immediate
updates over the same connection of real-time binding information updates over the same connection of real-time binding information
changes. Thus, the catch-up phase may run in parallel with the changes. Thus, the catch-up phase may run in parallel with the
normal updates generated by the Active Leasequery request. normal updates generated by the Active Leasequery request.
skipping to change at page 16, line 28 skipping to change at page 17, line 40
If there is enough data saved to satisfy the request, then If there is enough data saved to satisfy the request, then
LEASEQUERY-REPLY (with OPTION_STATUS_CODE of Success or reply without LEASEQUERY-REPLY (with OPTION_STATUS_CODE of Success or reply without
OPTION_STATUS_CODE option) and LEASEQUERY-DATA messages will begin OPTION_STATUS_CODE option) and LEASEQUERY-DATA messages will begin
arrive from the DHCPv6 server. Some of these messages will be arrive from the DHCPv6 server. Some of these messages will be
related to the OPTION_LQ_START_TIME request and be part of the catch- related to the OPTION_LQ_START_TIME request and be part of the catch-
up phase. Some of these messages will be real-time updates of up phase. Some of these messages will be real-time updates of
binding changes taking place in the DHCPv6 server. In general, there binding changes taking place in the DHCPv6 server. In general, there
is no way to determine the source of each message. is no way to determine the source of each message.
Until the catch-up phase is complete, the latest base-time value The updates sent by the DHCPv6 server during the catch-up phase are
received from a DHCPv6 server processing an Active Leasequery request not in the order that the binding data was updated. Therefore, until
cannot be reset from the incoming messages because to do so would the catch-up phase is complete, the latest base-time value received
from a DHCPv6 server processing an Active Leasequery request cannot
be reset from the incoming messages (and used in a subsequent Active
Leasequery's query-start-time option), because to do so would
compromise the ability to recover lost information if the Active compromise the ability to recover lost information if the Active
Leasequery were to terminate prior to the completion of the catch-up Leasequery were to terminate prior to the completion of the catch-up
phase. phase.
The requestor will know that the catch-up phase is complete when the The requestor will know that the catch-up phase is complete when the
DHCPv6 server will transmit a LEASEQUERY-DATA message with the DHCPv6 DHCPv6 server will transmit a LEASEQUERY-DATA message with the DHCPv6
status code of CatchUpComplete. Once this message is transmitted, status code of CatchUpComplete (or LEASEQUERY-REPLY message with a
all additional LEASEQUERY-DATA messages will relate to real-time DHCPv6 status code of DataMissing, as discussed above). Once this
("new") binding changes in the DHCPv6 server. message is transmitted, all additional LEASEQUERY-DATA messages will
relate to real-time ("new") binding changes in the DHCPv6 server.
As discussed in Section 8.3, the requestor SHOULD keep track of the As discussed in Section 8.4, 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 Active Leasequery request -- but only if to be used in a subsequent Active Leasequery request -- but only if
the catch-up phase is complete. Prior to the completion of the 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 LEASEQUERY-DONE message, then when it reconnects it MUST receives a LEASEQUERY-DONE message, then when it reconnects it MUST
use the base-time value from the previous connection and not any use the base-time value from the previous connection and not any
base-time value received from the recently closed connection. base-time value received from the recently closed connection.
In the event that there was enough data available to the DHCPv6 In the event that there was enough data available to the DHCPv6
server to begin to satisfy the request implied by the server to begin to satisfy the request implied by the
skipping to change at page 17, line 22 skipping to change at page 18, line 38
every binding during the period from the time specified in the every binding during the period from the time specified in the
OPTION_LQ_START_TIME and the present is replicated in an Active OPTION_LQ_START_TIME and the present is replicated in an Active
Leasequery reply message. The requestor MAY assume that at least one Leasequery reply message. The requestor MAY assume that at least one
Active Leasequery reply message will exist for every binding which Active Leasequery reply message will exist for every binding which
had one or more changes of state during the period specified by the had one or more changes of state during the period specified by the
OPTION_LQ_START_TIME and the current time. The last message for each OPTION_LQ_START_TIME and the current time. The last message for each
binding will contain the state at the current time, and there may be binding will contain the state at the current time, and there may be
one or more messages concerning a single binding during the catch-up one or more messages concerning a single binding during the catch-up
phase of processing. phase of processing.
If a binding changed state multiple times during the time that the Bindings can change multiple times while the requester was not
requestor was not connected (that is, during the time from the connected (that is, during the time from the OPTION_LQ_START_TIME and
OPTION_LQ_START_TIME and the present), then only the current binding the present). The requestor will only receive information about the
information will be sent during the catch-up phase. However, the current state of the binding, not information about each state change
requestor MUST NOT assume that every intermediate state change that that occurred during the period from the OPTION_LQ_START_TIME to the
occurred during the period from the OPTION_LQ_START_TIME to the present.
present will be represented by an individual Leasequery message.
If the LEASEQUERY-REPLY or LEASEQUERY-DATA message containing a If the LEASEQUERY-REPLY or LEASEQUERY-DATA message containing a
DHCPv6 status code of DataMissing is received and the requestor is DHCPv6 status code of DataMissing is received and the requestor is
interested in keeping its database up to date with respect to the interested in keeping its database up to date with respect to the
current state of bindings in the DHCPv6 server, then the requestor current state of bindings in the DHCPv6 server, then the requestor
SHOULD issue a Bulk Leasequery request to recover the information SHOULD issue a Bulk Leasequery request to recover the information
missing from its database. This Bulk Leasequery request should missing from its database. This Bulk Leasequery request should
include a OPTION_LQ_START_TIME option with the same value as the include a OPTION_LQ_START_TIME option with the same value as the
OPTION_LQ_START_TIME option previously included in the OPTION_LQ_START_TIME option previously included in the
ACTIVELEASEQUERY responses from the DHCPv6 server, and an ACTIVELEASEQUERY responses from the DHCPv6 server, and an
OPTION_LQ_END_TIME option equal to the OPTION_LQ_BASE_TIME option OPTION_LQ_END_TIME option equal to the OPTION_LQ_BASE_TIME option
returned by the DHCPv6 server in the LEASEQUERY-REPLY or LEASEQUERY- returned by the DHCPv6 server in the LEASEQUERY-REPLY or LEASEQUERY-
DATA message with the DHCPv6 status code of DataMissing. DATA message with the DHCPv6 status code of DataMissing.
In the event that the requestor receives a LEASEQUERY-REPLY or
LEASEQUERY-DATA message with a DHCPv6 status code of DataMissing, it
is a reasonable assumption that it is interested in keeping its
database up to date with respect to the DHCPv6 server's internal
binding database or it would not have included the
OPTION_LQ_START_TIME in the ACTIVELEASEQUERY message.
Typically, the requestor would have one connection open to a DHCPv6 Typically, the requestor would have one connection open to a DHCPv6
server for an Active Leasequery request and possibly one additional server for an Active Leasequery request and possibly one additional
connection open for a Bulk Leasequery request to the same DHCPv6 connection open for a Bulk Leasequery request to the same DHCPv6
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 Active Leasequery. The Bulk Leasequery connection initiation of the Active Leasequery. The Bulk Leasequery connection
would typically run to completion and be closed, leaving one Active would typically run to completion and be closed, leaving one Active
Leasequery connection open to a single DHCPv6 server. Alternatively, Leasequery connection open to a single DHCPv6 server. Alternatively,
both requests could be issued over a single connection. both requests could be issued over a single connection.
8.4. Processing Time Values in Leasequery messages 8.5. Processing Time Values in Leasequery messages
Active or Bulk Leasequery requests may be made to a DHCPv6 server Active or Bulk Leasequery requests may be made to a DHCPv6 server
whose absolute time may not be synchronized with the local time of whose absolute time may not be synchronized with the local time of
the requestor. Thus, there are at least two time contexts in even the requestor. Thus, there are at least two time contexts in even
the simplest Active or Bulk Leasequery response. the simplest Active or Bulk Leasequery response.
If the requestor of an Active or Bulk Leasequery is saving the data If the requestor of an Active or Bulk Leasequery is saving the data
returned in some form, it has a requirement to store a variety of returned in some form, it has a requirement to store a variety of
time values, and some of these will be time in the context of the time values, and some of these will be time in the context of the
requestor and some will be time in the context of the DHCPv6 server. requestor and some will be time in the context of the DHCPv6 server.
skipping to change at page 18, line 43 skipping to change at page 20, line 5
In addition to saving the OPTION_LQ_BASE_TIME for possible future use In addition to saving the OPTION_LQ_BASE_TIME for possible future use
in OPTION_LQ_START_TIME or OPTION_LQ_END_TIME option, the in OPTION_LQ_START_TIME or OPTION_LQ_END_TIME option, the
OPTION_LQ_BASE_TIME is used as part of the conversion of the other OPTION_LQ_BASE_TIME is used as part of the conversion of the other
times in the Leasequery message to values which are meaningful in the times in the Leasequery message to values which are meaningful in the
context of the requestor. context of the requestor.
In systems whose clocks are synchronized, perhaps using NTP, the In systems whose clocks are synchronized, perhaps using NTP, the
clock skew will usually be zero, which is not only acceptable, but clock skew will usually be zero, which is not only acceptable, but
desired. desired.
8.5. Examples 8.6. Examples
These examples illustrate what a series of queries and responses These examples illustrate what a series of queries and responses
might look like. These are only examples -- there are no requirement might look like. These are only examples -- there are no requirement
that these sequence must be followed. that these sequence must be followed.
8.5.1. Query Failure 8.6.1. Query Failure
This example illustrates the message flows in case DHCPv6 server This example illustrates the message flows in case DHCPv6 server
identifies that it cannot accept and/or process Active Leasequery identifies that it cannot accept and/or process Active Leasequery
request from the requestor. This could be because of various reasons request from the requestor. This could be because of various reasons
(i.e. UnknownQueryType, MalformedQuery, NotConfigured, NotAllowed). (i.e. UnknownQueryType, MalformedQuery, NotConfigured, NotAllowed,
NotSupported).
Client Server Client Server
------ ------ ------ ------
ACTIVELEASEQUERY xid 1 -----> ACTIVELEASEQUERY xid 1 ----->
<----- LEASEQUERY-REPLY xid 1 (w/error) <----- LEASEQUERY-REPLY xid 1 (w/error)
8.5.2. Data Missing on Server 8.6.2. Data Missing on Server
This example illustrates the message flows in case DHCPv6 server This example illustrates the message flows in case DHCPv6 server
identifies that it does not have enough data saved to satisfy the identifies that it does not have enough data saved to satisfy the
request specified by the OPTION_LQ_START_TIME option. request specified by the OPTION_LQ_START_TIME option.
In this case the DHCPv6 server will reply immediately with a In this case the DHCPv6 server will reply immediately with a
LEASEQUERY-REPLY message with a DHCPv6 status code of DataMissing LEASEQUERY-REPLY message with a DHCPv6 status code of DataMissing
with a base-time option equal to the server's current time. This with a base-time option equal to the server's current time. This
will signal the end of the catch-up phase, and the only updates that will signal the end of the catch-up phase, and the only updates that
will subsequently be received on this connection are the real-time will subsequently be received on this connection are the real-time
updates from the Active Leasequery request. updates from the Active Leasequery request.
Client Server Client Server
------ ------ ------ ------
ACTIVELEASEQUERY xid 2 -----> ACTIVELEASEQUERY xid 2 ----->
<----- LEASEQUERY-REPLY xid 2 (w/error) <----- LEASEQUERY-REPLY xid 2 (w/error)
<----- LEASEQUERY-DATA xid 2 <----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DATA xid 2 <----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DATA xid 2 <----- LEASEQUERY-DATA xid 2
8.5.3. Successful Query 8.6.3. Successful Query
This example illustrates the message flows in case of successful This example illustrates the message flows in case of successful
query processing by DHCPv6 server. query processing by DHCPv6 server.
In this case the DHCPv6 server will reply immediately with a In this case the DHCPv6 server will reply immediately with a
LEASEQUERY-REPLY message (with OPTION_STATUS_CODE of Success or reply LEASEQUERY-REPLY message (with OPTION_STATUS_CODE of Success or reply
without OPTION_STATUS_CODE option), followed by binding data in without OPTION_STATUS_CODE option), followed by binding data in
LEASEQUERY-DATA messages. In case, DHCPv6 server wants to abort in- LEASEQUERY-DATA messages. In case, DHCPv6 server wants to abort in-
process request and terminate the connection due to some reason, it process request and terminate the connection due to some reason, it
sends LEASEQUERY-DONE with error code present in OPTION_STATUS_CODE sends LEASEQUERY-DONE with error code present in OPTION_STATUS_CODE
skipping to change at page 20, line 15 skipping to change at page 21, line 23
Client Server Client Server
------ ------ ------ ------
ACTIVELEASEQUERY xid 3 -----> ACTIVELEASEQUERY xid 3 ----->
<----- LEASEQUERY-REPLY xid 3 <----- LEASEQUERY-REPLY xid 3
<----- LEASEQUERY-DATA xid 3 <----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DATA xid 3 <----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DATA xid 3 <----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DATA xid 3 <----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DONE xid 3 (w/error) <----- LEASEQUERY-DONE xid 3 (w/error)
8.6. Closing Connections 8.7. Closing Connections
The Requestor or DHCPv6 Leasequery server MAY close its end of the The Requestor or DHCPv6 Leasequery server MAY close its end of the
TCP connection at any time. The Requestor MAY choose to retain the TCP connection at any time. The Requestor MAY choose to retain the
connection if it intends to issue additional queries. Note that this connection if it intends to issue additional queries. Note that this
requestor behavior does not guarantee that the connection will be requestor behavior does not guarantee that the connection will be
available for additional queries: the server might decide to close available for additional queries: the server might decide to close
the connection based on its own configuration. the connection based on its own configuration.
9. Server Behavior 9. Server Behavior
A DHCPv6 server which supports Active Leasequery MUST support DHCPv6 A DHCPv6 server which supports Active Leasequery MUST support DHCPv6
Bulk Leasequery [RFC5460] and as extended herein. Bulk Leasequery [RFC5460] and as extended herein.
9.1. Accepting Connections 9.1. Accepting Connections
Servers that implement DHCPv6 Active Leasequery listen for incoming DHCPv6 servers that implement DHCPv6 Active Leasequery listen for
TCP connections. Approach used in accepting (or rejecting) the incoming TCP connections. Approach used in accepting the requestor
requestor connection is same as specified in DHCPv6 Bulk Leasequery connection is same as specified in DHCPv6 Bulk Leasequery [RFC5460].
[RFC5460].
9.2. Replying to an Active Leasequery DHCPv6 servers SHOULD support TLS [RFC5246] to protect the integrity
and privacy of the data transmitted over the TCP connection. DHCPv6
servers SHOULD negotiate a TLS connection with the requestor who asks
for one, and MAY choose to accept DHCPv6 Active Leasequery request
over connections which are not secured with TLS.
A requestor will request a TLS connection by sending a STARTTLS as
the first message over a newly created TCP connection. If the DHCPv6
server supports TLS connections and has not been configured to not
allow them on this link, the DHCPv6 server SHOULD respond to this
STARTTLS message by sending a REPLY [RFC3315] message without DHCPv6
status code back to the requestor. This indicates to the requestor
that the DHCPv6 server will support the negotiation of a TLS
connection over this existing TCP connection.
If for some reason the DHCPv6 server cannot or has been configured to
not support a TLS connection, then it SHOULD send a REPLY message
with DHCPv6 status code of TLSConnectionRefused back to the
requestor.
In the event that the DHCPv6 server sends a REPLY message without
DHCPv6 status code option included (which indicates success), the
requestor is supposed to initiate a TLS handshake [RFC5246] (see
Section 8.2).
If the TLS handshake is not successful in creating a TLS connection,
the server MUST drop the TCP connection.
9.2. Rejecting Connections
Servers that do not implement DHCPv6 Active and Bulk Leasequery
SHOULD NOT listen for incoming TCP connections for these requests.
If the DHCPv6 server supporting Bulk Leasequery and not Active
Leasequery receives an Active Leasequery request, it SHOULD send a
LEASEQUERY-REPLY with DHCPv6 status code as NotSupported. It SHOULD
close the TCP connection after this error is signaled.
9.3. Replying to an Active Leasequery
The DHCPv6 Leasequery [RFC5007] specification describes the initial The DHCPv6 Leasequery [RFC5007] specification describes the initial
construction of LEASEQUERY-REPLY messages. Use of the LEASEQUERY- construction of LEASEQUERY-REPLY messages. Use of the LEASEQUERY-
REPLY and LEASEQUERY-DATA messages to carry multiple bindings is REPLY and LEASEQUERY-DATA messages to carry multiple bindings is
described in DHCPv6 Bulk Leasequery [RFC5460]. Message transmission described in DHCPv6 Bulk Leasequery [RFC5460]. Message transmission
and framing for TCP is described in Section 6.1. and framing for TCP is described in Section 6.1.
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 be prepared to terminate the send reply messages, the server SHOULD terminate the TCP connection
TCP connection after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs for how long the
how much congestion the DHCPv6 server is prepared to tolerate over DHCPv6 server is prepared to wait for the requestor to read and
any Active Leasequery connection. The default is two minutes, which process enough information to unblock the TCP connection. The
means that if more than two minutes goes by without the requestor default is two minutes, which means that if more than two minutes
reading enough information to unblock the TCP connection, the DHCPv6 goes by without the requestor reading enough information to unblock
server will drop the TCP connection. the TCP connection, the DHCPv6 server SHOULD drop the TCP connection.
If the DHCPv6 server encounters an error during initial processing of If the DHCPv6 server encounters an error during initial processing of
the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-REPLY the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-REPLY
message containing an error code of some kind in a DHCPv6 status code message containing an error code of some kind in a DHCPv6 status code
option. It SHOULD close the connection after this error is signaled. option. It SHOULD close the connection after this error is signaled.
If the DHCPv6 server encounters an error during later processing of If the DHCPv6 server encounters an error during later processing of
the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-DONE the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-DONE
containing an error code of some kind in a DHCPv6 status code option. containing an error code of some kind in a DHCPv6 status code option.
It SHOULD close the connection after this error is signaled. It SHOULD close the connection after this error is signaled.
If the server finds any bindings satisfying a query, it sends each If the server finds any bindings satisfying a query, it SHOULD send
binding's data in a reply message. The first reply message is a each binding's data in a reply message. The first reply message is a
LEASEQUERY-REPLY. The binding data is carried in an LEASEQUERY-REPLY. The binding data is carried in an
OPTION_CLIENT_DATA option, as specified in [RFC5007]. The server OPTION_CLIENT_DATA option, as specified in [RFC5007]. The server
returns subsequent bindings in LEASEQUERY-DATA messages, which can SHOULD send subsequent bindings in LEASEQUERY-DATA messages, which
avoid redundant data (such as the requestor's Client-ID). can avoid redundant data (such as the requestor's Client-ID).
Every reply to an Active Leasequery request MUST contain the Every reply to an Active Leasequery request MUST contain the
information specified in replies to a DHCPv6 Bulk Leasequery request information specified in replies to a DHCPv6 Bulk Leasequery request
[RFC5460]. [RFC5460].
Some servers can be configured to respond to a DHCPv6 Leasequery
[RFC5007] and DHCPv6 Bulk Leasequery [RFC5460] for an IPv6 binding
which is reserved in such a way that it appears that the IPv6 binding
is leased to the DHCP client for which it is reserved. These servers
SHOULD also respond to an Active Leasequery request with the same
information as they would to a Bulk Leasequery request when they
first determine that the IPv6 binding is reserved to a DHCP client.
If an Active Leasequery or Bulk Leasequery request contains If an Active Leasequery or Bulk Leasequery request contains
OPTION_LQ_BASE_TIME option code present in OPTION_ORO, the DHCPv6 OPTION_LQ_BASE_TIME option code present in OPTION_ORO, the DHCPv6
server MUST include OPTION_LQ_BASE_TIME option in every reply for server MUST include OPTION_LQ_BASE_TIME option in every reply for
this request. The value for base-time option is current absolute this request. The value for base-time option is current absolute
time in the DHCPv6 server's context. time in the DHCPv6 server's context.
If an Active Leasequery request contains an OPTION_LQ_START_TIME If an Active Leasequery request contains an OPTION_LQ_START_TIME
option, it indicates that the requestor would like the DHCPv6 server option, it indicates that the requestor would like the DHCPv6 server
to send it not only messages that correspond to DHCPv6 binding to send it not only messages that correspond to DHCPv6 binding
activity that occurs subsequent to the receipt of the Active activity that occurs subsequent to the receipt of the Active
Leasequery request, but also messages that correspond to DHCPv6 Leasequery request, but also messages that correspond to DHCPv6
binding activity that occurred prior to the Active Leasequery binding activity that occurred prior to the Active Leasequery
request. request.
If OPTION_LQ_END_TIME option appears in an Active Leasequery request, If OPTION_LQ_END_TIME option appears in an Active Leasequery request,
the DHCPv6 server should send a LEASEQUERY-REPLY message with a the DHCPv6 server SHOULD send a LEASEQUERY-REPLY message with a
DHCPv6 status code of MalformedQuery and terminate the connection. DHCPv6 status code of MalformedQuery and terminate the connection.
In order to implement a meaningful response to this query, the DHCPv6 In order to implement a meaningful response to this query, the DHCPv6
server MAY keep track of the binding activity and associate changes server MAY keep track of the binding activity and associate changes
with particular base-time values from the messages. Then, when with particular base-time values from the messages. Then, when
requested to do so by an Active Leasequery request containing a requested to do so by an Active Leasequery request containing a
OPTION_LQ_START_TIME option, the DHCPv6 server can respond with OPTION_LQ_START_TIME option, the DHCPv6 server can respond with
replies for all binding activity occurring on that replies for all binding activity occurring on that
OPTION_LQ_START_TIME or later times. OPTION_LQ_START_TIME or later times.
skipping to change at page 22, line 31 skipping to change at page 24, line 35
server to retain this information over a server restart (or even to server to retain this information over a server restart (or even to
retain such information at all). retain such information at all).
Unless there is an error or some requirement to cease processing a Unless there is an error or some requirement to cease processing a
Active Leasequery request yielding a LEASEQUERY-DONE message, such as Active Leasequery request yielding a LEASEQUERY-DONE message, such as
a server shutdown, there will be no LEASEQUERY-DONE message at the a server shutdown, there will be no LEASEQUERY-DONE message at the
conclusion of the Active Leasequery processing because that conclusion of the Active Leasequery processing because that
processing will not conclude but will continue until either the processing will not conclude but will continue until either the
requestor or the server drops the connection. requestor or the server drops the connection.
9.3. Multiple or Parallel Queries 9.4. Multiple or Parallel Queries
Requesters may want to use an existing connection if they need to Requesters may want to use an existing connection if they need to
make multiple queries. Servers MAY support reading and processing make multiple queries. Servers MAY support reading and processing
multiple queries from a single connection. A server MUST NOT read multiple queries from a single connection. A server MUST NOT read
more query messages from a connection than it is prepared to process more query messages from a connection than it is prepared to process
simultaneously. simultaneously.
Typically, a requestor of an Active Leasequery would not need to send Typically, a requestor of an Active Leasequery would not need to send
a second Active Leasequery while the first is still active. However, a second Active Leasequery while the first is still active. However,
sending an Active Leasequery and a Bulk Leasequery over the same sending an Active Leasequery and a Bulk Leasequery over the same
connection would be possible and reasonable. But it is RECOMMENDED connection would be possible and reasonable. But it is RECOMMENDED
to use different connection in case of parallel Active and Bulk to use different connection in case of parallel Active and Bulk
Leasequeries. Leasequeries.
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 requesters seeking service. there are multiple requesters seeking service.
9.4. Closing Connections 9.5. Closing Connections
The server MUST close its end of the TCP connection if it encounters The server MUST close its end of the TCP connection if it encounters
an error sending data on the connection. The server MUST close its an error sending data on the connection. The server MUST close its
end of the TCP connection if it finds that it has to abort an in- end of the TCP connection if it finds that it has to abort an in-
process request. A server aborting an in-process request SHOULD process request. A server aborting an in-process request SHOULD
attempt to signal that to its requestors by using the QueryTerminated attempt to signal that to its requestors by using the QueryTerminated
status code in the DHCPv6 status code option in a LEASEQUERY-DONE status code in the DHCPv6 status code option in a LEASEQUERY-DONE
message. If the server detects that the requestor end has been message. If the server detects that the requestor end has been
closed, the server MUST close its end of the connection after it has closed, the server MUST close its end of the connection after it has
finished processing any outstanding requests from the requestor. finished processing any outstanding requests from the requestor.
The server SHOULD be prepared to limit the number of connections it The server SHOULD limit the number of connections it maintains, and
maintains, and SHOULD be prepared to close idle connections to SHOULD close idle connections to enforce the limit.
enforce the limit.
10. Security Considerations 10. Security Considerations
The "Security Considerations" section of [RFC3315] details the The "Security Considerations" section of [RFC3315] details the
general threats to DHCPv6. The DHCPv6 Leasequery specification general threats to DHCPv6. The DHCPv6 Leasequery specification
[RFC5007] describes recommendations for the Leasequery protocol, [RFC5007] 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 denial-of-service (DoS) attacks, restriction to packet-flooding denial-of-service (DoS) attacks, restriction to
trusted requestors, and use of IPsec [RFC4301]. trusted requestors, and use of IPsec [RFC4301].
skipping to change at page 24, line 5 skipping to change at page 26, line 9
that Active Leasequery can provide from reaching requestors who are that Active Leasequery can provide from reaching requestors who are
not authorized to receive such information. The second is ensuring not authorized to receive such information. The second is ensuring
that authorized requestors of the Active Leasequery capability that authorized requestors of the Active Leasequery capability
receive accurate information from the Server (and that this receive accurate information from the Server (and that this
information is not disrupted in transit). information is not disrupted in transit).
To prevent information leakage to unauthorized requestors, Servers To prevent information leakage to unauthorized requestors, Servers
SHOULD restrict Active Leasequery connections and ACTIVELEASEQUERY SHOULD restrict Active Leasequery connections and ACTIVELEASEQUERY
messages to certain requestors, either through explicit configuration messages to certain requestors, either through explicit configuration
of the Server itself or by employing external network elements to of the Server itself or by employing external network elements to
provide such restrictions. In particular, the typical DHCPv6 client provide such restrictions.
SHOULD NOT be allowed to receive a response to an Active Leasequery
request, and some technique MUST exist to allow prevention of such
access in any environment where Active Leasequery is deployed.
Connections not from permitted requestors SHOULD be closed Connections not from permitted requestors SHOULD be closed
immediately, to avoid server connection resource exhaustion or immediately, to avoid server connection resource exhaustion or
alternatively, simply not be allowed to reach the server at all. alternatively, simply not be allowed to reach the server at all.
Servers SHOULD have the capability to restrict certain requestors to Servers SHOULD have the capability to restrict certain requestors to
certain query types. Servers MAY reply to queries that are not certain query types. Servers MAY reply to queries that are not
permitted with the LEASEQUERY-DONE message with a status-code option permitted with the LEASEQUERY-DONE message with a status-code option
status of NotAllowed, or MAY simply close the connection. status of NotAllowed, or MAY simply close the connection.
To prevent interception, disruption and malicious corruption of In addition, requestors and servers SHOULD use TLS [RFC5246] to
Active Leasequery data flows between the server and authorized protect the integrity and privacy of the Active Leasequery data
requestors these data flows SHOULD transit only secured networks. transmitted over the TCP connection.
These data flows are typically infrastructure oriented, and there is
usually no reason to have them flowing over networks where such
attacks are likely. In the rare cases where these data flows might
need to be sent through unsecured networks, they MUST be sent over
connections secured through means external to the DHCPv4/DHCPv6
server and its requestor(s) (e.g., through VPN's).
Authentication for DHCP Messages [RFC3315] MUST NOT be used to Authentication for DHCP Messages [RFC3315] MUST NOT be used to
attempt to secure transmission of the messages described in this attempt to secure transmission of the messages described in this
document. document.
11. IANA Considerations 11. IANA Considerations
IANA is requested to assign new DHCPv6 Option Codes in the registry IANA is requested to assign new DHCPv6 Option Codes in the registry
maintained in http://www.iana.org/assignments/dhcpv6-parameters: maintained in http://www.iana.org/assignments/dhcpv6-parameters:
skipping to change at page 25, line 5 skipping to change at page 26, line 46
OPTION_LQ_END_TIME OPTION_LQ_END_TIME
IANA is requested to assign new values in the registry of DHCPv6 IANA is requested to assign new values in the registry of DHCPv6
Status Codes maintained in http://www.iana.org/assignments/ Status Codes maintained in http://www.iana.org/assignments/
dhcpv6-parameters: dhcpv6-parameters:
DataMissing DataMissing
CatchUpComplete CatchUpComplete
NotSupported
TLSConnectionRefused
IANA is requested to assign value for the following new DHCPv6 IANA is requested to assign value for the following new DHCPv6
Message type in the registry maintained in http://www.iana.org/ Message type in the registry maintained in
assignments/dhcpv6-parameters: http://www.iana.org/assignments/dhcpv6-parameters:
ACTIVELEASEQUERY ACTIVELEASEQUERY
STARTTLS
12. Acknowledgements 12. Acknowledgements
Some of the concept and content, present in this document, are based Some of the concept and content, present in this document, are based
on DHCPv4 Active Leasequery which was originally proposed by Kim on DHCPv4 Active Leasequery which was originally proposed by Kim
Kinnear, Bernie Volz, Mark Stapp and Neil Russell. Kinnear, Bernie Volz, Mark Stapp and Neil Russell.
13. Modification History 13. Modification History
14. References 14. References
skipping to change at page 25, line 37 skipping to change at page 27, line 39
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007. "DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February
2009. 2009.
14.2. Informative References 14.2. Informative References
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
for Transmission Control Protocol (TCP) Specification for Transmission Control Protocol (TCP) Specification
 End of changes. 74 change blocks. 
193 lines changed or deleted 290 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/