idnits 2.17.1 draft-raghuvanshi-dhc-dhcpv6-active-leasequery-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (October 4, 2013) is 3849 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) == Unused Reference: 'RFC4614' is defined on line 1137, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4614 (Obsoleted by RFC 7414) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group D. Raghuvanshi 3 Internet-Draft D. Kukrety 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: April 7, 2014 October 4, 2013 7 DHCPv6 Active Leasequery 8 draft-raghuvanshi-dhc-dhcpv6-active-leasequery-00.txt 10 Abstract 12 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been 13 extended with a Leasequery capability that allows a client to request 14 information about DHCPv6 bindings. That mechanism is limited to 15 queries for DHCPv6 binding data updates until the time DHCPv6 server 16 receive the Leasequery request. Continuous update of an external 17 client with Leasequery data is sometimes desired. This document 18 expands on the DHCPv6 Leasequery protocol, and allows for active 19 transfer of real-time DHCPv6 binding information data via TCP. This 20 document also extends DHCPv6 Bulk Leasequery by adding new options. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 7, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Interaction Between Active Leasequery and Bulk Leasequery . . 6 60 5. Extension to DHCPv6 Bulk Leasequery . . . . . . . . . . . . . 7 61 6. Message and Option Definitions . . . . . . . . . . . . . . . . 7 62 6.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 7 63 6.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6.2.1. ACTIVELEASEQUERY . . . . . . . . . . . . . . . . . . . 7 65 6.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.3.1. OPTION_LQ_BASE_TIME . . . . . . . . . . . . . . . . . 8 67 6.3.2. OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . . 9 68 6.3.3. OPTION_LQ_END_TIME . . . . . . . . . . . . . . . . . . 10 69 6.4. Connection and Transmission Parameters . . . . . . . . . . 10 70 7. Information Communicated by Active Leasequery . . . . . . . . 11 71 8. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . . 12 72 8.1. Connecting and General Processing . . . . . . . . . . . . 12 73 8.2. Forming an Active Leasequery . . . . . . . . . . . . . . . 12 74 8.3. Processing Active Replies . . . . . . . . . . . . . . . . 13 75 8.3.1. Processing Replies from a Request Containing a 76 OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . . 15 77 8.4. Processing Time Values in Leasequery messages . . . . . . 17 78 8.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 8.5.1. Query Failure . . . . . . . . . . . . . . . . . . . . 18 80 8.5.2. Data Missing on Server . . . . . . . . . . . . . . . . 18 81 8.5.3. Successful Query . . . . . . . . . . . . . . . . . . . 19 82 8.6. Closing Connections . . . . . . . . . . . . . . . . . . . 19 83 9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 19 84 9.1. Accepting Connections . . . . . . . . . . . . . . . . . . 20 85 9.2. Replying to an Active Leasequery . . . . . . . . . . . . . 20 86 9.3. Multiple or Parallel Queries . . . . . . . . . . . . . . . 22 87 9.4. Closing Connections . . . . . . . . . . . . . . . . . . . 22 88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 89 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 90 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 91 13. Modification History . . . . . . . . . . . . . . . . . . . . . 24 92 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 14.1. Normative References . . . . . . . . . . . . . . . . . . . 24 94 14.2. Informative References . . . . . . . . . . . . . . . . . . 25 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 97 1. Introduction 99 The DHCPv6 [RFC3315] protocol specifies a mechanism for the 100 assignment of IPv6 address and configuration information to IPv6 101 nodes. IPv6 Prefix Delegation for DHCPv6 (PD) [RFC3633] specifies a 102 mechanism for DHCPv6 delegation of IPv6 prefixes and related data. 103 DHCPv6 servers maintain authoritative information including binding 104 information for delegated IPv6 prefixes. 106 Requirements exist for external entities to keep up to date on the 107 correspondence between DHCPv6 clients and their bindings. These 108 requirements often stem from regulatory requirements placed on 109 service providers by governmental agencies. 111 These entities need to keep up with the current binding activity of 112 the DHCPv6 server. Keeping up with these binding activity is termed 113 "active" leasequery. 115 The DHCPv6 Bulk Leasequery [RFC5460] capability can be used to 116 recover useful information from a DHCPv6 server when some external 117 entity starts up. This entity could be one which is directly 118 involved in the DHCPv6 client - server transactions (e.g., a relay 119 agent), or it could be an external process which needs information 120 present in the DHCPv6 server's lease state database. 122 The Active Leasequery capability documented here is designed to allow 123 an entity not directly involved in DHCPv6 client - server 124 transactions to nevertheless keep current with the state of the 125 DHCPv6 lease state information in real-time. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 DHCPv6 terminology is defined in [RFC3315]. Terminology specific to 134 DHCPv6 Active Leasequery can be found below: 136 o "Absolute Time" 138 A 32-bit quantity containing the number of seconds since January 139 1, 2000. 141 o "Active Leasequery" 143 Keeping up to date in real-time (or near real-time) with DHCPv6 144 binding activity. 146 o "Bulk Leasequery" 148 Requesting and receiving the existing DHCPv6 binding information 149 in an efficient manner. 151 o "catch-up information, catch-up phase" 153 If a DHCPv6 Active Leasequery requestor sends OPTION_LQ_START_TIME 154 option in a ACTIVELEASEQUERY message, the DHCPv6 server will 155 attempt to send the requestor the information that changed since 156 the time specified in the OPTION_LQ_START_TIME option. The 157 binding information sent to satisfy this request is the catch-up 158 information, and the period while it is being sent is the catch-up 159 phase. 161 o "clock skew" 163 The difference between the absolute time on a DHCPv6 server and 164 the absolute time on the system where a requestor of an Active or 165 Bulk Leasequery is executing is termed the "clock skew" for that 166 Active or Bulk Leasequery connection. It is not absolutely 167 constant but is likely to vary only slowly. While it is easy to 168 think that this can be calculated precisely after one packet is 169 received by a requestor from a DHCPv6 server, a more accurate 170 value is derived from continuously examining the instantaneous 171 value developed from each packet received from a DHCPv6 server and 172 using it to make small adjustments to the existing value held in 173 the requestor. 175 o "Transaction ID" 177 An opaque value used to match responses with queries initiated by 178 an Active Leasequery client. 180 3. Protocol Overview 182 The Active Leasequery mechanism is modeled on the existing DHCPv6 183 Bulk Leasequery [RFC5460]; most differences arise from the long term 184 nature of the TCP connection required for Active Leasequery. In 185 addition, a DHCPv6 server which supports Active Leasequery MUST 186 support Bulk Leasequery [RFC5460] as well. 188 An Active Leasequery client opens a TCP connection to a DHCPv6 189 Server, using the DHCPv6 port 547. Note that this implies that the 190 Leasequery client has server IP address(es) available via 191 configuration or some other means, and that it has unicast IP 192 reachability to the DHCPv6 server. No relaying for Active Leasequery 193 is specified. 195 After establishing a connection, the client sends an ACTIVELEASEQUERY 196 message over the connection. In response, the server sends updates 197 to the requestor using LEASEQUERY-REPLY and LEASEQUERY-DATA messages. 198 This response procedure is identical to [RFC5460], except that in 199 case of Active Leasequery server sends updates whenever some activity 200 occurs to change binding state - thus the need for long lived 201 connection. Active Leasequery is designed to provide continuous 202 updates of DHCPv6 IPv6 binding activity to an external entity. 204 Active Leasequery has features which allow this external entity to 205 lose its connection and then reconnect and receive the latest 206 information concerning any IPv6 bindings changed while it was not 207 connected. 209 These capabilities are designed to allow the Active Leasequery 210 requestor to efficiently become current with respect to the lease 211 state database after it has been restarted or the machine on which it 212 is running has been reinitialized. It is easy to define a protocol 213 which works when the requestor is always connected to the DHCPv6 214 server. Since that isn't sufficiently robust, much of the mechanism 215 in this document is designed to deal efficiently with situations that 216 occur when the Active Leasequery requestor becomes disconnected from 217 the DHCPv6 server from which it is receiving updates and then becomes 218 reconnected to that server. 220 Central to this approach, if the Active Leasequery requestor loses 221 service, it is allowed to specify the time of its most recent update 222 in a subsequent Active Leasequery request and the DHCPv6 server will 223 determine whether or not data was missed while the Active Leasequery 224 requestor was not connected. 226 The DHCPv6 server processing the Active Leasequery request may limit 227 the amount of data saved, and methods exist for the DHCPv6 server to 228 inform the Active Leasequery requestor that more data was missed than 229 could be saved. In this situation, the Active Leasequery requestor 230 would issue a Bulk Leasequery [RFC5460] to recover information not 231 available through an Active Leasequery. 233 DHCPv6 servers are not required to keep any data corresponding to 234 data missed on a Active Leasequery connection, but will typically 235 choose to keep data corresponding to some recent activity available 236 for subsequent queries by a DHCPv6 Active Leasequery client whose 237 connection was temporarily interrupted. 239 An Active Leasequery requestor would typically use Bulk Leasequery to 240 initialize its database with all current data when that database 241 contains no binding information. In addition, it would use Bulk 242 Leasequery to recover missed information in the event that its 243 connection with the DHCPv6 server was lost for a longer time than the 244 DHCPv6 server would keep track of the specific changes to the IPv6 245 binding information. 247 The messages sent by the server in response to an Active Leasequery 248 request SHOULD be identical to the messages sent by the server to a 249 Bulk Leasequery request regarding the way the data is encoded into 250 the Active Leasequery responses. In addition, the actions taken by 251 the Active Leasequery requestor to interpret the responses to an 252 Active Leasequery request SHOULD be identical to the way that the 253 requestor interprets the responses to a Bulk Leasequery request. 254 Thus, the handling of OPTION_CLIENT_DATA and additional options 255 discussed in the Bulk Leasequery specification [RFC5460] are to be 256 followed when implementing Active Leasequery. 258 4. Interaction Between Active Leasequery and Bulk Leasequery 260 Active Leasequery can be seen as an extension of the Bulk Leasequery 261 protocol [RFC5460]. The format of packets returned to an Active 262 Leasequery requestor are identical to that defined for the Bulk 263 Leasequery protocol [RFC5460]. 265 Applications which employ Active Leasequery to keep a database up to 266 date with respect to the DHCPv6 server's lease state database will 267 usually use an initial Bulk Leasequery to bring their database into 268 equivalence with that of the DHCPv6 server, and then use Active 269 Leasequery to keep that database current with respect to the DHCPv6 270 server's lease state database. 272 There are several differences between the Active and Bulk Leasequery 273 protocols. Active Leasequery defines a new message 274 (ACTIVELEASEQUERY) to send Active Leasequery request to DHCPv6 275 server. An Active Leasequery connection sends all available updates 276 to the requestor, based on OPTION_LQ_QUERY option (see 277 Section 6.2.1). 279 An Active Leasequery connection does not ever "complete", though the 280 DHCPv6 server may drop the connection for a variety of reasons 281 associated with some sort of exception condition. 283 5. Extension to DHCPv6 Bulk Leasequery 285 This document extends to the capabilities of DHCPv6 Bulk Leasequery 286 protocol [RFC5460] by defining new options. More details about these 287 options are specified in Section 6.3. 289 6. Message and Option Definitions 291 6.1. Message Framing for TCP 293 The use of TCP for the Active Leasequery protocol permits one or more 294 DHCPv6 messages to be sent at a time. The receiver needs to be able 295 to determine how large each message is. The same message framing 296 technique used for DHCPv6 Bulk Leasequery [RFC5460] is used for 297 Active Leasequery as well. 299 The intent in using the same format is that code which currently 300 knows how to deal with a message returned from DHCPv6 Bulk Leasequery 301 [RFC5460] will be able to deal with the message held inside of the 302 TCP framing. 304 6.2. Messages 306 The LEASEQUERY-REPLY message is defined in [RFC5007]. The 307 LEASEQUERY-DATA and LEASEQUERY-DONE messages are defined in 308 [RFC5460]. 310 In a Active Leasequery exchange, a single LEASEQUERY-REPLY message is 311 used to indicate the success or failure of a query, and to carry data 312 that do not change in the context of a single query and answer, such 313 as the Server-ID and Client-ID options. If a query is successful, 314 only a single LEASEQUERY-REPLY message MUST appear. If the server is 315 returning binding data, the LEASEQUERY-REPLY also contains the first 316 client's binding data in an OPTION_CLIENT_DATA option. Additional 317 binding data is returned using LEASEQUERY-DATA message as explained 318 in DHCPv6 Bulk Leasequery [RFC5460]. In case of failure query, 319 single LEASEQUERY-REPLY message is returned without any binding data. 321 6.2.1. ACTIVELEASEQUERY 323 The new message type (ACTIVELEASEQUERY) is designed to assist 324 requestor keeping up to date in real-time (or near real-time) with 325 DHCPv6 bindings. It asks the server to return DHCPv6 bindings 326 activity that occurs subsequent to the receipt of the Active 327 Leasequery request. 329 An ACTIVELEASEQUERY request MUST contain a transaction-id, and that 330 transaction-id MUST BE locally unique to the TCP connection to the 331 DHCPv6 server. 333 While sending Active Leasequery request, requestor MAY include 334 OPTION_LQ_START_TIME option in ACTIVELEASEQUERY request. In this 335 case, DHCPv6 server returns all the bindings changed on or after the 336 OPTION_LQ_START_TIME. 338 If the requestor is interested in receiving all binding updates from 339 DHCPv6 server, it MUST NOT include OPTION_LQ_QUERY option in 340 ACTIVELEASEQUERY message. But if the requestor is only interested in 341 specific binding updates, it MAY include OPTION_LQ_QUERY option along 342 with query-types defined in [RFC5007] and [RFC5460]. 344 Other DHCPv6 options used in LEASEQUERY message (as specified in 345 [RFC5460]) can also be used in ACTIVELEASEQUERY request. 347 6.3. Options 349 New options (OPTION_LQ_BASE_TIME, OPTION_LQ_START_TIME and 350 OPTION_LQ_END_TIME) are defined as an extension to DHCPv6 Bulk 351 Leasequery [RFC5460]. DHCPv6 server sends OPTION_LQ_BASE_TIME option 352 in Active or Bulk Leasequery response if requestor ask for the same 353 in Active or Bulk Leasequery request. OPTION_LQ_START_TIME can be 354 used in Active or Bulk Leasequery request made to DHCPv6 server. 355 OPTION_LQ_END_TIME can be used in Bulk Leasequery request made to 356 DHCPv6 server. The reply messages for Active Leasequery uses the 357 options defined in [RFC3315], [RFC5007] and [RFC5460]. 359 6.3.1. OPTION_LQ_BASE_TIME 361 The OPTION_LQ_BASE_TIME option is the current time the message was 362 created to be sent by the DHCPv6 server to the requestor of the 363 Active or Bulk Leasequery. This MUST be an absolute time. All of 364 the other time based options in the reply message are relative to 365 this time, including OPTION_CLT_TIME [RFC5007]. This time is in the 366 context of the DHCPv6 server who placed this option in a message. 368 This is an unsigned integer in network byte order. 370 The code for this option is TBD. The length of this option is 4 371 octets. 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | OPTION_LQ_BASE_TIME | option-len | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | base-time | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 option-code OPTION_LQ_BASE_TIME (TBD). 382 option-len 4. 383 base-time DHCPv6 Server Base Time. 385 6.3.2. OPTION_LQ_START_TIME 387 The OPTION_LQ_START_TIME option specifies a query start time to the 388 DHCPv6 server. If specified, only bindings that have changed on or 389 after the OPTION_LQ_START_TIME should be included in the response to 390 the query. 392 The requestor MUST determine the OPTION_LQ_START_TIME using lease 393 information it has received from the DHCPv6 server. This MUST be an 394 absolute time in the DHCPv6 server's context (see Section 8.4). 396 Typically (though this is not a requirement) the OPTION_LQ_START_TIME 397 option will contain the value most recently received in a 398 OPTION_LQ_BASE_TIME option by the requestor, as this will indicate 399 the last successful communication with the DHCPv6 server. 401 This is an unsigned integer in network byte order. 403 The code for this option is TBD. The length of this option is 4 404 octets. 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | OPTION_LQ_START_TIME | option-len | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | query-start-time | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 option-code OPTION_LQ_START_TIME (TBD). 415 option-len 4. 416 query-start-time DHCPv6 Server Query Start Time. 418 6.3.3. OPTION_LQ_END_TIME 420 The OPTION_LQ_END_TIME option specifies a query end time to the 421 DHCPv6 server. If specified, only bindings that have changed on or 422 before the OPTION_LQ_END_TIME should be included in the response to 423 the query. This option MAY be used in Bulk Leasequery request. But 424 it MUST NOT be used in Active Leasequery request. 426 The requestor MUST determine the OPTION_LQ_END_TIME based on lease 427 information it has received from the DHCPv6 server. This MUST be an 428 absolute time in the context of the DHCPv6 server. 430 In the absence of information to the contrary, the requestor SHOULD 431 assume that the time context of the DHCPv6 server is identical to the 432 time context of the requestor (see Section 8.4). 434 This is an unsigned integer in network byte order. 436 The code for this option is TBD. The length of this option is 4 437 octets. 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | OPTION_LQ_END_TIME | option-len | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | query-end-time | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 option-code OPTION_LQ_END_TIME (TBD). 448 option-len 4. 449 query-end-time DHCPv6 Server Query End Time. 451 6.4. Connection and Transmission Parameters 453 Active Leasequery uses the same port configuration as DHCPv6 Bulk 454 Leasequery [RFC5460]. It also uses the other transmission parameters 455 (BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [RFC5460]. 457 This section presents a table of values used to control Active 458 Leasequery behavior, including recommended defaults. Implementations 459 MAY make these values configurable. However, configuring too-small 460 timeout values may lead to harmful behavior both to this application 461 as well as to other traffic in the network. As a result, timeout 462 values smaller than the default values are NOT RECOMMENDED. 464 Parameter Default Description 465 ---------------------------------------------------------------------- 466 ACTIVE_LQ_RCV_TIMEOUT 120 secs Active Leasequery receive timeout 467 ACTIVE_LQ_SEND_TIMEOUT 120 secs Active Leasequery send timeout 468 ACTIVE_LQ_IDLE_TIMEOUT 60 secs Active Leasequery idle timeout 470 7. Information Communicated by Active Leasequery 472 While the information communicated by a DHCPv6 Bulk Leasequery 473 [RFC5460] is taken directly from the DHCPv6 server's lease state 474 database, the information communicated by an Active Leasequery is 475 real-time information. As such, it is the information which is 476 currently associated with a particular binding in the DHCPv6 server's 477 lease state database. 479 This is of significance, because if the Active Leasequery requestor 480 runs slowly or the requestor disconnects from the DHCPv6 server and 481 then reconnects with a OPTION_LQ_START_TIME (signalling a catch-up 482 operation), the information communicated to the Active Leasequery 483 requestor is only the most current information from the DHCPv6 484 server's lease state database. 486 The requestor of an Active Leasequery MUST NOT assume that every 487 lease state change is communicated across an Active Leasequery 488 connection. Even if the Active Leasequery requestor remains 489 connected, the DHCPv6 server is only required to transmit information 490 about a binding that is current when the packet is created and handed 491 off to the TCP stack to send to the requestor. 493 If the TCP connection blocks and the DHCPv6 server is waiting to send 494 information down the connection, when the connection becomes 495 available to be written the DHCPv6 server MAY create the packet to 496 send at this time. The current state of the binding will be sent, 497 and any transition in state or other information that occurred while 498 the TCP connection was blocked will be lost. 500 Thus, the Active Leasequery protocol does not allow the requestor to 501 build a complete history of every activity on every lease. An 502 effective history of the important state changes for a lease can be 503 created if the parameters of the DHCPv6 server are tuned to take into 504 account the requirements of an Active Leasequery requestor. For 505 instance, the period after the expiration or release of a binding 506 could be configured long enough (say several minutes, well more than 507 the receive timeout), so that an Active Leasequery requestor would 508 never miss any changes in the binding. 510 8. Requestor Behavior 512 8.1. Connecting and General Processing 514 A Requestor attempts to establish a TCP connection to a DHCPv6 Server 515 in order to initiate a Active Leasequery exchange. If the attempt 516 fails, the Requestor MAY retry. 518 If an Active Leasequery is terminated prematurely by a LEASEQUERY- 519 DONE with a DHCPv6 status code (carried in an OPTION_STATUS_CODE 520 option) of QueryTerminated or by the failure of the connection over 521 which it was being submitted, the requestor MAY retry the request 522 after the creation of a new connection. 524 Messages from the DHCPv6 server come as multiple responses to a 525 single ACTIVELEASEQUERY message. Thus, each ACTIVELEASEQUERY request 526 MUST have an xid (transaction-id) unique on the connection on which 527 it is sent, and all of the messages which come as a response to it 528 contain the same xid as the request. It is the xid which allows the 529 data-streams of two or more different ACTIVELEASEQUERY requests to be 530 de-multiplexed by the requestor. 532 A requestor MAY send a ACTIVELEASEQUERY request to a DHCPv6 server 533 and immediately close the transmission side of its TCP connection, 534 and then read the resulting response messages from the DHCPv6 server. 535 This is not required, and the usual approach is to leave both sides 536 of the TCP connection up until at least the conclusion of the Active 537 Leasequery. 539 8.2. Forming an Active Leasequery 541 The Active Leasequery is designed to create a long lived connection 542 between the requestor and the DHCPv6 server processing the active 543 query. The DHCPv6 server will send binding information back across 544 this connection with minimal delay after it learns of the binding 545 information. It will learn about bindings either because it makes 546 the bindings itself or because it has received information about a 547 binding from another server. 549 To form the Active Leasequery, a DHCPv6 request is constructed with a 550 message type of ACTIVELEASEQUERY. The DHCPv6 request MUST contain a 551 transaction-id, and that transaction-id MUST BE locally unique to the 552 TCP connection to the DHCPv6 server. 554 An important capability of the Active Leasequery is the ability of 555 the requestor to specify that some recent data be sent immediately to 556 the requestor in parallel with the transmission of the ongoing 557 binding information in more or less real time. This capability is 558 used in order to allow an Active Leasequery requestor to recover 559 missed information in the event that it temporarily loses 560 connectivity with the DHCPv6 server processing a previous Active 561 Leasequery. 563 Note that until all of the recent data (catch-up data) has been 564 received, the requestor MUST NOT keep track of the base-time 565 (OPTION_LQ_BASE_TIME) received in Leasequery reply messages to use 566 later in a subsequent Active Leasequery request. 568 This capability is enabled by the transmission of a 4 octet 569 OPTION_LQ_BASE_TIME option with each Leasequery reply sent as the 570 result of a previous Active Leasequery. The requestor will typically 571 keep track of the highest base-time received from a particular DHCPv6 572 server over an Active Leasequery connection, and in the event that 573 the requestor finds it necessary (for whatever reason) to reestablish 574 an Active Leasequery connection to that DHCPv6 server, the requestor 575 will place this highest base-time value into a OPTION_LQ_START_TIME 576 option in the new Active Leasequery request. 578 If the requestor doesn't wish to request an update of information 579 missed when it was not connected to the DHCPv6 server, then it does 580 not include the OPTION_LQ_START_TIME option in the Active Leasequery 581 request. 583 If the TCP connection becomes blocked or stops being writable while 584 the requestor is sending its query, the requestor SHOULD be prepared 585 to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this 586 recommendation to allow requesters to control the period of time they 587 are willing to wait before abandoning a connection, independent of 588 notifications from the TCP implementations they may be using. 590 8.3. Processing Active Replies 592 The Requestor attempts to read a DHCPv6 LEASEQUERY-REPLY message from 593 the TCP connection. If the stream of replies becomes blocked, the 594 Requestor SHOULD be prepared to terminate the connection after 595 ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured 596 to do so. 598 The requestor examines the LEASEQUERY-REPLY message, and determines 599 how to proceed. Message validation rules are specified in DHCPv6 600 Leasequery [RFC5007] and DHCPv6 Bulk Leasequery [RFC5460]. If the 601 reply contains an DHCPv6 status code (carried in an 602 OPTION_STATUS_CODE option), the requestor follows the recommendations 603 in [RFC5007]. 605 Note that an Active Leasequery request specifically requests the 606 DHCPv6 server to create a long-lived connection which may not have 607 data transferring continuously during its lifetime. Therefore the 608 DHCPv6 server will send a LEASEQUERY-DATA message without binding 609 data (OPTION_CLIENT_DATA) every ACTIVE_LQ_IDLE_TIMEOUT seconds 610 (default 60) in order for the requestor to know that the connection 611 remains alive. This approach is followed only when connection is 612 idle (i.e. server has no binding data to send). During normal 613 binding data exchange, receiving of LEASEQUERY-DATA message by 614 requestor itself signifies that connection is active. Note that the 615 default for ACTIVE_LQ_RCV_TIMEOUT is 120 seconds, twice the value of 616 the ACTIVE_LQ_IDLE_TIMEOUT's default of 60 seconds which drives the 617 DHCPv6 server to send messages. Thus ACTIVE_LQ_RCV_TIMEOUT controls 618 how sensitive the requestor is to be to delays by the DHCPv6 server 619 in sending updates or LEASEQUERY-DATA messages. 621 A single Active Leasequery can and usually will result in a large 622 number of replies. The Requestor MUST be prepared to receive more 623 than one reply with transaction-ids matching a single 624 ACTIVELEASEQUERY message from a single DHCPv6 server. 626 An Active Leasequery has two regimes -- during the catch-up phase, if 627 any, and after any catch-up phase. During the catch-up phase (if one 628 exists), the data returned in the OPTION_LQ_BASE_TIME option in a 629 LEASEQUERY-REPLY or LEASEQUERY-DATA message may appear to be ordered, 630 but the most recent change in the lease state data being returned is 631 not related to the OPTION_LQ_BASE_TIME option value in the messages. 632 Another way to say this is that the ordering of the updates sent by 633 the DHCPv6 server during the catch-up phase is independent of the 634 ordering in the changes in the lease state data. The 635 OPTION_LQ_BASE_TIME option from messages during this phase MUST NOT 636 be saved and used in a subsequent ACTIVELEASEQUERY message's 637 OPTION_LQ_START_TIME option as it does not represent the extent of 638 progress of the catch-up activity. 640 After the catch-up phase, or during the entire series of messages 641 received as the response to a Active Leasequery request with no 642 OPTION_LQ_START_TIME (and therefore no catch-up phase), the 643 OPTION_LQ_BASE_TIME option of the most recent message SHOULD be saved 644 as a record of the most recent time that data was received. This 645 base-time (in the context of the DHCPv6 server) can be used in a 646 subsequent Active Leasequery message's OPTION_LQ_START_TIME after a 647 loss of the Active Leasequery connection. 649 The LEASEQUERY-DONE message MAY unilaterally terminate a successful 650 Active Leasequery request which is currently in progress in the event 651 that the DHCPv6 server determines that it cannot continue processing 652 a ACTIVELEASEQUERY request. For example, when a server is requested 653 to shut down it SHOULD send a LEASEQUERY-DONE message with a DHCPv6 654 status code of QueryTerminated and include OPTION_LQ_BASE_TIME option 655 in the message. This SHOULD be the last message on that connection, 656 and once the message has been transmitted, the server should close 657 the connection. 659 After receiving LEASEQUERY-DONE with a QueryTerminated status from a 660 server, the Requestor MAY close the TCP connection to that server. 662 8.3.1. Processing Replies from a Request Containing a 663 OPTION_LQ_START_TIME 665 If the Active Leasequery was requested with a OPTION_LQ_START_TIME, 666 the DHCPv6 server will attempt to send information about all bindings 667 that changed since the time specified in the OPTION_LQ_START_TIME. 668 This is the catch-up phase of the Active Leasequery processing. The 669 DHCPv6 server MAY also begin immediate updates over the same 670 connection of real-time binding information changes. Thus, the 671 catch-up phase may run in parallel with the normal updates generated 672 by the Active Leasequery request. 674 A DHCPv6 server MAY keep only a limited amount of time ordered 675 information available to respond to an Active Leasequery request 676 containing a OPTION_LQ_START_TIME. Thus, it is possible that the 677 time specified in the OPTION_LQ_START_TIME represents a time not 678 covered by the time ordered information kept by the DHCPv6 server. 679 If this should occur, and there is not enough data saved in the 680 DHCPv6 server to satisfy the request specified by the 681 OPTION_LQ_START_TIME option, the DHCPv6 server will reply immediately 682 with a LEASEQUERY-REPLY message with a DHCPv6 status code of 683 DataMissing with a base-time option equal to the server's current 684 time. This will signal the end of the catch-up phase, and the only 685 updates that will subsequently be received on this connection are the 686 real-time updates from the Active Leasequery request. 688 If there is enough data saved to satisfy the request, then 689 LEASEQUERY-REPLY (with OPTION_STATUS_CODE of Success or reply without 690 OPTION_STATUS_CODE option) and LEASEQUERY-DATA messages will begin 691 arrive from the DHCPv6 server. Some of these messages will be 692 related to the OPTION_LQ_START_TIME request and be part of the 693 catch-up phase. Some of these messages will be real-time updates of 694 binding changes taking place in the DHCPv6 server. In general, there 695 is no way to determine the source of each message. 697 Until the catch-up phase is complete, the latest base-time value 698 received from a DHCPv6 server processing an Active Leasequery request 699 cannot be reset from the incoming messages because to do so would 700 compromise the ability to recover lost information if the Active 701 Leasequery were to terminate prior to the completion of the catch-up 702 phase. 704 The requestor will know that the catch-up phase is complete when the 705 DHCPv6 server will transmit a LEASEQUERY-DATA message with the DHCPv6 706 status code of CatchUpComplete. Once this message is transmitted, 707 all additional LEASEQUERY-DATA messages will relate to real-time 708 ("new") binding changes in the DHCPv6 server. 710 As discussed in Section 8.3, the requestor SHOULD keep track of the 711 latest base-time option value received over a particular connection, 712 to be used in a subsequent Active Leasequery request -- but only if 713 the catch-up phase is complete. Prior to the completion of the 714 catch-up phase, if the connection should go away or if the requestor 715 receives a LEASEQUERY-DONE message, then when it reconnects it MUST 716 use the base-time value from the previous connection and not any 717 base-time value received from the recently closed connection. 719 In the event that there was enough data available to the DHCPv6 720 server to begin to satisfy the request implied by the 721 OPTION_LQ_START_TIME option, but during the processing of that data 722 the server found that it was unable to continue (perhaps there was 723 barely enough, the connection is very slow, and the aging algorithm 724 causes the saved data to become unavailable) the DHCPv6 server will 725 terminate the catch-up phase of processing immediately by sending a 726 LEASEQUERY-DATA message with a DHCPv6 status code of DataMissing and 727 with a base-time option of the current time. 729 The requestor MUST NOT assume that every individual state change of 730 every binding during the period from the time specified in the 731 OPTION_LQ_START_TIME and the present is replicated in an Active 732 Leasequery reply message. The requestor MAY assume that at least one 733 Active Leasequery reply message will exist for every binding which 734 had one or more changes of state during the period specified by the 735 OPTION_LQ_START_TIME and the current time. The last message for each 736 binding will contain the state at the current time, and there may be 737 one or more messages concerning a single binding during the catch-up 738 phase of processing. 740 If a binding changed state multiple times during the time that the 741 requestor was not connected (that is, during the time from the 742 OPTION_LQ_START_TIME and the present), then only the current binding 743 information will be sent during the catch-up phase. However, the 744 requestor MUST NOT assume that every intermediate state change that 745 occurred during the period from the OPTION_LQ_START_TIME to the 746 present will be represented by an individual Leasequery message. 748 If the LEASEQUERY-REPLY or LEASEQUERY-DATA message containing a 749 DHCPv6 status code of DataMissing is received and the requestor is 750 interested in keeping its database up to date with respect to the 751 current state of bindings in the DHCPv6 server, then the requestor 752 SHOULD issue a Bulk Leasequery request to recover the information 753 missing from its database. This Bulk Leasequery request should 754 include a OPTION_LQ_START_TIME, set to be the same as its 755 OPTION_LQ_START_TIME previously included in the ACTIVELEASEQUERY 756 responses from the DHCPv6 server, and a OPTION_LQ_END_TIME equal to 757 the OPTION_LQ_BASE_TIME returned by the DHCPv6 server in the 758 LEASEQUERY-REPLY or LEASEQUERY-DATA message with the DHCPv6 status 759 code of DataMissing. 761 In the event that the requestor receives a LEASEQUERY-REPLY or 762 LEASEQUERY-DATA message with a DHCPv6 status code of DataMissing, it 763 is a reasonable assumption that it is interested in keeping its 764 database up to date with respect to the DHCPv6 server's internal 765 binding database or it would not have included the 766 OPTION_LQ_START_TIME in the ACTIVELEASEQUERY message. 768 Typically, the requestor would have one connection open to a DHCPv6 769 server for a Active Leasequery request and possibly one additional 770 connection open for a Bulk Leasequery request to the same DHCPv6 771 server to fill in the data that might have been missed prior to the 772 initiation of the Active Leasequery. The Bulk Leasequery connection 773 would typically run to completion and be closed, leaving one Active 774 Leasequery connection open to a single DHCPv6 server. Alternatively, 775 both requests could be issued over a single connection. 777 8.4. Processing Time Values in Leasequery messages 779 Active or Bulk Leasequery requests may be made to a DHCPv6 server 780 whose absolute time may not be synchronized with the local time of 781 the requestor. Thus, there are at least two time contexts in even 782 the simplest Active or Bulk Leasequery response. 784 If the requestor of a Active or Bulk Leasequery is saving the data 785 returned in some form, it has a requirement to store a variety of 786 time values, and some of these will be time in the context of the 787 requestor and some will be time in the context of the DHCPv6 server. 789 When receiving a Active or Bulk Leasequery reply message from the 790 DHCPv6 server, the message will contain a OPTION_LQ_BASE_TIME option. 791 The time contained in this OPTION_LQ_BASE_TIME option is in the 792 context of the DHCPv6 server. As such, it is an ideal time to save 793 and use as input to an Active or Bulk Leasequery message in the 794 OPTION_LQ_START_TIME or OPTION_LQ_END_TIME option, should the 795 requestor need to ever issue an Active or Bulk Leasequery message 796 using these option as part of a later query, since these option 797 requires a time in the context of the DHCPv6 server. 799 In addition to saving the OPTION_LQ_BASE_TIME for possible future use 800 in OPTION_LQ_START_TIME or OPTION_LQ_END_TIME option, the 801 OPTION_LQ_BASE_TIME is used as part of the conversion of the other 802 times in the Leasequery message to values which are meaningful in the 803 context of the requestor. 805 In systems whose clocks are synchronized, perhaps using NTP, the 806 clock skew will usually be zero, which is not only acceptable, but 807 desired. 809 8.5. Examples 811 These examples illustrate what a series of queries and responses 812 might look like. These are only examples -- there are no requirement 813 that these sequence must be followed. 815 8.5.1. Query Failure 817 This example illustrates the message flows in case DHCPv6 server 818 identifies that it can not accept and/or process Active Leasequery 819 request from the client. This could be because of various reasons 820 (i.e. UnknownQueryType, MalformedQuery, NotConfigured, NotAllowed). 822 Client Server 823 ------ ------ 824 ACTIVELEASEQUERY xid 1 -----> 825 <----- LEASEQUERY-REPLY xid 1 (w/error) 827 8.5.2. Data Missing on Server 829 This example illustrates the message flows in case DHCPv6 server 830 identifies that it does not have enough data saved to satisfy the 831 request specified by the OPTION_LQ_START_TIME option. 833 In this case the DHCPv6 server will reply immediately with a 834 LEASEQUERY-REPLY message with a DHCPv6 status code of DataMissing 835 with a base-time option equal to the server's current time. This 836 will signal the end of the catch-up phase, and the only updates that 837 will subsequently be received on this connection are the real-time 838 updates from the Active Leasequery request. 840 Client Server 841 ------ ------ 842 ACTIVELEASEQUERY xid 2 -----> 843 <----- LEASEQUERY-REPLY xid 2 (w/error) 844 <----- LEASEQUERY-DATA xid 2 845 <----- LEASEQUERY-DATA xid 2 846 <----- LEASEQUERY-DATA xid 2 848 8.5.3. Successful Query 850 This example illustrates the message flows in case of successful 851 query processing by DHCPv6 server. 853 In this case the DHCPv6 server will reply immediately with a 854 LEASEQUERY-REPLY message (with OPTION_STATUS_CODE of Success or reply 855 without OPTION_STATUS_CODE option), followed by binding data in 856 LEASEQUERY-DATA messages. In case, DHCPv6 server wants to abort in- 857 process request and terminate the connection due to some reason, it 858 sends LEASEQUERY-DONE with error code present in OPTION_STATUS_CODE 859 option. 861 Client Server 862 ------ ------ 863 ACTIVELEASEQUERY xid 3 -----> 864 <----- LEASEQUERY-REPLY xid 3 865 <----- LEASEQUERY-DATA xid 3 866 <----- LEASEQUERY-DATA xid 3 867 <----- LEASEQUERY-DATA xid 3 868 <----- LEASEQUERY-DATA xid 3 869 <----- LEASEQUERY-DONE xid 3 (w/error) 871 8.6. Closing Connections 873 The Requestor or DHCPv6 Leasequery server MAY close its end of the 874 TCP connection at any time. The Requestor MAY choose to retain the 875 connection if it intends to issue additional queries. Note that this 876 client behavior does not guarantee that the connection will be 877 available for additional queries: the server might decide to close 878 the connection based on its own configuration. 880 9. Server Behavior 882 A DHCPv6 server which supports Active Leasequery MUST support DHCPv6 883 Bulk Leasequery [RFC5460] as well. 885 9.1. Accepting Connections 887 Servers that implement DHCPv6 Active Leasequery listen for incoming 888 TCP connections. Approach used in accepting (or rejecting) the 889 client connection is same as specified in DHCPv6 Bulk Leasequery 890 [RFC5460]. 892 9.2. Replying to an Active Leasequery 894 The DHCPv6 Leasequery [RFC5007] specification describes the initial 895 construction of LEASEQUERY-REPLY messages. Use of the LEASEQUERY- 896 REPLY and LEASEQUERY-DATA messages to carry multiple bindings is 897 described in DHCPv6 Bulk Leasequery [RFC5460]. Message transmission 898 and framing for TCP is described in Section 6.1. 900 If the connection becomes blocked while the server is attempting to 901 send reply messages, the server SHOULD be prepared to terminate the 902 TCP connection after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs 903 how much congestion the DHCPv6 server is prepared to tolerate over 904 any Active Leasequery connection. The default is two minutes, which 905 means that if more than two minutes goes by without the requestor 906 reading enough information to unblock the TCP connection, the DHCPv6 907 server will drop the TCP connection. 909 If the DHCPv6 server encounters an error during initial processing of 910 the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-REPLY 911 message containing an error code of some kind in a DHCPv6 status code 912 option. It SHOULD close the connection after this error is 913 signalled. 915 If the DHCPv6 server encounters an error during later processing of 916 the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-DONE 917 containing an error code of some kind in a DHCPv6 status code option. 918 It SHOULD close the connection after this error is signalled. 920 If the server finds any bindings satisfying a query, it sends each 921 binding's data in a reply message. The first reply message is a 922 LEASEQUERY-REPLY. The binding data is carried in an 923 OPTION_CLIENT_DATA option, as specified in [RFC5007]. The server 924 returns subsequent bindings in LEASEQUERY-DATA messages, which can 925 avoid redundant data (such as the requestor's Client-ID). 927 Every reply to a Active Leasequery request MUST contain the 928 information specified in replies to a DHCPv6 Bulk Leasequery request 929 [RFC5460]. 931 If an Active Leasequery or Bulk Leasequery request contains 932 OPTION_LQ_BASE_TIME option code present in OPTION_ORO, the DHCPv6 933 server MUST include OPTION_LQ_BASE_TIME option in every reply for 934 this request. The value for base-time option is current absolute 935 time in the DHCPv6 server's context. 937 If an Active Leasequery request contains a OPTION_LQ_START_TIME 938 option, it indicates that the requestor would like the DHCPv6 server 939 to send it not only messages that correspond to DHCPv6 binding 940 activity that occurs subsequent to the receipt of the Active 941 Leasequery request, but also messages that correspond to DHCPv6 942 binding activity that occurred prior to the Active Leasequery 943 request. 945 If OPTION_LQ_END_TIME option appears in a Active Leasequery request, 946 the DHCPv6 server should send a LEASEQUERY-REPLY message with a 947 DHCPv6 status code of MalformedQuery and terminate the connection. 949 In order to implement a meaningful response to this query, the DHCPv6 950 server MAY keep track of the binding activity and associate changes 951 with particular base-time values from the messages. Then, when 952 requested to do so by a Active Leasequery request containing a 953 OPTION_LQ_START_TIME option, the DHCPv6 server can respond with 954 replies for all binding activity occurring on that 955 OPTION_LQ_START_TIME or later times. 957 These replies based on the OPTION_LQ_START_TIME MAY be interleaved 958 with the messages generated due to current binding activity. 960 Once the transmission of the DHCPv6 Leasequery messages associated 961 with the OPTION_LQ_START_TIME option are complete, a LEASEQUERY-DATA 962 message MUST be sent with a DHCPv6 status code value of 963 CatchUpComplete. 965 The DHCPv6 server SHOULD, but is not required to, keep track of a 966 limited amount of previous binding activity. The DHCPv6 server MAY 967 choose to only do this in the event that it has received at least one 968 Active Leasequery request in the past, as to do so will almost 969 certainly entail some utilization of resources which would be wasted 970 if there are no Active Leasequery clients for this DHCPv6 server. 971 The DHCPv6 server SHOULD make the amount of previous binding activity 972 it retains configurable. There is no requirement on the DHCPv6 973 server to retain this information over a server restart (or even to 974 retain such information at all). 976 Unless there is an error or some requirement to cease processing a 977 Active Leasequery request yielding a LEASEQUERY-DONE message, such as 978 a server shutdown, there will be no LEASEQUERY-DONE message at the 979 conclusion of the Active Leasequery processing because that 980 processing will not conclude but will continue until either the 981 client or the server drops the connection. 983 9.3. Multiple or Parallel Queries 985 Requesters may want to use an existing connection if they need to 986 make multiple queries. Servers MAY support reading and processing 987 multiple queries from a single connection. A server MUST NOT read 988 more query messages from a connection than it is prepared to process 989 simultaneously. 991 Typically, a requestor of a Active Leasequery would not need to send 992 a second Active Leasequery while the first is still active. However, 993 sending an Active Leasequery and a Bulk Leasequery over the same 994 connection would be possible and reasonable. But it is RECOMMENDED 995 to use different connection in case of parallel Active and Bulk 996 Leasequeries. 998 This MAY be a feature that is administratively controlled. Servers 999 that are able to process queries in parallel SHOULD offer 1000 configuration that limits the number of simultaneous queries 1001 permitted from any one requestor, in order to control resource use if 1002 there are multiple requesters seeking service. 1004 9.4. Closing Connections 1006 The server MUST close its end of the TCP connection if it encounters 1007 an error sending data on the connection. The server MUST close its 1008 end of the TCP connection if it finds that it has to abort an in- 1009 process request. A server aborting an in-process request SHOULD 1010 attempt to signal that to its clients by using the QueryTerminated 1011 status code in the DHCPv6 status code option in a LEASEQUERY-DONE 1012 message. If the server detects that the client end has been closed, 1013 the server MUST close its end of the connection after it has finished 1014 processing any outstanding requests from the client. 1016 The server SHOULD be prepared to limit the number of connections it 1017 maintains, and SHOULD be prepared to close idle connections to 1018 enforce the limit. 1020 10. Security Considerations 1022 The "Security Considerations" section of [RFC3315] details the 1023 general threats to DHCPv6. The DHCPv6 Leasequery specification 1024 [RFC5007] describes recommendations for the Leasequery protocol, 1025 especially with regard to relayed Leasequery messages, mitigation of 1026 packet-flooding denial-of-service (DoS) attacks, restriction to 1027 trusted clients, and use of IPsec [RFC4301]. 1029 The use of TCP introduces some additional concerns. Attacks that 1030 attempt to exhaust the DHCPv6 server's available TCP connection 1031 resources, such as SYN flooding attacks, can compromise the ability 1032 of legitimate clients to receive service. Malicious clients who 1033 succeed in establishing connections, but who then send invalid 1034 queries, partial queries, or no queries at all also can exhaust a 1035 server's pool of available connections. We recommend that servers 1036 offer configuration to limit the sources of incoming connections, 1037 that they limit the number of accepted connections and the number of 1038 in-process queries from any one connection, and that they limit the 1039 period of time during which an idle connection will be left open. 1041 There are two specific issues regarding Active Leasequery security 1042 that deserve explicit mention. The first is preventing information 1043 that Active Leasequery can provide from reaching clients who are not 1044 authorized to receive such information. The second is ensuring that 1045 authorized clients of the Active Leasequery capability receive 1046 accurate information from the Server (and that this information is 1047 not disrupted in transit). 1049 To prevent information leakage to unauthorized clients Servers SHOULD 1050 restrict Active Leasequery connections and ACTIVELEASEQUERY messages 1051 to certain requestors, either through explicit configuration of the 1052 Server itself or by employing external network elements to provide 1053 such restrictions. In particular, the typical DHCPv6 client SHOULD 1054 NOT be allowed to receive a response to an Active Leasequery request, 1055 and some technique MUST exist to allow prevention of such access in 1056 any environment where Active Leasequery is deployed. 1058 Connections not from permitted requestors SHOULD be closed 1059 immediately, to avoid server connection resource exhaustion or 1060 alternatively, simply not be allowed to reach the server at all. 1061 Servers SHOULD have the capability to restrict certain requestors to 1062 certain query types. Servers MAY reply to queries that are not 1063 permitted with the LEASEQUERY-DONE message with a status-code option 1064 status of NotAllowed, or MAY simply close the connection. 1066 To prevent disruption and malicious corruption of Active Leasequery 1067 data flows between the server and authorized clients these data flows 1068 SHOULD transit only secured networks. These data flows are typically 1069 infrastructure oriented, and there is usually no reason to have them 1070 flowing over networks where such attacks are likely. In the rare 1071 cases where these data flows might need to be sent through unsecured 1072 networks, they MUST sent over connections secured through means 1073 external to the DHCPv4/DHCPv6 server and its client(s) (e.g., through 1074 VPN's). 1076 Authentication for DHCP Messages [RFC3315] MUST NOT be used to 1077 attempt to secure transmission of the messages described in this 1078 document. 1080 11. IANA Considerations 1082 IANA is requested to assign new DHCPv6 Option Codes in the registry 1083 maintained in http://www.iana.org/assignments/dhcpv6-parameters: 1085 OPTION_LQ_BASE_TIME 1086 OPTION_LQ_START_TIME 1087 OPTION_LQ_END_TIME 1089 IANA is requested to assign new values in the registry of DHCPv6 1090 Status Codes maintained in 1091 http://www.iana.org/assignments/dhcpv6-parameters: 1093 DataMissing 1094 CatchUpComplete 1096 IANA is requested to assign value for the following new DHCPv6 1097 Message type in the registry maintained in 1098 http://www.iana.org/assignments/dhcpv6-parameters: 1100 ACTIVELEASEQUERY 1102 12. Acknowledgements 1104 Many of the ideas in this document were originally proposed by Kim 1105 Kinnear, Bernie Volz, Mark Stapp and John Brzozowski. Many of the 1106 concept and content, present in this document, are based on DHCPv4 1107 Active Leasequery. 1109 13. Modification History 1111 14. References 1113 14.1. Normative References 1115 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1116 and M. Carney, "Dynamic Host Configuration Protocol for 1117 IPv6 (DHCPv6)", RFC 3315, July 2003. 1119 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1120 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1121 December 2003. 1123 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1124 Requirement Levels", BCP 14, RFC 2119, March 1997. 1126 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 1127 "DHCPv6 Leasequery", RFC 5007, September 2007. 1129 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 1130 February 2009. 1132 14.2. Informative References 1134 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1135 Internet Protocol", RFC 4301, December 2005. 1137 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 1138 for Transmission Control Protocol (TCP) Specification 1139 Documents", RFC 4614, September 2006. 1141 Authors' Addresses 1143 Dushyant Raghuvanshi 1144 Cisco Systems, Inc. 1145 Cessna Business Park, 1146 Varthur Hobli, Outer Ring Road, 1147 Bangalore, Karnataka 560037 1148 India 1150 Phone: +91 080 4365 7476 1151 Email: draghuva@cisco.com 1153 Deepak Kukrety 1154 Cisco Systems, Inc. 1155 Cessna Business Park, 1156 Varthur Hobli, Outer Ring Road, 1157 Bangalore, Karnataka 560037 1158 India 1160 Phone: +91 080 4365 7474 1161 Email: dkukrety@cisco.com