idnits 2.17.1 draft-ietf-dhc-dhcpv6-active-leasequery-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5460, but the abstract doesn't seem to directly say this. It does mention RFC5460 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5460, updated by this document, for RFC5378 checks: 2008-02-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 31, 2015) is 3192 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group D. Raghuvanshi 3 Internet-Draft K. Kinnear 4 Updates: 5460 (if approved) D. Kukrety 5 Intended status: Standards Track Cisco Systems, Inc. 6 Expires: February 1, 2016 July 31, 2015 8 DHCPv6 Active Leasequery 9 draft-ietf-dhc-dhcpv6-active-leasequery-04 11 Abstract 13 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been 14 extended with a Leasequery capability that allows a requestor to 15 request information about DHCPv6 bindings. That mechanism is limited 16 to queries for DHCPv6 binding data updates prior to the time the 17 DHCPv6 server receives the Leasequery request. Continuous update of 18 an external requestor with Leasequery data is sometimes desired. 19 This document expands on the DHCPv6 Leasequery protocol, and allows 20 for active transfer of real-time DHCPv6 binding information data via 21 TCP. This document also updates DHCPv6 Bulk Leasequery (RFC5460) by 22 adding new options. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 1, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Interaction Between Active Leasequery and Bulk Leasequery . . 7 62 5. Extension to DHCPv6 Bulk Leasequery . . . . . . . . . . . . . 8 63 6. Message and Option Definitions . . . . . . . . . . . . . . . 8 64 6.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 8 65 6.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.2.1. ACTIVELEASEQUERY . . . . . . . . . . . . . . . . . . 8 67 6.2.2. STARTTLS . . . . . . . . . . . . . . . . . . . . . . 9 68 6.2.3. Response Messages . . . . . . . . . . . . . . . . . . 9 69 6.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 6.3.1. OPTION_LQ_BASE_TIME . . . . . . . . . . . . . . . . . 10 71 6.3.2. OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 10 72 6.3.3. OPTION_LQ_END_TIME . . . . . . . . . . . . . . . . . 11 73 6.4. Connection and Transmission Parameters . . . . . . . . . 12 74 7. Information Communicated by Active Leasequery . . . . . . . . 12 75 8. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 13 76 8.1. General Processing . . . . . . . . . . . . . . . . . . . 13 77 8.2. Initiating a Connection . . . . . . . . . . . . . . . . . 14 78 8.3. Forming an Active Leasequery . . . . . . . . . . . . . . 15 79 8.4. Processing Active Replies . . . . . . . . . . . . . . . . 16 80 8.4.1. Processing Replies from a Request Containing a 81 OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 17 82 8.5. Processing Time Values in Leasequery messages . . . . . . 20 83 8.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 20 84 8.6.1. Query Failure . . . . . . . . . . . . . . . . . . . . 20 85 8.6.2. Data Missing on Server . . . . . . . . . . . . . . . 21 86 8.6.3. Successful Query . . . . . . . . . . . . . . . . . . 21 87 8.7. Closing Connections . . . . . . . . . . . . . . . . . . . 22 88 9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 22 89 9.1. Accepting Connections . . . . . . . . . . . . . . . . . . 22 90 9.2. Rejecting Connections . . . . . . . . . . . . . . . . . . 24 91 9.3. Replying to an Active Leasequery . . . . . . . . . . . . 24 92 9.4. Multiple or Parallel Queries . . . . . . . . . . . . . . 26 93 9.5. Closing Connections . . . . . . . . . . . . . . . . . . . 26 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 95 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 96 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 97 13. Modification History . . . . . . . . . . . . . . . . . . . . 28 98 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 99 14.1. Normative References . . . . . . . . . . . . . . . . . . 28 100 14.2. Informative References . . . . . . . . . . . . . . . . . 29 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 103 1. Introduction 105 The DHCPv6 [RFC3315] protocol specifies a mechanism for the 106 assignment of IPv6 address and configuration information to IPv6 107 nodes. IPv6 Prefix Delegation for DHCPv6 (PD) [RFC3633] specifies a 108 mechanism for DHCPv6 delegation of IPv6 prefixes and related data. 109 DHCPv6 servers maintain authoritative information including binding 110 information for delegated IPv6 prefixes. 112 Requirements exist for external entities to keep up to date on the 113 correspondence between DHCPv6 clients and their bindings. These 114 entities need to keep up with the current binding activity of the 115 DHCPv6 server. Keeping up with these binding activity is termed 116 "active" leasequery. 118 The DHCPv6 Bulk Leasequery [RFC5460] capability can be used to 119 recover useful information from a DHCPv6 server when some external 120 entity starts up. This entity could be one which is directly 121 involved in the DHCPv6 client - server transactions (e.g., a relay 122 agent), or it could be an external process which needs information 123 present in the DHCPv6 server's lease state database. 125 The Active Leasequery capability documented here is designed to allow 126 an entity not directly involved in DHCPv6 client - server 127 transactions to nevertheless keep current with the state of the 128 DHCPv6 lease state information in real-time. 130 This document updates DHCPv6 Bulk Leasequery [RFC5460] by adding new 131 options, as described in Section 6.2.1. For DHCPv6 servers, 132 supporting Bulk Leasequery and not Active Leasequery, Section 9.2 133 specifies the mechanism to reject incoming Active Leasequery 134 requests. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 DHCPv6 terminology is defined in [RFC3315]. Terminology specific to 143 DHCPv6 Active Leasequery can be found below: 145 o "Absolute Time" 147 A 32-bit unsigned quantity containing the number of seconds since 148 midnight (UTC), January 1, 2000, modulo 2^32. 150 o "Active Leasequery" 152 Keeping up to date in real-time (or near real-time) with DHCPv6 153 binding activity. 155 o "Bulk Leasequery" 157 Requesting and receiving the information about all or some of the 158 existing DHCPv6 binding information in an efficient manner, as 159 defined by [RFC5460]. 161 o "blocked TCP connection" 163 A TCP connection is considered blocked if the underlying TCP 164 transport will not accept new messages to be sent without blocking 165 the thread that is attempting to send the message. 167 o "binding change/update" 169 Any change in the DHCPv6 binding state. This also includes 170 expiration or deletion of the binding. 172 o "catch-up information" 174 If a DHCPv6 Active Leasequery requestor sends OPTION_LQ_START_TIME 175 option in an ACTIVELEASEQUERY message, the DHCPv6 server will 176 attempt to send the requestor the information that changed since 177 the time specified in the OPTION_LQ_START_TIME option. The 178 binding information sent to satisfy this request is the catch-up 179 information. 181 o "catch-up phase" 183 The period while catch-up information is being sent is the catch- 184 up phase. 186 o "clock skew" 188 The difference between the absolute time on a DHCPv6 server and 189 the absolute time on the system where a requestor of an Active or 190 Bulk Leasequery is executing is termed the "clock skew" for that 191 Active or Bulk Leasequery connection. It is not absolutely 192 constant but is likely to vary only slowly. While it is easy to 193 think that this can be calculated precisely after one message is 194 received by a requestor from a DHCPv6 server, a more accurate 195 value is derived from continuously examining the instantaneous 196 value developed from each message received from a DHCPv6 server 197 and using it to make small adjustments to the existing value held 198 in the requestor. 200 o "DHCPv6 binding state" 202 Data stored on the DHCPv6 server related to binding. 204 o "requestor" 206 The node that sends LEASEQUERY messages to one or more servers to 207 retrieve information on the bindings for a client. 209 o "Transaction ID" 211 An opaque value used to match responses with queries initiated by 212 an Active Leasequery requestor. 214 3. Protocol Overview 216 The Active Leasequery mechanism is modeled on the existing DHCPv6 217 Bulk Leasequery [RFC5460]; most differences arise from the long term 218 nature of the TCP [RFC7414] connection required for Active 219 Leasequery. A DHCPv6 server which supports Active Leasequery MUST 220 support Bulk Leasequery [RFC5460] as well. 222 An Active Leasequery requestor opens a TCP connection to a DHCPv6 223 Server, using the DHCPv6 port 547. Note that this implies that the 224 Leasequery requestor has server IP address(es) available via 225 configuration or some other means, and that it has unicast IP 226 reachability to the DHCPv6 server. No relaying for Active Leasequery 227 is specified. 229 After establishing a connection, the requestor sends an 230 ACTIVELEASEQUERY message over the connection. In response, the 231 server sends updates to the requestor using LEASEQUERY-REPLY and 232 LEASEQUERY-DATA messages. This response procedure is similar to the 233 procedure specified in [RFC5460], except that in the case of Active 234 Leasequery the server sends updates whenever some activity occurs to 235 change the binding state - thus the need for long lived connection. 236 Additionally, the Active Leasequery server SHOULD provide a mechanism 237 to control which data is allowed to be included in the 238 OPTION_CLIENT_DATA messages sent to the requestor. See Section 9.3. 240 Active Leasequery has features which allow this external entity to 241 lose its connection and then reconnect and receive the latest 242 information concerning any IPv6 bindings changed while it was not 243 connected. 245 These features are designed to allow the Active Leasequery requestor 246 to efficiently become current with respect to the lease state 247 database after it has been restarted or the machine on which it is 248 running has been reinitialized. It is easy to define a protocol 249 which works when the requestor is always connected to the DHCPv6 250 server. Since that isn't sufficiently robust, much of the mechanism 251 in this document is designed to deal efficiently with situations that 252 occur when the Active Leasequery requestor becomes disconnected from 253 the DHCPv6 server from which it is receiving updates and then 254 reconnects to that server. 256 Central to this approach, if the Active Leasequery requestor loses 257 service, it is allowed to specify the time of its most recent update 258 in a subsequent Active Leasequery request and the DHCPv6 server will 259 determine whether or not data was missed while the Active Leasequery 260 requestor was not connected. 262 The DHCPv6 server processing the Active Leasequery request MAY limit 263 the amount of data saved, and methods exist for the DHCPv6 server to 264 inform the Active Leasequery requestor that data was missed - not all 265 could be saved. In this situation, the Active Leasequery requestor 266 should issue a Bulk Leasequery [RFC5460] to recover information not 267 available through an Active Leasequery. 269 DHCPv6 servers are not required to keep any data corresponding to 270 data missed on an Active Leasequery connection, but will typically 271 choose to keep data corresponding to some recent activity available 272 for subsequent queries by a DHCPv6 Active Leasequery requestor whose 273 connection was temporarily interrupted. In other words, DHCPv6 274 servers supporting catch-up are required to have some mechanism to 275 keep/save historic information of bindings. 277 An Active Leasequery requestor would typically use Bulk Leasequery to 278 initialize its database with all current data when that database 279 contains no binding information. In addition, it would use Bulk 280 Leasequery to recover missed information in the event that its 281 connection with the DHCPv6 server was lost for a longer time than the 282 DHCPv6 server would keep track of the specific changes to the IPv6 283 binding information. 285 The messages sent by the server in response to an Active Leasequery 286 request should be identical to the messages sent by the server to a 287 Bulk Leasequery request regarding the way the data is encoded into 288 the Active Leasequery responses. In addition, the actions taken by 289 the Active Leasequery requestor to interpret the responses to an 290 Active Leasequery request should be identical to the way that the 291 requestor interprets the responses to a Bulk Leasequery request. 292 Thus, the handling of OPTION_CLIENT_DATA and additional options 293 discussed in the Bulk Leasequery specification [RFC5460] are to be 294 followed when implementing Active Leasequery, with the exception that 295 a server responding to an Active Leasequery request SHOULD be able to 296 be configured to prevent specific data items from being included in 297 the OPTION_CLIENT_DATA option even if they were requested by 298 inclusion in the OPTION_ORO option. 300 4. Interaction Between Active Leasequery and Bulk Leasequery 302 Active Leasequery is an extension of the Bulk Leasequery protocol 303 [RFC5460]. The format of messages returned to an Active Leasequery 304 requestor are identical to that defined for the Bulk Leasequery 305 protocol [RFC5460]. 307 Applications which employ Active Leasequery to keep a database up to 308 date with respect to the DHCPv6 server's lease state database should 309 use an initial Bulk Leasequery to bring their database into 310 equivalence with that of the DHCPv6 server, and then use Active 311 Leasequery to keep that database current with respect to the DHCPv6 312 server's lease state database. 314 There are several differences between the Active and Bulk Leasequery 315 protocols. Active Leasequery defines a new message 316 (ACTIVELEASEQUERY) to send Active Leasequery request to DHCPv6 317 server. An Active Leasequery connection sends all available updates 318 to the requestor, based on OPTION_LQ_QUERY option (see 319 Section 6.2.1). 321 An Active Leasequery connection does not ever "complete", though the 322 DHCPv6 server can close the connection for a variety of reasons 323 associated with some sort of exception condition. 325 5. Extension to DHCPv6 Bulk Leasequery 327 This document extends to the capabilities of DHCPv6 Bulk Leasequery 328 protocol [RFC5460] by defining new options (OPTION_LQ_BASE_TIME, 329 OPTION_LQ_START_TIME and OPTION_LQ_END_TIME). DHCPv6 server sends 330 OPTION_LQ_BASE_TIME option in Bulk Leasequery response if requestor 331 ask for the same in Bulk Leasequery request. OPTION_LQ_START_TIME 332 and OPTION_LQ_END_TIME can be used in Bulk Leasequery request made to 333 DHCPv6 server. More details about these options are specified in 334 Section 6.3. 336 6. Message and Option Definitions 338 6.1. Message Framing for TCP 340 The use of TCP for the Active Leasequery protocol permits one or more 341 DHCPv6 messages to be sent in response to single Active Leasequery 342 request. The receiver needs to be able to determine how large each 343 message is. The same message framing technique used for DHCPv6 Bulk 344 Leasequery [RFC5460] is used for Active Leasequery as well. 346 The intent in using the same format is that code which currently 347 knows how to deal with a message returned from DHCPv6 Bulk Leasequery 348 [RFC5460] will be able to deal with the message held inside of the 349 TCP framing. 351 When using TLS to secure a connection [RFC5246], the message framing 352 for TLS uses the same format as that used for TCP. One DHCP message 353 is carried in one TLS record. 355 6.2. Messages 357 6.2.1. ACTIVELEASEQUERY 359 The new message type (ACTIVELEASEQUERY) is designed for keeping the 360 requestor up to date in real-time (or near real-time) with DHCPv6 361 bindings. It asks the server to return DHCPv6 bindings activity that 362 occurs subsequent to the receipt of the Active Leasequery request. 364 An ACTIVELEASEQUERY request MUST contain a transaction-id, and that 365 transaction-id MUST be locally unique on the TCP connection on which 366 it is sent to the DHCPv6 server. 368 When sending an Active Leasequery request, the requestor MAY include 369 the OPTION_LQ_START_TIME option in the ACTIVELEASEQUERY request. In 370 this case, DHCPv6 server returns all the bindings changed on or after 371 the OPTION_LQ_START_TIME. 373 If the requestor is interested in receiving all binding updates from 374 the DHCPv6 server, it MUST NOT include the OPTION_LQ_QUERY option in 375 the ACTIVELEASEQUERY message. But if the requestor is only 376 interested in specific binding updates, it MAY include an 377 OPTION_LQ_QUERY option along with a query-types defined in [RFC5007] 378 and [RFC5460]. 380 Other DHCPv6 options used in the LEASEQUERY message (as specified in 381 [RFC5460]) can also be used in the ACTIVELEASEQUERY request. 383 6.2.2. STARTTLS 385 The new message type (STARTTLS) is designed for establishment of a 386 TLS connection between a requestor and a DHCPv6 server. The STARTTLS 387 message SHOULD be sent without any options. Any options received in 388 a STARTTLS message SHOULD be ignored./ 390 More details about this message are specified in Section 8.2. 392 6.2.3. Response Messages 394 The LEASEQUERY-REPLY message is defined in [RFC5007]. The 395 LEASEQUERY-DATA and LEASEQUERY-DONE messages are defined in 396 [RFC5460]. 398 In an Active Leasequery exchange, a single LEASEQUERY-REPLY message 399 is used to indicate the success or failure of a query, and to carry 400 data that do not change in the context of a single query and answer, 401 such as the Server-ID and Client-ID options. If a query is 402 successful, the DHCPv6 server MUST respond to it with exactly one 403 LEASEQUERY-REPLY message. If the server is returning binding data, 404 the LEASEQUERY-REPLY also contains the first client's binding data in 405 an OPTION_CLIENT_DATA option. Additional binding data is returned 406 using LEASEQUERY-DATA message as explained in DHCPv6 Bulk Leasequery 407 [RFC5460]. In case of failure query, single LEASEQUERY-REPLY message 408 is returned without any binding data. 410 6.3. Options 412 New options (OPTION_LQ_BASE_TIME, OPTION_LQ_START_TIME and 413 OPTION_LQ_END_TIME) are defined as an extension to DHCPv6 Bulk 414 Leasequery [RFC5460]. The reply messages for Active Leasequery uses 415 these options along with the options defined in [RFC3315], [RFC5007] 416 and [RFC5460]. 418 6.3.1. OPTION_LQ_BASE_TIME 420 The OPTION_LQ_BASE_TIME option is the current time the message was 421 created to be sent by the DHCPv6 server to the requestor of the 422 Active or Bulk Leasequery if requestor ask for the same in Active or 423 Bulk Leasequery request. This MUST be an absolute time (i.e., 424 seconds since midnight January 1, 2000 UTC). All of the other time 425 based options in the reply message are relative to this time, 426 including OPTION_CLT_TIME [RFC5007]. This time is in the context of 427 the DHCPv6 server who placed this option in a message. 429 This is an unsigned integer in network byte order. 431 The code for this option is TBD-1. 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | OPTION_LQ_BASE_TIME | option-len | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | base-time | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 option-code OPTION_LQ_BASE_TIME (TBD-1). 442 option-len 4. 443 base-time DHCPv6 Server Base Time. 445 6.3.2. OPTION_LQ_START_TIME 447 The OPTION_LQ_START_TIME option specifies a query start time to the 448 DHCPv6 server. If specified, only bindings that have changed on or 449 after the OPTION_LQ_START_TIME should be included in the response to 450 the query. This option MAY be used in Active or Bulk Leasequery 451 requests made to a DHCPv6 server. 453 The requestor MUST determine the OPTION_LQ_START_TIME using lease 454 information it has received from the DHCPv6 server. This MUST be an 455 absolute time in the DHCPv6 server's context (see Section 8.5). 457 Typically (though this is not a requirement) the OPTION_LQ_START_TIME 458 option will contain the value most recently received in a 459 OPTION_LQ_BASE_TIME option by the requestor, as this will indicate 460 the last successful communication with the DHCPv6 server. 462 This is an unsigned integer in network byte order. 464 The code for this option is TBD-2. 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | OPTION_LQ_START_TIME | option-len | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | query-start-time | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 option-code OPTION_LQ_START_TIME (TBD-2). 475 option-len 4. 476 query-start-time DHCPv6 Server Query Start Time. 478 6.3.3. OPTION_LQ_END_TIME 480 The OPTION_LQ_END_TIME option specifies a query end time to the 481 DHCPv6 server. If specified, only bindings that have changed on or 482 before the OPTION_LQ_END_TIME should be included in the response to 483 the query. This option MAY be used in a Bulk Leasequery request. 484 But it MUST NOT be used in an Active Leasequery request. 486 The requestor MUST determine the OPTION_LQ_END_TIME based on lease 487 information it has received from the DHCPv6 server. This MUST be an 488 absolute time in the context of the DHCPv6 server. 490 In the absence of information to the contrary, the requestor SHOULD 491 assume that the time context of the DHCPv6 server is identical to the 492 time context of the requestor (see Section 8.5). 494 This is an unsigned integer in network byte order. 496 The code for this option is TBD-3. 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | OPTION_LQ_END_TIME | option-len | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | query-end-time | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 option-code OPTION_LQ_END_TIME (TBD-3). 507 option-len 4. 508 query-end-time DHCPv6 Server Query End Time. 510 6.4. Connection and Transmission Parameters 512 Active Leasequery uses the same port configuration as DHCPv6 Bulk 513 Leasequery [RFC5460]. It also uses the other transmission parameters 514 (BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [RFC5460]. 516 This section presents a table of values used to control Active 517 Leasequery behavior, including recommended defaults. Implementations 518 MAY make these values configurable. However, configuring too-small 519 timeout values may lead to harmful behavior both to this application 520 as well as to other traffic in the network. As a result, timeout 521 values smaller than the default values SHOULD NOT be used. 523 +------------------------+----------+-------------------------------+ 524 | Parameter | Default | Description | 525 +------------------------+----------+-------------------------------+ 526 | ACTIVE_LQ_RCV_TIMEOUT | 120 secs | Active Leasequery receive | 527 | | | timeout | 528 | ACTIVE_LQ_SEND_TIMEOUT | 120 secs | Active Leasequery send | 529 | | | timeout | 530 | ACTIVE_LQ_IDLE_TIMEOUT | 60 secs | Active Leasequery idle | 531 | | | timeout | 532 +------------------------+----------+-------------------------------+ 534 7. Information Communicated by Active Leasequery 536 While the information communicated by a DHCPv6 Bulk Leasequery 537 [RFC5460] is taken directly from the DHCPv6 server's lease state 538 database, the information communicated by an Active Leasequery is 539 real-time information. As such, it is the information which is 540 currently associated with a particular binding in the DHCPv6 server's 541 lease state database. 543 This is of significance, because if the Active Leasequery requestor 544 runs slowly or the requestor disconnects from the DHCPv6 server and 545 then reconnects with an OPTION_LQ_START_TIME option (signaling a 546 catch-up operation), the information communicated to the Active 547 Leasequery requestor is only the most current information from the 548 DHCPv6 server's lease state database. 550 The requestor of an Active Leasequery MUST NOT assume that every 551 lease state change is communicated across an Active Leasequery 552 connection. Even if the Active Leasequery requestor remains 553 connected, the DHCPv6 server is only required to transmit information 554 about a binding that is current when the message is created and 555 handed off to the TCP stack to send to the requestor. 557 If the TCP connection blocks and the DHCPv6 server is waiting to send 558 information down the connection, when the connection becomes 559 available to be written the DHCPv6 server MAY create the message to 560 send at this time. The current state of the binding will be sent, 561 and any transition in state or other information that occurred while 562 the TCP connection was blocked will be lost. 564 Thus, the Active Leasequery protocol does not allow the requestor to 565 build a complete history of every activity on every lease. An 566 effective history of the important state changes for a lease can be 567 created if the parameters of the DHCPv6 server are tuned to take into 568 account the requirements of an Active Leasequery requestor. For 569 instance, the period after the expiration or release of a binding 570 could be configured long enough (say several minutes, well more than 571 the receive timeout), so that an Active Leasequery requestor would be 572 less likely to miss any changes in the binding. 574 8. Requestor Behavior 576 8.1. General Processing 578 A requestor attempts to establish a TCP connection to a DHCPv6 Server 579 in order to initiate an Active Leasequery exchange. If the attempt 580 fails, the Requestor MAY retry. 582 If an Active Leasequery is terminated prematurely by a LEASEQUERY- 583 DONE with a DHCPv6 status code (carried in an OPTION_STATUS_CODE 584 option) of QueryTerminated or by the failure of the connection over 585 which it was being submitted, the requestor MAY retry the request 586 after the creation of a new connection. 588 Messages from the DHCPv6 server come as multiple responses to a 589 single ACTIVELEASEQUERY message. Thus, each ACTIVELEASEQUERY request 590 MUST have an xid (transaction-id) unique on the connection on which 591 it is sent, and all of the messages which come as a response to it 592 contain the same xid as the request. It is the xid which allows the 593 data-streams of two or more different ACTIVELEASEQUERY requests to be 594 de-multiplexed by the requestor. 596 8.2. Initiating a Connection 598 A Requestor SHOULD be able to operate in either insecure or secure 599 mode. This MAY be a feature that is administratively controlled. 601 When operating in insecure mode, the requestor SHOULD proceed to send 602 an ACTIVELEASEQUERY message after the establishment of a TCP 603 connection. 605 When operating in secure mode, the requestor MUST attempt to 606 negotiate a TLS [RFC5246] connection over the TCP connection. If 607 this negotiation fails, the requestor MUST close the TCP connection. 608 The recommendations in [RFC7525] SHOULD be followed when negotiating 609 this connection. 611 A requestor requests the establishment of a TLS connection by sending 612 the STARTTLS message to the DHCPv6 server as the first message over 613 the TCP connection. This message indicates to the DHCPv6 server that 614 a TLS connection over this TCP connection is desired. There are four 615 possibilities after the requestor sends the STARTTLS message to the 616 DHCPv6 server: 618 1. No response from the DHCPv6 server. 620 2. The DHCPv6 server closes the TCP connection after it receives the 621 STARTTLS message. 623 3. DHCPv6 server responds with REPLY [RFC3315] message with DHCPv6 624 status code of TLSConnectionRefused. 626 4. DHCPv6 server responds with REPLY [RFC3315] message without 627 DHCPv6 status code, indicating success. 629 In any of the first three possibilities, the DHCPv6 server can be 630 assumed to not support TLS. In this case, the requestor MUST close 631 the TCP connection. 633 In the final possibility, where the DHCPv6 server has responded with 634 a REPLY message without DHCPv6 status code in response to the 635 requestor's STARTTLS message, the requestor SHOULD initiate the 636 exchange of the messages involved in a TLS handshake [RFC5246]. 637 During the TLS handshake, the requestor MUST validate the DHCPv6 638 server's digital certificate. 640 If the handshake exchange yields a functioning TLS connection, then 641 the requestor SHOULD transmit an ACTIVELEASEQUERY request over that 642 TLS connection and use that TLS connection for all further 643 interactions in which it engages with the DHCPv6 server over this TCP 644 connection. 646 If the handshake exchange does not yield a functioning TLS 647 connection, then the requestor MUST close the TCP connection. 649 8.3. Forming an Active Leasequery 651 The Active Leasequery is designed to create a long lived connection 652 between the requestor and the DHCPv6 server processing the active 653 query. The DHCPv6 server SHOULD send binding information back across 654 this connection with minimal delay after it learns of the binding 655 information. It learns about bindings either because it makes the 656 bindings itself or because it has received information about a 657 binding from another server. 659 An important capability of the Active Leasequery is the ability of 660 the requestor to specify that some recent data be sent immediately to 661 the requestor in parallel with the transmission of the ongoing 662 binding information in more or less real time. This capability is 663 used in order to allow an Active Leasequery requestor to recover 664 missed information in the event that it temporarily loses 665 connectivity with the DHCPv6 server processing a previous Active 666 Leasequery. 668 Note that until all of the recent data (catch-up data) has been 669 received, the requestor MUST NOT keep track of the base-time 670 (OPTION_LQ_BASE_TIME) received in Leasequery reply messages to use 671 later in a subsequent Active Leasequery request. 673 This capability is enabled by the transmission of an 674 OPTION_LQ_BASE_TIME option with each Leasequery reply sent as the 675 result of a previous Active Leasequery. The requestor SHOULD keep 676 track of the highest base-time received from a particular DHCPv6 677 server over an Active Leasequery connection, and in the event that 678 the requestor finds it necessary (for whatever reason) to reestablish 679 an Active Leasequery connection to that DHCPv6 server, the requestor 680 SHOULD place this highest base-time value into an 681 OPTION_LQ_START_TIME option in the new Active Leasequery request. 683 If the requestor doesn't wish to request an update of information 684 missed when it was not connected to the DHCPv6 server, then it SHOULD 685 NOT include the OPTION_LQ_START_TIME option in the Active Leasequery 686 request. 688 If the TCP connection becomes blocked or stops being writable while 689 the requestor is sending its query, the requestor SHOULD terminate 690 the connection after BULK_LQ_DATA_TIMEOUT. We make this 691 recommendation to allow requestors to control the period of time they 692 are willing to wait before abandoning a connection, independent of 693 notifications from the TCP implementations they may be using. 695 8.4. Processing Active Replies 697 The Requestor attempts to read a DHCPv6 LEASEQUERY-REPLY message from 698 the TCP connection. If the stream of replies becomes blocked, the 699 Requestor SHOULD terminate the connection after 700 ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured 701 to do so. 703 The requestor examines the LEASEQUERY-REPLY message, and determines 704 how to proceed. Message validation rules are specified in DHCPv6 705 Leasequery [RFC5007] and DHCPv6 Bulk Leasequery [RFC5460]. If the 706 reply contains an DHCPv6 status code (carried in an 707 OPTION_STATUS_CODE option), the requestor should follow the 708 recommendations in [RFC5007]. 710 Note that an Active Leasequery request specifically requests the 711 DHCPv6 server to create a long-lived connection which may not have 712 data transferring continuously during its lifetime. Therefore the 713 DHCPv6 server SHOULD send a LEASEQUERY-DATA message without binding 714 data (OPTION_CLIENT_DATA) every ACTIVE_LQ_IDLE_TIMEOUT seconds 715 (default 60) in order for the requestor to know that the connection 716 remains alive. This approach is followed only when connection is 717 idle (i.e., server has no binding data to send). During normal 718 binding data exchange, receiving of LEASEQUERY-DATA message by 719 requestor itself signifies that connection is active. Note that the 720 default for ACTIVE_LQ_RCV_TIMEOUT is 120 seconds, twice the value of 721 the ACTIVE_LQ_IDLE_TIMEOUT's default of 60 seconds which drives the 722 DHCPv6 server to send messages. Thus ACTIVE_LQ_RCV_TIMEOUT controls 723 how sensitive the requestor is to be to delays by the DHCPv6 server 724 in sending updates or LEASEQUERY-DATA messages. 726 A single Active Leasequery can and usually will result in a large 727 number of replies. The Requestor MUST be prepared to receive more 728 than one reply with transaction-ids matching a single 729 ACTIVELEASEQUERY message from a single DHCPv6 server. 731 An Active Leasequery has two regimes -- during the catch-up phase, if 732 any, and after any catch-up phase. If the Active Leasequery was 733 requested with an OPTION_LQ_START_TIME option, the Active Leasequery 734 starts out in the catch-up phase. See Section 8.4.1 for information 735 on processing during the catch-up phase, as well as how to determine 736 when the catch-up phase is complete. 738 The updates sent by the DHCPv6 server during the catch-up phase are 739 not in the order that the lease state data was updated. Therefore, 740 the OPTION_LQ_BASE_TIME option from messages during this phase MUST 741 NOT be saved and used to compute the subsequent ACTIVELEASEQUERY 742 message's OPTION_LQ_START_TIME option. 744 After the catch-up phase, or during the entire series of messages 745 received as the response to an Active Leasequery request with no 746 OPTION_LQ_START_TIME (and therefore no catch-up phase), the 747 OPTION_LQ_BASE_TIME option of the most recent message SHOULD be saved 748 as a record of the most recent time that data was received. This 749 base-time (in the context of the DHCPv6 server) can be used in a 750 subsequent Active Leasequery message's OPTION_LQ_START_TIME after a 751 loss of the Active Leasequery connection. 753 The LEASEQUERY-DONE message MAY unilaterally terminate a successful 754 Active Leasequery request which is currently in progress in the event 755 that the DHCPv6 server determines that it cannot continue processing 756 an ACTIVELEASEQUERY request. For example, when a server is requested 757 to shut down it SHOULD send a LEASEQUERY-DONE message with a DHCPv6 758 status code of QueryTerminated and include OPTION_LQ_BASE_TIME option 759 in the message. This SHOULD be the last message on that connection, 760 and once the message has been transmitted, the server SHOULD close 761 the connection. 763 After receiving LEASEQUERY-DONE with a QueryTerminated status from a 764 server, the Requestor MAY close the TCP connection to that server. 766 8.4.1. Processing Replies from a Request Containing a 767 OPTION_LQ_START_TIME 769 If the Active Leasequery was requested with an OPTION_LQ_START_TIME 770 option, the DHCPv6 server will attempt to send information about all 771 bindings that changed since the time specified in the 772 OPTION_LQ_START_TIME. This is the catch-up phase of the Active 773 Leasequery processing. The DHCPv6 server MAY also begin immediate 774 updates over the same connection of real-time binding information 775 changes. Thus, the catch-up phase can run in parallel with the 776 normal updates generated by the Active Leasequery request. 778 A DHCPv6 server MAY keep only a limited amount of time ordered 779 information available to respond to an Active Leasequery request 780 containing an OPTION_LQ_START_TIME option. Thus, it is possible that 781 the time specified in the OPTION_LQ_START_TIME option represents a 782 time not covered by the time ordered information kept by the DHCPv6 783 server. In such case, when there is not enough data saved in the 784 DHCPv6 server to satisfy the request specified by the 785 OPTION_LQ_START_TIME option, the DHCPv6 server will reply immediately 786 with a LEASEQUERY-REPLY message with a DHCPv6 status code of 787 DataMissing with a base-time option equal to the server's current 788 time. This will signal the end of the catch-up phase, and the only 789 updates that will subsequently be received on this connection are the 790 real-time updates from the Active Leasequery request. 792 If there is enough data saved to satisfy the request, then 793 LEASEQUERY-REPLY (with OPTION_STATUS_CODE of Success or reply without 794 OPTION_STATUS_CODE option) and LEASEQUERY-DATA messages will begin 795 arrive from the DHCPv6 server. Some of these messages will be 796 related to the OPTION_LQ_START_TIME request and be part of the catch- 797 up phase. Some of these messages will be real-time updates of 798 binding changes taking place in the DHCPv6 server. In general, there 799 is no way to determine the source of each message. 801 The updates sent by the DHCPv6 server during the catch-up phase are 802 not in the order that the binding data was updated. Therefore, until 803 the catch-up phase is complete, the latest base-time value received 804 from a DHCPv6 server processing an Active Leasequery request cannot 805 be reset from the incoming messages (and used in a subsequent Active 806 Leasequery's query-start-time option), because to do so would 807 compromise the ability to recover lost information if the Active 808 Leasequery were to terminate prior to the completion of the catch-up 809 phase. 811 The requestor will know that the catch-up phase is complete when the 812 DHCPv6 server will transmit a LEASEQUERY-DATA message with the DHCPv6 813 status code of CatchUpComplete (or LEASEQUERY-REPLY message with a 814 DHCPv6 status code of DataMissing, as discussed above). Once this 815 message is transmitted, all additional LEASEQUERY-DATA messages will 816 relate to real-time ("new") binding changes in the DHCPv6 server. 818 As discussed in Section 8.4, the requestor SHOULD keep track of the 819 latest base-time option value received over a particular connection, 820 to be used in a subsequent Active Leasequery request -- but only if 821 the catch-up phase is complete. Prior to the completion of the 822 catch-up phase, if the connection should go away or if the requestor 823 receives a LEASEQUERY-DONE message, then when it reconnects it MUST 824 use the base-time value from the previous connection and not any 825 base-time value received from the recently closed connection. 827 In the event that there was enough data available to the DHCPv6 828 server to begin to satisfy the request implied by the 829 OPTION_LQ_START_TIME option, but during the processing of that data 830 the server found that it was unable to continue (perhaps there was 831 barely enough, the connection is very slow, and the aging algorithm 832 causes the saved data to become unavailable) the DHCPv6 server will 833 terminate the catch-up phase of processing immediately by sending a 834 LEASEQUERY-DATA message with a DHCPv6 status code of DataMissing and 835 with a base-time option of the current time. 837 The requestor MUST NOT assume that every individual state change of 838 every binding during the period from the time specified in the 839 OPTION_LQ_START_TIME and the present is replicated in an Active 840 Leasequery reply message. The requestor MAY assume that at least one 841 Active Leasequery reply message will exist for every binding which 842 had one or more changes of state during the period specified by the 843 OPTION_LQ_START_TIME and the current time. The last message for each 844 binding will contain the state at the current time, and there can be 845 one or more messages concerning a single binding during the catch-up 846 phase of processing. 848 Bindings can change multiple times while the requestor was not 849 connected (that is, during the time from the OPTION_LQ_START_TIME and 850 the present). The requestor will only receive information about the 851 current state of the binding, not information about each state change 852 that occurred during the period from the OPTION_LQ_START_TIME to the 853 present. 855 If the LEASEQUERY-REPLY or LEASEQUERY-DATA message containing a 856 DHCPv6 status code of DataMissing is received and the requestor is 857 interested in keeping its database up to date with respect to the 858 current state of bindings in the DHCPv6 server, then the requestor 859 SHOULD issue a Bulk Leasequery request to recover the information 860 missing from its database. This Bulk Leasequery request SHOULD 861 include a OPTION_LQ_START_TIME option with the same value as the 862 OPTION_LQ_START_TIME option previously included in the 863 ACTIVELEASEQUERY responses from the DHCPv6 server, and an 864 OPTION_LQ_END_TIME option equal to the OPTION_LQ_BASE_TIME option 865 returned by the DHCPv6 server in the LEASEQUERY-REPLY or LEASEQUERY- 866 DATA message with the DHCPv6 status code of DataMissing. 868 Typically, the requestor would have one connection open to a DHCPv6 869 server for an Active Leasequery request and possibly one additional 870 connection open for a Bulk Leasequery request to the same DHCPv6 871 server to fill in the data that might have been missed prior to the 872 initiation of the Active Leasequery. The Bulk Leasequery connection 873 would typically run to completion and be closed, leaving one Active 874 Leasequery connection open to a single DHCPv6 server. 876 8.5. Processing Time Values in Leasequery messages 878 Active or Bulk Leasequery requests can be made to a DHCPv6 server 879 whose absolute time may not be synchronized with the local time of 880 the requestor. Thus, there are at least two time contexts in even 881 the simplest Active or Bulk Leasequery response. 883 If the requestor of an Active or Bulk Leasequery is saving the data 884 returned in some form, it has a requirement to store a variety of 885 time values, and some of these will be time in the context of the 886 requestor and some will be time in the context of the DHCPv6 server. 888 When receiving an Active or Bulk Leasequery reply message from the 889 DHCPv6 server, the message will contain an OPTION_LQ_BASE_TIME 890 option. The time contained in this OPTION_LQ_BASE_TIME option is in 891 the context of the DHCPv6 server. As such, it is an ideal time to 892 save and use as input to an Active or Bulk Leasequery message in the 893 OPTION_LQ_START_TIME or OPTION_LQ_END_TIME option, should the 894 requestor need to ever issue an Active or Bulk Leasequery message 895 using these option as part of a later query, since these option 896 requires a time in the context of the DHCPv6 server. 898 In addition to saving the OPTION_LQ_BASE_TIME for possible future use 899 in OPTION_LQ_START_TIME or OPTION_LQ_END_TIME option, the 900 OPTION_LQ_BASE_TIME is used as part of the conversion of the other 901 times in the Leasequery message to values which are meaningful in the 902 context of the requestor. 904 In systems whose clocks are synchronized, perhaps using NTP, the 905 clock skew will usually be zero, which is not only acceptable, but 906 desired. 908 8.6. Examples 910 These examples illustrate what a series of queries and responses 911 might look like. These are only examples -- there are no requirement 912 that these sequence must be followed. 914 8.6.1. Query Failure 916 This example illustrates the message flows in case DHCPv6 server 917 identifies that it cannot accept and/or process Active Leasequery 918 request from the requestor. This could be because of various reasons 919 (i.e., UnknownQueryType, MalformedQuery, NotConfigured, NotAllowed, 920 NotSupported). 922 Client Server 923 ------ ------ 924 ACTIVELEASEQUERY xid 1 -----> 925 <----- LEASEQUERY-REPLY xid 1 (w/error) 927 8.6.2. Data Missing on Server 929 This example illustrates the message flows in case DHCPv6 server 930 identifies that it does not have enough data saved to satisfy the 931 request specified by the OPTION_LQ_START_TIME option. 933 In this case the DHCPv6 server will reply immediately with a 934 LEASEQUERY-REPLY message with a DHCPv6 status code of DataMissing 935 with a base-time option equal to the server's current time. This 936 will signal the end of the catch-up phase, and the only updates that 937 will subsequently be received on this connection are the real-time 938 updates from the Active Leasequery request. 940 Client Server 941 ------ ------ 942 ACTIVELEASEQUERY xid 2 -----> 943 <----- LEASEQUERY-REPLY xid 2 (w/error) 944 <----- LEASEQUERY-DATA xid 2 945 <----- LEASEQUERY-DATA xid 2 946 <----- LEASEQUERY-DATA xid 2 948 8.6.3. Successful Query 950 This example illustrates the message flows in case of successful 951 query processing by DHCPv6 server. 953 In this case the DHCPv6 server will reply immediately with a 954 LEASEQUERY-REPLY message (with OPTION_STATUS_CODE of Success or reply 955 without OPTION_STATUS_CODE option), followed by binding data in 956 LEASEQUERY-DATA messages. In case, DHCPv6 server wants to abort in- 957 process request and terminate the connection due to some reason, it 958 sends LEASEQUERY-DONE with error code present in OPTION_STATUS_CODE 959 option. 961 Client Server 962 ------ ------ 963 ACTIVELEASEQUERY xid 3 -----> 964 <----- LEASEQUERY-REPLY xid 3 965 <----- LEASEQUERY-DATA xid 3 966 <----- LEASEQUERY-DATA xid 3 967 <----- LEASEQUERY-DATA xid 3 968 <----- LEASEQUERY-DATA xid 3 969 <----- LEASEQUERY-DONE xid 3 (w/error) 971 8.7. Closing Connections 973 The Requestor or DHCPv6 Leasequery server MAY close its end of the 974 TCP connection at any time. The Requestor MAY choose to retain the 975 connection if it intends to issue additional queries. Note that this 976 requestor behavior does not guarantee that the connection will be 977 available for additional queries: the server might decide to close 978 the connection based on its own configuration. 980 9. Server Behavior 982 A DHCPv6 server which supports Active Leasequery MUST support DHCPv6 983 Bulk Leasequery [RFC5460] and as extended herein. 985 9.1. Accepting Connections 987 DHCPv6 servers that implement DHCPv6 Active Leasequery listen for 988 incoming TCP connections. The approach used in accepting the 989 requestor's connection is same as specified in DHCPv6 Bulk Leasequery 990 [RFC5460], with the exception that support for Active Leasequery MUST 991 NOT be enabled by default, and MUST require an explicit configuration 992 step to be performed before it will operate. 994 DHCPv6 servers SHOULD be able to operate in either insecure or secure 995 mode. This MAY be a mode that is administratively controlled, where 996 the server will require a TLS connection to operate or will only 997 operate without a TLS connection. In either case, operation in 998 insecure mode MUST NOT be the default, even if operation in secure 999 mode is not supported. Operation in insecure mode MUST always 1000 require an explicit configuration step, separate from the 1001 configuration step required to enable support for Active Leasequery. 1003 When operating in insecure mode, the DHCPv6 server simply waits for 1004 the requestor to send the Active Leasequery request after the 1005 establishment of TCP connection. If it receives a STARTTLS message, 1006 it MUST respond with REPLY [RFC3315] message with DHCPv6 status code 1007 of TLSConnectionRefused. 1009 When operating in secure mode, DHCPv6 servers MUST support TLS 1010 [RFC5246] to protect the integrity and privacy of the data 1011 transmitted over the TCP connection. When operating in secure mode, 1012 DHCPv6 servers MUST be configurable with regard to which requestors 1013 they will communicate. The certificate presented by a requestor when 1014 initiating the TLS connection is used to distinguish between 1015 acceptable and unacceptable requestors. 1017 When operating in secure mode, DHCPv6 server MUST begin to negotiate 1018 a TLS connection with a requestor who asks for one, and MUST close he 1019 TCP connections which are not secured with TLS or for which the 1020 requestor's certificate is deemed unacceptable. The recommendations 1021 in [RFC7525] SHOULD be followed when negotiating a TLS connection. 1023 A requestor will request a TLS connection by sending a STARTTLS as 1024 the first message over a newly created TCP connection. If the DHCPv6 1025 server supports TLS connections and has not been configured to not 1026 allow them on this link, the DHCPv6 server MUST respond to this 1027 STARTTLS message by sending a REPLY [RFC3315] message without DHCPv6 1028 status code back to the requestor. This indicates to the requestor 1029 that the DHCPv6 server will support the negotiation of a TLS 1030 connection over this existing TCP connection. 1032 If for some reason the DHCPv6 server cannot or has been configured to 1033 not support a TLS connection, then it SHOULD send a REPLY message 1034 with DHCPv6 status code of TLSConnectionRefused back to the 1035 requestor. 1037 In the event that the DHCPv6 server sends a REPLY message without 1038 DHCPv6 status code option included (which indicates success), the 1039 requestor is supposed to initiate a TLS handshake [RFC5246] (see 1040 Section 8.2). During the TLS handshake, the DHCPv6 server MUST 1041 validate the requestor's digital certificate. In addition, the 1042 digital certificate presented by the requestor is used to decide if 1043 this requestor is allowed to perform an Active Leasequery. If this 1044 requestor's certificate is deemed unacceptable, the server MUST abort 1045 the creation of the TLS connection. 1047 All TLS connections established between the a requestor and a DHCPv6 1048 server for the purposes of supporting Active Leasequery MUST be 1049 mutually authenticated. 1051 If the TLS handshake is not successful in creating a TLS connection, 1052 the server MUST close the TCP connection. 1054 9.2. Rejecting Connections 1056 Servers that do not implement DHCPv6 Active and Bulk Leasequery 1057 SHOULD NOT listen for incoming TCP connections for these requests. 1059 If the DHCPv6 server supporting Bulk Leasequery and not Active 1060 Leasequery receives an Active Leasequery request, it SHOULD send a 1061 LEASEQUERY-REPLY with DHCPv6 status code as NotSupported. It SHOULD 1062 close the TCP connection after this error is signaled. 1064 9.3. Replying to an Active Leasequery 1066 The DHCPv6 Leasequery [RFC5007] specification describes the initial 1067 construction of LEASEQUERY-REPLY messages. Use of the LEASEQUERY- 1068 REPLY and LEASEQUERY-DATA messages to carry multiple bindings is 1069 described in DHCPv6 Bulk Leasequery [RFC5460]. Message transmission 1070 and framing for TCP is described in Section 6.1. 1072 If the connection becomes blocked while the server is attempting to 1073 send reply messages, the server SHOULD terminate the TCP connection 1074 after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs for how long the 1075 DHCPv6 server is prepared to wait for the requestor to read and 1076 process enough information to unblock the TCP connection. The 1077 default is two minutes, which means that if more than two minutes 1078 goes by without the requestor reading enough information to unblock 1079 the TCP connection, the DHCPv6 server SHOULD close the TCP 1080 connection. 1082 If the DHCPv6 server encounters an error during initial processing of 1083 the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-REPLY 1084 message containing an error code of some kind in a DHCPv6 status code 1085 option. It SHOULD close the connection after this error is signaled. 1087 If the DHCPv6 server encounters an error during later processing of 1088 the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-DONE 1089 containing an error code of some kind in a DHCPv6 status code option. 1090 It SHOULD close the connection after this error is signaled. 1092 If the server finds any bindings satisfying a query, it SHOULD send 1093 each binding's data in a reply message. The first reply message is a 1094 LEASEQUERY-REPLY. The binding data is carried in an 1095 OPTION_CLIENT_DATA option, as specified in [RFC5007]. The server 1096 SHOULD send subsequent bindings in LEASEQUERY-DATA messages, which 1097 can avoid redundant data (such as the requestor's Client-ID). 1099 Every reply to an Active Leasequery request MUST contain the 1100 information specified in replies to a DHCPv6 Bulk Leasequery request 1101 [RFC5460], with the exception that a server implementing Active 1102 Leasequery SHOULD be able to be configured to prevent specific data 1103 items from being sent to the requestor even if these data items were 1104 requested in the OPITON_ORO option. 1106 Some servers can be configured to respond to a DHCPv6 Leasequery 1107 [RFC5007] and DHCPv6 Bulk Leasequery [RFC5460] for an IPv6 binding 1108 which is reserved in such a way that it appears that the IPv6 binding 1109 is leased to the DHCP client for which it is reserved. These servers 1110 SHOULD also respond to an Active Leasequery request with the same 1111 information as they would to a Bulk Leasequery request when they 1112 first determine that the IPv6 binding is reserved to a DHCP client. 1114 If an Active Leasequery or Bulk Leasequery request contains 1115 OPTION_LQ_BASE_TIME option code present in OPTION_ORO, the DHCPv6 1116 server MUST include OPTION_LQ_BASE_TIME option in every reply for 1117 this request. The value for base-time option is current absolute 1118 time in the DHCPv6 server's context. 1120 If an Active Leasequery request contains an OPTION_LQ_START_TIME 1121 option, it indicates that the requestor would like the DHCPv6 server 1122 to send it not only messages that correspond to DHCPv6 binding 1123 activity that occurs subsequent to the receipt of the Active 1124 Leasequery request, but also messages that correspond to DHCPv6 1125 binding activity that occurred prior to the Active Leasequery 1126 request. 1128 If OPTION_LQ_END_TIME option appears in an Active Leasequery request, 1129 the DHCPv6 server SHOULD send a LEASEQUERY-REPLY message with a 1130 DHCPv6 status code of MalformedQuery and terminate the connection. 1132 In order to implement a meaningful response to this query, the DHCPv6 1133 server MAY keep track of the binding activity and associate changes 1134 with particular base-time values from the messages. Then, when 1135 requested to do so by an Active Leasequery request containing a 1136 OPTION_LQ_START_TIME option, the DHCPv6 server can respond with 1137 replies for all binding activity occurring on that 1138 OPTION_LQ_START_TIME or later times. 1140 These replies based on the OPTION_LQ_START_TIME MAY be interleaved 1141 with the messages generated due to current binding activity. 1143 Once the transmission of the DHCPv6 Leasequery messages associated 1144 with the OPTION_LQ_START_TIME option are complete, a LEASEQUERY-DATA 1145 message MUST be sent with a DHCPv6 status code value of 1146 CatchUpComplete. 1148 The DHCPv6 server SHOULD, but is not required to, keep track of a 1149 limited amount of previous binding activity. The DHCPv6 server MAY 1150 choose to only do this in the event that it has received at least one 1151 Active Leasequery request in the past, as to do so will almost 1152 certainly entail some utilization of resources which would be wasted 1153 if there are no Active Leasequery requestors for this DHCPv6 server. 1154 The DHCPv6 server SHOULD make the amount of previous binding activity 1155 it retains configurable. There is no requirement on the DHCPv6 1156 server to retain this information over a server restart (or even to 1157 retain such information at all). 1159 Unless there is an error or some requirement to cease processing a 1160 Active Leasequery request yielding a LEASEQUERY-DONE message, such as 1161 a server shutdown, there will be no LEASEQUERY-DONE message at the 1162 conclusion of the Active Leasequery processing because that 1163 processing will not conclude but will continue until either the 1164 requestor or the server closes the connection. 1166 9.4. Multiple or Parallel Queries 1168 Every Active Leasequery request MUST be made on a single TCP 1169 connection where there is no other request active at the time the 1170 request is made. 1172 Typically, a requestor of an Active Leasequery would not need to send 1173 a second Active Leasequery while the first is still active. However, 1174 sending an Active Leasequery and a Bulk Leasequery in parallel would 1175 be possible and reasonable. In case of parallel Active and Bulk 1176 Leasequeries, the requestor MUST use different TCP connections. 1178 This MAY be a feature that is administratively controlled. Servers 1179 that are able to process queries in parallel SHOULD offer 1180 configuration that limits the number of simultaneous queries 1181 permitted from any one requestor, in order to control resource use if 1182 there are multiple requestors seeking service. 1184 9.5. Closing Connections 1186 The server MUST close its end of the TCP connection if it encounters 1187 an error sending data on the connection. The server MUST close its 1188 end of the TCP connection if it finds that it has to abort an in- 1189 process request. A server aborting an in-process request SHOULD 1190 attempt to signal that to its requestors by using the QueryTerminated 1191 status code in the DHCPv6 status code option in a LEASEQUERY-DONE 1192 message. If the server detects that the requestor end has been 1193 closed, the server MUST close its end of the connection. 1195 The server SHOULD limit the number of connections it maintains, and 1196 SHOULD close idle connections to enforce the limit. 1198 10. Security Considerations 1200 The "Security Considerations" section of [RFC3315] details the 1201 general threats to DHCPv6. The DHCPv6 Leasequery specification 1202 [RFC5007] describes recommendations for the Leasequery protocol, 1203 especially with regard to relayed Leasequery messages, mitigation of 1204 packet-flooding denial-of-service (DoS) attacks, restriction to 1205 trusted requestors, and use of IPsec [RFC4301]. 1207 The use of TCP introduces some additional concerns. Attacks that 1208 attempt to exhaust the DHCPv6 server's available TCP connection 1209 resources can compromise the ability of legitimate requestors to 1210 receive service. Malicious requestors who succeed in establishing 1211 connections, but who then send invalid queries, partial queries, or 1212 no queries at all also can exhaust a server's pool of available 1213 connections. 1215 When operating in secure mode, TLS [RFC5246] is used to secure the 1216 connection. The recommendations in [RFC7525] SHOULD be followed when 1217 negotiating a TLS connection. 1219 Servers SHOULD offer configuration parameters to limit the sources of 1220 incoming connections through validation and use of the digital 1221 certificates presented to create a TLS connection. They SHOULD also 1222 limit the number of accepted connections, and limit the period of 1223 time during which an idle connection will be left open. 1225 The data acquired by using an Active Leasequery is subject to the 1226 same potential abuse as the data held by the DHCPv6 server from which 1227 it was acquired, and SHOULD be secured by mechanisms as strong as 1228 those used for the data held by that DHCPv6 server. The data 1229 acquired by using an Active Leasequery SHOULD be deleted as soon as 1230 possible after the use for which it was acquired has passed. 1232 Authentication for DHCP Messages [RFC3315] MUST NOT be used to 1233 attempt to secure transmission of the messages described in this 1234 document. 1236 11. IANA Considerations 1238 IANA is requested to assign new DHCPv6 Option Codes in the registry 1239 maintained in http://www.iana.org/assignments/dhcpv6-parameters: 1241 OPTION_LQ_BASE_TIME TBD-1 1243 OPTION_LQ_START_TIME TBD-2 1245 OPTION_LQ_END_TIME TBD-3 1247 IANA is requested to assign new values in the registry of DHCPv6 1248 Status Codes maintained in http://www.iana.org/assignments/ 1249 dhcpv6-parameters: 1251 DataMissing 1253 CatchUpComplete 1255 NotSupported 1257 TLSConnectionRefused 1259 IANA is requested to assign values for the following new DHCPv6 1260 Message types in the registry maintained in 1261 http://www.iana.org/assignments/dhcpv6-parameters: 1263 ACTIVELEASEQUERY 1265 STARTTLS 1267 12. Acknowledgments 1269 Some of the concept and content, present in this document, are based 1270 on DHCPv4 Active Leasequery which was originally proposed by Kim 1271 Kinnear, Bernie Volz, Mark Stapp and Neil Russell. 1273 Useful review comments were provided by Scott Bradner, Francis 1274 Dupont, and Stephen Farrell. The privacy protections were 1275 substantially upgraded due to these comments and discussions. 1277 13. Modification History 1279 14. References 1281 14.1. Normative References 1283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1284 Requirement Levels", BCP 14, RFC 2119, 1285 DOI 10.17487/RFC2119, March 1997, 1286 . 1288 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1289 C., and M. Carney, "Dynamic Host Configuration Protocol 1290 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1291 2003, . 1293 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1294 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1295 DOI 10.17487/RFC3633, December 2003, 1296 . 1298 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 1299 "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, 1300 September 2007, . 1302 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1303 (TLS) Protocol Version 1.2", RFC 5246, 1304 DOI 10.17487/RFC5246, August 2008, 1305 . 1307 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 1308 DOI 10.17487/RFC5460, February 2009, 1309 . 1311 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1312 "Recommendations for Secure Use of Transport Layer 1313 Security (TLS) and Datagram Transport Layer Security 1314 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1315 2015, . 1317 14.2. Informative References 1319 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1320 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1321 December 2005, . 1323 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 1324 Zimmermann, "A Roadmap for Transmission Control Protocol 1325 (TCP) Specification Documents", RFC 7414, 1326 DOI 10.17487/RFC7414, February 2015, 1327 . 1329 Authors' Addresses 1330 Dushyant Raghuvanshi 1331 Cisco Systems, Inc. 1332 Cessna Business Park, 1333 Varthur Hobli, Outer Ring Road, 1334 Bangalore, Karnataka 560037 1335 India 1337 Phone: +91 80 4426-7372 1338 Email: draghuva@cisco.com 1340 Kim Kinnear 1341 Cisco Systems, Inc. 1342 1414 Massachusetts Ave. 1343 Boxborough, Massachusetts 01719 1344 USA 1346 Phone: +1 978 936-0000 1347 Email: kkinnear@cisco.com 1349 Deepak Kukrety 1350 Cisco Systems, Inc. 1351 Cessna Business Park, 1352 Varthur Hobli, Outer Ring Road, 1353 Bangalore, Karnataka 560037 1354 India 1356 Phone: +91 80 4426-7346 1357 Email: dkukrety@cisco.com