最新dhcp协议RFC文档
温柔似野鬼°
986次浏览
2020年07月30日 17:16
最佳经验
本文由作者推荐
小题大做的意思-顽固不化
Request for Comments: 2131 Bucknell University
Obsoletes: 1541 March 1997
Category: Standards Track
Dynamic Host Configuration Protocol
Status of this memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a TCPIP network.
DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the
capability of automatic allocation of reusable network addresses and
additional configuration options [19]. DHCP captures the behavior of
BOOTP relay agents [7, 21], and DHCP participants can interoperate
with BOOTP participants [9].
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 3
1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Problem definition and issues . . . . . . . . . . . . . . . . 4
1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Configuration parameters repository . . . . . . . . . . . . . 11
2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12
3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13
3.1 Client-server interaction - allocating a network address. . . 13
3.2 Client-server interaction - reusing a previously allocated
network address . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Interpretation and representation of time values. . . . . . . 20
3.4 Obtaining parameters with externally configured network
address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21
3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22
3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22
4. Specification of the DHCP client-server protocol. . . . . . . 22
Droms Standards Track [Page 1]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22
4.2 DHCP server administrative controls . . . . . . . . . . . . . 25
4.3 DHCP server behavior. . . . . .
. . . . . . . . . . . . . . . 26
4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 34
5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .42
6. References . . . . . . . . . . . . . . . . . . . . . . . . . .42
7. Security Considerations. . . . . . . . . . . . . . . . . . . .43
8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .44
A. Host Configuration Parameters . . . . . . . . . . . . . . . .45
List of Figures
1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9
2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11
3. Timeline diagram of messages exchanged between DHCP client and
servers when allocating a new network address. . . . . . . . . 15
4. Timeline diagram of messages exchanged between DHCP client and
servers when reusing a previously allocated network address. . 18
5. State-transition diagram for DHCP clients. . . . . . . . . . . 34
List of Tables
1. Description of fields in a DHCP message. . . . . . . . . . . . 10
2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Fields and options used by DHCP servers. . . . . . . . . . . . 28
4. Client messages from various states. . . . . . . . . . . . . . 33
5. Fields and options used by DHCP clients. . . . . . . . . . . . 37
1. Introduction
The Dynamic Host Configuration Protocol (DHCP) provides configuration
parameters to Internet hosts. DHCP consists of two components: a
protocol for delivering host-specific configuration parameters from a
DHCP server to a host and a mechanism for allocation of network
addresses to hosts.
DHCP is built on a client-server model, where designated DHCP server
hosts allocate network addresses and deliver configuration parameters
to dynamically configured hosts. Throughout the remainder of this
document, the term "server" refers to a host providing initialization
parameters through DHCP, and the term "client" refers to a host
requesting initialization parameters from a DHCP server.
A host should not act as a DHCP server unless explicitly configured
to do so by a system administrator. The diversity of hardware and
protocol implementations in the Internet would preclude reliable
operation if random hosts were allowed to respond to DHCP requests.
For example, IP requires the setting of many parameters within the
protocol implementation software. Because IP can be used on many
dissimilar kinds of network hardware, values for those parameters
cannot be guessed or assumed to have correct defaults. Also,
distributed address allocation schemes depend on a polling/defense
Droms Standards Track [Page 2]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
mechanism for discovery of addresses that are already in use. IP
hosts may not always be able to defend their network addr
esses, so
that such a distributed address allocation scheme cannot be
guaranteed to avoid allocation of duplicate network addresses.
DHCP supports three mechanisms for IP address allocation. In
"automatic allocation", DHCP assigns a permanent IP address to a
client. In "dynamic allocation", DHCP assigns an IP address to a
client for a limited period of time (or until the client explicitly
relinquishes the address). In "manual allocation", a client's IP
address is assigned by the network administrator, and DHCP is used
simply to convey the assigned address to the client. A particular
network will use one or more of these mechanisms, depending on the
policies of the network administrator.
Dynamic allocation is the only one of the three mechanisms that
allows automatic reuse of an address that is no longer needed by the
client to which it was assigned. Thus, dynamic allocation is
particularly useful for assigning an address to a client that will be
connected to the network only temporarily or for sharing a limited
pool of IP addresses among a group of clients that do not need
permanent IP addresses. Dynamic allocation may also be a good choice
for assigning an IP address to a new client being permanently
connected to a network where IP addresses are sufficiently scarce
that it is important to reclaim them when old clients are retired.
Manual allocation allows DHCP to be used to eliminate the error-prone
process of manually configuring hosts with IP addresses in
environments where (for whatever reasons) it is desirable to manage
IP address assignment outside of the DHCP mechanisms.
The format of DHCP messages is based on the format of BOOTP messages,
to capture the BOOTP relay agent behavior described as part of the
BOOTP specification [7, 21] and to allow interoperability of existing
BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates
the necessity of having a DHCP server on each physical network
segment.
1.1 Changes to RFC 1541
This document updates the DHCP protocol specification that appears in
RFC1541. A new DHCP message type, DHCPINFORM, has been added; see
section 3.4, 4.3 and 4.4 for details. The classing mechanism for
identifying DHCP clients to DHCP servers has been extended to include
"vendor" classes as defined in sections 4.2 and 4.3. The minimum
lease time restriction has been removed. Finally, many editorial
changes have been made to clarify the text as a result of experience
gained in DHCP interoperability tests.
Droms Standards Track [Page 3]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
1.2 Related Work
There are several Internet protocols and related mechanisms that
address some parts of the dynamic host configuration problem. The
Reverse Address Resolution Protocol (RARP) [10] (through the
exte
nsions defined in the Dynamic RARP (DRARP) [5]) explicitly
addresses the problem of network address discovery, and includes an
automatic IP address assignment mechanism. The Trivial File Transfer
Protocol (TFTP) [20] provides for transport of a boot image from a
boot server. The Internet Control Message Protocol (ICMP) [16]
provides for informing hosts of additional routers via "ICMP
redirect" messages. ICMP also can provide subnet mask information
through the "ICMP mask request" message and other information through
the (obsolete) "ICMP information request" message. Hosts can locate
routers through the ICMP router discovery mechanism [8].
BOOTP is a transport mechanism for a collection of configuration
information. BOOTP is also extensible, and official extensions [17]
have been defined for several configuration parameters. Morgan has
proposed extensions to BOOTP for dynamic IP address assignment [15].
The Network Information Protocol (NIP), used by the Athena project at
MIT, is a distributed mechanism for dynamic IP address assignment
[19]. The Resource Location Protocol RLP [1] provides for location
of higher level services. Sun Microsystems diskless workstations use
a boot procedure that employs RARP, TFTP and an RPC mechanism called
"bootparams" to deliver configuration information and operating
system code to diskless hosts. (Sun Microsystems, Sun Workstation
and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun
networks also use DRARP and an auto-installation mechanism to
automate the configuration of new hosts in an existing network.
In other related work, the path minimum transmission unit (MTU)
discovery algorithm can determine the MTU of an arbitrary internet
path [14]. The Address Resolution Protocol (ARP) has been proposed
as a transport protocol for resource location and selection [6].
Finally, the Host Requirements RFCs [3, 4] mention specific
requirements for host reconfiguration and suggest a scenario for
initial configuration of diskless hosts.
1.3 Problem definition and issues
DHCP is designed to supply DHCP clients with the configuration
parameters defined in the Host Requirements RFCs. After obtaining
parameters via DHCP, a DHCP client should be able to exchange packets
with any other host in the Internet. The TCP/IP stack parameters
supplied by DHCP are listed in Appendix A.
Droms Standards Track [Page 4]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
Not all of these parameters are required for a newly initialized
client. A client and server may negotiate for the transmission of
only those parameters required by the client or specific to a
particular subnet.
DHCP allows but does not require the configuration of client
parameters not directly related to the IP protocol. DHCP also does
not address re
gistration of newly configured clients with the Domain
Name System (DNS) [12, 13].
DHCP is not intended for use in configuring routers.
1.4 Requirements
Throughout this document, the words that are used to define the
significance of particular requirements are capitalized. These words
are:
o "MUST"
This word or the adjective "REQUIRED" means that the
item is an absolute requirement of this specification.
o "MUST NOT"
This phrase means that the item is an absolute prohibition
of this specification.
o "SHOULD"
This word or the adjective "RECOMMENDED" means that there
may exist valid reasons in particular circumstances to ignore
this item, but the full implications should be understood and
the case carefully weighed before choosing a different course.
o "SHOULD NOT"
This phrase means that there may exist valid reasons in
particular circumstances when the listed behavior is acceptable
or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior
described with this label.
Droms Standards Track [Page 5]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
o "MAY"
This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit the
same item.
1.5 Terminology
This document uses the following terms:
o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain
configuration parameters such as a network address.
o "DHCP server"
A DHCP server is an Internet host that returns configuration
parameters to DHCP clients.
o "BOOTP relay agent"
A BOOTP relay agent or relay agent is an Internet host or router
that passes DHCP messages between DHCP clients and DHCP servers.
DHCP is designed to use the same relay agent behavior as specified
in the BOOTP protocol specification.
o "binding"
A binding is a collection of configuration parameters, including
at least an IP address, associated with or "bound to" a DHCP
client. Bindings are managed by DHCP servers.
1.6 Design goals
The following list gives general design goals for DHCP.
o DHCP should be a mechanism rather than a policy. DHCP must
allow local system administrators control over configuration
parameters where desired; e.g., local system administrators
should be able to enforce local policies concerning allocation
and access to local resources where desired.
Droms Standards Track [Page 6]
x0c
RFC 2131
ers in parentheses
indicate the size of each field in octets. The names for the fields
given in the figure will be used throughout this document to refer to
the fields in DHCP messages.
There are two primary differences between DHCP and BOOTP. First,
DHCP defines mechanisms through which clients can be assigned a
network address for a finite lease, allowing for serial reassignment
of network addresses to different clients. Second, DHCP provides the
mechanism for a client to acquire all of the IP configuration
parameters that it needs in order to operate.
DHCP introduces a small change in terminology intended to clarify the
meaning of one of the fields. What was the "vendor extensions" field
in BOOTP has been re-named the "options" field in DHCP. Similarly,
the tagged data items that were used inside the BOOTP "vendor
extensions" field, which were formerly referred to as "vendor
extensions," are now termed simply "options."
Droms Standards Track [Page 8]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| op (1) | htype (1) | hlen (1) | hops (1) |
+---------------+---------------+---------------+---------------+
| xid (4) |
+-------------------------------+-------------------------------+
| secs (2) | flags (2) |
+-------------------------------+-------------------------------+
| ciaddr (4) |
+---------------------------------------------------------------+
| yiaddr (4) |
+---------------------------------------------------------------+
| siaddr (4) |
+---------------------------------------------------------------+
| giaddr (4) |
+---------------------------------------------------------------+
| |
| chaddr (16) |
| |
| |
+---------------------------------------------------------------+
| |
| sname (64) |
+---------------------------------------------------------------+
| |
| file (128)
|
+---------------------------------------------------------------+
| |
| options (variable) |
+---------------------------------------------------------------+
Figure 1: Format of a DHCP message
DHCP defines a new 'client identifier' option that is used to pass an
explicit client identifier to a DHCP server. This change eliminates
the overloading of the 'chaddr' field in BOOTP messages, where
'chaddr' is used both as a hardware address for transmission of BOOTP
reply messages and as a client identifier. The 'client identifier'
is an opaque key, not to be interpreted by the server; for example,
the 'client identifier' may contain a hardware address, identical to
the contents of the 'chaddr' field, or it may contain another type of
identifier, such as a DNS name. The 'client identifier' chosen by a
DHCP client MUST be unique to that client within the subnet to which
the client is attached. If the client uses a 'client identifier' in
one message, it MUST use that same identifier in all subsequent
messages, to ensure that all servers correctly identify the client.
Droms Standards Track [Page 9]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
DHCP clarifies the interpretation of the 'siaddr' field as the
address of the server to use in the next step of the client's
bootstrap process. A DHCP server may return its own address in the
'siaddr' field, if the server is prepared to supply the next
bootstrap service (e.g., delivery of an operating system executable
image). A DHCP server always returns its own address in the 'server
identifier' option.
FIELD OCTETS DESCRIPTION
----- ------ -----------
op 1 Message op code / message type.
1 = BOOTREQUEST, 2 = BOOTREPLY
htype 1 Hardware address type, see ARP section in "Assigned
Numbers" RFC; e.g., '1' = 10mb ethernet.
hlen 1 Hardware address length (e.g. '6' for 10mb
ethernet).
hops 1 Client sets to zero, optionally used by relay agents
when booting via a relay agent.
xid 4 Transaction ID, a random number chosen by the
client, used by the client and server to associate
messages and responses between a client and a
server.
secs 2 Filled in by client, seconds elapsed since client
began address acquisition or renewal process.
flags 2 Flags (see figure 2).
ciaddr 4 Client IP address; only filled in if client is in
BOUND, RENEW or REBINDING state and can respond
to ARP requests.
yiaddr 4 'y
our' (client) IP address.
siaddr 4 IP address of next server to use in bootstrap;
returned in DHCPOFFER, DHCPACK by server.
giaddr 4 Relay agent IP address, used in booting via a
relay agent.
chaddr 16 Client hardware address.
sname 64 Optional server host name, null terminated string.
file 128 Boot file name, null terminated string; "generic"
name or null in DHCPDISCOVER, fully qualified
directory-path name in DHCPOFFER.
options var Optional parameters field. See the options
documents for a list of defined options.
Table 1: Description of fields in a DHCP message
The 'options' field is now variable length. A DHCP client must be
prepared to receive DHCP messages with an 'options' field of at least
length 312 octets. This requirement implies that a DHCP client must
be prepared to receive a message of up to 576 octets, the minimum IP
Droms Standards Track [Page 10]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
datagram size an IP host must be prepared to accept [3]. DHCP
clients may negotiate the use of larger DHCP messages through the
'maximum DHCP message size' option. The options field may be further
extended into the 'file' and 'sname' fields.
In the case of a client using DHCP for initial configuration (before
the client's TCP/IP software has been completely configured), DHCP
requires creative use of the client's TCP/IP software and liberal
interpretation of RFC 1122. The TCP/IP software SHOULD accept and
forward to the IP layer any IP packets delivered to the client's
hardware address before the IP address is configured; DHCP servers
and BOOTP relay agents may not be able to deliver DHCP messages to
clients that cannot accept hardware unicast datagrams before the
TCP/IP software is configured.
To work around some clients that cannot accept IP unicast datagrams
before the TCP/IP software is configured as discussed in the previous
paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is
defined as the BROADCAST (B) flag. The semantics of this flag are
discussed in section 4.1 of this document. The remaining bits of the
flags field are reserved for future use. They MUST be set to zero by
clients and ignored by servers and relay agents. Figure 2 gives the
format of the 'flags' field.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B: BROADCAST flag
MBZ: MUST BE ZERO (reserved for future use)
Figure 2: Format of the 'flags' field
2.1 Configuration parameters
repository
The first service provided by DHCP is to provide persistent storage
of network parameters for network clients. The model of DHCP
persistent storage is that the DHCP service stores a key-value entry
for each client, where the key is some unique identifier (for
example, an IP subnet number and a unique identifier within the
subnet) and the value contains the configuration parameters for the
client.
For example, the key might be the pair (IP-subnet-number, hardware-
address) (note that the "hardware-address" should be typed by the
Droms Standards Track [Page 11]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
type of hardware to accommodate possible duplication of hardware
addresses resulting from bit-ordering problems in a mixed-media,
bridged network) allowing for serial or concurrent reuse of a
hardware address on different subnets, and for hardware addresses
that may not be globally unique. Alternately, the key might be the
pair (IP-subnet-number, hostname), allowing the server to assign
parameters intelligently to a DHCP client that has been moved to a
different subnet or has changed hardware addresses (perhaps because
the network interface failed and was replaced). The protocol defines
that the key will be (IP-subnet-number, hardware-address) unless the
client explicitly supplies an identifier using the 'client
identifier' option. A client can query the DHCP service to
retrieve its configuration parameters. The client interface to the
configuration parameters repository consists of protocol messages to
request configuration parameters and responses from the server
carrying the configuration parameters.
2.2 Dynamic allocation of network addresses
The second service provided by DHCP is the allocation of temporary or
permanent network (IP) addresses to clients. The basic mechanism for
the dynamic allocation of network addresses is simple: a client
requests the use of an address for some period of time. The
allocation mechanism (the collection of DHCP servers) guarantees not
to reallocate that address within the requested time and attempts to
return the same network address each time the client requests an
address. In this document, the period over which a network address
is allocated to a client is referred to as a "lease" [11]. The
client may extend its lease with subsequent requests. The client may
issue a message to release the address back to the server when the
client no longer needs the address. The client may ask for a
permanent assignment by asking for an infinite lease. Even when
assigning "permanent" addresses, a server may choose to give out
lengthy but non-infinite leases to allow detection of the fact that
the client has been retired.
In some environments it will be necessary to reassign network
addr
esses due to exhaustion of available addresses. In such
environments, the allocation mechanism will reuse addresses whose
lease has expired. The server should use whatever information is
available in the configuration information repository to choose an
address to reuse. For example, the server may choose the least
recently assigned address. As a consistency check, the allocating
server SHOULD probe the reused address before allocating the address,
e.g., with an ICMP echo request, and the client SHOULD probe the
newly received address, e.g., with ARP.
Droms Standards Track [Page 12]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
3. The Client-Server Protocol
DHCP uses the BOOTP message format defined in RFC 951 and given in
table 1 and figure 1. The 'op' field of each DHCP message sent from
a client to a server contains BOOTREQUEST. BOOTREPLY is used in the
'op' field of each DHCP message sent from a server to a client.
The first four octets of the 'options' field of the DHCP message
contain the (decimal) values 99, 130, 83 and 99, respectively (this
is the same magic cookie as is defined in RFC 1497 [17]). The
remainder of the 'options' field consists of a list of tagged
parameters that are called "options". All of the "vendor extensions"
listed in RFC 1497 are also DHCP options. RFC 1533 gives the
complete set of options defined for use with DHCP.
Several options have been defined so far. One particular option -
the "DHCP message type" option - must be included in every DHCP
message. This option defines the "type" of the DHCP message.
Additional options may be allowed, required, or not allowed,
depending on the DHCP message type.
Throughout this document, DHCP messages that include a 'DHCP message
type' option will be referred to by the type of the message; e.g., a
DHCP message with 'DHCP message type' option type 1 will be referred
to as a "DHCPDISCOVER" message.
3.1 Client-server interaction - allocating a network address
The following summary of the protocol exchanges between clients and
servers refers to the DHCP messages described in table 2. The
timeline diagram in figure 3 shows the timing relationships in a
typical client-server interaction. If the client already knows its
address, some steps may be omitted; this abbreviated interaction is
described in section 3.2.
1. The client broadcasts a DHCPDISCOVER message on its local physical
subnet. The DHCPDISCOVER message MAY include options that suggest
values for the network address and lease duration. BOOTP relay
agents may pass the message on to DHCP servers not on the same
physical subnet.
2. Each server may respond with a DHCPOFFER message that includes an
available network address in the 'yiaddr' field (and other
configuration parameters in DHCP op
NIT state in the DHCP state diagram, which is
described in section 4.4.
If the client receives a DHCPNAK message, it cannot reuse its
remembered network address. It must instead request a new
address by restarting the configuration process, this time
using the (non-abbreviated) procedure described in section
3.1. This action also corresponds to the client moving to
the INIT state in the DHCP state diagram.
The client times out and retransmits the DHCPREQUEST message if
the client receives neither a DHCPACK nor a DHCPNAK message. The
client retransmits the DHCPREQUEST according to the retransmission
algorithm in section 4.1. The client should choose to retransmit
the DHCPREQUEST enough times to give adequate probability of
contacting the server without causing the client (and the user of
that client) to wait overly long before giving up; e.g., a client
retransmitting as described in section 4.1 might retransmit the
Droms Standards Track [Page 19]
x0c
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 client
receives neither a DHCPACK or a DHCPNAK message after employing
the retransmission algorithm, the client MAY choose to use the
previously allocated network address and configuration parameters
for the remainder of the unexpired lease. This corresponds to
moving to BOUND state in the client state transition diagram shown
in figure 5.
4. The client may choose to relinquish its lease on a network
address by sending a DHCPRELEASE message to the server. The
client identifies the lease to be released with its
'client identifierrequested by tag number.
In addition, the client may suggest values for the network address
and lease time in the DHCPDISCOVER message. The client may include
the 'requested IP address' option to suggest that a particular IP
address be assigned, and may include the 'IP address lease time'
option to suggest the lease time it would like. Other options
representing "hints" at configuration parameters are allowed in a
DHCPDISCOVER or DHCPREQUEST message. However, additional options may
Droms Standards Track [Page 21]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
be ignored by servers, and multiple servers may, therefore, not
return identical values for some options. The 'requested IP address'
option is to be filled in only in a DHCPREQUEST message when the
client is verifying network parameters obtained previously. The
client fills in the 'ciaddr' field only when correctly configured
with an IP address in BOUND, RENEWING or REBINDING state.
If a server receives a DHCPREQUEST message with an invalid 'requested
IP addressfic lease in the DHCPDISCOVER
message (regardless of whether the client has an assigned network
address), the server may choose either to return the requested
lease (if the lease is acceptable to local policy) or select
another lease.
Field DHCPOFFER DHCPACK DHCPNAK
----- --------- ------- -------
'op' BOOTREPLY BOOTREPLY BOOTREPLY
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' 'xid' from client 'xid' from client 'xid' from client
DHCPDISCOVER DHCPREQUEST DHCPREQUEST
message message message
'secs' 0 0 0
'ciaddr' 0 'ciaddr' from 0
DHCPREQUEST or 0
'yiaddr' IP address offered IP address 0
to client assigned to client
'siaddr' IP address of next IP address of next 0
bootstrap server bootstrap server
'flags' 'flags' from 'flags' from 'flags' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'giaddr' 'giaddr' from 'giaddr' from 'giaddr' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'sname' Server host name Server host name (unused)
or options or options
'file' Client boot file Client boot file (unused)
name or options name or options
'options' options options
Droms Standards Track [Page 28]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
Option DHCPOFFER DHCPACK DHCPNAK
------ --------- ------- -------
Requested IP address MUST NOT MUST NOT MUST NOT
IP address lease time MUST MUST (DHCPREQUEST) MUST NOT
MUST NOT (DHCPINFORM)
Use 'file'/'sname' fields MAY MAY MUST NOT
DHCP message type DHCPOFFER DHCPACK DHCPNAK
Parameter request list MUST NOT MUST NOT MUST NOT
Message SHOULD SHOULD SHOULD
Client identifier MUST NOT MUST NOT MAY
Vendor class identifier MAY MAY MAY
Server identifier MUST MUST MUST
Maximum message size MUST NOT MUST NOT MUST NOT
All others
FFER message to assist the
client in selecting which DHCPOFFER to accept. The server inserts
the 'xid' field from the DHCPDISCOVER message into the 'xid' field of
the DHCPOFFER message and sends the DHCPOFFER message to the
requesting client.
4.3.2 DHCPREQUEST message
A DHCPREQUEST message may come from a client responding to a
DHCPOFFER message from a server, from a client verifying a previously
allocated IP address or from a client extending the lease on a
network address. If the DHCPREQUEST message contains a 'server
identifier' option, the message is in response to a DHCPOFFER
message. Otherwise, the message is a request to verify or extend an
existing lease. If the client uses a 'client identifier' in a
DHCPREQUEST message, it MUST use that same 'client identifier' in all
subsequent messages. If the client included a list of requested
parameters in a DHCPDISCOVER message, it MUST include that list in
all subsequent messages.
Droms Standards Track [Page 30]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
Any configuration parameters in the DHCPACK message SHOULD NOT
conflict with those in the earlier DHCPOFFER message to which the
client is responding. The client SHOULD use the parameters in the
DHCPACK message for configuration.
Clients send DHCPREQUEST messages as follows:
o DHCPREQUEST generated during SELECTING state:
Client inserts the address of the selected server in 'server
identifierrocess.
Table 5 gives the use of the fields and options in a DHCP message by
a client. The remainder of this section describes the action of the
DHCP client for each possible incoming message. The description in
the following section corresponds to the full configuration procedure
previously described in section 3.1, and the text in the subsequent
section corresponds to the abbreviated configuration procedure
described in section 3.2.
Droms Standards Track [Page 34]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
-------- -------
| | +-------------------------->| |<-------------------+
| INIT- | | +-------------------->| INIT | |
| REBOOT |DHCPNAK/ +---------->| |<---+ |
| |Restart| | ------- | |
-------- | DHCPNAK/ | | |
| Discard offer | -/Send DHCPDISCOVER |
-/Send DHCPREQUEST | | |
| | | DHCPACK v | |
----------- | (not accept.)/ ----------- | |
| | | Send DHCPDECLINE | | |
| REBOOTING | | | | SELECTING |<----+ |
| | | / | | |DHCPOFFER/ |
----------- | / ----------- | |Collect |
| | / | | | replies |
DHCPACK/ | / +----------------+ +-------+ |
Record lease, set| | v Select offer/ |
timers T1, T2 ------------ send DHCPREQUEST | |
| +----->| | DHCPNAK, Lease expired/ |
| | | REQUESTING | Halt network |
DHCPOFFER/ | | | |
Discard ------------ | |
| | | | ----------- |
| +--------+ DHCPACK/ | | |
| Record lease, set -----| REBINDING | |
| timers T1, T2 / | | |
| | DHCPACK/ ----------- |
| v Record lease, set ^ |
+----------------> ------- /timers T1,T2 | |
+----->| |<---+ | |
| | BOUND |<---+ | |
DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/
DHCPNAK/Discard ------- | Broadcast Halt network
| | | | DHCPREQUEST
DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPINFORM DHCPRELEASE
----- ------------ ----------- -----------
'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' selected by client 'xid' from server selected by
DHCPOFFER message client
'secs' 0 or seconds since 0 or seconds since 0
DHCP process started DHCP process started
'flags' Set 'BROADCAST' Set 'BROADCAST' 0
flag if client flag if client
requires broadcast requires broadcast
reply reply
'ciaddr' 0 (DHCPDISCOVER) 0 or client's 0 (DHCPDECLINE)
client's network address client's network
network address (BOUND/RENEW/REBIND) address
(DHCPINFORM) (DHCPRELEASE)
'yiaddr' 0 0 0
'siaddr' 0 0 0
'giaddr' 0 0 0
'chaddr' client's hardware client's hardware client's hardware
address address address
'sname' options, if options, if (unused)
indicated in indicated in
'sname/file' 'sname/file'
option; otherwise option; otherwise
unused unused
'file' options, if options, if (unused)
indicated in indicated in
'sname/file' 'sname/file'
option; otherwise option; otherwise
unused unused
'options' options options (unused)
Droms Standards Track [Page 37]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPINFORM DHCPRELEASE
------ ------------ ----------- -----------
Requested IP address MAY MUST (in MUST
(DISCOVER) SELECTING or (DHCPDECLINE),
MUST NOT INIT-REBOOT) MUST NOT
(INFORM) MUST NOT (in (DHCPRELEASE)
BOUND or
RENEWING)
IP address lease time MAY MAY MUST NOT
(DISCOVER)
MUST NOT
(INFORM)
Use 'file'/'sname' fields MAY MAY MAY
DHCP message type
ime at which the client enters the RENEWING state and
attempts to contact the server that originally issued the client's
network address. T2 is the time at which the client enters the
REBINDING state and attempts to contact any server. T1 MUST be
earlier than T2, which, in turn, MUST be earlier than the time at
which the client's lease will expire.
To avoid the need for synchronized clocks, T1 and T2 are expressed in
options as relative times [2].
At time T1 the client moves to RENEWING state and sends (via unicast)
a DHCPREQUEST message to the server to extend its lease. The client
sets the 'ciaddr' field in the DHCPREQUEST to its current network
address. The client records the local time at which the DHCPREQUEST
message is sent for computation of the lease expiration time. The
client MUST NOT include a 'server identifier' in the DHCPREQUEST
message.
Any DHCPACK messages that arrive with an 'xid' that does not match
the 'xid' of the client's DHCPREQUEST message are silently discarded.
When the client receives a DHCPACK from the server, the client
computes the lease expiration time as the sum of the time at which
the client sent the DHCPREQUEST message and the duration of the lease
in the DHCPACK message. The client has successfully reacquired its
network address, returns to BOUND state and may continue network
processing.
Droms Standards Track [Page 40]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
If no DHCPACK arrives before time T2, the client moves to REBINDING
state and sends (via broadcast) a DHCPREQUEST message to extend its
lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its
current network address. The client MUST NOT include a 'server
identifier' in the DHCPREQUEST message.
Times T1 and T2 are configurable by the server through options. T1
defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 *
duration_of_lease). Times T1 and T2 SHOULD be chosen with some
random "fuzz" around a fixed value, to avoid synchronization of
client reacquisition.
A client MAY choose to renew or extend its lease prior to T1. The
server MAY choose to extend the client's lease according to policy
set by the network administrator. The server SHOULD return T1 and
T2, and their values SHOULD be adjusted from their original values to
take account of the time remaining on the lease.
In both RENEWING and REBINDING states, if the client receives no
response to its DHCPREQUEST message, the client SHOULD wait one-half
of the remaining time until T2 (in RENEWING state) and one-half of
the remaining lease time (in REBINDING state), down to a minimum of
60 seconds, before retransmitting the DHCPREQUEST message.
If the lease expires before the client receives a DHCPACK, the client
moves to INIT state, MUST immediately stop any oth
er network
processing and requests network initialization parameters as if the
client were uninitialized. If the client then receives a DHCPACK
allocating that client its previous network address, the client
SHOULD continue network processing. If the client is given a new
network address, it MUST NOT continue using the previous network
address and SHOULD notify the local users of the problem.
4.4.6 DHCPRELEASE
If the client no longer requires use of its assigned network address
(e.g., the client is gracefully shut down), the client sends a
DHCPRELEASE message to the server. Note that the correct operation
of DHCP does not depend on the transmission of DHCPRELEASE messages.
Droms Standards Track [Page 41]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
5. Acknowledgments
The author thanks the many (and too numerous to mention!) members of
the DHC WG for their tireless and ongoing efforts in the development
of DHCP and this document.
The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
Mendonca in organizing DHCP interoperability testing sessions are
gratefully acknowledged.
The development of this document was supported in part by grants from
the Corporation for National Research Initiatives (CNRI), Bucknell
University and Sun Microsystems.
6. References
[1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December
1983.
[2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
University, October 1993.
[3] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, USC/Information Sciences
Institute, October 1989.
[4] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support, STD 3, RFC 1123, USC/Information
Sciences Institute, October 1989.
[5] Brownell, D, "Dynamic Reverse Address Resolution Protocol
(DRARP)", Work in Progress.
[6] Comer, D., and R. Droms, "Uniform Access to Internet Directory
Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
Communications Review), 20(4):50--59, 1990.
[7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
Stanford and SUN Microsystems, September 1985.
[8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
PARC, September 1991.
[9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534,
Bucknell University, October 1993.
Droms Standards Track [Page 42]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
[10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
Address Resolution Protocol", RFC 903, Stanford, June 1984.
[11] Gray C., and D. Cheriton, "Leases: An
Efficient Fault-Tolerant
Mechanism for Distributed File Cache Consistency", In Proc. of
the Twelfth ACM Symposium on Operating Systems Design, 1989.
[12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[13] Mockapetris, P., "Domain Names -- Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached
Hosts", Work in Progress.
[16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
USC/Information Sciences Institute, September 1981.
[17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
USC/Information Sciences Institute, August 1993.
[18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
USC/Information Sciences Institute, October 1994.
[19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic
Assignment of IP Addresses for use on an Ethernet. (Available
from the Athena Project, MIT), 1989.
[20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC,
June 1981.
[21] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, Carnegie Mellon University, October 1993.
7. Security Considerations
DHCP is built directly on UDP and IP which are as yet inherently
insecure. Furthermore, DHCP is generally intended to make
maintenance of remote and/or diskless hosts easier. While perhaps
not impossible, configuring such hosts with passwords or keys may be
difficult and inconvenient. Therefore, DHCP in its current form is
quite insecure.
Droms Standards Track [Page 43]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
Unauthorized DHCP servers may be easily set up. Such servers can
then send false and potentially disruptive information to clients
such as incorrect or duplicate IP addresses, incorrect routing
information (including spoof routers, etc.), incorrect domain
nameserver addresses (such as spoof nameservers), and so on.
Clearly, once this seed information is in place, an attacker can
further compromise affected systems.
Malicious DHCP clients could masquerade as legitimate clients and
retrieve information intended for those legitimate clients. Where
dynamic allocation of resources is used, a malicious client could
claim all resources for itself, thereby denying resources to
legitimate clients.
8. Author's Address
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone: (717) 524-1145
EMail: droms@
Droms Standards Track [Page 44]
x0c
RFC 2131 Dynamic Host Configuration Protocol March 1997
A. Host Configuration Parameters
IP-layer_parameters,_per_host:_
Be a router on/off HRC 3.1
Non-local source routing on/off HRC 3.3.5
Policy filters for
non-local source routing (list) HRC 3.3.5
Maximum reassembly size integer HRC 3.3.2
Default TTL integer HRC 3.2.1.7
PMTU aging timeout integer MTU 6.6
MTU plateau table (list) MTU 7
IP-layer_parameters,_per_interface:_
IP address (address) HRC 3.3.1.6
Subnet mask (address mask) HRC 3.3.1.6
MTU integer HRC 3.3.3
All-subnets-MTU on/off HRC 3.3.3
Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6
Perform mask discovery on/off HRC 3.2.2.9
Be a mask supplier on/off HRC 3.2.2.9
Perform router discovery on/off RD 5.1
Router solicitation address (address) RD 5.1
Default routers, list of:
router address (address) HRC 3.3.1.6
preference level integer HRC 3.3.1.6
Static routes, list of:
destination (host/subnet/net) HRC 3.3.1.2
destination mask (address mask) HRC 3.3.1.2
type-of-service integer HRC 3.3.1.2
first-hop router (address) HRC 3.3.1.2
ignore redirects on/off HRC 3.3.1.2
PMTU integer MTU 6.6
perform PMTU discovery on/off MTU 6.6
Link-layer_parameters,_per_interface:_
Trailers on/off HRC 2.3.1
ARP cache timeout integer HRC 2.3.2.1
Ethernet encapsulation (RFC 894/RFC 1042) HRC 2.3.3
TCP_parameters,_per_host:_
TTL integer HRC 4.2.2.19
Keep-alive interval integer HRC 4.2.3.6
Keep-alive data size 0/1 HRC 4.2.3.6
Key:
MTU = Path MTU Discovery (RFC 1191, Proposed Standard)
RD = Router Discovery (RFC 1256, Proposed Standard)
Droms Standards Track [Page 45]
x0c