idnits 2.17.1 draft-ietf-dhc-dhcpv4-bulk-leasequery-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 520 has weird spacing: '...ge-size the...' == Line 604 has weird spacing: '...-number base...' == Line 605 has weird spacing: '...-number fro...' == Line 612 has weird spacing: '... Name sta...' == Line 1695 has weird spacing: '... Name sta...' == 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 (February 13, 2009) is 5551 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) == Outdated reference: A later version (-13) exists of draft-ietf-dhc-relay-id-suboption-06 -- No information found for draft-ietf-dhc-vpn-option - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'VpnId' -- Obsolete informational reference (is this intentional?): RFC 4614 (Obsoleted by RFC 7414) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Kim Kinnear 3 Internet Draft Bernie Volz 4 Intended Status: Standards Track Neil Russell 5 Expires: August 13, 2009 Mark Stapp 6 Cisco Systems, Inc. 7 D. Rao 8 B. Joshi 9 P. Kurapati 10 Infosys Technologies Ltd. 11 February 13, 2009 13 Bulk DHCPv4 Lease Query 14 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 13, 2009 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. 51 Abstract 53 The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been 54 extended with a Leasequery capability that allows a requestor to 55 request information about DHCPv4 bindings. That mechanism is limited 56 to queries for individual bindings. In some situations individual 57 binding queries may not be efficient, or even possible. This 58 document expands on the DHCPv4 Leasequery protocol to allow for bulk 59 transfer of DHCPv4 address binding data via TCP. 61 Table of Contents 63 1. Introduction................................................. 3 64 2. Terminology.................................................. 4 65 3. Motivation................................................... 6 66 4. Design Goals................................................. 8 67 4.1. Information Acquisition before Data Starts................. 8 68 4.2. Lessen need for Caching and Negative Caching............... 8 69 4.3. Antispoofing in 'Fast Path'................................ 8 70 4.4. Minimize data transmission................................. 8 71 5. Protocol Overview............................................ 9 72 6. Interaction Between UDP Leasequery and Bulk Leasequery....... 10 73 7. Message and Option Definitions............................... 11 74 7.1. Message Framing for TCP.................................... 11 75 7.2. New or Changed Options..................................... 12 76 7.3. Connection and Transmission Parameters..................... 20 77 8. Requestor Behavior........................................... 20 78 8.1. Connecting and General Processing.......................... 20 79 8.2. Forming a Bulk Leasequery.................................. 21 80 8.3. Processing Bulk Replies.................................... 23 81 8.4. Processing Time Values in Leasequery messages.............. 25 82 8.5. Querying Multiple Servers.................................. 27 83 8.6. Making Sense Out of Multiple Responses Concerning a Single. 27 84 8.7. Multiple Queries to a Single Server over One Connection.... 28 85 8.8. Closing Connections........................................ 29 86 9. Server Behavior.............................................. 29 87 9.1. Accepting Connections...................................... 29 88 9.2. Replying to a Bulk Leasequery.............................. 30 89 9.3. Building a Single Reply for Bulk Leasequery................ 34 90 9.4. Multiple or Parallel Queries............................... 35 91 9.5. Closing Connections........................................ 36 92 10. Security Considerations..................................... 36 93 11. IANA Considerations......................................... 36 94 12. Acknowledgements............................................ 38 95 13. References.................................................. 38 96 13.1. Normative References...................................... 38 97 13.2. Informative References.................................... 39 98 Authors' Addresses............................................... 39 99 Appendix -- Why a New Leasequery is Required..................... 41 101 1. Introduction 103 The DHCPv4 protocol [RFC2131] [RFC2132] specifies a mechanism for the 104 assignment of IPv4 address and configuration information to IPv4 105 nodes. DHCPv4 servers maintain authoritative binding information. 107 +--------+ 108 | DHCPv4 | +--------------+ 109 | Server |-...-| DSLAM | 110 | | | Relay Agent | 111 +--------+ +--------------+ 112 | | 113 +------+ +------+ 114 |Modem1| |Modem2| 115 +------+ +------+ 116 | | | 117 +-----+ +-----+ +-----+ 118 |Host1| |Host2| |Host3| 119 +-----+ +-----+ +-----+ 121 Figure 1: Example DHCPv4 configuration 123 DHCPv4 relay agents receive DHCPv4 messages and frequently append a 124 relay agent information option [RFC3046] before relaying them to the 125 configured DHCPv4 servers (see Figure 1). In this process, some 126 relay agents also glean the lease information sent by the server and 127 maintain this locally. This information is used for a variety of 128 purposes, including prevention of spoofing attempts from the DHCPv4 129 clients and to install routes. When a relay agent reboots, this 130 information is frequently lost. 132 The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4 133 capability to allow an external entity, such as a relay agent, to 134 query a DHCPv4 server to recover lease state information about a 135 particular IP address or client in near real-time. 137 The existing query types in Leasequery are typically data driven; the 138 relay agent initiates the Leasequery when it receives data traffic 139 from or to the client. This approach may not scale well when there 140 are thousands of clients connected to the relay agent or when the 141 relay agent has a need to rebuild its internal data store prior to 142 processing traffic in one direction or another. 144 Different query types are needed where a relay agent can query the 145 server without waiting for the traffic from or for the clients, as 146 well as a different transmission technique more conducive to the 147 transmission of large quantities of data. 149 This document extends the DHCPv4 Leasequery protocol to add support 150 for queries that address these additional requirements. There may be 151 many thousands of DHCPv4 bindings returned as the result of a single 152 request, so TCP [RFC4614] is specified for efficiency of data 153 transfer. We define several additional query types, each of which 154 could return multiple responses, in order to meet a variety of 155 requirements. 157 2. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC 2119 [RFC2119]. 163 This document uses the following terms: 165 o "absolute time" 167 A 32-bit quantity containing the number of seconds since Jan 1, 168 1970. 170 o "access concentrator" 172 An access concentrator is a router or switch at the broadband 173 access provider's edge of a public broadband access network. 174 This document assumes that the access concentrator includes the 175 DHCPv4 relay agent functionality. For example, a CMTS (Cable 176 Modem Termination System) in Cable environment or a DSLAM 177 (Digital Subscriber Line Multiplexer) in a DSL environment. 179 o "active binding" 181 An IP address with an active binding refers to an IP address 182 which is currently associated with a DHCPv4 client where that 183 DHCPv4 client has the right to use the IP address. 185 o "Bulk Leasequery" 186 Requesting and receiving the existing DHCPv4 address binding 187 information in an efficient manner. 189 o "clock skew" 191 The difference between the absolute time on a DHCPv4 server and 192 the absolute time on the system where a requestor of a Bulk 193 Leasequery is executing is termed the "clock skew" for that Bulk 194 Leasequery connection. It is not absolutely constant but is 195 likely to vary only slowly. It is possible that, when both 196 systems run NTP, the clock skew is negligible, and this is not 197 only acceptable, but desired. 199 While it is easy to think that this can be calculated precisely 200 after one message is received by a requestor from a DHCPv4 201 server, a more accurate value is derived from continuously 202 examining the instantaneous value developed from each message 203 received from a DHCPv4 server and using it to make small 204 adjustments to the existing value held in the requestor. 206 o "DHCPv4 client" 208 A DHCPv4 client is an Internet host using DHCPv4 to obtain 209 configuration parameters such as a network address. 211 o "DHCPv4 relay agent" 213 A DHCPv4 relay agent is a third-party agent that transfers BOOTP 214 and DHCPv4 messages between clients and servers residing on 215 different subnets, per [RFC951] and [RFC1542]. 217 o "DHCPv4 server" 219 A DHCPv4 server is an Internet host that returns configuration 220 parameters to DHCPv4 clients. 222 o "DSLAM" 224 Digital Subscriber Line Multiplexer. 226 o "downstream" 228 Refers to a direction away from the central part of a network 229 and toward the edge. In a DHCPv4 context, typically refers to a 230 network direction which is away from the DHCPv4 server. 232 o "IP address" 233 In this document, the term "IP address" refers to an IPv4 IP 234 address. 236 o "IP address binding" 238 The information that a DHCPv4 server keeps regarding the 239 relationship between a DHCPv4 client and an IPv4 IP address. 240 This includes the identity of the DHCPv4 client and the 241 expiration time, if any, of any lease that client has on a 242 particular IPv4 address. In some contexts, this may include 243 information on IP addresses that are currently associated with 244 DHCPv4 clients, and in others it may also include IP addresses 245 with no current association to a DHCPv4 client. 247 o "MAC address" 249 In the context of a DHCPv4 message, a MAC address consists of 250 the fields: hardware type "htype", hardware length "hlen", and 251 client hardware address "chaddr". 253 o "upstream" 255 Refers to a direction toward the central part of a network and 256 away from the edge. In a DHCPv4 context, typically refers to a 257 network direction which is toward the DHCPv4 server. 259 o "stable storage" 261 Stable storage is used to hold information concerning IP address 262 bindings (among other things) so that this information is not 263 lost in the event of a failure which requires restart of the 264 network element. DHCPv4 servers are typically expected to have 265 high speed access to stable storage, while relay agents and 266 access concentrators usually do not have access to stable 267 storage, although they may have periodic access to such storage. 269 o "xid" 271 Transaction-id. The term "xid" refers to the DHCPv4 field 272 containing the transaction-id of the message. 274 3. Motivation 276 Consider a typical DSLAM working also as a DHCPv4 relay agent (see 277 Figure 1). Typically, both a "fast path" and a "slow path" exist in 278 many network elements, including DSLAMs. Fast path processing is 279 done in a network processor or in an ASIC (Application Specific 280 Integrated Circuit). Slow path processing is done in a normal 281 processor. As much as possible, regular data handling code should be 282 in the fast path. Slow path processing should be reduced as it may 283 become a bottleneck. 285 For a DSLAM having multiple DSL ports, multiple IP addresses may be 286 assigned using DHCPv4 to a single port and the number of DHCPv4 287 clients on a port may be unknown. The DSLAM may also not know the 288 network portions of the IP addresses that are assigned to its DHCPv4 289 clients. 291 The DSLAM gleans IP address or other information from DHCP 292 negotiations for antispoofing and for other purposes. The 293 antispoofing itself is done in the fast path. The DSLAM keeps track 294 of only one list of IP addresses: the list of IP addresses that are 295 assigned by a DHCPv4 server. Traffic for all other IP addresses is 296 dropped. If a client starts its data transfer after its DHCPv4 297 negotiations are gleaned by the DSLAM, no legitimate packets will be 298 dropped because of antispoofing. In other words, antispoofing is 299 effective (no legitimate packets are dropped and all spoofed packets 300 are dropped) and efficient (antispoofing is done in the fast path). 301 The intention is to achieve similar effective and efficient 302 antispoofing in the Leasequery scenario after a DSLAM loses its 303 gleaned information (for example, because of reboot). 305 After a deep analysis, we found that the three existing query types 306 supported by [RFC4388] do not provide effective and efficient 307 antispoofing for the above scenario and a new mechanism is required. 309 The existing query types 311 o necessitate a data driven approach: the lease queries can only 312 be done when the Access Concentrator receives data. That 313 results in increased outage time for DHCPv4 clients; 315 o result in excessive negative caching consuming lot of resources 316 under a spoofing attack; 318 o result in antispoofing being done in the slow path instead of 319 the fast path; 321 o do not support an Access Concentrator which periodically uploads 322 its internal table to some form of stable storage. 324 The deeper analysis, which led to the above conclusions, itself 325 appears as an Appendix to this document. 327 4. Design Goals 329 The goal of this document is to provide a lightweight mechanism for 330 an Access Concentrator or other network element to retrieve IP 331 address binding information available in the DHCPv4 server. The 332 mechanism should also allow an Access Concentrator to retrieve 333 consolidated IP address binding information for either the entire 334 access concentrator or a single connection/circuit. 336 4.1. Information Acquisition before Data Starts 338 The existing data driven approach required by [RFC4388] means that 339 the Leasequeries can only be performed after an Access Concentrator 340 receives data. To implement antispoofing, packets need to be dropped 341 until it gets the lease information from DHCPv4 server. If an Access 342 Concentrator finishes the Leasequeries before it starts receiving 343 data, then there is no need to drop legitimate packets. In this way, 344 outage time may be reduced. 346 4.2. Lessen need for Caching and Negative Caching 348 The result of a single Leasequery should be cached, whether that 349 results in a positive or negative cache, in order to remember that 350 the Leasequery was performed. This caching is required to limit the 351 traffic imposed upon a DHCPv4 server by Leasequeries for information 352 already received. 354 These caches not only consume precious resources, they also need to 355 be managed. Hence they should be avoided as much as possible. 357 4.3. Antispoofing in 'Fast Path' 359 If Antispoofing is not done in the fast path, it will become a 360 bottleneck and may lead to denial of service of the access 361 concentrator. The Leasequeries should make it possible to do 362 antispoofing in the fast path. 364 4.4. Minimize data transmission 366 It may be that a network element is able to periodically save its 367 entire list of assigned IP addresses to some form of stable storage. 368 In this case, it will wish to recover all of the updates to this 369 information without duplicating the information it has recovered from 370 its own stable storage. 372 Bulk Leasequery allows the specification of a query-start-time as 373 well as a query-end-time. Use of query-times allows a network 374 element that periodically commits information to stable storage to 375 recover just what it lost since the last commit. 377 5. Protocol Overview 379 The Bulk Leasequery mechanism is modeled on the existing individual 380 Leasequery protocol in [RFC4388] as well as related work on DHCPv6 381 Bulk Leasequery [DHCPv6Bulk]. A Bulk Leasequery requestor opens a TCP 382 connection to a DHCPv4 Server, using the DHCPv4 port 67. Note that 383 this implies that the Leasequery requestor has server IP address(es) 384 available via configuration or some other means, and that it has 385 unicast IP reachability to the DHCPv4 server. No relaying of Bulk 386 Leasequery messages is specified. 388 After establishing a connection, the requestor sends a 389 DHCPBULKLEASEQUERY message over the connection. 391 The server uses the message type and additional data in the DHCPv4 392 DHCPBULKLEASEQUERY message to identify any relevant bindings. 394 In order to support some query types, servers may have to maintain 395 additional data structures or otherwise be able to locate bindings 396 that have been requested by the Leasequery requestor. 398 Relevant bindings are returned in DHCPv4 packets with either the 399 DHCPLEASEACTIVE message type for an IP address with a currently 400 active lease or, in some situations, a DHCPLEASEUNASSIGNED message 401 type for an IP address which is controlled by the DHCPv4 server but 402 which is not actively leased by a DHCPv4 client at the present time. 404 The Bulk Leasequery mechanism is designed to provide an external 405 entity with information concerning existing DHCPv4 IPv4 address 406 bindings managed by the DHCPv4 server. When complete, the DHCPv4 407 server will send a DHCPLEASEQUERYDONE message. If a connection is 408 lost while processing a Bulk Leasequery, the Bulk Leasequery must be 409 retried as there is no provision for determining the extent of data 410 already received by the requestor for a Bulk Leasequery. 412 Bulk Leasequery supports queries by MAC address and by Client 413 Identifier in a way similar to [RFC4388]. The Bulk Leasequery 414 protocol also adds several new queries. 416 o Query by Relay Identifier 417 This query asks a server for the bindings associated with a 418 specific relay agent; the relay agent is identified by a DUID 419 carried in a Relay-ID sub-option [RelayId]. Relay agents can 420 include this sub-option while relaying messages to DHCPv4 421 servers. Servers can retain the Relay-ID and associate it with 422 bindings made on behalf of the relay agent's clients. The 423 bindings returned are only those for DHCPv4 clients with a 424 currently active binding. 426 o Query by Remote ID 428 This query asks a server for the bindings associated with a 429 Relay Agent Remote-ID sub-option [RFC3046] value. The bindings 430 returned are only those for DHCPv4 clients with a currently 431 active binding. 433 o Query for All Configured IP Addresses 435 This query asks a server for information concerning all IP 436 addresses configured in that DHCPv4 server, by specifying no 437 other type of query. In this case, the bindings returned are for 438 all configured IP addresses, whether or not they contain a 439 currently active binding to a DHCPv4 client, since one point of 440 this type of query is to update an existing database with 441 changes after a particular point in time. 443 Any of the above queries can be qualified by the specification of a 444 query-start-time or a query-end-time (or both). When these timers are 445 used as qualifiers, they indicate that a binding should be included 446 if it changed on or after the query-start-time and on or before the 447 query-end-time. 449 In addition, any of the above queries can be qualified by the 450 specification of a vpn-id option [VpnId] to select the VPN on which 451 the query should be processed. The vpn-id option is also extended to 452 allow queries across all available VPNs. By default, only the default 453 VPN is used to satisfy the query. 455 6. Interaction Between UDP Leasequery and Bulk Leasequery 457 Bulk Leasequery can be seen as an extension of the existing UDP 458 Leasequery protocol [RFC4388]. This section clarifies the 459 relationship between the two protocols. 461 Only the DHCPBULKLEASEQUERY request is supported over the Bulk 462 Leasequery connection. No other DHCPv4 requests are supported. The 463 Bulk Leasequery connection is not an alternative DHCPv4 communication 464 option for clients seeking other DHCPv4 services. 466 Two of the query-types introduced in the UDP Leasequery protocol can 467 be used in the Bulk Leasequery protocol -- query by MAC address and 468 query by client-id. 470 The contents of the reply messages are similar between the existing 471 UDP Leasequery protocol and the Bulk Leasequery protocol, though more 472 information is returned in the Bulk Leasequery messages. 474 One change in behavior for these existing queries is required when 475 Bulk Leasequery is used. [RFC4388], in sections 6.1, 6.4.1, and 476 6.4.2 specifies the use of an associated-ip option in DHCPLEASEACTIVE 477 messages in cases where multiple bindings were found. When Bulk 478 Leasequery is used, this mechanism is not necessary; a server 479 returning multiple bindings simply does so directly as specified in 480 this document. The associated-ip option MUST NOT appear in Bulk 481 Leasequery replies. 483 Implementors should note that the TCP message framing defined in 484 Section 5.1 is not compatible with the UDP message format. If a TCP- 485 framed request is sent as a UDP message, it may not be valid, because 486 protocol fields will be offset by the message-size prefix. 488 7. Message and Option Definitions 490 7.1. Message Framing for TCP 492 The use of TCP for the Bulk Leasequery protocol permits multiple 493 messages to be sent from one end of the connection to the other 494 without requiring a request/response paradigm as does UDP DHCPv4 495 [RFC2131]. The receiver needs to be able to determine the size of 496 each message it receives. Two octets containing the message size in 497 network byte-order are prepended to each DHCPv4 message sent on a 498 Bulk Leasequery TCP connection. The two message-size octets 'frame' 499 each DHCPv4 message. 501 The maximum message size is 65535 octets. 503 DHCPv4 message framed for TCP: 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | message-size | op (1) | htype (1) | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | hlen (1) | hops (1) | .... | 511 +---------------+---------------+ + 512 | | 513 . remainder of DHCPv4 message, 514 . from Figure 1 of [RFC2131] . 515 . . 516 . (variable) . 517 | | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 message-size the number of octets in the message that 521 follows, as a 16-bit integer in network 522 byte-order. 524 All other fields are as specified in DHCPv4 [RFC2131]. 526 Figure 2: Format of a DHCPv4 message in TCP 528 The intent in using this format is that code which currently knows 529 how to deal with sending or receiving a message in [RFC2131] format 530 will easily be able to deal with the message contained in the TCP 531 framing. 533 7.2. New or Changed Options 535 The existing messages DHCPLEASEUNASSIGNED and DHCPLEASEACTIVE are 536 used as the value of the dhcp-message-type option to indicate an IP 537 address which is currently not leased or currently leased to a DHCPv4 538 client, respectively [RFC4388]. 540 Additional options have also been defined to enable the Bulk 541 Leasequery protocol to communicate useful information to the 542 requestor. 544 7.2.1. dhcp-message-type 546 The dhcp-message-type option (option 53) from Section 9.6 of 547 [RFC2132] requires new values. The values of these message types are 548 shown below in an extension of the table from Section 9.6 of 549 [RFC2132]: 551 Value Message Type 552 ----- ------------ 553 14 DHCPBULKLEASEQUERY 554 15 DHCPLEASEQUERYDONE 556 7.2.2. dhcp-message 558 The dhcp-message option (option 56) from Section 9.9 of [RFC2132] 559 requires additional definition for use in the context of a 560 DHCPBULKLEASEQUERY. 562 The format of the NVT ASCII message in the dhcp-message option is 563 specified to have the first three characters appear in a constrained 564 format. The first three characters MUST be numeric (base 10) 565 characters. 567 Encoded in these first three characters is the decimal number 568 corresponding to a variety of status codes defined below. 570 The motivation for this constraint of the existing dhcp-message 571 option is to reduce the number of top-level options used by this 572 document. 574 The status code returned in the dhcp-message option allows greater 575 detail to be returned regarding the status of a DHCPBULKLEASEQUERY 576 request. While specified in the Bulk Leasequery document, this 577 additional specification of the DHCPv4 dhcp-message option may well 578 be valuable in other circumstances. In those circumstances its scope 579 should be explicitly defined. 581 This option has two possible scopes when used with Bulk Leasequery, 582 depending on the context in which it appears. It refers to the 583 information in a single Leasequery reply if the value of the dhcp- 584 message-type is DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED. It refers to 585 the message stream related to an entire request if the value of the 586 dhcp-message-type is DHCPLEASEQUERYDONE. 588 The code for this option is 56. The length of this option is at least 589 3 octets. 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | option-code | option-len | left-number | middle-number | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | right-number | status-message (if any) ... . 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 option-code 56. 601 option-len 3 + length of status-message (which may be 0). 603 left-number NVT ASCII encoded characters representing the 604 middle-number base-10 value of the status code, taken 605 right-number from the table below. 607 status-message An optional NVT ASCII encoded text string 608 suitable for display to an end user, which 609 MUST NOT be null-terminated. It SHOULD 610 start with an NVT ASCII space. 612 Name status-code Description 613 ---- ----------- ----------- 614 Success 000 Success. Also signaled by absence of 615 a dhcp-message option. 617 UnspecFail 001 Failure, reason unspecified. 619 QueryTerminated 002 Indicates that the server is unable to 620 perform a query or has prematurely terminated 621 the query for some reason (which should be 622 communicated in the text message). 624 MalformedQuery 003 The query was not understood. 626 NotAllowed 004 The query or request was understood but was 627 not allowed in this context. 629 A dhcp-message option MAY appear in the options field of a DHCPv4 630 message. If the dhcp-message option does not appear, it is assumed 631 that the operation was successful. The dhcp-message option SHOULD 632 NOT appear in a message which is successful unless there is some text 633 string that needs to be communicated to the requestor. 635 7.2.3. base-time 637 The base-time option is the current time the message was created to 638 be sent by the DHCPv4 server to the requestor of the Bulk Leasequery. 639 This MUST be an absolute time. All of the other time based options in 640 the reply message are relative to this time, including the dhcp- 641 lease-time [RFC2132] and client-last-transaction-time [RFC4388]. 642 This time is in the context of the DHCPv4 server. 644 This is an integer in network byte order. 646 The code for this option is TBD1. The length of this option is 4 647 octets. 649 DHCPv4 Server 650 Code Len Base Time 651 +-----+-----+-----+-----+-----+-----+ 652 | TBD1| 4 | t1 | t2 | t3 | t4 | 653 +-----+-----+-----+-----+-----+-----+ 655 7.2.4. start-time-of-state 657 The start-time-of-state option allows the receiver to determine the 658 time at which the IP address transitioned into its current state. 660 This MUST NOT be an absolute time. This MUST NOT be an absolute 661 number of seconds since Jan 1, 1970. Instead, this MUST be an 662 integer number of seconds in the past from the time specified in the 663 base-time option in the same message that the IP address transitioned 664 into its current state. In the same way that the IP Address Lease 665 Time option (option 51) encodes a lease time which is a number of 666 seconds into the future from the time the message was sent, this 667 option encodes a value which is a number of seconds into the past 668 from the base-time option included in the same message. 670 This is an integer in network byte order. 672 The code for this option is TBD2. The length of this option is 4 673 octets. 675 Seconds in the past 676 Code Len from base-time 677 +-----+-----+-----+-----+-----+-----+ 678 | TBD2| 4 | t1 | t2 | t3 | t4 | 679 +-----+-----+-----+-----+-----+-----+ 681 7.2.5. query-start-time 683 The query-start-time option allows the requestor to specify a start 684 query time to the DHCPv4 server. If specified, only bindings that 685 have changed on or after the query-start-time should be included in 686 the response to the query. 688 This MUST be an absolute time. 690 This MUST be a time in the context of the DHCPv4 server. In the 691 absence of information to the contrary, the requestor SHOULD assume 692 that the time context of the DHCPv4 server is identical to the time 693 context of the requestor. 695 It SHOULD NOT be a time in the context of the requestor. 697 This is an integer in network byte order. 699 The code for this option is TBD3. The length of this option is 4 700 octets. 702 DHCPv4 Server 703 Code Len query-start-time 704 +-----+-----+-----+-----+-----+-----+ 705 | TBD3| 4 | t1 | t2 | t3 | t4 | 706 +-----+-----+-----+-----+-----+-----+ 708 7.2.6. query-end-time 710 The query-end-time option allows the requestor to specify an end 711 query time to the DHCPv4 server. If specified, only bindings that 712 have changed on or before the query-end-time should be included in 713 the response to the query. 715 This MUST be an absolute time. 717 This MUST be a time in the context of the DHCPv4 server. In the 718 absence of information to the contrary, the requestor SHOULD assume 719 that the time context of the DHCPv4 server is identical to the time 720 context of the requestor. 722 It SHOULD NOT be a time in the context of the requestor. 724 This is an integer in network byte order. 726 The code for this option is TBD4. The length of this option is 4 727 octets. 729 DHCPv4 Server 730 Code Len query-end-time 731 +-----+-----+-----+-----+-----+-----+ 732 | TBD4| 4 | t1 | t2 | t3 | t4 | 733 +-----+-----+-----+-----+-----+-----+ 735 7.2.7. dhcp-state 737 The dhcp-state option allows greater detail to be returned than 738 allowed by the DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types. 740 The code for this option is TBD6. The length of this option is 1 741 octet. 743 0 1 2 744 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | TBD6 | Length | State | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 TBD6 The option code. 751 Length The option length, 1 octet. 753 State The State of the IP address. 755 Value State 756 ----- ----- 757 1 AVAILABLE Address is available to local DHCPv4 server 758 2 ACTIVE Address is assigned to a DHCPv4 client 759 3 EXPIRED Lease has expired 760 4 RELEASED Lease has been released by DHCPv4 client 761 5 ABANDONED Server or client flagged address as unusable 762 6 RESET Lease was freed by some external agent 763 7 REMOTE Address is available to a remote DHCPv4 server 764 8 TRANSITIONING Address is moving between states 766 Note that some of these states may be transient and may not appear in 767 normal use. A DHCPv4 server MUST implement at least the AVAILABLE 768 and ACTIVE states, and SHOULD implement at least the ABANDONED and 769 RESET states. 771 The dhcp-state option SHOULD contain ACTIVE when it appears in a 772 DHCPLEASEACTIVE message. A DHCPv4 server MAY choose to not send a 773 dhcp-state option in a DHCPLEASEACTIVE message, and a requestor 774 SHOULD assume that the dhcp-state is ACTIVE if no dhcp-state option 775 appears in a DHCPLEASEACTIVE message. 777 The reference to local and remote relate to possible use in an 778 environment that includes multiple servers cooperating to provide an 779 increased availability solution. In this case, an IP address with 780 the state of AVAILABLE is available to the local server, while one 781 with the state of REMOTE is available to a remote server. Usually, 782 an IP address which is AVAILABLE on one server would be REMOTE on any 783 remote server. The TRANSITIONING state is also likely to be useful 784 in multiple server deployments, where sometimes one server must 785 interlock a state change with one or more other servers. Should a 786 Bulk Leasequery need to send information concerning the state of the 787 IP address during this period, it SHOULD use the TRANSITIONING state, 788 since the IP address is likely to be neither ACTIVE or AVAILABLE. 790 There is no requirement for the state of an IP address to transition 791 in a well defined way from state to state. To put this another way, 792 you cannot draw a simple state transition graph for the states of an 793 IP address and the requestor of a Leasequery MUST NOT depend on one 794 certain state always following a particular previous state. In 795 general, every state can (at times) follow every other state. 797 7.2.8. data-source 799 The data-source option contains information about the source of the 800 data in a DHCPLEASEACTIVE or a DHCPLEASEUNASSIGNED message. It is 801 used when there are two or more servers who might have information 802 about a particular IP address binding. Frequently two servers work 803 together to provide an increased availability solution for the DHCPv4 804 service, and in these cases, both servers will respond to Bulk 805 Leasequery requests for the same IP address. 807 The data contained in this option will allow an external process to 808 better discriminate between the information provided by each of the 809 servers servicing this IPv4 address. 811 The code for this option is TBD5. The length of this option is 1 812 octet. 814 0 1 2 815 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | TBD5 | Length | Flags | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 TBD5 The option code. 822 Length The option length, 1 octet. 824 Flags The Source information for this message. 826 0 1 2 3 4 5 6 7 827 +-+-+-+-+-+-+-+-+ 828 | MBZ |R| 829 +-+-+-+-+-+-+-+-+ 831 R: REMOTE flag 833 remote = 1 834 local = 0 836 MBZ: MUST BE ZERO (reserved for future use) 838 The REMOTE flag is used to indicate where the most recent change of 839 state (or other interesting change) concerning this IPv4 address took 840 place. If the value is local, then the change took place on the 841 server from which this message was transmitted. If the value is 842 remote, then the change took place on some other server, and was made 843 known to the server from which this message was transmitted. 845 If this option was requested and it doesn't appear, the the requestor 846 SHOULD consider that the data-source was local. 848 7.2.9. Virtual Subnet Selection Type and Information 850 All of the (sub)options defined in [VpnId] carry identical payloads, 851 consisting of a type and additional VSS (Virtual Subnet Selection) 852 information. The existing table is extended (see below) with a new 853 type 254 to allow specification of a type code which indicates that 854 all VPN's are to be used to process the Bulk Leasequery. 856 Type VSS Information format: 857 ---- ----------------------- 858 0 NVT ASCII VPN identifier 859 1 RFC2685 VPN-ID 860 2-253 Not Allowed 861 NEW -> 254 All VPN's (wildcard). 862 255 Global, default VPN. 864 7.3. Connection and Transmission Parameters 866 DHCPv4 servers that support Bulk Leasequery SHOULD listen for 867 incoming TCP connections on the DHCPv4 server port 67. 868 Implementations MAY offer to make the incoming port configurable, but 869 port 67 MUST be the default. Requestors SHOULD make TCP connections 870 to port 67, and MAY offer to make the destination server port 871 configurable. 873 This section presents a table of values used to control Bulk 874 Leasequery behavior, including recommended defaults. Implementations 875 MAY make these values configurable. However, configuring too-small 876 timeout values may lead to harmful behavior both to this application 877 as well as to other traffic in the network. As a result, timeout 878 values smaller than the default values are NOT RECOMMENDED. 880 Parameter Default Description 881 ------------------------------------------- 882 BULK_LQ_DATA_TIMEOUT 300 secs Bulk Leasequery data timeout 883 BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections 885 8. Requestor Behavior 887 8.1. Connecting and General Processing 889 A Requestor attempts to establish a TCP connection to a DHCPv4 Server 890 in order to initiate a Leasequery exchange. If the attempt fails, 891 the Requestor MAY retry. 893 If Bulk Leasequery is terminated prematurely by a DHCPLEASEQUERYDONE 894 with a dhcp-message status-code of QueryTerminated or by the failure 895 of the connection over which it was being submitted, the requestor 896 MAY retry the request after the creation of a new connection. 898 Messages from the DHCPv4 server come as multiple responses to a 899 single DHCPBULKLEASEQUERY message. Thus, each DHCPBULKLEASEQUERY 900 request MUST have a xid (transaction-id) unique on the connection on 901 which it is sent, and all of the messages which come as a response to 902 it all contain the same xid as the request. It is the xid which 903 allows the data-streams of two different DHCPBULKLEASEQUERY requests 904 to be demultiplexed by the requestor. 906 A requestor MAY send a DHCPBULKLEASEQUERY request to a DHCPv4 server 907 and immediately close the transmission side of its TCP connection, 908 and then read the resulting response messages from the DHCPv4 server. 909 This is not required, and the usual approach is to leave both sides 910 of the TCP connection up until at least the conclusion of the Bulk 911 Leasequery. 913 8.2. Forming a Bulk Leasequery 915 Bulk Leasequery is designed to create a connection which will 916 transfer the state of some subset (or possibly all) of the IP address 917 bindings from the DHCPv4 server to the requestor. The DHCPv4 server 918 will send all of the requested IPv4 address bindings across this 919 connection with minimal delay after it receives the request. In this 920 context, "all IP address binding information" means information about 921 all IPv4 addresses configured within the DHCPv4 server which meet the 922 specified query criteria. For some query criteria, this may include 923 IP address binding information for IP addresses which may not now 924 have or ever had have an association with a specific DHCPv4 client. 926 To form the Bulk query, a DHCPv4 request is constructed with a dhcp- 927 message-type of DHCPBULKLEASEQUERY. The query SHOULD have a dhcp- 928 parameter-request-list to inform the DHCPv4 server which DHCPv4 929 options are of interest to the requestor sending the 930 DHCPBULKLEASEQUERY message. The dhcp-parameter-request-list in a 931 DHCPBULKLEASEQUERY message SHOULD contain the codes for base-time, 932 dhcp-lease-time, start-time-of-state, and client-last-transaction- 933 time. 935 A DHCPBULKLEASEQUERY request is constructed of one primary query and 936 optionally one or more qualifiers for it. 938 The possible primary queries are listed below. Each 939 DHCPBULKLEASEQUERY request MUST contain only one of these primary 940 queries. 942 o Query by MAC address 944 In a Query by MAC address, the chaddr, htype, and hlen of the 945 DHCPv4 packet are filled in with the values requested. 947 o Query by Client-Id 949 In a Query by Client-Id, the dhcp-client-id option containing 950 the requested value is included in the DHCPBULKLEASEQUERY 951 request. 953 o Query by Remote-Id 955 In a Query by Remote-Id, the remote-id sub-option of the relay- 956 agent-information option containing the requested value is 957 included in the DHCPBULKLEASEQUERY request. 959 o Query by Relay-Id 961 In a Query by Relay-Id, the relay-id sub-option [RelayId] of the 962 relay-agent-information option containing the requested value is 963 included in the DHCPBULKLEASEQUERY request. 965 o Query for All Configured IP Addresses 967 A Query for All Configured IP addresses is signaled by the 968 absence of any other primary query. 970 There are three qualifiers which can be applied to any of the above 971 primary queries. These qualifiers can appear individually or 972 together in any combination, but only one of each can appear. 974 o Query Start Time 976 Inclusion of the query-start-time option specifies that only IP 977 address bindings which have changed on or after the time specified 978 in the query-start-time option should be returned. 980 o Query End Time 982 Inclusion of the query-end-time option specifies that only IP 983 address bindings which have changed on or before the time specified 984 in the query-end-time option should be returned. 986 o VPN Id 988 If no vpn-id option appears in the DHCPBULKLEASEQUERY, the default 989 VPN is used to search to satisfy the query specified by the 990 DHCPBULKLEASEQUERY. Using the vpn-id option [VpnId] allows the 991 requestor to specify a single VPN other than the default VPN. In 992 addition, the vpn-id option has been extended as part of this 993 document to allow specification that all configured VPN's be 994 searched in order to satisfy the query specified in the 995 DHCPBULKLEASEQUERY. 997 In all cases, any message returned from a DHCPBULKLEASEQUERY 998 request containing information about an IP address for other than 999 the default VPN MUST contain a vpn-id option in the message. 1001 Both of the query-start-time and query-end-time options (if they 1002 appear) MUST be in the time context of the DHCPv4 server to which the 1003 Bulk Leasequery is directed. In the absence of information to the 1004 contrary, the requestor SHOULD assume that the time context on the 1005 DHCPv4 server is identical to the time context on the requestor. In 1006 the event that previous operations have determined that the time 1007 context on the DHCPv4 server to which the Bulk Leasequery is 1008 addressed differs from the time context of the requestor, the time 1009 context of the DHCPv4 server MUST be used. 1011 Use of the query-start-time or the query-end-time options or both can 1012 serve to reduce the amount of data transferred over the TCP 1013 connection by a considerable amount. 1015 If the TCP connection becomes blocked or stops being writeable while 1016 the requestor is sending its query, the requestor SHOULD be prepared 1017 to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this 1018 recommendation to allow requestors to control the period of time they 1019 are willing to wait before abandoning a connection, independent of 1020 notifications from the TCP implementations they may be using. 1022 8.3. Processing Bulk Replies 1024 The requestor attempts to read a DHCPv4 Leasequery message from the 1025 TCP connection. If the TCP connection stops delivering reply data (if 1026 the connection stops being readable), the Requestor SHOULD be 1027 prepared to terminate the connection after BULK_LQ_DATA_TIMEOUT, and 1028 MAY begin retry processing if configured to do so. 1030 A single Bulk Leasequery can and usually will result in a large 1031 number of replies. The requestor MUST be prepared to receive more 1032 than one reply with an xid matching a single DHCPBULKLEASEQUERY 1033 message from a single DHCPv4 server. If the xid in the received 1034 message does not match an outstanding DHCPBULKLEASEQUERY message, the 1035 requestor MUST close the TCP connection. 1037 If a response message does not contain a DHCPv4 server-identifier 1038 option (option 54), then the server-identifier option from the 1039 previous message should be used. Thus, the DHCPv4 server MUST send 1040 the server-identifier option in the first response message, and MAY 1041 send it in subsequent response message for the same request. 1043 The response messages generated by a DHCPBULKLEASEQUERY request are: 1045 o DHCPLEASEACTIVE 1047 A Bulk Leasequery will generate DHCPLEASEACTIVE messages 1048 containing binding data for bound IP addresses which match the 1049 specified query criteria. The IP address which is bound to a 1050 DHCPv4 client will appear in the ciaddr field of the 1051 DHCPLEASEACTIVE message. The message may contain a non-zero 1052 chaddr, htype, and hlen and possibly additional options. 1054 o DHCPLEASEUNASSIGNED 1056 Some queries will also generate DHCPLEASEUNASSIGNED messages for 1057 IP addresses which match the query criteria. These messages 1058 indicate that the IP address is managed by the DHCPv4 server but 1059 is not currently bound to any DHCPv4 client. The IP address to 1060 which this message refers will appear in the ciaddr field of the 1061 DHCPLEASEUNASSIGNED message. A DHCPLEASEUNASSGINED message MAY 1062 also contain information about the last DHCPv4 client that was 1063 bound to this IP address. The message may contain a non-zero 1064 chaddr, htype, and hlen and possibly additional options. 1066 o DHCPLEASEQUERYDONE 1068 A response of DHCPLEASEQUERYDONE indicates that the server has 1069 completed its response to the query, and that no more messages 1070 will be sent in response to the DHCPBULKLEASEQUERY. More details 1071 will sometimes be available in the received dhcp-message option 1072 in the DHCPLEASEQUERYDONE message. If there is no dhcp-message 1073 option in the DHCPLEASEQUERYDONE message, then the query 1074 completed successfully. 1076 Note that a query which returned no data, that is a 1077 DHCPBULKLEASEQUERY request followed by a DHCPLEASEQUERYDONE 1078 response, is considered a successful query in that no errors 1079 occurred during the processing. It is not considered an error 1080 to have no information to return to a DHCPBULKLEASEQUERY 1081 request. 1083 The DHCPLEASEUNKNOWN message MUST NOT appear in a response to a Bulk 1084 Leasequery. 1086 The requestor MUST NOT assume that there is any inherent order in the 1087 IP address binding information that is sent in response to a 1088 DHCPBULKLEASEQUERY. While the base-time will tend to increase 1089 monotonically (as it is the current time on the DHCPv4 server), the 1090 actual time that any IP address binding information changed is 1091 unrelated to the base-time. 1093 The DHCPLEASEQUERYDONE message always ends a successful 1094 DHCPBULKLEASEQUERY request and any unsuccessful DHCPBULKLEASEQUERY 1095 requests not terminated by a dropped connection. After receiving 1096 DHCPLEASEQUERYDONE from a server, the requestor MAY close the TCP 1097 connection to that server if no other DHCPBULKLEASEQUERY is 1098 outstanding on that TCP connection. 1100 The DHCPv4 Leasequery protocol [RFC4388] uses the associated-ip 1101 option as an indicator that multiple bindings were present in 1102 response to a single DHCPv4 client based query. For Bulk Leasequery, 1103 a separate message is returned for each binding, and so the 1104 associated-ip option is not used. 1106 8.4. Processing Time Values in Leasequery messages 1108 Bulk Leasequery requests may be made to a DHCPv4 server whose 1109 absolute time may not be synchronized with the local time of the 1110 requestor. Thus, there are at least two time contexts in even the 1111 simplest Bulk Leasequery response, and in the situation where 1112 multiple DHCPv4 servers are queried, the situation becomes even more 1113 complex. 1115 If the requestor of a Bulk Leasequery is saving the data returned in 1116 some form, it has a requirement to store a variety of time values, 1117 and some of these will be time in the context of the requestor and 1118 some will be time in the context of the DHCPv4 server. 1120 When receiving a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message from 1121 the DHCPv4 server, the message will contain a base-time option. The 1122 time contained in this base-time option is in the context of the 1123 DHCPv4 server. As such, it is an ideal time to save and use as input 1124 to a DHCPBULKLEASEQUERY in the query-start-time or query-end-time 1125 options, should the requestor need to ever issue a DHCPBULKLEASEQUERY 1126 message using those options as part of a later query. 1128 In addition to saving the base-time for possible future use in a 1129 query-start-time option, the base-time is used as part of the 1130 conversion of the other times in the Leasequery message to values 1131 which are meaningful in the context of the requestor. 1133 The requestor SHOULD use the base-time values received in Bulk 1134 Leasequery messages to develop a value which represents the clock 1135 skew between the DHCPv4 server and the requestor. In theory this 1136 clock skew would simply be the difference between the first base-time 1137 value and the current time on the requestor when the message 1138 containing the base-time value was received. However, there may be 1139 transmission delays at the beginning or end or along the TCP 1140 connection, and so the actual clock skew may not be the same as any 1141 individual difference between a base-time value and the current time 1142 of the requestor. 1144 Moreover, in systems whose clocks are synchronized, perhaps using 1145 NTP, the clock skew will usually be zero, which is not only 1146 acceptable, but desired. 1148 The requestor SHOULD smooth the value which it uses as the clock skew 1149 by continuously examining the instantaneous value developed from the 1150 base-time of each message received from a DHCPv4 server and using 1151 this instantaneous value of clock skew to make small adjustments to 1152 the existing value of the clock skew. Thus, the clock skew will vary 1153 only slowly and one slow message will not completely distort a large 1154 number of future time calculations. 1156 Given the value of the clock skew on the requestor, the requestor 1157 SHOULD bring all of the times in the DHCPLEASEACTIVE and 1158 DHCPLEASEUNASSIGNED messages into the context of the requestor. 1159 Except for the base-time value, the times in the Leasequery message 1160 are all relative to the base-time. These relative times SHOULD first 1161 be converted into absolute times in the context of the DHCPv4 server 1162 using the base-time value. Once this stage is complete, the absolute 1163 times that result SHOULD be brought into the context of the requestor 1164 by applying the calculated clock skew to each of the absolute times. 1166 After all of this processing, the times are in the context of the 1167 requestor. 1169 An alternative might appear to be to leave all of the times in the 1170 context of the DHCPv4 server, and if the requestor is dealing with 1171 only one DHCPv4 server at a time, this is an accurate and effective 1172 approach. However, if the requestor is dealing with DHCPLEASEACTIVE 1173 and DHCPLEASEUNASSIGNED messages from two or more different DHCPv4 1174 servers, then in order to make any sense of them, the times from each 1175 server SHOULD be converted into the time of the requestor. 1177 Since various transmission and processing delays may occur, a time 1178 converted into the requestor's context may be accurate to only a few 1179 seconds, at best. This is rarely an issue in the larger context of 1180 the use of the information derived from a Bulk Leasequery request. 1181 However, time comparison is an important factor in determining which 1182 update to the address binding information for a particular IPv4 1183 address is the most recent and therefore worth remembering. The next 1184 section discusses the issue of comparing two updates in some detail, 1185 but a key aspect of that comparison is a comparison of the times in 1186 the two messages. 1188 The requestor SHOULD consider times converted into its context as 1189 effectively equivalent if they are within a small number of seconds 1190 of each other. The precise number depends on the particular 1191 implementation involved, but 4 to 8 seconds is probably a good 1192 starting point. Thus, if two times are 3 seconds apart after 1193 conversion to the requestor's context they should be considered the 1194 same for purposes of comparison with each other. 1196 8.5. Querying Multiple Servers 1198 A Bulk Leasequery requestor MAY be configured to attempt to connect 1199 to and query from multiple DHCPv4 servers in parallel. The DHCPv4 1200 Leasequery specification [RFC4388] includes a discussion about 1201 reconciling binding data received from multiple DHCPv4 servers. 1203 In addition, the algorithm in the Section 8.6 should be used. 1205 8.6. Making Sense Out of Multiple Responses Concerning a Single IPv4 1206 Address 1208 Any requestor of an Bulk Leasequery MUST be prepared for multiple 1209 responses to arrive for a particular IPv4 address from multiple 1210 different DHCPv4 servers. The following algorithm SHOULD be used to 1211 decide if the information just received is more up to date (i.e., 1212 better) than the best existing information. In the discussion below, 1213 the information that is received from a DHCPv4 server about a 1214 particular IPv4 address is termed a "record". The times used in the 1215 algorithm below SHOULD have been converted into the requestor's 1216 context and the time comparisons SHOULD be performed in a manner 1217 consistent with the information in Section 8.4. 1219 o If both the existing and the new record contain client-last- 1220 transaction-time information, the record with the later client- 1221 last-transaction-time is considered better. 1223 o If one of the records contains client-last-transaction-time 1224 information and the other one doesn't, then compare the client- 1225 last-transaction-time in the record that contains it against the 1226 other record's start-time-of-state. The record with the later 1227 time is considered better. 1229 o If neither record contains client-last-transaction-time 1230 information, compare their start-time-of-state information. The 1231 record with the later start-time-of-state is considered better. 1233 o If none of the comparisons above yield a clear answer as to 1234 which record is later, then compare the value of the REMOTE flag 1235 from the data-source option for each record. 1237 If the values of the REMOTE flag are different between the two 1238 records, the record with the REMOTE flag value of local is 1239 considered better. 1241 The above algorithm does not necessarily determine which record is 1242 better. In the event that the algorithm is inconclusive with regard 1243 to a record which was just received by the requestor, the requestor 1244 SHOULD use additional information in the two records to make a 1245 determination as to which record is better. 1247 8.7. Multiple Queries to a Single Server over One Connection 1249 Bulk Leasequery requestors may need to make multiple queries in order 1250 to recover binding information. A requestor MAY use a single 1251 connection to issue multiple queries to a server willing to support 1252 them. Each query MUST have a unique xid. 1254 A server MAY process more than one query at a time. A server that 1255 does not support more than one query at a time on a single connection 1256 MUST return a DHCPLEASEQUERYDONE message containing a dhcp-message 1257 option with a status-code of NotAllowed to the unsupported queries. 1258 Alternatively, a server that does not support more than one query at 1259 a time on a single connection MAY chose to simply read one query and 1260 only read any subsequent queries after processing of the current 1261 query is complete. 1263 A server that is willing to do so MAY interleave replies to the 1264 multiple queries within the stream of reply messages it sends. 1265 Requestors need to be aware that replies for multiple queries may be 1266 interleaved within the stream of reply messages. Requestors that are 1267 not able to process interleaved replies (based on xid) MUST NOT send 1268 more than one query over a single connection prior to the completion 1269 of the previous query. Requestors should be aware that servers are 1270 not required to process more than one query over a connection at a 1271 time, and that servers are likely to limit the rate at which they 1272 process queries from any one requestor. 1274 8.7.1. Example 1276 This example illustrates what a series of queries and responses might 1277 look like. This is only an example - there is no requirement that 1278 this sequence must be followed, or that requestors or servers must 1279 support parallel queries. 1281 In the example session, the client sends four queries after 1282 establishing a connection. Query 1 returns no results; query 2 1283 returns 3 messages and the stream of replies concludes before the 1284 client issues any new query. Query 3 and query 4 overlap, and the 1285 server interleaves its replies to those two queries. 1287 Requestor Server 1288 --------- ------ 1289 DHCPBULKLEASEQUERY xid 1 -----> 1290 <----- DHCPLEASEQUERYDONE xid 1 1291 DHCPBULKLEASEQUERY xid 2 -----> 1292 <----- DHCPLEASEACTIVE xid 2 1293 <----- DHCPLEASEACTIVE xid 2 1294 <----- DHCPLEASEACTIVE xid 2 1295 <----- DHCPLEASEQUERYDONE xid 2 1296 DHCPBULKLEASEQUERY xid 3 -----> 1297 DHCPBULKLEASEQUERY xid 4 -----> 1298 <----- DHCPLEASEACTIVE xid 4 1299 <----- DHCPLEASEACTIVE xid 4 1300 <----- DHCPLEASEACTIVE xid 3 1301 <----- DHCPLEASEACTIVE xid 4 1302 <----- DHCPLEASEUNASSIGNED xid 3 1303 <----- DHCPLEASEACTIVE xid 4 1304 <----- DHCPLEASEACTIVE xid 3 1305 <----- DHCPLEASEQUERYDONE xid 3 1306 <----- DHCPLEASEACTIVE xid 4 1307 <----- DHCPLEASEQUERYDONE xid 4 1309 8.8. Closing Connections 1311 Either the requestor or DHCPv4 server MAY close the TCP connection at 1312 any time. The requestor MAY choose to retain the connection if it 1313 intends to issue additional queries or if other queries are currently 1314 using the connection. Note that this requestor behavior does not 1315 guarantee that the connection will be available for additional 1316 queries: the server might decide to close the connection based on its 1317 own configuration. 1319 9. Server Behavior 1321 9.1. Accepting Connections 1323 Servers that implement DHCPv4 Bulk Leasequery listen for incoming TCP 1324 connections. Port numbers are discussed in Section 7.3. Servers 1325 MUST be able to limit the number of currently accepted and active 1326 connections. The value BULK_LQ_MAX_CONNS SHOULD be the default; 1327 implementations MAY permit the value to be configurable. Connections 1328 SHOULD be accepted and, if the number of connections is over 1329 BULK_LQ_MAX_CONNS, they SHOULD be closed immediately. 1331 Servers MAY restrict Bulk Leasequery connections and 1332 DHCPBULKLEASEQUERY messages to certain requestors. Connections not 1333 from permitted requestors SHOULD be closed immediately, to avoid 1334 server connection resource exhaustion. Servers MAY restrict some 1335 requestors to certain query types. Servers MAY reply to queries that 1336 are not permitted with the DHCPLEASEQUERYDONE message with a dhcp- 1337 message status of NotAllowed, or MAY simply close the connection. 1339 If the TCP connection becomes blocked while the server is accepting a 1340 connection or reading a query, it SHOULD be prepared to terminate the 1341 connection after an BULK_LQ_DATA_TIMEOUT. We make this 1342 recommendation to allow servers to control the period of time they 1343 are willing to wait before abandoning an inactive connection, 1344 independent of the TCP implementations they may be using. 1346 9.2. Replying to a Bulk Leasequery 1348 If the connection becomes blocked while the server is attempting to 1349 send reply messages, the server SHOULD be prepared to terminate the 1350 TCP connection after BULK_LQ_DATA_TIMEOUT. 1352 Every Bulk Leasequery request MUST be terminated by sending a final 1353 DHCPLEASEQUERYDONE message if such a message can be sent. The 1354 DHCPLEASEQUERYDONE message MUST have a dhcp-message status if the 1355 termination was other than successful, and SHOULD NOT contain a 1356 dhcp-message status if the termination was successful. 1358 If the DHCPv4 server encounters an error during processing of the 1359 DHCPBULKLEASEQUERY message, either during initial processing or later 1360 during the message processing, it SHOULD send a DHCPLEASEQUERYDONE 1361 containing a status dhcp-message option. It MAY close the connection 1362 after this error is signaled, but that is not required. 1364 If the server does not find any bindings satisfying a query, it MUST 1365 send a DHCPLEASEQUERYDONE. It SHOULD NOT include a dhcp-message 1366 option with a Success status unless there is a useful string to 1367 include in the dhcp-message option. Otherwise, the server sends each 1368 binding's data in a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message. 1370 The response to a DHCPBULKLEASEQUERY may involve examination of 1371 multiple DHCPv4 IP address bindings maintained by the DHCPv4 server. 1372 The Bulk Leasequery protocol does not require any ordering of the IP 1373 addresses returned in DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED 1374 messages. 1376 A Bulk Leasequery response MUST contain no more than one message for 1377 each IP address configured in the DHCPv4 server. In addition, a Bulk 1378 Leasequery may well take significant time between the beginning and 1379 end of the processing of all of the messages required to satisfy the 1380 Bulk Leasequery query. During this time, the state of some of the IP 1381 addresses sent early in the response may change prior to the 1382 completion of the entire response to the Bulk Leasequery. This is 1383 normal and expected -- there is no requirement for the entire 1384 response to a Bulk Leasequery to represent an instantaneous snapshot 1385 of the state of the IP address bindings of a DHCPv4 server. Quite 1386 the contrary -- as the cursor moves through the IP addresses in 1387 whatever order is convenient to the DHCPv4 server, the state of IP 1388 addresses already examined can change and a DHCPv4 server MUST NOT 1389 try to examine IP addresses already scanned in an attempt to "keep 1390 up" with the ongoing state changes of all of the IP addresses. To do 1391 so would make it difficult to meet the requirement to send only one 1392 message per IP address in response to a Bulk Leasequery and would 1393 also make it difficult to know when to finish the Bulk Leasequery. 1395 If the ciaddr, yiaddr, or siaddr is non-zero in a DHCPBULKLEASEQUERY 1396 request, the request must be terminated immediately by a 1397 DHCPLEASEQUERYDONE message with a dhcp-message status of 1398 MalformedQuery. 1400 Any DHCPBULKLEASEQUERY which has more than one of the following 1401 primary query types specified MUST be terminated immediately by a 1402 DHCPLEASEQUERYDONE message with a dhcp-message status code of 1403 NotAllowed. 1405 The allowable queries in a DHCPBULKLEASEQUERY message are processed 1406 as follows. Note that the descriptions of the primary queries below 1407 must be constrained by the actions of any of the three qualifiers 1408 described subsequently as well. 1410 The following table discusses how to process the various queries. 1411 For information on how to identify the query, see the information in 1412 Section 8.2. 1414 o Query by MAC address 1416 Every IP address that has a current binding to a DHCPv4 client 1417 matching the chaddr, htype, and hlen in the DHCPBULKLEASEQUERY 1418 request MUST be returned in a DHCPLEASEACTIVE message. 1420 o Query by Client-Id 1422 Every IP address that has a current binding to a DHCPv4 client 1423 matching the client-id option in the DHCPBULKLEASEQUERY request 1424 MUST be returned in a DHCPLEASEACTIVE message. 1426 o Query by Remote-Id 1428 Every IP address that has a current binding to a DHCPv4 client 1429 matching the remote-id sub-option of the relay-agent-information 1430 option in the DHCPBULKLEASEQUERY request MUST be returned in a 1431 DHCPLEASEACTIVE message. 1433 o Query by Relay-Id 1435 Every IP address that has a current binding to a DHCPv4 client 1436 matching the relay-id sub-option of the relay-agent-information 1437 option in the DHCPBULKLEASEQUERY request MUST be returned in a 1438 DHCPLEASEACTIVE message. 1440 o Query for All Configured IP Addresses 1442 A Query for All Configured IP addresses is signaled by the 1443 absence of any other primary query. That is, if there is no 1444 value in the chaddr, hlen, htype, no client-id option, no 1445 remote-id sub-option or relay-id sub-option of the relay-agent- 1446 information option, then the request is a query for information 1447 concerning all configured IP addresses. In this case, every 1448 configured IP address that has a current binding to a DHCPv4 1449 client MUST be returned in a DHCPLEASEACTIVE message. In 1450 addition, every configured IP address that does not have a 1451 current binding to a DHCPv4 client MUST be returned in a 1452 DHCPLEASEUNASSIGNED message. 1454 In this form of query, each configured IP address MUST be 1455 returned at most one time. If the absence of qualifiers 1456 restricting the number of IP addresses returned, every 1457 configured IP address MUST be returned exactly once. 1459 There are three qualifiers that can be applied to any of the above 1460 primary queries. These qualifiers can appear individually or 1461 together in any combination, but only one of each can appear. 1463 o Query Start Time 1465 If a query-start-time option appears in the DHCPBULKLEASEQUERY 1466 request, only IP address bindings that have changed on or after the 1467 time specified in the query-start-time option should be returned. 1469 o Query End Time 1471 If a query-end-time option appears in the DHCPBULKLEASEQUERY 1472 request, only IP address bindings that have changed on or before 1473 the time specified in the query-end-time option should be returned. 1475 o VPN Id 1477 If no vpn-id option appears in the DHCPBULKLEASEQUERY, the default 1478 VPN is used to satisfy the query. A vpn-id option [VpnId] value 1479 other than the wildcard value (254) allows the requestor to specify 1480 a single VPN other than the default VPN. In addition, the vpn-id 1481 option has been extended as part of this document to allow 1482 specification of a type 254 which indicates that all configured 1483 VPN's be searched in order to satisfy the primary query. 1485 In all cases, if the information returned in a DHCPLEASEACTIVE or 1486 DHCPLEASEUNASSIGNED message is for a VPN other than the default, a 1487 vpn-id option MUST appear in the packet. 1489 The query-start-time and query-end-time qualifiers are used to 1490 constrain the amount of data returned by a Bulk Leasequery request by 1491 returning only IP addresses whose address bindings have changed in 1492 some way during the time window specified by the query-start-time and 1493 query-end-time. 1495 A DHCPv4 server SHOULD consider an address binding to have changed 1496 during a specified time window if either the client-last- 1497 transaction-time or the start-time-of-state of the address binding 1498 changed during that time window. 1500 A DHCPv4 server MAY always compare the address binding information 1501 for an IP address against a time window if it follows the following 1502 guidelines. If there is no query-start-time, then the DHCPv4 server 1503 MUST assume the query-start-time is equivalent to a time prior to any 1504 time that resides in any IP address binding. If there is no query- 1505 end-time, the DHCPv4 server MUST assume that the query-end-time is 1506 equivalent to a time that is later than any time that resides in any 1507 IP address binding. 1509 Even if the query-start-time or query-end-time option value is being 1510 used to limit the amount of data flow from the DHCPv4 server to the 1511 requestor, there is no requirement placed on the DHCPv4 server to 1512 return address binding data in any order and certainly not in any 1513 order based on time. 1515 When the DHCPv4 server has no additional information to send to the 1516 requestor, it will send a DHCPLEASEQUERYDONE message. 1518 9.3. Building a Single Reply for Bulk Leasequery 1520 The DHCPv4 Leasequery [RFC4388] specification describes the initial 1521 construction of DHCPLEASEQUERY reply messages using the 1522 DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types in Section 1523 6.4.2. All of the reply messages in Bulk Leasequery are similar to 1524 the reply messages for an IP address query. Message transmission and 1525 framing for TCP is described in this document in Section 7.1. 1527 [RFC2131] and [RFC4388] specify that every response message MUST 1528 contain the server-identifier option. However, that option will be 1529 the same for every response from a particular DHCPBULKLEASEQUERY 1530 request. Thus, the DHCPv4 server MUST include the server-identifier 1531 option in the first message sent in response to a DHCPBULKLEASEQUERY. 1532 It MAY include the server-identifier in later messages as well, but 1533 there is no requirement for it to do so. 1535 The message type of DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED is based 1536 on the value of the dhcp-state option. If the dhcp-state option 1537 value is ACTIVE, then the message type is DHCPLEASEACTIVE, otherwise 1538 the message type is DHCPLEASEUNASSIGNED. 1540 In addition to the basic message construction described in [RFC4388], 1541 the following guidelines exist: 1543 1. If the dhcp-state option code appears in the dhcp-parameter- 1544 request-list, the DHCPv4 server SHOULD include a dhcp-state 1545 option whose value corresponds most closely to the state held 1546 by the DHCPv4 server for the IP address associated with this 1547 reply. If the state is ACTIVE and the message being returned 1548 is DHCPLEASEACTIVE, then the DHCPv4 server MAY choose to not 1549 send the dhcp-state option. The requestor SHOULD assume that 1550 any DHCPLEASEACTIVE message arriving without a requested dhcp- 1551 state option has a dhcp-state of ACTIVE. 1553 2. If the base-time option code appears in the dhcp-parameter- 1554 request-list, the DHCPv4 server MUST include a base-time 1555 option, which is the current time in the DHCPv4 server's 1556 context and the time from which the start-time-of-state, dhcp- 1557 lease-time, client-last-transaction-time, and other duration- 1558 style times are based upon. 1560 3. If the start-time-of-state option code appears in the dhcp- 1561 parameter-request-list, the DHCPv4 server MUST include a 1562 start-time-of-state option whose value represents the time at 1563 which the dhcp-state option's state became valid. 1565 4. If the dhcp-lease-time option code appears in the dhcp- 1566 parameter-request-list, the DHCPv4 server MUST include a dhcp- 1567 lease-time option for any state that has a time-out value 1568 associated with it. In the [RFC4388] Leasequery, the dhcp- 1569 lease-time option appears only in a DHCPLEASEACTIVE message. 1570 Thus, the EXPIRED state, which is sent in a DHCPLEASEUNASSIGNED 1571 message, would have a dhcp-lease-time option in the message if 1572 the EXPIRED state represented a grace-period and would be 1573 changed into the FREE state after the expiration of the grace- 1574 period. 1576 5. If the data-source option code appears in the dhcp-parameter- 1577 request-list, the DHCPv4 server MUST include the data-source 1578 option in any situation where any of the bits would be non- 1579 zero. Thus, in the absence of the data-source option, the 1580 assumption is that all of the flags were zero. 1582 6. If the client-last-transaction-time option code appears in the 1583 dhcp-parameter-request-list, The DHCPv4 server MUST include the 1584 client-last-transaction-time option in any situation where the 1585 information is available. 1587 7. If there is a dhcp-parameter-request-list in the initial 1588 DHCPBULKLEASEQUERY request, then it should be used for all of 1589 the replies generated by that request. Some options can be 1590 sent from a DHCPv4 client to the server or from the DHCPv4 1591 server to a DHCPv4 client. Option 125 is such an option. If 1592 the option code for one of these options appears in the dhcp- 1593 parameter-request-list, it SHOULD result in returning the value 1594 of the option sent by the DHCPv4 client to the server if one 1595 exists. 1597 Note that there may be other requirements for a reply to a 1598 DHCPBULKLEASEQUERY request discussed in Section 9.2. 1600 9.4. Multiple or Parallel Queries 1602 As discussed in Section 8.3, requestors may want to leverage an 1603 existing connection if they need to make multiple queries. Servers 1604 MAY support reading and processing multiple queries from a single 1605 connection. A server MUST NOT read more query messages from a 1606 connection than it is prepared to process simultaneously. 1608 This MAY be a feature that is administratively controlled. Servers 1609 that are able to process queries in parallel SHOULD offer 1610 configuration that limits the number of simultaneous queries 1611 permitted from any one requestor, in order to control resource use if 1612 there are multiple requestors seeking service. 1614 9.5. Closing Connections 1616 The server MAY close its end of the TCP connection after sending its 1617 last message, a DHCPLEASEQUERYDONE message in response to a query. 1618 Alternatively, the server MAY retain the connection and wait for 1619 additional queries from the requestor. The server SHOULD be prepared 1620 to limit the number of connections it maintains, and SHOULD be 1621 prepared to close idle connections to enforce the limit. 1623 The server MUST close its end of the TCP connection if it encounters 1624 an error sending data on the connection. The server MUST close its 1625 end of the TCP connection if it finds that it has to abort an in- 1626 process request. A server aborting an in-process request SHOULD 1627 attempt to signal that to its requestors by using the QueryTerminated 1628 status code in the dhcp-message option in a DHCPLEASEQUERYDONE 1629 message, including a message string indicating details of the reason 1630 for the abort. If the server detects that the requesting end of the 1631 connection has been closed, the server MUST close its end of the 1632 connection after it has finished processing any outstanding requests. 1634 The server MUST send a DHCPLEASEQUERYDONE message at the end of the 1635 data returned from a Bulk Leasequery request. 1637 10. Security Considerations 1639 The "Security Considerations" section of [RFC2131] details the 1640 general threats to DHCPv4. The DHCPv4 Leasequery specification 1641 [RFC4388] describes recommendations for the Leasequery protocol, 1642 especially with regard to authentication of LEASEQUERY messages, 1643 mitigation of packet-flooding DOS attacks, and restriction to trusted 1644 requestors. 1646 The use of TCP introduces some additional concerns. Attacks that 1647 attempt to exhaust the DHCPv4 server's available TCP connection 1648 resources, such as SYN flooding attacks, can compromise the ability 1649 of legitimate requestors to receive service. Malicious requestors 1650 who succeed in establishing connections, but who then send invalid 1651 queries, partial queries, or no queries at all also can exhaust a 1652 server's pool of available connections. We recommend that servers 1653 offer configuration to limit the sources of incoming connections, 1654 that they limit the number of accepted connections and the number of 1655 in-process queries from any one connection, and that they limit the 1656 period of time during which an idle connection will be left open. 1658 11. IANA Considerations 1660 IANA is requested to assign the following new values for this 1661 document. See Section 7.2 for details. 1663 1. A dhcp-message-type of 14 for DHCPBULKLEASEQUERY. 1665 2. A dhcp-message-type of 15 for DHCPLEASEQUERYDONE. 1667 3. An option code of TBD1 for base-time. 1669 4. An option code of TBD2 for start-time-of-state. 1671 5. An option code of TBD3 for query-start-time. 1673 6. An option code of TBD4 for query-end-time. 1675 7. An option code of TBD5 for data-source. 1677 8. An option code of TBD6 for dhcp-state. 1679 9. Values for dhcp-state: 1681 State 1682 ----- 1683 1 AVAILABLE 1684 2 ACTIVE 1685 3 EXPIRED 1686 4 RELEASED 1687 5 ABANDONED 1688 6 RESET 1689 7 REMOTE 1690 8 TRANSITIONING 1692 10.Values for status code in a constrained dhcp-message option 1693 (option 53): 1695 Name status-code 1696 ---- ----------- 1697 Success 000 1698 UnspecFail 001 1699 QueryTerminated 002 1700 MalformedQuery 003 1701 NotAllowed 004 1703 11.Additional type field values for the Virtual Subnet Selection 1704 Type and Information [VpnId]: 1706 Type VSS Information format: 1708 0 NVT ASCII VPN identifier 1709 1 RFC2685 VPN-ID 1710 2-253 Not Allowed 1711 NEW -> 254 All VPN's. (wildcard) 1712 255 Global, default VPN. 1714 12. Acknowledgements 1716 This draft is a collaboration between the authors of draft-dtv-dhc- 1717 dhcpv4-bulk-leasequery-00.txt and draft-kkinnear-dhc-dhcpv4-bulk- 1718 leasequery-00.txt. Both documents acknowledged that significant text 1719 as well as important ideas were borrowed in whole or in part from the 1720 DHCPv6 Bulk Leasequery RFC, [DHCPv6Bulk] written by Mark Stapp. 1721 Further suggestions and improvements were made by participants in the 1722 DHC working group, including Alfred Hoenes. 1724 13. References 1726 13.1. Normative References 1728 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1729 Requirement Levels", RFC 2119, March 1997. 1731 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 1732 March 1997. 1734 [RFC2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 1735 Extensions", RFC 2132, March 1997. 1737 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 1738 3046, January 2001. 1740 [RFC4388] Woundy, R., K. Kinnear, "Dynamic Host Configuration 1741 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 1743 [RelayId] Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption", 1744 draft-ietf-dhc-relay-id-suboption-06.txt, (work in progress) 1745 December 2008. 1747 [VpnId] Kinnear, K., R. Johnson, M. Stapp and J. Kumarasamy, "Virtual 1748 Subnet Selection Options for DHCPv4 and DHCPv6" draft-ietf-dhc- 1749 vpn-option-09.txt, (work in progress) July 2008. 1751 13.2. Informative References 1753 [RFC951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC 1754 951, September 1985. 1756 [RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap 1757 Protocol", RFC 1542, October 1993. 1759 [RFC4614] Duke, M., R. Braden, W. Eddy, and E. Blanton, "A Roadmap 1760 for Transmission Control Protocol (TCP) Specification Documents", 1761 RFC 4614, September 2006. 1763 [DHCPv6Bulk] Stapp, M., "DHCPv6 Bulk Leasequery", draft-ietf-dhc- 1764 dhcpv6-bulk-leasequery-06.txt, (work in progress) January 2009. 1766 Authors' Addresses 1768 Kim Kinnear 1769 Cisco Systems 1770 1414 Massachusetts Ave. 1771 Boxborough, Massachusetts 01719 1773 Phone: (978) 936-0000 1775 EMail: kkinnear@cisco.com 1777 Bernie Volz 1778 Cisco Systems 1779 1414 Massachusetts Ave. 1780 Boxborough, Massachusetts 01719 1782 Phone: (978) 936-0000 1784 EMail: volz@cisco.com 1786 Neil Russell 1787 Cisco Systems 1788 1414 Massachusetts Ave. 1789 Boxborough, Massachusetts 01719 1790 Phone: (978) 936-0000 1792 EMail: nrussell@cisco.com 1794 Mark Stapp 1795 Cisco Systems 1796 1414 Massachusetts Ave. 1797 Boxborough, Massachusetts 01719 1799 Phone: (978) 936-0000 1801 EMail: mjs@cisco.com 1803 Ramakrishna Rao DTV 1804 Infosys Technologies Ltd. 1805 44 Electronics City, Hosur Road 1806 Bangalore 560 100 1807 India 1809 EMail: ramakrishnadtv@infosys.com 1810 URI: http://www.infosys.com/ 1812 Bharat Joshi 1813 Infosys Technologies Ltd. 1814 44 Electronics City, Hosur Road 1815 Bangalore 560 100 1816 India 1818 EMail: bharat_joshi@infosys.com 1819 URI: http://www.infosys.com/ 1821 Pavan Kurapati 1822 Infosys Technologies Ltd. 1823 44 Electronics City, Hosur Road 1824 Bangalore 560 100 1825 India 1827 EMail: pavan_kurapati@infosys.com 1828 URI: http://www.infosys.com/ 1830 Appendix -- Why a New Leasequery is Required 1832 The three existing query types supported by [RFC4388] do not provide 1833 effective and efficient antispoofing for the scenario discussed in 1834 Section 3. 1836 o Query by Client Identifier 1838 Query by Client Identifier is not possible because the access 1839 concentrator would need to glean the client-identifier. This is not 1840 possible since if we are using a Leasequery, it is because the 1841 gleaned information was lost. On the other hand, we can query by 1842 client-identifier when the client sends a DHCPv4 request, but then 1843 there may not be any need for Leasequery as such -- regular gleaning 1844 may be enough. 1846 o Query by IP Address 1848 [RFC4388] suggests that it is preferable to use Query by IP Address 1849 when getting downstream traffic. 1851 Query by IP address is not very useful because downstream traffic may 1852 not exist for the clients on a DSL port. (In most Internet 1853 applications, downstream traffic exists only when a client sends 1854 upstream traffic). In other words, the client will be denied service 1855 until it gets downstream traffic, which may never arrive. 1857 Query by IP address may be used for upstream traffic. Then whenever 1858 an upstream packet arrives whose IP address is unknown to the access 1859 concentrator, a Leasequery may be initiated. A related question is 1860 what to do with that upstream traffic itself until the leasequery 1861 response arrives? If the traffic is dropped, we may be dropping 1862 legitimate traffic. If the traffic is forwarded, we may be 1863 forwarding spoofed packets. Once the lease response arrives, 1864 subsequent traffic is handled depending on the response. If a 1865 DHCPLEASEACTIVE response arrives, the access concentrator will accept 1866 the traffic. If a DHCPLEASEUNASSIGNED response arrives, the access 1867 concentrator will drop the traffic corresponding to the IP address. 1868 If a DHCPLEASEUNKNOWN response arrives the access concentrator may 1869 drop the traffic corresponding to the IP address but will have to 1870 periodically send the Leasequery for that IP address again 1871 (additional overhead). The process is triggered whenever an unknown 1872 IP address arrives. 1874 Note that the access concentrator needs to keep track of 4 lists of 1875 IP addresses: (1) List of IP addresses for which it got 1876 DHCPLEASEACTIVE responses; (2) List of IP addresses for which it got 1877 DHCPLEASEUNASSIGNED responses; (3) List of IP addresses for which it 1878 got DHCPLEASEUNKNOWN responses; (4) All other IP addresses. 1880 This approach may be acceptable if only legitimate traffic is 1881 received. Consider the case when someone sends packets that uses 1882 spoofed IP addresses. In that case, lease response will be 1883 DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN. [RFC4388] suggests usage of 1884 negative caching in this regard (which involves additional 1885 resources). 1887 In a spoofing type of attack, negative caching information may grow 1888 considerably if the attacker varies the source IP address. For each 1889 such new source IP address, traffic will arrive on the slow path, a 1890 new lease query needs to be initiated, the response will be 1891 processed, and negative caching needs to be done. That will mean 1892 using many resources for negative caching. 1894 [RFC4388] suggests that if the access concentrator knows the network 1895 portion of the IP addresses that are assigned to its clients, then 1896 some amount of antispoofing can be done in the fast path and some 1897 lease queries may be avoided. But as indicated before, that 1898 information may not always be available to access concentrators. 1900 Effectively, antispoofing support involves considerable slow path 1901 processing and considerable resources tied for negative caching. 1903 [RFC4388] says that DHCPv4 servers should be protected from being 1904 flooded with too many Leasequery requests and access concentrators 1905 also should not send too many Leasequery messages at a time. This 1906 would mean that legitimate requestors may be excessively delayed 1907 getting their information in the face of spoofing attacks. 1909 It is concluded that antispoofing is neither effective nor efficient 1910 with this query type. 1912 o Query by MAC Address 1914 Query by MAC address can also be used in a way similar to query by IP 1915 address described above. Indeed, query by MAC address may be better 1916 than query by IP address in one sense because of the possible 1917 presence of the associated-ip option in lease responses. (Note that 1918 the associated-ip option does not appear in responses for a query by 1919 IP address). With the associated-ip option access concentrator can 1920 get information not only about the IP address/MAC address that 1921 triggered the Leasequery but also about other IP addresses that are 1922 associated with the original MAC address. That way, when traffic 1923 that uses the other IP addresses arrives, the access concentrator is 1924 already prepared to deal with them. 1926 Although query by MAC address is better than query by IP address in 1927 the above respect, it has a specific problem which is not shared by 1928 query by IP address. For a query by MAC address, only two types of 1929 responses are possible: DHCPLEASEUNKNOWN and DHCPLEASEACTIVE; 1930 DHCPLEASEUNASSIGNED is not supported. This is particularly 1931 troublesome when a DHCPv4 server indeed has definitive information 1932 that no IP addresses are associated with the specified MAC address in 1933 the Leasequery, but it is forced to respond with DHCPLEASEUNKNOWN 1934 instead of DHCPLEASEUNASSIGNED. As we have seen above, unlike 1935 DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN requires periodic querying the 1936 DHCPv4 server, an additional overhead. 1938 Moreover, query by MAC address also shares all other issues we 1939 discussed above for query by IP address. 1941 We conclude that existing Leasequery types are not appropriate to 1942 achieve effective and efficient antispoofing in the environment 1943 discussed.