| blob | f45d9b864a24432c66f43d7a08e9a9390d36114d |
7 Network Working Group R. Droms
8 Request for Comments: 2131 Bucknell University
9 Obsoletes: 1541 March 1997
10 Category: Standards Track
12 Dynamic Host Configuration Protocol
14 Status of this memo
16 This document specifies an Internet standards track protocol for the
17 Internet community, and requests discussion and suggestions for
18 improvements. Please refer to the current edition of the "Internet
19 Official Protocol Standards" (STD 1) for the standardization state
20 and status of this protocol. Distribution of this memo is unlimited.
22 Abstract
24 The Dynamic Host Configuration Protocol (DHCP) provides a framework
25 for passing configuration information to hosts on a TCPIP network.
26 DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the
27 capability of automatic allocation of reusable network addresses and
28 additional configuration options [19]. DHCP captures the behavior of
29 BOOTP relay agents [7, 21], and DHCP participants can interoperate
30 with BOOTP participants [9].
32 Table of Contents
34 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
35 1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 3
36 1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
37 1.3 Problem definition and issues . . . . . . . . . . . . . . . . 4
38 1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5
39 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
40 1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6
41 2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8
42 2.1 Configuration parameters repository . . . . . . . . . . . . . 11
43 2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12
44 3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13
45 3.1 Client-server interaction - allocating a network address. . . 13
46 3.2 Client-server interaction - reusing a previously allocated
47 network address . . . . . . . . . . . . . . . . . . . . . . . 17
48 3.3 Interpretation and representation of time values. . . . . . . 20
49 3.4 Obtaining parameters with externally configured network
50 address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
51 3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21
52 3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22
53 3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22
54 4. Specification of the DHCP client-server protocol. . . . . . . 22
58 Droms Standards Track [Page 1]
59 \f
60 RFC 2131 Dynamic Host Configuration Protocol March 1997
63 4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22
64 4.2 DHCP server administrative controls . . . . . . . . . . . . . 25
65 4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 26
66 4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 34
67 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .42
68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . .42
69 7. Security Considerations. . . . . . . . . . . . . . . . . . . .43
70 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .44
71 A. Host Configuration Parameters . . . . . . . . . . . . . . . .45
72 List of Figures
73 1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9
74 2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11
75 3. Timeline diagram of messages exchanged between DHCP client and
76 servers when allocating a new network address. . . . . . . . . 15
77 4. Timeline diagram of messages exchanged between DHCP client and
78 servers when reusing a previously allocated network address. . 18
79 5. State-transition diagram for DHCP clients. . . . . . . . . . . 34
80 List of Tables
81 1. Description of fields in a DHCP message. . . . . . . . . . . . 10
82 2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 14
83 3. Fields and options used by DHCP servers. . . . . . . . . . . . 28
84 4. Client messages from various states. . . . . . . . . . . . . . 33
85 5. Fields and options used by DHCP clients. . . . . . . . . . . . 37
87 1. Introduction
89 The Dynamic Host Configuration Protocol (DHCP) provides configuration
90 parameters to Internet hosts. DHCP consists of two components: a
91 protocol for delivering host-specific configuration parameters from a
92 DHCP server to a host and a mechanism for allocation of network
93 addresses to hosts.
95 DHCP is built on a client-server model, where designated DHCP server
96 hosts allocate network addresses and deliver configuration parameters
97 to dynamically configured hosts. Throughout the remainder of this
98 document, the term "server" refers to a host providing initialization
99 parameters through DHCP, and the term "client" refers to a host
100 requesting initialization parameters from a DHCP server.
102 A host should not act as a DHCP server unless explicitly configured
103 to do so by a system administrator. The diversity of hardware and
104 protocol implementations in the Internet would preclude reliable
105 operation if random hosts were allowed to respond to DHCP requests.
106 For example, IP requires the setting of many parameters within the
107 protocol implementation software. Because IP can be used on many
108 dissimilar kinds of network hardware, values for those parameters
109 cannot be guessed or assumed to have correct defaults. Also,
110 distributed address allocation schemes depend on a polling/defense
114 Droms Standards Track [Page 2]
115 \f
116 RFC 2131 Dynamic Host Configuration Protocol March 1997
119 mechanism for discovery of addresses that are already in use. IP
120 hosts may not always be able to defend their network addresses, so
121 that such a distributed address allocation scheme cannot be
122 guaranteed to avoid allocation of duplicate network addresses.
124 DHCP supports three mechanisms for IP address allocation. In
125 "automatic allocation", DHCP assigns a permanent IP address to a
126 client. In "dynamic allocation", DHCP assigns an IP address to a
127 client for a limited period of time (or until the client explicitly
128 relinquishes the address). In "manual allocation", a client's IP
129 address is assigned by the network administrator, and DHCP is used
130 simply to convey the assigned address to the client. A particular
131 network will use one or more of these mechanisms, depending on the
132 policies of the network administrator.
134 Dynamic allocation is the only one of the three mechanisms that
135 allows automatic reuse of an address that is no longer needed by the
136 client to which it was assigned. Thus, dynamic allocation is
137 particularly useful for assigning an address to a client that will be
138 connected to the network only temporarily or for sharing a limited
139 pool of IP addresses among a group of clients that do not need
140 permanent IP addresses. Dynamic allocation may also be a good choice
141 for assigning an IP address to a new client being permanently
142 connected to a network where IP addresses are sufficiently scarce
143 that it is important to reclaim them when old clients are retired.
144 Manual allocation allows DHCP to be used to eliminate the error-prone
145 process of manually configuring hosts with IP addresses in
146 environments where (for whatever reasons) it is desirable to manage
147 IP address assignment outside of the DHCP mechanisms.
149 The format of DHCP messages is based on the format of BOOTP messages,
150 to capture the BOOTP relay agent behavior described as part of the
151 BOOTP specification [7, 21] and to allow interoperability of existing
152 BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates
153 the necessity of having a DHCP server on each physical network
154 segment.
156 1.1 Changes to RFC 1541
158 This document updates the DHCP protocol specification that appears in
159 RFC1541. A new DHCP message type, DHCPINFORM, has been added; see
160 section 3.4, 4.3 and 4.4 for details. The classing mechanism for
161 identifying DHCP clients to DHCP servers has been extended to include
162 "vendor" classes as defined in sections 4.2 and 4.3. The minimum
163 lease time restriction has been removed. Finally, many editorial
164 changes have been made to clarify the text as a result of experience
165 gained in DHCP interoperability tests.
170 Droms Standards Track [Page 3]
171 \f
172 RFC 2131 Dynamic Host Configuration Protocol March 1997
175 1.2 Related Work
177 There are several Internet protocols and related mechanisms that
178 address some parts of the dynamic host configuration problem. The
179 Reverse Address Resolution Protocol (RARP) [10] (through the
180 extensions defined in the Dynamic RARP (DRARP) [5]) explicitly
181 addresses the problem of network address discovery, and includes an
182 automatic IP address assignment mechanism. The Trivial File Transfer
183 Protocol (TFTP) [20] provides for transport of a boot image from a
184 boot server. The Internet Control Message Protocol (ICMP) [16]
185 provides for informing hosts of additional routers via "ICMP
186 redirect" messages. ICMP also can provide subnet mask information
187 through the "ICMP mask request" message and other information through
188 the (obsolete) "ICMP information request" message. Hosts can locate
189 routers through the ICMP router discovery mechanism [8].
191 BOOTP is a transport mechanism for a collection of configuration
192 information. BOOTP is also extensible, and official extensions [17]
193 have been defined for several configuration parameters. Morgan has
194 proposed extensions to BOOTP for dynamic IP address assignment [15].
195 The Network Information Protocol (NIP), used by the Athena project at
196 MIT, is a distributed mechanism for dynamic IP address assignment
197 [19]. The Resource Location Protocol RLP [1] provides for location
198 of higher level services. Sun Microsystems diskless workstations use
199 a boot procedure that employs RARP, TFTP and an RPC mechanism called
200 "bootparams" to deliver configuration information and operating
201 system code to diskless hosts. (Sun Microsystems, Sun Workstation
202 and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun
203 networks also use DRARP and an auto-installation mechanism to
204 automate the configuration of new hosts in an existing network.
206 In other related work, the path minimum transmission unit (MTU)
207 discovery algorithm can determine the MTU of an arbitrary internet
208 path [14]. The Address Resolution Protocol (ARP) has been proposed
209 as a transport protocol for resource location and selection [6].
210 Finally, the Host Requirements RFCs [3, 4] mention specific
211 requirements for host reconfiguration and suggest a scenario for
212 initial configuration of diskless hosts.
214 1.3 Problem definition and issues
216 DHCP is designed to supply DHCP clients with the configuration
217 parameters defined in the Host Requirements RFCs. After obtaining
218 parameters via DHCP, a DHCP client should be able to exchange packets
219 with any other host in the Internet. The TCP/IP stack parameters
220 supplied by DHCP are listed in Appendix A.
226 Droms Standards Track [Page 4]
227 \f
228 RFC 2131 Dynamic Host Configuration Protocol March 1997
231 Not all of these parameters are required for a newly initialized
232 client. A client and server may negotiate for the transmission of
233 only those parameters required by the client or specific to a
234 particular subnet.
236 DHCP allows but does not require the configuration of client
237 parameters not directly related to the IP protocol. DHCP also does
238 not address registration of newly configured clients with the Domain
239 Name System (DNS) [12, 13].
241 DHCP is not intended for use in configuring routers.
243 1.4 Requirements
245 Throughout this document, the words that are used to define the
246 significance of particular requirements are capitalized. These words
247 are:
249 o "MUST"
251 This word or the adjective "REQUIRED" means that the
252 item is an absolute requirement of this specification.
254 o "MUST NOT"
256 This phrase means that the item is an absolute prohibition
257 of this specification.
259 o "SHOULD"
261 This word or the adjective "RECOMMENDED" means that there
262 may exist valid reasons in particular circumstances to ignore
263 this item, but the full implications should be understood and
264 the case carefully weighed before choosing a different course.
266 o "SHOULD NOT"
268 This phrase means that there may exist valid reasons in
269 particular circumstances when the listed behavior is acceptable
270 or even useful, but the full implications should be understood
271 and the case carefully weighed before implementing any behavior
272 described with this label.
282 Droms Standards Track [Page 5]
283 \f
284 RFC 2131 Dynamic Host Configuration Protocol March 1997
287 o "MAY"
289 This word or the adjective "OPTIONAL" means that this item is
290 truly optional. One vendor may choose to include the item
291 because a particular marketplace requires it or because it
292 enhances the product, for example; another vendor may omit the
293 same item.
295 1.5 Terminology
297 This document uses the following terms:
299 o "DHCP client"
301 A DHCP client is an Internet host using DHCP to obtain
302 configuration parameters such as a network address.
304 o "DHCP server"
306 A DHCP server is an Internet host that returns configuration
307 parameters to DHCP clients.
309 o "BOOTP relay agent"
311 A BOOTP relay agent or relay agent is an Internet host or router
312 that passes DHCP messages between DHCP clients and DHCP servers.
313 DHCP is designed to use the same relay agent behavior as specified
314 in the BOOTP protocol specification.
316 o "binding"
318 A binding is a collection of configuration parameters, including
319 at least an IP address, associated with or "bound to" a DHCP
320 client. Bindings are managed by DHCP servers.
322 1.6 Design goals
324 The following list gives general design goals for DHCP.
326 o DHCP should be a mechanism rather than a policy. DHCP must
327 allow local system administrators control over configuration
328 parameters where desired; e.g., local system administrators
329 should be able to enforce local policies concerning allocation
330 and access to local resources where desired.
338 Droms Standards Track [Page 6]
339 \f
340 RFC 2131 Dynamic Host Configuration Protocol March 1997
343 o Clients should require no manual configuration. Each client
344 should be able to discover appropriate local configuration
345 parameters without user intervention and incorporate those
346 parameters into its own configuration.
348 o Networks should require no manual configuration for individual
349 clients. Under normal circumstances, the network manager
350 should not have to enter any per-client configuration
351 parameters.
353 o DHCP should not require a server on each subnet. To allow for
354 scale and economy, DHCP must work across routers or through the
355 intervention of BOOTP relay agents.
357 o A DHCP client must be prepared to receive multiple responses
358 to a request for configuration parameters. Some installations
359 may include multiple, overlapping DHCP servers to enhance
360 reliability and increase performance.
362 o DHCP must coexist with statically configured, non-participating
363 hosts and with existing network protocol implementations.
365 o DHCP must interoperate with the BOOTP relay agent behavior as
366 described by RFC 951 and by RFC 1542 [21].
368 o DHCP must provide service to existing BOOTP clients.
370 The following list gives design goals specific to the transmission of
371 the network layer parameters. DHCP must:
373 o Guarantee that any specific network address will not be in
374 use by more than one DHCP client at a time,
376 o Retain DHCP client configuration across DHCP client reboot. A
377 DHCP client should, whenever possible, be assigned the same
378 configuration parameters (e.g., network address) in response
379 to each request,
381 o Retain DHCP client configuration across server reboots, and,
382 whenever possible, a DHCP client should be assigned the same
383 configuration parameters despite restarts of the DHCP mechanism,
385 o Allow automated assignment of configuration parameters to new
386 clients to avoid hand configuration for new clients,
388 o Support fixed or permanent allocation of configuration
389 parameters to specific clients.
394 Droms Standards Track [Page 7]
395 \f
396 RFC 2131 Dynamic Host Configuration Protocol March 1997
399 2. Protocol Summary
401 From the client's point of view, DHCP is an extension of the BOOTP
402 mechanism. This behavior allows existing BOOTP clients to
403 interoperate with DHCP servers without requiring any change to the
404 clients' initialization software. RFC 1542 [2] details the
405 interactions between BOOTP and DHCP clients and servers [9]. There
406 are some new, optional transactions that optimize the interaction
407 between DHCP clients and servers that are described in sections 3 and
408 4.
410 Figure 1 gives the format of a DHCP message and table 1 describes
411 each of the fields in the DHCP message. The numbers in parentheses
412 indicate the size of each field in octets. The names for the fields
413 given in the figure will be used throughout this document to refer to
414 the fields in DHCP messages.
416 There are two primary differences between DHCP and BOOTP. First,
417 DHCP defines mechanisms through which clients can be assigned a
418 network address for a finite lease, allowing for serial reassignment
419 of network addresses to different clients. Second, DHCP provides the
420 mechanism for a client to acquire all of the IP configuration
421 parameters that it needs in order to operate.
423 DHCP introduces a small change in terminology intended to clarify the
424 meaning of one of the fields. What was the "vendor extensions" field
425 in BOOTP has been re-named the "options" field in DHCP. Similarly,
426 the tagged data items that were used inside the BOOTP "vendor
427 extensions" field, which were formerly referred to as "vendor
428 extensions," are now termed simply "options."
450 Droms Standards Track [Page 8]
451 \f
452 RFC 2131 Dynamic Host Configuration Protocol March 1997
455 0 1 2 3
456 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
457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
458 | op (1) | htype (1) | hlen (1) | hops (1) |
459 +---------------+---------------+---------------+---------------+
460 | xid (4) |
461 +-------------------------------+-------------------------------+
462 | secs (2) | flags (2) |
463 +-------------------------------+-------------------------------+
464 | ciaddr (4) |
465 +---------------------------------------------------------------+
466 | yiaddr (4) |
467 +---------------------------------------------------------------+
468 | siaddr (4) |
469 +---------------------------------------------------------------+
470 | giaddr (4) |
471 +---------------------------------------------------------------+
472 | |
473 | chaddr (16) |
474 | |
475 | |
476 +---------------------------------------------------------------+
477 | |
478 | sname (64) |
479 +---------------------------------------------------------------+
480 | |
481 | file (128) |
482 +---------------------------------------------------------------+
483 | |
484 | options (variable) |
485 +---------------------------------------------------------------+
487 Figure 1: Format of a DHCP message
489 DHCP defines a new 'client identifier' option that is used to pass an
490 explicit client identifier to a DHCP server. This change eliminates
491 the overloading of the 'chaddr' field in BOOTP messages, where
492 'chaddr' is used both as a hardware address for transmission of BOOTP
493 reply messages and as a client identifier. The 'client identifier'
494 is an opaque key, not to be interpreted by the server; for example,
495 the 'client identifier' may contain a hardware address, identical to
496 the contents of the 'chaddr' field, or it may contain another type of
497 identifier, such as a DNS name. The 'client identifier' chosen by a
498 DHCP client MUST be unique to that client within the subnet to which
499 the client is attached. If the client uses a 'client identifier' in
500 one message, it MUST use that same identifier in all subsequent
501 messages, to ensure that all servers correctly identify the client.
506 Droms Standards Track [Page 9]
507 \f
508 RFC 2131 Dynamic Host Configuration Protocol March 1997
511 DHCP clarifies the interpretation of the 'siaddr' field as the
512 address of the server to use in the next step of the client's
513 bootstrap process. A DHCP server may return its own address in the
514 'siaddr' field, if the server is prepared to supply the next
515 bootstrap service (e.g., delivery of an operating system executable
516 image). A DHCP server always returns its own address in the 'server
517 identifier' option.
519 FIELD OCTETS DESCRIPTION
520 ----- ------ -----------
522 op 1 Message op code / message type.
523 1 = BOOTREQUEST, 2 = BOOTREPLY
524 htype 1 Hardware address type, see ARP section in "Assigned
525 Numbers" RFC; e.g., '1' = 10mb ethernet.
526 hlen 1 Hardware address length (e.g. '6' for 10mb
527 ethernet).
528 hops 1 Client sets to zero, optionally used by relay agents
529 when booting via a relay agent.
530 xid 4 Transaction ID, a random number chosen by the
531 client, used by the client and server to associate
532 messages and responses between a client and a
533 server.
534 secs 2 Filled in by client, seconds elapsed since client
535 began address acquisition or renewal process.
536 flags 2 Flags (see figure 2).
537 ciaddr 4 Client IP address; only filled in if client is in
538 BOUND, RENEW or REBINDING state and can respond
539 to ARP requests.
540 yiaddr 4 'your' (client) IP address.
541 siaddr 4 IP address of next server to use in bootstrap;
542 returned in DHCPOFFER, DHCPACK by server.
543 giaddr 4 Relay agent IP address, used in booting via a
544 relay agent.
545 chaddr 16 Client hardware address.
546 sname 64 Optional server host name, null terminated string.
547 file 128 Boot file name, null terminated string; "generic"
548 name or null in DHCPDISCOVER, fully qualified
549 directory-path name in DHCPOFFER.
550 options var Optional parameters field. See the options
551 documents for a list of defined options.
553 Table 1: Description of fields in a DHCP message
555 The 'options' field is now variable length. A DHCP client must be
556 prepared to receive DHCP messages with an 'options' field of at least
557 length 312 octets. This requirement implies that a DHCP client must
558 be prepared to receive a message of up to 576 octets, the minimum IP
562 Droms Standards Track [Page 10]
563 \f
564 RFC 2131 Dynamic Host Configuration Protocol March 1997
567 datagram size an IP host must be prepared to accept [3]. DHCP
568 clients may negotiate the use of larger DHCP messages through the
569 'maximum DHCP message size' option. The options field may be further
570 extended into the 'file' and 'sname' fields.
572 In the case of a client using DHCP for initial configuration (before
573 the client's TCP/IP software has been completely configured), DHCP
574 requires creative use of the client's TCP/IP software and liberal
575 interpretation of RFC 1122. The TCP/IP software SHOULD accept and
576 forward to the IP layer any IP packets delivered to the client's
577 hardware address before the IP address is configured; DHCP servers
578 and BOOTP relay agents may not be able to deliver DHCP messages to
579 clients that cannot accept hardware unicast datagrams before the
580 TCP/IP software is configured.
582 To work around some clients that cannot accept IP unicast datagrams
583 before the TCP/IP software is configured as discussed in the previous
584 paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is
585 defined as the BROADCAST (B) flag. The semantics of this flag are
586 discussed in section 4.1 of this document. The remaining bits of the
587 flags field are reserved for future use. They MUST be set to zero by
588 clients and ignored by servers and relay agents. Figure 2 gives the
589 format of the 'flags' field.
591 1 1 1 1 1 1
592 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
594 |B| MBZ |
595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
597 B: BROADCAST flag
599 MBZ: MUST BE ZERO (reserved for future use)
601 Figure 2: Format of the 'flags' field
603 2.1 Configuration parameters repository
605 The first service provided by DHCP is to provide persistent storage
606 of network parameters for network clients. The model of DHCP
607 persistent storage is that the DHCP service stores a key-value entry
608 for each client, where the key is some unique identifier (for
609 example, an IP subnet number and a unique identifier within the
610 subnet) and the value contains the configuration parameters for the
611 client.
613 For example, the key might be the pair (IP-subnet-number, hardware-
614 address) (note that the "hardware-address" should be typed by the
618 Droms Standards Track [Page 11]
619 \f
620 RFC 2131 Dynamic Host Configuration Protocol March 1997
623 type of hardware to accommodate possible duplication of hardware
624 addresses resulting from bit-ordering problems in a mixed-media,
625 bridged network) allowing for serial or concurrent reuse of a
626 hardware address on different subnets, and for hardware addresses
627 that may not be globally unique. Alternately, the key might be the
628 pair (IP-subnet-number, hostname), allowing the server to assign
629 parameters intelligently to a DHCP client that has been moved to a
630 different subnet or has changed hardware addresses (perhaps because
631 the network interface failed and was replaced). The protocol defines
632 that the key will be (IP-subnet-number, hardware-address) unless the
633 client explicitly supplies an identifier using the 'client
634 identifier' option. A client can query the DHCP service to
635 retrieve its configuration parameters. The client interface to the
636 configuration parameters repository consists of protocol messages to
637 request configuration parameters and responses from the server
638 carrying the configuration parameters.
640 2.2 Dynamic allocation of network addresses
642 The second service provided by DHCP is the allocation of temporary or
643 permanent network (IP) addresses to clients. The basic mechanism for
644 the dynamic allocation of network addresses is simple: a client
645 requests the use of an address for some period of time. The
646 allocation mechanism (the collection of DHCP servers) guarantees not
647 to reallocate that address within the requested time and attempts to
648 return the same network address each time the client requests an
649 address. In this document, the period over which a network address
650 is allocated to a client is referred to as a "lease" [11]. The
651 client may extend its lease with subsequent requests. The client may
652 issue a message to release the address back to the server when the
653 client no longer needs the address. The client may ask for a
654 permanent assignment by asking for an infinite lease. Even when
655 assigning "permanent" addresses, a server may choose to give out
656 lengthy but non-infinite leases to allow detection of the fact that
657 the client has been retired.
659 In some environments it will be necessary to reassign network
660 addresses due to exhaustion of available addresses. In such
661 environments, the allocation mechanism will reuse addresses whose
662 lease has expired. The server should use whatever information is
663 available in the configuration information repository to choose an
664 address to reuse. For example, the server may choose the least
665 recently assigned address. As a consistency check, the allocating
666 server SHOULD probe the reused address before allocating the address,
667 e.g., with an ICMP echo request, and the client SHOULD probe the
668 newly received address, e.g., with ARP.
674 Droms Standards Track [Page 12]
675 \f
676 RFC 2131 Dynamic Host Configuration Protocol March 1997
679 3. The Client-Server Protocol
681 DHCP uses the BOOTP message format defined in RFC 951 and given in
682 table 1 and figure 1. The 'op' field of each DHCP message sent from
683 a client to a server contains BOOTREQUEST. BOOTREPLY is used in the
684 'op' field of each DHCP message sent from a server to a client.
686 The first four octets of the 'options' field of the DHCP message
687 contain the (decimal) values 99, 130, 83 and 99, respectively (this
688 is the same magic cookie as is defined in RFC 1497 [17]). The
689 remainder of the 'options' field consists of a list of tagged
690 parameters that are called "options". All of the "vendor extensions"
691 listed in RFC 1497 are also DHCP options. RFC 1533 gives the
692 complete set of options defined for use with DHCP.
694 Several options have been defined so far. One particular option -
695 the "DHCP message type" option - must be included in every DHCP
696 message. This option defines the "type" of the DHCP message.
697 Additional options may be allowed, required, or not allowed,
698 depending on the DHCP message type.
700 Throughout this document, DHCP messages that include a 'DHCP message
701 type' option will be referred to by the type of the message; e.g., a
702 DHCP message with 'DHCP message type' option type 1 will be referred
703 to as a "DHCPDISCOVER" message.
705 3.1 Client-server interaction - allocating a network address
707 The following summary of the protocol exchanges between clients and
708 servers refers to the DHCP messages described in table 2. The
709 timeline diagram in figure 3 shows the timing relationships in a
710 typical client-server interaction. If the client already knows its
711 address, some steps may be omitted; this abbreviated interaction is
712 described in section 3.2.
714 1. The client broadcasts a DHCPDISCOVER message on its local physical
715 subnet. The DHCPDISCOVER message MAY include options that suggest
716 values for the network address and lease duration. BOOTP relay
717 agents may pass the message on to DHCP servers not on the same
718 physical subnet.
720 2. Each server may respond with a DHCPOFFER message that includes an
721 available network address in the 'yiaddr' field (and other
722 configuration parameters in DHCP options). Servers need not
723 reserve the offered network address, although the protocol will
724 work more efficiently if the server avoids allocating the offered
725 network address to another client. When allocating a new address,
726 servers SHOULD check that the offered network address is not
730 Droms Standards Track [Page 13]
731 \f
732 RFC 2131 Dynamic Host Configuration Protocol March 1997
735 already in use; e.g., the server may probe the offered address
736 with an ICMP Echo Request. Servers SHOULD be implemented so that
737 network administrators MAY choose to disable probes of newly
738 allocated addresses. The server transmits the DHCPOFFER message
739 to the client, using the BOOTP relay agent if necessary.
741 Message Use
742 ------- ---
744 DHCPDISCOVER - Client broadcast to locate available servers.
746 DHCPOFFER - Server to client in response to DHCPDISCOVER with
747 offer of configuration parameters.
749 DHCPREQUEST - Client message to servers either (a) requesting
750 offered parameters from one server and implicitly
751 declining offers from all others, (b) confirming
752 correctness of previously allocated address after,
753 e.g., system reboot, or (c) extending the lease on a
754 particular network address.
756 DHCPACK - Server to client with configuration parameters,
757 including committed network address.
759 DHCPNAK - Server to client indicating client's notion of network
760 address is incorrect (e.g., client has moved to new
761 subnet) or client's lease as expired
763 DHCPDECLINE - Client to server indicating network address is already
764 in use.
766 DHCPRELEASE - Client to server relinquishing network address and
767 cancelling remaining lease.
769 DHCPINFORM - Client to server, asking only for local configuration
770 parameters; client already has externally configured
771 network address.
773 Table 2: DHCP messages
786 Droms Standards Track [Page 14]
787 \f
788 RFC 2131 Dynamic Host Configuration Protocol March 1997
791 Server Client Server
792 (not selected) (selected)
794 v v v
795 | | |
796 | Begins initialization |
797 | | |
798 | _____________/|\____________ |
799 |/DHCPDISCOVER | DHCPDISCOVER \|
800 | | |
801 Determines | Determines
802 configuration | configuration
803 | | |
804 |\ | ____________/ |
805 | \________ | /DHCPOFFER |
806 | DHCPOFFER\ |/ |
807 | \ | |
808 | Collects replies |
809 | \| |
810 | Selects configuration |
811 | | |
812 | _____________/|\____________ |
813 |/ DHCPREQUEST | DHCPREQUEST\ |
814 | | |
815 | | Commits configuration
816 | | |
817 | | _____________/|
818 | |/ DHCPACK |
819 | | |
820 | Initialization complete |
821 | | |
822 . . .
823 . . .
824 | | |
825 | Graceful shutdown |
826 | | |
827 | |\ ____________ |
828 | | DHCPRELEASE \|
829 | | |
830 | | Discards lease
831 | | |
832 v v v
833 Figure 3: Timeline diagram of messages exchanged between DHCP
834 client and servers when allocating a new network address
842 Droms Standards Track [Page 15]
843 \f
844 RFC 2131 Dynamic Host Configuration Protocol March 1997
847 3. The client receives one or more DHCPOFFER messages from one or more
848 servers. The client may choose to wait for multiple responses.
849 The client chooses one server from which to request configuration
850 parameters, based on the configuration parameters offered in the
851 DHCPOFFER messages. The client broadcasts a DHCPREQUEST message
852 that MUST include the 'server identifier' option to indicate which
853 server it has selected, and that MAY include other options
854 specifying desired configuration values. The 'requested IP
855 address' option MUST be set to the value of 'yiaddr' in the
856 DHCPOFFER message from the server. This DHCPREQUEST message is
857 broadcast and relayed through DHCP/BOOTP relay agents. To help
858 ensure that any BOOTP relay agents forward the DHCPREQUEST message
859 to the same set of DHCP servers that received the original
860 DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
861 value in the DHCP message header's 'secs' field and be sent to the
862 same IP broadcast address as the original DHCPDISCOVER message.
863 The client times out and retransmits the DHCPDISCOVER message if
864 the client receives no DHCPOFFER messages.
866 4. The servers receive the DHCPREQUEST broadcast from the client.
867 Those servers not selected by the DHCPREQUEST message use the
868 message as notification that the client has declined that server's
869 offer. The server selected in the DHCPREQUEST message commits the
870 binding for the client to persistent storage and responds with a
871 DHCPACK message containing the configuration parameters for the
872 requesting client. The combination of 'client identifier' or
873 'chaddr' and assigned network address constitute a unique
874 identifier for the client's lease and are used by both the client
875 and server to identify a lease referred to in any DHCP messages.
876 Any configuration parameters in the DHCPACK message SHOULD NOT
877 conflict with those in the earlier DHCPOFFER message to which the
878 client is responding. The server SHOULD NOT check the offered
879 network address at this point. The 'yiaddr' field in the DHCPACK
880 messages is filled in with the selected network address.
882 If the selected server is unable to satisfy the DHCPREQUEST message
883 (e.g., the requested network address has been allocated), the
884 server SHOULD respond with a DHCPNAK message.
886 A server MAY choose to mark addresses offered to clients in
887 DHCPOFFER messages as unavailable. The server SHOULD mark an
888 address offered to a client in a DHCPOFFER message as available if
889 the server receives no DHCPREQUEST message from that client.
891 5. The client receives the DHCPACK message with configuration
892 parameters. The client SHOULD perform a final check on the
893 parameters (e.g., ARP for allocated network address), and notes the
894 duration of the lease specified in the DHCPACK message. At this
898 Droms Standards Track [Page 16]
899 \f
900 RFC 2131 Dynamic Host Configuration Protocol March 1997
903 point, the client is configured. If the client detects that the
904 address is already in use (e.g., through the use of ARP), the
905 client MUST send a DHCPDECLINE message to the server and restarts
906 the configuration process. The client SHOULD wait a minimum of ten
907 seconds before restarting the configuration process to avoid
908 excessive network traffic in case of looping.
910 If the client receives a DHCPNAK message, the client restarts the
911 configuration process.
913 The client times out and retransmits the DHCPREQUEST message if the
914 client receives neither a DHCPACK or a DHCPNAK message. The client
915 retransmits the DHCPREQUEST according to the retransmission
916 algorithm in section 4.1. The client should choose to retransmit
917 the DHCPREQUEST enough times to give adequate probability of
918 contacting the server without causing the client (and the user of
919 that client) to wait overly long before giving up; e.g., a client
920 retransmitting as described in section 4.1 might retransmit the
921 DHCPREQUEST message four times, for a total delay of 60 seconds,
922 before restarting the initialization procedure. If the client
923 receives neither a DHCPACK or a DHCPNAK message after employing the
924 retransmission algorithm, the client reverts to INIT state and
925 restarts the initialization process. The client SHOULD notify the
926 user that the initialization process has failed and is restarting.
928 6. The client may choose to relinquish its lease on a network address
929 by sending a DHCPRELEASE message to the server. The client
930 identifies the lease to be released with its 'client identifier',
931 or 'chaddr' and network address in the DHCPRELEASE message. If the
932 client used a 'client identifier' when it obtained the lease, it
933 MUST use the same 'client identifier' in the DHCPRELEASE message.
935 3.2 Client-server interaction - reusing a previously allocated network
936 address
938 If a client remembers and wishes to reuse a previously allocated
939 network address, a client may choose to omit some of the steps
940 described in the previous section. The timeline diagram in figure 4
941 shows the timing relationships in a typical client-server interaction
942 for a client reusing a previously allocated network address.
954 Droms Standards Track [Page 17]
955 \f
956 RFC 2131 Dynamic Host Configuration Protocol March 1997
959 1. The client broadcasts a DHCPREQUEST message on its local subnet.
960 The message includes the client's network address in the
961 'requested IP address' option. As the client has not received its
962 network address, it MUST NOT fill in the 'ciaddr' field. BOOTP
963 relay agents pass the message on to DHCP servers not on the same
964 subnet. If the client used a 'client identifier' to obtain its
965 address, the client MUST use the same 'client identifier' in the
966 DHCPREQUEST message.
968 2. Servers with knowledge of the client's configuration parameters
969 respond with a DHCPACK message to the client. Servers SHOULD NOT
970 check that the client's network address is already in use; the
971 client may respond to ICMP Echo Request messages at this point.
973 Server Client Server
975 v v v
976 | | |
977 | Begins |
978 | initialization |
979 | | |
980 | /|\ |
981 | _________ __/ | \__________ |
982 | /DHCPREQU EST | DHCPREQUEST\ |
983 |/ | \|
984 | | |
985 Locates | Locates
986 configuration | configuration
987 | | |
988 |\ | /|
989 | \ | ___________/ |
990 | \ | / DHCPACK |
991 | \ _______ |/ |
992 | DHCPACK\ | |
993 | Initialization |
994 | complete |
995 | \| |
996 | | |
997 | (Subsequent |
998 | DHCPACKS |
999 | ignored) |
1000 | | |
1001 | | |
1002 v v v
1004 Figure 4: Timeline diagram of messages exchanged between DHCP
1005 client and servers when reusing a previously allocated
1006 network address
1010 Droms Standards Track [Page 18]
1011 \f
1012 RFC 2131 Dynamic Host Configuration Protocol March 1997
1015 If the client's request is invalid (e.g., the client has moved
1016 to a new subnet), servers SHOULD respond with a DHCPNAK message to
1017 the client. Servers SHOULD NOT respond if their information is not
1018 guaranteed to be accurate. For example, a server that identifies a
1019 request for an expired binding that is owned by another server SHOULD
1020 NOT respond with a DHCPNAK unless the servers are using an explicit
1021 mechanism to maintain coherency among the servers.
1023 If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
1024 the same subnet as the server. The server MUST
1025 broadcast the DHCPNAK message to the 0xffffffff broadcast address
1026 because the client may not have a correct network address or subnet
1027 mask, and the client may not be answering ARP requests.
1028 Otherwise, the server MUST send the DHCPNAK message to the IP
1029 address of the BOOTP relay agent, as recorded in 'giaddr'. The
1030 relay agent will, in turn, forward the message directly to the
1031 client's hardware address, so that the DHCPNAK can be delivered even
1032 if the client has moved to a new network.
1034 3. The client receives the DHCPACK message with configuration
1035 parameters. The client performs a final check on the parameters
1036 (as in section 3.1), and notes the duration of the lease specified
1037 in the DHCPACK message. The specific lease is implicitly identified
1038 by the 'client identifier' or 'chaddr' and the network address. At
1039 this point, the client is configured.
1041 If the client detects that the IP address in the DHCPACK message
1042 is already in use, the client MUST send a DHCPDECLINE message to the
1043 server and restarts the configuration process by requesting a
1044 new network address. This action corresponds to the client
1045 moving to the INIT state in the DHCP state diagram, which is
1046 described in section 4.4.
1048 If the client receives a DHCPNAK message, it cannot reuse its
1049 remembered network address. It must instead request a new
1050 address by restarting the configuration process, this time
1051 using the (non-abbreviated) procedure described in section
1052 3.1. This action also corresponds to the client moving to
1053 the INIT state in the DHCP state diagram.
1055 The client times out and retransmits the DHCPREQUEST message if
1056 the client receives neither a DHCPACK nor a DHCPNAK message. The
1057 client retransmits the DHCPREQUEST according to the retransmission
1058 algorithm in section 4.1. The client should choose to retransmit
1059 the DHCPREQUEST enough times to give adequate probability of
1060 contacting the server without causing the client (and the user of
1061 that client) to wait overly long before giving up; e.g., a client
1062 retransmitting as described in section 4.1 might retransmit the
1066 Droms Standards Track [Page 19]
1067 \f
1068 RFC 2131 Dynamic Host Configuration Protocol March 1997
1071 DHCPREQUEST message four times, for a total delay of 60 seconds,
1072 before restarting the initialization procedure. If the client
1073 receives neither a DHCPACK or a DHCPNAK message after employing
1074 the retransmission algorithm, the client MAY choose to use the
1075 previously allocated network address and configuration parameters
1076 for the remainder of the unexpired lease. This corresponds to
1077 moving to BOUND state in the client state transition diagram shown
1078 in figure 5.
1080 4. The client may choose to relinquish its lease on a network
1081 address by sending a DHCPRELEASE message to the server. The
1082 client identifies the lease to be released with its
1083 'client identifier', or 'chaddr' and network address in the
1084 DHCPRELEASE message.
1086 Note that in this case, where the client retains its network
1087 address locally, the client will not normally relinquish its
1088 lease during a graceful shutdown. Only in the case where the
1089 client explicitly needs to relinquish its lease, e.g., the client
1090 is about to be moved to a different subnet, will the client send
1091 a DHCPRELEASE message.
1093 3.3 Interpretation and representation of time values
1095 A client acquires a lease for a network address for a fixed period of
1096 time (which may be infinite). Throughout the protocol, times are to
1097 be represented in units of seconds. The time value of 0xffffffff is
1098 reserved to represent "infinity".
1100 As clients and servers may not have synchronized clocks, times are
1101 represented in DHCP messages as relative times, to be interpreted
1102 with respect to the client's local clock. Representing relative
1103 times in units of seconds in an unsigned 32 bit word gives a range of
1104 relative times from 0 to approximately 100 years, which is sufficient
1105 for the relative times to be measured using DHCP.
1107 The algorithm for lease duration interpretation given in the previous
1108 paragraph assumes that client and server clocks are stable relative
1109 to each other. If there is drift between the two clocks, the server
1110 may consider the lease expired before the client does. To
1111 compensate, the server may return a shorter lease duration to the
1112 client than the server commits to its local database of client
1113 information.
1115 3.4 Obtaining parameters with externally configured network address
1117 If a client has obtained a network address through some other means
1118 (e.g., manual configuration), it may use a DHCPINFORM request message
1122 Droms Standards Track [Page 20]
1123 \f
1124 RFC 2131 Dynamic Host Configuration Protocol March 1997
1127 to obtain other local configuration parameters. Servers receiving a
1128 DHCPINFORM message construct a DHCPACK message with any local
1129 configuration parameters appropriate for the client without:
1130 allocating a new address, checking for an existing binding, filling
1131 in 'yiaddr' or including lease time parameters. The servers SHOULD
1132 unicast the DHCPACK reply to the address given in the 'ciaddr' field
1133 of the DHCPINFORM message.
1135 The server SHOULD check the network address in a DHCPINFORM message
1136 for consistency, but MUST NOT check for an existing lease. The
1137 server forms a DHCPACK message containing the configuration
1138 parameters for the requesting client and sends the DHCPACK message
1139 directly to the client.
1141 3.5 Client parameters in DHCP
1143 Not all clients require initialization of all parameters listed in
1144 Appendix A. Two techniques are used to reduce the number of
1145 parameters transmitted from the server to the client. First, most of
1146 the parameters have defaults defined in the Host Requirements RFCs;
1147 if the client receives no parameters from the server that override
1148 the defaults, a client uses those default values. Second, in its
1149 initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the
1150 server with a list of specific parameters the client is interested
1151 in. If the client includes a list of parameters in a DHCPDISCOVER
1152 message, it MUST include that list in any subsequent DHCPREQUEST
1153 messages.
1155 The client SHOULD include the 'maximum DHCP message size' option to
1156 let the server know how large the server may make its DHCP messages.
1157 The parameters returned to a client may still exceed the space
1158 allocated to options in a DHCP message. In this case, two additional
1159 options flags (which must appear in the 'options' field of the
1160 message) indicate that the 'file' and 'sname' fields are to be used
1161 for options.
1163 The client can inform the server which configuration parameters the
1164 client is interested in by including the 'parameter request list'
1165 option. The data portion of this option explicitly lists the options
1166 requested by tag number.
1168 In addition, the client may suggest values for the network address
1169 and lease time in the DHCPDISCOVER message. The client may include
1170 the 'requested IP address' option to suggest that a particular IP
1171 address be assigned, and may include the 'IP address lease time'
1172 option to suggest the lease time it would like. Other options
1173 representing "hints" at configuration parameters are allowed in a
1174 DHCPDISCOVER or DHCPREQUEST message. However, additional options may
1178 Droms Standards Track [Page 21]
1179 \f
1180 RFC 2131 Dynamic Host Configuration Protocol March 1997
1183 be ignored by servers, and multiple servers may, therefore, not
1184 return identical values for some options. The 'requested IP address'
1185 option is to be filled in only in a DHCPREQUEST message when the
1186 client is verifying network parameters obtained previously. The
1187 client fills in the 'ciaddr' field only when correctly configured
1188 with an IP address in BOUND, RENEWING or REBINDING state.
1190 If a server receives a DHCPREQUEST message with an invalid 'requested
1191 IP address', the server SHOULD respond to the client with a DHCPNAK
1192 message and may choose to report the problem to the system
1193 administrator. The server may include an error message in the
1194 'message' option.
1196 3.6 Use of DHCP in clients with multiple interfaces
1198 A client with multiple network interfaces must use DHCP through each
1199 interface independently to obtain configuration information
1200 parameters for those separate interfaces.
1202 3.7 When clients should use DHCP
1204 A client SHOULD use DHCP to reacquire or verify its IP address and
1205 network parameters whenever the local network parameters may have
1206 changed; e.g., at system boot time or after a disconnection from the
1207 local network, as the local network configuration may change without
1208 the client's or user's knowledge.
1210 If a client has knowledge of a previous network address and is unable
1211 to contact a local DHCP server, the client may continue to use the
1212 previous network address until the lease for that address expires.
1213 If the lease expires before the client can contact a DHCP server, the
1214 client must immediately discontinue use of the previous network
1215 address and may inform local users of the problem.
1217 4. Specification of the DHCP client-server protocol
1219 In this section, we assume that a DHCP server has a block of network
1220 addresses from which it can satisfy requests for new addresses. Each
1221 server also maintains a database of allocated addresses and leases in
1222 local permanent storage.
1224 4.1 Constructing and sending DHCP messages
1226 DHCP clients and servers both construct DHCP messages by filling in
1227 fields in the fixed format section of the message and appending
1228 tagged data items in the variable length option area. The options
1229 area includes first a four-octet 'magic cookie' (which was described
1230 in section 3), followed by the options. The last option must always
1234 Droms Standards Track [Page 22]
1235 \f
1236 RFC 2131 Dynamic Host Configuration Protocol March 1997
1239 be the 'end' option.
1241 DHCP uses UDP as its transport protocol. DHCP messages from a client
1242 to a server are sent to the 'DHCP server' port (67), and DHCP
1243 messages from a server to a client are sent to the 'DHCP client' port
1244 (68). A server with multiple network address (e.g., a multi-homed
1245 host) MAY use any of its network addresses in outgoing DHCP messages.
1247 The 'server identifier' field is used both to identify a DHCP server
1248 in a DHCP message and as a destination address from clients to
1249 servers. A server with multiple network addresses MUST be prepared
1250 to to accept any of its network addresses as identifying that server
1251 in a DHCP message. To accommodate potentially incomplete network
1252 connectivity, a server MUST choose an address as a 'server
1253 identifier' that, to the best of the server's knowledge, is reachable
1254 from the client. For example, if the DHCP server and the DHCP client
1255 are connected to the same subnet (i.e., the 'giaddr' field in the
1256 message from the client is zero), the server SHOULD select the IP
1257 address the server is using for communication on that subnet as the
1258 'server identifier'. If the server is using multiple IP addresses on
1259 that subnet, any such address may be used. If the server has
1260 received a message through a DHCP relay agent, the server SHOULD
1261 choose an address from the interface on which the message was
1262 recieved as the 'server identifier' (unless the server has other,
1263 better information on which to make its choice). DHCP clients MUST
1264 use the IP address provided in the 'server identifier' option for any
1265 unicast requests to the DHCP server.
1267 DHCP messages broadcast by a client prior to that client obtaining
1268 its IP address must have the source address field in the IP header
1269 set to 0.
1271 If the 'giaddr' field in a DHCP message from a client is non-zero,
1272 the server sends any return messages to the 'DHCP server' port on the
1273 BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
1274 field is zero and the 'ciaddr' field is nonzero, then the server
1275 unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
1276 If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
1277 set, then the server broadcasts DHCPOFFER and DHCPACK messages to
1278 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
1279 'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
1280 messages to the client's hardware address and 'yiaddr' address. In
1281 all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
1282 messages to 0xffffffff.
1284 If the options in a DHCP message extend into the 'sname' and 'file'
1285 fields, the 'option overload' option MUST appear in the 'options'
1286 field, with value 1, 2 or 3, as specified in RFC 1533. If the
1290 Droms Standards Track [Page 23]
1291 \f
1292 RFC 2131 Dynamic Host Configuration Protocol March 1997
1295 'option overload' option is present in the 'options' field, the
1296 options in the 'options' field MUST be terminated by an 'end' option,
1297 and MAY contain one or more 'pad' options to fill the options field.
1298 The options in the 'sname' and 'file' fields (if in use as indicated
1299 by the 'options overload' option) MUST begin with the first octet of
1300 the field, MUST be terminated by an 'end' option, and MUST be
1301 followed by 'pad' options to fill the remainder of the field. Any
1302 individual option in the 'options', 'sname' and 'file' fields MUST be
1303 entirely contained in that field. The options in the 'options' field
1304 MUST be interpreted first, so that any 'option overload' options may
1305 be interpreted. The 'file' field MUST be interpreted next (if the
1306 'option overload' option indicates that the 'file' field contains
1307 DHCP options), followed by the 'sname' field.
1309 The values to be passed in an 'option' tag may be too long to fit in
1310 the 255 octets available to a single option (e.g., a list of routers
1311 in a 'router' option [21]). Options may appear only once, unless
1312 otherwise specified in the options document. The client concatenates
1313 the values of multiple instances of the same option into a single
1314 parameter list for configuration.
1316 DHCP clients are responsible for all message retransmission. The
1317 client MUST adopt a retransmission strategy that incorporates a
1318 randomized exponential backoff algorithm to determine the delay
1319 between retransmissions. The delay between retransmissions SHOULD be
1320 chosen to allow sufficient time for replies from the server to be
1321 delivered based on the characteristics of the internetwork between
1322 the client and the server. For example, in a 10Mb/sec Ethernet
1323 internetwork, the delay before the first retransmission SHOULD be 4
1324 seconds randomized by the value of a uniform random number chosen
1325 from the range -1 to +1. Clients with clocks that provide resolution
1326 granularity of less than one second may choose a non-integer
1327 randomization value. The delay before the next retransmission SHOULD
1328 be 8 seconds randomized by the value of a uniform number chosen from
1329 the range -1 to +1. The retransmission delay SHOULD be doubled with
1330 subsequent retransmissions up to a maximum of 64 seconds. The client
1331 MAY provide an indication of retransmission attempts to the user as
1332 an indication of the progress of the configuration process.
1334 The 'xid' field is used by the client to match incoming DHCP messages
1335 with pending requests. A DHCP client MUST choose 'xid's in such a
1336 way as to minimize the chance of using an 'xid' identical to one used
1337 by another client. For example, a client may choose a different,
1338 random initial 'xid' each time the client is rebooted, and
1339 subsequently use sequential 'xid's until the next reboot. Selecting
1340 a new 'xid' for each retransmission is an implementation decision. A
1341 client may choose to reuse the same 'xid' or select a new 'xid' for
1342 each retransmitted message.
1346 Droms Standards Track [Page 24]
1347 \f
1348 RFC 2131 Dynamic Host Configuration Protocol March 1997
1351 Normally, DHCP servers and BOOTP relay agents attempt to deliver
1352 DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
1353 uicast delivery. The IP destination address (in the IP header) is
1354 set to the DHCP 'yiaddr' address and the link-layer destination
1355 address is set to the DHCP 'chaddr' address. Unfortunately, some
1356 client implementations are unable to receive such unicast IP
1357 datagrams until the implementation has been configured with a valid
1358 IP address (leading to a deadlock in which the client's IP address
1359 cannot be delivered until the client has been configured with an IP
1360 address).
1362 A client that cannot receive unicast IP datagrams until its protocol
1363 software has been configured with an IP address SHOULD set the
1364 BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
1365 DHCPREQUEST messages that client sends. The BROADCAST bit will
1366 provide a hint to the DHCP server and BOOTP relay agent to broadcast
1367 any messages to the client on the client's subnet. A client that can
1368 receive unicast IP datagrams before its protocol software has been
1369 configured SHOULD clear the BROADCAST bit to 0. The BOOTP
1370 clarifications document discusses the ramifications of the use of the
1371 BROADCAST bit [21].
1373 A server or relay agent sending or relaying a DHCP message directly
1374 to a DHCP client (i.e., not to a relay agent specified in the
1375 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
1376 field. If this bit is set to 1, the DHCP message SHOULD be sent as
1377 an IP broadcast using an IP broadcast address (preferably 0xffffffff)
1378 as the IP destination address and the link-layer broadcast address as
1379 the link-layer destination address. If the BROADCAST bit is cleared
1380 to 0, the message SHOULD be sent as an IP unicast to the IP address
1381 specified in the 'yiaddr' field and the link-layer address specified
1382 in the 'chaddr' field. If unicasting is not possible, the message
1383 MAY be sent as an IP broadcast using an IP broadcast address
1384 (preferably 0xffffffff) as the IP destination address and the link-
1385 layer broadcast address as the link-layer destination address.
1387 4.2 DHCP server administrative controls
1389 DHCP servers are not required to respond to every DHCPDISCOVER and
1390 DHCPREQUEST message they receive. For example, a network
1391 administrator, to retain stringent control over the clients attached
1392 to the network, may choose to configure DHCP servers to respond only
1393 to clients that have been previously registered through some external
1394 mechanism. The DHCP specification describes only the interactions
1395 between clients and servers when the clients and servers choose to
1396 interact; it is beyond the scope of the DHCP specification to
1397 describe all of the administrative controls that system
1398 administrators might want to use. Specific DHCP server
1402 Droms Standards Track [Page 25]
1403 \f
1404 RFC 2131 Dynamic Host Configuration Protocol March 1997
1407 implementations may incorporate any controls or policies desired by a
1408 network administrator.
1410 In some environments, a DHCP server will have to consider the values
1411 of the vendor class options included in DHCPDISCOVER or DHCPREQUEST
1412 messages when determining the correct parameters for a particular
1413 client.
1415 A DHCP server needs to use some unique identifier to associate a
1416 client with its lease. The client MAY choose to explicitly provide
1417 the identifier through the 'client identifier' option. If the client
1418 supplies a 'client identifier', the client MUST use the same 'client
1419 identifier' in all subsequent messages, and the server MUST use that
1420 identifier to identify the client. If the client does not provide a
1421 'client identifier' option, the server MUST use the contents of the
1422 'chaddr' field to identify the client. It is crucial for a DHCP
1423 client to use an identifier unique within the subnet to which the
1424 client is attached in the 'client identifier' option. Use of
1425 'chaddr' as the client's unique identifier may cause unexpected
1426 results, as that identifier may be associated with a hardware
1427 interface that could be moved to a new client. Some sites may choose
1428 to use a manufacturer's serial number as the 'client identifier', to
1429 avoid unexpected changes in a clients network address due to transfer
1430 of hardware interfaces among computers. Sites may also choose to use
1431 a DNS name as the 'client identifier', causing address leases to be
1432 associated with the DNS name rather than a specific hardware box.
1434 DHCP clients are free to use any strategy in selecting a DHCP server
1435 among those from which the client receives a DHCPOFFER message. The
1436 client implementation of DHCP SHOULD provide a mechanism for the user
1437 to select directly the 'vendor class identifier' values.
1439 4.3 DHCP server behavior
1441 A DHCP server processes incoming DHCP messages from a client based on
1442 the current state of the binding for that client. A DHCP server can
1443 receive the following messages from a client:
1445 o DHCPDISCOVER
1447 o DHCPREQUEST
1449 o DHCPDECLINE
1451 o DHCPRELEASE
1453 o DHCPINFORM
1458 Droms Standards Track [Page 26]
1459 \f
1460 RFC 2131 Dynamic Host Configuration Protocol March 1997
1463 Table 3 gives the use of the fields and options in a DHCP message by
1464 a server. The remainder of this section describes the action of the
1465 DHCP server for each possible incoming message.
1467 4.3.1 DHCPDISCOVER message
1469 When a server receives a DHCPDISCOVER message from a client, the
1470 server chooses a network address for the requesting client. If no
1471 address is available, the server may choose to report the problem to
1472 the system administrator. If an address is available, the new address
1473 SHOULD be chosen as follows:
1475 o The client's current address as recorded in the client's current
1476 binding, ELSE
1478 o The client's previous address as recorded in the client's (now
1479 expired or released) binding, if that address is in the server's
1480 pool of available addresses and not already allocated, ELSE
1482 o The address requested in the 'Requested IP Address' option, if that
1483 address is valid and not already allocated, ELSE
1485 o A new address allocated from the server's pool of available
1486 addresses; the address is selected based on the subnet from which
1487 the message was received (if 'giaddr' is 0) or on the address of
1488 the relay agent that forwarded the message ('giaddr' when not 0).
1490 As described in section 4.2, a server MAY, for administrative
1491 reasons, assign an address other than the one requested, or may
1492 refuse to allocate an address to a particular client even though free
1493 addresses are available.
1495 Note that, in some network architectures (e.g., internets with more
1496 than one IP subnet assigned to a physical network segment), it may be
1497 the case that the DHCP client should be assigned an address from a
1498 different subnet than the address recorded in 'giaddr'. Thus, DHCP
1499 does not require that the client be assigned as address from the
1500 subnet in 'giaddr'. A server is free to choose some other subnet,
1501 and it is beyond the scope of the DHCP specification to describe ways
1502 in which the assigned IP address might be chosen.
1504 While not required for correct operation of DHCP, the server SHOULD
1505 NOT reuse the selected network address before the client responds to
1506 the server's DHCPOFFER message. The server may choose to record the
1507 address as offered to the client.
1509 The server must also choose an expiration time for the lease, as
1510 follows:
1514 Droms Standards Track [Page 27]
1515 \f
1516 RFC 2131 Dynamic Host Configuration Protocol March 1997
1519 o IF the client has not requested a specific lease in the
1520 DHCPDISCOVER message and the client already has an assigned network
1521 address, the server returns the lease expiration time previously
1522 assigned to that address (note that the client must explicitly
1523 request a specific lease to extend the expiration time on a
1524 previously assigned address), ELSE
1526 o IF the client has not requested a specific lease in the
1527 DHCPDISCOVER message and the client does not have an assigned
1528 network address, the server assigns a locally configured default
1529 lease time, ELSE
1531 o IF the client has requested a specific lease in the DHCPDISCOVER
1532 message (regardless of whether the client has an assigned network
1533 address), the server may choose either to return the requested
1534 lease (if the lease is acceptable to local policy) or select
1535 another lease.
1537 Field DHCPOFFER DHCPACK DHCPNAK
1538 ----- --------- ------- -------
1539 'op' BOOTREPLY BOOTREPLY BOOTREPLY
1540 'htype' (From "Assigned Numbers" RFC)
1541 'hlen' (Hardware address length in octets)
1542 'hops' 0 0 0
1543 'xid' 'xid' from client 'xid' from client 'xid' from client
1544 DHCPDISCOVER DHCPREQUEST DHCPREQUEST
1545 message message message
1546 'secs' 0 0 0
1547 'ciaddr' 0 'ciaddr' from 0
1548 DHCPREQUEST or 0
1549 'yiaddr' IP address offered IP address 0
1550 to client assigned to client
1551 'siaddr' IP address of next IP address of next 0
1552 bootstrap server bootstrap server
1553 'flags' 'flags' from 'flags' from 'flags' from
1554 client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
1555 message message message
1556 'giaddr' 'giaddr' from 'giaddr' from 'giaddr' from
1557 client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
1558 message message message
1559 'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
1560 client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
1561 message message message
1562 'sname' Server host name Server host name (unused)
1563 or options or options
1564 'file' Client boot file Client boot file (unused)
1565 name or options name or options
1566 'options' options options
1570 Droms Standards Track [Page 28]
1571 \f
1572 RFC 2131 Dynamic Host Configuration Protocol March 1997
1575 Option DHCPOFFER DHCPACK DHCPNAK
1576 ------ --------- ------- -------
1577 Requested IP address MUST NOT MUST NOT MUST NOT
1578 IP address lease time MUST MUST (DHCPREQUEST) MUST NOT
1579 MUST NOT (DHCPINFORM)
1580 Use 'file'/'sname' fields MAY MAY MUST NOT
1581 DHCP message type DHCPOFFER DHCPACK DHCPNAK
1582 Parameter request list MUST NOT MUST NOT MUST NOT
1583 Message SHOULD SHOULD SHOULD
1584 Client identifier MUST NOT MUST NOT MAY
1585 Vendor class identifier MAY MAY MAY
1586 Server identifier MUST MUST MUST
1587 Maximum message size MUST NOT MUST NOT MUST NOT
1588 All others MAY MAY MUST NOT
1590 Table 3: Fields and options used by DHCP servers
1592 Once the network address and lease have been determined, the server
1593 constructs a DHCPOFFER message with the offered configuration
1594 parameters. It is important for all DHCP servers to return the same
1595 parameters (with the possible exception of a newly allocated network
1596 address) to ensure predictable client behavior regardless of which
1597 server the client selects. The configuration parameters MUST be
1598 selected by applying the following rules in the order given below.
1599 The network administrator is responsible for configuring multiple
1600 DHCP servers to ensure uniform responses from those servers. The
1601 server MUST return to the client:
1603 o The client's network address, as determined by the rules given
1604 earlier in this section,
1606 o The expiration time for the client's lease, as determined by the
1607 rules given earlier in this section,
1609 o Parameters requested by the client, according to the following
1610 rules:
1612 -- IF the server has been explicitly configured with a default
1613 value for the parameter, the server MUST include that value
1614 in an appropriate option in the 'option' field, ELSE
1616 -- IF the server recognizes the parameter as a parameter
1617 defined in the Host Requirements Document, the server MUST
1618 include the default value for that parameter as given in the
1619 Host Requirements Document in an appropriate option in the
1620 'option' field, ELSE
1622 -- The server MUST NOT return a value for that parameter,
1626 Droms Standards Track [Page 29]
1627 \f
1628 RFC 2131 Dynamic Host Configuration Protocol March 1997
1631 The server MUST supply as many of the requested parameters as
1632 possible and MUST omit any parameters it cannot provide. The
1633 server MUST include each requested parameter only once unless
1634 explicitly allowed in the DHCP Options and BOOTP Vendor
1635 Extensions document.
1637 o Any parameters from the existing binding that differ from the Host
1638 Requirements Document defaults,
1640 o Any parameters specific to this client (as identified by
1641 the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER
1642 or DHCPREQUEST message), e.g., as configured by the network
1643 administrator,
1645 o Any parameters specific to this client's class (as identified
1646 by the contents of the 'vendor class identifier'
1647 option in the DHCPDISCOVER or DHCPREQUEST message),
1648 e.g., as configured by the network administrator; the parameters
1649 MUST be identified by an exact match between the client's vendor
1650 class identifiers and the client's classes identified in the
1651 server,
1653 o Parameters with non-default values on the client's subnet.
1655 The server MAY choose to return the 'vendor class identifier' used to
1656 determine the parameters in the DHCPOFFER message to assist the
1657 client in selecting which DHCPOFFER to accept. The server inserts
1658 the 'xid' field from the DHCPDISCOVER message into the 'xid' field of
1659 the DHCPOFFER message and sends the DHCPOFFER message to the
1660 requesting client.
1662 4.3.2 DHCPREQUEST message
1664 A DHCPREQUEST message may come from a client responding to a
1665 DHCPOFFER message from a server, from a client verifying a previously
1666 allocated IP address or from a client extending the lease on a
1667 network address. If the DHCPREQUEST message contains a 'server
1668 identifier' option, the message is in response to a DHCPOFFER
1669 message. Otherwise, the message is a request to verify or extend an
1670 existing lease. If the client uses a 'client identifier' in a
1671 DHCPREQUEST message, it MUST use that same 'client identifier' in all
1672 subsequent messages. If the client included a list of requested
1673 parameters in a DHCPDISCOVER message, it MUST include that list in
1674 all subsequent messages.
1682 Droms Standards Track [Page 30]
1683 \f
1684 RFC 2131 Dynamic Host Configuration Protocol March 1997
1687 Any configuration parameters in the DHCPACK message SHOULD NOT
1688 conflict with those in the earlier DHCPOFFER message to which the
1689 client is responding. The client SHOULD use the parameters in the
1690 DHCPACK message for configuration.
1692 Clients send DHCPREQUEST messages as follows:
1694 o DHCPREQUEST generated during SELECTING state:
1696 Client inserts the address of the selected server in 'server
1697 identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be
1698 filled in with the yiaddr value from the chosen DHCPOFFER.
1700 Note that the client may choose to collect several DHCPOFFER
1701 messages and select the "best" offer. The client indicates its
1702 selection by identifying the offering server in the DHCPREQUEST
1703 message. If the client receives no acceptable offers, the client
1704 may choose to try another DHCPDISCOVER message. Therefore, the
1705 servers may not receive a specific DHCPREQUEST from which they can
1706 decide whether or not the client has accepted the offer. Because
1707 the servers have not committed any network address assignments on
1708 the basis of a DHCPOFFER, servers are free to reuse offered
1709 network addresses in response to subsequent requests. As an
1710 implementation detail, servers SHOULD NOT reuse offered addresses
1711 and may use an implementation-specific timeout mechanism to decide
1712 when to reuse an offered address.
1714 o DHCPREQUEST generated during INIT-REBOOT state:
1716 'server identifier' MUST NOT be filled in, 'requested IP address'
1717 option MUST be filled in with client's notion of its previously
1718 assigned address. 'ciaddr' MUST be zero. The client is seeking to
1719 verify a previously allocated, cached configuration. Server SHOULD
1720 send a DHCPNAK message to the client if the 'requested IP address'
1721 is incorrect, or is on the wrong network.
1723 Determining whether a client in the INIT-REBOOT state is on the
1724 correct network is done by examining the contents of 'giaddr', the
1725 'requested IP address' option, and a database lookup. If the DHCP
1726 server detects that the client is on the wrong net (i.e., the
1727 result of applying the local subnet mask or remote subnet mask (if
1728 'giaddr' is not zero) to 'requested IP address' option value
1729 doesn't match reality), then the server SHOULD send a DHCPNAK
1730 message to the client.
1738 Droms Standards Track [Page 31]
1739 \f
1740 RFC 2131 Dynamic Host Configuration Protocol March 1997
1743 If the network is correct, then the DHCP server should check if
1744 the client's notion of its IP address is correct. If not, then the
1745 server SHOULD send a DHCPNAK message to the client. If the DHCP
1746 server has no record of this client, then it MUST remain silent,
1747 and MAY output a warning to the network administrator. This
1748 behavior is necessary for peaceful coexistence of non-
1749 communicating DHCP servers on the same wire.
1751 If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
1752 the same subnet as the server. The server MUST broadcast the
1753 DHCPNAK message to the 0xffffffff broadcast address because the
1754 client may not have a correct network address or subnet mask, and
1755 the client may not be answering ARP requests.
1757 If 'giaddr' is set in the DHCPREQUEST message, the client is on a
1758 different subnet. The server MUST set the broadcast bit in the
1759 DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the
1760 client, because the client may not have a correct network address
1761 or subnet mask, and the client may not be answering ARP requests.
1763 o DHCPREQUEST generated during RENEWING state:
1765 'server identifier' MUST NOT be filled in, 'requested IP address'
1766 option MUST NOT be filled in, 'ciaddr' MUST be filled in with
1767 client's IP address. In this situation, the client is completely
1768 configured, and is trying to extend its lease. This message will
1769 be unicast, so no relay agents will be involved in its
1770 transmission. Because 'giaddr' is therefore not filled in, the
1771 DHCP server will trust the value in 'ciaddr', and use it when
1772 replying to the client.
1774 A client MAY choose to renew or extend its lease prior to T1. The
1775 server may choose not to extend the lease (as a policy decision by
1776 the network administrator), but should return a DHCPACK message
1777 regardless.
1779 o DHCPREQUEST generated during REBINDING state:
1781 'server identifier' MUST NOT be filled in, 'requested IP address'
1782 option MUST NOT be filled in, 'ciaddr' MUST be filled in with
1783 client's IP address. In this situation, the client is completely
1784 configured, and is trying to extend its lease. This message MUST
1785 be broadcast to the 0xffffffff IP broadcast address. The DHCP
1786 server SHOULD check 'ciaddr' for correctness before replying to
1787 the DHCPREQUEST.
1794 Droms Standards Track [Page 32]
1795 \f
1796 RFC 2131 Dynamic Host Configuration Protocol March 1997
1799 The DHCPREQUEST from a REBINDING client is intended to accommodate
1800 sites that have multiple DHCP servers and a mechanism for
1801 maintaining consistency among leases managed by multiple servers.
1802 A DHCP server MAY extend a client's lease only if it has local
1803 administrative authority to do so.
1805 4.3.3 DHCPDECLINE message
1807 If the server receives a DHCPDECLINE message, the client has
1808 discovered through some other means that the suggested network
1809 address is already in use. The server MUST mark the network address
1810 as not available and SHOULD notify the local system administrator of
1811 a possible configuration problem.
1813 4.3.4 DHCPRELEASE message
1815 Upon receipt of a DHCPRELEASE message, the server marks the network
1816 address as not allocated. The server SHOULD retain a record of the
1817 client's initialization parameters for possible reuse in response to
1818 subsequent requests from the client.
1820 4.3.5 DHCPINFORM message
1822 The server responds to a DHCPINFORM message by sending a DHCPACK
1823 message directly to the address given in the 'ciaddr' field of the
1824 DHCPINFORM message. The server MUST NOT send a lease expiration time
1825 to the client and SHOULD NOT fill in 'yiaddr'. The server includes
1826 other parameters in the DHCPACK message as defined in section 4.3.1.
1828 4.3.6 Client messages
1830 Table 4 details the differences between messages from clients in
1831 various states.
1833 ---------------------------------------------------------------------
1834 | |INIT-REBOOT |SELECTING |RENEWING |REBINDING |
1835 ---------------------------------------------------------------------
1836 |broad/unicast |broadcast |broadcast |unicast |broadcast |
1837 |server-ip |MUST NOT |MUST |MUST NOT |MUST NOT |
1838 |requested-ip |MUST |MUST |MUST NOT |MUST NOT |
1839 |ciaddr |zero |zero |IP address |IP address|
1840 ---------------------------------------------------------------------
1842 Table 4: Client messages from different states
1850 Droms Standards Track [Page 33]
1851 \f
1852 RFC 2131 Dynamic Host Configuration Protocol March 1997
1855 4.4 DHCP client behavior
1857 Figure 5 gives a state-transition diagram for a DHCP client. A
1858 client can receive the following messages from a server:
1860 o DHCPOFFER
1862 o DHCPACK
1864 o DHCPNAK
1866 The DHCPINFORM message is not shown in figure 5. A client simply
1867 sends the DHCPINFORM and waits for DHCPACK messages. Once the client
1868 has selected its parameters, it has completed the configuration
1869 process.
1871 Table 5 gives the use of the fields and options in a DHCP message by
1872 a client. The remainder of this section describes the action of the
1873 DHCP client for each possible incoming message. The description in
1874 the following section corresponds to the full configuration procedure
1875 previously described in section 3.1, and the text in the subsequent
1876 section corresponds to the abbreviated configuration procedure
1877 described in section 3.2.
1906 Droms Standards Track [Page 34]
1907 \f
1908 RFC 2131 Dynamic Host Configuration Protocol March 1997
1911 -------- -------
1912 | | +-------------------------->| |<-------------------+
1913 | INIT- | | +-------------------->| INIT | |
1914 | REBOOT |DHCPNAK/ +---------->| |<---+ |
1915 | |Restart| | ------- | |
1916 -------- | DHCPNAK/ | | |
1917 | Discard offer | -/Send DHCPDISCOVER |
1918 -/Send DHCPREQUEST | | |
1919 | | | DHCPACK v | |
1920 ----------- | (not accept.)/ ----------- | |
1921 | | | Send DHCPDECLINE | | |
1922 | REBOOTING | | | | SELECTING |<----+ |
1923 | | | / | | |DHCPOFFER/ |
1924 ----------- | / ----------- | |Collect |
1925 | | / | | | replies |
1926 DHCPACK/ | / +----------------+ +-------+ |
1927 Record lease, set| | v Select offer/ |
1928 timers T1, T2 ------------ send DHCPREQUEST | |
1929 | +----->| | DHCPNAK, Lease expired/ |
1930 | | | REQUESTING | Halt network |
1931 DHCPOFFER/ | | | |
1932 Discard ------------ | |
1933 | | | | ----------- |
1934 | +--------+ DHCPACK/ | | |
1935 | Record lease, set -----| REBINDING | |
1936 | timers T1, T2 / | | |
1937 | | DHCPACK/ ----------- |
1938 | v Record lease, set ^ |
1939 +----------------> ------- /timers T1,T2 | |
1940 +----->| |<---+ | |
1941 | | BOUND |<---+ | |
1942 DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/
1943 DHCPNAK/Discard ------- | Broadcast Halt network
1944 | | | | DHCPREQUEST |
1945 +-------+ | DHCPACK/ | |
1946 T1 expires/ Record lease, set | |
1947 Send DHCPREQUEST timers T1, T2 | |
1948 to leasing server | | |
1949 | ---------- | |
1950 | | |------------+ |
1951 +->| RENEWING | |
1952 | |----------------------------+
1953 ----------
1954 Figure 5: State-transition diagram for DHCP clients
1962 Droms Standards Track [Page 35]
1963 \f
1964 RFC 2131 Dynamic Host Configuration Protocol March 1997
1967 4.4.1 Initialization and allocation of network address
1969 The client begins in INIT state and forms a DHCPDISCOVER message.
1970 The client SHOULD wait a random time between one and ten seconds to
1971 desynchronize the use of DHCP at startup. The client sets 'ciaddr'
1972 to 0x00000000. The client MAY request specific parameters by
1973 including the 'parameter request list' option. The client MAY
1974 suggest a network address and/or lease time by including the
1975 'requested IP address' and 'IP address lease time' options. The
1976 client MUST include its hardware address in the 'chaddr' field, if
1977 necessary for delivery of DHCP reply messages. The client MAY
1978 include a different unique identifier in the 'client identifier'
1979 option, as discussed in section 4.2. If the client included a list
1980 of requested parameters in a DHCPDISCOVER message, it MUST include
1981 that list in all subsequent messages.
1983 The client generates and records a random transaction identifier and
1984 inserts that identifier into the 'xid' field. The client records its
1985 own local time for later use in computing the lease expiration. The
1986 client then broadcasts the DHCPDISCOVER on the local hardware
1987 broadcast address to the 0xffffffff IP broadcast address and 'DHCP
1988 server' UDP port.
1990 If the 'xid' of an arriving DHCPOFFER message does not match the
1991 'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message
1992 must be silently discarded. Any arriving DHCPACK messages must be
1993 silently discarded.
1995 The client collects DHCPOFFER messages over a period of time, selects
1996 one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
1997 messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
1998 from the previously used server) and extracts the server address from
1999 the 'server identifier' option in the DHCPOFFER message. The time
2000 over which the client collects messages and the mechanism used to
2001 select one DHCPOFFER are implementation dependent.
2018 Droms Standards Track [Page 36]
2019 \f
2020 RFC 2131 Dynamic Host Configuration Protocol March 1997
2023 Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
2024 DHCPINFORM DHCPRELEASE
2025 ----- ------------ ----------- -----------
2026 'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
2027 'htype' (From "Assigned Numbers" RFC)
2028 'hlen' (Hardware address length in octets)
2029 'hops' 0 0 0
2030 'xid' selected by client 'xid' from server selected by
2031 DHCPOFFER message client
2032 'secs' 0 or seconds since 0 or seconds since 0
2033 DHCP process started DHCP process started
2034 'flags' Set 'BROADCAST' Set 'BROADCAST' 0
2035 flag if client flag if client
2036 requires broadcast requires broadcast
2037 reply reply
2038 'ciaddr' 0 (DHCPDISCOVER) 0 or client's 0 (DHCPDECLINE)
2039 client's network address client's network
2040 network address (BOUND/RENEW/REBIND) address
2041 (DHCPINFORM) (DHCPRELEASE)
2042 'yiaddr' 0 0 0
2043 'siaddr' 0 0 0
2044 'giaddr' 0 0 0
2045 'chaddr' client's hardware client's hardware client's hardware
2046 address address address
2047 'sname' options, if options, if (unused)
2048 indicated in indicated in
2049 'sname/file' 'sname/file'
2050 option; otherwise option; otherwise
2051 unused unused
2052 'file' options, if options, if (unused)
2053 indicated in indicated in
2054 'sname/file' 'sname/file'
2055 option; otherwise option; otherwise
2056 unused unused
2057 'options' options options (unused)
2074 Droms Standards Track [Page 37]
2075 \f
2076 RFC 2131 Dynamic Host Configuration Protocol March 1997
2079 Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
2080 DHCPINFORM DHCPRELEASE
2081 ------ ------------ ----------- -----------
2082 Requested IP address MAY MUST (in MUST
2083 (DISCOVER) SELECTING or (DHCPDECLINE),
2084 MUST NOT INIT-REBOOT) MUST NOT
2085 (INFORM) MUST NOT (in (DHCPRELEASE)
2086 BOUND or
2087 RENEWING)
2088 IP address lease time MAY MAY MUST NOT
2089 (DISCOVER)
2090 MUST NOT
2091 (INFORM)
2092 Use 'file'/'sname' fields MAY MAY MAY
2093 DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/
2094 DHCPINFORM DHCPRELEASE
2095 Client identifier MAY MAY MAY
2096 Vendor class identifier MAY MAY MUST NOT
2097 Server identifier MUST NOT MUST (after MUST
2098 SELECTING)
2099 MUST NOT (after
2100 INIT-REBOOT,
2101 BOUND, RENEWING
2102 or REBINDING)
2103 Parameter request list MAY MAY MUST NOT
2104 Maximum message size MAY MAY MUST NOT
2105 Message SHOULD NOT SHOULD NOT SHOULD
2106 Site-specific MAY MAY MUST NOT
2107 All others MAY MAY MUST NOT
2109 Table 5: Fields and options used by DHCP clients
2111 If the parameters are acceptable, the client records the address of
2112 the server that supplied the parameters from the 'server identifier'
2113 field and sends that address in the 'server identifier' field of a
2114 DHCPREQUEST broadcast message. Once the DHCPACK message from the
2115 server arrives, the client is initialized and moves to BOUND state.
2116 The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER
2117 message. The client records the lease expiration time as the sum of
2118 the time at which the original request was sent and the duration of
2119 the lease from the DHCPACK message. The client SHOULD perform a
2120 check on the suggested address to ensure that the address is not
2121 already in use. For example, if the client is on a network that
2122 supports ARP, the client may issue an ARP request for the suggested
2123 request. When broadcasting an ARP request for the suggested address,
2124 the client must fill in its own hardware address as the sender's
2125 hardware address, and 0 as the sender's IP address, to avoid
2126 confusing ARP caches in other hosts on the same subnet. If the
2130 Droms Standards Track [Page 38]
2131 \f
2132 RFC 2131 Dynamic Host Configuration Protocol March 1997
2135 network address appears to be in use, the client MUST send a
2136 DHCPDECLINE message to the server. The client SHOULD broadcast an ARP
2137 reply to announce the client's new IP address and clear any outdated
2138 ARP cache entries in hosts on the client's subnet.
2140 4.4.2 Initialization with known network address
2142 The client begins in INIT-REBOOT state and sends a DHCPREQUEST
2143 message. The client MUST insert its known network address as a
2144 'requested IP address' option in the DHCPREQUEST message. The client
2145 may request specific configuration parameters by including the
2146 'parameter request list' option. The client generates and records a
2147 random transaction identifier and inserts that identifier into the
2148 'xid' field. The client records its own local time for later use in
2149 computing the lease expiration. The client MUST NOT include a
2150 'server identifier' in the DHCPREQUEST message. The client then
2151 broadcasts the DHCPREQUEST on the local hardware broadcast address to
2152 the 'DHCP server' UDP port.
2154 Once a DHCPACK message with an 'xid' field matching that in the
2155 client's DHCPREQUEST message arrives from any server, the client is
2156 initialized and moves to BOUND state. The client records the lease
2157 expiration time as the sum of the time at which the DHCPREQUEST
2158 message was sent and the duration of the lease from the DHCPACK
2159 message.
2161 4.4.3 Initialization with an externally assigned network address
2163 The client sends a DHCPINFORM message. The client may request
2164 specific configuration parameters by including the 'parameter request
2165 list' option. The client generates and records a random transaction
2166 identifier and inserts that identifier into the 'xid' field. The
2167 client places its own network address in the 'ciaddr' field. The
2168 client SHOULD NOT request lease time parameters.
2170 The client then unicasts the DHCPINFORM to the DHCP server if it
2171 knows the server's address, otherwise it broadcasts the message to
2172 the limited (all 1s) broadcast address. DHCPINFORM messages MUST be
2173 directed to the 'DHCP server' UDP port.
2175 Once a DHCPACK message with an 'xid' field matching that in the
2176 client's DHCPINFORM message arrives from any server, the client is
2177 initialized.
2179 If the client does not receive a DHCPACK within a reasonable period
2180 of time (60 seconds or 4 tries if using timeout suggested in section
2181 4.1), then it SHOULD display a message informing the user of the
2182 problem, and then SHOULD begin network processing using suitable
2186 Droms Standards Track [Page 39]
2187 \f
2188 RFC 2131 Dynamic Host Configuration Protocol March 1997
2191 defaults as per Appendix A.
2193 4.4.4 Use of broadcast and unicast
2195 The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
2196 messages, unless the client knows the address of a DHCP server. The
2197 client unicasts DHCPRELEASE messages to the server. Because the
2198 client is declining the use of the IP address supplied by the server,
2199 the client broadcasts DHCPDECLINE messages.
2201 When the DHCP client knows the address of a DHCP server, in either
2202 INIT or REBOOTING state, the client may use that address in the
2203 DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
2204 The client may also use unicast to send DHCPINFORM messages to a
2205 known DHCP server. If the client receives no response to DHCP
2206 messages sent to the IP address of a known DHCP server, the DHCP
2207 client reverts to using the IP broadcast address.
2209 4.4.5 Reacquisition and expiration
2211 The client maintains two times, T1 and T2, that specify the times at
2212 which the client tries to extend its lease on its network address.
2213 T1 is the time at which the client enters the RENEWING state and
2214 attempts to contact the server that originally issued the client's
2215 network address. T2 is the time at which the client enters the
2216 REBINDING state and attempts to contact any server. T1 MUST be
2217 earlier than T2, which, in turn, MUST be earlier than the time at
2218 which the client's lease will expire.
2220 To avoid the need for synchronized clocks, T1 and T2 are expressed in
2221 options as relative times [2].
2223 At time T1 the client moves to RENEWING state and sends (via unicast)
2224 a DHCPREQUEST message to the server to extend its lease. The client
2225 sets the 'ciaddr' field in the DHCPREQUEST to its current network
2226 address. The client records the local time at which the DHCPREQUEST
2227 message is sent for computation of the lease expiration time. The
2228 client MUST NOT include a 'server identifier' in the DHCPREQUEST
2229 message.
2231 Any DHCPACK messages that arrive with an 'xid' that does not match
2232 the 'xid' of the client's DHCPREQUEST message are silently discarded.
2233 When the client receives a DHCPACK from the server, the client
2234 computes the lease expiration time as the sum of the time at which
2235 the client sent the DHCPREQUEST message and the duration of the lease
2236 in the DHCPACK message. The client has successfully reacquired its
2237 network address, returns to BOUND state and may continue network
2238 processing.
2242 Droms Standards Track [Page 40]
2243 \f
2244 RFC 2131 Dynamic Host Configuration Protocol March 1997
2247 If no DHCPACK arrives before time T2, the client moves to REBINDING
2248 state and sends (via broadcast) a DHCPREQUEST message to extend its
2249 lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its
2250 current network address. The client MUST NOT include a 'server
2251 identifier' in the DHCPREQUEST message.
2253 Times T1 and T2 are configurable by the server through options. T1
2254 defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 *
2255 duration_of_lease). Times T1 and T2 SHOULD be chosen with some
2256 random "fuzz" around a fixed value, to avoid synchronization of
2257 client reacquisition.
2259 A client MAY choose to renew or extend its lease prior to T1. The
2260 server MAY choose to extend the client's lease according to policy
2261 set by the network administrator. The server SHOULD return T1 and
2262 T2, and their values SHOULD be adjusted from their original values to
2263 take account of the time remaining on the lease.
2265 In both RENEWING and REBINDING states, if the client receives no
2266 response to its DHCPREQUEST message, the client SHOULD wait one-half
2267 of the remaining time until T2 (in RENEWING state) and one-half of
2268 the remaining lease time (in REBINDING state), down to a minimum of
2269 60 seconds, before retransmitting the DHCPREQUEST message.
2271 If the lease expires before the client receives a DHCPACK, the client
2272 moves to INIT state, MUST immediately stop any other network
2273 processing and requests network initialization parameters as if the
2274 client were uninitialized. If the client then receives a DHCPACK
2275 allocating that client its previous network address, the client
2276 SHOULD continue network processing. If the client is given a new
2277 network address, it MUST NOT continue using the previous network
2278 address and SHOULD notify the local users of the problem.
2280 4.4.6 DHCPRELEASE
2282 If the client no longer requires use of its assigned network address
2283 (e.g., the client is gracefully shut down), the client sends a
2284 DHCPRELEASE message to the server. Note that the correct operation
2285 of DHCP does not depend on the transmission of DHCPRELEASE messages.
2298 Droms Standards Track [Page 41]
2299 \f
2300 RFC 2131 Dynamic Host Configuration Protocol March 1997
2303 5. Acknowledgments
2305 The author thanks the many (and too numerous to mention!) members of
2306 the DHC WG for their tireless and ongoing efforts in the development
2307 of DHCP and this document.
2309 The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
2310 Mendonca in organizing DHCP interoperability testing sessions are
2311 gratefully acknowledged.
2313 The development of this document was supported in part by grants from
2314 the Corporation for National Research Initiatives (CNRI), Bucknell
2315 University and Sun Microsystems.
2317 6. References
2319 [1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December
2320 1983.
2322 [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
2323 Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
2324 University, October 1993.
2326 [3] Braden, R., Editor, "Requirements for Internet Hosts --
2327 Communication Layers", STD 3, RFC 1122, USC/Information Sciences
2328 Institute, October 1989.
2330 [4] Braden, R., Editor, "Requirements for Internet Hosts --
2331 Application and Support, STD 3, RFC 1123, USC/Information
2332 Sciences Institute, October 1989.
2334 [5] Brownell, D, "Dynamic Reverse Address Resolution Protocol
2335 (DRARP)", Work in Progress.
2337 [6] Comer, D., and R. Droms, "Uniform Access to Internet Directory
2338 Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
2339 Communications Review), 20(4):50--59, 1990.
2341 [7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
2342 Stanford and SUN Microsystems, September 1985.
2344 [8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
2345 PARC, September 1991.
2347 [9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534,
2348 Bucknell University, October 1993.
2354 Droms Standards Track [Page 42]
2355 \f
2356 RFC 2131 Dynamic Host Configuration Protocol March 1997
2359 [10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
2360 Address Resolution Protocol", RFC 903, Stanford, June 1984.
2362 [11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant
2363 Mechanism for Distributed File Cache Consistency", In Proc. of
2364 the Twelfth ACM Symposium on Operating Systems Design, 1989.
2366 [12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
2367 13, RFC 1034, USC/Information Sciences Institute, November 1987.
2369 [13] Mockapetris, P., "Domain Names -- Implementation and
2370 Specification", STD 13, RFC 1035, USC/Information Sciences
2371 Institute, November 1987.
2373 [14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
2374 November 1990.
2376 [15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached
2377 Hosts", Work in Progress.
2379 [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
2380 USC/Information Sciences Institute, September 1981.
2382 [17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
2383 USC/Information Sciences Institute, August 1993.
2385 [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
2386 USC/Information Sciences Institute, October 1994.
2388 [19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic
2389 Assignment of IP Addresses for use on an Ethernet. (Available
2390 from the Athena Project, MIT), 1989.
2392 [20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC,
2393 June 1981.
2395 [21] Wimer, W., "Clarifications and Extensions for the Bootstrap
2396 Protocol", RFC 1542, Carnegie Mellon University, October 1993.
2398 7. Security Considerations
2400 DHCP is built directly on UDP and IP which are as yet inherently
2401 insecure. Furthermore, DHCP is generally intended to make
2402 maintenance of remote and/or diskless hosts easier. While perhaps
2403 not impossible, configuring such hosts with passwords or keys may be
2404 difficult and inconvenient. Therefore, DHCP in its current form is
2405 quite insecure.
2410 Droms Standards Track [Page 43]
2411 \f
2412 RFC 2131 Dynamic Host Configuration Protocol March 1997
2415 Unauthorized DHCP servers may be easily set up. Such servers can
2416 then send false and potentially disruptive information to clients
2417 such as incorrect or duplicate IP addresses, incorrect routing
2418 information (including spoof routers, etc.), incorrect domain
2419 nameserver addresses (such as spoof nameservers), and so on.
2420 Clearly, once this seed information is in place, an attacker can
2421 further compromise affected systems.
2423 Malicious DHCP clients could masquerade as legitimate clients and
2424 retrieve information intended for those legitimate clients. Where
2425 dynamic allocation of resources is used, a malicious client could
2426 claim all resources for itself, thereby denying resources to
2427 legitimate clients.
2429 8. Author's Address
2431 Ralph Droms
2432 Computer Science Department
2433 323 Dana Engineering
2434 Bucknell University
2435 Lewisburg, PA 17837
2437 Phone: (717) 524-1145
2438 EMail: droms@bucknell.edu
2466 Droms Standards Track [Page 44]
2467 \f
2468 RFC 2131 Dynamic Host Configuration Protocol March 1997
2471 A. Host Configuration Parameters
2473 IP-layer_parameters,_per_host:_
2475 Be a router on/off HRC 3.1
2476 Non-local source routing on/off HRC 3.3.5
2477 Policy filters for
2478 non-local source routing (list) HRC 3.3.5
2479 Maximum reassembly size integer HRC 3.3.2
2480 Default TTL integer HRC 3.2.1.7
2481 PMTU aging timeout integer MTU 6.6
2482 MTU plateau table (list) MTU 7
2483 IP-layer_parameters,_per_interface:_
2484 IP address (address) HRC 3.3.1.6
2485 Subnet mask (address mask) HRC 3.3.1.6
2486 MTU integer HRC 3.3.3
2487 All-subnets-MTU on/off HRC 3.3.3
2488 Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6
2489 Perform mask discovery on/off HRC 3.2.2.9
2490 Be a mask supplier on/off HRC 3.2.2.9
2491 Perform router discovery on/off RD 5.1
2492 Router solicitation address (address) RD 5.1
2493 Default routers, list of:
2494 router address (address) HRC 3.3.1.6
2495 preference level integer HRC 3.3.1.6
2496 Static routes, list of:
2497 destination (host/subnet/net) HRC 3.3.1.2
2498 destination mask (address mask) HRC 3.3.1.2
2499 type-of-service integer HRC 3.3.1.2
2500 first-hop router (address) HRC 3.3.1.2
2501 ignore redirects on/off HRC 3.3.1.2
2502 PMTU integer MTU 6.6
2503 perform PMTU discovery on/off MTU 6.6
2505 Link-layer_parameters,_per_interface:_
2506 Trailers on/off HRC 2.3.1
2507 ARP cache timeout integer HRC 2.3.2.1
2508 Ethernet encapsulation (RFC 894/RFC 1042) HRC 2.3.3
2510 TCP_parameters,_per_host:_
2511 TTL integer HRC 4.2.2.19
2512 Keep-alive interval integer HRC 4.2.3.6
2513 Keep-alive data size 0/1 HRC 4.2.3.6
2515 Key:
2517 MTU = Path MTU Discovery (RFC 1191, Proposed Standard)
2518 RD = Router Discovery (RFC 1256, Proposed Standard)
2522 Droms Standards Track [Page 45]
2523 \f