mirror of
https://gitee.com/acl-dev/acl.git
synced 2024-12-05 13:29:03 +08:00
2513 lines
111 KiB
Plaintext
2513 lines
111 KiB
Plaintext
Network Working Group R. Droms
|
||
Request for Comments: 2131 Bucknell University
|
||
Obsoletes: 1541 March 1997
|
||
Category: Standards Track
|
||
|
||
Dynamic Host Configuration Protocol
|
||
|
||
Status of this memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Abstract
|
||
|
||
The Dynamic Host Configuration Protocol (DHCP) provides a framework
|
||
for passing configuration information to hosts on a TCPIP network.
|
||
DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the
|
||
capability of automatic allocation of reusable network addresses and
|
||
additional configuration options [19]. DHCP captures the behavior of
|
||
BOOTP relay agents [7, 21], and DHCP participants can interoperate
|
||
with BOOTP participants [9].
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 3
|
||
1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
1.3 Problem definition and issues . . . . . . . . . . . . . . . . 4
|
||
1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8
|
||
2.1 Configuration parameters repository . . . . . . . . . . . . . 11
|
||
2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12
|
||
3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13
|
||
3.1 Client-server interaction - allocating a network address. . . 13
|
||
3.2 Client-server interaction - reusing a previously allocated
|
||
network address . . . . . . . . . . . . . . . . . . . . . . . 17
|
||
3.3 Interpretation and representation of time values. . . . . . . 20
|
||
3.4 Obtaining parameters with externally configured network
|
||
address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
|
||
3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21
|
||
3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22
|
||
3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22
|
||
4. Specification of the DHCP client-server protocol. . . . . . . 22
|
||
|
||
|
||
|
||
Droms Standards Track [Page 1]
|
||
|
||
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 these parameters are required for a newly initialized
|
||
client. A client and server may negotiate for the transmission of
|
||
only those parameters required by the client or specific to a
|
||
particular subnet.
|
||
|
||
DHCP allows but does not require the configuration of client
|
||
parameters not directly related to the IP protocol. DHCP also does
|
||
not address registration of newly configured clients with the Domain
|
||
Name System (DNS) [12, 13].
|
||
|
||
DHCP is not intended for use in configuring routers.
|
||
|
||
1.4 Requirements
|
||
|
||
Throughout this document, the words that are used to define the
|
||
significance of particular requirements are capitalized. These words
|
||
are:
|
||
|
||
o "MUST"
|
||
|
||
This word or the adjective "REQUIRED" means that the
|
||
item is an absolute requirement of this specification.
|
||
|
||
o "MUST NOT"
|
||
|
||
This phrase means that the item is an absolute prohibition
|
||
of this specification.
|
||
|
||
o "SHOULD"
|
||
|
||
This word or the adjective "RECOMMENDED" means that there
|
||
may exist valid reasons in particular circumstances to ignore
|
||
this item, but the full implications should be understood and
|
||
the case carefully weighed before choosing a different course.
|
||
|
||
o "SHOULD NOT"
|
||
|
||
This phrase means that there may exist valid reasons in
|
||
particular circumstances when the listed behavior is acceptable
|
||
or even useful, but the full implications should be understood
|
||
and the case carefully weighed before implementing any behavior
|
||
described with this label.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Droms Standards Track [Page 5]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
o "MAY"
|
||
|
||
This word or the adjective "OPTIONAL" means that this item is
|
||
truly optional. One vendor may choose to include the item
|
||
because a particular marketplace requires it or because it
|
||
enhances the product, for example; another vendor may omit the
|
||
same item.
|
||
|
||
1.5 Terminology
|
||
|
||
This document uses the following terms:
|
||
|
||
o "DHCP client"
|
||
|
||
A DHCP client is an Internet host using DHCP to obtain
|
||
configuration parameters such as a network address.
|
||
|
||
o "DHCP server"
|
||
|
||
A DHCP server is an Internet host that returns configuration
|
||
parameters to DHCP clients.
|
||
|
||
o "BOOTP relay agent"
|
||
|
||
A BOOTP relay agent or relay agent is an Internet host or router
|
||
that passes DHCP messages between DHCP clients and DHCP servers.
|
||
DHCP is designed to use the same relay agent behavior as specified
|
||
in the BOOTP protocol specification.
|
||
|
||
o "binding"
|
||
|
||
A binding is a collection of configuration parameters, including
|
||
at least an IP address, associated with or "bound to" a DHCP
|
||
client. Bindings are managed by DHCP servers.
|
||
|
||
1.6 Design goals
|
||
|
||
The following list gives general design goals for DHCP.
|
||
|
||
o DHCP should be a mechanism rather than a policy. DHCP must
|
||
allow local system administrators control over configuration
|
||
parameters where desired; e.g., local system administrators
|
||
should be able to enforce local policies concerning allocation
|
||
and access to local resources where desired.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Droms Standards Track [Page 6]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
o Clients should require no manual configuration. Each client
|
||
should be able to discover appropriate local configuration
|
||
parameters without user intervention and incorporate those
|
||
parameters into its own configuration.
|
||
|
||
o Networks should require no manual configuration for individual
|
||
clients. Under normal circumstances, the network manager
|
||
should not have to enter any per-client configuration
|
||
parameters.
|
||
|
||
o DHCP should not require a server on each subnet. To allow for
|
||
scale and economy, DHCP must work across routers or through the
|
||
intervention of BOOTP relay agents.
|
||
|
||
o A DHCP client must be prepared to receive multiple responses
|
||
to a request for configuration parameters. Some installations
|
||
may include multiple, overlapping DHCP servers to enhance
|
||
reliability and increase performance.
|
||
|
||
o DHCP must coexist with statically configured, non-participating
|
||
hosts and with existing network protocol implementations.
|
||
|
||
o DHCP must interoperate with the BOOTP relay agent behavior as
|
||
described by RFC 951 and by RFC 1542 [21].
|
||
|
||
o DHCP must provide service to existing BOOTP clients.
|
||
|
||
The following list gives design goals specific to the transmission of
|
||
the network layer parameters. DHCP must:
|
||
|
||
o Guarantee that any specific network address will not be in
|
||
use by more than one DHCP client at a time,
|
||
|
||
o Retain DHCP client configuration across DHCP client reboot. A
|
||
DHCP client should, whenever possible, be assigned the same
|
||
configuration parameters (e.g., network address) in response
|
||
to each request,
|
||
|
||
o Retain DHCP client configuration across server reboots, and,
|
||
whenever possible, a DHCP client should be assigned the same
|
||
configuration parameters despite restarts of the DHCP mechanism,
|
||
|
||
o Allow automated assignment of configuration parameters to new
|
||
clients to avoid hand configuration for new clients,
|
||
|
||
o Support fixed or permanent allocation of configuration
|
||
parameters to specific clients.
|
||
|
||
|
||
|
||
|
||
Droms Standards Track [Page 7]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
2. Protocol Summary
|
||
|
||
From the client's point of view, DHCP is an extension of the BOOTP
|
||
mechanism. This behavior allows existing BOOTP clients to
|
||
interoperate with DHCP servers without requiring any change to the
|
||
clients' initialization software. RFC 1542 [2] details the
|
||
interactions between BOOTP and DHCP clients and servers [9]. There
|
||
are some new, optional transactions that optimize the interaction
|
||
between DHCP clients and servers that are described in sections 3 and
|
||
4.
|
||
|
||
Figure 1 gives the format of a DHCP message and table 1 describes
|
||
each of the fields in the DHCP message. The numbers in parentheses
|
||
indicate the size of each field in octets. The names for the fields
|
||
given in the figure will be used throughout this document to refer to
|
||
the fields in DHCP messages.
|
||
|
||
There are two primary differences between DHCP and BOOTP. First,
|
||
DHCP defines mechanisms through which clients can be assigned a
|
||
network address for a finite lease, allowing for serial reassignment
|
||
of network addresses to different clients. Second, DHCP provides the
|
||
mechanism for a client to acquire all of the IP configuration
|
||
parameters that it needs in order to operate.
|
||
|
||
DHCP introduces a small change in terminology intended to clarify the
|
||
meaning of one of the fields. What was the "vendor extensions" field
|
||
in BOOTP has been re-named the "options" field in DHCP. Similarly,
|
||
the tagged data items that were used inside the BOOTP "vendor
|
||
extensions" field, which were formerly referred to as "vendor
|
||
extensions," are now termed simply "options."
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Droms Standards Track [Page 8]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
0 1 2 3
|
||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| op (1) | htype (1) | hlen (1) | hops (1) |
|
||
+---------------+---------------+---------------+---------------+
|
||
| xid (4) |
|
||
+-------------------------------+-------------------------------+
|
||
| secs (2) | flags (2) |
|
||
+-------------------------------+-------------------------------+
|
||
| ciaddr (4) |
|
||
+---------------------------------------------------------------+
|
||
| yiaddr (4) |
|
||
+---------------------------------------------------------------+
|
||
| siaddr (4) |
|
||
+---------------------------------------------------------------+
|
||
| giaddr (4) |
|
||
+---------------------------------------------------------------+
|
||
| |
|
||
| chaddr (16) |
|
||
| |
|
||
| |
|
||
+---------------------------------------------------------------+
|
||
| |
|
||
| sname (64) |
|
||
+---------------------------------------------------------------+
|
||
| |
|
||
| file (128) |
|
||
+---------------------------------------------------------------+
|
||
| |
|
||
| options (variable) |
|
||
+---------------------------------------------------------------+
|
||
|
||
Figure 1: Format of a DHCP message
|
||
|
||
DHCP defines a new 'client identifier' option that is used to pass an
|
||
explicit client identifier to a DHCP server. This change eliminates
|
||
the overloading of the 'chaddr' field in BOOTP messages, where
|
||
'chaddr' is used both as a hardware address for transmission of BOOTP
|
||
reply messages and as a client identifier. The 'client identifier'
|
||
is an opaque key, not to be interpreted by the server; for example,
|
||
the 'client identifier' may contain a hardware address, identical to
|
||
the contents of the 'chaddr' field, or it may contain another type of
|
||
identifier, such as a DNS name. The 'client identifier' chosen by a
|
||
DHCP client MUST be unique to that client within the subnet to which
|
||
the client is attached. If the client uses a 'client identifier' in
|
||
one message, it MUST use that same identifier in all subsequent
|
||
messages, to ensure that all servers correctly identify the client.
|
||
|
||
|
||
|
||
|
||
Droms Standards Track [Page 9]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
DHCP clarifies the interpretation of the 'siaddr' field as the
|
||
address of the server to use in the next step of the client's
|
||
bootstrap process. A DHCP server may return its own address in the
|
||
'siaddr' field, if the server is prepared to supply the next
|
||
bootstrap service (e.g., delivery of an operating system executable
|
||
image). A DHCP server always returns its own address in the 'server
|
||
identifier' option.
|
||
|
||
FIELD OCTETS DESCRIPTION
|
||
----- ------ -----------
|
||
|
||
op 1 Message op code / message type.
|
||
1 = BOOTREQUEST, 2 = BOOTREPLY
|
||
htype 1 Hardware address type, see ARP section in "Assigned
|
||
Numbers" RFC; e.g., '1' = 10mb ethernet.
|
||
hlen 1 Hardware address length (e.g. '6' for 10mb
|
||
ethernet).
|
||
hops 1 Client sets to zero, optionally used by relay agents
|
||
when booting via a relay agent.
|
||
xid 4 Transaction ID, a random number chosen by the
|
||
client, used by the client and server to associate
|
||
messages and responses between a client and a
|
||
server.
|
||
secs 2 Filled in by client, seconds elapsed since client
|
||
began address acquisition or renewal process.
|
||
flags 2 Flags (see figure 2).
|
||
ciaddr 4 Client IP address; only filled in if client is in
|
||
BOUND, RENEW or REBINDING state and can respond
|
||
to ARP requests.
|
||
yiaddr 4 'your' (client) IP address.
|
||
siaddr 4 IP address of next server to use in bootstrap;
|
||
returned in DHCPOFFER, DHCPACK by server.
|
||
giaddr 4 Relay agent IP address, used in booting via a
|
||
relay agent.
|
||
chaddr 16 Client hardware address.
|
||
sname 64 Optional server host name, null terminated string.
|
||
file 128 Boot file name, null terminated string; "generic"
|
||
name or null in DHCPDISCOVER, fully qualified
|
||
directory-path name in DHCPOFFER.
|
||
options var Optional parameters field. See the options
|
||
documents for a list of defined options.
|
||
|
||
Table 1: Description of fields in a DHCP message
|
||
|
||
The 'options' field is now variable length. A DHCP client must be
|
||
prepared to receive DHCP messages with an 'options' field of at least
|
||
length 312 octets. This requirement implies that a DHCP client must
|
||
be prepared to receive a message of up to 576 octets, the minimum IP
|
||
|
||
|
||
|
||
Droms Standards Track [Page 10]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
datagram size an IP host must be prepared to accept [3]. DHCP
|
||
clients may negotiate the use of larger DHCP messages through the
|
||
'maximum DHCP message size' option. The options field may be further
|
||
extended into the 'file' and 'sname' fields.
|
||
|
||
In the case of a client using DHCP for initial configuration (before
|
||
the client's TCP/IP software has been completely configured), DHCP
|
||
requires creative use of the client's TCP/IP software and liberal
|
||
interpretation of RFC 1122. The TCP/IP software SHOULD accept and
|
||
forward to the IP layer any IP packets delivered to the client's
|
||
hardware address before the IP address is configured; DHCP servers
|
||
and BOOTP relay agents may not be able to deliver DHCP messages to
|
||
clients that cannot accept hardware unicast datagrams before the
|
||
TCP/IP software is configured.
|
||
|
||
To work around some clients that cannot accept IP unicast datagrams
|
||
before the TCP/IP software is configured as discussed in the previous
|
||
paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is
|
||
defined as the BROADCAST (B) flag. The semantics of this flag are
|
||
discussed in section 4.1 of this document. The remaining bits of the
|
||
flags field are reserved for future use. They MUST be set to zero by
|
||
clients and ignored by servers and relay agents. Figure 2 gives the
|
||
format of the 'flags' field.
|
||
|
||
1 1 1 1 1 1
|
||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|B| MBZ |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|
||
B: BROADCAST flag
|
||
|
||
MBZ: MUST BE ZERO (reserved for future use)
|
||
|
||
Figure 2: Format of the 'flags' field
|
||
|
||
2.1 Configuration parameters repository
|
||
|
||
The first service provided by DHCP is to provide persistent storage
|
||
of network parameters for network clients. The model of DHCP
|
||
persistent storage is that the DHCP service stores a key-value entry
|
||
for each client, where the key is some unique identifier (for
|
||
example, an IP subnet number and a unique identifier within the
|
||
subnet) and the value contains the configuration parameters for the
|
||
client.
|
||
|
||
For example, the key might be the pair (IP-subnet-number, hardware-
|
||
address) (note that the "hardware-address" should be typed by the
|
||
|
||
|
||
|
||
Droms Standards Track [Page 11]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
type of hardware to accommodate possible duplication of hardware
|
||
addresses resulting from bit-ordering problems in a mixed-media,
|
||
bridged network) allowing for serial or concurrent reuse of a
|
||
hardware address on different subnets, and for hardware addresses
|
||
that may not be globally unique. Alternately, the key might be the
|
||
pair (IP-subnet-number, hostname), allowing the server to assign
|
||
parameters intelligently to a DHCP client that has been moved to a
|
||
different subnet or has changed hardware addresses (perhaps because
|
||
the network interface failed and was replaced). The protocol defines
|
||
that the key will be (IP-subnet-number, hardware-address) unless the
|
||
client explicitly supplies an identifier using the 'client
|
||
identifier' option. A client can query the DHCP service to
|
||
retrieve its configuration parameters. The client interface to the
|
||
configuration parameters repository consists of protocol messages to
|
||
request configuration parameters and responses from the server
|
||
carrying the configuration parameters.
|
||
|
||
2.2 Dynamic allocation of network addresses
|
||
|
||
The second service provided by DHCP is the allocation of temporary or
|
||
permanent network (IP) addresses to clients. The basic mechanism for
|
||
the dynamic allocation of network addresses is simple: a client
|
||
requests the use of an address for some period of time. The
|
||
allocation mechanism (the collection of DHCP servers) guarantees not
|
||
to reallocate that address within the requested time and attempts to
|
||
return the same network address each time the client requests an
|
||
address. In this document, the period over which a network address
|
||
is allocated to a client is referred to as a "lease" [11]. The
|
||
client may extend its lease with subsequent requests. The client may
|
||
issue a message to release the address back to the server when the
|
||
client no longer needs the address. The client may ask for a
|
||
permanent assignment by asking for an infinite lease. Even when
|
||
assigning "permanent" addresses, a server may choose to give out
|
||
lengthy but non-infinite leases to allow detection of the fact that
|
||
the client has been retired.
|
||
|
||
In some environments it will be necessary to reassign network
|
||
addresses due to exhaustion of available addresses. In such
|
||
environments, the allocation mechanism will reuse addresses whose
|
||
lease has expired. The server should use whatever information is
|
||
available in the configuration information repository to choose an
|
||
address to reuse. For example, the server may choose the least
|
||
recently assigned address. As a consistency check, the allocating
|
||
server SHOULD probe the reused address before allocating the address,
|
||
e.g., with an ICMP echo request, and the client SHOULD probe the
|
||
newly received address, e.g., with ARP.
|
||
|
||
|
||
|
||
|
||
|
||
Droms Standards Track [Page 12]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
3. The Client-Server Protocol
|
||
|
||
DHCP uses the BOOTP message format defined in RFC 951 and given in
|
||
table 1 and figure 1. The 'op' field of each DHCP message sent from
|
||
a client to a server contains BOOTREQUEST. BOOTREPLY is used in the
|
||
'op' field of each DHCP message sent from a server to a client.
|
||
|
||
The first four octets of the 'options' field of the DHCP message
|
||
contain the (decimal) values 99, 130, 83 and 99, respectively (this
|
||
is the same magic cookie as is defined in RFC 1497 [17]). The
|
||
remainder of the 'options' field consists of a list of tagged
|
||
parameters that are called "options". All of the "vendor extensions"
|
||
listed in RFC 1497 are also DHCP options. RFC 1533 gives the
|
||
complete set of options defined for use with DHCP.
|
||
|
||
Several options have been defined so far. One particular option -
|
||
the "DHCP message type" option - must be included in every DHCP
|
||
message. This option defines the "type" of the DHCP message.
|
||
Additional options may be allowed, required, or not allowed,
|
||
depending on the DHCP message type.
|
||
|
||
Throughout this document, DHCP messages that include a 'DHCP message
|
||
type' option will be referred to by the type of 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 options). Servers need not
|
||
reserve the offered network address, although the protocol will
|
||
work more efficiently if the server avoids allocating the offered
|
||
network address to another client. When allocating a new address,
|
||
servers SHOULD check that the offered network address is not
|
||
|
||
|
||
|
||
Droms Standards Track [Page 13]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
already in use; e.g., the server may probe the offered address
|
||
with an ICMP Echo Request. Servers SHOULD be implemented so that
|
||
network administrators MAY choose to disable probes of newly
|
||
allocated addresses. The server transmits the DHCPOFFER message
|
||
to the client, using the BOOTP relay agent if necessary.
|
||
|
||
Message Use
|
||
------- ---
|
||
|
||
DHCPDISCOVER - Client broadcast to locate available servers.
|
||
|
||
DHCPOFFER - Server to client in response to DHCPDISCOVER with
|
||
offer of configuration parameters.
|
||
|
||
DHCPREQUEST - Client message to servers either (a) requesting
|
||
offered parameters from one server and implicitly
|
||
declining offers from all others, (b) confirming
|
||
correctness of previously allocated address after,
|
||
e.g., system reboot, or (c) extending the lease on a
|
||
particular network address.
|
||
|
||
DHCPACK - Server to client with configuration parameters,
|
||
including committed network address.
|
||
|
||
DHCPNAK - Server to client indicating client's notion of network
|
||
address is incorrect (e.g., client has moved to new
|
||
subnet) or client's lease as expired
|
||
|
||
DHCPDECLINE - Client to server indicating network address is already
|
||
in use.
|
||
|
||
DHCPRELEASE - Client to server relinquishing network address and
|
||
cancelling remaining lease.
|
||
|
||
DHCPINFORM - Client to server, asking only for local configuration
|
||
parameters; client already has externally configured
|
||
network address.
|
||
|
||
Table 2: DHCP messages
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Droms Standards Track [Page 14]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
Server Client Server
|
||
(not selected) (selected)
|
||
|
||
v v v
|
||
| | |
|
||
| Begins initialization |
|
||
| | |
|
||
| _____________/|\____________ |
|
||
|/DHCPDISCOVER | DHCPDISCOVER \|
|
||
| | |
|
||
Determines | Determines
|
||
configuration | configuration
|
||
| | |
|
||
|\ | ____________/ |
|
||
| \________ | /DHCPOFFER |
|
||
| DHCPOFFER\ |/ |
|
||
| \ | |
|
||
| Collects replies |
|
||
| \| |
|
||
| Selects configuration |
|
||
| | |
|
||
| _____________/|\____________ |
|
||
|/ DHCPREQUEST | DHCPREQUEST\ |
|
||
| | |
|
||
| | Commits configuration
|
||
| | |
|
||
| | _____________/|
|
||
| |/ DHCPACK |
|
||
| | |
|
||
| Initialization complete |
|
||
| | |
|
||
. . .
|
||
. . .
|
||
| | |
|
||
| Graceful shutdown |
|
||
| | |
|
||
| |\ ____________ |
|
||
| | DHCPRELEASE \|
|
||
| | |
|
||
| | Discards lease
|
||
| | |
|
||
v v v
|
||
Figure 3: Timeline diagram of messages exchanged between DHCP
|
||
client and servers when allocating a new network address
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
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 more
|
||
servers. The client may choose to wait for multiple responses.
|
||
The client chooses one server from which to request configuration
|
||
parameters, based on the configuration parameters offered in the
|
||
DHCPOFFER messages. The client broadcasts a DHCPREQUEST message
|
||
that MUST include the 'server identifier' option to indicate which
|
||
server it has selected, and that MAY include other options
|
||
specifying desired configuration values. The 'requested IP
|
||
address' option MUST be set to the value of 'yiaddr' in the
|
||
DHCPOFFER message from the server. This DHCPREQUEST message is
|
||
broadcast and relayed through DHCP/BOOTP relay agents. To help
|
||
ensure that any BOOTP relay agents forward the DHCPREQUEST message
|
||
to the same set of DHCP servers that received the original
|
||
DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
|
||
value in the DHCP message header's 'secs' field and be sent to the
|
||
same IP broadcast address as the original DHCPDISCOVER message.
|
||
The client times out and retransmits the DHCPDISCOVER message if
|
||
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 the
|
||
message as notification that the client has declined that server's
|
||
offer. The server selected in the DHCPREQUEST message commits the
|
||
binding for the client to persistent storage and responds with a
|
||
DHCPACK message containing the configuration parameters for the
|
||
requesting client. The combination of 'client identifier' or
|
||
'chaddr' and assigned network address constitute a unique
|
||
identifier for the client's lease and are used by both the client
|
||
and server to identify a lease referred to in any DHCP messages.
|
||
Any configuration parameters in the DHCPACK message SHOULD NOT
|
||
conflict with those in the earlier DHCPOFFER message to which the
|
||
client is responding. The server SHOULD NOT check the offered
|
||
network address at this point. The 'yiaddr' field in the DHCPACK
|
||
messages is filled in with the selected network address.
|
||
|
||
If the selected server is unable to satisfy the DHCPREQUEST message
|
||
(e.g., the requested network address has been allocated), the
|
||
server SHOULD respond with a DHCPNAK message.
|
||
|
||
A server MAY choose to mark addresses offered to clients in
|
||
DHCPOFFER messages as unavailable. The server SHOULD mark an
|
||
address offered to a client in a DHCPOFFER message as available if
|
||
the server receives no DHCPREQUEST message from that client.
|
||
|
||
5. The client receives the DHCPACK message with configuration
|
||
parameters. The client SHOULD perform a final check on the
|
||
parameters (e.g., ARP for allocated network address), and notes the
|
||
duration of the lease specified in the DHCPACK message. At this
|
||
|
||
|
||
|
||
Droms Standards Track [Page 16]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
point, the client is configured. If the client detects that the
|
||
address is already in use (e.g., through the use of ARP), the
|
||
client MUST send a DHCPDECLINE message to the server and restarts
|
||
the configuration process. The client SHOULD wait a minimum of ten
|
||
seconds before restarting the configuration process to avoid
|
||
excessive network traffic in case of looping.
|
||
|
||
If the client receives a DHCPNAK message, the client restarts the
|
||
configuration process.
|
||
|
||
The client times out and retransmits the DHCPREQUEST message if the
|
||
client receives neither a DHCPACK or 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
|
||
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 reverts to INIT state and
|
||
restarts the initialization process. The client SHOULD notify the
|
||
user that the initialization process has failed and is restarting.
|
||
|
||
6. 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 identifier',
|
||
or 'chaddr' and network address in the DHCPRELEASE message. If the
|
||
client used a 'client identifier' when it obtained the lease, it
|
||
MUST use the same 'client identifier' in the DHCPRELEASE message.
|
||
|
||
3.2 Client-server interaction - reusing a previously allocated network
|
||
address
|
||
|
||
If a client remembers and wishes to reuse a previously allocated
|
||
network address, a client may choose to omit some of the steps
|
||
described in the previous section. The timeline diagram in figure 4
|
||
shows the timing relationships in a typical client-server interaction
|
||
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 the
|
||
'requested IP address' option. As the client has not received its
|
||
network address, it MUST NOT fill in the 'ciaddr' field. BOOTP
|
||
relay agents pass the message on to DHCP servers not on the same
|
||
subnet. If the client used a 'client identifier' to obtain its
|
||
address, the client MUST use the same 'client identifier' in the
|
||
DHCPREQUEST message.
|
||
|
||
2. Servers with knowledge of the client's configuration parameters
|
||
respond with a DHCPACK message to the client. Servers SHOULD NOT
|
||
check that the client's network address is already in use; the
|
||
client may respond to ICMP Echo Request messages at this point.
|
||
|
||
Server Client Server
|
||
|
||
v v v
|
||
| | |
|
||
| Begins |
|
||
| initialization |
|
||
| | |
|
||
| /|\ |
|
||
| _________ __/ | \__________ |
|
||
| /DHCPREQU EST | DHCPREQUEST\ |
|
||
|/ | \|
|
||
| | |
|
||
Locates | Locates
|
||
configuration | configuration
|
||
| | |
|
||
|\ | /|
|
||
| \ | ___________/ |
|
||
| \ | / DHCPACK |
|
||
| \ _______ |/ |
|
||
| DHCPACK\ | |
|
||
| Initialization |
|
||
| complete |
|
||
| \| |
|
||
| | |
|
||
| (Subsequent |
|
||
| DHCPACKS |
|
||
| ignored) |
|
||
| | |
|
||
| | |
|
||
v v v
|
||
|
||
Figure 4: Timeline diagram of messages exchanged between DHCP
|
||
client and servers when reusing a previously allocated
|
||
network address
|
||
|
||
|
||
|
||
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 moved
|
||
to a new subnet), servers SHOULD respond with a DHCPNAK message to
|
||
the client. Servers SHOULD NOT respond if their information is not
|
||
guaranteed to be accurate. For example, a server that identifies a
|
||
request for an expired binding that is owned by another server SHOULD
|
||
NOT respond with a DHCPNAK unless the servers are using an explicit
|
||
mechanism to maintain coherency among the servers.
|
||
|
||
If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
|
||
the same subnet as the server. The server MUST
|
||
broadcast the DHCPNAK message to the 0xffffffff broadcast address
|
||
because the client may not have a correct network address or subnet
|
||
mask, and the client may not be answering ARP requests.
|
||
Otherwise, the server MUST send the DHCPNAK message to the IP
|
||
address of the BOOTP relay agent, as recorded in 'giaddr'. The
|
||
relay agent will, in turn, forward the message directly to the
|
||
client's hardware address, so that the DHCPNAK can be delivered even
|
||
if the client has moved to a new network.
|
||
|
||
3. The client receives the DHCPACK message with configuration
|
||
parameters. The client performs a final check on the parameters
|
||
(as in section 3.1), and notes the duration of the lease specified
|
||
in the DHCPACK message. The specific lease is implicitly identified
|
||
by the 'client identifier' or 'chaddr' and the network address. At
|
||
this point, the client is configured.
|
||
|
||
If the client detects that the IP address in the DHCPACK message
|
||
is already in use, the client MUST send a DHCPDECLINE message to the
|
||
server and restarts the configuration process by requesting a
|
||
new network address. This action corresponds to the client
|
||
moving to the INIT 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]
|
||
|
||
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 identifier', or 'chaddr' and network address in the
|
||
DHCPRELEASE message.
|
||
|
||
Note that in this case, where the client retains its network
|
||
address locally, the client will not normally relinquish its
|
||
lease during a graceful shutdown. Only in the case where the
|
||
client explicitly needs to relinquish its lease, e.g., the client
|
||
is about to be moved to a different subnet, will the client send
|
||
a DHCPRELEASE message.
|
||
|
||
3.3 Interpretation and representation of time values
|
||
|
||
A client acquires a lease for a network address for a fixed period of
|
||
time (which may be infinite). Throughout the protocol, times are to
|
||
be represented in units of seconds. The time value of 0xffffffff is
|
||
reserved to represent "infinity".
|
||
|
||
As clients and servers may not have synchronized clocks, times are
|
||
represented in DHCP messages as relative times, to be interpreted
|
||
with respect to the client's local clock. Representing relative
|
||
times in units of seconds in an unsigned 32 bit word gives a range of
|
||
relative times from 0 to approximately 100 years, which is sufficient
|
||
for the relative times to be measured using DHCP.
|
||
|
||
The algorithm for lease duration interpretation given in the previous
|
||
paragraph assumes that client and server clocks are stable relative
|
||
to each other. If there is drift between the two clocks, the server
|
||
may consider the lease expired before the client does. To
|
||
compensate, the server may return a shorter lease duration to the
|
||
client than the server commits to its local database of client
|
||
information.
|
||
|
||
3.4 Obtaining parameters with externally configured network address
|
||
|
||
If a client has obtained a network address through some other means
|
||
(e.g., manual configuration), it may use a DHCPINFORM request message
|
||
|
||
|
||
|
||
Droms Standards Track [Page 20]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
to obtain other local configuration parameters. Servers receiving a
|
||
DHCPINFORM message construct a DHCPACK message with any local
|
||
configuration parameters appropriate for the client without:
|
||
allocating a new address, checking for an existing binding, filling
|
||
in 'yiaddr' or including lease time parameters. The servers SHOULD
|
||
unicast the DHCPACK reply to the address given in the 'ciaddr' field
|
||
of the DHCPINFORM message.
|
||
|
||
The server SHOULD check the network address in a DHCPINFORM message
|
||
for consistency, but MUST NOT check for an existing lease. The
|
||
server forms a DHCPACK message containing the configuration
|
||
parameters for the requesting client and sends the DHCPACK message
|
||
directly to the client.
|
||
|
||
3.5 Client parameters in DHCP
|
||
|
||
Not all clients require initialization of all parameters listed in
|
||
Appendix A. Two techniques are used to reduce the number of
|
||
parameters transmitted from the server to the client. First, most of
|
||
the parameters have defaults defined in the Host Requirements RFCs;
|
||
if the client receives no parameters from the server that override
|
||
the defaults, a client uses those default values. Second, in its
|
||
initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the
|
||
server with a list of specific parameters the client is interested
|
||
in. If the client includes a list of parameters in a DHCPDISCOVER
|
||
message, it MUST include that list in any subsequent DHCPREQUEST
|
||
messages.
|
||
|
||
The client SHOULD include the 'maximum DHCP message size' option to
|
||
let the server know how large the server may make its DHCP messages.
|
||
The parameters returned to a client may still exceed the space
|
||
allocated to options in a DHCP message. In this case, two additional
|
||
options flags (which must appear in the 'options' field of the
|
||
message) indicate that the 'file' and 'sname' fields are to be used
|
||
for options.
|
||
|
||
The client can inform the server which configuration parameters the
|
||
client is interested in by including the 'parameter request list'
|
||
option. The data portion of this option explicitly lists the options
|
||
requested 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]
|
||
|
||
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 address', the server SHOULD respond to the client with a DHCPNAK
|
||
message and may choose to report the problem to the system
|
||
administrator. The server may include an error message in the
|
||
'message' option.
|
||
|
||
3.6 Use of DHCP in clients with multiple interfaces
|
||
|
||
A client with multiple network interfaces must use DHCP through each
|
||
interface independently to obtain configuration information
|
||
parameters for those separate interfaces.
|
||
|
||
3.7 When clients should use DHCP
|
||
|
||
A client SHOULD use DHCP to reacquire or verify its IP address and
|
||
network parameters whenever the local network parameters may have
|
||
changed; e.g., at system boot time or after a disconnection from the
|
||
local network, as the local network configuration may change without
|
||
the client's or user's knowledge.
|
||
|
||
If a client has knowledge of a previous network address and is unable
|
||
to contact a local DHCP server, the client may continue to use the
|
||
previous network address until the lease for that address expires.
|
||
If the lease expires before the client can contact a DHCP server, the
|
||
client must immediately discontinue use of the previous network
|
||
address and may inform local users of the problem.
|
||
|
||
4. Specification of the DHCP client-server protocol
|
||
|
||
In this section, we assume that a DHCP server has a block of network
|
||
addresses from which it can satisfy requests for new addresses. Each
|
||
server also maintains a database of allocated addresses and leases in
|
||
local permanent storage.
|
||
|
||
4.1 Constructing and sending DHCP messages
|
||
|
||
DHCP clients and servers both construct DHCP messages by filling in
|
||
fields in the fixed format section of the message and appending
|
||
tagged data items in the variable length option area. The options
|
||
area includes first a four-octet 'magic cookie' (which was described
|
||
in section 3), followed by the options. The last option must always
|
||
|
||
|
||
|
||
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 client
|
||
to a server are sent to the 'DHCP server' port (67), and DHCP
|
||
messages from a server to a client are sent to the 'DHCP client' port
|
||
(68). A server with multiple network address (e.g., a multi-homed
|
||
host) MAY use any of its network addresses in outgoing DHCP messages.
|
||
|
||
The 'server identifier' field is used both to identify a DHCP server
|
||
in a DHCP message and as a destination address from clients to
|
||
servers. A server with multiple network addresses MUST be prepared
|
||
to to accept any of its network addresses as identifying that server
|
||
in a DHCP message. To accommodate potentially incomplete network
|
||
connectivity, a server MUST choose an address as a 'server
|
||
identifier' that, to the best of the server's knowledge, is reachable
|
||
from the client. For example, if the DHCP server and the DHCP client
|
||
are connected to the same subnet (i.e., the 'giaddr' field in the
|
||
message from the client is zero), the server SHOULD select the IP
|
||
address the server is using for communication on that subnet as the
|
||
'server identifier'. If the server is using multiple IP addresses on
|
||
that subnet, any such address may be used. If the server has
|
||
received a message through a DHCP relay agent, the server SHOULD
|
||
choose an address from the interface on which the message was
|
||
recieved as the 'server identifier' (unless the server has other,
|
||
better information on which to make its choice). DHCP clients MUST
|
||
use the IP address provided in the 'server identifier' option for any
|
||
unicast requests to the DHCP server.
|
||
|
||
DHCP messages broadcast by a client prior to that client obtaining
|
||
its IP address must have the source address field in the IP header
|
||
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 the
|
||
BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
|
||
field is zero and the 'ciaddr' field is nonzero, then the server
|
||
unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
|
||
If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
|
||
set, then the server broadcasts DHCPOFFER and DHCPACK messages to
|
||
0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
|
||
'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
|
||
messages to the client's hardware address and 'yiaddr' address. In
|
||
all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
|
||
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 the
|
||
|
||
|
||
|
||
Droms Standards Track [Page 23]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
'option overload' option is present in the 'options' field, the
|
||
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 indicated
|
||
by the 'options overload' option) MUST begin with the first octet of
|
||
the field, MUST be terminated by an 'end' option, and MUST be
|
||
followed by 'pad' options to fill the remainder of the field. Any
|
||
individual option in the 'options', 'sname' and 'file' fields MUST be
|
||
entirely contained in that field. The options in the 'options' field
|
||
MUST be interpreted first, so that any 'option overload' options may
|
||
be interpreted. The 'file' field MUST be interpreted next (if the
|
||
'option overload' option indicates that the 'file' field contains
|
||
DHCP options), followed by the 'sname' field.
|
||
|
||
The values to be passed in an 'option' tag may be too long to fit in
|
||
the 255 octets available to a single option (e.g., a list of routers
|
||
in a 'router' option [21]). Options may appear only once, unless
|
||
otherwise specified in the options document. The client concatenates
|
||
the values of multiple instances of the same option into a single
|
||
parameter list for configuration.
|
||
|
||
DHCP clients are responsible for all message retransmission. The
|
||
client MUST adopt a retransmission strategy that incorporates a
|
||
randomized exponential backoff algorithm to determine the delay
|
||
between retransmissions. The delay between retransmissions SHOULD be
|
||
chosen to allow sufficient time for replies from the server to be
|
||
delivered based on the characteristics of the internetwork between
|
||
the client and the server. For example, in a 10Mb/sec Ethernet
|
||
internetwork, the delay before the first retransmission SHOULD be 4
|
||
seconds randomized by the value of a uniform random number chosen
|
||
from the range -1 to +1. Clients with clocks that provide resolution
|
||
granularity of less than one second may choose a non-integer
|
||
randomization value. The delay before the next retransmission SHOULD
|
||
be 8 seconds randomized by the value of a uniform number chosen from
|
||
the range -1 to +1. The retransmission delay SHOULD be doubled with
|
||
subsequent retransmissions up to a maximum of 64 seconds. The client
|
||
MAY provide an indication of retransmission attempts to the user as
|
||
an indication of the progress of the configuration process.
|
||
|
||
The 'xid' field is used by the client to match incoming DHCP messages
|
||
with pending requests. A DHCP client MUST choose 'xid's in such a
|
||
way as to minimize the chance of using an 'xid' identical to one used
|
||
by another client. For example, a client may choose a different,
|
||
random initial 'xid' each time the client is rebooted, and
|
||
subsequently use sequential 'xid's until the next reboot. Selecting
|
||
a new 'xid' for each retransmission is an implementation decision. A
|
||
client may choose to reuse the same 'xid' or select a new 'xid' for
|
||
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 deliver
|
||
DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
|
||
uicast delivery. The IP destination address (in the IP header) is
|
||
set to the DHCP 'yiaddr' address and the link-layer destination
|
||
address is set to the DHCP 'chaddr' address. Unfortunately, some
|
||
client implementations are unable to receive such unicast IP
|
||
datagrams until the implementation has been configured with a valid
|
||
IP address (leading to a deadlock in which the client's IP address
|
||
cannot be delivered until the client has been configured with an IP
|
||
address).
|
||
|
||
A client that cannot receive unicast IP datagrams until its protocol
|
||
software has been configured with an IP address SHOULD set the
|
||
BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
|
||
DHCPREQUEST messages that client sends. The BROADCAST bit will
|
||
provide a hint to the DHCP server and BOOTP relay agent to broadcast
|
||
any messages to the client on the client's subnet. A client that can
|
||
receive unicast IP datagrams before its protocol software has been
|
||
configured SHOULD clear the BROADCAST bit to 0. The BOOTP
|
||
clarifications document discusses the ramifications of the use of the
|
||
BROADCAST bit [21].
|
||
|
||
A server or relay agent sending or relaying a DHCP message directly
|
||
to a DHCP client (i.e., not to a relay agent specified in the
|
||
'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
|
||
field. If this bit is set to 1, the DHCP message SHOULD be sent as
|
||
an IP broadcast using an IP broadcast address (preferably 0xffffffff)
|
||
as the IP destination address and the link-layer broadcast address as
|
||
the link-layer destination address. If the BROADCAST bit is cleared
|
||
to 0, the message SHOULD be sent as an IP unicast to the IP address
|
||
specified in the 'yiaddr' field and the link-layer address specified
|
||
in the 'chaddr' field. If unicasting is not possible, the message
|
||
MAY be sent as an IP broadcast using an IP broadcast address
|
||
(preferably 0xffffffff) as the IP destination address and the link-
|
||
layer broadcast address as the link-layer destination address.
|
||
|
||
4.2 DHCP server administrative controls
|
||
|
||
DHCP servers are not required to respond to every DHCPDISCOVER and
|
||
DHCPREQUEST message they receive. For example, a network
|
||
administrator, to retain stringent control over the clients attached
|
||
to the network, may choose to configure DHCP servers to respond only
|
||
to clients that have been previously registered through some external
|
||
mechanism. The DHCP specification describes only the interactions
|
||
between clients and servers when the clients and servers choose to
|
||
interact; it is beyond the scope of the DHCP specification to
|
||
describe all of the administrative controls that system
|
||
administrators might want to use. Specific DHCP server
|
||
|
||
|
||
|
||
Droms Standards Track [Page 25]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
implementations may incorporate any controls or policies desired by a
|
||
network administrator.
|
||
|
||
In some environments, a DHCP server will have to consider the values
|
||
of the vendor class options included in DHCPDISCOVER or DHCPREQUEST
|
||
messages when determining the correct parameters for a particular
|
||
client.
|
||
|
||
A DHCP server needs to use some unique identifier to associate a
|
||
client with its lease. The client MAY choose to explicitly provide
|
||
the identifier through the 'client identifier' option. If the client
|
||
supplies a 'client identifier', the client MUST use the same 'client
|
||
identifier' in all subsequent messages, and the server MUST use that
|
||
identifier to identify the client. If the client does not provide a
|
||
'client identifier' option, the server MUST use the contents of the
|
||
'chaddr' field to identify the client. It is crucial for a DHCP
|
||
client to use an identifier unique within the subnet to which the
|
||
client is attached in the 'client identifier' option. Use of
|
||
'chaddr' as the client's unique identifier may cause unexpected
|
||
results, as that identifier may be associated with a hardware
|
||
interface that could be moved to a new client. Some sites may choose
|
||
to use a manufacturer's serial number as the 'client identifier', to
|
||
avoid unexpected changes in a clients network address due to transfer
|
||
of hardware interfaces among computers. Sites may also choose to use
|
||
a DNS name as the 'client identifier', causing address leases to be
|
||
associated with the DNS name rather than a specific hardware box.
|
||
|
||
DHCP clients are free to use any strategy in selecting a DHCP server
|
||
among those from which the client receives a DHCPOFFER message. The
|
||
client implementation of DHCP SHOULD provide a mechanism for the user
|
||
to select directly the 'vendor class identifier' values.
|
||
|
||
4.3 DHCP server behavior
|
||
|
||
A DHCP server processes incoming DHCP messages from a client based on
|
||
the current state of the binding for that client. A DHCP server can
|
||
receive the following messages from a client:
|
||
|
||
o DHCPDISCOVER
|
||
|
||
o DHCPREQUEST
|
||
|
||
o DHCPDECLINE
|
||
|
||
o DHCPRELEASE
|
||
|
||
o DHCPINFORM
|
||
|
||
|
||
|
||
|
||
Droms Standards Track [Page 26]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
Table 3 gives the use of the fields and options in a DHCP message by
|
||
a server. The remainder of this section describes the action of the
|
||
DHCP server for each possible incoming message.
|
||
|
||
4.3.1 DHCPDISCOVER message
|
||
|
||
When a server receives a DHCPDISCOVER message from a client, the
|
||
server chooses a network address for the requesting client. If no
|
||
address is available, the server may choose to report the problem to
|
||
the system administrator. If an address is available, the new address
|
||
SHOULD be chosen as follows:
|
||
|
||
o The client's current address as recorded in the client's current
|
||
binding, ELSE
|
||
|
||
o The client's previous address as recorded in the client's (now
|
||
expired or released) binding, if that address is in the server's
|
||
pool of available addresses and not already allocated, ELSE
|
||
|
||
o The address requested in the 'Requested IP Address' option, if that
|
||
address is valid and not already allocated, ELSE
|
||
|
||
o A new address allocated from the server's pool of available
|
||
addresses; the address is selected based on the subnet from which
|
||
the message was received (if 'giaddr' is 0) or on the address of
|
||
the relay agent that forwarded the message ('giaddr' when not 0).
|
||
|
||
As described in section 4.2, a server MAY, for administrative
|
||
reasons, assign an address other than the one requested, or may
|
||
refuse to allocate an address to a particular client even though free
|
||
addresses are available.
|
||
|
||
Note that, in some network architectures (e.g., internets with more
|
||
than one IP subnet assigned to a physical network segment), it may be
|
||
the case that the DHCP client should be assigned an address from a
|
||
different subnet than the address recorded in 'giaddr'. Thus, DHCP
|
||
does not require that the client be assigned as address from the
|
||
subnet in 'giaddr'. A server is free to choose some other subnet,
|
||
and it is beyond the scope of the DHCP specification to describe ways
|
||
in which the assigned IP address might be chosen.
|
||
|
||
While not required for correct operation of DHCP, the server SHOULD
|
||
NOT reuse the selected network address before the client responds to
|
||
the server's DHCPOFFER message. The server may choose to record the
|
||
address as offered to the client.
|
||
|
||
The server must also choose an expiration time for the lease, as
|
||
follows:
|
||
|
||
|
||
|
||
Droms Standards Track [Page 27]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
o IF the client has not requested a specific lease in the
|
||
DHCPDISCOVER message and the client already has an assigned network
|
||
address, the server returns the lease expiration time previously
|
||
assigned to that address (note that the client must explicitly
|
||
request a specific lease to extend the expiration time on a
|
||
previously assigned address), ELSE
|
||
|
||
o IF the client has not requested a specific lease in the
|
||
DHCPDISCOVER message and the client does not have an assigned
|
||
network address, the server assigns a locally configured default
|
||
lease time, ELSE
|
||
|
||
o IF the client has requested a specific 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]
|
||
|
||
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 MAY MAY MUST NOT
|
||
|
||
Table 3: Fields and options used by DHCP servers
|
||
|
||
Once the network address and lease have been determined, the server
|
||
constructs a DHCPOFFER message with the offered configuration
|
||
parameters. It is important for all DHCP servers to return the same
|
||
parameters (with the possible exception of a newly allocated network
|
||
address) to ensure predictable client behavior regardless of which
|
||
server the client selects. The configuration parameters MUST be
|
||
selected by applying the following rules in the order given below.
|
||
The network administrator is responsible for configuring multiple
|
||
DHCP servers to ensure uniform responses from those servers. The
|
||
server MUST return to the client:
|
||
|
||
o The client's network address, as determined by the rules given
|
||
earlier in this section,
|
||
|
||
o The expiration time for the client's lease, as determined by the
|
||
rules given earlier in this section,
|
||
|
||
o Parameters requested by the client, according to the following
|
||
rules:
|
||
|
||
-- IF the server has been explicitly configured with a default
|
||
value for the parameter, the server MUST include that value
|
||
in an appropriate option in the 'option' field, ELSE
|
||
|
||
-- IF the server recognizes the parameter as a parameter
|
||
defined in the Host Requirements Document, the server MUST
|
||
include the default value for that parameter as given in the
|
||
Host Requirements Document in an appropriate option in the
|
||
'option' field, ELSE
|
||
|
||
-- The server MUST NOT return a value for that parameter,
|
||
|
||
|
||
|
||
Droms Standards Track [Page 29]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
The server MUST supply as many of the requested parameters as
|
||
possible and MUST omit any parameters it cannot provide. The
|
||
server MUST include each requested parameter only once unless
|
||
explicitly allowed in the DHCP Options and BOOTP Vendor
|
||
Extensions document.
|
||
|
||
o Any parameters from the existing binding that differ from the Host
|
||
Requirements Document defaults,
|
||
|
||
o Any parameters specific to this client (as identified by
|
||
the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER
|
||
or DHCPREQUEST message), e.g., as configured by the network
|
||
administrator,
|
||
|
||
o Any parameters specific to this client's class (as identified
|
||
by the contents of the 'vendor class identifier'
|
||
option in the DHCPDISCOVER or DHCPREQUEST message),
|
||
e.g., as configured by the network administrator; the parameters
|
||
MUST be identified by an exact match between the client's vendor
|
||
class identifiers and the client's classes identified in the
|
||
server,
|
||
|
||
o Parameters with non-default values on the client's subnet.
|
||
|
||
The server MAY choose to return the 'vendor class identifier' used to
|
||
determine the parameters in the DHCPOFFER 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]
|
||
|
||
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
|
||
identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be
|
||
filled in with the yiaddr value from the chosen DHCPOFFER.
|
||
|
||
Note that the client may choose to collect several DHCPOFFER
|
||
messages and select the "best" offer. The client indicates its
|
||
selection by identifying the offering server in the DHCPREQUEST
|
||
message. If the client receives no acceptable offers, the client
|
||
may choose to try another DHCPDISCOVER message. Therefore, the
|
||
servers may not receive a specific DHCPREQUEST from which they can
|
||
decide whether or not the client has accepted the offer. Because
|
||
the servers have not committed any network address assignments on
|
||
the basis of a DHCPOFFER, servers are free to reuse offered
|
||
network addresses in response to subsequent requests. As an
|
||
implementation detail, servers SHOULD NOT reuse offered addresses
|
||
and may use an implementation-specific timeout mechanism to decide
|
||
when to reuse an offered address.
|
||
|
||
o DHCPREQUEST generated during INIT-REBOOT state:
|
||
|
||
'server identifier' MUST NOT be filled in, 'requested IP address'
|
||
option MUST be filled in with client's notion of its previously
|
||
assigned address. 'ciaddr' MUST be zero. The client is seeking to
|
||
verify a previously allocated, cached configuration. Server SHOULD
|
||
send a DHCPNAK message to the client if the 'requested IP address'
|
||
is incorrect, or is on the wrong network.
|
||
|
||
Determining whether a client in the INIT-REBOOT state is on the
|
||
correct network is done by examining the contents of 'giaddr', the
|
||
'requested IP address' option, and a database lookup. If the DHCP
|
||
server detects that the client is on the wrong net (i.e., the
|
||
result of applying the local subnet mask or remote subnet mask (if
|
||
'giaddr' is not zero) to 'requested IP address' option value
|
||
doesn't match reality), then the server SHOULD send a DHCPNAK
|
||
message to the client.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Droms Standards Track [Page 31]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
If the network is correct, then the DHCP server should check if
|
||
the client's notion of its IP address is correct. If not, then the
|
||
server SHOULD send a DHCPNAK message to the client. If the DHCP
|
||
server has no record of this client, then it MUST remain silent,
|
||
and MAY output a warning to the network administrator. This
|
||
behavior is necessary for peaceful coexistence of non-
|
||
communicating DHCP servers on the same wire.
|
||
|
||
If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
|
||
the same subnet as the server. The server MUST broadcast the
|
||
DHCPNAK message to the 0xffffffff broadcast address because the
|
||
client may not have a correct network address or subnet mask, and
|
||
the client may not be answering ARP requests.
|
||
|
||
If 'giaddr' is set in the DHCPREQUEST message, the client is on a
|
||
different subnet. The server MUST set the broadcast bit in the
|
||
DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the
|
||
client, because the client may not have a correct network address
|
||
or subnet mask, and the client may not be answering ARP requests.
|
||
|
||
o DHCPREQUEST generated during RENEWING state:
|
||
|
||
'server identifier' MUST NOT be filled in, 'requested IP address'
|
||
option MUST NOT be filled in, 'ciaddr' MUST be filled in with
|
||
client's IP address. In this situation, the client is completely
|
||
configured, and is trying to extend its lease. This message will
|
||
be unicast, so no relay agents will be involved in its
|
||
transmission. Because 'giaddr' is therefore not filled in, the
|
||
DHCP server will trust the value in 'ciaddr', and use it when
|
||
replying to the client.
|
||
|
||
A client MAY choose to renew or extend its lease prior to T1. The
|
||
server may choose not to extend the lease (as a policy decision by
|
||
the network administrator), but should return a DHCPACK message
|
||
regardless.
|
||
|
||
o DHCPREQUEST generated during REBINDING state:
|
||
|
||
'server identifier' MUST NOT be filled in, 'requested IP address'
|
||
option MUST NOT be filled in, 'ciaddr' MUST be filled in with
|
||
client's IP address. In this situation, the client is completely
|
||
configured, and is trying to extend its lease. This message MUST
|
||
be broadcast to the 0xffffffff IP broadcast address. The DHCP
|
||
server SHOULD check 'ciaddr' for correctness before replying to
|
||
the DHCPREQUEST.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Droms Standards Track [Page 32]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
The DHCPREQUEST from a REBINDING client is intended to accommodate
|
||
sites that have multiple DHCP servers and a mechanism for
|
||
maintaining consistency among leases managed by multiple servers.
|
||
A DHCP server MAY extend a client's lease only if it has local
|
||
administrative authority to do so.
|
||
|
||
4.3.3 DHCPDECLINE message
|
||
|
||
If the server receives a DHCPDECLINE message, the client has
|
||
discovered through some other means that the suggested network
|
||
address is already in use. The server MUST mark the network address
|
||
as not available and SHOULD notify the local system administrator of
|
||
a possible configuration problem.
|
||
|
||
4.3.4 DHCPRELEASE message
|
||
|
||
Upon receipt of a DHCPRELEASE message, the server marks the network
|
||
address as not allocated. The server SHOULD retain a record of the
|
||
client's initialization parameters for possible reuse in response to
|
||
subsequent requests from the client.
|
||
|
||
4.3.5 DHCPINFORM message
|
||
|
||
The server responds to a DHCPINFORM message by sending a DHCPACK
|
||
message directly to the address given in the 'ciaddr' field of the
|
||
DHCPINFORM message. The server MUST NOT send a lease expiration time
|
||
to the client and SHOULD NOT fill in 'yiaddr'. The server includes
|
||
other parameters in the DHCPACK message as defined in section 4.3.1.
|
||
|
||
4.3.6 Client messages
|
||
|
||
Table 4 details the differences between messages from clients in
|
||
various states.
|
||
|
||
---------------------------------------------------------------------
|
||
| |INIT-REBOOT |SELECTING |RENEWING |REBINDING |
|
||
---------------------------------------------------------------------
|
||
|broad/unicast |broadcast |broadcast |unicast |broadcast |
|
||
|server-ip |MUST NOT |MUST |MUST NOT |MUST NOT |
|
||
|requested-ip |MUST |MUST |MUST NOT |MUST NOT |
|
||
|ciaddr |zero |zero |IP address |IP address|
|
||
---------------------------------------------------------------------
|
||
|
||
Table 4: Client messages from different states
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Droms Standards Track [Page 33]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
4.4 DHCP client behavior
|
||
|
||
Figure 5 gives a state-transition diagram for a DHCP client. A
|
||
client can receive the following messages from a server:
|
||
|
||
o DHCPOFFER
|
||
|
||
o DHCPACK
|
||
|
||
o DHCPNAK
|
||
|
||
The DHCPINFORM message is not shown in figure 5. A client simply
|
||
sends the DHCPINFORM and waits for DHCPACK messages. Once the client
|
||
has selected its parameters, it has completed the configuration
|
||
process.
|
||
|
||
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]
|
||
|
||
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 |
|
||
+-------+ | DHCPACK/ | |
|
||
T1 expires/ Record lease, set | |
|
||
Send DHCPREQUEST timers T1, T2 | |
|
||
to leasing server | | |
|
||
| ---------- | |
|
||
| | |------------+ |
|
||
+->| RENEWING | |
|
||
| |----------------------------+
|
||
----------
|
||
Figure 5: State-transition diagram for DHCP clients
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Droms Standards Track [Page 35]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
4.4.1 Initialization and allocation of network address
|
||
|
||
The client begins in INIT state and forms a DHCPDISCOVER message.
|
||
The client SHOULD wait a random time between one and ten seconds to
|
||
desynchronize the use of DHCP at startup. The client sets 'ciaddr'
|
||
to 0x00000000. The client MAY request specific parameters by
|
||
including the 'parameter request list' option. The client MAY
|
||
suggest a network address and/or lease time by including the
|
||
'requested IP address' and 'IP address lease time' options. The
|
||
client MUST include its hardware address in the 'chaddr' field, if
|
||
necessary for delivery of DHCP reply messages. The client MAY
|
||
include a different unique identifier in the 'client identifier'
|
||
option, as discussed in section 4.2. If the client included a list
|
||
of requested parameters in a DHCPDISCOVER message, it MUST include
|
||
that list in all subsequent messages.
|
||
|
||
The client generates and records a random transaction identifier and
|
||
inserts that identifier into the 'xid' field. The client records its
|
||
own local time for later use in computing the lease expiration. The
|
||
client then broadcasts the DHCPDISCOVER on the local hardware
|
||
broadcast address to the 0xffffffff IP broadcast address and 'DHCP
|
||
server' UDP port.
|
||
|
||
If the 'xid' of an arriving DHCPOFFER message does not match the
|
||
'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message
|
||
must be silently discarded. Any arriving DHCPACK messages must be
|
||
silently discarded.
|
||
|
||
The client collects DHCPOFFER messages over a period of time, selects
|
||
one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
|
||
messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
|
||
from the previously used server) and extracts the server address from
|
||
the 'server identifier' option in the DHCPOFFER message. The time
|
||
over which the client collects messages and the mechanism used to
|
||
select one DHCPOFFER are implementation dependent.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Droms Standards Track [Page 36]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
Field 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]
|
||
|
||
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 DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/
|
||
DHCPINFORM DHCPRELEASE
|
||
Client identifier MAY MAY MAY
|
||
Vendor class identifier MAY MAY MUST NOT
|
||
Server identifier MUST NOT MUST (after MUST
|
||
SELECTING)
|
||
MUST NOT (after
|
||
INIT-REBOOT,
|
||
BOUND, RENEWING
|
||
or REBINDING)
|
||
Parameter request list MAY MAY MUST NOT
|
||
Maximum message size MAY MAY MUST NOT
|
||
Message SHOULD NOT SHOULD NOT SHOULD
|
||
Site-specific MAY MAY MUST NOT
|
||
All others MAY MAY MUST NOT
|
||
|
||
Table 5: Fields and options used by DHCP clients
|
||
|
||
If the parameters are acceptable, the client records the address of
|
||
the server that supplied the parameters from the 'server identifier'
|
||
field and sends that address in the 'server identifier' field of a
|
||
DHCPREQUEST broadcast message. Once the DHCPACK message from the
|
||
server arrives, the client is initialized and moves to BOUND state.
|
||
The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER
|
||
message. The client records the lease expiration time as the sum of
|
||
the time at which the original request was sent and the duration of
|
||
the lease from the DHCPACK message. The client SHOULD perform a
|
||
check on the suggested address to ensure that the address is not
|
||
already in use. For example, if the client is on a network that
|
||
supports ARP, the client may issue an ARP request for the suggested
|
||
request. When broadcasting an ARP request for the suggested address,
|
||
the client must fill in its own hardware address as the sender's
|
||
hardware address, and 0 as the sender's IP address, to avoid
|
||
confusing ARP caches in other hosts on the same subnet. If the
|
||
|
||
|
||
|
||
Droms Standards Track [Page 38]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
network address appears to be in use, the client MUST send a
|
||
DHCPDECLINE message to the server. The client SHOULD broadcast an ARP
|
||
reply to announce the client's new IP address and clear any outdated
|
||
ARP cache entries in hosts on the client's subnet.
|
||
|
||
4.4.2 Initialization with known network address
|
||
|
||
The client begins in INIT-REBOOT state and sends a DHCPREQUEST
|
||
message. The client MUST insert its known network address as a
|
||
'requested IP address' option in the DHCPREQUEST message. The client
|
||
may request specific configuration parameters by including the
|
||
'parameter request list' option. The client generates and records a
|
||
random transaction identifier and inserts that identifier into the
|
||
'xid' field. The client records its own local time for later use in
|
||
computing the lease expiration. The client MUST NOT include a
|
||
'server identifier' in the DHCPREQUEST message. The client then
|
||
broadcasts the DHCPREQUEST on the local hardware broadcast address to
|
||
the 'DHCP server' UDP port.
|
||
|
||
Once a DHCPACK message with an 'xid' field matching that in the
|
||
client's DHCPREQUEST message arrives from any server, the client is
|
||
initialized and moves to BOUND state. The client records the lease
|
||
expiration time as the sum of the time at which the DHCPREQUEST
|
||
message was sent and the duration of the lease from the DHCPACK
|
||
message.
|
||
|
||
4.4.3 Initialization with an externally assigned network address
|
||
|
||
The client sends a DHCPINFORM message. The client may request
|
||
specific configuration parameters by including the 'parameter request
|
||
list' option. The client generates and records a random transaction
|
||
identifier and inserts that identifier into the 'xid' field. The
|
||
client places its own network address in the 'ciaddr' field. The
|
||
client SHOULD NOT request lease time parameters.
|
||
|
||
The client then unicasts the DHCPINFORM to the DHCP server if it
|
||
knows the server's address, otherwise it broadcasts the message to
|
||
the limited (all 1s) broadcast address. DHCPINFORM messages MUST be
|
||
directed to the 'DHCP server' UDP port.
|
||
|
||
Once a DHCPACK message with an 'xid' field matching that in the
|
||
client's DHCPINFORM message arrives from any server, the client is
|
||
initialized.
|
||
|
||
If the client does not receive a DHCPACK within a reasonable period
|
||
of time (60 seconds or 4 tries if using timeout suggested in section
|
||
4.1), then it SHOULD display a message informing the user of the
|
||
problem, and then SHOULD begin network processing using suitable
|
||
|
||
|
||
|
||
Droms Standards Track [Page 39]
|
||
|
||
RFC 2131 Dynamic Host Configuration Protocol March 1997
|
||
|
||
|
||
defaults as per Appendix A.
|
||
|
||
4.4.4 Use of broadcast and unicast
|
||
|
||
The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
|
||
messages, unless the client knows the address of a DHCP server. The
|
||
client unicasts DHCPRELEASE messages to the server. Because the
|
||
client is declining the use of the IP address supplied by the server,
|
||
the client broadcasts DHCPDECLINE messages.
|
||
|
||
When the DHCP client knows the address of a DHCP server, in either
|
||
INIT or REBOOTING state, the client may use that address in the
|
||
DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
|
||
The client may also use unicast to send DHCPINFORM messages to a
|
||
known DHCP server. If the client receives no response to DHCP
|
||
messages sent to the IP address of a known DHCP server, the DHCP
|
||
client reverts to using the IP broadcast address.
|
||
|
||
4.4.5 Reacquisition and expiration
|
||
|
||
The client maintains two times, T1 and T2, that specify the times at
|
||
which the client tries to extend its lease on its network address.
|
||
T1 is the time 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]
|
||
|
||
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 other 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]
|
||
|
||
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]
|
||
|
||
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]
|
||
|
||
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@bucknell.edu
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Droms Standards Track [Page 44]
|
||
|
||
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)
|