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