Network Working Group
Request for Comments: 2131
Obsoletes: 1541
Category: Standards Track
R. Droms
Bucknell University
March 1997
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.
1.1
1.2
1.3
1.4
1.5
1.6
2.
2.1
2.2
3.
3.1
3.2
3.3
3.4
3.5
3.6
3.7
4.
Introduction. . . . . . . . . . . . . . . . . . . . . . . .
Changes to RFC1541. . . . . . . . . . . . . . . . . . . . .
Related Work. . . . . . . . . . . . . . . . . . . . . . . .
Problem definition and issues . . . . . . . . . . . . . . .
Requirements. . . . . . . . . . . . . . . . . . . . . . . .
Terminology . . . . . . . . . . . . . . . . . . . . . . . .
Design goals. . . . . . . . . . . . . . . . . . . . . . . .
Protocol Summary. . . . . . . . . . . . . . . . . . . . . .
Configuration parameters repository . . . . . . . . . . . .
Dynamic allocation of network addresses . . . . . . . . . .
The Client-Server Protocol. . . . . . . . . . . . . . . . .
Client-server interaction - allocating a network address. .
Client-server interaction - reusing a previously allocated
network address . . . . . . . . . . . . . . . . . . . . . .
Interpretation and representation of time values. . . . . .
Obtaining parameters with externally configured network
address . . . . . . . . . . . . . . . . . . . . . . . . . .
Client parameters in DHCP . . . . . . . . . . . . . . . . .
Use of DHCP in clients with multiple interfaces . . . . . .
When clients should use DHCP. . . . . . . . . . . . . . . .
Specification of the DHCP client-server protocol. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
2
3
4
4
5
6
6
8
11
12
13
13
. 17
. 20
.
.
.
.
.
20
21
22
22
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 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]
RFC 2131
Dynamic Host Configuration Protocol
March 1997
mechanism for discovery of addresses that are already in use. IP
hosts may not always be able to defend their network addresses, so
that such a distributed address allocation scheme cannot be
guaranteed to avoid allocation of duplicate network addresses.
DHCP supports three mechanisms for IP address allocation. In
"automatic allocation", DHCP assigns a permanent IP address to a
client. In "dynamic allocation", DHCP assigns an IP address to a
client for a limited period of time (or until the client explicitly
relinquishes the address). In "manual allocation", a client’s IP
address is assigned by the network administrator, and DHCP is used
simply to convey the assigned address to the client. A particular
network will use one or more of these mechanisms, depending on the
policies of the network administrator.
Dynamic allocation is the only one of the three mechanisms that
allows automatic reuse of an address that is no longer needed by the
client to which it was assigned. Thus, dynamic allocation is
particularly useful for assigning an address to a client that will be
connected to the network only temporarily or for sharing a limited
pool of IP addresses among a group of clients that do not need
permanent IP addresses. Dynamic allocation may also be a good choice
for assigning an IP address to a new client being permanently
connected to a network where IP addresses are sufficiently scarce
that it is important to reclaim them when old clients are retired.
Manual allocation allows DHCP to be used to eliminate the error-prone
process of manually configuring hosts with IP addresses in
environments where (for whatever reasons) it is desirable to manage
IP address assignment outside of the DHCP mechanisms.
The format of DHCP messages is based on the format of BOOTP messages,
to capture the BOOTP relay agent behavior described as part of the
BOOTP specification [7, 21] and to allow interoperability of existing
BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates
the necessity of having a DHCP server on each physical network
segment.
1.1 Changes to RFC 1541
This document updates the DHCP protocol specification that appears in
RFC1541. A new DHCP message type, DHCPINFORM, has been added; see
section 3.4, 4.3 and 4.4 for details. The classing mechanism for
identifying DHCP clients to DHCP servers has been extended to include
"vendor" classes as defined in sections 4.2 and 4.3. The minimum
lease time restriction has been removed. Finally, many editorial
changes have been made to clarify the text as a result of experience
gained in DHCP interoperability tests.
Droms
Standards Track
[Page 3]
RFC 2131
Dynamic Host Configuration Protocol
March 1997
1.2 Related Work
There are several Internet protocols and related mechanisms that
address some parts of the dynamic host configuration problem. The
Reverse Address Resolution Protocol (RARP) [10] (through the
extensions defined in the Dynamic RARP (DRARP) [5]) explicitly
addresses the problem of network address discovery, and includes an
automatic IP address assignment mechanism. The Trivial File Transfer
Protocol (TFTP) [20] provides for transport of a boot image from a
boot server. The Internet Control Message Protocol (ICMP) [16]
provides for informing hosts of additional routers via "ICMP
redirect" messages. ICMP also can provide subnet mask information
through the "ICMP mask request" message and other information through
the (obsolete) "ICMP information request" message. Hosts can locate
routers through the ICMP router discovery mechanism [8].
BOOTP is a transport mechanism for a collection of configuration
information. BOOTP is also extensible, and official extensions [17]
have been defined for several configuration parameters. Morgan has
proposed extensions to BOOTP for dynamic IP address assignment [15].
The Network Information Protocol (NIP), used by the Athena project at
MIT, is a distributed mechanism for dynamic IP address assignment
[19]. The Resource Location Protocol RLP [1] provides for location
of higher level services. Sun Microsystems diskless workstations use
a boot procedure that employs RARP, TFTP and an RPC mechanism called
"bootparams" to deliver configuration information and operating
system code to diskless hosts. (Sun Microsystems, Sun Workstation
and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun
networks also use DRARP and an auto-installation mechanism to
automate the configuration of new hosts in an existing network.
In other related work, the path minimum transmission unit (MTU)
discovery algorithm can determine the MTU of an arbitrary internet
path [14]. The Address Resolution Protocol (ARP) has been proposed
as a transport protocol for resource location and selection [6].
Finally, the Host Requirements RFCs [3, 4] mention specific
requirements for host reconfiguration and suggest a scenario for
initial configuration of diskless hosts.
1.3 Problem definition and issues
DHCP is designed to supply DHCP clients with the configuration
parameters defined in the Host Requirements RFCs. After obtaining
parameters via DHCP, a DHCP client should be able to exchange packets
with any other host in the Internet. The TCP/IP stack parameters
supplied by DHCP are listed in Appendix A.
Droms
Standards Track
[Page 4]
RFC 2131
Dynamic Host Configuration Protocol
March 1997
Not all of
client. A
only those
particular
these parameters are required for a newly initialized
client and server may negotiate for the transmission of
parameters required by the client or specific to a
subnet.
DHCP allows but does not require the configuration of client
parameters not directly related to the IP protocol. DHCP also does
not address registration of newly configured clients with the Domain
Name System (DNS) [12, 13].
DHCP is not intended for use in configuring routers.
1.4 Requirements
Throughout this document, the words that are used to define the
significance of particular requirements are capitalized. These words
are:
o "MUST"
This word or the adjective "REQUIRED" means that the
item is an absolute requirement of this specification.
o "MUST NOT"
This phrase means that the item is an absolute prohibition
of this specification.
o "SHOULD"
This word or the adjective "RECOMMENDED" means that there
may exist valid reasons in particular circumstances to ignore
this item, but the full implications should be understood and
the case carefully weighed before choosing a different course.
o "SHOULD NOT"
This phrase means that there may exist valid reasons in
particular circumstances when the listed behavior is acceptable
or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior
described with this label.
Droms
Standards Track
[Page 5]
京公网安备 11010802033920号
Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved
评论