idnits 2.17.1 draft-ietf-dhc-leasequery-09.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1238. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1230), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 928 has weird spacing: '...ent out a DHC...' == Line 1207 has weird spacing: '...imed to perta...' -- 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 (April 2006) is 6557 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) == Missing Reference: 'RFC2131' is mentioned on line 1030, but not defined == Unused Reference: 'RFC 826' is defined on line 1148, but no explicit reference was found in the text == Unused Reference: 'RFC 3315' is defined on line 1161, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration Working Group Rich Woundy 3 INTERNET DRAFT Comcast Cable 5 Kim Kinnear 6 Cisco Systems 8 October 2005 9 Expires April 2006 11 DHCP Lease Query 12 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Abstract 43 A DHCPv4 server is the authoritative source of IP addresses that it 44 has provided to DHCPv4 clients. Other processes and devices that 45 already make use of DHCPv4 may need to access this information. The 46 leasequery protocol provides these processes and devices a 47 lightweight way to access IP address information. 49 Table of Contents 51 1. Introduction................................................. 2 52 2. Terminology.................................................. 5 53 3. Background................................................... 7 54 4. Design Goals................................................. 7 55 4.1. Broadcast ARP is Undesirable............................... 7 56 4.2. SNMP and LDAP Not Appropriate.............................. 8 57 4.3. DHCP Relay Agent Functionality is Common................... 8 58 4.4. DHCP Servers as a Reliable Source of Location Information.. 9 59 4.5. Minimal Additional Configuration is Required............... 9 60 5. Protocol Overview............................................ 9 61 6. Protocol Details............................................. 12 62 6.1. Definitions required for DHCPLEASEQUERY processing......... 12 63 6.2. Sending the DHCPLEASEQUERY Message......................... 14 64 6.3. Receiving the DHCPLEASEQUERY Message....................... 15 65 6.4. Responding to the DHCPLEASEQUERY Message................... 16 66 6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or....... 20 67 6.6. Receiving no response to the DHCPLEASEQUERY Message........ 21 68 6.7. Lease binding data storage requirements.................... 22 69 6.8. Using the DHCPLEASEQUERY message with multiple DHCP servers 23 70 7. Security Considerations...................................... 23 71 8. IANA Considerations.......................................... 24 72 9. Acknowledgments.............................................. 24 73 10. References.................................................. 25 74 10.1. Normative References...................................... 25 75 10.2. Informative References.................................... 25 76 11. Author's information........................................ 26 77 12. Intellectual Property Statement............................. 26 78 13. Full Copyright Statement.................................... 27 80 1. Introduction 82 A DHCPv4 server contains considerable authoritative information 83 concerning the IP addresses it has leased to DHCP clients. Sometimes 84 devices or other processes may need access to this information. In 85 some cases, these devices or processes already have the capability to 86 send and receive DHCP packets, and so the leasequery protocol is 87 designed to give these processes and devices a low overhead way to 88 access such information. 90 For example, access concentrators that act as DHCP relay agents 91 sometimes derive information important to their operation by 92 extracting data out of the DHCP packets they forward, a process known 93 as "gleaning". Unfortunately, the typical access concentrator loses 94 its gleaned information when the access concentrator is rebooted or 95 is replaced. This memo proposes that when gleaned DHCP information 96 is not available, the access concentrator/relay agent can obtain the 97 location information directly from the DHCP server(s) using the 98 DHCPLEASEQUERY message. 100 To continue this example in more depth, in many broadband access 101 networks, the access concentrator needs to associate an IP address 102 lease to the correct endpoint location, which includes knowledge of 103 the host hardware address, the port or virtual circuit that leads to 104 the host, and/or the hardware address of the intervening subscriber 105 modem. This is particularly important when one or more IP subnets 106 are shared among many ports, circuits, and modems. Representative 107 cable and DSL environments are depicted in Figures 1 and 2 below. 109 +--------+ +---------------+ 110 | DHCP | | DOCSIS CMTS | 111 | Server |-...-| or DVB INA |------------------- 112 +--------+ | (Relay Agent) | | | 113 +---------------+ +------+ +------+ 114 |Modem1| |Modem2| 115 +------+ +------+ 116 | | | 117 +-----+ +-----+ +-----+ 118 |Host1| |Host2| |Host3| 119 +-----+ +-----+ +-----+ 121 Figure 1: Cable Environment for DHCPLEASEQUERY 123 +--------+ +---------------+ 124 | DHCP | | DSL Access | +-------+ 125 | Server |-...-| Concentrator |-...-| DSLAM | 126 +--------+ | (Relay Agent) | +-------+ 127 +---------------+ | | 128 +------+ +------+ 129 |Modem1| |Modem2| 130 +------+ +------+ 131 | | | 132 +-----+ +-----+ +-----+ 133 |Host1| |Host2| |Host3| 134 +-----+ +-----+ +-----+ 136 Figure 2: DSL Environment for DHCPLEASEQUERY 138 Knowledge of this location information can benefit the access 139 concentrator in several ways: 141 1. The access concentrator can forward traffic to the access 142 network using the correct access network port, down the correct 143 virtual circuit, through the correct modem, to the correct 144 hardware address. 146 2. The access concentrator can perform IP source address 147 verification of datagrams received from the access network. 148 The verification may be based on the datagram source hardware 149 address, the incoming access network port, the incoming virtual 150 circuit, and/or the transmitting modem. 152 3. The access concentrator can encrypt datagrams which can only be 153 decrypted by the correct modem, using mechanisms such as [BPI] 154 or [BPI+]. 156 The access concentrator in this example obtains the location 157 information primarily from "gleaning" information from DHCP server 158 responses sent through the relay agent. When location information is 159 not available from "gleaning", e.g. because the access concentrator 160 has rebooted, the access concentrator can query the DHCP server(s) 161 for location information using the DHCPLEASEQUERY message defined in 162 this document. 164 The DHCPLEASEQUERY message is a new DHCP message type transmitted 165 from a DHCP relay agent to a DHCP server. A DHCPLEASEQUERY-aware 166 relay agent sends the DHCPLEASEQUERY message when it needs to know 167 the location of an IP endpoint. The DHCPLEASEQUERY-aware DHCP server 168 replies with a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE or 169 DHCPLEASEUNKNOWN message. The DHCPLEASEACTIVE response to a 170 DHCPLEASEQUERY message allows the relay agent to determine the IP 171 endpoint location, and the remaining duration of the IP address 172 lease. The DHCPLEASEUNASSIGNED is similar to a DHCPLEASEACTIVE 173 message but indicates that there is no currently active lease on the 174 resultant IP address but that this DHCP server is authoritative for 175 this IP address. The DHCPLEASEUNKNOWN message indicates that the 176 DHCP server has no knowledge of the information specified in the 177 query (e.g., IP address, MAC address, or Client-identifier option). 179 The DHCPLEASEQUERY message does not presuppose a particular use for 180 the information it returns -- it is simply designed to return 181 information for which the DHCP server is an authoritative source to a 182 client which requests that information. It is designed to make it 183 straightforward for processes and devices which already interpret 184 DHCP packets to access information from the DHCP server. 186 This document specifies an extension specifically to the DHCPv4 187 protocol [RFC2131]. Given the nature of the DHCPv6 protocol [RFC 188 3315], there is no effective way to make the DHCPLEASEQUERY message 189 interaction common between DHCPv4 and DHCPv6 even should the desire 190 to do so exist. 192 The DHCPLEASEQUERY message was the result of a set of specific real- 193 world implementation needs that appeared many years after the DHCPv4 194 protocol was in wide use. Furthermore, at the time of this writing, 195 the DHCPv6 protocol has yet to be widely deployed. The needs of 196 access concentrators in yet to be determined DHCPv6 deployment 197 scenarios are difficult to estimate. If a DHCPLEASEQUERY-like 198 function is necessary in DHCPv6, many of the ideas of this document 199 will probably be applicable, while others may not. We have been 200 cautioned against designing protocol capabililties for which there is 201 only an imagined consumer, and that is all that exists today in the 202 realm of DHCPLEASEQUERY for DHCPv6. 204 Thus, this document applies only to DHCPv4, and for clarity we have 205 not appended DHCPv4 to every appearance of several common terms. In 206 this document all references to IP addresses should be taken to mean 207 IPv4 addresses, and all references to DHCP servers and DHCP clients 208 should be taken to mean DHCPv4 servers and DHCPv4 clients. 210 2. Terminology 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 214 document are to be interpreted as described in RFC 2119 [RFC 2119]. 216 This document uses the following terms: 218 o "access concentrator" 220 An access concentrator is a router or switch at the broadband 221 access provider's edge of a public broadband access network. 222 This document assumes that the access concentrator includes the 223 DHCP relay agent functionality. 225 o "DHCP client" 227 A DHCP client is an Internet host using DHCP to obtain 228 configuration parameters such as a network address. 230 o "DHCP relay agent" 232 A DHCP relay agent is a third-party agent that transfers BOOTP 233 and DHCP messages between clients and servers residing on 234 different subnets, per [RFC 951] and [RFC 1542]. 236 o "DHCP server" 238 A DHCP server is an Internet host that returns configuration 239 parameters to DHCP clients. 241 o "downstream" 243 Downstream is the direction from the access concentrator towards 244 the broadband subscriber. 246 o "gleaning" 248 Gleaning is the extraction of location information from DHCP 249 messages, as the messages are forwarded by the DHCP relay agent 250 function. 252 o "location information" 254 Location information is information needed by the access 255 concentrator to forward traffic to a broadband-accessible host. 256 This information includes knowledge of the host hardware 257 address, the port or virtual circuit that leads to the host, 258 and/or the hardware address of the intervening subscriber modem. 260 o "MAC address" 262 In the context of a DHCP packet, a MAC address consists of the 263 fields: hardware type "htype", hardware length "hlen", and 264 client hardware address "chaddr". 266 o "stable storage" 268 Every DHCP server is assumed to have some form of what is called 269 "stable storage". Stable storage is used to hold information 270 concerning IP address bindings (among other things) so that this 271 information is not lost in the event of a server failure which 272 requires restart of the server. 274 o "upstream" 276 Upstream is the direction from the broadband subscriber towards 277 the access concentrator. 279 3. Background 281 The focus of this document is to enable processes and devices which 282 wish to access information from the DHCP server in a lightweight and 283 convenient manner. It is especially appropriate for processes and 284 devices which already interpret DHCP packets. 286 One important motivating example is that the DHCPLEASEQUERY message 287 allows access concentrators to send DHCPLEASEQUERY messages to DHCP 288 servers, to obtain location information of broadband access network 289 devices. 291 This document assumes that many access concentrators have an embedded 292 DHCP relay agent functionality. Typical access concentrators include 293 DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB 294 Interactive Network Adapters (INAs) [EUROMODEM], and DSL Access 295 Concentrators. 297 The DHCPLEASEQUERY message is an extension to the DHCP protocol [RFC 298 2131]. 300 The DHCPLEASEQUERY message is a query message only, and does not 301 affect the state of the IP address or the binding information 302 associated with it. 304 4. Design Goals 306 The goal of this document is to provide a lightweight mechanism for 307 processes or devices to access information contained in the DHCP 308 server. It is designed to allow processes and devices which already 309 process and interpret DHCP messages to access this information in a 310 rapid and lightweight manner. 312 Some of this information might be acquired in a different way, and 313 the following sections discuss some of these alternative approaches. 315 4.1. Broadcast ARP is Undesirable 317 The access concentrator can transmit a broadcast ARP Request [RFC 318 826], and observe the origin and contents of the ARP Reply, to 319 reconstruct the location information. 321 The ARP mechanism is undesirable for three reasons: 323 1. the burden on the access concentrator to transmit over multiple 324 access ports and virtual circuits (assuming that IP subnets 325 span multiple ports or virtual circuits), 327 2. the burden on the numerous subscriber hosts to receive and 328 process the broadcast, and 330 3. the ease by which a malicious host can misrepresent itself as 331 the IP endpoint. 333 4.2. SNMP and LDAP Not Appropriate 335 Access concentrator implementations typically do not have SNMP 336 management client interfaces nor LDAP client interfaces (although 337 they typically do include SNMP management agents). This is one 338 reason why this document does not leverage the proposed DHCP Server 339 MIB [DHCPMIB]. 341 The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering 342 and troubleshooting activities at large DHCP installations, and is 343 primarily intended as a method of gathering performance statistics 344 about servers the load presented to them. 346 Despite the presence in the proposed DHCPv4 server MIB of objects 347 that report configuration and status information, the MIB is intended 348 to provide more generic, server-wide aggregated or summarized data. 349 DHCPLEASEQUERY is intended to provide detailed, specific information 350 about individual leases at a level that would be difficult or 351 impossible to shoehorn into a MIB. 353 From an implementation standpoint, the DHCPLEASEQUERY message is not 354 required to be supported by all DHCPv4 servers. Since it appears 355 that defining optional MIB objects and objects for optional features 356 in a MIB is discouraged, trying to support DHCPLEASEQUERY 357 functionality optionally through a MIB would be similarly discouraged 358 from an SNMP MIB standpoint. 360 4.3. DHCP Relay Agent Functionality is Common 362 Access concentrators commonly act as DHCP relay agents. Furthermore, 363 many access concentrators already glean location information from 364 DHCP server responses, as part of the relay agent function. 366 The gleaning mechanism as a technique to determine the IP addresses 367 valid for a particular downstream link is preferred over other 368 mechanisms (ARP, SNMP, LDAP) because of the lack of additional 369 network traffic, but sometimes gleaning information can be 370 incomplete. The access concentrator usually cannot glean information 371 from any DHCP unicast (i.e. non-relayed) messages due to performance 372 reasons. Furthermore, the DHCP-gleaned location information often 373 does not persist across access concentrator reboots (due to lack of 374 stable storage), and almost never persists across concentrator 375 replacements. 377 4.4. DHCP Servers as a Reliable Source of Location Information 379 DHCP servers are the most reliable source of location information for 380 access concentrators, particularly when the location information is 381 dynamic and not reproducible by algorithmic means (e.g. when a 382 single IP subnet extends behind many broadband modems). DHCP servers 383 participate in all IP lease transactions (and therefore in all 384 location information updates) with DHCP clients, whereas access 385 concentrators sometimes miss some important lease transactions. 387 An access concentrator can be configured with the IP addresses of 388 multiple different DHCP servers, so that no one DHCP server is a 389 single point of failure. 391 4.5. Minimal Additional Configuration is Required 393 Access concentrators can usually query the same set of DHCP servers 394 used for forwarding by the relay agent, thus minimizing configuration 395 requirements. 397 5. Protocol Overview 399 In the following discussion of the DHCPLEASEQUERY message, the client 400 of the message is assumed to be an access concentrator. Note that 401 access concentrators are not the only allowed (or required) consumers 402 of the information provided by the DHCPLEASEQUERY message, but they 403 do give reader a concrete feel for how the message might be used. 405 The access concentrator initiates all DHCPLEASEQUERY message 406 conversations. This document assumes that the access concentrator 407 gleans location information in its DHCP relay agent function. 408 However, the location information is usually unavailable after the 409 reboot or replacement of the access concentrator. 411 Suppose the access concentrator is a router, and further suppose that 412 the router receives an IP datagram to forward downstream to the 413 public broadband access network. If the location information for the 414 downstream next hop is missing, the access concentrator sends one or 415 more DHCPLEASEQUERY message(s), each containing the IP address of the 416 downstream next hop in the "ciaddr" field. 418 This query will then be answered by, returning the information 419 current when this client's lease was last granted or renewed, 420 allowing the access concentrator to forward the IP datagram. 422 An alternative approach is to send in a DHCPLEASEQUERY message with 423 the "ciaddr" field empty and the MAC address (i.e., "htype", "hlen", 424 and "chaddr" fields) with a valid MAC address or a Client-identifier 425 option (option 61) appearing in the options area. In this case, the 426 DHCP server must return an IP address in the "ciaddr" if it has any 427 record of the client described by the Client-identifier or MAC 428 address. In the absence of specific configuration information to the 429 contrary (see Section 6.4) it SHOULD be the IP address with the 430 latest client-last-transaction-time associated with the client 431 described by the MAC address or Client-identifier option (or the 432 client described by both, if both appear). 434 The DHCP servers that implement this protocol always send a response 435 to the DHCPLEASEQUERY message: either a DHCPLEASEUNASSIGNED, 436 DHCPLEASEACTIVE or DHCPLEASEUNKNOWN. The reasons why a 437 DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN message 438 might be generated are explained in the specific query regimes, 439 below. 441 Servers which do not implement the DHCPLEASEQUERY message SHOULD 442 simply not respond. 444 The DHCPLEASEQUERY message can support three query regimes: A server 445 which implements the DHCPLEASEQUERY message must implement all three 446 query regimes. 448 o Query by IP address: 450 For this query, the requester supplies only an IP address in the 451 DHCPLEASEQUERY message. The DHCP server will return any 452 information that it has on the most recent client to have been 453 assigned that IP address. 455 The DHCP server replies with a DHCPLEASEUNASSIGNED or 456 DHCPLEASEACTIVE message if the IP address in the DHCPLEASEQUERY 457 message corresponds to an IP address about which the server has 458 definitive information (ie., it is authorized to lease this IP 459 address). The server replies with a DHCPLEASEUNKNOWN message if 460 the server does not have definitive information concerning the 461 address in the DHCPLEASEQUERY message. 463 o Query by MAC address: 465 For this query, the requester supplies only a MAC address in the 466 DHCPLEASEQUERY message. The DHCP server will return any 467 information that it has on the IP address most recently accessed 468 by a client with that MAC address. In addition, it may supply 469 addition IP addresses which have been associated with that MAC 470 address in different subnets. Information about these bindings 471 can then be found using the Query by IP Address, described 472 above. 474 The DHCP server replies with a DHCPLEASEACTIVE message if the 475 MAC address in the DHCPLEASEQUERY message corresponds to a MAC 476 address with an active lease on an IP address in this server. 477 The server replies with a DHCPLEASEUNKNOWN message if the server 478 does not presently have an active lease by a client with this 479 MAC address in this DHCP server. 481 o Query by Client-identifier option: 483 For this query, the requester supplies only a Client-identifier 484 option in the DHCPLEASEQUERY message. The DHCP server will 485 return any information that it has on the IP address most 486 recently accessed by a client with that Client-identifier. In 487 addition, it may supply additional IP addresses which have been 488 associated with Client-identifier in different subnets. 489 Information about these bindings can then be found using the 490 Query by IP Address, described above. 492 The DHCP server replies with a DHCPLEASEACTIVE message if the 493 Client-identifier in the DHCPLEASEQUERY message currently has an 494 active lease on an IP address in this DHCP server. The server 495 replies with a DHCPLEASEUNKNOWN message if the server does not 496 have an active lease by a client with this Client-identifier. 498 For many DHCP servers, the query by IP address is likely to be the 499 most efficient form of leasequery. This is the form of 500 DHCPLEASEQUERY that SHOULD be used if possible. 502 The DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message reply must always 503 contain the IP address in the ciaddr field. The DHCPLEASEACTIVE 504 message SHOULD contain the physical address of the IP address lease 505 owner in the "htype", "hlen", and "chaddr" fields. The Parameter 506 Request List (option 55) can be used to request specific options to 507 be returned about the IP address in the ciaddr. The reply often 508 contains the time until expiration of the lease, and the original 509 contents of the Relay Agent Information option [RFC 3046]. The 510 access concentrator uses the "chaddr" and Relay Agent Information 511 option to construct location information, which can be cached on the 512 access concentrator until lease expiration. 514 Any DHCP server which supports the DHCPLEASEQUERY message SHOULD save 515 the information from the most recent Relay Agent Information option 516 (option 82) [RFC 3046] associated with every IP address which it 517 serves. It is assumed that most clients which generate the 518 DHCPLEASEQUERY message will ask for the Relay Agent Information 519 option (option 82) in the Parameter Request List (option 55), and so 520 supporting the DHCPLEASEQUERY message without having the Relay Agent 521 Information option around to return to the client is likely to be 522 less than helpful. 524 A server which implements DHCPLEASEQUERY SHOULD also save the 525 information on the most recent Vendor class identifier, option 60, 526 associated with each IP address, since this option is also likely to 527 be requested by clients sending the DHCPLEASEQUERY message. 529 6. Protocol Details 531 6.1. Definitions required for DHCPLEASEQUERY processing 533 The operation of the DHCPLEASEQUERY message requires the definition 534 of the following new and extended values for the DHCP packet beyond 535 those defined by [RFC 2131] and [RFC 2132]. See also Section 8, IANA 536 considerations. 538 1. The message type option (option 53) from [RFC 2132] requires 539 four new values: one for the DHCPLEASEQUERY message itself and 540 and one for each of its three possible responses 541 DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, DHCPLEASEUNKNOWN. The 542 values of these message types are shown below in a reproduction 543 of the table from [RFC 2132]: 545 Value Message Type 546 ----- ------------ 547 1 DHCPDISCOVER 548 2 DHCPOFFER 549 3 DHCPREQUEST 550 4 DHCPDECLINE 551 5 DHCPACK 552 6 DHCPNAK 553 7 DHCPRELEASE 554 8 DHCPINFORM 555 TBD DHCPLEASEQUERY 556 TBD DHCPLEASEUNASSIGNED 557 TBD DHCPLEASEUNKNOWN 558 TBD DHCPLEASEACTIVE 560 2. There is a new option, the client-last-transaction-time: 562 client-last-transaction-time 564 This option allows the receiver to determine the time of the 565 most recent access of the client. It is particularly useful 566 when DHCPLEASEACTIVE messages from two different DHCP servers 567 need to be compared, although it can be useful in other 568 situations. The value is a duration in seconds from the 569 current time into the past when this IP address was most 570 recently the subject of communication between the client and 571 the DHCP server. 573 This MUST NOT be an absolute time. This MUST NOT be an 574 absolute number of seconds since Jan 1, 1970. Instead, this 575 MUST be an integer number of seconds in the past from the time 576 the DHCPLEASEACTIVE message is sent that the client last dealt 577 with this server about this IP address. In the same way that 578 the IP Address Lease Time option (option 51) encodes a lease 579 time which is a number of seconds into the future from the time 580 the message was sent, this option encodes a value which is a 581 number of seconds into the past from when the message was sent. 583 The code for the this option is TBD. The length of the this 584 option is 4 octets. 586 Code Len Seconds in the past 587 +-----+-----+-----+-----+-----+-----+ 588 | TBD | 4 | t1 | t2 | t3 | t4 | 589 +-----+-----+-----+-----+-----+-----+ 591 3. There in a second new option, the associated-ip option: 593 associated-ip 595 This option is used to return all of the IP addresses 596 associated with the DHCP client specified in a particular 597 DHCPLEASEQUERY message. 599 The code for this option is TBD. The minimum length for this 600 option is 4 octets, and the length MUST always be a multiple of 601 4. 603 Code Len Address 1 Address 2 604 +-----+-----+-----+-----+-----+-----+-----+-----+-- 605 | TBD | n | a1 | a2 | a3 | a4 | a1 | a2 | ... 606 +-----+-----+-----+-----+-----+-----+-----+-----+-- 608 6.2. Sending the DHCPLEASEQUERY Message 610 The DHCPLEASEQUERY message is typically sent by an access 611 concentrator. The DHCPLEASEQUERY message uses the DHCP message 612 format as described in [RFC 2131], and uses message number TBD in the 613 DHCP Message Type option (option 53). The DHCPLEASEQUERY message has 614 the following pertinent message contents: 616 o The giaddr MUST be set to the IP address of the requester (i.e. 617 the access concentrator). The giaddr is independent of the 618 "ciaddr" field to be searched -- it is simply the return address 619 of for the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE or 620 DHCPLEASEUNKNOWN message from the DHCP server. 622 Note that this use of the giaddr is consistent with the 623 definition of giaddr in [RFC2131], where the giaddr is always 624 used as the return address of the DHCP response message. In 625 some (but not all) contexts in RFC2131 the giaddr is used as the 626 "key" to access the appropriate address pool. The 627 DHCPLEASEQUERY message is one of those cases where the giaddr 628 MUST NOT be used as such a "key". 630 o The Parameter Request List option (option 55) SHOULD be set to 631 the options of interest to the requester. The interesting 632 options are likely to include the IP Address Lease Time option 633 (option 51), the Relay Agent Information option (option 82) and 634 possibly the Vendor class identifier option (option 60). In the 635 absence of a Parameter Request List option, the server SHOULD 636 return the same options it would return for a DHCPREQUEST 637 message which didn't contain a DHCPLEASEQUERY message, which 638 includes those mandated by [RFC 2131, Section 4.3.1] as well as 639 any options which the server was configured to always return to 640 a client. 642 Additional details concerning different query types are: 644 o Query by IP address: 646 The values of htype, hlen, and chaddr MUST be set to 0. 648 The "ciaddr" field MUST be set to the IP address of the lease to 649 be queried. 651 The Client-identifier option (option 61) MUST NOT appear in the 652 packet. 654 o Query by MAC address: 656 The values of htype, hlen, and chaddr MUST be set to the value 657 of the MAC address to search for. 659 The "ciaddr" field MUST be set to zero. 661 The Client-identifier option (option 61) MUST NOT appear in the 662 packet. 664 o Query by Client-identifier option: 666 There MUST be a Client-identifier option (option 61) in the 667 DHCPLEASEQUERY message. 669 The "ciaddr" field MUST be set to zero. 671 The values of htype, hlen, and chaddr MUST be set to 0. 673 The DHCPLEASEQUERY message SHOULD be sent to a DHCP server which is 674 known to possess authoritative information concerning the IP address. 675 The DHCPLEASEQUERY message MAY be sent to more than one DHCP server, 676 and in the absence of information concerning which DHCP server might 677 possess authoritative information concerning the IP address, it 678 SHOULD be sent to all DHCP servers configured for the associated 679 relay agent (if any are known). 681 Any device expecting to use a DHCPLEASEQUERY message SHOULD ensure 682 that the Relay Agent Info option that it uses contains information 683 that unambiguously identifies the device. 685 6.3. Receiving the DHCPLEASEQUERY Message 687 A server which implements the DHCPLEASEQUERY message MUST implement 688 all three query regimes, query by IP address, query by MAC address, 689 and query by Client-identifier. 691 A DHCPLEASEQUERY message MUST have a non-zero giaddr. The 692 DHCPLEASEQUERY message MUST have exactly one of: a non-zero ciaddr, 693 a non-zero "htype"/"hlen"/"chaddr", or a Client-identifier option. 695 The DHCP server which receives a DHCPLEASEQUERY message MUST base its 696 response on the particular data item used in the query. 698 The giaddr is used only for the destination address of any generated 699 response and, while required, is not otherwise used in generating the 700 response to the DHCPLEASEQUERY message. It MUST NOT be used to 701 restrict the processing of the query in any way, and MUST NOT be used 702 locate a subnet to which the ciaddr (if any) must belong. 704 Note that this use of the giaddr is consistent with the definition of 705 giaddr in [RFC2131], where the giaddr is always used as the return 706 address of the DHCP response message. In some (but not all) contexts 707 in RFC2131 the giaddr is used as the "key" to access the appropriate 708 address pool. The DHCPLEASEQUERY message is one of those cases where 709 the giaddr MUST NOT be used as such a "key". 711 6.4. Responding to the DHCPLEASEQUERY Message 713 There are three possible responses to a DHCPLEASEQUERY message: 715 o DHCPLEASEUNASSIGNED 717 The server MUST respond with a DHCPLEASEUNASSIGNED message if 718 this server has information about the IP address, but there is 719 no active lease for the IP address. The DHCPLEASEUNASSIGNED 720 message is only returned for a query by IP address, and 721 indicates that the server manages this IP address but there is 722 no currently active lease on this IP address. 724 o DHCPLEASEUNKNOWN 726 The DHCPLEASEUNKNOWN message indicates that the server does not 727 manage the IP address or the client specified in the 728 DHCPLEASEQUERY message does not currently have a lease on an IP 729 address. 731 When responding with a DHCPLEASEUNKNOWN, the DHCP server MUST 732 NOT include other DHCP options in the response. 734 o DHCPLEASEACTIVE 736 The DHCPLEASEACTIVE message indicates that the server not only 737 knows about the IP address and client specified in the 738 DHCPLEASEACTIVE message but also that there is an active lease 739 by that client for that IP address. 741 The server MUST respond with a DHCPLEASEACTIVE message when the 742 IP address returned in the "ciaddr" field is currently leased. 744 6.4.1. Determining the IP address to which to respond 746 Since the response to a DHCPLEASEQUERY request can only contain full 747 information about one IP address -- the one that appears in the 748 "ciaddr" field -- determination of which IP address to which to 749 respond is a key issue. Of course, the values of additional IP 750 addresses for which a client has a lease must also be returned in the 751 associated-ip option (Section 6.1, #4). This is the only information 752 returned not directly associated with the IP address in the "ciaddr" 753 field. 755 In the event that an IP address appears in the "ciaddr" field of a 756 DHCPLEASEQUERY message, if that IP address is one managed by the DHCP 757 server, then that IP address MUST be set in the "ciaddr" field of a 758 DHCPLEASEUNASSIGNED message. 760 If the IP address is not managed by the DHCP server, then a 761 DHCPLEASEUNKNOWN message must be returned. 763 If the "ciaddr" field of the DHCPLEASEQUERY is zero, then the 764 DHCPLEASEQUERY message is a query by Client-identifier or MAC 765 address. In this case, the client's identity is any client which has 766 proffered an identical Client-identifier option (if the Client- 767 identifier option appears in the DHCPLEASEQUERY message), or an 768 identical MAC address (if the MAC address fields in the 769 DHCPLEASEQUERY message are non-zero). This client matching approach 770 will, for the purposes of this section, be described as "Client- 771 identifier or MAC address". 773 If the "ciaddr" field is zero in a DHCPLEASEQUERY message, then the 774 IP address placed in the "ciaddr" field of a DHCPLEASEACTIVE message 775 MUST be that of an IP address for which the client that most recently 776 used the IP address matches the Client-identifier or MAC address 777 specified in the DHCPLEASEQUERY message. 779 If there is only a single IP address which fulfills this criteria, 780 then it MUST be placed in the "ciaddr" field of the DHCPLEASEACTIVE 781 message. 783 In the case where more than one IP address has been accessed by the 784 client specified by the MAC address or Client-identifier option, then 785 the DHCP server MUST return the IP address returned to the client in 786 the most recent transaction with the client unless the DHCP server 787 has been configured by the server administrator to use some other 788 preference mechanism. 790 If, after all of the above processing, no value is set in the 791 "ciaddr" field of the DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message, 792 then a DHCPLEASEUNKNOWN message MUST be returned instead. 794 6.4.2. Building a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message once 795 the "ciaddr" field is set 797 Once the "ciaddr" field of the DHCPLEASEUNASSIGNED is set, the 798 processing for a DHCPLEASEUNASSIGNED message is complete. No other 799 options returned for the DHCPLEASEUNASSIGNED message. 801 For the DHCPLEASEACTIVE message, the rest of the processing largely 802 involves returning information about the IP address specified in the 803 "ciaddr" field. 805 The IP address in the "ciaddr" field of the DHCPLEASEUNASSIGNED or 806 DHCPLEASEACTIVE message MUST be one for which this server is 807 responsible (or a DHCPLEASEUNKNOWN message would be have already been 808 returned early in the processing described in the previous section). 810 The MAC address of the DHCPLEASEACTIVE message MUST be set to the 811 values which identify the client associated with the IP address in 812 the "ciaddr" field of the DHCPLEASEUNASSIGNED message. 814 If the Client-identifier option (option 61) is specified in the 815 Parameter Request List option (option 55), then the Client-identifier 816 (if any) of the client associated with the IP address in the "ciaddr" 817 field SHOULD be returned in the DHCPLEASEACTIVE message. 819 In the case where more than one IP address has been involved in a 820 DHCP message exchange with the client specified by the MAC address 821 and/or Client-identifier option, then the list of all of the IP 822 addresses MUST be returned in the associated-ip option, whether or 823 not that option was requested as part of the Parameter Request List 824 option. 826 If the IP Address Lease Time option (option 51) is specified in the 827 Parameter Request List and if there is a currently valid lease for 828 the IP address specified in the ciaddr, then the DHCP server MUST 829 return this option in the DHCPLEASEACTIVE message with its value 830 equal to the time remaining until lease expiration. If there is no 831 valid lease for the IP address, then the server MUST NOT return the 832 IP Address Lease Time option (option 51). 834 A request for the Renewal (T1) Time Value option or the Rebinding 835 (T2) Time Value option in the Parameter Request List of the 836 DHCPLEASEQUERY message MUST be handled like the IP Address Lease Time 837 option is handled. If there is a valid lease and these times are not 838 yet in the past, then the DHCP server SHOULD return these options 839 (when requested) with the remaining time until renewal or rebinding, 840 respectively. If these times are already in the past, or if there is 841 not currently a valid lease for this IP address, the DHCP server MUST 842 NOT return these options. 844 If the Relay Agent Information (option 82) is specified in the 845 Parameter Request List then the information contained in the most 846 recent Relay Agent Information option received from the relay agent 847 associated with this IP address MUST be included in the 848 DHCPLEASEACTIVE message. The DHCP server MUST the Relay Agent 849 Information option that was received when from the relay agent 850 associated with this IP address. 852 The DHCPLEASEACTIVE message SHOULD include the values of all other 853 options not specifically discussed above that were requested in the 854 Parameter Request List of the DHCPLEASEQUERY message and that are 855 acceptable to return based on the list of "non-senstive options", 856 discussed below. 858 DHCP servers SHOULD be configurable with a list of "non-sensitive 859 options" that can be returned to the client when specified in the 860 Parameter Request List of the DHCPLEASEQUERY message. Any option not 861 on this should SHOULD NOT be returned to a client, even if requested 862 by that client. 864 The DHCP server uses information from its lease binding database to 865 supply the DHCPLEASEACTIVE option values. The values of the options 866 that were returned to the DHCP client would generally be preferred, 867 but in the absence of those, options that were sent in DHCP client 868 requests would be acceptable. 870 In some cases, the Relay Agent Information option in an incoming 871 DHCPREQUEST packet is used to help determine the options returned to 872 the DHCP client which sent the DHCPREQUEST. When responding to a 873 DHCPLEASEQUERY message, the DHCP server MUST use the saved Relay 874 Agent Information option just like it did when responding to the DHCP 875 client in order to determine the values of any options requested by 876 the DHCPLEASEQUERY message. The goal is to return the same option 877 values to the DHCPLEASEQUERY as those that were returned to the 878 DHCPDISCOVER or DHCPREQUEST from the DHCP client (unless otherwise 879 specified, above). 881 In the event that two servers are cooperating to provide a high 882 availability DHCP server, as supported by [RFC2131], they would have 883 to communicate some information about IP address bindings to each 884 other. In order to properly support the DHCPLEASEQUERY message, 885 these servers MUST ensure that they communicate the Relay Agent 886 Information option information to each other in addition to any other 887 IP address binding information. 889 6.4.3. Sending a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 890 DHCPLEASEUNKNOWN message 892 The server expects a giaddr in the DHCPLEASEQUERY message, and 893 unicasts the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN 894 message to the giaddr. If the giaddr field is zero, then the DHCP 895 server MUST NOT reply to the DHCPLEASEQUERY message. 897 6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 898 DHCPLEASEUNKNOWN Message 900 When a DHCPLEASEACTIVE message is received in response to the 901 DHCPLEASEQUERY message it means that there is a currently active 902 lease for this IP address in this DHCP server. The access 903 concentrator SHOULD use the information in the htype, hlen, and 904 chaddr fields of the DHCPLEASEACTIVE as well as any Relay Agent 905 Information option information included in the packet to refresh its 906 location information for this IP address. 908 When a DHCPLEASEUNASSIGNED message is received in response to the 909 DHCPLEASEQUERY message that means that there is no currently active 910 lease for the IP address present in the DHCP server, but that this 911 server does in fact manage that IP address. In this case, the access 912 concentrator SHOULD cache this information in order to prevent 913 unacceptable loads on the access concentrator and the DHCP server in 914 the face of a malicious or seriously compromised device downstream of 915 the access concentrator. This caching could be as simple as simply 916 setting a bit saying that a response was received from a server which 917 knew about this IP address but that there was no current lease. This 918 would of course need to be cleared when the access concentrator next 919 "gleaned" that a lease for this IP address came into existence. 921 In either case, when a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message 922 is received in response to a DHCPLEASEQUERY message, it means that 923 the DHCP server which responded is a DHCP server which manages the IP 924 address present in the ciaddr, and the Relay Agent SHOULD cache this 925 information for later use. 927 When a DHCPLEASEUNKNOWN message is received by an access concentrator 928 which has sent out a DHCPLEASEQUERY message, it means that the DHCP 929 server contacted supports the DHCPLEASEQUERY message but that the 930 DHCP server does not have definitive information concerning the IP 931 address contained in the "ciaddr" field of the DHCPLEASEQUERY 932 message. If there is no IP address in the "ciaddr" field of the 933 DHCPLEASEQUERY message, then a DHCPLEASEUNKNOWN message means that 934 the DHCP server does not have definitive information concerning the 935 any DHCP client specified in the "hlen", "htype", and "chaddr" fields 936 or the Client-identifier option of the DHCPLEASEQUERY message. 938 The access concentrator SHOULD cache this information, but only for a 939 relatively short lifetime, approximately 5 minutes. 941 Having cached this information, the access concentrator SHOULD only 942 infrequently direct a DHCPLEASEQUERY message to a DHCP server that 943 responded to a DHCPLEASEQUERY message for a particular "ciaddr" field 944 with a DHCPLEASEUNKNOWN. 946 6.6. Receiving no response to the DHCPLEASEQUERY Message 948 When an access concentrator receives no response to a DHCPLEASEQUERY 949 message, there are several possible reasons: 951 o The DHCPLEASEQUERY or a corresponding DHCPLEASEUNASSIGNED, 952 DHCPLEASEACTIVE or DHCPLEASEUNKNOWN were lost during 953 transmission or the DHCPLEASEQUERY arrived at the DHCP server 954 but it was dropped because the server was too busy. 956 o The DHCP server doesn't support DHCPLEASEQUERY. 958 In the first of the cases above, a retransmission of the 959 DHCPLEASEQUERY would be appropriate, but in the second of the two 960 cases, a retransmission would not be appropriate. There is no way to 961 tell these two cases apart (other than, perhaps, because of a DHCP 962 server's response to other DHCPLEASEQUERY messages indicating that it 963 does or does not support the DHCPLEASEQUERY message). 965 An access concentrator which utilizes the DHCPLEASEQUERY message 966 SHOULD attempt to resend DHCPLEASEQUERY messages to servers which do 967 not respond to them using a backoff algorithm for the retry time that 968 approximates an exponential backoff. The access concentrator SHOULD 969 adjust the backoff approach such that DHCPLEASEQUERY messages do not 970 arrive at a server which is not otherwise known to support the 971 DHCPLEASEQUERY message at a rate of more than approximately one 972 packet every 10 seconds, and yet (if the access concentrator needs to 973 send DHCPLEASEQUERY messages) not less than one DHCPLEASEQUERY per 70 974 seconds. 976 In practice this approach would probably best be handled by a per- 977 server timer that is restarted whenever a response to a 978 DHCPLEASEQUERY message is received, and expires after one minute. 979 The per-server timer would start off expired, and in the expired 980 state only one DHCPLEASEQUERY message would be queued for the 981 associated server. 983 All DHCPLEASEQUERY messages SHOULD use the exponential backoff 984 algorithm specified in RFC 2131, section 4.1 [RFC 2131]. 986 Thus, in the initial state, the per-server timer is expired, and a 987 single DHCPLEASEQUERY message is queued for each server. After the 988 first response to a DHCPLEASEQUERY message, the per-server timer is 989 started. At that time, multiple DHCPLEASEQUERY message can be sent 990 in parallel to the DHCP server, though the total number SHOULD be 991 limited to 100 or 200, to avoid swamping the DHCP server. Each of 992 these messages uses the RFC 2131 exponential backoff algorithm. 993 Every time a response to any of these messages is received, the per- 994 server timer is reset and starts counting again up to one minute. In 995 the event the per-server timer goes off, then all outstanding 996 messages SHOULD be dropped except for a single DHCPLEASEQUERY message 997 which is used to poll the server at approximately 64 second intervals 998 until such time as another (or the first) response to the 999 DHCPLEASEQUERY is received. 1001 In the event that there is no DHCPLEASEQUERY traffic for one minute, 1002 then the per-server timer will expire. After that time, there will 1003 only be one DHCPLEASEQUERY message allowed to be outstanding to that 1004 server until a response to that message is received. 1006 6.7. Lease binding data storage requirements 1008 DHCP server implementations that implement the DHCPLEASEQUERY 1009 capability MUST save the most recent Relay Agent Information option 1010 from the most recent DHCPREQUEST packet for two reasons. First, it 1011 is almost certain to be requested by in the dhcp-parameter-request- 1012 list option in any DHCPLEASEQUERY request. Second, the saved Relay 1013 Agent Information option may be necessary to determine the value of 1014 other options given to the DHCP client, if these are requested by the 1015 dhcp-parameter-request list in the DHCPLEASEQUERY request. 1017 This is a list of the information that is required to successfully 1018 implement 1020 o relay-agent-info option from client packet: MUST store with 1021 binding. 1023 o client-last-transaction-time of last client interaction: MUST 1024 store with binding. 1026 o vendor-class-id: SHOULD store with binding. 1028 These data storage requirements are minimally larger than those 1029 required for normal operation of the DHCP protocol, as required to 1030 properly implement [RFC2131]. 1032 6.8. Using the DHCPLEASEQUERY message with multiple DHCP servers 1034 When using the DHCPLEASEQUERY message in an environment where 1035 multiple DHCP servers may contain authoritative information about the 1036 same IP address (such as when two DHCP servers are cooperating to 1037 provide a high availability DHCP service) multiple, possibly 1038 conflicting, responses might be received. 1040 In this case, some information in the response packet SHOULD be used 1041 to decide among the various responses. The client-last-transaction- 1042 time (if it is available) can be used to decide which server has more 1043 recent information concerning the IP address returned in the "ciaddr" 1044 field. 1046 7. Security Considerations 1048 Access concentrators that use DHCP gleaning, refreshed with 1049 DHCPLEASEQUERY messages, will maintain accurate location information. 1050 Location information accuracy ensures that the access concentrator 1051 can forward data traffic to the intended location in the broadband 1052 access network, can perform IP source address verification of 1053 datagrams from the access network, and can encrypt traffic which can 1054 only be decrypted by the intended access modem (e.g. [BPI] and 1055 [BPI+]). As a result, the access concentrator does not need to 1056 depend on ARP broadcasts across the access network, which is 1057 susceptible to malicious hosts which masquerade as the intended IP 1058 endpoints. Thus, the DHCPLEASEQUERY message allows an access 1059 concentrator to provide considerably enhanced security. 1061 DHCP servers SHOULD prevent exposure of location information 1062 (particularly the mapping of hardware address to IP address lease, 1063 which can be an invasion of broadband subscriber privacy) by 1064 employing the techniques detailed in [RFC 3118], "Authentication for 1065 DHCP Messages". 1067 This RFC describes how a DHCP client interacts with a DHCP server. 1068 Access concentrators that send the DHCPLEASEQUERY message are 1069 essentially DHCP clients for the purposes of the DHCPLEASEQUERY 1070 message, even though they perform the functions of a DHCP relay agent 1071 as well. Thus, [RFC 3118] is an appropriate mechanism for 1072 DHCPLEASEQUERY messages. 1074 Since [RFC 3118] discusses the normal DHCP client interaction, 1075 consisting of a DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK, it 1076 is necessary to transpose the operations described in [RFC 3118] to 1077 the DHCPLEASEQUERY domain. The operations described in [RFC 3118] 1078 for DHCPDISCOVER are performed for DHCPLEASEQUERY, and the operations 1079 described for DHCPOFFER are performed for DHCPLEASEUNASSIGNED, 1080 DHCPLEASEACTIVE, DHCPLEASEUNKNOWN messages. 1082 Access concentrators SHOULD minimize potential denial of service 1083 attacks on the DHCP servers by minimizing the generation of 1084 DHCPLEASEQUERY messages. In particular, the access concentrator 1085 SHOULD employ negative caching (i.e. cache DHCPLEASEUNASSIGNED, 1086 DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY 1087 messages) and ciaddr restriction (i.e. don't send a DHCPLEASEQUERY 1088 message with a ciaddr outside of the range of the attached broadband 1089 access networks). Together, these mechanisms limit the access 1090 concentrator to transmitting one DHCPLEASEQUERY message (excluding 1091 message retries) per legitimate broadband access network IP address 1092 after a reboot event. 1094 DHCP servers supporting the DHCPLEASEQUERY message SHOULD ensure that 1095 they cannot be successfully attacked by being flooded with large 1096 quantities of DHCPLEASEQUERY messages in a short time. 1098 In some environments it may be appropriate to configure a DHCP server 1099 with the IP addresses of the relay agents for which it may respond to 1100 DHCPLEASEQUERY messages, thereby allowing it to respond only to to 1101 requests from only a handful of relay agents. This does not provide 1102 any true security, but may be useful to thwart unsophisticated 1103 attacks of various sorts. 1105 8. IANA Considerations 1107 IANA has assigned seven values for this document. See Section 6.1 for 1108 details. There are four new messages types, which are the value of 1109 the message type option (option 53) from [RFC 2132]. The value for 1110 DHCPLEASEQUERY is TBD, the value for DHCPLEASEUNASSIGNED is TBD, the 1111 value for DHCPLEASEACTIVE is TBD, and the value for DHCPLEASEUNKNOWN 1112 is TBD. Finally, there are two new DHCP option defined; the client- 1113 last-transaction-time option -- option code TBD, and the associated- 1114 ip option -- option code TBD. 1116 9. Acknowledgments 1118 Jim Forster, Joe Ng, Guenter Roeck, and Mark Stapp contributed 1119 greatly to the initial creation of the DHCPLEASEQUERY message. 1121 Patrick Guelat suggested several improvements to support static IP 1122 addressing. Thomas Narten made many suggestions for improvements. 1123 Russ Housely pressed effectively for increased security capabilities 1124 and Ted Hardie suggested ways to minimize undesired information 1125 leakage. Bert Wijnen suggested we clarify our focus to DHCPv4 and 1126 distinguish our approach from that of the DHCP MIB. R. Barr Hibbs, 1127 one of the authors of the DHCP MIB, supplied information to 1128 effectively distinguish that effort from DHCPLEASEQUERY. 1130 10. References 1132 10.1. Normative References 1134 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 1135 Requirement Levels", RFC 2119, March 1997. 1137 [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1138 2131, March 1997. 1140 [RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 1141 3046, January 2001. 1143 [RFC 3118] Droms, R., Arbaugh, W., "Authentication for DHCP 1144 Messages", RFC 3118, June 2001. 1146 10.2. Informative References 1148 [RFC 826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1149 converting network protocol addresses to 48.bit Ethernet address 1150 for transmission on Ethernet hardware", RFC 826, November 1982. 1152 [RFC 951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC 1153 951, September 1985. 1155 [RFC 1542] Wimer, W., "Clarifications and Extensions for the 1156 Bootstrap Protocol", RFC 1542, October 1993. 1158 [RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 1159 Extensions", RFC 2132, March 1997. 1161 [RFC 3315] Droms, R., Bound J., Volz B., Lemon T., Perkins C., Carney 1162 M., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 1163 3315, July 2003. 1165 [BPI] CableLabs, "Baseline Privacy Interface Specification", SP-BPI- 1166 I02-990319, March 1999, available at http://www.cablemodem.com/. 1168 [BPI+] CableLabs, "Baseline Privacy Plus Interface Specification", 1169 SP-BPI+-I04-000407, April 2000, available at 1170 http://www.cablemodem.com/. 1172 [DHCPMIB] Hibbs, R., Waters, G., "Dynamic Host Configuration Protocol 1173 (DHCP) Server MIB", draft-ietf-dhc-server-mib-10.txt, February 1174 2004. 1176 [DOCSIS] CableLabs, "Data-Over-Cable Service Interface 1177 Specifications: Cable Modem Radio Frequency Interface 1178 Specification SP-RFI-I05-991105", November 1999. 1180 [EUROMODEM] ECCA, "Technical Specification of a European Cable Modem 1181 for digital bi-directional communications via cable networks", 1182 Version 1.0, May 1999. 1184 11. Author's information 1186 Rich Woundy 1187 Comcast Cable 1188 27 Industrial Ave. 1189 Chelmsford, MA 01824 1191 Phone: (978) 244-4010 1193 EMail: richard_woundy@cable.comcast.com 1195 Kim Kinnear 1196 Cisco Systems 1197 1414 Massachusetts Ave 1198 Boxborough, MA 01719 1200 Phone: (978) 936-0000 1202 EMail: kkinnear@cisco.com 1204 12. Intellectual Property Statement 1206 The IETF takes no position regarding the validity or scope of any 1207 intellectual property or other rights that might be claimed to pertain 1208 to the implementation or use of the technology described in this 1209 document or the extent to which any license under such rights might or 1210 might not be available; neither does it represent that it has made any 1211 effort to identify any such rights. Information on the IETF's 1212 procedures with respect to rights in standards-track and standards- 1213 related documentation can be found in BCP-11. Copies of claims of 1214 rights made available for publication and any assurances of licenses to 1215 be made available, or the result of an attempt made to obtain a general 1216 license or permission for the use of such proprietary rights by 1217 implementors or users of this specification can be obtained from the 1218 IETF Secretariat. 1220 The IETF invites any interested party to bring to its attention any 1221 copyrights, patents or patent applications, or other proprietary rights 1222 which may cover technology that may be required to practice this 1223 standard. Please address the information to the IETF Executive 1224 Director. 1226 13. Full Copyright Statement 1228 Copyright (C) The Internet Society (2005). This document is subject to 1229 the rights, licenses and restrictions contained in BCP 78, and except as 1230 set forth therein, the authors retain all their rights. 1232 This document and the information contained herein are provided on an 1233 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 1234 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1235 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1236 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1237 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1238 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.