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