--- 1/draft-ietf-dhc-leasequery-07.txt 2006-02-04 23:04:35.000000000 +0100 +++ 2/draft-ietf-dhc-leasequery-08.txt 2006-02-04 23:04:35.000000000 +0100 @@ -1,92 +1,94 @@ Dynamic Host Configuration Working Group Rich Woundy INTERNET DRAFT Comcast Cable Kim Kinnear Cisco Systems - March 2004 - Expires September 2004 + February 2005 + Expires August 2005 DHCP Lease Query - + Status of this Memo - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + or will be disclosed, and any of which I become aware will be + disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt + http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. + http://www.ietf.org/shadow.html Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. + Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract - A DHCP server contains considerable authoritative information + A DHCPv4 server contains considerable authoritative information concerning the IP addresses it has leased to DHCP clients. Other processes and devices, many that already send and receive DHCP format packets, sometimes need to access this information. The leasequery - protocol is designed to give these processes and devices a + protocol for DHCPv4 is designed to give these processes and devices a lightweight way to access information that may be critical to their operation. Table of Contents 1. Introduction................................................. 2 2. Terminology.................................................. 5 3. Background................................................... 6 4. Design Goals................................................. 7 4.1. Broadcast ARP is Undesirable............................... 7 - 4.2. SNMP and LDAP Client Functionality is Lacking.............. 7 - 4.3. DHCP Relay Agent Functionality is Common................... 7 + 4.2. SNMP and LDAP Client Functionality is Lacking.............. 8 + 4.3. DHCP Relay Agent Functionality is Common................... 8 4.4. DHCP Servers as a Reliable Source of Location Information.. 8 - 4.5. Minimal Additional Configuration is Required............... 8 - 5. Protocol Overview............................................ 8 - 6. Protocol Details............................................. 11 - 6.1. Definitions required for DHCPLEASEQUERY processing......... 11 + 4.5. Minimal Additional Configuration is Required............... 9 + 5. Protocol Overview............................................ 9 + 6. Protocol Details............................................. 12 + 6.1. Definitions required for DHCPLEASEQUERY processing......... 12 6.2. Sending the DHCPLEASEQUERY Message......................... 13 6.3. Receiving the DHCPLEASEQUERY Message....................... 15 - 6.4. Responding to the DHCPLEASEQUERY Message................... 15 - 6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or....... 19 - 6.6. Receiving no response to the DHCPLEASEQUERY Message........ 20 - 6.7. Lease binding data storage requirements.................... 21 - 6.8. Using the DHCPLEASEQUERY message with multiple DHCP servers 22 - 7. Security Considerations...................................... 22 - 8. IANA Considerations.......................................... 23 - 9. Acknowledgments.............................................. 23 + 6.4. Responding to the DHCPLEASEQUERY Message................... 16 + 6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or....... 20 + 6.6. Receiving no response to the DHCPLEASEQUERY Message........ 21 + 6.7. Lease binding data storage requirements.................... 22 + 6.8. Using the DHCPLEASEQUERY message with multiple DHCP servers 23 + 7. Security Considerations...................................... 23 + 8. IANA Considerations.......................................... 24 + 9. Acknowledgments.............................................. 24 10. References.................................................. 24 10.1. Normative References...................................... 24 - 10.2. Informative References.................................... 24 + 10.2. Informative References.................................... 25 11. Author's information........................................ 25 - 12. Intellectual Property Statement............................. 25 + 12. Intellectual Property Statement............................. 26 13. Full Copyright Statement.................................... 26 1. Introduction - A DHCP server contains considerable authoritative information + A DHCPv4 server contains considerable authoritative information concerning the IP addresses it has leased to DHCP clients. Sometimes devices or other processes may need access to this information. In some cases, these devices or processes already have the capability to send and receive DHCP packets, and so the leasequery protocol is designed to give these processes and devices a low overhead way to access such information. For example, access concentrators that act as DHCP relay agents sometimes derive information important to their operation by extracting data out of the DHCP packets they forward, a process known @@ -175,20 +177,23 @@ DHCP server has no knowledge of the information specified in the query (e.g., IP address, MAC address, or Client-identifier option). The DHCPLEASEQUERY message does not presuppose a particular use for the information it returns -- it is simply designed to return information for which the DHCP server is an authoritative source to a client which requests that information. It is designed to make it straightforward for processes and devices which already interpret DHCP packets to access information from the DHCP server. + This document specifies an extension specifically to the DHCPv4 + protocol [RFC2131]. + 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. This document uses the following terms: o "access concentrator" @@ -375,37 +379,38 @@ current when this client's lease was last granted or renewed, allowing the access concentrator to forward the IP datagram. An alternative approach is to send in a DHCPLEASEQUERY message with the "ciaddr" field empty and the MAC address (i.e., "htype", "hlen", and "chaddr" fields) with a valid MAC address or a Client-identifier option (option 61) appearing in the options area. In this case, the DHCP server must return an IP address in the "ciaddr" if it has any record of the client described by the Client-identifier or MAC address. In the absence of specific configuration information to the - contrary (see Section 6.4) it should be the IP address most recently - used by the client described by the MAC address or Client-identifier - option (or the client described by both, if both appear). + contrary (see Section 6.4) it SHOULD be the IP address with the + latest client-last-transaction-time associated with the client + described by the MAC address or Client-identifier option (or the + client described by both, if both appear). The DHCP servers that implement this protocol always send a response to the DHCPLEASEQUERY message: either a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN (or in some cases, DHCPUNIMPLEMENTED). The reasons why a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN message might be generated are explained in the specific query regimes, below. Servers which do not implement the DHCPLEASEQUERY message fall into two classes. Those that simply do not know about the DHCPLEASEQUERY message will simply not respond to it, so clients which send the DHCPLEASEQUERY message must be prepared to deal with this behavior. Servers which are aware of the DHCPLEASEQUERY message but do not - implement it should respond with a DHCPUNIMPLEMENTED message but may + implement it SHOULD respond with a DHCPUNIMPLEMENTED message but may simply not respond. The DHCPLEASEQUERY message can support three query regimes: A server which implements the DHCPLEASEQUERY message must implement all three query regimes. o Query by IP address: For this query, the requester supplies only an IP address in the DHCPLEASEQUERY message. The DHCP server will return any @@ -450,45 +455,45 @@ Query by IP Address, described above. The DHCP server replies with a DHCPLEASEACTIVE message if the Client-identifier in the DHCPLEASEQUERY message currently has an active lease on an IP address in this DHCP server. The server replies with a DHCPLEASEUNKNOWN message if the server does not have an active lease by a client with this Client-identifier. For many DHCP servers, the query by IP address is likely to be the most efficient form of leasequery. This is the form of - DHCPLEASEQUERY that should be used if possible. + DHCPLEASEQUERY that SHOULD be used if possible. The DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message reply must always contain the IP address in the ciaddr field. The DHCPLEASEACTIVE - message should contains the physical address of the IP address lease + message SHOULD contain the physical address of the IP address lease owner in the "htype", "hlen", and "chaddr" fields. The Parameter Request List (option 55) can be used to request specific options to be returned about the IP address in the ciaddr. The reply often contains the time until expiration of the lease, and the original contents of the Relay Agent Information option [RFC 3046]. The access concentrator uses the "chaddr" and Relay Agent Information option to construct location information, which can be cached on the access concentrator until lease expiration. - Any DHCP server which supports the DHCPLEASEQUERY message should save + Any DHCP server which supports the DHCPLEASEQUERY message SHOULD save the information from the most recent Relay Agent Information option (option 82) [RFC 3046] associated with every IP address which it serves. It is assumed that most clients which generate the DHCPLEASEQUERY message will ask for the Relay Agent Information option (option 82) in the Parameter Request List (option 55), and so supporting the DHCPLEASEQUERY message without having the Relay Agent Information option around to return to the client is likely to be less than helpful. - A server which implements DHCPLEASEQUERY should also save the + A server which implements DHCPLEASEQUERY SHOULD also save the information on the most recent Vendor class identifier, option 60, associated with each IP address, since this option is also a likely candidate to be requested by clients sending the DHCPLEASEQUERY message. 6. Protocol Details 6.1. Definitions required for DHCPLEASEQUERY processing The operation of the DHCPLEASEQUERY message requires the definition @@ -633,20 +638,24 @@ The values of htype, hlen, and chaddr MUST be set to 0. The DHCPLEASEQUERY message SHOULD be sent to a DHCP server which is known to possess authoritative information concerning the IP address. The DHCPLEASEQUERY message MAY be sent to more than one DHCP server, and in the absence of information concerning which DHCP server might possess authoritative information concerning the IP address, it SHOULD be sent to all DHCP servers configured for the associated relay agent (if any are known). + Any device expecting to use a DHCPLEASEQUERY message SHOULD ensure + that the Relay Agent Info option that it uses contains information + that unambiguously identifies the device. + 6.3. Receiving the DHCPLEASEQUERY Message A server which implements the DHCPLEASEQUERY message MUST implement all three query regimes, query by IP address, query by MAC address, and query by Client-identifier. A DHCPLEASEQUERY message MUST have a non-zero giaddr. The DHCPLEASEQUERY message MUST have exactly one of: a non-zero ciaddr, a non-zero "htype"/"hlen"/"chaddr", or a Client-identifier option. @@ -756,21 +765,22 @@ preference mechanism. If, after all of the above processing, no value is set in the "ciaddr" field of the DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message, then a DHCPLEASEUNKNOWN message MUST be returned instead. 6.4.2. Building a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message once the "ciaddr" field is set Once the "ciaddr" field of the DHCPLEASEUNASSIGNED is set, the - processing for a DHCPLEASEUNASSIGNED message is complete. + processing for a DHCPLEASEUNASSIGNED message is complete. No other + options returned for the DHCPLEASEUNASSIGNED message. For the DHCPLEASEACTIVE message, the rest of the processing largely involves returning information about the IP address specified in the "ciaddr" field. The IP address in the "ciaddr" field of the DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message MUST be one for which this server is responsible (or a DHCPLEASEUNKNOWN message would be have already been returned early in the processing described in the previous section). @@ -779,23 +789,23 @@ the "ciaddr" field of the DHCPLEASEUNASSIGNED message. If the Client-identifier option (option 61) is specified in the Parameter Request List option (option 55), then the Client-identifier (if any) of the client associated with the IP address in the "ciaddr" field SHOULD be returned in the DHCPLEASEACTIVE message. In the case where more than one IP address has been involved in a DHCP message exchange with the client specified by the MAC address and/or Client-identifier option, then the list of all of the IP - addresses SHOULD be returned in the associated-ip option (option - TBD), if that option was requested as part of the Parameter Request - List option. + addresses MUST be returned in the associated-ip option, whether or + not that option was requested as part of the Parameter Request List + option. If the IP Address Lease Time option (option 51) is specified in the Parameter Request List and if there is a currently valid lease for the IP address specified in the ciaddr, then the DHCP server MUST return this option in the DHCPLEASEACTIVE message with its value equal to the time remaining until lease expiration. If there is no valid lease for the IP address, then the server MUST NOT return the IP Address Lease Time option (option 51). A request for the Renewal (T1) Time Value option or the Rebinding @@ -810,28 +820,33 @@ If the Relay Agent Information (option 82) is specified in the Parameter Request List then the information contained in the most recent Relay Agent Information option received from the relay agent associated with this IP address MUST be included in the DHCPLEASEACTIVE message. The DHCP server MUST the Relay Agent Information option that was received when from the relay agent associated with this IP address. The DHCPLEASEACTIVE message SHOULD include the values of all other - options not specifically discussed above that were requested in the + options not specifically discussed above or specifically excluded by + being configured as "sensitive options" that were requested in the Parameter Request List of the DHCPLEASEQUERY message. The DHCP server uses information from its lease binding database to supply the DHCPLEASEACTIVE option values. The values of the options that were returned to the DHCP client would generally be preferred, but in the absence of those, options that were sent in DHCP client requests would be acceptable. + DHCP servers SHOULD be configurable with a list of "sensitive + options" that will not be returned to the client even if specified in + the Parameter Request List of the DHCPLEASEQUERY message. + In some cases, the Relay Agent Information option in an incoming DHCPREQUEST packet is used to help determine the options returned to the DHCP client which sent the DHCPREQUEST. When responding to a DHCPLEASEQUERY message, the DHCP server MUST use the saved Relay Agent Information option just like it did when responding to the DHCP client in order to determine the values of any options requested by the DHCPLEASEQUERY message. The goal is to return the same option values to the DHCPLEASEQUERY as those that were returned to the DHCPDISCOVER or DHCPREQUEST from the DHCP client (unless otherwise specified, above). @@ -971,24 +986,30 @@ DHCP server implementations that implement the DHCPLEASEQUERY capability MUST save the most recent Relay Agent Information option from the most recent DHCPREQUEST packet for two reasons. First, it is almost certain to be requested by in the dhcp-parameter-request- list option in any DHCPLEASEQUERY request. Second, the saved Relay Agent Information option may be necessary to determine the value of other options given to the DHCP client, if these are requested by the dhcp-parameter-request list in the DHCPLEASEQUERY request. - Some of the clients of the DHCPLEASEQUERY capability will also - request the vendor-class-id of in the dhcp-parameter-request list, - and so a DHCP server SHOULD save that option in the lease binding - data storage. + This is a list of the information that is required to successfully + implement + + o relay-agent-info option from client packet: MUST store with + binding. + + o client-last-transaction-time of last client interaction: MUST + store with binding. + + o vendor-class-id: SHOULD store with binding. These data storage requirements are minimally larger than those required for normal operation of the DHCP protocol, as required to properly implement [RFC2131]. 6.8. Using the DHCPLEASEQUERY message with multiple DHCP servers When using the DHCPLEASEQUERY message in an environment where multiple DHCP servers may contain authoritative information about the same IP address (such as when two DHCP servers are cooperating to @@ -1024,21 +1045,21 @@ Clients of the DHCPLEASEQUERY message SHOULD ensure that their data path to the DHCP server is secure. Clients SHOULD use Relay Agent Information security as a way to achieve this goal. This will ensure against the clients receiving false data, due perhaps to a third party spoofing the reply from a DHCPLEASEQUERY message. Access concentrators SHOULD minimize potential denial of service attacks on the DHCP servers by minimizing the generation of DHCPLEASEQUERY messages. In particular, the access concentrator - should employ negative caching (i.e. cache DHCPLEASEUNASSIGNED, + SHOULD employ negative caching (i.e. cache DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY messages) and ciaddr restriction (i.e. don't send a DHCPLEASEQUERY message with a ciaddr outside of the range of the attached broadband access networks). Together, these mechanisms limit the access concentrator to transmitting one DHCPLEASEQUERY message (excluding message retries) per legitimate broadband access network IP address after a reboot event. DHCP servers supporting the DHCPLEASEQUERY message SHOULD ensure that they cannot be successfully attacked by being flooded with large @@ -1158,34 +1178,21 @@ IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 13. Full Copyright Statement -Copyright (C) The Internet Society (2004). All Rights Reserved. - -This document and translations of it may be copied and furnished to -others, and derivative works that comment on or otherwise explain it or -assist in its implementation may be prepared, copied, published and -distributed, in whole or in part, without restriction of any kind, -provided that the above copyright notice and this paragraph are included -on all such copies and derivative works. However, this document itself -may not be modified in any way, such as by removing the copyright notice -or references to the Internet Society or other Internet organizations, -except as needed for the purpose of developing Internet standards in -which case the procedures for copyrights defined in the Internet -Standards process must be followed, or as required to translate it into -languages other than English. - -The limited permissions granted above are perpetual and will not be -revoked by the Internet Society or its successors or assigns. +Copyright (C) The Internet Society (2005). This document is subject to +the rights, licenses and restrictions contained in BCP 78, and except as +set forth therein, the authors retain all their rights. -This document and the information contained herein is provided on an "AS -IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK -FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT -LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT -INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR -FITNESS FOR A PARTICULAR PURPOSE. +This document and the information contained herein are provided on an +"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR +IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET +ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, +INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE +INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED +WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.