idnits 2.17.1 draft-dtv-dhc-dhcpv4-bulk-leasequery-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1121. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1098. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1105. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1111. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 358 has weird spacing: '...ge-size the...' -- 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 (July 1, 2008) is 5777 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4614 (ref. '4') (Obsoleted by RFC 7414) -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group D. Rao 3 Internet-Draft B. Joshi 4 Expires: January 2, 2009 P. Kurapati 5 Infosys Technologies Ltd. 6 July 1, 2008 8 DHCPv4 bulk lease query 9 draft-dtv-dhc-dhcpv4-bulk-leasequery-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 2, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been 43 extended with a Leasequery capability that allows a client to request 44 information about DHCPv4 bindings. That mechanism is limited to 45 queries for individual bindings. In some situations individual 46 binding queries may not be efficient, or even possible. This 47 document expands on the Leasequery protocol, adding new query types 48 and allowing for bulk transfer of DHCPv4 binding data via TCP. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4.1. Information Acquisition before Data Starts . . . . . . . . 6 57 4.2. Lessen Negative Caching . . . . . . . . . . . . . . . . . 6 58 4.3. Antispoofing in 'Fast Path' . . . . . . . . . . . . . . . 6 59 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 60 6. Interaction Between UDP Leasequery and Bulk Leasequery . . . . 9 61 7. Message and Option Definitions . . . . . . . . . . . . . . . . 10 62 7.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 10 63 7.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 7.2.1. DHCPLEASEDATA . . . . . . . . . . . . . . . . . . . . 12 65 7.2.2. DHCPLEASEDONE . . . . . . . . . . . . . . . . . . . . 12 66 7.2.3. DHCPLEASEQUERYFAIL . . . . . . . . . . . . . . . . . . 12 67 7.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 13 68 7.3.1. QUERY_BY_RELAYID . . . . . . . . . . . . . . . . . . . 13 69 7.3.2. QUERY_BY_REMOTE_ID . . . . . . . . . . . . . . . . . . 14 70 7.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 7.4.1. STATUS-CODE option . . . . . . . . . . . . . . . . . . 14 72 7.5. Connection and Transmission Parameters . . . . . . . . . . 16 73 8. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . . 17 74 8.1. Connecting . . . . . . . . . . . . . . . . . . . . . . . . 17 75 8.2. Forming Queries . . . . . . . . . . . . . . . . . . . . . 17 76 8.3. Processing Replies . . . . . . . . . . . . . . . . . . . . 17 77 8.4. Leasequery Request Completion Criteria . . . . . . . . . . 18 78 8.5. Querying Multiple Servers . . . . . . . . . . . . . . . . 19 79 8.6. Multiple Queries to a Single Server . . . . . . . . . . . 19 80 8.6.1. Example . . . . . . . . . . . . . . . . . . . . . . . 19 81 8.7. Closing Connections . . . . . . . . . . . . . . . . . . . 20 82 9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 21 83 9.1. Accepting Connections . . . . . . . . . . . . . . . . . . 21 84 9.2. Forming Replies . . . . . . . . . . . . . . . . . . . . . 21 85 9.3. Multiple or Parallel Queries . . . . . . . . . . . . . . . 22 86 9.4. Closing Connections . . . . . . . . . . . . . . . . . . . 22 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 89 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 91 13.1. Normative Reference . . . . . . . . . . . . . . . . . . . 27 92 13.2. Informative Reference . . . . . . . . . . . . . . . . . . 27 93 Appendix 1. Why a New Leasequery is Required? . . . . . . . . . . 28 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 95 Intellectual Property and Copyright Statements . . . . . . . . . . 32 97 1. Introduction 99 The DHCPv4 [2] protocol specifies a mechanism for the assignment of 100 IPv4 address and configuration information to IPv4 nodes. DHCPv4 101 servers maintain authoritative binding information. 103 +--------+ 104 | DHCP | +--------------+ 105 | Server |-...-| DSLAM | 106 | | | Relay Agent | 107 +--------+ +--------------+ 108 | | 109 +------+ +------+ 110 |Modem1| |Modem2| 111 +------+ +------+ 112 | | | 113 +-----+ +-----+ +-----+ 114 |Host1| |Host2| |Host3| 115 +-----+ +-----+ +-----+ 117 Figure 1 119 DHCP relay agents snoop DHCP messages and append relay agent 120 information option before relaying it to the configured DHCP Servers 121 (see Figure 1). In this process, some relay agents also glean the 122 lease information sent by the server and maintain this locally. This 123 information is used for prevention of spoofing attempts from the 124 clients and to install routes. When a relay agent reboots, this 125 information is lost. RFC 4388 [5] has defined a mechanism to obtain 126 this lease information from the server. The existing query types in 127 leasequery are data driven; relay agent initiates the leasequery when 128 it receives data traffic from/for the client. This approach does not 129 scale well when there are thousands of clients connected to the relay 130 agent. Different query types are needed where a relay agent can 131 query the server without waiting for the traffic from/for the 132 clients. 134 This document extends the DHCPv4 Leasequery protocol to add support 135 for queries that address these requirements. There may be many 136 thousands of DHCPv4 bindings per relay agent, so we specify the use 137 of TCP [4] for efficiency of data transfer. We specify a new query 138 type that uses the Relay Identifier sub-option to support efficient 139 recovery of all data associated with a specific relay agent. We also 140 specify query-type by Remote-ID sub-option value, to assist a relay 141 agent that needs to recover a subset of its clients' bindings. 143 2. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [1]. 149 DHCPv4 terminology is defined in [2]. DHCPv4 Leasequery terminology 150 is defined in [5]. DUID terminology is in defined in [7]. Relay 151 agent terminalogy is defined in [3]. 153 3. Motivation 155 Consider a typical DSLAM working also as a DHCP relay agent (see 156 Figure 1). "Fast path" and "slow path" generally exist in most 157 networking boxes including DSLAMs. Fast path processing is done in 158 network processor or an ASIC (Application Specific Integrated 159 Circuit). Slow path processing is done in a normal processor. As 160 much as possible, regular data handling code should be in fast path. 161 Slow path processing should be reduced as it may become a bottleneck. 163 For a DSLAM having multiple DSL ports, multiple IP addresses may be 164 assigned using DHCP to a single port and the number of clients on a 165 port may be unknown. The DSLAM may also not know the network 166 portions of the IP addresses that are assigned to its DHCP clients. 168 The DSLAM gleans IP address or other information from DHCP 169 negotiations for antispoofing and for other purposes. The 170 antispoofing itself is done in fast path. DSLAM keeps track of only 171 one list of IP addresses: list of IP addresses that are assigned by 172 DHCP server. Traffic for all other IP addresses is dropped. If 173 client starts its data transfer after its DHCP negotiations are 174 gleaned by DSLAM, no legitimate packets will be dropped because of 175 antispoofing. In other words, antispoofing is effective (no 176 legitimate packets are dropped and all spoofed packets are dropped) 177 and efficient (antispoofing is done in fast path). The intention is 178 to achieve similar effective and efficient antispoofing in the lease 179 query scenario also when a DSLAM loses its gleaned information (for 180 example, because of reboot). 182 After a deep analysis, we found that the three existing query types 183 supported by RFC 4388 [5] do not provide effective and efficient 184 antispoofing for the above scenario and a new mechanism is required. 186 The existing query types 188 o necessitate a data driven approach: the lease queries can only be 189 done when the Access Concentrator receives data. That results in 190 increased outage time for clients. 192 o result in excessive negative caching consuming lot of resources 193 under a spoofing attack. 195 o result in antispoofing being done in slow path instead of fast 196 path. 198 The deeper analysis, which led to the above conclusions, itself 199 appears as an Appendix to this document. 201 4. Design Goals 203 The goal of this document is to provide a lightweight mechanism for 204 an Access Concentrator to retrieve lease information available in the 205 DHCP server. The mechanism should also support an Access 206 Concentrator to retrieve consolidated lease information for the 207 entire access concentrator or for a connection/circuit. 209 4.1. Information Acquisition before Data Starts 211 Existing data driven approach by RFC 4388 [5] means that the lease 212 queries can only be done when an Access Concentrator receives data. 213 For antispoofing, packets need to be dropped until it gets the lease 214 information from DHCP server. If an Access Concentrator finishes the 215 lease queries before it starts receiving data, then there is no need 216 to drop legitimate packets. So, effectively outage time may be 217 reduced. 219 4.2. Lessen Negative Caching 221 If lease queries result in negative caches, then that puts additional 222 overhead on the access concentrator. The negative caches not only 223 consume precious resources they also need to be managed. Hence they 224 should be avoided as much as possible. The lease queries should 225 reduce the need for negative caching as far as possible. 227 4.3. Antispoofing in 'Fast Path' 229 If Antispoofing is not done in fast path, it will become a bottleneck 230 and may lead to denial of service of the access concentrator. The 231 lease queries should make it possible to do antispoofing in fast 232 path. 234 5. Protocol Overview 236 The Bulk Leasequery mechanism is modeled on the existing individual 237 Leasequery protocol described in RFC 4388[5]; most differences arise 238 from the use of TCP. A Bulk Leasequery client opens a TCP connection 239 to a DHCPv4 Server, using the DHCPv4 port 67. Note that this implies 240 that the Leasequery client has server IP address(es) available via 241 configuration or some other means, and that it has unicast IP 242 reachability to the server. No relaying for bulk leasequery is 243 specified. 245 After establishing a connection, the client sends a DHCPLEASEQUERY 246 message containing a query-type and data about bindings it is 247 interested in. The server uses the query-type and the data to 248 identify any relevant bindings. In order to support some query- 249 types, servers may have to maintain additional data structures or be 250 able to locate bindings based on specific option data. The server 251 replies with a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, 252 DHCPLEASEQUERYFAIL, or DHCPLEASEUNKNOWN. The reasons why a 253 DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message 254 might be generated are explained in [5] and below. The reasons why a 255 DHCPLEASEQUERYFAIL message might be generated are explained below. 256 If the query was successful, the server includes the first client's 257 binding data in a DHCPLEASEACTIVE message. If more than one client's 258 bindings are being returned, the server then transmits the additional 259 client bindings in a series of DHCPLEASEDATA messages. If the server 260 has sent at least one client's bindings, it sends a DHCPLEASEDONE 261 message when it has finished sending its replies. The client may 262 reuse the connection to send additional queries. Each end of the TCP 263 connection can be closed after all data has been sent. 265 The Relay-ID sub-option is defined in [6]. The sub-option contains a 266 DUID identifying a DHCPv4 relay agent. Relay agents can include this 267 sub-option while relaying messages to DHCPv4 servers. Servers can 268 retain the Relay-ID and associate it with bindings made on behalf of 269 the relay agent's clients. A relay agent can then recover binding 270 information about downstream clients by using the Relay-ID in a 271 DHCPLEASEQUERY message. 273 Bulk Leasequery supports the queries by IPv4 address, MAC address, 274 and Client Identifier as specified in RFC4388 [5]. The Bulk 275 Leasequery protocol also adds two new queries. 277 o Query by Relay Identifier 279 This query asks a server for the bindings associated with a specific 280 relay agent; the relay agent is identified by a DUID carried in a 281 Relay-ID sub-option. 283 o Query by Remote ID 285 This query asks a server for the bindings associated with a Relay 286 Agent Remote-ID sub-option [3] value. 288 6. Interaction Between UDP Leasequery and Bulk Leasequery 290 Bulk Leasequery can be seen as an extension of the existing UDP 291 Leasequery protocol [5]. This section tries to clarify the 292 relationship between the two protocols. 294 The query-types introduced in the UDP Leasequery protocol can be used 295 in the Bulk Leasequery protocol. One change in behavior is required 296 when Bulk Leasequery is used. RFC4388 [5], in sections 6.1, 6.4.1, 297 and 6.4.2 specifies the use of an associated-ip option in 298 DHCPLEASEACTIVE messages in cases where multiple bindings were found. 299 When Bulk Leasequery is used, this mechanism is not necessary: a 300 server returning multiple bindings simply does so directly as 301 specified in this document. The associated-ip option MUST NOT appear 302 in Bulk Leasequery replies. 304 Only DHCPLEASEQUERY, DHCPLEASEACTIVE, DHCPLEASEUNASSIGNED, 305 DHCPLEASEUNKNOWN, DHCPLEASEDATA, DHCPLEASEQUERYFAIL, and 306 DHCPLEASEDONE messages are allowed over the Bulk Leasequery 307 connection. No other DHCPv4 messages are supported. The Bulk 308 Leasequery connection is not an alternative DHCPv4 communication 309 option for clients seeking DHCPv4 service. 311 7. Message and Option Definitions 313 7.1. Message Framing for TCP 315 The use of TCP for the Bulk Leasequery protocol permits one or more 316 DHCPv4 messages to be sent at a time. The receiver needs to be able 317 to determine how large each message is. Four octets, out of which 318 the first two octets contain the message size in network byte-order, 319 are prepended to each DHCPv4 message sent on a Bulk Leasequery TCP 320 connection. The four octets 'frame' each DHCPv4 message. 322 DHCPv4 message framed for TCP: 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | message-size | unused | 328 +---------------+---------------+---------------+---------------+ 329 | op (1) | htype (1) | hlen (1) | hops (1) | 330 +---------------+---------------+---------------+---------------+ 331 | xid (4) | 332 +-------------------------------+-------------------------------+ 333 | secs (2) | flags (2) | 334 +-------------------------------+-------------------------------+ 335 | ciaddr (4) | 336 +---------------------------------------------------------------+ 337 | yiaddr (4) | 338 +---------------------------------------------------------------+ 339 | siaddr (4) | 340 +---------------------------------------------------------------+ 341 | giaddr (4) | 342 +---------------------------------------------------------------+ 343 | | 344 | chaddr (16) | 345 | | 346 | | 347 +---------------------------------------------------------------+ 348 | | 349 | sname (64) | 350 +---------------------------------------------------------------+ 351 | | 352 | file (128) | 353 +---------------------------------------------------------------+ 354 | | 355 | options (variable) | 356 +---------------------------------------------------------------+ 358 message-size the number of octets in the message that 359 follows (excluding the two unused bytes), as a 360 16-bit integer in network byte-order. 361 unused these 16 bits are unused; they should be set to 362 zero by sender and ignored by receiver. 364 All other fields are as specified in DHCPv4 [2]. 366 7.2. Messages 368 The DHCPLEASEQUERY, DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN, and 369 DHCPLEASEACTIVE messages are defined in RFC4388 [5]. In a Bulk 370 Leasequery exchange, a single DHCPLEASEUNASSIGNED, 371 DHCPLEASEQUERYFAIL, or DHCPLEASEUNKNOWN message is used to indicate 372 the failure of a query. A single DHCPLEASEACTIVE message is used to 373 indicate the success of a query, and contains the first client's 374 binding data. It also carries data that do not change in the context 375 of a single query and answer, such as the Server Identifier (option 376 54) option. 378 7.2.1. DHCPLEASEDATA 380 The DHCPLEASEDATA message (message type TBD) carries data about a 381 single DHCPv4 client's leases and bindings. The purpose of the 382 message is to reduce redundant data when there are multiple bindings 383 to be sent. The DHCPLEASEDATA message MUST be preceded by a 384 DHCPLEASEACTIVE message. The DHCPLEASEACTIVE carries the 385 Leasequery's Server Identifier options, and carries the first 386 client's binding data if the query was successful. 388 DHCPLEASEDATA MUST ONLY be sent in response to a successful 389 DHCPLEASEQUERY, and only if more than one client's data is to be 390 sent. The DHCPLEASEDATA message's xid field MUST match the xid of 391 the DHCPLEASEQUERY request message. The Server Identifier option 392 SHOULD NOT be included: that data should be constant for any one Bulk 393 Leasequery reply, and should have been conveyed in the 394 DHCPLEASEACTIVE message. 396 7.2.2. DHCPLEASEDONE 398 The DHCPLEASEDONE message (message type TBD) indicates the end of a 399 group of related Leasequery replies. The DHCPLEASEDONE message's xid 400 field MUST match the xid of the DHCPLEASEQUERY request message. The 401 presence of the message itself signals the end of a stream of reply 402 messages. A single DHCPLEASEDONE MUST be sent after all replies (a 403 DHCPLEASEACTIVE and zero or more DHCPLEASEDATA messages) to a 404 successful Bulk Leasequery request that returned at least one 405 binding. Other DHCPv4 options SHOULD NOT be included in the 406 DHCPLEASEDONE message. 408 7.2.3. DHCPLEASEQUERYFAIL 410 A server may encounter an error condition while processing a 411 DHCPLEASEQUERY message but before it has sent any response. A server 412 may also encounter an error condition after it has sent the initial 413 DHCPLEASEACTIVE. In these cases, it SHOULD attempt to send a 414 DHCPLEASEQUERYFAIL (message type TBD) with STATUS_CODE option 415 indicating the error condition to the requestor. Other DHCPv4 416 options SHOULD NOT be included in the DHCPLEASEQUERYFAIL message. 418 7.3. Query Types 420 We introduce the following new query-types: QUERY_BY_RELAYID and 421 QUERY_BY_REMOTE_ID. These queries are designed to assist relay 422 agents in recovering binding data in circumstances where some or all 423 of the relay agent's binding data has been lost. 425 7.3.1. QUERY_BY_RELAYID 427 This query asks the server to return bindings associated with the 428 specified relay DUID. A relay agent MAY include the option in the 429 messages it relays. Obviously, it will not be possible for a server 430 to respond to QUERY_BY_RELAYID queries unless the relay agent has 431 included this option. A relay agent SHOULD be able to generate a 432 DUID for this purpose, and capture the result in stable storage. A 433 relay agent SHOULD also allow the DUID value to be configurable: 434 doing so allows an administrator to replace a relay agent while 435 retaining the association between the relay agent and existing DHCPv4 436 bindings. 438 A DHCPv4 Server MAY associate Relay-ID sub-options from relayed 439 messages it processes with lease bindings that result. Doing so 440 allows it to respond to QUERY_BY_RELAYID Leasequeries. 442 QUERY_BY_RELAYID message is formatted as follows: 444 o The requester supplies only an option 82 which will include only 445 an Agent Relay ID sub-option in the DHCPLEASEQUERY message. The 446 query options MUST contain a RELAYID sub-option. 448 o The "ciaddr" field MUST be set to zero. 450 o The values of htype, hlen, and chaddr MUST be set to zero. 452 o The Client-identifier option (option 61) MUST NOT appear in the 453 packet. 455 The DHCP server replies with a DHCPLEASEACTIVE message if the DHCP 456 server has one or multiple active leases which were assigned through 457 the Relay Agent identified by Relay ID in the DHCPLEASEQUERY message. 458 If the Server has recorded Relay-ID values with its bindings, it uses 459 the sub-option's value to identify bindings to return. Server 460 replies with a DHCPLEASEUNASSIGNED if it has information of the said 461 relay ID but no lease is associated with the same. Server replies 462 with a DHCPLEASEUNKNOWN message if it has no information of the said 463 relay ID. 465 7.3.2. QUERY_BY_REMOTE_ID 467 The QUERY_BY_REMOTE_ID is used to ask the server to return bindings 468 associated with a Remote-ID sub-option value from a relayed message. 469 QUERY_BY_REMOTE_ID for TCP defined in this draft is consistent with 470 QUERY_BY_REMOTE_ID for UDP defined in [9]. 472 In order to support this query, a server needs to record the most- 473 recent Remote-ID sub-option value seen in a relayed message along 474 with its other binding data. 476 QUERY_BY_REMOTE_ID message is formatted as follows: 478 o There MUST be only a Relay Agent Information option (option 82) 479 with only Agent Remote ID sub-option (sub-option 2) in the 480 DHCPLEASEQUERY message. 482 o The "ciaddr" field MUST be set to zero. 484 o The values of htype, hlen, and chaddr MUST be set to zero. 486 o The Client-identifier option (option 61) MUST NOT appear in the 487 packet. 489 The DHCP server replies with a DHCPLEASEACTIVE message if the Agent 490 Remote ID in the DHCPLEASEQUERY message currently has an active lease 491 on an IP address in this DHCP server. Server replies with a 492 DHCPLEASEUNASSIGNED if it has information of the said remote ID but 493 no lease is associated with the same. Server replies with a 494 DHCPLEASEUNKNOWN message if it has no information of the said remote 495 ID. If the Server has recorded Remote-ID values with its bindings, 496 it uses the sub-option's value to identify bindings to return. 498 7.4. Options 500 7.4.1. STATUS-CODE option 502 This option returns a status indication related to the DHCP message. 503 Currently it is used along with DHCPLEASEQUERYFAIL message. 505 The format of the Status Code option is: 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | STATUS_CODE | option-len | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | status-code | | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 514 . . 515 . status-message . 516 . . 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 option-code STATUS_CODE (TBD). 521 option-len 2 + length of status-message. 523 status-code The numeric code for the status encoded in 524 this option. The status codes are defined below. 526 status-message A UTF-8 encoded text string suitable for 527 display to an end user, which MUST NOT be 528 null-terminated. 530 A Status Code option may appear in the options field of a DHCP 531 message. If the Status Code option does not appear in a message 532 in which the option could appear, the status of the message is 533 assumed to be Success. 535 The following status codes are defined: 537 Name Code Description 538 ---------- ---- ----------- 539 Success 0 Success. 540 UnspecFail 1 Failure, reason unspecified; this 541 status code is sent by either a client 542 or a server to indicate a failure 543 not explicitly specified in this 544 document. 545 UnknownQueryType 2 The query-type is unknown to or not supported 546 by the server. 547 MalformedQuery 3 The query is not valid; for example, a 548 required query option is missing. 549 NotAllowed 4 The server does not allow the requestor to 550 issue this DHCPLEASEQUERY 551 QueryTerminated 5 Indicates that the server is unable to perform 552 a query or has prematurely terminated the query 553 for some reason (which should be communicated 554 in the text message). This may be because the 555 server is short of resources or is being shut 556 down. The requestor may retry the query at a 557 later time. The requestor should wait at least 558 a short interval before retrying. Note that 559 while a server may simply prematurely close 560 its end of the connection, it is preferable 561 for the server to send a DHCPLEASEQUERYFAIL 562 with this status-code to notify the requestor 563 of the condition. 565 7.5. Connection and Transmission Parameters 567 DHCPv4 Servers that support Bulk Leasequery SHOULD listen for 568 incoming TCP connections on the DHCPv4 server port 67. 569 Implementations MAY offer to make the incoming port configurable, but 570 port 67 MUST be the default. Client implementations SHOULD make TCP 571 connections to port 67, and MAY offer to make the destination server 572 port configurable. 574 This section presents a table of values used to control Bulk 575 Leasequery behavior, including recommended defaults. Implementations 576 MAY make these values configurable. 578 Parameter Default Description 579 ------------------------------------------------------------------ 580 BULK_LQ_CONN_TIMEOUT 30 secs Bulk Leasequery connection timeout 581 BULK_LQ_DATA_TIMEOUT 30 secs Bulk Leasequery data timeout 582 BULK_LQ_MAX_RETRY 60 secs Max Bulk Leasequery retry timeout 583 BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections 585 8. Requestor Behavior 587 8.1. Connecting 589 A Requestor attempts to establish a TCP connection to a DHCPv4 Server 590 in order to initiate a Leasequery exchange. The Requestor SHOULD be 591 prepared to abandon the connection attempt after 592 BULK_LQ_CONN_TIMEOUT. If the attempt fails, the Requestor MAY retry. 593 Retries MUST use an exponential backoff timer, increasing the 594 interval between attempts up to BULK_LQ_MAX_RETRY. 596 8.2. Forming Queries 598 After a connection is established, the Requestor constructs a 599 Leasequery message, as specified in [5]. The query may have any of 600 the defined query-types, and includes the options and data required 601 by the query-type chosen. The Requestor sends the message size, 16 602 reserved bits (zeroes), and then sends the actual DHCPv4 message, as 603 described in Section 7.1. 605 If the TCP connection becomes blocked while the Requestor is sending 606 its query, the Requestor SHOULD be prepared to terminate the 607 connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation 608 to allow Requestors to control the period of time they are willing to 609 wait before abandoning a connection, independent of notifications 610 from the TCP implementations they may be using. 612 8.3. Processing Replies 614 The Requestor attempts to read a DHCPLEASEACTIVE, DHCPLEASEUNKNOWN, 615 DHCPLEASEQUERYFAIL, or DHCPLEASEUNASSIGNED message from the TCP 616 connection. If the stream of replies becomes blocked, the Requestor 617 SHOULD be prepared to terminate the connection after 618 BULK_LQ_DATA_TIMEOUT, and MAY begin retry processing if configured to 619 do so. 621 The Requestor examines the DHCPLEASEACTIVE, DHCPLEASEUNKNOWN, 622 DHCPLEASEQUERYFAIL, or DHCPLEASEUNASSIGNED message, and determines 623 how to proceed. If the xid in the received message does not match an 624 outstanding DHCPLEASEQUERY message, the client MUST close the TCP 625 connection. Message processing rules for DHCPLEASEACTIVE are 626 specified in DHCPv4 Leasequery [5]. DHCPLEASEUNKNOWN and 627 DHCPLEASEUNASSIGNED replies indicate that the target server had no 628 bindings matching the query. DHCPLEASEQUERYFAIL indicates that the 629 server failed to serve the client. More details will be available in 630 the received STATUS_CODE option. 632 The Leasequery protocol [5] uses the associated-ip option as an 633 indicator that multiple bindings were present in response to a single 634 query. For Bulk Leasequery, the associated-ip option is not used, 635 and MUST NOT be present in replies. 637 A successful DHCPLEASEACTIVE that is returning binding data is 638 created as specified in [5]. If there are additional bindings to be 639 returned, they will be carried in DHCPLEASEDATA messages. Each 640 DHCPLEASEDATA message returns binding data and is prepared just like 641 the DHCPLEASEACTIVE message described in [5] except for the new 642 message type. 644 A single bulk query can result in a large number of replies. For 645 example, a single relay agent might be responsible for thousands of 646 DHCP clients. The Requestor MUST be prepared to receive more than 647 one DHCPLEASEDATA with xids matching a single DHCPLEASEQUERY message. 649 The DHCPLEASEDONE message ends a successful Bulk Leasequery request 650 that returned at least one binding. DHCPLEASEUNKNOWN and 651 DHCPLEASEUNASSIGNED MUST NOT be followed by a DHCPLEASEDONE message 652 for the same xid. After receiving DHCPLEASEDONE from a server, the 653 Requestor MAY close the TCP connection to that server. If the xid in 654 the DHCPLEASEDONE does not match an outstanding DHCPLEASEQUERY 655 message, the client MUST close the TCP connection. 657 The DHCPLEASEQUERYFAIL message ends a Bulk Leasequery request in 658 failure. Depending on the status code, the requestor may try a 659 different server (such as for NotAllowed and UnknownQueryType), try a 660 different or corrected query (such as for UnknownQueryType and 661 MalformedQuery), or terminate the query. If the xid in the 662 DHCPLEASEQUERYFAIL does not match an outstanding DHCPLEASEQUERY 663 message, the client MUST close the TCP connection. 665 8.4. Leasequery Request Completion Criteria 667 This section provides rules for when a DHCPLEASEQUERY request is 668 complete. 670 A DHCPLEASEQUERY request is complete for a requestor (i.e., no 671 further messages for that request will be received): 673 o If it receives a DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN, 674 DHCPLEASEDONE, or DHCPLEASEQUERYFAIL message. 676 o If the connection is closed. 678 8.5. Querying Multiple Servers 680 A Bulk Leasequery client MAY be configured to attempt to connect to 681 and query from multiple DHCPv4 servers in parallel. Binding data 682 received from multiple DHCPv4 servers may need to be reconciled. 684 The client data from the different servers may be disjoint or 685 overlapping. 687 When using the DHCPLEASEQUERY message in an environment where 688 multiple DHCP servers may contain authoritative information about the 689 same IP address (such as when two DHCP servers are cooperating to 690 provide a high-availability DHCP service), multiple, possibly 691 conflicting, responses might be received. 693 In this case, some information in the response packet SHOULD be used 694 to decide among the various responses. The client-last-transaction- 695 time (if it is available) can be used to decide which server has more 696 recent information concerning the IP address returned in the "ciaddr" 697 field. 699 If the requestor receives disjoint client data from different 700 sources, it SHOULD merge them. 702 8.6. Multiple Queries to a Single Server 704 Bulk Leasequery clients may need to make multiple queries in order to 705 recover binding information. A Requestor MAY use a single connection 706 to issue multiple queries. Each query MUST have a unique xid. A 707 server MAY process more than one query at a time. A server that is 708 willing to do so MAY interleave replies to the multiple queries 709 within the stream of reply messages it sends. Clients need to be 710 aware that replies for multiple queries may be interleaved within the 711 stream of reply messages. Clients that are not able to process 712 interleaved replies (based on xid) MUST NOT send more than one query 713 at a time. Requestors should be aware that servers are not required 714 to process queries in parallel, and that servers are likely to limit 715 the rate at which they process queries from any one Requestor. 717 8.6.1. Example 719 This example illustrates what a series of queries and responses might 720 look like. This is only an example - there is no requirement that 721 this sequence must be followed, or that clients or servers must 722 support parallel queries. 724 In the example session, the client sends four queries after 725 establishing a connection. Query 1 results in a failure; query 2 726 succeeds and the stream of replies concludes before the client issues 727 any new query. Query 3 and query 4 overlap, and the server 728 interleaves its replies to those two queries. 730 Client Server 731 ------ ------ 732 DHCPLEASEQUERY xid 1 -----> 733 <----- DHCPLEASEUNKNOWN xid 1 734 DHCPLEASEQUERY xid 2 -----> 735 <----- DHCPLEASEACTIVE xid 2 736 <----- DHCPLEASEDATA xid 2 737 <----- DHCPLEASEDATA xid 2 738 <----- DHCPLEASEDONE xid 2 739 DHCPLEASEQUERY xid 3 -----> 740 DHCPLEASEQUERY xid 4 -----> 741 <----- DHCPLEASEACTIVE xid 4 742 <----- DHCPLEASEDATA xid 4 743 <----- DHCPLEASEACTIVE xid 3 744 <----- DHCPLEASEDATA xid 4 745 <----- DHCPLEASEDATA xid 3 746 <----- DHCPLEASEDONE xid 3 747 <----- DHCPLEASEDATA xid 4 748 <----- DHCPLEASEDONE xid 4 750 8.7. Closing Connections 752 The Requestor MAY close its end of the TCP connection after sending a 753 DHCPLEASEQUERY message to the server. The Requestor MAY choose to 754 retain the connection if it intends to issue additional queries. 755 Note that this client behavior does not guarantee that the connection 756 will be available for additional queries: the server might decide to 757 close the connection based on its own configuration. 759 9. Server Behavior 761 9.1. Accepting Connections 763 Servers that implement DHCPv4 Bulk Leasequery listen for incoming TCP 764 connections. Port numbers are discussed in Section 7.5. Servers 765 MUST be able to limit the number of currently accepted and active 766 connections. The value BULK_LQ_MAX_CONNS MUST be the default; 767 implementations MAY permit the value to be configurable. 769 Servers MAY restrict Bulk Leasequery connections and DHCPLEASEQUERY 770 messages to certain clients. Connections not from permitted clients 771 SHOULD be closed immediately, to avoid server connection resource 772 exhaustion. Servers MAY restrict some clients to certain query 773 types. Servers MAY reply to queries that are not permitted with the 774 DHCPLEASEQUERYFAIL message with the NotAllowed status code, or MAY 775 close the connection. 777 If the TCP connection becomes blocked while the server is accepting a 778 connection or reading a query, it SHOULD be prepared to terminate the 779 connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation 780 to allow Servers to control the period of time they are willing to 781 wait before abandoning an inactive connection, independent of the TCP 782 implementations they may be using. 784 9.2. Forming Replies 786 The DHCPv4 Leasequery [5] specification describes the initial 787 construction of DHCPLEASEACTIVE, DHCPLEASEUNKNOWN, and 788 DHCPLEASEUNASSIGNED messages and the processing of 789 QUERY_BY_IP_ADDRESS, QUERY_BY_MAC_ADDRESS, and 790 QUERY_BY_CLIENTIDENTIFIER. Use of the DHCPLEASEACTIVE and 791 DHCPLEASEDATA messages to carry multiple bindings are described in 792 Section 7.2. Message transmission and framing for TCP is described 793 in Section 7.1. If the connection becomes blocked while the server 794 is attempting to send reply messages, the server SHOULD be prepared 795 to terminate the TCP connection after BULK_LQ_DATA_TIMEOUT. 797 If the server encounters an error during initial query processing, 798 before any reply has been sent, it SHOULD send a DHCPLEASEQUERYFAIL 799 containing an appropriate STATUS_CODE option. This signals to the 800 requestor that no data will be returned. If the server encounters an 801 error while processing a query that has already resulted in one or 802 more reply messages, the server SHOULD send a DHCPLEASEQUERYFAIL 803 containing an appropriate STATUS_CODE option. The server SHOULD 804 close its end of the connection as an indication that it was not able 805 to complete query processing. 807 If the server does not recognize the identifier (relay id or remote 808 id) in a query, it SHOULD send a DHCPLEASEUNKNOWN. If the server 809 recognizes the identifier in a query but does not find any bindings 810 satisfying a query, it SHOULD send a DHCPLEASEUNASSIGNED. Otherwise, 811 the server sends each binding's data in a reply message. The first 812 reply message is a DHCPLEASEACTIVE. The binding data is carried as 813 specified in [5] and extended below. The server returns subsequent 814 bindings in DHCPLEASEDATA messages. 816 For QUERY_BY_RELAYID, the server locates each binding associated with 817 the query's Relay-ID sub-option value. In order to give a meaningful 818 reply to a QUERY_BY_RELAYID, the server has to be able to maintain 819 this association in its DHCPv4 binding data. 821 For QUERY_BY_REMOTE_ID, the server locates each binding associated 822 with the query's Relay Remote-ID sub-option value. In order to be 823 able to give meaningful replies to this query, the server has to be 824 able to maintain this association in its binding database. 826 The server sends the DHCPLEASEDONE message as specified in Section 827 7.2. 829 9.3. Multiple or Parallel Queries 831 As discussed in Section 6.5, Requestors may want to leverage an 832 existing connection if they need to make multiple queries. Servers 833 MAY support reading and processing multiple queries from a single 834 connection. A server MUST NOT read more query messages from a 835 connection than it is prepared to process simultaneously. 837 This MAY be a feature that is administratively controlled. Servers 838 that are able to process queries in parallel SHOULD offer 839 configuration that limits the number of simultaneous queries 840 permitted from any one Requestor, in order to control resource use if 841 there are multiple Requestors seeking service. 843 9.4. Closing Connections 845 The server MAY close its end of the TCP connection after sending its 846 last message (a DHCPLEASEUNASSIGNED, a DHCPLEASEUNKNOWN, 847 DHCPLEASEQUERYFAIL, or a DHCPLEASEDONE) in response to a query. 848 Alternatively, the server MAY retain the connection and wait for 849 additional queries from the client. The server SHOULD be prepared to 850 limit the number of connections it maintains, and SHOULD be prepared 851 to close idle connections to enforce the limit. 853 The server MUST close its end of the TCP connection if it encounters 854 an error sending data on the connection. The server MUST close its 855 end of the TCP connection if it finds that it has to abort an in- 856 process request. A server aborting an in-process request MAY attempt 857 to signal that to its clients by using the DHCPLEASEQUERYFAIL message 858 type (Section 7.2.3). If the server detects that the client end has 859 been closed, the server MUST close its end of the connection after it 860 has finished processing any outstanding requests from the client. 862 10. Security Considerations 864 The "Security Considerations" section of [2] details the general 865 threats to DHCPv4. The DHCPv4 Leasequery specification [5] describes 866 recommendations for the Leasequery protocol, especially with regard 867 to DHCPLEASEQUERY messages, mitigation of packet-flooding DOS 868 attacks, and restriction to trusted clients. 870 The use of TCP introduces some additional concerns. Attacks that 871 attempt to exhaust the DHCPv4 server's available TCP connection 872 resources, such as SYN flooding attacks, can compromise the ability 873 of legitimate clients to receive service. Malicious clients who 874 succeed in establishing connections, but who then send invalid 875 queries, partial queries, or no queries at all also can exhaust a 876 server's pool of available connections. We recommend that servers 877 offer configuration to limit the sources of incoming connections, 878 that they limit the number of accepted connections and the number of 879 in-process queries from any one connection, and that they limit the 880 period of time during which an idle connection will be left open. 882 11. IANA Considerations 884 IANA is requested to assign a new DHCPv4 Option Code in the registry 885 maintained in http://www.iana.org/assignments/bootp-dhcp-parameters: 887 o STATUS_CODE 889 IANA is requested to assign the following values for the STATUS_CODE 890 option maintained in 891 http://www.iana.org/assignments/bootp-dhcp-parameters: 893 Success 0 894 UnspecFail 1 895 UnknownQueryType 2 896 MalformedQuery 3 897 NotAllowed 4 898 QueryTerminated 5 900 IANA is requested to assign values for the following new DHCPv4 901 Message types in the Message Type option (option 53) in the registry 902 maintained in http://www.iana.org/assignments/bootp-dhcp-parameters: 904 o DHCPLEASEDONE 905 o DHCPLEASEDATA 906 o DHCPLEASEQUERYFAIL 908 12. Acknowledgments 910 The bulk lease query protocol for DHCPv4 described in this draft is 911 inspired by the bulk lease query protocol defined for DHCPv6 [8] by 912 Mark Stapp and liberally borrows from that draft. We also use the 913 protocol mechanisms proposed in RFC 4388 [5] by R. Woundy and K. 914 Kinnear. 916 13. References 918 13.1. Normative Reference 920 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 921 Levels", BCP 14, RFC 2119, March 1997. 923 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 924 March 1997. 926 [3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 927 January 2001. 929 [4] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for 930 Transmission Control Protocol (TCP) Specification Documents", 931 RFC 4614, September 2006. 933 [5] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol 934 (DHCP) Leasequery", RFC 4388, February 2006. 936 [6] Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption", 937 IETF draft, June 2008. 939 [7] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 940 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 941 RFC 31315, July 2003. 943 13.2. Informative Reference 945 [8] Stapp, M., "DHCPv6 Bulk Leasequery", IETF draft, June 2008. 947 [9] Kurapati, P., Desetti, R., and B. Joshi, "DHCPv4 Leasequery by 948 relay agent remote ID", IETF draft, June 2008. 950 1. Why a New Leasequery is Required? 952 The three existing query types supported by RFC 4388 [5] do not 953 provide effective and efficient antispoofing for the above scenario. 955 o Query by Client Identifier 957 Query by Client Identifier is not possible because to use that DSLAM 958 need to glean client identifier also but the whole issue is that we 959 need leasequeries because the gleaned information was lost. On the 960 other hand, we can query by client identifier when client sends a 961 DHCP request, but then there may not be any need for lease query as 962 such -- regular gleaning may be enough. 964 o Query by IP Address 966 RFC 4388 [5] suggests that it is preferable to use Query by IP 967 Address when getting downstream traffic. 969 Query by IP address is not very useful in downstream traffic because 970 downstream traffic may not exist for the clients on a DSL port. (In 971 most Internet applications, downstream traffic exists only when a 972 client sends upstream traffic). In other words, the client will be 973 denied service until it gets downstream traffic, which may never 974 come. 976 Query by IP address may be used for upstream traffic. Then whenever 977 an upstream packet comes whose IP address is unknown to the DSLAM, a 978 lease query may be initiated. A related question is what to do with 979 that upstream traffic itself until lease query response comes? If 980 the traffic is dropped, we may be dropping legitimate traffic. If 981 the traffic is forwarded, we may be forwarding spoofed packets. Once 982 the lease response comes, subsequent traffic is handled depending on 983 the response. If a DHCPLEASEACTIVE response comes, DSLAM will accept 984 the traffic. If a DHCPLEASEUNASSIGNED response comes, DSLAM will 985 drop the traffic corresponding to the IP address. If a 986 DHCPLEASEUNKNOWN response comes DSLAM may drop the traffic 987 corresponding to the IP address but will have to periodically send 988 the lease query for that IP address again (additional overhead). The 989 process is triggered whenever an unknown IP address comes. 991 Note that DSLAM needs to keep track of 4 lists of IP addresses: (1) 992 List of IP addresses for which it got DHCPLEASEACTIVE responses; (2) 993 List of IP addresses for which it got DHCPLEASEUNASSIGNED responses; 994 (3) List of IP addresses for which it got DHCPLEASEUNKNOWN responses; 995 (4) All other IP addresses. 997 This approach may be acceptable if only legitimate traffic is 998 received. Consider the case when someone sends packets that uses 999 spoofed IP addresses. In that case, lease response will be 1000 DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN. RFC 4388 [5] suggests usage 1001 of negative caching in this regard (which involves additional 1002 resources). 1004 In a spoofing type of attack, negative caching information may grow 1005 considerably if attacker varies the source IP address. For each such 1006 new source IP address, traffic will come to slow path, a new lease 1007 query needs to be initiated, response will be processed, and negative 1008 caching to be done. That will mean using many resources for negative 1009 caching. 1011 RFC 4388 [5] suggests that if the DSLAM knows the network portion of 1012 the IP addresses that are assigned to its clients, then some amount 1013 of antispoofing can be done in fast path and some lease queries may 1014 be avoided. But as indicated before, that information may not always 1015 be available to DSLAMs. 1017 Effectively, antispoofing support involves considerable slow path 1018 processing and considerable resources tied for negative caching. 1020 RFC 4388 [5] says that DHCP server should be protected from being 1021 flooded with too many leasequery requests and DSLAM also should not 1022 send too many lease query messages at a time. This would mean that 1023 legitimate clients may be excessively delayed getting their 1024 information in the face of antispoofing attacks. 1026 It is concluded that antispoofing is neither effective nor efficient 1027 with this query type. 1029 o Query by MAC Address 1031 Query by MAC address can also be used similar to query by IP address 1032 described above. Indeed, query by MAC address may be better than 1033 query by IP address in one sense because of the possible presence of 1034 associated-ip option in lease responses (Note that associated-ip 1035 option does not appear in responses for query by IP address). With 1036 associated-ip option DSLAM can get information not only about the IP 1037 address/MAC address that triggered the lease query but also about 1038 other IP addresses that are associated with the original MAC address. 1039 That way, when traffic that uses the other IP addresses comes along, 1040 DSLAM is already prepared to deal with them. 1042 Although, query by MAC address is better than query by IP address in 1043 the above respect, it has a specific problem which is not shared by 1044 query by IP address. For a query by MAC address, only two types of 1045 responses are possible: DHCPLEASEUNKNOWN and DHCPLEASEACTIVE; 1046 DHCPLEASEUNASSIGNED is not supported. This is particularly 1047 troublesome when a DHCP server indeed has definitive information that 1048 no IP addresses are associated with the specified MAC address in the 1049 leasequery, but it is forced to respond with DHCPLEASEUNKNOWN instead 1050 of DHCPLEASEUNASSIGNED. As we have seen above, unlike 1051 DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN requires periodic querying with 1052 DHCP server, an additional overhead. 1054 Moreover, query by MAC address also shares all other issues we 1055 discussed above for query by IP address. 1057 We conclude that existing lease query types are not appropriate to 1058 achieve effective and efficient antispoofing. 1060 Authors' Addresses 1062 Ramakrishna Rao D. T. V. 1063 Infosys Technologies Ltd. 1064 44 Electronics City, Hosur Road 1065 Bangalore 560 100 1066 India 1068 Email: RAMAKRISHNADTV@infosys.com 1069 URI: http://www.infosys.com/ 1071 Bharat joshi 1072 Infosys Technologies Ltd. 1073 44 Electronics City, Hosur Road 1074 Bangalore 560 100 1075 India 1077 Email: bharat_joshi@infosys.com 1078 URI: http://www.infosys.com/ 1080 Pavan Kurapati 1081 Infosys Technologies Ltd. 1082 44 Electronics City, Hosur Road 1083 Bangalore 560 100 1084 India 1086 Email: pavan_kurapati@infosys.com 1087 URI: http://www.infosys.com/ 1089 Intellectual Property Statement 1091 The IETF takes no position regarding the validity or scope of any 1092 Intellectual Property Rights or other rights that might be claimed to 1093 pertain to the implementation or use of the technology described in 1094 this document or the extent to which any license under such rights 1095 might or might not be available; nor does it represent that it has 1096 made any independent effort to identify any such rights. Information 1097 on the procedures with respect to rights in RFC documents can be 1098 found in BCP 78 and BCP 79. 1100 Copies of IPR disclosures made to the IETF Secretariat and any 1101 assurances of licenses to be made available, or the result of an 1102 attempt made to obtain a general license or permission for the use of 1103 such proprietary rights by implementers or users of this 1104 specification can be obtained from the IETF on-line IPR repository at 1105 http://www.ietf.org/ipr. 1107 The IETF invites any interested party to bring to its attention any 1108 copyrights, patents or patent applications, or other proprietary 1109 rights that may cover technology that may be required to implement 1110 this standard. Please address the information to the IETF at 1111 ietf-ipr@ietf.org. 1113 Disclaimer of Validity 1115 This document and the information contained herein are provided on an 1116 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1117 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1118 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1119 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1120 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1121 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1123 Copyright Statement 1125 Copyright (C) The IETF Trust (2008). This document is subject to the 1126 rights, licenses and restrictions contained in BCP 78, and except as 1127 set forth therein, the authors retain all their rights. 1129 Acknowledgment 1131 Funding for the RFC Editor function is currently provided by the 1132 Internet Society.