idnits 2.17.1 draft-kinnear-dhc-dhcpv4-bulk-leasequery-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1843. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1850. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1856. 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 Copyright Line does not match the current year == Line 499 has weird spacing: '...ge-size the...' == Line 583 has weird spacing: '...-number base...' == Line 584 has weird spacing: '...-number fro...' == Line 591 has weird spacing: '... Name sta...' == Line 1682 has weird spacing: '... Name sta...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5653 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-04 == Outdated reference: A later version (-15) exists of draft-ietf-dhc-vpn-option-09 -- Obsolete informational reference (is this intentional?): RFC 4614 (Obsoleted by RFC 7414) == Outdated reference: A later version (-06) exists of draft-ietf-dhc-dhcpv6-bulk-leasequery-04 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 8 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: May 3, 2009 Mark Stapp 6 Cisco Systems, Inc. 7 D. Rao 8 B. Joshi 9 P. Kurapati 10 Infosys Technologies Ltd. 11 November 3, 2008 13 Bulk DHCPv4 Lease Query 14 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 7, 2009 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been 48 extended with a Leasequery capability that allows a requestor to 49 request information about DHCPv4 bindings. That mechanism is limited 50 to queries for individual bindings. In some situations individual 51 binding queries may not be efficient, or even possible. This 52 document expands on the DHCPv4 Leasequery protocol to allow for bulk 53 transfer of DHCPv4 address binding data via TCP. 55 Table of Contents 57 1. Introduction................................................. 3 58 2. Terminology.................................................. 4 59 3. Motivation................................................... 6 60 4. Design Goals................................................. 8 61 4.1. Information Acquisition before Data Starts................. 8 62 4.2. Lessen Negative Caching.................................... 8 63 4.3. Antispoofing in 'Fast Path'................................ 8 64 4.4. Minimize data transmission................................. 8 65 5. Protocol Overview............................................ 9 66 6. Interaction Between UDP Leasequery and Bulk Leasequery....... 10 67 7. Message and Option Definitions............................... 11 68 7.1. Message Framing for TCP.................................... 11 69 7.2. New or Changed Options..................................... 12 70 7.3. Connection and Transmission Parameters..................... 20 71 8. Requestor Behavior........................................... 20 72 8.1. Connecting and General Processing.......................... 20 73 8.2. Forming a Bulk Leasequery.................................. 21 74 8.3. Processing Bulk Replies.................................... 23 75 8.4. Processing Time Values in Leasequery messages.............. 25 76 8.5. Querying Multiple Servers.................................. 27 77 8.6. Making Sense Out of Multiple Responses Concerning a Single. 27 78 8.7. Multiple Queries to a Single Server over One Connection.... 28 79 8.8. Closing Connections........................................ 29 80 9. Server Behavior.............................................. 30 81 9.1. Accepting Connections...................................... 30 82 9.2. Replying to a Bulk Leasequery.............................. 30 83 9.3. Building a Single Reply for Bulk Leasequery................ 34 84 9.4. Multiple or Parallel Queries............................... 35 85 9.5. Closing Connections........................................ 36 86 10. Security Considerations..................................... 36 87 11. IANA Considerations......................................... 37 88 12. Acknowledgements............................................ 38 89 13. References.................................................. 38 90 13.1. Normative References...................................... 38 91 13.2. Informative References.................................... 39 92 14. Authors' Addresses.......................................... 39 93 15. Full Copyright Statement.................................... 41 94 16. Intellectual Property....................................... 41 95 17. Acknowledgment.............................................. 41 96 18. Appendix -- Why a New Leasequery is Required................ 42 98 1. Introduction 100 The DHCPv4 protocol [RFC2131] [RFC2132] specifies a mechanism for the 101 assignment of IPv4 address and configuration information to IPv4 102 nodes. DHCPv4 servers maintain authoritative binding information. 104 +--------+ 105 | DHCPv4 | +--------------+ 106 | Server |-...-| DSLAM | 107 | | | Relay Agent | 108 +--------+ +--------------+ 109 | | 110 +------+ +------+ 111 |Modem1| |Modem2| 112 +------+ +------+ 113 | | | 114 +-----+ +-----+ +-----+ 115 |Host1| |Host2| |Host3| 116 +-----+ +-----+ +-----+ 118 Figure 1: Example DHCPv4 configuration 120 DHCPv4 relay agents receive DHCPv4 messages and frequently append a 121 relay agent information option [RFC3046] before relaying them to the 122 configured DHCPv4 servers (see Figure 1). In this process, some 123 relay agents also glean the lease information sent by the server and 124 maintain this locally. This information is used for a variety of 125 purposes, including prevention of spoofing attempts from the DHCPv4 126 clients and to install routes. When a relay agent reboots, this 127 information is frequently lost. 129 The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4 130 capability to allow an external entity, such as a relay agent, to 131 query a DHCPv4 server to recover lease state information about a 132 particular IP address or client in near real-time. 134 The existing query types in Leasequery are typically data driven; the 135 relay agent initiates the Leasequery when it receives data traffic 136 from or to the client. This approach may not scale well when there 137 are thousands of clients connected to the relay agent or when the 138 relay agent has a need to rebuild its internal data store prior to 139 processing traffic in one direction or another. 141 Different query types are needed where a relay agent can query the 142 server without waiting for the traffic from or for the clients, as 143 well as a different transmission technique more conducive to the 144 transmission of large quantities of data. 146 This document extends the DHCPv4 Leasequery protocol to add support 147 for queries that address these additional requirements. There may be 148 many thousands of DHCPv4 bindings returned as the result of a single 149 request, so TCP [RFC4614] is specified for efficiency of data 150 transfer. We define several additional query types, each of which 151 could return multiple responses, in order to meet a variety of 152 requirements. 154 2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 This document uses the following terms: 162 o "absolute time" 164 A 32-bit quantity containing the number of seconds since Jan 1, 165 1970. 167 o "access concentrator" 169 An access concentrator is a router or switch at the broadband 170 access provider's edge of a public broadband access network. 171 This document assumes that the access concentrator includes the 172 DHCPv4 relay agent functionality. 174 o "active binding" 176 An IP address with an active binding refers to an IP address 177 which is currently associated with a DHCPv4 client where that 178 DHCPv4 client has the right to use the IP address. 180 o "Bulk Leasequery" 182 Requesting and receiving the existing DHCPv4 address binding 183 information in an efficient manner. 185 o "clock skew" 187 The difference between the absolute time on a DHCPv4 server and 188 the absolute time on the system where a requestor of a Bulk 189 Leasequery is executing is termed the "clock skew" for that Bulk 190 Leasequery connection. It is not absolutely constant but is 191 likely to vary only slowly. It is possible that, when both 192 systems run NTP, that the clock skew is zero, and this is not 193 only acceptable, but desired. 195 While it is easy to think that this can be calculated precisely 196 after one message is received by a requestor from a DHCPv4 197 server, a more accurate value is derived from continuously 198 examining the instantaneous value developed from each message 199 received from a DHCPv4 server and using it to make small 200 adjustments to the existing value held in the requestor. 202 o "DHCPv4 client" 204 A DHCPv4 client is an Internet host using DHCPv4 to obtain 205 configuration parameters such as a network address. 207 o "DHCPv4 relay agent" 209 A DHCPv4 relay agent is a third-party agent that transfers BOOTP 210 and DHCPv4 messages between clients and servers residing on 211 different subnets, per [RFC951] and [RFC1542]. 213 o "DHCPv4 server" 215 A DHCPv4 server is an Internet host that returns configuration 216 parameters to DHCPv4 clients. 218 o "downstream" 220 Refers to a direction away from the central part of a network 221 and toward the edge. In a DHCPv4 context, typically refers to a 222 network direction which is away from the DHCPv4 server. 224 o "IP address" 225 In this document, the term "IP address" refers to an IPv4 IP 226 address. 228 o "IP address binding" 230 The information that a DHCPv4 server keeps regarding the 231 relationship between a DHCPv4 client and an IPv4 IP address. 232 This includes the identity of the DHCPv4 client and the 233 expiration time, if any, of any lease that client has on a 234 particular IPv4 address. In some contexts, this may include 235 information on IP addresses that are currently associated with 236 DHCPv4 clients, and in others it may also include IP addresses 237 with no current association to a DHCPv4 client. 239 o "MAC address" 241 In the context of a DHCPv4 message, a MAC address consists of 242 the fields: hardware type "htype", hardware length "hlen", and 243 client hardware address "chaddr". 245 o "upstream" 247 Refers to a direction toward the central part of a network and 248 away from the edge. In a DHCPv4 context, typically refers to a 249 network direction which is toward the DHCPv4 server. 251 o "stable storage" 253 Stable storage is used to hold information concerning IP address 254 bindings (among other things) so that this information is not 255 lost in the event of a failure which requires restart of the 256 network element. DHCPv4 servers are typically expected to have 257 high speed access to stable storage, while relay agents and 258 access concentrators usually do not have access to stable 259 storage, although they may have periodic access to such storage. 261 o "xid" 263 Transaction-id. The term "xid" refers to the DHCPv4 field 264 containing the transaction-id of the message. 266 3. Motivation 268 Consider a typical DSLAM working also as a DHCPv4 relay agent (see 269 Figure 1). Typically, both a "fast path" and a "slow path" exist in 270 many network elements, including DSLAMs. Fast path processing is 271 done in a network processor or in an ASIC (Application Specific 272 Integrated Circuit). Slow path processing is done in a normal 273 processor. As much as possible, regular data handling code should be 274 in the fast path. Slow path processing should be reduced as it may 275 become a bottleneck. 277 For a DSLAM having multiple DSL ports, multiple IP addresses may be 278 assigned using DHCPv4 to a single port and the number of DHCPv4 279 clients on a port may be unknown. The DSLAM may also not know the 280 network portions of the IP addresses that are assigned to its DHCPv4 281 clients. 283 The DSLAM gleans IP address or other information from DHCP 284 negotiations for antispoofing and for other purposes. The 285 antispoofing itself is done in the fast path. The DSLAM keeps track 286 of only one list of IP addresses: the list of IP addresses that are 287 assigned by a DHCPv4 server. Traffic for all other IP addresses is 288 dropped. If a client starts its data transfer after its DHCPv4 289 negotiations are gleaned by the DSLAM, no legitimate packets will be 290 dropped because of antispoofing. In other words, antispoofing is 291 effective (no legitimate packets are dropped and all spoofed packets 292 are dropped) and efficient (antispoofing is done in the fast path). 293 The intention is to achieve similar effective and efficient 294 antispoofing in the Leasequery scenario after a DSLAM loses its 295 gleaned information (for example, because of reboot). 297 After a deep analysis, we found that the three existing query types 298 supported by [RFC4388] do not provide effective and efficient 299 antispoofing for the above scenario and a new mechanism is required. 301 The existing query types 303 o necessitate a data driven approach: the lease queries can only 304 be done when the Access Concentrator receives data. That 305 results in increased outage time for DHCPv4 clients. 307 o result in excessive negative caching consuming lot of resources 308 under a spoofing attack. 310 o result in antispoofing being done in the slow path instead of 311 the fast path. 313 o do not support an Access Concentrator which periodically uploads 314 its internal table to some form of stable storage 316 The deeper analysis, which led to the above conclusions, itself 317 appears as an Appendix to this document. 319 4. Design Goals 321 The goal of this document is to provide a lightweight mechanism for 322 an Access Concentrator or other network element to retrieve IP 323 address binding information available in the DHCPv4 server. The 324 mechanism should also allow an Access Concentrator to retrieve 325 consolidated IP address binding information for the entire access 326 concentrator or for a single connection/circuit. 328 4.1. Information Acquisition before Data Starts 330 The existing data driven approach required by [RFC4388] means that 331 the Leasequeries can only be performed after an Access Concentrator 332 receives data. To implement antispoofing, packets need to be dropped 333 until it gets the lease information from DHCPv4 server. If an Access 334 Concentrator finishes the Leasequeries before it starts receiving 335 data, then there is no need to drop legitimate packets. In this way, 336 outage time may be reduced. 338 4.2. Lessen Negative Caching 340 If Leasequeries result in negative caches, then that puts additional 341 overhead on the access concentrator. The negative caches not only 342 consume precious resources, they also need to be managed. Hence they 343 should be avoided as much as possible. The Leasequeries should 344 reduce the need for negative caching as far as possible. 346 4.3. Antispoofing in 'Fast Path' 348 If Antispoofing is not done in fast path, it will become a bottleneck 349 and may lead to denial of service of the access concentrator. The 350 Leasequeries should make it possible to do antispoofing in fast path. 352 4.4. Minimize data transmission 354 It may be that a network element is able to periodically save its 355 entire list of assigned IP addresses to some form of stable storage. 356 In this case, it will wish to recover all of the updates to this 357 information without duplicating the information it has recovered from 358 its own stable storage. 360 Bulk Leasequery allows specification of a query-start-time as well as 361 a query-end-time. Use of query-times allows a network element that 362 periodically commits information to stable storage to recover just 363 what it lost since the last commit. 365 5. Protocol Overview 367 The Bulk Leasequery mechanism is modeled on the existing individual 368 Leasequery protocol in [RFC4388] as well as related work on DHCPv6 369 Bulk Leasequery [DHCPv6Bulk]. A Bulk Leasequery requestor opens a TCP 370 connection to a DHCPv4 Server, using the DHCPv4 port 67. Note that 371 this implies that the Leasequery requestor has server IP address(es) 372 available via configuration or some other means, and that it has 373 unicast IP reachability to the DHCPv4 server. No relaying of Bulk 374 Leasequery messages is specified. 376 After establishing a connection, the requestor sends a 377 DHCPBULKLEASEQUERY message over the connection. 379 The server uses the message type and additional data in the DHCPv4 380 DHCPBULKLEASEQUERY message to identify any relevant bindings. 382 In order to support some query types, servers may have to maintain 383 additional data structures or otherwise be able to locate bindings 384 that have been requested by the Leasequery requestor. 386 The Bulk Leasequery mechanism is designed to provide an external 387 entity with information concerning existing DHCPv4 IPv4 address 388 bindings managed by the DHCPv4 server. When complete, the DHCPv4 389 server will send a DHCPLEASEQUERYDONE message. If a connection is 390 lost while processing a Bulk Leasequery, the Bulk Leasequery must be 391 retried as there is no provision for determining the extent of data 392 already received by the requestor for a Bulk Leasequery. 394 Bulk Leasequery supports queries by MAC address, and Client 395 Identifier in a way similar to [RFC4388]. The Bulk Leasequery 396 protocol also adds several new queries. 398 o Query by Relay Identifier 400 This query asks a server for the bindings associated with a 401 specific relay agent; the relay agent is identified by a DUID 402 carried in a Relay-ID sub-option [RelayId]. Relay agents can 403 include this sub-option while relaying messages to DHCPv4 404 servers. Servers can retain the Relay-ID and associate it with 405 bindings made on behalf of the relay agent's clients. The 406 bindings returned are only those for DHCPv4 clients with a 407 currently active binding. 409 o Query by Remote ID 411 This query asks a server for the bindings associated with a 412 Relay Agent Remote-ID sub-option [RFC3046] value. The bindings 413 returned are only those for DHCPv4 clients with a currently 414 active binding. 416 o Query for All Configured IP Addresses 418 This query asks a server for information concerning all IP 419 addresses configured in that DHCPv4 server, by specifying no 420 other type of query. In this case, the bindings returned are for 421 all configured IP addresses, whether or not they contain a 422 currently active binding to a DHCPv4 client, since one point of 423 this type of query is to update an existing database with 424 changes after a particular point in time. 426 Any of the above queries can be qualified by the specification of a 427 query-start-time or a query-end-time (or both). In the event these 428 times are used as qualifiers they indicate that a binding should be 429 included if it changed on or after the query-start-time and on or 430 before the query-end-time. 432 In addition, any of the above queries can be qualified by the 433 specification of a vpn-id option [VpnId] to select the VPN on which 434 the query should be processed. The vpn-id option is also extended to 435 allow queries across all available VPNs. By default, only the default 436 VPN is used to satisfy the query. 438 6. Interaction Between UDP Leasequery and Bulk Leasequery 440 Bulk Leasequery can be seen as an extension of the existing UDP 441 Leasequery protocol [RFC4388]. This section clarifies the 442 relationship between the two protocols. 444 Only the DHCPBULKLEASEQUERY request is supported over the Bulk 445 Leasequery connection. No other DHCPv4 requests are supported. The 446 Bulk Leasequery connection is not an alternative DHCPv4 communication 447 option for clients seeking other DHCPv4 services. 449 Two of the query-types introduced in the UDP Leasequery protocol can 450 be used in the Bulk Leasequery protocol -- query by MAC address and 451 query by client-id. 453 One change in behavior for these existing queries is required when 454 Bulk Leasequery is used. [RFC4388], in sections 6.1, 6.4.1, and 455 6.4.2 specifies the use of an associated-ip option in DHCPLEASEACTIVE 456 messages in cases where multiple bindings were found. When Bulk 457 Leasequery is used, this mechanism is not necessary; a server 458 returning multiple bindings simply does so directly as specified in 459 this document. The associated-ip option MUST NOT appear in Bulk 460 Leasequery replies. 462 The contents of the reply messages are similar between the existing 463 UDP Leasequery protocol and the Bulk Leasequery protocol, though more 464 information is returned in the Bulk Leasequery messages and, as 465 discussed above, the associated-ip option MUST NOT be used. 467 7. Message and Option Definitions 469 7.1. Message Framing for TCP 471 The use of TCP for the Bulk Leasequery protocol permits multiple 472 messages to be sent from one end of the connection to the other 473 without requiring a request/response paradigm as does UDP DHCPv4 474 [RFC2131]. The receiver needs to be able to determine the size of 475 each message it receives. Two octets containing the message size in 476 network byte-order are prepended to each DHCPv4 message sent on a 477 Bulk Leasequery TCP connection. The two message-size octets 'frame' 478 each DHCPv4 message. 480 The maximum message size is 65535 octets. 482 DHCPv4 message framed for TCP: 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | message-size | op (1) | htype (1) | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | hlen (1) | hops (1) | .... | 490 +---------------+---------------+ + 491 | | 492 . remainder of DHCPv4 message, 493 . from Figure 1 of [RFC2131] . 494 . . 495 . (variable) . 496 | | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 message-size the number of octets in the message that 500 follows, as a 16-bit integer in network 501 byte-order. 503 All other fields are as specified in DHCPv4 [RFC2131]. 505 Figure 2: Format of a DHCPv4 message in TCP 507 The intent in using this format is that code which currently knows 508 how to deal with sending or receiving a message in [RFC2131] format 509 will easily be able to deal with the message contained in the TCP 510 framing. 512 7.2. New or Changed Options 514 The existing messages DHCPLEASEUNASSIGNED and DHCPLEASEACTIVE are 515 used as the value of the dhcp-message-type option to indicate an IP 516 address which is currently not leased or currently leased to a DHCPv4 517 client, respectively [RFC4388]. 519 Additional options have also been defined to enable the Bulk 520 Leasequery protocol to communicate useful information to the 521 requestor. 523 7.2.1. dhcp-message-type 525 The dhcp-message-type option (option 53) from Section 9.6 of 526 [RFC2132] requires new values. The values of these message types are 527 shown below in an extension of the table from Section 9.6 of 528 [RFC2132]: 530 Value Message Type 531 ----- ------------ 532 14 DHCPBULKLEASEQUERY 533 15 DHCPLEASEQUERYDONE 535 7.2.2. dhcp-message 537 The dhcp-message option (option 56) from Section 9.9 of [RFC2132] 538 requires additional definition for use in the context of a 539 DHCPBULKLEASEQUERY. 541 The format of the NVT ASCII message in the dhcp-message option is 542 specified to have the first three characters appear in a constrained 543 format. The first three characters MUST be numeric (base 10) 544 characters. 546 Encoded in these first three characters is the decimal number 547 corresponding to a variety of status codes defined below. 549 The motivation for this constraint of the existing dhcp-message 550 option is to reduce the number of top-level options used by this 551 document. 553 The status code returned in the dhcp-message option allows greater 554 detail to be returned regarding the status of a DHCPBULKLEASEQUERY 555 request. While specified in the Bulk Leasequery document, this 556 additional specification of the DHCPv4 dhcp-message option may well 557 be valuable in other circumstances. In those circumstances its scope 558 should be explicitly defined. 560 This option has two possible scopes when used with Bulk Leasequery, 561 depending on the context in which it appears. It refers to the 562 information in a single Leasequery reply if the value of the dhcp- 563 message-type is DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED. It refers to 564 the message stream related to an entire request if the value of the 565 dhcp-message-type is DHCPLEASEQUERYDONE. 567 The code for this option is 56. The length of this option is at least 568 3 octets. 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | option-code | option-len | left-number | middle-number | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | right-number | status-message (if any) ... . 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 option-code 56. 580 option-len 3 + length of status-message (which may be 0). 582 left-number NVT ASCII encoded characters representing the 583 middle-number base-10 value of the status code, taken 584 right-number from the table below. 586 status-message An optional NVT ASCII encoded text string 587 suitable for display to an end user, which 588 MUST NOT be null-terminated. It SHOULD 589 start with an NVT ASCII space. 591 Name status-code Description 592 ---- ----------- ----------- 593 Success 000 Success. Also signaled by absence of 594 dhcp-message option. 596 UnspecFail 001 Failure, reason unspecified. 598 QueryTerminated 002 Indicates that the server is unable to 599 perform a query or has prematurely terminated 600 the query for some reason (which should be 601 communicated in the text message). 603 MalformedQuery 003 The query was not understood. 605 NotAllowed 004 The query or request was understood but was 606 not allowed in this context. 608 A dhcp-message option MAY appear in the options field of a DHCPv4 609 message. If the dhcp-message option does not appear, it is assumed 610 that the operation was successful. The dhcp-message option SHOULD 611 NOT appear in a message which is successful unless there is some text 612 string that needs to be communicated to the requestor. 614 7.2.3. base-time 616 The base-time option is the current time the message was created to 617 be sent by the DHCPv4 server to the requestor of the Bulk Leasequery. 618 This MUST be an absolute time. All of the other time based options in 619 the reply message are relative to this time, including the dhcp- 620 lease-time [RFC2132] and client-last-transaction-time [RFC4388]. 621 This time is in the context of the DHCPv4 server. 623 This is an integer in network byte order. 625 The code for this option is TBD. The length of this option is 4 626 octets. 628 DHCPv4 Server 629 Code Len Base Time 630 +-----+-----+-----+-----+-----+-----+ 631 | TBD | 4 | t1 | t2 | t3 | t4 | 632 +-----+-----+-----+-----+-----+-----+ 634 7.2.4. start-time-of-state 636 The start-time-of-state option allows the receiver to determine the 637 time at which the IP address transitioned into its current state. 639 This MUST NOT be an absolute time. This MUST NOT be an absolute 640 number of seconds since Jan 1, 1970. Instead, this MUST be an 641 integer number of seconds in the past from the time specified in the 642 base-time option in the same message that the IP address transitioned 643 into its current state. In the same way that the IP Address Lease 644 Time option (option 51) encodes a lease time which is a number of 645 seconds into the future from the time the message was sent, this 646 option encodes a value which is a number of seconds into the past 647 from the base-time option included in the same message. 649 This is an integer in network byte order. 651 The code for this option is TBD. The length of this option is 4 652 octets. 654 Seconds in the past 655 Code Len from base-time 656 +-----+-----+-----+-----+-----+-----+ 657 | TBD | 4 | t1 | t2 | t3 | t4 | 658 +-----+-----+-----+-----+-----+-----+ 660 7.2.5. query-start-time 662 The query-start-time option allows the requestor to specify a start 663 query time to the DHCPv4 server. If specified, only bindings that 664 have changed on or after the query-start-time should be included in 665 the response to the query. 667 This MUST be an absolute time. 669 This MUST be a time in the context of the DHCPv4 server. In the 670 absence of information to the contrary, the requestor SHOULD assume 671 that the time context of the DHCPv4 server is identical to the time 672 context of the requestor. 674 It SHOULD NOT be a time in the context of the requestor. 676 This is an integer in network byte order. 678 The code for this option is TBD. The length of this option is 4 679 octets. 681 DHCPv4 Server 682 Code Len query-start-time 683 +-----+-----+-----+-----+-----+-----+ 684 | TBD | 4 | t1 | t2 | t3 | t4 | 685 +-----+-----+-----+-----+-----+-----+ 687 7.2.6. query-end-time 689 The query-end-time option allows the requestor to specify an end 690 query time to the DHCPv4 server. If specified, only bindings that 691 have changed on or before the query-end-time should be included in 692 the response to the query. 694 This MUST be an absolute time. 696 This MUST be a time in the context of the DHCPv4 server. In the 697 absence of information to the contrary, the requestor SHOULD assume 698 that the time context of the DHCPv4 server is identical to the time 699 context of the requestor. 701 It SHOULD NOT be a time in the context of the requestor. 703 This is an integer in network byte order. 705 The code for this option is TBD. The length of this option is 4 706 octets. 708 DHCPv4 Server 709 Code Len query-end-time 710 +-----+-----+-----+-----+-----+-----+ 711 | TBD | 4 | t1 | t2 | t3 | t4 | 712 +-----+-----+-----+-----+-----+-----+ 714 7.2.7. dhcp-state 716 The dhcp-state option allows greater detail to be returned than 717 allowed by the DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types. 719 The code for this option is TBD. The length of this option is 1 720 octet. 722 0 1 2 723 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Code | Length | State | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 Code The suboption code (TBD). 730 Length The suboption length, 1 octet. 732 State The State of the IP address. 734 Value State 735 ----- ----- 736 1 AVAILABLE Address is available to local DHCPv4 server 737 2 ACTIVE Address is assigned to a DHCPv4 client 738 3 EXPIRED Lease has expired 739 4 RELEASED Lease has been released by DHCPv4 client 740 5 ABANDONED Server or client flagged address as unusable 741 6 RESET Lease was freed by some external agent 742 7 REMOTE Address is available to a remote DHCPv4 server 743 8 TRANSITIONING Address is moving between states 745 Note that some of these states may be transient and may not appear in 746 normal use. A DHCPv4 server MUST implement at least the AVAILABLE 747 and ACTIVE states, and SHOULD implement at least the ABANDONED and 748 RESET states. 750 The dhcp-state option SHOULD contain ACTIVE when it appears in a 751 DHCPLEASEACTIVE message. A DHCPv4 server MAY choose to not send a 752 dhcp-state option in a DHCPLEASEACTIVE message, and a requestor 753 SHOULD assume that the dhcp-state is ACTIVE if no dhcp-state option 754 appears in a DHCPLEASEACTIVE message. 756 The reference to local and remote relate to possible use in an 757 environment that includes multiple servers cooperating to provide an 758 increased availability solution. In this case, an IP address with 759 the state of AVAILABLE is available to the local server, while one 760 with the state of REMOTE is available to a remote server. Usually, 761 an IP address which is AVAILABLE on one server would be REMOTE on any 762 remote server. The TRANSITIONING state is also likely to be useful 763 in multiple server deployments, where sometimes one server must 764 interlock a state change with one or more other servers. Should a 765 Bulk Leasequery need to send information concerning the state of the 766 IP address during this period, it SHOULD use the TRANSITIONING state, 767 since the IP address is likely to be neither ACTIVE or AVAILABLE. 769 There is no requirement for the state of an IP address to transition 770 in a well defined way from state to state. To put this another way, 771 you cannot draw a simple state transition graph for the states of an 772 IP address and the requestor of a Leasequery MUST NOT depend on one 773 certain state always following a particular previous state. In 774 general, every state can (at times) follow every other state. 776 7.2.8. data-source 778 The data-source option contains information about the source of the 779 data in a DHCPLEASEACTIVE or a DHCPLEASEUNASSIGNED message. It is 780 used when there are two or more servers who might have information 781 about a particular IP address binding. Frequently two servers work 782 together to provide an increased availability solution for the DHCPv4 783 service, and in these cases, both servers will respond to Bulk 784 Leasequery requests for the same IP address. 786 The data contained in this option will allow an external process to 787 better discriminate between the information provided by each of the 788 servers servicing this IPv4 address. 790 The code for this option is TBD. The length of this option is 1 791 octet. 793 0 1 2 794 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Code | Length | Flags | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 Code The suboption code (TBD). 801 Length The suboption length, 1 octet. 803 Flags The Source information for this message. 805 0 1 2 3 4 5 6 7 806 +-+-+-+-+-+-+-+-+ 807 | MBZ |R| 808 +-+-+-+-+-+-+-+-+ 810 R: REMOTE flag 812 remote = 1 813 local = 0 815 MBZ: MUST BE ZERO (reserved for future use) 817 The REMOTE flag is used to indicate where the most recent change of 818 state (or other interesting change) concerning this IPv4 address took 819 place. If the value is local, then the change took place on the 820 server from which this message was transmitted. If the value is 821 remote, then the change took place on some other server, and was made 822 known to the server from which this message was transmitted. 824 If this option was requested and it doesn't appear, the the requestor 825 SHOULD consider that the data-source was local. 827 7.2.9. Virtual Subnet Selection Type and Information 829 All of the (sub)options defined in [VpnId] carry identical payloads, 830 consisting of a type and additional VSS (Virtual Subnet Selection) 831 information. The existing table is extended (see below) with a new 832 type 254 to allow specification of a type code which indicates that 833 all VPN's are to be used to process the Bulk Leasequery. 835 Type VSS Information format: 836 ---- ----------------------- 837 0 NVT ASCII VPN identifier 838 1 RFC2685 VPN-ID 839 2-253 Not Allowed 840 NEW -> 254 All VPN's (wildcard). 841 255 Global, default VPN. 843 7.3. Connection and Transmission Parameters 845 DHCPv4 servers that support Bulk Leasequery SHOULD listen for 846 incoming TCP connections on the DHCPv4 server port 67. 847 Implementations MAY offer to make the incoming port configurable, but 848 port 67 MUST be the default. Requestors SHOULD make TCP connections 849 to port 67, and MAY offer to make the destination server port 850 configurable. 852 This section presents a table of values used to control Bulk 853 Leasequery behavior, including recommended defaults. Implementations 854 MAY make these values configurable. 856 Parameter Default Description 857 ------------------------------------------ 858 BULK_LQ_CONN_TIMEOUT 30 secs Leasequery connection timeout 859 BULK_LQ_QUERY_TIMEOUT 30 secs Leasequery query timeout 860 BULK_LQ_MAX_CONNS 10 Max Leasequery TCP connections 861 BULK_LQ_MAX_CONN_RETRY 60 secs Max Leasequery retry timeout 862 BULK_LQ_DATA_TIMEOUT 30 secs Leasequery data timeout 864 8. Requestor Behavior 866 8.1. Connecting and General Processing 868 A requestor attempts to establish a TCP connection to a DHCPv4 server 869 in order to initiate a Leasequery exchange. The requestor SHOULD be 870 prepared to abandon the connection attempt after 871 BULK_LQ_CONN_TIMEOUT. If the attempt fails, the requestor MAY retry. 872 Retries MUST use an exponential backoff timer, increasing the 873 interval between attempts up to BULK_LQ_MAX_CONN_RETRY. 875 If Bulk Leasequery is terminated prematurely by a DHCPLEASEQUERYDONE 876 with a dhcp-message status-code of QueryTerminated or by the failure 877 of the connection over which it was being submitted, the requestor 878 MAY retry the request after the creation of a new connection. 879 Retries MUST use an exponential backoff timer, increasing the 880 interval between attempts up to BULK_LQ_MAX_CONN_RETRY. 882 Messages from the DHCPv4 server come as multiple responses to a 883 single DHCPBULKLEASEQUERY message. Thus, each DHCPBULKLEASEQUERY 884 request MUST have a xid (transaction-id) unique on the connection on 885 which it is sent, and all of the messages which come as a response to 886 it all contain the same xid as the request. It is the xid which 887 allows the data-streams of two different DHCPBULKLEASEQUERY requests 888 to be demultiplexed by the requestor. 890 A requestor MAY send a DHCPBULKLEASEQUERY request to a DHCPv4 server 891 and immediately close the transmission side of its TCP connection, 892 and then read the resulting response messages from the DHCPv4 server. 893 This is not required, and the usual approach is to leave both sides 894 of the TCP connection up until at least the conclusion of the Bulk 895 Leasequery. 897 8.2. Forming a Bulk Leasequery 899 Bulk Leasequery is designed to create a connection which will 900 transfer the state of some subset (or possibly all) of the IP address 901 bindings to the requestor from DHCPv4 server. The DHCPv4 server 902 will send all of the requested IPv4 address bindings across this 903 connection with minimal delay after it receives the request. In this 904 context, "all IP address binding information" means information about 905 all IPv4 addresses configured within the DHCPv4 server which meet the 906 specified query criteria. For some query criteria, this may include 907 IP address binding information for IP addresses which may not now 908 have or ever had have an association with a specific DHCPv4 client. 910 To form the Bulk query, a DHCPv4 request is constructed with a dhcp- 911 message-type of DHCPBULKLEASEQUERY. The query SHOULD have a dhcp- 912 parameter-request-list to inform the DHCPv4 server which DHCPv4 913 options are of interest to the requestor sending the 914 DHCPBULKLEASEQUERY message. The dhcp-parameter-request-list in a 915 DHCPBULKLEASEQUERY message SHOULD contain the codes for base-time, 916 dhcp-lease-time, start-time-of-state, and client-last-transaction- 917 time. 919 A DHCPBULKLEASEQUERY request is constructed of one of a series of 920 primary queries and the optional addition of one or more qualifiers 921 to those primary queries. 923 The possible primary queries are listed below. Each 924 DHCPBULKLEASEQUERY request MUST consist of only one of these primary 925 queries. 927 o Query by MAC address 929 In a Query by MAC address, the chaddr, htype, and hlen of the 930 DHCPv4 packet are filled in with the values requested. 932 o Query by Client-Id 934 In a Query by Client-Id, the dhcp-client-id option containing 935 the requested value is included in the DHCPBULKLEASEQUERY 936 request. 938 o Query by Remote-Id 940 In a Query by Remote-Id, the remote-id sub-option of the relay- 941 agent-information option containing the requested value is 942 included in the DHCPBULKLEASEQUERY request. 944 o Query by Relay-Id 946 In a Query by Relay-Id, the relay-id sub-option [RelayId] of the 947 relay-agent-information option containing the requested value is 948 included in the DHCPBULKLEASEQUERY request. 950 o Query for All Configured IP Addresses 952 A Query for All Configured IP addresses is signaled by the 953 absence of any other primary query. 955 There are three qualifiers which can be applied to any of the above 956 primary queries. These qualifiers can appear individually or 957 together in any combination, but only one of each can appear. 959 o Query Start Time 961 Inclusion of the query-start-time option specifies that only IP 962 address bindings which have changed on or after the time specified 963 in the query-start-time option should be returned. 965 o Query End Time 967 Inclusion of the query-end-time option specifies that only IP 968 address bindings which have changed on or before the time specified 969 in the query-end-time option should be returned. 971 o VPN Id 973 If no vpn-id option appears in the DHCPBULKLEASEQUERY, the default 974 VPN is used to search to satisfy the query specified by the 975 DHCPBULKLEASEQUERY. Using the vpn-id option [VpnId] allows the 976 requestor to specify a single VPN other than the default VPN. In 977 addition, the vpn-id option has been extended as part of this 978 document to allow specification that all configured VPN's be 979 searched in order to satisfy the query specified in the 980 DHCPBULKLEASEQUERY. 982 In all cases, any message returned from a DHCPBULKLEASEQUERY 983 request containing information about an IP address for other than 984 the default VPN MUST contain a vpn-id option in the message. 986 Both of the query-start-time and query-end-time options (if they 987 appear) MUST be in the time context of the DHCPv4 server to which the 988 Bulk Leasequery is directed. In the absence of information to the 989 contrary, the requestor SHOULD assume that the time context on the 990 DHCPv4 server is identical to the time context on the requestor. In 991 the event that previous operations have determined that the time 992 context on the DHCPv4 server to which the Bulk Leasequery is 993 addressed differs from the time context of the requestor, the time 994 context of the DHCPv4 server MUST be used. 996 Use of the query-start-time or the query-end-time options or both can 997 serve to reduce the amount of data transferred over the TCP 998 connection by a considerable amount. 1000 If the TCP connection becomes blocked while the requestor is sending 1001 its query, the requestor SHOULD be prepared to terminate the 1002 connection after BULK_LQ_QUERY_TIMEOUT. We make this recommendation 1003 to allow requestors to control the period of time they are willing to 1004 wait before abandoning a connection, independent of notifications 1005 from the TCP implementations they may be using. 1007 8.3. Processing Bulk Replies 1009 The requestor attempts to read a DHCPv4 Leasequery message from the 1010 TCP connection. If the stream of replies becomes blocked, the 1011 requestor SHOULD be prepared to terminate the connection after 1012 BULK_LQ_DATA_TIMEOUT, and MAY begin retry processing if configured to 1013 do so. 1015 A single Bulk Leasequery can and usually will result in a large 1016 number of replies. The requestor MUST be prepared to receive more 1017 than one reply with an xid matching a single DHCPBULKLEASEQUERY 1018 message from a single DHCPv4 server. If the xid in the received 1019 message does not match an outstanding DHCPBULKLEASEQUERY message, the 1020 requestor MUST close the TCP connection. 1022 If a response message does not contain a DHCPv4 server-identifier 1023 option (option 54), then the server-identifier option from the 1024 previous message should be used. Thus, the DHCPv4 server MUST send 1025 the server-identifier option in the first response message, and MAY 1026 send it in subsequent response message for the same request. 1028 The response messages generated by a DHCPBULKLEASEQUERY request are: 1030 o DHCPLEASEQUERYDONE 1032 A response of DHCPLEASEQUERYDONE indicates that the server has 1033 completed its response to the query, and that no more messages 1034 will be sent in response to the DHCPBULKLEASEQUERY. More details 1035 will sometimes be available in the received dhcp-message option 1036 in the DHCPLEASEQUERYDONE message. If there is no dhcp-message 1037 option in the DHCPLEASEQUERYDONE message, then the query 1038 completed successfully. 1040 Note that a query which returned no data, that is a 1041 DHCPBULKLEASEQUERY request followed by a DHCPLEASEQUERYDONE 1042 response, is considered a successful query in that no errors 1043 occurred during the processing. It is not considered an error 1044 to have no information to return to a DHCPBULKLEASEQUERY 1045 request. 1047 o DHCPLEASEACTIVE 1049 A Bulk Leasequery will generate DHCPLEASEACTIVE messages 1050 containing binding data for bound IP addresses which match the 1051 specified query criteria. The IP address which is bound to a 1052 DHCPv4 client will appear in the ciaddr field of the 1053 DHCPLEASEACTIVE message. The message may contain a non-zero 1054 chaddr, htype, and hlen and possibly additional options. 1056 o DHCPLEASEUNASSIGNED 1058 Some queries will also generate DHCPLEASEUNASSIGNED messages for 1059 IP addresses which match the query criteria. These messages 1060 indicate that the IP address was not currently bound to any 1061 DHCPv4 client. The IP address to which this message refers will 1062 appear in the ciaddr field of the DHCPLEASEUNASSIGNED message. 1063 A DHCPLEASEUNASSGINED message MAY also contain information about 1064 the last DHCPv4 client that was bound to this IP address. The 1065 message may contain a non-zero chaddr, htype, and hlen and 1066 possibly additional options. 1068 o DHCPLEASEUNKNOWN 1070 The DHCPLEASEUNKNOWN message MUST NOT appear in a response to a 1071 Bulk Leasequery. 1073 The requestor MUST NOT assume that there is any inherent order in the 1074 IP address binding information that is sent in response to a 1075 DHCPBULKLEASEQUERY. While the base-time will tend to increase 1076 monotonically (as it is the current time on the DHCPv4 server), the 1077 actual time that any IP address binding information changed is 1078 unrelated to the base-time. 1080 The DHCPLEASEQUERYDONE message always ends a successful 1081 DHCPBULKLEASEQUERY request and any unsuccessful DHCPBULKLEASEQUERY 1082 requests not terminated by a dropped connection. After receiving 1083 DHCPLEASEQUERYDONE from a server, the requestor MAY close the TCP 1084 connection to that server if no other DHCPBULKLEASEQUERY is 1085 outstanding on that TCP connection. 1087 The DHCPv4 Leasequery protocol [RFC4388] uses the associated-ip 1088 option as an indicator that multiple bindings were present in 1089 response to a single DHCPv4 client based query. For Bulk Leasequery, 1090 a separate message is returned for each binding, and so the 1091 associated-ip option is not used. 1093 8.4. Processing Time Values in Leasequery messages 1095 Bulk Leasequery requests may be made to a DHCPv4 server whose 1096 absolute time may not be synchronized with the local time of the 1097 requestor. Thus, there are at least two time contexts in even the 1098 simplest Bulk Leasequery response, and in the situation where 1099 multiple DHCPv4 servers are queried, the situation becomes even more 1100 complex. 1102 If the requestor of a Bulk Leasequery is saving the data returned in 1103 some form, it has a requirement to store a variety of time values, 1104 and some of these will be time in the context of the requestor and 1105 some will be time in the context of the DHCPv4 server. 1107 When receiving a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message from 1108 the DHCPv4 server, the message will contain a base-time option. The 1109 time contained in this base-time option is in the context of the 1110 DHCPv4 server. As such, it is an ideal time to save and use as input 1111 to a DHCPBULKLEASEQUERY in the query-start-time or query-end-time 1112 options, should the requestor need to ever issue a DHCPBULKLEASEQUERY 1113 message using those options as part of the query. 1115 In addition to saving the base-time for possible future use in a 1116 query-start-time option, the base-time is used as part of the 1117 conversion of the other times in the Leasequery message to values 1118 which are meaningful in the context of the requestor. 1120 The requestor SHOULD use the base-time values received in Bulk 1121 Leasequery messages to develop a value which represents the clock 1122 skew between the DHCPv4 server and the requestor. In theory this 1123 clock skew would simply be the difference between the first base-time 1124 value and the current time on the requestor when the message 1125 containing the base-time value was received. However, there may be 1126 transmission delays at the beginning or end or along the TCP 1127 connection, and so the actual clock skew may not be the same as any 1128 individual difference between a base-time value and the current time 1129 of the requestor. 1131 Moreover, in systems whose clocks are synchronized, perhaps using 1132 NTP, the clock skew will usually be zero, which is not only 1133 acceptable, but desired. 1135 The requestor SHOULD smooth the value which it uses as the clock skew 1136 by continuously examining the instantaneous value developed from the 1137 base-time of each message received from a DHCPv4 server and using 1138 this instantaneous value of clock skew to make small adjustments to 1139 the existing value of the clock skew. Thus, the clock skew will vary 1140 only slowly and one slow message will not completely distort a large 1141 number of future time calculations. 1143 Given the value of the clock skew on the requestor, the requestor 1144 SHOULD bring all of the times in the DHCPLEASEACTIVE and 1145 DHCPLEASEUNASSIGNED messages into the context of the requestor. 1146 Except for the base-time value, the times in the Leasequery message 1147 are all relative to the base-time. These relative times SHOULD first 1148 be converted into absolute times in the context of the DHCPv4 server 1149 using the base-time value. Once this stage is complete, the absolute 1150 times that result SHOULD be brought into the context of the requestor 1151 by applying the calculated clock skew to each of the absolute times. 1153 After all of this processing, the times are in the context of the 1154 requestor. 1156 An alternative might appear to be to leave all of the times in the 1157 context of the DHCPv4 server, and if the requestor is dealing with 1158 only one DHCPv4 server at a time, this is an accurate and effective 1159 approach. However, if the requestor is dealing with DHCPLEASEACTIVE 1160 and DHCPLEASEUNASSIGNED messages from two or more different DHCPv4 1161 servers, then in order to make any sense of them, the times from each 1162 server SHOULD be converted into the time of the requestor. 1164 Since various transmission and processing delays may occur, a time 1165 converted into the requestor's context may be accurate to only a few 1166 seconds, at best. This is rarely an issue in the larger context of 1167 the use of the information derived from a Bulk Leasequery request. 1168 However, time comparison is an important factor in determining which 1169 update to the address binding information for a particular IPv4 1170 address is the most recent and therefore worth remembering. The next 1171 section discusses the issue of comparing two updates in some detail, 1172 but a key aspect of that comparison is a comparison of the times in 1173 the two messages. 1175 The requestor SHOULD consider times converted into its context as 1176 effectively equivalent if they are within a small number of seconds 1177 of each other. The precise number depends on the particular 1178 implementation involved, but 4 to 8 seconds is probably a good 1179 starting point. Thus, if two times are 3 seconds apart after 1180 conversion to the requestor's context they should be considered the 1181 same for purposes of comparison with each other. 1183 8.5. Querying Multiple Servers 1185 A Bulk Leasequery requestor MAY be configured to attempt to connect 1186 to and query from multiple DHCPv4 servers in parallel. The DHCPv4 1187 Leasequery specification [RFC4388] includes a discussion about 1188 reconciling binding data received from multiple DHCPv4 servers. 1190 In addition, the algorithm in the Section 8.6 should be used. 1192 8.6. Making Sense Out of Multiple Responses Concerning a Single IPv4 1193 Address 1195 Any requestor of an Bulk Leasequery MUST be prepared for multiple 1196 responses to arrive for a particular IPv4 address from multiple 1197 different DHCPv4 servers. The following algorithm SHOULD be used to 1198 decide if the information just received is more up to date (i.e., 1199 better) than the best existing information. In the discussion below, 1200 the information that is received from a DHCPv4 server about a 1201 particular IPv4 address is termed a "record". The times used in the 1202 algorithm below SHOULD have been converted into the requestor's 1203 context and the time comparisons SHOULD be performed in a manner 1204 consistent with the information in Section 8.4. 1206 o If both the existing and the new record contain client-last- 1207 transaction-time information, the record with the later client- 1208 last-transaction-time is considered better. 1210 o If one of the records contains client-last-transaction-time 1211 information and the other one doesn't, then compare the client- 1212 last-transaction-time in the record that contains it against the 1213 other record's start-time-of-state. The record with the later 1214 time is considered better. 1216 o If neither record contains client-last-transaction-time 1217 information, compare their start-time-of-state information. The 1218 record with the later start-time-of-state is considered better. 1220 o If none of the comparisons above yield a clear answer as to 1221 which record is later, then compare the value of the REMOTE flag 1222 from the data-source option for each record. 1224 If the values of the REMOTE flag are different between the two 1225 records, the record with the REMOTE flag value of local is 1226 considered better. 1228 The above algorithm does not necessarily determine which record is 1229 better. In the event that the algorithm is inconclusive with regard 1230 to a record which was just received by the requestor, the requestor 1231 SHOULD use additional information in the two records to make a 1232 determination as to which record is better. 1234 8.7. Multiple Queries to a Single Server over One Connection 1236 Bulk Leasequery requestors may need to make multiple queries in order 1237 to recover binding information. A requestor MAY use a single 1238 connection to issue multiple queries to a server willing to support 1239 them. Each query MUST have a unique xid. 1241 A server MAY process more than one query at a time. A server that 1242 will not support more than one query at a time on a single connection 1243 MUST return a DHCPLEASEQUERYDONE message containing a dhcp-message 1244 option with a status-code of NotAllowed to the unsupported queries. 1245 Alternatively, a server that will not support more than one query at 1246 a time on a single connection MAY chose to simply read one query and 1247 only read any subsequent queries after processing of the current 1248 query is complete. 1250 A server that is willing to do so MAY interleave replies to the 1251 multiple queries within the stream of reply messages it sends. 1252 Requestors need to be aware that replies for multiple queries may be 1253 interleaved within the stream of reply messages. Requestors that are 1254 not able to process interleaved replies (based on xid) MUST NOT send 1255 more than one query over a single connection prior to the completion 1256 of the previous query. Requestors should be aware that servers are 1257 not required to process more than one query over a connection at a 1258 time, and that servers are likely to limit the rate at which they 1259 process queries from any one requestor. 1261 8.7.1. Example 1263 This example illustrates what a series of queries and responses might 1264 look like. This is only an example - there is no requirement that 1265 this sequence must be followed, or that requestors or servers must 1266 support parallel queries. 1268 In the example session, the client sends four queries after 1269 establishing a connection. Query 1 returns no results; query 2 1270 returns 3 messages and the stream of replies concludes before the 1271 client issues any new query. Query 3 and query 4 overlap, and the 1272 server interleaves its replies to those two queries. 1274 Requestor Server 1275 --------- ------ 1276 DHCPBULKLEASEQUERY xid 1 -----> 1277 <----- DHCPLEASEQUERYDONE xid 1 1278 DHCPBULKLEASEQUERY xid 2 -----> 1279 <----- DHCPLEASEACTIVE xid 2 1280 <----- DHCPLEASEACTIVE xid 2 1281 <----- DHCPLEASEACTIVE xid 2 1282 <----- DHCPLEASEQUERYDONE xid 2 1283 DHCPBULKLEASEQUERY xid 3 -----> 1284 DHCPBULKLEASEQUERY xid 4 -----> 1285 <----- DHCPLEASEACTIVE xid 4 1286 <----- DHCPLEASEACTIVE xid 4 1287 <----- DHCPLEASEACTIVE xid 3 1288 <----- DHCPLEASEACTIVE xid 4 1289 <----- DHCPLEASEUNASSIGNED xid 3 1290 <----- DHCPLEASEACTIVE xid 4 1291 <----- DHCPLEASEACTIVE xid 3 1292 <----- DHCPLEASEQUERYDONE xid 3 1293 <----- DHCPLEASEACTIVE xid 4 1294 <----- DHCPLEASEQUERYDONE xid 4 1296 8.8. Closing Connections 1298 Either the requestor or DHCPv4 server MAY close the TCP connection at 1299 any time. The requestor MAY choose to retain the connection if it 1300 intends to issue additional queries or if other queries are currently 1301 using the connection. Note that this requestor behavior does not 1302 guarantee that the connection will be available for additional 1303 queries: the server might decide to close the connection based on its 1304 own configuration. 1306 9. Server Behavior 1308 9.1. Accepting Connections 1310 Servers that implement DHCPv4 Bulk Leasequery listen for incoming TCP 1311 connections. Port numbers are discussed in Section 7.3. Servers 1312 MUST be able to limit the number of currently accepted and active 1313 connections. The value BULK_LQ_MAX_CONNS SHOULD be the default; 1314 implementations MAY permit the value to be configurable. Connections 1315 SHOULD be accepted and, if the number of connections is over 1316 BULK_LQ_MAX_CONNS, they SHOULD be closed immediately. 1318 Servers MAY restrict Bulk Leasequery connections and 1319 DHCPBULKLEASEQUERY messages to certain requestors. Connections not 1320 from permitted requestors SHOULD be closed immediately, to avoid 1321 server connection resource exhaustion. Servers MAY restrict some 1322 requestors to certain query types. Servers MAY reply to queries that 1323 are not permitted with the DHCPLEASEQUERYDONE message with a dhcp- 1324 message status of NotAllowed, or MAY simply close the connection. 1326 If the TCP connection becomes blocked while the server is accepting a 1327 connection or reading a query, it SHOULD be prepared to terminate the 1328 connection after an BULK_LQ_QUERY_TIMEOUT. We make this 1329 recommendation to allow servers to control the period of time they 1330 are willing to wait before abandoning an inactive connection, 1331 independent of the TCP implementations they may be using. 1333 9.2. Replying to a Bulk Leasequery 1335 If the connection becomes blocked while the server is attempting to 1336 send reply messages, the server SHOULD be prepared to terminate the 1337 TCP connection after BULK_LQ_DATA_TIMEOUT. 1339 Every Bulk Leasequery request MUST be terminated by sending a final 1340 DHCPLEASEQUERYDONE message if such a message can be sent. The 1341 DHCPLEASEQUERYDONE message MUST have a dhcp-message status if the 1342 termination was other than successful, and SHOULD NOT contain a 1343 dhcp-message status if the termination was successful. 1345 If the DHCPv4 server encounters an error during processing of the 1346 DHCPBULKLEASEQUERY message, either during initial processing or later 1347 during the message processing, it SHOULD send a DHCPLEASEQUERYDONE 1348 containing a status dhcp-message option. It MAY close the connection 1349 after this error is signaled, but that is not required. 1351 If the server does not find any bindings satisfying a query, it MUST 1352 send a DHCPLEASEQUERYDONE. It SHOULD NOT include a dhcp-message 1353 option with a Success status unless there is a useful string to 1354 include in the dhcp-message option. Otherwise, the server sends each 1355 binding's data in a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message. 1357 The response to a DHCPBULKLEASEQUERY may involve examination of 1358 multiple DHCPv4 IP address bindings maintained by the DHCPv4 server. 1359 The Bulk Leasequery protocol does not require any ordering of the IP 1360 addresses returned in DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED 1361 messages. 1363 A Bulk Leasequery response MUST contain no more than one message for 1364 each configured IP address in the DHCPv4 server. In addition, a Bulk 1365 Leasequery may well take significant time between the beginning and 1366 end of the processing of all of the messages required to satisfy the 1367 Bulk Leasequery query. During this time, the state of some of the IP 1368 addresses sent early in the response may change prior to the 1369 completion of the entire response to the Bulk Leasequery. This is 1370 normal and expected -- there is no requirement for the entire 1371 response to a Bulk Leasequery to represent an instantaneous snapshot 1372 of the state of the IP address bindings of a DHCPv4 server. Quite 1373 the contrary -- as the cursor moves through the IP addresses in 1374 whatever order is convenient to the DHCPv4 server, the state of IP 1375 addresses already examined can change and a DHCPv4 server MUST NOT 1376 try to examine IP addresses already scanned in an attempt to "keep 1377 up" with the ongoing state changes of all of the IP addresses. To do 1378 so would make it difficult to meet the requirement to send only one 1379 message per IP address in response to a Bulk Leasequery and would 1380 also make it difficult to know when to finish the Bulk Leasequery. 1382 If the ciaddr, yiaddr, or siaddr is non-zero in a DHCPBULKLEASEQUERY 1383 request, the request must be terminated immediately by a 1384 DHCPLEASEQUERYDONE message with a dhcp-message status of 1385 MalformedQuery. 1387 Any DHCPBULKLEASEQUERY which has more than one of the following 1388 primary query types specified MUST be terminated immediately by a 1389 DHCPLEASEQUERYDONE message with a dhcp-message status code of 1390 NotAllowed. 1392 The allowable queries in a DHCPBULKLEASEQUERY message are processed 1393 as follows. Note that the descriptions of the primary queries below 1394 must constrained by the actions of any of the three qualifiers 1395 described subsequently as well. 1397 The following table discusses how to process the various queries. 1398 For information on how to identify the query, see the information in 1399 Section 8.2. 1401 o Query by MAC address 1403 Every IP address which has a current binding to a DHCPv4 client 1404 which matches the chaddr, htype, and hlen in the 1405 DHCPBULKLEASEQUERY request MUST be returned in a DHCPLEASEACTIVE 1406 message. 1408 o Query by Client-Id 1410 Every IP address which has a current binding to a DHCPv4 client 1411 which matches the client-id option in the DHCPBULKLEASEQUERY 1412 request MUST be returned in a DHCPLEASEACTIVE message. 1414 o Query by Remote-Id 1416 Every IP address which has a current binding to a DHCPv4 client 1417 which matches the remote-id sub-option of the relay-agent- 1418 information option in the DHCPBULKLEASEQUERY request MUST be 1419 returned in a DHCPLEASEACTIVE message. 1421 o Query by Relay-Id 1423 Every IP address which has a current binding to a DHCPv4 client 1424 which matches the relay-id sub-option of the relay-agent- 1425 information option in the DHCPBULKLEASEQUERY request MUST be 1426 returned in a DHCPLEASEACTIVE message. 1428 o Query for All Configured IP Addresses 1430 A Query for All Configured IP addresses is signaled by the 1431 absence of any other primary query. That is, if there is no 1432 value in the chaddr, hlen, htype, no client-id option, no 1433 remote-id sub-option or relay-id sub-option of the relay-agent- 1434 information option, then the request is a query for information 1435 concerning all configured IP addresses. In this case, every 1436 configured IP address which has a current binding to a DHCPv4 1437 client MUST be returned in a DHCPLEASEACTIVE message. In 1438 addition, every configured IP address which does not have a 1439 current binding to a DHCPv4 client MUST be returned in a 1440 DHCPLEASEUNASSIGNED message. 1442 In this form of query, each configured IP address MUST be 1443 returned at most one time. If the absence of qualifiers which 1444 restrict the number of IP addresses returned, every configured 1445 IP address MUST be returned exactly once. 1447 There are three qualifiers which can be applied to any of the above 1448 primary queries. These qualifiers can appear individually or 1449 together in any combination, but only one of each can appear. 1451 o Query Start Time 1453 If a query-start-time option appears in the DHCPBULKLEASEQUERY 1454 request, only IP address bindings which have changed on or after 1455 the time specified in the query-start-time option should be 1456 returned. 1458 o Query End Time 1460 If a query-end-time option appears in the DHCPBULKLEASEQUERY 1461 request, only IP address bindings which have changed on or before 1462 the time specified in the query-end-time option should be returned. 1464 o VPN Id 1466 If no vpn-id option appears in the DHCPBULKLEASEQUERY, the default 1467 VPN is used to satisfy the query. A vpn-id option [VpnId] value 1468 other than the wildcard value (254) allows the requestor to specify 1469 a single VPN other than the default VPN. In addition, the vpn-id 1470 option has been extended as part of this document to allow 1471 specification of a type 254 which indicates that all configured 1472 VPN's be searched in order to satisfy the primary query. 1474 In all cases, if the information returned in a DHCPLEASEACTIVE or 1475 DHCPLEASEUNASSIGNED message is for other than the default a vpn-id 1476 option MUST appear in the packet. 1478 The query-start-time and query-end-time qualifiers are used to 1479 constrain the amount of data returned by a Bulk Leasequery request by 1480 returning only IP addresses whose address bindings have changed in 1481 some way during the time window specified by the query-start-time and 1482 query-end-time. 1484 A DHCPv4 server SHOULD consider an address binding to have changed 1485 during a specified time window if either the client-last- 1486 transaction-time or the start-time-of-state of the address binding 1487 changed during that time window. 1489 A DHCPv4 server MAY always compare the address binding information 1490 for an IP address against a time window if it follows the following 1491 guidelines. If there is no query-start-time, then the DHCPv4 server 1492 MUST assume the query-start-time is equivalent to a time prior to any 1493 time that resides in any IP address binding. If there is no query- 1494 end-time, the DHCPv4 server MUST assume that the query-end-time is 1495 equivalent to a time that is later than any time that resides in any 1496 IP address binding. 1498 Even if the query-start-time or query-end-time option value is being 1499 used to limit the amount of data flow from the DHCPv4 server to the 1500 requestor, there is no requirement placed on the DHCPv4 server to 1501 return address binding data in any order and certainly not in any 1502 order based on time. 1504 When the DHCPv4 server has no additional information to send to the 1505 requestor, it will send a DHCPLEASEQUERYDONE message. 1507 9.3. Building a Single Reply for Bulk Leasequery 1509 The DHCPv4 Leasequery [RFC4388] specification describes the initial 1510 construction of DHCPLEASEQUERY reply messages using the 1511 DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types in Section 1512 6.4.2. All of the reply messages in Bulk Leasequery are similar to 1513 the reply messages for an IP address query. Message transmission and 1514 framing for TCP is described in this document in Section 7.1. 1516 [RFC2131] and [RFC4388] specify that every response message MUST 1517 contain the server-identifier option. However, that option will be 1518 the identical for every response from a particular DHCPBULKLEASEQUERY 1519 request. Thus, the DHCPv4 server MUST include the server-identifier 1520 option in the first message sent in response to a DHCPBULKLEASEQUERY. 1521 It MAY include the server-identifier in later messages as well, but 1522 there is no requirement for it to do so. 1524 The message type of DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED is based 1525 on the value of the dhcp-state option. If the dhcp-state option 1526 value is ACTIVE, then the message type is DHCPLEASEACTIVE, otherwise 1527 the message type is DHCPLEASEUNASSIGNED. 1529 In addition to the basic message construction described in [RFC4388], 1530 the following guidelines exist: 1532 1. If the dhcp-state option code appears in the dhcp-parameter- 1533 request-list, the DHCPv4 server SHOULD include a dhcp-state 1534 option whose value corresponds most closely to the state held 1535 by the DHCPv4 server for the IP address associated with this 1536 reply. If the state is ACTIVE and the message being returned 1537 in DHCPLEASEACTIVE then the DHCPv4 server MAY choose to not 1538 send the dhcp-state option. The requestor SHOULD assume that 1539 any DHCPLEASEACTIVE message arriving without a requested dhcp- 1540 state option has a dhcp-state of ACTIVE. 1542 2. If the base-time option code appears in the dhcp-parameter- 1543 request-list, the DHCPv4 server MUST include a base-time 1544 option, which is the current time in the DHCPv4 server's 1545 context and the time from which the start-time-of-state, dhcp- 1546 lease-time, client-last-transaction-time, and other duration- 1547 style times are based upon. 1549 3. If the start-time-of-state option code appears in the dhcp- 1550 parameter-request-list, the DHCPv4 server MUST include a 1551 start-time-of-state option whose value represents the time at 1552 which the dhcp-state option's state became valid. 1554 4. If the dhcp-lease-time option code appears in the dhcp- 1555 parameter-request-list, the DHCPv4 server MUST include a dhcp- 1556 lease-time option for any state that has a time-out value 1557 associated with it, and not just appear in a DHCPLEASEACTIVE 1558 message. Thus, the EXPIRED state which is sent in a 1559 DHCPLEASEUNASSIGNED message would have a dhcp-lease-time option 1560 in the message if the EXPIRED state represented a grace-period 1561 and would be changing state after the grace-period expired. 1563 5. If the data-source option code appears in the dhcp-parameter- 1564 request-list, the DHCPv4 server MUST include the data-source 1565 option in any situation where any of the bits would be non- 1566 zero. Thus, in the absence of the data-source option, the 1567 assumption is that all of the flags were zero. 1569 6. If the client-last-transaction-time option code appears in the 1570 dhcp-parameter-request-list, The DHCPv4 server MUST include the 1571 client-last-transaction-time option in any situation where the 1572 information is available. 1574 7. If there is a dhcp-parameter-request-list in the initial 1575 DHCPBULKLEASEQUERY request, then it should be used for all of 1576 the replies generated by that request. Some options can be 1577 sent from a DHCPv4 client to the server or from the DHCPv4 1578 server to a DHCPv4 client. Option 125 is such an option. If 1579 the option code for one of these options appears in the dhcp- 1580 parameter-request-list, it SHOULD result in returning the value 1581 of the option sent by the DHCPv4 client to the server if one 1582 exists. 1584 Note that there may be other requirements for a reply to a 1585 DHCPBULKLEASEQUERY request discussed in Section 9.2. 1587 9.4. Multiple or Parallel Queries 1589 As discussed in Section 8.3, requestors may want to leverage an 1590 existing connection if they need to make multiple queries. Servers 1591 MAY support reading and processing multiple queries from a single 1592 connection. A server MUST NOT read more query messages from a 1593 connection than it is prepared to process simultaneously. 1595 This MAY be a feature that is administratively controlled. Servers 1596 that are able to process queries in parallel SHOULD offer 1597 configuration that limits the number of simultaneous queries 1598 permitted from any one requestor, in order to control resource use if 1599 there are multiple requestors seeking service. 1601 9.5. Closing Connections 1603 The server MAY close its end of the TCP connection after sending its 1604 last message, a DHCPLEASEQUERYDONE message in response to a query. 1605 Alternatively, the server MAY retain the connection and wait for 1606 additional queries from the requestor. The server SHOULD be prepared 1607 to limit the number of connections it maintains, and SHOULD be 1608 prepared to close idle connections to enforce the limit. 1610 The server MUST close its end of the TCP connection if it encounters 1611 an error sending data on the connection. The server MUST close its 1612 end of the TCP connection if it finds that it has to abort an in- 1613 process request. A server aborting an in-process request SHOULD 1614 attempt to signal that to its requestors by using the QueryTerminated 1615 status code in the dhcp-message option in a DHCPLEASEQUERYDONE 1616 message, including a message string indicating details of the reason 1617 for the abort. If the server detects that the requesting end of the 1618 connection has been closed, the server MUST close its end of the 1619 connection after it has finished processing any outstanding requests. 1621 The server MUST send a DHCPLEASEQUERYDONE message at the end of the 1622 data returned from a Bulk Leasequery request. 1624 10. Security Considerations 1626 The "Security Considerations" section of [RFC2131] details the 1627 general threats to DHCPv4. The DHCPv4 Leasequery specification 1628 [RFC4388] describes recommendations for the Leasequery protocol, 1629 especially with regard to relayed LEASEQUERY messages, mitigation of 1630 packet-flooding DOS attacks, restriction to trusted requestors, and 1631 use of IPsec [RFC4301]. 1633 The use of TCP introduces some additional concerns. Attacks that 1634 attempt to exhaust the DHCPv4 server's available TCP connection 1635 resources, such as SYN flooding attacks, can compromise the ability 1636 of legitimate requestors to receive service. Malicious requestors 1637 who succeed in establishing connections, but who then send invalid 1638 queries, partial queries, or no queries at all also can exhaust a 1639 server's pool of available connections. We recommend that servers 1640 offer configuration to limit the sources of incoming connections, 1641 that they limit the number of accepted connections and the number of 1642 in-process queries from any one connection, and that they limit the 1643 period of time during which an idle connection will be left open. 1645 11. IANA Considerations 1647 IANA is requested to assign the following new values for this 1648 document. See Section 7.2 for details. 1650 1. A dhcp-message-type of 14 for DHCPBULKLEASEQUERY. 1652 2. A dhcp-message-type of 15 for DHCPLEASEQUERYDONE. 1654 3. An option code of TBD for base-time. 1656 4. An option code of TBD for start-time-of-state. 1658 5. An option code of TBD for query-start-time. 1660 6. An option code of TBD for query-end-time. 1662 7. An option code of TBD for data-source. 1664 8. An option code of TBD for dhcp-state. 1666 9. Values for dhcp-state: 1668 State 1669 ----- 1670 1 AVAILABLE 1671 2 ACTIVE 1672 3 EXPIRED 1673 4 RELEASED 1674 5 ABANDONED 1675 6 RESET 1676 7 REMOTE 1677 8 TRANSITIONING 1679 10.Values for status code in a constrained dhcp-message option 1680 (option 53): 1682 Name status-code 1683 ---- ----------- 1684 Success 000 1685 UnspecFail 001 1686 QueryTerminated 002 1687 MalformedQuery 003 1688 NotAllowed 004 1690 11.Addtional type field values for the Virtual Subnet Selection 1691 Type and Information [VpnId]: 1693 Type VSS Information format: 1695 0 NVT ASCII VPN identifier 1696 1 RFC2685 VPN-ID 1697 2-253 Not Allowed 1698 NEW -> 254 All VPN's. (wildcard) 1699 255 Global, default VPN. 1701 12. Acknowledgements 1703 This draft is a collaboration between the authors of draft-dtv-dhc- 1704 dhcpv4-bulk-leasequery-00.txt and draft-kkinnear-dhc-dhcpv4-bulk- 1705 leasequery-00.txt. Both documents acknowledged that significant text 1706 as well as ideas were borrowed in whole or in part from the DHCPv6 1707 Bulk Leasequery draft [DHCPv6Bulk]. 1709 13. References 1711 13.1. Normative References 1713 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1714 Requirement Levels", RFC 2119, March 1997. 1716 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 1717 March 1997. 1719 [RFC2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 1720 Extensions", RFC 2132, March 1997. 1722 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 1723 3046, January 2001. 1725 [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet 1726 Protocol", RFC4301, December 2005. 1728 [RFC4388] Woundy, R., K. Kinnear, "Dynamic Host Configuration 1729 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 1731 [RelayId] Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption", 1732 draft-ietf-dhc-relay-id-suboption-04.txt, September 2008. 1734 [VpnId] Kinnear, K., R. Johnson, M. Stapp and J. Kumarasamy, "Virtual 1735 Subnet Selection Options for DHCPv4 and DHCPv6" draft-ietf-dhc- 1736 vpn-option-09.txt, July 2008. 1738 13.2. Informative References 1740 [RFC951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC 1741 951, September 1985. 1743 [RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap 1744 Protocol", RFC 1542, October 1993. 1746 [RFC4614] Duke, M., R. Braden, W. Eddy, and E. Blanton, "A Roadmap 1747 for Transmission Control Protocol (TCP) Specification Documents", 1748 RFC 4614, September 2006. 1750 [DHCPv6Bulk] Stapp, M., "DHCPv6 Bulk Leasequery", draft-ietf-dhc- 1751 dhcpv6-bulk-leasequery-04.txt, October 2008. 1753 14. Authors' Addresses 1755 Kim Kinnear 1756 Cisco Systems 1757 1414 Massachusetts Ave. 1758 Boxborough, Massachusetts 01719 1760 Phone: (978) 936-0000 1762 EMail: kkinnear@cisco.com 1764 Bernie Volz 1765 Cisco Systems 1766 1414 Massachusetts Ave. 1767 Boxborough, Massachusetts 01719 1769 Phone: (978) 936-0000 1771 EMail: volz@cisco.com 1773 Neil Russell 1774 Cisco Systems 1775 1414 Massachusetts Ave. 1777 Boxborough, Massachusetts 01719 1779 Phone: (978) 936-0000 1781 EMail: nrussell@cisco.com 1783 Mark Stapp 1784 Cisco Systems 1785 1414 Massachusetts Ave. 1786 Boxborough, Massachusetts 01719 1788 Phone: (978) 936-0000 1790 EMail: mjs@cisco.com 1792 Ramakrishna Rao DTV 1793 Infosys Technologies Ltd. 1794 44 Electronics City, Hosur Road 1795 Bangalore 560 100 1796 India 1798 EMail: ramakrishnadtv@infosys.com 1799 URI: http://www.infosys.com/ 1801 Bharat joshi 1802 Infosys Technologies Ltd. 1803 44 Electronics City, Hosur Road 1804 Bangalore 560 100 1805 India 1807 EMail: bharat_joshi@infosys.com 1808 URI: http://www.infosys.com/ 1810 Pavan Kurapati 1811 Infosys Technologies Ltd. 1812 44 Electronics City, Hosur Road 1813 Bangalore 560 100 1814 India 1815 EMail: pavan_kurapati@infosys.com 1816 URI: http://www.infosys.com/ 1818 15. Full Copyright Statement 1820 Copyright (C) The IETF Trust (2008). 1822 This document is subject to the rights, licenses and restrictions 1823 contained in BCP 78, and except as set forth therein, the authors 1824 retain all their rights. 1826 This document and the information contained herein are provided on an 1827 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1828 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1829 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1830 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1831 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1832 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1834 16. Intellectual Property 1836 The IETF takes no position regarding the validity or scope of any 1837 Intellectual Property Rights or other rights that might be claimed to 1838 pertain to the implementation or use of the technology described in 1839 this document or the extent to which any license under such rights 1840 might or might not be available; nor does it represent that it has 1841 made any independent effort to identify any such rights. Information 1842 on the procedures with respect to rights in RFC documents can be 1843 found in BCP 78 and BCP 79. 1845 Copies of IPR disclosures made to the IETF Secretariat and any 1846 assurances of licenses to be made available, or the result of an 1847 attempt made to obtain a general license or permission for the use of 1848 such proprietary rights by implementers or users of this 1849 specification can be obtained from the IETF on-line IPR repository at 1850 http://www.ietf.org/ipr. 1852 The IETF invites any interested party to bring to its attention any 1853 copyrights, patents or patent applications, or other proprietary 1854 rights that may cover technology that may be required to implement 1855 this standard. Please address the information to the IETF at 1856 ietf-ipr@ietf.org. 1858 17. Acknowledgment 1860 Funding for the RFC Editor function is provided by the IETF 1861 Administrative Support Activity (IASA). 1863 18. Appendix -- Why a New Leasequery is Required 1865 The three existing query types supported by [RFC4388] do not provide 1866 effective and efficient antispoofing for the scenario discussed in 1867 Section 3. 1869 o Query by Client Identifier 1871 Query by Client Identifier is not possible because the DSLAM would 1872 need to glean the client-identifier. This is not possible since if 1873 we are using a Leasequery, it is because the gleaned information was 1874 lost. On the other hand, we can query by client-identifier when 1875 client sends a DHCPv4 request, but then there may not be any need for 1876 Leasequery as such -- regular gleaning may be enough. 1878 o Query by IP Address 1880 [RFC4388] suggests that it is preferable to use Query by IP Address 1881 when getting downstream traffic. 1883 Query by IP address is not very useful because because downstream 1884 traffic may not exist for the clients on a DSL port. (In most 1885 Internet applications, downstream traffic exists only when a client 1886 sends upstream traffic). In other words, the client will be denied 1887 service until it gets downstream traffic, which may never come. 1889 Query by IP address may be used for upstream traffic. Then whenever 1890 an upstream packet comes whose IP address is unknown to the DSLAM, a 1891 lease query may be initiated. A related question is what to do with 1892 that upstream traffic itself until lease query response comes? If 1893 the traffic is dropped, we may be dropping legitimate traffic. If 1894 the traffic is forwarded, we may be forwarding spoofed packets. Once 1895 the lease response comes, subsequent traffic is handled depending on 1896 the response. If a DHCPLEASEACTIVE response comes, the DSLAM will 1897 accept the traffic. If a DHCPLEASEUNASSIGNED response comes, the 1898 DSLAM will drop the traffic corresponding to the IP address. If a 1899 DHCPLEASEUNKNOWN response comes the DSLAM may drop the traffic 1900 corresponding to the IP address but will have to periodically send 1901 the lease query for that IP address again (additional overhead). The 1902 process is triggered whenever an unknown IP address comes. 1904 Note that the DSLAM needs to keep track of 4 lists of IP addresses: 1905 (1) List of IP addresses for which it got DHCPLEASEACTIVE responses; 1906 (2) List of IP addresses for which it got DHCPLEASEUNASSIGNED 1907 responses; (3) List of IP addresses for which it got DHCPLEASEUNKNOWN 1908 responses; (4) All other IP addresses. 1910 This approach may be acceptable if only legitimate traffic is 1911 received. Consider the case when someone sends packets that uses 1912 spoofed IP addresses. In that case, lease response will be 1913 DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN. [RFC4388] suggests usage of 1914 negative caching in this regard (which involves additional 1915 resources). 1917 In a spoofing type of attack, negative caching information may grow 1918 considerably if attacker varies the source IP address. For each such 1919 new source IP address, traffic will come to slow path, a new lease 1920 query needs to be initiated, response will be processed, and negative 1921 caching needs to be done. That will mean using many resources for 1922 negative caching. 1924 [RFC4388] suggests that if the DSLAM knows the network portion of the 1925 IP addresses that are assigned to its clients, then some amount of 1926 antispoofing can be done in fast path and some lease queries may be 1927 avoided. But as indicated before, that information may not always be 1928 available to DSLAMs. 1930 Effectively, antispoofing support involves considerable slow path 1931 processing and considerable resources tied for negative caching. 1933 [RFC4388] says that DHCPv4 server should be protected from being 1934 flooded with too many Leasequery requests and DSLAM also should not 1935 send too many lease query messages at a time. This would mean that 1936 legitimate requestors may be excessively delayed getting their 1937 information in the face of antispoofing attacks. 1939 It is concluded that antispoofing is neither effective nor efficient 1940 with this query type. 1942 o Query by MAC Address 1944 Query by MAC address can also be used in a way similar to query by IP 1945 address described above. Indeed, query by MAC address may be better 1946 than query by IP address in one sense because of the possible 1947 presence of the associated-ip option in lease responses. (Note that 1948 associated-ip option does not appear in responses for query by IP 1949 address). With associated-ip option DSLAM can get information not 1950 only about the IP address/MAC address that triggered the Leasequery 1951 but also about other IP addresses that are associated with the 1952 original MAC address. That way, when traffic that uses the other IP 1953 addresses comes along, DSLAM is already prepared to deal with them. 1955 Although, query by MAC address is better than query by IP address in 1956 the above respect, it has a specific problem which is not shared by 1957 query by IP address. For a query by MAC address, only two types of 1958 responses are possible: DHCPLEASEUNKNOWN and DHCPLEASEACTIVE; 1959 DHCPLEASEUNASSIGNED is not supported. This is particularly 1960 troublesome when a DHCPv4 server indeed has definitive information 1961 that no IP addresses are associated with the specified MAC address in 1962 the Leasequery, but it is forced to respond with DHCPLEASEUNKNOWN 1963 instead of DHCPLEASEUNASSIGNED. As we have seen above, unlike 1964 DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN requires periodic querying with 1965 DHCPv4 server, an additional overhead. 1967 Moreover, query by MAC address also shares all other issues we 1968 discussed above for query by IP address. 1970 We conclude that existing Leasequery types are not appropriate to 1971 achieve effective and efficient antispoofing in the environment 1972 discussed.