idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 (December 4, 2013) is 3796 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 informational reference (is this intentional?): RFC 4614 (Obsoleted by RFC 7414) Summary: 3 errors (**), 0 flaws (~~), 2 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 K. Kinnear 4 Intended status: Standards Track D. Kukrety 5 Expires: June 7, 2014 Cisco Systems, Inc. 6 December 4, 2013 8 DHCPv6 Active Leasequery 9 draft-ietf-dhc-dhcpv6-active-leasequery-00 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 until the time DHCPv6 17 server receive the Leasequery request. Continuous update of an 18 external requestor with Leasequery data is sometimes desired. This 19 document expands on the DHCPv6 Leasequery protocol, and allows for 20 active transfer of real-time DHCPv6 binding information data via TCP. 21 This document also extends DHCPv6 Bulk Leasequery by adding new 22 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 June 7, 2014. 41 Copyright Notice 43 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Interaction Between Active Leasequery and Bulk Leasequery . . 6 62 5. Extension to DHCPv6 Bulk Leasequery . . . . . . . . . . . . . 7 63 6. Message and Option Definitions . . . . . . . . . . . . . . . 7 64 6.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 7 65 6.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.2.1. ACTIVELEASEQUERY . . . . . . . . . . . . . . . . . . 7 67 6.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.3.1. OPTION_LQ_BASE_TIME . . . . . . . . . . . . . . . . . 8 69 6.3.2. OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 9 70 6.3.3. OPTION_LQ_END_TIME . . . . . . . . . . . . . . . . . 9 71 6.4. Connection and Transmission Parameters . . . . . . . . . 10 72 7. Information Communicated by Active Leasequery . . . . . . . . 11 73 8. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 11 74 8.1. Connecting and General Processing . . . . . . . . . . . . 11 75 8.2. Forming an Active Leasequery . . . . . . . . . . . . . . 12 76 8.3. Processing Active Replies . . . . . . . . . . . . . . . . 13 77 8.3.1. Processing Replies from a Request Containing a 78 OPTION_LQ_START_TIME . . . . . . . . . . . . . . . . 15 79 8.4. Processing Time Values in Leasequery messages . . . . . . 17 80 8.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 18 81 8.5.1. Query Failure . . . . . . . . . . . . . . . . . . . . 18 82 8.5.2. Data Missing on Server . . . . . . . . . . . . . . . 18 83 8.5.3. Successful Query . . . . . . . . . . . . . . . . . . 19 84 8.6. Closing Connections . . . . . . . . . . . . . . . . . . . 19 85 9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 19 86 9.1. Accepting Connections . . . . . . . . . . . . . . . . . . 19 87 9.2. Replying to an Active Leasequery . . . . . . . . . . . . 20 88 9.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 22 89 9.4. Closing Connections . . . . . . . . . . . . . . . . . . . 22 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 91 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 93 13. Modification History . . . . . . . . . . . . . . . . . . . . 24 94 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 14.1. Normative References . . . . . . . . . . . . . . . . . . 24 96 14.2. Informative References . . . . . . . . . . . . . . . . . 25 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 100 1. Introduction 102 The DHCPv6 [RFC3315] protocol specifies a mechanism for the 103 assignment of IPv6 address and configuration information to IPv6 104 nodes. IPv6 Prefix Delegation for DHCPv6 (PD) [RFC3633] specifies a 105 mechanism for DHCPv6 delegation of IPv6 prefixes and related data. 106 DHCPv6 servers maintain authoritative information including binding 107 information for delegated IPv6 prefixes. 109 Requirements exist for external entities to keep up to date on the 110 correspondence between DHCPv6 clients and their bindings. These 111 requirements often stem from regulatory requirements placed on 112 service providers by governmental agencies. 114 These entities need to keep up with the current binding activity of 115 the DHCPv6 server. Keeping up with these binding activity is termed 116 "active" leasequery. 118 The DHCPv6 Bulk Leasequery [RFC5460] capability can be used to 119 recover useful information from a DHCPv6 server when some external 120 entity starts up. This entity could be one which is directly 121 involved in the DHCPv6 client - server transactions (e.g., a relay 122 agent), or it could be an external process which needs information 123 present in the DHCPv6 server's lease state database. 125 The Active Leasequery capability documented here is designed to allow 126 an entity not directly involved in DHCPv6 client - server 127 transactions to nevertheless keep current with the state of the 128 DHCPv6 lease state information in real-time. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 DHCPv6 terminology is defined in [RFC3315]. Terminology specific to 137 DHCPv6 Active Leasequery can be found below: 139 o "Absolute Time" 141 A 32-bit quantity containing the number of seconds since midnight 142 January 1, 2000 UTC. 144 o "Active Leasequery" 145 Keeping up to date in real-time (or near real-time) with DHCPv6 146 binding activity. 148 o "Bulk Leasequery" 150 Requesting and receiving the existing DHCPv6 binding information 151 in an efficient manner. 153 o "catch-up information, catch-up phase" 155 If a DHCPv6 Active Leasequery requestor sends OPTION_LQ_START_TIME 156 option in a ACTIVELEASEQUERY message, the DHCPv6 server will 157 attempt to send the requestor the information that changed since 158 the time specified in the OPTION_LQ_START_TIME option. The 159 binding information sent to satisfy this request is the catch-up 160 information, and the period while it is being sent is the catch-up 161 phase. 163 o "clock skew" 165 The difference between the absolute time on a DHCPv6 server and 166 the absolute time on the system where a requestor of an Active or 167 Bulk Leasequery is executing is termed the "clock skew" for that 168 Active or Bulk Leasequery connection. It is not absolutely 169 constant but is likely to vary only slowly. While it is easy to 170 think that this can be calculated precisely after one packet is 171 received by a requestor from a DHCPv6 server, a more accurate 172 value is derived from continuously examining the instantaneous 173 value developed from each packet received from a DHCPv6 server and 174 using it to make small adjustments to the existing value held in 175 the requestor. 177 o "Transaction ID" 179 An opaque value used to match responses with queries initiated by 180 an Active Leasequery requestor. 182 3. Protocol Overview 184 The Active Leasequery mechanism is modeled on the existing DHCPv6 185 Bulk Leasequery [RFC5460]; most differences arise from the long term 186 nature of the TCP [RFC4614] connection required for Active 187 Leasequery. In addition, a DHCPv6 server which supports Active 188 Leasequery MUST support Bulk Leasequery [RFC5460] as well. 190 An Active Leasequery requestor opens a TCP connection to a DHCPv6 191 Server, using the DHCPv6 port 547. Note that this implies that the 192 Leasequery requestor has server IP address(es) available via 193 configuration or some other means, and that it has unicast IP 194 reachability to the DHCPv6 server. No relaying for Active Leasequery 195 is specified. 197 After establishing a connection, the requestor sends an 198 ACTIVELEASEQUERY message over the connection. In response, the 199 server sends updates to the requestor using LEASEQUERY-REPLY and 200 LEASEQUERY-DATA messages. This response procedure is identical to 201 [RFC5460], except that in case of Active Leasequery server sends 202 updates whenever some activity occurs to change binding state - thus 203 the need for long lived connection. Active Leasequery is designed to 204 provide continuous updates of DHCPv6 IPv6 binding activity to an 205 external entity. 207 Active Leasequery has features which allow this external entity to 208 lose its connection and then reconnect and receive the latest 209 information concerning any IPv6 bindings changed while it was not 210 connected. 212 These capabilities are designed to allow the Active Leasequery 213 requestor to efficiently become current with respect to the lease 214 state database after it has been restarted or the machine on which it 215 is running has been reinitialized. It is easy to define a protocol 216 which works when the requestor is always connected to the DHCPv6 217 server. Since that isn't sufficiently robust, much of the mechanism 218 in this document is designed to deal efficiently with situations that 219 occur when the Active Leasequery requestor becomes disconnected from 220 the DHCPv6 server from which it is receiving updates and then becomes 221 reconnected to that server. 223 Central to this approach, if the Active Leasequery requestor loses 224 service, it is allowed to specify the time of its most recent update 225 in a subsequent Active Leasequery request and the DHCPv6 server will 226 determine whether or not data was missed while the Active Leasequery 227 requestor was not connected. 229 The DHCPv6 server processing the Active Leasequery request may limit 230 the amount of data saved, and methods exist for the DHCPv6 server to 231 inform the Active Leasequery requestor that more data was missed than 232 could be saved. In this situation, the Active Leasequery requestor 233 would issue a Bulk Leasequery [RFC5460] to recover information not 234 available through an Active Leasequery. 236 DHCPv6 servers are not required to keep any data corresponding to 237 data missed on a Active Leasequery connection, but will typically 238 choose to keep data corresponding to some recent activity available 239 for subsequent queries by a DHCPv6 Active Leasequery requestor whose 240 connection was temporarily interrupted. 242 An Active Leasequery requestor would typically use Bulk Leasequery to 243 initialize its database with all current data when that database 244 contains no binding information. In addition, it would use Bulk 245 Leasequery to recover missed information in the event that its 246 connection with the DHCPv6 server was lost for a longer time than the 247 DHCPv6 server would keep track of the specific changes to the IPv6 248 binding information. 250 The messages sent by the server in response to an Active Leasequery 251 request SHOULD be identical to the messages sent by the server to a 252 Bulk Leasequery request regarding the way the data is encoded into 253 the Active Leasequery responses. In addition, the actions taken by 254 the Active Leasequery requestor to interpret the responses to an 255 Active Leasequery request SHOULD be identical to the way that the 256 requestor interprets the responses to a Bulk Leasequery request. 257 Thus, the handling of OPTION_CLIENT_DATA and additional options 258 discussed in the Bulk Leasequery specification [RFC5460] are to be 259 followed when implementing Active Leasequery. 261 4. Interaction Between Active Leasequery and Bulk Leasequery 263 Active Leasequery can be seen as an extension of the Bulk Leasequery 264 protocol [RFC5460]. The format of packets returned to an Active 265 Leasequery requestor are identical to that defined for the Bulk 266 Leasequery protocol [RFC5460]. 268 Applications which employ Active Leasequery to keep a database up to 269 date with respect to the DHCPv6 server's lease state database will 270 usually use an initial Bulk Leasequery to bring their database into 271 equivalence with that of the DHCPv6 server, and then use Active 272 Leasequery to keep that database current with respect to the DHCPv6 273 server's lease state database. 275 There are several differences between the Active and Bulk Leasequery 276 protocols. Active Leasequery defines a new message 277 (ACTIVELEASEQUERY) to send Active Leasequery request to DHCPv6 278 server. An Active Leasequery connection sends all available updates 279 to the requestor, based on OPTION_LQ_QUERY option (see 280 Section 6.2.1). 282 An Active Leasequery connection does not ever "complete", though the 283 DHCPv6 server may drop the connection for a variety of reasons 284 associated with some sort of exception condition. 286 5. Extension to DHCPv6 Bulk Leasequery 288 This document extends to the capabilities of DHCPv6 Bulk Leasequery 289 protocol [RFC5460] by defining new options. More details about these 290 options are specified in Section 6.3. 292 6. Message and Option Definitions 294 6.1. Message Framing for TCP 296 The use of TCP for the Active Leasequery protocol permits one or more 297 DHCPv6 messages to be sent at a time. The receiver needs to be able 298 to determine how large each message is. The same message framing 299 technique used for DHCPv6 Bulk Leasequery [RFC5460] is used for 300 Active Leasequery as well. 302 The intent in using the same format is that code which currently 303 knows how to deal with a message returned from DHCPv6 Bulk Leasequery 304 [RFC5460] will be able to deal with the message held inside of the 305 TCP framing. 307 6.2. Messages 309 The LEASEQUERY-REPLY message is defined in [RFC5007]. The 310 LEASEQUERY-DATA and LEASEQUERY-DONE messages are defined in 311 [RFC5460]. 313 In a Active Leasequery exchange, a single LEASEQUERY-REPLY message is 314 used to indicate the success or failure of a query, and to carry data 315 that do not change in the context of a single query and answer, such 316 as the Server-ID and Client-ID options. If a query is successful, 317 only a single LEASEQUERY-REPLY message MUST appear. If the server is 318 returning binding data, the LEASEQUERY-REPLY also contains the first 319 client's binding data in an OPTION_CLIENT_DATA option. Additional 320 binding data is returned using LEASEQUERY-DATA message as explained 321 in DHCPv6 Bulk Leasequery [RFC5460]. In case of failure query, 322 single LEASEQUERY-REPLY message is returned without any binding data. 324 6.2.1. ACTIVELEASEQUERY 326 The new message type (ACTIVELEASEQUERY) is designed to assist 327 requestor keeping up to date in real-time (or near real-time) with 328 DHCPv6 bindings. It asks the server to return DHCPv6 bindings 329 activity that occurs subsequent to the receipt of the Active 330 Leasequery request. 332 An ACTIVELEASEQUERY request MUST contain a transaction-id, and that 333 transaction-id MUST BE locally unique to the TCP connection to the 334 DHCPv6 server. 336 While sending Active Leasequery request, requestor MAY include 337 OPTION_LQ_START_TIME option in ACTIVELEASEQUERY request. In this 338 case, DHCPv6 server returns all the bindings changed on or after the 339 OPTION_LQ_START_TIME. 341 If the requestor is interested in receiving all binding updates from 342 DHCPv6 server, it MUST NOT include OPTION_LQ_QUERY option in 343 ACTIVELEASEQUERY message. But if the requestor is only interested in 344 specific binding updates, it MAY include OPTION_LQ_QUERY option along 345 with query-types defined in [RFC5007] and [RFC5460]. 347 Other DHCPv6 options used in LEASEQUERY message (as specified in 348 [RFC5460]) can also be used in ACTIVELEASEQUERY request. 350 6.3. Options 352 New options (OPTION_LQ_BASE_TIME, OPTION_LQ_START_TIME and 353 OPTION_LQ_END_TIME) are defined as an extension to DHCPv6 Bulk 354 Leasequery [RFC5460]. DHCPv6 server sends OPTION_LQ_BASE_TIME option 355 in Active or Bulk Leasequery response if requestor ask for the same 356 in Active or Bulk Leasequery request. OPTION_LQ_START_TIME can be 357 used in Active or Bulk Leasequery request made to DHCPv6 server. 358 OPTION_LQ_END_TIME can be used in Bulk Leasequery request made to 359 DHCPv6 server. The reply messages for Active Leasequery uses the 360 options defined in [RFC3315], [RFC5007] and [RFC5460]. 362 6.3.1. OPTION_LQ_BASE_TIME 364 The OPTION_LQ_BASE_TIME option is the current time the message was 365 created to be sent by the DHCPv6 server to the requestor of the 366 Active or Bulk Leasequery. This MUST be an absolute time (i.e. 367 seconds since midnight 1 Jan 2000 UTC modulo 2^32). All of the other 368 time based options in the reply message are relative to this time, 369 including OPTION_CLT_TIME [RFC5007]. This time is in the context of 370 the DHCPv6 server who placed this option in a message. 372 This is an unsigned integer in network byte order. 374 The code for this option is TBD. The length of this option is 4 375 octets. 377 0 1 2 3 378 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | OPTION_LQ_BASE_TIME | option-len | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | base-time | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 option-code OPTION_LQ_BASE_TIME (TBD). 387 option-len 4. 388 base-time DHCPv6 Server Base Time. 390 6.3.2. OPTION_LQ_START_TIME 392 The OPTION_LQ_START_TIME option specifies a query start time to the 393 DHCPv6 server. If specified, only bindings that have changed on or 394 after the OPTION_LQ_START_TIME should be included in the response to 395 the query. 397 The requestor MUST determine the OPTION_LQ_START_TIME using lease 398 information it has received from the DHCPv6 server. This MUST be an 399 absolute time in the DHCPv6 server's context (see Section 8.4). 401 Typically (though this is not a requirement) the OPTION_LQ_START_TIME 402 option will contain the value most recently received in a 403 OPTION_LQ_BASE_TIME option by the requestor, as this will indicate 404 the last successful communication with the DHCPv6 server. 406 This is an unsigned integer in network byte order. 408 The code for this option is TBD. The length of this option is 4 409 octets. 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | OPTION_LQ_START_TIME | option-len | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | query-start-time | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 option-code OPTION_LQ_START_TIME (TBD). 420 option-len 4. 421 query-start-time DHCPv6 Server Query Start Time. 423 6.3.3. OPTION_LQ_END_TIME 424 The OPTION_LQ_END_TIME option specifies a query end time to the 425 DHCPv6 server. If specified, only bindings that have changed on or 426 before the OPTION_LQ_END_TIME should be included in the response to 427 the query. This option MAY be used in Bulk Leasequery request. But 428 it MUST NOT be used in Active Leasequery request. 430 The requestor MUST determine the OPTION_LQ_END_TIME based on lease 431 information it has received from the DHCPv6 server. This MUST be an 432 absolute time in the context of the DHCPv6 server. 434 In the absence of information to the contrary, the requestor SHOULD 435 assume that the time context of the DHCPv6 server is identical to the 436 time context of the requestor (see Section 8.4). 438 This is an unsigned integer in network byte order. 440 The code for this option is TBD. The length of this option is 4 441 octets. 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | OPTION_LQ_END_TIME | option-len | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | query-end-time | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 option-code OPTION_LQ_END_TIME (TBD). 452 option-len 4. 453 query-end-time DHCPv6 Server Query End Time. 455 6.4. Connection and Transmission Parameters 457 Active Leasequery uses the same port configuration as DHCPv6 Bulk 458 Leasequery [RFC5460]. It also uses the other transmission parameters 459 (BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [RFC5460]. 461 This section presents a table of values used to control Active 462 Leasequery behavior, including recommended defaults. Implementations 463 MAY make these values configurable. However, configuring too-small 464 timeout values may lead to harmful behavior both to this application 465 as well as to other traffic in the network. As a result, timeout 466 values smaller than the default values are NOT RECOMMENDED. 468 Parameter Default Description 469 ---------------------------------------------------------------------- 470 ACTIVE_LQ_RCV_TIMEOUT 120 secs Active Leasequery receive timeout 471 ACTIVE_LQ_SEND_TIMEOUT 120 secs Active Leasequery send timeout 472 ACTIVE_LQ_IDLE_TIMEOUT 60 secs Active Leasequery idle timeout 474 7. Information Communicated by Active Leasequery 476 While the information communicated by a DHCPv6 Bulk Leasequery 477 [RFC5460] is taken directly from the DHCPv6 server's lease state 478 database, the information communicated by an Active Leasequery is 479 real-time information. As such, it is the information which is 480 currently associated with a particular binding in the DHCPv6 server's 481 lease state database. 483 This is of significance, because if the Active Leasequery requestor 484 runs slowly or the requestor disconnects from the DHCPv6 server and 485 then reconnects with a OPTION_LQ_START_TIME (signalling a catch-up 486 operation), the information communicated to the Active Leasequery 487 requestor is only the most current information from the DHCPv6 488 server's lease state database. 490 The requestor of an Active Leasequery MUST NOT assume that every 491 lease state change is communicated across an Active Leasequery 492 connection. Even if the Active Leasequery requestor remains 493 connected, the DHCPv6 server is only required to transmit information 494 about a binding that is current when the packet is created and handed 495 off to the TCP stack to send to the requestor. 497 If the TCP connection blocks and the DHCPv6 server is waiting to send 498 information down the connection, when the connection becomes 499 available to be written the DHCPv6 server MAY create the packet to 500 send at this time. The current state of the binding will be sent, 501 and any transition in state or other information that occurred while 502 the TCP connection was blocked will be lost. 504 Thus, the Active Leasequery protocol does not allow the requestor to 505 build a complete history of every activity on every lease. An 506 effective history of the important state changes for a lease can be 507 created if the parameters of the DHCPv6 server are tuned to take into 508 account the requirements of an Active Leasequery requestor. For 509 instance, the period after the expiration or release of a binding 510 could be configured long enough (say several minutes, well more than 511 the receive timeout), so that an Active Leasequery requestor would 512 never miss any changes in the binding. 514 8. Requestor Behavior 516 8.1. Connecting and General Processing 517 A Requestor attempts to establish a TCP connection to a DHCPv6 Server 518 in order to initiate a Active Leasequery exchange. If the attempt 519 fails, the Requestor MAY retry. 521 If an Active Leasequery is terminated prematurely by a LEASEQUERY- 522 DONE with a DHCPv6 status code (carried in an OPTION_STATUS_CODE 523 option) of QueryTerminated or by the failure of the connection over 524 which it was being submitted, the requestor MAY retry the request 525 after the creation of a new connection. 527 Messages from the DHCPv6 server come as multiple responses to a 528 single ACTIVELEASEQUERY message. Thus, each ACTIVELEASEQUERY request 529 MUST have an xid (transaction-id) unique on the connection on which 530 it is sent, and all of the messages which come as a response to it 531 contain the same xid as the request. It is the xid which allows the 532 data-streams of two or more different ACTIVELEASEQUERY requests to be 533 de-multiplexed by the requestor. 535 A requestor MAY send a ACTIVELEASEQUERY request to a DHCPv6 server 536 and immediately close the transmission side of its TCP connection, 537 and then read the resulting response messages from the DHCPv6 server. 538 This is not required, and the usual approach is to leave both sides 539 of the TCP connection up until at least the conclusion of the Active 540 Leasequery. 542 8.2. Forming an Active Leasequery 544 The Active Leasequery is designed to create a long lived connection 545 between the requestor and the DHCPv6 server processing the active 546 query. The DHCPv6 server will send binding information back across 547 this connection with minimal delay after it learns of the binding 548 information. It will learn about bindings either because it makes 549 the bindings itself or because it has received information about a 550 binding from another server. 552 To form the Active Leasequery, a DHCPv6 request is constructed with a 553 message type of ACTIVELEASEQUERY. The DHCPv6 request MUST contain a 554 transaction-id, and that transaction-id MUST BE locally unique to the 555 TCP connection to the DHCPv6 server. 557 An important capability of the Active Leasequery is the ability of 558 the requestor to specify that some recent data be sent immediately to 559 the requestor in parallel with the transmission of the ongoing 560 binding information in more or less real time. This capability is 561 used in order to allow an Active Leasequery requestor to recover 562 missed information in the event that it temporarily loses 563 connectivity with the DHCPv6 server processing a previous Active 564 Leasequery. 566 Note that until all of the recent data (catch-up data) has been 567 received, the requestor MUST NOT keep track of the base-time 568 (OPTION_LQ_BASE_TIME) received in Leasequery reply messages to use 569 later in a subsequent Active Leasequery request. 571 This capability is enabled by the transmission of a 4 octet 572 OPTION_LQ_BASE_TIME option with each Leasequery reply sent as the 573 result of a previous Active Leasequery. The requestor will typically 574 keep track of the highest base-time received from a particular DHCPv6 575 server over an Active Leasequery connection, and in the event that 576 the requestor finds it necessary (for whatever reason) to reestablish 577 an Active Leasequery connection to that DHCPv6 server, the requestor 578 will place this highest base-time value into a OPTION_LQ_START_TIME 579 option in the new Active Leasequery request. 581 If the requestor doesn't wish to request an update of information 582 missed when it was not connected to the DHCPv6 server, then it does 583 not include the OPTION_LQ_START_TIME option in the Active Leasequery 584 request. 586 If the TCP connection becomes blocked or stops being writable while 587 the requestor is sending its query, the requestor SHOULD be prepared 588 to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this 589 recommendation to allow requesters to control the period of time they 590 are willing to wait before abandoning a connection, independent of 591 notifications from the TCP implementations they may be using. 593 8.3. Processing Active Replies 595 The Requestor attempts to read a DHCPv6 LEASEQUERY-REPLY message from 596 the TCP connection. If the stream of replies becomes blocked, the 597 Requestor SHOULD be prepared to terminate the connection after 598 ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured 599 to do so. 601 The requestor examines the LEASEQUERY-REPLY message, and determines 602 how to proceed. Message validation rules are specified in DHCPv6 603 Leasequery [RFC5007] and DHCPv6 Bulk Leasequery [RFC5460]. If the 604 reply contains an DHCPv6 status code (carried in an 605 OPTION_STATUS_CODE option), the requestor follows the recommendations 606 in [RFC5007]. 608 Note that an Active Leasequery request specifically requests the 609 DHCPv6 server to create a long-lived connection which may not have 610 data transferring continuously during its lifetime. Therefore the 611 DHCPv6 server will send a LEASEQUERY-DATA message without binding 612 data (OPTION_CLIENT_DATA) every ACTIVE_LQ_IDLE_TIMEOUT seconds 613 (default 60) in order for the requestor to know that the connection 614 remains alive. This approach is followed only when connection is 615 idle (i.e. server has no binding data to send). During normal 616 binding data exchange, receiving of LEASEQUERY-DATA message by 617 requestor itself signifies that connection is active. Note that the 618 default for ACTIVE_LQ_RCV_TIMEOUT is 120 seconds, twice the value of 619 the ACTIVE_LQ_IDLE_TIMEOUT's default of 60 seconds which drives the 620 DHCPv6 server to send messages. Thus ACTIVE_LQ_RCV_TIMEOUT controls 621 how sensitive the requestor is to be to delays by the DHCPv6 server 622 in sending updates or LEASEQUERY-DATA messages. 624 A single Active Leasequery can and usually will result in a large 625 number of replies. The Requestor MUST be prepared to receive more 626 than one reply with transaction-ids matching a single 627 ACTIVELEASEQUERY message from a single DHCPv6 server. 629 An Active Leasequery has two regimes -- during the catch-up phase, if 630 any, and after any catch-up phase. During the catch-up phase (if one 631 exists), the data returned in the OPTION_LQ_BASE_TIME option in a 632 LEASEQUERY-REPLY or LEASEQUERY-DATA message may appear to be ordered, 633 but the most recent change in the lease state data being returned is 634 not related to the OPTION_LQ_BASE_TIME option value in the messages. 635 Another way to say this is that the ordering of the updates sent by 636 the DHCPv6 server during the catch-up phase is independent of the 637 ordering in the changes in the lease state data. The 638 OPTION_LQ_BASE_TIME option from messages during this phase MUST NOT 639 be saved and used in a subsequent ACTIVELEASEQUERY message's 640 OPTION_LQ_START_TIME option as it does not represent the extent of 641 progress of the catch-up activity. 643 After the catch-up phase, or during the entire series of messages 644 received as the response to a Active Leasequery request with no 645 OPTION_LQ_START_TIME (and therefore no catch-up phase), the 646 OPTION_LQ_BASE_TIME option of the most recent message SHOULD be saved 647 as a record of the most recent time that data was received. This 648 base-time (in the context of the DHCPv6 server) can be used in a 649 subsequent Active Leasequery message's OPTION_LQ_START_TIME after a 650 loss of the Active Leasequery connection. 652 The LEASEQUERY-DONE message MAY unilaterally terminate a successful 653 Active Leasequery request which is currently in progress in the event 654 that the DHCPv6 server determines that it cannot continue processing 655 a ACTIVELEASEQUERY request. For example, when a server is requested 656 to shut down it SHOULD send a LEASEQUERY-DONE message with a DHCPv6 657 status code of QueryTerminated and include OPTION_LQ_BASE_TIME option 658 in the message. This SHOULD be the last message on that connection, 659 and once the message has been transmitted, the server should close 660 the connection. 662 After receiving LEASEQUERY-DONE with a QueryTerminated status from a 663 server, the Requestor MAY close the TCP connection to that server. 665 8.3.1. Processing Replies from a Request Containing a 666 OPTION_LQ_START_TIME 668 If the Active Leasequery was requested with a OPTION_LQ_START_TIME, 669 the DHCPv6 server will attempt to send information about all bindings 670 that changed since the time specified in the OPTION_LQ_START_TIME. 671 This is the catch-up phase of the Active Leasequery processing. The 672 DHCPv6 server MAY also begin immediate updates over the same 673 connection of real-time binding information changes. Thus, the 674 catch-up phase may run in parallel with the normal updates generated 675 by the Active Leasequery request. 677 A DHCPv6 server MAY keep only a limited amount of time ordered 678 information available to respond to an Active Leasequery request 679 containing a OPTION_LQ_START_TIME. Thus, it is possible that the 680 time specified in the OPTION_LQ_START_TIME represents a time not 681 covered by the time ordered information kept by the DHCPv6 server. 682 If this should occur, and there is not enough data saved in the 683 DHCPv6 server to satisfy the request specified by the 684 OPTION_LQ_START_TIME option, the DHCPv6 server will reply immediately 685 with a LEASEQUERY-REPLY message with a DHCPv6 status code of 686 DataMissing with a base-time option equal to the server's current 687 time. This will signal the end of the catch-up phase, and the only 688 updates that will subsequently be received on this connection are the 689 real-time updates from the Active Leasequery request. 691 If there is enough data saved to satisfy the request, then 692 LEASEQUERY-REPLY (with OPTION_STATUS_CODE of Success or reply without 693 OPTION_STATUS_CODE option) and LEASEQUERY-DATA messages will begin 694 arrive from the DHCPv6 server. Some of these messages will be 695 related to the OPTION_LQ_START_TIME request and be part of the catch- 696 up phase. Some of these messages will be real-time updates of 697 binding changes taking place in the DHCPv6 server. In general, there 698 is no way to determine the source of each message. 700 Until the catch-up phase is complete, the latest base-time value 701 received from a DHCPv6 server processing an Active Leasequery request 702 cannot be reset from the incoming messages because to do so would 703 compromise the ability to recover lost information if the Active 704 Leasequery were to terminate prior to the completion of the catch-up 705 phase. 707 The requestor will know that the catch-up phase is complete when the 708 DHCPv6 server will transmit a LEASEQUERY-DATA message with the DHCPv6 709 status code of CatchUpComplete. Once this message is transmitted, 710 all additional LEASEQUERY-DATA messages will relate to real-time 711 ("new") binding changes in the DHCPv6 server. 713 As discussed in Section 8.3, the requestor SHOULD keep track of the 714 latest base-time option value received over a particular connection, 715 to be used in a subsequent Active Leasequery request -- but only if 716 the catch-up phase is complete. Prior to the completion of the 717 catch-up phase, if the connection should go away or if the requestor 718 receives a LEASEQUERY-DONE message, then when it reconnects it MUST 719 use the base-time value from the previous connection and not any 720 base-time value received from the recently closed connection. 722 In the event that there was enough data available to the DHCPv6 723 server to begin to satisfy the request implied by the 724 OPTION_LQ_START_TIME option, but during the processing of that data 725 the server found that it was unable to continue (perhaps there was 726 barely enough, the connection is very slow, and the aging algorithm 727 causes the saved data to become unavailable) the DHCPv6 server will 728 terminate the catch-up phase of processing immediately by sending a 729 LEASEQUERY-DATA message with a DHCPv6 status code of DataMissing and 730 with a base-time option of the current time. 732 The requestor MUST NOT assume that every individual state change of 733 every binding during the period from the time specified in the 734 OPTION_LQ_START_TIME and the present is replicated in an Active 735 Leasequery reply message. The requestor MAY assume that at least one 736 Active Leasequery reply message will exist for every binding which 737 had one or more changes of state during the period specified by the 738 OPTION_LQ_START_TIME and the current time. The last message for each 739 binding will contain the state at the current time, and there may be 740 one or more messages concerning a single binding during the catch-up 741 phase of processing. 743 If a binding changed state multiple times during the time that the 744 requestor was not connected (that is, during the time from the 745 OPTION_LQ_START_TIME and the present), then only the current binding 746 information will be sent during the catch-up phase. However, the 747 requestor MUST NOT assume that every intermediate state change that 748 occurred during the period from the OPTION_LQ_START_TIME to the 749 present will be represented by an individual Leasequery message. 751 If the LEASEQUERY-REPLY or LEASEQUERY-DATA message containing a 752 DHCPv6 status code of DataMissing is received and the requestor is 753 interested in keeping its database up to date with respect to the 754 current state of bindings in the DHCPv6 server, then the requestor 755 SHOULD issue a Bulk Leasequery request to recover the information 756 missing from its database. This Bulk Leasequery request should 757 include a OPTION_LQ_START_TIME, set to be the same as its 758 OPTION_LQ_START_TIME previously included in the ACTIVELEASEQUERY 759 responses from the DHCPv6 server, and a OPTION_LQ_END_TIME equal to 760 the OPTION_LQ_BASE_TIME returned by the DHCPv6 server in the 761 LEASEQUERY-REPLY or LEASEQUERY-DATA message with the DHCPv6 status 762 code of DataMissing. 764 In the event that the requestor receives a LEASEQUERY-REPLY or 765 LEASEQUERY-DATA message with a DHCPv6 status code of DataMissing, it 766 is a reasonable assumption that it is interested in keeping its 767 database up to date with respect to the DHCPv6 server's internal 768 binding database or it would not have included the 769 OPTION_LQ_START_TIME in the ACTIVELEASEQUERY message. 771 Typically, the requestor would have one connection open to a DHCPv6 772 server for a Active Leasequery request and possibly one additional 773 connection open for a Bulk Leasequery request to the same DHCPv6 774 server to fill in the data that might have been missed prior to the 775 initiation of the Active Leasequery. The Bulk Leasequery connection 776 would typically run to completion and be closed, leaving one Active 777 Leasequery connection open to a single DHCPv6 server. Alternatively, 778 both requests could be issued over a single connection. 780 8.4. Processing Time Values in Leasequery messages 782 Active or Bulk Leasequery requests may be made to a DHCPv6 server 783 whose absolute time may not be synchronized with the local time of 784 the requestor. Thus, there are at least two time contexts in even 785 the simplest Active or Bulk Leasequery response. 787 If the requestor of a Active or Bulk Leasequery is saving the data 788 returned in some form, it has a requirement to store a variety of 789 time values, and some of these will be time in the context of the 790 requestor and some will be time in the context of the DHCPv6 server. 792 When receiving a Active or Bulk Leasequery reply message from the 793 DHCPv6 server, the message will contain a OPTION_LQ_BASE_TIME option. 794 The time contained in this OPTION_LQ_BASE_TIME option is in the 795 context of the DHCPv6 server. As such, it is an ideal time to save 796 and use as input to an Active or Bulk Leasequery message in the 797 OPTION_LQ_START_TIME or OPTION_LQ_END_TIME option, should the 798 requestor need to ever issue an Active or Bulk Leasequery message 799 using these option as part of a later query, since these option 800 requires a time in the context of the DHCPv6 server. 802 In addition to saving the OPTION_LQ_BASE_TIME for possible future use 803 in OPTION_LQ_START_TIME or OPTION_LQ_END_TIME option, the 804 OPTION_LQ_BASE_TIME is used as part of the conversion of the other 805 times in the Leasequery message to values which are meaningful in the 806 context of the requestor. 808 In systems whose clocks are synchronized, perhaps using NTP, the 809 clock skew will usually be zero, which is not only acceptable, but 810 desired. 812 8.5. Examples 814 These examples illustrate what a series of queries and responses 815 might look like. These are only examples -- there are no requirement 816 that these sequence must be followed. 818 8.5.1. Query Failure 820 This example illustrates the message flows in case DHCPv6 server 821 identifies that it can not accept and/or process Active Leasequery 822 request from the requestor. This could be because of various reasons 823 (i.e. UnknownQueryType, MalformedQuery, NotConfigured, NotAllowed). 825 Client Server 826 ------ ------ 827 ACTIVELEASEQUERY xid 1 -----> 828 <----- LEASEQUERY-REPLY xid 1 (w/error) 830 8.5.2. Data Missing on Server 832 This example illustrates the message flows in case DHCPv6 server 833 identifies that it does not have enough data saved to satisfy the 834 request specified by the OPTION_LQ_START_TIME option. 836 In this case the DHCPv6 server will reply immediately with a 837 LEASEQUERY-REPLY message with a DHCPv6 status code of DataMissing 838 with a base-time option equal to the server's current time. This 839 will signal the end of the catch-up phase, and the only updates that 840 will subsequently be received on this connection are the real-time 841 updates from the Active Leasequery request. 843 Client Server 844 ------ ------ 845 ACTIVELEASEQUERY xid 2 -----> 846 <----- LEASEQUERY-REPLY xid 2 (w/error) 847 <----- LEASEQUERY-DATA xid 2 848 <----- LEASEQUERY-DATA xid 2 849 <----- LEASEQUERY-DATA xid 2 851 8.5.3. Successful Query 853 This example illustrates the message flows in case of successful 854 query processing by DHCPv6 server. 856 In this case the DHCPv6 server will reply immediately with a 857 LEASEQUERY-REPLY message (with OPTION_STATUS_CODE of Success or reply 858 without OPTION_STATUS_CODE option), followed by binding data in 859 LEASEQUERY-DATA messages. In case, DHCPv6 server wants to abort in- 860 process request and terminate the connection due to some reason, it 861 sends LEASEQUERY-DONE with error code present in OPTION_STATUS_CODE 862 option. 864 Client Server 865 ------ ------ 866 ACTIVELEASEQUERY xid 3 -----> 867 <----- LEASEQUERY-REPLY xid 3 868 <----- LEASEQUERY-DATA xid 3 869 <----- LEASEQUERY-DATA xid 3 870 <----- LEASEQUERY-DATA xid 3 871 <----- LEASEQUERY-DATA xid 3 872 <----- LEASEQUERY-DONE xid 3 (w/error) 874 8.6. Closing Connections 876 The Requestor or DHCPv6 Leasequery server MAY close its end of the 877 TCP connection at any time. The Requestor MAY choose to retain the 878 connection if it intends to issue additional queries. Note that this 879 requestor behavior does not guarantee that the connection will be 880 available for additional queries: the server might decide to close 881 the connection based on its own configuration. 883 9. Server Behavior 885 A DHCPv6 server which supports Active Leasequery MUST support DHCPv6 886 Bulk Leasequery [RFC5460] as well. 888 9.1. Accepting Connections 890 Servers that implement DHCPv6 Active Leasequery listen for incoming 891 TCP connections. Approach used in accepting (or rejecting) the 892 requestor connection is same as specified in DHCPv6 Bulk Leasequery 893 [RFC5460]. 895 9.2. Replying to an Active Leasequery 897 The DHCPv6 Leasequery [RFC5007] specification describes the initial 898 construction of LEASEQUERY-REPLY messages. Use of the LEASEQUERY- 899 REPLY and LEASEQUERY-DATA messages to carry multiple bindings is 900 described in DHCPv6 Bulk Leasequery [RFC5460]. Message transmission 901 and framing for TCP is described in Section 6.1. 903 If the connection becomes blocked while the server is attempting to 904 send reply messages, the server SHOULD be prepared to terminate the 905 TCP connection after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs 906 how much congestion the DHCPv6 server is prepared to tolerate over 907 any Active Leasequery connection. The default is two minutes, which 908 means that if more than two minutes goes by without the requestor 909 reading enough information to unblock the TCP connection, the DHCPv6 910 server will drop the TCP connection. 912 If the DHCPv6 server encounters an error during initial processing of 913 the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-REPLY 914 message containing an error code of some kind in a DHCPv6 status code 915 option. It SHOULD close the connection after this error is 916 signalled. 918 If the DHCPv6 server encounters an error during later processing of 919 the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-DONE 920 containing an error code of some kind in a DHCPv6 status code option. 921 It SHOULD close the connection after this error is signalled. 923 If the server finds any bindings satisfying a query, it sends each 924 binding's data in a reply message. The first reply message is a 925 LEASEQUERY-REPLY. The binding data is carried in an 926 OPTION_CLIENT_DATA option, as specified in [RFC5007]. The server 927 returns subsequent bindings in LEASEQUERY-DATA messages, which can 928 avoid redundant data (such as the requestor's Client-ID). 930 Every reply to a Active Leasequery request MUST contain the 931 information specified in replies to a DHCPv6 Bulk Leasequery request 932 [RFC5460]. 934 If an Active Leasequery or Bulk Leasequery request contains 935 OPTION_LQ_BASE_TIME option code present in OPTION_ORO, the DHCPv6 936 server MUST include OPTION_LQ_BASE_TIME option in every reply for 937 this request. The value for base-time option is current absolute 938 time in the DHCPv6 server's context. 940 If an Active Leasequery request contains a OPTION_LQ_START_TIME 941 option, it indicates that the requestor would like the DHCPv6 server 942 to send it not only messages that correspond to DHCPv6 binding 943 activity that occurs subsequent to the receipt of the Active 944 Leasequery request, but also messages that correspond to DHCPv6 945 binding activity that occurred prior to the Active Leasequery 946 request. 948 If OPTION_LQ_END_TIME option appears in a Active Leasequery request, 949 the DHCPv6 server should send a LEASEQUERY-REPLY message with a 950 DHCPv6 status code of MalformedQuery and terminate the connection. 952 In order to implement a meaningful response to this query, the DHCPv6 953 server MAY keep track of the binding activity and associate changes 954 with particular base-time values from the messages. Then, when 955 requested to do so by a Active Leasequery request containing a 956 OPTION_LQ_START_TIME option, the DHCPv6 server can respond with 957 replies for all binding activity occurring on that 958 OPTION_LQ_START_TIME or later times. 960 These replies based on the OPTION_LQ_START_TIME MAY be interleaved 961 with the messages generated due to current binding activity. 963 Once the transmission of the DHCPv6 Leasequery messages associated 964 with the OPTION_LQ_START_TIME option are complete, a LEASEQUERY-DATA 965 message MUST be sent with a DHCPv6 status code value of 966 CatchUpComplete. 968 The DHCPv6 server SHOULD, but is not required to, keep track of a 969 limited amount of previous binding activity. The DHCPv6 server MAY 970 choose to only do this in the event that it has received at least one 971 Active Leasequery request in the past, as to do so will almost 972 certainly entail some utilization of resources which would be wasted 973 if there are no Active Leasequery requestors for this DHCPv6 server. 974 The DHCPv6 server SHOULD make the amount of previous binding activity 975 it retains configurable. There is no requirement on the DHCPv6 976 server to retain this information over a server restart (or even to 977 retain such information at all). 979 Unless there is an error or some requirement to cease processing a 980 Active Leasequery request yielding a LEASEQUERY-DONE message, such as 981 a server shutdown, there will be no LEASEQUERY-DONE message at the 982 conclusion of the Active Leasequery processing because that 983 processing will not conclude but will continue until either the 984 requestor or the server drops the connection. 986 9.3. Multiple or Parallel Queries 988 Requesters may want to use an existing connection if they need to 989 make multiple queries. Servers MAY support reading and processing 990 multiple queries from a single connection. A server MUST NOT read 991 more query messages from a connection than it is prepared to process 992 simultaneously. 994 Typically, a requestor of a Active Leasequery would not need to send 995 a second Active Leasequery while the first is still active. However, 996 sending an Active Leasequery and a Bulk Leasequery over the same 997 connection would be possible and reasonable. But it is RECOMMENDED 998 to use different connection in case of parallel Active and Bulk 999 Leasequeries. 1001 This MAY be a feature that is administratively controlled. Servers 1002 that are able to process queries in parallel SHOULD offer 1003 configuration that limits the number of simultaneous queries 1004 permitted from any one requestor, in order to control resource use if 1005 there are multiple requesters seeking service. 1007 9.4. Closing Connections 1009 The server MUST close its end of the TCP connection if it encounters 1010 an error sending data on the connection. The server MUST close its 1011 end of the TCP connection if it finds that it has to abort an in- 1012 process request. A server aborting an in-process request SHOULD 1013 attempt to signal that to its requestors by using the QueryTerminated 1014 status code in the DHCPv6 status code option in a LEASEQUERY-DONE 1015 message. If the server detects that the requestor end has been 1016 closed, the server MUST close its end of the connection after it has 1017 finished processing any outstanding requests from the requestor. 1019 The server SHOULD be prepared to limit the number of connections it 1020 maintains, and SHOULD be prepared to close idle connections to 1021 enforce the limit. 1023 10. Security Considerations 1025 The "Security Considerations" section of [RFC3315] details the 1026 general threats to DHCPv6. The DHCPv6 Leasequery specification 1027 [RFC5007] describes recommendations for the Leasequery protocol, 1028 especially with regard to relayed Leasequery messages, mitigation of 1029 packet-flooding denial-of-service (DoS) attacks, restriction to 1030 trusted requestors, and use of IPsec [RFC4301]. 1032 The use of TCP introduces some additional concerns. Attacks that 1033 attempt to exhaust the DHCPv6 server's available TCP connection 1034 resources, such as SYN flooding attacks, can compromise the ability 1035 of legitimate requestors to receive service. Malicious requestors 1036 who succeed in establishing connections, but who then send invalid 1037 queries, partial queries, or no queries at all also can exhaust a 1038 server's pool of available connections. We recommend that servers 1039 offer configuration to limit the sources of incoming connections, 1040 that they limit the number of accepted connections and the number of 1041 in-process queries from any one connection, and that they limit the 1042 period of time during which an idle connection will be left open. 1044 There are two specific issues regarding Active Leasequery security 1045 that deserve explicit mention. The first is preventing information 1046 that Active Leasequery can provide from reaching requestors who are 1047 not authorized to receive such information. The second is ensuring 1048 that authorized requestors of the Active Leasequery capability 1049 receive accurate information from the Server (and that this 1050 information is not disrupted in transit). 1052 To prevent information leakage to unauthorized requestors, Servers 1053 SHOULD restrict Active Leasequery connections and ACTIVELEASEQUERY 1054 messages to certain requestors, either through explicit configuration 1055 of the Server itself or by employing external network elements to 1056 provide such restrictions. In particular, the typical DHCPv6 client 1057 SHOULD NOT be allowed to receive a response to an Active Leasequery 1058 request, and some technique MUST exist to allow prevention of such 1059 access in any environment where Active Leasequery is deployed. 1061 Connections not from permitted requestors SHOULD be closed 1062 immediately, to avoid server connection resource exhaustion or 1063 alternatively, simply not be allowed to reach the server at all. 1064 Servers SHOULD have the capability to restrict certain requestors to 1065 certain query types. Servers MAY reply to queries that are not 1066 permitted with the LEASEQUERY-DONE message with a status-code option 1067 status of NotAllowed, or MAY simply close the connection. 1069 To prevent disruption and malicious corruption of Active Leasequery 1070 data flows between the server and authorized requestors these data 1071 flows SHOULD transit only secured networks. These data flows are 1072 typically infrastructure oriented, and there is usually no reason to 1073 have them flowing over networks where such attacks are likely. In 1074 the rare cases where these data flows might need to be sent through 1075 unsecured networks, they MUST sent over connections secured through 1076 means external to the DHCPv4/DHCPv6 server and its requestor(s) 1077 (e.g., through VPN's). 1079 Authentication for DHCP Messages [RFC3315] MUST NOT be used to 1080 attempt to secure transmission of the messages described in this 1081 document. 1083 11. IANA Considerations 1085 IANA is requested to assign new DHCPv6 Option Codes in the registry 1086 maintained in http://www.iana.org/assignments/dhcpv6-parameters: 1088 OPTION_LQ_BASE_TIME 1090 OPTION_LQ_START_TIME 1092 OPTION_LQ_END_TIME 1094 IANA is requested to assign new values in the registry of DHCPv6 1095 Status Codes maintained in http://www.iana.org/assignments/ 1096 dhcpv6-parameters: 1098 DataMissing 1100 CatchUpComplete 1102 IANA is requested to assign value for the following new DHCPv6 1103 Message type in the registry maintained in http://www.iana.org/ 1104 assignments/dhcpv6-parameters: 1106 ACTIVELEASEQUERY 1108 12. Acknowledgements 1110 Some of the concept and content, present in this document, are based 1111 on DHCPv4 Active Leasequery which was originally proposed by Kim 1112 Kinnear, Bernie Volz, Mark Stapp and Neil Russell. 1114 13. Modification History 1116 14. References 1118 14.1. Normative References 1120 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1121 Requirement Levels", BCP 14, RFC 2119, March 1997. 1123 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1124 and M. Carney, "Dynamic Host Configuration Protocol for 1125 IPv6 (DHCPv6)", RFC 3315, July 2003. 1127 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1128 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1129 December 2003. 1131 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 1132 "DHCPv6 Leasequery", RFC 5007, September 2007. 1134 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 1135 2009. 1137 14.2. Informative References 1139 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1140 Internet Protocol", RFC 4301, December 2005. 1142 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 1143 for Transmission Control Protocol (TCP) Specification 1144 Documents", RFC 4614, September 2006. 1146 Authors' Addresses 1148 Dushyant Raghuvanshi 1149 Cisco Systems, Inc. 1150 Cessna Business Park, 1151 Varthur Hobli, Outer Ring Road, 1152 Bangalore, Karnataka 560037 1153 India 1155 Phone: +91 (080) 4365-7476 1156 Email: draghuva@cisco.com 1158 Kim Kinnear 1159 Cisco Systems, Inc. 1160 1414 Massachusetts Ave. 1161 Boxborough, Massachusetts 01719 1162 USA 1164 Phone: +1 (978) 936-0000 1165 Email: kkinnear@cisco.com 1167 Deepak Kukrety 1168 Cisco Systems, Inc. 1169 Cessna Business Park, 1170 Varthur Hobli, Outer Ring Road, 1171 Bangalore, Karnataka 560037 1172 India 1174 Phone: +91 (080) 4365-7474 1175 Email: dkukrety@cisco.com