RFC2131(原文)
Network WorkingGroup R. Droms
Request forComments: 2131 Bucknell University
Obsoletes:1541 March 1997
Category: StandardsTrack
Dynamic Host ConfigurationProtocol
Status of this memo
This document specifies an Internetstandards track protocol for the
Internet community, and requests discussionand 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
forpassing configuration information to hosts on a TCPIP network.
DHCP is based on the Bootstrap Protocol(BOOTP) [7], adding the
capability of automatic allocation ofreusable network addresses and
additional configuration options [19]. DHCP captures the behavior of
BOOTP relay agents [7, 21], and DHCPparticipants 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 anetwork address. . . 13
3.2 Client-server interaction - reusinga previously allocated
network address . . . . . . . . . . . .. . . . . . . . . . . 17
3.3 Interpretation and representation oftime values. . . . . . . 20
3.4 Obtaining parameters with externallyconfigured network
address . . . . . . . . . . . . . . . .. . . . . . . . . . . 20
3.5 Client parameters in DHCP . . . . . . .. . . . . . . . . . . 21
3.6 Use of DHCP in clients with multipleinterfaces . . . . . . . 22
3.7 When clients should use DHCP. . . . . .. . . . . . . . . . . 22
4. Specification of the DHCP client-server protocol. . . . . . . 22
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. HostConfiguration Parameters . . . . . . . .. . . . . . . .45
List of Figures
1. Format of a DHCP message . . . . . . . .. . . . . . . . . . . 9
2. Format of the 'flags' field. . . . . . .. . . . . . . . . . . 11
3. Timeline diagram of messages exchangedbetween DHCP client and
servers when allocating a new networkaddress. . . . . . . . . 15
4. Timeline diagram of messages exchangedbetween DHCP client and
servers when reusing a previouslyallocated network address. . 18
5. State-transition diagram for DHCPclients. . . . . . . . . . . 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-specificconfiguration parameters from a
DHCP server to a host and a mechanism forallocation of network
addresses to hosts.
DHCP is built on a client-server model,where designated DHCP server
hosts allocate network addresses and deliverconfiguration parameters
to dynamically configured hosts. Throughout the remainder of this
document, the term "server" refersto a host providing initialization
parameters through DHCP, and the term"client" refers to a host
requesting initialization parameters from aDHCP server.
A host should not act as a DHCP server unlessexplicitly configured
to do so by a system administrator. The diversity of hardware and
protocol implementations in the Internetwould preclude reliable
operation if random hosts were allowed torespond to DHCP requests.
For example, IP requires the setting of manyparameters within the
protocol implementation software. Because IP can be used on many
dissimilar kinds of network hardware, valuesfor those parameters
cannot be guessed or assumed to have correctdefaults. Also,
distributed address allocation schemesdepend on a polling/defense
mechanism for discovery of addresses thatare already in use. IP
hosts may not always be able to defend theirnetwork addresses, so
that such a distributed address allocation schemecannot be
guaranteed to avoid allocation of duplicatenetwork addresses.
DHCP supports three mechanisms for IPaddress allocation. In
"automatic allocation", DHCPassigns a permanent IP address to a
client. In "dynamic allocation", DHCP assigns an IP address to a
client for a limited period of time (oruntil the client explicitly
relinquishes the address). In "manual allocation", a client'sIP
address is assigned by the networkadministrator, and DHCP is used
simply to convey the assigned address to theclient. A particular
network will use one or more of thesemechanisms, depending on the
policies of the network administrator.
Dynamic allocation is the only one of thethree mechanisms that
allows automatic reuse of an address that isno longer needed by the
client to which it was assigned. Thus, dynamic allocation is
particularly useful for assigning an addressto a client that will be
connected to the network only temporarily orfor sharing a limited
pool of IP addresses among a group ofclients that do not need
permanent IP addresses. Dynamic allocation may also be a good choice
for assigning an IP address to a new clientbeing permanently
connected to a network where IP addressesare sufficiently scarce
that it is important to reclaim them whenold clients are retired.
Manual allocation allows DHCP to be used toeliminate the error-prone
process of manually configuring hosts withIP addresses in
environments where (for whatever reasons) itis desirable to manage
IP address assignment outside of the DHCPmechanisms.
The format of DHCP messages is based on theformat of BOOTP messages,
to capture the BOOTP relay agent behaviordescribed as part of the
BOOTP specification [7, 21] and to allow interoperabilityof existing
BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates
the necessity of having a DHCP server oneach physical network
segment.
1.1 Changes to RFC 1541
This document updates the DHCP protocolspecification that appears in
RFC1541. Anew 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 hasbeen extended to include
"vendor" classes as definedin sections 4.2 and 4.3. The minimum
lease time restriction has beenremoved. Finally, many editorial
changes have been made to clarify the textas a result of experience
gained in DHCP interoperability tests.
1.2 Related Work
There are several Internet protocols andrelated mechanisms that
address some parts of the dynamic hostconfiguration problem. The
Reverse Address Resolution Protocol (RARP)[10] (through the
extensions defined in the Dynamic RARP(DRARP) [5]) explicitly
addresses the problem of network addressdiscovery, and includes an
automatic IP address assignmentmechanism. The Trivial File Transfer
Protocol (TFTP) [20] provides for transportof a boot image from a
boot server. The Internet Control Message Protocol (ICMP) [16]
provides for informing hosts of additionalrouters via "ICMP
redirect" messages. ICMP also can provide subnet mask information
through the "ICMP mask request"message and other information through
the (obsolete) "ICMP informationrequest" message. Hosts can locate
routers through the ICMP router discoverymechanism [8].
BOOTP is a transport mechanism for acollection of configuration
information. BOOTP is also extensible, and official extensions [17]
have been defined for several configurationparameters. Morgan has
proposed extensions to BOOTP for dynamic IPaddress assignment [15].
The Network Information Protocol (NIP), usedby the Athena project at
MIT, is a distributed mechanism for dynamicIP 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 andan RPC mechanism called
"bootparams" to deliverconfiguration 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 anauto-installation mechanism to
automate the configuration of new hosts inan existing network.
In other related work, the path minimumtransmission unit (MTU)
discovery algorithm can determine the MTU ofan arbitrary internet
path [14]. The Address Resolution Protocol (ARP) has been proposed
as a transport protocol for resourcelocation and selection [6].
Finally, the Host Requirements RFCs [3, 4]mention specific
requirements for host reconfiguration andsuggest a scenario for
initial configuration of diskless hosts.
1.3 Problemdefinition and issues
DHCP is designed to supply DHCP clients withthe configuration
parameters defined in the Host RequirementsRFCs. After obtaining
parameters via DHCP, a DHCP client should beable to exchange packets
with any other host in the Internet. The TCP/IP stack parameters
supplied by DHCP are listed in Appendix A.
Not all of these parameters are required fora newly initialized
client. A client and server may negotiate for the transmission of
only those parameters required by the clientor specific to a
particular subnet.
DHCP allows but does not require theconfiguration of client
parameters not directly related to the IPprotocol. DHCP also does
not address registration of newly configuredclients with the Domain
Name System
DHCP is not intended for use in configuringrouters.
1.4 Requirements
Throughout this document, the words that areused to define the
significance of particular requirements arecapitalized. These words
are:
o "MUST"
This word or the adjective"REQUIRED" means that the
item is an absolute requirement of thisspecification.
o "MUST NOT"
This phrase means that the item is anabsolute prohibition
of this specification.
o "SHOULD"
This word or the adjective"RECOMMENDED" means that there
may exist valid reasons in particularcircumstances to ignore
this item, but the full implicationsshould be understood and
the case carefully weighed beforechoosing a different course.
o "SHOULD NOT"
This phrase means that there may existvalid reasons in
particular circumstances when thelisted behavior is acceptable
or even useful, but the fullimplications should be understood
and the case carefully weighed beforeimplementing any behavior
described with this label.
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 marketplacerequires 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 usingDHCP to obtain
configuration parameters such as anetwork address.
o "DHCP server"
A DHCP server is an Internet host thatreturns configuration
parameters to DHCP clients.
o "BOOTP relay agent"
A BOOTP relay agent or relay agent is anInternet host or router
that passes DHCP messages between DHCPclients and DHCP servers.
DHCP is designed to use the same relayagent behavior as specified
in the BOOTP protocol specification.
o "binding"
A binding is a collection ofconfiguration parameters, including
at least an IP address, associated withor "bound to" a DHCP
client. Bindings are managed by DHCP servers.
1.6 Design goals
The following list gives general designgoals 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.
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 normalcircumstances, 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 RFC951 andby 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.
2. Protocol Summary
From the client's point of view, DHCP is anextension of the BOOTP
mechanism. This behavior allows existing BOOTP clients to
interoperate with DHCP servers withoutrequiring any change to the
clients' initialization software. RFC1542 [2] details the
interactions between BOOTP and DHCP clientsand servers [9]. There
are some new, optional transactions thatoptimize the interaction
between DHCP clients and servers that aredescribed in sections 3 and
4.
Figure 1 gives the format of a DHCP messageand table 1 describes
each of the fields in the DHCP message. The numbers in parentheses
indicate the size of each field inoctets. The names for the fields
given in the figure will be used throughoutthis document to refer to
the fields in DHCP messages.
There are two primary differences betweenDHCP and BOOTP. First,
DHCP defines mechanisms through which clientscan be assigned a
network address for a finite lease, allowingfor serial reassignment
of network addresses to differentclients. Second, DHCP provides the
mechanism for a client to acquire all of theIP configuration
parameters that it needs in order tooperate.
DHCP introduces a small change interminology 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 insidethe BOOTP "vendor
extensions" field, which were formerlyreferred to as "vendor
extensions," are now termed simply"options."
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 12 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 DHCPserver. This change eliminates
the overloading of the 'chaddr' field inBOOTP messages, where
'chaddr' is used both as a hardware addressfor transmission of BOOTP
reply messages and as a clientidentifier. The 'client identifier'
is an opaque key, not to be interpretedby the server; for example,
the 'client identifier' may contain ahardware address, identical to
the contents of the 'chaddr' field, or itmay contain another type of
identifier, such as a DNS name. The 'client identifier' chosen by a
DHCP client MUST be unique to that clientwithin the subnet to which
the client is attached. If the client uses a'client identifier' in
one message, it MUST use that sameidentifier in all subsequent
messages, to ensure that all serverscorrectly identify the client.
DHCP clarifies the interpretation of the'siaddr' field as the
address of the server to use in the nextstep of the client's
bootstrap process. A DHCP server may return its own address inthe
'siaddr' field, if the server is prepared tosupply the next
bootstrap service (e.g., delivery of anoperating 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 ARPsection 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, optionallyused by relay agents
when booting via a relayagent.
xid 4 Transaction ID, a random numberchosen by the
client, used by the clientand server to associate
messages and responsesbetween a client and a
server.
secs 2 Filled in by client, secondselapsed since client
began address acquisitionor renewal process.
flags 2 Flags (see figure 2).
ciaddr 4 Client IP address; only filledin if client is in
BOUND, RENEW or REBINDINGstate and can respond
to ARP requests.
yiaddr 4 'your' (client) IP address.
siaddr 4 IP address of next server touse in bootstrap;
returned in DHCPOFFER,DHCPACK by server.
giaddr 4 Relay agent IP address, used inbooting via a
relay agent.
chaddr 16 Client hardware address.
sname 64 Optional server host name,null terminated string.
file 128 Boot file name, nullterminated string; "generic"
name or null inDHCPDISCOVER, fully qualified
directory-path name inDHCPOFFER.
options var Optional parametersfield. See the options
documents for a list ofdefined 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 clientmust
be prepared to receive a message of up to576 octets, the minimum IP
datagram size an IP host must be prepared toaccept [3]. DHCP
clients may negotiate the use of larger DHCPmessages 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 forinitial configuration (before
the client's TCP/IP software has beencompletely configured), DHCP
requires creative use of the client's TCP/IPsoftware and liberal
interpretation of RFC1122. The TCP/IP software SHOULD accept and
forward to the IP layer any IP packetsdelivered to the client's
hardware address before the IP address isconfigured; DHCP servers
and BOOTP relay agents may not be able todeliver DHCP messages to
clients that cannot accept hardware unicastdatagrams before the
TCP/IP software is configured.
To work around some clients that cannotaccept IP unicast datagrams
before the TCP/IP software is configured asdiscussed 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 thisdocument. The remaining bits of the
flags field are reserved for futureuse. They MUST be set to zero by
clients and ignored by servers and relayagents. 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 Configurationparameters repository
The first service provided by DHCP is toprovide persistent storage
of network parameters for networkclients. The model of DHCP
persistent storage is that the DHCP servicestores a key-value entry
for each client, where the key is someunique identifier (for
example, an IP subnet number and a uniqueidentifier within the
subnet) and the value contains theconfiguration 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
type of hardware to accommodate possibleduplication of hardware
addresses resulting from bit-orderingproblems in a mixed-media,
bridged network) allowing for serial orconcurrent reuse of a
hardware address on different subnets, andfor hardware addresses
that may not be globally unique. Alternately, the key might be the
pair (IP-subnet-number, hostname), allowingthe server to assign
parameters intelligently to a DHCP clientthat has been moved to a
different subnet or has changed hardwareaddresses (perhaps because
the network interface failed and wasreplaced). The protocol defines
that the key will be (IP-subnet-number,hardware-address) unless the
client explicitly supplies an identifierusing the 'client
identifier' option. A client can query the DHCP serviceto
retrieve its configuration parameters. The client interface to the
configuration parameters repository consistsof protocol messages to
request configuration parameters andresponses from the server
carrying the configuration parameters.
2.2 Dynamicallocation of network addresses
The second service provided by DHCP is theallocation of temporary or
permanent network (IP) addresses toclients. The basic mechanism for
the dynamic allocation of network addressesis simple: a client
requests the use of an address for someperiod of time. The
allocation mechanism (the collection of DHCPservers) guarantees not
to reallocate that address within therequested time and attempts to
return the same network address each timethe 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 subsequentrequests. The client may
issue a message to release the address backto the server when the
client no longer needs the address. The client may ask for a
permanent assignment by asking for aninfinite lease. Even when
assigning "permanent" addresses, aserver may choose to give out
lengthy but non-infinite leases to allowdetection of the fact that
the client has been retired.
In some environments it will be necessary toreassign network
addresses due to exhaustion of availableaddresses. In such
environments, the allocation mechanism willreuse addresses whose
lease has expired. The server should use whatever information is
available in the configuration informationrepository 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 addressbefore allocating the address,
e.g., with an ICMP echo request, and theclient SHOULD probe the
newly received address, e.g., with ARP.
3. TheClient-Server Protocol
DHCP uses the BOOTP message format definedin 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 aserver to a client.
The first four octets of the 'options' fieldof the DHCP message
contain the (decimal) values 99, 130, 83 and99, respectively (this
is the same magic cookie as is defined in RFC 1497 [17]). The
remainder of the 'options' field consists ofa list of tagged
parameters that are called"options". All of the"vendor extensions"
listed in RFC1497 are also DHCPoptions. RFC1533 gives the
complete set of options defined for use withDHCP.
Several options have been defined sofar. 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 thatinclude a 'DHCP message
type' option will be referred to by the typeof the message; e.g., a
DHCP message with 'DHCP message type' optiontype 1 will be referred
to as a "DHCPDISCOVER" message.
3.1 Client-server interaction- allocating a network address
The following summary of the protocolexchanges between clients and
servers refers to the DHCP messagesdescribed in table 2. The
timeline diagram in figure 3 shows thetiming relationships in a
typical client-server interaction. If the client already knows its
address, some steps may be omitted; thisabbreviated interaction is
described in section 3.2.
1. The client broadcasts a DHCPDISCOVERmessage on its local physical
subnet. The DHCPDISCOVER message MAY include options that suggest
values for the network address and leaseduration. BOOTP relay
agents may pass the message on to DHCPservers not on the same
physical subnet.
2. Each server may respond with a DHCPOFFERmessage that includes an
available network address in the 'yiaddr'field (and other
configuration parameters in DHCPoptions). Servers need not
reserve the offered network address,although the protocol will
work more efficiently if the serveravoids allocating the offered
network address to another client. When allocating a new address,
servers SHOULD check that the offerednetwork address is not
already in use; e.g., the server mayprobe the offered address
with an ICMP Echo Request. Servers SHOULD be implemented so that
network administrators MAY choose todisable probes of newly
allocated addresses. The server transmits the DHCPOFFER message
to the client, using the BOOTP relayagent if necessary.
Message Use
------- ---
DHCPDISCOVER - Client broadcast to locate available servers.
DHCPOFFER - Server to client in response toDHCPDISCOVER with
offer of configurationparameters.
DHCPREQUEST - Client message to serverseither (a) requesting
offered parameters from oneserver and implicitly
declining offers from allothers, (b) confirming
correctness of previouslyallocated address after,
e.g., system reboot, or (c)extending the lease on a
particular network address.
DHCPACK - Server to client with configurationparameters,
including committed networkaddress.
DHCPNAK - Server to client indicatingclient's notion of network
address is incorrect (e.g.,client has moved to new
subnet) or client's lease asexpired
DHCPDECLINE - Client to server indicatingnetwork address is already
in use.
DHCPRELEASE - Client to server relinquishingnetwork address and
cancelling remaining lease.
DHCPINFORM - Client to server, asking onlyfor local configuration
parameters; client alreadyhas externally configured
network address.
Table 2: DHCP messages
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 messagesexchanged between DHCP
client and servers whenallocating a new network address
3. The client receives one or more DHCPOFFERmessages from one or more
servers. The client may choose to wait for multiple responses.
The client chooses one server from whichto request configuration
parameters, based on the configurationparameters 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 MAYinclude other options
specifying desired configurationvalues. The 'requested IP
address' option MUST be set to the valueof 'yiaddr' in the
DHCPOFFER message from the server. This DHCPREQUEST message is
broadcast and relayed through DHCP/BOOTPrelay agents. To help
ensure that any BOOTP relay agents forwardthe DHCPREQUEST message
to the same set of DHCP servers thatreceived the original
DHCPDISCOVER message, the DHCPREQUESTmessage MUST use the same
value in the DHCP message header's 'secs'field and be sent to the
same IP broadcast address as the originalDHCPDISCOVER message.
The client times out and retransmits theDHCPDISCOVER message if
the client receives no DHCPOFFER messages.
4. The servers receive the DHCPREQUESTbroadcast from the client.
Those servers not selected by theDHCPREQUEST message use the
message as notification that the clienthas declined that server's
offer. The server selected in the DHCPREQUEST message commits the
binding for the client to persistentstorage and responds with a
DHCPACK message containing theconfiguration parameters for the
requesting client. The combination of 'client identifier' or
'chaddr' and assigned network addressconstitute a unique
identifier for the client's lease and areused by both the client
and server to identify a lease referred toin any DHCP messages.
Any configuration parameters in theDHCPACK message SHOULD NOT
conflict with those in the earlierDHCPOFFER 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 selectednetwork address.
If the selected server is unable tosatisfy the DHCPREQUEST message
(e.g., the requested network address hasbeen allocated), the
server SHOULD respond with a DHCPNAKmessage.
A server MAY choose to mark addressesoffered to clients in
DHCPOFFER messages as unavailable. The server SHOULD mark an
address offered to a client in a DHCPOFFERmessage as available if
the server receives no DHCPREQUEST messagefrom that client.
5. The client receives the DHCPACK messagewith configuration
parameters. The client SHOULD perform a final check onthe
parameters (e.g., ARP for allocatednetwork address), and notes the
duration of the lease specified in theDHCPACK message. At this
point, the client is configured. If the client detects that the
address is already in use (e.g., throughthe use of ARP), the
client MUST send a DHCPDECLINE message tothe server and restarts
the configuration process. The client SHOULD wait a minimum of ten
seconds before restarting theconfiguration process to avoid
excessive network traffic in case oflooping.
If the client receives a DHCPNAK message,the client restarts the
configuration process.
The client times out and retransmits theDHCPREQUEST message if the
client receives neither a DHCPACK or aDHCPNAK message. The client
retransmits the DHCPREQUEST according tothe retransmission
algorithm in section 4.1. The client should choose to retransmit
the DHCPREQUEST enough times to giveadequate probability of
contacting the server without causing theclient (and the user of
that client) to wait overly long beforegiving up; e.g., a client
retransmitting as described in section 4.1might retransmit the
DHCPREQUEST message four times, for atotal delay of 60 seconds,
before restarting the initializationprocedure. If the client
receives neither a DHCPACK or a DHCPNAKmessage after employing the
retransmission algorithm, the clientreverts to INIT state and
restarts the initialization process. The client SHOULD notify the
user that the initialization process hasfailed and is restarting.
6. The client may choose to relinquish itslease on a network address
by sending a DHCPRELEASE message to theserver. The client
identifies the lease to be released withits 'client identifier',
or 'chaddr' and network address in theDHCPRELEASE message. If the
client used a 'client identifier' when itobtained the lease, it
MUST use the same 'client identifier' inthe DHCPRELEASE message.
3.2 Client-serverinteraction - reusing a previously allocated network
address
If a client remembers and wishes to reuse apreviously allocated
network address, a client may choose to omitsome of the steps
described in the previous section. The timeline diagram in figure 4
shows the timing relationships in a typicalclient-server interaction
for a client reusing a previously allocatednetwork address.
1. The client broadcasts a DHCPREQUESTmessage on its local subnet.
The message includes the client's networkaddress in the
'requested IP address' option. As theclient has not received its
network address, it MUST NOT fill in the'ciaddr' field. BOOTP
relay agents pass the message on to DHCPservers 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'sconfiguration parameters
respond with a DHCPACK message to theclient. Servers SHOULD NOT
check that the client's network addressis already in use; the
client may respond to ICMP Echo Requestmessages 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 messagesexchanged between DHCP
client and servers when reusinga previously allocated
network address
If the client's request is invalid (e.g.,the client has moved
to a new subnet), servers SHOULD respondwith a DHCPNAK message to
the client. Servers SHOULD NOT respond iftheir information is not
guaranteed to be accurate. For example, a server that identifies a
request for an expired binding that isowned by another server SHOULD
NOT respond with a DHCPNAK unless theservers are using an explicit
mechanism to maintain coherency among theservers.
If 'giaddr' is 0x0 in the DHCPREQUESTmessage, the client is on
the same subnet as the server. The server MUST
broadcast the DHCPNAK message to the0xffffffff broadcast address
because the client may not have a correct network address or subnet
mask, and the client may not be answeringARP requests.
Otherwise, the server MUST send theDHCPNAK message to the IP
address of the BOOTP relay agent, asrecorded in 'giaddr'. The
relay agent will, in turn, forward themessage directly to the
client's hardware address, so that theDHCPNAK can be delivered even
if the client has moved to a new network.
3. The client receives the DHCPACK messagewith configuration
parameters. The client performs a final check on theparameters
(as in section 3.1), and notes theduration 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 addressin the DHCPACK message
is already in use, the client MUST send aDHCPDECLINE message to the
server and restarts the configurationprocess by requesting a
new network address. This action corresponds to the client
moving to the INIT state in the DHCPstate 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 configurationprocess, this time
using the (non-abbreviated) proceduredescribed 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 theDHCPREQUEST message if
the client receives neither a DHCPACK nora DHCPNAK message. The
client retransmits the DHCPREQUESTaccording to the retransmission
algorithm in section 4.1. The client should choose to retransmit
the DHCPREQUEST enough times to giveadequate probability of
contacting the server without causing theclient (and the user of
that client) to wait overly long beforegiving up; e.g., a client
retransmitting as described in section4.1 might retransmit the
DHCPREQUEST message four times, for atotal delay of 60 seconds,
before restarting the initializationprocedure. If the client
receives neither a DHCPACK or a DHCPNAKmessage after employing
the retransmission algorithm, the clientMAY choose to use the
previously allocated network address andconfiguration parameters
for the remainder of the unexpiredlease. This corresponds to
moving to BOUND state in the client statetransition diagram shown
in figure 5.
4. The client may choose to relinquish itslease on a network
address by sending a DHCPRELEASE messageto the server. The
client identifies the lease to bereleased with its
'client identifier', or 'chaddr' andnetwork address in the
DHCPRELEASE message.
Note that in this case, where the clientretains its network
address locally, the client will notnormally relinquish its
lease during a graceful shutdown. Only in the case where the
client explicitly needs to relinquish itslease, e.g., the client
is about to be moved to a differentsubnet, will the client send
a DHCPRELEASE message.
3.3 Interpretationand representation of time values
A client acquires a lease for a networkaddress 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 havesynchronized clocks, times are
represented in DHCP messages as relativetimes, to be interpreted
with respect to the client's localclock. Representing relative
times in units of seconds in an unsigned 32bit word gives a range of
relative times from 0 to approximately 100years, which is sufficient
for the relative times to be measured usingDHCP.
The algorithm for lease durationinterpretation given in the previous
paragraph assumes that client and serverclocks are stable relative
to each other. If there is drift between the two clocks, theserver
may consider the lease expired before theclient does. To
compensate, the server may return a shorterlease duration to the
client than the server commits to its localdatabase of client
information.
3.4 Obtainingparameters with externally configured network address
If a client has obtained a network addressthrough some other means
(e.g., manual configuration), it may use aDHCPINFORM request message
to obtain other local configurationparameters. Servers receiving a
DHCPINFORM message construct a DHCPACKmessage with any local
configuration parameters appropriate for theclient without:
allocating a new address, checking for anexisting binding, filling
in 'yiaddr' or including lease timeparameters. The servers SHOULD
unicast the DHCPACK reply to the addressgiven in the 'ciaddr' field
of the DHCPINFORM message.
The server SHOULD check the network addressin a DHCPINFORM message
for consistency, but MUST NOT check for anexisting lease. The
server forms a DHCPACK message containingthe configuration
parameters for the requesting client andsends the DHCPACK message
directly to the client.
3.5 Clientparameters in DHCP
Not all clients require initialization ofall parameters listed in
Appendix A. Two techniques are used to reduce the number of
parameters transmitted from the server tothe client. First, most of
the parameters have defaults defined in theHost Requirements RFCs;
if the client receives no parameters fromthe server that override
the defaults, a client uses those defaultvalues. Second, in its
initial DHCPDISCOVER or DHCPREQUEST message,a client may provide the
server with a list of specific parametersthe client is interested
in. If the client includes a list of parameters in a DHCPDISCOVER
message, it MUST include that list in anysubsequent DHCPREQUEST
messages.
The client SHOULD include the 'maximum DHCPmessage size' option to
let the server know how large the server maymake its DHCP messages.
The parameters returned to a client maystill 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 whichconfiguration 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 valuesfor the network address
and lease time in the DHCPDISCOVERmessage. The client may include
the 'requested IP address' option to suggestthat a particular IP
address be assigned, and may include the 'IPaddress lease time'
option to suggest the lease time it wouldlike. Other options
representing "hints" atconfiguration parameters are allowed in a
DHCPDISCOVER or DHCPREQUEST message. However, additional options may
be ignored by servers, and multiple serversmay, therefore, not
return identical values for some options. The 'requested IP address'
option is to be filled in only in aDHCPREQUEST message when the
client is verifying network parametersobtained previously. The
client fills in the 'ciaddr' field only whencorrectly configured
with an IP address in BOUND, RENEWING orREBINDING state.
If a server receives a DHCPREQUEST messagewith an invalid 'requested
IP address', the server SHOULD respond tothe client with a DHCPNAK
message and may choose to report the problemto the system
administrator. The server may include an error message inthe
'message' option.
3.6 Use of DHCP inclients with multiple interfaces
A client with multiple network interfacesmust use DHCP through each
interface independently to obtainconfiguration information
parameters for those separate interfaces.
3.7 When clientsshould use DHCP
A client SHOULD use DHCP to reacquire orverify its IP address and
network parameters whenever the local networkparameters may have
changed; e.g., at system boot time or aftera disconnection from the
local network, as the local networkconfiguration may change without
the client's or user's knowledge.
If a client has knowledge of a previousnetwork address and is unable
to contact a local DHCP server, the clientmay continue to use the
previous network address until the lease forthat address expires.
If the lease expires before the client cancontact a DHCP server, the
client must immediately discontinue use ofthe previous network
address and may inform local users of theproblem.
4. Specification ofthe DHCP client-server protocol
In this section, we assume that a DHCPserver has a block of network
addresses from which it can satisfy requestsfor new addresses. Each
server also maintains a database ofallocated addresses and leases in
local permanent storage.
4.1 Constructingand sending DHCP messages
DHCP clients and servers both construct DHCPmessages by filling in
fields in the fixed format section of themessage and appending
tagged data items in the variable lengthoption area. The options
area includes first a four-octet 'magiccookie' (which was described
in section 3), followed by the options. The last option must always
be the 'end' option.
DHCP uses UDP as its transportprotocol. 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 sentto the 'DHCP client' port
(68). A server with multiple network address(e.g., a multi-homed
host) MAY use any of its network addressesin outgoing DHCP messages.
The 'server identifier' field is used bothto identify a DHCP server
in aDHCP 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 asidentifying that server
in a DHCP message. To accommodate potentially incomplete network
connectivity, a server MUST choose anaddress as a 'server
identifier' that, to the best of theserver's knowledge, is reachable
from the client. For example, if the DHCP server and the DHCPclient
are connected to the same subnet (i.e., the'giaddr' field in the
message from the client is zero), the serverSHOULD select the IP
address the server is using forcommunication on that subnet as the
'server identifier'. If the server is using multiple IP addresseson
that subnet, any such address may beused. If the server has
received a message through a DHCP relayagent, the server SHOULD
choose an address from the interface onwhich the message was
recieved as the 'server identifier' (unlessthe server has other,
better information on which to make itschoice). DHCP clients MUST
use the IP address provided in the 'serveridentifier' option for any
unicast requests to the DHCP server.
DHCP messages broadcast by a client prior tothat client obtaining
its IP address must have the source addressfield in the IP header
set to 0.
If the 'giaddr' field in a DHCP message froma 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 isnonzero, then the server
unicasts DHCPOFFER and DHCPACK messages tothe address in 'ciaddr'.
If 'giaddr' is zero and 'ciaddr' is zero,and the broadcast bit is
set, then the server broadcasts DHCPOFFERand DHCPACK messages to
0xffffffff. If the broadcast bit is not setand 'giaddr' is zero and
'ciaddr' is zero, then the server unicastsDHCPOFFER and DHCPACK
messages to the client's hardware addressand 'yiaddr' address. In
all cases, when 'giaddr' is zero, the serverbroadcasts any DHCPNAK
messages to 0xffffffff.
If the options in a DHCP message extend intothe 'sname' and 'file'
fields, the 'option overload' option MUSTappear in the 'options'
field, with value 1, 2 or 3, as specified inRFC 1533. If the
'option overload' option is present in the'options' field, the
options in the 'options' field MUST beterminated by an 'end' option,
and MAY contain one or more 'pad' options tofill the options field.
The options in the 'sname' and 'file' fields(if in use as indicated
by the 'options overload' option) MUST beginwith the first octet of
the field, MUST be terminated by an 'end'option, and MUST be
followed by 'pad' options to fill theremainder 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 (ifthe
'option overload' option indicates that the'file' field contains
DHCP options), followed by the 'sname'field.
The values to be passed in an 'option' tagmay 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 optionsdocument. The client concatenates
the values of multiple instances of the sameoption into a single
parameter list for configuration.
DHCP clients are responsible for all messageretransmission. The
client MUST adopt a retransmission strategythat incorporates a
randomized exponential backoff algorithm todetermine the delay
between retransmissions. The delay between retransmissions SHOULD be
chosen to allow sufficient time for repliesfrom the server to be
delivered based on the characteristics ofthe internetwork between
the client and the server. For example, in a 10Mb/sec Ethernet
internetwork, the delay before the firstretransmission SHOULD be 4
seconds randomized by the value of a uniformrandom number chosen
from the range -1 to +1. Clients with clocks that provide resolution
granularity of less than one second maychoose a non-integer
randomization value. The delay before the next retransmissionSHOULD
be 8 seconds randomized by the value of auniform number chosen from
the range -1 to +1. The retransmission delay SHOULD be doubledwith
subsequent retransmissions up to a maximumof 64 seconds. The client
MAY provide an indication of retransmissionattempts to the user as
an indication of the progress of theconfiguration process.
The 'xid' field is used by the client tomatch 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 maychoose a different,
random initial 'xid' each time the client isrebooted, and
subsequently use sequential 'xid's until thenext reboot. Selecting
a new 'xid' for each retransmission is animplementation decision. A
client may choose to reuse the same 'xid' orselect a new 'xid' for
each retransmitted message.
Normally, DHCP servers and BOOTP relayagents attempt to deliver
DHCPOFFER, DHCPACK and DHCPNAK messagesdirectly to the client using
uicast delivery. The IP destination address (in the IP header)is
set to the DHCP 'yiaddr' address and thelink-layer destination
address is set to the DHCP 'chaddr'address. Unfortunately, some
client implementations are unable to receivesuch unicast IP
datagrams until the implementation has beenconfigured with a valid
IP address (leading to a deadlock in whichthe client's IP address
cannot be delivered until the client hasbeen configured with an IP
address).
A client that cannot receive unicast IPdatagrams until its protocol
software has been configured with an IPaddress SHOULD set the
BROADCAST bit in the 'flags' field to 1 inany DHCPDISCOVER or
DHCPREQUEST messages that client sends. The BROADCAST bit will
provide a hint to the DHCP server and BOOTPrelay agent to broadcast
any messages to the client on the client'ssubnet. A client that can
receive unicast IP datagrams before itsprotocol software has been
configured SHOULD clear the BROADCAST bit to0. The BOOTP
clarifications document discusses theramifications of the use of the
BROADCAST bit [21].
A server or relay agent sending or relayinga DHCP message directly
to a DHCP client (i.e., not to a relay agentspecified in the
'giaddr' field) SHOULD examine the BROADCASTbit in the 'flags'
field. If this bit is set to 1, the DHCP message SHOULD be sent as
an IP broadcast using an IP broadcastaddress (preferably 0xffffffff)
as the IP destination address and thelink-layer broadcast address as
the link-layer destination address. If the BROADCAST bit is cleared
to 0, the message SHOULD be sent as an IPunicast to the IP address
specified in the 'yiaddr' field and thelink-layer address specified
in the 'chaddr' field. If unicasting is not possible, the message
MAY be sent as an IP broadcast using an IPbroadcast address
(preferably 0xffffffff) as the IPdestination address and the link-
layer broadcast address as the link-layerdestination address.
4.2 DHCP serveradministrative controls
DHCP servers are not required to respond toevery DHCPDISCOVER and
DHCPREQUEST message they receive. For example, a network
administrator, to retain stringent controlover the clients attached
to the network, may choose to configure DHCPservers to respond only
to clients that have been previouslyregistered through some external
mechanism. The DHCP specification describes only the interactions
between clients and servers when the clientsand servers choose to
interact; it is beyond the scope of the DHCPspecification to
describe all of the administrative controlsthat system
administrators might want to use. Specific DHCP server
implementations may incorporate any controlsor policies desired by a
network administrator.
In some environments, a DHCP server willhave to consider the values
of the vendor class options included inDHCPDISCOVER or DHCPREQUEST
messages when determining the correctparameters for a particular
client.
A DHCP server needs to use some uniqueidentifier to associate a
client with its lease. The client MAY choose to explicitly provide
the identifier through the 'clientidentifier' option. If the client
supplies a 'client identifier', the clientMUST use the same 'client
identifier' in all subsequent messages, andthe server MUST use that
identifier to identify the client. If the client does not provide a
'client identifier' option, the server MUSTuse the contents of the
'chaddr' field to identify the client. It iscrucial for a DHCP
client to use an identifier unique withinthe subnet to which the
client is attached in the 'clientidentifier' option. Use of
'chaddr' as the client's unique identifiermay cause unexpected
results, as that identifier may be associated with a hardware
interface that could be moved to a newclient. Some sites may choose
to use a manufacturer's serial number as the'client identifier', to
avoid unexpected changes in a clients networkaddress 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 aspecific hardware box.
DHCP clients are free to use any strategy inselecting a DHCP server
among those from which the client receives aDHCPOFFER message. The
client implementation of DHCP SHOULD providea mechanism for the user
to select directly the 'vendor classidentifier' values.
4.3 DHCP serverbehavior
A DHCP server processes incoming DHCPmessages from a client based on
the current state of the binding for thatclient. A DHCP server can
receive the following messages from aclient:
o DHCPDISCOVER
o DHCPREQUEST
o DHCPDECLINE
o DHCPRELEASE
o DHCPINFORM
Table 3 gives the use of the fields andoptions in a DHCP message by
a server. The remainder of this section describes the action of the
DHCP server for each possible incomingmessage.
4.3.1 DHCPDISCOVERmessage
When a server receives a DHCPDISCOVERmessage from a client, the
server chooses a network address for therequesting client. If no
address is available, the server may chooseto report the problem to
the system administrator. If an address isavailable, the new address
SHOULD be chosen as follows:
o The client's current address asrecorded in the client's current
binding, ELSE
o The client's previous address asrecorded in the client's (now
expired or released) binding, if thataddress is in the server's
pool of available addresses and notalready allocated, ELSE
o The address requested in the 'RequestedIP Address' option, if that
address is valid and not alreadyallocated, ELSE
o A new address allocated from theserver's pool of available
addresses; the address is selectedbased on the subnet from which
the message was received (if 'giaddr' is 0)or on the address of
the relay agent that forwarded themessage ('giaddr' when not 0).
As described in section 4.2, a server MAY,for administrative
reasons, assign an address other than theone requested, or may
refuse to allocate an address to aparticular 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 physicalnetwork segment), it may be
the case that the DHCP client should beassigned an address from a
different subnet than the address recordedin 'giaddr'. Thus, DHCP
does not require that the client be assignedas address from the
subnet in 'giaddr'. A server is free to choose some other subnet,
and it is beyond the scope of the DHCPspecification to describe ways
in which the assigned IP address might bechosen.
While not required for correct operation ofDHCP, the server SHOULD
NOT reuse the selected network addressbefore 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 expirationtime for the lease, as
follows:
o IF the client has not requested a specificlease in the
DHCPDISCOVER message and the clientalready has an assigned network
address, the server returns the leaseexpiration time previously
assigned to that address (note that theclient must explicitly
request a specific lease to extend theexpiration time on a
previously assigned address), ELSE
o IF the client has not requested a specificlease in the
DHCPDISCOVER message and the client doesnot have an assigned
network address, the server assigns alocally configured default
lease time, ELSE
o IF the client has requested a specificlease in the DHCPDISCOVER
message (regardless of whether the clienthas an assigned network
address), the server may choose either toreturn the requested
lease (if the lease is acceptable to localpolicy) 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 or0
'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
Option DHCPOFFER DHCPACK DHCPNAK
------ --------- ------- -------
Requested IPaddress MUST NOT MUST NOT MUST NOT
IP address leasetime MUST MUST (DHCPREQUEST) MUST NOT
MUST NOT(DHCPINFORM)
Use 'file'/'sname'fields MAY MAY MUST NOT
DHCP messagetype DHCPOFFER DHCPACK DHCPNAK
Parameter requestlist MUST NOT MUST NOT MUST NOT
Message SHOULD SHOULD SHOULD
Clientidentifier MUST NOT MUST NOT MAY
Vendor classidentifier MAY MAY MAY
Serveridentifier MUST MUST MUST
Maximum messagesize 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 beendetermined, the server
constructs a DHCPOFFER message with theoffered configuration
parameters. It is important for all DHCP servers to return the same
parameters (with the possible exception of anewly allocated network
address) to ensure predictable clientbehavior regardless of which
server the client selects. The configuration parameters MUST be
selected by applying the following rules inthe order given below.
The network administrator is responsible forconfiguring multiple
DHCP servers to ensure uniform responsesfrom those servers. The
server MUST return to the client:
o The client's network address, asdetermined by the rules given
earlier in this section,
o The expiration time for the client'slease, 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 explicitlyconfigured with a default
value for the parameter, the serverMUST include that value
in an appropriate option in the'option' field, ELSE
-- IF the server recognizes theparameter as a parameter
defined in the Host RequirementsDocument, the server MUST
include the default value for thatparameter as given in the
Host Requirements Document in anappropriate option in the
'option' field, ELSE
-- The server MUST NOT return a valuefor that parameter,
The server MUST supply as many of therequested parameters as
possible and MUST omit any parameters itcannot provide. The
server MUST include each requestedparameter only once unless
explicitly allowed in the DHCP Options andBOOTP Vendor
Extensions document.
o Any parameters from the existing bindingthat differ from the Host
Requirements Document defaults,
o Any parameters specific to this client (asidentified by
the contents of 'chaddr' or 'clientidentifier' in the DHCPDISCOVER
or DHCPREQUEST message), e.g., asconfigured by the network
administrator,
o Any parameters specific to this client'sclass (as identified
by the contents of the 'vendor classidentifier'
option in the DHCPDISCOVER or DHCPREQUESTmessage),
e.g., as configured by the networkadministrator; the parameters
MUST be identified by an exact matchbetween the client's vendor
class identifiers and the client's classesidentified in the
server,
o Parameters with non-default values on theclient's subnet.
The server MAY choose to return the 'vendorclass identifier' used to
determine the parameters in the DHCPOFFERmessage to assist the
client in selecting which DHCPOFFER toaccept. The server inserts
the 'xid' field from the DHCPDISCOVERmessage into the 'xid' field of
the DHCPOFFER message and sends theDHCPOFFER message to the
requesting client.
4.3.2 DHCPREQUESTmessage
A DHCPREQUEST message may come from a clientresponding to a
DHCPOFFER message from a server, from aclient verifying a previously
allocated IP address or from a clientextending the lease on a
network address. If the DHCPREQUEST message contains a 'server
identifier' option, the message is inresponse 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 includeda list of requested
parameters in a DHCPDISCOVER message, itMUST include that list in
all subsequent messages.
Any configuration parameters in the DHCPACKmessage SHOULD NOT
conflict with those in the earlier DHCPOFFERmessage to which the
client is responding. The client SHOULD use the parameters in the
DHCPACK message for configuration.
Clients send DHCPREQUEST messages asfollows:
o DHCPREQUEST generated during SELECTINGstate:
Client inserts the address of theselected server in 'server
identifier', 'ciaddr' MUST be zero,'requested IP address' MUST be
filled in with the yiaddr value from thechosen DHCPOFFER.
Note that the client may choose tocollect several DHCPOFFER
messages and select the "best"offer. The client indicates its
selection by identifying the offeringserver in the DHCPREQUEST
message. If the client receives no acceptable offers, the client
may choose to try another DHCPDISCOVERmessage. Therefore, the
servers may not receive a specificDHCPREQUEST from which they can
decide whether or not the client hasaccepted the offer. Because
the servers have not committed anynetwork address assignments on
the basis of a DHCPOFFER, servers arefree to reuse offered
network addresses in response tosubsequent requests. As an
implementation detail, servers SHOULD NOTreuse offered addresses
and may use an implementation-specific timeoutmechanism to decide
when to reuse an offered address.
o DHCPREQUEST generated during INIT-REBOOTstate:
'server identifier' MUST NOT be filledin, 'requested IP address'
option MUST be filled in with client'snotion of its previously
assigned address. 'ciaddr' MUST be zero.The client is seeking to
verify a previously allocated, cachedconfiguration. Server SHOULD
send a DHCPNAK message to the client ifthe 'requested IP address'
is incorrect, or is on the wrong network.
Determining whether a client in theINIT-REBOOT state is on the
correct network is done by examining thecontents of 'giaddr', the
'requested IP address' option, and adatabase lookup. If the DHCP
server detects that the client is on thewrong net (i.e., the
result of applying the local subnet maskor remote subnet mask (if
'giaddr' is not zero) to 'requested IPaddress' option value
doesn't match reality), then the serverSHOULD send a DHCPNAK
message to the client.
If the network is correct, then the DHCPserver should check if
the client's notion of its IP address iscorrect. If not, then the
server SHOULD send a DHCPNAK message tothe client. If the DHCP
server has no record of this client, thenit MUST remain silent,
and MAY output a warning to the networkadministrator. This
behavior is necessary for peacefulcoexistence of non-
communicating DHCP servers on the samewire.
If 'giaddr' is 0x0 in the DHCPREQUESTmessage, the client is on
the same subnet as the server. The server MUST broadcast the
DHCPNAK message to the 0xffffffffbroadcast address because the
client may not have a correct networkaddress or subnet mask, and
the client may not be answering ARPrequests.
If 'giaddr' is set in the DHCPREQUESTmessage, the client is on a
different subnet. The server MUST set the broadcast bit in the
DHCPNAK, so that the relay agent willbroadcast the DHCPNAK to the
client, because the client may not have acorrect network address
or subnet mask, and the client may not beanswering ARP requests.
o DHCPREQUEST generated during RENEWINGstate:
'server identifier' MUST NOT be filledin, '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 itslease. This message will
be unicast, so no relay agents will beinvolved 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 extendits lease prior to T1. The
server may choose not to extend the lease(as a policy decision by
the network administrator), but shouldreturn a DHCPACK message
regardless.
o DHCPREQUEST generated during REBINDINGstate:
'server identifier' MUST NOT be filledin, '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 itslease. This message MUST
be broadcast to the 0xffffffff IPbroadcast address. The DHCP
server SHOULD check 'ciaddr' forcorrectness before replying to
the DHCPREQUEST.
The DHCPREQUEST from a REBINDING clientis intended to accommodate
sites that have multiple DHCP servers anda mechanism for
maintaining consistency among leasesmanaged by multiple servers.
A DHCP server MAY extend a client's leaseonly if it has local
administrative authority to do so.
4.3.3 DHCPDECLINEmessage
If the server receives a DHCPDECLINEmessage, the client has
discovered through some other means that thesuggested network
address is already in use. The server MUST mark the network address
as not available and SHOULD notify the localsystem administrator of
a possible configuration problem.
4.3.4 DHCPRELEASEmessage
Upon receipt of a DHCPRELEASE message, theserver marks the network
address as not allocated. The server SHOULD retain a record of the
client's initialization parameters forpossible reuse in response to
subsequent requests from the client.
4.3.5 DHCPINFORMmessage
The server responds to a DHCPINFORM messageby sending a DHCPACK
message directly to the address given in the'ciaddr' field of the
DHCPINFORM message. The server MUST NOT send a lease expirationtime
to the client and SHOULD NOT fill in'yiaddr'. The server includes
other parameters in the DHCPACK message asdefined in section 4.3.1.
4.3.6 Clientmessages
Table 4 details the differences betweenmessages 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 fromdifferent states
4.4 DHCP clientbehavior
Figure 5 gives a state-transition diagramfor a DHCP client. A
client can receive the following messagesfrom a server:
o DHCPOFFER
o DHCPACK
o DHCPNAK
The DHCPINFORM message is not shown infigure 5. A client simply
sends the DHCPINFORM and waits for DHCPACKmessages. Once the client
has selected its parameters, it hascompleted the configuration
process.
Table 5 gives the use of the fields andoptions in a DHCP message by
a client. The remainder of this section describes the action of the
DHCP client for each possible incomingmessage. The description in
the following section corresponds to thefull configuration procedure
previously described in section 3.1, and thetext in the subsequent
section corresponds to the abbreviatedconfiguration procedure
described in section 3.2.
-------- -------
| | +-------------------------->| |<-------------------+
| INIT- | | +-------------------->| INIT | |
| REBOOT|DHCPNAK/ +---------->| |<---+ |
| |Restart| | ------- | |
-------- | DHCPNAK/ | | |
| Discard offer | -/Send DHCPDISCOVER |
-/SendDHCPREQUEST | | |
| | | 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
4.4.1 Initializationand allocation of network address
The client begins in INIT state and forms aDHCPDISCOVER message.
The client SHOULD wait a random time betweenone and ten seconds to
desynchronize the use of DHCP atstartup. The client sets 'ciaddr'
to0x00000000. The client MAY requestspecific parameters by
including the 'parameter request list'option. The client MAY
suggest a network address and/or lease timeby including the
'requested IP address' and 'IP address leasetime' options. The
client MUST include its hardware address inthe 'chaddr' field, if
necessary for delivery of DHCP replymessages. 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 DHCPDISCOVERmessage, it MUST include
that list in all subsequent messages.
The client generates and records a randomtransaction identifier and
inserts that identifier into the 'xid' field. The client records its
own local time for later use in computingthe lease expiration. The
client then broadcasts the DHCPDISCOVER onthe local hardware
broadcast address to the 0xffffffff IPbroadcast address and 'DHCP
server' UDP port.
If the 'xid' of an arriving DHCPOFFERmessage does not match the
'xid' of the most recent DHCPDISCOVERmessage, the DHCPOFFER message
must be silently discarded. Any arriving DHCPACK messages must be
silently discarded.
The client collects DHCPOFFER messages overa period of time, selects
one DHCPOFFER message from the (possiblymany) incoming DHCPOFFER
messages (e.g., the first DHCPOFFER messageor the DHCPOFFER message
from the previously used server) andextracts the server address from
the 'server identifier' option in theDHCPOFFER message. The time
over which the client collects messages andthe mechanism used to
select one DHCPOFFER are implementationdependent.
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
DHCPOFFERmessage 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)
Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPINFORM DHCPRELEASE
------ ------------ ----------- -----------
Requested IPaddress MAY MUST (in MUST
(DISCOVER) SELECTING or (DHCPDECLINE),
MUST NOT INIT-REBOOT) MUST NOT
(INFORM) MUST NOT (in (DHCPRELEASE)
BOUNDor
RENEWING)
IP address leasetime MAY MAY MUST NOT
(DISCOVER)
MUST NOT
(INFORM)
Use 'file'/'sname'fields MAY MAY MAY
DHCP messagetype DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/
DHCPINFORM DHCPRELEASE
Clientidentifier MAY MAY MAY
Vendor classidentifier MAY MAY MUST NOT
Serveridentifier MUST NOT MUST (after MUST
SELECTING)
MUSTNOT (after
INIT-REBOOT,
BOUND,RENEWING
orREBINDING)
Parameter requestlist MAY MAY MUST NOT
Maximum messagesize 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 clientrecords the address of
the server that supplied the parameters fromthe 'server identifier'
field and sends that address in the 'serveridentifier' field of a
DHCPREQUEST broadcast message. Once the DHCPACK message from the
server arrives, the client is initializedand 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 wassent and the duration of
the lease from the DHCPACK message. The client SHOULD perform a
check on the suggested address to ensurethat the address is not
already in use. For example, if the client is on a networkthat
supports ARP, the client may issue an ARPrequest for the suggested
request. When broadcasting an ARP request for the suggested address,
the client must fill in its own hardwareaddress as the sender's
hardware address, and 0 as the sender's IPaddress, to avoid
confusing ARP caches in other hosts on thesame subnet. If the
network address appears to be in use, theclient MUST send a
DHCPDECLINE message to the server. Theclient SHOULD broadcast an ARP
reply to announce the client's new IPaddress and clear any outdated
ARP cache entries in hosts on the client'ssubnet.
4.4.2Initialization with known network address
The client begins in INIT-REBOOT state andsends a DHCPREQUEST
message. The client MUST insert its known network address as a
'requested IP address' option in theDHCPREQUEST message. The client
may request specific configurationparameters by including the
'parameter request list' option. The client generates and records a
random transaction identifier and insertsthat 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 DHCPREQUESTmessage. The client then
broadcasts the DHCPREQUEST on the localhardware broadcast address to
the 'DHCP server' UDP port.
Once a DHCPACK message with an 'xid' fieldmatching that in the
client's DHCPREQUEST message arrives fromany server, the client is
initialized and moves to BOUND state. The client records the lease
expiration time as the sum of the time atwhich the DHCPREQUEST
message was sent and the duration of thelease from the DHCPACK
message.
4.4.3Initialization with an externally assigned network address
The client sends a DHCPINFORM message. Theclient may request
specific configuration parameters byincluding the 'parameter request
list' option. The client generates andrecords a random transaction
identifier and inserts that identifier intothe 'xid' field. The
client places its own network address in the'ciaddr' field. The
client SHOULD NOT request lease timeparameters.
The client then unicasts the DHCPINFORM tothe DHCP server if it
knows the server's address, otherwise itbroadcasts 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' fieldmatching that in the
client's DHCPINFORM message arrives from anyserver, the client is
initialized.
If the client does not receive a DHCPACKwithin a reasonable period
of time (60 seconds or 4 tries if usingtimeout suggested in section
4.1), then it SHOULD display a messageinforming the user of the
problem, and then SHOULD begin networkprocessing using suitable
defaults as per Appendix A.
4.4.4 Use ofbroadcast and unicast
The DHCP client broadcasts DHCPDISCOVER,DHCPREQUEST and DHCPINFORM
messages, unless the client knows theaddress of a DHCP server. The
client unicasts DHCPRELEASE messages to theserver. Because the
client is declining the use of the IPaddress supplied by the server,
the client broadcasts DHCPDECLINE messages.
Whenthe DHCP client knows the address of a DHCP server, in either
INIT or REBOOTING state, the client may usethat address in the
DHCPDISCOVER or DHCPREQUEST rather than theIP broadcast address.
The client may also use unicast to sendDHCPINFORM messages to a
known DHCP server. If the client receives no response to DHCP
messages sent to the IP address of a knownDHCP server, the DHCP
client reverts to using the IP broadcastaddress.
4.4.5 Reacquisitionand expiration
The client maintains two times, T1 and T2,that specify the times at
which the client tries to extend its leaseon its network address.
T1 is the time at which the client entersthe RENEWING state and
attempts to contact the server that originallyissued the client's
network address. T2 is the time at which the client enters the
REBINDING state and attempts to contact anyserver. T1 MUST be
earlier than T2, which, in turn, MUST beearlier 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 RENEWINGstate and sends (via unicast)
a DHCPREQUEST message to the server toextend its lease. The client
sets the 'ciaddr' field in the DHCPREQUESTto its current network
address. The client records the local timeat which the DHCPREQUEST
message is sent for computation of the leaseexpiration 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 DHCPREQUESTmessage are silently discarded.
When the client receives a DHCPACK from theserver, the client
computes the lease expiration time as thesum of the time at which
the client sent the DHCPREQUEST message andthe duration of the lease
in the DHCPACK message. The client has successfully reacquired its
network address, returns to BOUND state andmay continue network
processing.
If no DHCPACK arrives before time T2, theclient moves to REBINDING
state and sends (via broadcast) aDHCPREQUEST 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 theserver 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 fixedvalue, to avoid synchronization of
client reacquisition.
A client MAY choose to renew or extend itslease prior to T1. The
server MAY choose to extend the client'slease according to policy
set by the network administrator. The server SHOULD return T1 and
T2, and their values SHOULD be adjusted fromtheir original values to
take account of the time remaining on thelease.
In both RENEWING and REBINDING states, ifthe client receives no
response to its DHCPREQUEST message, theclient SHOULD wait one-half
of the remaining time until T2 (in RENEWINGstate) and one-half of
the remaining lease time (in REBINDING state),down to a minimum of
60 seconds, before retransmitting theDHCPREQUEST message.
If the lease expires before the clientreceives a DHCPACK, the client
moves to INIT state, MUST immediately stopany other network
processing and requests networkinitialization parameters as if the
client were uninitialized. If the client then receives a DHCPACK
allocating that client its previous networkaddress, the client
SHOULD continue network processing. If the client is given a new
network address, it MUST NOT continue usingthe previous network
address and SHOULD notify the local users ofthe problem.
4.4.6 DHCPRELEASE
If the client no longer requires use of itsassigned 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 transmissionof DHCPRELEASE messages.
5. Acknowledgments
The author thanks the many (and too numerousto mention!) members of
the DHC WG for their tireless and ongoingefforts in the development
of DHCP and this document.
The efforts of J Allard, Mike Carney, DaveLapp, Fred Lien and John
Mendonca in organizing DHCP interoperabilitytesting sessions are
gratefully acknowledged.
The development of this document wassupported in part by grants from
the Corporation for National ResearchInitiatives (CNRI), Bucknell
University and Sun Microsystems.
6. References
[1] Acetta, M., "Resource LocationProtocol", RFC887, CMU, December
1983.
[2] Alexander, S., and R. Droms, "DHCPOptions and BOOTP Vendor
Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
University, October 1993.
[3] Braden, R., Editor, "Requirementsfor Internet Hosts --
Communication Layers", STD 3, RFC 1122, USC/Information Sciences
Institute, October 1989.
[4] Braden, R., Editor, "Requirementsfor Internet Hosts --
Application and Support, STD 3, RFC 1123, USC/Information
Sciences Institute, October 1989.
[5] Brownell, D, "Dynamic ReverseAddress Resolution Protocol
(DRARP)", Work in Progress.
[6] Comer, D., and R. Droms, "UniformAccess 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)", RFC951,
Stanford and SUN Microsystems, September1985.
[8] Deering, S., "ICMP Router DiscoveryMessages", RFC1256, Xerox
PARC, September 1991.
[9] Droms, D., "Interoperation betweenDHCP and BOOTP", RFC1534,
Bucknell University, October 1993.
[10] Finlayson, R., Mann, T., Mogul, J., andM. 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 CacheConsistency", In Proc. of
the Twelfth ACM Symposium on OperatingSystems Design, 1989.
[12] Mockapetris, P., "Domain Names --Concepts and Facilities", STD
13, RFC1034,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, "PathMTU Discovery", RFC1191,
November 1990.
[15] Morgan, R., "Dynamic IP AddressAssignment for Ethernet Attached
Hosts", Work in Progress.
[16] Postel, J., "Internet ControlMessage Protocol", STD 5, RFC792,
USC/Information Sciences Institute,September 1981.
[17] Reynolds, J., "BOOTP VendorInformation Extensions", RFC1497,
USC/Information Sciences Institute,August 1993.
[18] Reynolds, J., and J. Postel,"Assigned Numbers", STD 2, RFC1700,
USC/Information Sciences Institute,October 1994.
[19] Jeffrey Schiller and Mark Rosenstein. AProtocol for the Dynamic
Assignment of IP Addresses for use onan 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 andExtensions for the Bootstrap
Protocol", RFC 1542, Carnegie Mellon University, October 1993.
7. SecurityConsiderations
DHCP is built directly on UDP and IP whichare as yet inherently
insecure. Furthermore, DHCP is generally intended to make
maintenance of remote and/or diskless hostseasier. While perhaps
not impossible, configuring such hosts withpasswords or keys may be
difficult and inconvenient. Therefore, DHCP in its current form is
quite insecure.
Unauthorized DHCP servers may be easily setup. Such servers can
then send false and potentially disruptiveinformation to clients
such as incorrect or duplicate IP addresses,incorrect routing
information (including spoof routers, etc.),incorrect domain
nameserver addresses (such as spoofnameservers), and so on.
Clearly, once this seed information is inplace, an attacker can
further compromise affected systems.
Malicious DHCP clients could masquerade aslegitimate clients and
retrieve information intended for thoselegitimate clients. Where
dynamic allocation of resources is used, amalicious client could
claim all resources for itself, therebydenying 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: [email protected]
A. HostConfiguration 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 (RFC894/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)