draft-ietf-dhc-dhcpv6-active-leasequery-00.txt   draft-ietf-dhc-dhcpv6-active-leasequery-01.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 Intended status: Standards Track D. Kukrety
Expires: June 7, 2014 Cisco Systems, Inc. Expires: September 29, 2014 Cisco Systems, Inc.
December 4, 2013 March 28, 2014
DHCPv6 Active Leasequery DHCPv6 Active Leasequery
draft-ietf-dhc-dhcpv6-active-leasequery-00 draft-ietf-dhc-dhcpv6-active-leasequery-01
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 until the time DHCPv6 to queries for DHCPv6 binding data updates prior to the time the
server receive the Leasequery request. Continuous update of an DHCPv6 server receives the Leasequery request. Continuous update of
external requestor with Leasequery data is sometimes desired. This an external requestor with Leasequery data is sometimes desired.
document expands on the DHCPv6 Leasequery protocol, and allows for This document expands on the DHCPv6 Leasequery protocol, and allows
active transfer of real-time DHCPv6 binding information data via TCP. for active transfer of real-time DHCPv6 binding information data via
This document also extends DHCPv6 Bulk Leasequery by adding new TCP. This document also extends DHCPv6 Bulk Leasequery by adding new
options. 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 June 7, 2014. This Internet-Draft will expire on September 29, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Interaction Between Active Leasequery and Bulk Leasequery . . 6 4. Interaction Between Active Leasequery and Bulk Leasequery . . 6
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 . . . . . . . . . . . . . . . 7
6.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 7 6.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 7
6.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2.1. ACTIVELEASEQUERY . . . . . . . . . . . . . . . . . . 7 6.2.1. ACTIVELEASEQUERY . . . . . . . . . . . . . . . . . . 8
6.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3.1. OPTION_LQ_BASE_TIME . . . . . . . . . . . . . . . . . 8 6.3.1. OPTION_LQ_BASE_TIME . . . . . . . . . . . . . . . . . 9
6.3.2. OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 9 6.3.2. OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 9
6.3.3. OPTION_LQ_END_TIME . . . . . . . . . . . . . . . . . 9 6.3.3. OPTION_LQ_END_TIME . . . . . . . . . . . . . . . . . 10
6.4. Connection and Transmission Parameters . . . . . . . . . 10 6.4. Connection and Transmission Parameters . . . . . . . . . 11
7. Information Communicated by Active Leasequery . . . . . . . . 11 7. Information Communicated by Active Leasequery . . . . . . . . 11
8. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 11 8. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 12
8.1. Connecting and General Processing . . . . . . . . . . . . 11 8.1. Connecting and General Processing . . . . . . . . . . . . 12
8.2. Forming an Active Leasequery . . . . . . . . . . . . . . 12 8.2. Forming an Active Leasequery . . . . . . . . . . . . . . 13
8.3. Processing Active Replies . . . . . . . . . . . . . . . . 13 8.3. Processing Active Replies . . . . . . . . . . . . . . . . 14
8.3.1. Processing Replies from a Request Containing a 8.3.1. Processing Replies from a Request Containing a
OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 15 OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 15
8.4. Processing Time Values in Leasequery messages . . . . . . 17 8.4. Processing Time Values in Leasequery messages . . . . . . 18
8.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 18 8.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 18
8.5.1. Query Failure . . . . . . . . . . . . . . . . . . . . 18 8.5.1. Query Failure . . . . . . . . . . . . . . . . . . . . 19
8.5.2. Data Missing on Server . . . . . . . . . . . . . . . 18 8.5.2. Data Missing on Server . . . . . . . . . . . . . . . 19
8.5.3. Successful Query . . . . . . . . . . . . . . . . . . 19 8.5.3. Successful Query . . . . . . . . . . . . . . . . . . 19
8.6. Closing Connections . . . . . . . . . . . . . . . . . . . 19 8.6. Closing Connections . . . . . . . . . . . . . . . . . . . 20
9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 19 9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Accepting Connections . . . . . . . . . . . . . . . . . . 19 9.1. Accepting Connections . . . . . . . . . . . . . . . . . . 20
9.2. Replying to an Active Leasequery . . . . . . . . . . . . 20 9.2. Replying to an Active Leasequery . . . . . . . . . . . . 20
9.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 22 9.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 22
9.4. Closing Connections . . . . . . . . . . . . . . . . . . . 22 9.4. Closing Connections . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
13. Modification History . . . . . . . . . . . . . . . . . . . . 24 13. Modification History . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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.
skipping to change at page 3, line 41 skipping to change at page 3, line 41
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.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in 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"
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"
skipping to change at page 4, line 4 skipping to change at page 4, line 6
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"
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 existing DHCPv6 binding information
in an efficient manner. in an efficient manner.
o "binding change/update"
Any change in the DHCPv6 binding state or data stored on the
DHCPv6 server related to binding. This also includes expiration
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
option in a ACTIVELEASEQUERY message, the DHCPv6 server will option in an ACTIVELEASEQUERY message, the DHCPv6 server will
attempt to send the requestor the information that changed since attempt to send the requestor the information that changed since
the time specified in the OPTION_LQ_START_TIME option. The the time specified in the OPTION_LQ_START_TIME option. The
binding information sent to satisfy this request is the catch-up binding information sent to satisfy this request is the catch-up
information, and the period while it is being sent is the catch-up information, 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
skipping to change at page 5, line 16 skipping to change at page 5, line 29
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
server sends updates to the requestor using LEASEQUERY-REPLY and server sends updates to the requestor using LEASEQUERY-REPLY and
LEASEQUERY-DATA messages. This response procedure is identical to LEASEQUERY-DATA messages. This response procedure is identical to
[RFC5460], except that in case of Active Leasequery server sends [RFC5460], except that in the case of Active Leasequery the server
updates whenever some activity occurs to change binding state - thus sends updates whenever some activity occurs to change the binding
the need for long lived connection. Active Leasequery is designed to state - thus the need for long lived connection.
provide continuous updates of DHCPv6 IPv6 binding activity to an
external entity.
Active Leasequery has features which allow this external entity to Active Leasequery has features which allow this external entity to
lose its connection and then reconnect and receive the latest lose its connection and then reconnect and receive the latest
information concerning any 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 capabilities are designed to allow the Active Leasequery
requestor to efficiently become current with respect to the lease requestor to efficiently become current with respect to the lease
state database after it has been restarted or the machine on which it state database after it has been restarted or the machine on which it
is running has been reinitialized. It is easy to define a protocol is running has been reinitialized. It is easy to define a protocol
skipping to change at page 5, line 52 skipping to change at page 6, line 15
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 more data was missed than
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 would 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 a 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. connection was temporarily interrupted. In other words, DHCPv6
servers supporting catch-up are required to have some mechanism to
keep/save historic information of bindings.
An Active Leasequery requestor would typically use Bulk Leasequery to An Active Leasequery requestor would typically use Bulk Leasequery to
initialize its database with all current data when that database initialize its database with all current data when that database
contains no binding information. In addition, it would use Bulk contains no binding information. In addition, it would use Bulk
Leasequery to recover missed information in the event that its Leasequery to recover missed information in the event that its
connection with the DHCPv6 server was lost for a longer time than the connection with the DHCPv6 server was lost for a longer time than the
DHCPv6 server would keep track of the specific changes to the IPv6 DHCPv6 server would keep track of the specific changes to the IPv6
binding information. binding information.
The messages sent by the server in response to an Active Leasequery The messages sent by the server in response to an Active Leasequery
skipping to change at page 7, line 8 skipping to change at page 7, line 21
to the requestor, based on OPTION_LQ_QUERY option (see to the requestor, based on OPTION_LQ_QUERY option (see
Section 6.2.1). Section 6.2.1).
An Active Leasequery connection does not ever "complete", though the An Active Leasequery connection does not ever "complete", though the
DHCPv6 server may drop the connection for a variety of reasons DHCPv6 server may drop the connection for a variety of reasons
associated with some sort of exception condition. associated with some sort of exception condition.
5. Extension to DHCPv6 Bulk Leasequery 5. Extension to DHCPv6 Bulk Leasequery
This document extends to the capabilities of DHCPv6 Bulk Leasequery This document extends to the capabilities of DHCPv6 Bulk Leasequery
protocol [RFC5460] by defining new options. More details about these protocol [RFC5460] by defining new options (OPTION_LQ_BASE_TIME,
options are specified in Section 6.3. OPTION_LQ_START_TIME and OPTION_LQ_END_TIME). DHCPv6 server sends
OPTION_LQ_BASE_TIME option in Bulk Leasequery response if requestor
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
DHCPv6 server. More details about these options are specified in
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 at a time. The receiver needs to be able
to determine how large each message is. The same message framing to determine how large each message is. The same message framing
technique used for DHCPv6 Bulk Leasequery [RFC5460] is used for technique used for DHCPv6 Bulk Leasequery [RFC5460] is used for
Active Leasequery as well. Active Leasequery as well.
skipping to change at page 7, line 32 skipping to change at page 7, line 50
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 a Active Leasequery exchange, a single LEASEQUERY-REPLY message is In an Active Leasequery exchange, a single LEASEQUERY-REPLY message
used to indicate the success or failure of a query, and to carry data is used to indicate the success or failure of a query, and to carry
that do not change in the context of a single query and answer, such data that do not change in the context of a single query and answer,
as the Server-ID and Client-ID options. If a query is successful, such as the Server-ID and Client-ID options. If a query is
only a single LEASEQUERY-REPLY message MUST appear. If the server is successful, only a single LEASEQUERY-REPLY message MUST appear. If
returning binding data, the LEASEQUERY-REPLY also contains the first the server is returning binding data, the LEASEQUERY-REPLY also
client's binding data in an OPTION_CLIENT_DATA option. Additional contains the first client's binding data in an OPTION_CLIENT_DATA
binding data is returned using LEASEQUERY-DATA message as explained option. Additional binding data is returned using LEASEQUERY-DATA
in DHCPv6 Bulk Leasequery [RFC5460]. In case of failure query, message as explained in DHCPv6 Bulk Leasequery [RFC5460]. In case of
single LEASEQUERY-REPLY message is returned without any binding data. failure query, single LEASEQUERY-REPLY message is returned without
any binding data.
6.2.1. ACTIVELEASEQUERY 6.2.1. ACTIVELEASEQUERY
The new message type (ACTIVELEASEQUERY) is designed to assist The new message type (ACTIVELEASEQUERY) is designed for keeping the
requestor keeping up to date in real-time (or near real-time) with requestor up to date in real-time (or near real-time) with DHCPv6
DHCPv6 bindings. It asks the server to return DHCPv6 bindings bindings. It asks the server to return DHCPv6 bindings activity that
activity that occurs subsequent to the receipt of the Active occurs subsequent to the receipt of the Active Leasequery request.
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 to the TCP connection to the
DHCPv6 server. DHCPv6 server.
While sending Active Leasequery request, requestor MAY include When sending an Active Leasequery request, the requestor MAY include
OPTION_LQ_START_TIME option in ACTIVELEASEQUERY request. In this the OPTION_LQ_START_TIME option in the ACTIVELEASEQUERY request. In
case, DHCPv6 server returns all the bindings changed on or after the this case, DHCPv6 server returns all the bindings changed on or after
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
DHCPv6 server, it MUST NOT include OPTION_LQ_QUERY option in the DHCPv6 server, it MUST NOT include the OPTION_LQ_QUERY option in
ACTIVELEASEQUERY message. But if the requestor is only interested in the ACTIVELEASEQUERY message. But if the requestor is only
specific binding updates, it MAY include OPTION_LQ_QUERY option along interested in specific binding updates, it MAY include an
with query-types defined in [RFC5007] and [RFC5460]. OPTION_LQ_QUERY option along with a query-types defined in [RFC5007]
and [RFC5460].
Other DHCPv6 options used in LEASEQUERY message (as specified in Other DHCPv6 options used in the LEASEQUERY message (as specified in
[RFC5460]) can also be used in ACTIVELEASEQUERY request. [RFC5460]) can also be used in the ACTIVELEASEQUERY request.
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]. DHCPv6 server sends OPTION_LQ_BASE_TIME option Leasequery [RFC5460]. The reply messages for Active Leasequery uses
in Active or Bulk Leasequery response if requestor ask for the same these options along with the options defined in [RFC3315], [RFC5007]
in Active or Bulk Leasequery request. OPTION_LQ_START_TIME can be and [RFC5460].
used in Active or Bulk Leasequery request made to DHCPv6 server.
OPTION_LQ_END_TIME can be used in Bulk Leasequery request made to
DHCPv6 server. The reply messages for Active Leasequery uses the
options defined in [RFC3315], [RFC5007] and [RFC5460].
6.3.1. OPTION_LQ_BASE_TIME 6.3.1. OPTION_LQ_BASE_TIME
The OPTION_LQ_BASE_TIME option is the current time the message was The OPTION_LQ_BASE_TIME option is the current time the message was
created to be sent by the DHCPv6 server to the requestor of the created to be sent by the DHCPv6 server to the requestor of the
Active or Bulk Leasequery. This MUST be an absolute time (i.e. Active or Bulk Leasequery if requestor ask for the same in Active or
seconds since midnight 1 Jan 2000 UTC modulo 2^32). All of the other Bulk Leasequery request. This MUST be an absolute time (i.e. seconds
time based options in the reply message are relative to this time, since midnight January 1, 2000 UTC). All of the other time based
including OPTION_CLT_TIME [RFC5007]. This time is in the context of options in the reply message are relative to this time, including
the DHCPv6 server who placed this option in a message. OPTION_CLT_TIME [RFC5007]. This time is in the context of the DHCPv6
server who placed this option in a message.
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 length of this option is 4 The code for this option is TBD.
octets.
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_BASE_TIME | option-len | | OPTION_LQ_BASE_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| base-time | | base-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_BASE_TIME (TBD). option-code OPTION_LQ_BASE_TIME (TBD).
option-len 4. option-len 4.
base-time DHCPv6 Server Base Time. base-time DHCPv6 Server Base Time.
skipping to change at page 9, line 20 skipping to change at page 9, line 37
option-code OPTION_LQ_BASE_TIME (TBD). option-code OPTION_LQ_BASE_TIME (TBD).
option-len 4. option-len 4.
base-time DHCPv6 Server Base Time. base-time DHCPv6 Server Base Time.
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. the query. This option MAY be used in Active or Bulk Leasequery
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.4).
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 length of this option is 4 The code for this option is TBD.
octets.
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_START_TIME | option-len | | OPTION_LQ_START_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| query-start-time | | query-start-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_START_TIME (TBD). option-code OPTION_LQ_START_TIME (TBD).
skipping to change at page 10, line 4 skipping to change at page 10, line 20
| OPTION_LQ_START_TIME | option-len | | OPTION_LQ_START_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| query-start-time | | query-start-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_START_TIME (TBD). option-code OPTION_LQ_START_TIME (TBD).
option-len 4. option-len 4.
query-start-time DHCPv6 Server Query Start Time. query-start-time DHCPv6 Server Query Start Time.
6.3.3. OPTION_LQ_END_TIME 6.3.3. OPTION_LQ_END_TIME
The OPTION_LQ_END_TIME option specifies a query end time to the The OPTION_LQ_END_TIME option specifies a query end 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
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 Bulk Leasequery request. But the query. This option MAY be used in a Bulk Leasequery request.
it MUST NOT be used in 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.4).
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 length of this option is 4 The code for this option is TBD.
octets.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| query-end-time | | query-end-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_END_TIME (TBD). option-code OPTION_LQ_END_TIME (TBD).
skipping to change at page 10, line 46 skipping to change at page 11, line 28
Active Leasequery uses the same port configuration as DHCPv6 Bulk Active Leasequery uses the same port configuration as DHCPv6 Bulk
Leasequery [RFC5460]. It also uses the other transmission parameters Leasequery [RFC5460]. It also uses the other transmission parameters
(BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [RFC5460]. (BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [RFC5460].
This section presents a table of values used to control Active This section presents a table of values used to control Active
Leasequery behavior, including recommended defaults. Implementations Leasequery behavior, including recommended defaults. Implementations
MAY make these values configurable. However, configuring too-small MAY make these values configurable. However, configuring too-small
timeout values may lead to harmful behavior both to this application timeout values may lead to harmful behavior both to this application
as well as to other traffic in the network. As a result, timeout as well as to other traffic in the network. As a result, timeout
values smaller than the default values are NOT RECOMMENDED. values smaller than the default values SHOULD NOT be used.
Parameter Default Description +------------------------+----------+-------------------------------+
---------------------------------------------------------------------- | Parameter | Default | Description |
ACTIVE_LQ_RCV_TIMEOUT 120 secs Active Leasequery receive timeout +------------------------+----------+-------------------------------+
ACTIVE_LQ_SEND_TIMEOUT 120 secs Active Leasequery send timeout | ACTIVE_LQ_RCV_TIMEOUT | 120 secs | Active Leasequery receive |
ACTIVE_LQ_IDLE_TIMEOUT 60 secs Active Leasequery idle timeout | | | timeout |
| ACTIVE_LQ_SEND_TIMEOUT | 120 secs | Active Leasequery send |
| | | timeout |
| ACTIVE_LQ_IDLE_TIMEOUT | 60 secs | Active Leasequery idle |
| | | timeout |
+------------------------+----------+-------------------------------+
7. Information Communicated by Active Leasequery 7. Information Communicated by Active Leasequery
While the information communicated by a DHCPv6 Bulk Leasequery While the information communicated by a DHCPv6 Bulk Leasequery
[RFC5460] is taken directly from the DHCPv6 server's lease state [RFC5460] is taken directly from the DHCPv6 server's lease state
database, the information communicated by an Active Leasequery is database, the information communicated by an Active Leasequery is
real-time information. As such, it is the information which is real-time information. As such, it is the information which is
currently associated with a particular binding in the DHCPv6 server's currently associated with a particular binding in the DHCPv6 server's
lease state database. lease state database.
This is of significance, because if the Active Leasequery requestor This is of significance, because if the Active Leasequery requestor
runs slowly or the requestor disconnects from the DHCPv6 server and runs slowly or the requestor disconnects from the DHCPv6 server and
then reconnects with a OPTION_LQ_START_TIME (signalling a catch-up then reconnects with an OPTION_LQ_START_TIME option (signaling a
operation), the information communicated to the Active Leasequery catch-up operation), the information communicated to the Active
requestor is only the most current information from the DHCPv6 Leasequery requestor is only the most current information from the
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 packet is created and handed
off to the TCP stack to send to the requestor. off to the TCP stack to send to the requestor.
If the TCP connection blocks and the 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
skipping to change at page 11, line 45 skipping to change at page 12, line 30
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 the receive timeout), so that an Active Leasequery requestor would be
never 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. Connecting and 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 a 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 a ACTIVELEASEQUERY request to a DHCPv6 server A requestor MAY send an ACTIVELEASEQUERY request to a DHCPv6 server
and immediately close the transmission side of its TCP connection, and immediately close the transmission side of its TCP connection,
and then read the resulting response messages from the DHCPv6 server. and then read the resulting response messages from the DHCPv6 server.
This is not required, and the usual approach is to leave both sides 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 of the TCP connection up until at least the conclusion of the Active
Leasequery. Leasequery.
8.2. Forming an Active Leasequery 8.2. 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
skipping to change at page 13, line 10 skipping to change at page 13, line 43
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 a 4 octet 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 will typically
keep track of the highest base-time received from a particular DHCPv6 keep 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 a OPTION_LQ_START_TIME will place this highest base-time value into an OPTION_LQ_START_TIME
option in the new Active Leasequery request. 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 does
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 be prepared
to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this
skipping to change at page 14, line 34 skipping to change at page 15, line 20
not related to the OPTION_LQ_BASE_TIME option value in the messages. not related to the OPTION_LQ_BASE_TIME option value in the messages.
Another way to say this is that the ordering of the updates sent by 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 DHCPv6 server during the catch-up phase is independent of the
ordering in the changes in the lease state data. The ordering in the changes in the lease state data. The
OPTION_LQ_BASE_TIME option from messages during this phase MUST NOT OPTION_LQ_BASE_TIME option from messages during this phase MUST NOT
be saved and used in a subsequent ACTIVELEASEQUERY message's be saved and used in a subsequent ACTIVELEASEQUERY message's
OPTION_LQ_START_TIME option as it does not represent the extent of OPTION_LQ_START_TIME option as it does not represent the extent of
progress of the catch-up activity. 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 a 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.
The LEASEQUERY-DONE message MAY unilaterally terminate a successful The LEASEQUERY-DONE message MAY unilaterally terminate a successful
Active Leasequery request which is currently in progress in the event Active Leasequery request which is currently in progress in the event
that the DHCPv6 server determines that it cannot continue processing that the DHCPv6 server determines that it cannot continue processing
skipping to change at page 15, line 11 skipping to change at page 15, line 44
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.3.1. Processing Replies from a Request Containing a
OPTION_LQ_START_TIME OPTION_LQ_START_TIME
If the Active Leasequery was requested with a OPTION_LQ_START_TIME, If the Active Leasequery was requested with an OPTION_LQ_START_TIME
the DHCPv6 server will attempt to send information about all bindings option, the DHCPv6 server will attempt to send information about all
that changed since the time specified in the OPTION_LQ_START_TIME. bindings that changed since the time specified in the
This is the catch-up phase of the Active Leasequery processing. The OPTION_LQ_START_TIME. This is the catch-up phase of the Active
DHCPv6 server MAY also begin immediate updates over the same Leasequery processing. The DHCPv6 server MAY also begin immediate
connection of real-time binding information changes. Thus, the updates over the same connection of real-time binding information
catch-up phase may run in parallel with the normal updates generated changes. Thus, the catch-up phase may run in parallel with the
by the Active Leasequery request. normal updates generated by the Active Leasequery request.
A DHCPv6 server MAY keep only a limited amount of time ordered A DHCPv6 server MAY keep only a limited amount of time ordered
information available to respond to an Active Leasequery request information available to respond to an Active Leasequery request
containing a OPTION_LQ_START_TIME. Thus, it is possible that the containing an OPTION_LQ_START_TIME option. Thus, it is possible that
time specified in the OPTION_LQ_START_TIME represents a time not the time specified in the OPTION_LQ_START_TIME option represents a
covered by the time ordered information kept by the DHCPv6 server. time not covered by the time ordered information kept by the DHCPv6
If this should occur, and there is not enough data saved in the server. If this should occur, and there is not enough data saved in
DHCPv6 server to satisfy the request specified by the the DHCPv6 server to satisfy the request specified by the
OPTION_LQ_START_TIME option, the DHCPv6 server will reply immediately OPTION_LQ_START_TIME option, the DHCPv6 server will reply immediately
with a LEASEQUERY-REPLY message with a DHCPv6 status code of with a LEASEQUERY-REPLY message with a DHCPv6 status code of
DataMissing with a base-time option equal to the server's current DataMissing 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 time. This will signal the end of the catch-up phase, and the only
updates that will subsequently be received on this connection are the updates that will subsequently be received on this connection are the
real-time updates from the Active Leasequery request. real-time updates from the Active Leasequery request.
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
skipping to change at page 16, line 51 skipping to change at page 17, line 36
requestor MUST NOT assume that every intermediate state change that requestor MUST NOT assume that every intermediate state change 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 will be represented by an individual Leasequery message. 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, set to be the same as its include a OPTION_LQ_START_TIME option with the same value as the
OPTION_LQ_START_TIME previously included in the ACTIVELEASEQUERY OPTION_LQ_START_TIME option previously included in the
responses from the DHCPv6 server, and a OPTION_LQ_END_TIME equal to ACTIVELEASEQUERY responses from the DHCPv6 server, and an
the OPTION_LQ_BASE_TIME returned by the DHCPv6 server in the OPTION_LQ_END_TIME option equal to the OPTION_LQ_BASE_TIME option
LEASEQUERY-REPLY or LEASEQUERY-DATA message with the DHCPv6 status returned by the DHCPv6 server in the LEASEQUERY-REPLY or LEASEQUERY-
code of DataMissing. DATA message with the DHCPv6 status code of DataMissing.
In the event that the requestor receives a LEASEQUERY-REPLY or In the event that the requestor receives a LEASEQUERY-REPLY or
LEASEQUERY-DATA message with a DHCPv6 status code of DataMissing, it LEASEQUERY-DATA message with a DHCPv6 status code of DataMissing, it
is a reasonable assumption that it is interested in keeping its is a reasonable assumption that it is interested in keeping its
database up to date with respect to the DHCPv6 server's internal database up to date with respect to the DHCPv6 server's internal
binding database or it would not have included the binding database or it would not have included the
OPTION_LQ_START_TIME in the ACTIVELEASEQUERY message. 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 a 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.4. 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 a 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.
When receiving a Active or Bulk Leasequery reply message from the When receiving an Active or Bulk Leasequery reply message from the
DHCPv6 server, the message will contain a OPTION_LQ_BASE_TIME option. DHCPv6 server, the message will contain an OPTION_LQ_BASE_TIME
The time contained in this OPTION_LQ_BASE_TIME option is in the option. The time contained in this OPTION_LQ_BASE_TIME option is in
context of the DHCPv6 server. As such, it is an ideal time to save the context of the DHCPv6 server. As such, it is an ideal time to
and use as input to an Active or Bulk Leasequery message in the save and use as input to an Active or Bulk Leasequery message in the
OPTION_LQ_START_TIME or OPTION_LQ_END_TIME option, should the OPTION_LQ_START_TIME or OPTION_LQ_END_TIME option, should the
requestor need to ever issue an Active or Bulk Leasequery message requestor need to ever issue an Active or Bulk Leasequery message
using these option as part of a later query, since these option using these option as part of a later query, since these option
requires a time in the context of the DHCPv6 server. requires a time in the context of the DHCPv6 server.
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.
skipping to change at page 18, line 24 skipping to change at page 19, line 8
8.5. Examples 8.5. 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.5.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 can not 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).
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.5.2. Data Missing on Server
skipping to change at page 19, line 43 skipping to change at page 20, line 27
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] as well. Bulk Leasequery [RFC5460] and as extended herein.
9.1. Accepting Connections 9.1. Accepting Connections
Servers that implement DHCPv6 Active Leasequery listen for incoming Servers that implement DHCPv6 Active Leasequery listen for incoming
TCP connections. Approach used in accepting (or rejecting) the TCP connections. Approach used in accepting (or rejecting) the
requestor connection is same as specified in DHCPv6 Bulk Leasequery requestor connection is same as specified in DHCPv6 Bulk Leasequery
[RFC5460]. [RFC5460].
9.2. Replying to an Active Leasequery 9.2. Replying to an Active Leasequery
skipping to change at page 20, line 25 skipping to change at page 21, line 8
TCP connection after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs TCP connection after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs
how much congestion the DHCPv6 server is prepared to tolerate over how much congestion the DHCPv6 server is prepared to tolerate over
any Active Leasequery connection. The default is two minutes, which any Active Leasequery connection. The default is two minutes, which
means that if more than two minutes goes by without the requestor means that if more than two minutes goes by without the requestor
reading enough information to unblock the TCP connection, the DHCPv6 reading enough information to unblock the TCP connection, the DHCPv6
server will drop the TCP connection. server will 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 option. It SHOULD close the connection after this error is signaled.
signalled.
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 signalled. 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 sends each
binding's data in a reply message. The first reply message is a 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 returns subsequent bindings in LEASEQUERY-DATA messages, which can
avoid redundant data (such as the requestor's Client-ID). avoid redundant data (such as the requestor's Client-ID).
Every reply to a 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].
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 a 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 a 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 a 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.
These replies based on the OPTION_LQ_START_TIME MAY be interleaved These replies based on the OPTION_LQ_START_TIME MAY be interleaved
with the messages generated due to current binding activity. with the messages generated due to current binding activity.
Once the transmission of the DHCPv6 Leasequery messages associated Once the transmission of the DHCPv6 Leasequery messages associated
with the OPTION_LQ_START_TIME option are complete, a LEASEQUERY-DATA with the OPTION_LQ_START_TIME option are complete, a LEASEQUERY-DATA
message MUST be sent with a DHCPv6 status code value of message MUST be sent with a DHCPv6 status code value of
skipping to change at page 22, line 13 skipping to change at page 22, line 39
requestor or the server drops the connection. requestor or the server drops the connection.
9.3. Multiple or Parallel Queries 9.3. 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 a 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
skipping to change at page 23, line 39 skipping to change at page 24, line 18
access in any environment where Active Leasequery is deployed. 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 disruption and malicious corruption of Active Leasequery To prevent interception, disruption and malicious corruption of
data flows between the server and authorized requestors these data Active Leasequery data flows between the server and authorized
flows SHOULD transit only secured networks. These data flows are requestors these data flows SHOULD transit only secured networks.
typically infrastructure oriented, and there is usually no reason to These data flows are typically infrastructure oriented, and there is
have them flowing over networks where such attacks are likely. In usually no reason to have them flowing over networks where such
the rare cases where these data flows might need to be sent through attacks are likely. In the rare cases where these data flows might
unsecured networks, they MUST sent over connections secured through need to be sent through unsecured networks, they MUST be sent over
means external to the DHCPv4/DHCPv6 server and its requestor(s) connections secured through means external to the DHCPv4/DHCPv6
(e.g., through VPN's). 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:
 End of changes. 64 change blocks. 
153 lines changed or deleted 166 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/