draft-ietf-dhc-dhcpv6-active-leasequery-03.txt   draft-ietf-dhc-dhcpv6-active-leasequery-04.txt 
DHC Working Group D. Raghuvanshi DHC Working Group D. Raghuvanshi
Internet-Draft K. Kinnear Internet-Draft K. Kinnear
Updates: 5460 (if approved) D. Kukrety Updates: 5460 (if approved) D. Kukrety
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: December 11, 2015 June 9, 2015 Expires: February 1, 2016 July 31, 2015
DHCPv6 Active Leasequery DHCPv6 Active Leasequery
draft-ietf-dhc-dhcpv6-active-leasequery-03 draft-ietf-dhc-dhcpv6-active-leasequery-04
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
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 December 11, 2015. This Internet-Draft will expire on February 1, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Interaction Between Active Leasequery and Bulk Leasequery . . 7 4. Interaction Between Active Leasequery and Bulk Leasequery . . 7
5. Extension to DHCPv6 Bulk Leasequery . . . . . . . . . . . . . 8 5. Extension to DHCPv6 Bulk Leasequery . . . . . . . . . . . . . 8
6. Message and Option Definitions . . . . . . . . . . . . . . . 8 6. Message and Option Definitions . . . . . . . . . . . . . . . 8
6.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 8 6.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 8
6.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2.1. ACTIVELEASEQUERY . . . . . . . . . . . . . . . . . . 8 6.2.1. ACTIVELEASEQUERY . . . . . . . . . . . . . . . . . . 8
6.2.2. STARTTLS . . . . . . . . . . . . . . . . . . . . . . 9 6.2.2. STARTTLS . . . . . . . . . . . . . . . . . . . . . . 9
6.2.3. Response Messages . . . . . . . . . . . . . . . . . . 9 6.2.3. Response Messages . . . . . . . . . . . . . . . . . . 9
6.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3.1. OPTION_LQ_BASE_TIME . . . . . . . . . . . . . . . . . 9 6.3.1. OPTION_LQ_BASE_TIME . . . . . . . . . . . . . . . . . 10
6.3.2. OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 10 6.3.2. OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 10
6.3.3. OPTION_LQ_END_TIME . . . . . . . . . . . . . . . . . 11 6.3.3. OPTION_LQ_END_TIME . . . . . . . . . . . . . . . . . 11
6.4. Connection and Transmission Parameters . . . . . . . . . 12 6.4. Connection and Transmission Parameters . . . . . . . . . 12
7. Information Communicated by Active Leasequery . . . . . . . . 12 7. Information Communicated by Active Leasequery . . . . . . . . 12
8. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 13 8. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 13
8.1. General Processing . . . . . . . . . . . . . . . . . . . 13 8.1. General Processing . . . . . . . . . . . . . . . . . . . 13
8.2. Initiating a Connection . . . . . . . . . . . . . . . . . 13 8.2. Initiating a Connection . . . . . . . . . . . . . . . . . 14
8.3. Forming an Active Leasequery . . . . . . . . . . . . . . 14 8.3. Forming an Active Leasequery . . . . . . . . . . . . . . 15
8.4. Processing Active Replies . . . . . . . . . . . . . . . . 15 8.4. Processing Active Replies . . . . . . . . . . . . . . . . 16
8.4.1. Processing Replies from a Request Containing a 8.4.1. Processing Replies from a Request Containing a
OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 17 OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 17
8.5. Processing Time Values in Leasequery messages . . . . . . 19 8.5. Processing Time Values in Leasequery messages . . . . . . 20
8.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 20 8.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 20
8.6.1. Query Failure . . . . . . . . . . . . . . . . . . . . 20 8.6.1. Query Failure . . . . . . . . . . . . . . . . . . . . 20
8.6.2. Data Missing on Server . . . . . . . . . . . . . . . 20 8.6.2. Data Missing on Server . . . . . . . . . . . . . . . 21
8.6.3. Successful Query . . . . . . . . . . . . . . . . . . 21 8.6.3. Successful Query . . . . . . . . . . . . . . . . . . 21
8.7. Closing Connections . . . . . . . . . . . . . . . . . . . 21 8.7. Closing Connections . . . . . . . . . . . . . . . . . . . 22
9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 22 9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Accepting Connections . . . . . . . . . . . . . . . . . . 22 9.1. Accepting Connections . . . . . . . . . . . . . . . . . . 22
9.2. Rejecting Connections . . . . . . . . . . . . . . . . . . 23 9.2. Rejecting Connections . . . . . . . . . . . . . . . . . . 24
9.3. Replying to an Active Leasequery . . . . . . . . . . . . 23 9.3. Replying to an Active Leasequery . . . . . . . . . . . . 24
9.4. Multiple or Parallel Queries . . . . . . . . . . . . . . 25 9.4. Multiple or Parallel Queries . . . . . . . . . . . . . . 26
9.5. Closing Connections . . . . . . . . . . . . . . . . . . . 25 9.5. Closing Connections . . . . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
13. Modification History . . . . . . . . . . . . . . . . . . . . 27 13. Modification History . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
14.1. Normative References . . . . . . . . . . . . . . . . . . 27 14.1. Normative References . . . . . . . . . . . . . . . . . . 28
14.2. Informative References . . . . . . . . . . . . . . . . . 27 14.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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 38 skipping to change at page 3, line 38
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 This document updates DHCPv6 Bulk Leasequery [RFC5460] by adding new
options, as described in Section 6.2.1. For the DHCPv6 servers, options, as described in Section 6.2.1. For DHCPv6 servers,
supporting Bulk Leasequery and not Active Leasequery, Section 9.2 supporting Bulk Leasequery and not Active Leasequery, Section 9.2
specifies the mechanism to reject incoming Active Leasequery specifies the mechanism to reject incoming Active Leasequery
requests. 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].
skipping to change at page 6, line 15 skipping to change at page 6, line 15
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
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 similar to the
[RFC5460], except that in the case of Active Leasequery the server procedure specified in [RFC5460], except that in the case of Active
sends updates whenever some activity occurs to change the binding Leasequery the server sends updates whenever some activity occurs to
state - thus the need for long lived connection. change the binding state - thus the need for long lived connection.
Additionally, the Active Leasequery server SHOULD provide a mechanism
to control which data is allowed to be included in the
OPTION_CLIENT_DATA messages sent to the requestor. See Section 9.3.
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 features are designed to allow the Active Leasequery requestor These features are designed to allow the Active Leasequery requestor
to efficiently become current with respect to the lease state to efficiently become current with respect to the lease state
database after it has been restarted or the machine on which it is database after it has been restarted or the machine on which it is
running has been reinitialized. It is easy to define a protocol running has been reinitialized. It is easy to define a protocol
skipping to change at page 6, line 42 skipping to change at page 6, line 45
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 the DHCPv6 server from which it is receiving updates and then
reconnects 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 data was missed - not all 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
should 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
skipping to change at page 7, line 25 skipping to change at page 7, line 30
The messages sent by the server in response to an Active Leasequery The messages sent by the server in response to an Active Leasequery
request should be identical to the messages sent by the server to a request should be identical to the messages sent by the server to a
Bulk Leasequery request regarding the way the data is encoded into Bulk Leasequery request regarding the way the data is encoded into
the Active Leasequery responses. In addition, the actions taken by the Active Leasequery responses. In addition, the actions taken by
the Active Leasequery requestor to interpret the responses to an the Active Leasequery requestor to interpret the responses to an
Active Leasequery request should be identical to the way that the Active Leasequery request should be identical to the way that the
requestor interprets the responses to a Bulk Leasequery request. requestor interprets the responses to a Bulk Leasequery request.
Thus, the handling of 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, with the exception that
a server responding to an Active Leasequery request SHOULD be able to
be configured to prevent specific data items from being included in
the OPTION_CLIENT_DATA option even if they were requested by
inclusion in the OPTION_ORO option.
4. Interaction Between Active Leasequery and Bulk Leasequery 4. Interaction Between Active Leasequery and Bulk Leasequery
Active Leasequery is an extension of the Bulk Leasequery protocol Active Leasequery is an extension of the Bulk Leasequery protocol
[RFC5460]. The format of messages returned to an Active Leasequery [RFC5460]. The format of messages returned to an Active Leasequery
requestor are identical to that defined for the Bulk Leasequery requestor are identical to that defined for the Bulk Leasequery
protocol [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 should date with respect to the DHCPv6 server's lease state database should
skipping to change at page 7, line 49 skipping to change at page 8, line 9
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
(ACTIVELEASEQUERY) to send Active Leasequery request to DHCPv6 (ACTIVELEASEQUERY) to send Active Leasequery request to DHCPv6
server. An Active Leasequery connection sends all available updates server. An Active Leasequery connection sends all available updates
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 can close 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 (OPTION_LQ_BASE_TIME, protocol [RFC5460] by defining new options (OPTION_LQ_BASE_TIME,
OPTION_LQ_START_TIME and OPTION_LQ_END_TIME). DHCPv6 server sends OPTION_LQ_START_TIME and OPTION_LQ_END_TIME). DHCPv6 server sends
OPTION_LQ_BASE_TIME option in Bulk Leasequery response if requestor OPTION_LQ_BASE_TIME option in Bulk Leasequery response if requestor
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
skipping to change at page 8, line 31 skipping to change at page 8, line 38
DHCPv6 messages to be sent in response to single Active Leasequery DHCPv6 messages to be sent in response to single Active Leasequery
request. The receiver needs to be able to determine how large each request. The receiver needs to be able to determine how large each
message is. The same message framing technique used for DHCPv6 Bulk message is. The same message framing technique used for DHCPv6 Bulk
Leasequery [RFC5460] is used for 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.
When using TLS to secure a connection [RFC5246], the message framing
for TLS uses the same format as that used for TCP. One DHCP message
is carried in one TLS record.
6.2. Messages 6.2. Messages
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 on the TCP connection on which transaction-id MUST be locally unique on the TCP connection on which
it is sent to the 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 6.2.2. STARTTLS
The new message type (STARTTLS) is designed for establishment of a The new message type (STARTTLS) is designed for establishment of a
TLS connection between requestor and DHCPv6 server. TLS connection between a requestor and a DHCPv6 server. The STARTTLS
message SHOULD be sent without any options. Any options received in
a STARTTLS message SHOULD be ignored./
More details about this message are specified in Section 8.2. More details about this message are specified in Section 8.2.
6.2.3. Response Messages 6.2.3. Response 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
skipping to change at page 9, line 48 skipping to change at page 10, line 18
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
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 if requestor ask for the same in Active or Active or Bulk Leasequery if requestor ask for the same in Active or
Bulk Leasequery request. This MUST be an absolute time (i.e. seconds Bulk Leasequery request. This MUST be an absolute time (i.e.,
since midnight January 1, 2000 UTC). All of the other time based seconds since midnight January 1, 2000 UTC). All of the other time
options in the reply message are relative to this time, including based options in the reply message are relative to this time,
OPTION_CLT_TIME [RFC5007]. This time is in the context of the DHCPv6 including OPTION_CLT_TIME [RFC5007]. This time is in the context of
server who placed this option in a message. 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 code for this option is TBD-1.
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-1).
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. 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.
skipping to change at page 10, line 42 skipping to change at page 11, line 12
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.5). 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-2.
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-2).
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 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.
skipping to change at page 11, line 35 skipping to change at page 11, line 44
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.5). 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-3.
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-3).
option-len 4. option-len 4.
query-end-time DHCPv6 Server Query End Time. query-end-time DHCPv6 Server Query End Time.
6.4. Connection and Transmission Parameters 6.4. Connection and Transmission Parameters
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
skipping to change at page 13, line 49 skipping to change at page 14, line 12
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.
8.2. Initiating a Connection 8.2. Initiating a Connection
A Requestor SHOULD be able to operate in either insecure or secure A Requestor SHOULD be able to operate in either insecure or secure
mode. This MAY be a feature that is administratively controlled. mode. This MAY be a feature that is administratively controlled.
When operating in insecure mode, requestor should proceed with the When operating in insecure mode, the requestor SHOULD proceed to send
Active Leasequery request after the establishment of a TCP an ACTIVELEASEQUERY message after the establishment of a TCP
connection. connection.
When operating in secure mode, requestor MUST attempt to negotiate a When operating in secure mode, the requestor MUST attempt to
TLS [RFC5246] connection over the TCP connection. If this negotiate a TLS [RFC5246] connection over the TCP connection. If
negotiation fails, the requestor MUST drop the TCP connection. this negotiation fails, the requestor MUST close the TCP connection.
The recommendations in [RFC7525] SHOULD be followed when negotiating
this connection.
A requestor requests the establishment of a TLS connection by sending A requestor requests the establishment of a TLS connection by sending
the STARTTLS message to the DHCPv6 server as the first message over the STARTTLS message to the DHCPv6 server as the first message over
the TCP connection. This message indicates to the DHCPv6 server that the TCP connection. This message indicates to the DHCPv6 server that
a TLS connection over this TCP connection is desired. There are four a TLS connection over this TCP connection is desired. There are four
possibilities after the requestor sends the STARTTLS message to the possibilities after the requestor sends the STARTTLS message to the
DHCPv6 server: DHCPv6 server:
1. No response from the DHCPv6 server. 1. No response from the DHCPv6 server.
2. The DHCPv6 server drops the TCP connection after it receives the 2. The DHCPv6 server closes the TCP connection after it receives the
STARTTLS message. STARTTLS message.
3. DHCPv6 server responds with REPLY [RFC3315] message with DHCPv6 3. DHCPv6 server responds with REPLY [RFC3315] message with DHCPv6
status code of TLSConnectionRefused. status code of TLSConnectionRefused.
4. DHCPv6 server responds with REPLY [RFC3315] message without 4. DHCPv6 server responds with REPLY [RFC3315] message without
DHCPv6 status code, indicating success. DHCPv6 status code, indicating success.
In any of the first three possibilities, the DHCPv6 server can be In any of the first three possibilities, the DHCPv6 server can be
assumed to not support TLS. In this case, the requestor MUST drop assumed to not support TLS. In this case, the requestor MUST close
the TCP connection. the TCP connection.
In the final possibility, where the DHCPv6 server has responded with In the final possibility, where the DHCPv6 server has responded with
a REPLY message without DHCPv6 status code in response to the a REPLY message without DHCPv6 status code in response to the
requestor's STARTTLS message, the requestor SHOULD initiate the requestor's STARTTLS message, the requestor SHOULD initiate the
exchange of the messages involved in a TLS handshake [RFC5246]. exchange of the messages involved in a TLS handshake [RFC5246].
During the TLS handshake, the requestor MUST verify DHCPv6 server's During the TLS handshake, the requestor MUST validate the DHCPv6
digital certificate. server's digital certificate.
If the handshake exchange yields a functioning TLS connection, then If the handshake exchange yields a functioning TLS connection, then
the requestor SHOULD transmit an Active Leasequery message over that the requestor SHOULD transmit an ACTIVELEASEQUERY request over that
TLS connection and use that TLS connection for all further TLS connection and use that TLS connection for all further
interactions in which it engages with the DHCPv6 server over this TCP interactions in which it engages with the DHCPv6 server over this TCP
connection. connection.
If the handshake exchange does not yield a functioning TLS If the handshake exchange does not yield a functioning TLS
connection, then the requestor MUST drop the TCP connection. connection, then the requestor MUST close the TCP connection.
8.3. Forming an Active Leasequery 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 SHOULD 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 learns about bindings either because it makes the information. It learns about bindings either because it makes 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.
skipping to change at page 15, line 40 skipping to change at page 16, line 8
OPTION_LQ_START_TIME 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 SHOULD 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 terminate the requestor is sending its query, the requestor SHOULD 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 requestors 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.4. 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 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.
skipping to change at page 16, line 19 skipping to change at page 16, line 34
OPTION_STATUS_CODE option), the requestor should follow the OPTION_STATUS_CODE option), the requestor should follow the
recommendations 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 SHOULD 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
skipping to change at page 17, line 14 skipping to change at page 17, line 29
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
an ACTIVELEASEQUERY request. For example, when a server is requested an 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.4.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 can run in parallel with the
normal updates generated 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 an OPTION_LQ_START_TIME option. Thus, it is possible that containing an OPTION_LQ_START_TIME option. Thus, it is possible that
the time specified in the OPTION_LQ_START_TIME option represents a the time specified in the OPTION_LQ_START_TIME option represents a
time not covered by the time ordered information kept by the DHCPv6 time not covered by the time ordered information kept by the DHCPv6
server. If this should occur, and there is not enough data saved in server. In such case, when there is not enough data saved in the
the DHCPv6 server to satisfy the request specified by 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 18, line 50 skipping to change at page 19, line 17
LEASEQUERY-DATA message with a DHCPv6 status code of DataMissing and LEASEQUERY-DATA message with a DHCPv6 status code of DataMissing and
with a base-time option of the current time. with a base-time option of the current time.
The requestor MUST NOT assume that every individual state change of The requestor MUST NOT assume that every individual state change of
every 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 can 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.
Bindings can change multiple times while the requester was not Bindings can change multiple times while the requestor was not
connected (that is, during the time from the OPTION_LQ_START_TIME and connected (that is, during the time from the OPTION_LQ_START_TIME and
the present). The requestor will only receive information about the the present). The requestor will only receive information about the
current state of the binding, not information about each state change current state of the binding, not information about each state change
that occurred during the period from the OPTION_LQ_START_TIME to the that occurred during the period from the OPTION_LQ_START_TIME to the
present. present.
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.
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.
both requests could be issued over a single connection.
8.5. 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 can 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.
When receiving an Active or Bulk Leasequery reply message from the When receiving an Active or Bulk Leasequery reply message from the
skipping to change at page 20, line 31 skipping to change at page 20, line 48
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.6.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). NotSupported).
Client Server Client Server
------ ------ ------ ------
ACTIVELEASEQUERY xid 1 -----> ACTIVELEASEQUERY xid 1 ----->
<----- LEASEQUERY-REPLY xid 1 (w/error) <----- LEASEQUERY-REPLY xid 1 (w/error)
8.6.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
skipping to change at page 22, line 13 skipping to change at page 22, line 32
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
DHCPv6 servers that implement DHCPv6 Active Leasequery listen for DHCPv6 servers that implement DHCPv6 Active Leasequery listen for
incoming TCP connections. Approach used in accepting the requestor incoming TCP connections. The approach used in accepting the
connection is same as specified in DHCPv6 Bulk Leasequery [RFC5460]. requestor's connection is same as specified in DHCPv6 Bulk Leasequery
[RFC5460], with the exception that support for Active Leasequery MUST
NOT be enabled by default, and MUST require an explicit configuration
step to be performed before it will operate.
DHCPv6 servers SHOULD be able to operate in either insecure or secure DHCPv6 servers SHOULD be able to operate in either insecure or secure
mode. This MAY be a mode that is administratively controlled, where mode. This MAY be a mode that is administratively controlled, where
the server will require a TLS connection to operate or will only the server will require a TLS connection to operate or will only
operate without a TLS connection. operate without a TLS connection. In either case, operation in
insecure mode MUST NOT be the default, even if operation in secure
mode is not supported. Operation in insecure mode MUST always
require an explicit configuration step, separate from the
configuration step required to enable support for Active Leasequery.
When operating in insecure mode, DHCPv6 server simply waits for the When operating in insecure mode, the DHCPv6 server simply waits for
requestor to send the Active Leasequery request after the the requestor to send the Active Leasequery request after the
establishment of TCP connection. If it receives a STARTTLS message, establishment of TCP connection. If it receives a STARTTLS message,
it MUST respond with REPLY [RFC3315] message with DHCPv6 status code it MUST respond with REPLY [RFC3315] message with DHCPv6 status code
of TLSConnectionRefused. of TLSConnectionRefused.
When operating in secure mode, DHCPv6 servers MUST support TLS When operating in secure mode, DHCPv6 servers MUST support TLS
[RFC5246] to protect the integrity and privacy of the data [RFC5246] to protect the integrity and privacy of the data
transmitted over the TCP connection. DHCPv6 servers SHOULD negotiate transmitted over the TCP connection. When operating in secure mode,
a TLS connection with the requestor who asks for one, and MUST drop DHCPv6 servers MUST be configurable with regard to which requestors
the TCP connections which are not secured with TLS. they will communicate. The certificate presented by a requestor when
initiating the TLS connection is used to distinguish between
acceptable and unacceptable requestors.
When operating in secure mode, DHCPv6 server MUST begin to negotiate
a TLS connection with a requestor who asks for one, and MUST close he
TCP connections which are not secured with TLS or for which the
requestor's certificate is deemed unacceptable. The recommendations
in [RFC7525] SHOULD be followed when negotiating a TLS connection.
A requestor will request a TLS connection by sending a STARTTLS as A requestor will request a TLS connection by sending a STARTTLS as
the first message over a newly created TCP connection. If the DHCPv6 the first message over a newly created TCP connection. If the DHCPv6
server supports TLS connections and has not been configured to not server supports TLS connections and has not been configured to not
allow them on this link, the DHCPv6 server SHOULD respond to this allow them on this link, the DHCPv6 server MUST respond to this
STARTTLS message by sending a REPLY [RFC3315] message without DHCPv6 STARTTLS message by sending a REPLY [RFC3315] message without DHCPv6
status code back to the requestor. This indicates to the requestor status code back to the requestor. This indicates to the requestor
that the DHCPv6 server will support the negotiation of a TLS that the DHCPv6 server will support the negotiation of a TLS
connection over this existing TCP connection. connection over this existing TCP connection.
If for some reason the DHCPv6 server cannot or has been configured to 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 not support a TLS connection, then it SHOULD send a REPLY message
with DHCPv6 status code of TLSConnectionRefused back to the with DHCPv6 status code of TLSConnectionRefused back to the
requestor. requestor.
In the event that the DHCPv6 server sends a REPLY message without In the event that the DHCPv6 server sends a REPLY message without
DHCPv6 status code option included (which indicates success), the DHCPv6 status code option included (which indicates success), the
requestor is supposed to initiate a TLS handshake [RFC5246] (see requestor is supposed to initiate a TLS handshake [RFC5246] (see
Section 8.2). During the TLS handshake, the DHCPv6 server MUST Section 8.2). During the TLS handshake, the DHCPv6 server MUST
verify the requestor's digital certificate. validate the requestor's digital certificate. In addition, the
digital certificate presented by the requestor is used to decide if
this requestor is allowed to perform an Active Leasequery. If this
requestor's certificate is deemed unacceptable, the server MUST abort
the creation of the TLS connection.
All TLS connections established between the a requestor and a DHCPv6
server for the purposes of supporting Active Leasequery MUST be
mutually authenticated.
If the TLS handshake is not successful in creating a TLS connection, If the TLS handshake is not successful in creating a TLS connection,
the server MUST drop the TCP connection. the server MUST close the TCP connection.
9.2. Rejecting Connections 9.2. Rejecting Connections
Servers that do not implement DHCPv6 Active and Bulk Leasequery Servers that do not implement DHCPv6 Active and Bulk Leasequery
SHOULD NOT listen for incoming TCP connections for these requests. SHOULD NOT listen for incoming TCP connections for these requests.
If the DHCPv6 server supporting Bulk Leasequery and not Active If the DHCPv6 server supporting Bulk Leasequery and not Active
Leasequery receives an Active Leasequery request, it SHOULD send a Leasequery receives an Active Leasequery request, it SHOULD send a
LEASEQUERY-REPLY with DHCPv6 status code as NotSupported. It SHOULD LEASEQUERY-REPLY with DHCPv6 status code as NotSupported. It SHOULD
close the TCP connection after this error is signaled. close the TCP connection after this error is signaled.
skipping to change at page 23, line 33 skipping to change at page 24, line 30
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 terminate the TCP connection send reply messages, the server SHOULD terminate the TCP connection
after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs for how long the after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs for how long the
DHCPv6 server is prepared to wait for the requestor to read and DHCPv6 server is prepared to wait for the requestor to read and
process enough information to unblock the TCP connection. The process enough information to unblock the TCP connection. The
default is two minutes, which means that if more than two minutes default is two minutes, which means that if more than two minutes
goes by without the requestor reading enough information to unblock goes by without the requestor reading enough information to unblock
the TCP connection, the DHCPv6 server SHOULD drop the TCP connection. the TCP connection, the DHCPv6 server SHOULD close 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 SHOULD send If the server finds any bindings satisfying a query, it SHOULD send
each 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
SHOULD send subsequent bindings in LEASEQUERY-DATA messages, which SHOULD send subsequent bindings in LEASEQUERY-DATA messages, which
can 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], with the exception that a server implementing Active
Leasequery SHOULD be able to be configured to prevent specific data
items from being sent to the requestor even if these data items were
requested in the OPITON_ORO option.
Some servers can be configured to respond to a DHCPv6 Leasequery Some servers can be configured to respond to a DHCPv6 Leasequery
[RFC5007] and DHCPv6 Bulk Leasequery [RFC5460] for an IPv6 binding [RFC5007] and DHCPv6 Bulk Leasequery [RFC5460] for an IPv6 binding
which is reserved in such a way that it appears that the 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 is leased to the DHCP client for which it is reserved. These servers
SHOULD also respond to an Active Leasequery request with the same SHOULD also respond to an Active Leasequery request with the same
information as they would to a Bulk Leasequery request when they information as they would to a Bulk Leasequery request when they
first determine that the IPv6 binding is reserved to a DHCP client. 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
skipping to change at page 25, line 18 skipping to change at page 26, line 18
The DHCPv6 server SHOULD make the amount of previous binding activity The DHCPv6 server SHOULD make the amount of previous binding activity
it retains configurable. There is no requirement on the DHCPv6 it retains configurable. There is no requirement on the DHCPv6
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 closes the connection.
9.4. Multiple or Parallel Queries 9.4. Multiple or Parallel Queries
Every Active Leasequery request MUST be made on a single TCP Every Active Leasequery request MUST be made on a single TCP
connection where there is no other request active at the time the connection where there is no other request active at the time the
request is made. request is made.
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 in parallel would sending an Active Leasequery and a Bulk Leasequery in parallel would
be possible and reasonable. In case of parallel Active and Bulk be possible and reasonable. In case of parallel Active and Bulk
Leasequeries, requestor MUST use different TCP connections. Leasequeries, the requestor MUST use different TCP connections.
This MAY be a feature that is administratively controlled. Servers This MAY be a feature that is administratively controlled. Servers
that are able to process queries in parallel SHOULD offer that are able to process queries in parallel SHOULD offer
configuration that limits the number of simultaneous queries configuration that limits the number of simultaneous queries
permitted from any one requestor, in order to control resource use if permitted from any one requestor, in order to control resource use if
there are multiple requesters seeking service. there are multiple requestors seeking service.
9.5. 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
skipping to change at page 26, line 20 skipping to change at page 27, line 20
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].
The use of TCP introduces some additional concerns. Attacks that The use of TCP introduces some additional concerns. Attacks that
attempt to exhaust the DHCPv6 server's available TCP connection attempt to exhaust the DHCPv6 server's available TCP connection
resources can compromise the ability of legitimate requestors to resources can compromise the ability of legitimate requestors to
receive service. Malicious requestors who succeed in establishing receive service. Malicious requestors who succeed in establishing
connections, but who then send invalid queries, partial queries, or connections, but who then send invalid queries, partial queries, or
no queries at all also can exhaust a server's pool of available no queries at all also can exhaust a server's pool of available
connections. We recommend that servers offer configuration to limit connections.
the sources of incoming connections, that they limit the number of
accepted connections, and that they limit the period of time during When operating in secure mode, TLS [RFC5246] is used to secure the
which an idle connection will be left open. connection. The recommendations in [RFC7525] SHOULD be followed when
negotiating a TLS connection.
Servers SHOULD offer configuration parameters to limit the sources of
incoming connections through validation and use of the digital
certificates presented to create a TLS connection. They SHOULD also
limit the number of accepted connections, and limit the period of
time during which an idle connection will be left open.
The data acquired by using an Active Leasequery is subject to the
same potential abuse as the data held by the DHCPv6 server from which
it was acquired, and SHOULD be secured by mechanisms as strong as
those used for the data held by that DHCPv6 server. The data
acquired by using an Active Leasequery SHOULD be deleted as soon as
possible after the use for which it was acquired has passed.
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:
OPTION_LQ_BASE_TIME OPTION_LQ_BASE_TIME TBD-1
OPTION_LQ_START_TIME OPTION_LQ_START_TIME TBD-2
OPTION_LQ_END_TIME OPTION_LQ_END_TIME TBD-3
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 NotSupported
skipping to change at page 27, line 13 skipping to change at page 28, line 25
TLSConnectionRefused TLSConnectionRefused
IANA is requested to assign values for the following new DHCPv6 IANA is requested to assign values for the following new DHCPv6
Message types in the registry maintained in Message types in the registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters: http://www.iana.org/assignments/dhcpv6-parameters:
ACTIVELEASEQUERY ACTIVELEASEQUERY
STARTTLS STARTTLS
12. Acknowledgements 12. Acknowledgments
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.
Useful review comments were provided by Scott Bradner, Francis
Dupont, and Stephen Farrell. The privacy protections were
substantially upgraded due to these comments and discussions.
13. Modification History 13. Modification History
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration Protocol
IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[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. DOI 10.17487/RFC3633, December 2003,
<http://www.rfc-editor.org/info/rfc3633>.
[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, DOI 10.17487/RFC5007,
September 2007, <http://www.rfc-editor.org/info/rfc5007>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
2009. DOI 10.17487/RFC5460, February 2009,
<http://www.rfc-editor.org/info/rfc5460>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
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, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
Zimmermann, "A Roadmap for Transmission Control Protocol Zimmermann, "A Roadmap for Transmission Control Protocol
(TCP) Specification Documents", RFC 7414, February 2015. (TCP) Specification Documents", RFC 7414,
DOI 10.17487/RFC7414, February 2015,
<http://www.rfc-editor.org/info/rfc7414>.
Authors' Addresses Authors' Addresses
Dushyant Raghuvanshi Dushyant Raghuvanshi
Cisco Systems, Inc. Cisco Systems, Inc.
Cessna Business Park, Cessna Business Park,
Varthur Hobli, Outer Ring Road, Varthur Hobli, Outer Ring Road,
Bangalore, Karnataka 560037 Bangalore, Karnataka 560037
India India
Phone: +91 (080) 4365-7476 Phone: +91 80 4426-7372
Email: draghuva@cisco.com Email: draghuva@cisco.com
Kim Kinnear Kim Kinnear
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, Massachusetts 01719 Boxborough, Massachusetts 01719
USA USA
Phone: +1 (978) 936-0000 Phone: +1 978 936-0000
Email: kkinnear@cisco.com Email: kkinnear@cisco.com
Deepak Kukrety Deepak Kukrety
Cisco Systems, Inc. Cisco Systems, Inc.
Cessna Business Park, Cessna Business Park,
Varthur Hobli, Outer Ring Road, Varthur Hobli, Outer Ring Road,
Bangalore, Karnataka 560037 Bangalore, Karnataka 560037
India India
Phone: +91 (080) 4365-7474 Phone: +91 80 4426-7346
Email: dkukrety@cisco.com Email: dkukrety@cisco.com
 End of changes. 72 change blocks. 
107 lines changed or deleted 182 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/