INTERNET-DRAFT Eric A. Hall Updates: RFC 951, 2131 Independent Consultant Expires: January 12, 2001 Ted Lemon Internet Software Consortium July 12, 2000 Multicast BOOTP/DHCPv4 Relay Agents 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. Abstract The current design of the Bootstrap Protocol (BOOTP) and the Dynamic Host Configuration Protocol (DHCP) requires the use of a relay agent in order for client requests to reach servers which are located on remote network segments. Network administrators must manually configure the relay agents with the IP addresses of the target servers, and must update the configuration whenever the servers' addresses are changed. This memo describes a mechanism whereby relay agents can be configured to use multicast addresses in lieu of specific destination addresses for the target servers. By having the relay agents forward BOOTP/DHCP requests to a multicast address, and by having the BOOTP/DHCP servers listen for requests on this multicast address, the servers will always be able to receive the requests regardless of the link-specific IP addresses in use, thereby eliminating the need for the manual configuration and maintenance of BOOTP/DHCP relay agents. Hall & Lemon Expires Jan 12, 2001 [Page 1] INTERNET DRAFT Multicast BOOTP/DHCPv4 Relay Agents July 2000 1. Introduction The Bootstrap Protocol (BOOTP) [1, 2] defines a mechanism whereby hosts can automatically request and retrieve networking information such as an IP address, subnet mask, default router, and so forth. The Dynamic Host Configuration Protocol (DHCP) [3] provides services that are very similar to BOOTP, with the notable differences of providing "pools" of addresses that can be dynamically assigned and "leases" of variable duration. For both of these protocols, clients transmit configuration requests to the local network, and any BOOTP or DHCP servers that may be present on the local network may respond to the request with configuration information for the client to use. If a server is not available on the local network, both protocols recognize and endorse the use of a relay agent to forward the client requests to remote servers or networks, allowing a remote server to receive and respond to the requests. In essence, the relay agent provides a BOOTP/DHCP proxy, since it listens for local requests and forwards them to a specified destination, and also relays responses from the servers back to the clients. In all cases, the protocol exchange uses a mix of UDP broadcasts and unicasts. Although relay agents have proven to be useful in a large number of sites, the proxy-centric design of the protocol has meant that a significant amount of time and effort is required on the part of network administrators in order to configure and maintain the relay agents. In particular, network administrators have to explicitly configure relay agents for every subnet that has BOOTP or DHCP clients and which does not also have a local server, providing the relay with an explicit destination address of the remote server(s) or network(s). Furthermore, the relay agents have to be manually reconfigured whenever the IP address associated with a server is changed (this could be as a result of a new addressing scheme, an equipment move, or a shifting of roles on existing equipment, among other causes). Unfortunately, changes happen quite often on many large networks, resulting in a significant amount of operational overhead being expended on maintaining the relay agents. However, by using IP multicasts [4], manual configuration of relay agents can practically be eliminated. Instead of an administrator defining an explicit destination address on each relay agent, the relay agents can be configured to forward requests to a well-known multicast address. As long as the BOOTP/DHCP servers are monitoring this group address (and as long as the organization's infrastructure supports this usage), the servers would receive the requests and could respond to them regardless of their location in the network. More importantly, once the relay agents were configured to use multicast addresses for the relay destination, they would not have to be changed again, since the multicast infrastructure would propagate the requests to all of the servers in the multicast group, regardless of their location or IP addresses. As long as the multicasts were propagated to the segments that the servers were Hall & Lemon Expires Jan 12, 2001 [Page 2] INTERNET DRAFT Multicast BOOTP/DHCPv4 Relay Agents July 2000 on, the servers would always be able to receive BOOTP/DHCP requests that were forwarded by the relay agents. It is also important to note that the use of multicasts for this design does not exclude the historical usage of unicasts or directed broadcasts with relay agents. Organizations that wish to continue using those approaches (or who have no choice in the matter due to product constraints) can continue to do so, and those relay agents ought to be able to coexist peacefully with multicast- aware relay agents without any problem. 1.1 Requirements Throughout this memo, the words that are used to define the significance of particular requirements are capitalized. These words are: o "MUST" This word or the adjective "REQUIRED" means that the item is an absolute requirement of this specification. o "MUST NOT" This phrase means that the item is an absolute prohibition of this specification. o "SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. o "SHOULD NOT" This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. o "MAY" This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. 1.2 Terminology This memo uses terms that are consistent with the BOOTP and DHCP specifications. For clarity, these terms are defined as follows: o "BOOTP client" Hall & Lemon Expires Jan 12, 2001 [Page 3] INTERNET DRAFT Multicast BOOTP/DHCPv4 Relay Agents July 2000 A BOOTP client is an Internet host using BOOTP to obtain configuration parameters such as a network address. O "BOOTP server" A BOOTP server is an Internet host that returns configuration parameters to BOOTP clients. o "DHCP client" A DHCP client is an Internet host using DHCP to obtain configuration parameters such as a network address. o "DHCP server" A DHCP server is an Internet host that returns configuration parameters to DHCP clients. o "relay agent" A relay agent is an Internet host or router that passes BOOTP/DHCP messages between BOOTP/DHCP clients and BOOTP/DHCP servers. BOOTP and DHCP are designed to share the same relay agent technology, which is defined by the BOOTP protocol specification. o "binding" A binding is a collection of configuration parameters, including at least an IP address, associated with or "bound to" a BOOTP or DHCP client. Bindings are managed by BOOTP/DHCP servers, although the concept of a "bound configuration" is mostly specific to DHCP, and has no real corollary in BOOTP (the latter simply assigns configurations and does not track its usage). 2. Principles of Operation Using multicasts with relay agents is relatively simple, although certain behaviors have to be standardized in order for implementations to interoperate successfully. The core principal behind this memo is that the existing operational behavior of the BOOTP and DHCP protocols should not be changed. Therefore, the actual protocol-specific behavior of the clients, relay agents and servers has not been changed at all. The only difference between this memo and the existing specifications is the optional use of multicasting between the relay agents and the servers, although even this usage is limited to specific operations. In essence, a BOOTP/DHCP client must continue to behave as specified in the relevant specifications, broadcasting and/or unicasting query messages depending upon their current state. A relay agent that supports the model of operation defined herein would forward any broadcast queries that it receives to a well- Hall & Lemon Expires Jan 12, 2001 [Page 4] INTERNET DRAFT Multicast BOOTP/DHCPv4 Relay Agents July 2000 known multicast address (instead of forwarding them to an explicitly configured unicast or directed-broadcast address). Any servers monitoring the multicast group which receive these messages would return the response messages using directed unicast responses, as normal. Servers MUST NOT send responses back to the multicast group, clients MUST NOT monitor the group address, and relay agents SHOULD NOT monitor the group address. Additional details and principles are provided in the following sections. 2.1 Multicast Addresses and Time-To-Live Issues Historically, infrastructure-oriented application protocols that used multicast delivery had to limit the Time-To-Live values of the IP packets in order to constrain propagation (a default TTL of "1 hop" is recommended in the multicast specification). However, a limited TTL is insufficient for most organizations, particularly when used with BOOTP/DHCP relay agents in a highly-distributed organization, as this model constrains the placement of servers (all clients are required to be within a 4-hop radius of the servers, for example). Conversely, a large TTL would not work consistently across a highly-distributed organization either, since it could result in excessive propagation across organizational boundaries if it were set to a large value and used near a boundary router. One solution to this problem is the use of administratively scoped multicast addresses [5], which use artificial (software-based) boundaries to limit the propagation of certain multicast addresses. By enforcing this behavior on boundary routers and firewalls, network administrators can use large TTL values for specific multicast groups without having to worry about the packets being propagating beyond the organization's network. For this reason, the authors of this memo suggest the use of an administratively scoped multicast addresses, as defined in RFC 2365. In particular, the authors suggest the use of a multicast address from the IPv4 Local Scope defined in RFC 2365, since some organizations may wish to separate BOOTP/DHCP services into distinct inter-organizational groupings, while other organizations may wish to run a single scope for all BOOTP/DHCP services. The IPv4 Local Scope meets both of these requirements, since it can exist in multiple (non-overlapping) instances, or as a single scope that is stretched across an entire organization. A request for a relative address from the IPv4 Local Scope block was made to IANA, and the relative address "6" has been assigned to this memo. Therefore, implementations MUST use the multicast address of 239.255.255.249 as the default multicast address. When using this address, the default TTL MUST be set to 255. In all cases, implementations SHOULD allow administrators to manually override the multicast addresses and TTL values. This will ensure that administrators can still limit propagation if they do Hall & Lemon Expires Jan 12, 2001 [Page 5] INTERNET DRAFT Multicast BOOTP/DHCPv4 Relay Agents July 2000 not yet have infrastructure equipment that fully supports the principles and usage of administratively scoped multicast addressing. 2.2 Membership in the Multicast Group The three basic components involved in the traditional binding process are clients, servers and relay agents, each of which exhibit different behavior at different times, depending upon their current state and the BOOTP/DHCP messages being exchanged. In the multicasting model proposed in this memo, some of these behaviors are slightly different: o clients Clients MUST continue to perform as prescribed in the BOOTP and DHCP specifications. Clients MUST NOT transmit any data to nor read any data from the multicast group addresses specified in this memo. They would gain no benefit from doing so, would generate useless traffic that had to propagated to every segment with an active member in the multicast group, and could cause unexpected problems to occur. o servers Servers MUST continue to perform as prescribed in the BOOTP and DHCP specifications, with the additional requirement that servers MUST join a multicast group, and MUST listen for messages sent to that group address. This group address should either be the address defined in section 2.1, or an address defined by the local network manager. The server MUST NOT send any datagrams to the multicast group, and MUST only listen to group traffic. o relay agents The behavior of relay agents that conform to the model specified in this memo would only change slightly in comparison to the historical behavior. Anytime the relay agent would normally forward a client request to a remote server (whether via unicasts or directed broadcasts), the relay agent would now forward that request to a multicast address (either the one described in section 2.1 or one defined by the local network manager). Note that the relay agent SHOULD NOT join the multicast group address, SHOULD NOT cause any IGMP Join or Leave messages [6] for that group address to be sent, and SHOULD NOT read any data from that group address. The reason for restricting relay agents from joining the multicast group is to prevent unnecessary propagation of client requests. If all of the relay agents across the network were to join the multicast group, then every network segment with a relay agent would receive a copy of every client request sent on any segment, which is unnecessary and would be wasteful of bandwidth. Instead, by having the relay agents only transmit (but not register as listeners), the datagrams will only be sent to the network segments that have active servers. Hall & Lemon Expires Jan 12, 2001 [Page 6] INTERNET DRAFT Multicast BOOTP/DHCPv4 Relay Agents July 2000 Some multicast implementations may not allow an application to transmit datagrams to a multicast address which has not been joined, or may present operational problems (such as failing to perform data-link multicast address conversion). In those cases, it would be acceptable (but highly undesirable) for the relay agent to join the multicast group. 3. References [1] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, September 1985. [2] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1532, October 1993. [3] Droms, R., "Dynamic Host Configuration Protocol (DHCP)", RFC 2131, March 1997. [4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, August 1989. [5] Meyer, D. "Administratively Scoped IP Multicast", RFC 2365, July 1998. [6] Fenner, W. "Internet Group Message Protocol, v2", RFC 2236, November 1997. 4. Authors' Addresses Eric A. Hall Network Technology Research Group 1840 41st Avenue, Suite 102 Capitola, CA 95010 Phone: +1-650-685-0557 Fax: +1-650-685-0463 Email: ehall@ntrg.com Ted Lemon Internet Software Consortium 950 Charter Street Redwood City, CA 94063 Phone: +1-650-779-7060 Fax: +1-650-779-7055 Email: mellon@isc.org Hall & Lemon Expires Jan 12, 2001 [Page 7] INTERNET DRAFT Multicast BOOTP/DHCPv4 Relay Agents July 2000 5. Full Copyright Statement Copyright (C) The Internet Society (2000). 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 implmentation 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. 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." Hall & Lemon Expires Jan 12, 2001 [Page 8]