idnits 2.17.1 draft-ietf-dhc-dhcp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 26 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([19], [7], [9], [7,21]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 434: '... DHCP client MUST be unique to that ...' RFC 2119 keyword, line 436: '... one message, it MUST use that same id...' RFC 2119 keyword, line 500: '... The TCP/IP software SHOULD accept and...' RFC 2119 keyword, line 512: '...uture use. They MUST be set to zero b...' RFC 2119 keyword, line 524: '... MBZ: MUST BE ZERO (reserve...' (161 more instances...) -- The draft header indicates that this document obsoletes draft-ietf-dhc-dhcp-07.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1733 has weird spacing: '...oadcast req...' == Line 2114 has weird spacing: '...scovery on/of...' -- No information found for rfcdraft-ietf-dhc-dhcp-07.txt - is the name correct? -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1997) is 9843 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '18' is defined on line 2029, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 887 (ref. '1') ** Obsolete normative reference: RFC 1533 (ref. '2') (Obsoleted by RFC 2132) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '15' ** Obsolete normative reference: RFC 1497 (ref. '17') (Obsoleted by RFC 1533) ** Obsolete normative reference: RFC 1340 (ref. '18') (Obsoleted by RFC 1700) -- Possible downref: Non-RFC (?) normative reference: ref. '19' ** Obsolete normative reference: RFC 783 (ref. '20') (Obsoleted by RFC 1350) Summary: 16 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Droms 2 INTERNET DRAFT Bucknell University 3 Obsoletes: draft-ietf-dhc-dhcp-07.txt November 1996 4 Expires May 1997 6 Dynamic Host Configuration Protocol 7 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 The Dynamic Host Configuration Protocol (DHCP) provides a framework 30 for passing configuration information to hosts on a TCP/IP network. 31 DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the 32 capability of automatic allocation of reusable network addresses and 33 additional configuration options [19]. DHCP captures the behavior of 34 BOOTP relay agents [7, 21], and DHCP participants can interoperate 35 with BOOTP participants [9]. 37 Table of Contents 39 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 40 1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 4 41 1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4 42 1.3 Problem definition and issues . . . . . . . . . . . . . . . . 5 43 1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5 44 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 45 1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6 46 2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8 48 DRAFT Dynamic Host Configuration Protocol November 1996 50 2.1 Configuration parameters repository . . . . . . . . . . . . . 11 51 2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12 52 3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13 53 3.1 Client-server interaction - allocating a network address. . . 13 54 3.2 Client-server interaction - reusing a previously allocated 55 network address . . . . . . . . . . . . . . . . . . . . . . . 17 56 3.3 Interpretation and representation of time values. . . . . . . 20 57 3.4 Obtaining parameters with externally configured network 58 address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 59 3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 20 60 3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22 61 3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22 62 4. Specification of the DHCP client-server protocol. . . . . . . 22 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. . . . . . . . . . . . . . . . . . . . . 33 67 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .40 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . .41 69 7. Security Considerations. . . . . . . . . . . . . . . . . . . .42 70 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .43 71 A. Host Configuration Parameters . . . . . . . . . . . . . . . .44 73 List of Figures 75 1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9 76 2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11 77 3. Timeline diagram of messages exchanged between DHCP client and 78 servers when allocating a new network address. . . . . . . . . 15 79 4. Timeline diagram of messages exchanged between DHCP client and 80 servers when reusing a previously allocated network address. . 18 81 5. State-transition diagram for DHCP clients. . . . . . . . . . . 34 83 List of Tables 85 1. Description of fields in a DHCP message. . . . . . . . . . . . 10 86 2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 14 87 3. Fields and options used by DHCP servers. . . . . . . . . . . . 28 88 4. Client messages from various states. . . . . . . . . . . . . . 33 89 5. Fields and options used by DHCP clients. . . . . . . . . . . . 37 91 1. Introduction 93 The Dynamic Host Configuration Protocol (DHCP) provides configuration 94 parameters to Internet hosts. DHCP consists of two components: a 95 protocol for delivering host-specific configuration parameters from a 96 DHCP server to a host and a mechanism for allocation of network 97 addresses to hosts. 99 DRAFT Dynamic Host Configuration Protocol November 1996 101 DHCP is built on a client-server model, where designated DHCP server 102 hosts allocate network addresses and deliver configuration parameters 103 to dynamically configured hosts. Throughout the remainder of this 104 document, the term "server" refers to a host providing initialization 105 parameters through DHCP, and the term "client" refers to a host 106 requesting initialization parameters from a DHCP server. 108 A host should not act as a DHCP server unless explicitly configured 109 to do so by a system administrator. The diversity of hardware and 110 protocol implementations in the Internet would preclude reliable 111 operation if random hosts were allowed to respond to DHCP requests. 112 For example, IP requires the setting of many parameters within the 113 protocol implementation software. Because IP can be used on many 114 dissimilar kinds of network hardware, values for those parameters 115 cannot be guessed or assumed to have correct defaults. Also, 116 distributed address allocation schemes depend on a polling/defense 117 mechanism for discovery of addresses that are already in use. IP 118 hosts may not always be able to defend their network addresses, so 119 that such a distributed address allocation scheme cannot be 120 guaranteed to avoid allocation of duplicate network addresses. 122 DHCP supports three mechanisms for IP address allocation. In 123 "automatic allocation", DHCP assigns a permanent IP address to a 124 client. In "dynamic allocation", DHCP assigns an IP address to a 125 client for a limited period of time (or until the client explicitly 126 relinquishes the address). In "manual allocation", a client's IP 127 address is assigned by the network administrator, and DHCP is used 128 simply to convey the assigned address to the client. A particular 129 network will use one or more of these mechanisms, depending on the 130 policies of the network administrator. 132 Dynamic allocation is the only one of the three mechanisms that 133 allows automatic reuse of an address that is no longer needed by the 134 client to which it was assigned. Thus, dynamic allocation is 135 particularly useful for assigning an address to a client that will be 136 connected to the network only temporarily or for sharing a limited 137 pool of IP addresses among a group of clients that do not need 138 permanent IP addresses. Dynamic allocation may also be a good choice 139 for assigning an IP address to a new client being permanently 140 connected to a network where IP addresses are sufficiently scarce 141 that it is important to reclaim them when old clients are retired. 142 Manual allocation allows DHCP to be used to eliminate the error-prone 143 process of manually configuring hosts with IP addresses in 144 environments where (for whatever reasons) it is desirable to manage 145 IP address assignment outside of the DHCP mechanisms. 147 The format of DHCP messages is based on the format of BOOTP messages, 148 to capture the BOOTP relay agent behavior described as part of the 150 DRAFT Dynamic Host Configuration Protocol November 1996 152 BOOTP specification [7, 21] and to allow interoperability of existing 153 BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates 154 the necessity of having a DHCP server on each physical network 155 segment. 157 1.1 Changes to RFC 1541 159 This document updates the DHCP protocol specification that appears in 160 RFC1541. A new DHCP message type, DHCPINFORM, has been added; see 161 section 3.4, 4.3 and 4.4 for details. The classing mechanism for 162 identifying DHCP clients to DHCP servers has been extended to include 163 "vendor" classes as defined in sections 4.2 and 4.3. The minimum 164 lease time restriction has been removed. Finally, many editorial 165 changes have been made to clarify the text as a result of experience 166 gained in DHCP interoperability tests. 168 1.2 Related Work 170 There are several Internet protocols and related mechanisms that 171 address some parts of the dynamic host configuration problem. The 172 Reverse Address Resolution Protocol (RARP) [10] (through the 173 extensions defined in the Dynamic RARP (DRARP) [5]) explicitly 174 addresses the problem of network address discovery, and includes an 175 automatic IP address assignment mechanism. The Trivial File Transfer 176 Protocol (TFTP) [20] provides for transport of a boot image from a 177 boot server. The Internet Control Message Protocol (ICMP) [16] 178 provides for informing hosts of additional routers via "ICMP 179 redirect" messages. ICMP also can provide subnet mask information 180 through the "ICMP mask request" message and other information through 181 the (obsolete) "ICMP information request" message. Hosts can locate 182 routers through the ICMP router discovery mechanism [8]. 184 BOOTP is a transport mechanism for a collection of configuration 185 information. BOOTP is also extensible, and official extensions [17] 186 have been defined for several configuration parameters. Morgan has 187 proposed extensions to BOOTP for dynamic IP address assignment [15]. 188 The Network Information Protocol (NIP), used by the Athena project at 189 MIT, is a distributed mechanism for dynamic IP address assignment 190 [19]. The Resource Location Protocol RLP [1] provides for location 191 of higher level services. Sun Microsystems diskless workstations use 192 a boot procedure that employs RARP, TFTP and an RPC mechanism called 193 "bootparams" to deliver configuration information and operating 194 system code to diskless hosts. (Sun Microsystems, Sun Workstation 195 and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun 196 networks also use DRARP and an auto-installation mechanism to 197 automate the configuration of new hosts in an existing network. 199 In other related work, the path minimum transmission unit (MTU) 201 DRAFT Dynamic Host Configuration Protocol November 1996 203 discovery algorithm can determine the MTU of an arbitrary internet 204 path [14]. The Address Resolution Protocol (ARP) has been proposed 205 as a transport protocol for resource location and selection [6]. 206 Finally, the Host Requirements RFCs [3, 4] mention specific 207 requirements for host reconfiguration and suggest a scenario for 208 initial configuration of diskless hosts. 210 1.3 Problem definition and issues 212 DHCP is designed to supply DHCP clients with the configuration 213 parameters defined in the Host Requirements RFCs. After obtaining 214 parameters via DHCP, a DHCP client should be able to exchange packets 215 with any other host in the Internet. The TCP/IP stack parameters 216 supplied by DHCP are listed in Appendix A. 218 Not all of these parameters are required for a newly initialized 219 client. A client and server may negotiate for the transmission of 220 only those parameters required by the client or specific to a 221 particular subnet. 223 DHCP allows but does not require the configuration of client 224 parameters not directly related to the IP protocol. DHCP also does 225 not address registration of newly configured clients with the Domain 226 Name System (DNS) [12, 13]. 228 DHCP is not intended for use in configuring routers. 230 1.4 Requirements 232 Throughout this document, the words that are used to define the 233 significance of particular requirements are capitalized. These words 234 are: 236 o "MUST" 238 This word or the adjective "REQUIRED" means that the 239 item is an absolute requirement of this specification. 241 o "MUST NOT" 243 This phrase means that the item is an absolute prohibition 244 of this specification. 246 DRAFT Dynamic Host Configuration Protocol November 1996 248 o "SHOULD" 250 This word or the adjective "RECOMMENDED" means that there 251 may exist valid reasons in particular circumstances to ignore 252 this item, but the full implications should be understood and 253 the case carefully weighed before choosing a different course. 255 o "SHOULD NOT" 257 This phrase means that there may exist valid reasons in 258 particular circumstances when the listed behavior is acceptable 259 or even useful, but the full implications should be understood 260 and the case carefully weighed before implementing any behavior 261 described with this label. 263 o "MAY" 265 This word or the adjective "OPTIONAL" means that this item is 266 truly optional. One vendor may choose to include the item 267 because a particular marketplace requires it or because it 268 enhances the product, for example; another vendor may omit the 269 same item. 271 1.5 Terminology 273 This document uses the following terms: 275 o "DHCP client" 277 A DHCP client is an Internet host using DHCP to obtain 278 configuration parameters such as a network address. 280 o "DHCP server" 282 A DHCP server is an Internet host that returns configuration 283 parameters to DHCP clients. 285 o "BOOTP relay agent" 287 A BOOTP relay agent or relay agent is an Internet host or router that 288 passes DHCP messages between DHCP clients and DHCP servers. DHCP is 289 designed to use the same relay agent behavior as specified in 290 the BOOTP protocol specification. 292 DRAFT Dynamic Host Configuration Protocol November 1996 294 o "binding" 296 A binding is a collection of configuration parameters, including 297 at least an IP address, associated with or "bound to" a DHCP 298 client. Bindings are managed by DHCP servers. 300 1.6 Design goals 302 The following list gives general design goals for DHCP. 304 o DHCP should be a mechanism rather than a policy. DHCP must 305 allow local system administrators control over configuration 306 parameters where desired; e.g., local system administrators 307 should be able to enforce local policies concerning allocation 308 and access to local resources where desired. 310 o Clients should require no manual configuration. Each client should 311 be able to discover appropriate local configuration parameters 312 without user intervention and incorporate those parameters into 313 its own configuration. 315 o Networks should require no manual configuration for individual 316 clients. Under normal circumstances, the network manager should 317 not have to enter any per-client configuration parameters. 319 o DHCP should not require a server on each subnet. To allow for 320 scale and economy, DHCP must work across routers or through the 321 intervention of BOOTP relay agents. 323 o A DHCP client must be prepared to receive multiple responses to a 324 request for configuration parameters. Some installations may 325 include multiple, overlapping DHCP servers to enhance 326 reliability and increase performance. 328 o DHCP must coexist with statically configured, non-participating 329 hosts and with existing network protocol implementations. 331 o DHCP must interoperate with the BOOTP relay agent behavior as 332 described by RFC 951 and by RFC 1542 [21]. 334 o DHCP must provide service to existing BOOTP clients. 336 The following list gives design goals specific to the transmission of 337 the network layer parameters. DHCP must: 339 DRAFT Dynamic Host Configuration Protocol November 1996 341 o Guarantee that any specific network address will not be in 342 use by more than one DHCP client at a time, 344 o Retain DHCP client configuration across DHCP client reboot. A DHCP 345 client should, whenever possible, be assigned the same configuration 346 parameters (e.g., network address) in response to each request, 348 o Retain DHCP client configuration across server reboots, and, whenever 349 possible, a DHCP client should be assigned the same configuration 350 parameters despite restarts of the DHCP mechanism, 352 o Allow automated assignment of configuration parameters to new 353 clients to avoid hand configuration for new clients, 355 o Support fixed or permanent allocation of configuration 356 parameters to specific clients. 358 2. Protocol Summary 360 From the client's point of view, DHCP is an extension of the BOOTP 361 mechanism. This behavior allows existing BOOTP clients to 362 interoperate with DHCP servers without requiring any change to the 363 clients' initialization software. RFC 1542 [2] details the 364 interactions between BOOTP and DHCP clients and servers [9]. There 365 are some new, optional transactions that optimize the interaction 366 between DHCP clients and servers that are described in sections 3 and 367 4. 369 Figure 1 gives the format of a DHCP message and table 1 describes 370 each of the fields in the DHCP message. The numbers in parentheses 371 indicate the size of each field in octets. The names for the fields 372 given in the figure will be used throughout this document to refer to 373 the fields in DHCP messages. 375 There are two primary differences between DHCP and BOOTP. First, 376 DHCP defines mechanisms through which clients can be assigned a 377 network address for a finite lease, allowing for serial reassignment 378 of network addresses to different clients. Second, DHCP provides the 379 mechanism for a client to acquire all of the IP configuration 380 parameters that it needs in order to operate. 382 DHCP introduces a small change in terminology intended to clarify the 383 meaning of one of the fields. What was the "vendor extensions" field 384 in BOOTP has been re-named the "options" field in DHCP. Similarly, 385 the tagged data items that were used inside the BOOTP "vendor 386 extensions" field, which were formerly referred to as "vendor 387 extensions," are now termed simply "options." 389 DRAFT Dynamic Host Configuration Protocol November 1996 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | op (1) | htype (1) | hlen (1) | hops (1) | 395 +---------------+---------------+---------------+---------------+ 396 | xid (4) | 397 +-------------------------------+-------------------------------+ 398 | secs (2) | flags (2) | 399 +-------------------------------+-------------------------------+ 400 | ciaddr (4) | 401 +---------------------------------------------------------------+ 402 | yiaddr (4) | 403 +---------------------------------------------------------------+ 404 | siaddr (4) | 405 +---------------------------------------------------------------+ 406 | giaddr (4) | 407 +---------------------------------------------------------------+ 408 | | 409 | chaddr (16) | 410 | | 411 | | 412 +---------------------------------------------------------------+ 413 | | 414 | sname (64) | 415 +---------------------------------------------------------------+ 416 | | 417 | file (128) | 418 +---------------------------------------------------------------+ 419 | | 420 | options (variable) | 421 +---------------------------------------------------------------+ 423 Figure 1: Format of a DHCP message 425 DHCP defines a new 'client identifier' option that is used to pass an 426 explicit client identifier to a DHCP server. This change eliminates 427 the overloading of the 'chaddr' field in BOOTP messages, where 428 'chaddr' is used both as a hardware address for transmission of BOOTP 429 reply messages and as a client identifier. The 'client identifier' 430 is an opaque key, not to be interpreted by the server; for example, 431 the 'client identifier' may contain a hardware address, identical to 432 the contents of the 'chaddr' field, or it may contain another type of 433 identifier, such as a DNS name. The 'client identifier' chosen by a 434 DHCP client MUST be unique to that client within the subnet to which 435 the client is attached. If the client uses a 'client identifier' in 436 one message, it MUST use that same identifier in all subsequent 437 messages, to ensure that all servers correctly identify the client. 439 DRAFT Dynamic Host Configuration Protocol November 1996 441 DHCP clarifies the interpretation of the 'siaddr' field as the 442 address of the server to use in the next step of the client's 443 bootstrap process. A DHCP server may return its own address in the 444 'siaddr' field, if the server is prepared to supply the next 445 bootstrap service (e.g., delivery of an operating system executable 446 image). A DHCP server always returns its own address in the 'server 447 identifier' option. 449 FIELD OCTETS DESCRIPTION 450 ----- ------ ----------- 452 op 1 Message op code / message type. 453 1 = BOOTREQUEST, 2 = BOOTREPLY 454 htype 1 Hardware address type, see ARP section in "Assigned 455 Numbers" RFC; e.g., '1' = 10mb ethernet. 456 hlen 1 Hardware address length (e.g. '6' for 10mb 457 ethernet). 458 hops 1 Client sets to zero, optionally used by relay agents 459 when booting via a relay agent. 460 xid 4 Transaction ID, a random number chosen by the 461 client, used by the client and server to associate 462 messages and responses between a client and a 463 server. 464 secs 2 Filled in by client, seconds elapsed since client 465 began address acquisition or renewal process. 466 flags 2 Flags (see figure 2). 467 ciaddr 4 Client IP address; only filled in if client is in 468 BOUND, RENEW or REBINDING state and can respond to ARP 469 requests. 470 yiaddr 4 'your' (client) IP address. 471 siaddr 4 IP address of next server to use in bootstrap; 472 returned in DHCPOFFER, DHCPACK by server. 473 giaddr 4 Relay agent IP address, used in booting via a 474 relay agent. 475 chaddr 16 Client hardware address. 476 sname 64 Optional server host name, null terminated string. 477 file 128 Boot file name, null terminated string; "generic" 478 name or null in DHCPDISCOVER, fully qualified 479 directory-path name in DHCPOFFER. 480 options var Optional parameters field. See the options 481 documents for a list of defined options. 483 Table 1: Description of fields in a DHCP message 485 The 'options' field is now variable length. A DHCP client must be 486 prepared to receive DHCP messages with an 'options' field of at least 487 length 312 octets. This requirement implies that a DHCP client must 488 be prepared to receive a message of up to 576 octets, the minimum IP 490 DRAFT Dynamic Host Configuration Protocol November 1996 492 datagram size an IP host must be prepared to accept [3]. DHCP 493 clients may negotiate the use of larger DHCP messages through the 494 'maximum DHCP message size' option. The options field may be further 495 extended into the 'file' and 'sname' fields. 497 In the case of a client using DHCP for initial configuration (before 498 the client's TCP/IP software has been completely configured), DHCP 499 requires creative use of the client's TCP/IP software and liberal 500 interpretation of RFC 1122. The TCP/IP software SHOULD accept and 501 forward to the IP layer any IP packets delivered to the client's 502 hardware address before the IP address is configured; DHCP servers 503 and BOOTP relay agents may not be able to deliver DHCP messages to 504 clients that cannot accept hardware unicast datagrams before the 505 TCP/IP software is configured. 507 To work around some clients that cannot accept IP unicast datagrams 508 before the TCP/IP software is configured as discussed in the previous 509 paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is 510 defined as the BROADCAST (B) flag. The semantics of this flag are 511 discussed in section 4.1 of this document. The remaining bits of the 512 flags field are reserved for future use. They MUST be set to zero by 513 clients and ignored by servers and relay agents. Figure 2 gives the 514 format of the 'flags' field. 516 1 1 1 1 1 1 517 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 |B| MBZ | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 B: BROADCAST flag 524 MBZ: MUST BE ZERO (reserved for future use) 526 Figure 2: Format of the 'flags' field 528 2.1 Configuration parameters repository 530 The first service provided by DHCP is to provide persistent storage 531 of network parameters for network clients. The model of DHCP 532 persistent storage is that the DHCP service stores a key-value entry 533 for each client, where the key is some unique identifier (for 534 example, an IP subnet number and a unique identifier within the 535 subnet) and the value contains the configuration parameters for the 536 client. 538 DRAFT Dynamic Host Configuration Protocol November 1996 540 For example, the key might be the pair (IP-subnet-number, hardware- 541 address) (note that the "hardware-address" should be typed by the 542 type of hardware to accommodate possible duplication of hardware 543 addresses resulting from bit-ordering problems in a mixed-media, 544 bridged network) allowing for serial or concurrent reuse of a 545 hardware address on different subnets, and for hardware addresses 546 that may not be globally unique. Alternately, the key might be the 547 pair (IP-subnet-number, hostname), allowing the server to assign 548 parameters intelligently to a DHCP client that has been moved to a 549 different subnet or has changed hardware addresses (perhaps because 550 the network interface failed and was replaced). The protocol defines 551 that the key will be (IP-subnet-number, hardware-address) unless the 552 client explicitly supplies an identifier using the 'client 553 identifier' option. 555 A client can query the DHCP service to retrieve its configuration 556 parameters. The client interface to the configuration parameters 557 repository consists of protocol messages to request configuration 558 parameters and responses from the server carrying the configuration 559 parameters. 561 2.2 Dynamic allocation of network addresses 563 The second service provided by DHCP is the allocation of temporary or 564 permanent network (IP) addresses to clients. The basic mechanism for 565 the dynamic allocation of network addresses is simple: a client 566 requests the use of an address for some period of time. The 567 allocation mechanism (the collection of DHCP servers) guarantees not 568 to reallocate that address within the requested time and attempts to 569 return the same network address each time the client requests an 570 address. In this document, the period over which a network address 571 is allocated to a client is referred to as a "lease" [11]. The 572 client may extend its lease with subsequent requests. The client may 573 issue a message to release the address back to the server when the 574 client no longer needs the address. The client may ask for a 575 permanent assignment by asking for an infinite lease. Even when 576 assigning "permanent" addresses, a server may choose to give out 577 lengthy but non-infinite leases to allow detection of the fact that 578 the client has been retired. 580 In some environments it will be necessary to reassign network 581 addresses due to exhaustion of available addresses. In such 582 environments, the allocation mechanism will reuse addresses whose 583 lease has expired. The server should use whatever information is 584 available in the configuration information repository to choose an 585 address to reuse. For example, the server may choose the least 586 recently assigned address. As a consistency check, the allocating 587 server SHOULD probe the reused address before allocating the address, 589 DRAFT Dynamic Host Configuration Protocol November 1996 591 e.g., with an ICMP echo request, and the client SHOULD probe the 592 newly received address, e.g., with ARP. 594 3. The Client-Server Protocol 596 DHCP uses the BOOTP message format defined in RFC 951 and given in 597 table 1 and figure 1. The 'op' field of each DHCP message sent from 598 a client to a server contains BOOTREQUEST. BOOTREPLY is used in the 599 'op' field of each DHCP message sent from a server to a client. 601 The first four octets of the 'options' field of the DHCP message 602 contain the (decimal) values 99, 130, 83 and 99, respectively (this 603 is the same magic cookie as is defined in RFC 1497 [17]). The 604 remainder of the 'options' field consists of a list of tagged 605 parameters that are called "options". All of the "vendor extensions" 606 listed in RFC 1497 are also DHCP options. RFC 1533 gives the 607 complete set of options defined for use with DHCP. 609 Several options have been defined so far. One particular option - 610 the "DHCP message type" option - must be included in every DHCP 611 message. This option defines the "type" of the DHCP message. 612 Additional options may be allowed, required, or not allowed, 613 depending on the DHCP message type. 615 Throughout this document, DHCP messages that include a 'DHCP message 616 type' option will be referred to by the type of the message; e.g., a 617 DHCP message with 'DHCP message type' option type 1 will be referred 618 to as a "DHCPDISCOVER" message. 620 3.1 Client-server interaction - allocating a network address 622 The following summary of the protocol exchanges between clients and 623 servers refers to the DHCP messages described in table 2. The 624 timeline diagram in figure 3 shows the timing relationships in a 625 typical client-server interaction. If the client already knows its 626 address, some steps may be omitted; this abbreviated interaction is 627 described in section 3.2. 629 1. The client broadcasts a DHCPDISCOVER message on its local physical 630 subnet. The DHCPDISCOVER message MAY include options that suggest 631 values for the network address and lease duration. BOOTP relay 632 agents may pass the message on to DHCP servers not on the same 633 physical subnet. 635 DRAFT Dynamic Host Configuration Protocol November 1996 637 2. Each server may respond with a DHCPOFFER message that includes an 638 available network address in the 'yiaddr' field (and other 639 configuration parameters in DHCP options). Servers need not 640 reserve the offered network address, although the protocol will 641 work more efficiently if the server avoids allocating the offered 642 network address to another client. When allocating a new address, 643 servers SHOULD check that the offered network address is not 644 already in use; e.g., the server may probe the offered address 645 with an ICMP Echo Request. Servers SHOULD be implemented so that 646 network administrators MAY choose to disable probes of newly 647 allocated addresses. The server transmits the DHCPOFFER message 648 to the client, using the BOOTP relay agent if necessary. 650 Message Use 651 ------- --- 653 DHCPDISCOVER - Client broadcast to locate available servers. 655 DHCPOFFER - Server to client in response to DHCPDISCOVER with 656 offer of configuration parameters. 658 DHCPREQUEST - Client message to servers either (a) requesting 659 offered parameters from one server and implicitly 660 declining offers from all others, (b) confirming 661 correctness of previously allocated address after, 662 e.g., system reboot, or (c) extending the lease on a 663 particular network address. 665 DHCPACK - Server to client with configuration parameters, 666 including committed network address. 668 DHCPNAK - Server to client indicating client's notion of network 669 address is incorrect (e.g., client has moved to new 670 subnet) or client's lease as expired 672 DHCPDECLINE - Client to server indicating network address is already 673 in use. 675 DHCPRELEASE - Client to server relinquishing network address and 676 cancelling remaining lease. 678 DHCPINFORM - Client to server, asking only for local configuration 679 parameters; client already has externally configured 680 network address. 682 Table 2: DHCP messages 684 DRAFT Dynamic Host Configuration Protocol November 1996 686 Server Client Server 687 (not selected) (selected) 689 v v v 690 | | | 691 | Begins initialization | 692 | | | 693 | _____________/|\_____________ | 694 |/ DHCPDISCOVER | DHCPDISCOVER \| 695 | | | 696 Determines | Determines 697 configuration | configuration 698 | | | 699 |\ | ____________/| 700 | \_________ | /DHCPOFFER | 701 | DHCPOFFER\ |/ | 702 | \ | | 703 | Collects replies | 704 | \| | 705 | Selects configuration | 706 | | | 707 | _____________/|\_____________ | 708 |/ DHCPREQUEST | DHCPREQUEST \| 709 | | | 710 | | Commits configuration 711 | | | 712 | | _____________/| 713 | |/ DHCPACK | 714 | | | 715 | Initialization complete | 716 | | | 717 . . . 718 . . . 719 | | | 720 | Graceful shutdown | 721 | | | 722 | |\_____________ | 723 | | DHCPRELEASE \| 724 | | | 725 | | Discards lease 726 | | | 727 v v v 728 Figure 3: Timeline diagram of messages exchanged between DHCP 729 client and servers when allocating a new network address 731 DRAFT Dynamic Host Configuration Protocol November 1996 733 3. The client receives one or more DHCPOFFER messages from one or more 734 servers. The client may choose to wait for multiple responses. 735 The client chooses one server from which to request configuration 736 parameters, based on the configuration parameters offered in the 737 DHCPOFFER messages. The client broadcasts a DHCPREQUEST message 738 that MUST include the 'server identifier' option to indicate which 739 server it has selected, and that MAY include other options 740 specifying desired configuration values. The 'requested IP 741 address' option MUST be set to the value of 'yiaddr' in the 742 DHCPOFFER message from the server. This DHCPREQUEST message is 743 broadcast and relayed through DHCP/BOOTP relay agents. To help 744 ensure that any BOOTP relay agents forward the DHCPREQUEST message 745 to the same set of DHCP servers that received the original 746 DHCPDISCOVER message, the DHCPREQUEST message MUST use the same 747 value in the DHCP message header's 'secs' field and be sent to the 748 same IP broadcast address as the original DHCPDISCOVER message. 749 The client times out and retransmits the DHCPDISCOVER message if 750 the client receives no DHCPOFFER messages. 752 4. The servers receive the DHCPREQUEST broadcast from the client. 753 Those servers not selected by the DHCPREQUEST message use the 754 message as notification that the client has declined that server's 755 offer. The server selected in the DHCPREQUEST message commits the 756 binding for the client to persistent storage and responds with a 757 DHCPACK message containing the configuration parameters for the 758 requesting client. The combination of 'client identifier' or 759 'chaddr' and assigned network address constitute a unique 760 identifier for the client's lease and are used by both the client 761 and server to identify a lease referred to in any DHCP messages. 762 Any configuration parameters in the DHCPACK message SHOULD NOT 763 conflict with those in the earlier DHCPOFFER message to which the 764 client is responding. The server SHOULD NOT check the offered 765 network address at this point. The 'yiaddr' field in the DHCPACK 766 messages is filled in with the selected network address. 768 If the selected server is unable to satisfy the DHCPREQUEST message 769 (e.g., the requested network address has been allocated), the 770 server SHOULD respond with a DHCPNAK message. 772 A server MAY choose to mark addresses offered to clients in 773 DHCPOFFER messages as unavailable. The server SHOULD mark an 774 address offered to a client in a DHCPOFFER message as available if 775 the server receives no DHCPREQUEST message from that client. 777 5. The client receives the DHCPACK message with configuration 778 parameters. The client SHOULD perform a final check on the 779 parameters (e.g., ARP for allocated network address), and notes the 780 duration of the lease specified in the DHCPACK message. At this 782 DRAFT Dynamic Host Configuration Protocol November 1996 784 point, the client is configured. If the client detects that the 785 address is already in use (e.g., through the use of ARP), the 786 client MUST send a DHCPDECLINE message to the server and restarts 787 the configuration process. The client SHOULD wait a minimum of ten 788 seconds before restarting the configuration process to avoid 789 excessive network traffic in case of looping. 791 If the client receives a DHCPNAK message, the client restarts the 792 configuration process. 794 The client times out and retransmits the DHCPREQUEST message if the 795 client receives neither a DHCPACK or a DHCPNAK message. The client 796 retransmits the DHCPREQUEST according to the retransmission 797 algorithm in section 4.1. The client should choose to retransmit 798 the DHCPREQUEST enough times to give adequate probability of 799 contacting the server without causing the client (and the user of 800 that client) to wait overly long before giving up; e.g., a client 801 retransmitting as described in section 4.1 might retransmit the 802 DHCPREQUEST message four times, for a total delay of 60 seconds, 803 before restarting the initialization procedure. If the client 804 receives neither a DHCPACK or a DHCPNAK message after employing the 805 retransmission algorithm, the client reverts to INIT state and 806 restarts the initialization process. The client SHOULD notify the 807 user that the initialization process has failed and is restarting. 809 6. The client may choose to relinquish its lease on a network address 810 by sending a DHCPRELEASE message to the server. The client 811 identifies the lease to be released with its 'client identifier', 812 or 'chaddr' and network address in the DHCPRELEASE message. If the 813 client used a 'client identifier' when it obtained the lease, it 814 MUST use the same 'client identifier' in the DHCPRELEASE message. 816 3.2 Client-server interaction - reusing a previously allocated network 817 address 819 If a client remembers and wishes to reuse a previously allocated 820 network address, a client may choose to omit some of the steps 821 described in the previous section. The timeline diagram in figure 4 822 shows the timing relationships in a typical client-server interaction 823 for a client reusing a previously allocated network address. 825 1. The client broadcasts a DHCPREQUEST message on its local subnet. 826 The message includes the client's network address in the 827 'requested IP address' option. As the client has not received its 828 network address, it MUST NOT fill in the 'ciaddr' field. BOOTP 829 relay agents pass the message on to DHCP servers not on the same 830 subnet. If the client used a 'client identifier' to obtain its 831 address, the client MUST use the same 'client identifier' in the 833 DRAFT Dynamic Host Configuration Protocol November 1996 835 DHCPREQUEST message. 837 2. Servers with knowledge of the client's configuration parameters 838 respond with a DHCPACK message to the client. Servers SHOULD NOT 839 check that the client's network address is already in use; the 840 client may respond to ICMP Echo Request messages at this point. 842 Server Client Server 844 v v v 845 | | | 846 | Begins | 847 | initialization | 848 | | | 849 | /|\ | 850 | ___________/ | \___________ | 851 | /DHCPREQUEST | DHCPREQUEST\ | 852 |/ | \| 853 | | | 854 Locates | Locates 855 configuration | configuration 856 | | | 857 |\ | /| 858 | \ | ___________/ | 859 | \ | / DHCPACK | 860 | \_______ |/ | 861 | DHCPACK\ | | 862 | Initialization | 863 | complete | 864 | \| | 865 | | | 866 | (Subsequent | 867 | DHCPACKS | 868 | ignored) | 869 | | | 870 | | | 871 v v v 873 Figure 4: Timeline diagram of messages exchanged between DHCP 874 client and servers when reusing a previously allocated 875 network address 877 If the client's request is invalid (e.g., the client has moved 878 to a new subnet), servers SHOULD respond with a DHCPNAK message to 879 the client. Servers SHOULD NOT respond if their information is not 880 guaranteed to be accurate. For example, a server that identifies a 881 request for an expired binding that is owned by another server SHOULD 883 DRAFT Dynamic Host Configuration Protocol November 1996 885 NOT respond with a DHCPNAK unless the servers are using an explicit 886 mechanism to maintain coherency among the servers. 888 If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on 889 the same subnet as the server. The server MUST 890 broadcast the DHCPNAK message to the 0xffffffff broadcast address 891 because the client may not have a correct network address or subnet 892 mask, and the client may not be answering ARP requests. 893 Otherwise, the server MUST send the DHCPNAK message to the IP 894 address of the BOOTP relay agent, as recorded in 'giaddr'. The 895 relay agent will, in turn, forward the message directly to the 896 client's hardware address, so that the DHCPNAK can be delivered even 897 if the client has moved to a new network. 899 3. The client receives the DHCPACK message with configuration 900 parameters. The client performs a final check on the parameters 901 (as in section 3.1), and notes the duration of the lease specified 902 in the DHCPACK message. The specific lease is implicitly identified 903 by the 'client identifier' or 'chaddr' and the network address. At 904 this point, the client is configured. 906 If the client detects that the IP address in the DHCPACK message 907 is already in use, the client MUST send a DHCPDECLINE message to the 908 server and restarts the configuration process by requesting a 909 new network address. This action corresponds to the client 910 moving to the INIT state in the DHCP state diagram, which is 911 described in section 4.4. 913 If the client receives a DHCPNAK message, it cannot reuse its 914 remembered network address. It must instead request a new 915 address by restarting the configuration process, this time 916 using the (non-abbreviated) procedure described in section 917 3.1. This action also corresponds to the client moving to 918 the INIT state in the DHCP state diagram. 920 The client times out and retransmits the DHCPREQUEST message if 921 the client receives neither a DHCPACK nor a DHCPNAK message. The 922 client retransmits the DHCPREQUEST according to the retransmission 923 algorithm in section 4.1. The client should choose to retransmit 924 the DHCPREQUEST enough times to give adequate probability of 925 contacting the server without causing the client (and the user of 926 that client) to wait overly long before giving up; e.g., a client 927 retransmitting as described in section 4.1 might retransmit the 928 DHCPREQUEST message four times, for a total delay of 60 seconds, 929 before restarting the initialization procedure. If the client 930 receives neither a DHCPACK or a DHCPNAK message after employing 931 the retransmission algorithm, the client MAY choose to use the 932 previously allocated network address and configuration parameters 934 DRAFT Dynamic Host Configuration Protocol November 1996 936 for the remainder of the unexpired lease. This corresponds to 937 moving to BOUND state in the client state transition diagram shown 938 in figure 5. 940 4. The client may choose to relinquish its lease on a network 941 address by sending a DHCPRELEASE message to the server. The 942 client identifies the lease to be released with its 943 'client identifier', or 'chaddr' and network address in the 944 DHCPRELEASE message. 946 Note that in this case, where the client retains its network 947 address locally, the client will not normally relinquish its 948 lease during a graceful shutdown. Only in the case where the 949 client explicitly needs to relinquish its lease, e.g., the client 950 is about to be moved to a different subnet, will the client send 951 a DHCPRELEASE message. 953 3.3 Interpretation and representation of time values 955 A client acquires a lease for a network address for a fixed period of 956 time (which may be infinite). Throughout the protocol, times are to 957 be represented in units of seconds. The time value of 0xffffffff is 958 reserved to represent "infinity". 960 As clients and servers may not have synchronized clocks, times are 961 represented in DHCP messages as relative times, to be interpreted 962 with respect to the client's local clock. Representing relative 963 times in units of seconds in an unsigned 32 bit word gives a range of 964 relative times from 0 to approximately 100 years, which is sufficient 965 for the relative times to be measured using DHCP. 967 The algorithm for lease duration interpretation given in the previous 968 paragraph assumes that client and server clocks are stable relative 969 to each other. If there is drift between the two clocks, the server 970 may consider the lease expired before the client does. To 971 compensate, the server may return a shorter lease duration to the 972 client than the server commits to its local database of client 973 information. 975 3.4 Obtaining parameters with externally configured network address 977 If a client has obtained a network address through some other means 978 (e.g., manual configuration), it may use a DHCPINFORM request message 979 to obtain other local configuration parameters. Servers receiving a 980 DHCPINFORM message construct a DHCPACK message with any local 981 configuration parameters appropriate for the client without: 982 allocating a new address, checking for an existing binding, filling 983 in 'yiaddr' or including lease time parameters. The servers SHOULD 985 DRAFT Dynamic Host Configuration Protocol November 1996 987 unicast the DHCPACK reply to the address given in the 'ciaddr' field 988 of the DHCPINFORM message. 990 The server SHOULD check the network address in a DHCPINFORM message 991 for consistency, but MUST NOT check for an existing lease. The 992 server forms a DHCPACK message containing the configuration 993 parameters for the requesting client and sends the DHCPACK message 994 directly to the client. 996 3.5 Client parameters in DHCP 998 Not all clients require initialization of all parameters listed in 999 Appendix A. Two techniques are used to reduce the number of 1000 parameters transmitted from the server to the client. First, most of 1001 the parameters have defaults defined in the Host Requirements RFCs; 1002 if the client receives no parameters from the server that override 1003 the defaults, a client uses those default values. Second, in its 1004 initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the 1005 server with a list of specific parameters the client is interested 1006 in. If the client includes a list of parameters in a DHCPDISCOVER 1007 message, it MUST include that list in any subsequent DHCPREQUEST 1008 messages. 1010 The client SHOULD include the 'maximum DHCP message size' option to 1011 let the server know how large the server may make its DHCP messages. 1012 The parameters returned to a client may still exceed the space 1013 allocated to options in a DHCP message. In this case, two additional 1014 options flags (which must appear in the 'options' field of the 1015 message) indicate that the 'file' and 'sname' fields are to be used 1016 for options. 1018 The client can inform the server which configuration parameters the 1019 client is interested in by including the 'parameter request list' 1020 option. The data portion of this option explicitly lists the options 1021 requested by tag number. 1023 In addition, the client may suggest values for the network address 1024 and lease time in the DHCPDISCOVER message. The client may include 1025 the 'requested IP address' option to suggest that a particular IP 1026 address be assigned, and may include the 'IP address lease time' 1027 option to suggest the lease time it would like. Other options 1028 representing "hints" at configuration parameters are allowed in a 1029 DHCPDISCOVER or DHCPREQUEST message. However, additional options may 1030 be ignored by servers, and multiple servers may, therefore, not 1031 return identical values for some options. The 'requested IP address' 1032 option is to be filled in only in a DHCPREQUEST message when the 1033 client is verifying network parameters obtained previously. The 1034 client fills in the 'ciaddr' field only when correctly configured 1036 DRAFT Dynamic Host Configuration Protocol November 1996 1038 with an IP address in BOUND, RENEWING or REBINDING state. 1040 If a server receives a DHCPREQUEST message with an invalid 'requested 1041 IP address', the server SHOULD respond to the client with a DHCPNAK 1042 message and may choose to report the problem to the system 1043 administrator. The server may include an error message in the 1044 'message' option. 1046 3.6 Use of DHCP in clients with multiple interfaces 1048 A client with multiple network interfaces must use DHCP through each 1049 interface independently to obtain configuration information 1050 parameters for those separate interfaces. 1052 3.7 When clients should use DHCP 1054 A client SHOULD use DHCP to reacquire or verify its IP address and 1055 network parameters whenever the local network parameters may have 1056 changed; e.g., at system boot time or after a disconnection from the 1057 local network, as the local network configuration may change without 1058 the client's or user's knowledge. 1060 If a client has knowledge of a previous network address and is unable 1061 to contact a local DHCP server, the client may continue to use the 1062 previous network address until the lease for that address expires. 1063 If the lease expires before the client can contact a DHCP server, the 1064 client must immediately discontinue use of the previous network 1065 address and may inform local users of the problem. 1067 4. Specification of the DHCP client-server protocol 1069 In this section, we assume that a DHCP server has a block of network 1070 addresses from which it can satisfy requests for new addresses. Each 1071 server also maintains a database of allocated addresses and leases in 1072 local permanent storage. 1074 4.1 Constructing and sending DHCP messages 1076 DHCP clients and servers both construct DHCP messages by filling in 1077 fields in the fixed format section of the message and appending 1078 tagged data items in the variable length option area. The options 1079 area includes first a four-octet 'magic cookie' (which was described 1080 in section 3), followed by the options. The last option must always 1081 be the 'end' option. 1083 DHCP uses UDP as its transport protocol. DHCP messages from a client 1084 to a server are sent to the 'DHCP server' port (67), and DHCP 1085 messages from a server to a client are sent to the 'DHCP client' port 1087 DRAFT Dynamic Host Configuration Protocol November 1996 1089 (68). A server with multiple network address (e.g., a multi-homed 1090 host) MAY use any of its network addresses in outgoing DHCP messages. 1092 DHCP messages broadcast by a client prior to that client obtaining 1093 its IP address must have the source address field in the IP header 1094 set to 0. 1096 If the 'giaddr' field in a DHCP message from a client is non-zero, 1097 the server sends any return messages to the 'DHCP server' port on the 1098 BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr' 1099 field is zero and the 'ciaddr' field is nonzero, then the server 1100 unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'. 1101 If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is 1102 set, then the server broadcasts DHCPOFFER and DHCPACK messages to 1103 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and 1104 'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK 1105 messages to the client's hardware address and 'yiaddr' address. In 1106 all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK 1107 messages to 0xffffffff. 1109 If the options in a DHCP message extend into the 'sname' and 'file' 1110 fields, the 'option overload' option MUST appear in the 'options' 1111 field, with value 1, 2 or 3, as specified in RFC 1533. If the 1112 'option overload' option is present in the 'options' field, the 1113 options in the 'options' field MUST be terminated by an 'end' option, 1114 and MAY contain one or more 'pad' options to fill the options field. 1115 The options in the 'sname' and 'file' fields (if in use as indicated 1116 by the 'options overload' option) MUST begin with the first octet of 1117 the field, MUST be terminated by an 'end' option, and MUST be 1118 followed by 'pad' options to fill the remainder of the field. Any 1119 individual option in the 'options', 'sname' and 'file' fields MUST be 1120 entirely contained in that field. The options in the 'options' field 1121 MUST be interpreted first, so that any 'option overload' options may 1122 be interpreted. The 'file' field MUST be interpreted next (if the 1123 'option overload' option indicates that the 'file' field contains 1124 DHCP options), followed by the 'sname' field. 1126 The values to be passed in an 'option' tag may be too long to fit in 1127 the 255 octets available to a single option (e.g., a list of routers 1128 in a 'router' option [21]). Options may appear only once, unless 1129 otherwise specified in the options document. The client concatenates 1130 the values of multiple instances of the same option into a single 1131 parameter list for configuration. 1133 DHCP clients are responsible for all message retransmission. The 1134 client MUST adopt a retransmission strategy that incorporates a 1135 randomized exponential backoff algorithm to determine the delay 1136 between retransmissions. The delay between retransmissions SHOULD be 1138 DRAFT Dynamic Host Configuration Protocol November 1996 1140 chosen to allow sufficient time for replies from the server to be 1141 delivered based on the characteristics of the internetwork between 1142 the client and the server. For example, in a 10Mb/sec Ethernet 1143 internetwork, the delay before the first retransmission SHOULD be 4 1144 seconds randomized by the value of a uniform random number chosen 1145 from the range -1 to +1. Clients with clocks that provide resolution 1146 granularity of less than one second may choose a non-integer 1147 randomization value. The delay before the next retransmission SHOULD 1148 be 8 seconds randomized by the value of a uniform number chosen from 1149 the range -1 to +1. The retransmission delay SHOULD be doubled with 1150 subsequent retransmissions up to a maximum of 64 seconds. The client 1151 MAY provide an indication of retransmission attempts to the user as 1152 an indication of the progress of the configuration process. 1154 The 'xid' field is used by the client to match incoming DHCP messages 1155 with pending requests. A DHCP client MUST choose 'xid's in such a 1156 way as to minimize the chance of using an 'xid' identical to one used 1157 by another client. For example, a client may choose a different, 1158 random initial 'xid' each time the client is rebooted, and 1159 subsequently use sequential 'xid's until the next reboot. Selecting 1160 a new 'xid' for each retransmission is an implementation decision. A 1161 client may choose to reuse the same 'xid' or select a new 'xid' for 1162 each retransmitted message. 1164 Normally, DHCP servers and BOOTP relay agents attempt to deliver 1165 DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using 1166 unicast delivery. The IP destination address (in the IP header) is 1167 set to the DHCP 'yiaddr' address and the link-layer destination 1168 address is set to the DHCP 'chaddr' address. Unfortunately, some 1169 client implementations are unable to receive such unicast IP 1170 datagrams until the implementation has been configured with a valid 1171 IP address (leading to a deadlock in which the client's IP address 1172 cannot be delivered until the client has been configured with an IP 1173 address). 1175 A client that cannot receive unicast IP datagrams until its protocol 1176 software has been configured with an IP address SHOULD set the 1177 BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or 1178 DHCPREQUEST messages that client sends. The BROADCAST bit will 1179 provide a hint to the DHCP server and BOOTP relay agent to broadcast 1180 any messages to the client on the client's subnet. A client that can 1181 receive unicast IP datagrams before its protocol software has been 1182 configured SHOULD clear the BROADCAST bit to 0. The BOOTP 1183 clarifications document discusses the ramifications of the use of the 1184 BROADCAST bit [21]. 1186 A server or relay agent sending or relaying a DHCP message directly 1187 to a DHCP client (i.e., not to a relay agent specified in the 1189 DRAFT Dynamic Host Configuration Protocol November 1996 1191 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags' 1192 field. If this bit is set to 1, the DHCP message SHOULD be sent as 1193 an IP broadcast using an IP broadcast address (preferably 0xffffffff) 1194 as the IP destination address and the link-layer broadcast address as 1195 the link-layer destination address. If the BROADCAST bit is cleared 1196 to 0, the message SHOULD be sent as an IP unicast to the IP address 1197 specified in the 'yiaddr' field and the link-layer address specified 1198 in the 'chaddr' field. If unicasting is not possible, the message 1199 MAY be sent as an IP broadcast using an IP broadcast address 1200 (preferably 0xffffffff) as the IP destination address and the link- 1201 layer broadcast address as the link-layer destination address. 1203 4.2 DHCP server administrative controls 1205 DHCP servers are not required to respond to every DHCPDISCOVER and 1206 DHCPREQUEST message they receive. For example, a network 1207 administrator, to retain stringent control over the clients attached 1208 to the network, may choose to configure DHCP servers to respond only 1209 to clients that have been previously registered through some external 1210 mechanism. The DHCP specification describes only the interactions 1211 between clients and servers when the clients and servers choose to 1212 interact; it is beyond the scope of the DHCP specification to 1213 describe all of the administrative controls that system 1214 administrators might want to use. Specific DHCP server 1215 implementations may incorporate any controls or policies desired by a 1216 network administrator. 1218 In some environments, a DHCP server will have to consider the values 1219 of the vendor class options included in DHCPDISCOVER or DHCPREQUEST 1220 messages when determining the correct parameters for a particular 1221 client. 1223 A DHCP server needs to use some unique identifier to associate a 1224 client with its lease. The client MAY choose to explicitly provide 1225 the identifier through the 'client identifier' option. If the client 1226 supplies a 'client identifier', the client MUST use the same 'client 1227 identifier' in all subsequent messages, and the server MUST use that 1228 identifier to identify the client. If the client does not provide a 1229 'client identifier' option, the server MUST use the contents of the 1230 'chaddr' field to identify the client. It is crucial for a DHCP 1231 client to use an identifier unique within the subnet to which the 1232 client is attached in the 'client identifier' option. Use of 1233 'chaddr' as the client's unique identifier may cause unexpected 1234 results, as that identifier may be associated with a hardware 1235 interface that could be moved to a new client. Some sites may choose 1236 to use a manufacturer's serial number as the 'client identifier', to 1237 avoid unexpected changes in a clients network address due to transfer 1238 of hardware interfaces among computers. Sites may also choose to use 1240 DRAFT Dynamic Host Configuration Protocol November 1996 1242 a DNS name as the 'client identifier', causing address leases to be 1243 associated with the DNS name rather than a specific hardware box. 1245 DHCP clients are free to use any strategy in selecting a DHCP server 1246 among those from which the client receives a DHCPOFFER message. The 1247 client implementation of DHCP SHOULD provide a mechanism for the user 1248 to select directly the 'vendor class identifier' values. 1250 4.3 DHCP server behavior 1252 A DHCP server processes incoming DHCP messages from a client based on 1253 the current state of the binding for that client. A DHCP server can 1254 receive the following messages from a client: 1256 o DHCPDISCOVER 1258 o DHCPREQUEST 1260 o DHCPDECLINE 1262 o DHCPRELEASE 1264 o DHCPINFORM 1266 Table 3 gives the use of the fields and options in a DHCP message by 1267 a server. The remainder of this section describes the action of the 1268 DHCP server for each possible incoming message. 1270 4.3.1 DHCPDISCOVER message 1272 When a server receives a DHCPDISCOVER message from a client, the 1273 server chooses a network address for the requesting client. If no 1274 address is available, the server may choose to report the problem to 1275 the system administrator. If an address is available, the new address 1276 SHOULD be chosen as follows: 1278 o The client's current address as recorded in the client's current 1279 binding, ELSE 1281 o The client's previous address as recorded in the client's (now 1282 expired or released) binding, if that address is in the server's 1283 pool of available addresses and not already allocated, ELSE 1285 o The address requested in the 'Requested IP Address' option, if that 1286 address is valid and not already allocated, ELSE 1288 o A new address allocated from the server's pool of available 1289 addresses; the address is selected based on the subnet from which 1291 DRAFT Dynamic Host Configuration Protocol November 1996 1293 the message was received (if 'giaddr' is 0) or on the address of 1294 the relay agent that forwarded the message ('giaddr' when not 0). 1296 As described in section 4.2, a server MAY, for administrative 1297 reasons, assign an address other than the one requested, or may 1298 refuse to allocate an address to a particular client even though free 1299 addresses are available. 1301 Note that, in some network architectures (e.g., internets with more 1302 than one IP subnet assigned to a physical network segment), it may be 1303 the case that the DHCP client should be assigned an address from a 1304 different subnet than the address recorded in 'giaddr'. Thus, DHCP 1305 does not require that the client be assigned as address from the 1306 subnet in 'giaddr'. A server is free to choose some other subnet, 1307 and it is beyond the scope of the DHCP specification to describe ways 1308 in which the assigned IP address might be chosen. 1310 While not required for correct operation of DHCP, the server SHOULD 1311 NOT reuse the selected network address before the client responds to 1312 the server's DHCPOFFER message. The server may choose to record the 1313 address as offered to the client. 1315 The server must also choose an expiration time for the lease, as 1316 follows: 1318 o IF the client has not requested a specific lease in the 1319 DHCPDISCOVER message and the client already has an assigned network 1320 address, the server returns the lease expiration time previously 1321 assigned to that address (note that the client must explicitly 1322 request a specific lease to extend the expiration time on a 1323 previously assigned address), ELSE 1325 o IF the client has not requested a specific lease in the 1326 DHCPDISCOVER message and the client does not have an assigned 1327 network address, the server assigns a locally configured default 1328 lease time, ELSE 1330 o IF the client has requested a specific lease in the DHCPDISCOVER 1331 message (regardless of whether the client has an assigned network 1332 address), the server may choose either to return the requested 1333 lease (if the lease is acceptable to local policy) or select 1334 another lease. 1336 DRAFT Dynamic Host Configuration Protocol November 1996 1338 Field DHCPOFFER DHCPACK DHCPNAK 1339 ----- --------- ------- ------- 1340 'op' BOOTREPLY BOOTREPLY BOOTREPLY 1341 'htype' (From "Assigned Numbers" RFC) 1342 'hlen' (Hardware address length in octets) 1343 'hops' 0 0 0 1344 'xid' 'xid' from client 'xid' from client 'xid' from client 1345 DHCPDISCOVER DHCPREQUEST DHCPREQUEST 1346 message message message 1347 'secs' 0 0 0 1348 'ciaddr' 0 'ciaddr' from 0 1349 DHCPREQUEST or 0 1350 'yiaddr' IP address offered IP address 0 1351 to client assigned to client 1352 'siaddr' IP address of next IP address of next 0 1353 bootstrap server bootstrap server 1354 'flags' 'flags' from 'flags' from 'flags' from 1355 client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST 1356 message message message 1357 'giaddr' 'giaddr' from 'giaddr' from 'giaddr' from 1358 client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST 1359 message message message 1360 'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from 1361 client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST 1362 message message message 1363 'sname' Server host name Server host name (unused) 1364 or options or options 1365 'file' Client boot file Client boot file (unused) 1366 name or options name or options 1367 'options' options options 1369 Option DHCPOFFER DHCPACK DHCPNAK 1370 ------ --------- ------- ------- 1371 Requested IP address MUST NOT MUST NOT MUST NOT 1372 IP address lease time MUST MUST (DHCPREQUEST) MUST NOT 1373 MUST NOT (DHCPINFORM) 1374 Use 'file'/'sname' fields MAY MAY MUST NOT 1375 DHCP message type DHCPOFFER DHCPACK DHCPNAK 1376 Parameter request list MUST NOT MUST NOT MUST NOT 1377 Message SHOULD SHOULD SHOULD 1378 Client identifier MUST NOT MUST NOT MAY 1379 Vendor class identifier MAY MAY MAY 1380 Server identifier MUST MUST MUST 1381 Maximum message size MUST NOT MUST NOT MUST NOT 1382 All others MAY MAY MUST NOT 1384 Table 3: Fields and options used by DHCP servers 1386 DRAFT Dynamic Host Configuration Protocol November 1996 1388 Once the network address and lease have been determined, the server 1389 constructs a DHCPOFFER message with the offered configuration 1390 parameters. It is important for all DHCP servers to return the same 1391 parameters (with the possible exception of a newly allocated network 1392 address) to ensure predictable client behavior regardless of which 1393 server the client selects. The configuration parameters MUST be 1394 selected by applying the following rules in the order given below. 1395 The network administrator is responsible for configuring multiple 1396 DHCP servers to ensure uniform responses from those servers. The 1397 server MUST return to the client: 1399 o The client's network address, as determined by the rules given 1400 earlier in this section, 1402 o The expiration time for the client's lease, as determined by the 1403 rules given earlier in this section, 1405 o Parameters requested by the client, according to the following 1406 rules: 1408 -- IF the server has been explicitly configured with a default 1409 value for the parameter, the server MUST include that value 1410 in an appropriate option in the 'option' field, ELSE 1412 -- IF the server recognizes the parameter as a parameter 1413 defined in the Host Requirements Document, the server MUST 1414 include the default value for that parameter as given in the 1415 Host Requirements Document in an appropriate option in the 1416 'option' field, ELSE 1418 -- The server MUST NOT return a value for that parameter, 1420 The server MUST supply as many of the requested parameters as 1421 possible and MUST omit any parameters it cannot provide. The 1422 server MUST include each requested parameter only once unless 1423 explicitly allowed in the DHCP Options and BOOTP Vendor 1424 Extensions document. 1426 o Any parameters from the existing binding that differ from the Host 1427 Requirements Document defaults, 1429 o Any parameters specific to this client (as identified by 1430 the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER 1431 or DHCPREQUEST message), e.g., as configured by the network 1432 administrator, 1434 DRAFT Dynamic Host Configuration Protocol November 1996 1436 o Any parameters specific to this client's class (as identified 1437 by the contents of the 'vendor class identifier' 1438 option in the DHCPDISCOVER or DHCPREQUEST message), 1439 e.g., as configured by the network administrator; the parameters 1440 MUST be identified by an exact match between the client's vendor 1441 class identifiers and the client's classes identified in the 1442 server, 1444 o Parameters with non-default values on the client's subnet. 1446 The server MAY choose to return the 'vendor class identifier' used to 1447 determine the parameters in the DHCPOFFER message to assist the 1448 client in selecting which DHCPOFFER to accept. The server inserts 1449 the 'xid' field from the DHCPDISCOVER message into the 'xid' field of 1450 the DHCPOFFER message and sends the DHCPOFFER message to the 1451 requesting client. 1453 4.3.2 DHCPREQUEST message 1455 A DHCPREQUEST message may come from a client responding to a 1456 DHCPOFFER message from a server, from a client verifying a previously 1457 allocated IP address or from a client extending the lease on a 1458 network address. If the DHCPREQUEST message contains a 'server 1459 identifier' option, the message is in response to a DHCPOFFER 1460 message. Otherwise, the message is a request to verify or extend an 1461 existing lease. If the client uses a 'client identifier' in a 1462 DHCPREQUEST message, it MUST use that same 'client identifier' in all 1463 subsequent messages. If the client included a list of requested 1464 parameters in a DHCPDISCOVER message, it MUST include that list in 1465 all subsequent messages. 1467 Any configuration parameters in the DHCPACK message SHOULD NOT 1468 conflict with those in the earlier DHCPOFFER message to which the 1469 client is responding. The client SHOULD use the parameters in the 1470 DHCPACK message for configuration. 1472 Clients send DHCPREQUEST messages as follows: 1474 o DHCPREQUEST generated during SELECTING state: 1476 Client inserts the address of the selected server in 'server 1477 identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be 1478 filled in with the yiaddr value from the chosen DHCPOFFER. 1480 Note that the client may choose to collect several DHCPOFFER 1481 messages and select the "best" offer. The client indicates its 1482 selection by identifying the offering server in the DHCPREQUEST 1483 message. If the client receives no acceptable offers, the client 1485 DRAFT Dynamic Host Configuration Protocol November 1996 1487 may choose to try another DHCPDISCOVER message. Therefore, the 1488 servers may not receive a specific DHCPREQUEST from which they can 1489 decide whether or not the client has accepted the offer. Because 1490 the servers have not committed any network address assignments on 1491 the basis of a DHCPOFFER, servers are free to reuse offered network 1492 addresses in response to subsequent requests. As an implementation 1493 detail, servers SHOULD NOT reuse offered addresses and may use an 1494 implementation-specific timeout mechanism to decide when to reuse 1495 an offered address. 1497 o DHCPREQUEST generated during INIT-REBOOT state: 1499 'server identifier' MUST NOT be filled in, 'requested IP address' 1500 option MUST be filled in with client's notion of its previously 1501 assigned address. 'ciaddr' MUST be zero. The client is seeking to 1502 verify a previously allocated, cached configuration. Server SHOULD 1503 send a DHCPNAK message to the client if the 'requested IP address' 1504 is incorrect, or is on the wrong network. 1506 Determining whether a client in the INIT-REBOOT state is on the 1507 correct network is done by examining the contents of 'giaddr', the 1508 'requested IP address' option, and a database lookup. If the DHCP 1509 server detects that the client is on the wrong net (i.e., the 1510 result of applying the local subnet mask or remote subnet mask (if 1511 'giaddr' is not zero) to 'requested IP address' option value 1512 doesn't match reality), then the server SHOULD send a DHCPNAK 1513 message to the client. 1515 If the network is correct, then the DHCP server should check if the 1516 client's notion of its IP address is correct. If not, then the 1517 server SHOULD send a DHCPNAK message to the client. If the DHCP 1518 server has no record of this client, then it MUST remain silent, 1519 and MAY output a warning to the network administrator. This 1520 behavior is necessary for peaceful coexistence of non-communicating 1521 DHCP servers on the same wire. 1523 If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on the 1524 same subnet as the server. The server MUST broadcast the DHCPNAK 1525 message to the 0xffffffff broadcast address because the client may 1526 not have a correct network address or subnet mask, and the client 1527 may not be answering ARP requests. 1529 If 'giaddr' is set in the DHCPREQUEST message, the client is on a 1530 different subnet. The server MUST set the broadcast bit in the 1531 DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the 1532 client, because the client may not have a correct network address 1533 or subnet mask, and the client may not be answering ARP requests. 1535 DRAFT Dynamic Host Configuration Protocol November 1996 1537 o DHCPREQUEST generated during RENEWING state: 1539 'server identifier' MUST NOT be filled in, 'requested IP address' 1540 option MUST NOT be filled in, 'ciaddr' MUST be filled in with 1541 client's IP address. In this situation, the client is completely 1542 configured, and is trying to extend its lease. This message will be 1543 unicast, so no relay agents will be involved in its transmission. 1544 Because 'giaddr' is therefore not filled in, the DHCP server will 1545 trust the value in 'ciaddr', and use it when replying to the 1546 client. 1548 A client MAY choose to renew or extend its lease prior to T1. The 1549 server may choose not to extend the lease (as a policy decision by 1550 the network administrator), but should return a DHCPACK message 1551 regardless. 1553 o DHCPREQUEST generated during REBINDING state: 1555 'server identifier' MUST NOT be filled in, 'requested IP address' 1556 option MUST NOT be filled in, 'ciaddr' MUST be filled in with 1557 client's IP address. In this situation, the client is completely 1558 configured, and is trying to extend its lease. This message MUST be 1559 broadcast to the 0xffffffff IP broadcast address. The DHCP server 1560 SHOULD check 'ciaddr' for correctness before replying to the 1561 DHCPREQUEST. 1563 The DHCPREQUEST from a REBINDING client is intended to accommodate 1564 sites that have multiple DHCP servers and a mechanism for 1565 maintaining consistency among leases managed by multiple servers. 1566 A DHCP server MAY extend a client's lease only if it has local 1567 administrative authority to do so. 1569 4.3.3 DHCPDECLINE message 1571 If the server receives a DHCPDECLINE message, the client has 1572 discovered through some other means that the suggested network 1573 address is already in use. The server MUST mark the network address 1574 as not available and SHOULD notify the local system administrator of 1575 a possible configuration problem. 1577 4.3.4 DHCPRELEASE message 1579 Upon receipt of a DHCPRELEASE message, the server marks the network 1580 address as not allocated. The server SHOULD retain a record of the 1581 client's initialization parameters for possible reuse in response to 1582 subsequent requests from the client. 1584 4.3.5 DHCPINFORM message 1585 DRAFT Dynamic Host Configuration Protocol November 1996 1587 The server responds to a DHCPINFORM message by sending a DHCPACK 1588 message directly to the address given in the 'ciaddr' field of the 1589 DHCPINFORM message. The server MUST NOT send a lease expiration time 1590 to the client and SHOULD NOT fill in 'yiaddr'. The server includes 1591 other parameters in the DHCPACK message as defined in section 4.3.1. 1593 4.3.6 Client messages 1595 Table 4 details the differences between messages from clients in 1596 various states. 1598 --------------------------------------------------------------------- 1599 | |INIT-REBOOT |SELECTING |RENEWING |REBINDING | 1600 --------------------------------------------------------------------- 1601 |broad/unicast |broadcast |broadcast |unicast |broadcast | 1602 |server-ip |MUST NOT |MUST |MUST NOT |MUST NOT | 1603 |requested-ip |MUST |MUST |MUST NOT |MUST NOT | 1604 |ciaddr |zero |zero |IP address |IP address| 1605 --------------------------------------------------------------------- 1607 Table 4: Client messages from different states 1609 4.4 DHCP client behavior 1611 Figure 5 gives a state-transition diagram for a DHCP client. A 1612 client can receive the following messages from a server: 1614 o DHCPOFFER 1616 o DHCPACK 1618 o DHCPNAK 1620 The DHCPINFORM message is not shown in figure 5. A client simply 1621 sends the DHCPINFORM and waits for DHCPACK messages. Once the client 1622 has selected its parameters, it has completed the configuration 1623 process. 1625 Table 5 gives the use of the fields and options in a DHCP message by 1626 a client. The remainder of this section describes the action of the 1627 DHCP client for each possible incoming message. The description in 1628 the following section corresponds to the full configuration procedure 1629 previously described in section 3.1, and the text in the subsequent 1630 section corresponds to the abbreviated configuration procedure 1631 described in section 3.2. 1633 DRAFT Dynamic Host Configuration Protocol November 1996 1635 -------- ------- 1636 | | +-------------------------->| |<-------------------+ 1637 | INIT- | | +-------------------->| INIT | | 1638 | REBOOT |DHCPNAK/ +---------->| |<---+ | 1639 | |Restart| | ------- | | 1640 -------- | DHCPNAK/ | | | 1641 | Discard offer | -/Send DHCPDISCOVER | 1642 -/Send DHCPREQUEST | | | 1643 | | | DHCPACK v | | 1644 ----------- | (not accept.)/ ----------- | | 1645 | | | Send DHCPDECLINE | | | 1646 | REBOOTING | | | | SELECTING |<----+ | 1647 | | | / | | |DHCPOFFER/ | 1648 ----------- | / ----------- | |Collect | 1649 | | / | | | replies | 1650 DHCPACK/ | / +----------------+ +-------+ | 1651 Record lease, set| | v Select offer/ | 1652 timers T1, T2 ------------ send DHCPREQUEST | | 1653 | +----->| | DHCPNAK, Lease expired/ | 1654 | | | REQUESTING | Halt network | 1655 DHCPOFFER/ | | | | 1656 Discard ------------ | | 1657 | | | | ----------- | 1658 | +--------+ DHCPACK/ | | | 1659 | Record lease, set -----| REBINDING | | 1660 | timers T1, T2 / | | | 1661 | | DHCPACK/ ----------- | 1662 | v Record lease, set ^ | 1663 +----------------> ------- /timers T1,T2 | | 1664 +----->| |<---+ | | 1665 | | BOUND |<---+ | | 1666 DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/ 1667 DHCPNAK/Discard ------- | Broadcast Halt network 1668 | | | | DHCPREQUEST | 1669 +-------+ | DHCPACK/ | | 1670 T1 expires/ Record lease, set | | 1671 Send DHCPREQUEST timers T1, T2 | | 1672 to leasing server | | | 1673 | ---------- | | 1674 | | |------------+ | 1675 +->| RENEWING | | 1676 | |----------------------------+ 1677 ---------- 1678 Figure 5: State-transition diagram for DHCP clients 1680 DRAFT Dynamic Host Configuration Protocol November 1996 1682 4.4.1 Initialization and allocation of network address 1684 The client begins in INIT state and forms a DHCPDISCOVER message. 1685 The client SHOULD wait a random time between one and ten seconds to 1686 desynchronize the use of DHCP at startup. The client sets 'ciaddr' 1687 to 0x00000000. The client MAY request specific parameters by 1688 including the 'parameter request list' option. The client MAY 1689 suggest a network address and/or lease time by including the 1690 'requested IP address' and 'IP address lease time' options. The 1691 client MUST include its hardware address in the 'chaddr' field, if 1692 necessary for delivery of DHCP reply messages. The client MAY 1693 include a different unique identifier in the 'client identifier' 1694 option, as discussed in section 4.2. If the client included a list 1695 of requested parameters in a DHCPDISCOVER message, it MUST include 1696 that list in all subsequent messages. 1698 The client generates and records a random transaction identifier and 1699 inserts that identifier into the 'xid' field. The client records its 1700 own local time for later use in computing the lease expiration. The 1701 client then broadcasts the DHCPDISCOVER on the local hardware 1702 broadcast address to the 0xffffffff IP broadcast address and 'DHCP 1703 server' UDP port. 1705 If the 'xid' of an arriving DHCPOFFER message does not match the 1706 'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message 1707 must be silently discarded. Any arriving DHCPACK messages must be 1708 silently discarded. 1710 The client collects DHCPOFFER messages over a period of time, selects 1711 one DHCPOFFER message from the (possibly many) incoming DHCPOFFER 1712 messages (e.g., the first DHCPOFFER message or the DHCPOFFER message 1713 from the previously used server) and extracts the server address from 1714 the 'server identifier' option in the DHCPOFFER message. The time 1715 over which the client collects messages and the mechanism used to 1716 select one DHCPOFFER are implementation dependent. 1718 DRAFT Dynamic Host Configuration Protocol November 1996 1720 Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE, 1721 DHCPINFORM DHCPRELEASE 1722 ----- ------------ ----------- ----------- 1723 'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST 1724 'htype' (From "Assigned Numbers" RFC) 1725 'hlen' (Hardware address length in octets) 1726 'hops' 0 0 0 1727 'xid' selected by client 'xid' from server selected by 1728 DHCPOFFER message client 1729 'secs' 0 or seconds since 0 or seconds since 0 1730 DHCP process started DHCP process started 1731 'flags' Set 'BROADCAST' Set 'BROADCAST' 0 1732 flag if client flag if client 1733 requires broadcast requires broadcast 1734 reply reply 1735 'ciaddr' 0 (DHCPDISCOVER) 0 or client's 0 (DHCPDECLINE) 1736 client's network address client's network 1737 network address (BOUND/RENEW/REBIND) address 1738 (DHCPINFORM) (DHCPRELEASE) 1739 'yiaddr' 0 0 0 1740 'siaddr' 0 0 0 1741 'giaddr' 0 0 0 1742 'chaddr' client's hardware client's hardware client's hardware 1743 address address address 1744 'sname' options, if options, if (unused) 1745 indicated in indicated in 1746 'sname/file' 'sname/file' 1747 option; otherwise option; otherwise 1748 unused unused 1749 'file' options, if options, if (unused) 1750 indicated in indicated in 1751 'sname/file' 'sname/file' 1752 option; otherwise option; otherwise 1753 unused unused 1754 'options' options options (unused) 1756 Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE, 1757 DHCPINFORM DHCPRELEASE 1758 ------ ------------ ----------- ----------- 1759 Requested IP address MAY MUST (in MUST 1760 (DISCOVER) SELECTING or (DHCPDECLINE), 1761 MUST NOT INIT-REBOOT) MUST NOT 1762 (INFORM) MUST NOT (in (DHCPRELEASE) 1763 BOUND or 1764 RENEWING) 1765 IP address lease time MAY MAY MUST NOT 1766 (DISCOVER) 1767 MUST NOT 1769 DRAFT Dynamic Host Configuration Protocol November 1996 1771 (INFORM) 1772 Use 'file'/'sname' fields MAY MAY MAY 1773 DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/ 1774 DHCPINFORM DHCPRELEASE 1775 Client identifier MAY MAY MAY 1776 Vendor class identifier MAY MAY MUST NOT 1777 Server identifier MUST NOT MUST (after MUST 1778 SELECTING) 1779 MUST NOT (after 1780 INIT-REBOOT, 1781 BOUND, RENEWING 1782 or REBINDING) 1783 Parameter request list MAY MAY MUST NOT 1784 Maximum message size MAY MAY MUST NOT 1785 Message SHOULD NOT SHOULD NOT SHOULD 1786 Site-specific MAY MAY MUST NOT 1787 All others MAY MAY MUST NOT 1789 Table 5: Fields and options used by DHCP clients 1791 If the parameters are acceptable, the client records the address of 1792 the server that supplied the parameters from the 'server identifier' 1793 field and sends that address in the 'server identifier' field of a 1794 DHCPREQUEST broadcast message. Once the DHCPACK message from the 1795 server arrives, the client is initialized and moves to BOUND state. 1796 The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER 1797 message. The client records the lease expiration time as the sum of 1798 the time at which the original request was sent and the duration of 1799 the lease from the DHCPACK message. The client SHOULD perform a 1800 check on the suggested address to ensure that the address is not 1801 already in use. For example, if the client is on a network that 1802 supports ARP, the client may issue an ARP request for the suggested 1803 request. When broadcasting an ARP request for the suggested address, 1804 the client must fill in its own hardware address as the sender's 1805 hardware address, and 0 as the sender's IP address, to avoid 1806 confusing ARP caches in other hosts on the same subnet. If the 1807 network address appears to be in use, the client MUST send a 1808 DHCPDECLINE message to the server. The client SHOULD broadcast an ARP 1809 reply to announce the client's new IP address and clear any outdated 1810 ARP cache entries in hosts on the client's subnet. 1812 4.4.2 Initialization with known network address 1814 The client begins in INIT-REBOOT state and sends a DHCPREQUEST 1815 message. The client MUST insert its known network address as a 1816 'requested IP address' option in the DHCPREQUEST message. The client 1817 may request specific configuration parameters by including the 1818 'parameter request list' option. The client generates and records a 1820 DRAFT Dynamic Host Configuration Protocol November 1996 1822 random transaction identifier and inserts that identifier into the 1823 'xid' field. The client records its own local time for later use in 1824 computing the lease expiration. The client MUST NOT include a 1825 'server identifier' in the DHCPREQUEST message. The client then 1826 broadcasts the DHCPREQUEST on the local hardware broadcast address to 1827 the 'DHCP server' UDP port. 1829 Once a DHCPACK message with an 'xid' field matching that in the 1830 client's DHCPREQUEST message arrives from any server, the client is 1831 initialized and moves to BOUND state. The client records the lease 1832 expiration time as the sum of the time at which the DHCPREQUEST 1833 message was sent and the duration of the lease from the DHCPACK 1834 message. 1836 4.4.3 Initialization with an externally assigned network address 1838 The client sends a DHCPINFORM message. The client may request 1839 specific configuration parameters by including the 'parameter request 1840 list' option. The client generates and records a random transaction 1841 identifier and inserts that identifier into the 'xid' field. The 1842 client places its own network address in the 'ciaddr' field. The 1843 client SHOULD NOT request lease time parameters. 1845 The client then unicasts the DHCPINFORM to the DHCP server if it 1846 knows the server's address, otherwise it broadcasts the message to 1847 the limited (all 1s) broadcast address. DHCPINFORM messages MUST be 1848 directed to the 'DHCP server' UDP port. 1850 Once a DHCPACK message with an 'xid' field matching that in the 1851 client's DHCPINFORM message arrives from any server, the client is 1852 initialized. 1854 If the client does not receive a DHCPACK within a reasonable period 1855 of time (60 seconds or 4 tries if using timeout suggested in section 1856 4.1), then it SHOULD display a message informing the user of the 1857 problem, and then SHOULD begin network processing using suitable 1858 defaults as per Appendix A. 1860 4.4.4 Use of broadcast and unicast 1862 The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM 1863 messages, unless the client knows the address of a DHCP server. The 1864 client unicasts DHCPRELEASE messages to the server. Because the 1865 client is declining the use of the IP address supplied by the server, 1866 the client broadcasts DHCPDECLINE messages. 1868 When the DHCP client knows the address of a DHCP server, in either 1869 INIT or REBOOTING state, the client may use that address in the 1871 DRAFT Dynamic Host Configuration Protocol November 1996 1873 DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. 1874 The client may also use unicast to send DHCPINFORM messages to a 1875 known DHCP server. If the client receives no response to DHCP 1876 messages sent to the IP address of a known DHCP server, the DHCP 1877 client reverts to using the IP broadcast address. 1879 4.4.5 Reacquisition and expiration 1881 The client maintains two times, T1 and T2, that specify the times at 1882 which the client tries to extend its lease on its network address. 1883 T1 is the time at which the client enters the RENEWING state and 1884 attempts to contact the server that originally issued the client's 1885 network address. T2 is the time at which the client enters the 1886 REBINDING state and attempts to contact any server. T1 MUST be 1887 earlier than T2, which, in turn, MUST be earlier than the time at 1888 which the client's lease will expire. 1890 To avoid the need for synchronized clocks, T1 and T2 are expressed in 1891 options as relative times [2]. 1893 At time T1 the client moves to RENEWING state and sends (via unicast) 1894 a DHCPREQUEST message to the server to extend its lease. The client 1895 sets the 'ciaddr' field in the DHCPREQUEST to its current network 1896 address. The client records the local time at which the DHCPREQUEST 1897 message is sent for computation of the lease expiration time. The 1898 client MUST NOT include a 'server identifier' in the DHCPREQUEST 1899 message. 1901 Any DHCPACK messages that arrive with an 'xid' that does not match 1902 the 'xid' of the client's DHCPREQUEST message are silently discarded. 1903 When the client receives a DHCPACK from the server, the client 1904 computes the lease expiration time as the sum of the time at which 1905 the client sent the DHCPREQUEST message and the duration of the lease 1906 in the DHCPACK message. The client has successfully reacquired its 1907 network address, returns to BOUND state and may continue network 1908 processing. 1910 If no DHCPACK arrives before time T2, the client moves to REBINDING 1911 state and sends (via broadcast) a DHCPREQUEST message to extend its 1912 lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its 1913 current network address. The client MUST NOT include a 'server 1914 identifier' in the DHCPREQUEST message. 1916 Times T1 and T2 are configurable by the server through options. T1 1917 defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * 1918 duration_of_lease). Times T1 and T2 SHOULD be chosen with some 1919 random "fuzz" around a fixed value, to avoid synchronization of 1920 client reacquisition. 1922 DRAFT Dynamic Host Configuration Protocol November 1996 1924 A client MAY choose to renew or extend its lease prior to T1. The 1925 server MAY choose to extend the client's lease according to policy 1926 set by the network administrator. The server SHOULD return T1 and 1927 T2, and their values SHOULD be adjusted from their original values to 1928 take account of the time remaining on the lease. 1930 In both RENEWING and REBINDING states, if the client receives no 1931 response to its DHCPREQUEST message, the client SHOULD wait one-half 1932 of the remaining time until T2 (in RENEWING state) and one-half of 1933 the remaining lease time (in REBINDING state), down to a minimum of 1934 60 seconds, before retransmitting the DHCPREQUEST message. 1936 If the lease expires before the client receives a DHCPACK, the client 1937 moves to INIT state, MUST immediately stop any other network 1938 processing and requests network initialization parameters as if the 1939 client were uninitialized. If the client then receives a DHCPACK 1940 allocating that client its previous network address, the client 1941 SHOULD continue network processing. If the client is given a new 1942 network address, it MUST NOT continue using the previous network 1943 address and SHOULD notify the local users of the problem. 1945 4.4.6 DHCPRELEASE 1947 If the client no longer requires use of its assigned network address 1948 (e.g., the client is gracefully shut down), the client sends a 1949 DHCPRELEASE message to the server. Note that the correct operation 1950 of DHCP does not depend on the transmission of DHCPRELEASE messages. 1952 5. Acknowledgments 1954 The author thanks the many (and too numerous to mention!) members of 1955 the DHC WG for their tireless and ongoing efforts in the development 1956 of DHCP and this document. 1958 The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John 1959 Mendonca in organizing DHCP interoperability testing sessions are 1960 gratefully acknowledged. 1962 The development of this document was supported in part by grants from 1963 the Corporation for National Research Initiatives (CNRI), Bucknell 1964 University and Sun Microsystems. 1966 DRAFT Dynamic Host Configuration Protocol November 1996 1968 6. References 1970 [1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December 1971 1983. 1973 [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor 1974 Extensions", RFC 1533, Lachman Technology, Inc., Bucknell 1975 University, October 1993. 1977 [3] Braden, R., Editor, "Requirements for Internet Hosts -- 1978 Communication Layers", STD 3, RFC 1122, USC/Information Sciences 1979 Institute, October 1989. 1981 [4] Braden, R., Editor, "Requirements for Internet Hosts -- 1982 Application and Support, STD 3, RFC 1123, USC/Information 1983 Sciences Institute, October 1989. 1985 [5] Brownell, D, "Dynamic Reverse Address Resolution Protocol 1986 (DRARP)", Work in Progress. 1988 [6] Comer, D., and R. Droms, "Uniform Access to Internet Directory 1989 Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer 1990 Communications Review), 20(4):50--59, 1990. 1992 [7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, 1993 Stanford and SUN Microsystems, September 1985. 1995 [8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox 1996 PARC, September 1991. 1998 [9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534, 1999 Bucknell University, October 1993. 2001 [10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse 2002 Address Resolution Protocol", RFC 903, Stanford, June 1984. 2004 [11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant 2005 Mechanism for Distributed File Cache Consistency", In Proc. of 2006 the Twelfth ACM Symposium on Operating Systems Design, 1989. 2008 [12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 2009 13, RFC 1034, USC/Information Sciences Institute, November 1987. 2011 [13] Mockapetris, P., "Domain Names -- Implementation and 2012 Specification", STD 13, RFC 1035, USC/Information Sciences 2013 Institute, November 1987. 2015 DRAFT Dynamic Host Configuration Protocol November 1996 2017 [14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191, 2018 November 1990. 2020 [15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached 2021 Hosts", Work in Progress. 2023 [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 2024 USC/Information Sciences Institute, September 1981. 2026 [17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, 2027 USC/Information Sciences Institute, August 1993. 2029 [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, 2030 USC/Information Sciences Institute, July 1992. 2032 [19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic 2033 Assignment of IP Addresses for use on an Ethernet. (Available 2034 from the Athena Project, MIT), 1989. 2036 [20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC, 2037 June 1981. 2039 [21] Wimer, W., "Clarifications and Extensions for the Bootstrap 2040 Protocol", RFC 1542, Carnegie Mellon University, October 1993. 2042 7. Security Considerations 2044 DHCP is built directly on UDP and IP which are as yet inherently 2045 insecure. Furthermore, DHCP is generally intended to make 2046 maintenance of remote and/or diskless hosts easier. While perhaps 2047 not impossible, configuring such hosts with passwords or keys may be 2048 difficult and inconvenient. Therefore, DHCP in its current form is 2049 quite insecure. 2051 Unauthorized DHCP servers may be easily set up. Such servers can 2052 then send false and potentially disruptive information to clients 2053 such as incorrect or duplicate IP addresses, incorrect routing 2054 information (including spoof routers, etc.), incorrect domain 2055 nameserver addresses (such as spoof nameservers), and so on. 2056 Clearly, once this seed information is in place, an attacker can 2057 further compromise affected systems. 2059 Malicious DHCP clients could masquerade as legitimate clients and 2060 retrieve information intended for those legitimate clients. Where 2061 dynamic allocation of resources is used, a malicious client could 2062 claim all resources for itself, thereby denying resources to 2063 legitimate clients. 2065 DRAFT Dynamic Host Configuration Protocol November 1996 2067 8. Author's Address 2069 Ralph Droms 2070 Computer Science Department 2071 323 Dana Engineering 2072 Bucknell University 2073 Lewisburg, PA 17837 2075 Phone: (717) 524-1145 2076 EMail: droms@bucknell.edu 2078 This document will expire on May 30, 1996. 2080 DRAFT Dynamic Host Configuration Protocol November 1996 2082 A. Host Configuration Parameters 2084 IP-layer_parameters,_per_host:_ 2086 Be a router on/off HRC 3.1 2087 Non-local source routing on/off HRC 3.3.5 2088 Policy filters for 2089 non-local source routing (list) HRC 3.3.5 2090 Maximum reassembly size integer HRC 3.3.2 2091 Default TTL integer HRC 3.2.1.7 2092 PMTU aging timeout integer MTU 6.6 2093 MTU plateau table (list) MTU 7 2094 IP-layer_parameters,_per_interface:_ 2095 IP address (address) HRC 3.3.1.6 2096 Subnet mask (address mask) HRC 3.3.1.6 2097 MTU integer HRC 3.3.3 2098 All-subnets-MTU on/off HRC 3.3.3 2099 Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6 2100 Perform mask discovery on/off HRC 3.2.2.9 2101 Be a mask supplier on/off HRC 3.2.2.9 2102 Perform router discovery on/off RD 5.1 2103 Router solicitation address (address) RD 5.1 2104 Default routers, list of: 2105 router address (address) HRC 3.3.1.6 2106 preference level integer HRC 3.3.1.6 2107 Static routes, list of: 2108 destination (host/subnet/net) HRC 3.3.1.2 2109 destination mask (address mask) HRC 3.3.1.2 2110 type-of-service integer HRC 3.3.1.2 2111 first-hop router (address) HRC 3.3.1.2 2112 ignore redirects on/off HRC 3.3.1.2 2113 PMTU integer MTU 6.6 2114 perform PMTU discovery on/off MTU 6.6 2116 Link-layer_parameters,_per_interface:_ 2117 Trailers on/off HRC 2.3.1 2118 ARP cache timeout integer HRC 2.3.2.1 2119 Ethernet encapsulation (RFC 894/RFC 1042) HRC 2.3.3 2121 TCP_parameters,_per_host:_ 2122 TTL integer HRC 4.2.2.19 2123 Keep-alive interval integer HRC 4.2.3.6 2124 Keep-alive data size 0/1 HRC 4.2.3.6 2126 Key: 2128 MTU = Path MTU Discovery (RFC 1191, Proposed Standard) 2129 RD = Router Discovery (RFC 1256, Proposed Standard)