idnits 2.17.1 draft-ietf-dhc-dhcpv4-active-leasequery-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4388]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 6, 2015) is 3124 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 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kinnear 3 Internet-Draft M. Stapp 4 Updates: 6926 (if approved) B. Volz 5 Intended status: Standards Track Cisco Systems 6 Expires: April 8, 2016 N. Russell 7 Staples 8 October 6, 2015 10 Active DHCPv4 Lease Query 11 draft-ietf-dhc-dhcpv4-active-leasequery-07.txt 13 Abstract 15 The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been 16 extended with a Leasequery capability that allows a requestor to 17 request information about DHCPv4 bindings [RFC4388]. That mechanism 18 is limited to queries for individual bindings. In some situations 19 individual binding queries may not be efficient, or even possible. 20 In addition, continuous update of an external requestor with 21 Leasequery data is sometimes desired. This document expands on the 22 DHCPv4 Leasequery protocol, and allows for active transfer of near 23 real-time DHCPv4 binding information data via TCP. This document 24 updates RFC6926, DHCPv4 Bulk Leasequery. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 8, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Interaction Between Active Leasequery and Bulk Leasequery . . 7 64 5. Message and Option Definitions . . . . . . . . . . . . . . . 8 65 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 8 66 5.2. New or Changed Options . . . . . . . . . . . . . . . . . 8 67 5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 8 68 5.2.2. dhcp-status-code . . . . . . . . . . . . . . . . . . 9 69 5.3. Connection and Transmission Parameters . . . . . . . . . 10 70 6. Information Communicated by Active Leasequery . . . . . . . . 10 71 7. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 11 72 7.1. General Processing . . . . . . . . . . . . . . . . . . . 11 73 7.2. Initiating a Connection . . . . . . . . . . . . . . . . . 12 74 7.3. Forming an Active Leasequery . . . . . . . . . . . . . . 13 75 7.4. Processing Active Replies . . . . . . . . . . . . . . . . 14 76 7.4.1. Processing Replies from a Request Containing a query- 77 start-time . . . . . . . . . . . . . . . . . . . . . 16 78 7.5. Closing Connections . . . . . . . . . . . . . . . . . . . 18 79 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 18 80 8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 18 81 8.1.1. Update to RFC 6926 . . . . . . . . . . . . . . . . . 20 82 8.2. Replying to an Active Leasequery . . . . . . . . . . . . 20 83 8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 22 84 8.4. Closing Connections . . . . . . . . . . . . . . . . . . . 23 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 87 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 90 12.2. Informative References . . . . . . . . . . . . . . . . . 26 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 93 1. Introduction 95 The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4 96 capability [RFC2131] [RFC2132] to allow an external entity to query a 97 DHCPv4 server to recover lease state information about a particular 98 IPv4 address or client in near real-time. 100 Continuous update of an external requestor with Leasequery data is 101 sometimes desired. These requestors need to keep up with the current 102 binding activity of the DHCPv4 server. Keeping up with these binding 103 activities is termed "active" leasequery. 105 The DHCPv4 Bulk Leasequery [RFC6926] capability can be used to 106 recover useful information from a DHCPv4 server when some external 107 entity starts up. This entity could be one which is directly 108 involved in the DHCPv4 client - server transactions (e.g., a relay 109 agent), or it could be an external process which needs information 110 present in the DHCPv4 server's lease state database. 112 The Active Leasequery capability documented here is designed to allow 113 an entity not directly involved in DHCPv4 client - server 114 transactions to nevertheless keep current with the state of the 115 DHCPv4 lease state information in real-time. 117 This document updates DHCPv4 Bulk Leasequery [RFC6926] in that it 118 specifies the DHCPv4 server must close the TCP connection if it 119 receives a DHCPv4 message that is not allowed over the TCP connection 120 (for example, DHCPDISCOVER, DHCPLEASEQUERY). See Section 8.1.1. 122 2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 This document uses the following terms: 130 o "Active Leasequery" 132 Keeping up to date in real-time (or near real-time) with DHCPv4 133 binding activity. 135 o "binding" 137 The information that a DHCPv4 server keeps regarding the 138 relationship between a DHCPv4 client and an IPv4 address. This 139 includes the identity of the DHCPv4 client and the expiration 140 time, if any, of any lease that client has on a particular IPv4 141 address. 143 o "Bulk Leasequery" 145 Requesting and receiving the information about all or some of the 146 existing DHCPv4 binding information in an efficient manner, as 147 defined by [RFC6926]. 149 o "blocked TCP connection" 151 A TCP connection is considered blocked if the underlying TCP 152 transport will not accept new messages to be sent without blocking 153 the thread that is attempting to send the message. 155 o "catch-up information" 157 If a DHCPv4 Active Leasequery requestor sends in a query-start- 158 time option in a DHCPACTIVELEASEQUERY message, the DHCPv4 server 159 will attempt to send the requestor the information that changed 160 since the time specified in the query-start-time option. The 161 binding information sent to satisfy this request is the catch-up 162 information. 164 o "catch-up phase" 166 The period while the catch-up information is being sent is the 167 catch-up phase. 169 o "clock skew" 171 The difference between the absolute time on a DHCPv4 server and 172 the absolute time on the system where a requestor of an Active or 173 Bulk Leasequery is executing is termed the "clock skew" for that 174 Active or Bulk Leasequery connection. It is not absolutely 175 constant but is likely to vary only slowly. While it is easy to 176 think that this can be calculated precisely after one packet is 177 received by a requestor from a DHCPv4 server, a more accurate 178 value is derived from continuously examining the instantaneous 179 value developed from each packet received from a DHCPv4 server and 180 using it to make small adjustments to the existing value held in 181 the requestor. 183 o "DHCPv4 client" 185 A DHCPv4 client is an IPv4 node using DHCP to obtain configuration 186 parameters such as a network address. 188 o "DHCPv4 relay agent" 190 A DHCPv4 relay agent is a third-party agent that transfers BOOTP 191 and DHCPv4 messages between clients and servers residing on 192 different subnets, per [RFC0951] and [RFC1542]. 194 o "DHCPv4 server" 196 A DHCPv4 server is an IPv4 node that returns configuration 197 parameters to DHCPv4 clients. 199 o "insecure mode" 201 When operating in insecure mode, the TCP connection between the 202 requestor and DHCPv4 server is not protected in any way. In 203 addition, the identity of the requestor is not validated by the 204 server nor is the identity of the server validated by the 205 requestor. 207 o "MAC address" 209 In the context of a DHCP message, a MAC address consists of the 210 fields: hardware type "htype", hardware length "hlen", and client 211 hardware address "chaddr". 213 o "requestor" 215 The node that sends LEASEQUERY messages to one or more servers to 216 retrieve information on the bindings for a client. 218 o "secure mode" 220 When operating in secure mode, the TCP connection between the 221 requestor and the DHCPv4 server is protected by TLS [RFC5246]. In 222 addition, the requestor uses the certificates exchanged between it 223 and the DHCPv4 server while setting up the TLS connection to 224 validate the identity of the server. The DHCPv4 server also uses 225 these certificates to validate the identity of the requestor. 227 3. Protocol Overview 229 The Active Leasequery mechanism is modeled on the existing individual 230 Leasequery protocol in [RFC4388] as well as related work on DHCPv4 231 Bulk Leasequery [RFC6926]; most differences arise from the long term 232 nature of the TCP [RFC7414] connection required for Active 233 Leasequery. In addition, a DHCPv4 server which supports Active 234 Leasequery must support Bulk Leasequery [RFC6926] as well. See 235 Section 8. 237 An Active Leasequery requestor opens a TCP connection to a DHCPv4 238 Server, using the DHCPv4 port 67. Note that this implies that the 239 Leasequery requestor has the server IPv4 address(es) available via 240 configuration or some other means, and that it has unicast IP 241 reachability to the DHCPv4 server. The message framing for TCP is 242 discussed in Section 5.1. No relaying for Active Leasequery is 243 specified. 245 After establishing a connection, the requestor sends an 246 DHCPACTIVELEASEQUERY message over the connection. In response, the 247 server sends updates to the requestor using DHCPLEASEACTIVE and 248 DHCPLEASEUNASSIGNED messages which are extensions of these messages 249 as defined in [RFC4388] and [RFC6926]. This response procedure is 250 similar to the procedure specified in [RFC6926], except that in the 251 case of Active Leasequery the server sends updates whenever some 252 activity occurs to change the binding state -- thus the need for the 253 long lived connection. Additionally, the Active Leasequery server 254 should provide a mechanism to control which data is allowed to be 255 included in the messages sent to the requestor. See Section 8.2. 257 Since [RFC6926] did not specify what to do with an unknown message 258 type received over the DHCP TCP connection, system administrators 259 SHOULD NOT allow an DHCPACTIVELEASEQUERY message to be sent over a 260 DHCP TCP connection to a DHCPv4 server which does not support Active 261 Leasequery. 263 Active Leasequery is designed to provide continuous updates of DHCPv4 264 binding activity to an external entity. 266 Active Leasequery has features which allow this external entity to 267 lose its connection and then reconnect and receive the latest 268 information concerning any IPv4 bindings changed while it was not 269 connected. 271 These capabilities are designed to allow the Active Leasequery 272 requestor to efficiently become current with respect to the lease 273 state database after it has been restarted or the machine on which it 274 is running has been reinitialized. It is easy to define a protocol 275 which works when the requestor is always connected to the DHCPv4 276 server. Since that isn't sufficiently robust, much of the mechanism 277 in this document is designed to deal efficiently with situations that 278 occur when the Active Leasequery requestor becomes disconnected from 279 the DHCPv4 server from which it is receiving updates and then becomes 280 reconnected to that server. 282 Central to this approach, if the Active Leasequery requestor loses 283 service, it is allowed to specify the time of its most recent update 284 in a subsequent Active Leasequery request and the DHCPv4 server will 285 determine whether or not data was missed while the Active Leasequery 286 requestor was not connected. 288 The DHCP server processing the Active Leasequery request MAY limit 289 the amount of data saved, and methods exist for the DHCPv4 server to 290 inform the Active Leasequery requestor that more data was missed than 291 could be saved. In this situation, the Active Leasequery requestor 292 would issue a Bulk Leasequery [RFC6926] to recover information not 293 available through an Active Leasequery. 295 DHCPv4 servers are not required to keep any data corresponding to 296 data missed on a Active Leasequery connection, but will typically 297 choose to keep data corresponding to some recent activity available 298 for subsequent queries by a DHCPv4 Active Leasequery requestor whose 299 connection was temporarily interrupted. 301 An Active Leasequery requestor would typically use Bulk Leasequery to 302 initialize its database with all current data when that database 303 contains no binding information. In addition, it would use Bulk 304 Leasequery to recover missed information in the event that its 305 connection with the DHCPv4 server was lost for a longer time than the 306 DHCPv4 server would keep track of the specific changes to the IPv4 307 binding information. 309 The messages sent by the server in response to an Active Leasequery 310 request should be identical to the messages sent by the server to a 311 Bulk Leasequery request regarding the way the data is encoded into 312 the Active Leasequery responses. In addition, the actions taken by 313 the Active Leasequery requestor to interpret the responses to an 314 Active Leasequery request should be identical to the way that the 315 requestor interprets the responses to a Bulk Leasequery request. 316 Thus, the handling of time, clock skew, data source, and other items 317 discussed in the Bulk Leasequery specification [RFC6926] are to be 318 followed when implementing Active Leasequery, with the exception that 319 a server responding to an Active Leasequery request SHOULD be able to 320 be configured to prevent specific data items from being included in 321 the response to the requestor even if they were requested by 322 inclusion in the dhcp-parameter-request-list option. 324 4. Interaction Between Active Leasequery and Bulk Leasequery 326 Active Leasequery is an extension of the Bulk Leasequery protocol 327 [RFC6926]. The contents of messages returned to an Active Leasequery 328 requestor are identical to that defined for the Bulk Leasequery 329 protocol. 331 Applications which employ Active Leasequery to keep a database up to 332 date with respect to the DHCPv4 server's lease state database should 333 use an initial Bulk Leasequery to bring their database into 334 equivalence with that of the DHCPv4 server, and then use Active 335 Leasequery to keep that database current with respect to the DHCPv4 336 server's lease state database. 338 There are several differences between the Active and Bulk Leasequery 339 protocols. Active Leasequery defines only one qualifier (the query- 340 start-time) and no query types, while Bulk Leasequery defines several 341 query types and qualifiers. An Active Leasequery connection sends 342 all available updates to the requestor. 344 An Active Leasequery connection does not ever "complete", though the 345 DHCPv4 server can close the connection for a variety of reasons 346 associated with some sort of exception condition. 348 5. Message and Option Definitions 350 5.1. Message Framing for TCP 352 The use of TCP for the Active Leasequery protocol permits one or more 353 DHCPv4 messages to be sent in response to a single Active Leasequery 354 request. The receiver needs to be able to determine how large each 355 message is. The same framing technique used for Bulk Leasequery 356 [RFC6926] is used for Active Leasequery. 358 When using TLS to secure a connection [RFC5246], the message framing 359 for TLS uses the same format as that used for TCP. One DHCP message 360 is carried in one TLS record. 362 5.2. New or Changed Options 364 The existing messages DHCPLEASEUNASSIGNED and DHCPLEASEACTIVE are 365 used as the value of the dhcp-message-type option to indicate an IPv4 366 address which is currently not leased or currently leased to a DHCPv4 367 client, respectively. 369 All of the message types and options defined for Bulk Leasequery 370 [RFC6926] are also used by Active Leasequery. In addition, new 371 message types and option types are defined for Active Leasequery, as 372 described below. 374 5.2.1. dhcp-message-type 376 The message type option (option 53) from [RFC2132] requires 377 additional values. The values of these message types are shown below 378 in an extension of the table from Section 9.6 of [RFC2132]: 380 +-------+----------------------+ 381 | Value | Message Type | 382 +-------+----------------------+ 383 | TBD1 | DHCPACTIVELEASEQUERY | 384 | TBD2 | DHCPLEASEQUERYSTATUS | 385 | TBD3 | DHCPTLS | 386 +-------+----------------------+ 388 5.2.2. dhcp-status-code 390 The dhcp-status-code option defined in [RFC6926] allows greater 391 detail to be returned regarding the status of a DHCP request. While 392 specified in the Bulk Leasequery document, this DHCPv4 option is also 393 used in Active Leasequery. 395 This option has two possible scopes when used with Active Leasequery, 396 depending on the context in which it appears. It refers to the 397 information in a single leasequery reply if the value of the dhcp- 398 message-type is DHCPLEASEACTIVE, DHCPLEASEUNASSIGNED or DHCPTLS. It 399 refers to the message stream related to an entire request if the 400 value of the dhcp-message-type is DHCPLEASEQUERYSTATUS. 402 Additional status codes defined for support of Active Leasequery are: 404 +----------------------+-------------+------------------------------+ 405 | Name | status-code | Description | 406 +----------------------+-------------+------------------------------+ 407 | DataMissing | TBD4 | Indicates that IPv4 binding | 408 | | | information requested is not | 409 | | | available. | 410 | ConnectionActive | TBD5 | Indicates that this | 411 | | | connection remains active. | 412 | CatchUpComplete | TBD6 | Indicates that this Active | 413 | | | Leasequery connection has | 414 | | | completed sending all of the | 415 | | | saved data requested. | 416 | TLSConnectionRefused | TBD7 | Indicates that a TLS | 417 | | | connection is not allowed. | 418 +----------------------+-------------+------------------------------+ 420 A dhcp-status-code option MAY appear in the options field of a DHCP 421 message. If the dhcp-status-code option does not appear, it is 422 assumed that the operation was successful. The dhcp-status-code 423 option SHOULD NOT appear in a message which is successful unless it 424 is needed to convey some text message along with the Success status 425 code. 427 5.3. Connection and Transmission Parameters 429 Active Leasequery uses the same port configuration as DHCPv4 Bulk 430 Leasequery [RFC6926]. It also uses other transmission parameters 431 (BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [RFC6926]. 433 This section presents a table of values used to control Active 434 Leasequery behavior, including recommended defaults. Implementations 435 MAY make these values configurable. However, configuring too-small 436 timeout values may lead to harmful behavior both to this application 437 as well as to other traffic in the network. As a result, timeout 438 values smaller than the default values SHOULD NOT be used. 440 +------------------------+----------+-------------------------------+ 441 | Parameter | Default | Description | 442 +------------------------+----------+-------------------------------+ 443 | ACTIVE_LQ_RCV_TIMEOUT | 120 secs | Active Leasequery receive | 444 | | | timeout | 445 | ACTIVE_LQ_SEND_TIMEOUT | 120 secs | Active Leasequery send | 446 | | | timeout | 447 | ACTIVE_LQ_IDLE_TIMEOUT | 60 secs | Active Leasequery idle | 448 | | | timeout | 449 +------------------------+----------+-------------------------------+ 451 6. Information Communicated by Active Leasequery 453 While the information communicated by a Bulk Leasequery [RFC6926] is 454 taken directly from the DHCPv4 server's lease state database, the 455 information communicated by an Active Leasequery is real-time 456 information. As such, it is the information which is currently 457 associated with a particular binding in the DHCPv4 server's lease 458 state database. 460 This is of significance, because if the Active Leasequery requestor 461 runs slowly or the requestor disconnects from the DHCPv4 server and 462 then reconnects with a query-start-time (signaling a catch-up 463 operation), the information communicated to the Active Leasequery 464 requestor is only the most current information from the DHCPv4 465 server's lease state database. 467 The requestor of an Active Leasequery MUST NOT assume that every 468 lease state change is communicated across an Active Leasequery 469 connection. Even if the Active Leasequery requestor remains 470 connected, the DHCPv4 server is only required to transmit information 471 about a binding that is current when the packet is created and handed 472 off to the TCP stack to send to the requestor. 474 If the TCP connection blocks and the DHCPv4 server is waiting to send 475 information down the connection, when the connection becomes 476 available to be written the DHCPv4 server MAY create the packet to 477 send at this time. The current state of the binding will be sent, 478 and any transition in state or other information that occurred while 479 the TCP connection was blocked will be lost. 481 Thus, the Active Leasequery protocol does not allow the requestor to 482 build a complete history of every activity on every lease. An 483 effective history of the important state changes for a lease can be 484 created if the parameters of the DHCPv4 server are tuned to take into 485 account the requirements of an Active Leasequery requestor. For 486 instance, the period after the expiration or release of a binding 487 could be configured long enough (say several minutes, well more than 488 the receive timeout), so that an Active Leasequery requestor would 489 never miss any changes in the binding. 491 7. Requestor Behavior 493 7.1. General Processing 495 A requestor attempts to establish a TCP connection to a DHCPv4 Server 496 in order to initiate a Leasequery exchange. If the attempt fails, 497 the Requestor MAY retry. Retries should not be more frequent than 498 one every ACTIVE_LQ_IDLE_TIMEOUT. See Section 5.3. 500 If an Active Leasequery is terminated prematurely by a 501 DHCPLEASEQUERYDONE with a dhcp-message status-code of QueryTerminated 502 or by the failure of the connection over which it was being 503 submitted, the requestor MAY retry the request after the creation of 504 a new connection. Retries should not be more frequent than one every 505 ACTIVE_LQ_IDLE_TIMEOUT. See Section 5.3. 507 Messages from the DHCPv4 server come as multiple responses to a 508 single DHCPACTIVELEASEQUERY message. Thus, each DHCPACTIVELEASEQUERY 509 or DHCPBULKLEASEQUERY request must have an xid (transaction-id) 510 unique on the connection on which it is sent (see Section 7.3), and 511 all of the messages which come as a response to it all contain the 512 same xid as the request. 514 Only one DHCPACTIVELEASEQUERY is allowed on any one TCP connection at 515 a time. Parallel DHCPACTIVELEASEQUERY requests on the same TCP are 516 not allowed. 518 7.2. Initiating a Connection 520 A requestor SHOULD be able to operate in either insecure or secure 521 mode. See Section 9. This MAY be a feature that is administratively 522 controlled. 524 When operating in insecure mode, the requestor sends a 525 DHCPACTIVELEASEQUERY request after the establishment of a TCP 526 connection. 528 When operating in secure mode, the requestor MUST attempt to 529 negotiate a TLS [RFC5246] connection over the TCP connection. If 530 this negotiation fails, the requestor MUST close the TCP connection. 531 The recommendations in [RFC7525] apply when negotiating this 532 connection. 534 A requestor requests the establishment of a TLS connection by sending 535 the DHCPTLS message to the DHCPv4 server as the first message over 536 the TCP connection. The DHCPTLS message SHOULD be sent without any 537 options. This message indicates to the DHCPv4 server that a TLS 538 connection over this TCP connection is desired. There are four 539 possibilities after the requestor sends the DHCPTLS message to the 540 DHCPV4 server: 542 1. No response from the DHCPv4 server. 544 2. The DHCPv4 server closes the TCP connection after it receives the 545 DHCPTLS message. 547 3. DHCPv4 server responds with a DHCPTLS message with a dhcp-status- 548 code of TLSConnectionRefused. 550 4. DHCPv4 server responds with DHCPTLS message with no dhcp-status- 551 code, indicating success. 553 In any of the first three possibilities, the DHCPv4 server can be 554 assumed to not support TLS. In this case, the requestor MUST close 555 the connection. 557 In the final possibility, where the DHCPv4 server has responded with 558 a DHCPTLS message with no dhcp-status-code in response to the 559 requestor's DHCPTLS message, the requestor SHOULD initiate the 560 exchange of the messages involved in a TLS handshake [RFC5246]. 561 During the TLS handshake, the requestor MUST validate the DHCPv4 562 server's digital certificates. 564 If the handshake exchange yields a functioning TLS connection, then 565 the requestor SHOULD transmit an DHCPACTIVELEASEQUERY message over 566 that TLS connection and use that TLS connection for all further 567 interactions in which it engages with the DHCPv4 server over this TCP 568 connection. 570 If the handshake exchange does not yield a functioning TLS 571 connection, then the requestor MUST close the TCP connection. 573 7.3. Forming an Active Leasequery 575 The Active Leasequery is designed to create a long lived connection 576 between the requestor and the DHCPv4 server processing the active 577 query. The DHCPv4 server SHOULD send binding information back across 578 this connection with minimal delay after it learns of the binding 579 information. It will learn about the bindings either because it 580 makes the bindings itself or because it has received information 581 about a binding from another server. 583 An Active Leasequery is a DHCPv4 request with a dhcp-message-type of 584 DHCPACTIVELEASEQUERY. The DHCPv4 request MUST NOT have a ciaddr, a 585 chaddr, or a dhcp-client-identifier. The DHCPv4 request MUST have an 586 xid (transaction-id) unique on the connection on which it is sent. 587 The DHCPv4 request SHOULD have a dhcp-parameter-request-list to 588 inform the DHCPv4 server which DHCPv4 options are of interest to the 589 requestor sending the DHCPACTIVELEASEQUERY message. 591 An important capability of the Active Leasequery is the ability of 592 the requestor to specify that some recent data be sent immediately to 593 the requestor in parallel with the transmission of the ongoing 594 binding information in more or less real time. This capability is 595 used in order to allow an Active Leasequery requestor to recover 596 missed information in the event that it temporarily loses 597 connectivity with the DHCPv4 server processing a previous Active 598 Leasequery. 600 This capability is enabled by the transmission of a 4 octet base-time 601 option with each Leasequery reply sent as the result of a previous 602 Active Leasequery. The requestor SHOULD keep track of the highest 603 base-time received from a particular DHCPv4 server over an Active 604 Leasequery connection, and in the event that the requestor finds it 605 necessary (for whatever reason) to reestablish an Active Leasequery 606 connection to that DHCPv4 server, the requestor should place this 607 highest base-time value into a query-start-time option in the new 608 DHCPACTIVELEASEQUERY request. (See Sections 6.2.5 and 7.2 of 609 [RFC6926] for information on the query-start-time option.) 611 Note that until all of the recent data (catch-up data) has been 612 received, the requestor MUST NOT keep track of the base time received 613 in Leasequery reply messages to use later in a subsequent Bulk 614 Leasequery or Active Leasequery request. 616 If the requestor doesn't wish to request an update of information 617 missed when it was not connected to the DHCPv4 server, then it does 618 not include the query-start-time option in the DHCPACTIVELEASEQUERY 619 request. 621 If the TCP connection becomes blocked or stops being writable while 622 the requestor is sending its query, the requestor SHOULD terminate 623 the connection after BULK_LQ_DATA_TIMEOUT. We make this 624 recommendation to allow requestors to control the period of time they 625 are willing to wait before abandoning a connection, independent of 626 notifications from the TCP implementations they may be using. 628 7.4. Processing Active Replies 630 The Requestor attempts to read a DHCPv4 leasequery reply message from 631 the TCP connection. 633 Note that the connection resulting from accepting a 634 DHCPACTIVELEASEQUERY request may be long-lived, and may not have data 635 transferring continuously during its lifetime. Therefore the DHCPv4 636 server SHOULD send a DHCPLEASEQUERYSTATUS message with a dhcp-status- 637 code of ConnectionActive every ACTIVE_LQ_IDLE_TIMEOUT seconds 638 (default 60) in order for the requestor to know that the connection 639 remains alive. This approach is followed only when the connection is 640 idle (i.e., the server has no binding data to send). During normal 641 binding data exchange, receiving DHCPLEASEACTIVE or 642 DHCPLEASEUNASSIGNED messages by the requestor itself signifies that 643 the connection is active. Note that the default for 644 ACTIVE_LQ_RCV_TIMEOUT is 120 seconds, twice the value of the 645 ACTIVE_LQ_IDLE_TIMEOUT's default of 60 seconds which drives the 646 DHCPv4 server to send messages. Thus ACTIVE_LQ_RCV_TIMEOUT controls 647 how sensitive the requestor is to be to delays by the DHCPv4 server 648 in sending updates or DHCPLEASEQUERYSTATUS messages. 650 If the stream of replies becomes blocked with no messages being 651 received, the Requestor SHOULD terminate the connection after 652 ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured 653 to do so. 655 A successful query that is returning binding data MUST include a non- 656 zero ciaddr. It may also include a non-zero chaddr, htype, and hlen 657 as well as additional options. If there are additional bindings to 658 be returned, they will be carried in additional Active Leasequery 659 messages. 661 Any requestor of an Active Leasequery operation MUST be prepared to 662 receive multiple copies of the binding information for a particular 663 IPv4 address. See the Bulk Leasequery document [RFC6926] for 664 information on how to deal with this situation. 666 A single Active Leasequery can and usually will result in a large 667 number of replies. The Requestor MUST be prepared to receive more 668 than one reply with transaction-ids matching a single 669 DHCPACTIVELEASEQUERY message from a single DHCPv4 server. 671 A DHCPACTIVELEASEQUERY has two regimes -- during the catch-up phase, 672 if any, and after any catch-up phase. If the DHCPACTIVELASEQUERY 673 request had a query-start-time, then the DHCPACTIVELEASEQUERY starts 674 out in the catch-up phase. See Section 7.4.1 for information on 675 processing during the catch-up phase, as well as how to determine 676 when the catch-up phase is complete. 678 After the catch-up phase, or during the entire series of messages 679 received as the response to a DHCPACTIVELEASEQUERY request with no 680 query-start-time (and therefore no catch-up phase), the base-time 681 option of the most recent message SHOULD be saved as a record of the 682 most recent time that data was received. This base-time (in the 683 context of the DHCPv4 server) can be used in a subsequent 684 DHCPACTIVELEASEQUERY message's query-start-time, or in a 685 DHCPBULKLEASEQUERY message's query-start-time if one is required, 686 after a loss of the Active Leasequery connection. 688 The DHCPLEASEQUERYSTATUS message MAY unilaterally terminate a 689 successful DHCPACTIVELEASEQUERY request which is currently in 690 progress in the event that the DHCPv4 server determines that it 691 cannot continue processing a DHCPACTIVELEASEQUERY request. For 692 example, when a server is requested to shut down it SHOULD send a 693 DHCPLEASEQUERYSTATUS message with a dhcp-status-code of 694 QueryTerminated and include in the message a base time. This MUST be 695 the last message on that connection, and once the message has been 696 transmitted, the server MUST close the connection. 698 After receiving DHCPLEASEQUERYSTATUS with a QueryTerminated status 699 from a server, the Requestor MAY close the TCP connection to that 700 server. 702 The DHCPv4 Leasequery protocol uses the associated-ip option as an 703 indicator that multiple bindings were present in response to a single 704 client based query. For Active Leasequery, client-based queries are 705 not supported and so the associated-ip option is not used, and MUST 706 NOT be present in replies. 708 7.4.1. Processing Replies from a Request Containing a query-start-time 710 If the DHCPACTIVELEASEQUERY was requested with a query-start-time, 711 the DHCPv4 server will attempt to send information about all bindings 712 that changed since the time specified in the query- start-time. This 713 is the catch-up phase of the DHCPACTIVELEASEQUERY processing. The 714 DHCPv4 server MAY also begin immediate updates over the same 715 connection of real-time binding information changes. Thus, the 716 catch-up phase can run in parallel with the normal updates generated 717 by the DHCPACTIVELEASEQUERY request. 719 A DHCPv4 server MAY keep only a limited amount of time ordered 720 information available to respond to a DHCPACTIVELEASEQUERY request 721 containing a query-start-time. Thus, it is possible that the time 722 specified in the query-start-time represents a time not covered by 723 the time ordered information kept by the DHCPv4 server. In such 724 case, when there is not enough data saved in the DHCPv4 server to 725 satisfy the request specified by the query-start-time option, the 726 DHCPv4 server will reply immediately with a DHCPLEASEQUERYSTATUS 727 message with a dhcp-status-code of DataMissing with a base-time 728 option equal to the server's current time. This will signal the end 729 of the catch-up phase, and the only updates that will subsequently be 730 received on this connection are the real-time updates from the 731 DHCPACTIVELEASEQUERY request. 733 If there is enough data saved to satisfy the request, then 734 DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages will begin arrive 735 from the DHCPv4 server. Some of these messages will be related to 736 the query-start-time request and be part of the catch-up phase. Some 737 of these messages will be real-time updates of binding changes taking 738 place in the DHCPv4 server. In general, there is no way to determine 739 the source each message. 741 The updates sent by the DHCPv4 server during the catch-up phase are 742 not in the order that the binding data was updated. Therefore, until 743 the catch-up phase is complete, the latest base-time value received 744 from a DHCPv4 server processing an Active Leasequery request cannot 745 be reset from the incoming messages (and used in a subsequent Active 746 Leasequery's query-start-time option), because to do so would 747 compromise the ability to recover lost information if the 748 DHCPACTIVELEASEQUERY were to terminate prior to the completion of the 749 catch-up phase. 751 The requestor will know that the catch-up phase is complete because 752 the DHCPv4 server will transmit a DHCPLEASEQUERYSTATUS message with 753 the dhcp-status-code of CatchUpComplete (or, as discussed above, 754 DataMissing). Once this message is transmitted, all additional 755 DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages will relate to real- 756 time ("new") binding changes in the DHCPv4 server. 758 As discussed in Section 6.3, the requestor SHOULD keep track of the 759 latest base-time option value received over a particular connection, 760 to be used in a subsequent DHCPACTIVELEASEQUERY request -- but only 761 if the catch-up phase is complete. Prior to the completion of the 762 catch-up phase, if the connection should go away or if the requestor 763 receives a DHCPLEASEQUERYDONE message, then when it reconnects it 764 MUST use the base-time value from the previous connection and not any 765 base-time value received from the recently closed connection. 767 In the event that there was enough data available to the DHCPv4 768 server to begin to satisfy the request implied by the query-start- 769 time option, but during the processing of that data the server found 770 that it was unable to continue (perhaps there was barely enough, the 771 connection is very slow, and the aging algorithm causes the saved 772 data to become unavailable) the DHCPv4 server will terminate the 773 catch-up phase of processing immediately by sending a 774 DHCPLEASEQUERYSTATUS message with a dhcp-status-code of DataMissing 775 and with a base-time option of the current time. 777 The requestor must not assume that every individual state change of 778 every binding during the period from the time specified in the query- 779 start-time and the present is replicated in an Active Leasequery 780 reply message. See Section 6. The requestor MAY assume that at 781 least one Active Leasequery reply message will exist for every 782 binding which had one or more changes of state during the period 783 specified by the query-start-time and the current time. The last 784 message for each binding will contain the state at the current time, 785 and there can be one or more messages concerning a single binding 786 during the catch-up phase of processing. 788 Bindings can change multiple times while the requestor is not 789 connected. The requestor will only receive information about the 790 current state of the binding, not information about each state change 791 that occurred during the period from the query-start-time to the 792 present. 794 If the DHCPLEASEQUERYSTATUS message containing a dhcp-status-code of 795 DataMissing is received and the requestor is interested in keeping 796 its database up to date with respect to the current state of the 797 bindings in the DHCPv4 server, then the requestor SHOULD issue a 798 DHCPBULKLEASEQUERY request to recover the information missing from 799 its database. This DHCPBULKLEASEQUERY should include a query-start- 800 time option, set to the same value as the query-start-time option 801 previously included in the DHCPACTIVELEASEQUERY responses from the 802 DHCPv4 server, and a query-end-time option equal to the base-time 803 option returned by the DHCPv4 server in the DHCPLEASEQUERYSTATUS 804 message with the dhcp-status-code of DataMissing. 806 Typically, the requestor would have one connection open to a DHCPv4 807 server for a DHCPACTIVELEASEQUERY request and possibly one additional 808 connection open for a DHCPBULKLEASEQUERY request to the same DHCPv4 809 server to fill in the data that might have been missed prior to the 810 initiation of the DHCPACTIVELEASEQUERY. The Bulk Leasequery 811 connection would typically run to completion and be closed, leaving 812 one Active Leasequery connection open to a single DHCPv4 server. 814 7.5. Closing Connections 816 The Requestor or DHCPv4 leasequery server MAY close its end of the 817 TCP connection at any time. The Requestor MAY choose to retain the 818 connection if it intends to issue additional queries. Note that this 819 requestor behavior does not guarantee that the connection will be 820 available for additional queries: the server might decide to close 821 the connection based on its own configuration. 823 8. Server Behavior 825 A DHCPv4 server which supports Active Leasequery MUST support Bulk 826 Leasequery [RFC6926] as well. 828 8.1. Accepting Connections 830 DHCPv4 servers that implement DHCPv4 Active Leasequery listen for 831 incoming TCP connections. The approach used in accepting the 832 requestor's connection is the same as specified in DHCPv4 Bulk 833 Leasequery [RFC6926], with the exception that support for Active 834 Leasequery MUST NOT be enabled by default, and MUST require an 835 explicit configuration step to be performed before it will operate. 837 DHCPv4 servers SHOULD be able to operate in either insecure or secure 838 mode. See Section 9. This MAY be a mode that is administratively 839 controlled, where the server will require a TLS connection to operate 840 or will only operate without a TLS connection. In either case, 841 operation in insecure mode MUST NOT be the default, even if operation 842 in secure mode is not supported. Operation in insecure mode MUST 843 always require an explicit configuration step, separate from the 844 configuration step required to enable support for Active Leasequery. 846 When operating in insecure mode, the DHCPv4 server simply waits for 847 the requestor to send the Active Leasequery after the establishment 848 of TCP connection. If it receives a DHCPTLS message, it will respond 849 with TLSConnectionRefused in a DHCPTLS message. 851 When operating in secure mode, DHCPv4 servers MUST support TLS 852 [RFC5246] to protect the integrity and privacy of the data 853 transmitted over the TCP connection. When operating in secure mode, 854 DHCPv4 servers MUST be configurable with regard to which requestors 855 they will communicate. The certificate presented by a requestor when 856 initiating the TLS connection is used to distinguish between 857 acceptable and unacceptable requestors. 859 When operating in secure mode, a DHCPv4 server MUST begin to 860 negotiate a TLS connection with a requestor who asks for one, and 861 MUST close TCP connections which are not secured with TLS or for 862 which the requestor's certificate is deemed unacceptable. The 863 recommendations in [RFC7525] apply when negotiating a TLS connection. 865 A requestor will request a TLS connection by sending a DHCPTLS as the 866 first message over a newly created TCP connection. If the DHCPv4 867 server supports TLS connections and has not been configured to not 868 allow them on this link, the DHCPv4 server MUST respond to this 869 DHCPTLS message by sending a DHCPTLS message with no dhcp-status-code 870 back to the requestor. This indicates to the requestor that the 871 DHCPv4 server will support the negotiation of a TLS connection over 872 this existing TCP connection. 874 If a connection is to be rejected because of a limitation of the 875 number of open connections, the TCP connection itself should be 876 rejected, or the subsequent ACTIVELEASEQUERY message should be 877 rejected. Capacity related rejections SHOULD NOT affect the response 878 to the DHCPTLS message. 880 Any options appearing in a DHCPTLS message received by a DHCPv4 881 server SHOULD be ignored. This is a SHOULD instead of a MUST in 882 order to allow use of the DHCPTLS message in later documents, 883 possibly with the use of options, without requiring those documents 884 to update this document. 886 If for some reason the DHCPv4 server cannot or has been configured to 887 not support a TLS connection, then it sends a DHCPTLS message with a 888 dhcp-status-code of TLSConnectionRefused back to the requestor. 890 In the event that the DHCPv4 server sends a DHCPTLS message with no 891 dhcp-status-code option included (which indicates success), the 892 requestor is supposed to initiate a TLS handshake [RFC5246] (see 893 Section 7.2). During the TLS handshake, the DHCPv4 server MUST 894 validate the requestor's digital certificate. In addition, the 895 digital certificate presented by the requestor is used to decide if 896 this requestor is allowed to perform an Active Leasequery. If this 897 requestor's certificate is deemed unacceptable, the server MUST abort 898 the creation of the TLS connection. 900 All TLS connections established between the a requestor and a DHCPv4 901 server for the purposes of supporting Active Leasequery MUST be 902 mutually authenticated. 904 If the TLS handshake is not successful in creating a TLS connection, 905 the server MUST close the TCP connection. 907 If the TCP connection becomes blocked while the server is accepting a 908 connection or reading a query, it SHOULD terminate the connection 909 after a BULK_LQ_DATA_TIMEOUT. We make this recommendation to allow 910 servers to control the period of time they are willing to wait before 911 abandoning an inactive connection, independent of the TCP 912 implementations they may be using. 914 8.1.1. Update to RFC 6926 916 In an update to the DHCPv4 Bulk Leasequery protocol [RFC6926] (which 917 didn't discuss this situation explicitly), if the DHCPv4 server 918 receives a DHCPv4 message containing a dhcp-message-type option with 919 a value that is not supported over a TCP connection, it MUST close 920 the TCP connection. 922 8.2. Replying to an Active Leasequery 924 If the connection becomes blocked while the server is attempting to 925 send reply messages, the server SHOULD terminate the TCP connection 926 after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs how long the 927 DHCPv4 server is prepared to wait for the requestor to read and 928 process enough information to unblock the TCP connection. The 929 default is two minutes, which means that if more than two minutes 930 goes by without the requestor reading enough information to unblock 931 the TCP connection, the DHCPv4 server SHOULD close the TCP 932 connection. 934 If the DHCPv4 server encounters an error during processing of the 935 DHCPACTIVELEASEQUERY message, either during initial processing or 936 later during the message processing, it SHOULD send a 937 DHCPLEASEQUERYSTATUS containing an error code of some kind in a dhcp- 938 status-code option. It SHOULD close the connection after this error 939 is signaled. 941 Every reply to a DHCPACTIVELEASEQUERY request MUST contain the 942 information specified in replies to a DHCPBULKLEASEQUERY request 943 [RFC6926], with the exception that a server implementing Active 944 Leasequery SHOULD be able to be configured to prevent specific data 945 items from being sent to the requestor even if these data items were 946 requested in the dhcp-parameter-request-list option.. 948 Some servers can be configured to respond to a DHCPv4 Leasequery 949 [RFC4388] or a DHCPBULKLEASEQUERY [RFC6926] for an IPv4 binding which 950 is reserved in such a way that it appears that the IPv4 binding is 951 leased to the DHCP client for which it is reserved. These servers 952 SHOULD also respond to a DHCPACTIVELEASEQUERY request with the same 953 information as they would to a DHCPBULKLEASEQUERY request when they 954 first determine that the IPv4 binding is reserved to a DHCP client. 956 If a DHCPACTIVELEASEQUERY request contains a query-start-time option, 957 it indicates that the requestor would like the DHCPv4 server to send 958 it not only messages that correspond to DHCPv4 binding activity that 959 occurs subsequent to the receipt of the DHCPLEASEACTIVE request, but 960 also messages that correspond to DHCPv4 binding activity that 961 occurred prior to the DHCPACTIVELEASEQUERY request. 963 If a query-end-time option appears in a DHCPACTIVELEASEQUERY the 964 DHCPv4 server should send a DHCPLEASEQUERYSTATUS message with a dhcp- 965 status-code of MalformedQuery and terminate the connection. 967 In order to implement a meaningful response to this query, the DHCPv4 968 server MAY keep track of the binding activity and associate changes 969 with particular base-time values from the messages. Then, when 970 requested to do so by a DHCPACTIVELEASEQUERY request containing a 971 query-start-time option, the DHCPv4 server can respond with replies 972 for all binding activity occurring on that query-start-time or later 973 times. 975 These replies based on the query-start-time MAY be interleaved with 976 the messages generated due to current binding activity. 978 Once the transmission of the DHCPv4 Leasequery messages associated 979 with the query-start-time option are complete, a DHCPLEASEQUERYSTATUS 980 message MUST be sent with a dhcp-status-code value of 981 CatchUpComplete. 983 The DHCPv4 server SHOULD keep track of previous binding activity. It 984 SHOULD limit the amount of previous binding activity it keeps track 985 of. The DHCPv4 server MAY choose to only do this in the event that 986 it has received at least one DHCPACTIVELEASEQUERY request in the 987 past, as to do so will almost certainly entail some utilization of 988 resources which would be wasted if there are no DHCPACTIVELEASEQUERY 989 requestors for this DHCPv4 server. The DHCPv4 server SHOULD make the 990 amount of previous binding activity it retains configurable. There 991 is no requirement on the DHCPv4 server to retain this information 992 over a server restart (or even to retain such information at all). 994 Unless there is an error or some requirement to cease processing a 995 DHCPACTIVELEASEQUERY request yielding a DHCPLEASEQUERYSTATUS message, 996 such as a server shutdown, there will be no DHCPLEASEQUERYSTATUS 997 message at the conclusion of the DHCPACTIVELEASEQUERY processing 998 because that processing will not conclude but will continue until 999 either the requestor or the server closes the connection. 1001 While the form of the data being sent by a DHCPACTIVELEASEQUERY is 1002 essentially the same as that being sent by a DHCPBULKLEASEQUERY, the 1003 reasons for sending information differs considerably between these 1004 two capabilities. In the DHCPBULKLEASEQUERY context, the entire 1005 contents of the lease state database (subject to the constraints of 1006 the various query options) are returned to the requestor. In the 1007 DHCPACTIVELEASEQUERY context, changes to the lease state database are 1008 returned to the requestor essentially as they happen. For instance, 1009 when an IPv4 binding transitions from the leased state to some other 1010 state, the DHCPACTIVELEASEQUERY will send a DHCPLEASEUNASSIGNED 1011 packet with information regarding that binding. The server may then 1012 entirely forget about that IPv4 binding (or not), but it is important 1013 to tell the DHCPACTIVELEASEQUERY requestor that an binding has 1014 transitioned away from the leased state. 1016 The relationship between the time that the server replies to a DHCP 1017 client request and the time that the DHCP server sends a reply to a 1018 DHCPACTIVELEASEQUERY message is a matter of implementation (and thus 1019 not something defined by this document). However, the server SHOULD 1020 NOT delay responding to the DHCP client in order to transmit a reply 1021 to a DHCPACTIVELEASEQUERY message, and the server SHOULD send the 1022 reply to the DHCPACTIVELASEQUERY message as soon as possible after 1023 responding to the client. 1025 8.3. Multiple or Parallel Queries 1027 Every Active Leasequery request MUST be made on a single TCP 1028 connection where there is no other request active at the time the 1029 request is made. Note that this is different than what was allowed 1030 in [RFC6926] section 7.7 for Bulk Leasequery requests. 1032 Typically, a requestor of a Active Leasequery would not need to send 1033 a second Active Leasequery while the first is still active. However, 1034 sending an Active Leasequery and a Bulk Leasequery in parallel would 1035 be possible and reasonable. In case of parallel Active and Bulk 1036 Leasequery requests, the requestor MUST use different connections. 1038 This MAY be a feature that is administratively controlled. Servers 1039 that are able to process queries in parallel SHOULD offer 1040 configuration that limits the number of simultaneous queries 1041 permitted from any one requestor, in order to control resource use if 1042 there are multiple requestors seeking service. 1044 8.4. Closing Connections 1046 The server MAY end communication by sending a DHCPLEASEQUERYSTATUS 1047 message and then immediately closing the TCP connection. 1048 Alternatively, the server MAY retain the connection and wait for 1049 additional queries from the requestor. The server SHOULD limit the 1050 number of connections it maintains, and SHOULD close idle connections 1051 to enforce the limit. 1053 The server MUST close its end of the TCP connection if it encounters 1054 an error sending data on the connection. The server MUST close its 1055 end of the TCP connection if it finds that it has to abort an in- 1056 process request. A server aborting an in-process request SHOULD 1057 attempt to signal that to its requestors by using the QueryTerminated 1058 status code in the dhcp-status-code option in a DHCPLEASEQUERYSTATUS 1059 message. If the server detects that the requestor end has been 1060 closed, the server MUST close its end of the connection. 1062 9. Security Considerations 1064 The "Security Considerations" section of [RFC2131] details the 1065 general threats to DHCPv4. The DHCPv4 Leasequery specification 1066 [RFC4388] describes recommendations for the Leasequery protocol, 1067 especially with regard to relayed LEASEQUERY messages, mitigation of 1068 packet-flooding DOS attacks, restriction to trusted requestors, and 1069 use of IPsec [RFC4301]. 1071 The use of TCP introduces some additional concerns. Attacks that 1072 attempt to exhaust the DHCPv4 server's available TCP connection 1073 resources can compromise the ability of legitimate clients to receive 1074 service. Malicious requestors who succeed in establishing 1075 connections, but who then send invalid queries, partial queries, or 1076 no queries at all also can exhaust a server's pool of available 1077 connections. 1079 Two modes of operation exist for this protocol, insecure mode and 1080 secure mode. These two modes exists because there are essentially 1081 two models of use for this protocol. In one model, the requestor of 1082 an Active Leasequery is connected to the internet in an arbitrary 1083 location, and the information transmitted needs to be protected 1084 during transmission. In addition, the identity of both requestor and 1085 server need to be verified. For this model of use, the secure mode 1086 is appropriate. 1088 The other model of use is where the requestor of the Active 1089 Leasequery resides in a network element that is essentially "next to" 1090 the element containing the DHCP server, and both of these elements 1091 are inside a protected environment. For this model, the insecure 1092 mode is sufficient since there are other, more global, protections in 1093 place to protect this information. 1095 When operating in secure mode, TLS [RFC5246] is used to secure the 1096 connection. The recommendations in [RFC7525] apply when negotiating 1097 a TLS connection. 1099 Operating in insecure mode (see Section 8.1 does not provide any way 1100 to validate the authorization of requestors of a DHCPV4 Active 1101 Leasequery request. 1103 Servers SHOULD offer configuration parameters to limit the sources of 1104 incoming connections through validation and use of the digital 1105 certificates presented to create a TLS connection. They SHOULD also 1106 limit the number of accepted connections, and limit the period of 1107 time during which an idle connection will be left open. 1109 The data acquired by using an Active Leasequery is subject to the 1110 same potential abuse as the data held by the DHCPv4 server from which 1111 it was acquired, and SHOULD be secured by mechanisms as strong as 1112 those used for the data held by that DHCPv4 server. The data 1113 acquired by using an Active Leasequery SHOULD be deleted as soon as 1114 possible after the use for which it was acquired has passed. 1116 Servers which implement the Bulk Leasequery protocol [RFC6926] but do 1117 not implement the Active Leasequery protocol SHOULD implement the 1118 update to [RFC6926] discussed in Section 8.1.1. 1120 10. IANA Considerations 1122 IANA is requested to assign the following new DHCP message types from 1123 the registry "DHCP Message Type 53 Values" maintained at 1124 http://www.iana.org/assignments/bootp-dhcp-parameters: 1126 1. A dhcp-message-type of TBD1 for DHCPACTIVELEASEQUERY. 1128 2. A dhcp-message-type of TBD2 for DHCPLEASEQUERYSTATUS. 1130 3. A dhcp-message-type of TBD3 for DHCPTLS. 1132 IANA is requested to assign the following new DHCP status codes from 1133 the registry "DHCP Status Code Type 151 Values" maintained at 1134 http://www.iana.org/assignments/bootp-dhcp-parameters: 1136 +----------------------+-------------+ 1137 | Name | status-code | 1138 +----------------------+-------------+ 1139 | DataMissing | TBD4 | 1140 | ConnectionActive | TBD5 | 1141 | CatchUpComplete | TBD6 | 1142 | TLSConnectionRefused | TBD7 | 1143 +----------------------+-------------+ 1145 11. Acknowledgments 1147 The ideas in this document came in part from work in DHCPv6 and 1148 DHCPv4 Bulk Leasequery as well as from in depth discussions between 1149 the authors. Useful review comments by Ted Lemon, Scott Bradner, 1150 Francis Dupont, and Stephen Farrell on drafts for DHCPv6 Active 1151 Leasequery were also included in this draft. Brian Haberman's review 1152 brought this document into much closer alignment with DHCPv6 Active 1153 Leasequery. Additional reviews by Alissa Cooper, Spencer Dawkins, 1154 Christer Holmberg, and Ben Campbell added clarity to this document. 1156 12. References 1158 12.1. Normative References 1160 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1161 Requirement Levels", BCP 14, RFC 2119, 1162 DOI 10.17487/RFC2119, March 1997, 1163 . 1165 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1166 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1167 . 1169 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 1170 Protocol (DHCP) Leasequery", RFC 4388, 1171 DOI 10.17487/RFC4388, February 2006, 1172 . 1174 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1175 (TLS) Protocol Version 1.2", RFC 5246, 1176 DOI 10.17487/RFC5246, August 2008, 1177 . 1179 [RFC6926] Kinnear, K., Stapp, M., Desetti, R., Joshi, B., Russell, 1180 N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery", 1181 RFC 6926, DOI 10.17487/RFC6926, April 2013, 1182 . 1184 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1185 "Recommendations for Secure Use of Transport Layer 1186 Security (TLS) and Datagram Transport Layer Security 1187 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1188 2015, . 1190 12.2. Informative References 1192 [RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, 1193 DOI 10.17487/RFC0951, September 1985, 1194 . 1196 [RFC1542] Wimer, W., "Clarifications and Extensions for the 1197 Bootstrap Protocol", RFC 1542, DOI 10.17487/RFC1542, 1198 October 1993, . 1200 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1201 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 1202 . 1204 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1205 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1206 December 2005, . 1208 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 1209 Zimmermann, "A Roadmap for Transmission Control Protocol 1210 (TCP) Specification Documents", RFC 7414, 1211 DOI 10.17487/RFC7414, February 2015, 1212 . 1214 Authors' Addresses 1216 Kim Kinnear 1217 Cisco Systems, Inc. 1218 1414 Massachusetts Ave 1219 Boxborough, MA 01719 1220 USA 1222 Email: kkinnear@cisco.com 1224 Mark Stapp 1225 Cisco Systems, Inc. 1226 1414 Massachusetts Ave 1227 Boxborough, MA 01719 1228 USA 1230 Email: mjs@cisco.com 1231 Bernie Volz 1232 Cisco Systems, Inc. 1233 1414 Massachusetts Ave 1234 Boxborough, MA 01719 1235 USA 1237 Email: volz@cisco.com 1239 Neil Russell 1240 Staples 1241 500 Staples Drive 1242 Framingham, MA 01702 1243 USA 1245 Email: neil.e.russell@gmail.com