--- 1/draft-ietf-dhc-leasequery-04.txt 2006-02-04 23:04:33.000000000 +0100 +++ 2/draft-ietf-dhc-leasequery-05.txt 2006-02-04 23:04:33.000000000 +0100 @@ -1,20 +1,22 @@ Dynamic Host Configuration Working Group Rich Woundy -INTERNET DRAFT Kim Kinnear +INTERNET DRAFT Comcast Cable + + Kim Kinnear Cisco Systems - October 2002 - Expires April 2003 + March 2003 + Expires September 2003 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. @@ -25,47 +27,60 @@ 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 (2002). All Rights Reserved. + Copyright (C) The Internet Society (2003). 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 - from the DHCP server(s) using a new, lightweight DHCPLEASEQUERY - message. + A DHCP 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 + lightweight way to access information that may be critical to their + operation. 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. + A DHCP server contains considerable authoritative information con- + cerning 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 light- + weight way to access information that may be critical to their opera- + tion. + + For example, access concentrators that act as DHCP relay agents some- + times derive information important to their operation by extracting + data out of the DHCP packets they forward, a process known as "glean- + ing". 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 can obtain the + location information directly from the DHCP server(s) using the new + lightweight DHCPLEASEQUERY message. + + To continue this example in more depth, in many broadband access net- + works, 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| +------+ +------+ | | | +-----+ +-----+ +-----+ @@ -81,60 +95,67 @@ +---------------+ | | +------+ +------+ |Modem1| |Modem2| +------+ +------+ | | | +-----+ +-----+ +-----+ |Host1| |Host2| |Host3| +-----+ +-----+ +-----+ Figure 2: DSL Environment for DHCPLEASEQUERY - Knowledge of this location information benefits the access concentra- - tor in several ways: + + Knowledge of this location information can benefit the access concen- + trator 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 verif- ication 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] or [BPI+]. - The premise of this document is that the access concentrator obtains - this location information primarily from "gleaning" information from - DHCP server responses sent through the relay agent. When location - information is not available from "gleaning", e.g. due to reboot, - the access concentrator can query the DHCP server(s) for location - information using the DHCPLEASEQUERY message. The DHCPLEASEQUERY - mechanism is the focus of this document. + The access concentrator in this example obtains the location informa- + tion primarily from "gleaning" information from DHCP server responses + sent through the relay agent. When location information is not + available from "gleaning", e.g. due to reboot, the access concentra- + tor can query the DHCP server(s) for location information using the + DHCPLEASEQUERY message defined in this document. The DHCPLEASEQUERY message is a new DHCP message type transmitted - from a DHCP relay agent to a DHCP server. The DHCPLEASEQUERY-aware + from a DHCP relay agent to a DHCP server. A 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 DHCPLEASEKNOWN, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN message. The DHCPLEASEACTIVE response to a DHCPLEASEQUERY message allows the relay agent to determine the IP endpoint location, and the remaining duration of the IP address lease. The DHCPLEASEKNOWN is similar to a DHCPLEASEACTIVE message but indicates that there is no currently active lease on the resultant IP address. The DHCPLEASEUN- KNOWN message indicates that the DHCP server has no knowledge of the information specified in the query (e.g., IP address, MAC address, or client-id option). + The DHCPLEASEQUERY message does not presuppose a particular use for + the information it returns -- it is simply designed to return infor- + mation 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. + 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" @@ -216,54 +237,61 @@ 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. + The focus of this document is to enable processes and devices which + wish to access information from the DHCP server in a lightweight and + convenient manner. It is especially appropriate for processes and + devices which already interpret DHCP packets. + + One important motivating example is that the DHCPLEASEQUERY message + allows access concentrators to send DHCPLEASEQUERY messages to DHCP + servers, to obtain location information of broadband access network + devices. This document assumes that many access concentrators have an embedded DHCP relay agent functionality. Typical access concentrators include DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB Interac- - tive Network Adapters (INAs) [EUROMODEM], and DSL Access - Concentrators. + tive Network Adapters (INAs) [EUROMODEM], and DSL Access Concentra- + tors. 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. + tocol [RFC 2131]. 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 [RFC 3046]) in Failover BNDUPD messages to the secondary DHCP server, as recommended by section 7.1.1 of [FAIL- OVER]. The DHCPLEASEQUERY message is a query message only, and does not affect the state of the IP address or the binding information associ- ated with it. 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 specifics of - the broadband environment that drove the approach of this document - follow. + The goal of this document is to provide a lightweight mechanism for + processes or devices to access information contained in the DHCP + server. It is designed to allow processes and devices which already + process and interpret DHCP messages to access this information in a + rapid and lightweight manner. + + Some of this information might be acquired in a different way, and + the following sections discuss some of these alternative approaches. 4.1. Broadcast ARP is Undesirable The access concentrator can transmit a broadcast ARP Request [RFC 826], and observe the origin and contents of the ARP Reply, to recon- struct the location information. The ARP mechanism is undesirable for three reasons: 1. the burden on the access concentrator to transmit over multiple @@ -315,20 +343,26 @@ DHCP server is a single point of failure. 4.5. Minimal Additional Configuration is Required Access concentrators can usually query the same set of DHCP servers used for forwarding by the relay agent, thus minimizing configuration requirements. 5. Protocol Overview + In the following discussion of the DHCPLEASEQUERY message, the client + of the message is assumed to be an access concentrator. Note that + access concentrators are not the only allowed (or required) consumers + of the information provided by the DHCPLEASEQUERY message, but they + do give reader a concrete feel for how the message might be used. + 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. 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 @@ -371,22 +405,22 @@ assigned that IP address. The DHCP server replies with a DHCPLEASEKNOWN or DHCPLEASEACTIVE message if the IP address in the DHCPLEASEQUERY message corresponds to an IP address about which the server has defini- tive information (ie., it is authorized to lease this IP address). The server replies with a DHCPLEASEUNKNOWN message if the server does not have definitive information concerning the address in the DHCPLEASEQUERY message. - A server which implements the DHCPLEASEQUERY message MUST imple- - ment this capability. + A server which implements the DHCPLEASEQUERY message MUST + implement this capability. o Query by MAC address: For this query, the requester supplies only a MAC address in the DHCPLEASEQUERY message. The DHCP server will return any infor- mation that it has on the IP address most recently accessed by a client with that MAC address. In addition, it may supply addi- tion IP addresses which have been associated with that MAC address in different subnets. Information about these bindings can then be found using the Query by IP Address, described @@ -493,21 +527,21 @@ TBD DHCPUNIMPLEMENTED 2. There is a new bit defined in the "flags" field of the DHCP packet (see Section 1, Figure 1 and Table 1 of [RFC 2131]). It is called the R: RESERVATION flag. The revised Figure 2 from [RFC 2131] is show here: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |B| tbd MBZ | + |B|R| MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B: BROADCAST flag R: RESERVATION FLAG MBZ: MUST BE ZERO (reserved for future use) Revised Figure 2 from RFC2131: Format of the 'flags' field @@ -1004,24 +1037,24 @@ 7. Security Considerations Access concentrators that use DHCP gleaning, refreshed with DHCPLEASEQUERY messages, will maintain accurate location information. Location information accuracy ensures that the access concentrator can forward data traffic to the intended location in the broadband access network, can perform IP source address verification of datagrams from the access network, and can encrypt traffic which can only be decrypted by the intended access modem (e.g. [BPI] and [BPI+]). As a result, the access concentrator does not need to - depend on ARP broadcasts across the access network, which is - susceptible to malicious hosts which masquerade as the intended IP - endpoints. Thus, the DHCPLEASEQUERY message allows an access concen- - trator to provide considerably enhanced security. + depend on ARP broadcasts across the access network, which is suscep- + tible to malicious hosts which masquerade as the intended IP end- + points. Thus, the DHCPLEASEQUERY message allows an access concentra- + tor to provide considerably enhanced security. DHCP servers SHOULD prevent exposure of location information (partic- ularly the mapping of hardware address to IP address lease, which can be an invasion of broadband subscriber privacy) by leveraging DHCP authentication [RFC 3118]. With respect to authentication, the access concentrator acts as the "client". The use of "Authentication Protocol 0" (using simple unencoded authentication token(s) between the access concentrator and the DHCP server) is straightforward. Alternatively, use of IPsec would also be a way to ensure security between the relay agent and the DHCP server. @@ -1113,35 +1146,34 @@ for digital bi-directional communications via cable networks", Version 1.0, May 1999. [FAILOVER] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., Rabil, G., Dooley, M., Kapur, A., "DHCP Failover Protocol", draft-ietf-dhc-failover-10.txt, January 2002. 11. Author's information Rich Woundy - AT&T Broadband + Comcast Cable 27 Industrial Ave. Chelmsford, MA 01824 Phone: (978) 244-4010 - EMail: rwoundy@broadband.att.com + EMail: richard_woundy@cable.comcast.com Kim Kinnear Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 Phone: (978) 497-8000 - EMail: kkinnear@cisco.com 12. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intel- lectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with @@ -1153,21 +1184,21 @@ the use of such proprietary rights by implementors or users of this specification can be obtained from the 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 stan- dard. Please address the information to the IETF Executive Director. 13. Full Copyright Statement -Copyright (C) The Internet Society (2002). All Rights Reserved. +Copyright (C) The Internet Society (2003). 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