idnits 2.17.1 draft-ietf-dhc-dhcpv6-active-leasequery-03.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 (June 9, 2015) is 3238 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) Summary: 3 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: December 11, 2015 June 9, 2015 8 DHCPv6 Active Leasequery 9 draft-ietf-dhc-dhcpv6-active-leasequery-03 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 December 11, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6.3.1. OPTION_LQ_BASE_TIME . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 13 78 8.3. Forming an Active Leasequery . . . . . . . . . . . . . . 14 79 8.4. Processing Active Replies . . . . . . . . . . . . . . . . 15 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 . . . . . . 19 83 8.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 20 84 8.6.1. Query Failure . . . . . . . . . . . . . . . . . . . . 20 85 8.6.2. Data Missing on Server . . . . . . . . . . . . . . . 20 86 8.6.3. Successful Query . . . . . . . . . . . . . . . . . . 21 87 8.7. Closing Connections . . . . . . . . . . . . . . . . . . . 21 88 9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 22 89 9.1. Accepting Connections . . . . . . . . . . . . . . . . . . 22 90 9.2. Rejecting Connections . . . . . . . . . . . . . . . . . . 23 91 9.3. Replying to an Active Leasequery . . . . . . . . . . . . 23 92 9.4. Multiple or Parallel Queries . . . . . . . . . . . . . . 25 93 9.5. Closing Connections . . . . . . . . . . . . . . . . . . . 25 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 95 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 96 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 97 13. Modification History . . . . . . . . . . . . . . . . . . . . 27 98 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 99 14.1. Normative References . . . . . . . . . . . . . . . . . . 27 100 14.2. Informative References . . . . . . . . . . . . . . . . . 27 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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 the 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 identical to 233 [RFC5460], except that in the case of Active Leasequery the server 234 sends updates whenever some activity occurs to change the binding 235 state - thus the need for long lived connection. 237 Active Leasequery has features which allow this external entity to 238 lose its connection and then reconnect and receive the latest 239 information concerning any IPv6 bindings changed while it was not 240 connected. 242 These features are designed to allow the Active Leasequery requestor 243 to efficiently become current with respect to the lease state 244 database after it has been restarted or the machine on which it is 245 running has been reinitialized. It is easy to define a protocol 246 which works when the requestor is always connected to the DHCPv6 247 server. Since that isn't sufficiently robust, much of the mechanism 248 in this document is designed to deal efficiently with situations that 249 occur when the Active Leasequery requestor becomes disconnected from 250 the DHCPv6 server from which it is receiving updates and then 251 reconnects to that server. 253 Central to this approach, if the Active Leasequery requestor loses 254 service, it is allowed to specify the time of its most recent update 255 in a subsequent Active Leasequery request and the DHCPv6 server will 256 determine whether or not data was missed while the Active Leasequery 257 requestor was not connected. 259 The DHCPv6 server processing the Active Leasequery request may limit 260 the amount of data saved, and methods exist for the DHCPv6 server to 261 inform the Active Leasequery requestor that data was missed - not all 262 could be saved. In this situation, the Active Leasequery requestor 263 should issue a Bulk Leasequery [RFC5460] to recover information not 264 available through an Active Leasequery. 266 DHCPv6 servers are not required to keep any data corresponding to 267 data missed on an Active Leasequery connection, but will typically 268 choose to keep data corresponding to some recent activity available 269 for subsequent queries by a DHCPv6 Active Leasequery requestor whose 270 connection was temporarily interrupted. In other words, DHCPv6 271 servers supporting catch-up are required to have some mechanism to 272 keep/save historic information of bindings. 274 An Active Leasequery requestor would typically use Bulk Leasequery to 275 initialize its database with all current data when that database 276 contains no binding information. In addition, it would use Bulk 277 Leasequery to recover missed information in the event that its 278 connection with the DHCPv6 server was lost for a longer time than the 279 DHCPv6 server would keep track of the specific changes to the IPv6 280 binding information. 282 The messages sent by the server in response to an Active Leasequery 283 request should be identical to the messages sent by the server to a 284 Bulk Leasequery request regarding the way the data is encoded into 285 the Active Leasequery responses. In addition, the actions taken by 286 the Active Leasequery requestor to interpret the responses to an 287 Active Leasequery request should be identical to the way that the 288 requestor interprets the responses to a Bulk Leasequery request. 289 Thus, the handling of OPTION_CLIENT_DATA and additional options 290 discussed in the Bulk Leasequery specification [RFC5460] are to be 291 followed when implementing Active Leasequery. 293 4. Interaction Between Active Leasequery and Bulk Leasequery 295 Active Leasequery is an extension of the Bulk Leasequery protocol 296 [RFC5460]. The format of messages returned to an Active Leasequery 297 requestor are identical to that defined for the Bulk Leasequery 298 protocol [RFC5460]. 300 Applications which employ Active Leasequery to keep a database up to 301 date with respect to the DHCPv6 server's lease state database should 302 use an initial Bulk Leasequery to bring their database into 303 equivalence with that of the DHCPv6 server, and then use Active 304 Leasequery to keep that database current with respect to the DHCPv6 305 server's lease state database. 307 There are several differences between the Active and Bulk Leasequery 308 protocols. Active Leasequery defines a new message 309 (ACTIVELEASEQUERY) to send Active Leasequery request to DHCPv6 310 server. An Active Leasequery connection sends all available updates 311 to the requestor, based on OPTION_LQ_QUERY option (see 312 Section 6.2.1). 314 An Active Leasequery connection does not ever "complete", though the 315 DHCPv6 server may drop the connection for a variety of reasons 316 associated with some sort of exception condition. 318 5. Extension to DHCPv6 Bulk Leasequery 320 This document extends to the capabilities of DHCPv6 Bulk Leasequery 321 protocol [RFC5460] by defining new options (OPTION_LQ_BASE_TIME, 322 OPTION_LQ_START_TIME and OPTION_LQ_END_TIME). DHCPv6 server sends 323 OPTION_LQ_BASE_TIME option in Bulk Leasequery response if requestor 324 ask for the same in Bulk Leasequery request. OPTION_LQ_START_TIME 325 and OPTION_LQ_END_TIME can be used in Bulk Leasequery request made to 326 DHCPv6 server. More details about these options are specified in 327 Section 6.3. 329 6. Message and Option Definitions 331 6.1. Message Framing for TCP 333 The use of TCP for the Active Leasequery protocol permits one or more 334 DHCPv6 messages to be sent in response to single Active Leasequery 335 request. The receiver needs to be able to determine how large each 336 message is. The same message framing technique used for DHCPv6 Bulk 337 Leasequery [RFC5460] is used for Active Leasequery as well. 339 The intent in using the same format is that code which currently 340 knows how to deal with a message returned from DHCPv6 Bulk Leasequery 341 [RFC5460] will be able to deal with the message held inside of the 342 TCP framing. 344 6.2. Messages 346 6.2.1. ACTIVELEASEQUERY 348 The new message type (ACTIVELEASEQUERY) is designed for keeping the 349 requestor up to date in real-time (or near real-time) with DHCPv6 350 bindings. It asks the server to return DHCPv6 bindings activity that 351 occurs subsequent to the receipt of the Active Leasequery request. 353 An ACTIVELEASEQUERY request MUST contain a transaction-id, and that 354 transaction-id MUST BE locally unique on the TCP connection on which 355 it is sent to the DHCPv6 server. 357 When sending an Active Leasequery request, the requestor MAY include 358 the OPTION_LQ_START_TIME option in the ACTIVELEASEQUERY request. In 359 this case, DHCPv6 server returns all the bindings changed on or after 360 the OPTION_LQ_START_TIME. 362 If the requestor is interested in receiving all binding updates from 363 the DHCPv6 server, it MUST NOT include the OPTION_LQ_QUERY option in 364 the ACTIVELEASEQUERY message. But if the requestor is only 365 interested in specific binding updates, it MAY include an 366 OPTION_LQ_QUERY option along with a query-types defined in [RFC5007] 367 and [RFC5460]. 369 Other DHCPv6 options used in the LEASEQUERY message (as specified in 370 [RFC5460]) can also be used in the ACTIVELEASEQUERY request. 372 6.2.2. STARTTLS 374 The new message type (STARTTLS) is designed for establishment of a 375 TLS connection between requestor and DHCPv6 server. 377 More details about this message are specified in Section 8.2. 379 6.2.3. Response Messages 381 The LEASEQUERY-REPLY message is defined in [RFC5007]. The 382 LEASEQUERY-DATA and LEASEQUERY-DONE messages are defined in 383 [RFC5460]. 385 In an Active Leasequery exchange, a single LEASEQUERY-REPLY message 386 is used to indicate the success or failure of a query, and to carry 387 data that do not change in the context of a single query and answer, 388 such as the Server-ID and Client-ID options. If a query is 389 successful, the DHCPv6 server MUST respond to it with exactly one 390 LEASEQUERY-REPLY message. If the server is returning binding data, 391 the LEASEQUERY-REPLY also contains the first client's binding data in 392 an OPTION_CLIENT_DATA option. Additional binding data is returned 393 using LEASEQUERY-DATA message as explained in DHCPv6 Bulk Leasequery 394 [RFC5460]. In case of failure query, single LEASEQUERY-REPLY message 395 is returned without any binding data. 397 6.3. Options 399 New options (OPTION_LQ_BASE_TIME, OPTION_LQ_START_TIME and 400 OPTION_LQ_END_TIME) are defined as an extension to DHCPv6 Bulk 401 Leasequery [RFC5460]. The reply messages for Active Leasequery uses 402 these options along with the options defined in [RFC3315], [RFC5007] 403 and [RFC5460]. 405 6.3.1. OPTION_LQ_BASE_TIME 407 The OPTION_LQ_BASE_TIME option is the current time the message was 408 created to be sent by the DHCPv6 server to the requestor of the 409 Active or Bulk Leasequery if requestor ask for the same in Active or 410 Bulk Leasequery request. This MUST be an absolute time (i.e. seconds 411 since midnight January 1, 2000 UTC). All of the other time based 412 options in the reply message are relative to this time, including 413 OPTION_CLT_TIME [RFC5007]. This time is in the context of the DHCPv6 414 server who placed this option in a message. 416 This is an unsigned integer in network byte order. 418 The code for this option is TBD. 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | OPTION_LQ_BASE_TIME | option-len | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | base-time | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 option-code OPTION_LQ_BASE_TIME (TBD). 429 option-len 4. 430 base-time DHCPv6 Server Base Time. 432 6.3.2. OPTION_LQ_START_TIME 434 The OPTION_LQ_START_TIME option specifies a query start time to the 435 DHCPv6 server. If specified, only bindings that have changed on or 436 after the OPTION_LQ_START_TIME should be included in the response to 437 the query. This option MAY be used in Active or Bulk Leasequery 438 requests made to a DHCPv6 server. 440 The requestor MUST determine the OPTION_LQ_START_TIME using lease 441 information it has received from the DHCPv6 server. This MUST be an 442 absolute time in the DHCPv6 server's context (see Section 8.5). 444 Typically (though this is not a requirement) the OPTION_LQ_START_TIME 445 option will contain the value most recently received in a 446 OPTION_LQ_BASE_TIME option by the requestor, as this will indicate 447 the last successful communication with the DHCPv6 server. 449 This is an unsigned integer in network byte order. 451 The code for this option is TBD. 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | OPTION_LQ_START_TIME | option-len | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | query-start-time | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 option-code OPTION_LQ_START_TIME (TBD). 462 option-len 4. 463 query-start-time DHCPv6 Server Query Start Time. 465 6.3.3. OPTION_LQ_END_TIME 467 The OPTION_LQ_END_TIME option specifies a query end time to the 468 DHCPv6 server. If specified, only bindings that have changed on or 469 before the OPTION_LQ_END_TIME should be included in the response to 470 the query. This option MAY be used in a Bulk Leasequery request. 471 But it MUST NOT be used in an Active Leasequery request. 473 The requestor MUST determine the OPTION_LQ_END_TIME based on lease 474 information it has received from the DHCPv6 server. This MUST be an 475 absolute time in the context of the DHCPv6 server. 477 In the absence of information to the contrary, the requestor SHOULD 478 assume that the time context of the DHCPv6 server is identical to the 479 time context of the requestor (see Section 8.5). 481 This is an unsigned integer in network byte order. 483 The code for this option is TBD. 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | OPTION_LQ_END_TIME | option-len | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | query-end-time | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 option-code OPTION_LQ_END_TIME (TBD). 494 option-len 4. 495 query-end-time DHCPv6 Server Query End Time. 497 6.4. Connection and Transmission Parameters 499 Active Leasequery uses the same port configuration as DHCPv6 Bulk 500 Leasequery [RFC5460]. It also uses the other transmission parameters 501 (BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [RFC5460]. 503 This section presents a table of values used to control Active 504 Leasequery behavior, including recommended defaults. Implementations 505 MAY make these values configurable. However, configuring too-small 506 timeout values may lead to harmful behavior both to this application 507 as well as to other traffic in the network. As a result, timeout 508 values smaller than the default values SHOULD NOT be used. 510 +------------------------+----------+-------------------------------+ 511 | Parameter | Default | Description | 512 +------------------------+----------+-------------------------------+ 513 | ACTIVE_LQ_RCV_TIMEOUT | 120 secs | Active Leasequery receive | 514 | | | timeout | 515 | ACTIVE_LQ_SEND_TIMEOUT | 120 secs | Active Leasequery send | 516 | | | timeout | 517 | ACTIVE_LQ_IDLE_TIMEOUT | 60 secs | Active Leasequery idle | 518 | | | timeout | 519 +------------------------+----------+-------------------------------+ 521 7. Information Communicated by Active Leasequery 523 While the information communicated by a DHCPv6 Bulk Leasequery 524 [RFC5460] is taken directly from the DHCPv6 server's lease state 525 database, the information communicated by an Active Leasequery is 526 real-time information. As such, it is the information which is 527 currently associated with a particular binding in the DHCPv6 server's 528 lease state database. 530 This is of significance, because if the Active Leasequery requestor 531 runs slowly or the requestor disconnects from the DHCPv6 server and 532 then reconnects with an OPTION_LQ_START_TIME option (signaling a 533 catch-up operation), the information communicated to the Active 534 Leasequery requestor is only the most current information from the 535 DHCPv6 server's lease state database. 537 The requestor of an Active Leasequery MUST NOT assume that every 538 lease state change is communicated across an Active Leasequery 539 connection. Even if the Active Leasequery requestor remains 540 connected, the DHCPv6 server is only required to transmit information 541 about a binding that is current when the message is created and 542 handed off to the TCP stack to send to the requestor. 544 If the TCP connection blocks and the DHCPv6 server is waiting to send 545 information down the connection, when the connection becomes 546 available to be written the DHCPv6 server MAY create the message to 547 send at this time. The current state of the binding will be sent, 548 and any transition in state or other information that occurred while 549 the TCP connection was blocked will be lost. 551 Thus, the Active Leasequery protocol does not allow the requestor to 552 build a complete history of every activity on every lease. An 553 effective history of the important state changes for a lease can be 554 created if the parameters of the DHCPv6 server are tuned to take into 555 account the requirements of an Active Leasequery requestor. For 556 instance, the period after the expiration or release of a binding 557 could be configured long enough (say several minutes, well more than 558 the receive timeout), so that an Active Leasequery requestor would be 559 less likely to miss any changes in the binding. 561 8. Requestor Behavior 563 8.1. General Processing 565 A requestor attempts to establish a TCP connection to a DHCPv6 Server 566 in order to initiate an Active Leasequery exchange. If the attempt 567 fails, the Requestor MAY retry. 569 If an Active Leasequery is terminated prematurely by a LEASEQUERY- 570 DONE with a DHCPv6 status code (carried in an OPTION_STATUS_CODE 571 option) of QueryTerminated or by the failure of the connection over 572 which it was being submitted, the requestor MAY retry the request 573 after the creation of a new connection. 575 Messages from the DHCPv6 server come as multiple responses to a 576 single ACTIVELEASEQUERY message. Thus, each ACTIVELEASEQUERY request 577 MUST have an xid (transaction-id) unique on the connection on which 578 it is sent, and all of the messages which come as a response to it 579 contain the same xid as the request. It is the xid which allows the 580 data-streams of two or more different ACTIVELEASEQUERY requests to be 581 de-multiplexed by the requestor. 583 8.2. Initiating a Connection 585 A Requestor SHOULD be able to operate in either insecure or secure 586 mode. This MAY be a feature that is administratively controlled. 588 When operating in insecure mode, requestor should proceed with the 589 Active Leasequery request after the establishment of a TCP 590 connection. 592 When operating in secure mode, requestor MUST attempt to negotiate a 593 TLS [RFC5246] connection over the TCP connection. If this 594 negotiation fails, the requestor MUST drop the TCP connection. 596 A requestor requests the establishment of a TLS connection by sending 597 the STARTTLS message to the DHCPv6 server as the first message over 598 the TCP connection. This message indicates to the DHCPv6 server that 599 a TLS connection over this TCP connection is desired. There are four 600 possibilities after the requestor sends the STARTTLS message to the 601 DHCPv6 server: 603 1. No response from the DHCPv6 server. 605 2. The DHCPv6 server drops the TCP connection after it receives the 606 STARTTLS message. 608 3. DHCPv6 server responds with REPLY [RFC3315] message with DHCPv6 609 status code of TLSConnectionRefused. 611 4. DHCPv6 server responds with REPLY [RFC3315] message without 612 DHCPv6 status code, indicating success. 614 In any of the first three possibilities, the DHCPv6 server can be 615 assumed to not support TLS. In this case, the requestor MUST drop 616 the TCP connection. 618 In the final possibility, where the DHCPv6 server has responded with 619 a REPLY message without DHCPv6 status code in response to the 620 requestor's STARTTLS message, the requestor SHOULD initiate the 621 exchange of the messages involved in a TLS handshake [RFC5246]. 622 During the TLS handshake, the requestor MUST verify DHCPv6 server's 623 digital certificate. 625 If the handshake exchange yields a functioning TLS connection, then 626 the requestor SHOULD transmit an Active Leasequery message over that 627 TLS connection and use that TLS connection for all further 628 interactions in which it engages with the DHCPv6 server over this TCP 629 connection. 631 If the handshake exchange does not yield a functioning TLS 632 connection, then the requestor MUST drop the TCP connection. 634 8.3. Forming an Active Leasequery 636 The Active Leasequery is designed to create a long lived connection 637 between the requestor and the DHCPv6 server processing the active 638 query. The DHCPv6 server SHOULD send binding information back across 639 this connection with minimal delay after it learns of the binding 640 information. It learns about bindings either because it makes the 641 bindings itself or because it has received information about a 642 binding from another server. 644 An important capability of the Active Leasequery is the ability of 645 the requestor to specify that some recent data be sent immediately to 646 the requestor in parallel with the transmission of the ongoing 647 binding information in more or less real time. This capability is 648 used in order to allow an Active Leasequery requestor to recover 649 missed information in the event that it temporarily loses 650 connectivity with the DHCPv6 server processing a previous Active 651 Leasequery. 653 Note that until all of the recent data (catch-up data) has been 654 received, the requestor MUST NOT keep track of the base-time 655 (OPTION_LQ_BASE_TIME) received in Leasequery reply messages to use 656 later in a subsequent Active Leasequery request. 658 This capability is enabled by the transmission of an 659 OPTION_LQ_BASE_TIME option with each Leasequery reply sent as the 660 result of a previous Active Leasequery. The requestor SHOULD keep 661 track of the highest base-time received from a particular DHCPv6 662 server over an Active Leasequery connection, and in the event that 663 the requestor finds it necessary (for whatever reason) to reestablish 664 an Active Leasequery connection to that DHCPv6 server, the requestor 665 SHOULD place this highest base-time value into an 666 OPTION_LQ_START_TIME option in the new Active Leasequery request. 668 If the requestor doesn't wish to request an update of information 669 missed when it was not connected to the DHCPv6 server, then it SHOULD 670 NOT include the OPTION_LQ_START_TIME option in the Active Leasequery 671 request. 673 If the TCP connection becomes blocked or stops being writable while 674 the requestor is sending its query, the requestor SHOULD terminate 675 the connection after BULK_LQ_DATA_TIMEOUT. We make this 676 recommendation to allow requesters to control the period of time they 677 are willing to wait before abandoning a connection, independent of 678 notifications from the TCP implementations they may be using. 680 8.4. Processing Active Replies 682 The Requestor attempts to read a DHCPv6 LEASEQUERY-REPLY message from 683 the TCP connection. If the stream of replies becomes blocked, the 684 Requestor SHOULD terminate the connection after 685 ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured 686 to do so. 688 The requestor examines the LEASEQUERY-REPLY message, and determines 689 how to proceed. Message validation rules are specified in DHCPv6 690 Leasequery [RFC5007] and DHCPv6 Bulk Leasequery [RFC5460]. If the 691 reply contains an DHCPv6 status code (carried in an 692 OPTION_STATUS_CODE option), the requestor should follow the 693 recommendations in [RFC5007]. 695 Note that an Active Leasequery request specifically requests the 696 DHCPv6 server to create a long-lived connection which may not have 697 data transferring continuously during its lifetime. Therefore the 698 DHCPv6 server SHOULD send a LEASEQUERY-DATA message without binding 699 data (OPTION_CLIENT_DATA) every ACTIVE_LQ_IDLE_TIMEOUT seconds 700 (default 60) in order for the requestor to know that the connection 701 remains alive. This approach is followed only when connection is 702 idle (i.e. server has no binding data to send). During normal 703 binding data exchange, receiving of LEASEQUERY-DATA message by 704 requestor itself signifies that connection is active. Note that the 705 default for ACTIVE_LQ_RCV_TIMEOUT is 120 seconds, twice the value of 706 the ACTIVE_LQ_IDLE_TIMEOUT's default of 60 seconds which drives the 707 DHCPv6 server to send messages. Thus ACTIVE_LQ_RCV_TIMEOUT controls 708 how sensitive the requestor is to be to delays by the DHCPv6 server 709 in sending updates or LEASEQUERY-DATA messages. 711 A single Active Leasequery can and usually will result in a large 712 number of replies. The Requestor MUST be prepared to receive more 713 than one reply with transaction-ids matching a single 714 ACTIVELEASEQUERY message from a single DHCPv6 server. 716 An Active Leasequery has two regimes -- during the catch-up phase, if 717 any, and after any catch-up phase. If the Active Leasequery was 718 requested with an OPTION_LQ_START_TIME option, the Active Leasequery 719 starts out in the catch-up phase. See Section 8.4.1 for information 720 on processing during the catch-up phase, as well as how to determine 721 when the catch-up phase is complete. 723 The updates sent by the DHCPv6 server during the catch-up phase are 724 not in the order that the lease state data was updated. Therefore, 725 the OPTION_LQ_BASE_TIME option from messages during this phase MUST 726 NOT be saved and used to compute the subsequent ACTIVELEASEQUERY 727 message's OPTION_LQ_START_TIME option. 729 After the catch-up phase, or during the entire series of messages 730 received as the response to an Active Leasequery request with no 731 OPTION_LQ_START_TIME (and therefore no catch-up phase), the 732 OPTION_LQ_BASE_TIME option of the most recent message SHOULD be saved 733 as a record of the most recent time that data was received. This 734 base-time (in the context of the DHCPv6 server) can be used in a 735 subsequent Active Leasequery message's OPTION_LQ_START_TIME after a 736 loss of the Active Leasequery connection. 738 The LEASEQUERY-DONE message MAY unilaterally terminate a successful 739 Active Leasequery request which is currently in progress in the event 740 that the DHCPv6 server determines that it cannot continue processing 741 an ACTIVELEASEQUERY request. For example, when a server is requested 742 to shut down it SHOULD send a LEASEQUERY-DONE message with a DHCPv6 743 status code of QueryTerminated and include OPTION_LQ_BASE_TIME option 744 in the message. This SHOULD be the last message on that connection, 745 and once the message has been transmitted, the server should close 746 the connection. 748 After receiving LEASEQUERY-DONE with a QueryTerminated status from a 749 server, the Requestor MAY close the TCP connection to that server. 751 8.4.1. Processing Replies from a Request Containing a 752 OPTION_LQ_START_TIME 754 If the Active Leasequery was requested with an OPTION_LQ_START_TIME 755 option, the DHCPv6 server will attempt to send information about all 756 bindings that changed since the time specified in the 757 OPTION_LQ_START_TIME. This is the catch-up phase of the Active 758 Leasequery processing. The DHCPv6 server MAY also begin immediate 759 updates over the same connection of real-time binding information 760 changes. Thus, the catch-up phase may run in parallel with the 761 normal updates generated by the Active Leasequery request. 763 A DHCPv6 server MAY keep only a limited amount of time ordered 764 information available to respond to an Active Leasequery request 765 containing an OPTION_LQ_START_TIME option. Thus, it is possible that 766 the time specified in the OPTION_LQ_START_TIME option represents a 767 time not covered by the time ordered information kept by the DHCPv6 768 server. If this should occur, and there is not enough data saved in 769 the DHCPv6 server to satisfy the request specified by the 770 OPTION_LQ_START_TIME option, the DHCPv6 server will reply immediately 771 with a LEASEQUERY-REPLY message with a DHCPv6 status code of 772 DataMissing with a base-time option equal to the server's current 773 time. This will signal the end of the catch-up phase, and the only 774 updates that will subsequently be received on this connection are the 775 real-time updates from the Active Leasequery request. 777 If there is enough data saved to satisfy the request, then 778 LEASEQUERY-REPLY (with OPTION_STATUS_CODE of Success or reply without 779 OPTION_STATUS_CODE option) and LEASEQUERY-DATA messages will begin 780 arrive from the DHCPv6 server. Some of these messages will be 781 related to the OPTION_LQ_START_TIME request and be part of the catch- 782 up phase. Some of these messages will be real-time updates of 783 binding changes taking place in the DHCPv6 server. In general, there 784 is no way to determine the source of each message. 786 The updates sent by the DHCPv6 server during the catch-up phase are 787 not in the order that the binding data was updated. Therefore, until 788 the catch-up phase is complete, the latest base-time value received 789 from a DHCPv6 server processing an Active Leasequery request cannot 790 be reset from the incoming messages (and used in a subsequent Active 791 Leasequery's query-start-time option), because to do so would 792 compromise the ability to recover lost information if the Active 793 Leasequery were to terminate prior to the completion of the catch-up 794 phase. 796 The requestor will know that the catch-up phase is complete when the 797 DHCPv6 server will transmit a LEASEQUERY-DATA message with the DHCPv6 798 status code of CatchUpComplete (or LEASEQUERY-REPLY message with a 799 DHCPv6 status code of DataMissing, as discussed above). Once this 800 message is transmitted, all additional LEASEQUERY-DATA messages will 801 relate to real-time ("new") binding changes in the DHCPv6 server. 803 As discussed in Section 8.4, the requestor SHOULD keep track of the 804 latest base-time option value received over a particular connection, 805 to be used in a subsequent Active Leasequery request -- but only if 806 the catch-up phase is complete. Prior to the completion of the 807 catch-up phase, if the connection should go away or if the requestor 808 receives a LEASEQUERY-DONE message, then when it reconnects it MUST 809 use the base-time value from the previous connection and not any 810 base-time value received from the recently closed connection. 812 In the event that there was enough data available to the DHCPv6 813 server to begin to satisfy the request implied by the 814 OPTION_LQ_START_TIME option, but during the processing of that data 815 the server found that it was unable to continue (perhaps there was 816 barely enough, the connection is very slow, and the aging algorithm 817 causes the saved data to become unavailable) the DHCPv6 server will 818 terminate the catch-up phase of processing immediately by sending a 819 LEASEQUERY-DATA message with a DHCPv6 status code of DataMissing and 820 with a base-time option of the current time. 822 The requestor MUST NOT assume that every individual state change of 823 every binding during the period from the time specified in the 824 OPTION_LQ_START_TIME and the present is replicated in an Active 825 Leasequery reply message. The requestor MAY assume that at least one 826 Active Leasequery reply message will exist for every binding which 827 had one or more changes of state during the period specified by the 828 OPTION_LQ_START_TIME and the current time. The last message for each 829 binding will contain the state at the current time, and there may be 830 one or more messages concerning a single binding during the catch-up 831 phase of processing. 833 Bindings can change multiple times while the requester was not 834 connected (that is, during the time from the OPTION_LQ_START_TIME and 835 the present). The requestor will only receive information about the 836 current state of the binding, not information about each state change 837 that occurred during the period from the OPTION_LQ_START_TIME to the 838 present. 840 If the LEASEQUERY-REPLY or LEASEQUERY-DATA message containing a 841 DHCPv6 status code of DataMissing is received and the requestor is 842 interested in keeping its database up to date with respect to the 843 current state of bindings in the DHCPv6 server, then the requestor 844 SHOULD issue a Bulk Leasequery request to recover the information 845 missing from its database. This Bulk Leasequery request should 846 include a OPTION_LQ_START_TIME option with the same value as the 847 OPTION_LQ_START_TIME option previously included in the 848 ACTIVELEASEQUERY responses from the DHCPv6 server, and an 849 OPTION_LQ_END_TIME option equal to the OPTION_LQ_BASE_TIME option 850 returned by the DHCPv6 server in the LEASEQUERY-REPLY or LEASEQUERY- 851 DATA message with the DHCPv6 status code of DataMissing. 853 Typically, the requestor would have one connection open to a DHCPv6 854 server for an Active Leasequery request and possibly one additional 855 connection open for a Bulk Leasequery request to the same DHCPv6 856 server to fill in the data that might have been missed prior to the 857 initiation of the Active Leasequery. The Bulk Leasequery connection 858 would typically run to completion and be closed, leaving one Active 859 Leasequery connection open to a single DHCPv6 server. Alternatively, 860 both requests could be issued over a single connection. 862 8.5. Processing Time Values in Leasequery messages 864 Active or Bulk Leasequery requests may be made to a DHCPv6 server 865 whose absolute time may not be synchronized with the local time of 866 the requestor. Thus, there are at least two time contexts in even 867 the simplest Active or Bulk Leasequery response. 869 If the requestor of an Active or Bulk Leasequery is saving the data 870 returned in some form, it has a requirement to store a variety of 871 time values, and some of these will be time in the context of the 872 requestor and some will be time in the context of the DHCPv6 server. 874 When receiving an Active or Bulk Leasequery reply message from the 875 DHCPv6 server, the message will contain an OPTION_LQ_BASE_TIME 876 option. The time contained in this OPTION_LQ_BASE_TIME option is in 877 the context of the DHCPv6 server. As such, it is an ideal time to 878 save and use as input to an Active or Bulk Leasequery message in the 879 OPTION_LQ_START_TIME or OPTION_LQ_END_TIME option, should the 880 requestor need to ever issue an Active or Bulk Leasequery message 881 using these option as part of a later query, since these option 882 requires a time in the context of the DHCPv6 server. 884 In addition to saving the OPTION_LQ_BASE_TIME for possible future use 885 in OPTION_LQ_START_TIME or OPTION_LQ_END_TIME option, the 886 OPTION_LQ_BASE_TIME is used as part of the conversion of the other 887 times in the Leasequery message to values which are meaningful in the 888 context of the requestor. 890 In systems whose clocks are synchronized, perhaps using NTP, the 891 clock skew will usually be zero, which is not only acceptable, but 892 desired. 894 8.6. Examples 896 These examples illustrate what a series of queries and responses 897 might look like. These are only examples -- there are no requirement 898 that these sequence must be followed. 900 8.6.1. Query Failure 902 This example illustrates the message flows in case DHCPv6 server 903 identifies that it cannot accept and/or process Active Leasequery 904 request from the requestor. This could be because of various reasons 905 (i.e. UnknownQueryType, MalformedQuery, NotConfigured, NotAllowed, 906 NotSupported). 908 Client Server 909 ------ ------ 910 ACTIVELEASEQUERY xid 1 -----> 911 <----- LEASEQUERY-REPLY xid 1 (w/error) 913 8.6.2. Data Missing on Server 915 This example illustrates the message flows in case DHCPv6 server 916 identifies that it does not have enough data saved to satisfy the 917 request specified by the OPTION_LQ_START_TIME option. 919 In this case the DHCPv6 server will reply immediately with a 920 LEASEQUERY-REPLY message with a DHCPv6 status code of DataMissing 921 with a base-time option equal to the server's current time. This 922 will signal the end of the catch-up phase, and the only updates that 923 will subsequently be received on this connection are the real-time 924 updates from the Active Leasequery request. 926 Client Server 927 ------ ------ 928 ACTIVELEASEQUERY xid 2 -----> 929 <----- LEASEQUERY-REPLY xid 2 (w/error) 930 <----- LEASEQUERY-DATA xid 2 931 <----- LEASEQUERY-DATA xid 2 932 <----- LEASEQUERY-DATA xid 2 934 8.6.3. Successful Query 936 This example illustrates the message flows in case of successful 937 query processing by DHCPv6 server. 939 In this case the DHCPv6 server will reply immediately with a 940 LEASEQUERY-REPLY message (with OPTION_STATUS_CODE of Success or reply 941 without OPTION_STATUS_CODE option), followed by binding data in 942 LEASEQUERY-DATA messages. In case, DHCPv6 server wants to abort in- 943 process request and terminate the connection due to some reason, it 944 sends LEASEQUERY-DONE with error code present in OPTION_STATUS_CODE 945 option. 947 Client Server 948 ------ ------ 949 ACTIVELEASEQUERY xid 3 -----> 950 <----- LEASEQUERY-REPLY xid 3 951 <----- LEASEQUERY-DATA xid 3 952 <----- LEASEQUERY-DATA xid 3 953 <----- LEASEQUERY-DATA xid 3 954 <----- LEASEQUERY-DATA xid 3 955 <----- LEASEQUERY-DONE xid 3 (w/error) 957 8.7. Closing Connections 959 The Requestor or DHCPv6 Leasequery server MAY close its end of the 960 TCP connection at any time. The Requestor MAY choose to retain the 961 connection if it intends to issue additional queries. Note that this 962 requestor behavior does not guarantee that the connection will be 963 available for additional queries: the server might decide to close 964 the connection based on its own configuration. 966 9. Server Behavior 968 A DHCPv6 server which supports Active Leasequery MUST support DHCPv6 969 Bulk Leasequery [RFC5460] and as extended herein. 971 9.1. Accepting Connections 973 DHCPv6 servers that implement DHCPv6 Active Leasequery listen for 974 incoming TCP connections. Approach used in accepting the requestor 975 connection is same as specified in DHCPv6 Bulk Leasequery [RFC5460]. 977 DHCPv6 servers SHOULD be able to operate in either insecure or secure 978 mode. This MAY be a mode that is administratively controlled, where 979 the server will require a TLS connection to operate or will only 980 operate without a TLS connection. 982 When operating in insecure mode, DHCPv6 server simply waits for the 983 requestor to send the Active Leasequery request after the 984 establishment of TCP connection. If it receives a STARTTLS message, 985 it MUST respond with REPLY [RFC3315] message with DHCPv6 status code 986 of TLSConnectionRefused. 988 When operating in secure mode, DHCPv6 servers MUST support TLS 989 [RFC5246] to protect the integrity and privacy of the data 990 transmitted over the TCP connection. DHCPv6 servers SHOULD negotiate 991 a TLS connection with the requestor who asks for one, and MUST drop 992 the TCP connections which are not secured with TLS. 994 A requestor will request a TLS connection by sending a STARTTLS as 995 the first message over a newly created TCP connection. If the DHCPv6 996 server supports TLS connections and has not been configured to not 997 allow them on this link, the DHCPv6 server SHOULD respond to this 998 STARTTLS message by sending a REPLY [RFC3315] message without DHCPv6 999 status code back to the requestor. This indicates to the requestor 1000 that the DHCPv6 server will support the negotiation of a TLS 1001 connection over this existing TCP connection. 1003 If for some reason the DHCPv6 server cannot or has been configured to 1004 not support a TLS connection, then it SHOULD send a REPLY message 1005 with DHCPv6 status code of TLSConnectionRefused back to the 1006 requestor. 1008 In the event that the DHCPv6 server sends a REPLY message without 1009 DHCPv6 status code option included (which indicates success), the 1010 requestor is supposed to initiate a TLS handshake [RFC5246] (see 1011 Section 8.2). During the TLS handshake, the DHCPv6 server MUST 1012 verify the requestor's digital certificate. 1014 If the TLS handshake is not successful in creating a TLS connection, 1015 the server MUST drop the TCP connection. 1017 9.2. Rejecting Connections 1019 Servers that do not implement DHCPv6 Active and Bulk Leasequery 1020 SHOULD NOT listen for incoming TCP connections for these requests. 1022 If the DHCPv6 server supporting Bulk Leasequery and not Active 1023 Leasequery receives an Active Leasequery request, it SHOULD send a 1024 LEASEQUERY-REPLY with DHCPv6 status code as NotSupported. It SHOULD 1025 close the TCP connection after this error is signaled. 1027 9.3. Replying to an Active Leasequery 1029 The DHCPv6 Leasequery [RFC5007] specification describes the initial 1030 construction of LEASEQUERY-REPLY messages. Use of the LEASEQUERY- 1031 REPLY and LEASEQUERY-DATA messages to carry multiple bindings is 1032 described in DHCPv6 Bulk Leasequery [RFC5460]. Message transmission 1033 and framing for TCP is described in Section 6.1. 1035 If the connection becomes blocked while the server is attempting to 1036 send reply messages, the server SHOULD terminate the TCP connection 1037 after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs for how long the 1038 DHCPv6 server is prepared to wait for the requestor to read and 1039 process enough information to unblock the TCP connection. The 1040 default is two minutes, which means that if more than two minutes 1041 goes by without the requestor reading enough information to unblock 1042 the TCP connection, the DHCPv6 server SHOULD drop the TCP connection. 1044 If the DHCPv6 server encounters an error during initial processing of 1045 the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-REPLY 1046 message containing an error code of some kind in a DHCPv6 status code 1047 option. It SHOULD close the connection after this error is signaled. 1049 If the DHCPv6 server encounters an error during later processing of 1050 the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-DONE 1051 containing an error code of some kind in a DHCPv6 status code option. 1052 It SHOULD close the connection after this error is signaled. 1054 If the server finds any bindings satisfying a query, it SHOULD send 1055 each binding's data in a reply message. The first reply message is a 1056 LEASEQUERY-REPLY. The binding data is carried in an 1057 OPTION_CLIENT_DATA option, as specified in [RFC5007]. The server 1058 SHOULD send subsequent bindings in LEASEQUERY-DATA messages, which 1059 can avoid redundant data (such as the requestor's Client-ID). 1061 Every reply to an Active Leasequery request MUST contain the 1062 information specified in replies to a DHCPv6 Bulk Leasequery request 1063 [RFC5460]. 1065 Some servers can be configured to respond to a DHCPv6 Leasequery 1066 [RFC5007] and DHCPv6 Bulk Leasequery [RFC5460] for an IPv6 binding 1067 which is reserved in such a way that it appears that the IPv6 binding 1068 is leased to the DHCP client for which it is reserved. These servers 1069 SHOULD also respond to an Active Leasequery request with the same 1070 information as they would to a Bulk Leasequery request when they 1071 first determine that the IPv6 binding is reserved to a DHCP client. 1073 If an Active Leasequery or Bulk Leasequery request contains 1074 OPTION_LQ_BASE_TIME option code present in OPTION_ORO, the DHCPv6 1075 server MUST include OPTION_LQ_BASE_TIME option in every reply for 1076 this request. The value for base-time option is current absolute 1077 time in the DHCPv6 server's context. 1079 If an Active Leasequery request contains an OPTION_LQ_START_TIME 1080 option, it indicates that the requestor would like the DHCPv6 server 1081 to send it not only messages that correspond to DHCPv6 binding 1082 activity that occurs subsequent to the receipt of the Active 1083 Leasequery request, but also messages that correspond to DHCPv6 1084 binding activity that occurred prior to the Active Leasequery 1085 request. 1087 If OPTION_LQ_END_TIME option appears in an Active Leasequery request, 1088 the DHCPv6 server SHOULD send a LEASEQUERY-REPLY message with a 1089 DHCPv6 status code of MalformedQuery and terminate the connection. 1091 In order to implement a meaningful response to this query, the DHCPv6 1092 server MAY keep track of the binding activity and associate changes 1093 with particular base-time values from the messages. Then, when 1094 requested to do so by an Active Leasequery request containing a 1095 OPTION_LQ_START_TIME option, the DHCPv6 server can respond with 1096 replies for all binding activity occurring on that 1097 OPTION_LQ_START_TIME or later times. 1099 These replies based on the OPTION_LQ_START_TIME MAY be interleaved 1100 with the messages generated due to current binding activity. 1102 Once the transmission of the DHCPv6 Leasequery messages associated 1103 with the OPTION_LQ_START_TIME option are complete, a LEASEQUERY-DATA 1104 message MUST be sent with a DHCPv6 status code value of 1105 CatchUpComplete. 1107 The DHCPv6 server SHOULD, but is not required to, keep track of a 1108 limited amount of previous binding activity. The DHCPv6 server MAY 1109 choose to only do this in the event that it has received at least one 1110 Active Leasequery request in the past, as to do so will almost 1111 certainly entail some utilization of resources which would be wasted 1112 if there are no Active Leasequery requestors for this DHCPv6 server. 1113 The DHCPv6 server SHOULD make the amount of previous binding activity 1114 it retains configurable. There is no requirement on the DHCPv6 1115 server to retain this information over a server restart (or even to 1116 retain such information at all). 1118 Unless there is an error or some requirement to cease processing a 1119 Active Leasequery request yielding a LEASEQUERY-DONE message, such as 1120 a server shutdown, there will be no LEASEQUERY-DONE message at the 1121 conclusion of the Active Leasequery processing because that 1122 processing will not conclude but will continue until either the 1123 requestor or the server drops the connection. 1125 9.4. Multiple or Parallel Queries 1127 Every Active Leasequery request MUST be made on a single TCP 1128 connection where there is no other request active at the time the 1129 request is made. 1131 Typically, a requestor of an Active Leasequery would not need to send 1132 a second Active Leasequery while the first is still active. However, 1133 sending an Active Leasequery and a Bulk Leasequery in parallel would 1134 be possible and reasonable. In case of parallel Active and Bulk 1135 Leasequeries, requestor MUST use different TCP connections. 1137 This MAY be a feature that is administratively controlled. Servers 1138 that are able to process queries in parallel SHOULD offer 1139 configuration that limits the number of simultaneous queries 1140 permitted from any one requestor, in order to control resource use if 1141 there are multiple requesters seeking service. 1143 9.5. Closing Connections 1145 The server MUST close its end of the TCP connection if it encounters 1146 an error sending data on the connection. The server MUST close its 1147 end of the TCP connection if it finds that it has to abort an in- 1148 process request. A server aborting an in-process request SHOULD 1149 attempt to signal that to its requestors by using the QueryTerminated 1150 status code in the DHCPv6 status code option in a LEASEQUERY-DONE 1151 message. If the server detects that the requestor end has been 1152 closed, the server MUST close its end of the connection. 1154 The server SHOULD limit the number of connections it maintains, and 1155 SHOULD close idle connections to enforce the limit. 1157 10. Security Considerations 1159 The "Security Considerations" section of [RFC3315] details the 1160 general threats to DHCPv6. The DHCPv6 Leasequery specification 1161 [RFC5007] describes recommendations for the Leasequery protocol, 1162 especially with regard to relayed Leasequery messages, mitigation of 1163 packet-flooding denial-of-service (DoS) attacks, restriction to 1164 trusted requestors, and use of IPsec [RFC4301]. 1166 The use of TCP introduces some additional concerns. Attacks that 1167 attempt to exhaust the DHCPv6 server's available TCP connection 1168 resources can compromise the ability of legitimate requestors to 1169 receive service. Malicious requestors who succeed in establishing 1170 connections, but who then send invalid queries, partial queries, or 1171 no queries at all also can exhaust a server's pool of available 1172 connections. We recommend that servers offer configuration to limit 1173 the sources of incoming connections, that they limit the number of 1174 accepted connections, and that they limit the period of time during 1175 which an idle connection will be left open. 1177 Authentication for DHCP Messages [RFC3315] MUST NOT be used to 1178 attempt to secure transmission of the messages described in this 1179 document. 1181 11. IANA Considerations 1183 IANA is requested to assign new DHCPv6 Option Codes in the registry 1184 maintained in http://www.iana.org/assignments/dhcpv6-parameters: 1186 OPTION_LQ_BASE_TIME 1188 OPTION_LQ_START_TIME 1190 OPTION_LQ_END_TIME 1192 IANA is requested to assign new values in the registry of DHCPv6 1193 Status Codes maintained in http://www.iana.org/assignments/ 1194 dhcpv6-parameters: 1196 DataMissing 1198 CatchUpComplete 1200 NotSupported 1202 TLSConnectionRefused 1204 IANA is requested to assign values for the following new DHCPv6 1205 Message types in the registry maintained in 1206 http://www.iana.org/assignments/dhcpv6-parameters: 1208 ACTIVELEASEQUERY 1210 STARTTLS 1212 12. Acknowledgements 1214 Some of the concept and content, present in this document, are based 1215 on DHCPv4 Active Leasequery which was originally proposed by Kim 1216 Kinnear, Bernie Volz, Mark Stapp and Neil Russell. 1218 13. Modification History 1220 14. References 1222 14.1. Normative References 1224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1225 Requirement Levels", BCP 14, RFC 2119, March 1997. 1227 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1228 and M. Carney, "Dynamic Host Configuration Protocol for 1229 IPv6 (DHCPv6)", RFC 3315, July 2003. 1231 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1232 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1233 December 2003. 1235 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 1236 "DHCPv6 Leasequery", RFC 5007, September 2007. 1238 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1239 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1241 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 1242 2009. 1244 14.2. Informative References 1246 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1247 Internet Protocol", RFC 4301, December 2005. 1249 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 1250 Zimmermann, "A Roadmap for Transmission Control Protocol 1251 (TCP) Specification Documents", RFC 7414, February 2015. 1253 Authors' Addresses 1255 Dushyant Raghuvanshi 1256 Cisco Systems, Inc. 1257 Cessna Business Park, 1258 Varthur Hobli, Outer Ring Road, 1259 Bangalore, Karnataka 560037 1260 India 1262 Phone: +91 (080) 4365-7476 1263 Email: draghuva@cisco.com 1265 Kim Kinnear 1266 Cisco Systems, Inc. 1267 1414 Massachusetts Ave. 1268 Boxborough, Massachusetts 01719 1269 USA 1271 Phone: +1 (978) 936-0000 1272 Email: kkinnear@cisco.com 1274 Deepak Kukrety 1275 Cisco Systems, Inc. 1276 Cessna Business Park, 1277 Varthur Hobli, Outer Ring Road, 1278 Bangalore, Karnataka 560037 1279 India 1281 Phone: +91 (080) 4365-7474 1282 Email: dkukrety@cisco.com