Network Working Group R. Droms
`Request for Comments: 1541 Bucknell University
`Obsoletes: 1531 October 1993
`Category: Standards Track
`
` 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]. Due to some errors introduced into RFC
` 1531 in the editorial process, this memo is reissued as RFC 1541.
`
`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
`
`Droms [Page 1]
`
`1
`
`EX 1009
`IPR of Pat. No. 6,892,304
`
`

`

`
`RFC 1541 Dynamic Host Configuration Protocol October 1993
`
` 4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 21
` 4.2 DHCP server administrative controls . . . . . . . . . . . . . 23
` 4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 24
` 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
`
`Droms [Page 2]
`
`2
`
`

`

`
`RFC 1541 Dynamic Host Configuration Protocol October 1993
`
` parameters through DHCP, and the term "client" refers to a host
` requesting initialization parameters from a DHCP server.
`
` 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]
`
`3
`
`

`

`
`RFC 1541 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]
`
`4
`
`

`

`
`RFC 1541 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]
`
`5
`
`

`

`
`RFC 1541 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]
`
`6
`
`

`

`
`RFC 1541 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]
`
`7
`
`

`

`
`RFC 1541 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
` ’chaddr’ is used both as a hardware address for transmission of BOOTP
` 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]
`
`8
`
`

`

`
`RFC 1541 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]
`
`9
`
`

`

`
`RFC 1541 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 ’flags’ field.
`
`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]
`
`10
`
`

`

`
`RFC 1541 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]
`
`11
`
`

`

`
`RFC 1541 Dynamic Host Configuration Protocol October 1993
`
` is the same magic cookie as is defined in RFC 1497). The remainder
` of the ’options’ field consists a list of tagged parameters that are
` called "options". All of the "vendor extensions" listed in RFC 1497
` 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]
`
`12
`
`

`

`
`RFC 1541 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