As per Relevance of the word broadcast, we have this rfc below:
Network Working Group R.
Request for Comments: 1531 Bucknell
Category: Standards Track October 1993
Dynamic Host Configuration
Status of this
This RFC specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" for the standardization state and
of this protocol. Distribution of this memo is unlimited
The Dynamic Host Configuration Protocol (DHCP) provides a
for passing configuration information to hosts on a TCP/IP network
DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding
capability of automatic allocation of reusable network addresses
additional configuration options [19]. DHCP captures the behavior
BOOTP relay agents [7, 23], and DHCP participants can
with BOOTP participants [9].
Table of
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
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
1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9
2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 10
3. Timeline diagram of messages exchanged between DHCP client
servers when allocating a new network address. . . . . . . . . 15
4. Timeline diagram of messages exchanged between DHCP client
servers when reusing a previously allocated network address. . 18
5. State-transition diagram for DHCP clients. . . . . . . . . . . 31
List of
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.
The Dynamic Host Configuration Protocol (DHCP) provides
parameters to Internet hosts. DHCP consists of two components:
protocol for delivering host-specific configuration parameters from
DHCP server to a host and a mechanism for allocation of
addresses to hosts
DHCP is built on a client-server model, where designated DHCP
hosts allocate network addresses and deliver configuration
to dynamically configured hosts. Throughout the remainder of
document, the term "server" refers to a host providing
parameters through DHCP, and the term "client" refers to a
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
to do so by a system administrator. The diversity of hardware
protocol implementations in the Internet would preclude
operation if random hosts were allowed to respond to DHCP requests
For example, IP requires the setting of many parameters within
protocol implementation software. Because IP can be used on
dissimilar kinds of network hardware, values for those
cannot be guessed or assumed to have correct defaults. Also
distributed address allocation schemes depend on a polling/
mechanism for discovery of addresses that are already in use.
hosts may not always be able to defend their network addresses,
that such a distributed address allocation scheme cannot
guaranteed to avoid allocation of duplicate network addresses
DHCP supports three mechanisms for IP address allocation.
"automatic allocation", DHCP assigns a permanent IP address to
host. In "dynamic allocation", DHCP assigns an IP address to a
for a limited period of time (or until the host
relinquishes the address). In "manual allocation", a host's
address is assigned by the network administrator, and DHCP is
simply to convey the assigned address to the host. A
network will use one or more of these mechanisms, depending on
policies of the network administrator
Dynamic allocation is the only one of the three mechanisms
allows automatic reuse of an address that is no longer needed by
host to which it was assigned. Thus, dynamic allocation
particularly useful for assigning an address to a host that will
connected to the network only temporarily or for sharing a
pool of IP addresses among a group of hosts that do not
permanent IP addresses. Dynamic allocation may also be a good
for assigning an IP address to a new host being permanently
to a network where IP addresses are sufficiently scarce that it
important to reclaim them when old hosts are retired.
allocation allows DHCP to be used to eliminate the error-
process of manually configuring hosts with IP addresses
environments where (for whatever reasons) it is desirable to
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
BOOTP specification [7, 23] and to allow interoperability of
BOOTP clients with DHCP servers. Using BOOTP relaying
eliminates the necessity of having a DHCP server on each
network segment
Droms [Page 3]
RFC 1531 Dynamic Host Configuration Protocol October 1993
1.1 Related
There are several Internet protocols and related mechanisms
address some parts of the dynamic host configuration problem.
Reverse Address Resolution Protocol (RARP) [10] (through
extensions defined in the Dynamic RARP (DRARP) [5])
addresses the problem of network address discovery, and includes
automatic IP address assignment mechanism. The Trivial File
Protocol (TFTP) [20] provides for transport of a boot image from
boot server. The Internet Control Message Protocol (ICMP) [16]
provides for informing hosts of additional routers via "
redirect" messages. ICMP also can provide subnet mask
through the "ICMP mask request" message and other information
the (obsolete) "ICMP information request" message. Hosts can
routers through the ICMP router discovery mechanism [8].
BOOTP is a transport mechanism for a collection of
information. BOOTP is also extensible, and official extensions [17]
have been defined for several configuration parameters. Morgan
proposed extensions to BOOTP for dynamic IP address assignment [15].
The Network Information Protocol (NIP), used by the Athena project
MIT, is a distributed mechanism for dynamic IP address
[19]. The Resource Location Protocol RLP [1] provides for
of higher level services. Sun Microsystems diskless workstations
a boot procedure that employs RARP, TFTP and an RPC mechanism
"bootparams" to deliver configuration information and
system code to diskless hosts. (Sun Microsystems, Sun
and SunOS are trademarks of Sun Microsystems, Inc.) Some
networks also use DRARP and an auto-installation mechanism
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
path [14]. Comer and Droms have proposed the use of the
Resolution Protocol (ARP) as a transport protocol for
location and selection [6]. Finally, the Host Requirements RFCs [3,
4] mention specific requirements for host reconfiguration and
a scenario for initial configuration of diskless hosts
1.2 Problem definition and
DHCP is designed to supply hosts with the configuration
defined in the Host Requirements RFCs. After obtaining
via DHCP, a host should be able to exchange packets with any
host in the Internet. The parameters supplied by DHCP are listed
Appendix A
Droms [Page 4]
RFC 1531 Dynamic Host Configuration Protocol October 1993
Not all of these parameters are required for a newly
host. A client and server may negotiate for the transmission of
those parameters required by the client or specific to a
subnet
DHCP allows but does not require the configuration of host
not directly related to the IP protocol. DHCP also does not
registration of newly configured hosts with the Domain Name
(DNS) [12, 13].
DHCP is not intended for use in configuring routers
1.3
Throughout this document, the words that are used to define
significance of particular requirements are capitalized. These
are
o "MUST
This word or the adjective "REQUIRED" means that
item is an absolute requirement of this specification
o "MUST NOT
This phrase means that the item is an absolute
of this specification
o "SHOULD
This word or the adjective "RECOMMENDED" means that
may exist valid reasons in particular circumstances to
this item, but the full implications should be understood
the case carefully weighed before choosing a different course
o "SHOULD NOT
This phrase means that there may exist valid reasons
particular circumstances when the listed behavior is
or even useful, but the full implications should be
and the case carefully weighed before implementing any
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
truly optional. One vendor may choose to include the
because a particular marketplace requires it or because
enhances the product, for example; another vendor may omit
same item
1.4
This document uses the following terms
o "DHCP client
A DHCP client is an Internet host using DHCP to
configuration parameters such as a network address
o "DHCP server
A DHCP server is an Internet host that returns
parameters to DHCP clients
o "BOOTP relay agent
A BOOTP relay agent is an Internet host or router that
DHCP messages between DHCP clients and DHCP servers. DHCP
designed to use the same relay agent behavior as specified
the BOOTP protocol specification
o "binding
A binding is a collection of configuration parameters,
at least an IP address, associated with or "bound to" a
client. Bindings are managed by DHCP servers
1.5 Design
The following list gives general design goals for DHCP
o DHCP should be a mechanism rather than a policy. DHCP
allow local system administrators control over
parameters where desired; e.g., local system
should be able to enforce local policies concerning
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
be able to discover appropriate local configuration
without user intervention and incorporate those parameters
its own configuration
o Networks should require no hand configuration for
hosts. Under normal circumstances, the network manager
not have to enter any per-host configuration parameters
o DHCP should not require a server on each subnet. To allow
scale and economy, DHCP must work across routers or through
intervention of BOOTP/DHCP relay agents
o A DHCP host must be prepared to receive multiple responses to
request for configuration parameters. Some installations
include multiple, overlapping DHCP servers to
reliability and increase performance
o DHCP must coexist with statically configured, non-
hosts and with existing network protocol implementations
o DHCP must interoperate with the BOOTP relay agent behavior
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
the network layer parameters. DHCP must
o Guarantee that any specific network address will not be
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
(e.g., network address) in response to each request
o Retain host configuration across server reboots, and,
possible, a host should be assigned the same
parameters despite restarts of the DHCP mechanism
o Allow automatic assignment of configuration parameters to
hosts to avoid hand configuration for new hosts
o Support fixed or permanent allocation of
parameters to specific hosts
Droms [Page 7]
RFC 1531 Dynamic Host Configuration Protocol October 1993
2. Protocol
From the client's point of view, DHCP is an extension of the
mechanism. This behavior allows existing BOOTP clients
interoperate with DHCP servers without requiring any change to
clients' initialization software. A separate document details
interactions between BOOTP and DHCP clients and servers [9].
are some new, optional transactions that optimize the
between DHCP clients and servers that are described in sections 3
4.
Figure 1 gives the format of a DHCP message and table 1
each of the fields in the DHCP message. The numbers in
indicate the size of each field in octets. The names for the
given in the figure will be used throughout this document to refer
the fields in DHCP messages
There are two primary differences between DHCP and BOOTP. First
DHCP defines mechanisms through which clients can be assigned
network address for a fixed lease, allowing for serial
of network addresses to different clients. Second, DHCP provides
mechanism for a client to acquire all of the IP
parameters that it needs in order to operate
DHCP introduces a small change in terminology intended to clarify
meaning of one of the fields. What was the "vendor extensions"
in BOOTP has been re-named the "options" field in DHCP. Similarly
the tagged data items that were used inside the BOOTP "
extensions" field, which were formerly referred to as "
extensions," are now termed simply "options."
DHCP defines a new 'client identifier' option that is used to pass
explicit client identifier to a DHCP server. This change
the overloading of the 'chaddr' field in BOOTP messages, where
messages and as a client identifier. The 'client identifier'
may contain a hardware address, identical to the contents of
'chaddr' field, or it may contain another type of identifier, such
a DNS name. Other client identifier types may be defined as
for use with DHCP. New client identifier types will be
with the IANA [18] and will be included in new revisions of
Assigned Numbers document, as well as described in detail in
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
DHCP clarifies the interpretation of the 'siaddr' field as
address of the server to use in the next step of the client'
bootstrap process. A DHCP server may return its own address in
'siaddr' field, if the server is prepared to supply the
bootstrap service (e.g., delivery of an operating system
image). A DHCP server always returns its own address in the '
identifier' option
The options field is now variable length, with the minimum
to 312 octets. This brings the minimum size of a DHCP message up
576 octets, the minimum IP datagram size a host must be prepared
accept [3]. DHCP clients may negotiate the use of larger
messages through the 'Maximum DHCP message size' option. The
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
allow for expansion of the number of options that can be
[2]. Options encapsulated as 'vendor specific information' must
carefully defined and documented so as to allow for
between clients and servers from diferent vendors. In particular
vendors defining 'vendor specific information' MUST document
options in the form of the DHCP Options document, MUST choose
represent those options either in data types already defined for
options or in other well-defined data types, and MUST choose
that can be readily encoded in configuration files for exchange
servers provided by other vendors. Options included as '
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
MBZ: MUST BE ZERO (reserved for future use
Figure 2: Format of the 'flags'
DHCP uses the 'flags' field [21]. The leftmost bit is defined as
BROADCAST (B) flag. The semantics of this flag are discussed
section 4.1 of this document. The remaining bits of the flags
are reserved for future use. They MUST be set to zero by clients
ignored by servers and relay agents. Figure 2 gives the format
2.1 Configuration parameters
The first service provided by DHCP is to provide persistent
of network parameters for network clients. The model of
persistent storage is that the DHCP service stores a key-value
for each client, where the key is some unique identifier (
example, an IP subnet number and a unique identifier within
subnet) and the value contains the configuration parameters for
client
For example, the key might be the pair (IP-subnet-number, hardware
address), allowing for serial or concurrent reuse of a
address on different subnets, and for hardware addresses that may
be globally unique. Alternately, the key might be the pair (IP
subnet-number, hostname), allowing the server to assign
intelligently to a host that has been moved to a different subnet
Droms [Page 10]
RFC 1531 Dynamic Host Configuration Protocol October 1993
has changed hardware addresses (perhaps because the network
failed and was replaced).
A client can query the DHCP service to retrieve its
parameters. The client interface to the configuration
repository consists of protocol messages to request
parameters and responses from the server carrying the
parameters
2.2 Dynamic allocation of network
The second service provided by DHCP is the allocation of temporary
permanent network (IP) addresses to hosts. The basic mechanism
the dynamic allocation of network addresses is simple: a
requests the use of an address for some period of time.
allocation mechanism (the collection of DHCP servers) guarantees
to reallocate that address within the requested time and attempts
return the same network address each time the client requests
address. In this document, the period over which a network
is allocated to a client is referred to as a "lease" [11].
client may extend its lease with subsequent requests. The client
issue a message to release the address back to the server when
client no longer needs the address. The client may ask for
permanent assignment by asking for an infinite lease. Even
assigning "permanent" addresses, a server may choose to give
lengthy but non-infinite leases to allow detection of the fact
the host has been retired
In some environments it will be necessary to reassign
addresses due to exhaustion of available addresses. In
environments, the allocation mechanism will reuse addresses
lease has expired. The server should use whatever information
available in the configuration information repository to choose
address to reuse. For example, the server may choose the
recently assigned address. As a consistency check, the
mechanism may probe the reused address, e.g., with an ICMP
request, before allocating the address, and the client will probe
newly received address, e.g., with ARP
3. The Client-Server
DHCP uses the BOOTP message format defined in RFC 951 and given
table 1 and figure 1. The 'op' field of each DHCP message sent
a client to a server contains BOOTREQUEST. BOOTREPLY is used in
'op' field of each DHCP message sent from a server to a client
The first four octets of the 'options' field of the DHCP
contain the (decimal) values 99, 130, 83 and 99, respectively (
Droms [Page 11]
RFC 1531 Dynamic Host Configuration Protocol October 1993
is the same magic cookie as is defined in RFC 1395). The
of the 'options' field consists a list of tagged parameters that
called "options". All of the "vendor extensions" listed in RFC 1395
are also DHCP options. A separate document gives the complete set
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
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
type' option will be referred to by the type of the message; e.g.,
DHCP message with 'DHCP message type' option type 1 will be
to as a "DHCPDISCOVER" message
3.1 Client-server interaction - allocating a network
The following summary of the protocol exchanges between clients
servers refers to the DHCP messages described in table 2.
timeline diagram in figure 3 shows the timing relationships in
typical client-server interaction. If the client already knows
address, some steps may be omitted; this abbreviated interaction
described in section 3.2.
1. The client broadcasts a DHCPDISCOVER message on its local
subnet. The DHCPDISCOVER message may include options that
values for the network address and lease duration. BOOTP
agents may pass the message on to DHCP servers not on the
physical subnet
2. Each server may respond with a DHCPOFFER message that includes
available network address in the 'yiaddr' field (and
configuration parameters in DHCP options). Servers need
reserve the offered network address, although the protocol
work more efficiently if the server avoids allocating the
network address to another client. The server unicasts
DHCPOFFER message to the client (using the DHCP/BOOTP relay
if necessary) if possible, or may broadcast the message to
broadcast address (preferably 255.255.255.255) on the client'
subnet
3. The client receives one or more DHCPOFFER messages from one
more servers. The client may choose to wait for
responses. The client chooses one server from which to
configuration parameters, based on the configuration
offered in the DHCPOFFER messages. The client broadcasts
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
other options specifying desired configuration values.
DHCPREQUEST message is broadcast and relayed through DHCP/
relay agents. To help ensure that any DHCP/BOOTP relay
forward the DHCPREQUEST message to the same set of DHCP
that received the original DHCPDISCOVER message, the
message must use the same value in the DHCP message header'
'secs' field and be sent to the same IP broadcast address as
original DHCPDISCOVER message. The client times out
retransmits the DHCPDISCOVER message if the client receives
DHCPOFFER messages
4. The servers receive the DHCPREQUEST broadcast from the client
Those servers not selected by the DHCPREQUEST message use
message as notification that the client has declined that server'
offer. The server selected in the DHCPREQUEST message commits
binding for the client to persistent storage and responds with
DHCPACK message containing the configuration parameters for
requesting client. The combination of 'chaddr' and
network address constitute an unique identifier for the client'
lease and are used by both the client and server to identify
lease referred to in any DHCP messages. The 'yiaddr' field in
DHCPACK messages is filled in with the selected network address
If the selected server is unable to satisfy the DHCPREQUEST
(e.g., the requested network address has been allocated),
server SHOULD respond with a DHCPNAK message
A server may choose to mark addresses offered to clients
DHCPOFFER messages as unavailable. The server should mark
address offered to a client in a DHCPOFFER message as available
the server receives no DHCPREQUEST message from that client
Droms [Page 13]
RFC 1531 Dynamic Host Configuration Protocol October 1993
FIELD OCTETS
----- ------ -----------
op 1 Message op code / message type
1 = BOOTREQUEST, 2 =
htype 1 Hardware address type, see ARP section in "
Numbers" RFC; e.g., '1' = 10mb ethernet
hlen 1 Hardware address length (e.g. '6' for 10
ethernet).
hops 1 Client sets to zero, optionally used by relay-
when booting via a relay-agent
xid 4 Transaction ID, a random number chosen by
client, used by the client and server to
messages and responses between a client and
server
secs 2 Filled in by client, seconds elapsed since
started trying to boot
flags 2 Flags (see figure 2).
ciaddr 4 Client IP address; filled in by client
DHCPREQUEST if verifying previously
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
server
giaddr 4 Relay agent IP address, used in booting via
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
directory-path name in DHCPOFFER
options 312 Optional parameters field. See the
documents for a list of defined options
Table 1: Description of fields in a DHCP
Droms [Page 14]
RFC 1531 Dynamic Host Configuration Protocol October 1993
Server Client
(not selected) (selected
v v
| | |
| Begins initialization |
| | |
| _____________/|\_____________ |
|/ DHCPDISCOVER | DHCPDISCOVER \|
| | |
Determines |
configuration |
| | |
|\ | ____________/|
| \_________ | /DHCPOFFER |
| DHCPOFFER\ |/ |
| \ | |
| Collects replies |
| \| |
| Selects configuration |
| | |
| _____________/|\_____________ |
|/ DHCPREQUEST | DHCPREQUEST \|
| | |
| | Commits
| | |
| | _____________/|
| |/ DHCPACK |
| | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\_____________ |
| | DHCPRELEASE \|
| | |
| | Discards
| | |
v v
Figure 3: Timeline diagram of messages exchanged between
client and servers when allocating a new network
Droms [Page 15]
RFC 1531 Dynamic Host Configuration Protocol October 1993
Message
------- ---
DHCPDISCOVER - Client broadcast to locate available servers
DHCPOFFER - Server to client in response to DHCPDISCOVER
offer of configuration parameters
DHCPREQUEST - Client broadcast to servers requesting
parameters from one server and implicitly
offers from all others
DHCPACK - Server to client with configuration parameters
including committed network address
DHCPNAK - Server to client refusing request for
parameters (e.g., requested network address
allocated).
DHCPDECLINE - Client to server indicating configuration
(e.g., network address) invalid
DHCPRELEASE - Client to server relinquishing network address
cancelling remaining lease
Table 2: DHCP
5. The client receives the DHCPACK message with
parameters. The client performs a final check on the
(e.g., ARP for allocated network address), and notes the
of the lease and the lease identification cookie specified in
DHCPACK message. At this point, the client is configured. If
client detects a problem with the parameters in the
message, the client sends a DHCPDECLINE message to the server
restarts the configuration process. The client should wait
minimum of ten seconds before restarting the configuration
to avoid excessive network traffic in case of looping
If the client receives a DHCPNAK message, the client restarts
configuration process
The client times out and retransmits the DHCPREQUEST message if
client receives neither a DHCPACK or a DHCPNAK message. The
retransmits the DHCPREQUEST according to the
algorithm in section 4.1. If the client receives neither a
or a DHCPNAK message after ten retransmissions of the
message, the client reverts to INIT state and restarts
initialization process. The client SHOULD notify the user that
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
by sending a DHCPRELEASE message to the server. The
identifies the lease to be released by including its
address in the 'ciaddr' field and its hardware address in
'chaddr' field
3.2 Client-server interaction - reusing a previously allocated
If a client remembers and wishes to reuse a previously
network address (allocated either by DHCP or some means outside
protocol), a client may choose to omit some of the steps described
the previous section. The timeline diagram in figure 4 shows
timing relationships in a typical client-server interaction for
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
the 'ciaddr' field. DHCP/BOOTP relay agents pass the message
to DHCP servers not on the same subnet
2. Servers with knowledge of the client's configuration
respond with a DHCPACK message to the client
If the client's request is invalid (e.g., the client has
to a new subnet), servers may respond with a DHCPNAK message
the client
3. The client receives the DHCPACK message with
prameters. The client performs a final check on the
(as in section 3.1), and notes the duration of the lease
the lease identification cookie specified in the
message. At this point, the client is configured
If the client detects a problem with the parameters in
DHCPACK message, the client sends a DHCPDECLINE message to
server and restarts the configuration process by requesting
new network address. This action corresponds to the
moving to the INIT state in the DHCP state diagram, which
described in section 4.4.
Droms [Page 17]
RFC 1531 Dynamic Host Configuration Protocol October 1993
Server Client
v v
| | |
| Begins |
| initialization |
| | |
| /|\ |
| ___________/ | \___________ |
| /DHCPREQUEST | DHCPREQUEST\ |
|/ | \|
| | |
Locates |
configuration |
| | |
|\ | /|
| \ | ___________/ |
| \ | / DHCPACK |
| \_______ |/ |
| DHCPACK\ | |
| Initialization |
| complete |
| \| |
| | |
| (Subsequent |
| DHCPACKS |
| ignored) |
| | |
| | |
v v
Figure 4: Timeline diagram of messages exchanged between
client and servers when reusing a previously
network
If the client receives a DHCPNAK message, it cannot reuse
remembered network address. It must instead request a
address by restarting the configuration process, this
using the (non-abbreviated) procedure described in
3.1. This action also corresponds to the client moving
the INIT state in the DHCP state diagram
The client times out and retransmits the DHCPREQUEST message
the client receives neither a DHCPACK nor a DHCPNAK message
The time between retransmission MUST be chosen according
the algorithm given in section 4.1. If the client receives
answer after transmitting 4 DHCPREQUEST messages, the
MAY choose to use the previously allocated network address
Droms [Page 18]
RFC 1531 Dynamic Host Configuration Protocol October 1993
configuration parameters for the remainder of the
lease. This corresponds to moving to BOUND state in the
state transition diagram shown in figure 5.
4. The client may choose to relinquish its lease on a
address by sending a DHCPRELEASE message to the server.
client identifies the lease to be released with the
identification cookie
Note that in this case, where the client retains its
address locally, the client will not normally relinquish
lease during a graceful shutdown. Only in the case where
client explicitly needs to relinquish its lease, e.g., the
is about to be moved to a different subnet, will the client
a DHCPRELEASE message
3.3 Interpretation and representation of time
A client acquires a lease for a network address for a fixed period
time (which may be infinite). Throughout the protocol, times are
be represented in units of seconds. The time value of 0xffffffff
reserved to represent "infinity". The minimum lease duration is
hour
As clients and servers may not have synchronized clocks, times
represented in DHCP messages as relative times, to be
with respect to the client's local clock. Representing
times in units of seconds in an unsigned 32 bit word gives a range
relative times from 0 to approximately 100 years, which is
for the relative times to be measured using DHCP
The algorithm for lease duration interpretation given in the
paragraph assumes that client and server clocks are stable
to each other. If there is drift between the two clocks, the
may consider the lease expired before the client does.
compensate, the server may return a shorter lease duration to
client than the server commits to its local database of
information
3.4 Host parameters in
Not all clients require initialization of all parameters listed
Appendix A. Two techniques are used to reduce the number
parameters transmitted from the server to the client. First, most
the parameters have defaults defined in the Host Requirements RFCs
if the client receives no parameters from the server that
the defaults, a client uses those default values. Second, in
initial DHCPDISCOVER or DHCPREQUEST message, a client may provide
Droms [Page 19]
RFC 1531 Dynamic Host Configuration Protocol October 1993
server with a list of specific parameters the client is
in
The client SHOULD include the 'maximum DHCP message size' option
let the server know how large the server may make its DHCP messages
The parameters returned to a client may still exceed the
allocated to options in a DHCP message. In this case, two
options flags (which must appear in the 'options' field of
message) indicate that the 'file' and 'sname' fields are to be
for options
The client can inform the server which configuration parameters
client is interested in by including the 'parameter request list
option. The data portion of this option explicitly lists the
requested by tag number
In addition, the client may suggest values for the network
and lease time in the DHCPDISCOVER message. The client may
the be assigned, and may include the 'IP address lease time'
to suggest the lease time it would like. No other
representing "hints" at configuration parameters are allowed in
DHCPDISCOVER or DHCPREQUEST message. The 'ciaddr' field is to
filled in only in a DHCPREQUEST message when the client is
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
may choose to report the problem to the system administrator.
server may include an error message in the 'message' option
3.5 Use of DHCP in clients with multiple
A host with multiple network interfaces must use DHCP through
interface independently to obtain configuration
parameters for those separate interfaces
3.6 When clients should use
A host should use DHCP to reacquire or verify its IP address
network parameters whenever the local network parameters may
changed; e.g., at system boot time or after a disconnection from
local network, as the local network configuration may change
the host's or user's knowledge
If a host has knowledge of a previous network address and is
to contact a local DHCP server, the host may continue to use
previous network address until the lease for that address expires
If the lease expires before the host can contact a DHCP server,
Droms [Page 20]
RFC 1531 Dynamic Host Configuration Protocol October 1993
host must immediately discontinue use of the previous network
and may inform local users of the problem
4. Specification of the DHCP client-server
In this section, we assume that a DHCP server has a block of
addresses from which it can satisfy requests for new addresses.
server also maintains a database of allocated addresses and leases
local permanent storage
4.1 Constructing and sending DHCP
DHCP clients and servers both construct DHCP messages by filling
fields in the fixed format section of the message and
tagged data items in the variable length option area. The
area includes first a four-octet 'magic cookie' (which was
in section 3), followed by the options. The last option must
be the 'end' option
DHCP uses UDP as its transport protocol. DHCP messages from a
to a server are sent to the 'DHCP server' port (67), and
messages from a server to a client are sent to the 'DHCP client'
(68).
DHCP messages broadcast by a client prior to that client
its IP address must have the source address field in the IP
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
DHCP relaying agent whose address appears in 'giaddr'. If
'giaddr' field is zero, the client is on the same subnet, and
server sends any return messages to either the client's
address, if that address was supplied in the 'ciaddr' field, or
the client's hardware address or to the local subnet
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
document [2]. If the 'option overload' option is present in
'options' field, the options in the 'options' field MUST
terminated by an options field. The options in the 'sname'
'file' fields (if in use as indicated by the 'options overload
option) MUST begin with the first octet of the field, MUST
terminated by an 'end' option, and MUST be followed by 'pad'
to fill the remainder of the field. Any individual option in
'options', 'sname' and 'file' fields MUST be entirely contained
Droms [Page 21]
RFC 1531 Dynamic Host Configuration Protocol October 1993
that field. The options in the 'options' field MUST be
first, so that any 'option overload' options may be interpreted.
'file' field MUST be interpreted next (if the options), followed
the 'sname' field
DHCP clients are responsible for all message retransmission.
client MUST adopt a retransmission strategy that incorporates
randomized exponential backoff algorithm to determine the
between retransmissions. The delay before the first
MUST be 4 seconds randomized by the value of a uniform random
chosen from the range -1 to +1. Clients with clocks that
resolution granularity of less than one second may choose a non
integer randomization value. The delay before the
retransmission MUST be 8 seconds randomized by the value of a
number chosen from the range -1 to +1. The retransmission delay
be doubled with subsequent retransmissions up to a maximum of 64
seconds. The client MAY provide an indication of
attempts to the user as an indication of the progress of
configuration process. The protocol specification in the
of this section will describe, for each DHCP message, when it
appropriate for the client to retransmit that message forever,
when it is appropriate for a client to abandon that message
attempt to use a different DHCP message
Normally, DHCP servers and BOOTP relay agents attempt to
DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client
unicast delivery. The IP destination address (in the IP header)
set to the DHCP 'yiaddr' address and the link-layer
address is set to the DHCP 'chaddr' address. Unfortunately,
client implementations are unable to receive such unicast
datagrams until the implementation has been configured with a
IP address (leading to a deadlock in which the client's IP
cannot be delivered until the client has been configured with an
address).
A client that cannot receive unicast IP datagrams until its
software has been configured with an IP address SHOULD set
BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER
DHCPREQUEST messages that client sends. The BROADCAST bit
provide a hint to the DHCP server and BOOTP relay agent to
any messages to the client on the client's subnet. A client that
receive unicast IP datagrams before its protocol software has
configured SHOULD clear the BROADCAST bit to 0. The
clarifications document discusses the ramifications of the use of
BROADCAST bit [21].
A server or relay agent sending or relaying a DHCP message
to a DHCP client (i.e., not to a relay agent specified in
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
an IP broadcast using an IP broadcast address (
255.255.255.255) as the IP destination address and the link-
broadcast address as the link-layer destination address. If
BROADCAST bit is cleared to 0, the message SHOULD be sent as an
unicast to the IP address specified in the 'yiaddr' field and
link-layer address specified in the 'chaddr' field. If unicasting
not possible, the message MAY be sent as an IP broadcast using an
broadcast address (preferably 255.255.255.255) as the IP
address and the link-layer broadcast address as the link-
destination address
4.2 DHCP server administrative
DHCP servers are not required to respond to every DHCPDISCOVER
DHCPREQUEST message they receive. For example, a
administrator, to retain stringent control over the hosts attached
the network, may choose to configure DHCP servers to respond only
hosts that have been previously registered through some
mechanism. The DHCP specification describes only the
between clients and servers when the clients and servers choose
interact; it is beyond the scope of the DHCP specification
describe all of the administrative controls that
administrators might want to use. Specific DHCP
implementations may incorporate any controls or policies desired by
network administrator
In some environments, a DHCP server will have to consider the
of the 'chaddr' field and/or the 'class-identifier' option
in the DHCPDISCOVER or DHCPREQUEST messages when determining
correct parameters for a particular client. For example,
organization might have a separate bootstrap server for each type
client it uses, requiring the DHCP server to examine the 'class
identifier' to determine which bootstrap server address to return
the 'siaddr' field of a DHCPOFFER or DHCPACK message
A DHCP server must use some unique identifier to associate a
with its lease. The client may choose to explicitly provide
identifier through the 'client identifier' option. If the
does not provide a 'client identifier' option, the server MSUT
the contents of the 'chaddr' field to identify the client
DHCP clients are free to use any strategy in selecting a DHCP
among those from which the client receives a DHCPOFFER message.
client implementation of DHCP should provide a mechanism for the
to select directly the 'class-identifier' value
Droms [Page 23]
RFC 1531 Dynamic Host Configuration Protocol October 1993
4.3 DHCP server
A DHCP server processes incoming DHCP messages from a client based
the current state of the binding for that client. A DHCP server
receive the following messages from a client
o
o
o
o
Table 3 gives the use of the fields and options in a DHCP message
a server. The remainder of this section describes the action of
DHCP server for each possible incoming message
4.3.1 DHCPDISCOVER
When a server receives a DHCPDISCOVER message from a client,
server chooses a network address for the requesting client. If
address is available, the server may choose to report the problem
the system administrator and may choose to reply to the client with
DHCPNAK message. If the server chooses to respond to the client,
may include an error message in the 'message' option. If an
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
not already allocated,
o The address requested in the 'Requested IP Address' option, if
address is valid and not already allocated,
o A new address allocated from the server's pool of
addresses
Droms [Page 24]
RFC 1531 Dynamic Host Configuration Protocol October 1993
Field DHCPOFFER DHCPACK
----- --------- ------- -------
'op' 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
DHCPDISCOVER DHCPREQUEST
message message
'secs' 0 0 0
'ciaddr' 0 'ciaddr' from 'ciaddr'
DHCPREQUEST or 0 DHCPREQUEST or 0
'yiaddr' IP address offered IP address 0
to client assigned to
'siaddr' IP address of next IP address of next 0
bootstrap server bootstrap
'flags' if 'giaddr' is not 0 then 'flags' from client message else 0
'giaddr' 0 0 0
'chaddr' 'chaddr' from 'chaddr' from 'chaddr'
client client DHCPREQUEST client
DHCPDISCOVER message
'sname' Server host name Server host name (unused
or options or
'file' Client boot file Client boot file (unused
name or options name or
'options' options
Option DHCPOFFER DHCPACK
------ --------- ------- -------
Requested IP address MUST NOT MUST NOT MUST
IP address lease time MUST MUST MUST
Use 'file'/'sname' MAY MAY MUST
DHCP message type DHCPOFFER DHCPACK
Parameter request list MUST NOT MUST NOT MUST
Message SHOULD SHOULD
Client identifier MUST NOT MUST NOT MUST
Class identifier MUST NOT MUST NOT MUST
Server identifier MUST MAY
Maximum message size MUST NOT MUST NOT MUST
All others MAY MAY MUST
Table 3: Fields and options used by DHCP
Droms [Page 25]
RFC 1531 Dynamic Host Configuration Protocol October 1993
As described in section 4.2, a server MAY, for
reasons, assign an address other than the one requested, or
refuse to allocate an address to a particular client even though
addresses are available
While not required for correct operation of DHCP, the server
not reuse the selected network address before the client responds
the server's DHCPOFFER message. The server may choose to record
address as offered to the client
The server must also choose an expiration time for the lease,
follows
o IF the client has not requested a specific lease in
DHCPDISCOVER message and the client already has an assigned
address, the server returns the lease expiration time
assigned to that address (note that the client must
request a specific lease to extend the expiration time on
previously assigned address),
o IF the client has not requested a specific lease in
DHCPDISCOVER message and the client does not have an
network address, the server assigns a locally configured
lease time,
o IF the client has requested a specific lease in the
message (regardless of whether the client has an assigned
address), the server may choose either to return the
lease (if the lease is acceptable to local policy) or
another lease
Once the network address and lease have been determined, the
constructs a DHCPOFFER message with the offered
parameters. It is important for all DHCP servers to return the
parameters (with the possible exception of a newly allocated
address) to ensure predictable host behavior regardless of the
server the client selects. The configuration parameters MUST
selected by applying the following rules in the order given below
The network administrator is responsible for configuring
DHCP servers to ensure uniform responses from those servers.
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
earlier in this section, and the subnet mask for the network
which the client is connected
o The expiration time for the client's lease, as determined by
rules given earlier in this section
o Parameters requested by the client, according to the
rules
-- IF the server has been explicitly configured with a
value for the parameter, the server MUST include that
in an appropriate option in the 'option' field,
-- IF the server recognizes the parameter as a
defined in the Host Requirements Document, the server
include the default value for that parameter as given in
Host Requirements Document in an appropriate option in
'option' field,
-- The server MUST NOT return a value for that parameter
o Any parameters from the existing binding that differ from the
Requirements documents defaults
o Any parameters specific to this client (as identified
the contents of 'chaddr' in the DHCPDISCOVER or
message), e.g., as configured by the network administrator
o Any parameters specific to this client's class (as
by the contents of the 'class identifier' option in
DHCPDISCOVER or DHCPREQUEST message), e.g., as configured
the network administrator; the parameters MUST be
by an exact match between the client's 'client class' and
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
the 'xid' field of the DHCPOFFER message and sends the
message to the requesting client
4.3.2 DHCPREQUEST
A DHCPREQUEST message may come from a client responding to
DHCPOFFER message from a server, or from a client verifying
previously allocated IP address. If the DHCPREQUEST message
a 'server identifier' option, the message is in response to
Droms [Page 27]
RFC 1531 Dynamic Host Configuration Protocol October 1993
DHCPOFFER message. Otherwise, the message is a request to renew
extend an existing lease
Consider first the case of a DHCPREQUEST message in response to
DHCPOFFER message. If the server is identified in the '
identifier' option in the DHCPREQUEST message, the server checks
confirm that the requested parameters are acceptable. Usually, <