Network Working Group Rich Woundy INTERNET DRAFT Kim Kinnear Cisco Systems March 2000 Expires September 2000 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. 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract Access concentrators that act as DHCP relay agents need to determine the endpoint locations of IP addresses across public broadband access networks such as cable, DSL, and wireless networks. Because ARP broadcasts are undesirable in public networks, many access concentrator implementations "glean" location information from DHCP messages forwarded by its relay agent function. Unfortunately, the typical access concentrator loses its gleaned information when the access concentrator is rebooted or is replaced. This memo proposes that when gleaned DHCP information is not available, the access concentrator/relay agent obtains the location information directly Rich Woundy Expires June 2000 [Page 1] Internet Draft DHCP Lease Query December 1999 from the DHCP server(s) using a new, lightweight DHCPLEASEQUERY message. 1. Introduction In many broadband access networks, the access concentrator needs to associate an IP address lease to the correct endpoint location, which includes knowledge of the host hardware address, the port or virtual circuit that leads to the host, and/or the hardware address of the intervening subscriber modem. This is particularly important when one or more IP subnets are shared among many ports, circuits, and modems. Representative cable and DSL environments are depicted in Figures 1 and 2 below. +--------+ +---------------+ | DHCP | | DOCSIS CMTS | | Server |-...-| or DVB INA |------------------- +--------+ | (Relay Agent) | | | +---------------+ +------+ +------+ |Modem1| |Modem2| +------+ +------+ | | | +-----+ +-----+ +-----+ |Host1| |Host2| |Host3| +-----+ +-----+ +-----+ Figure 1: Cable Environment for DHCPLEASEQUERY +--------+ +---------------+ | DHCP | | DSL Access | +-------+ | Server |-...-| Concentrator |-...-| DSLAM | +--------+ | (Relay Agent) | +-------+ +---------------+ | | +------+ +------+ |Modem1| |Modem2| +------+ +------+ | | | +-----+ +-----+ +-----+ |Host1| |Host2| |Host3| +-----+ +-----+ +-----+ Figure 2: DSL Environment for DHCPLEASEQUERY Rich Woundy Expires June 2000 [Page 2] Internet Draft DHCP Lease Query December 1999 Knowledge of this location information benefits the access concentra- tor in several ways: 1. The access concentrator can forward traffic to the access net- work using the correct access network port, down the correct virtual circuit, through the correct modem, to the correct hardware address. 2. The access concentrator can perform IP source address verifica- tion of datagrams received from the access network. The verifi- cation may be based on the datagram source hardware address, the incoming access network port, the incoming virtual circuit, and/or the transmitting modem. 3. The access concentrator can encrypt datagrams which can only be decrypted by the correct modem, using mechanisms such as [BPI]. There are several mechanisms for the access concentrator to obtain this location information: 1. The access concentrator can transmit a broadcast ARP Request [RFC 826], and observe the origin and contents of the ARP Reply. This mechanism is undesirable for three reasons: the burden imposed on the access concentrator to transmit over mul- tiple access ports and virtual circuits, the burden imposed on the numerous subscriber hosts to receive the broadcast, and the ease by which a malicious host can misrepresent itself as the IP endpoint. 2. The access concentrator can "glean" information from DHCP server responses. This mechanism is desirable because of the lack of additional network traffic and the reliable source of the information (the DHCP server), but sometimes this source of information is incomplete. The access concentrator usually can- not glean information from any DHCP unicast (i.e. non-relayed) messages due to performance reasons. Furthermore, the DHCP state information often does not persist across access concen- trator reboots (due to lack of stable storage), and almost never persists across concentrator replacements. 3. The access concentrator can query the DHCP server(s) for loca- tion information. This mechanism is the focus of this document. The DHCPLEASEQUERY message is a new DHCP message type transmitted from a DHCP relay agent to a DHCP server. The DHCPLEASEQUERY-aware relay agent sends the DHCPLEASEQUERY message when it needs to know the location of an IP endpoint. The DHCPLEASEQUERY-aware DHCP server replies with a DHCPACK or DHCPNAK message. The DHCPACK Rich Woundy Expires June 2000 [Page 3] Internet Draft DHCP Lease Query December 1999 response to a DHCPLEASEQUERY message allows the relay agent to determine the IP endpoint location, and the remaining duration of the IP address lease. 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" An access concentrator is a router or switch at the service provider's edge of a public broadband access network. This docu- ment assumes that the access concentrator includes the DHCP relay agent functionality. o "DHCP client" A DHCP client is an Internet host using DHCP to obtain confi- guration parameters such as a network address. o "DHCP relay agent" A DHCP relay agent is a third-party agent that transfers BOOTP and DHCP messages between clients and servers residing on dif- ferent subnets, per [RFC 951] and [RFC 1542]. o "DHCP server" A DHCP server is an Internet host that returns configuration parameters to DHCP clients. o "downstream" Downstream is the direction from the access concentrator towards the broadband subscriber. o "gleaning" Gleaning is the extraction of location information from DHCP messages, as the messages are forwarded by the DHCP relay agent function. o "location information" Rich Woundy Expires June 2000 [Page 4] Internet Draft DHCP Lease Query December 1999 Location information is information needed by the access concen- trator to forward traffic to a broadband-accessible host. This information includes knowledge of the host hardware address, the port or virtual circuit that leads to the host, and/or the hardware address of the intervening subscriber modem. o "primary DHCP server" The primary DHCP server in a DHCP Failover environment is con- figured to provide primary service to a set of DHCP clients for a particular set of subnet address pools. o "secondary DHCP server" The secondary DHCP server in a DHCP Failover environment is con- figured to act as backup to a primary server for a particular set of subnet address pools. o "stable storage" Every DHCP server is assumed to have some form of what is called "stable storage". Stable storage is used to hold information concerning IP address bindings (among other things) so that this information is not lost in the event of a server failure which requires restart of the server. o "upstream" Upstream is the direction from the broadband subscriber towards the access concentrator. 3. Background The focus of this document is to enable access concentrators to send DHCPLEASEQUERY messages to DHCP servers, to obtain location informa- tion of broadband access network devices. This document assumes that many access concentrators have an embedded DHCP relay agent func- tionality. Typical access concentrators include DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB Interactive Network Adapters (INAs) [EUROMODEM], and DSL Access Concentrators. The DHCPLEASEQUERY message is an optional extension to the DHCP pro- tocol [RFC 2131]. Unlike previous DHCP message types, the DHCP relay agent originates and sends the DHCPLEASEQUERY message to the DHCP server, and processes the reply from the DHCP server (a DHCPACK or DHCPNAK). Rich Woundy Expires June 2000 [Page 5] Internet Draft DHCP Lease Query December 1999 In a DHCP Failover environment [FAILOVER], the DHCPLEASEQUERY message can be sent to the primary or secondary DHCP server. In order for the secondary DHCP server to answer DHCPLEASEQUERY messages, the primary DHCP server must send "interesting options" (such as the relay- agent-information option) in Failover BNDUPD messages to the secon- dary DHCP server, as recommended by section 7.1.1 of [FAILOVER]. The DHCPLEASEQUERY message is a query message only, and does not affect the state of the IP address lease. 4. Design Goals The core requirement of this document is to provide a lightweight mechanism for access concentrator implementations to obtain location information for broadband access network devices. The specific assumptions that drove the content of this document are the follow- ing: 1. Access concentrators have embedded DHCP relay agent functional- ity, and can glean location information in the relay agent function. 2. Access concentrators obtain location information from DHCP servers. The location information is dynamic and subject to change over time. The access concentrator cannot reliably store location information, nor generate it algorithmically. In par- ticular, a single IP subnet may extend to behind many broadband modems. 3. Access concentrators use DHCP messages to obtain location information. Access concentrators do not have SNMP management clients nor LDAP clients -- this is why this document does not leverage the proposed DHCP Server MIB [DHCPMIB] nor leverage the proposed DHCP LDAP schema [DHCPSCHEMA]. 4. Access concentrators use the same set of DHCP servers for DHCP relay as for obtaining location information. 5. Protocol Overview The access concentrator initiates all DHCPLEASEQUERY message conver- sations. This document assumes that the access concentrator gleans location information in its DHCP relay agent function. However, the location information is usually unavailable after the reboot or replacement of the access concentrator. Rich Woundy Expires June 2000 [Page 6] Internet Draft DHCP Lease Query December 1999 Suppose the access concentrator is a router, and further suppose that the router receives an IP datagram to forward downstream to the pub- lic broadband access network. If the location information for the downstream next hop is missing, the access concentrator sends one or more DHCPLEASEQUERY message(s), each containing the IP address of the downstream next hop in the "ciaddr" field. The DHCP servers that implement this protocol always sends a response to the DHCPLEASEQUERY message: either a DHCPACK or DHCPNAK. The DHCP server replies to the DHCPLEASEQUERY message with a DHCPACK message if the "ciaddr" corresponds to a lease about which the server has definitive location information. The server replies with a DHCPNAK message if the server does not have definitive location information concerning the lease implied by the "ciaddr". Note that non- DHCPLEASEQUERY-literate DHCP servers are likely to drop the message silently. The DHCPACK message reply contains the physical address of the IP address lease owner in the "htype", "hlen", and "chaddr" fields. The reply often contains the time until expiration of the lease, and the original contents of the relay-agent-information option [RELAYAGEN- TINFO]. 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. 6. Packet Formats The DHCPLEASEQUERY message uses the DHCP message format as described in [RFC 2131], and uses message number TBD (author suggests "13") in the DHCP Message Type option (option 53). The DHCPLEASEQUERY message has the following pertinent message contents: o The values of htype, hlen, and chaddr MUST be set to 0. At this time, this DHCP message is used for querying on IP address, not on hardware address or DHCP client ID. o The ciaddr MUST be set to the IP address of the lease to be queried. o The giaddr MUST be set to the IP address of the requestor (i.e. the access concentrator). The giaddr is independent of the ciaddr to be searched. o The Parameter Request List SHOULD be set to the options of interest to the requestor. The interesting options are likely to include the IP Address Lease Time option (option 51) and the Relay Agent Information option (82). Rich Woundy Expires June 2000 [Page 7] Internet Draft DHCP Lease Query December 1999 The DHCP server replies to the DHCPLEASEQUERY message with a DHCPACK message if the ciaddr corresponds to a lease about which the server has definitive information. The server replies with a DHCPNAK message if the server does not have definitive information concerning the lease implied by the ciaddr. The server expects a giaddr in the DHCPLEASEQUERY message, and unicasts the result to the giaddr. If the giaddr field is "0.0.0.0", then the DHCP server does not reply to the DHCPLEASEQUERY message. If the IP Address Lease Time (option 51) is specified in the Parame- ter Request List, the DHCP server returns this option in the DHCPACK with the remaining time until lease expiration, if the lease is currently leased. The server does not return this option if the lease is not leased, i.e. is available, offered, expired, pending- available, or unavailable. This allows the requestor (i.e. the access concentrator) to determine whether the lease is currently leased, and for how long. The DHCPACK message MUST encode the physical address of the lease owner in the htype, hlen, and chaddr fields, and SHOULD include the values of the options requested (if available) in the Parameter Request List of the DHCPLEASEQUERY message. The DHCP server uses information from the lease state for the DHCPACK option values. The value for the IP Address Lease Time in the DHCPACK is the number of seconds that remain until the current lease expires (assuming the number of seconds is greater than zero). The value for the Relay Agent Information option in the DHCPACK is the value of the Relay Agent Information option from the most recent DHCPDISCOVER or DHCPREQUEST message from the DHCP client to this DHCP server. 7. Protocol Details In order to accommodate DHCPLEASEQUERY messages sent to a DHCP Fail- over secondary server [FAILOVER] when the primary server is down, the primary server must communicate the Relay Agent Information option (82) values to the secondary server via the DHCP Failover BNDUPD mes- sages. [I'm not sure what else to say here. I guess a document reorg is in order.] 8. Security [Got to say something about security here. I expect that we will re- use the approach in the DHCP authentication draft.] Rich Woundy Expires June 2000 [Page 8] Internet Draft DHCP Lease Query December 1999 9. Acknowledgments Jim Forster, Kim Kinnear, Joe Ng, Guenter Roeck, and Mark Stapp con- tributed greatly to the initial creation of the DHCPLEASEQUERY mes- sage. 10. References [RFC 826] Plummer, D., "Ethernet Address Resolution Protocol: Or con- verting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", RFC 826, November 1982. [RFC 951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC 951, September 1985. [RFC 1542] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor Extensions", Internet RFC 2132, March 1997. [BPI] CableLabs, "Baseline Privacy Interface Specification", SP-BPI- I02-990319, March 1999. [DHCPMIB] Hibbs, R., Waters, G., "Dynamic Host Configuration Protocol (DHCP) Server MIB", draft-ietf-dhc-server-mib-04.txt, October 1999. [DHCPSCHEMA] Bennett, A., Volz, B., Westerinen, A., "DHCP Schema for LDAP", draft-ietf-dhc-schema-01.txt, October 1999. [DOCSIS] CableLabs, "Data-Over-Cable Service Interface Specifica- tions: Cable Modem Radio Frequency Interface Specification SP- RFI-I05-991105", November 1999. [EUROMODEM] ECCA, "Technical Specification of a European Cable Modem for digital bi-directional communications via cable networks", Version 1.0, May 1999. [FAILOVER] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., Rich Woundy Expires June 2000 [Page 9] Internet Draft DHCP Lease Query December 1999 Rabil, G., Dooley, M., Kapur, A., "DHCP Failover Protocol", draft-ietf-dhc-failover-05.txt, October 1999. [RELAYAGENTINFO] Patrick, M., "DHCP Relay Agent Information Option", draft-ietf-dhc-agent-options-09.txt, March 2000. 11. Author's information Rich Woundy Kim Kinnear Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 Phone: (978) 244-8000 EMail: rwoundy@cisco.com kkinnear@cisco.com 12. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to oth- ers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and dis- tributed, 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 Stan- dards 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. 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 Rich Woundy Expires June 2000 [Page 10] Internet Draft DHCP Lease Query December 1999 FITNESS FOR A PARTICULAR PURPOSE. Open Issues These issues need to be resolved: 1. Can the DHCPLEASEQUERY message be sent by parties other than relay agents? 2. Can the DHCPLEASEQUERY message be extended to find lease infor- mation by physical address or by DHCP Client ID? This might be useful for non-router access concentrators. Rich Woundy Expires June 2000 [Page 11]