1 2 3 4 5 6 7Network Working Group R. Droms, Ed. 8Request for Comments: 3315 Cisco 9Category: Standards Track J. Bound 10 Hewlett Packard 11 B. Volz 12 Ericsson 13 T. Lemon 14 Nominum 15 C. Perkins 16 Nokia Research Center 17 M. Carney 18 Sun Microsystems 19 July 2003 20 21 22 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 23 24Status of this Memo 25 26 This document specifies an Internet standards track protocol for the 27 Internet community, and requests discussion and suggestions for 28 improvements. Please refer to the current edition of the "Internet 29 Official Protocol Standards" (STD 1) for the standardization state 30 and status of this protocol. Distribution of this memo is unlimited. 31 32Copyright Notice 33 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 36Abstract 37 38 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP 39 servers to pass configuration parameters such as IPv6 network 40 addresses to IPv6 nodes. It offers the capability of automatic 41 allocation of reusable network addresses and additional configuration 42 flexibility. This protocol is a stateful counterpart to "IPv6 43 Stateless Address Autoconfiguration" (RFC 2462), and can be used 44 separately or concurrently with the latter to obtain configuration 45 parameters. 46 47 48 49 50 51 52 53 54 55 56 57 58Droms, et al. Standards Track [Page 1] 59 60RFC 3315 DHCP for IPv6 July 2003 61 62 63Table of Contents 64 65 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 5 66 1.1. Protocols and Addressing . . . . . . . . . . . . . . . 6 67 1.2. Client-server Exchanges Involving Two Messages . . . . 6 68 1.3. Client-server Exchanges Involving Four Messages. . . . 7 69 2. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3. Background. . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . 9 73 4.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . 10 74 5. DHCP Constants. . . . . . . . . . . . . . . . . . . . . . . . 12 75 5.1. Multicast Addresses. . . . . . . . . . . . . . . . . . 13 76 5.2. UDP Ports. . . . . . . . . . . . . . . . . . . . . . . 13 77 5.3. DHCP Message Types . . . . . . . . . . . . . . . . . . 13 78 5.4. Status Codes . . . . . . . . . . . . . . . . . . . . . 15 79 5.5. Transmission and Retransmission Parameters . . . . . . 16 80 5.6 Representation of time values and "Infinity" as a time 81 value. . . . . . . . . . . . . . . . . . . . . . . . . 16 82 6. Client/Server Message Formats . . . . . . . . . . . . . . . . 16 83 7. Relay Agent/Server Message Formats. . . . . . . . . . . . . . 17 84 7.1. Relay-forward Message. . . . . . . . . . . . . . . . . 18 85 7.2. Relay-reply Message. . . . . . . . . . . . . . . . . . 19 86 8. Representation and Use of Domain Names. . . . . . . . . . . . 19 87 9. DHCP Unique Identifier (DUID) . . . . . . . . . . . . . . . . 19 88 9.1. DUID Contents. . . . . . . . . . . . . . . . . . . . . 20 89 9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT]. 20 90 9.3. DUID Assigned by Vendor Based on Enterprise Number 91 [DUID-EN]. . . . . . . . . . . . . . . . . . . . . . . 22 92 9.4. DUID Based on Link-layer Address [DUID-LL] . . . . . . 22 93 10. Identity Association. . . . . . . . . . . . . . . . . . . . . 23 94 11. Selecting Addresses for Assignment to an IA . . . . . . . . . 24 95 12. Management of Temporary Addresses . . . . . . . . . . . . . . 25 96 13. Transmission of Messages by a Client. . . . . . . . . . . . . 25 97 14. Reliability of Client Initiated Message Exchanges . . . . . . 26 98 15. Message Validation. . . . . . . . . . . . . . . . . . . . . . 27 99 15.1. Use of Transaction IDs . . . . . . . . . . . . . . . . 28 100 15.2. Solicit Message. . . . . . . . . . . . . . . . . . . . 28 101 15.3. Advertise Message. . . . . . . . . . . . . . . . . . . 28 102 15.4. Request Message. . . . . . . . . . . . . . . . . . . . 29 103 15.5. Confirm Message. . . . . . . . . . . . . . . . . . . . 29 104 15.6. Renew Message. . . . . . . . . . . . . . . . . . . . . 29 105 15.7. Rebind Message . . . . . . . . . . . . . . . . . . . . 29 106 15.8. Decline Messages . . . . . . . . . . . . . . . . . . . 30 107 15.9. Release Message. . . . . . . . . . . . . . . . . . . . 30 108 15.10. Reply Message. . . . . . . . . . . . . . . . . . . . . 30 109 15.11. Reconfigure Message. . . . . . . . . . . . . . . . . . 31 110 15.12. Information-request Message. . . . . . . . . . . . . . 31 111 112 113 114Droms, et al. Standards Track [Page 2] 115 116RFC 3315 DHCP for IPv6 July 2003 117 118 119 15.13. Relay-forward Message. . . . . . . . . . . . . . . . . 31 120 15.14. Relay-reply Message. . . . . . . . . . . . . . . . . . 31 121 16. Client Source Address and Interface Selection . . . . . . . . 32 122 17. DHCP Server Solicitation. . . . . . . . . . . . . . . . . . . 32 123 17.1. Client Behavior. . . . . . . . . . . . . . . . . . . . 32 124 17.1.1. Creation of Solicit Messages . . . . . . . . . 32 125 17.1.2. Transmission of Solicit Messages . . . . . . . 33 126 17.1.3. Receipt of Advertise Messages. . . . . . . . . 35 127 17.1.4. Receipt of Reply Message . . . . . . . . . . . 35 128 17.2. Server Behavior. . . . . . . . . . . . . . . . . . . . 36 129 17.2.1. Receipt of Solicit Messages . . . . . . . . . 36 130 17.2.2. Creation and Transmission of Advertise Messages 36 131 17.2.3. Creation and Transmission of Reply Messages. . 38 132 18. DHCP Client-Initiated Configuration Exchange. . . . . . . . . 38 133 18.1. Client Behavior. . . . . . . . . . . . . . . . . . . . 39 134 18.1.1. Creation and Transmission of Request Messages. 39 135 18.1.2. Creation and Transmission of Confirm Messages. 40 136 18.1.3. Creation and Transmission of Renew Messages. . 41 137 18.1.4. Creation and Transmission of Rebind Messages . 43 138 18.1.5. Creation and Transmission of Information- 139 request Messages . . .. . . . . . . . . . . . 44 140 18.1.6. Creation and Transmission of Release Messages. 44 141 18.1.7. Creation and Transmission of Decline Messages. 46 142 18.1.8. Receipt of Reply Messages. . . . . . . . . . . 46 143 18.2. Server Behavior. . . . . . . . . . . . . . . . . . . . 48 144 18.2.1. Receipt of Request Messages. . . . . . . . . . 49 145 18.2.2. Receipt of Confirm Messages. . . . . . . . . . 50 146 18.2.3. Receipt of Renew Messages. . . . . . . . . . . 51 147 18.2.4. Receipt of Rebind Messages . . . . . . . . . . 51 148 18.2.5. Receipt of Information-request Messages. . . . 52 149 18.2.6. Receipt of Release Messages. . . . . . . . . . 53 150 18.2.7. Receipt of Decline Messages. . . . . . . . . . 53 151 18.2.8. Transmission of Reply Messages . . . . . . . . 54 152 19. DHCP Server-Initiated Configuration Exchange. . . . . . . . . 54 153 19.1. Server Behavior. . . . . . . . . . . . . . . . . . . . 55 154 19.1.1. Creation and Transmission of Reconfigure 155 Messages . . . . . . . . . . . . . . . . . . . 55 156 19.1.2. Time Out and Retransmission of Reconfigure 157 Messages . . . . . . . . . . . . . . . . . . . 56 158 19.2. Receipt of Renew Messages. . . . . . . . . . . . . . . 56 159 19.3. Receipt of Information-request Messages. . . . . . . . 56 160 19.4. Client Behavior. . . . . . . . . . . . . . . . . . . . 57 161 19.4.1. Receipt of Reconfigure Messages. . . . . . . . 57 162 19.4.2. Creation and Transmission of Renew Messages. . 58 163 19.4.3. Creation and Transmission of Information- 164 request Messages . . . . . . . . . . . . . . . 58 165 19.4.4. Time Out and Retransmission of Renew or 166 Information-request Messages . . . . . . . . . 58 167 168 169 170Droms, et al. Standards Track [Page 3] 171 172RFC 3315 DHCP for IPv6 July 2003 173 174 175 19.4.5. Receipt of Reply Messages. . . . . . . . . . . 58 176 20. Relay Agent Behavior. . . . . . . . . . . . . . . . . . . . . 58 177 20.1. Relaying a Client Message or a Relay-forward Message . 59 178 20.1.1. Relaying a Message from a Client . . . . . . . 59 179 20.1.2. Relaying a Message from a Relay Agent. . . . . 59 180 20.2. Relaying a Relay-reply Message . . . . . . . . . . . . 60 181 20.3. Construction of Relay-reply Messages . . . . . . . . . 60 182 21. Authentication of DHCP Messages . . . . . . . . . . . . . . . 61 183 21.1. Security of Messages Sent Between Servers and Relay 184 Agents . . . . . . . . . . . . . . . . . . . . . . . 61 185 21.2. Summary of DHCP Authentication . . . . . . . . . . . . 63 186 21.3. Replay Detection . . . . . . . . . . . . . . . . . . . 63 187 21.4. Delayed Authentication Protocol. . . . . . . . . . . . 63 188 21.4.1. Use of the Authentication Option in the Delayed 189 Authentication Protocol. . . . . . . . . . . . 64 190 21.4.2. Message Validation . . . . . . . . . . . . . . 65 191 21.4.3. Key Utilization . . . . . . . . . . . . . . . 65 192 21.4.4. Client Considerations for Delayed Authentication 193 Protocol . . . . . . . . . . . . . . . . . . . 66 194 21.4.5. Server Considerations for Delayed Authentication 195 Protocol . . . . . . . . . . . . . . . . . . . 67 196 21.5. Reconfigure Key Authentication Protocol. . . . . . . . 68 197 21.5.1. Use of the Authentication Option in the 198 Reconfigure Key Authentication Protocol. . . . 69 199 21.5.2. Server considerations for Reconfigure Key 200 protocol . . . . . . . . . . . . . . . . . . . 69 201 21.5.3. Client considerations for Reconfigure Key 202 protocol . . . . . . . . . . . . . . . . . . . 70 203 22. DHCP Options. . . . . . . . . . . . . . . . . . . . . . . . . 70 204 22.1. Format of DHCP Options . . . . . . . . . . . . . . . . 71 205 22.2. Client Identifier Option . . . . . . . . . . . . . . . 71 206 22.3. Server Identifier Option . . . . . . . . . . . . . . . 72 207 22.4. Identity Association for Non-temporary Addresses Option 72 208 22.5. Identity Association for Temporary Addresses Option. . 75 209 22.6. IA Address Option. . . . . . . . . . . . . . . . . . . 76 210 22.7. Option Request Option. . . . . . . . . . . . . . . . . 78 211 22.8. Preference Option. . . . . . . . . . . . . . . . . . . 79 212 22.9. Elapsed Time Option. . . . . . . . . . . . . . . . . . 79 213 22.10. Relay Message Option . . . . . . . . . . . . . . . . . 80 214 22.11. Authentication Option. . . . . . . . . . . . . . . . . 81 215 22.12. Server Unicast Option. . . . . . . . . . . . . . . . . 82 216 22.13. Status Code Option . . . . . . . . . . . . . . . . . . 82 217 22.14. Rapid Commit Option. . . . . . . . . . . . . . . . . . 83 218 22.15. User Class Option. . . . . . . . . . . . . . . . . . . 84 219 22.16. Vendor Class Option. . . . . . . . . . . . . . . . . . 85 220 22.17. Vendor-specific Information Option . . . . . . . . . . 86 221 22.18. Interface-Id Option. . . . . . . . . . . . . . . . . . 87 222 22.19. Reconfigure Message Option . . . . . . . . . . . . . . 88 223 224 225 226Droms, et al. Standards Track [Page 4] 227 228RFC 3315 DHCP for IPv6 July 2003 229 230 231 22.20. Reconfigure Accept Option. . . . . . . . . . . . . . . 89 232 23. Security Considerations . . . . . . . . . . . . . . . . . . . 89 233 24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91 234 24.1. Multicast Addresses. . . . . . . . . . . . . . . . . . 92 235 24.2. DHCP Message Types . . . . . . . . . . . . . . . . . . 93 236 24.3. DHCP Options . . . . . . . . . . . . . . . . . . . . . 94 237 24.4. Status Codes . . . . . . . . . . . . . . . . . . . . . 95 238 24.5. DUID . . . . . . . . . . . . . . . . . . . . . . . . . 95 239 25. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 95 240 26. References. . . . . . . . . . . . . . . . . . . . . . . . . . 96 241 26.1. Normative References . . . . . . . . . . . . . . . . . 96 242 26.2. Informative References . . . . . . . . . . . . . . . . 97 243 A. Appearance of Options in Message Types . . . . . . . . . . . . 98 244 B. Appearance of Options in the Options Field of DHCP Options . . 99 245 Chair's Address . . . . . . . . . . . . . . . . . . . . . . . . . 99 246 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 100 247 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 101 248 2491. Introduction and Overview 250 251 This document describes DHCP for IPv6 (DHCP), a client/server 252 protocol that provides managed configuration of devices. 253 254 DHCP can provide a device with addresses assigned by a DHCP server 255 and other configuration information, which are carried in options. 256 DHCP can be extended through the definition of new options to carry 257 configuration information not specified in this document. 258 259 DHCP is the "stateful address autoconfiguration protocol" and the 260 "stateful autoconfiguration protocol" referred to in "IPv6 Stateless 261 Address Autoconfiguration" [17]. 262 263 The operational models and relevant configuration information for 264 DHCPv4 [18][19] and DHCPv6 are sufficiently different that 265 integration between the two services is not included in this 266 document. If there is sufficient interest and demand, integration 267 can be specified in a document that extends DHCPv6 to carry IPv4 268 addresses and configuration information. 269 270 The remainder of this introduction summarizes DHCP, explaining the 271 message exchange mechanisms and example message flows. The message 272 flows in sections 1.2 and 1.3 are intended as illustrations of DHCP 273 operation rather than an exhaustive list of all possible 274 client-server interactions. Sections 17, 18, and 19 explain client 275 and server operation in detail. 276 277 278 279 280 281 282Droms, et al. Standards Track [Page 5] 283 284RFC 3315 DHCP for IPv6 July 2003 285 286 2871.1. Protocols and Addressing 288 289 Clients and servers exchange DHCP messages using UDP [15]. The 290 client uses a link-local address or addresses determined through 291 other mechanisms for transmitting and receiving DHCP messages. 292 293 DHCP servers receive messages from clients using a reserved, 294 link-scoped multicast address. A DHCP client transmits most messages 295 to this reserved multicast address, so that the client need not be 296 configured with the address or addresses of DHCP servers. 297 298 To allow a DHCP client to send a message to a DHCP server that is not 299 attached to the same link, a DHCP relay agent on the client's link 300 will relay messages between the client and server. The operation of 301 the relay agent is transparent to the client and the discussion of 302 message exchanges in the remainder of this section will omit the 303 description of message relaying by relay agents. 304 305 Once the client has determined the address of a server, it may under 306 some circumstances send messages directly to the server using 307 unicast. 308 3091.2. Client-server Exchanges Involving Two Messages 310 311 When a DHCP client does not need to have a DHCP server assign it IP 312 addresses, the client can obtain configuration information such as a 313 list of available DNS servers [20] or NTP servers [21] through a 314 single message and reply exchanged with a DHCP server. To obtain 315 configuration information the client first sends an 316 Information-Request message to the All_DHCP_Relay_Agents_and_Servers 317 multicast address. Servers respond with a Reply message containing 318 the configuration information for the client. 319 320 This message exchange assumes that the client requires only 321 configuration information and does not require the assignment of any 322 IPv6 addresses. 323 324 When a server has IPv6 addresses and other configuration information 325 committed to a client, the client and server may be able to complete 326 the exchange using only two messages, instead of four messages as 327 described in the next section. In this case, the client sends a 328 Solicit message to the All_DHCP_Relay_Agents_and_Servers requesting 329 the assignment of addresses and other configuration information. 330 This message includes an indication that the client is willing to 331 accept an immediate Reply message from the server. The server that 332 is willing to commit the assignment of addresses to the client 333 334 335 336 337 338Droms, et al. Standards Track [Page 6] 339 340RFC 3315 DHCP for IPv6 July 2003 341 342 343 immediately responds with a Reply message. The configuration 344 information and the addresses in the Reply message are then 345 immediately available for use by the client. 346 347 Each address assigned to the client has associated preferred and 348 valid lifetimes specified by the server. To request an extension of 349 the lifetimes assigned to an address, the client sends a Renew 350 message to the server. The server sends a Reply message to the 351 client with the new lifetimes, allowing the client to continue to use 352 the address without interruption. 353 3541.3. Client-server Exchanges Involving Four Messages 355 356 To request the assignment of one or more IPv6 addresses, a client 357 first locates a DHCP server and then requests the assignment of 358 addresses and other configuration information from the server. The 359 client sends a Solicit message to the 360 All_DHCP_Relay_Agents_and_Servers address to find available DHCP 361 servers. Any server that can meet the client's requirements responds 362 with an Advertise message. The client then chooses one of the 363 servers and sends a Request message to the server asking for 364 confirmed assignment of addresses and other configuration 365 information. The server responds with a Reply message that contains 366 the confirmed addresses and configuration. 367 368 As described in the previous section, the client sends a Renew 369 message to the server to extend the lifetimes associated with its 370 addresses, allowing the client to continue to use those addresses 371 without interruption. 372 3732. Requirements 374 375 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 376 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 377 document, are to be interpreted as described in [1]. 378 379 This document also makes use of internal conceptual variables to 380 describe protocol behavior and external variables that an 381 implementation must allow system administrators to change. The 382 specific variable names, how their values change, and how their 383 settings influence protocol behavior are provided to demonstrate 384 protocol behavior. An implementation is not required to have them in 385 the exact form described here, so long as its external behavior is 386 consistent with that described in this document. 387 388 389 390 391 392 393 394Droms, et al. Standards Track [Page 7] 395 396RFC 3315 DHCP for IPv6 July 2003 397 398 3993. Background 400 401 The IPv6 Specification provides the base architecture and design of 402 IPv6. Related work in IPv6 that would best serve an implementor to 403 study includes the IPv6 Specification [3], the IPv6 Addressing 404 Architecture [5], IPv6 Stateless Address Autoconfiguration [17], IPv6 405 Neighbor Discovery Processing [13], and Dynamic Updates to DNS [22]. 406 These specifications enable DHCP to build upon the IPv6 work to 407 provide both robust stateful autoconfiguration and autoregistration 408 of DNS Host Names. 409 410 The IPv6 Addressing Architecture specification [5] defines the 411 address scope that can be used in an IPv6 implementation, and the 412 various configuration architecture guidelines for network designers 413 of the IPv6 address space. Two advantages of IPv6 are that support 414 for multicast is required and nodes can create link-local addresses 415 during initialization. The availability of these features means that 416 a client can use its link-local address and a well-known multicast 417 address to discover and communicate with DHCP servers or relay agents 418 on its link. 419 420 IPv6 Stateless Address Autoconfiguration [17] specifies procedures by 421 which a node may autoconfigure addresses based on router 422 advertisements [13], and the use of a valid lifetime to support 423 renumbering of addresses on the Internet. In addition, the protocol 424 interaction by which a node begins stateless or stateful 425 autoconfiguration is specified. DHCP is one vehicle to perform 426 stateful autoconfiguration. Compatibility with stateless address 427 autoconfiguration is a design requirement of DHCP. 428 429 IPv6 Neighbor Discovery [13] is the node discovery protocol in IPv6 430 which replaces and enhances functions of ARP [14]. To understand 431 IPv6 and stateless address autoconfiguration, it is strongly 432 recommended that implementors understand IPv6 Neighbor Discovery. 433 434 Dynamic Updates to DNS [22] is a specification that supports the 435 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 436 the dynamic updates to DNS to integrate addresses and name space to 437 not only support autoconfiguration, but also autoregistration in 438 IPv6. 439 4404. Terminology 441 442 This sections defines terminology specific to IPv6 and DHCP used in 443 this document. 444 445 446 447 448 449 450Droms, et al. Standards Track [Page 8] 451 452RFC 3315 DHCP for IPv6 July 2003 453 454 4554.1. IPv6 Terminology 456 457 IPv6 terminology relevant to this specification from the IPv6 458 Protocol [3], IPv6 Addressing Architecture [5], and IPv6 Stateless 459 Address Autoconfiguration [17] is included below. 460 461 address An IP layer identifier for an interface 462 or a set of interfaces. 463 464 host Any node that is not a router. 465 466 IP Internet Protocol Version 6 (IPv6). The 467 terms IPv4 and IPv6 are used only in 468 contexts where it is necessary to avoid 469 ambiguity. 470 471 interface A node's attachment to a link. 472 473 link A communication facility or medium over 474 which nodes can communicate at the link 475 layer, i.e., the layer immediately 476 below IP. Examples are Ethernet (simple 477 or bridged); Token Ring; PPP links, 478 X.25, Frame Relay, or ATM networks; and 479 Internet (or higher) layer "tunnels", 480 such as tunnels over IPv4 or IPv6 481 itself. 482 483 link-layer identifier A link-layer identifier for an 484 interface. Examples include IEEE 802 485 addresses for Ethernet or Token Ring 486 network interfaces, and E.164 addresses 487 for ISDN links. 488 489 link-local address An IPv6 address having a link-only 490 scope, indicated by having the prefix 491 (FE80::/10), that can be used to reach 492 neighboring nodes attached to the same 493 link. Every interface has a link-local 494 address. 495 496 multicast address An identifier for a set of interfaces 497 (typically belonging to different 498 nodes). A packet sent to a multicast 499 address is delivered to all interfaces 500 identified by that address. 501 502 neighbor A node attached to the same link. 503 504 505 506Droms, et al. Standards Track [Page 9] 507 508RFC 3315 DHCP for IPv6 July 2003 509 510 511 node A device that implements IP. 512 513 packet An IP header plus payload. 514 515 prefix The initial bits of an address, or a 516 set of IP addresses that share the same 517 initial bits. 518 519 prefix length The number of bits in a prefix. 520 521 router A node that forwards IP packets not 522 explicitly addressed to itself. 523 524 unicast address An identifier for a single interface. 525 A packet sent to a unicast address is 526 delivered to the interface identified by 527 that address. 528 5294.2. DHCP Terminology 530 531 Terminology specific to DHCP can be found below. 532 533 appropriate to the link An address is "appropriate to the link" 534 when the address is consistent with the 535 DHCP server's knowledge of the network 536 topology, prefix assignment and address 537 assignment policies. 538 539 binding A binding (or, client binding) is a 540 group of server data records containing 541 the information the server has about 542 the addresses in an IA or configuration 543 information explicitly assigned to the 544 client. Configuration information that 545 has been returned to a client through a 546 policy - for example, the information 547 returned to all clients on the same 548 link - does not require a binding. A 549 binding containing information about 550 an IA is indexed by the tuple <DUID, 551 IA-type, IAID> (where IA-type is the 552 type of address in the IA; for example, 553 temporary). A binding containing 554 configuration information for a client 555 is indexed by <DUID>. 556 557 558 559 560 561 562Droms, et al. Standards Track [Page 10] 563 564RFC 3315 DHCP for IPv6 July 2003 565 566 567 configuration parameter An element of the configuration 568 information set on the server and 569 delivered to the client using DHCP. 570 Such parameters may be used to carry 571 information to be used by a node to 572 configure its network subsystem and 573 enable communication on a link or 574 internetwork, for example. 575 576 DHCP Dynamic Host Configuration Protocol 577 for IPv6. The terms DHCPv4 and DHCPv6 578 are used only in contexts where it is 579 necessary to avoid ambiguity. 580 581 DHCP client (or client) A node that initiates requests on a link 582 to obtain configuration parameters from 583 one or more DHCP servers. 584 585 DHCP domain A set of links managed by DHCP and 586 operated by a single administrative 587 entity. 588 589 DHCP realm A name used to identify the DHCP 590 administrative domain from which a DHCP 591 authentication key was selected. 592 593 DHCP relay agent (or relay agent) A node that acts as an 594 intermediary to deliver DHCP messages 595 between clients and servers, and is on 596 the same link as the client. 597 598 DHCP server (or server) A node that responds to requests from 599 clients, and may or may not be on the 600 same link as the client(s). 601 602 DUID A DHCP Unique IDentifier for a DHCP 603 participant; each DHCP client and server 604 has exactly one DUID. See section 9 for 605 details of the ways in which a DUID may 606 be constructed. 607 608 Identity association (IA) A collection of addresses assigned to 609 a client. Each IA has an associated 610 IAID. A client may have more than one 611 IA assigned to it; for example, one for 612 each of its interfaces. 613 614 615 616 617 618Droms, et al. Standards Track [Page 11] 619 620RFC 3315 DHCP for IPv6 July 2003 621 622 623 Each IA holds one type of address; 624 for example, an identity association 625 for temporary addresses (IA_TA) holds 626 temporary addresses (see "identity 627 association for temporary addresses"). 628 Throughout this document, "IA" is used 629 to refer to an identity association 630 without identifying the type of 631 addresses in the IA. 632 633 Identity association identifier (IAID) An identifier for an IA, 634 chosen by the client. Each IA has an 635 IAID, which is chosen to be unique among 636 all IAIDs for IAs belonging to that 637 client. 638 639 Identity association for non-temporary addresses (IA_NA) An IA 640 that carries assigned addresses that are 641 not temporary addresses (see "identity 642 association for temporary addresses") 643 644 Identity association for temporary addresses (IA_TA) An IA that 645 carries temporary addresses (see RFC 646 3041 [12]). 647 648 message A unit of data carried as the payload 649 of a UDP datagram, exchanged among DHCP 650 servers, relay agents and clients. 651 652 Reconfigure key A key supplied to a client by a server 653 used to provide security for Reconfigure 654 messages. 655 656 relaying A DHCP relay agent relays DHCP messages 657 between DHCP participants. 658 659 transaction ID An opaque value used to match responses 660 with replies initiated either by a 661 client or server. 662 6635. DHCP Constants 664 665 This section describes various program and networking constants used 666 by DHCP. 667 668 669 670 671 672 673 674Droms, et al. Standards Track [Page 12] 675 676RFC 3315 DHCP for IPv6 July 2003 677 678 6795.1. Multicast Addresses 680 681 DHCP makes use of the following multicast addresses: 682 683 All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped 684 multicast address used by a client to communicate with 685 neighboring (i.e., on-link) relay agents and servers. 686 All servers and relay agents are members of this 687 multicast group. 688 689 All_DHCP_Servers (FF05::1:3) A site-scoped multicast address used 690 by a relay agent to communicate with servers, either 691 because the relay agent wants to send messages to 692 all servers or because it does not know the unicast 693 addresses of the servers. Note that in order for 694 a relay agent to use this address, it must have an 695 address of sufficient scope to be reachable by the 696 servers. All servers within the site are members of 697 this multicast group. 698 6995.2. UDP Ports 700 701 Clients listen for DHCP messages on UDP port 546. Servers and relay 702 agents listen for DHCP messages on UDP port 547. 703 7045.3. DHCP Message Types 705 706 DHCP defines the following message types. More detail on these 707 message types can be found in sections 6 and 7. Message types not 708 listed here are reserved for future use. The numeric encoding for 709 each message type is shown in parentheses. 710 711 SOLICIT (1) A client sends a Solicit message to locate 712 servers. 713 714 ADVERTISE (2) A server sends an Advertise message to indicate 715 that it is available for DHCP service, in 716 response to a Solicit message received from a 717 client. 718 719 REQUEST (3) A client sends a Request message to request 720 configuration parameters, including IP 721 addresses, from a specific server. 722 723 CONFIRM (4) A client sends a Confirm message to any 724 available server to determine whether the 725 addresses it was assigned are still appropriate 726 to the link to which the client is connected. 727 728 729 730Droms, et al. Standards Track [Page 13] 731 732RFC 3315 DHCP for IPv6 July 2003 733 734 735 RENEW (5) A client sends a Renew message to the server 736 that originally provided the client's addresses 737 and configuration parameters to extend the 738 lifetimes on the addresses assigned to the 739 client and to update other configuration 740 parameters. 741 742 REBIND (6) A client sends a Rebind message to any 743 available server to extend the lifetimes on the 744 addresses assigned to the client and to update 745 other configuration parameters; this message is 746 sent after a client receives no response to a 747 Renew message. 748 749 REPLY (7) A server sends a Reply message containing 750 assigned addresses and configuration parameters 751 in response to a Solicit, Request, Renew, 752 Rebind message received from a client. A 753 server sends a Reply message containing 754 configuration parameters in response to an 755 Information-request message. A server sends a 756 Reply message in response to a Confirm message 757 confirming or denying that the addresses 758 assigned to the client are appropriate to the 759 link to which the client is connected. A 760 server sends a Reply message to acknowledge 761 receipt of a Release or Decline message. 762 763 RELEASE (8) A client sends a Release message to the server 764 that assigned addresses to the client to 765 indicate that the client will no longer use one 766 or more of the assigned addresses. 767 768 DECLINE (9) A client sends a Decline message to a server to 769 indicate that the client has determined that 770 one or more addresses assigned by the server 771 are already in use on the link to which the 772 client is connected. 773 774 RECONFIGURE (10) A server sends a Reconfigure message to a 775 client to inform the client that the server has 776 new or updated configuration parameters, and 777 that the client is to initiate a Renew/Reply 778 or Information-request/Reply transaction with 779 the server in order to receive the updated 780 information. 781 782 783 784 785 786Droms, et al. Standards Track [Page 14] 787 788RFC 3315 DHCP for IPv6 July 2003 789 790 791 INFORMATION-REQUEST (11) A client sends an Information-request 792 message to a server to request configuration 793 parameters without the assignment of any IP 794 addresses to the client. 795 796 RELAY-FORW (12) A relay agent sends a Relay-forward message 797 to relay messages to servers, either directly 798 or through another relay agent. The received 799 message, either a client message or a 800 Relay-forward message from another relay 801 agent, is encapsulated in an option in the 802 Relay-forward message. 803 804 RELAY-REPL (13) A server sends a Relay-reply message to a relay 805 agent containing a message that the relay 806 agent delivers to a client. The Relay-reply 807 message may be relayed by other relay agents 808 for delivery to the destination relay agent. 809 810 The server encapsulates the client message as 811 an option in the Relay-reply message, which the 812 relay agent extracts and relays to the client. 813 8145.4. Status Codes 815 816 DHCPv6 uses status codes to communicate the success or failure of 817 operations requested in messages from clients and servers, and to 818 provide additional information about the specific cause of the 819 failure of a message. The specific status codes are defined in 820 section 24.4. 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842Droms, et al. Standards Track [Page 15] 843 844RFC 3315 DHCP for IPv6 July 2003 845 846 8475.5. Transmission and Retransmission Parameters 848 849 This section presents a table of values used to describe the message 850 transmission behavior of clients and servers. 851 852 Parameter Default Description 853 ------------------------------------- 854 SOL_MAX_DELAY 1 sec Max delay of first Solicit 855 SOL_TIMEOUT 1 sec Initial Solicit timeout 856 SOL_MAX_RT 120 secs Max Solicit timeout value 857 REQ_TIMEOUT 1 sec Initial Request timeout 858 REQ_MAX_RT 30 secs Max Request timeout value 859 REQ_MAX_RC 10 Max Request retry attempts 860 CNF_MAX_DELAY 1 sec Max delay of first Confirm 861 CNF_TIMEOUT 1 sec Initial Confirm timeout 862 CNF_MAX_RT 4 secs Max Confirm timeout 863 CNF_MAX_RD 10 secs Max Confirm duration 864 REN_TIMEOUT 10 secs Initial Renew timeout 865 REN_MAX_RT 600 secs Max Renew timeout value 866 REB_TIMEOUT 10 secs Initial Rebind timeout 867 REB_MAX_RT 600 secs Max Rebind timeout value 868 INF_MAX_DELAY 1 sec Max delay of first Information-request 869 INF_TIMEOUT 1 sec Initial Information-request timeout 870 INF_MAX_RT 120 secs Max Information-request timeout value 871 REL_TIMEOUT 1 sec Initial Release timeout 872 REL_MAX_RC 5 MAX Release attempts 873 DEC_TIMEOUT 1 sec Initial Decline timeout 874 DEC_MAX_RC 5 Max Decline attempts 875 REC_TIMEOUT 2 secs Initial Reconfigure timeout 876 REC_MAX_RC 8 Max Reconfigure attempts 877 HOP_COUNT_LIMIT 32 Max hop count in a Relay-forward message 878 8795.6 Representation of time values and "Infinity" as a time value 880 881 All time values for lifetimes, T1 and T2 are unsigned integers. The 882 value 0xffffffff is taken to mean "infinity" when used as a lifetime 883 (as in RFC2461 [17]) or a value for T1 or T2. 884 8856. Client/Server Message Formats 886 887 All DHCP messages sent between clients and servers share an identical 888 fixed format header and a variable format area for options. 889 890 All values in the message header and in options are in network byte 891 order. 892 893 894 895 896 897 898Droms, et al. Standards Track [Page 16] 899 900RFC 3315 DHCP for IPv6 July 2003 901 902 903 Options are stored serially in the options field, with no padding 904 between the options. Options are byte-aligned but are not aligned in 905 any other way such as on 2 or 4 byte boundaries. 906 907 The following diagram illustrates the format of DHCP messages sent 908 between clients and servers: 909 910 0 1 2 3 911 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 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | msg-type | transaction-id | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | | 916 . options . 917 . (variable) . 918 | | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 921 msg-type Identifies the DHCP message type; the 922 available message types are listed in 923 section 5.3. 924 925 transaction-id The transaction ID for this message exchange. 926 927 options Options carried in this message; options are 928 described in section 22. 929 9307. Relay Agent/Server Message Formats 931 932 Relay agents exchange messages with servers to relay messages between 933 clients and servers that are not connected to the same link. 934 935 All values in the message header and in options are in network byte 936 order. 937 938 Options are stored serially in the options field, with no padding 939 between the options. Options are byte-aligned but are not aligned in 940 any other way such as on 2 or 4 byte boundaries. 941 942 943 944 945 946 947 948 949 950 951 952 953 954Droms, et al. Standards Track [Page 17] 955 956RFC 3315 DHCP for IPv6 July 2003 957 958 959 There are two relay agent messages, which share the following format: 960 961 0 1 2 3 962 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 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | msg-type | hop-count | | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 966 | | 967 | link-address | 968 | | 969 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 970 | | | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 972 | | 973 | peer-address | 974 | | 975 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 976 | | | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 978 . . 979 . options (variable number and length) .... . 980 | | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 983 The following sections describe the use of the Relay Agent message 984 header. 985 9867.1. Relay-forward Message 987 988 The following table defines the use of message fields in a Relay- 989 forward message. 990 991 msg-type RELAY-FORW 992 993 hop-count Number of relay agents that have relayed this 994 message. 995 996 link-address A global or site-local address that will be used by 997 the server to identify the link on which the client 998 is located. 999 1000 peer-address The address of the client or relay agent from which 1001 the message to be relayed was received. 1002 1003 options MUST include a "Relay Message option" (see 1004 section 22.10); MAY include other options added by 1005 the relay agent. 1006 1007 1008 1009 1010Droms, et al. Standards Track [Page 18] 1011 1012RFC 3315 DHCP for IPv6 July 2003 1013 1014 10157.2. Relay-reply Message 1016 1017 The following table defines the use of message fields in a 1018 Relay-reply message. 1019 1020 msg-type RELAY-REPL 1021 1022 hop-count Copied from the Relay-forward message 1023 1024 link-address Copied from the Relay-forward message 1025 1026 peer-address Copied from the Relay-forward message 1027 1028 options MUST include a "Relay Message option"; see 1029 section 22.10; MAY include other options 1030 10318. Representation and Use of Domain Names 1032 1033 So that domain names may be encoded uniformly, a domain name or a 1034 list of domain names is encoded using the technique described in 1035 section 3.1 of RFC 1035 [10]. A domain name, or list of domain 1036 names, in DHCP MUST NOT be stored in compressed form, as described in 1037 section 4.1.4 of RFC 1035. 1038 10399. DHCP Unique Identifier (DUID) 1040 1041 Each DHCP client and server has a DUID. DHCP servers use DUIDs to 1042 identify clients for the selection of configuration parameters and in 1043 the association of IAs with clients. DHCP clients use DUIDs to 1044 identify a server in messages where a server needs to be identified. 1045 See sections 22.2 and 22.3 for the representation of a DUID in a DHCP 1046 message. 1047 1048 Clients and servers MUST treat DUIDs as opaque values and MUST only 1049 compare DUIDs for equality. Clients and servers MUST NOT in any 1050 other way interpret DUIDs. Clients and servers MUST NOT restrict 1051 DUIDs to the types defined in this document, as additional DUID types 1052 may be defined in the future. 1053 1054 The DUID is carried in an option because it may be variable length 1055 and because it is not required in all DHCP messages. The DUID is 1056 designed to be unique across all DHCP clients and servers, and stable 1057 for any specific client or server - that is, the DUID used by a 1058 client or server SHOULD NOT change over time if at all possible; for 1059 example, a device's DUID should not change as a result of a change in 1060 the device's network hardware. 1061 1062 1063 1064 1065 1066Droms, et al. Standards Track [Page 19] 1067 1068RFC 3315 DHCP for IPv6 July 2003 1069 1070 1071 The motivation for having more than one type of DUID is that the DUID 1072 must be globally unique, and must also be easy to generate. The sort 1073 of globally-unique identifier that is easy to generate for any given 1074 device can differ quite widely. Also, some devices may not contain 1075 any persistent storage. Retaining a generated DUID in such a device 1076 is not possible, so the DUID scheme must accommodate such devices. 1077 10789.1. DUID Contents 1079 1080 A DUID consists of a two-octet type code represented in network byte 1081 order, followed by a variable number of octets that make up the 1082 actual identifier. A DUID can be no more than 128 octets long (not 1083 including the type code). The following types are currently defined: 1084 1085 1 Link-layer address plus time 1086 2 Vendor-assigned unique ID based on Enterprise Number 1087 3 Link-layer address 1088 1089 Formats for the variable field of the DUID for each of the above 1090 types are shown below. 1091 10929.2. DUID Based on Link-layer Address Plus Time [DUID-LLT] 1093 1094 This type of DUID consists of a two octet type field containing the 1095 value 1, a two octet hardware type code, four octets containing a 1096 time value, followed by link-layer address of any one network 1097 interface that is connected to the DHCP device at the time that the 1098 DUID is generated. The time value is the time that the DUID is 1099 generated represented in seconds since midnight (UTC), January 1, 1100 2000, modulo 2^32. The hardware type MUST be a valid hardware type 1101 assigned by the IANA as described in RFC 826 [14]. Both the time and 1102 the hardware type are stored in network byte order. The link-layer 1103 address is stored in canonical form, as described in RFC 2464 [2]. 1104 1105 The following diagram illustrates the format of a DUID-LLT: 1106 1107 0 1 2 3 1108 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 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | 1 | hardware type (16 bits) | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | time (32 bits) | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 . . 1115 . link-layer address (variable length) . 1116 . . 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 1119 1120 1121 1122Droms, et al. Standards Track [Page 20] 1123 1124RFC 3315 DHCP for IPv6 July 2003 1125 1126 1127 The choice of network interface can be completely arbitrary, as long 1128 as that interface provides a globally unique link-layer address for 1129 the link type, and the same DUID-LLT SHOULD be used in configuring 1130 all network interfaces connected to the device, regardless of which 1131 interface's link-layer address was used to generate the DUID-LLT. 1132 1133 Clients and servers using this type of DUID MUST store the DUID-LLT 1134 in stable storage, and MUST continue to use this DUID-LLT even if the 1135 network interface used to generate the DUID-LLT is removed. Clients 1136 and servers that do not have any stable storage MUST NOT use this 1137 type of DUID. 1138 1139 Clients and servers that use this DUID SHOULD attempt to configure 1140 the time prior to generating the DUID, if that is possible, and MUST 1141 use some sort of time source (for example, a real-time clock) in 1142 generating the DUID, even if that time source could not be configured 1143 prior to generating the DUID. The use of a time source makes it 1144 unlikely that two identical DUID-LLTs will be generated if the 1145 network interface is removed from the client and another client then 1146 uses the same network interface to generate a DUID-LLT. A collision 1147 between two DUID-LLTs is very unlikely even if the clocks have not 1148 been configured prior to generating the DUID. 1149 1150 This method of DUID generation is recommended for all general purpose 1151 computing devices such as desktop computers and laptop computers, and 1152 also for devices such as printers, routers, and so on, that contain 1153 some form of writable non-volatile storage. 1154 1155 Despite our best efforts, it is possible that this algorithm for 1156 generating a DUID could result in a client identifier collision. A 1157 DHCP client that generates a DUID-LLT using this mechanism MUST 1158 provide an administrative interface that replaces the existing DUID 1159 with a newly-generated DUID-LLT. 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178Droms, et al. Standards Track [Page 21] 1179 1180RFC 3315 DHCP for IPv6 July 2003 1181 1182 11839.3. DUID Assigned by Vendor Based on Enterprise Number [DUID-EN] 1184 1185 This form of DUID is assigned by the vendor to the device. It 1186 consists of the vendor's registered Private Enterprise Number as 1187 maintained by IANA [6] followed by a unique identifier assigned by 1188 the vendor. The following diagram summarizes the structure of a 1189 DUID-EN: 1190 1191 0 1 2 3 1192 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 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | 2 | enterprise-number | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | enterprise-number (contd) | | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1198 . identifier . 1199 . (variable length) . 1200 . . 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 1203 The source of the identifier is left up to the vendor defining it, 1204 but each identifier part of each DUID-EN MUST be unique to the device 1205 that is using it, and MUST be assigned to the device at the time it 1206 is manufactured and stored in some form of non-volatile storage. The 1207 generated DUID SHOULD be recorded in non-erasable storage. The 1208 enterprise-number is the vendor's registered Private Enterprise 1209 Number as maintained by IANA [6]. The enterprise-number is stored as 1210 an unsigned 32 bit number. 1211 1212 An example DUID of this type might look like this: 1213 1214 +---+---+---+---+---+---+---+---+ 1215 | 0 | 2 | 0 | 0 | 0 | 9| 12|192| 1216 +---+---+---+---+---+---+---+---+ 1217 |132|221| 3 | 0 | 9 | 18| 1218 +---+---+---+---+---+---+ 1219 1220 This example includes the two-octet type of 2, the Enterprise Number 1221 (9), followed by eight octets of identifier data 1222 (0x0CC084D303000912). 1223 12249.4. DUID Based on Link-layer Address [DUID-LL] 1225 1226 This type of DUID consists of two octets containing the DUID type 3, 1227 a two octet network hardware type code, followed by the link-layer 1228 address of any one network interface that is permanently connected to 1229 the client or server device. For example, a host that has a network 1230 interface implemented in a chip that is unlikely to be removed and 1231 1232 1233 1234Droms, et al. Standards Track [Page 22] 1235 1236RFC 3315 DHCP for IPv6 July 2003 1237 1238 1239 used elsewhere could use a DUID-LL. The hardware type MUST be a 1240 valid hardware type assigned by the IANA, as described in RFC 826 1241 [14]. The hardware type is stored in network byte order. The 1242 link-layer address is stored in canonical form, as described in RFC 1243 2464 [2]. The following diagram illustrates the format of a DUID-LL: 1244 1245 0 1 2 3 1246 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 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | 3 | hardware type (16 bits) | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 . . 1251 . link-layer address (variable length) . 1252 . . 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 1255 The choice of network interface can be completely arbitrary, as long 1256 as that interface provides a unique link-layer address and is 1257 permanently attached to the device on which the DUID-LL is being 1258 generated. The same DUID-LL SHOULD be used in configuring all 1259 network interfaces connected to the device, regardless of which 1260 interface's link-layer address was used to generate the DUID. 1261 1262 DUID-LL is recommended for devices that have a permanently-connected 1263 network interface with a link-layer address, and do not have 1264 nonvolatile, writable stable storage. DUID-LL MUST NOT be used by 1265 DHCP clients or servers that cannot tell whether or not a network 1266 interface is permanently attached to the device on which the DHCP 1267 client is running. 1268 126910. Identity Association 1270 1271 An "identity-association" (IA) is a construct through which a server 1272 and a client can identify, group, and manage a set of related IPv6 1273 addresses. Each IA consists of an IAID and associated configuration 1274 information. 1275 1276 A client must associate at least one distinct IA with each of its 1277 network interfaces for which it is to request the assignment of IPv6 1278 addresses from a DHCP server. The client uses the IAs assigned to an 1279 interface to obtain configuration information from a server for that 1280 interface. Each IA must be associated with exactly one interface. 1281 1282 The IAID uniquely identifies the IA and must be chosen to be unique 1283 among the IAIDs on the client. The IAID is chosen by the client. 1284 For any given use of an IA by the client, the IAID for that IA MUST 1285 be consistent across restarts of the DHCP client. The client may 1286 maintain consistency either by storing the IAID in non-volatile 1287 1288 1289 1290Droms, et al. Standards Track [Page 23] 1291 1292RFC 3315 DHCP for IPv6 July 2003 1293 1294 1295 storage or by using an algorithm that will consistently produce the 1296 same IAID as long as the configuration of the client has not changed. 1297 There may be no way for a client to maintain consistency of the IAIDs 1298 if it does not have non-volatile storage and the client's hardware 1299 configuration changes. 1300 1301 The configuration information in an IA consists of one or more IPv6 1302 addresses along with the times T1 and T2 for the IA. See section 1303 22.4 for the representation of an IA in a DHCP message. 1304 1305 Each address in an IA has a preferred lifetime and a valid lifetime, 1306 as defined in RFC 2462 [17]. The lifetimes are transmitted from the 1307 DHCP server to the client in the IA option. The lifetimes apply to 1308 the use of IPv6 addresses, as described in section 5.5.4 of RFC 2462. 1309 131011. Selecting Addresses for Assignment to an IA 1311 1312 A server selects addresses to be assigned to an IA according to the 1313 address assignment policies determined by the server administrator 1314 and the specific information the server determines about the client 1315 from some combination of the following sources: 1316 1317 - The link to which the client is attached. The server determines 1318 the link as follows: 1319 1320 * If the server receives the message directly from the client and 1321 the source address in the IP datagram in which the message was 1322 received is a link-local address, then the client is on the 1323 same link to which the interface over which the message was 1324 received is attached. 1325 1326 * If the server receives the message from a forwarding relay 1327 agent, then the client is on the same link as the one to which 1328 the interface, identified by the link-address field in the 1329 message from the relay agent, is attached. 1330 1331 * If the server receives the message directly from the client and 1332 the source address in the IP datagram in which the message was 1333 received is not a link-local address, then the client is on the 1334 link identified by the source address in the IP datagram (note 1335 that this situation can occur only if the server has enabled 1336 the use of unicast message delivery by the client and the 1337 client has sent a message for which unicast delivery is 1338 allowed). 1339 1340 - The DUID supplied by the client. 1341 1342 - Other information in options supplied by the client. 1343 1344 1345 1346Droms, et al. Standards Track [Page 24] 1347 1348RFC 3315 DHCP for IPv6 July 2003 1349 1350 1351 - Other information in options supplied by the relay agent. 1352 1353 Any address assigned by a server that is based on an EUI-64 1354 identifier MUST include an interface identifier with the "u" 1355 (universal/local) and "g" (individual/group) bits of the interface 1356 identifier set appropriately, as indicated in section 2.5.1 of RFC 1357 2373 [5]. 1358 1359 A server MUST NOT assign an address that is otherwise reserved for 1360 some other purpose. For example, a server MUST NOT assign reserved 1361 anycast addresses, as defined in RFC 2526, from any subnet. 1362 136312. Management of Temporary Addresses 1364 1365 A client may request the assignment of temporary addresses (see RFC 1366 3041 [12] for the definition of temporary addresses). DHCPv6 1367 handling of address assignment is no different for temporary 1368 addresses. DHCPv6 says nothing about details of temporary addresses 1369 like lifetimes, how clients use temporary addresses, rules for 1370 generating successive temporary addresses, etc. 1371 1372 Clients ask for temporary addresses and servers assign them. 1373 Temporary addresses are carried in the Identity Association for 1374 Temporary Addresses (IA_TA) option (see section 22.5). Each IA_TA 1375 option contains at most one temporary address for each of the 1376 prefixes on the link to which the client is attached. 1377 1378 The IAID number space for the IA_TA option IAID number space is 1379 separate from the IA_NA option IAID number space. 1380 1381 The server MAY update the DNS for a temporary address, as described 1382 in section 4 of RFC 3041. 1383 138413. Transmission of Messages by a Client 1385 1386 Unless otherwise specified in this document, or in a document that 1387 describes how IPv6 is carried over a specific type of link (for link 1388 types that do not support multicast), a client sends DHCP messages to 1389 the All_DHCP_Relay_Agents_and_Servers. 1390 1391 A client uses multicast to reach all servers or an individual server. 1392 An individual server is indicated by specifying that server's DUID in 1393 a Server Identifier option (see section 22.3) in the client's message 1394 (all servers will receive this message but only the indicated server 1395 will respond). All servers are indicated by not supplying this 1396 option. 1397 1398 1399 1400 1401 1402Droms, et al. Standards Track [Page 25] 1403 1404RFC 3315 DHCP for IPv6 July 2003 1405 1406 1407 A client may send some messages directly to a server using unicast, 1408 as described in section 22.12. 1409 141014. Reliability of Client Initiated Message Exchanges 1411 1412 DHCP clients are responsible for reliable delivery of messages in the 1413 client-initiated message exchanges described in sections 17 and 18. 1414 If a DHCP client fails to receive an expected response from a server, 1415 the client must retransmit its message. This section describes the 1416 retransmission strategy to be used by clients in client-initiated 1417 message exchanges. 1418 1419 Note that the procedure described in this section is slightly 1420 modified when used with the Solicit message. The modified procedure 1421 is described in section 17.1.2. 1422 1423 The client begins the message exchange by transmitting a message to 1424 the server. The message exchange terminates when either the client 1425 successfully receives the appropriate response or responses from a 1426 server or servers, or when the message exchange is considered to have 1427 failed according to the retransmission mechanism described below. 1428 1429 The client retransmission behavior is controlled and described by the 1430 following variables: 1431 1432 RT Retransmission timeout 1433 1434 IRT Initial retransmission time 1435 1436 MRC Maximum retransmission count 1437 1438 MRT Maximum retransmission time 1439 1440 MRD Maximum retransmission duration 1441 1442 RAND Randomization factor 1443 1444 With each message transmission or retransmission, the client sets RT 1445 according to the rules given below. If RT expires before the message 1446 exchange terminates, the client recomputes RT and retransmits the 1447 message. 1448 1449 Each of the computations of a new RT include a randomization factor 1450 (RAND), which is a random number chosen with a uniform distribution 1451 between -0.1 and +0.1. The randomization factor is included to 1452 minimize synchronization of messages transmitted by DHCP clients. 1453 1454 1455 1456 1457 1458Droms, et al. Standards Track [Page 26] 1459 1460RFC 3315 DHCP for IPv6 July 2003 1461 1462 1463 The algorithm for choosing a random number does not need to be 1464 cryptographically sound. The algorithm SHOULD produce a different 1465 sequence of random numbers from each invocation of the DHCP client. 1466 1467 RT for the first message transmission is based on IRT: 1468 1469 RT = IRT + RAND*IRT 1470 1471 RT for each subsequent message transmission is based on the previous 1472 value of RT: 1473 1474 RT = 2*RTprev + RAND*RTprev 1475 1476 MRT specifies an upper bound on the value of RT (disregarding the 1477 randomization added by the use of RAND). If MRT has a value of 0, 1478 there is no upper limit on the value of RT. Otherwise: 1479 1480 if (RT > MRT) 1481 RT = MRT + RAND*MRT 1482 1483 MRC specifies an upper bound on the number of times a client may 1484 retransmit a message. Unless MRC is zero, the message exchange fails 1485 once the client has transmitted the message MRC times. 1486 1487 MRD specifies an upper bound on the length of time a client may 1488 retransmit a message. Unless MRD is zero, the message exchange fails 1489 once MRD seconds have elapsed since the client first transmitted the 1490 message. 1491 1492 If both MRC and MRD are non-zero, the message exchange fails whenever 1493 either of the conditions specified in the previous two paragraphs are 1494 met. 1495 1496 If both MRC and MRD are zero, the client continues to transmit the 1497 message until it receives a response. 1498 149915. Message Validation 1500 1501 Clients and servers SHOULD discard any messages that contain options 1502 that are not allowed to appear in the received message. For example, 1503 an IA option is not allowed to appear in an Information-request 1504 message. Clients and servers MAY choose to extract information from 1505 such a message if the information is of use to the recipient. 1506 1507 A server MUST discard any Solicit, Confirm, Rebind or 1508 Information-request messages it receives with a unicast destination 1509 address. 1510 1511 1512 1513 1514Droms, et al. Standards Track [Page 27] 1515 1516RFC 3315 DHCP for IPv6 July 2003 1517 1518 1519 Message validation based on DHCP authentication is discussed in 1520 section 21.4.2. 1521 1522 If a server receives a message that contains options it should not 1523 contain (such as an Information-request message with an IA option), 1524 is missing options that it should contain, or is otherwise not valid, 1525 it MAY send a Reply (or Advertise as appropriate) with a Server 1526 Identifier option, a Client Identifier option if one was included in 1527 the message and a Status Code option with status UnSpecFail. 1528 152915.1. Use of Transaction IDs 1530 1531 The "transaction-id" field holds a value used by clients and servers 1532 to synchronize server responses to client messages. A client SHOULD 1533 generate a random number that cannot easily be guessed or predicted 1534 to use as the transaction ID for each new message it sends. Note 1535 that if a client generates easily predictable transaction 1536 identifiers, it may become more vulnerable to certain kinds of 1537 attacks from off-path intruders. A client MUST leave the transaction 1538 ID unchanged in retransmissions of a message. 1539 154015.2. Solicit Message 1541 1542 Clients MUST discard any received Solicit messages. 1543 1544 Servers MUST discard any Solicit messages that do not include a 1545 Client Identifier option or that do include a Server Identifier 1546 option. 1547 154815.3. Advertise Message 1549 1550 Clients MUST discard any received Advertise messages that meet any of 1551 the following conditions: 1552 1553 - the message does not include a Server Identifier option. 1554 1555 - the message does not include a Client Identifier option. 1556 1557 - the contents of the Client Identifier option does not match the 1558 client's DUID. 1559 1560 - the "transaction-id" field value does not match the value the 1561 client used in its Solicit message. 1562 1563 Servers and relay agents MUST discard any received Advertise 1564 messages. 1565 1566 1567 1568 1569 1570Droms, et al. Standards Track [Page 28] 1571 1572RFC 3315 DHCP for IPv6 July 2003 1573 1574 157515.4. Request Message 1576 1577 Clients MUST discard any received Request messages. 1578 1579 Servers MUST discard any received Request message that meet any of 1580 the following conditions: 1581 1582 - the message does not include a Server Identifier option. 1583 1584 - the contents of the Server Identifier option do not match the 1585 server's DUID. 1586 1587 - the message does not include a Client Identifier option. 1588 158915.5. Confirm Message 1590 1591 Clients MUST discard any received Confirm messages. 1592 1593 Servers MUST discard any received Confirm messages that do not 1594 include a Client Identifier option or that do include a Server 1595 Identifier option. 1596 159715.6. Renew Message 1598 1599 Clients MUST discard any received Renew messages. 1600 1601 Servers MUST discard any received Renew message that meets any of the 1602 following conditions: 1603 1604 - the message does not include a Server Identifier option. 1605 1606 - the contents of the Server Identifier option does not match the 1607 server's identifier. 1608 1609 - the message does not include a Client Identifier option. 1610 161115.7. Rebind Message 1612 1613 Clients MUST discard any received Rebind messages. 1614 1615 Servers MUST discard any received Rebind messages that do not include 1616 a Client Identifier option or that do include a Server Identifier 1617 option. 1618 1619 1620 1621 1622 1623 1624 1625 1626Droms, et al. Standards Track [Page 29] 1627 1628RFC 3315 DHCP for IPv6 July 2003 1629 1630 163115.8. Decline Messages 1632 1633 Clients MUST discard any received Decline messages. 1634 1635 Servers MUST discard any received Decline message that meets any of 1636 the following conditions: 1637 1638 - the message does not include a Server Identifier option. 1639 1640 - the contents of the Server Identifier option does not match the 1641 server's identifier. 1642 1643 - the message does not include a Client Identifier option. 1644 164515.9. Release Message 1646 1647 Clients MUST discard any received Release messages. 1648 1649 Servers MUST discard any received Release message that meets any of 1650 the following conditions: 1651 1652 - the message does not include a Server Identifier option. 1653 1654 - the contents of the Server Identifier option does not match the 1655 server's identifier. 1656 1657 - the message does not include a Client Identifier option. 1658 165915.10. Reply Message 1660 1661 Clients MUST discard any received Reply message that meets any of the 1662 following conditions: 1663 1664 - the message does not include a Server Identifier option. 1665 1666 - the "transaction-id" field in the message does not match the value 1667 used in the original message. 1668 1669 If the client included a Client Identifier option in the original 1670 message, the Reply message MUST include a Client Identifier option 1671 and the contents of the Client Identifier option MUST match the DUID 1672 of the client; OR, if the client did not include a Client Identifier 1673 option in the original message, the Reply message MUST NOT include a 1674 Client Identifier option. 1675 1676 Servers and relay agents MUST discard any received Reply messages. 1677 1678 1679 1680 1681 1682Droms, et al. Standards Track [Page 30] 1683 1684RFC 3315 DHCP for IPv6 July 2003 1685 1686 168715.11. Reconfigure Message 1688 1689 Servers and relay agents MUST discard any received Reconfigure 1690 messages. 1691 1692 Clients MUST discard any Reconfigure messages that meets any of the 1693 following conditions: 1694 1695 - the message was not unicast to the client. 1696 1697 - the message does not include a Server Identifier option. 1698 1699 - the message does not include a Client Identifier option that 1700 contains the client's DUID. 1701 1702 - the message does not contain a Reconfigure Message option and the 1703 msg-type must be a valid value. 1704 1705 - the message includes any IA options and the msg-type in the 1706 Reconfigure Message option is INFORMATION-REQUEST. 1707 1708 - the message does not include DHCP authentication: 1709 1710 * the message does not contain an authentication option. 1711 1712 * the message does not pass the authentication validation 1713 performed by the client. 1714 171515.12. Information-request Message 1716 1717 Clients MUST discard any received Information-request messages. 1718 1719 Servers MUST discard any received Information-request message that 1720 meets any of the following conditions: 1721 1722 - The message includes a Server Identifier option and the DUID in 1723 the option does not match the server's DUID. 1724 1725 - The message includes an IA option. 1726 172715.13. Relay-forward Message 1728 1729 Clients MUST discard any received Relay-forward messages. 1730 173115.14. Relay-reply Message 1732 1733 Clients and servers MUST discard any received Relay-reply messages. 1734 1735 1736 1737 1738Droms, et al. Standards Track [Page 31] 1739 1740RFC 3315 DHCP for IPv6 July 2003 1741 1742 174316. Client Source Address and Interface Selection 1744 1745 When a client sends a DHCP message to the 1746 All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message 1747 through the interface for which configuration information is being 1748 requested. However, the client MAY send the message through another 1749 interface attached to the same link, if and only if the client is 1750 certain the two interfaces are attached to the same link. The client 1751 MUST use a link-local address assigned to the interface for which it 1752 is requesting configuration information as the source address in the 1753 header of the IP datagram. 1754 1755 When a client sends a DHCP message directly to a server using unicast 1756 (after receiving the Server Unicast option from that server), the 1757 source address in the header of the IP datagram MUST be an address 1758 assigned to the interface for which the client is interested in 1759 obtaining configuration and which is suitable for use by the server 1760 in responding to the client. 1761 176217. DHCP Server Solicitation 1763 1764 This section describes how a client locates servers that will assign 1765 addresses to IAs belonging to the client. 1766 1767 The client is responsible for creating IAs and requesting that a 1768 server assign IPv6 addresses to the IA. The client first creates an 1769 IA and assigns it an IAID. The client then transmits a Solicit 1770 message containing an IA option describing the IA. Servers that can 1771 assign addresses to the IA respond to the client with an Advertise 1772 message. The client then initiates a configuration exchange as 1773 described in section 18. 1774 1775 If the client will accept a Reply message with committed address 1776 assignments and other resources in response to the Solicit message, 1777 the client includes a Rapid Commit option (see section 22.14) in the 1778 Solicit message. 1779 178017.1. Client Behavior 1781 1782 A client uses the Solicit message to discover DHCP servers configured 1783 to assign addresses or return other configuration parameters on the 1784 link to which the client is attached. 1785 178617.1.1. Creation of Solicit Messages 1787 1788 The client sets the "msg-type" field to SOLICIT. The client 1789 generates a transaction ID and inserts this value in the 1790 "transaction-id" field. 1791 1792 1793 1794Droms, et al. Standards Track [Page 32] 1795 1796RFC 3315 DHCP for IPv6 July 2003 1797 1798 1799 The client MUST include a Client Identifier option to identify itself 1800 to the server. The client includes IA options for any IAs to which 1801 it wants the server to assign addresses. The client MAY include 1802 addresses in the IAs as a hint to the server about addresses for 1803 which the client has a preference. The client MUST NOT include any 1804 other options in the Solicit message, except as specifically allowed 1805 in the definition of individual options. 1806 1807 The client uses IA_NA options to request the assignment of non- 1808 temporary addresses and uses IA_TA options to request the assignment 1809 of temporary addresses. Either IA_NA or IA_TA options, or a 1810 combination of both, can be included in DHCP messages. 1811 1812 The client SHOULD include an Option Request option (see section 22.7) 1813 to indicate the options the client is interested in receiving. The 1814 client MAY additionally include instances of those options that are 1815 identified in the Option Request option, with data values as hints to 1816 the server about parameter values the client would like to have 1817 returned. 1818 1819 The client includes a Reconfigure Accept option (see section 22.20) 1820 if the client is willing to accept Reconfigure messages from the 1821 server. 1822 182317.1.2. Transmission of Solicit Messages 1824 1825 The first Solicit message from the client on the interface MUST be 1826 delayed by a random amount of time between 0 and SOL_MAX_DELAY. In 1827 the case of a Solicit message transmitted when DHCP is initiated by 1828 IPv6 Neighbor Discovery, the delay gives the amount of time to wait 1829 after IPv6 Neighbor Discovery causes the client to invoke the 1830 stateful address autoconfiguration protocol (see section 5.5.3 of RFC 1831 2462). This random delay desynchronizes clients which start at the 1832 same time (for example, after a power outage). 1833 1834 The client transmits the message according to section 14, using the 1835 following parameters: 1836 1837 IRT SOL_TIMEOUT 1838 1839 MRT SOL_MAX_RT 1840 1841 MRC 0 1842 1843 MRD 0 1844 1845 1846 1847 1848 1849 1850Droms, et al. Standards Track [Page 33] 1851 1852RFC 3315 DHCP for IPv6 July 2003 1853 1854 1855 If the client has included a Rapid Commit option in its Solicit 1856 message, the client terminates the waiting process as soon as a Reply 1857 message with a Rapid Commit option is received. 1858 1859 If the client is waiting for an Advertise message, the mechanism in 1860 section 14 is modified as follows for use in the transmission of 1861 Solicit messages. The message exchange is not terminated by the 1862 receipt of an Advertise before the first RT has elapsed. Rather, the 1863 client collects Advertise messages until the first RT has elapsed. 1864 Also, the first RT MUST be selected to be strictly greater than IRT 1865 by choosing RAND to be strictly greater than 0. 1866 1867 A client MUST collect Advertise messages for the first RT seconds, 1868 unless it receives an Advertise message with a preference value of 1869 255. The preference value is carried in the Preference option 1870 (section 22.8). Any Advertise that does not include a Preference 1871 option is considered to have a preference value of 0. If the client 1872 receives an Advertise message that includes a Preference option with 1873 a preference value of 255, the client immediately begins a client- 1874 initiated message exchange (as described in section 18) by sending a 1875 Request message to the server from which the Advertise message was 1876 received. If the client receives an Advertise message that does not 1877 include a Preference option with a preference value of 255, the 1878 client continues to wait until the first RT elapses. If the first RT 1879 elapses and the client has received an Advertise message, the client 1880 SHOULD continue with a client-initiated message exchange by sending a 1881 Request message. 1882 1883 If the client does not receive any Advertise messages before the 1884 first RT has elapsed, it begins the retransmission mechanism 1885 described in section 14. The client terminates the retransmission 1886 process as soon as it receives any Advertise message, and the client 1887 acts on the received Advertise message without waiting for any 1888 additional Advertise messages. 1889 1890 A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client 1891 is configured with either MRC or MRD set to a value other than 0, it 1892 MUST stop trying to configure the interface if the message exchange 1893 fails. After the DHCP client stops trying to configure the 1894 interface, it SHOULD restart the reconfiguration process after some 1895 external event, such as user input, system restart, or when the 1896 client is attached to a new link. 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906Droms, et al. Standards Track [Page 34] 1907 1908RFC 3315 DHCP for IPv6 July 2003 1909 1910 191117.1.3. Receipt of Advertise Messages 1912 1913 The client MUST ignore any Advertise message that includes a Status 1914 Code option containing the value NoAddrsAvail, with the exception 1915 that the client MAY display the associated status message to the 1916 user. 1917 1918 Upon receipt of one or more valid Advertise messages, the client 1919 selects one or more Advertise messages based upon the following 1920 criteria. 1921 1922 - Those Advertise messages with the highest server preference value 1923 are preferred over all other Advertise messages. 1924 1925 - Within a group of Advertise messages with the same server 1926 preference value, a client MAY select those servers whose 1927 Advertise messages advertise information of interest to the 1928 client. For example, the client may choose a server that returned 1929 an advertisement with configuration options of interest to the 1930 client. 1931 1932 - The client MAY choose a less-preferred server if that server has a 1933 better set of advertised parameters, such as the available 1934 addresses advertised in IAs. 1935 1936 Once a client has selected Advertise message(s), the client will 1937 typically store information about each server, such as server 1938 preference value, addresses advertised, when the advertisement was 1939 received, and so on. 1940 1941 If the client needs to select an alternate server in the case that a 1942 chosen server does not respond, the client chooses the next server 1943 according to the criteria given above. 1944 194517.1.4. Receipt of Reply Message 1946 1947 If the client includes a Rapid Commit option in the Solicit message, 1948 it will expect a Reply message that includes a Rapid Commit option in 1949 response. The client discards any Reply messages it receives that do 1950 not include a Rapid Commit option. If the client receives a valid 1951 Reply message that includes a Rapid Commit option, it processes the 1952 message as described in section 18.1.8. If it does not receive such 1953 a Reply message and does receive a valid Advertise message, the 1954 client processes the Advertise message as described in section 1955 17.1.3. 1956 1957 1958 1959 1960 1961 1962Droms, et al. Standards Track [Page 35] 1963 1964RFC 3315 DHCP for IPv6 July 2003 1965 1966 1967 If the client subsequently receives a valid Reply message that 1968 includes a Rapid Commit option, it either: 1969 1970 processes the Reply message as described in section 18.1.8, and 1971 discards any Reply messages received in response to the Request 1972 message, or 1973 1974 processes any Reply messages received in response to the Request 1975 message and discards the Reply message that includes the Rapid 1976 Commit option. 1977 197817.2. Server Behavior 1979 1980 A server sends an Advertise message in response to valid Solicit 1981 messages it receives to announce the availability of the server to 1982 the client. 1983 198417.2.1. Receipt of Solicit Messages 1985 1986 The server determines the information about the client and its 1987 location as described in section 11 and checks its administrative 1988 policy about responding to the client. If the server is not 1989 permitted to respond to the client, the server discards the Solicit 1990 message. For example, if the administrative policy for the server is 1991 that it may only respond to a client that is willing to accept a 1992 Reconfigure message, if the client indicates with a Reconfigure 1993 Accept option in the Solicit message that it will not accept a 1994 Reconfigure message, the servers discard the Solicit message. 1995 1996 If the client has included a Rapid Commit option in the Solicit 1997 message and the server has been configured to respond with committed 1998 address assignments and other resources, the server responds to the 1999 Solicit with a Reply message as described in section 17.2.3. 2000 Otherwise, the server ignores the Rapid Commit option and processes 2001 the remainder of the message as if no Rapid Commit option were 2002 present. 2003 200417.2.2. Creation and Transmission of Advertise Messages 2005 2006 The server sets the "msg-type" field to ADVERTISE and copies the 2007 contents of the transaction-id field from the Solicit message 2008 received from the client to the Advertise message. The server 2009 includes its server identifier in a Server Identifier option and 2010 copies the Client Identifier from the Solicit message into the 2011 Advertise message. 2012 2013 2014 2015 2016 2017 2018Droms, et al. Standards Track [Page 36] 2019 2020RFC 3315 DHCP for IPv6 July 2003 2021 2022 2023 The server MAY add a Preference option to carry the preference value 2024 for the Advertise message. The server implementation SHOULD allow 2025 the setting of a server preference value by the administrator. The 2026 server preference value MUST default to zero unless otherwise 2027 configured by the server administrator. 2028 2029 The server includes a Reconfigure Accept option if the server wants 2030 to require that the client accept Reconfigure messages. 2031 2032 The server includes options the server will return to the client in a 2033 subsequent Reply message. The information in these options may be 2034 used by the client in the selection of a server if the client 2035 receives more than one Advertise message. If the client has included 2036 an Option Request option in the Solicit message, the server includes 2037 options in the Advertise message containing configuration parameters 2038 for all of the options identified in the Option Request option that 2039 the server has been configured to return to the client. The server 2040 MAY return additional options to the client if it has been configured 2041 to do so. The server must be aware of the recommendations on packet 2042 sizes and the use of fragmentation in section 5 of RFC 2460. 2043 2044 If the Solicit message from the client included one or more IA 2045 options, the server MUST include IA options in the Advertise message 2046 containing any addresses that would be assigned to IAs contained in 2047 the Solicit message from the client. If the client has included 2048 addresses in the IAs in the Solicit message, the server uses those 2049 addresses as hints about the addresses the client would like to 2050 receive. 2051 2052 If the server will not assign any addresses to any IAs in a 2053 subsequent Request from the client, the server MUST send an Advertise 2054 message to the client that includes only a Status Code option with 2055 code NoAddrsAvail and a status message for the user, a Server 2056 Identifier option with the server's DUID, and a Client Identifier 2057 option with the client's DUID. 2058 2059 If the Solicit message was received directly by the server, the 2060 server unicasts the Advertise message directly to the client using 2061 the address in the source address field from the IP datagram in which 2062 the Solicit message was received. The Advertise message MUST be 2063 unicast on the link from which the Solicit message was received. 2064 2065 If the Solicit message was received in a Relay-forward message, the 2066 server constructs a Relay-reply message with the Advertise message in 2067 the payload of a "relay-message" option. If the Relay-forward 2068 messages included an Interface-id option, the server copies that 2069 option to the Relay-reply message. The server unicasts the 2070 Relay-reply message directly to the relay agent using the address in 2071 2072 2073 2074Droms, et al. Standards Track [Page 37] 2075 2076RFC 3315 DHCP for IPv6 July 2003 2077 2078 2079 the source address field from the IP datagram in which the Relay- 2080 forward message was received. 2081 208217.2.3. Creation and Transmission of Reply Messages 2083 2084 The server MUST commit the assignment of any addresses or other 2085 configuration information message before sending a Reply message to a 2086 client in response to a Solicit message. 2087 2088 DISCUSSION: 2089 2090 When using the Solicit-Reply message exchange, the server commits 2091 the assignment of any addresses before sending the Reply message. 2092 The client can assume it has been assigned the addresses in the 2093 Reply message and does not need to send a Request message for 2094 those addresses. 2095 2096 Typically, servers that are configured to use the Solicit-Reply 2097 message exchange will be deployed so that only one server will 2098 respond to a Solicit message. If more than one server responds, 2099 the client will only use the addresses from one of the servers, 2100 while the addresses from the other servers will be committed to 2101 the client but not used by the client. 2102 2103 The server includes a Rapid Commit option in the Reply message to 2104 indicate that the Reply is in response to a Solicit message. 2105 2106 The server includes a Reconfigure Accept option if the server wants 2107 to require that the client accept Reconfigure messages. 2108 2109 The server produces the Reply message as though it had received a 2110 Request message, as described in section 18.2.1. The server 2111 transmits the Reply message as described in section 18.2.8. 2112 211318. DHCP Client-Initiated Configuration Exchange 2114 2115 A client initiates a message exchange with a server or servers to 2116 acquire or update configuration information of interest. The client 2117 may initiate the configuration exchange as part of the operating 2118 system configuration process, when requested to do so by the 2119 application layer, when required by Stateless Address 2120 Autoconfiguration or as required to extend the lifetime of an address 2121 (Renew and Rebind messages). 2122 2123 2124 2125 2126 2127 2128 2129 2130Droms, et al. Standards Track [Page 38] 2131 2132RFC 3315 DHCP for IPv6 July 2003 2133 2134 213518.1. Client Behavior 2136 2137 A client uses Request, Renew, Rebind, Release and Decline messages 2138 during the normal life cycle of addresses. It uses Confirm to 2139 validate addresses when it may have moved to a new link. It uses 2140 Information-Request messages when it needs configuration information 2141 but no addresses. 2142 2143 If the client has a source address of sufficient scope that can be 2144 used by the server as a return address, and the client has received a 2145 Server Unicast option (section 22.12) from the server, the client 2146 SHOULD unicast any Request, Renew, Release and Decline messages to 2147 the server. 2148 2149 DISCUSSION: 2150 2151 Use of unicast may avoid delays due to the relaying of messages by 2152 relay agents, as well as avoid overhead and duplicate responses by 2153 servers due to the delivery of client messages to multiple 2154 servers. Requiring the client to relay all DHCP messages through 2155 a relay agent enables the inclusion of relay agent options in all 2156 messages sent by the client. The server should enable the use of 2157 unicast only when relay agent options will not be used. 2158 215918.1.1. Creation and Transmission of Request Messages 2160 2161 The client uses a Request message to populate IAs with addresses and 2162 obtain other configuration information. The client includes one or 2163 more IA options in the Request message. The server then returns 2164 addresses and other information about the IAs to the client in IA 2165 options in a Reply message. 2166 2167 The client generates a transaction ID and inserts this value in the 2168 "transaction-id" field. 2169 2170 The client places the identifier of the destination server in a 2171 Server Identifier option. 2172 2173 The client MUST include a Client Identifier option to identify itself 2174 to the server. The client adds any other appropriate options, 2175 including one or more IA options (if the client is requesting that 2176 the server assign it some network addresses). 2177 2178 The client MUST include an Option Request option (see section 22.7) 2179 to indicate the options the client is interested in receiving. The 2180 client MAY include options with data values as hints to the server 2181 about parameter values the client would like to have returned. 2182 2183 2184 2185 2186Droms, et al. Standards Track [Page 39] 2187 2188RFC 3315 DHCP for IPv6 July 2003 2189 2190 2191 The client includes a Reconfigure Accept option (see section 22.20) 2192 indicating whether or not the client is willing to accept Reconfigure 2193 messages from the server. 2194 2195 The client transmits the message according to section 14, using the 2196 following parameters: 2197 2198 IRT REQ_TIMEOUT 2199 2200 MRT REQ_MAX_RT 2201 2202 MRC REQ_MAX_RC 2203 2204 MRD 0 2205 2206 If the message exchange fails, the client takes an action based on 2207 the client's local policy. Examples of actions the client might take 2208 include: 2209 2210 - Select another server from a list of servers known to the client; 2211 for example, servers that responded with an Advertise message. 2212 2213 - Initiate the server discovery process described in section 17. 2214 2215 - Terminate the configuration process and report failure. 2216 221718.1.2. Creation and Transmission of Confirm Messages 2218 2219 Whenever a client may have moved to a new link, the prefixes from the 2220 addresses assigned to the interfaces on that link may no longer be 2221 appropriate for the link to which the client is attached. Examples 2222 of times when a client may have moved to a new link include: 2223 2224 o The client reboots. 2225 2226 o The client is physically connected to a wired connection. 2227 2228 o The client returns from sleep mode. 2229 2230 o The client using a wireless technology changes access points. 2231 2232 In any situation when a client may have moved to a new link, the 2233 client MUST initiate a Confirm/Reply message exchange. The client 2234 includes any IAs assigned to the interface that may have moved to a 2235 new link, along with the addresses associated with those IAs, in its 2236 2237 2238 2239 2240 2241 2242Droms, et al. Standards Track [Page 40] 2243 2244RFC 3315 DHCP for IPv6 July 2003 2245 2246 2247 Confirm message. Any responding servers will indicate whether those 2248 addresses are appropriate for the link to which the client is 2249 attached with the status in the Reply message it returns to the 2250 client. 2251 2252 The client sets the "msg-type" field to CONFIRM. The client 2253 generates a transaction ID and inserts this value in the 2254 "transaction-id" field. 2255 2256 The client MUST include a Client Identifier option to identify itself 2257 to the server. The client includes IA options for all of the IAs 2258 assigned to the interface for which the Confirm message is being 2259 sent. The IA options include all of the addresses the client 2260 currently has associated with those IAs. The client SHOULD set the 2261 T1 and T2 fields in any IA_NA options, and the preferred-lifetime and 2262 valid-lifetime fields in the IA Address options to 0, as the server 2263 will ignore these fields. 2264 2265 The first Confirm message from the client on the interface MUST be 2266 delayed by a random amount of time between 0 and CNF_MAX_DELAY. The 2267 client transmits the message according to section 14, using the 2268 following parameters: 2269 2270 IRT CNF_TIMEOUT 2271 2272 MRT CNF_MAX_RT 2273 2274 MRC 0 2275 2276 MRD CNF_MAX_RD 2277 2278 If the client receives no responses before the message transmission 2279 process terminates, as described in section 14, the client SHOULD 2280 continue to use any IP addresses, using the last known lifetimes for 2281 those addresses, and SHOULD continue to use any other previously 2282 obtained configuration parameters. 2283 228418.1.3. Creation and Transmission of Renew Messages 2285 2286 To extend the valid and preferred lifetimes for the addresses 2287 associated with an IA, the client sends a Renew message to the server 2288 from which the client obtained the addresses in the IA containing an 2289 IA option for the IA. The client includes IA Address options in the 2290 IA option for the addresses associated with the IA. The server 2291 determines new lifetimes for the addresses in the IA according to the 2292 administrative configuration of the server. The server may also add 2293 2294 2295 2296 2297 2298Droms, et al. Standards Track [Page 41] 2299 2300RFC 3315 DHCP for IPv6 July 2003 2301 2302 2303 new addresses to the IA. The server may remove addresses from the IA 2304 by setting the preferred and valid lifetimes of those addresses to 2305 zero. 2306 2307 The server controls the time at which the client contacts the server 2308 to extend the lifetimes on assigned addresses through the T1 and T2 2309 parameters assigned to an IA. 2310 2311 At time T1 for an IA, the client initiates a Renew/Reply message 2312 exchange to extend the lifetimes on any addresses in the IA. The 2313 client includes an IA option with all addresses currently assigned to 2314 the IA in its Renew message. 2315 2316 If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no 2317 T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind 2318 message, respectively, at the client's discretion. 2319 2320 The client sets the "msg-type" field to RENEW. The client generates 2321 a transaction ID and inserts this value in the "transaction-id" 2322 field. 2323 2324 The client places the identifier of the destination server in a 2325 Server Identifier option. 2326 2327 The client MUST include a Client Identifier option to identify itself 2328 to the server. The client adds any appropriate options, including 2329 one or more IA options. The client MUST include the list of 2330 addresses the client currently has associated with the IAs in the 2331 Renew message. 2332 2333 The client MUST include an Option Request option (see section 22.7) 2334 to indicate the options the client is interested in receiving. The 2335 client MAY include options with data values as hints to the server 2336 about parameter values the client would like to have returned. 2337 2338 The client transmits the message according to section 14, using the 2339 following parameters: 2340 2341 IRT REN_TIMEOUT 2342 2343 MRT REN_MAX_RT 2344 2345 MRC 0 2346 2347 MRD Remaining time until T2 2348 2349 2350 2351 2352 2353 2354Droms, et al. Standards Track [Page 42] 2355 2356RFC 3315 DHCP for IPv6 July 2003 2357 2358 2359 The message exchange is terminated when time T2 is reached (see 2360 section 18.1.4), at which time the client begins a Rebind message 2361 exchange. 2362 236318.1.4. Creation and Transmission of Rebind Messages 2364 2365 At time T2 for an IA (which will only be reached if the server to 2366 which the Renew message was sent at time T1 has not responded), the 2367 client initiates a Rebind/Reply message exchange with any available 2368 server. The client includes an IA option with all addresses 2369 currently assigned to the IA in its Rebind message. 2370 2371 The client sets the "msg-type" field to REBIND. The client generates 2372 a transaction ID and inserts this value in the "transaction-id" 2373 field. 2374 2375 The client MUST include a Client Identifier option to identify itself 2376 to the server. The client adds any appropriate options, including 2377 one or more IA options. The client MUST include the list of 2378 addresses the client currently has associated with the IAs in the 2379 Rebind message. 2380 2381 The client MUST include an Option Request option (see section 22.7) 2382 to indicate the options the client is interested in receiving. The 2383 client MAY include options with data values as hints to the server 2384 about parameter values the client would like to have returned. 2385 2386 The client transmits the message according to section 14, using the 2387 following parameters: 2388 2389 IRT REB_TIMEOUT 2390 2391 MRT REB_MAX_RT 2392 2393 MRC 0 2394 2395 MRD Remaining time until valid lifetimes of all addresses have 2396 expired 2397 2398 The message exchange is terminated when the valid lifetimes of all 2399 the addresses assigned to the IA expire (see section 10), at which 2400 time the client has several alternative actions to choose from; for 2401 example: 2402 2403 - The client may choose to use a Solicit message to locate a new 2404 DHCP server and send a Request for the expired IA to the new 2405 server. 2406 2407 2408 2409 2410Droms, et al. Standards Track [Page 43] 2411 2412RFC 3315 DHCP for IPv6 July 2003 2413 2414 2415 - The client may have other addresses in other IAs, so the client 2416 may choose to discard the expired IA and use the addresses in the 2417 other IAs. 2418 241918.1.5. Creation and Transmission of Information-request Messages 2420 2421 The client uses an Information-request message to obtain 2422 configuration information without having addresses assigned to it. 2423 2424 The client sets the "msg-type" field to INFORMATION-REQUEST. The 2425 client generates a transaction ID and inserts this value in the 2426 "transaction-id" field. 2427 2428 The client SHOULD include a Client Identifier option to identify 2429 itself to the server. If the client does not include a Client 2430 Identifier option, the server will not be able to return any client- 2431 specific options to the client, or the server may choose not to 2432 respond to the message at all. The client MUST include a Client 2433 Identifier option if the Information-Request message will be 2434 authenticated. 2435 2436 The client MUST include an Option Request option (see section 22.7) 2437 to indicate the options the client is interested in receiving. The 2438 client MAY include options with data values as hints to the server 2439 about parameter values the client would like to have returned. 2440 2441 The first Information-request message from the client on the 2442 interface MUST be delayed by a random amount of time between 0 and 2443 INF_MAX_DELAY. The client transmits the message according to section 2444 14, using the following parameters: 2445 2446 IRT INF_TIMEOUT 2447 2448 MRT INF_MAX_RT 2449 2450 MRC 0 2451 2452 MRD 0 2453 245418.1.6. Creation and Transmission of Release Messages 2455 2456 To release one or more addresses, a client sends a Release message to 2457 the server. 2458 2459 The client sets the "msg-type" field to RELEASE. The client 2460 generates a transaction ID and places this value in the 2461 "transaction-id" field. 2462 2463 2464 2465 2466Droms, et al. Standards Track [Page 44] 2467 2468RFC 3315 DHCP for IPv6 July 2003 2469 2470 2471 The client places the identifier of the server that allocated the 2472 address(es) in a Server Identifier option. 2473 2474 The client MUST include a Client Identifier option to identify itself 2475 to the server. The client includes options containing the IAs for 2476 the addresses it is releasing in the "options" field. The addresses 2477 to be released MUST be included in the IAs. Any addresses for the 2478 IAs the client wishes to continue to use MUST NOT be added to the 2479 IAs. 2480 2481 The client MUST NOT use any of the addresses it is releasing as the 2482 source address in the Release message or in any subsequently 2483 transmitted message. 2484 2485 Because Release messages may be lost, the client should retransmit 2486 the Release if no Reply is received. However, there are scenarios 2487 where the client may not wish to wait for the normal retransmission 2488 timeout before giving up (e.g., on power down). Implementations 2489 SHOULD retransmit one or more times, but MAY choose to terminate the 2490 retransmission procedure early. 2491 2492 The client transmits the message according to section 14, using the 2493 following parameters: 2494 2495 IRT REL_TIMEOUT 2496 2497 MRT 0 2498 2499 MRC REL_MAX_RC 2500 2501 MRD 0 2502 2503 The client MUST stop using all of the addresses being released as 2504 soon as the client begins the Release message exchange process. If 2505 addresses are released but the Reply from a DHCP server is lost, the 2506 client will retransmit the Release message, and the server may 2507 respond with a Reply indicating a status of NoBinding. Therefore, 2508 the client does not treat a Reply message with a status of NoBinding 2509 in a Release message exchange as if it indicates an error. 2510 2511 Note that if the client fails to release the addresses, each address 2512 assigned to the IA will be reclaimed by the server when the valid 2513 lifetime of that address expires. 2514 2515 2516 2517 2518 2519 2520 2521 2522Droms, et al. Standards Track [Page 45] 2523 2524RFC 3315 DHCP for IPv6 July 2003 2525 2526 252718.1.7. Creation and Transmission of Decline Messages 2528 2529 If a client detects that one or more addresses assigned to it by a 2530 server are already in use by another node, the client sends a Decline 2531 message to the server to inform it that the address is suspect. 2532 2533 The client sets the "msg-type" field to DECLINE. The client 2534 generates a transaction ID and places this value in the 2535 "transaction-id" field. 2536 2537 The client places the identifier of the server that allocated the 2538 address(es) in a Server Identifier option. 2539 2540 The client MUST include a Client Identifier option to identify itself 2541 to the server. The client includes options containing the IAs for 2542 the addresses it is declining in the "options" field. The addresses 2543 to be declined MUST be included in the IAs. Any addresses for the 2544 IAs the client wishes to continue to use should not be in added to 2545 the IAs. 2546 2547 The client MUST NOT use any of the addresses it is declining as the 2548 source address in the Decline message or in any subsequently 2549 transmitted message. 2550 2551 The client transmits the message according to section 14, using the 2552 following parameters: 2553 2554 IRT DEC_TIMEOUT 2555 2556 MRT 0 2557 2558 MRC DEC_MAX_RC 2559 2560 MRD 0 2561 2562 If addresses are declined but the Reply from a DHCP server is lost, 2563 the client will retransmit the Decline message, and the server may 2564 respond with a Reply indicating a status of NoBinding. Therefore, 2565 the client does not treat a Reply message with a status of NoBinding 2566 in a Decline message exchange as if it indicates an error. 2567 256818.1.8. Receipt of Reply Messages 2569 2570 Upon the receipt of a valid Reply message in response to a Solicit 2571 (with a Rapid Commit option), Request, Confirm, Renew, Rebind or 2572 Information-request message, the client extracts the configuration 2573 2574 2575 2576 2577 2578Droms, et al. Standards Track [Page 46] 2579 2580RFC 3315 DHCP for IPv6 July 2003 2581 2582 2583 information contained in the Reply. The client MAY choose to report 2584 any status code or message from the status code option in the Reply 2585 message. 2586 2587 The client SHOULD perform duplicate address detection [17] on each of 2588 the addresses in any IAs it receives in the Reply message before 2589 using that address for traffic. If any of the addresses are found to 2590 be in use on the link, the client sends a Decline message to the 2591 server as described in section 18.1.7. 2592 2593 If the Reply was received in response to a Solicit (with a Rapid 2594 Commit option), Request, Renew or Rebind message, the client updates 2595 the information it has recorded about IAs from the IA options 2596 contained in the Reply message: 2597 2598 - Record T1 and T2 times. 2599 2600 - Add any new addresses in the IA option to the IA as recorded by 2601 the client. 2602 2603 - Update lifetimes for any addresses in the IA option that the 2604 client already has recorded in the IA. 2605 2606 - Discard any addresses from the IA, as recorded by the client, that 2607 have a valid lifetime of 0 in the IA Address option. 2608 2609 - Leave unchanged any information about addresses the client has 2610 recorded in the IA but that were not included in the IA from the 2611 server. 2612 2613 Management of the specific configuration information is detailed in 2614 the definition of each option in section 22. 2615 2616 If the client receives a Reply message with a Status Code containing 2617 UnspecFail, the server is indicating that it was unable to process 2618 the message due to an unspecified failure condition. If the client 2619 retransmits the original message to the same server to retry the 2620 desired operation, the client MUST limit the rate at which it 2621 retransmits the message and limit the duration of the time during 2622 which it retransmits the message. 2623 2624 When the client receives a Reply message with a Status Code option 2625 with the value UseMulticast, the client records the receipt of the 2626 message and sends subsequent messages to the server through the 2627 interface on which the message was received using multicast. The 2628 client resends the original message using multicast. 2629 2630 2631 2632 2633 2634Droms, et al. Standards Track [Page 47] 2635 2636RFC 3315 DHCP for IPv6 July 2003 2637 2638 2639 When the client receives a NotOnLink status from the server in 2640 response to a Confirm message, the client performs DHCP server 2641 solicitation, as described in section 17, and client-initiated 2642 configuration as described in section 18. If the client receives any 2643 Reply messages that do not indicate a NotOnLink status, the client 2644 can use the addresses in the IA and ignore any messages that indicate 2645 a NotOnLink status. 2646 2647 When the client receives a NotOnLink status from the server in 2648 response to a Request, the client can either re-issue the Request 2649 without specifying any addresses or restart the DHCP server discovery 2650 process (see section 17). 2651 2652 The client examines the status code in each IA individually. If the 2653 status code is NoAddrsAvail, the client has received no usable 2654 addresses in the IA and may choose to try obtaining addresses for the 2655 IA from another server. The client uses addresses and other 2656 information from any IAs that do not contain a Status Code option 2657 with the NoAddrsAvail code. If the client receives no addresses in 2658 any of the IAs, it may either try another server (perhaps restarting 2659 the DHCP server discovery process) or use the Information-request 2660 message to obtain other configuration information only. 2661 2662 When the client receives a Reply message in response to a Renew or 2663 Rebind message, the client examines each IA independently. For each 2664 IA in the original Renew or Rebind message, the client: 2665 2666 - sends a Request message if the IA contained a Status Code option 2667 with the NoBinding status (and does not send any additional 2668 Renew/Rebind messages) 2669 2670 - sends a Renew/Rebind if the IA is not in the Reply message 2671 2672 - otherwise accepts the information in the IA 2673 2674 When the client receives a valid Reply message in response to a 2675 Release message, the client considers the Release event completed, 2676 regardless of the Status Code option(s) returned by the server. 2677 2678 When the client receives a valid Reply message in response to a 2679 Decline message, the client considers the Decline event completed, 2680 regardless of the Status Code option(s) returned by the server. 2681 268218.2. Server Behavior 2683 2684 For this discussion, the Server is assumed to have been configured in 2685 an implementation specific manner with configuration of interest to 2686 clients. 2687 2688 2689 2690Droms, et al. Standards Track [Page 48] 2691 2692RFC 3315 DHCP for IPv6 July 2003 2693 2694 2695 In most instances, the server will send a Reply in response to a 2696 client message. This Reply message MUST always contain the Server 2697 Identifier option containing the server's DUID and the Client 2698 Identifier option from the client message if one was present. 2699 2700 In most Reply messages, the server includes options containing 2701 configuration information for the client. The server must be aware 2702 of the recommendations on packet sizes and the use of fragmentation 2703 in section 5 of RFC 2460. If the client included an Option Request 2704 option in its message, the server includes options in the Reply 2705 message containing configuration parameters for all of the options 2706 identified in the Option Request option that the server has been 2707 configured to return to the client. The server MAY return additional 2708 options to the client if it has been configured to do so. 2709 271018.2.1. Receipt of Request Messages 2711 2712 When the server receives a Request message via unicast from a client 2713 to which the server has not sent a unicast option, the server 2714 discards the Request message and responds with a Reply message 2715 containing a Status Code option with the value UseMulticast, a Server 2716 Identifier option containing the server's DUID, the Client Identifier 2717 option from the client message, and no other options. 2718 2719 When the server receives a valid Request message, the server creates 2720 the bindings for that client according to the server's policy and 2721 configuration information and records the IAs and other information 2722 requested by the client. 2723 2724 The server constructs a Reply message by setting the "msg-type" field 2725 to REPLY, and copying the transaction ID from the Request message 2726 into the transaction-id field. 2727 2728 The server MUST include a Server Identifier option containing the 2729 server's DUID and the Client Identifier option from the Request 2730 message in the Reply message. 2731 2732 If the server finds that the prefix on one or more IP addresses in 2733 any IA in the message from the client is not appropriate for the link 2734 to which the client is connected, the server MUST return the IA to 2735 the client with a Status Code option with the value NotOnLink. 2736 2737 If the server cannot assign any addresses to an IA in the message 2738 from the client, the server MUST include the IA in the Reply message 2739 with no addresses in the IA and a Status Code option in the IA 2740 containing status code NoAddrsAvail. 2741 2742 2743 2744 2745 2746Droms, et al. Standards Track [Page 49] 2747 2748RFC 3315 DHCP for IPv6 July 2003 2749 2750 2751 For any IAs to which the server can assign addresses, the server 2752 includes the IA with addresses and other configuration parameters, 2753 and records the IA as a new client binding. 2754 2755 The server includes a Reconfigure Accept option if the server wants 2756 to require that the client accept Reconfigure messages. 2757 2758 The server includes other options containing configuration 2759 information to be returned to the client as described in section 2760 18.2. 2761 2762 If the server finds that the client has included an IA in the Request 2763 message for which the server already has a binding that associates 2764 the IA with the client, the client has resent a Request message for 2765 which it did not receive a Reply message. The server either resends 2766 a previously cached Reply message or sends a new Reply message. 2767 276818.2.2. Receipt of Confirm Messages 2769 2770 When the server receives a Confirm message, the server determines 2771 whether the addresses in the Confirm message are appropriate for the 2772 link to which the client is attached. If all of the addresses in the 2773 Confirm message pass this test, the server returns a status of 2774 Success. If any of the addresses do not pass this test, the server 2775 returns a status of NotOnLink. If the server is unable to perform 2776 this test (for example, the server does not have information about 2777 prefixes on the link to which the client is connected), or there were 2778 no addresses in any of the IAs sent by the client, the server MUST 2779 NOT send a reply to the client. 2780 2781 The server ignores the T1 and T2 fields in the IA options and the 2782 preferred-lifetime and valid-lifetime fields in the IA Address 2783 options. 2784 2785 The server constructs a Reply message by setting the "msg-type" field 2786 to REPLY, and copying the transaction ID from the Confirm message 2787 into the transaction-id field. 2788 2789 The server MUST include a Server Identifier option containing the 2790 server's DUID and the Client Identifier option from the Confirm 2791 message in the Reply message. The server includes a Status Code 2792 option indicating the status of the Confirm message. 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802Droms, et al. Standards Track [Page 50] 2803 2804RFC 3315 DHCP for IPv6 July 2003 2805 2806 280718.2.3. Receipt of Renew Messages 2808 2809 When the server receives a Renew message via unicast from a client to 2810 which the server has not sent a unicast option, the server discards 2811 the Renew message and responds with a Reply message containing a 2812 Status Code option with the value UseMulticast, a Server Identifier 2813 option containing the server's DUID, the Client Identifier option 2814 from the client message, and no other options. 2815 2816 When the server receives a Renew message that contains an IA option 2817 from a client, it locates the client's binding and verifies that the 2818 information in the IA from the client matches the information stored 2819 for that client. 2820 2821 If the server cannot find a client entry for the IA the server 2822 returns the IA containing no addresses with a Status Code option set 2823 to NoBinding in the Reply message. 2824 2825 If the server finds that any of the addresses are not appropriate for 2826 the link to which the client is attached, the server returns the 2827 address to the client with lifetimes of 0. 2828 2829 If the server finds the addresses in the IA for the client then the 2830 server sends back the IA to the client with new lifetimes and T1/T2 2831 times. The server may choose to change the list of addresses and the 2832 lifetimes of addresses in IAs that are returned to the client. 2833 2834 The server constructs a Reply message by setting the "msg-type" field 2835 to REPLY, and copying the transaction ID from the Renew message into 2836 the transaction-id field. 2837 2838 The server MUST include a Server Identifier option containing the 2839 server's DUID and the Client Identifier option from the Renew message 2840 in the Reply message. 2841 2842 The server includes other options containing configuration 2843 information to be returned to the client as described in section 2844 18.2. 2845 284618.2.4. Receipt of Rebind Messages 2847 2848 When the server receives a Rebind message that contains an IA option 2849 from a client, it locates the client's binding and verifies that the 2850 information in the IA from the client matches the information stored 2851 for that client. 2852 2853 2854 2855 2856 2857 2858Droms, et al. Standards Track [Page 51] 2859 2860RFC 3315 DHCP for IPv6 July 2003 2861 2862 2863 If the server cannot find a client entry for the IA and the server 2864 determines that the addresses in the IA are not appropriate for the 2865 link to which the client's interface is attached according to the 2866 server's explicit configuration information, the server MAY send a 2867 Reply message to the client containing the client's IA, with the 2868 lifetimes for the addresses in the IA set to zero. This Reply 2869 constitutes an explicit notification to the client that the addresses 2870 in the IA are no longer valid. In this situation, if the server does 2871 not send a Reply message it silently discards the Rebind message. 2872 2873 If the server finds that any of the addresses are no longer 2874 appropriate for the link to which the client is attached, the server 2875 returns the address to the client with lifetimes of 0. 2876 2877 If the server finds the addresses in the IA for the client then the 2878 server SHOULD send back the IA to the client with new lifetimes and 2879 T1/T2 times. 2880 2881 The server constructs a Reply message by setting the "msg-type" field 2882 to REPLY, and copying the transaction ID from the Rebind message into 2883 the transaction-id field. 2884 2885 The server MUST include a Server Identifier option containing the 2886 server's DUID and the Client Identifier option from the Rebind 2887 message in the Reply message. 2888 2889 The server includes other options containing configuration 2890 information to be returned to the client as described in section 2891 18.2. 2892 289318.2.5. Receipt of Information-request Messages 2894 2895 When the server receives an Information-request message, the client 2896 is requesting configuration information that does not include the 2897 assignment of any addresses. The server determines all configuration 2898 parameters appropriate to the client, based on the server 2899 configuration policies known to the server. 2900 2901 The server constructs a Reply message by setting the "msg-type" field 2902 to REPLY, and copying the transaction ID from the Information-request 2903 message into the transaction-id field. 2904 2905 The server MUST include a Server Identifier option containing the 2906 server's DUID in the Reply message. If the client included a Client 2907 Identification option in the Information-request message, the server 2908 copies that option to the Reply message. 2909 2910 2911 2912 2913 2914Droms, et al. Standards Track [Page 52] 2915 2916RFC 3315 DHCP for IPv6 July 2003 2917 2918 2919 The server includes options containing configuration information to 2920 be returned to the client as described in section 18.2. 2921 2922 If the Information-request message received from the client did not 2923 include a Client Identifier option, the server SHOULD respond with a 2924 Reply message containing any configuration parameters that are not 2925 determined by the client's identity. If the server chooses not to 2926 respond, the client may continue to retransmit the 2927 Information-request message indefinitely. 2928 292918.2.6. Receipt of Release Messages 2930 2931 When the server receives a Release message via unicast from a client 2932 to which the server has not sent a unicast option, the server 2933 discards the Release message and responds with a Reply message 2934 containing a Status Code option with value UseMulticast, a Server 2935 Identifier option containing the server's DUID, the Client Identifier 2936 option from the client message, and no other options. 2937 2938 Upon the receipt of a valid Release message, the server examines the 2939 IAs and the addresses in the IAs for validity. If the IAs in the 2940 message are in a binding for the client, and the addresses in the IAs 2941 have been assigned by the server to those IAs, the server deletes the 2942 addresses from the IAs and makes the addresses available for 2943 assignment to other clients. The server ignores addresses not 2944 assigned to the IA, although it may choose to log an error. 2945 2946 After all the addresses have been processed, the server generates a 2947 Reply message and includes a Status Code option with value Success, a 2948 Server Identifier option with the server's DUID, and a Client 2949 Identifier option with the client's DUID. For each IA in the Release 2950 message for which the server has no binding information, the server 2951 adds an IA option using the IAID from the Release message, and 2952 includes a Status Code option with the value NoBinding in the IA 2953 option. No other options are included in the IA option. 2954 2955 A server may choose to retain a record of assigned addresses and IAs 2956 after the lifetimes on the addresses have expired to allow the server 2957 to reassign the previously assigned addresses to a client. 2958 295918.2.7. Receipt of Decline Messages 2960 2961 When the server receives a Decline message via unicast from a client 2962 to which the server has not sent a unicast option, the server 2963 discards the Decline message and responds with a Reply message 2964 containing a Status Code option with the value UseMulticast, a Server 2965 Identifier option containing the server's DUID, the Client Identifier 2966 option from the client message, and no other options. 2967 2968 2969 2970Droms, et al. Standards Track [Page 53] 2971 2972RFC 3315 DHCP for IPv6 July 2003 2973 2974 2975 Upon the receipt of a valid Decline message, the server examines the 2976 IAs and the addresses in the IAs for validity. If the IAs in the 2977 message are in a binding for the client, and the addresses in the IAs 2978 have been assigned by the server to those IAs, the server deletes the 2979 addresses from the IAs. The server ignores addresses not assigned to 2980 the IA (though it may choose to log an error if it finds such an 2981 address). 2982 2983 The client has found any addresses in the Decline messages to be 2984 already in use on its link. Therefore, the server SHOULD mark the 2985 addresses declined by the client so that those addresses are not 2986 assigned to other clients, and MAY choose to make a notification that 2987 addresses were declined. Local policy on the server determines when 2988 the addresses identified in a Decline message may be made available 2989 for assignment. 2990 2991 After all the addresses have been processed, the server generates a 2992 Reply message and includes a Status Code option with the value 2993 Success, a Server Identifier option with the server's DUID, and a 2994 Client Identifier option with the client's DUID. For each IA in the 2995 Decline message for which the server has no binding information, the 2996 server adds an IA option using the IAID from the Release message and 2997 includes a Status Code option with the value NoBinding in the IA 2998 option. No other options are included in the IA option. 2999 300018.2.8. Transmission of Reply Messages 3001 3002 If the original message was received directly by the server, the 3003 server unicasts the Reply message directly to the client using the 3004 address in the source address field from the IP datagram in which the 3005 original message was received. The Reply message MUST be unicast 3006 through the interface on which the original message was received. 3007 3008 If the original message was received in a Relay-forward message, the 3009 server constructs a Relay-reply message with the Reply message in the 3010 payload of a Relay Message option (see section 22.10). If the 3011 Relay-forward messages included an Interface-id option, the server 3012 copies that option to the Relay-reply message. The server unicasts 3013 the Relay-reply message directly to the relay agent using the address 3014 in the source address field from the IP datagram in which the 3015 Relay-forward message was received. 3016 301719. DHCP Server-Initiated Configuration Exchange 3018 3019 A server initiates a configuration exchange to cause DHCP clients to 3020 obtain new addresses and other configuration information. For 3021 example, an administrator may use a server-initiated configuration 3022 exchange when links in the DHCP domain are to be renumbered. Other 3023 3024 3025 3026Droms, et al. Standards Track [Page 54] 3027 3028RFC 3315 DHCP for IPv6 July 2003 3029 3030 3031 examples include changes in the location of directory servers, 3032 addition of new services such as printing, and availability of new 3033 software. 3034 303519.1. Server Behavior 3036 3037 A server sends a Reconfigure message to cause a client to initiate 3038 immediately a Renew/Reply or Information-request/Reply message 3039 exchange with the server. 3040 304119.1.1. Creation and Transmission of Reconfigure Messages 3042 3043 The server sets the "msg-type" field to RECONFIGURE. The server sets 3044 the transaction-id field to 0. The server includes a Server 3045 Identifier option containing its DUID and a Client Identifier option 3046 containing the client's DUID in the Reconfigure message. 3047 3048 The server MAY include an Option Request option to inform the client 3049 of what information has been changed or new information that has been 3050 added. In particular, the server specifies the IA option in the 3051 Option Request option if the server wants the client to obtain new 3052 address information. If the server identifies the IA option in the 3053 Option Request option, the server MUST include an IA option that 3054 contains no other sub-options to identify each IA that is to be 3055 reconfigured on the client. 3056 3057 Because of the risk of denial of service attacks against DHCP 3058 clients, the use of a security mechanism is mandated in Reconfigure 3059 messages. The server MUST use DHCP authentication in the Reconfigure 3060 message. 3061 3062 The server MUST include a Reconfigure Message option (defined in 3063 section 22.19) to select whether the client responds with a Renew 3064 message or an Information-Request message. 3065 3066 The server MUST NOT include any other options in the Reconfigure 3067 except as specifically allowed in the definition of individual 3068 options. 3069 3070 A server sends each Reconfigure message to a single DHCP client, 3071 using an IPv6 unicast address of sufficient scope belonging to the 3072 DHCP client. If the server does not have an address to which it can 3073 send the Reconfigure message directly to the client, the server uses 3074 a Relay-reply message (as described in section 20.3) to send the 3075 Reconfigure message to a relay agent that will relay the message to 3076 the client. The server may obtain the address of the client (and the 3077 3078 3079 3080 3081 3082Droms, et al. Standards Track [Page 55] 3083 3084RFC 3315 DHCP for IPv6 July 2003 3085 3086 3087 appropriate relay agent, if required) through the information the 3088 server has about clients that have been in contact with the server, 3089 or through some external agent. 3090 3091 To reconfigure more than one client, the server unicasts a separate 3092 message to each client. The server may initiate the reconfiguration 3093 of multiple clients concurrently; for example, a server may send a 3094 Reconfigure message to additional clients while previous 3095 reconfiguration message exchanges are still in progress. 3096 3097 The Reconfigure message causes the client to initiate a Renew/Reply 3098 or Information-request/Reply message exchange with the server. The 3099 server interprets the receipt of a Renew or Information-request 3100 message (whichever was specified in the original Reconfigure message) 3101 from the client as satisfying the Reconfigure message request. 3102 310319.1.2. Time Out and Retransmission of Reconfigure Messages 3104 3105 If the server does not receive a Renew or Information-request message 3106 from the client in REC_TIMEOUT milliseconds, the server retransmits 3107 the Reconfigure message, doubles the REC_TIMEOUT value and waits 3108 again. The server continues this process until REC_MAX_RC 3109 unsuccessful attempts have been made, at which point the server 3110 SHOULD abort the reconfigure process for that client. 3111 3112 Default and initial values for REC_TIMEOUT and REC_MAX_RC are 3113 documented in section 5.5. 3114 311519.2. Receipt of Renew Messages 3116 3117 The server generates and sends a Reply message to the client as 3118 described in sections 18.2.3 and 18.2.8, including options for 3119 configuration parameters. 3120 3121 The server MAY include options containing the IAs and new values for 3122 other configuration parameters in the Reply message, even if those 3123 IAs and parameters were not requested in the Renew message from the 3124 client. 3125 312619.3. Receipt of Information-request Messages 3127 3128 The server generates and sends a Reply message to the client as 3129 described in sections 18.2.5 and 18.2.8, including options for 3130 configuration parameters. 3131 3132 3133 3134 3135 3136 3137 3138Droms, et al. Standards Track [Page 56] 3139 3140RFC 3315 DHCP for IPv6 July 2003 3141 3142 3143 The server MAY include options containing new values for other 3144 configuration parameters in the Reply message, even if those 3145 parameters were not requested in the Information-request message from 3146 the client. 3147 314819.4. Client Behavior 3149 3150 A client receives Reconfigure messages sent to the UDP port 546 on 3151 interfaces for which it has acquired configuration information 3152 through DHCP. These messages may be sent at any time. Since the 3153 results of a reconfiguration event may affect application layer 3154 programs, the client SHOULD log these events, and MAY notify these 3155 programs of the change through an implementation-specific interface. 3156 315719.4.1. Receipt of Reconfigure Messages 3158 3159 Upon receipt of a valid Reconfigure message, the client responds with 3160 either a Renew message or an Information-request message as indicated 3161 by the Reconfigure Message option (as defined in section 22.19). The 3162 client ignores the transaction-id field in the received Reconfigure 3163 message. While the transaction is in progress, the client silently 3164 discards any Reconfigure messages it receives. 3165 3166 DISCUSSION: 3167 3168 The Reconfigure message acts as a trigger that signals the client 3169 to complete a successful message exchange. Once the client has 3170 received a Reconfigure, the client proceeds with the message 3171 exchange (retransmitting the Renew or Information-request message 3172 if necessary); the client ignores any additional Reconfigure 3173 messages until the exchange is complete. Subsequent Reconfigure 3174 messages cause the client to initiate a new exchange. 3175 3176 How does this mechanism work in the face of duplicated or 3177 retransmitted Reconfigure messages? Duplicate messages will be 3178 ignored because the client will begin the exchange after the 3179 receipt of the first Reconfigure. Retransmitted messages will 3180 either trigger the exchange (if the first Reconfigure was not 3181 received by the client) or will be ignored. The server can 3182 discontinue retransmission of Reconfigure messages to the client 3183 once the server receives the Renew or Information-request message 3184 from the client. 3185 3186 It might be possible for a duplicate or retransmitted Reconfigure 3187 to be sufficiently delayed (and delivered out of order) to arrive 3188 at the client after the exchange (initiated by the original 3189 Reconfigure) has been completed. In this case, the client would 3190 initiate a redundant exchange. The likelihood of delayed and out 3191 3192 3193 3194Droms, et al. Standards Track [Page 57] 3195 3196RFC 3315 DHCP for IPv6 July 2003 3197 3198 3199 of order delivery is small enough to be ignored. The consequence 3200 of the redundant exchange is inefficiency rather than incorrect 3201 operation. 3202 320319.4.2. Creation and Transmission of Renew Messages 3204 3205 When responding to a Reconfigure, the client creates and sends the 3206 Renew message in exactly the same manner as outlined in section 3207 18.1.3, with the exception that the client copies the Option Request 3208 option and any IA options from the Reconfigure message into the Renew 3209 message. 3210 321119.4.3. Creation and Transmission of Information-request Messages 3212 3213 When responding to a Reconfigure, the client creates and sends the 3214 Information-request message in exactly the same manner as outlined in 3215 section 18.1.5, with the exception that the client includes a Server 3216 Identifier option with the identifier from the Reconfigure message to 3217 which the client is responding. 3218 321919.4.4. Time Out and Retransmission of Renew or Information-request 3220 Messages 3221 3222 The client uses the same variables and retransmission algorithm as it 3223 does with Renew or Information-request messages generated as part of 3224 a client-initiated configuration exchange. See sections 18.1.3 and 3225 18.1.5 for details. If the client does not receive a response from 3226 the server by the end of the retransmission process, the client 3227 ignores and discards the Reconfigure message. 3228 322919.4.5. Receipt of Reply Messages 3230 3231 Upon the receipt of a valid Reply message, the client processes the 3232 options and sets (or resets) configuration parameters appropriately. 3233 The client records and updates the lifetimes for any addresses 3234 specified in IAs in the Reply message. 3235 323620. Relay Agent Behavior 3237 3238 The relay agent MAY be configured to use a list of destination 3239 addresses, which MAY include unicast addresses, the All_DHCP_Servers 3240 multicast address, or other addresses selected by the network 3241 administrator. If the relay agent has not been explicitly 3242 configured, it MUST use the All_DHCP_Servers multicast address as the 3243 default. 3244 3245 3246 3247 3248 3249 3250Droms, et al. Standards Track [Page 58] 3251 3252RFC 3315 DHCP for IPv6 July 2003 3253 3254 3255 If the relay agent relays messages to the All_DHCP_Servers multicast 3256 address or other multicast addresses, it sets the Hop Limit field to 3257 32. 3258 325920.1. Relaying a Client Message or a Relay-forward Message 3260 3261 A relay agent relays both messages from clients and Relay-forward 3262 messages from other relay agents. When a relay agent receives a 3263 valid message to be relayed, it constructs a new Relay-forward 3264 message. The relay agent copies the source address from the header 3265 of the IP datagram in which the message was received to the 3266 peer-address field of the Relay-forward message. The relay agent 3267 copies the received DHCP message (excluding any IP or UDP headers) 3268 into a Relay Message option in the new message. The relay agent adds 3269 to the Relay-forward message any other options it is configured to 3270 include. 3271 327220.1.1. Relaying a Message from a Client 3273 3274 If the relay agent received the message to be relayed from a client, 3275 the relay agent places a global or site-scoped address with a prefix 3276 assigned to the link on which the client should be assigned an 3277 address in the link-address field. This address will be used by the 3278 server to determine the link from which the client should be assigned 3279 an address and other configuration information. The hop-count in the 3280 Relay-forward message is set to 0. 3281 3282 If the relay agent cannot use the address in the link-address field 3283 to identify the interface through which the response to the client 3284 will be relayed, the relay agent MUST include an Interface-id option 3285 (see section 22.18) in the Relay-forward message. The server will 3286 include the Interface-id option in its Relay-reply message. The 3287 relay agent fills in the link-address field as described in the 3288 previous paragraph regardless of whether the relay agent includes an 3289 Interface-id option in the Relay-forward message. 3290 329120.1.2. Relaying a Message from a Relay Agent 3292 3293 If the message received by the relay agent is a Relay-forward message 3294 and the hop-count in the message is greater than or equal to 3295 HOP_COUNT_LIMIT, the relay agent discards the received message. 3296 3297 The relay agent copies the source address from the IP datagram in 3298 which the message was received from the client into the peer-address 3299 field in the Relay-forward message and sets the hop-count field to 3300 the value of the hop-count field in the received message incremented 3301 by 1. 3302 3303 3304 3305 3306Droms, et al. Standards Track [Page 59] 3307 3308RFC 3315 DHCP for IPv6 July 2003 3309 3310 3311 If the source address from the IP datagram header of the received 3312 message is a global or site-local address (and the device on which 3313 the relay agent is running belongs to only one site), the relay agent 3314 sets the link-address field to 0; otherwise the relay agent sets the 3315 link-address field to a global or site-local address assigned to the 3316 interface on which the message was received, or includes an 3317 Interface-ID option to identify the interface on which the message 3318 was received. 3319 332020.2. Relaying a Relay-reply Message 3321 3322 The relay agent processes any options included in the Relay-reply 3323 message in addition to the Relay Message option, and then discards 3324 those options. 3325 3326 The relay agent extracts the message from the Relay Message option 3327 and relays it to the address contained in the peer-address field of 3328 the Relay-reply message. 3329 3330 If the Relay-reply message includes an Interface-id option, the relay 3331 agent relays the message from the server to the client on the link 3332 identified by the Interface-id option. Otherwise, if the 3333 link-address field is not set to zero, the relay agent relays the 3334 message on the link identified by the link-address field. 3335 333620.3. Construction of Relay-reply Messages 3337 3338 A server uses a Relay-reply message to return a response to a client 3339 if the original message from the client was relayed to the server in 3340 a Relay-forward message or to send a Reconfigure message to a client 3341 if the server does not have an address it can use to send the message 3342 directly to the client. 3343 3344 A response to the client MUST be relayed through the same relay 3345 agents as the original client message. The server causes this to 3346 happen by creating a Relay-reply message that includes a Relay 3347 Message option containing the message for the next relay agent in the 3348 return path to the client. The contained Relay-reply message 3349 contains another Relay Message option to be sent to the next relay 3350 agent, and so on. The server must record the contents of the 3351 peer-address fields in the received message so it can construct the 3352 appropriate Relay-reply message carrying the response from the 3353 server. 3354 3355 3356 3357 3358 3359 3360 3361 3362Droms, et al. Standards Track [Page 60] 3363 3364RFC 3315 DHCP for IPv6 July 2003 3365 3366 3367 For example, if client C sent a message that was relayed by relay 3368 agent A to relay agent B and then to the server, the server would 3369 send the following Relay-Reply message to relay agent B: 3370 3371 msg-type: RELAY-REPLY 3372 hop-count: 1 3373 link-address: 0 3374 peer-address: A 3375 Relay Message option, containing: 3376 msg-type: RELAY-REPLY 3377 hop-count: 0 3378 link-address: address from link to which C is attached 3379 peer-address: C 3380 Relay Message option: <response from server> 3381 3382 When sending a Reconfigure message to a client through a relay agent, 3383 the server creates a Relay-reply message that includes a Relay 3384 Message option containing the Reconfigure message for the next relay 3385 agent in the return path to the client. The server sets the 3386 peer-address field in the Relay-reply message header to the address 3387 of the client, and sets the link-address field as required by the 3388 relay agent to relay the Reconfigure message to the client. The 3389 server obtains the addresses of the client and the relay agent 3390 through prior interaction with the client or through some external 3391 mechanism. 3392 339321. Authentication of DHCP Messages 3394 3395 Some network administrators may wish to provide authentication of the 3396 source and contents of DHCP messages. For example, clients may be 3397 subject to denial of service attacks through the use of bogus DHCP 3398 servers, or may simply be misconfigured due to unintentionally 3399 instantiated DHCP servers. Network administrators may wish to 3400 constrain the allocation of addresses to authorized hosts to avoid 3401 denial of service attacks in "hostile" environments where the network 3402 medium is not physically secured, such as wireless networks or 3403 college residence halls. 3404 3405 The DHCP authentication mechanism is based on the design of 3406 authentication for DHCPv4 [4]. 3407 340821.1. Security of Messages Sent Between Servers and Relay Agents 3409 3410 Relay agents and servers that exchange messages securely use the 3411 IPsec mechanisms for IPv6 [7]. If a client message is relayed 3412 through multiple relay agents, each of the relay agents must have 3413 established independent, pairwise trust relationships. That is, if 3414 messages from client C will be relayed by relay agent A to relay 3415 3416 3417 3418Droms, et al. Standards Track [Page 61] 3419 3420RFC 3315 DHCP for IPv6 July 2003 3421 3422 3423 agent B and then to the server, relay agents A and B must be 3424 configured to use IPSec for the messages they exchange, and relay 3425 agent B and the server must be configured to use IPSec for the 3426 messages they exchange. 3427 3428 Relay agents and servers that support secure relay agent to server or 3429 relay agent to relay agent communication use IPsec under the 3430 following conditions: 3431 3432 Selectors Relay agents are manually configured with the 3433 addresses of the relay agent or server to which 3434 DHCP messages are to be forwarded. Each relay 3435 agent and server that will be using IPsec for 3436 securing DHCP messages must also be configured 3437 with a list of the relay agents to which messages 3438 will be returned. The selectors for the relay 3439 agents and servers will be the pairs of addresses 3440 defining relay agents and servers that exchange 3441 DHCP messages on the DHCPv6 UDP ports 546 and 3442 547. 3443 3444 Mode Relay agents and servers use transport mode and 3445 ESP. The information in DHCP messages is not 3446 generally considered confidential, so encryption 3447 need not be used (i.e., NULL encryption can be 3448 used). 3449 3450 Key management Because the relay agents and servers are used 3451 within an organization, public key schemes are 3452 not necessary. Because the relay agents and 3453 servers must be manually configured, manually 3454 configured key management may suffice, but does 3455 not provide defense against replayed messages. 3456 Accordingly, IKE with preshared secrets SHOULD be 3457 supported. IKE with public keys MAY be 3458 supported. 3459 3460 Security policy DHCP messages between relay agents and servers 3461 should only be accepted from DHCP peers as 3462 identified in the local configuration. 3463 3464 Authentication Shared keys, indexed to the source IP address of 3465 the received DHCP message, are adequate in this 3466 application. 3467 3468 Availability Appropriate IPsec implementations are likely to 3469 be available for servers and for relay agents in 3470 more featureful devices used in enterprise and 3471 3472 3473 3474Droms, et al. Standards Track [Page 62] 3475 3476RFC 3315 DHCP for IPv6 July 2003 3477 3478 3479 core ISP networks. IPsec is less likely to be 3480 available for relay agents in low end devices 3481 primarily used in the home or small office 3482 markets. 3483 348421.2. Summary of DHCP Authentication 3485 3486 Authentication of DHCP messages is accomplished through the use of 3487 the Authentication option (see section 22.11). The authentication 3488 information carried in the Authentication option can be used to 3489 reliably identify the source of a DHCP message and to confirm that 3490 the contents of the DHCP message have not been tampered with. 3491 3492 The Authentication option provides a framework for multiple 3493 authentication protocols. Two such protocols are defined here. 3494 Other protocols defined in the future will be specified in separate 3495 documents. 3496 3497 Any DHCP message MUST NOT include more than one Authentication 3498 option. 3499 3500 The protocol field in the Authentication option identifies the 3501 specific protocol used to generate the authentication information 3502 carried in the option. The algorithm field identifies a specific 3503 algorithm within the authentication protocol; for example, the 3504 algorithm field specifies the hash algorithm used to generate the 3505 message authentication code (MAC) in the authentication option. The 3506 replay detection method (RDM) field specifies the type of replay 3507 detection used in the replay detection field. 3508 350921.3. Replay Detection 3510 3511 The Replay Detection Method (RDM) field determines the type of replay 3512 detection used in the Replay Detection field. 3513 3514 If the RDM field contains 0x00, the replay detection field MUST be 3515 set to the value of a monotonically increasing counter. Using a 3516 counter value, such as the current time of day (for example, an NTP- 3517 format timestamp [9]), can reduce the danger of replay attacks. This 3518 method MUST be supported by all protocols. 3519 352021.4. Delayed Authentication Protocol 3521 3522 If the protocol field is 2, the message is using the "delayed 3523 authentication" mechanism. In delayed authentication, the client 3524 requests authentication in its Solicit message, and the server 3525 replies with an Advertise message that includes authentication 3526 3527 3528 3529 3530Droms, et al. Standards Track [Page 63] 3531 3532RFC 3315 DHCP for IPv6 July 2003 3533 3534 3535 information. This authentication information contains a nonce value 3536 generated by the source as a message authentication code (MAC) to 3537 provide message authentication and entity authentication. 3538 3539 The use of a particular technique based on the HMAC protocol [8] 3540 using the MD5 hash [16] is defined here. 3541 354221.4.1. Use of the Authentication Option in the Delayed Authentication 3543 Protocol 3544 3545 In a Solicit message, the client fills in the protocol, algorithm and 3546 RDM fields in the Authentication option with the client's 3547 preferences. The client sets the replay detection field to zero and 3548 omits the authentication information field. The client sets the 3549 option-len field to 11. 3550 3551 In all other messages, the protocol and algorithm fields identify the 3552 method used to construct the contents of the authentication 3553 information field. The RDM field identifies the method used to 3554 construct the contents of the replay detection field. 3555 3556 The format of the Authentication information is: 3557 3558 0 1 2 3 3559 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 3560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3561 | DHCP realm | 3562 | (variable length) | 3563 . . 3564 . . 3565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3566 | key ID | 3567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3568 | | 3569 | HMAC-MD5 | 3570 | (128 bits) | 3571 | | 3572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3573 3574 DHCP realm The DHCP realm that identifies the key used to 3575 generate the HMAC-MD5 value. 3576 3577 key ID The key identifier that identified the key used to 3578 generate the HMAC-MD5 value. 3579 3580 HMAC-MD5 The message authentication code generated by applying 3581 MD5 to the DHCP message using the key identified by 3582 the DHCP realm, client DUID, and key ID. 3583 3584 3585 3586Droms, et al. Standards Track [Page 64] 3587 3588RFC 3315 DHCP for IPv6 July 2003 3589 3590 3591 The sender computes the MAC using the HMAC generation algorithm [8] 3592 and the MD5 hash function [16]. The entire DHCP message (setting the 3593 MAC field of the authentication option to zero), including the DHCP 3594 message header and the options field, is used as input to the HMAC- 3595 MD5 computation function. 3596 3597 DISCUSSION: 3598 3599 Algorithm 1 specifies the use of HMAC-MD5. Use of a different 3600 technique, such as HMAC-SHA, will be specified as a separate 3601 protocol. 3602 3603 The DHCP realm used to identify authentication keys is chosen to 3604 be unique among administrative domains. Use of the DHCP realm 3605 allows DHCP administrators to avoid conflict in the use of key 3606 identifiers, and allows a host using DHCP to use authenticated 3607 DHCP while roaming among DHCP administrative domains. 3608 360921.4.2. Message Validation 3610 3611 Any DHCP message that includes more than one authentication option 3612 MUST be discarded. 3613 3614 To validate an incoming message, the receiver first checks that the 3615 value in the replay detection field is acceptable according to the 3616 replay detection method specified by the RDM field. Next, the 3617 receiver computes the MAC as described in [8]. The entire DHCP 3618 message (setting the MAC field of the authentication option to 0) is 3619 used as input to the HMAC-MD5 computation function. If the MAC 3620 computed by the receiver does not match the MAC contained in the 3621 authentication option, the receiver MUST discard the DHCP message. 3622 362321.4.3. Key Utilization 3624 3625 Each DHCP client has a set of keys. Each key is identified by <DHCP 3626 realm, client DUID, key id>. Each key also has a lifetime. The key 3627 may not be used past the end of its lifetime. The client's keys are 3628 initially distributed to the client through some out-of-band 3629 mechanism. The lifetime for each key is distributed with the key. 3630 Mechanisms for key distribution and lifetime specification are beyond 3631 the scope of this document. 3632 3633 The client and server use one of the client's keys to authenticate 3634 DHCP messages during a session (until the next Solicit message sent 3635 by the client). 3636 3637 3638 3639 3640 3641 3642Droms, et al. Standards Track [Page 65] 3643 3644RFC 3315 DHCP for IPv6 July 2003 3645 3646 364721.4.4. Client Considerations for Delayed Authentication Protocol 3648 3649 The client announces its intention to use DHCP authentication by 3650 including an Authentication option in its Solicit message. The 3651 server selects a key for the client based on the client's DUID. The 3652 client and server use that key to authenticate all DHCP messages 3653 exchanged during the session. 3654 365521.4.4.1. Sending Solicit Messages 3656 3657 When the client sends a Solicit message and wishes to use 3658 authentication, it includes an Authentication option with the desired 3659 protocol, algorithm and RDM as described in section 21.4. The client 3660 does not include any replay detection or authentication information 3661 in the Authentication option. 3662 366321.4.4.2. Receiving Advertise Messages 3664 3665 The client validates any Advertise messages containing an 3666 Authentication option specifying the delayed authentication protocol 3667 using the validation test described in section 21.4.2. 3668 3669 Client behavior, if no Advertise messages include authentication 3670 information or pass the validation test, is controlled by local 3671 policy on the client. According to client policy, the client MAY 3672 choose to respond to an Advertise message that has not been 3673 authenticated. 3674 3675 The decision to set local policy to accept unauthenticated messages 3676 should be made with care. Accepting an unauthenticated Advertise 3677 message can make the client vulnerable to spoofing and other attacks. 3678 If local users are not explicitly informed that the client has 3679 accepted an unauthenticated Advertise message, the users may 3680 incorrectly assume that the client has received an authenticated 3681 address and is not subject to DHCP attacks through unauthenticated 3682 messages. 3683 3684 A client MUST be configurable to discard unauthenticated messages, 3685 and SHOULD be configured by default to discard unauthenticated 3686 messages if the client has been configured with an authentication key 3687 or other authentication information. A client MAY choose to 3688 differentiate between Advertise messages with no authentication 3689 information and Advertise messages that do not pass the validation 3690 test; for example, a client might accept the former and discard the 3691 latter. If a client does accept an unauthenticated message, the 3692 client SHOULD inform any local users and SHOULD log the event. 3693 3694 3695 3696 3697 3698Droms, et al. Standards Track [Page 66] 3699 3700RFC 3315 DHCP for IPv6 July 2003 3701 3702 370321.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline or Release 3704 Messages 3705 3706 If the client authenticated the Advertise message through which the 3707 client selected the server, the client MUST generate authentication 3708 information for subsequent Request, Confirm, Renew, Rebind or Release 3709 messages sent to the server, as described in section 21.4. When the 3710 client sends a subsequent message, it MUST use the same key used by 3711 the server to generate the authentication information. 3712 371321.4.4.4. Sending Information-request Messages 3714 3715 If the server has selected a key for the client in a previous message 3716 exchange (see section 21.4.5.1), the client MUST use the same key to 3717 generate the authentication information throughout the session. 3718 371921.4.4.5. Receiving Reply Messages 3720 3721 If the client authenticated the Advertise it accepted, the client 3722 MUST validate the associated Reply message from the server. The 3723 client MUST discard the Reply if the message fails to pass the 3724 validation test and MAY log the validation failure. If the Reply 3725 fails to pass the validation test, the client MUST restart the DHCP 3726 configuration process by sending a Solicit message. 3727 3728 If the client accepted an Advertise message that did not include 3729 authentication information or did not pass the validation test, the 3730 client MAY accept an unauthenticated Reply message from the server. 3731 373221.4.4.6. Receiving Reconfigure Messages 3733 3734 The client MUST discard the Reconfigure if the message fails to pass 3735 the validation test and MAY log the validation failure. 3736 373721.4.5. Server Considerations for Delayed Authentication Protocol 3738 3739 After receiving a Solicit message that contains an Authentication 3740 option, the server selects a key for the client, based on the 3741 client's DUID and key selection policies with which the server has 3742 been configured. The server identifies the selected key in the 3743 Advertise message and uses the key to validate subsequent messages 3744 between the client and the server. 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754Droms, et al. Standards Track [Page 67] 3755 3756RFC 3315 DHCP for IPv6 July 2003 3757 3758 375921.4.5.1. Receiving Solicit Messages and Sending Advertise Messages 3760 3761 The server selects a key for the client and includes authentication 3762 information in the Advertise message returned to the client as 3763 specified in section 21.4. The server MUST record the identifier of 3764 the key selected for the client and use that same key for validating 3765 subsequent messages with the client. 3766 376721.4.5.2. Receiving Request, Confirm, Renew, Rebind or Release Messages 3768 and Sending Reply Messages 3769 3770 The server uses the key identified in the message and validates the 3771 message as specified in section 21.4.2. If the message fails to pass 3772 the validation test or the server does not know the key identified by 3773 the 'key ID' field, the server MUST discard the message and MAY 3774 choose to log the validation failure. 3775 3776 If the message passes the validation test, the server responds to the 3777 specific message as described in section 18.2. The server MUST 3778 include authentication information generated using the key identified 3779 in the received message, as specified in section 21.4. 3780 378121.5. Reconfigure Key Authentication Protocol 3782 3783 The Reconfigure key authentication protocol provides protection 3784 against misconfiguration of a client caused by a Reconfigure message 3785 sent by a malicious DHCP server. In this protocol, a DHCP server 3786 sends a Reconfigure Key to the client in the initial exchange of DHCP 3787 messages. The client records the Reconfigure Key for use in 3788 authenticating subsequent Reconfigure messages from that server. The 3789 server then includes an HMAC computed from the Reconfigure Key in 3790 subsequent Reconfigure messages. 3791 3792 Both the Reconfigure Key sent from the server to the client and the 3793 HMAC in subsequent Reconfigure messages are carried as the 3794 Authentication information in an Authentication option. The format 3795 of the Authentication information is defined in the following 3796 section. 3797 3798 The Reconfigure Key protocol is used (initiated by the server) only 3799 if the client and server are not using any other authentication 3800 protocol and the client and server have negotiated to use Reconfigure 3801 messages. 3802 3803 3804 3805 3806 3807 3808 3809 3810Droms, et al. Standards Track [Page 68] 3811 3812RFC 3315 DHCP for IPv6 July 2003 3813 3814 381521.5.1. Use of the Authentication Option in the Reconfigure Key 3816 Authentication Protocol 3817 3818 The following fields are set in an Authentication option for the 3819 Reconfigure Key Authentication Protocol: 3820 3821 protocol 3 3822 3823 algorithm 1 3824 3825 RDM 0 3826 3827 The format of the Authentication information for the Reconfigure Key 3828 Authentication Protocol is: 3829 3830 0 1 2 3 3831 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 3832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3833 | Type | Value (128 bits) | 3834 +-+-+-+-+-+-+-+-+ | 3835 . . 3836 . . 3837 . +-+-+-+-+-+-+-+-+ 3838 | | 3839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3840 3841 Type Type of data in Value field carried in this option: 3842 3843 1 Reconfigure Key value (used in Reply message). 3844 3845 2 HMAC-MD5 digest of the message (used in Reconfigure 3846 message). 3847 3848 Value Data as defined by field. 3849 385021.5.2. Server considerations for Reconfigure Key protocol 3851 3852 The server selects a Reconfigure Key for a client during the 3853 Request/Reply, Solicit/Reply or Information-request/Reply message 3854 exchange. The server records the Reconfigure Key and transmits that 3855 key to the client in an Authentication option in the Reply message. 3856 3857 The Reconfigure Key is 128 bits long, and MUST be a cryptographically 3858 strong random or pseudo-random number that cannot easily be 3859 predicted. 3860 3861 3862 3863 3864 3865 3866Droms, et al. Standards Track [Page 69] 3867 3868RFC 3315 DHCP for IPv6 July 2003 3869 3870 3871 To provide authentication for a Reconfigure message, the server 3872 selects a replay detection value according to the RDM selected by the 3873 server, and computes an HMAC-MD5 of the Reconfigure message using the 3874 Reconfigure Key for the client. The server computes the HMAC-MD5 3875 over the entire DHCP Reconfigure message, including the 3876 Authentication option; the HMAC-MD5 field in the Authentication 3877 option is set to zero for the HMAC-MD5 computation. The server 3878 includes the HMAC-MD5 in the authentication information field in an 3879 Authentication option included in the Reconfigure message sent to the 3880 client. 3881 388221.5.3. Client considerations for Reconfigure Key protocol 3883 3884 The client will receive a Reconfigure Key from the server in the 3885 initial Reply message from the server. The client records the 3886 Reconfigure Key for use in authenticating subsequent Reconfigure 3887 messages. 3888 3889 To authenticate a Reconfigure message, the client computes an 3890 HMAC-MD5 over the DHCP Reconfigure message, using the Reconfigure Key 3891 received from the server. If this computed HMAC-MD5 matches the 3892 value in the Authentication option, the client accepts the 3893 Reconfigure message. 3894 389522. DHCP Options 3896 3897 Options are used to carry additional information and parameters in 3898 DHCP messages. Every option shares a common base format, as 3899 described in section 22.1. All values in options are represented in 3900 network byte order. 3901 3902 This document describes the DHCP options defined as part of the base 3903 DHCP specification. Other options may be defined in the future in 3904 separate documents. 3905 3906 Unless otherwise noted, each option may appear only in the options 3907 area of a DHCP message and may appear only once. If an option does 3908 appear multiple times, each instance is considered separate and the 3909 data areas of the options MUST NOT be concatenated or otherwise 3910 combined. 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922Droms, et al. Standards Track [Page 70] 3923 3924RFC 3315 DHCP for IPv6 July 2003 3925 3926 392722.1. Format of DHCP Options 3928 3929 The format of DHCP options is: 3930 3931 0 1 2 3 3932 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 3933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3934 | option-code | option-len | 3935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3936 | option-data | 3937 | (option-len octets) | 3938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3939 3940 option-code An unsigned integer identifying the specific option 3941 type carried in this option. 3942 3943 option-len An unsigned integer giving the length of the 3944 option-data field in this option in octets. 3945 3946 option-data The data for the option; the format of this data 3947 depends on the definition of the option. 3948 3949 DHCPv6 options are scoped by using encapsulation. Some options apply 3950 generally to the client, some are specific to an IA, and some are 3951 specific to the addresses within an IA. These latter two cases are 3952 discussed in sections 22.4 and 22.6. 3953 395422.2. Client Identifier Option 3955 3956 The Client Identifier option is used to carry a DUID (see section 9) 3957 identifying a client between a client and a server. The format of 3958 the Client Identifier option is: 3959 3960 0 1 2 3 3961 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 3962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3963 | OPTION_CLIENTID | option-len | 3964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3965 . . 3966 . DUID . 3967 . (variable length) . 3968 . . 3969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3970 3971 option-code OPTION_CLIENTID (1). 3972 3973 option-len Length of DUID in octets. 3974 3975 3976 3977 3978Droms, et al. Standards Track [Page 71] 3979 3980RFC 3315 DHCP for IPv6 July 2003 3981 3982 3983 DUID The DUID for the client. 3984 398522.3. Server Identifier Option 3986 3987 The Server Identifier option is used to carry a DUID (see section 9) 3988 identifying a server between a client and a server. The format of 3989 the Server Identifier option is: 3990 3991 0 1 2 3 3992 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 3993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3994 | OPTION_SERVERID | option-len | 3995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3996 . . 3997 . DUID . 3998 . (variable length) . 3999 . . 4000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4001 4002 option-code OPTION_SERVERID (2). 4003 4004 option-len Length of DUID in octets. 4005 4006 DUID The DUID for the server. 4007 400822.4. Identity Association for Non-temporary Addresses Option 4009 4010 The Identity Association for Non-temporary Addresses option (IA_NA 4011 option) is used to carry an IA_NA, the parameters associated with the 4012 IA_NA, and the non-temporary addresses associated with the IA_NA. 4013 4014 Addresses appearing in an IA_NA option are not temporary addresses 4015 (see section 22.5). 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034Droms, et al. Standards Track [Page 72] 4035 4036RFC 3315 DHCP for IPv6 July 2003 4037 4038 4039 The format of the IA_NA option is: 4040 4041 0 1 2 3 4042 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 4043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4044 | OPTION_IA_NA | option-len | 4045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4046 | IAID (4 octets) | 4047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4048 | T1 | 4049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4050 | T2 | 4051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4052 | | 4053 . IA_NA-options . 4054 . . 4055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4056 4057 option-code OPTION_IA_NA (3). 4058 4059 option-len 12 + length of IA_NA-options field. 4060 4061 IAID The unique identifier for this IA_NA; the 4062 IAID must be unique among the identifiers for 4063 all of this client's IA_NAs. The number 4064 space for IA_NA IAIDs is separate from the 4065 number space for IA_TA IAIDs. 4066 4067 T1 The time at which the client contacts the 4068 server from which the addresses in the IA_NA 4069 were obtained to extend the lifetimes of the 4070 addresses assigned to the IA_NA; T1 is a 4071 time duration relative to the current time 4072 expressed in units of seconds. 4073 4074 T2 The time at which the client contacts any 4075 available server to extend the lifetimes of 4076 the addresses assigned to the IA_NA; T2 is a 4077 time duration relative to the current time 4078 expressed in units of seconds. 4079 4080 IA_NA-options Options associated with this IA_NA. 4081 4082 The IA_NA-options field encapsulates those options that are specific 4083 to this IA_NA. For example, all of the IA Address Options carrying 4084 the addresses associated with this IA_NA are in the IA_NA-options 4085 field. 4086 4087 4088 4089 4090Droms, et al. Standards Track [Page 73] 4091 4092RFC 3315 DHCP for IPv6 July 2003 4093 4094 4095 An IA_NA option may only appear in the options area of a DHCP 4096 message. A DHCP message may contain multiple IA_NA options. 4097 4098 The status of any operations involving this IA_NA is indicated in a 4099 Status Code option in the IA_NA-options field. 4100 4101 Note that an IA_NA has no explicit "lifetime" or "lease length" of 4102 its own. When the valid lifetimes of all of the addresses in an 4103 IA_NA have expired, the IA_NA can be considered as having expired. 4104 T1 and T2 are included to give servers explicit control over when a 4105 client recontacts the server about a specific IA_NA. 4106 4107 In a message sent by a client to a server, values in the T1 and T2 4108 fields indicate the client's preference for those parameters. The 4109 client sets T1 and T2 to 0 if it has no preference for those values. 4110 In a message sent by a server to a client, the client MUST use the 4111 values in the T1 and T2 fields for the T1 and T2 parameters, unless 4112 those values in those fields are 0. The values in the T1 and T2 4113 fields are the number of seconds until T1 and T2. 4114 4115 The server selects the T1 and T2 times to allow the client to extend 4116 the lifetimes of any addresses in the IA_NA before the lifetimes 4117 expire, even if the server is unavailable for some short period of 4118 time. Recommended values for T1 and T2 are .5 and .8 times the 4119 shortest preferred lifetime of the addresses in the IA that the 4120 server is willing to extend, respectively. If the "shortest" 4121 preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and 4122 T2 values are also 0xffffffff. If the time at which the addresses in 4123 an IA_NA are to be renewed is to be left to the discretion of the 4124 client, the server sets T1 and T2 to 0. 4125 4126 If a server receives an IA_NA with T1 greater than T2, and both T1 4127 and T2 are greater than 0, the server ignores the invalid values of 4128 T1 and T2 and processes the IA_NA as though the client had set T1 and 4129 T2 to 0. 4130 4131 If a client receives an IA_NA with T1 greater than T2, and both T1 4132 and T2 are greater than 0, the client discards the IA_NA option and 4133 processes the remainder of the message as though the server had not 4134 included the invalid IA_NA option. 4135 4136 Care should be taken in setting T1 or T2 to 0xffffffff ("infinity"). 4137 A client will never attempt to extend the lifetimes of any addresses 4138 in an IA with T1 set to 0xffffffff. A client will never attempt to 4139 use a Rebind message to locate a different server to extend the 4140 lifetimes of any addresses in an IA with T2 set to 0xffffffff. 4141 4142 4143 4144 4145 4146Droms, et al. Standards Track [Page 74] 4147 4148RFC 3315 DHCP for IPv6 July 2003 4149 4150 415122.5. Identity Association for Temporary Addresses Option 4152 4153 The Identity Association for the Temporary Addresses (IA_TA) option 4154 is used to carry an IA_TA, the parameters associated with the IA_TA 4155 and the addresses associated with the IA_TA. All of the addresses in 4156 this option are used by the client as temporary addresses, as defined 4157 in RFC 3041 [12]. The format of the IA_TA option is: 4158 4159 0 1 2 3 4160 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 4161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4162 | OPTION_IA_TA | option-len | 4163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4164 | IAID (4 octets) | 4165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4166 | | 4167 . IA_TA-options . 4168 . . 4169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4170 4171 option-code OPTION_IA_TA (4). 4172 4173 option-len 4 + length of IA_TA-options field. 4174 4175 IAID The unique identifier for this IA_TA; the 4176 IAID must be unique among the identifiers 4177 for all of this client's IA_TAs. The number 4178 space for IA_TA IAIDs is separate from the 4179 number space for IA_NA IAIDs. 4180 4181 IA_TA-options Options associated with this IA_TA. 4182 4183 The IA_TA-Options field encapsulates those options that are specific 4184 to this IA_TA. For example, all of the IA Address Options carrying 4185 the addresses associated with this IA_TA are in the IA_TA-options 4186 field. 4187 4188 Each IA_TA carries one "set" of temporary addresses; that is, at most 4189 one address from each prefix assigned to the link to which the client 4190 is attached. 4191 4192 An IA_TA option may only appear in the options area of a DHCP 4193 message. A DHCP message may contain multiple IA_TA options. 4194 4195 The status of any operations involving this IA_TA is indicated in a 4196 Status Code option in the IA_TA-options field. 4197 4198 4199 4200 4201 4202Droms, et al. Standards Track [Page 75] 4203 4204RFC 3315 DHCP for IPv6 July 2003 4205 4206 4207 Note that an IA has no explicit "lifetime" or "lease length" of its 4208 own. When the valid lifetimes of all of the addresses in an IA_TA 4209 have expired, the IA can be considered as having expired. 4210 4211 An IA_TA option does not include values for T1 and T2. A client MAY 4212 request that the lifetimes on temporary addresses be extended by 4213 including the addresses in a IA_TA option sent in a Renew or Rebind 4214 message to a server. For example, a client would request an 4215 extension on the lifetime of a temporary address to allow an 4216 application to continue to use an established TCP connection. 4217 4218 The client obtains new temporary addresses by sending an IA_TA option 4219 with a new IAID to a server. Requesting new temporary addresses from 4220 the server is the equivalent of generating new temporary addresses as 4221 described in RFC 3041. The server will generate new temporary 4222 addresses and return them to the client. The client should request 4223 new temporary addresses before the lifetimes on the previously 4224 assigned addresses expire. 4225 4226 A server MUST return the same set of temporary address for the same 4227 IA_TA (as identified by the IAID) as long as those addresses are 4228 still valid. After the lifetimes of the addresses in an IA_TA have 4229 expired, the IAID may be reused to identify a new IA_TA with new 4230 temporary addresses. 4231 4232 This option MAY appear in a Confirm message if the lifetimes on the 4233 temporary addresses in the associated IA have not expired. 4234 423522.6. IA Address Option 4236 4237 The IA Address option is used to specify IPv6 addresses associated 4238 with an IA_NA or an IA_TA. The IA Address option must be 4239 encapsulated in the Options field of an IA_NA or IA_TA option. The 4240 Options field encapsulates those options that are specific to this 4241 address. 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258Droms, et al. Standards Track [Page 76] 4259 4260RFC 3315 DHCP for IPv6 July 2003 4261 4262 4263 The format of the IA Address option is: 4264 4265 0 1 2 3 4266 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 4267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4268 | OPTION_IAADDR | option-len | 4269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4270 | | 4271 | IPv6 address | 4272 | | 4273 | | 4274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4275 | preferred-lifetime | 4276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4277 | valid-lifetime | 4278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4279 . . 4280 . IAaddr-options . 4281 . . 4282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4283 4284 option-code OPTION_IAADDR (5). 4285 4286 option-len 24 + length of IAaddr-options field. 4287 4288 IPv6 address An IPv6 address. 4289 4290 preferred-lifetime The preferred lifetime for the IPv6 address in 4291 the option, expressed in units of seconds. 4292 4293 valid-lifetime The valid lifetime for the IPv6 address in the 4294 option, expressed in units of seconds. 4295 4296 IAaddr-options Options associated with this address. 4297 4298 In a message sent by a client to a server, values in the preferred 4299 and valid lifetime fields indicate the client's preference for those 4300 parameters. The client may send 0 if it has no preference for the 4301 preferred and valid lifetimes. In a message sent by a server to a 4302 client, the client MUST use the values in the preferred and valid 4303 lifetime fields for the preferred and valid lifetimes. The values in 4304 the preferred and valid lifetimes are the number of seconds remaining 4305 in each lifetime. 4306 4307 4308 4309 4310 4311 4312 4313 4314Droms, et al. Standards Track [Page 77] 4315 4316RFC 3315 DHCP for IPv6 July 2003 4317 4318 4319 A client discards any addresses for which the preferred lifetime is 4320 greater than the valid lifetime. A server ignores the lifetimes set 4321 by the client if the preferred lifetime is greater than the valid 4322 lifetime and ignores the values for T1 and T2 set by the client if 4323 those values are greater than the preferred lifetime. 4324 4325 Care should be taken in setting the valid lifetime of an address to 4326 0xffffffff ("infinity"), which amounts to a permanent assignment of 4327 an address to a client. 4328 4329 An IA Address option may appear only in an IA_NA option or an IA_TA 4330 option. More than one IA Address Option can appear in an IA_NA 4331 option or an IA_TA option. 4332 4333 The status of any operations involving this IA Address is indicated 4334 in a Status Code option in the IAaddr-options field. 4335 433622.7. Option Request Option 4337 4338 The Option Request option is used to identify a list of options in a 4339 message between a client and a server. The format of the Option 4340 Request option is: 4341 4342 0 1 2 3 4343 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 4344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4345 | OPTION_ORO | option-len | 4346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4347 | requested-option-code-1 | requested-option-code-2 | 4348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4349 | ... | 4350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4351 4352 option-code OPTION_ORO (6). 4353 4354 option-len 2 * number of requested options. 4355 4356 requested-option-code-n The option code for an option requested by 4357 the client. 4358 4359 A client MAY include an Option Request option in a Solicit, Request, 4360 Renew, Rebind, Confirm or Information-request message to inform the 4361 server about options the client wants the server to send to the 4362 client. A server MAY include an Option Request option in a 4363 Reconfigure option to indicate which options the client should 4364 request from the server. 4365 4366 4367 4368 4369 4370Droms, et al. Standards Track [Page 78] 4371 4372RFC 3315 DHCP for IPv6 July 2003 4373 4374 437522.8. Preference Option 4376 4377 The Preference option is sent by a server to a client to affect the 4378 selection of a server by the client. 4379 4380 The format of the Preference option is: 4381 4382 0 1 2 3 4383 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 4384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4385 | OPTION_PREFERENCE | option-len | 4386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4387 | pref-value | 4388 +-+-+-+-+-+-+-+-+ 4389 4390 option-code OPTION_PREFERENCE (7). 4391 4392 option-len 1. 4393 4394 pref-value The preference value for the server in this message. 4395 4396 A server MAY include a Preference option in an Advertise message to 4397 control the selection of a server by the client. See section 17.1.3 4398 for the use of the Preference option by the client and the 4399 interpretation of Preference option data value. 4400 440122.9. Elapsed Time Option 4402 4403 0 1 2 3 4404 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 4405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4406 | OPTION_ELAPSED_TIME | option-len | 4407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4408 | elapsed-time | 4409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4410 4411 option-code OPTION_ELAPSED_TIME (8). 4412 4413 option-len 2. 4414 4415 elapsed-time The amount of time since the client began its 4416 current DHCP transaction. This time is expressed in 4417 hundredths of a second (10^-2 seconds). 4418 4419 A client MUST include an Elapsed Time option in messages to indicate 4420 how long the client has been trying to complete a DHCP message 4421 exchange. The elapsed time is measured from the time at which the 4422 client sent the first message in the message exchange, and the 4423 4424 4425 4426Droms, et al. Standards Track [Page 79] 4427 4428RFC 3315 DHCP for IPv6 July 2003 4429 4430 4431 elapsed-time field is set to 0 in the first message in the message 4432 exchange. Servers and Relay Agents use the data value in this option 4433 as input to policy controlling how a server responds to a client 4434 message. For example, the elapsed time option allows a secondary 4435 DHCP server to respond to a request when a primary server has not 4436 answered in a reasonable time. The elapsed time value is an 4437 unsigned, 16 bit integer. The client uses the value 0xffff to 4438 represent any elapsed time values greater than the largest time value 4439 that can be represented in the Elapsed Time option. 4440 444122.10. Relay Message Option 4442 4443 The Relay Message option carries a DHCP message in a Relay-forward or 4444 Relay-reply message. 4445 4446 The format of the Relay Message option is: 4447 4448 0 1 2 3 4449 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 4450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4451 | OPTION_RELAY_MSG | option-len | 4452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4453 | | 4454 . DHCP-relay-message . 4455 . . 4456 . . 4457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4458 4459 option-code OPTION_RELAY_MSG (9) 4460 4461 option-len Length of DHCP-relay-message 4462 4463 DHCP-relay-message In a Relay-forward message, the received 4464 message, relayed verbatim to the next relay agent 4465 or server; in a Relay-reply message, the message to 4466 be copied and relayed to the relay agent or client 4467 whose address is in the peer-address field of the 4468 Relay-reply message 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482Droms, et al. Standards Track [Page 80] 4483 4484RFC 3315 DHCP for IPv6 July 2003 4485 4486 448722.11. Authentication Option 4488 4489 The Authentication option carries authentication information to 4490 authenticate the identity and contents of DHCP messages. The use of 4491 the Authentication option is described in section 21. The format of 4492 the Authentication option is: 4493 4494 0 1 2 3 4495 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 4496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4497 | OPTION_AUTH | option-len | 4498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4499 | protocol | algorithm | RDM | | 4500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4501 | | 4502 | replay detection (64 bits) +-+-+-+-+-+-+-+-+ 4503 | | auth-info | 4504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4505 . authentication information . 4506 . (variable length) . 4507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4508 4509 option-code OPTION_AUTH (11) 4510 4511 option-len 11 + length of authentication 4512 information field 4513 4514 protocol The authentication protocol used in 4515 this authentication option 4516 4517 algorithm The algorithm used in the 4518 authentication protocol 4519 4520 RDM The replay detection method used in 4521 this authentication option 4522 4523 Replay detection The replay detection information for 4524 the RDM 4525 4526 authentication information The authentication information, 4527 as specified by the protocol and 4528 algorithm used in this authentication 4529 option 4530 4531 4532 4533 4534 4535 4536 4537 4538Droms, et al. Standards Track [Page 81] 4539 4540RFC 3315 DHCP for IPv6 July 2003 4541 4542 454322.12. Server Unicast Option 4544 4545 The server sends this option to a client to indicate to the client 4546 that it is allowed to unicast messages to the server. The format of 4547 the Server Unicast option is: 4548 4549 0 1 2 3 4550 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 4551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4552 | OPTION_UNICAST | option-len | 4553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4554 | | 4555 | server-address | 4556 | | 4557 | | 4558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4559 4560 option-code OPTION_UNICAST (12). 4561 4562 option-len 16. 4563 4564 server-address The IP address to which the client should send 4565 messages delivered using unicast. 4566 4567 The server specifies the IPv6 address to which the client is to send 4568 unicast messages in the server-address field. When a client receives 4569 this option, where permissible and appropriate, the client sends 4570 messages directly to the server using the IPv6 address specified in 4571 the server-address field of the option. 4572 4573 When the server sends a Unicast option to the client, some messages 4574 from the client will not be relayed by Relay Agents, and will not 4575 include Relay Agent options from the Relay Agents. Therefore, a 4576 server should only send a Unicast option to a client when Relay 4577 Agents are not sending Relay Agent options. A DHCP server rejects 4578 any messages sent inappropriately using unicast to ensure that 4579 messages are relayed by Relay Agents when Relay Agent options are in 4580 use. 4581 4582 Details about when the client may send messages to the server using 4583 unicast are in section 18. 4584 458522.13. Status Code Option 4586 4587 This option returns a status indication related to the DHCP message 4588 or option in which it appears. The format of the Status Code option 4589 is: 4590 4591 4592 4593 4594Droms, et al. Standards Track [Page 82] 4595 4596RFC 3315 DHCP for IPv6 July 2003 4597 4598 4599 0 1 2 3 4600 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 4601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4602 | OPTION_STATUS_CODE | option-len | 4603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4604 | status-code | | 4605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4606 . . 4607 . status-message . 4608 . . 4609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4610 4611 option-code OPTION_STATUS_CODE (13). 4612 4613 option-len 2 + length of status-message. 4614 4615 status-code The numeric code for the status encoded in 4616 this option. The status codes are defined in 4617 section 24.4. 4618 4619 status-message A UTF-8 encoded text string suitable for 4620 display to an end user, which MUST NOT be 4621 null-terminated. 4622 4623 A Status Code option may appear in the options field of a DHCP 4624 message and/or in the options field of another option. If the Status 4625 Code option does not appear in a message in which the option could 4626 appear, the status of the message is assumed to be Success. 4627 462822.14. Rapid Commit Option 4629 4630 The Rapid Commit option is used to signal the use of the two message 4631 exchange for address assignment. The format of the Rapid Commit 4632 option is: 4633 4634 0 1 2 3 4635 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 4636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4637 | OPTION_RAPID_COMMIT | 0 | 4638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4639 4640 option-code OPTION_RAPID_COMMIT (14). 4641 4642 option-len 0. 4643 4644 A client MAY include this option in a Solicit message if the client 4645 is prepared to perform the Solicit-Reply message exchange described 4646 in section 17.1.1. 4647 4648 4649 4650Droms, et al. Standards Track [Page 83] 4651 4652RFC 3315 DHCP for IPv6 July 2003 4653 4654 4655 A server MUST include this option in a Reply message sent in response 4656 to a Solicit message when completing the Solicit-Reply message 4657 exchange. 4658 4659 DISCUSSION: 4660 4661 Each server that responds with a Reply to a Solicit that includes 4662 a Rapid Commit option will commit the assigned addresses in the 4663 Reply message to the client, and will not receive any confirmation 4664 that the client has received the Reply message. Therefore, if 4665 more than one server responds to a Solicit that includes a Rapid 4666 Commit option, some servers will commit addresses that are not 4667 actually used by the client. 4668 4669 The problem of unused addresses can be minimized, for example, by 4670 designing the DHCP service so that only one server responds to the 4671 Solicit or by using relatively short lifetimes for assigned 4672 addresses. 4673 467422.15. User Class Option 4675 4676 The User Class option is used by a client to identify the type or 4677 category of user or applications it represents. 4678 4679 The format of the User Class option is: 4680 4681 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 4682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4683 | OPTION_USER_CLASS | option-len | 4684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4685 . . 4686 . user-class-data . 4687 . . 4688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4689 4690 option-code OPTION_USER_CLASS (15). 4691 4692 option-len Length of user class data field. 4693 4694 user-class-data The user classes carried by the client. 4695 4696 The information contained in the data area of this option is 4697 contained in one or more opaque fields that represent the user class 4698 or classes of which the client is a member. A server selects 4699 configuration information for the client based on the classes 4700 identified in this option. For example, the User Class option can be 4701 used to configure all clients of people in the accounting department 4702 4703 4704 4705 4706Droms, et al. Standards Track [Page 84] 4707 4708RFC 3315 DHCP for IPv6 July 2003 4709 4710 4711 with a different printer than clients of people in the marketing 4712 department. The user class information carried in this option MUST 4713 be configurable on the client. 4714 4715 The data area of the user class option MUST contain one or more 4716 instances of user class data. Each instance of the user class data 4717 is formatted as follows: 4718 4719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4720 | user-class-len | opaque-data | 4721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4722 4723 The user-class-len is two octets long and specifies the length of the 4724 opaque user class data in network byte order. 4725 4726 A server interprets the classes identified in this option according 4727 to its configuration to select the appropriate configuration 4728 information for the client. A server may use only those user classes 4729 that it is configured to interpret in selecting configuration 4730 information for a client and ignore any other user classes. In 4731 response to a message containing a User Class option, a server 4732 includes a User Class option containing those classes that were 4733 successfully interpreted by the server, so that the client can be 4734 informed of the classes interpreted by the server. 4735 473622.16. Vendor Class Option 4737 4738 This option is used by a client to identify the vendor that 4739 manufactured the hardware on which the client is running. The 4740 information contained in the data area of this option is contained in 4741 one or more opaque fields that identify details of the hardware 4742 configuration. The format of the Vendor Class option is: 4743 4744 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 4745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4746 | OPTION_VENDOR_CLASS | option-len | 4747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4748 | enterprise-number | 4749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4750 . . 4751 . vendor-class-data . 4752 . . . . . 4753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4754 4755 option-code OPTION_VENDOR_CLASS (16). 4756 4757 option-len 4 + length of vendor class data field. 4758 4759 4760 4761 4762Droms, et al. Standards Track [Page 85] 4763 4764RFC 3315 DHCP for IPv6 July 2003 4765 4766 4767 enterprise-number The vendor's registered Enterprise Number as 4768 registered with IANA [6]. 4769 4770 vendor-class-data The hardware configuration of the host on 4771 which the client is running. 4772 4773 The vendor-class-data is composed of a series of separate items, each 4774 of which describes some characteristic of the client's hardware 4775 configuration. Examples of vendor-class-data instances might include 4776 the version of the operating system the client is running or the 4777 amount of memory installed on the client. 4778 4779 Each instance of the vendor-class-data is formatted as follows: 4780 4781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4782 | vendor-class-len | opaque-data | 4783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4784 4785 The vendor-class-len is two octets long and specifies the length of 4786 the opaque vendor class data in network byte order. 4787 478822.17. Vendor-specific Information Option 4789 4790 This option is used by clients and servers to exchange 4791 vendor-specific information. 4792 4793 The format of the Vendor-specific Information option is: 4794 4795 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 4796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4797 | OPTION_VENDOR_OPTS | option-len | 4798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4799 | enterprise-number | 4800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4801 . . 4802 . option-data . 4803 . . 4804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4805 4806 option-code OPTION_VENDOR_OPTS (17) 4807 4808 option-len 4 + length of option-data field 4809 4810 enterprise-number The vendor's registered Enterprise Number as 4811 registered with IANA [6]. 4812 4813 4814 4815 4816 4817 4818Droms, et al. Standards Track [Page 86] 4819 4820RFC 3315 DHCP for IPv6 July 2003 4821 4822 4823 option-data An opaque object of option-len octets, 4824 interpreted by vendor-specific code on the 4825 clients and servers 4826 4827 The definition of the information carried in this option is vendor 4828 specific. The vendor is indicated in the enterprise-number field. 4829 Use of vendor-specific information allows enhanced operation, 4830 utilizing additional features in a vendor's DHCP implementation. A 4831 DHCP client that does not receive requested vendor-specific 4832 information will still configure the host device's IPv6 stack to be 4833 functional. 4834 4835 The encapsulated vendor-specific options field MUST be encoded as a 4836 sequence of code/length/value fields of identical format to the DHCP 4837 options field. The option codes are defined by the vendor identified 4838 in the enterprise-number field and are not managed by IANA. Each of 4839 the encapsulated options is formatted as follows: 4840 4841 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 4842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4843 | opt-code | option-len | 4844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4845 . . 4846 . option-data . 4847 . . 4848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4849 4850 opt-code The code for the encapsulated option. 4851 4852 option-len An unsigned integer giving the length of the 4853 option-data field in this encapsulated option 4854 in octets. 4855 4856 option-data The data area for the encapsulated option. 4857 4858 Multiple instances of the Vendor-specific Information option may 4859 appear in a DHCP message. Each instance of the option is interpreted 4860 according to the option codes defined by the vendor identified by the 4861 Enterprise Number in that option. 4862 486322.18. Interface-Id Option 4864 4865 The relay agent MAY send the Interface-id option to identify the 4866 interface on which the client message was received. If a relay agent 4867 receives a Relay-reply message with an Interface-id option, the relay 4868 agent relays the message to the client through the interface 4869 identified by the option. 4870 4871 4872 4873 4874Droms, et al. Standards Track [Page 87] 4875 4876RFC 3315 DHCP for IPv6 July 2003 4877 4878 4879 The format of the Interface ID option is: 4880 4881 0 1 2 3 4882 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 4883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4884 | OPTION_INTERFACE_ID | option-len | 4885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4886 . . 4887 . interface-id . 4888 . . 4889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4890 4891 option-code OPTION_INTERFACE_ID (18). 4892 4893 option-len Length of interface-id field. 4894 4895 interface-id An opaque value of arbitrary length generated 4896 by the relay agent to identify one of the 4897 relay agent's interfaces. 4898 4899 The server MUST copy the Interface-Id option from the Relay-Forward 4900 message into the Relay-Reply message the server sends to the relay 4901 agent in response to the Relay-Forward message. This option MUST NOT 4902 appear in any message except a Relay-Forward or Relay-Reply message. 4903 4904 Servers MAY use the Interface-ID for parameter assignment policies. 4905 The Interface-ID SHOULD be considered an opaque value, with policies 4906 based on exact match only; that is, the Interface-ID SHOULD NOT be 4907 internally parsed by the server. The Interface-ID value for an 4908 interface SHOULD be stable and remain unchanged, for example, after 4909 the relay agent is restarted; if the Interface-ID changes, a server 4910 will not be able to use it reliably in parameter assignment policies. 4911 491222.19. Reconfigure Message Option 4913 4914 A server includes a Reconfigure Message option in a Reconfigure 4915 message to indicate to the client whether the client responds with a 4916 Renew message or an Information-request message. The format of this 4917 option is: 4918 4919 0 1 2 3 4920 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 4921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4922 | OPTION_RECONF_MSG | option-len | 4923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4924 | msg-type | 4925 +-+-+-+-+-+-+-+-+ 4926 4927 4928 4929 4930Droms, et al. Standards Track [Page 88] 4931 4932RFC 3315 DHCP for IPv6 July 2003 4933 4934 4935 option-code OPTION_RECONF_MSG (19). 4936 4937 option-len 1. 4938 4939 msg-type 5 for Renew message, 11 for 4940 Information-request message. 4941 4942 The Reconfigure Message option can only appear in a Reconfigure 4943 message. 4944 494522.20. Reconfigure Accept Option 4946 4947 A client uses the Reconfigure Accept option to announce to the server 4948 whether the client is willing to accept Reconfigure messages, and a 4949 server uses this option to tell the client whether or not to accept 4950 Reconfigure messages. The default behavior, in the absence of this 4951 option, means unwillingness to accept Reconfigure messages, or 4952 instruction not to accept Reconfigure messages, for the client and 4953 server messages, respectively. The following figure gives the format 4954 of the Reconfigure Accept option: 4955 4956 0 1 2 3 4957 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 4958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4959 | OPTION_RECONF_ACCEPT | 0 | 4960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4961 4962 option-code OPTION_RECONF_ACCEPT (20). 4963 4964 option-len 0. 4965 496623. Security Considerations 4967 4968 The threat to DHCP is inherently an insider threat (assuming a 4969 properly configured network where DHCPv6 ports are blocked on the 4970 perimeter gateways of the enterprise). Regardless of the gateway 4971 configuration, however, the potential attacks by insiders and 4972 outsiders are the same. 4973 4974 Use of manually configured preshared keys for IPsec between relay 4975 agents and servers does not defend against replayed DHCP messages. 4976 Replayed messages can represent a DOS attack through exhaustion of 4977 processing resources, but not through mis-configuration or exhaustion 4978 of other resources such as assignable addresses. 4979 4980 One attack specific to a DHCP client is the establishment of a 4981 malicious server with the intent of providing incorrect configuration 4982 information to the client. The motivation for doing so may be to 4983 4984 4985 4986Droms, et al. Standards Track [Page 89] 4987 4988RFC 3315 DHCP for IPv6 July 2003 4989 4990 4991 mount a "man in the middle" attack that causes the client to 4992 communicate with a malicious server instead of a valid server for 4993 some service such as DNS or NTP. The malicious server may also mount 4994 a denial of service attack through misconfiguration of the client 4995 that causes all network communication from the client to fail. 4996 4997 There is another threat to DHCP clients from mistakenly or 4998 accidentally configured DHCP servers that answer DHCP client requests 4999 with unintentionally incorrect configuration parameters. 5000 5001 A DHCP client may also be subject to attack through the receipt of a 5002 Reconfigure message from a malicious server that causes the client to 5003 obtain incorrect configuration information from that server. Note 5004 that although a client sends its response (Renew or 5005 Information-request message) through a relay agent and, therefore, 5006 that response will only be received by servers to which DHCP messages 5007 are relayed, a malicious server could send a Reconfigure message to a 5008 client, followed (after an appropriate delay) by a Reply message that 5009 would be accepted by the client. Thus, a malicious server that is 5010 not on the network path between the client and the server may still 5011 be able to mount a Reconfigure attack on a client. The use of 5012 transaction IDs that are cryptographically sound and cannot easily be 5013 predicted will also reduce the probability that such an attack will 5014 be successful. 5015 5016 The threat specific to a DHCP server is an invalid client 5017 masquerading as a valid client. The motivation for this may be for 5018 theft of service, or to circumvent auditing for any number of 5019 nefarious purposes. 5020 5021 The threat common to both the client and the server is the resource 5022 "denial of service" (DoS) attack. These attacks typically involve 5023 the exhaustion of available addresses, or the exhaustion of CPU or 5024 network bandwidth, and are present anytime there is a shared 5025 resource. 5026 5027 In the case where relay agents add additional options to Relay 5028 Forward messages, the messages exchanged between relay agents and 5029 servers may be used to mount a "man in the middle" or denial of 5030 service attack. 5031 5032 This threat model does not consider the privacy of the contents of 5033 DHCP messages to be important. DHCP is not used to exchange 5034 authentication or configuration information that must be kept secret 5035 from other networks nodes. 5036 5037 5038 5039 5040 5041 5042Droms, et al. Standards Track [Page 90] 5043 5044RFC 3315 DHCP for IPv6 July 2003 5045 5046 5047 DHCP authentication provides for authentication of the identity of 5048 DHCP clients and servers, and for the integrity of messages delivered 5049 between DHCP clients and servers. DHCP authentication does not 5050 provide any privacy for the contents of DHCP messages. 5051 5052 The Delayed Authentication protocol described in section 21.4 uses a 5053 secret key that is shared between a client and a server. The use of 5054 a "DHCP realm" in the shared key allows identification of 5055 administrative domains so that a client can select the appropriate 5056 key or keys when roaming between administrative domains. However, 5057 the Delayed Authentication protocol does not define any mechanism for 5058 sharing of keys, so a client may require separate keys for each 5059 administrative domain it encounters. The use of shared keys may not 5060 scale well and does not provide for repudiation of compromised keys. 5061 This protocol is focused on solving the intradomain problem where the 5062 out-of-band exchange of a shared key is feasible. 5063 5064 Because of the opportunity for attack through the Reconfigure 5065 message, a DHCP client MUST discard any Reconfigure message that does 5066 not include authentication or that does not pass the validation 5067 process for the authentication protocol. 5068 5069 The Reconfigure Key protocol described in section 21.5 provides 5070 protection against the use of a Reconfigure message by a malicious 5071 DHCP server to mount a denial of service or man-in-the-middle attack 5072 on a client. This protocol can be compromised by an attacker that 5073 can intercept the initial message in which the DHCP server sends the 5074 key to the client. 5075 5076 Communication between a server and a relay agent, and communication 5077 between relay agents, can be secured through the use of IPSec, as 5078 described in section 21.1. The use of manual configuration and 5079 installation of static keys are acceptable in this instance because 5080 relay agents and the server will belong to the same administrative 5081 domain and the relay agents will require other specific configuration 5082 (for example, configuration of the DHCP server address) as well as 5083 the IPSec configuration. 5084 508524. IANA Considerations 5086 5087 This document defines several new name spaces associated with DHCPv6 5088 and DHCPv6 options: 5089 5090 - Message types 5091 5092 - Status codes 5093 5094 - DUID 5095 5096 5097 5098Droms, et al. Standards Track [Page 91] 5099 5100RFC 3315 DHCP for IPv6 July 2003 5101 5102 5103 - Option codes 5104 5105 IANA has established a registry of values for each of these name 5106 spaces, which are described in the remainder of this section. These 5107 name spaces will be managed by the IANA and all will be managed 5108 separately from the name spaces defined for DHCPv4. 5109 5110 New multicast addresses, message types, status codes, and DUID types 5111 are assigned via Standards Action [11]. 5112 5113 New DHCP option codes are tentatively assigned after the 5114 specification for the associated option, published as an Internet 5115 Draft, has received expert review by a designated expert [11]. The 5116 final assignment of DHCP option codes is through Standards Action, as 5117 defined in RFC 2434 [11]. 5118 5119 This document also references three name spaces in section 21 that 5120 are associated with the Authentication Option (section 22.11). These 5121 name spaces are defined by the authentication mechanism for DHCPv4 in 5122 RFC 3118 [4]. 5123 5124 The authentication name spaces currently registered by IANA will 5125 apply to both DHCPv6 and DHCPv4. In the future, specifications that 5126 define new Protocol, Algorithm and RDM mechanisms will explicitly 5127 define whether the new mechanisms are used with DHCPv4, DHCPv6 or 5128 both. 5129 513024.1. Multicast Addresses 5131 5132 Section 5.1 defines the following multicast addresses, which have 5133 been assigned by IANA for use by DHCPv6: 5134 5135 All_DHCP_Relay_Agents_and_Servers address: FF02::1:2 5136 5137 All_DHCP_Servers address: FF05::1:3 5138 5139 5140 5141 5142 5143 5144 5145 5146 5147 5148 5149 5150 5151 5152 5153 5154Droms, et al. Standards Track [Page 92] 5155 5156RFC 3315 DHCP for IPv6 July 2003 5157 5158 515924.2. DHCP Message Types 5160 5161 IANA has recorded the following message types (defined in section 5162 5.3). IANA will maintain the registry of DHCP message types. 5163 5164 SOLICIT 1 5165 5166 ADVERTISE 2 5167 5168 REQUEST 3 5169 5170 CONFIRM 4 5171 5172 RENEW 5 5173 5174 REBIND 6 5175 5176 REPLY 7 5177 5178 RELEASE 8 5179 5180 DECLINE 9 5181 5182 RECONFIGURE 10 5183 5184 INFORMATION-REQUEST 11 5185 5186 RELAY-FORW 12 5187 5188 RELAY-REPL 13 5189 5190 5191 5192 5193 5194 5195 5196 5197 5198 5199 5200 5201 5202 5203 5204 5205 5206 5207 5208 5209 5210Droms, et al. Standards Track [Page 93] 5211 5212RFC 3315 DHCP for IPv6 July 2003 5213 5214 521524.3. DHCP Options 5216 5217 IANA has recorded the following option-codes (as defined in section 5218 22). IANA will maintain the registry of DHCP option codes. 5219 5220 OPTION_CLIENTID 1 5221 5222 OPTION_SERVERID 2 5223 5224 OPTION_IA_NA 3 5225 5226 OPTION_IA_TA 4 5227 5228 OPTION_IAADDR 5 5229 5230 OPTION_ORO 6 5231 5232 OPTION_PREFERENCE 7 5233 5234 OPTION_ELAPSED_TIME 8 5235 5236 OPTION_RELAY_MSG 9 5237 5238 OPTION_AUTH 11 5239 5240 OPTION_UNICAST 12 5241 5242 OPTION_STATUS_CODE 13 5243 5244 OPTION_RAPID_COMMIT 14 5245 5246 OPTION_USER_CLASS 15 5247 5248 OPTION_VENDOR_CLASS 16 5249 5250 OPTION_VENDOR_OPTS 17 5251 5252 OPTION_INTERFACE_ID 18 5253 5254 OPTION_RECONF_MSG 19 5255 5256 OPTION_RECONF_ACCEPT 20 5257 5258 5259 5260 5261 5262 5263 5264 5265 5266Droms, et al. Standards Track [Page 94] 5267 5268RFC 3315 DHCP for IPv6 July 2003 5269 5270 527124.4. Status Codes 5272 5273 IANA has recorded the status codes defined in the following table. 5274 IANA will manage the definition of additional status codes in the 5275 future. 5276 5277 Name Code Description 5278 ---------- ---- ----------- 5279 Success 0 Success. 5280 UnspecFail 1 Failure, reason unspecified; this 5281 status code is sent by either a client 5282 or a server to indicate a failure 5283 not explicitly specified in this 5284 document. 5285 NoAddrsAvail 2 Server has no addresses available to assign to 5286 the IA(s). 5287 NoBinding 3 Client record (binding) unavailable. 5288 NotOnLink 4 The prefix for the address is not appropriate for 5289 the link to which the client is attached. 5290 UseMulticast 5 Sent by a server to a client to force the 5291 client to send messages to the server. 5292 using the All_DHCP_Relay_Agents_and_Servers 5293 address. 5294 529524.5. DUID 5296 5297 IANA has recorded the following DUID types (as defined in section 5298 9.1). IANA will manage the definition of additional DUID types in 5299 the future. 5300 5301 DUID-LLT 1 5302 5303 DUID-EN 2 5304 5305 DUID-LL 3 5306 530725. Acknowledgments 5308 5309 Thanks to the DHC Working Group and the members of the IETF for their 5310 time and input into the specification. In particular, thanks also 5311 for the consistent input, ideas, and review by (in alphabetical 5312 order) Bernard Aboba, Bill Arbaugh, Thirumalesh Bhat, Steve Bellovin, 5313 A. K. Vijayabhaskar, Brian Carpenter, Matt Crawford, Francis Dupont, 5314 Richard Hussong, Kim Kinnear, Fredrik Lindholm, Tony Lindstrom, Josh 5315 Littlefield, Gerald Maguire, Jack McCann, Shin Miyakawa, Thomas 5316 Narten, Erik Nordmark, Jarno Rajahalme, Yakov Rekhter, Mark Stapp, 5317 Matt Thomas, Sue Thomson, Tatuya Jinmei and Phil Wells. 5318 5319 5320 5321 5322Droms, et al. Standards Track [Page 95] 5323 5324RFC 3315 DHCP for IPv6 July 2003 5325 5326 5327 Thanks to Steve Deering and Bob Hinden, who have consistently taken 5328 the time to discuss the more complex parts of the IPv6 5329 specifications. 5330 5331 And, thanks to Steve Deering for pointing out at IETF 51 in London 5332 that the DHCPv6 specification has the highest revision number of any 5333 Internet Draft. 5334 533526. References 5336 533726.1. Normative References 5338 5339 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 5340 Levels", BCP 14, RFC 2119, March 1997. 5341 5342 [2] Crawford, M., "Transmission of IPv6 Packets over Ethernet 5343 Networks", RFC 2464, December 1998. 5344 5345 [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 5346 Specification", RFC 2460, December 1998. 5347 5348 [4] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for DHCP 5349 Messages", RFC 3118, June 2001. 5350 5351 [5] Hinden, R. and S. Deering, "IP Version 6 Addressing 5352 Architecture", RFC 2373, July 1998. 5353 5354 [6] IANA. Private Enterprise Numbers. 5355 http://www.iana.org/assignments/enterprise-numbers.html. 5356 5357 [7] Kent, S. and R. Atkinson, "Security Architecture for the 5358 Internet Protocol", RFC 2401, November 1998. 5359 5360 [8] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 5361 for Message Authentication", RFC 2104, February 1997. 5362 5363 [9] Mills, D., "Network Time Protocol (Version 3) Specification, 5364 Implementation", RFC 1305, March 1992. 5365 5366 [10] Mockapetris, P., "Domain names - implementation and 5367 specification", RFC 1035, November 1987. 5368 5369 [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 5370 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 5371 5372 [12] Narten, T. and R. Draves, "Privacy Extensions for Stateless 5373 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 5374 5375 5376 5377 5378Droms, et al. Standards Track [Page 96] 5379 5380RFC 3315 DHCP for IPv6 July 2003 5381 5382 5383 [13] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 5384 IP Version 6 (IPv6)", RFC 2461, December 1998. 5385 5386 [14] Plummer, D.C., "Ethernet Address Resolution Protocol: Or 5387 converting network protocol addresses to 48.bit Ethernet address 5388 for transmission on Ethernet hardware", STD 37, RFC 826, 5389 November 1982. 5390 5391 [15] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 5392 1980. 5393 5394 [16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 5395 1992. 5396 5397 [17] Thomson, S. and T. Narten, "IPv6 Stateless Address 5398 Autoconfiguration", RFC 2462, December 1998. 5399 540026.2. Informative References 5401 5402 [18] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 5403 Extensions", RFC 2132, March 1997. 5404 5405 [19] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 5406 March 1997. 5407 5408 [20] R. Droms, Ed. DNS Configuration options for DHCPv6. April 5409 2002. Work in Progress. 5410 5411 [21] A. K. Vijayabhaskar. Time Configuration Options for DHCPv6. 5412 May 2002. Work in Progress. 5413 5414 [22] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 5415 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 5416 1997. 5417 5418 5419 5420 5421 5422 5423 5424 5425 5426 5427 5428 5429 5430 5431 5432 5433 5434Droms, et al. Standards Track [Page 97] 5435 5436RFC 3315 DHCP for IPv6 July 2003 5437 5438 5439A. Appearance of Options in Message Types 5440 5441 The following table indicates with a "*" the options are allowed in 5442 each DHCP message type: 5443 5444 Client Server IA_NA Option Pref Time Relay Auth. Server 5445 ID ID IA_TA Request Msg. Unica. 5446 Solicit * * * * * 5447 Advert. * * * * * 5448 Request * * * * * * 5449 Confirm * * * * * 5450 Renew * * * * * * 5451 Rebind * * * * * 5452 Decline * * * * * * 5453 Release * * * * * * 5454 Reply * * * * * * 5455 Reconf. * * * * 5456 Inform. * (see note) * * * 5457 R-forw. * * 5458 R-repl. * * 5459 5460 NOTE: 5461 5462 Only included in Information-Request messages that are sent 5463 in response to a Reconfigure (see section 19.4.3). 5464 5465 Status Rap. User Vendor Vendor Inter. Recon. Recon. 5466 Code Comm. Class Class Spec. ID Msg. Accept 5467 Solicit * * * * * 5468 Advert. * * * * * 5469 Request * * * * 5470 Confirm * * * 5471 Renew * * * * 5472 Rebind * * * * 5473 Decline * * * 5474 Release * * * 5475 Reply * * * * * * 5476 Reconf. * 5477 Inform. * * * * 5478 R-forw. * * * * 5479 R-repl. * * * * 5480 5481 5482 5483 5484 5485 5486 5487 5488 5489 5490Droms, et al. Standards Track [Page 98] 5491 5492RFC 3315 DHCP for IPv6 July 2003 5493 5494 5495B. Appearance of Options in the Options Field of DHCP Options 5496 5497 The following table indicates with a "*" where options can appear in 5498 the options field of other options: 5499 5500 Option IA_NA/ IAADDR Relay Relay 5501 Field IA_TA Forw. Reply 5502 Client ID * 5503 Server ID * 5504 IA_NA/IA_TA * 5505 IAADDR * 5506 ORO * 5507 Preference * 5508 Elapsed Time * 5509 Relay Message * * 5510 Authentic. * 5511 Server Uni. * 5512 Status Code * * * 5513 Rapid Comm. * 5514 User Class * 5515 Vendor Class * 5516 Vendor Info. * 5517 Interf. ID * * 5518 Reconf. MSG. * 5519 Reconf. Accept * 5520 5521 Note: "Relay Forw" / "Relay Reply" options appear in the options 5522 field of the message but may only appear in these messages. 5523 5524Chair's Address 5525 5526 The working group can be contacted via the current chair: 5527 5528 Ralph Droms 5529 Cisco Systems 5530 1414 Massachusetts Avenue 5531 Boxborough, MA 01719 5532 5533 Phone: (978) 936-1674 5534 EMail: rdroms@cisco.com 5535 5536 5537 5538 5539 5540 5541 5542 5543 5544 5545 5546Droms, et al. Standards Track [Page 99] 5547 5548RFC 3315 DHCP for IPv6 July 2003 5549 5550 5551Authors' Addresses 5552 5553 Jim Bound 5554 Hewlett Packard Corporation 5555 ZK3-3/W20 5556 110 Spit Brook Road 5557 Nashua, NH 03062-2698 5558 USA 5559 5560 Phone: +1 603 884 0062 5561 EMail: Jim.Bound@hp.com 5562 5563 Bernie Volz 5564 116 Hawkins Pond Road 5565 Center Harbor, NH 03226-3103 5566 USA 5567 5568 Phone: +1-508-259-3734 5569 EMail: volz@metrocast.net 5570 5571 Ted Lemon 5572 Nominum, Inc. 5573 950 Charter Street 5574 Redwood City, CA 94043 5575 USA 5576 5577 EMail: Ted.Lemon@nominum.com 5578 5579 Charles E. Perkins 5580 Communications Systems Lab 5581 Nokia Research Center 5582 313 Fairchild Drive 5583 Mountain View, California 94043 5584 USA 5585 5586 Phone: +1-650 625-2986 5587 EMail: charles.perkins@nokia.com 5588 5589 Mike Carney 5590 Sun Microsystems, Inc 5591 17 Network Circle 5592 Menlo Park, CA 94025 5593 USA 5594 5595 Phone: +1-650-786-4171 5596 EMail: michael.carney@sun.com 5597 5598 5599 5600 5601 5602Droms, et al. Standards Track [Page 100] 5603 5604RFC 3315 DHCP for IPv6 July 2003 5605 5606 5607Full Copyright Statement 5608 5609 Copyright (C) The Internet Society (2003). All Rights Reserved. 5610 5611 This document and translations of it may be copied and furnished to 5612 others, and derivative works that comment on or otherwise explain it 5613 or assist in its implementation may be prepared, copied, published 5614 and distributed, in whole or in part, without restriction of any 5615 kind, provided that the above copyright notice and this paragraph are 5616 included on all such copies and derivative works. However, this 5617 document itself may not be modified in any way, such as by removing 5618 the copyright notice or references to the Internet Society or other 5619 Internet organizations, except as needed for the purpose of 5620 developing Internet standards in which case the procedures for 5621 copyrights defined in the Internet Standards process must be 5622 followed, or as required to translate it into languages other than 5623 English. 5624 5625 The limited permissions granted above are perpetual and will not be 5626 revoked by the Internet Society or its successors or assigns. 5627 5628 This document and the information contained herein is provided on an 5629 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 5630 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 5631 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 5632 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 5633 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5634 5635Acknowledgement 5636 5637 Funding for the RFC Editor function is currently provided by the 5638 Internet Society. 5639 5640 5641 5642 5643 5644 5645 5646 5647 5648 5649 5650 5651 5652 5653 5654 5655 5656 5657 5658Droms, et al. Standards Track [Page 101] 5659 5660