`
`
`
`
`Network Working Group R. Droms
`Request for Comments: 2131 Bucknell University
`Obsoletes: 1541 March 1997
`Category: Standards Track
`
` Dynamic Host Configuration Protocol
`
`Status of this memo
`
` This document 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" (STD 1) 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 TCPIP 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, 21], and DHCP participants can interoperate
` with BOOTP participants [9].
`
`Table of Contents
`
` 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
` 1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 3
` 1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
` 1.3 Problem definition and issues . . . . . . . . . . . . . . . . 4
` 1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5
` 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
` 1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6
` 2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8
` 2.1 Configuration parameters repository . . . . . . . . . . . . . 11
` 2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12
` 3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13
` 3.1 Client-server interaction - allocating a network address. . . 13
` 3.2 Client-server interaction - reusing a previously allocated
` network address . . . . . . . . . . . . . . . . . . . . . . . 17
` 3.3 Interpretation and representation of time values. . . . . . . 20
` 3.4 Obtaining parameters with externally configured network
` address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
` 3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21
` 3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22
` 3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22
` 4. Specification of the DHCP client-server protocol. . . . . . . 22
`
`
`
`Droms Standards Track [Page 1]
`
`1
`
`SAMSUNG 1014
`
`

`

`
`RFC 2131 Dynamic Host Configuration Protocol March 1997
`
`
` 4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22
` 4.2 DHCP server administrative controls . . . . . . . . . . . . . 25
` 4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 26
` 4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 34
` 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .42
` 6. References . . . . . . . . . . . . . . . . . . . . . . . . . .42
` 7. Security Considerations. . . . . . . . . . . . . . . . . . . .43
` 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .44
` A. Host Configuration Parameters . . . . . . . . . . . . . . . .45
`List of Figures
` 1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9
` 2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11
` 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. . . . . . . . . . . 34
`List of Tables
` 1. Description of fields in a DHCP message. . . . . . . . . . . . 10
` 2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 14
` 3. Fields and options used by DHCP servers. . . . . . . . . . . . 28
` 4. Client messages from various states. . . . . . . . . . . . . . 33
` 5. Fields and options used by DHCP clients. . . . . . . . . . . . 37
`
`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.
`
` 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
`
`
`
`
`
`
`2
`
`

`

`
`Droms Standards Track [Page 2]
`
`RFC 2131 Dynamic Host Configuration Protocol March 1997
`
`
` 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
` client. In "dynamic allocation", DHCP assigns an IP address to a
` client for a limited period of time (or until the client explicitly
` relinquishes the address). In "manual allocation", a client's IP
` address is assigned by the network administrator, and DHCP is used
` simply to convey the assigned address to the client. 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
` client to which it was assigned. Thus, dynamic allocation is
` particularly useful for assigning an address to a client that will be
` connected to the network only temporarily or for sharing a limited
` pool of IP addresses among a group of clients that do not need
` permanent IP addresses. Dynamic allocation may also be a good choice
` for assigning an IP address to a new client being permanently
` connected to a network where IP addresses are sufficiently scarce
` that it is important to reclaim them when old clients 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, 21] and to allow interoperability of existing
` BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates
` the necessity of having a DHCP server on each physical network
` segment.
`
`1.1 Changes to RFC 1541
`
` This document updates the DHCP protocol specification that appears in
` RFC1541. A new DHCP message type, DHCPINFORM, has been added; see
` section 3.4, 4.3 and 4.4 for details. The classing mechanism for
` identifying DHCP clients to DHCP servers has been extended to include
` "vendor" classes as defined in sections 4.2 and 4.3. The minimum
` lease time restriction has been removed. Finally, many editorial
` changes have been made to clarify the text as a result of experience
` gained in DHCP interoperability tests.
`
`
`
`
`
`3
`
`

`

`Droms Standards Track [Page 3]
`
`RFC 2131 Dynamic Host Configuration Protocol March 1997
`
`
`1.2 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]. The Address Resolution Protocol (ARP) has been proposed
` 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.3 Problem definition and issues
`
` DHCP is designed to supply DHCP clients with the configuration
` parameters defined in the Host Requirements RFCs. After obtaining
` parameters via DHCP, a DHCP client should be able to exchange packets
` with any other host in the Internet. The TCP/IP stack parameters
` supplied by DHCP are listed in Appendix A.
`
`
`
`
`
`Droms Standards Track [Page 4]
`
`4
`
`

`

`
`RFC 2131 Dynamic Host Configuration Protocol March 1997
`
`
` Not all of these parameters are required for a newly initialized
` client. 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 client
` parameters not directly related to the IP protocol. DHCP also does
` not address registration of newly configured clients with the Domain
` Name System (DNS) [12, 13].
`
` DHCP is not intended for use in configuring routers.
`
`1.4 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.
`
`
`
`
`
`
`
`
`
`
`
`
`5
`
`

`

`Droms Standards Track [Page 5]
`
`RFC 2131 Dynamic Host Configuration Protocol March 1997
`
`
` 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.5 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 or 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.6 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.
`
`
`
`
`
`
`
`
`
`6
`
`

`

`Droms Standards Track [Page 6]
`
`RFC 2131 Dynamic Host Configuration Protocol March 1997
`
`
` o Clients should require no manual configuration. Each client
` 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 manual configuration for individual
` clients. Under normal circumstances, the network manager
` should not have to enter any per-client 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 relay agents.
`
` o A DHCP client 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 RFC 1542 [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 DHCP client at a time,
`
` o Retain DHCP client configuration across DHCP client reboot. A
` DHCP client should, whenever possible, be assigned the same
` configuration parameters (e.g., network address) in response
` to each request,
`
` o Retain DHCP client configuration across server reboots, and,
` whenever possible, a DHCP client should be assigned the same
` configuration parameters despite restarts of the DHCP mechanism,
`
` o Allow automated assignment of configuration parameters to new
` clients to avoid hand configuration for new clients,
`
` o Support fixed or permanent allocation of configuration
` parameters to specific clients.
`
`
`
`
`
`
`7
`
`

`

`Droms Standards Track [Page 7]
`
`RFC 2131 Dynamic Host Configuration Protocol March 1997
`
`
`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. RFC 1542 [2] 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 finite 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."
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`8
`
`

`

`Droms Standards Track [Page 8]
`
`RFC 2131 Dynamic Host Configuration Protocol March 1997
`
`
` 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 (variable) |
` +---------------------------------------------------------------+
`
` Figure 1: Format of a DHCP message
`
` 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'
` is an opaque key, not to be interpreted by the server; for example,
` the 'client identifier' 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. The 'client identifier' chosen by a
` DHCP client MUST be unique to that client within the subnet to which
` the client is attached. If the client uses a 'client identifier' in
` one message, it MUST use that same identifier in all subsequent
` messages, to ensure that all servers correctly identify the client.
`
`
`
`
`
`
`9
`
`

`

`Droms Standards Track [Page 9]
`
`RFC 2131 Dynamic Host Configuration Protocol March 1997
`
`
` 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.
`
` 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
` began address acquisition or renewal process.
` flags 2 Flags (see figure 2).
` ciaddr 4 Client IP address; only filled in if client is in
` BOUND, RENEW or REBINDING state and can respond
` to ARP requests.
` yiaddr 4 'your' (client) IP address.
` siaddr 4 IP address of next server to use in bootstrap;
` returned in DHCPOFFER, DHCPACK 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 var Optional parameters field. See the options
` documents for a list of defined options.
`
` Table 1: Description of fields in a DHCP message
`
` The 'options' field is now variable length. A DHCP client must be
` prepared to receive DHCP messages with an 'options' field of at least
` length 312 octets. This requirement implies that a DHCP client must
` be prepared to receive a message of up to 576 octets, the minimum IP
`
`
`
`
`
`10
`
`

`

`Droms Standards Track [Page 10]
`
`RFC 2131 Dynamic Host Configuration Protocol March 1997
`
`
` datagram size an IP 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.
`
` In the case of a client using DHCP for initial configuration (before
` the client's TCP/IP software has been completely configured), DHCP
` requires creative use of the client's TCP/IP software and liberal
` interpretation of RFC 1122. The TCP/IP software SHOULD accept and
` forward to the IP layer any IP packets delivered to the client's
` hardware address before the IP address is configured; DHCP servers
` and BOOTP relay agents may not be able to deliver DHCP messages to
` clients that cannot accept hardware unicast datagrams before the
` TCP/IP software is configured.
`
` To work around some clients that cannot accept IP unicast datagrams
` before the TCP/IP software is configured as discussed in the previous
` paragraph, 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.
`
` 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
`
`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) (note that the "hardware-address" should be typed by the
`
`
`
`
`
`11
`
`

`

`Droms Standards Track [Page 11]
`
`RFC 2131 Dynamic Host Configuration Protocol March 1997
`
`
` type of hardware to accommodate possible duplication of hardware
` addresses resulting from bit-ordering problems in a mixed-media,
` bridged network) 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 DHCP client that has been moved to a
` different subnet or has changed hardware addresses (perhaps because
` the network interface failed and was replaced). The protocol defines
` that the key will be (IP-subnet-number, hardware-address) unless the
` client explicitly supplies an identifier using the 'client
` identifier' option. 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 clients. 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 client 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 allocating
` server SHOULD probe the reused address before allocating the address,
` e.g., with an ICMP echo request, and the client SHOULD probe the
` newly received address, e.g., with ARP.
`
`
`
`
`
`
`
`12
`
`

`

`Droms Standards Track [Page 12]
`
`RFC 2131 Dynamic Host Configuration Protocol March 1997
`
`
`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
` is the same magic cookie as is defined in RFC 1497 [17]). The
` remainder of the 'options' field consists of a list of tagged
` parameters that are called "options". All of the "vendor extensions"
` listed in RFC 1497 are also DHCP options. RFC 1533 gives the
` complete set of options defined for use with DHCP.
`
` 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