Network Working Group R. Droms Request for Comments: 1531 Bucknell University Category: Standards Track October 1993 Dynamic Host Configuration Protocol Status of this memo This RFC specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior of BOOTP relay agents [7, 23], and DHCP participants can interoperate with BOOTP participants [9]. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Problem definition and issues . . . . . . . . . . . . . . . . 4 1.3 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 8 2.1 Configuration parameters repository . . . . . . . . . . . . . 10 2.2 Dynamic allocation of network addresses . . . . . . . . . . . 11 3. The Client-Server Protocol . . . . . . . . . . . . . . . . . . 11 3.1 Client-server interaction - allocating a network address. . . 12 3.2 Client-server interaction - reusing a previously allocated network address . . . . . . . . . . . . . . . . . . . . . . . 17 3.3 Interpretation and representation of time values. . . . . . . 19 3.4 Host parameters in DHCP . . . . . . . . . . . . . . . . . . . 19 3.5 Use of DHCP in clients with multiple interfaces . . . . . . . 20 3.6 When clients should use DHCP. . . . . . . . . . . . . . . . . 20 4. Specification of the DHCP client-server protocol . . . . . . . 21 4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 21 4.2 DHCP server administrative controls . . . . . . . . . . . . . 23 4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 24 Droms [Page 1] RFC 1531 Dynamic Host Configuration Protocol October 1993 4.3.1 DHCPDISCOVER message. . . . . . . . . . . . . . . . . . . . 24 4.3.2 DHCPREQUEST message . . . . . . . . . . . . . . . . . . . . 27 4.3.3 DHCPDECLINE message . . . . . . . . . . . . . . . . . . . . 29 4.3.4 DHCPRELEASE message . . . . . . . . . . . . . . . . . . . . 29 4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 29 4.4.1 Initialization and allocation of network address. . . . . . 29 4.4.2 Initialization with known network address . . . . . . . . . 33 4.4.3 Initialization with a known DHCP server address . . . . . . 34 4.4.4 Reacquisition and expiration. . . . . . . . . . . . . . . . 34 4.4.5 DHCPRELEASE . . . . . . . . . . . . . . . . . . . . . . . . 35 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 35 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 37 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 38 A. Host Configuration Parameters . . . . . . . . . . . . . . . . 39 List of Figures 1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9 2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 10 3. Timeline diagram of messages exchanged between DHCP client and servers when allocating a new network address. . . . . . . . . 15 4. Timeline diagram of messages exchanged between DHCP client and servers when reusing a previously allocated network address. . 18 5. State-transition diagram for DHCP clients. . . . . . . . . . . 31 List of Tables 1. Description of fields in a DHCP message. . . . . . . . . . . . 14 2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Fields and options used by DHCP servers. . . . . . . . . . . . 25 4. Fields and options used by DHCP clients. . . . . . . . . . . . 32 1. Introduction The Dynamic Host Configuration Protocol (DHCP) provides configuration parameters to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocation of network addresses to hosts. DHCP is built on a client-server model, where designated DHCP server hosts allocate network addresses and deliver configuration parameters to dynamically configured hosts. Throughout the remainder of this document, the term "server" refers to a host providing initialization parameters through DHCP, and the term "client" refers to a host requesting initialization parameters from a DHCP server. Droms [Page 2] RFC 1531 Dynamic Host Configuration Protocol October 1993 A host should not act as a DHCP server unless explicitly configured to do so by a system administrator. The diversity of hardware and protocol implementations in the Internet would preclude reliable operation if random hosts were allowed to respond to DHCP requests. For example, IP requires the setting of many parameters within the protocol implementation software. Because IP can be used on many dissimilar kinds of network hardware, values for those parameters cannot be guessed or assumed to have correct defaults. Also, distributed address allocation schemes depend on a polling/defense mechanism for discovery of addresses that are already in use. IP hosts may not always be able to defend their network addresses, so that such a distributed address allocation scheme cannot be guaranteed to avoid allocation of duplicate network addresses. DHCP supports three mechanisms for IP address allocation. In "automatic allocation", DHCP assigns a permanent IP address to a host. In "dynamic allocation", DHCP assigns an IP address to a host for a limited period of time (or until the host explicitly relinquishes the address). In "manual allocation", a host's IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the host. A particular network will use one or more of these mechanisms, depending on the policies of the network administrator. Dynamic allocation is the only one of the three mechanisms that allows automatic reuse of an address that is no longer needed by the host to which it was assigned. Thus, dynamic allocation is particularly useful for assigning an address to a host that will be connected to the network only temporarily or for sharing a limited pool of IP addresses among a group of hosts that do not need permanent IP addresses. Dynamic allocation may also be a good choice for assigning an IP address to a new host being permanently connected to a network where IP addresses are sufficiently scarce that it is important to reclaim them when old hosts are retired. Manual allocation allows DHCP to be used to eliminate the error-prone process of manually configuring hosts with IP addresses in environments where (for whatever reasons) it is desirable to manage IP address assignment outside of the DHCP mechanisms. The format of DHCP messages is based on the format of BOOTP messages, to capture the BOOTP relay agent behavior described as part of the BOOTP specification [7, 23] and to allow interoperability of existing BOOTP clients with DHCP servers. Using BOOTP relaying agents eliminates the necessity of having a DHCP server on each physical network segment. Droms [Page 3] RFC 1531 Dynamic Host Configuration Protocol October 1993 1.1 Related Work There are several Internet protocols and related mechanisms that address some parts of the dynamic host configuration problem. The Reverse Address Resolution Protocol (RARP) [10] (through the extensions defined in the Dynamic RARP (DRARP) [5]) explicitly addresses the problem of network address discovery, and includes an automatic IP address assignment mechanism. The Trivial File Transfer Protocol (TFTP) [20] provides for transport of a boot image from a boot server. The Internet Control Message Protocol (ICMP) [16] provides for informing hosts of additional routers via "ICMP redirect" messages. ICMP also can provide subnet mask information through the "ICMP mask request" message and other information through the (obsolete) "ICMP information request" message. Hosts can locate routers through the ICMP router discovery mechanism [8]. BOOTP is a transport mechanism for a collection of configuration information. BOOTP is also extensible, and official extensions [17] have been defined for several configuration parameters. Morgan has proposed extensions to BOOTP for dynamic IP address assignment [15]. The Network Information Protocol (NIP), used by the Athena project at MIT, is a distributed mechanism for dynamic IP address assignment [19]. The Resource Location Protocol RLP [1] provides for location of higher level services. Sun Microsystems diskless workstations use a boot procedure that employs RARP, TFTP and an RPC mechanism called "bootparams" to deliver configuration information and operating system code to diskless hosts. (Sun Microsystems, Sun Workstation and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun networks also use DRARP and an auto-installation mechanism to automate the configuration of new hosts in an existing network. In other related work, the path minimum transmission unit (MTU) discovery algorithm can determine the MTU of an arbitrary internet path [14]. Comer and Droms have proposed the use of the Address Resolution Protocol (ARP) as a transport protocol for resource location and selection [6]. Finally, the Host Requirements RFCs [3, 4] mention specific requirements for host reconfiguration and suggest a scenario for initial configuration of diskless hosts. 1.2 Problem definition and issues DHCP is designed to supply hosts with the configuration parameters defined in the Host Requirements RFCs. After obtaining parameters via DHCP, a host should be able to exchange packets with any other host in the Internet. The parameters supplied by DHCP are listed in Appendix A. Droms [Page 4] RFC 1531 Dynamic Host Configuration Protocol October 1993 Not all of these parameters are required for a newly initialized host. A client and server may negotiate for the transmission of only those parameters required by the client or specific to a particular subnet. DHCP allows but does not require the configuration of host parameters not directly related to the IP protocol. DHCP also does not address registration of newly configured hosts with the Domain Name System (DNS) [12, 13]. DHCP is not intended for use in configuring routers. 1.3 Requirements Throughout this document, 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. Droms [Page 5] RFC 1531 Dynamic Host Configuration Protocol October 1993 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.4 Terminology This document uses the following terms: 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 "BOOTP relay agent" A BOOTP relay agent is an Internet host or router that passes DHCP messages between DHCP clients and DHCP servers. DHCP is designed to use the same relay agent behavior as specified in 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 DHCP client. Bindings are managed by DHCP servers. 1.5 Design goals The following list gives general design goals for DHCP. o DHCP should be a mechanism rather than a policy. DHCP must allow local system administrators control over configuration parameters where desired; e.g., local system administrators should be able to enforce local policies concerning allocation and access to local resources where desired. Droms [Page 6] RFC 1531 Dynamic Host Configuration Protocol October 1993 o Hosts should require no manual configuration. Each host should be able to discover appropriate local configuration parameters without user intervention and incorporate those parameters into its own configuration. o Networks should require no hand configuration for individual hosts. Under normal circumstances, the network manager should not have to enter any per-host configuration parameters. o DHCP should not require a server on each subnet. To allow for scale and economy, DHCP must work across routers or through the intervention of BOOTP/DHCP relay agents. o A DHCP host must be prepared to receive multiple responses to a request for configuration parameters. Some installations may include multiple, overlapping DHCP servers to enhance reliability and increase performance. o DHCP must coexist with statically configured, non-participating hosts and with existing network protocol implementations. o DHCP must interoperate with the BOOTP relay agent behavior as described by RFC 951 and by Wimer [21]. o DHCP must provide service to existing BOOTP clients. The following list gives design goals specific to the transmission of the network layer parameters. DHCP must: o Guarantee that any specific network address will not be in use by more than one host at a time, o Retain host configuration across host reboot. A host should, whenever possible, be assigned the