RFCs in HTML Format


RFC 1531

                  Dynamic Host Configuration Protocol

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 same configuration parameters (e.g., network address) in response to each request, o Retain host configuration across server reboots, and, whenever possible, a host should be assigned the same configuration parameters despite restarts of the DHCP mechanism, o Allow automatic assignment of configuration parameters to new hosts to avoid hand configuration for new hosts, o Support fixed or permanent allocation of configuration parameters to specific hosts. Droms [Page 7]
RFC 1531 Dynamic Host Configuration Protocol October 1993 2. Protocol Summary From the client's point of view, DHCP is an extension of the BOOTP mechanism. This behavior allows existing BOOTP clients to interoperate with DHCP servers without requiring any change to the clients' initialization software. A separate document details the interactions between BOOTP and DHCP clients and servers [9]. There are some new, optional transactions that optimize the interaction between DHCP clients and servers that are described in sections 3 and 4 Figure 1 gives the format of a DHCP message and table 1 describes each of the fields in the DHCP message. The numbers in parentheses indicate the size of each field in octets. The names for the fields given in the figure will be used throughout this document to refer to the fields in DHCP messages. There are two primary differences between DHCP and BOOTP. First, DHCP defines mechanisms through which clients can be assigned a network address for a fixed lease, allowing for serial reassignment of network addresses to different clients. Second, DHCP provides the mechanism for a client to acquire all of the IP configuration parameters that it needs in order to operate. DHCP introduces a small change in terminology intended to clarify the meaning of one of the fields. What was the "vendor extensions" field in BOOTP has been re-named the "options" field in DHCP. Similarly, the tagged data items that were used inside the BOOTP "vendor extensions" field, which were formerly referred to as "vendor extensions," are now termed simply "options." DHCP defines a new 'client identifier' option that is used to pass an explicit client identifier to a DHCP server. This change eliminates the overloading of the 'chaddr' field in BOOTP messages, where reply messages and as a client identifier. The 'client identifier' option may contain a hardware address, identical to the contents of the 'chaddr' field, or it may contain another type of identifier, such as a DNS name. Other client identifier types may be defined as needed for use with DHCP. New client identifier types will be registered with the IANA [18] and will be included in new revisions of the Assigned Numbers document, as well as described in detail in future revisions of the DHCP Options [2]. Droms [Page 8]
RFC 1531 Dynamic Host Configuration Protocol October 1993 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op (1) | htype (1) | hlen (1) | hops (1) | +---------------+---------------+---------------+---------------+ | xid (4) | +-------------------------------+-------------------------------+ | secs (2) | flags (2) | +-------------------------------+-------------------------------+ | ciaddr (4) | +---------------------------------------------------------------+ | yiaddr (4) | +---------------------------------------------------------------+ | siaddr (4) | +---------------------------------------------------------------+ | giaddr (4) | +---------------------------------------------------------------+ | | | chaddr (16) | | | | | +---------------------------------------------------------------+ | | | sname (64) | +---------------------------------------------------------------+ | | | file (128) | +---------------------------------------------------------------+ | | | options (312) | +---------------------------------------------------------------+ Figure 1: Format of a DHCP message DHCP clarifies the interpretation of the 'siaddr' field as the address of the server to use in the next step of the client's bootstrap process. A DHCP server may return its own address in the 'siaddr' field, if the server is prepared to supply the next bootstrap service (e.g., delivery of an operating system executable image). A DHCP server always returns its own address in the 'server identifier' option. The options field is now variable length, with the minimum extended to 312 octets. This brings the minimum size of a DHCP message up to 576 octets, the minimum IP datagram size a host must be prepared to accept [3]. DHCP clients may negotiate the use of larger DHCP messages through the 'Maximum DHCP message size' option. The options field may be further extended into the 'file' and 'sname' fields. Droms [Page 9]
RFC 1531 Dynamic Host Configuration Protocol October 1993 A new option, called 'vendor specific information', has been added to allow for expansion of the number of options that can be supported [2]. Options encapsulated as 'vendor specific information' must be carefully defined and documented so as to allow for interoperability between clients and servers from diferent vendors. In particular, vendors defining 'vendor specific information' MUST document those options in the form of the DHCP Options document, MUST choose to represent those options either in data types already defined for DHCP options or in other well-defined data types, and MUST choose options that can be readily encoded in configuration files for exchange with servers provided by other vendors. Options included as 'vendor specific options' MUST be readily supportable by all servers. 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B| MBZ | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B: BROADCAST flag MBZ: MUST BE ZERO (reserved for future use) Figure 2: Format of the 'flags' field DHCP uses the 'flags' field [21]. The leftmost bit is defined as the BROADCAST (B) flag. The semantics of this flag are discussed in section 4.1 of this document. The remaining bits of the flags field are reserved for future use. They MUST be set to zero by clients and ignored by servers and relay agents. Figure 2 gives the format of the 2.1 Configuration parameters repository The first service provided by DHCP is to provide persistent storage of network parameters for network clients. The model of DHCP persistent storage is that the DHCP service stores a key-value entry for each client, where the key is some unique identifier (for example, an IP subnet number and a unique identifier within the subnet) and the value contains the configuration parameters for the client. For example, the key might be the pair (IP-subnet-number, hardware- address), allowing for serial or concurrent reuse of a hardware address on different subnets, and for hardware addresses that may not be globally unique. Alternately, the key might be the pair (IP- subnet-number, hostname), allowing the server to assign parameters intelligently to a host that has been moved to a different subnet or Droms [Page 10]
RFC 1531 Dynamic Host Configuration Protocol October 1993 has changed hardware addresses (perhaps because the network interface failed and was replaced). A client can query the DHCP service to retrieve its configuration parameters. The client interface to the configuration parameters repository consists of protocol messages to request configuration parameters and responses from the server carrying the configuration parameters. 2.2 Dynamic allocation of network addresses The second service provided by DHCP is the allocation of temporary or permanent network (IP) addresses to hosts. The basic mechanism for the dynamic allocation of network addresses is simple: a client requests the use of an address for some period of time. The allocation mechanism (the collection of DHCP servers) guarantees not to reallocate that address within the requested time and attempts to return the same network address each time the client requests an address. In this document, the period over which a network address is allocated to a client is referred to as a "lease" [11]. The client may extend its lease with subsequent requests. The client may issue a message to release the address back to the server when the client no longer needs the address. The client may ask for a permanent assignment by asking for an infinite lease. Even when assigning "permanent" addresses, a server may choose to give out lengthy but non-infinite leases to allow detection of the fact that the host has been retired. In some environments it will be necessary to reassign network addresses due to exhaustion of available addresses. In such environments, the allocation mechanism will reuse addresses whose lease has expired. The server should use whatever information is available in the configuration information repository to choose an address to reuse. For example, the server may choose the least recently assigned address. As a consistency check, the allocation mechanism may probe the reused address, e.g., with an ICMP echo request, before allocating the address, and the client will probe the newly received address, e.g., with ARP. 3. The Client-Server Protocol DHCP uses the BOOTP message format defined in RFC 951 and given in table 1 and figure 1. The 'op' field of each DHCP message sent from a client to a server contains BOOTREQUEST. BOOTREPLY is used in the 'op' field of each DHCP message sent from a server to a client. The first four octets of the 'options' field of the DHCP message contain the (decimal) values 99, 130, 83 and 99, respectively (this Droms [Page 11]
RFC 1531 Dynamic Host Configuration Protocol October 1993 is the same magic cookie as is defined in RFC 1395). The remainder of the 'options' field consists a list of tagged parameters that are called "options". All of the "vendor extensions" listed in RFC 1395 are also DHCP options. A separate document gives the complete set of options defined for use with DHCP [2]. Several options have been defined so far. One particular option - the "DHCP message type" option - must be included in every DHCP message. This option defines the "type" of the DHCP message. Additional options may be allowed, required, or not allowed, depending on the DHCP message type. Throughout this document, DHCP messages that include a 'DHCP message type' option will be referred to by the type of the message; e.g., a DHCP message with 'DHCP message type' option type 1 will be referred to as a "DHCPDISCOVER" message. 3.1 Client-server interaction - allocating a network address The following summary of the protocol exchanges between clients and servers refers to the DHCP messages described in table 2. The timeline diagram in figure 3 shows the timing relationships in a typical client-server interaction. If the client already knows its address, some steps may be omitted; this abbreviated interaction is described in section 3.2. 1. The client broadcasts a DHCPDISCOVER message on its local physical subnet. The DHCPDISCOVER message may include options that suggest values for the network address and lease duration. BOOTP relay agents may pass the message on to DHCP servers not on the same physical subnet. 2. Each server may respond with a DHCPOFFER message that includes an available network address in the 'yiaddr' field (and other configuration parameters in DHCP options). Servers need not reserve the offered network address, although the protocol will work more efficiently if the server avoids allocating the offered network address to another client. The server unicasts the DHCPOFFER message to the client (using the DHCP/BOOTP relay agent if necessary) if possible, or may broadcast the message to a broadcast address (preferably 255.255.255.255) on the client's subnet. 3. The client receives one or more DHCPOFFER messages from one or more servers. The client may choose to wait for multiple responses. The client chooses one server from which to request configuration parameters, based on the configuration parameters offered in the DHCPOFFER messages. The client broadcasts a Droms [Page 12]
RFC 1531 Dynamic Host Configuration Protocol October 1993 DHCPREQUEST message that MUST include the 'server identifier' option to indicate which server it has selected, and may include other options specifying desired configuration values. This DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP relay agents. To help ensure that any DHCP/BOOTP relay agents forward the DHCPREQUEST message to the same set of DHCP servers that received the original DHCPDISCOVER message, the DHCPREQUEST message must use the same value in the DHCP message header's 'secs' field and be sent to the same IP broadcast address as the original DHCPDISCOVER message. The client times out and retransmits the DHCPDISCOVER message if the client receives no DHCPOFFER messages. 4. The servers receive the DHCPREQUEST broadcast from the client. Those servers not selected by the DHCPREQUEST message use the message as notification that the client has declined that server's offer. The server selected in the DHCPREQUEST message commits the binding for the client to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting client. The combination of 'chaddr' and assigned network address constitute an unique identifier for the client's lease and are used by both the client and server to identify a lease referred to in any DHCP messages. The 'yiaddr' field in the DHCPACK messages is filled in with the selected network address. If the selected server is unable to satisfy the DHCPREQUEST message (e.g., the requested network address has been allocated), the server SHOULD respond with a DHCPNAK message. A server may choose to mark addresses offered to clients in DHCPOFFER messages as unavailable. The server should mark an address offered to a client in a DHCPOFFER message as available if the server receives no DHCPREQUEST message from that client. Droms [Page 13]
RFC 1531 Dynamic Host Configuration Protocol October 1993 FIELD OCTETS DESCRIPTION ----- ------ ----------- op 1 Message op code / message type. 1 = BOOTREQUEST, 2 = BOOTREPLY htype 1 Hardware address type, see ARP section in "Assigned Numbers" RFC; e.g., '1' = 10mb ethernet. hlen 1 Hardware address length (e.g. '6' for 10mb ethernet). hops 1 Client sets to zero, optionally used by relay-agents when booting via a relay-agent. xid 4 Transaction ID, a random number chosen by the client, used by the client and server to associate messages and responses between a client and a server. secs 2 Filled in by client, seconds elapsed since client started trying to boot. flags 2 Flags (see figure 2). ciaddr 4 Client IP address; filled in by client in DHCPREQUEST if verifying previously allocated configuration parameters. yiaddr 4 'your' (client) IP address. siaddr 4 IP address of next server to use in bootstrap; returned in DHCPOFFER, DHCPACK and DHCPNAK by server. giaddr 4 Relay agent IP address, used in booting via a relay-agent. chaddr 16 Client hardware address. sname 64 Optional server host name, null terminated string. file 128 Boot file name, null terminated string; "generic" name or null in DHCPDISCOVER, fully qualified directory-path name in DHCPOFFER. options 312 Optional parameters field. See the options documents for a list of defined options. Table 1: Description of fields in a DHCP message Droms [Page 14]
RFC 1531 Dynamic Host Configuration Protocol October 1993 Server Client Server (not selected) (selected) v v v | | | | Begins initialization | | | | | _____________/|\_____________ | |/ DHCPDISCOVER | DHCPDISCOVER \| | | | Determines | Determines configuration | configuration | | | |\ | ____________/| | \_________ | /DHCPOFFER | | DHCPOFFER\ |/ | | \ | | | Collects replies | | \| | | Selects configuration | | | | | _____________/|\_____________ | |/ DHCPREQUEST | DHCPREQUEST \| | | | | | Commits configuration | | | | | _____________/| | |/ DHCPACK | | | | | Initialization complete | | | | . . . . . . | | | | Graceful shutdown | | | | | |\_____________ | | | DHCPRELEASE \| | | | | | Discards lease | | | v v v Figure 3: Timeline diagram of messages exchanged between DHCP client and servers when allocating a new network address Droms [Page 15]
RFC 1531 Dynamic Host Configuration Protocol October 1993 Message Use ------- --- DHCPDISCOVER - Client broadcast to locate available servers. DHCPOFFER - Server to client in response to DHCPDISCOVER with offer of configuration parameters. DHCPREQUEST - Client broadcast to servers requesting offered parameters from one server and implicitly declining offers from all others. DHCPACK - Server to client with configuration parameters, including committed network address. DHCPNAK - Server to client refusing request for configuration parameters (e.g., requested network address already allocated). DHCPDECLINE - Client to server indicating configuration parameters (e.g., network address) invalid. DHCPRELEASE - Client to server relinquishing network address and cancelling remaining lease. Table 2: DHCP messages 5. The client receives the DHCPACK message with configuration parameters. The client performs a final check on the parameters (e.g., ARP for allocated network address), and notes the duration of the lease and the lease identification cookie specified in the DHCPACK message. At this point, the client is configured. If the client detects a problem with the parameters in the DHCPACK message, the client sends a DHCPDECLINE message to the server and restarts the configuration process. The client should wait a minimum of ten seconds before restarting the configuration process to avoid excessive network traffic in case of looping. If the client receives a DHCPNAK message, the client restarts the configuration process. The client times out and retransmits the DHCPREQUEST message if the client receives neither a DHCPACK or a DHCPNAK message. The client retransmits the DHCPREQUEST according to the retransmission algorithm in section 4.1. If the client receives neither a DHCPACK or a DHCPNAK message after ten retransmissions of the DHCPREQUEST message, the client reverts to INIT state and restarts the initialization process. The client SHOULD notify the user that the Droms [Page 16]
RFC 1531 Dynamic Host Configuration Protocol October 1993 initialization process has failed and is restarting. 6. The client may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to the server. The client identifies the lease to be released by including its network address in the 'ciaddr' field and its hardware address in the 'chaddr' field. 3.2 Client-server interaction - reusing a previously allocated network address If a client remembers and wishes to reuse a previously allocated network address (allocated either by DHCP or some means outside the protocol), a client may choose to omit some of the steps described in the previous section. The timeline diagram in figure 4 shows the timing relationships in a typical client-server interaction for a client reusing a previously allocated network address. 1. The client broadcasts a DHCPREQUEST message on its local subnet. The DHCPREQUEST message includes the client's network address in the 'ciaddr' field. DHCP/BOOTP relay agents pass the message on to DHCP servers not on the same subnet. 2. Servers with knowledge of the client's configuration parameters respond with a DHCPACK message to the client. If the client's request is invalid (e.g., the client has moved to a new subnet), servers may respond with a DHCPNAK message to the client. 3. The client receives the DHCPACK message with configuration prameters. The client performs a final check on the parameters (as in section 3.1), and notes the duration of the lease and the lease identification cookie specified in the DHCPACK message. At this point, the client is configured. If the client detects a problem with the parameters in the DHCPACK message, the client sends a DHCPDECLINE message to the server and restarts the configuration process by requesting a new network address. This action corresponds to the client moving to the INIT state in the DHCP state diagram, which is described in section 4.4. Droms [Page 17]
RFC 1531 Dynamic Host Configuration Protocol October 1993
RFC 1531 Dynamic Host Configuration Protocol October 1993 defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * duration_of_lease). Times T1 and T2 should be chosen with some random "fuzz" around a fixed value, to avoid synchronization of client reacquisition. In both RENEWING and REBINDING state, if the client receives no response to its DHCPREQUEST message, the client should wait one-half the remaining time until the expiration of T1 (in RENEWING state) and T2 (in REBINDING state) down to a minimum of 60 seconds, before retransmitting the DHCPREQUEST message. If the lease expires before the client receives a DHCPACK, the client moves to INIT state, MUST immediately stop any other network processing and requests network initialization parameters as if the client were uninitialized. If the client then receives a DHCPACK allocating that client its previous network address, the client SHOULD continue network processing. If the client is given a new network address, it MUST NOT continue using the previous network address and SHOULD notify the local users of the problem. 4.4.5 DHCPRELEASE If the client no longer requires use of its assigned network address (e.g., the client is gracefully shut down), the client sends a DHCPRELEASE message to the server. Note that the correct operation of DHCP does not depend on the transmission of DHCPRELEASE messages. 5. Acknowledgments Greg Minshall, Leo McLaughlin and John Veizades have patiently contributed to the the design of DHCP through innumerable discussions, meetings and mail conversations. Jeff Mogul first proposed the client-server based model for DHCP. Steve Deering searched the various IP RFCs to put together the list of network parameters supplied by DHCP. Walt Wimer contributed a wealth of practical experience with BOOTP and wrote a document clarifying the behavior of BOOTP/DHCP relay agents. Jesse Walker analyzed DHCP in detail, pointing out several inconsistencies in earlier specifications of the protocol. Steve Alexander reviewed Walker's analysis and the fixes to the protocol based on Walker's work. And, of course, all the members of the Dynamic Host Configuration Working Group of the IETF have contributed to the design of the protocol through discussion and review of the protocol design. Droms [Page 35]
RFC 1531 Dynamic Host Configuration Protocol October 1993 6. References [1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December 1983 [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 1533, Lachman Technology, Inc., Bucknell University, October 1993. [3] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989. [4] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support, STD 3, RFC 1123, USC/Information Sciences Institute, October 1989. [5] Brownell, D, "Dynamic Reverse Address Resolution Protocol (DRARP)", Work in Progress. [6] Comer, D., and R. Droms, "Uniform Access to Internet Directory Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer Communications Review), 20(4):50--59, 1990. [7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, Stanford and SUN Microsystems, September 1985. [8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991. [9] Droms, D., "Interoperation between DHCP an BOOTP" RFC 1534, Bucknell University, October 1993. [10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", RFC 903, Stanford, June 1984. [11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency", In Proc. of the Twelfth ACM Symposium on Operating Systems Design, 1989. [12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987. [13] Mockapetris, P., "Domain Names -- Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987. Droms [Page 36]
RFC 1531 Dynamic Host Configuration Protocol October 1993 [14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached Hosts", Work in Progress. [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, USC/Information Sciences Institute, September 1981. [17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, USC/Information Sciences Institute, August 1993. [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. [19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic Assignment of IP Addresses for use on an Ethernet. (Available from the Athena Project, MIT), 1989. [20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC, June 1981. [21] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1532, Carnegie Mellon University, October 1993. 7. Security Considerations DHCP is built directly on UDP and IP which are as yet inherently insecure. Furthermore, DHCP is generally intended to make maintenance of remote and/or diskless hosts easier. While perhaps not impossible, configuring such hosts with passwords or keys may be difficult and inconvenient. Therefore, DHCP in its current form is quite insecure. Unauthorized DHCP servers may be easily set up. Such servers can then send false and potentially disruptive information to clients such as incorrect or duplicate IP addresses, incorrect routing information (including spoof routers, etc.), incorrect domain nameserver addresses (such as spoof nameservers), and so on. Clearly, once this seed information is in place, an attacker can further compromise affected systems. Malicious DHCP clients could masquerade as legitimate clients and retrieve information intended for those legitimate clients. Where dynamic allocation of resources is used, a malicious client could claim all resources for itself, thereby denying resources to legitimate clients. Droms [Page 37]
RFC 1531 Dynamic Host Configuration Protocol October 1993 8. Author's Address Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837 Phone: (717) 524-1145 EMail: droms@bucknell.edu Droms [Page 38]
RFC 1531 Dynamic Host Configuration Protocol October 1993 A. Host Configuration Parameters IP-layer_parameters,_per_host:_ Be a router on/off HRC 3.1 Non-local source routing on/off HRC 3.3.5 Policy filters for non-local source routing (list) HRC 3.3.5 Maximum reassembly size integer HRC 3.3.2 Default TTL integer HRC 3.2.1.7 PMTU aging timeout integer MTU 6.6 MTU plateau table (list) MTU 7 IP-layer_parameters,_per_interface:_ IP address (address) HRC 3.3.1.6 Subnet mask (address mask) HRC 3.3.1.6 MTU integer HRC 3.3.3 All-subnets-MTU on/off HRC 3.3.3 Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6 Perform mask discovery on/off HRC 3.2.2.9 Be a mask supplier on/off HRC 3.2.2.9 Perform router discovery on/off RD 5.1 Router solicitation address (address) RD 5.1 Default routers, list of: router address (address) HRC 3.3.1.6 preference level integer HRC 3.3.1.6 Static routes, list of: destination (host/subnet/net) HRC 3.3.1.2 destination mask (address mask) HRC 3.3.1.2 type-of-service integer HRC 3.3.1.2 first-hop router (address) HRC 3.3.1.2 ignore redirects on/off HRC 3.3.1.2 PMTU integer MTU 6.6 perform PMTU discovery on/off MTU 6.6 Link-layer_parameters,_per_interface:_ Trailers on/off HRC 2.3.1 ARP cache timeout integer HRC 2.3.2.1 Ethernet encapsulation (RFC 894/RFC 1042) HRC 2.3.3



Back to RFC index

 

Associates:

 



Sponsered-Sites:

Register domain name and transfer | Cheap webhosting service | Domain name registration

 

 

""