idnits 2.17.1 draft-ietf-dhc-dhcpv6-active-leasequery-02.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 (March 2, 2015) is 3342 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 informational reference (is this intentional?): RFC 4614 (Obsoleted by RFC 7414) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 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: September 3, 2015 March 2, 2015 8 DHCPv6 Active Leasequery 9 draft-ietf-dhc-dhcpv6-active-leasequery-02 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 September 3, 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 . . . . . . . . . . . . . 7 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.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.3.1. OPTION_LQ_BASE_TIME . . . . . . . . . . . . . . . . . 9 70 6.3.2. OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 10 71 6.3.3. OPTION_LQ_END_TIME . . . . . . . . . . . . . . . . . 11 72 6.4. Connection and Transmission Parameters . . . . . . . . . 11 73 7. Information Communicated by Active Leasequery . . . . . . . . 12 74 8. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 13 75 8.1. General Processing . . . . . . . . . . . . . . . . . . . 13 76 8.2. Initiating a Connection . . . . . . . . . . . . . . . . . 13 77 8.3. Forming an Active Leasequery . . . . . . . . . . . . . . 14 78 8.4. Processing Active Replies . . . . . . . . . . . . . . . . 15 79 8.4.1. Processing Replies from a Request Containing a 80 OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 17 81 8.5. Processing Time Values in Leasequery messages . . . . . . 19 82 8.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 20 83 8.6.1. Query Failure . . . . . . . . . . . . . . . . . . . . 20 84 8.6.2. Data Missing on Server . . . . . . . . . . . . . . . 20 85 8.6.3. Successful Query . . . . . . . . . . . . . . . . . . 20 86 8.7. Closing Connections . . . . . . . . . . . . . . . . . . . 21 87 9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 21 88 9.1. Accepting Connections . . . . . . . . . . . . . . . . . . 21 89 9.2. Rejecting Connections . . . . . . . . . . . . . . . . . . 22 90 9.3. Replying to an Active Leasequery . . . . . . . . . . . . 22 91 9.4. Multiple or Parallel Queries . . . . . . . . . . . . . . 24 92 9.5. Closing Connections . . . . . . . . . . . . . . . . . . . 25 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 95 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 96 13. Modification History . . . . . . . . . . . . . . . . . . . . 27 97 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 98 14.1. Normative References . . . . . . . . . . . . . . . . . . 27 99 14.2. Informative References . . . . . . . . . . . . . . . . . 27 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 102 1. Introduction 104 The DHCPv6 [RFC3315] protocol specifies a mechanism for the 105 assignment of IPv6 address and configuration information to IPv6 106 nodes. IPv6 Prefix Delegation for DHCPv6 (PD) [RFC3633] specifies a 107 mechanism for DHCPv6 delegation of IPv6 prefixes and related data. 108 DHCPv6 servers maintain authoritative information including binding 109 information for delegated IPv6 prefixes. 111 Requirements exist for external entities to keep up to date on the 112 correspondence between DHCPv6 clients and their bindings. These 113 entities need to keep up with the current binding activity of the 114 DHCPv6 server. Keeping up with these binding activity is termed 115 "active" leasequery. 117 The DHCPv6 Bulk Leasequery [RFC5460] capability can be used to 118 recover useful information from a DHCPv6 server when some external 119 entity starts up. This entity could be one which is directly 120 involved in the DHCPv6 client - server transactions (e.g., a relay 121 agent), or it could be an external process which needs information 122 present in the DHCPv6 server's lease state database. 124 The Active Leasequery capability documented here is designed to allow 125 an entity not directly involved in DHCPv6 client - server 126 transactions to nevertheless keep current with the state of the 127 DHCPv6 lease state information in real-time. 129 This document updates DHCPv6 Bulk Leasequery [RFC5460] by adding new 130 options, as described in Section 6.2.1. For the DHCPv6 servers, 131 supporting Bulk Leasequery and not Active Leasequery, Section 9.2 132 specifies the mechanism to reject incoming Active Leasequery 133 requests. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 DHCPv6 terminology is defined in [RFC3315]. Terminology specific to 142 DHCPv6 Active Leasequery can be found below: 144 o "Absolute Time" 145 A 32-bit quantity containing the number of seconds since midnight 146 January 1, 2000 UTC. 148 o "Active Leasequery" 150 Keeping up to date in real-time (or near real-time) with DHCPv6 151 binding activity. 153 o "Bulk Leasequery" 155 Requesting and receiving the information about all or some of the 156 existing DHCPv6 binding information in an efficient manner, as 157 defined by [RFC5460]. 159 o "blocked TCP connection" 161 A TCP connection is considered blocked if the underlying TCP 162 transport will not accept new messages to be sent without blocking 163 the thread that is attempting to send the message. 165 o "binding change/update" 167 Any change in the DHCPv6 binding state or data stored on the 168 DHCPv6 server related to binding. This also includes expiration 169 or deletion of the binding. 171 o "catch-up information, catch-up phase" 173 If a DHCPv6 Active Leasequery requestor sends OPTION_LQ_START_TIME 174 option in an ACTIVELEASEQUERY message, the DHCPv6 server will 175 attempt to send the requestor the information that changed since 176 the time specified in the OPTION_LQ_START_TIME option. The 177 binding information sent to satisfy this request is the catch-up 178 information, and the period while it is being sent is the catch-up 179 phase. 181 o "clock skew" 183 The difference between the absolute time on a DHCPv6 server and 184 the absolute time on the system where a requestor of an Active or 185 Bulk Leasequery is executing is termed the "clock skew" for that 186 Active or Bulk Leasequery connection. It is not absolutely 187 constant but is likely to vary only slowly. While it is easy to 188 think that this can be calculated precisely after one message is 189 received by a requestor from a DHCPv6 server, a more accurate 190 value is derived from continuously examining the instantaneous 191 value developed from each message received from a DHCPv6 server 192 and using it to make small adjustments to the existing value held 193 in the requestor. 195 o "requestor" 197 The node that sends LEASEQUERY messages to one or more servers to 198 retrieve information on the bindings for a client. 200 o "Transaction ID" 202 An opaque value used to match responses with queries initiated by 203 an Active Leasequery requestor. 205 3. Protocol Overview 207 The Active Leasequery mechanism is modeled on the existing DHCPv6 208 Bulk Leasequery [RFC5460]; most differences arise from the long term 209 nature of the TCP [RFC4614] connection required for Active 210 Leasequery. A DHCPv6 server which supports Active Leasequery MUST 211 support Bulk Leasequery [RFC5460] as well. 213 An Active Leasequery requestor opens a TCP connection to a DHCPv6 214 Server, using the DHCPv6 port 547. Note that this implies that the 215 Leasequery requestor has server IP address(es) available via 216 configuration or some other means, and that it has unicast IP 217 reachability to the DHCPv6 server. No relaying for Active Leasequery 218 is specified. 220 After establishing a connection, the requestor sends an 221 ACTIVELEASEQUERY message over the connection. In response, the 222 server sends updates to the requestor using LEASEQUERY-REPLY and 223 LEASEQUERY-DATA messages. This response procedure is identical to 224 [RFC5460], except that in the case of Active Leasequery the server 225 sends updates whenever some activity occurs to change the binding 226 state - thus the need for long lived connection. 228 Active Leasequery has features which allow this external entity to 229 lose its connection and then reconnect and receive the latest 230 information concerning any IPv6 bindings changed while it was not 231 connected. 233 These features are designed to allow the Active Leasequery requestor 234 to efficiently become current with respect to the lease state 235 database after it has been restarted or the machine on which it is 236 running has been reinitialized. It is easy to define a protocol 237 which works when the requestor is always connected to the DHCPv6 238 server. Since that isn't sufficiently robust, much of the mechanism 239 in this document is designed to deal efficiently with situations that 240 occur when the Active Leasequery requestor becomes disconnected from 241 the DHCPv6 server from which it is receiving updates and then 242 reconnects to that server. 244 Central to this approach, if the Active Leasequery requestor loses 245 service, it is allowed to specify the time of its most recent update 246 in a subsequent Active Leasequery request and the DHCPv6 server will 247 determine whether or not data was missed while the Active Leasequery 248 requestor was not connected. 250 The DHCPv6 server processing the Active Leasequery request may limit 251 the amount of data saved, and methods exist for the DHCPv6 server to 252 inform the Active Leasequery requestor that data was missed - not all 253 could be saved. In this situation, the Active Leasequery requestor 254 should issue a Bulk Leasequery [RFC5460] to recover information not 255 available through an Active Leasequery. 257 DHCPv6 servers are not required to keep any data corresponding to 258 data missed on an Active Leasequery connection, but will typically 259 choose to keep data corresponding to some recent activity available 260 for subsequent queries by a DHCPv6 Active Leasequery requestor whose 261 connection was temporarily interrupted. In other words, DHCPv6 262 servers supporting catch-up are required to have some mechanism to 263 keep/save historic information of bindings. 265 An Active Leasequery requestor would typically use Bulk Leasequery to 266 initialize its database with all current data when that database 267 contains no binding information. In addition, it would use Bulk 268 Leasequery to recover missed information in the event that its 269 connection with the DHCPv6 server was lost for a longer time than the 270 DHCPv6 server would keep track of the specific changes to the IPv6 271 binding information. 273 The messages sent by the server in response to an Active Leasequery 274 request SHOULD be identical to the messages sent by the server to a 275 Bulk Leasequery request regarding the way the data is encoded into 276 the Active Leasequery responses. In addition, the actions taken by 277 the Active Leasequery requestor to interpret the responses to an 278 Active Leasequery request SHOULD be identical to the way that the 279 requestor interprets the responses to a Bulk Leasequery request. 280 Thus, the handling of OPTION_CLIENT_DATA and additional options 281 discussed in the Bulk Leasequery specification [RFC5460] are to be 282 followed when implementing Active Leasequery. 284 4. Interaction Between Active Leasequery and Bulk Leasequery 286 Active Leasequery is an extension of the Bulk Leasequery protocol 287 [RFC5460]. The format of messages returned to an Active Leasequery 288 requestor are identical to that defined for the Bulk Leasequery 289 protocol [RFC5460]. 291 Applications which employ Active Leasequery to keep a database up to 292 date with respect to the DHCPv6 server's lease state database will 293 usually use an initial Bulk Leasequery to bring their database into 294 equivalence with that of the DHCPv6 server, and then use Active 295 Leasequery to keep that database current with respect to the DHCPv6 296 server's lease state database. 298 There are several differences between the Active and Bulk Leasequery 299 protocols. Active Leasequery defines a new message 300 (ACTIVELEASEQUERY) to send Active Leasequery request to DHCPv6 301 server. An Active Leasequery connection sends all available updates 302 to the requestor, based on OPTION_LQ_QUERY option (see 303 Section 6.2.1). 305 An Active Leasequery connection does not ever "complete", though the 306 DHCPv6 server may drop the connection for a variety of reasons 307 associated with some sort of exception condition. 309 5. Extension to DHCPv6 Bulk Leasequery 311 This document extends to the capabilities of DHCPv6 Bulk Leasequery 312 protocol [RFC5460] by defining new options (OPTION_LQ_BASE_TIME, 313 OPTION_LQ_START_TIME and OPTION_LQ_END_TIME). DHCPv6 server sends 314 OPTION_LQ_BASE_TIME option in Bulk Leasequery response if requestor 315 ask for the same in Bulk Leasequery request. OPTION_LQ_START_TIME 316 and OPTION_LQ_END_TIME can be used in Bulk Leasequery request made to 317 DHCPv6 server. More details about these options are specified in 318 Section 6.3. 320 6. Message and Option Definitions 322 6.1. Message Framing for TCP 324 The use of TCP for the Active Leasequery protocol permits one or more 325 DHCPv6 messages to be sent in response to single Active Leasequery 326 request. The receiver needs to be able to determine how large each 327 message is. The same message framing technique used for DHCPv6 Bulk 328 Leasequery [RFC5460] is used for Active Leasequery as well. 330 The intent in using the same format is that code which currently 331 knows how to deal with a message returned from DHCPv6 Bulk Leasequery 332 [RFC5460] will be able to deal with the message held inside of the 333 TCP framing. 335 6.2. Messages 337 The LEASEQUERY-REPLY message is defined in [RFC5007]. The 338 LEASEQUERY-DATA and LEASEQUERY-DONE messages are defined in 339 [RFC5460]. 341 In an Active Leasequery exchange, a single LEASEQUERY-REPLY message 342 is used to indicate the success or failure of a query, and to carry 343 data that do not change in the context of a single query and answer, 344 such as the Server-ID and Client-ID options. If a query is 345 successful, the DHCPv6 server MUST respond to it with exactly one 346 LEASEQUERY-REPLY message. If the server is returning binding data, 347 the LEASEQUERY-REPLY also contains the first client's binding data in 348 an OPTION_CLIENT_DATA option. Additional binding data is returned 349 using LEASEQUERY-DATA message as explained in DHCPv6 Bulk Leasequery 350 [RFC5460]. In case of failure query, single LEASEQUERY-REPLY message 351 is returned without any binding data. 353 6.2.1. ACTIVELEASEQUERY 355 The new message type (ACTIVELEASEQUERY) is designed for keeping the 356 requestor up to date in real-time (or near real-time) with DHCPv6 357 bindings. It asks the server to return DHCPv6 bindings activity that 358 occurs subsequent to the receipt of the Active Leasequery request. 360 An ACTIVELEASEQUERY request MUST contain a transaction-id, and that 361 transaction-id MUST BE locally unique on the TCP connection on which 362 it is sent to the DHCPv6 server. 364 When sending an Active Leasequery request, the requestor MAY include 365 the OPTION_LQ_START_TIME option in the ACTIVELEASEQUERY request. In 366 this case, DHCPv6 server returns all the bindings changed on or after 367 the OPTION_LQ_START_TIME. 369 If the requestor is interested in receiving all binding updates from 370 the DHCPv6 server, it MUST NOT include the OPTION_LQ_QUERY option in 371 the ACTIVELEASEQUERY message. But if the requestor is only 372 interested in specific binding updates, it MAY include an 373 OPTION_LQ_QUERY option along with a query-types defined in [RFC5007] 374 and [RFC5460]. 376 Other DHCPv6 options used in the LEASEQUERY message (as specified in 377 [RFC5460]) can also be used in the ACTIVELEASEQUERY request. 379 6.2.2. STARTTLS 381 The new message type (STARTTLS) is designed for establishment of a 382 TLS connection between requestor and DHCPv6 server. 384 More details about this message are specified in Section 8.2. 386 6.3. Options 388 New options (OPTION_LQ_BASE_TIME, OPTION_LQ_START_TIME and 389 OPTION_LQ_END_TIME) are defined as an extension to DHCPv6 Bulk 390 Leasequery [RFC5460]. The reply messages for Active Leasequery uses 391 these options along with the options defined in [RFC3315], [RFC5007] 392 and [RFC5460]. 394 6.3.1. OPTION_LQ_BASE_TIME 396 The OPTION_LQ_BASE_TIME option is the current time the message was 397 created to be sent by the DHCPv6 server to the requestor of the 398 Active or Bulk Leasequery if requestor ask for the same in Active or 399 Bulk Leasequery request. This MUST be an absolute time (i.e. seconds 400 since midnight January 1, 2000 UTC). All of the other time based 401 options in the reply message are relative to this time, including 402 OPTION_CLT_TIME [RFC5007]. This time is in the context of the DHCPv6 403 server who placed this option in a message. 405 This is an unsigned integer in network byte order. 407 The code for this option is TBD. 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | OPTION_LQ_BASE_TIME | option-len | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | base-time | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 option-code OPTION_LQ_BASE_TIME (TBD). 418 option-len 4. 419 base-time DHCPv6 Server Base Time. 421 6.3.2. OPTION_LQ_START_TIME 423 The OPTION_LQ_START_TIME option specifies a query start time to the 424 DHCPv6 server. If specified, only bindings that have changed on or 425 after the OPTION_LQ_START_TIME should be included in the response to 426 the query. This option MAY be used in Active or Bulk Leasequery 427 requests made to a DHCPv6 server. 429 The requestor MUST determine the OPTION_LQ_START_TIME using lease 430 information it has received from the DHCPv6 server. This MUST be an 431 absolute time in the DHCPv6 server's context (see Section 8.5). 433 Typically (though this is not a requirement) the OPTION_LQ_START_TIME 434 option will contain the value most recently received in a 435 OPTION_LQ_BASE_TIME option by the requestor, as this will indicate 436 the last successful communication with the DHCPv6 server. 438 This is an unsigned integer in network byte order. 440 The code for this option is TBD. 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | OPTION_LQ_START_TIME | option-len | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | query-start-time | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 option-code OPTION_LQ_START_TIME (TBD). 451 option-len 4. 452 query-start-time DHCPv6 Server Query Start Time. 454 6.3.3. OPTION_LQ_END_TIME 456 The OPTION_LQ_END_TIME option specifies a query end time to the 457 DHCPv6 server. If specified, only bindings that have changed on or 458 before the OPTION_LQ_END_TIME should be included in the response to 459 the query. This option MAY be used in a Bulk Leasequery request. 460 But it MUST NOT be used in an Active Leasequery request. 462 The requestor MUST determine the OPTION_LQ_END_TIME based on lease 463 information it has received from the DHCPv6 server. This MUST be an 464 absolute time in the context of the DHCPv6 server. 466 In the absence of information to the contrary, the requestor SHOULD 467 assume that the time context of the DHCPv6 server is identical to the 468 time context of the requestor (see Section 8.5). 470 This is an unsigned integer in network byte order. 472 The code for this option is TBD. 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | OPTION_LQ_END_TIME | option-len | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | query-end-time | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 option-code OPTION_LQ_END_TIME (TBD). 483 option-len 4. 484 query-end-time DHCPv6 Server Query End Time. 486 6.4. Connection and Transmission Parameters 488 Active Leasequery uses the same port configuration as DHCPv6 Bulk 489 Leasequery [RFC5460]. It also uses the other transmission parameters 490 (BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [RFC5460]. 492 This section presents a table of values used to control Active 493 Leasequery behavior, including recommended defaults. Implementations 494 MAY make these values configurable. However, configuring too-small 495 timeout values may lead to harmful behavior both to this application 496 as well as to other traffic in the network. As a result, timeout 497 values smaller than the default values SHOULD NOT be used. 499 +------------------------+----------+-------------------------------+ 500 | Parameter | Default | Description | 501 +------------------------+----------+-------------------------------+ 502 | ACTIVE_LQ_RCV_TIMEOUT | 120 secs | Active Leasequery receive | 503 | | | timeout | 504 | ACTIVE_LQ_SEND_TIMEOUT | 120 secs | Active Leasequery send | 505 | | | timeout | 506 | ACTIVE_LQ_IDLE_TIMEOUT | 60 secs | Active Leasequery idle | 507 | | | timeout | 508 +------------------------+----------+-------------------------------+ 510 7. Information Communicated by Active Leasequery 512 While the information communicated by a DHCPv6 Bulk Leasequery 513 [RFC5460] is taken directly from the DHCPv6 server's lease state 514 database, the information communicated by an Active Leasequery is 515 real-time information. As such, it is the information which is 516 currently associated with a particular binding in the DHCPv6 server's 517 lease state database. 519 This is of significance, because if the Active Leasequery requestor 520 runs slowly or the requestor disconnects from the DHCPv6 server and 521 then reconnects with an OPTION_LQ_START_TIME option (signaling a 522 catch-up operation), the information communicated to the Active 523 Leasequery requestor is only the most current information from the 524 DHCPv6 server's lease state database. 526 The requestor of an Active Leasequery MUST NOT assume that every 527 lease state change is communicated across an Active Leasequery 528 connection. Even if the Active Leasequery requestor remains 529 connected, the DHCPv6 server is only required to transmit information 530 about a binding that is current when the message is created and 531 handed off to the TCP stack to send to the requestor. 533 If the TCP connection blocks and the DHCPv6 server is waiting to send 534 information down the connection, when the connection becomes 535 available to be written the DHCPv6 server MAY create the message to 536 send at this time. The current state of the binding will be sent, 537 and any transition in state or other information that occurred while 538 the TCP connection was blocked will be lost. 540 Thus, the Active Leasequery protocol does not allow the requestor to 541 build a complete history of every activity on every lease. An 542 effective history of the important state changes for a lease can be 543 created if the parameters of the DHCPv6 server are tuned to take into 544 account the requirements of an Active Leasequery requestor. For 545 instance, the period after the expiration or release of a binding 546 could be configured long enough (say several minutes, well more than 547 the receive timeout), so that an Active Leasequery requestor would be 548 less likely to miss any changes in the binding. 550 8. Requestor Behavior 552 8.1. General Processing 554 A requestor attempts to establish a TCP connection to a DHCPv6 Server 555 in order to initiate an Active Leasequery exchange. If the attempt 556 fails, the Requestor MAY retry. 558 If an Active Leasequery is terminated prematurely by a LEASEQUERY- 559 DONE with a DHCPv6 status code (carried in an OPTION_STATUS_CODE 560 option) of QueryTerminated or by the failure of the connection over 561 which it was being submitted, the requestor MAY retry the request 562 after the creation of a new connection. 564 Messages from the DHCPv6 server come as multiple responses to a 565 single ACTIVELEASEQUERY message. Thus, each ACTIVELEASEQUERY request 566 MUST have an xid (transaction-id) unique on the connection on which 567 it is sent, and all of the messages which come as a response to it 568 contain the same xid as the request. It is the xid which allows the 569 data-streams of two or more different ACTIVELEASEQUERY requests to be 570 de-multiplexed by the requestor. 572 8.2. Initiating a Connection 574 A Requestor SHOULD attempt to negotiate a TLS [RFC5246] connection 575 over the TCP connection. If this negotiation fails, a requestor MAY 576 choose to proceed with the Active Leasequery request without TLS. 578 A requestor requests the establishment of a TLS connection by sending 579 the STARTTLS message to the DHCPv6 server as the first message over 580 the TCP connection. This message indicates to the DHCPv6 server that 581 a TLS connection over this TCP connection is desired. There are four 582 possibilities after the requestor sends the STARTTLS message to the 583 DHCPv6 server: 585 1. No response from the DHCPv6 server. 587 2. The DHCPv6 server drops the TCP connection after it receives the 588 STARTTLS message. 590 3. DHCPv6 server responds with REPLY [RFC3315] message with DHCPv6 591 status code of TLSConnectionRefused. 593 4. DHCPv6 server responds with REPLY [RFC3315] message without 594 DHCPv6 status code, indicating success. 596 In any of the first three possibilities, the DHCPv6 server can be 597 assumed to not support TLS. In this case, the requestor MAY choose 598 to proceed with the Active Leasequery request without having it 599 protected by TLS. 601 In the final possibility, where the DHCPv6 server has responded with 602 a REPLY message without DHCPv6 status code in response to the 603 requestor's STARTTLS message, the requestor SHOULD initiate the 604 exchange of the messages involved in a TLS handshake [RFC5246]. 606 If the handshake exchange yields a functioning TLS connection, then 607 the requestor SHOULD transmit an Active Leasequery message over that 608 TLS connection and use that TLS connection for all further 609 interactions in which it engages with the DHCPv6 server over this TCP 610 connection. 612 If the handshake exchange does not yield a functioning TLS 613 connection, then the requestor MUST drop the TCP connection. The 614 requestor MAY create a new TCP connection and MAY choose to proceed 615 with an Active Leasequery request without using TLS. 617 8.3. Forming an Active Leasequery 619 The Active Leasequery is designed to create a long lived connection 620 between the requestor and the DHCPv6 server processing the active 621 query. The DHCPv6 server SHOULD send binding information back across 622 this connection with minimal delay after it learns of the binding 623 information. It learns about bindings either because it makes the 624 bindings itself or because it has received information about a 625 binding from another server. 627 An important capability of the Active Leasequery is the ability of 628 the requestor to specify that some recent data be sent immediately to 629 the requestor in parallel with the transmission of the ongoing 630 binding information in more or less real time. This capability is 631 used in order to allow an Active Leasequery requestor to recover 632 missed information in the event that it temporarily loses 633 connectivity with the DHCPv6 server processing a previous Active 634 Leasequery. 636 Note that until all of the recent data (catch-up data) has been 637 received, the requestor MUST NOT keep track of the base-time 638 (OPTION_LQ_BASE_TIME) received in Leasequery reply messages to use 639 later in a subsequent Active Leasequery request. 641 This capability is enabled by the transmission of an 642 OPTION_LQ_BASE_TIME option with each Leasequery reply sent as the 643 result of a previous Active Leasequery. The requestor SHOULD keep 644 track of the highest base-time received from a particular DHCPv6 645 server over an Active Leasequery connection, and in the event that 646 the requestor finds it necessary (for whatever reason) to reestablish 647 an Active Leasequery connection to that DHCPv6 server, the requestor 648 SHOULD place this highest base-time value into an 649 OPTION_LQ_START_TIME option in the new Active Leasequery request. 651 If the requestor doesn't wish to request an update of information 652 missed when it was not connected to the DHCPv6 server, then it SHOULD 653 NOT include the OPTION_LQ_START_TIME option in the Active Leasequery 654 request. 656 If the TCP connection becomes blocked or stops being writable while 657 the requestor is sending its query, the requestor SHOULD terminate 658 the connection after BULK_LQ_DATA_TIMEOUT. We make this 659 recommendation to allow requesters to control the period of time they 660 are willing to wait before abandoning a connection, independent of 661 notifications from the TCP implementations they may be using. 663 8.4. Processing Active Replies 665 The Requestor attempts to read a DHCPv6 LEASEQUERY-REPLY message from 666 the TCP connection. If the stream of replies becomes blocked, the 667 Requestor SHOULD terminate the connection after 668 ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured 669 to do so. 671 The requestor examines the LEASEQUERY-REPLY message, and determines 672 how to proceed. Message validation rules are specified in DHCPv6 673 Leasequery [RFC5007] and DHCPv6 Bulk Leasequery [RFC5460]. If the 674 reply contains an DHCPv6 status code (carried in an 675 OPTION_STATUS_CODE option), the requestor should follow the 676 recommendations in [RFC5007]. 678 Note that an Active Leasequery request specifically requests the 679 DHCPv6 server to create a long-lived connection which may not have 680 data transferring continuously during its lifetime. Therefore the 681 DHCPv6 server SHOULD send a LEASEQUERY-DATA message without binding 682 data (OPTION_CLIENT_DATA) every ACTIVE_LQ_IDLE_TIMEOUT seconds 683 (default 60) in order for the requestor to know that the connection 684 remains alive. This approach is followed only when connection is 685 idle (i.e. server has no binding data to send). During normal 686 binding data exchange, receiving of LEASEQUERY-DATA message by 687 requestor itself signifies that connection is active. Note that the 688 default for ACTIVE_LQ_RCV_TIMEOUT is 120 seconds, twice the value of 689 the ACTIVE_LQ_IDLE_TIMEOUT's default of 60 seconds which drives the 690 DHCPv6 server to send messages. Thus ACTIVE_LQ_RCV_TIMEOUT controls 691 how sensitive the requestor is to be to delays by the DHCPv6 server 692 in sending updates or LEASEQUERY-DATA messages. 694 A single Active Leasequery can and usually will result in a large 695 number of replies. The Requestor MUST be prepared to receive more 696 than one reply with transaction-ids matching a single 697 ACTIVELEASEQUERY message from a single DHCPv6 server. 699 An Active Leasequery has two regimes -- during the catch-up phase, if 700 any, and after any catch-up phase. If the Active Leasequery was 701 requested with an OPTION_LQ_START_TIME option, the Active Leasequery 702 starts out in the catch-up phase. See Section 8.4.1 for information 703 on processing during the catch-up phase, as well as how to determine 704 when the catch-up phase is complete. 706 The updates sent by the DHCPv6 server during the catch-up phase are 707 not in the order that the lease state data was updated. Therefore, 708 the OPTION_LQ_BASE_TIME option from messages during this phase MUST 709 NOT be saved and used to compute the subsequent ACTIVELEASEQUERY 710 message's OPTION_LQ_START_TIME option. 712 After the catch-up phase, or during the entire series of messages 713 received as the response to an Active Leasequery request with no 714 OPTION_LQ_START_TIME (and therefore no catch-up phase), the 715 OPTION_LQ_BASE_TIME option of the most recent message SHOULD be saved 716 as a record of the most recent time that data was received. This 717 base-time (in the context of the DHCPv6 server) can be used in a 718 subsequent Active Leasequery message's OPTION_LQ_START_TIME after a 719 loss of the Active Leasequery connection. 721 The LEASEQUERY-DONE message MAY unilaterally terminate a successful 722 Active Leasequery request which is currently in progress in the event 723 that the DHCPv6 server determines that it cannot continue processing 724 a ACTIVELEASEQUERY request. For example, when a server is requested 725 to shut down it SHOULD send a LEASEQUERY-DONE message with a DHCPv6 726 status code of QueryTerminated and include OPTION_LQ_BASE_TIME option 727 in the message. This SHOULD be the last message on that connection, 728 and once the message has been transmitted, the server should close 729 the connection. 731 After receiving LEASEQUERY-DONE with a QueryTerminated status from a 732 server, the Requestor MAY close the TCP connection to that server. 734 8.4.1. Processing Replies from a Request Containing a 735 OPTION_LQ_START_TIME 737 If the Active Leasequery was requested with an OPTION_LQ_START_TIME 738 option, the DHCPv6 server will attempt to send information about all 739 bindings that changed since the time specified in the 740 OPTION_LQ_START_TIME. This is the catch-up phase of the Active 741 Leasequery processing. The DHCPv6 server MAY also begin immediate 742 updates over the same connection of real-time binding information 743 changes. Thus, the catch-up phase may run in parallel with the 744 normal updates generated by the Active Leasequery request. 746 A DHCPv6 server MAY keep only a limited amount of time ordered 747 information available to respond to an Active Leasequery request 748 containing an OPTION_LQ_START_TIME option. Thus, it is possible that 749 the time specified in the OPTION_LQ_START_TIME option represents a 750 time not covered by the time ordered information kept by the DHCPv6 751 server. If this should occur, and there is not enough data saved in 752 the DHCPv6 server to satisfy the request specified by the 753 OPTION_LQ_START_TIME option, the DHCPv6 server will reply immediately 754 with a LEASEQUERY-REPLY message with a DHCPv6 status code of 755 DataMissing with a base-time option equal to the server's current 756 time. This will signal the end of the catch-up phase, and the only 757 updates that will subsequently be received on this connection are the 758 real-time updates from the Active Leasequery request. 760 If there is enough data saved to satisfy the request, then 761 LEASEQUERY-REPLY (with OPTION_STATUS_CODE of Success or reply without 762 OPTION_STATUS_CODE option) and LEASEQUERY-DATA messages will begin 763 arrive from the DHCPv6 server. Some of these messages will be 764 related to the OPTION_LQ_START_TIME request and be part of the catch- 765 up phase. Some of these messages will be real-time updates of 766 binding changes taking place in the DHCPv6 server. In general, there 767 is no way to determine the source of each message. 769 The updates sent by the DHCPv6 server during the catch-up phase are 770 not in the order that the binding data was updated. Therefore, until 771 the catch-up phase is complete, the latest base-time value received 772 from a DHCPv6 server processing an Active Leasequery request cannot 773 be reset from the incoming messages (and used in a subsequent Active 774 Leasequery's query-start-time option), because to do so would 775 compromise the ability to recover lost information if the Active 776 Leasequery were to terminate prior to the completion of the catch-up 777 phase. 779 The requestor will know that the catch-up phase is complete when the 780 DHCPv6 server will transmit a LEASEQUERY-DATA message with the DHCPv6 781 status code of CatchUpComplete (or LEASEQUERY-REPLY message with a 782 DHCPv6 status code of DataMissing, as discussed above). Once this 783 message is transmitted, all additional LEASEQUERY-DATA messages will 784 relate to real-time ("new") binding changes in the DHCPv6 server. 786 As discussed in Section 8.4, the requestor SHOULD keep track of the 787 latest base-time option value received over a particular connection, 788 to be used in a subsequent Active Leasequery request -- but only if 789 the catch-up phase is complete. Prior to the completion of the 790 catch-up phase, if the connection should go away or if the requestor 791 receives a LEASEQUERY-DONE message, then when it reconnects it MUST 792 use the base-time value from the previous connection and not any 793 base-time value received from the recently closed connection. 795 In the event that there was enough data available to the DHCPv6 796 server to begin to satisfy the request implied by the 797 OPTION_LQ_START_TIME option, but during the processing of that data 798 the server found that it was unable to continue (perhaps there was 799 barely enough, the connection is very slow, and the aging algorithm 800 causes the saved data to become unavailable) the DHCPv6 server will 801 terminate the catch-up phase of processing immediately by sending a 802 LEASEQUERY-DATA message with a DHCPv6 status code of DataMissing and 803 with a base-time option of the current time. 805 The requestor MUST NOT assume that every individual state change of 806 every binding during the period from the time specified in the 807 OPTION_LQ_START_TIME and the present is replicated in an Active 808 Leasequery reply message. The requestor MAY assume that at least one 809 Active Leasequery reply message will exist for every binding which 810 had one or more changes of state during the period specified by the 811 OPTION_LQ_START_TIME and the current time. The last message for each 812 binding will contain the state at the current time, and there may be 813 one or more messages concerning a single binding during the catch-up 814 phase of processing. 816 Bindings can change multiple times while the requester was not 817 connected (that is, during the time from the OPTION_LQ_START_TIME and 818 the present). The requestor will only receive information about the 819 current state of the binding, not information about each state change 820 that occurred during the period from the OPTION_LQ_START_TIME to the 821 present. 823 If the LEASEQUERY-REPLY or LEASEQUERY-DATA message containing a 824 DHCPv6 status code of DataMissing is received and the requestor is 825 interested in keeping its database up to date with respect to the 826 current state of bindings in the DHCPv6 server, then the requestor 827 SHOULD issue a Bulk Leasequery request to recover the information 828 missing from its database. This Bulk Leasequery request should 829 include a OPTION_LQ_START_TIME option with the same value as the 830 OPTION_LQ_START_TIME option previously included in the 831 ACTIVELEASEQUERY responses from the DHCPv6 server, and an 832 OPTION_LQ_END_TIME option equal to the OPTION_LQ_BASE_TIME option 833 returned by the DHCPv6 server in the LEASEQUERY-REPLY or LEASEQUERY- 834 DATA message with the DHCPv6 status code of DataMissing. 836 Typically, the requestor would have one connection open to a DHCPv6 837 server for an Active Leasequery request and possibly one additional 838 connection open for a Bulk Leasequery request to the same DHCPv6 839 server to fill in the data that might have been missed prior to the 840 initiation of the Active Leasequery. The Bulk Leasequery connection 841 would typically run to completion and be closed, leaving one Active 842 Leasequery connection open to a single DHCPv6 server. Alternatively, 843 both requests could be issued over a single connection. 845 8.5. Processing Time Values in Leasequery messages 847 Active or Bulk Leasequery requests may be made to a DHCPv6 server 848 whose absolute time may not be synchronized with the local time of 849 the requestor. Thus, there are at least two time contexts in even 850 the simplest Active or Bulk Leasequery response. 852 If the requestor of an Active or Bulk Leasequery is saving the data 853 returned in some form, it has a requirement to store a variety of 854 time values, and some of these will be time in the context of the 855 requestor and some will be time in the context of the DHCPv6 server. 857 When receiving an Active or Bulk Leasequery reply message from the 858 DHCPv6 server, the message will contain an OPTION_LQ_BASE_TIME 859 option. The time contained in this OPTION_LQ_BASE_TIME option is in 860 the context of the DHCPv6 server. As such, it is an ideal time to 861 save and use as input to an Active or Bulk Leasequery message in the 862 OPTION_LQ_START_TIME or OPTION_LQ_END_TIME option, should the 863 requestor need to ever issue an Active or Bulk Leasequery message 864 using these option as part of a later query, since these option 865 requires a time in the context of the DHCPv6 server. 867 In addition to saving the OPTION_LQ_BASE_TIME for possible future use 868 in OPTION_LQ_START_TIME or OPTION_LQ_END_TIME option, the 869 OPTION_LQ_BASE_TIME is used as part of the conversion of the other 870 times in the Leasequery message to values which are meaningful in the 871 context of the requestor. 873 In systems whose clocks are synchronized, perhaps using NTP, the 874 clock skew will usually be zero, which is not only acceptable, but 875 desired. 877 8.6. Examples 879 These examples illustrate what a series of queries and responses 880 might look like. These are only examples -- there are no requirement 881 that these sequence must be followed. 883 8.6.1. Query Failure 885 This example illustrates the message flows in case DHCPv6 server 886 identifies that it cannot accept and/or process Active Leasequery 887 request from the requestor. This could be because of various reasons 888 (i.e. UnknownQueryType, MalformedQuery, NotConfigured, NotAllowed, 889 NotSupported). 891 Client Server 892 ------ ------ 893 ACTIVELEASEQUERY xid 1 -----> 894 <----- LEASEQUERY-REPLY xid 1 (w/error) 896 8.6.2. Data Missing on Server 898 This example illustrates the message flows in case DHCPv6 server 899 identifies that it does not have enough data saved to satisfy the 900 request specified by the OPTION_LQ_START_TIME option. 902 In this case the DHCPv6 server will reply immediately with a 903 LEASEQUERY-REPLY message with a DHCPv6 status code of DataMissing 904 with a base-time option equal to the server's current time. This 905 will signal the end of the catch-up phase, and the only updates that 906 will subsequently be received on this connection are the real-time 907 updates from the Active Leasequery request. 909 Client Server 910 ------ ------ 911 ACTIVELEASEQUERY xid 2 -----> 912 <----- LEASEQUERY-REPLY xid 2 (w/error) 913 <----- LEASEQUERY-DATA xid 2 914 <----- LEASEQUERY-DATA xid 2 915 <----- LEASEQUERY-DATA xid 2 917 8.6.3. Successful Query 919 This example illustrates the message flows in case of successful 920 query processing by DHCPv6 server. 922 In this case the DHCPv6 server will reply immediately with a 923 LEASEQUERY-REPLY message (with OPTION_STATUS_CODE of Success or reply 924 without OPTION_STATUS_CODE option), followed by binding data in 925 LEASEQUERY-DATA messages. In case, DHCPv6 server wants to abort in- 926 process request and terminate the connection due to some reason, it 927 sends LEASEQUERY-DONE with error code present in OPTION_STATUS_CODE 928 option. 930 Client Server 931 ------ ------ 932 ACTIVELEASEQUERY xid 3 -----> 933 <----- LEASEQUERY-REPLY xid 3 934 <----- LEASEQUERY-DATA xid 3 935 <----- LEASEQUERY-DATA xid 3 936 <----- LEASEQUERY-DATA xid 3 937 <----- LEASEQUERY-DATA xid 3 938 <----- LEASEQUERY-DONE xid 3 (w/error) 940 8.7. Closing Connections 942 The Requestor or DHCPv6 Leasequery server MAY close its end of the 943 TCP connection at any time. The Requestor MAY choose to retain the 944 connection if it intends to issue additional queries. Note that this 945 requestor behavior does not guarantee that the connection will be 946 available for additional queries: the server might decide to close 947 the connection based on its own configuration. 949 9. Server Behavior 951 A DHCPv6 server which supports Active Leasequery MUST support DHCPv6 952 Bulk Leasequery [RFC5460] and as extended herein. 954 9.1. Accepting Connections 956 DHCPv6 servers that implement DHCPv6 Active Leasequery listen for 957 incoming TCP connections. Approach used in accepting the requestor 958 connection is same as specified in DHCPv6 Bulk Leasequery [RFC5460]. 960 DHCPv6 servers SHOULD support TLS [RFC5246] to protect the integrity 961 and privacy of the data transmitted over the TCP connection. DHCPv6 962 servers SHOULD negotiate a TLS connection with the requestor who asks 963 for one, and MAY choose to accept DHCPv6 Active Leasequery request 964 over connections which are not secured with TLS. 966 A requestor will request a TLS connection by sending a STARTTLS as 967 the first message over a newly created TCP connection. If the DHCPv6 968 server supports TLS connections and has not been configured to not 969 allow them on this link, the DHCPv6 server SHOULD respond to this 970 STARTTLS message by sending a REPLY [RFC3315] message without DHCPv6 971 status code back to the requestor. This indicates to the requestor 972 that the DHCPv6 server will support the negotiation of a TLS 973 connection over this existing TCP connection. 975 If for some reason the DHCPv6 server cannot or has been configured to 976 not support a TLS connection, then it SHOULD send a REPLY message 977 with DHCPv6 status code of TLSConnectionRefused back to the 978 requestor. 980 In the event that the DHCPv6 server sends a REPLY message without 981 DHCPv6 status code option included (which indicates success), the 982 requestor is supposed to initiate a TLS handshake [RFC5246] (see 983 Section 8.2). 985 If the TLS handshake is not successful in creating a TLS connection, 986 the server MUST drop the TCP connection. 988 9.2. Rejecting Connections 990 Servers that do not implement DHCPv6 Active and Bulk Leasequery 991 SHOULD NOT listen for incoming TCP connections for these requests. 993 If the DHCPv6 server supporting Bulk Leasequery and not Active 994 Leasequery receives an Active Leasequery request, it SHOULD send a 995 LEASEQUERY-REPLY with DHCPv6 status code as NotSupported. It SHOULD 996 close the TCP connection after this error is signaled. 998 9.3. Replying to an Active Leasequery 1000 The DHCPv6 Leasequery [RFC5007] specification describes the initial 1001 construction of LEASEQUERY-REPLY messages. Use of the LEASEQUERY- 1002 REPLY and LEASEQUERY-DATA messages to carry multiple bindings is 1003 described in DHCPv6 Bulk Leasequery [RFC5460]. Message transmission 1004 and framing for TCP is described in Section 6.1. 1006 If the connection becomes blocked while the server is attempting to 1007 send reply messages, the server SHOULD terminate the TCP connection 1008 after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs for how long the 1009 DHCPv6 server is prepared to wait for the requestor to read and 1010 process enough information to unblock the TCP connection. The 1011 default is two minutes, which means that if more than two minutes 1012 goes by without the requestor reading enough information to unblock 1013 the TCP connection, the DHCPv6 server SHOULD drop the TCP connection. 1015 If the DHCPv6 server encounters an error during initial processing of 1016 the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-REPLY 1017 message containing an error code of some kind in a DHCPv6 status code 1018 option. It SHOULD close the connection after this error is signaled. 1020 If the DHCPv6 server encounters an error during later processing of 1021 the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-DONE 1022 containing an error code of some kind in a DHCPv6 status code option. 1023 It SHOULD close the connection after this error is signaled. 1025 If the server finds any bindings satisfying a query, it SHOULD send 1026 each binding's data in a reply message. The first reply message is a 1027 LEASEQUERY-REPLY. The binding data is carried in an 1028 OPTION_CLIENT_DATA option, as specified in [RFC5007]. The server 1029 SHOULD send subsequent bindings in LEASEQUERY-DATA messages, which 1030 can avoid redundant data (such as the requestor's Client-ID). 1032 Every reply to an Active Leasequery request MUST contain the 1033 information specified in replies to a DHCPv6 Bulk Leasequery request 1034 [RFC5460]. 1036 Some servers can be configured to respond to a DHCPv6 Leasequery 1037 [RFC5007] and DHCPv6 Bulk Leasequery [RFC5460] for an IPv6 binding 1038 which is reserved in such a way that it appears that the IPv6 binding 1039 is leased to the DHCP client for which it is reserved. These servers 1040 SHOULD also respond to an Active Leasequery request with the same 1041 information as they would to a Bulk Leasequery request when they 1042 first determine that the IPv6 binding is reserved to a DHCP client. 1044 If an Active Leasequery or Bulk Leasequery request contains 1045 OPTION_LQ_BASE_TIME option code present in OPTION_ORO, the DHCPv6 1046 server MUST include OPTION_LQ_BASE_TIME option in every reply for 1047 this request. The value for base-time option is current absolute 1048 time in the DHCPv6 server's context. 1050 If an Active Leasequery request contains an OPTION_LQ_START_TIME 1051 option, it indicates that the requestor would like the DHCPv6 server 1052 to send it not only messages that correspond to DHCPv6 binding 1053 activity that occurs subsequent to the receipt of the Active 1054 Leasequery request, but also messages that correspond to DHCPv6 1055 binding activity that occurred prior to the Active Leasequery 1056 request. 1058 If OPTION_LQ_END_TIME option appears in an Active Leasequery request, 1059 the DHCPv6 server SHOULD send a LEASEQUERY-REPLY message with a 1060 DHCPv6 status code of MalformedQuery and terminate the connection. 1062 In order to implement a meaningful response to this query, the DHCPv6 1063 server MAY keep track of the binding activity and associate changes 1064 with particular base-time values from the messages. Then, when 1065 requested to do so by an Active Leasequery request containing a 1066 OPTION_LQ_START_TIME option, the DHCPv6 server can respond with 1067 replies for all binding activity occurring on that 1068 OPTION_LQ_START_TIME or later times. 1070 These replies based on the OPTION_LQ_START_TIME MAY be interleaved 1071 with the messages generated due to current binding activity. 1073 Once the transmission of the DHCPv6 Leasequery messages associated 1074 with the OPTION_LQ_START_TIME option are complete, a LEASEQUERY-DATA 1075 message MUST be sent with a DHCPv6 status code value of 1076 CatchUpComplete. 1078 The DHCPv6 server SHOULD, but is not required to, keep track of a 1079 limited amount of previous binding activity. The DHCPv6 server MAY 1080 choose to only do this in the event that it has received at least one 1081 Active Leasequery request in the past, as to do so will almost 1082 certainly entail some utilization of resources which would be wasted 1083 if there are no Active Leasequery requestors for this DHCPv6 server. 1084 The DHCPv6 server SHOULD make the amount of previous binding activity 1085 it retains configurable. There is no requirement on the DHCPv6 1086 server to retain this information over a server restart (or even to 1087 retain such information at all). 1089 Unless there is an error or some requirement to cease processing a 1090 Active Leasequery request yielding a LEASEQUERY-DONE message, such as 1091 a server shutdown, there will be no LEASEQUERY-DONE message at the 1092 conclusion of the Active Leasequery processing because that 1093 processing will not conclude but will continue until either the 1094 requestor or the server drops the connection. 1096 9.4. Multiple or Parallel Queries 1098 Requesters may want to use an existing connection if they need to 1099 make multiple queries. Servers MAY support reading and processing 1100 multiple queries from a single connection. A server MUST NOT read 1101 more query messages from a connection than it is prepared to process 1102 simultaneously. 1104 Typically, a requestor of an Active Leasequery would not need to send 1105 a second Active Leasequery while the first is still active. However, 1106 sending an Active Leasequery and a Bulk Leasequery over the same 1107 connection would be possible and reasonable. But it is RECOMMENDED 1108 to use different connection in case of parallel Active and Bulk 1109 Leasequeries. 1111 This MAY be a feature that is administratively controlled. Servers 1112 that are able to process queries in parallel SHOULD offer 1113 configuration that limits the number of simultaneous queries 1114 permitted from any one requestor, in order to control resource use if 1115 there are multiple requesters seeking service. 1117 9.5. Closing Connections 1119 The server MUST close its end of the TCP connection if it encounters 1120 an error sending data on the connection. The server MUST close its 1121 end of the TCP connection if it finds that it has to abort an in- 1122 process request. A server aborting an in-process request SHOULD 1123 attempt to signal that to its requestors by using the QueryTerminated 1124 status code in the DHCPv6 status code option in a LEASEQUERY-DONE 1125 message. If the server detects that the requestor end has been 1126 closed, the server MUST close its end of the connection after it has 1127 finished processing any outstanding requests from the requestor. 1129 The server SHOULD limit the number of connections it maintains, and 1130 SHOULD close idle connections to enforce the limit. 1132 10. Security Considerations 1134 The "Security Considerations" section of [RFC3315] details the 1135 general threats to DHCPv6. The DHCPv6 Leasequery specification 1136 [RFC5007] describes recommendations for the Leasequery protocol, 1137 especially with regard to relayed Leasequery messages, mitigation of 1138 packet-flooding denial-of-service (DoS) attacks, restriction to 1139 trusted requestors, and use of IPsec [RFC4301]. 1141 The use of TCP introduces some additional concerns. Attacks that 1142 attempt to exhaust the DHCPv6 server's available TCP connection 1143 resources, such as SYN flooding attacks, can compromise the ability 1144 of legitimate requestors to receive service. Malicious requestors 1145 who succeed in establishing connections, but who then send invalid 1146 queries, partial queries, or no queries at all also can exhaust a 1147 server's pool of available connections. We recommend that servers 1148 offer configuration to limit the sources of incoming connections, 1149 that they limit the number of accepted connections and the number of 1150 in-process queries from any one connection, and that they limit the 1151 period of time during which an idle connection will be left open. 1153 There are two specific issues regarding Active Leasequery security 1154 that deserve explicit mention. The first is preventing information 1155 that Active Leasequery can provide from reaching requestors who are 1156 not authorized to receive such information. The second is ensuring 1157 that authorized requestors of the Active Leasequery capability 1158 receive accurate information from the Server (and that this 1159 information is not disrupted in transit). 1161 To prevent information leakage to unauthorized requestors, Servers 1162 SHOULD restrict Active Leasequery connections and ACTIVELEASEQUERY 1163 messages to certain requestors, either through explicit configuration 1164 of the Server itself or by employing external network elements to 1165 provide such restrictions. 1167 Connections not from permitted requestors SHOULD be closed 1168 immediately, to avoid server connection resource exhaustion or 1169 alternatively, simply not be allowed to reach the server at all. 1170 Servers SHOULD have the capability to restrict certain requestors to 1171 certain query types. Servers MAY reply to queries that are not 1172 permitted with the LEASEQUERY-DONE message with a status-code option 1173 status of NotAllowed, or MAY simply close the connection. 1175 In addition, requestors and servers SHOULD use TLS [RFC5246] to 1176 protect the integrity and privacy of the Active Leasequery data 1177 transmitted over the TCP connection. 1179 Authentication for DHCP Messages [RFC3315] MUST NOT be used to 1180 attempt to secure transmission of the messages described in this 1181 document. 1183 11. IANA Considerations 1185 IANA is requested to assign new DHCPv6 Option Codes in the registry 1186 maintained in http://www.iana.org/assignments/dhcpv6-parameters: 1188 OPTION_LQ_BASE_TIME 1190 OPTION_LQ_START_TIME 1192 OPTION_LQ_END_TIME 1194 IANA is requested to assign new values in the registry of DHCPv6 1195 Status Codes maintained in http://www.iana.org/assignments/ 1196 dhcpv6-parameters: 1198 DataMissing 1200 CatchUpComplete 1202 NotSupported 1204 TLSConnectionRefused 1206 IANA is requested to assign value for the following new DHCPv6 1207 Message type in the registry maintained in 1208 http://www.iana.org/assignments/dhcpv6-parameters: 1210 ACTIVELEASEQUERY 1212 STARTTLS 1214 12. Acknowledgements 1216 Some of the concept and content, present in this document, are based 1217 on DHCPv4 Active Leasequery which was originally proposed by Kim 1218 Kinnear, Bernie Volz, Mark Stapp and Neil Russell. 1220 13. Modification History 1222 14. References 1224 14.1. Normative References 1226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1227 Requirement Levels", BCP 14, RFC 2119, March 1997. 1229 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1230 and M. Carney, "Dynamic Host Configuration Protocol for 1231 IPv6 (DHCPv6)", RFC 3315, July 2003. 1233 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1234 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1235 December 2003. 1237 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 1238 "DHCPv6 Leasequery", RFC 5007, September 2007. 1240 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1241 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1243 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 1244 2009. 1246 14.2. Informative References 1248 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1249 Internet Protocol", RFC 4301, December 2005. 1251 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 1252 for Transmission Control Protocol (TCP) Specification 1253 Documents", RFC 4614, September 2006. 1255 Authors' Addresses 1257 Dushyant Raghuvanshi 1258 Cisco Systems, Inc. 1259 Cessna Business Park, 1260 Varthur Hobli, Outer Ring Road, 1261 Bangalore, Karnataka 560037 1262 India 1264 Phone: +91 (080) 4365-7476 1265 Email: draghuva@cisco.com 1267 Kim Kinnear 1268 Cisco Systems, Inc. 1269 1414 Massachusetts Ave. 1270 Boxborough, Massachusetts 01719 1271 USA 1273 Phone: +1 (978) 936-0000 1274 Email: kkinnear@cisco.com 1276 Deepak Kukrety 1277 Cisco Systems, Inc. 1278 Cessna Business Park, 1279 Varthur Hobli, Outer Ring Road, 1280 Bangalore, Karnataka 560037 1281 India 1283 Phone: +91 (080) 4365-7474 1284 Email: dkukrety@cisco.com