As per Relevance of the word broadcast, we have this rfc below:
Network Working Group R.
Request for Comments: 2131 Bucknell
Obsoletes: 1541 March 1997
Category: Standards
Dynamic Host Configuration
Status of this
This document 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" (STD 1) for the standardization
and status 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 TCPIP 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, 21], and DHCP participants can
with BOOTP participants [9].
Table of
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
network address . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Interpretation and representation of time values. . . . . . . 20
3.4 Obtaining parameters with externally configured
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]
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
1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9
2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11
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. . . . . . . . . . . 34
List of
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.
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
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/
Droms Standards Track [Page 2]
RFC 2131 Dynamic Host Configuration Protocol March 1997
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
client. In "dynamic allocation", DHCP assigns an IP address to
client for a limited period of time (or until the client
relinquishes the address). In "manual allocation", a client's
address is assigned by the network administrator, and DHCP is
simply to convey the assigned address to the client. 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
client to which it was assigned. Thus, dynamic allocation
particularly useful for assigning an address to a client that will
connected to the network only temporarily or for sharing a
pool of IP addresses among a group of clients that do not
permanent IP addresses. Dynamic allocation may also be a good
for assigning an IP address to a new client being
connected to a network where IP addresses are sufficiently
that it is important to reclaim them when old clients are retired
Manual 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, 21] and to allow interoperability of
BOOTP clients with DHCP servers. Using BOOTP relay agents
the necessity of having a DHCP server on each physical
segment
1.1 Changes to RFC 1541
This document updates the DHCP protocol specification that appears
RFC1541. A new DHCP message type, DHCPINFORM, has been added;
section 3.4, 4.3 and 4.4 for details. The classing mechanism
identifying DHCP clients to DHCP servers has been extended to
"vendor" classes as defined in sections 4.2 and 4.3. The
lease time restriction has been removed. Finally, many
changes have been made to clarify the text as a result of
gained in DHCP interoperability tests
Droms Standards Track [Page 3]
RFC 2131 Dynamic Host Configuration Protocol March 1997
1.2 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]. The Address Resolution Protocol (ARP) has been
as a transport protocol for resource location and selection [6].
Finally, the Host Requirements RFCs [3, 4] mention
requirements for host reconfiguration and suggest a scenario
initial configuration of diskless hosts
1.3 Problem definition and
DHCP is designed to supply DHCP clients with the
parameters defined in the Host Requirements RFCs. After
parameters via DHCP, a DHCP client should be able to exchange
with any other host in the Internet. The TCP/IP stack
supplied by DHCP are listed in Appendix A
Droms Standards Track [Page 4]
RFC 2131 Dynamic Host Configuration Protocol March 1997
Not all of these parameters are required for a newly
client. A client and server may negotiate for the transmission
only those parameters required by the client or specific to
particular subnet
DHCP allows but does not require the configuration of
parameters not directly related to the IP protocol. DHCP also
not address registration of newly configured clients with the
Name System (DNS) [12, 13].
DHCP is not intended for use in configuring routers
1.4
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 Standards Track [Page 5]
RFC 2131 Dynamic Host Configuration Protocol March 1997
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.5
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 or relay agent is an Internet host or
that passes DHCP messages between DHCP clients and DHCP servers
DHCP is designed to use the same relay agent behavior as
in 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.6 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 Standards Track [Page 6]
RFC 2131 Dynamic Host Configuration Protocol March 1997
o Clients should require no manual configuration. Each
should be able to discover appropriate local
parameters without user intervention and incorporate
parameters into its own configuration
o Networks should require no manual configuration for
clients. Under normal circumstances, the network
should not have to enter any per-client
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 relay agents
o A DHCP client must be prepared to receive multiple
to a request for configuration parameters. Some
may 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 RFC 1542 [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 DHCP client at a time
o Retain DHCP client configuration across DHCP client reboot.
DHCP client should, whenever possible, be assigned the
configuration parameters (e.g., network address) in
to each request
o Retain DHCP client configuration across server reboots, and
whenever possible, a DHCP client should be assigned the
configuration parameters despite restarts of the DHCP mechanism
o Allow automated assignment of configuration parameters to
clients to avoid hand configuration for new clients
o Support fixed or permanent allocation of
parameters to specific clients
Droms Standards Track [Page 7]
RFC 2131 Dynamic Host Configuration Protocol March 1997
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. RFC 1542 [2] 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 finite 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."
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
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,
'chaddr' is used both as a hardware address for transmission of
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
the contents of the 'chaddr' field, or it may contain another type
identifier, such as a DNS name. The 'client identifier' chosen by
DHCP client MUST be unique to that client within the subnet to
the client is attached. If the client uses a 'client identifier'
one message, it MUST use that same identifier in all
messages, to ensure that all servers correctly identify the client
Droms Standards Track [Page 9]
RFC 2131 Dynamic Host Configuration Protocol March 1997
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
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
began address acquisition or renewal process
flags 2 Flags (see figure 2).
ciaddr 4 Client IP address; only filled in if client is
BOUND, RENEW or REBINDING state and can
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
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 var Optional parameters field. See the
documents for a list of defined options
Table 1: Description of fields in a DHCP
The 'options' field is now variable length. A DHCP client must
prepared to receive DHCP messages with an 'options' field of at
length 312 octets. This requirement implies that a DHCP client
be prepared to receive a message of up to 576 octets, the minimum
Droms Standards Track [Page 10]
RFC 2131 Dynamic Host Configuration Protocol March 1997
datagram size an IP host must be prepared to accept [3].
clients may negotiate the use of larger DHCP messages through
'maximum DHCP message size' option. The options field may be
extended into the 'file' and 'sname' fields
In the case of a client using DHCP for initial configuration (
the client's TCP/IP software has been completely configured),
requires creative use of the client's TCP/IP software and
interpretation of RFC 1122. The TCP/IP software SHOULD accept
forward to the IP layer any IP packets delivered to the client'
hardware address before the IP address is configured; DHCP
and BOOTP relay agents may not be able to deliver DHCP messages
clients that cannot accept hardware unicast datagrams before
TCP/IP software is configured
To work around some clients that cannot accept IP unicast
before the TCP/IP software is configured as discussed in the
paragraph, DHCP uses the 'flags' field [21]. The leftmost bit
defined as the BROADCAST (B) flag. The semantics of this flag
discussed in section 4.1 of this document. The remaining bits of
flags field are reserved for future use. They MUST be set to zero
clients and ignored by servers and relay agents. Figure 2 gives
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
MBZ: MUST BE ZERO (reserved for future use
Figure 2: Format of the 'flags'
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) (note that the "hardware-address" should be typed by
Droms Standards Track [Page 11]
RFC 2131 Dynamic Host Configuration Protocol March 1997
type of hardware to accommodate possible duplication of
addresses resulting from bit-ordering problems in a mixed-media
bridged network) allowing for serial or concurrent reuse of
hardware address on different subnets, and for hardware
that may not be globally unique. Alternately, the key might be
pair (IP-subnet-number, hostname), allowing the server to
parameters intelligently to a DHCP client that has been moved to
different subnet or has changed hardware addresses (perhaps
the network interface failed and was replaced). The protocol
that the key will be (IP-subnet-number, hardware-address) unless
client explicitly supplies an identifier using the '
identifier' option. A client can query the DHCP service
retrieve its configuration parameters. The client interface to
configuration parameters repository consists of protocol messages
request configuration parameters and responses from the
carrying the configuration parameters
2.2 Dynamic allocation of network
The second service provided by DHCP is the allocation of temporary
permanent network (IP) addresses to clients. 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 client 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
server SHOULD probe the reused address before allocating the address
e.g., with an ICMP echo request, and the client SHOULD probe
newly received address, e.g., with ARP
Droms Standards Track [Page 12]
RFC 2131 Dynamic Host Configuration Protocol March 1997
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 (
is the same magic cookie as is defined in RFC 1497 [17]).
remainder of the 'options' field consists of a list of
parameters that are called "options". All of the "vendor extensions
listed in RFC 1497 are also DHCP options. RFC 1533 gives
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
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. When allocating a new address
servers SHOULD check that the offered network address is
Droms Standards Track [Page 13]
RFC 2131 Dynamic Host Configuration Protocol March 1997
already in use; e.g., the server may probe the offered
with an ICMP Echo Request. Servers SHOULD be implemented so
network administrators MAY choose to disable probes of
allocated addresses. The server transmits the DHCPOFFER
to the client, using the BOOTP relay agent if necessary
Message
------- ---
DHCPDISCOVER - Client broadcast to locate available servers
DHCPOFFER - Server to client in response to DHCPDISCOVER
offer of configuration parameters
DHCPREQUEST - Client message to servers either (a)
offered parameters from one server and
declining offers from all others, (b)
correctness of previously allocated address after
e.g., system reboot, or (c) extending the lease on
particular network address
DHCPACK - Server to client with configuration parameters
including committed network address
DHCPNAK - Server to client indicating client's notion of
address is incorrect (e.g., client has moved to
subnet) or client's lease as
DHCPDECLINE - Client to server indicating network address is
in use
DHCPRELEASE - Client to server relinquishing network address
cancelling remaining lease
DHCPINFORM - Client to server, asking only for local
parameters; client already has externally
network address
Table 2: DHCP
Droms Standards Track [Page 14]
RFC 2131 Dynamic Host Configuration Protocol March 1997
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 Standards Track [Page 15]
RFC 2131 Dynamic Host Configuration Protocol March 1997
3. The client receives one or more DHCPOFFER messages from one or
servers. The client may choose to wait for multiple responses
The client chooses one server from which to request
parameters, based on the configuration parameters offered in
DHCPOFFER messages. The client broadcasts a DHCPREQUEST
that MUST include the 'server identifier' option to indicate
server it has selected, and that MAY include other
specifying desired configuration values. The 'requested
address' option MUST be set to the value of 'yiaddr' in
DHCPOFFER message from the server. This DHCPREQUEST message
broadcast and relayed through DHCP/BOOTP relay agents. To
ensure that any BOOTP relay agents forward the DHCPREQUEST
to the same set of DHCP servers that received the
DHCPDISCOVER message, the DHCPREQUEST message MUST use the
value in the DHCP message header's 'secs' field and be sent to
same IP broadcast address as the original DHCPDISCOVER message
The client times out and retransmits the DHCPDISCOVER message
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
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 'client identifier'
'chaddr' and assigned network address constitute a
identifier for the client's lease and are used by both the
and server to identify a lease referred to in any DHCP messages
Any configuration parameters in the DHCPACK message SHOULD
conflict with those in the earlier DHCPOFFER message to which
client is responding. The server SHOULD NOT check the
network address at this point. The 'yiaddr' field in the
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
5. The client receives the DHCPACK message with
parameters. The client SHOULD perform a final check on
parameters (e.g., ARP for allocated network address), and notes
duration of the lease specified in the DHCPACK message. At
Droms Standards Track [Page 16]
RFC 2131 Dynamic Host Configuration Protocol March 1997
point, the client is configured. If the client detects that
address is already in use (e.g., through the use of ARP),
client MUST send a DHCPDECLINE message to the server and
the configuration process. The client SHOULD wait a minimum of
seconds before restarting the configuration process to
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. The client should choose to
the DHCPREQUEST enough times to give adequate probability
contacting the server without causing the client (and the user
that client) to wait overly long before giving up; e.g., a
retransmitting as described in section 4.1 might retransmit
DHCPREQUEST message four times, for a total delay of 60 seconds
before restarting the initialization procedure. If the
receives neither a DHCPACK or a DHCPNAK message after employing
retransmission algorithm, the client reverts to INIT state
restarts the initialization process. The client SHOULD notify
user that the 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 with its 'client identifier',
or 'chaddr' and network address in the DHCPRELEASE message. If
client used a 'client identifier' when it obtained the lease,
MUST use the same 'client identifier' in the DHCPRELEASE message
3.2 Client-server interaction - reusing a previously allocated
If a client remembers and wishes to reuse a previously
network address, a client may choose to omit some of the
described in the previous section. The timeline diagram in figure 4
shows the timing relationships in a typical client-server
for a client reusing a previously allocated network address
Droms Standards Track [Page 17]
RFC 2131 Dynamic Host Configuration Protocol March 1997
1. The client broadcasts a DHCPREQUEST message on its local subnet
The message includes the client's network address in
'requested IP address' option. As the client has not received
network address, it MUST NOT fill in the 'ciaddr' field.
relay agents pass the message on to DHCP servers not on the
subnet. If the client used a 'client identifier' to obtain
address, the client MUST use the same 'client identifier' in
DHCPREQUEST message
2. Servers with knowledge of the client's configuration
respond with a DHCPACK message to the client. Servers SHOULD
check that the client's network address is already in use;
client may respond to ICMP Echo Request messages at this point
Server Client
v v
| | |
| Begins |
| initialization |
| | |
| /|\ |
| _________ __/ | \__________ |
| /DHCPREQU EST | 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
Droms Standards Track [Page 18]
RFC 2131 Dynamic Host Configuration Protocol March 1997
If the client's request is invalid (e.g., the client has
to a new subnet), servers SHOULD respond with a DHCPNAK message
the client. Servers SHOULD NOT respond if their information is
guaranteed to be accurate. For example, a server that identifies
request for an expired binding that is owned by another server
NOT respond with a DHCPNAK unless the servers are using an
mechanism to maintain coherency among the servers
If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is
the same subnet as the server. The server
broadcast the DHCPNAK message to the 0xffffffff broadcast
because the client may not have a correct network address or
mask, and the client may not be answering ARP requests
Otherwise, the server MUST send the DHCPNAK message to the
address of the BOOTP relay agent, as recorded in 'giaddr'.
relay agent will, in turn, forward the message directly to
client's hardware address, so that the DHCPNAK can be delivered
if the client has moved to a new network
3. The client receives the DHCPACK message with
parameters. The client performs a final check on the
(as in section 3.1), and notes the duration of the lease
in the DHCPACK message. The specific lease is implicitly
by the 'client identifier' or 'chaddr' and the network address.
this point, the client is configured
If the client detects that the IP address in the DHCPACK
is already in use, the client MUST send 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.
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.
client retransmits the DHCPREQUEST according to the
algorithm in section 4.1. The client should choose to
the DHCPREQUEST enough times to give adequate probability
contacting the server without causing the client (and the user
that client) to wait overly long before giving up; e.g., a
retransmitting as described in section 4.1 might retransmit
Droms Standards Track [Page 19]
RFC 2131 Dynamic Host Configuration Protocol March 1997
DHCPREQUEST message four times, for a total delay of 60 seconds
before restarting the initialization procedure. If the
receives neither a DHCPACK or a DHCPNAK message after
the retransmission algorithm, the client MAY choose to use
previously allocated network address and configuration
for the remainder of the unexpired lease. This corresponds
moving to BOUND state in the client state transition diagram
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
'client identifier', or 'chaddr' and network address in
DHCPRELEASE message
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".
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 Obtaining parameters with externally configured network
If a client has obtained a network address through some other
(e.g., manual configuration), it may use a DHCPINFORM request
Droms Standards Track [Page 20]
RFC 2131 Dynamic Host Configuration Protocol March 1997
to obtain other local configuration parameters. Servers receiving
DHCPINFORM message construct a DHCPACK message with any
configuration parameters appropriate for the client without
allocating a new address, checking for an existing binding,
in 'yiaddr' or including lease time parameters. The servers
unicast the DHCPACK reply to the address given in the 'ciaddr'
of the DHCPINFORM message
The server SHOULD check the network address in a DHCPINFORM
for consistency, but MUST NOT check for an existing lease.
server forms a DHCPACK message containing the
parameters for the requesting client and sends the DHCPACK
directly to the client
3.5 Client 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
server with a list of specific parameters the client is
in. If the client includes a list of parameters in a
message, it MUST include that list in any subsequent
messages
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 'requested IP address' option to suggest that a particular
address be assigned, and may include the 'IP address lease time
option to suggest the lease time it would like. Other
representing "hints" at configuration parameters are allowed in
DHCPDISCOVER or DHCPREQUEST message. However, additional options
Droms Standards Track [Page 21]
RFC 2131 Dynamic Host Configuration Protocol March 1997
be ignored by servers, and multiple servers may, therefore,
return identical values for some options. The 'requested IP address
option is to be filled in only in a DHCPREQUEST message when
client is verifying network parameters obtained previously.
client fills in the 'ciaddr' field only when correctly
with an IP address in BOUND, RENEWING or REBINDING state
If a server receives a DHCPREQUEST message with an invalid '
IP address', the server SHOULD respond to the client with a
message and may choose to report the problem to the
administrator. The server may include an error message in
'message' option
3.6 Use of DHCP in clients with multiple
A client with multiple network interfaces must use DHCP through
interface independently to obtain configuration
parameters for those separate interfaces
3.7 When clients should use
A client 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 client's or user's knowledge
If a client has knowledge of a previous network address and is
to contact a local DHCP server, the client may continue to use
previous network address until the lease for that address expires
If the lease expires before the client can contact a DHCP server,
client must immediately discontinue use of the previous
address 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
Droms Standards Track [Page 22]
RFC 2131 Dynamic Host Configuration Protocol March 1997
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). A server with multiple network address (e.g., a multi-
host) MAY use any of its network addresses in outgoing DHCP messages
The 'server identifier' field is used both to identify a DHCP
in a DHCP message and as a destination address from clients
servers. A server with multiple network addresses MUST be
to to accept any of its network addresses as identifying that
in a DHCP message. To accommodate potentially incomplete
connectivity, a server MUST choose an address as a '
identifier' that, to the best of the server's knowledge, is
from the client. For example, if the DHCP server and the DHCP
are connected to the same subnet (i.e., the 'giaddr' field in
message from the client is zero), the server SHOULD select the
address the server is using for communication on that subnet as
'server identifier'. If the server is using multiple IP addresses
that subnet, any such address may be used. If the server
received a message through a DHCP relay agent, the server
choose an address from the interface on which the message
recieved as the 'server identifier' (unless the server has other
better information on which to make its choice). DHCP clients
use the IP address provided in the 'server identifier' option for
unicast requests to the DHCP server
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
BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr
field is zero and the 'ciaddr' field is nonzero, then the
unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit
set, then the server broadcasts DHCPOFFER and DHCPACK messages
0xffffffff. If the broadcast bit is not set and 'giaddr' is zero
'ciaddr' is zero, then the server unicasts DHCPOFFER and
messages to the client's hardware address and 'yiaddr' address.
all cases, when 'giaddr' is zero, the server broadcasts any
messages to 0xffffffff
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 RFC 1533. If
Droms Standards Track [Page 23]
RFC 2131 Dynamic Host Configuration Protocol March 1997
'option overload' option is present in the 'options' field,
options in the 'options' field MUST be terminated by an 'end' option
and MAY contain one or more 'pad' options to fill the options field
The options in the 'sname' and 'file' fields (if in use as
by the 'options overload' option) MUST begin with the first octet
the field, MUST be terminated by an 'end' option, and MUST
followed by 'pad' options to fill the remainder of the field.
individual option in the 'options', 'sname' and 'file' fields MUST
entirely contained in that field. The options in the 'options'
MUST be interpreted first, so that any 'option overload' options
be interpreted. The 'file' field MUST be interpreted next (if
'option overload' option indicates that the 'file' field
DHCP options), followed by the 'sname' field
The values to be passed in an 'option' tag may be too long to fit
the 255 octets available to a single option (e.g., a list of
in a 'router' option [21]). Options may appear only once,
otherwise specified in the options document. The client
the values of multiple instances of the same option into a
parameter list for configuration
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 between retransmissions SHOULD
chosen to allow sufficient time for replies from the server to
delivered based on the characteristics of the internetwork
the client and the server. For example, in a 10Mb/sec
internetwork, the delay before the first retransmission SHOULD be 4
seconds randomized by the value of a uniform random number
from the range -1 to +1. Clients with clocks that provide
granularity of less than one second may choose a non-
randomization value. The delay before the next retransmission
be 8 seconds randomized by the value of a uniform number chosen
the range -1 to +1. The retransmission delay SHOULD be doubled
subsequent retransmissions up to a maximum of 64 seconds. The
MAY provide an indication of retransmission attempts to the user
an indication of the progress of the configuration process
The 'xid' field is used by the client to match incoming DHCP
with pending requests. A DHCP client MUST choose 'xid's in such
way as to minimize the chance of using an 'xid' identical to one
by another client. For example, a client may choose a different
random initial 'xid' each time the client is rebooted,
subsequently use sequential 'xid's until the next reboot.
a new 'xid' for each retransmission is an implementation decision.
client may choose to reuse the same 'xid' or select a new 'xid'
each retransmitted message
Droms Standards Track [Page 24]
RFC 2131 Dynamic Host Configuration Protocol March 1997
Normally, DHCP servers and BOOTP relay agents attempt to
DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client
uicast 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
'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 (preferably 0xffffffff
as the IP destination address and the link-layer broadcast address
the link-layer destination address. If the BROADCAST bit is
to 0, the message SHOULD be sent as an IP unicast to the IP
specified in the 'yiaddr' field and the link-layer address
in the 'chaddr' field. If unicasting is not possible, the
MAY be sent as an IP broadcast using an IP broadcast
(preferably 0xffffffff) as the IP destination address and the link
layer broadcast address as the link-layer 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 clients
to the network, may choose to configure DHCP servers to respond
to clients 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
Droms Standards Track [Page 25]
RFC 2131 Dynamic Host Configuration Protocol March 1997
implementations may incorporate any controls or policies desired by
network administrator
In some environments, a DHCP server will have to consider the
of the vendor class options included in DHCPDISCOVER or
messages when determining the correct parameters for a
client
A DHCP server needs to use some unique identifier to associate
client with its lease. The client MAY choose to explicitly
the identifier through the 'client identifier' option. If the
supplies a 'client identifier', the client MUST use the same '
identifier' in all subsequent messages, and the server MUST use
identifier to identify the client. If the client does not provide
'client identifier' option, the server MUST use the contents of
'chaddr' field to identify the client. It is crucial for a
client to use an identifier unique within the subnet to which
client is attached in the 'client identifier' option. Use
'chaddr' as the client's unique identifier may cause
results, as that identifier may be associated with a
interface that could be moved to a new client. Some sites may
to use a manufacturer's serial number as the 'client identifier',
avoid unexpected changes in a clients network address due to
of hardware interfaces among computers. Sites may also choose to
a DNS name as the 'client identifier', causing address leases to
associated with the DNS name rather than a specific hardware box
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 