draft-ietf-dhc-dhcpv6-active-leasequery-02.txt   draft-ietf-dhc-dhcpv6-active-leasequery-03.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: September 3, 2015 March 2, 2015 Expires: December 11, 2015 June 9, 2015
DHCPv6 Active Leasequery DHCPv6 Active Leasequery
draft-ietf-dhc-dhcpv6-active-leasequery-02 draft-ietf-dhc-dhcpv6-active-leasequery-03
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 September 3, 2015. This Internet-Draft will expire on December 11, 2015.
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 17 skipping to change at page 2, line 17
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Interaction Between Active Leasequery and Bulk Leasequery . . 7 4. Interaction Between Active Leasequery and Bulk Leasequery . . 7
5. Extension to DHCPv6 Bulk Leasequery . . . . . . . . . . . . . 7 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.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3.1. OPTION_LQ_BASE_TIME . . . . . . . . . . . . . . . . . 9 6.3.1. OPTION_LQ_BASE_TIME . . . . . . . . . . . . . . . . . 9
6.3.2. OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 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 . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . 13
8.3. Forming an Active Leasequery . . . . . . . . . . . . . . 14 8.3. Forming an Active Leasequery . . . . . . . . . . . . . . 14
8.4. Processing Active Replies . . . . . . . . . . . . . . . . 15 8.4. Processing Active Replies . . . . . . . . . . . . . . . . 15
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 . . . . . . 19
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 . . . . . . . . . . . . . . . 20
8.6.3. Successful Query . . . . . . . . . . . . . . . . . . 20 8.6.3. Successful Query . . . . . . . . . . . . . . . . . . 21
8.7. Closing Connections . . . . . . . . . . . . . . . . . . . 21 8.7. Closing Connections . . . . . . . . . . . . . . . . . . . 21
9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 21 9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Accepting Connections . . . . . . . . . . . . . . . . . . 21 9.1. Accepting Connections . . . . . . . . . . . . . . . . . . 22
9.2. Rejecting Connections . . . . . . . . . . . . . . . . . . 22 9.2. Rejecting Connections . . . . . . . . . . . . . . . . . . 23
9.3. Replying to an Active Leasequery . . . . . . . . . . . . 22 9.3. Replying to an Active Leasequery . . . . . . . . . . . . 23
9.4. Multiple or Parallel Queries . . . . . . . . . . . . . . 24 9.4. Multiple or Parallel Queries . . . . . . . . . . . . . . 25
9.5. Closing Connections . . . . . . . . . . . . . . . . . . . 25 9.5. Closing Connections . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
13. Modification History . . . . . . . . . . . . . . . . . . . . 27 13. Modification History . . . . . . . . . . . . . . . . . . . . 27
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1. Normative References . . . . . . . . . . . . . . . . . . 27 14.1. Normative References . . . . . . . . . . . . . . . . . . 27
14.2. Informative References . . . . . . . . . . . . . . . . . 27 14.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
skipping to change at page 4, line 4 skipping to change at page 4, line 6
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
DHCPv6 terminology is defined in [RFC3315]. Terminology specific to DHCPv6 terminology is defined in [RFC3315]. Terminology specific to
DHCPv6 Active Leasequery can be found below: DHCPv6 Active Leasequery can be found below:
o "Absolute Time" o "Absolute Time"
A 32-bit quantity containing the number of seconds since midnight
January 1, 2000 UTC. A 32-bit unsigned quantity containing the number of seconds since
midnight (UTC), January 1, 2000, modulo 2^32.
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 information about all or some of the Requesting and receiving the information about all or some of the
existing DHCPv6 binding information in an efficient manner, as existing DHCPv6 binding information in an efficient manner, as
defined by [RFC5460]. defined by [RFC5460].
o "blocked TCP connection" o "blocked TCP connection"
A TCP connection is considered blocked if the underlying TCP A TCP connection is considered blocked if the underlying TCP
transport will not accept new messages to be sent without blocking transport will not accept new messages to be sent without blocking
the thread that is attempting to send the message. the thread that is attempting to send the message.
o "binding change/update" o "binding change/update"
Any change in the DHCPv6 binding state or data stored on the Any change in the DHCPv6 binding state. This also includes
DHCPv6 server related to binding. This also includes expiration expiration or deletion of the binding.
or deletion of the binding.
o "catch-up information, catch-up phase" o "catch-up information"
If a DHCPv6 Active Leasequery requestor sends OPTION_LQ_START_TIME If a DHCPv6 Active Leasequery requestor sends OPTION_LQ_START_TIME
option in an 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.
phase.
o "catch-up phase"
The period while catch-up information is being sent is the catch-
up phase.
o "clock skew" o "clock skew"
The difference between the absolute time on a DHCPv6 server and The difference between the absolute time on a DHCPv6 server and
the absolute time on the system where a requestor of an Active or the absolute time on the system where a requestor of an Active or
Bulk Leasequery is executing is termed the "clock skew" for that Bulk Leasequery is executing is termed the "clock skew" for that
Active or Bulk Leasequery connection. It is not absolutely Active or Bulk Leasequery connection. It is not absolutely
constant but is likely to vary only slowly. While it is easy to constant but is likely to vary only slowly. While it is easy to
think that this can be calculated precisely after one message is think that this can be calculated precisely after one message is
received by a requestor from a DHCPv6 server, a more accurate received by a requestor from a DHCPv6 server, a more accurate
value is derived from continuously examining the instantaneous value is derived from continuously examining the instantaneous
value developed from each message received from a DHCPv6 server value developed from each message received from a DHCPv6 server
and using it to make small adjustments to the existing value held and using it to make small adjustments to the existing value held
in the requestor. in the requestor.
o "DHCPv6 binding state"
Data stored on the DHCPv6 server related to binding.
o "requestor" o "requestor"
The node that sends LEASEQUERY messages to one or more servers to The node that sends LEASEQUERY messages to one or more servers to
retrieve information on the bindings for a client. retrieve information on the bindings for a client.
o "Transaction ID" o "Transaction ID"
An opaque value used to match responses with queries initiated by An opaque value used to match responses with queries initiated by
an Active Leasequery requestor. an Active Leasequery requestor.
3. Protocol Overview 3. Protocol Overview
The Active Leasequery mechanism is modeled on the existing DHCPv6 The Active Leasequery mechanism is modeled on the existing DHCPv6
Bulk Leasequery [RFC5460]; most differences arise from the long term Bulk Leasequery [RFC5460]; most differences arise from the long term
nature of the TCP [RFC4614] connection required for Active nature of the TCP [RFC7414] connection required for Active
Leasequery. A DHCPv6 server which supports Active Leasequery MUST Leasequery. A DHCPv6 server which supports Active Leasequery MUST
support Bulk Leasequery [RFC5460] as well. support Bulk Leasequery [RFC5460] as well.
An Active Leasequery requestor opens a TCP connection to a DHCPv6 An Active Leasequery requestor opens a TCP connection to a DHCPv6
Server, using the DHCPv6 port 547. Note that this implies that the Server, using the DHCPv6 port 547. Note that this implies that the
Leasequery requestor has server IP address(es) available via Leasequery requestor has server IP address(es) available via
configuration or some other means, and that it has unicast IP configuration or some other means, and that it has unicast IP
reachability to the DHCPv6 server. No relaying for Active Leasequery reachability to the DHCPv6 server. No relaying for Active Leasequery
is specified. is specified.
skipping to change at page 7, line 6 skipping to change at page 7, line 17
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
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.
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 will date with respect to the DHCPv6 server's lease state database should
usually use an initial Bulk Leasequery to bring their database into use an initial Bulk Leasequery to bring their database into
equivalence with that of the DHCPv6 server, and then use Active equivalence with that of the DHCPv6 server, and then use Active
Leasequery to keep that database current with respect to the DHCPv6 Leasequery to keep that database current with respect to the DHCPv6
server's lease state database. server's lease state database.
There are several differences between the Active and Bulk Leasequery There are several differences between the Active and Bulk Leasequery
protocols. Active Leasequery defines a new message protocols. Active Leasequery defines a new message
(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).
skipping to change at page 8, line 22 skipping to change at page 8, line 33
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.
6.2. Messages 6.2. Messages
The LEASEQUERY-REPLY message is defined in [RFC5007]. The
LEASEQUERY-DATA and LEASEQUERY-DONE messages are defined in
[RFC5460].
In an Active Leasequery exchange, a single LEASEQUERY-REPLY message
is used to indicate the success or failure of a query, and to carry
data that do not change in the context of a single query and answer,
such as the Server-ID and Client-ID options. If a query is
successful, the DHCPv6 server MUST respond to it with exactly one
LEASEQUERY-REPLY message. If the server is returning binding data,
the LEASEQUERY-REPLY also contains the first client's binding data in
an OPTION_CLIENT_DATA option. Additional binding data is returned
using LEASEQUERY-DATA message as explained in DHCPv6 Bulk Leasequery
[RFC5460]. In case of 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 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.
skipping to change at page 9, line 22 skipping to change at page 9, line 17
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 requestor and DHCPv6 server.
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
The LEASEQUERY-REPLY message is defined in [RFC5007]. The
LEASEQUERY-DATA and LEASEQUERY-DONE messages are defined in
[RFC5460].
In an Active Leasequery exchange, a single LEASEQUERY-REPLY message
is used to indicate the success or failure of a query, and to carry
data that do not change in the context of a single query and answer,
such as the Server-ID and Client-ID options. If a query is
successful, the DHCPv6 server MUST respond to it with exactly one
LEASEQUERY-REPLY message. If the server is returning binding data,
the LEASEQUERY-REPLY also contains the first client's binding data in
an OPTION_CLIENT_DATA option. Additional binding data is returned
using LEASEQUERY-DATA message as explained in DHCPv6 Bulk Leasequery
[RFC5460]. In case of failure query, single LEASEQUERY-REPLY message
is returned without any binding data.
6.3. Options 6.3. Options
New options (OPTION_LQ_BASE_TIME, OPTION_LQ_START_TIME and New options (OPTION_LQ_BASE_TIME, OPTION_LQ_START_TIME and
OPTION_LQ_END_TIME) are defined as an extension to DHCPv6 Bulk OPTION_LQ_END_TIME) are defined as an extension to DHCPv6 Bulk
Leasequery [RFC5460]. The reply messages for Active Leasequery uses Leasequery [RFC5460]. The reply messages for Active Leasequery uses
these options along with the options defined in [RFC3315], [RFC5007] these options along with the options defined in [RFC3315], [RFC5007]
and [RFC5460]. and [RFC5460].
6.3.1. OPTION_LQ_BASE_TIME 6.3.1. OPTION_LQ_BASE_TIME
skipping to change at page 13, line 31 skipping to change at page 13, line 46
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.
8.2. Initiating a Connection 8.2. Initiating a Connection
A Requestor SHOULD attempt to negotiate a TLS [RFC5246] connection A Requestor SHOULD be able to operate in either insecure or secure
over the TCP connection. If this negotiation fails, a requestor MAY mode. This MAY be a feature that is administratively controlled.
choose to proceed with the Active Leasequery request without TLS.
When operating in insecure mode, requestor should proceed with the
Active Leasequery request after the establishment of a TCP
connection.
When operating in secure mode, requestor MUST attempt to negotiate a
TLS [RFC5246] connection over the TCP connection. If this
negotiation fails, the requestor MUST drop the TCP 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 drops 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 MAY choose assumed to not support TLS. In this case, the requestor MUST drop
to proceed with the Active Leasequery request without having it the TCP connection.
protected by TLS.
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
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 Active Leasequery message 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. The connection, then the requestor MUST drop the TCP connection.
requestor MAY create a new TCP connection and MAY choose to proceed
with an Active Leasequery request without using TLS.
8.3. Forming an Active Leasequery 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 16, line 37 skipping to change at page 17, line 10
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
a 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
skipping to change at page 21, line 43 skipping to change at page 22, line 16
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. Approach used in accepting the requestor
connection is same as specified in DHCPv6 Bulk Leasequery [RFC5460]. connection is same as specified in DHCPv6 Bulk Leasequery [RFC5460].
DHCPv6 servers SHOULD support TLS [RFC5246] to protect the integrity DHCPv6 servers SHOULD be able to operate in either insecure or secure
and privacy of the data transmitted over the TCP connection. DHCPv6 mode. This MAY be a mode that is administratively controlled, where
servers SHOULD negotiate a TLS connection with the requestor who asks the server will require a TLS connection to operate or will only
for one, and MAY choose to accept DHCPv6 Active Leasequery request operate without a TLS connection.
over connections which are not secured with TLS.
When operating in insecure mode, DHCPv6 server simply waits for the
requestor to send the Active Leasequery request after the
establishment of TCP connection. If it receives a STARTTLS message,
it MUST respond with REPLY [RFC3315] message with DHCPv6 status code
of TLSConnectionRefused.
When operating in secure mode, DHCPv6 servers MUST support TLS
[RFC5246] to protect the integrity and privacy of the data
transmitted over the TCP connection. DHCPv6 servers SHOULD negotiate
a TLS connection with the requestor who asks for one, and MUST drop
the TCP connections which are not secured with TLS.
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 SHOULD 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). Section 8.2). During the TLS handshake, the DHCPv6 server MUST
verify the requestor's digital certificate.
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 drop 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
skipping to change at page 24, line 37 skipping to change at page 25, line 22
Unless there is an error or some requirement to cease processing a Unless there is an error or some requirement to cease processing a
Active Leasequery request yielding a LEASEQUERY-DONE message, such as Active Leasequery request yielding a LEASEQUERY-DONE message, such as
a server shutdown, there will be no LEASEQUERY-DONE message at the a server shutdown, there will be no LEASEQUERY-DONE message at the
conclusion of the Active Leasequery processing because that conclusion of the Active Leasequery processing because that
processing will not conclude but will continue until either the processing will not conclude but will continue until either the
requestor or the server drops the connection. requestor or the server drops the connection.
9.4. Multiple or Parallel Queries 9.4. Multiple or Parallel Queries
Requesters may want to use an existing connection if they need to Every Active Leasequery request MUST be made on a single TCP
make multiple queries. Servers MAY support reading and processing connection where there is no other request active at the time the
multiple queries from a single connection. A server MUST NOT read request is made.
more query messages from a connection than it is prepared to process
simultaneously.
Typically, a requestor of an Active Leasequery would not need to send Typically, a requestor of an Active Leasequery would not need to send
a second Active Leasequery while the first is still active. However, a second Active Leasequery while the first is still active. However,
sending an Active Leasequery and a Bulk Leasequery over the same sending an Active Leasequery and a Bulk Leasequery in parallel would
connection would be possible and reasonable. But it is RECOMMENDED be possible and reasonable. In case of parallel Active and Bulk
to use different connection in case of parallel Active and Bulk Leasequeries, requestor MUST use different TCP connections.
Leasequeries.
This MAY be a feature that is administratively controlled. Servers This MAY be a feature that is administratively controlled. Servers
that are able to process queries in parallel SHOULD offer that are able to process queries in parallel SHOULD offer
configuration that limits the number of simultaneous queries configuration that limits the number of simultaneous queries
permitted from any one requestor, in order to control resource use if permitted from any one requestor, in order to control resource use if
there are multiple requesters seeking service. there are multiple requesters seeking service.
9.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
closed, the server MUST close its end of the connection after it has closed, the server MUST close its end of the connection.
finished processing any outstanding requests from the requestor.
The server SHOULD limit the number of connections it maintains, and The server SHOULD limit the number of connections it maintains, and
SHOULD close idle connections to enforce the limit. SHOULD close idle connections to enforce the limit.
10. Security Considerations 10. Security Considerations
The "Security Considerations" section of [RFC3315] details the The "Security Considerations" section of [RFC3315] details the
general threats to DHCPv6. The DHCPv6 Leasequery specification general threats to DHCPv6. The DHCPv6 Leasequery specification
[RFC5007] describes recommendations for the Leasequery protocol, [RFC5007] describes recommendations for the Leasequery protocol,
especially with regard to relayed Leasequery messages, mitigation of especially with regard to relayed Leasequery messages, mitigation of
packet-flooding denial-of-service (DoS) attacks, restriction to packet-flooding denial-of-service (DoS) attacks, restriction to
trusted requestors, and use of IPsec [RFC4301]. trusted requestors, and use of IPsec [RFC4301].
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, such as SYN flooding attacks, can compromise the ability resources can compromise the ability of legitimate requestors to
of legitimate requestors to receive service. Malicious requestors receive service. Malicious requestors who succeed in establishing
who succeed in establishing connections, but who then send invalid connections, but who then send invalid queries, partial queries, or
queries, partial queries, or no queries at all also can exhaust a no queries at all also can exhaust a server's pool of available
server's pool of available connections. We recommend that servers connections. We recommend that servers offer configuration to limit
offer configuration to limit the sources of incoming connections, the sources of incoming connections, that they limit the number of
that they limit the number of accepted connections and the number of accepted connections, and that they limit the period of time during
in-process queries from any one connection, and that they limit the which an idle connection will be left open.
period of time during which an idle connection will be left open.
There are two specific issues regarding Active Leasequery security
that deserve explicit mention. The first is preventing information
that Active Leasequery can provide from reaching requestors who are
not authorized to receive such information. The second is ensuring
that authorized requestors of the Active Leasequery capability
receive accurate information from the Server (and that this
information is not disrupted in transit).
To prevent information leakage to unauthorized requestors, Servers
SHOULD restrict Active Leasequery connections and ACTIVELEASEQUERY
messages to certain requestors, either through explicit configuration
of the Server itself or by employing external network elements to
provide such restrictions.
Connections not from permitted requestors SHOULD be closed
immediately, to avoid server connection resource exhaustion or
alternatively, simply not be allowed to reach the server at all.
Servers SHOULD have the capability to restrict certain requestors to
certain query types. Servers MAY reply to queries that are not
permitted with the LEASEQUERY-DONE message with a status-code option
status of NotAllowed, or MAY simply close the connection.
In addition, requestors and servers SHOULD use TLS [RFC5246] to
protect the integrity and privacy of the Active Leasequery data
transmitted over the TCP connection.
Authentication for DHCP Messages [RFC3315] MUST NOT be used to Authentication for DHCP Messages [RFC3315] MUST NOT be used to
attempt to secure transmission of the messages described in this attempt to secure transmission of the messages described in this
document. document.
11. IANA Considerations 11. IANA Considerations
IANA is requested to assign new DHCPv6 Option Codes in the registry IANA is requested to assign new DHCPv6 Option Codes in the registry
maintained in http://www.iana.org/assignments/dhcpv6-parameters: maintained in http://www.iana.org/assignments/dhcpv6-parameters:
skipping to change at page 27, line 5 skipping to change at page 27, line 5
dhcpv6-parameters: dhcpv6-parameters:
DataMissing DataMissing
CatchUpComplete CatchUpComplete
NotSupported NotSupported
TLSConnectionRefused TLSConnectionRefused
IANA is requested to assign value for the following new DHCPv6 IANA is requested to assign values for the following new DHCPv6
Message type 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. Acknowledgements
Some of the concept and content, present in this document, are based Some of the concept and content, present in this document, are based
on DHCPv4 Active Leasequery which was originally proposed by Kim on DHCPv4 Active Leasequery which was originally proposed by Kim
skipping to change at page 28, line 5 skipping to change at page 28, line 5
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February
2009. 2009.
14.2. Informative References 14.2. Informative References
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
for Transmission Control Protocol (TCP) Specification Zimmermann, "A Roadmap for Transmission Control Protocol
Documents", RFC 4614, September 2006. (TCP) Specification Documents", RFC 7414, February 2015.
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
 End of changes. 33 change blocks. 
108 lines changed or deleted 106 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/