summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1531.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1531.txt')
-rw-r--r--doc/rfc/rfc1531.txt2187
1 files changed, 2187 insertions, 0 deletions
diff --git a/doc/rfc/rfc1531.txt b/doc/rfc/rfc1531.txt
new file mode 100644
index 0000000..b342021
--- /dev/null
+++ b/doc/rfc/rfc1531.txt
@@ -0,0 +1,2187 @@
+
+
+
+
+
+
+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 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
+
+
+ Server Client Server
+
+ v v v
+ | | |
+ | Begins |
+ | initialization |
+ | | |
+ | /|\ |
+ | ___________/ | \___________ |
+ | /DHCPREQUEST | DHCPREQUEST\ |
+ |/ | \|
+ | | |
+ Locates | Locates
+ configuration | configuration
+ | | |
+ |\ | /|
+ | \ | ___________/ |
+ | \ | / DHCPACK |
+ | \_______ |/ |
+ | DHCPACK\ | |
+ | Initialization |
+ | complete |
+ | \| |
+ | | |
+ | (Subsequent |
+ | DHCPACKS |
+ | ignored) |
+ | | |
+ | | |
+ v v v
+
+ Figure 4: Timeline diagram of messages exchanged between DHCP
+ client and servers when reusing a previously allocated
+ network address
+
+ If the client receives a DHCPNAK message, it cannot reuse its
+ remembered network address. It must instead request a new
+ address by restarting the configuration process, this time
+ using the (non-abbreviated) procedure described in section
+ 3.1. This action also corresponds to the client moving to
+ the INIT state in the DHCP state diagram.
+
+ The client times out and retransmits the DHCPREQUEST message if
+ the client receives neither a DHCPACK nor a DHCPNAK message.
+ The time between retransmission MUST be chosen according to
+ the algorithm given in section 4.1. If the client receives no
+ answer after transmitting 4 DHCPREQUEST messages, the client
+ MAY choose to use the previously allocated network address and
+
+
+
+Droms [Page 18]
+
+RFC 1531 Dynamic Host Configuration Protocol October 1993
+
+
+ configuration parameters for the remainder of the unexpired
+ lease. This corresponds to moving to BOUND state in the client
+ state transition diagram shown in figure 5.
+
+ 4. 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 with the lease
+ identification cookie.
+
+ Note that in this case, where the client retains its network
+ address locally, the client will not normally relinquish its
+ lease during a graceful shutdown. Only in the case where the
+ client explicitly needs to relinquish its lease, e.g., the client
+ is about to be moved to a different subnet, will the client send
+ a DHCPRELEASE message.
+
+3.3 Interpretation and representation of time values
+
+ A client acquires a lease for a network address for a fixed period of
+ time (which may be infinite). Throughout the protocol, times are to
+ be represented in units of seconds. The time value of 0xffffffff is
+ reserved to represent "infinity". The minimum lease duration is one
+ hour.
+
+ As clients and servers may not have synchronized clocks, times are
+ represented in DHCP messages as relative times, to be interpreted
+ with respect to the client's local clock. Representing relative
+ times in units of seconds in an unsigned 32 bit word gives a range of
+ relative times from 0 to approximately 100 years, which is sufficient
+ for the relative times to be measured using DHCP.
+
+ The algorithm for lease duration interpretation given in the previous
+ paragraph assumes that client and server clocks are stable relative
+ to each other. If there is drift between the two clocks, the server
+ may consider the lease expired before the client does. To
+ compensate, the server may return a shorter lease duration to the
+ client than the server commits to its local database of client
+ information.
+
+3.4 Host parameters in DHCP
+
+ Not all clients require initialization of all parameters listed in
+ Appendix A. Two techniques are used to reduce the number of
+ parameters transmitted from the server to the client. First, most of
+ the parameters have defaults defined in the Host Requirements RFCs;
+ if the client receives no parameters from the server that override
+ the defaults, a client uses those default values. Second, in its
+ initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the
+
+
+
+Droms [Page 19]
+
+RFC 1531 Dynamic Host Configuration Protocol October 1993
+
+
+ server with a list of specific parameters the client is interested
+ in.
+
+ The client SHOULD include the 'maximum DHCP message size' option to
+ let the server know how large the server may make its DHCP messages.
+ The parameters returned to a client may still exceed the space
+ allocated to options in a DHCP message. In this case, two additional
+ options flags (which must appear in the 'options' field of the
+ message) indicate that the 'file' and 'sname' fields are to be used
+ for options.
+
+ The client can inform the server which configuration parameters the
+ client is interested in by including the 'parameter request list'
+ option. The data portion of this option explicitly lists the options
+ requested by tag number.
+
+ In addition, the client may suggest values for the network address
+ and lease time in the DHCPDISCOVER message. The client may include
+ the be assigned, and may include the 'IP address lease time' option
+ to suggest the lease time it would like. No other options
+ representing "hints" at configuration parameters are allowed in a
+ DHCPDISCOVER or DHCPREQUEST message. The 'ciaddr' field is to be
+ filled in only in a DHCPREQUEST message when the client is requesting
+ use of a previously allocated IP address.
+
+ If a server receives a DHCPREQUEST message with an invalid 'ciaddr',
+ the server SHOULD respond to the client with a DHCPNAK message and
+ may choose to report the problem to the system administrator. The
+ server may include an error message in the 'message' option.
+
+3.5 Use of DHCP in clients with multiple interfaces
+
+ A host with multiple network interfaces must use DHCP through each
+ interface independently to obtain configuration information
+ parameters for those separate interfaces.
+
+3.6 When clients should use DHCP
+
+ A host should use DHCP to reacquire or verify its IP address and
+ network parameters whenever the local network parameters may have
+ changed; e.g., at system boot time or after a disconnection from the
+ local network, as the local network configuration may change without
+ the host's or user's knowledge.
+
+ If a host has knowledge of a previous network address and is unable
+ to contact a local DHCP server, the host may continue to use the
+ previous network address until the lease for that address expires.
+ If the lease expires before the host can contact a DHCP server, the
+
+
+
+Droms [Page 20]
+
+RFC 1531 Dynamic Host Configuration Protocol October 1993
+
+
+ host must immediately discontinue use of the previous network address
+ and may inform local users of the problem.
+
+4. Specification of the DHCP client-server protocol
+
+ In this section, we assume that a DHCP server has a block of network
+ addresses from which it can satisfy requests for new addresses. Each
+ server also maintains a database of allocated addresses and leases in
+ local permanent storage.
+
+4.1 Constructing and sending DHCP messages
+
+ DHCP clients and servers both construct DHCP messages by filling in
+ fields in the fixed format section of the message and appending
+ tagged data items in the variable length option area. The options
+ area includes first a four-octet 'magic cookie' (which was described
+ in section 3), followed by the options. The last option must always
+ be the 'end' option.
+
+ DHCP uses UDP as its transport protocol. DHCP messages from a client
+ to a server are sent to the 'DHCP server' port (67), and DHCP
+ messages from a server to a client are sent to the 'DHCP client' port
+ (68).
+
+ DHCP messages broadcast by a client prior to that client obtaining
+ its IP address must have the source address field in the IP header
+ set to 0.
+
+ If the 'giaddr' field in a DHCP message from a client is non-zero,
+ the server sends any return messages to the 'DHCP server' port on the
+ DHCP relaying agent whose address appears in 'giaddr'. If the
+ 'giaddr' field is zero, the client is on the same subnet, and the
+ server sends any return messages to either the client's network
+ address, if that address was supplied in the 'ciaddr' field, or to
+ the client's hardware address or to the local subnet broadcast
+ address.
+
+ If the options in a DHCP message extend into the 'sname' and 'file'
+ fields, the 'option overload' option MUST appear in the 'options'
+ field, with value 1, 2 or 3, as specified in the DHCP options
+ document [2]. If the 'option overload' option is present in the
+ 'options' field, the options in the 'options' field MUST be
+ terminated by an options field. The options in the 'sname' and
+ 'file' fields (if in use as indicated by the 'options overload'
+ option) MUST begin with the first octet of the field, MUST be
+ terminated by an 'end' option, and MUST be followed by 'pad' options
+ to fill the remainder of the field. Any individual option in the
+ 'options', 'sname' and 'file' fields MUST be entirely contained in
+
+
+
+Droms [Page 21]
+
+RFC 1531 Dynamic Host Configuration Protocol October 1993
+
+
+ that field. The options in the 'options' field MUST be interpreted
+ first, so that any 'option overload' options may be interpreted. The
+ 'file' field MUST be interpreted next (if the options), followed by
+ the 'sname' field.
+
+ DHCP clients are responsible for all message retransmission. The
+ client MUST adopt a retransmission strategy that incorporates a
+ randomized exponential backoff algorithm to determine the delay
+ between retransmissions. The delay before the first retransmission
+ MUST be 4 seconds randomized by the value of a uniform random number
+ chosen from the range -1 to +1. Clients with clocks that provide
+ resolution granularity of less than one second may choose a non-
+ integer randomization value. The delay before the next
+ retransmission MUST be 8 seconds randomized by the value of a uniform
+ number chosen from the range -1 to +1. The retransmission delay MUST
+ be doubled with subsequent retransmissions up to a maximum of 64
+ seconds. The client MAY provide an indication of retransmission
+ attempts to the user as an indication of the progress of the
+ configuration process. The protocol specification in the remainder
+ of this section will describe, for each DHCP message, when it is
+ appropriate for the client to retransmit that message forever, and
+ when it is appropriate for a client to abandon that message and
+ attempt to use a different DHCP message.
+
+ Normally, DHCP servers and BOOTP relay agents attempt to deliver
+ DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
+ unicast delivery. The IP destination address (in the IP header) is
+ set to the DHCP 'yiaddr' address and the link-layer destination
+ address is set to the DHCP 'chaddr' address. Unfortunately, some
+ client implementations are unable to receive such unicast IP
+ datagrams until the implementation has been configured with a valid
+ IP address (leading to a deadlock in which the client's IP address
+ cannot be delivered until the client has been configured with an IP
+ address).
+
+ A client that cannot receive unicast IP datagrams until its protocol
+ software has been configured with an IP address SHOULD set the
+ BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
+ DHCPREQUEST messages that client sends. The BROADCAST bit will
+ provide a hint to the DHCP server and BOOTP relay agent to broadcast
+ any messages to the client on the client's subnet. A client that can
+ receive unicast IP datagrams before its protocol software has been
+ configured SHOULD clear the BROADCAST bit to 0. The BOOTP
+ clarifications document discusses the ramifications of the use of the
+ BROADCAST bit [21].
+
+ A server or relay agent sending or relaying a DHCP message directly
+ to a DHCP client (i.e., not to a relay agent specified in the
+
+
+
+Droms [Page 22]
+
+RFC 1531 Dynamic Host Configuration Protocol October 1993
+
+
+ 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
+ field. If this bit is set to 1, the DHCP message SHOULD be sent as
+ an IP broadcast using an IP broadcast address (preferably
+ 255.255.255.255) as the IP destination address and the link-layer
+ broadcast address as the link-layer destination address. If the
+ BROADCAST bit is cleared to 0, the message SHOULD be sent as an IP
+ unicast to the IP address specified in the 'yiaddr' field and the
+ link-layer address specified in the 'chaddr' field. If unicasting is
+ not possible, the message MAY be sent as an IP broadcast using an IP
+ broadcast address (preferably 255.255.255.255) as the IP destination
+ address and the link-layer broadcast address as the link-layer
+ destination address.
+
+4.2 DHCP server administrative controls
+
+ DHCP servers are not required to respond to every DHCPDISCOVER and
+ DHCPREQUEST message they receive. For example, a network
+ administrator, to retain stringent control over the hosts attached to
+ the network, may choose to configure DHCP servers to respond only to
+ hosts that have been previously registered through some external
+ mechanism. The DHCP specification describes only the interactions
+ between clients and servers when the clients and servers choose to
+ interact; it is beyond the scope of the DHCP specification to
+ describe all of the administrative controls that system
+ administrators might want to use. Specific DHCP server
+ implementations may incorporate any controls or policies desired by a
+ network administrator.
+
+ In some environments, a DHCP server will have to consider the values
+ of the 'chaddr' field and/or the 'class-identifier' option included
+ in the DHCPDISCOVER or DHCPREQUEST messages when determining the
+ correct parameters for a particular client. For example, an
+ organization might have a separate bootstrap server for each type of
+ client it uses, requiring the DHCP server to examine the 'class-
+ identifier' to determine which bootstrap server address to return in
+ the 'siaddr' field of a DHCPOFFER or DHCPACK message.
+
+ A DHCP server must use some unique identifier to associate a client
+ with its lease. The client may choose to explicitly provide the
+ identifier through the 'client identifier' option. If the client
+ does not provide a 'client identifier' option, the server MSUT use
+ the contents of the 'chaddr' field to identify the client.
+
+ DHCP clients are free to use any strategy in selecting a DHCP server
+ among those from which the client receives a DHCPOFFER message. The
+ client implementation of DHCP should provide a mechanism for the user
+ to select directly the 'class-identifier' value.
+
+
+
+
+Droms [Page 23]
+
+RFC 1531 Dynamic Host Configuration Protocol October 1993
+
+
+4.3 DHCP server behavior
+
+ A DHCP server processes incoming DHCP messages from a client based on
+ the current state of the binding for that client. A DHCP server can
+ receive the following messages from a client:
+
+ o DHCPDISCOVER
+
+ o DHCPREQUEST
+
+ o DHCPDECLINE
+
+ o DHCPRELEASE
+
+ Table 3 gives the use of the fields and options in a DHCP message by
+ a server. The remainder of this section describes the action of the
+ DHCP server for each possible incoming message.
+
+4.3.1 DHCPDISCOVER message
+
+ When a server receives a DHCPDISCOVER message from a client, the
+ server chooses a network address for the requesting client. If no
+ address is available, the server may choose to report the problem to
+ the system administrator and may choose to reply to the client with a
+ DHCPNAK message. If the server chooses to respond to the client, it
+ may include an error message in the 'message' option. If an address
+ is available, the new address should be chosen as follows:
+
+ o The client's previous address as recorded in the client's binding,
+ if that address is in the server's pool of available addresses and
+ not already allocated, else
+
+ o The address requested in the 'Requested IP Address' option, if that
+ address is valid and not already allocated, else
+
+ o A new address allocated from the server's pool of available
+ addresses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms [Page 24]
+
+RFC 1531 Dynamic Host Configuration Protocol October 1993
+
+
+ Field DHCPOFFER DHCPACK DHCPNAK
+ ----- --------- ------- -------
+
+ 'op' BOOTREPLY BOOTREPLY BOOTREPLY
+ 'htype' (From "Assigned Numbers" RFC)
+ 'hlen' (Hardware address length in octets)
+ 'hops' 0 0 0
+ 'xid' 'xid' from client 'xid' from client 'xid' from client
+ DHCPDISCOVER DHCPREQUEST DHCPREQUEST
+ message message message
+ 'secs' 0 0 0
+ 'ciaddr' 0 'ciaddr' from 'ciaddr' from
+ DHCPREQUEST or 0 DHCPREQUEST or 0
+ 'yiaddr' IP address offered IP address 0
+ to client assigned to client
+ 'siaddr' IP address of next IP address of next 0
+ bootstrap server bootstrap server
+ 'flags' if 'giaddr' is not 0 then 'flags' from client message else 0
+ 'giaddr' 0 0 0
+ 'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
+ client client DHCPREQUEST client DHCPREQUEST
+ DHCPDISCOVER message message
+ message
+ 'sname' Server host name Server host name (unused)
+ or options or options
+ 'file' Client boot file Client boot file (unused)
+ name or options name or options
+ 'options' options options
+
+ Option DHCPOFFER DHCPACK DHCPNAK
+ ------ --------- ------- -------
+
+ Requested IP address MUST NOT MUST NOT MUST NOT
+ IP address lease time MUST MUST MUST NOT
+ Use 'file'/'sname' MAY MAY MUST NOT
+ fields
+ DHCP message type DHCPOFFER DHCPACK DHCPNAK
+ Parameter request list MUST NOT MUST NOT MUST NOT
+ Message SHOULD SHOULD SHOULD
+ Client identifier MUST NOT MUST NOT MUST NOT
+ Class identifier MUST NOT MUST NOT MUST NOT
+ Server identifier MUST MAY MAY
+ Maximum message size MUST NOT MUST NOT MUST NOT
+ All others MAY MAY MUST NOT
+
+ Table 3: Fields and options used by DHCP servers
+
+
+
+
+
+Droms [Page 25]
+
+RFC 1531 Dynamic Host Configuration Protocol October 1993
+
+
+ As described in section 4.2, a server MAY, for administrative
+ reasons, assign an address other than the one requested, or may
+ refuse to allocate an address to a particular client even though free
+ addresses are available.
+
+ While not required for correct operation of DHCP, the server should
+ not reuse the selected network address before the client responds to
+ the server's DHCPOFFER message. The server may choose to record the
+ address as offered to the client.
+
+ The server must also choose an expiration time for the lease, as
+ follows:
+
+ o IF the client has not requested a specific lease in the
+ DHCPDISCOVER message and the client already has an assigned network
+ address, the server returns the lease expiration time previously
+ assigned to that address (note that the client must explicitly
+ request a specific lease to extend the expiration time on a
+ previously assigned address), ELSE
+
+ o IF the client has not requested a specific lease in the
+ DHCPDISCOVER message and the client does not have an assigned
+ network address, the server assigns a locally configured default
+ lease time, ELSE
+
+ o IF the client has requested a specific lease in the DHCPDISCOVER
+ message (regardless of whether the client has an assigned network
+ address), the server may choose either to return the requested
+ lease (if the lease is acceptable to local policy) or select
+ another lease.
+
+ Once the network address and lease have been determined, the server
+ constructs a DHCPOFFER message with the offered configuration
+ parameters. It is important for all DHCP servers to return the same
+ parameters (with the possible exception of a newly allocated network
+ address) to ensure predictable host behavior regardless of the which
+ server the client selects. The configuration parameters MUST be
+ selected by applying the following rules in the order given below.
+ The network administrator is responsible for configuring multiple
+ DHCP servers to ensure uniform responses from those servers. The
+ server MUST return to the client:
+
+
+
+
+
+
+
+
+
+
+Droms [Page 26]
+
+RFC 1531 Dynamic Host Configuration Protocol October 1993
+
+
+ o The client's network address, as determined by the rules given
+ earlier in this section, and the subnet mask for the network to
+ which the client is connected,
+
+ o The expiration time for the client's lease, as determined by the
+ rules given earlier in this section,
+
+ o Parameters requested by the client, according to the following
+ rules:
+
+ -- IF the server has been explicitly configured with a default
+ value for the parameter, the server MUST include that value
+ in an appropriate option in the 'option' field, ELSE
+
+ -- IF the server recognizes the parameter as a parameter
+ defined in the Host Requirements Document, the server MUST
+ include the default value for that parameter as given in the
+ Host Requirements Document in an appropriate option in the
+ 'option' field, ELSE
+
+ -- The server MUST NOT return a value for that parameter,
+
+ o Any parameters from the existing binding that differ from the Host
+ Requirements documents defaults,
+
+ o Any parameters specific to this client (as identified by
+ the contents of 'chaddr' in the DHCPDISCOVER or DHCPREQUEST
+ message), e.g., as configured by the network administrator,
+
+ o Any parameters specific to this client's class (as identified
+ by the contents of the 'class identifier' option in the
+ DHCPDISCOVER or DHCPREQUEST message), e.g., as configured by
+ the network administrator; the parameters MUST be identified
+ by an exact match between the client's 'client class' and the
+ client class identified in the server,
+
+ o Parameters with non-default values on the client's subnet.
+
+ The server inserts the 'xid' field from the DHCPDISCOVER message into
+ the 'xid' field of the DHCPOFFER message and sends the DHCPOFFER
+ message to the requesting client.
+
+4.3.2 DHCPREQUEST message
+
+ A DHCPREQUEST message may come from a client responding to a
+ DHCPOFFER message from a server, or from a client verifying a
+ previously allocated IP address. If the DHCPREQUEST message contains
+ a 'server identifier' option, the message is in response to a
+
+
+
+Droms [Page 27]
+
+RFC 1531 Dynamic Host Configuration Protocol October 1993
+
+
+ DHCPOFFER message. Otherwise, the message is a request to renew or
+ extend an existing lease.
+
+ Consider first the case of a DHCPREQUEST message in response to a
+ DHCPOFFER message. If the server is identified in the 'server
+ identifier' option in the DHCPREQUEST message, the server checks to
+ confirm that the requested parameters are acceptable. Usually, the
+ requested parameters will match those returned to the client in the
+ DHCPOFFER message; however, the client may choose to request a
+ different lease duration. Also, there is no requirement that the
+ server cache the parameters from the DHCPOFFER message. The server
+ must simply check that the parameters requested in the DHCPREQUEST
+ are acceptable. If the parameters are acceptable, the server records
+ the new client binding and returns a DHCPACK message to the client.
+
+ If the requested parameters are unacceptable, e.g., the requested
+ lease time is unacceptable to local policy, the server sends a
+ DHCPNAK message to the client. The server may choose to return an
+ error message in the 'message' option.
+
+ If a different server is identified in the 'server identifier' field,
+ the client has selected a different server from which to obtain
+ configuration parameters. The server may discard any information it
+ may have cached about the client's request, and may free the network
+ address that it had offered to the client.
+
+ Note that the client may choose to collect several DHCPOFFER messages
+ and select the "best" offer. The client indicates its selection by
+ identifying the offering server in the DHCPREQUEST message. If the
+ client receives no acceptable offers, the client may choose to try
+ another DHCPDISCOVER message. Therefore, the servers may not receive
+ a specific DHCPREQUEST from which they can decide whether or not the
+ client has accepted the offer. Because the servers have not
+ committed any network address assignments on the basis of a
+ DHCPOFFER, servers are free to reuse offered network addresses in
+ response to subsequent requests. As an implementation detail,
+ servers should not reuse offered addresses and may use an
+ implementation-specific timeout mechanism to decide when to reuse an
+ offered address.
+
+ In the second case, when there is no 'server identifier' option, the
+ client is renewing or extending a previously allocated IP address.
+ The server checks to confirm that the requested parameters are
+ acceptable. If the parameters specified in the DHCPREQUEST message
+ match the previous parameters, or if the request for an extension of
+ the lease (indicated by an extended 'IP address lease time' option)
+ is acceptable, the server returns a DHCPACK message to the requesting
+ client. Otherwise, the server returns a DHCPNAK message to the
+
+
+
+Droms [Page 28]
+
+RFC 1531 Dynamic Host Configuration Protocol October 1993
+
+
+ client. In particular, if the previously allocated network address
+ in the 'ciaddr' field from the client does not match the network
+ address recorded by the server for that client, the server sends a
+ DHCPNAK to the client.
+
+ A DHCP server chooses the parameters to return in a DHCPACK message
+ according to the same rules as used in constructing a DHCPOFFER
+ message, as given in section 4.3.1.
+
+4.3.3 DHCPDECLINE message
+
+ If the server receives a DHCPDECLINE message, the client has
+ discovered through some other means that the suggested network
+ address is already in use. The server MUST mark the network address
+ as not allocated and SHOULD notify the local system administrator of
+ a possible configuration problem.
+
+4.3.4 DHCPRELEASE message
+
+ Upon receipt of a DHCPRELEASE message, the server marks the network
+ address as not allocated. The server should retain a record of the
+ client's initialization parameters for possible reuse in response to
+ subsequent requests from the client.
+
+4.4 DHCP client behavior
+
+ Figure 5 gives a state-transition diagram for a DHCP client. A
+ client can receive the following messages from a server:
+
+ o DHCPOFFER
+
+ o DHCPACK
+
+ o DHCPNAK
+
+ Table 4 gives the use of the fields and options in a DHCP message by
+ a client. The remainder of this section describes the action of the
+ DHCP client for each possible incoming message. The description in
+ the following section corresponds to the full configuration procedure
+ previously described in section 3.1, and the text in the subsequent
+ section corresponds to the abbreviated configuration procedure
+ described in section 3.2.
+
+4.4.1 Initialization and allocation of network address
+
+ The client begins in INIT state and forms a DHCPDISCOVER message.
+ The client should wait a random time between one and ten seconds to
+ desynchronize the use of DHCP at startup. The client sets 'ciaddr'
+
+
+
+Droms [Page 29]
+
+RFC 1531 Dynamic Host Configuration Protocol October 1993
+
+
+ to all 0x00000000. The client MAY request specific parameters by
+ including the 'parameter request list' option. The client MAY
+ suggest a network address and/or lease time by including the
+ 'requested IP address' and 'IP address lease time' options. The
+ client MUST include its hardware address in the 'chaddr' field for
+ use in delivery of DHCP reply messages. The client MAY include a
+ different unique identifier in the 'client identifier' option. If
+ the client does not include the
+
+ The client generates and records a random transaction identifier and
+ inserts that identifier into the 'xid' field. The client records its
+ own local time for later use in computing the lease expiration. The
+ client then broadcasts the DHCPDISCOVER on the local hardware
+ broadcast address to the all-ones IP broadcast address and 'DHCP
+ server' UDP port.
+
+ If the 'xid' of an arriving DHCPOFFER message does not match the
+ 'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message
+ must be silently discarded. Any arriving DHCPACK messages must be
+ silently discarded.
+
+ The client collects DHCPOFFER messages over a period of time, selects
+ one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
+ messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
+ from the previously used server) and extracts the server address from
+ the 'server identifier' option in the DHCPOFFER message. The time
+ over which the client collects messages and the mechanism used to
+ select one DHCPOFFER are implementation dependent. The client may
+ perform a check on the suggested address to ensure that the address
+ is not already in use. For example, if the client is on a network
+ that supports ARP, the client may issue an ARP request for the
+ suggested request. When broadcasting an ARP request for the
+ suggested address, the client must fill in its own hardware address
+ as the sender's hardware address, and 0 as the sender's IP address,
+ to avoid confusing ARP caches in other hosts on the same subnet. If
+ the network address appears to be in use, the client sends a
+ DHCPDECLINE message to the server and waits for another DHCPOFFER. As
+ the client does not have a valid network address, the client must
+ broadcast the DHCPDECLINE message.
+
+
+
+
+
+
+
+
+
+
+
+
+Droms [Page 30]
+
+RFC 1531 Dynamic Host Configuration Protocol October 1993
+
+
+ -------- -------
+| | +-------------------------->| |<-------------------+
+| INIT/ | | +-------------------->| INIT | |
+| REBOOT |DHCPNAK/ +---------->| |<---+ |
+| |Restart| | ------- | |
+ -------- | DHCPNAK/ | | |
+ | Discard offer | -/Send DHCPDISCOVER |
+-/Send DHCPREQUEST | | |
+ | | | DHCPACK v | |
+ ----------- | (not accept.)/ ----------- | |
+| | | Send DHCPDECLINE | | | |
+| REBOOTING | | | | SELECTING | | |
+| | | / | | | |
+ ----------- | / ----------- | |
+ | | / | | |
+DHCPACK/ | / +----------------+ | |
+Record lease, | | v | |
+set timers ------------ | |
+ | +----->| | DHCPNAK, Lease expired/ |
+ | | | REQUESTING | Halt network |
+ DHCPOFFER/ | | | |
+ Discard ------------ | |
+ | | | | ----------- |
+ | +--------+ DHCPACK/ | | |
+ | Record lease, set -----| REBINDING | |
+ | timers T1, T2 / | | |
+ | | DHCPACK/ ----------- |
+ | v Record lease, set ^ |
+ +----------------> ------- /Timers T1,T2 | |
+ +----->| |<---+ | |
+ | | BOUND |<---+ | |
+ DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/
+ DHCPNAK/Discard ------- | Broadcast Halt network
+ | | | | DHCPREQUEST |
+ +-------+ | DHCPACK/ | |
+ T1 expires/ Record lease, set | |
+ Send DHCPREQUEST timers T1, T2 | |
+ to leasing server | | |
+ | ---------- | |
+ | | |------------+ |
+ +->| RENEWING | |
+ | |----------------------------+
+ ----------
+
+ Figure 5: State-transition diagram for DHCP clients
+
+
+
+
+
+
+Droms [Page 31]
+
+RFC 1531 Dynamic Host Configuration Protocol October 1993
+
+
+ Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
+ DHCPRELEASE
+ ----- ------------ ----------- -----------
+
+ 'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
+ 'htype' (From "Assigned Numbers" RFC)
+ 'hlen' (Hardware address length in octets)
+ 'hops' 0 0 0
+ 'xid' selected by client selected by client selected by
+ client
+ 'secs' (opt.) (opt.) 0
+ 'flags' Set 'BROADCAST' Set 'BROADCAST'
+ flag if client flag if client
+ requires broadcast requires broadcast
+ reply reply
+ 0
+ 'ciaddr' 0 previously ciaddr
+ allocated newtork
+ address
+ 'yiaddr' 0 0 0
+ 'siaddr' 0 0 0
+ 'giaddr' 0 0 0
+ 'chaddr' client's hardware client's hardware client's
+ hardware
+ address address address
+ 'sname' options, if options, if (unused)
+ indicated in indicated in
+ 'sname/file' 'sname/file'
+ option; otherwise option; otherwise
+ unused unused
+ 'file' options, if options, if (unused)
+ indicated in indicated in
+ 'sname/file' 'sname/file'
+ option; otherwise option; otherwise
+ 'generic' name or 'generic' name or
+ null null
+ 'options' options options (unused)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms [Page 32]
+
+RFC 1531 Dynamic Host Configuration Protocol October 1993
+
+
+ Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
+ DHCPRELEASE
+ ------ ------------ ----------- -----------
+
+ Requested IP address MAY MUST NOT MUST NOT
+ IP address lease time MAY MAY MUST NOT
+ Use 'file'/'sname' fields MAY MAY MAY
+ DHCP message type DHCPDISCOVER DHCPREQUEST DHCPDECLINE/
+ DHCPRELEASE
+ Client identifier MAY MAY MAY
+ Class identifier SHOULD SHOULD MUST NOT
+ Server identifier MUST NOT MUST (after MUST
+ DHCPDISCOVER),
+ MUST NOT (when
+ renewing)
+ Parameter request list MAY MAY MUST NOT
+ Maximum message size MAY MAY MUST NOT
+ Message SHOULD NOT SHOULD NOT SHOULD
+ Site-specific MAY MAY MUST NOT
+ All others MUST NOT MUST NOT MUST NOT
+
+ Table 4: Fields and options used by DHCP clients
+
+ If the parameters are acceptable, the client records the address of
+ the server that supplied the parameters from the 'server identifier'
+ field and sends that address in the 'server identifier' field of a
+ DHCPREQUEST broadcast message. Once the DHCPACK message from the
+ server arrives, the client is initialized and moves to BOUND state.
+ The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER
+ message. The client records the lease expiration time as the sum of
+ the time at which the original request was sent and the duration of
+ the lease from the DHCPOFFER message. The client SHOULD broadcast an
+ ARP reply to announce the client's new IP address and clear any
+ outdated ARP cache entries in hosts on the client's subnet.
+
+4.4.2 Initialization with known network address
+
+ The client begins in INIT-REBOOT state and sends a DHCPREQUEST message
+ with the 'ciaddr' field set to the client's network address. The
+ client may request specific configuration parameters by including the
+ random transaction identifier and inserts that identifier into the
+ computing the lease expiration. The client MUST NOT incldue a 'server
+ identifier' in the DHCPREQUEST message. The client then broadcasts
+ the DHCPREQUEST on the local hardware broadcast address to the 'DHCP
+ server' UDP port.
+
+ Once a DHCPACK message with an 'xid' field matching that in the
+ client's DHCPREQUEST message arrives from any server, the client is
+
+
+
+Droms [Page 33]
+
+RFC 1531 Dynamic Host Configuration Protocol October 1993
+
+
+ initialized and moves to BOUND state. The client records the lease
+ expiration time as the sum of the time at which the DHCPREQUEST
+ message was sent and the duration of the lease from the DHCPACK
+ message.
+
+4.4.3 Initialization with a known DHCP server address
+
+ When the DHCP client knows the address of a DHCP server, in either
+ INIT or REBOOTING state, the client may use that address in the
+ DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. If
+ the client receives no response to DHCP messages sent to the IP
+ address of a known DHCP server, the DHCP client reverts to using the
+ IP broadcast address.
+
+4.4.4 Reacquisition and expiration
+
+ The client maintains two times, T1 and T2, that specify the times at
+ which the client tries to extend its lease on its network address. T1
+ is the time at which the client enters the RENEWING state and attempts
+ to contact the server that originally issued the client's network
+ address. T2 is the time at which the client enters the REBINDING
+ state and attempts to contact any server.
+
+ At time T1 after the client accepts the lease on its network address,
+ the client moves to RENEWING state and sends (via unicast) a
+ DHCPREQUEST message to the server to extend its lease. The client
+ generates a random transaction identifier and inserts that identifier
+ into the 'xid' field in the DHCPREQUEST. The client records the local
+ time at which the DHCPREQUEST message is sent for computation of the
+ lease expiration time. The client MUST NOT include a 'server
+ identifier' in the DHCPREQUEST message.
+
+ Any DHCPACK messages that arrive with an 'xid' that does not match the
+ When the client receives a DHCPACK from the server, the client
+ computes the lease expiration time as the sum of the time at which the
+ client sent the DHCPREQUEST message and the duration of the lease in
+ the DHCPACK message. The client has successfully reacquired its
+ network address, returns to BOUND state and may continue network
+ processing.
+
+ If no DHCPACK arrives before time T2 (T2 > T1) before the expiration
+ of the client's lease on its network address, the client moves to
+ REBINDING state and sends (via broadcast) a DHCPREQUEST message to
+ extend its lease. The client sets the 'ciaddr' field in the
+ DHCPREQUEST to its current network address. The client MUST NOT
+ include a 'server identifier' in the DHCPREQUEST message.
+
+ Times T1 and T2 are configurable by the server through options. T1
+
+
+
+Droms [Page 34]
+
+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
+
+ TCP_parameters,_per_host:_
+ TTL integer HRC 4.2.2.19
+ Keep-alive interval integer HRC 4.2.3.6
+ Keep-alive data size 0/1 HRC 4.2.3.6
+
+Key:
+
+ MTU = Path MTU Discovery (RFC 1191, Proposed Standard)
+ RD = Router Discovery (RFC 1256, Proposed Standard)
+
+
+
+Droms [Page 39]
+ \ No newline at end of file