idnits 2.17.1 draft-ietf-dhc-dhcpv6-27.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 92 longer pages, the longest (page 0) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. -- The draft header indicates that this document obsoletes draft-ietf-dhc-dhcpv6-26.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 473 has weird spacing: '...he link an a...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- No information found for rfcdraft-ietf-dhc-dhcpv6-26.txt - is the name correct? -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 Oct 2003) is 7491 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'DUID-LLT' on line 910 -- Looks like a reference, but probably isn't: 'DUID-EN' on line 971 -- Looks like a reference, but probably isn't: 'DUID-LL' on line 1012 ** Obsolete normative reference: RFC 2460 (ref. '4') (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2373 (ref. '8') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 2401 (ref. '10') (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '11') ** Obsolete normative reference: RFC 1305 (ref. '12') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2434 (ref. '14') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3041 (ref. '15') (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 2461 (ref. '16') (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '19') ** Obsolete normative reference: RFC 2462 (ref. '20') (Obsoleted by RFC 4862) -- Possible downref: Non-RFC (?) normative reference: ref. '21' Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force R. Droms (ed.), Cisco 2 INTERNET DRAFT J. Bound, Hewlett Packard 3 DHC Working Group Bernie Volz, Ericsson 4 Obsoletes: draft-ietf-dhc-dhcpv6-26.txt Ted Lemon, Nominum 5 C. Perkins, Nokia Research Center 6 M. Carney, Sun Microsystems 7 22 Oct 2003 9 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 10 draft-ietf-dhc-dhcpv6-27.txt 12 Status of This Memo 14 This document is a submission by the Dynamic Host Configuration 15 Working Group of the Internet Engineering Task Force (IETF). Comments 16 should be submitted to the dhcwg@ietf.org mailing list. 18 Distribution of this memo is unlimited. 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at 28 any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at: 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 Abstract 38 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables 39 DHCP servers to pass configuration parameters such as IPv6 network 40 addresses to IPv6 nodes. It offers the capability of automatic 41 allocation of reusable network addresses and additional configuration 42 flexibility. This protocol is a stateful counterpart to "IPv6 43 Stateless Address Autoconfiguration" (RFC2462), and can be used 44 separately or concurrently with the latter to obtain configuration 45 parameters. 47 Contents 49 Status of This Memo i 51 Abstract i 53 1. Introduction and Overview 1 54 1.1. Protocols and Addressing . . . . . . . . . . . . . . . . 1 55 1.2. Client-server Exchanges Involving Two Messages . . . . . 2 56 1.3. Client-server Exchanges Involving Four Messages . . . . . 2 58 2. Requirements 3 60 3. Background 3 62 4. Terminology 4 63 4.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 4 64 4.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 5 66 5. DHCP Constants 7 67 5.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 7 68 5.2. UDP Ports . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.3. DHCP Message Types . . . . . . . . . . . . . . . . . . . 8 70 5.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 10 71 5.5. Transmission and Retransmission Parameters . . . . . . . 10 73 6. Client/Server Message Formats 11 75 7. Relay Agent/Server Message Formats 11 76 7.1. Relay-forward Message . . . . . . . . . . . . . . . . . . 12 77 7.2. Relay-reply Message . . . . . . . . . . . . . . . . . . . 13 79 8. Representation and Use of Domain Names 13 81 9. DHCP Unique Identifier (DUID) 13 82 9.1. DUID Contents . . . . . . . . . . . . . . . . . . . . . . 14 83 9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT] . . 14 84 9.3. DUID Assigned by Vendor Based on Enterprise Number 85 [DUID-EN] . . . . . . . . . . . . . . . . . . . . . . 15 86 9.4. DUID Based on Link-layer Address [DUID-LL] . . . . . . . 16 88 10. Identity Association 17 90 11. Selecting Addresses for Assignment to an IA 17 92 12. Management of Temporary Addresses 18 94 13. Transmission of Messages by a Client 19 96 14. Reliability of Client Initiated Message Exchanges 19 98 15. Message Validation 21 99 15.1. Use of Transaction IDs . . . . . . . . . . . . . . . . . 21 100 15.2. Solicit Message . . . . . . . . . . . . . . . . . . . . . 21 101 15.3. Advertise Message . . . . . . . . . . . . . . . . . . . . 21 102 15.4. Request Message . . . . . . . . . . . . . . . . . . . . . 22 103 15.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 22 104 15.6. Renew Message . . . . . . . . . . . . . . . . . . . . . . 22 105 15.7. Rebind Message . . . . . . . . . . . . . . . . . . . . . 22 106 15.8. Decline Messages . . . . . . . . . . . . . . . . . . . . 23 107 15.9. Release Message . . . . . . . . . . . . . . . . . . . . . 23 108 15.10. Reply Message . . . . . . . . . . . . . . . . . . . . . . 23 109 15.11. Reconfigure Message . . . . . . . . . . . . . . . . . . . 24 110 15.12. Information-request Message . . . . . . . . . . . . . . . 24 111 15.13. Relay-forward Message . . . . . . . . . . . . . . . . . . 24 112 15.14. Relay-reply Message . . . . . . . . . . . . . . . . . . . 24 114 16. Client Source Address and Interface Selection 25 116 17. DHCP Server Solicitation 25 117 17.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 25 118 17.1.1. Creation of Solicit Messages . . . . . . . . . . 25 119 17.1.2. Transmission of Solicit Messages . . . . . . . . 26 120 17.1.3. Receipt of Advertise Messages . . . . . . . . . . 27 121 17.1.4. Receipt of Reply Message . . . . . . . . . . . . 28 122 17.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 28 123 17.2.1. Receipt of Solicit Messages . . . . . . . . . . . 28 124 17.2.2. Creation and Transmission of Advertise Messages . 29 125 17.2.3. Creation and Transmission of Reply Messages . . . 30 127 18. DHCP Client-Initiated Configuration Exchange 31 128 18.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 31 129 18.1.1. Creation and Transmission of Request Messages . . 31 130 18.1.2. Creation and Transmission of Confirm Messages . . 32 131 18.1.3. Creation and Transmission of Renew Messages . . . 33 132 18.1.4. Creation and Transmission of Rebind Messages . . 34 133 18.1.5. Creation and Transmission of Information-request 134 Messages . . . . . . . . . . . . . . . . . 35 135 18.1.6. Creation and Transmission of Release Messages . . 36 136 18.1.7. Creation and Transmission of Decline Messages . . 37 137 18.1.8. Receipt of Reply Messages . . . . . . . . . . . . 38 138 18.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 39 139 18.2.1. Receipt of Request Messages . . . . . . . . . . . 40 140 18.2.2. Receipt of Confirm Messages . . . . . . . . . . . 41 141 18.2.3. Receipt of Renew Messages . . . . . . . . . . . . 41 142 18.2.4. Receipt of Rebind Messages . . . . . . . . . . . 42 143 18.2.5. Receipt of Information-request Messages . . . . . 42 144 18.2.6. Receipt of Release Messages . . . . . . . . . . . 43 145 18.2.7. Receipt of Decline Messages . . . . . . . . . . . 44 146 18.2.8. Transmission of Reply Messages . . . . . . . . . 44 148 19. DHCP Server-Initiated Configuration Exchange 44 149 19.1. Server Behavior . . . . . . . . . . . . . . . . . . . . . 45 150 19.1.1. Creation and Transmission of Reconfigure Messages 45 151 19.1.2. Time Out and Retransmission of Reconfigure 152 Messages . . . . . . . . . . . . . . . . . 46 153 19.2. Receipt of Renew Messages . . . . . . . . . . . . . . . . 46 154 19.3. Receipt of Information-request Messages . . . . . . . . . 46 155 19.4. Client Behavior . . . . . . . . . . . . . . . . . . . . . 47 156 19.4.1. Receipt of Reconfigure Messages . . . . . . . . . 47 157 19.4.2. Creation and Transmission of Renew Messages . . . 48 158 19.4.3. Creation and Transmission of Information-request 159 Messages . . . . . . . . . . . . . . . . . 48 160 19.4.4. Time Out and Retransmission of Renew or 161 Information-request Messages . . . . . . . 48 162 19.4.5. Receipt of Reply Messages . . . . . . . . . . . . 48 164 20. Relay Agent Behavior 48 165 20.1. Relaying a Client Message or a Relay-forward Message . . 49 166 20.1.1. Relaying a Message from a Client . . . . . . . . 49 167 20.1.2. Relaying a Message from a Relay Agent . . . . . . 49 168 20.2. Relaying a Relay-reply Message . . . . . . . . . . . . . 50 169 20.3. Construction of Relay-reply Messages . . . . . . . . . . 50 171 21. Authentication of DHCP Messages 51 172 21.1. Security of Messages Sent Between Servers and Relay Agents 51 173 21.2. Summary of DHCP Authentication . . . . . . . . . . . . . 52 174 21.3. Replay Detection . . . . . . . . . . . . . . . . . . . . 52 175 21.4. Delayed Authentication Protocol . . . . . . . . . . . . . 52 176 21.4.1. Use of the Authentication Option in the Delayed 177 Authentication Protocol . . . . . . . . . 53 178 21.4.2. Message Validation . . . . . . . . . . . . . . . 54 179 21.4.3. Key Utilization . . . . . . . . . . . . . . . . . 54 180 21.4.4. Client Considerations for Delayed Authentication 181 Protocol . . . . . . . . . . . . . . . . . 54 182 21.4.5. Server Considerations for Delayed Authentication 183 Protocol . . . . . . . . . . . . . . . . . 56 184 21.5. Reconfigure Key Authentication Protocol . . . . . . . . . 57 185 21.5.1. Use of the Authentication Option in the Reconfigure 186 Key Authentication Protocol . . . . . . . 57 187 21.5.2. Server considerations for Reconfigure Key protocol 58 188 21.5.3. Client considerations for Reconfigure Key protocol 58 190 22. DHCP Options 58 191 22.1. Format of DHCP Options . . . . . . . . . . . . . . . . . 59 192 22.2. Client Identifier Option . . . . . . . . . . . . . . . . 59 193 22.3. Server Identifier Option . . . . . . . . . . . . . . . . 60 194 22.4. Identity Association for Non-temporary Addresses Option . 60 195 22.5. Identity Association for Temporary Addresses Option . . . 62 196 22.6. IA Address Option . . . . . . . . . . . . . . . . . . . . 64 197 22.7. Option Request Option . . . . . . . . . . . . . . . . . . 65 198 22.8. Preference Option . . . . . . . . . . . . . . . . . . . . 65 199 22.9. Elapsed Time Option . . . . . . . . . . . . . . . . . . . 66 200 22.10. Relay Message Option . . . . . . . . . . . . . . . . . . 67 201 22.11. Authentication Option . . . . . . . . . . . . . . . . . . 67 202 22.12. Server Unicast Option . . . . . . . . . . . . . . . . . . 68 203 22.13. Status Code Option . . . . . . . . . . . . . . . . . . . 69 204 22.14. Rapid Commit Option . . . . . . . . . . . . . . . . . . . 69 205 22.15. User Class Option . . . . . . . . . . . . . . . . . . . . 70 206 22.16. Vendor Class Option . . . . . . . . . . . . . . . . . . . 71 207 22.17. Vendor-specific Information Option . . . . . . . . . . . 72 208 22.18. Interface-Id Option . . . . . . . . . . . . . . . . . . . 74 209 22.19. Reconfigure Message Option . . . . . . . . . . . . . . . 75 210 22.20. Reconfigure Accept Option . . . . . . . . . . . . . . . . 75 212 23. Security Considerations 76 214 24. IANA Considerations 77 215 24.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 78 216 24.2. DHCP Message Types . . . . . . . . . . . . . . . . . . . 78 217 24.3. DHCP Options . . . . . . . . . . . . . . . . . . . . . . 79 218 24.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 80 219 24.5. DUID . . . . . . . . . . . . . . . . . . . . . . . . . . 80 221 25. Acknowledgments 80 223 26. Changes in draft-ietf-dhc-dhcpv6-27.txt 81 225 References 82 227 Chair's Address 83 229 Authors' Addresses 84 231 A. Appearance of Options in Message Types 85 233 B. Appearance of Options in the Options Field of DHCP Options 85 235 C. Full Copyright Statement 86 237 1. Introduction and Overview 239 This document describes DHCP for IPv6 (DHCP), a client/server 240 protocol that provides managed configuration of devices. 242 DHCP can provide a device with addresses assigned by a DHCP server 243 and other configuration information, which are carried in options. 244 DHCP can be extended through the definition of new options to carry 245 configuration information not specified in this document. 247 DHCP is the "stateful address autoconfiguration protocol" and the 248 "stateful autoconfiguration protocol" referred to in "IPv6 Stateless 249 Address Autoconfiguration" [20]. 251 The operational models and relevant configuration information for 252 DHCPv4 [1][5] and DHCPv6 are sufficiently different that integration 253 between the two services is not included in this document. If there 254 is sufficient interest and demand, integration can be specified 255 in a document that extends DHCPv6 to carry IPv4 addresses and 256 configuration information. 258 The remainder of this introduction summarizes DHCP, explaining 259 the message exchange mechanisms and example message flows. The 260 message flows in sections 1.2 and 1.3 are intended as illustrations 261 of DHCP operation rather than an exhaustive list of all possible 262 client-server interactions. Sections 17, 18 and 19 explain client 263 and server operation in detail. 265 1.1. Protocols and Addressing 267 Clients and servers exchange DHCP messages using UDP [18]. The 268 client uses a link-local address or addresses determined through 269 other mechanisms for transmitting and receiving DHCP messages. 271 DHCP servers receive messages from clients using a reserved, 272 link-scoped multicast address. A DHCP client transmits most messages 273 to this reserved multicast address, so that the client need not be 274 configured with the address or addresses of DHCP servers. 276 To allow a DHCP client to send a message to a DHCP server that is not 277 attached to the same link, a DHCP relay agent on the client's link 278 will relay messages between the client and server. The operation 279 of the relay agent is transparent to the client and the discussion 280 of message exchanges in the remainder of this section will omit the 281 description of message relaying by relay agents. 283 Once the client has determined the address of a server, it may 284 under some circumstances send messages directly to the server using 285 unicast. 287 1.2. Client-server Exchanges Involving Two Messages 289 When a DHCP client does not need to have a DHCP server assign 290 it IP addresses, the client can obtain configuration information 291 such as a list of available DNS servers [7] or NTP servers [21] 292 through a single message and reply exchanged with a DHCP server. 293 To obtain configuration information the client first sends an 294 Information-Request message to the All_DHCP_Relay_Agents_and_Servers 295 multicast address. Servers respond with a Reply message containing 296 the configuration information for the client. 298 This message exchange assumes that the client requires only 299 configuration information and does not require the assignment of any 300 IPv6 addresses. 302 When a server has IPv6 addresses and other configuration information 303 committed to a client, the client and server may be able to complete 304 the exchange using only two messages, instead of four messages as 305 described in the next section. In this case, the client sends a 306 Solicit message to the All_DHCP_Relay_Agents_and_Servers requesting 307 the assignment of addresses and other configuration information. 308 This message includes an indication that the client is willing to 309 accept an immediate Reply message from the server. The server that 310 is willing to commit the assignment of addresses to the client 311 immediately responds with a Reply message. The configuration 312 information and the addresses in the Reply message are then 313 immediately available for use by the client. 315 Each address assigned to the client has associated preferred and 316 valid lifetimes specified by the server. To request an extension 317 of the lifetimes assigned to an address, the client sends a Renew 318 message to the server. The server sends a Reply message to the 319 client with the new lifetimes, allowing the client to continue to use 320 the address without interruption. 322 1.3. Client-server Exchanges Involving Four Messages 324 To request the assignment of one or more IPv6 addresses, a 325 client first locates a DHCP server and then requests the 326 assignment of addresses and other configuration information 327 from the server. The client sends a Solicit message to the 328 All_DHCP_Relay_Agents_and_Servers address to find available DHCP 329 servers. Any server that can meet the client's requirements 330 responds with an Advertise message. The client then chooses one 331 of the servers and sends a Request message to the server asking 332 for confirmed assignment of addresses and other configuration 333 information. The server responds with a Reply message that contains 334 the confirmed addresses and configuration. 336 As described in the previous section, the client sends a Renew 337 messages to the server to extend the lifetimes associated with its 338 addresses, allowing the client to continue to use those addresses 339 without interruption. 341 2. Requirements 343 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 344 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 345 document, are to be interpreted as described in [2]. 347 This document also makes use of internal conceptual variables 348 to describe protocol behavior and external variables that an 349 implementation must allow system administrators to change. The 350 specific variable names, how their values change, and how their 351 settings influence protocol behavior are provided to demonstrate 352 protocol behavior. An implementation is not required to have them in 353 the exact form described here, so long as its external behavior is 354 consistent with that described in this document. 356 3. Background 358 The IPv6 Specification provides the base architecture and design of 359 IPv6. Related work in IPv6 that would best serve an implementor 360 to study includes the IPv6 Specification [4], the IPv6 Addressing 361 Architecture [8], IPv6 Stateless Address Autoconfiguration [20], IPv6 362 Neighbor Discovery Processing [16], and Dynamic Updates to DNS [22]. 363 These specifications enable DHCP to build upon the IPv6 work to 364 provide both robust stateful autoconfiguration and autoregistration 365 of DNS Host Names. 367 The IPv6 Addressing Architecture specification [8] defines the 368 address scope that can be used in an IPv6 implementation, and the 369 various configuration architecture guidelines for network designers 370 of the IPv6 address space. Two advantages of IPv6 are that support 371 for multicast is required and nodes can create link-local addresses 372 during initialization. The availability of these features means that 373 a client can use its link-local address and a well-known multicast 374 address to discover and communicate with DHCP servers or relay agents 375 on its link. 377 IPv6 Stateless Address Autoconfiguration [20] specifies procedures 378 by which a node may autoconfigure addresses based on router 379 advertisements [16], and the use of a valid lifetime to support 380 renumbering of addresses on the Internet. In addition the 381 protocol interaction by which a node begins stateless or stateful 382 autoconfiguration is specified. DHCP is one vehicle to perform 383 stateful autoconfiguration. Compatibility with stateless address 384 autoconfiguration is a design requirement of DHCP. 386 IPv6 Neighbor Discovery [16] is the node discovery protocol in IPv6 387 which replaces and enhances functions of ARP [17]. To understand 388 IPv6 and stateless address autoconfiguration it is strongly 389 recommended that implementors understand IPv6 Neighbor Discovery. 391 Dynamic Updates to DNS [22] is a specification that supports the 392 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 393 the dynamic updates to DNS to integrate addresses and name space to 394 not only support autoconfiguration, but also autoregistration in 395 IPv6. 397 4. Terminology 399 This sections defines terminology specific to IPv6 and DHCP used in 400 this document. 402 4.1. IPv6 Terminology 404 IPv6 terminology relevant to this specification from the IPv6 405 Protocol [4], IPv6 Addressing Architecture [8], and IPv6 Stateless 406 Address Autoconfiguration [20] is included below. 408 address An IP layer identifier for an interface 409 or a set of interfaces. 411 host Any node that is not a router. 413 IP Internet Protocol Version 6 (IPv6). The 414 terms IPv4 and IPv6 are used only in 415 contexts where it is necessary to avoid 416 ambiguity. 418 interface A node's attachment to a link. 420 link A communication facility or medium over 421 which nodes can communicate at the link 422 layer, i.e., the layer immediately 423 below IP. Examples are Ethernet (simple 424 or bridged); Token Ring; PPP links, 425 X.25, Frame Relay, or ATM networks; and 426 Internet (or higher) layer "tunnels", 427 such as tunnels over IPv4 or IPv6 428 itself. 430 link-layer identifier A link-layer identifier for an 431 interface. Examples include IEEE 802 432 addresses for Ethernet or Token Ring 433 network interfaces, and E.164 addresses 434 for ISDN links. 436 link-local address An IPv6 address having link-only 437 scope, indicated by having the prefix 438 (FE80::/10), that can be used to reach 439 neighboring nodes attached to the same 440 link. Every interface has a link-local 441 address. 443 multicast address An identifier for a set of interfaces 444 (typically belonging to different 445 nodes). A packet sent to a multicast 446 address is delivered to all interfaces 447 identified by that address. 449 neighbor A node attached to the same link. 451 node A device that implements IP. 453 packet An IP header plus payload. 455 prefix The initial bits of an address, or a 456 set of IP addresses that share the same 457 initial bits. 459 prefix length The number of bits in a prefix. 461 router A node that forwards IP packets not 462 explicitly addressed to itself. 464 unicast address An identifier for a single interface. 465 A packet sent to a unicast address is 466 delivered to the interface identified by 467 that address. 469 4.2. DHCP Terminology 471 Terminology specific to DHCP can be found below. 473 appropriate to the link an address is "appropriate to the link" 474 when the address is consistent with the 475 DHCP server's knowledge of the network 476 topology, prefix assignment and address 477 assignment policies. 479 binding A binding (or, client binding) is a 480 group of server data records containing 481 the information the server has about 482 the addresses in an IA or configuration 483 information explicitly assigned to the 484 client. Configuration information that 485 has been returned to a client through a 486 policy - for example, the information 487 returned to all clients on the same 488 link - does not require a binding. A 489 binding containing information about 490 an IA is indexed by the tuple (where IA-type is the 492 type of address in the IA; for example, 493 temporary). A binding containing 494 configuration information for a client 495 is indexed by . 497 configuration parameter An element of the configuration 498 information set on the server and 499 delivered to the client using DHCP. 500 Such parameters may be used to carry 501 information to be used by a node to 502 configure its network subsystem and 503 enable communication on a link or 504 internetwork, for example. 506 DHCP Dynamic Host Configuration Protocol 507 for IPv6. The terms DHCPv4 and DHCPv6 508 are used only in contexts where it is 509 necessary to avoid ambiguity. 511 DHCP client (or client) A node that initiates requests on a link 512 to obtain configuration parameters from 513 one or more DHCP servers. 515 DHCP domain A set of links managed by DHCP and 516 operated by a single administrative 517 entity. 519 DHCP realm A names used to identify the DHCP 520 administrative domain from which a DHCP 521 authentication key was selected. 523 DHCP relay agent (or relay agent) A node that acts as an 524 intermediary to deliver DHCP messages 525 between clients and servers, and is on 526 the same link as the client. 528 DHCP server (or server) A node that responds to requests from 529 clients, and may or may not be on the 530 same link as the client(s). 532 DUID A DHCP Unique IDentifier for a DHCP 533 participant; each DHCP client and server 534 has exactly one DUID. See section 9 for 535 details of the ways in which a DUID may 536 be constructed. 538 Identity association (IA) A collection of addresses assigned to 539 a client. Each IA has an associated 540 IAID. A client may have more than one 541 IA assigned to it; for example, one for 542 each of its interfaces. 544 Each IA holds one type of address; 545 for example, an identity association 546 for temporary addresses (IA_TA) holds 547 temporary addresses (see "identity 548 association for temporary addresses"). 549 Throughout this document, "IA" is used 550 to refer to an identity association 551 without identifying the type of 552 addresses in the IA. 554 Identity association identifier (IAID) An identifier for an IA, 555 chosen by the client. Each IA has an 556 IAID, which is chosen to be unique among 557 all IAIDs for IAs belonging to that 558 client. 560 Identity association for non-temporary addresses (IA_NA) An IA 561 that carries assigned addresses that are 562 not temporary addresses (see "identity 563 association for temporary addresses") 565 Identity association for temporary addresses (IA_TA) An IA that 566 carries temporary addresses (see RFC 567 3041 [15]). 569 message A unit of data carried as the payload 570 of a UDP datagram, exchanged among DHCP 571 servers, relay agents and clients. 573 Reconfigure key An key supplied to a client by a server 574 used to provide security for Reconfigure 575 messages. 577 relaying A DHCP relay agent relays DHCP messages 578 between DHCP participants. 580 transaction ID An opaque value used to match responses 581 with replies initiated either by a 582 client or server. 584 5. DHCP Constants 586 This section describes various program and networking constants used 587 by DHCP. 589 5.1. Multicast Addresses 591 DHCP makes use of the following multicast addresses: 593 All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped 594 multicast address used by a client to communicate with 595 neighboring (i.e., on-link) relay agents and servers. 596 All servers and relay agents are members of this 597 multicast group. 599 All_DHCP_Servers (FF05::1:3) A site-scoped multicast address used 600 by a relay agent to communicate with servers, either 601 because the relay agent wants to send messages to 602 all servers or because it does not know the unicast 603 addresses of the servers. Note that in order for 604 a relay agent to use this address, it must have an 605 address of sufficient scope to be reachable by the 606 servers. All servers within the site are members of 607 this multicast group. 609 5.2. UDP Ports 611 Clients listen for DHCP messages on UDP port 546. Servers and relay 612 agents listen for DHCP messages on UDP port 547. 614 5.3. DHCP Message Types 616 DHCP defines the following message types. More detail on these 617 message types can be found in sections 6 and 7. Message types not 618 listed here are reserved for future use. The numeric encoding for 619 each message type is shown in parentheses. 621 SOLICIT (1) A client sends a Solicit message to locate 622 servers. 624 ADVERTISE (2) A server sends an Advertise message to indicate 625 that it is available for DHCP service, in 626 response to a Solicit message received from a 627 client. 629 REQUEST (3) A client sends a Request message to request 630 configuration parameters, including IP 631 addresses, from a specific server. 633 CONFIRM (4) A client sends a Confirm message to any 634 available server to determine whether the 635 addresses it was assigned are still appropriate 636 to the link to which the client is connected. 638 RENEW (5) A client sends a Renew message to the server 639 that originally provided the client's addresses 640 and configuration parameters to extend the 641 lifetimes on the addresses assigned to the 642 client and to update other configuration 643 parameters. 645 REBIND (6) A client sends a Rebind message to any 646 available server to extend the lifetimes on the 647 addresses assigned to the client and to update 648 other configuration parameters; this message is 649 sent after a client receives no response to a 650 Renew message. 652 REPLY (7) A server sends a Reply message containing 653 assigned addresses and configuration parameters 654 in response to a Solicit, Request, Renew, 655 Rebind message received from a client. A 656 server sends a Reply message containing 657 configuration parameters in response to an 658 Information-request message. A server sends a 659 Reply message in response to a Confirm message 660 confirming or denying that the addresses 661 assigned to the client are appropriate to the 662 link to which the client is connected. A 663 server sends a Reply message to acknowledge 664 receipt of a Release or Decline message. 666 RELEASE (8) A client sends a Release message to the server 667 that assigned addresses to the client to 668 indicate that the client will no longer use one 669 or more of the assigned addresses. 671 DECLINE (9) A client sends a Decline message to a server to 672 indicate that the client has determined that 673 one or more addresses assigned by the server 674 are already in use on the link to which the 675 client is connected. 677 RECONFIGURE (10) A server sends a Reconfigure message to a 678 client to inform the client that the server has 679 new or updated configuration parameters, and 680 that the client is to initiate a Renew/Reply 681 or Information-request/Reply transaction with 682 the server in order to receive the updated 683 information. 685 INFORMATION-REQUEST (11) A client sends an Information-request 686 message to a server to request configuration 687 parameters without the assignment of any IP 688 addresses to the client. 690 RELAY-FORW (12) A relay agent sends a Relay-forward message 691 to relay messages to servers, either directly 692 or through another relay agent. The received 693 message, either a client message or a 694 Relay-forward message from another relay 695 agent, is encapsulated in an option in the 696 Relay-forward message. 698 RELAY-REPL (13) A server sends a Relay-reply message to a relay 699 agent containing a message that the relay 700 agent delivers to a client. The Relay-reply 701 message may be relayed by other relay agents 702 for delivery to the destination relay agent. 703 The server encapsulates the client message as 704 an option in the Relay-reply message, which the 705 relay agent extracts and relays to the client. 707 5.4. Status Codes 709 DHCPv6 uses status codes to communicate the success or failure of 710 operations requested in messages from clients and servers, and to 711 provide additional information about the specific cause of the 712 failure of a message. The specific status codes are defined in 713 section 24.4. 715 5.5. Transmission and Retransmission Parameters 717 This section presents a table of values used to describe the message 718 transmission behavior of clients and servers. 720 Parameter Default Description 721 ------------------------------------- 722 SOL_MAX_DELAY 1 sec Max delay of first Solicit 723 SOL_TIMEOUT 1 sec Initial Solicit timeout 724 SOL_MAX_RT 120 secs Max Solicit timeout value 725 REQ_TIMEOUT 1 sec Initial Request timeout 726 REQ_MAX_RT 30 secs Max Request timeout value 727 REQ_MAX_RC 10 Max Request retry attempts 728 CNF_MAX_DELAY 1 sec Max delay of first Confirm 729 CNF_TIMEOUT 1 sec Initial Confirm timeout 730 CNF_MAX_RT 4 secs Max Confirm timeout 731 CNF_MAX_RD 10 secs Max Confirm duration 732 REN_TIMEOUT 10 secs Initial Renew timeout 733 REN_MAX_RT 600 secs Max Renew timeout value 734 REB_TIMEOUT 10 secs Initial Rebind timeout 735 REB_MAX_RT 600 secs Max Rebind timeout value 736 INF_MAX_DELAY 1 sec Max delay of first Information-request 737 INF_TIMEOUT 1 sec Initial Information-request timeout 738 INF_MAX_RT 120 secs Max Information-request timeout value 739 REL_TIMEOUT 1 sec Initial Release timeout 740 REL_MAX_RC 5 MAX Release attempts 741 DEC_TIMEOUT 1 sec Initial Decline timeout 742 DEC_MAX_RC 5 Max Decline attempts 743 REC_TIMEOUT 2 secs Initial Reconfigure timeout 744 REC_MAX_RC 8 Max Reconfigure attempts 745 HOP_COUNT_LIMIT 32 Max hop count in a Relay-forward message 747 6. Client/Server Message Formats 749 All DHCP messages sent between clients and servers share an identical 750 fixed format header and a variable format area for options. 752 All values in the message header and in options are in network byte 753 order. 755 Options are stored serially in the options field, with no padding 756 between the options. Options are byte-aligned but are not aligned in 757 any other way such as on 2 or 4 byte boundaries. 759 The following diagram illustrates the format of DHCP messages sent 760 between clients and servers: 762 0 1 2 3 763 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 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | msg-type | transaction-id | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | | 768 . options . 769 . (variable) . 770 | | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 msg-type Identifies the DHCP message type; the 774 available message types are listed in 775 section 5.3. 777 transaction-id The transaction ID for this message exchange. 779 options Options carried in this message; options are 780 described in section 22. 782 7. Relay Agent/Server Message Formats 784 Relay agents exchange messages with servers to relay messages between 785 clients and servers that are not connected to the same link. 787 All values in the message header and in options are in network byte 788 order. 790 Options are stored serially in the options field, with no padding 791 between the options. Options are byte-aligned but are not aligned in 792 any other way such as on 2 or 4 byte boundaries. 794 There are two relay agent messages, which share the following format: 796 0 1 2 3 797 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 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | msg-type | hop-count | | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 801 | | 802 | link-address | 803 | | 804 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 805 | | | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 807 | | 808 | peer-address | 809 | | 810 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 811 | | | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 813 . . 814 . options (variable number and length) .... . 815 | | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 The following sections describe the use of the Relay Agent message 819 header. 821 7.1. Relay-forward Message 823 The following table defines the use of message fields in a 824 Relay-forward message. 826 msg-type RELAY-FORW 828 hop-count Number of relay agents that have relayed this 829 message 831 link-address A global or site-local address that will be used by 832 the server to identify the link on which the client 833 is located. 835 peer-address The address of the client or relay agent from which 836 the message to be relayed was received 838 options MUST include a "Relay Message option" (see 839 section 22.10); MAY include other options added by 840 the relay agent 842 7.2. Relay-reply Message 844 The following table defines the use of message fields in a 845 Relay-reply message. 847 msg-type RELAY-REPL 849 hop-count Copied from the Relay-forward message 851 link-address Copied from the Relay-forward message 853 peer-address Copied from the Relay-forward message 855 options MUST include a "Relay Message option"; see 856 section 22.10; MAY include other options 858 8. Representation and Use of Domain Names 860 So that domain names may be encoded uniformly, a domain name or a 861 list of domain names is encoded using the technique described in 862 section 3.1 of RFC1035 [13]. A domain name or list of domain names 863 in DHCP MUST NOT be stored in compressed form as described in section 864 4.1.4 of RFC1035. 866 9. DHCP Unique Identifier (DUID) 868 Each DHCP client and server has a DUID. DHCP servers use DUIDs to 869 identify clients for the selection of configuration parameters and 870 in the association of IAs with clients. DHCP clients use DUIDs to 871 identify a server in messages where a server needs to be identified. 872 See sections 22.2 and 22.3 for the representation of a DUID in a DHCP 873 message. 875 Clients and servers MUST treat DUIDs as opaque values and MUST only 876 compare DUIDs for equality. Clients and servers MUST NOT in any 877 other way interpret DUIDs. Clients and servers MUST NOT restrict 878 DUIDs to the types defined in this document as additional DUID types 879 may be defined in the future. 881 The DUID is carried in an option because it may be variable length 882 and because it is not required in all DHCP messages. The DUID is 883 designed to be unique across all DHCP clients and servers, and stable 884 for any specific client or server - that is, the DUID used by a 885 client or server SHOULD NOT change over time if at all possible; for 886 example, a device's DUID should not change as a result of a change in 887 the device's network hardware. 889 The motivation for having more than one type of DUID is that the DUID 890 must be globally unique, and must also be easy to generate. The sort 891 of globally-unique identifier that is easy to generate for any given 892 device can differ quite widely. Also, some devices may not contain 893 any persistent storage. Retaining a generated DUID in such a device 894 is not possible, so the DUID scheme must accommodate such devices. 896 9.1. DUID Contents 898 A DUID consists of a two-octet type code represented in network byte 899 order, followed by a variable number of octets that make up the 900 actual identifier. A DUID can be no more than 128 octets long (not 901 including the type code). The following types are currently defined: 903 1 Link-layer address plus time 904 2 Vendor-assigned unique ID based on Enterprise Number 905 3 Link-layer address 907 Formats for the variable field of the DUID for each of the above 908 types are shown below. 910 9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT] 912 This type of DUID consists of a two octet type field containing the 913 value 1, a two octet hardware type code, four octets containing 914 a time value, followed by link-layer address of any one network 915 interface that is connected to the DHCP device at the time that the 916 DUID is generated. The time value is the time that the DUID is 917 generated represented in seconds since midnight (UTC), January 1, 918 2000, modulo 2^32. The hardware type MUST be a valid hardware type 919 assigned by the IANA as described in RFC826 [17]. Both the time and 920 the hardware type are stored in network byte order. The link-layer 921 address is stored in canonical form, as described in RFC2464 [3]. 923 The following diagram illustrates the format of a DUID-LLT: 925 0 1 2 3 926 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 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | 1 | hardware type (16 bits) | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | time (32 bits) | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 . . 933 . link-layer address (variable length) . 934 . . 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 The choice of network interface can be completely arbitrary, as long 938 as that interface provides a globally unique link-layer address for 939 the link type, and the same DUID-LLT SHOULD be used in configuring 940 all network interfaces connected to the device, regardless of which 941 interface's link-layer address was used to generate the DUID-LLT. 943 Clients and servers using this type of DUID MUST store the DUID-LLT 944 in stable storage, and MUST continue to use this DUID-LLT even if the 945 network interface used to generate the DUID-LLT is removed. Clients 946 and servers that do not have any stable storage MUST NOT use this 947 type of DUID. 949 Clients and servers that use this DUID SHOULD attempt to configure 950 the time prior to generating the DUID, if that is possible, and MUST 951 use some sort of time source (for example, a real-time clock) in 952 generating the DUID, even if that time source could not be configured 953 prior to generating the DUID. The use of a time source makes it 954 unlikely that two identical DUID-LLTs will be generated if the 955 network interface is removed from the client and another client then 956 uses the same network interface to generate a DUID-LLT. A collision 957 between two DUID-LLTs is very unlikely even if the clocks haven't 958 been configured prior to generating the DUID. 960 This method of DUID generation is recommended for all general purpose 961 computing devices such as desktop computers and laptop computers, and 962 also for devices such as printers, routers, and so on, that contain 963 some form of writable non-volatile storage. 965 Despite our best efforts, it is possible that this algorithm for 966 generating a DUID could result in a client identifier collision. 967 A DHCP client that generates a DUID-LLT using this mechanism MUST 968 provide an administrative interface that replaces the existing DUID 969 with a newly-generated DUID-LLT. 971 9.3. DUID Assigned by Vendor Based on Enterprise Number [DUID-EN] 973 This form of DUID is assigned by the vendor to the device. It 974 consists of the vendor's registered Private Enterprise Number as 975 maintained by IANA [9] followed by a unique identifier assigned by 976 the vendor. The following diagram summarizes the structure of a 977 DUID-EN: 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | 2 | enterprise-number | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | enterprise-number (contd) | | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 986 . identifier . 987 . (variable length) . 988 . . 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 The source of the identifier is left up to the vendor defining it, 992 but each identifier part of each DUID-EN MUST be unique to the device 993 that is using it, and MUST be assigned to the device at the time of 994 manufacture and stored in some form of non-volatile storage. The 995 generated DUID SHOULD be recorded in non-erasable storage. The 996 enterprise-number is the vendor's registered Private Enterprise 997 Number as maintained by IANA [9]. The enterprise-number is stored as 998 an unsigned 32 bit number. 1000 An example DUID of this type might look like this: 1002 +---+---+---+---+---+---+---+---+ 1003 | 0 | 2 | 0 | 0 | 0 | 9| 12|192| 1004 +---+---+---+---+---+---+---+---+ 1005 |132|221| 3 | 0 | 9 | 18| 1006 +---+---+---+---+---+---+ 1008 This example includes the two-octet type of 2, the Enterprise 1009 Number (9), followed by eight octets of identifier data 1010 (0x0CC084D303000912). 1012 9.4. DUID Based on Link-layer Address [DUID-LL] 1014 This type of DUID consists of two octets containing the DUID type 3, 1015 a two octet network hardware type code, followed by the link-layer 1016 address of any one network interface that is permanently connected to 1017 the client or server device. For example, a host that has a network 1018 interface implemented in a chip that is unlikely to be removed and 1019 used elsewhere could use a DUID-LL. The hardware type MUST be a valid 1020 hardware type assigned by the IANA as described in RFC826 [17]. 1021 The hardware type is stored in network byte order. The link-layer 1022 address is stored in canonical form, as described in RFC2464 [3]. 1023 The following diagram illustrates the format of a DUID-LL: 1025 0 1 2 3 1026 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 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | 3 | hardware type (16 bits) | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 . . 1031 . link-layer address (variable length) . 1032 . . 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 The choice of network interface can be completely arbitrary, as 1036 long as that interface provides a unique link-layer address and is 1037 permanently attached to the device on which the DUID-LL is being 1038 generated. The same DUID-LL SHOULD be used in configuring all 1039 network interfaces connected to the device, regardless of which 1040 interface's link-layer address was used to generate the DUID. 1042 DUID-LL is recommended for devices that have a permanently-connected 1043 network interface with a link-layer address and do not have 1044 nonvolatile, writable stable storage. DUID-LL MUST NOT be used by 1045 DHCP clients or servers that cannot tell whether or not a network 1046 interface is permanently attached to the device on which the DHCP 1047 client is running. 1049 10. Identity Association 1051 An "identity-association" (IA) is a construct through which a server 1052 and a client can identify, group and manage a set of related IPv6 1053 addresses. Each IA consists of an IAID and associated configuration 1054 information. 1056 A client must associate at least one distinct IA with each of its 1057 network interfaces for which it is to request the assignment of IPv6 1058 addresses from a DHCP server. The client uses the IAs assigned to an 1059 interface to obtain configuration information from a server for that 1060 interface. Each IA must be associated with exactly one interface. 1062 The IAID uniquely identifies the IA and must be chosen to be unique 1063 among the IAIDs on the client. The IAID is chosen by the client. 1064 For any given use of an IA by the client, the IAID for that IA MUST 1065 be consistent across restarts of the DHCP client. The client may 1066 maintain consistency either by storing the IAID in non-volatile 1067 storage or by using an algorithm that will consistently produce the 1068 same IAID as long as the configuration of the client has not changed. 1069 There may be no way for a client to maintain consistency of the IAIDs 1070 if it does not have non-volatile storage and the client's hardware 1071 configuration changes. 1073 The configuration information in an IA consists of one or more IPv6 1074 addresses along with the times T1 and T2 for the IA. See section 22.4 1075 for the representation of an IA in a DHCP message. 1077 Each address in an IA has a preferred lifetime and a valid lifetime, 1078 as defined in RFC2462 [20]. The lifetimes are transmitted from the 1079 DHCP server to the client in the IA option. The lifetimes apply to 1080 the use of IPv6 addresses as described in section 5.5.4 of RFC2462. 1082 11. Selecting Addresses for Assignment to an IA 1084 A server selects addresses to be assigned to an IA according to the 1085 address assignment policies determined by the server administrator 1086 and the specific information the server determines about the client 1087 from some combination of the following sources: 1089 - The link to which the client is attached. The server determines 1090 the link as follows: 1092 * If the server receives the message directly from the client 1093 and the source address in the IP datagram in which the 1094 message was received is a link-local address, then the client 1095 is on the same link to which the interface over which the 1096 message was received is attached 1098 * If the server receives the message from a forwarding relay 1099 agent, then the client is on the same link as the one to 1100 which the interface identified by the link-address field in 1101 the message from the relay agent is attached 1103 * If the server receives the message directly from the client 1104 and the source address in the IP datagram in which the 1105 message was received is not a link-local address, then the 1106 client is on the link identified by the source address in the 1107 IP datagram (note that this situation can occur only if the 1108 server has enabled the use of unicast message delivery by the 1109 client and the client has sent a message for which unicast 1110 delivery is allowed) 1112 - The DUID supplied by the client 1114 - Other information in options supplied by the client 1116 - Other information in options supplied by the relay agent 1118 Any address assigned by a server that is based on an EUI-64 1119 identifier MUST include an interface identifier with the "u" 1120 (universal/local) and "g" (individual/group) bits of the interface 1121 identifier set appropriately, as indicated in section 2.5.1 of RFC 1122 2373 [8]. 1124 A server MUST NOT assign an address that is otherwise reserved for 1125 some other purpose. For example, a server MUST NOT assign reserved 1126 anycast addresses, as defined in RFC2526, from any subnet. 1128 12. Management of Temporary Addresses 1130 A client may request the assignment of temporary addresses (see 1131 RFC 3041 [15] for the definition of temporary addresses). DHCPv6 1132 handling of address assignment is no different for temporary 1133 addresses. DHCPv6 says nothing about details of temporary addresses 1134 like lifetimes, how clients use temporary addresses, rules for 1135 generating successive temporary addresses, etc. 1137 Clients ask for temporary addresses and servers assign them. 1138 Temporary addresses are carried in the Identity Association for 1139 Temporary Addresses (IA_TA) option (see section 22.5). Each IA_TA 1140 option contains at most one temporary address for each of the 1141 prefixes on the link to which the client is attached. 1143 The IAID number space for the IA_TA option IAID number space is 1144 separate from the IA_NA option IAID number space. 1146 The server MAY update the DNS for a temporary address as described in 1147 section 4 of RFC3041. 1149 13. Transmission of Messages by a Client 1151 Unless otherwise specified in this document or in a document that 1152 describes how IPv6 is carried over a specific type of link (for link 1153 types that do not support multicast), a client sends DHCP messages to 1154 the All_DHCP_Relay_Agents_and_Servers. 1156 A client uses multicast to reach all servers or an individual server. 1157 An individual server is indicated by specifying that server's DUID in 1158 a Server Identifier option (see section 22.3) in the client's message 1159 (all servers will receive this message but only the indicated server 1160 will respond). All servers are indicated by not supplying this 1161 option. 1163 A client may send some messages directly to a server using unicast, 1164 as described in section 22.12. 1166 14. Reliability of Client Initiated Message Exchanges 1168 DHCP clients are responsible for reliable delivery of messages in the 1169 client-initiated message exchanges described in sections 17 and 18. 1170 If a DHCP client fails to receive an expected response from a server, 1171 the client must retransmit its message. This section describes the 1172 retransmission strategy to be used by clients in client-initiated 1173 message exchanges. 1175 Note that the procedure described in this section is slightly 1176 modified when used with the Solicit message. The modified procedure 1177 is described in section 17.1.2. 1179 The client begins the message exchange by transmitting a message to 1180 the server. The message exchange terminates when either the client 1181 successfully receives the appropriate response or responses from a 1182 server or servers, or when the message exchange is considered to have 1183 failed according to the retransmission mechanism described below. 1185 The client retransmission behavior is controlled and described by the 1186 following variables: 1188 RT Retransmission timeout 1190 IRT Initial retransmission time 1192 MRC Maximum retransmission count 1194 MRT Maximum retransmission time 1196 MRD Maximum retransmission duration 1197 RAND Randomization factor 1199 With each message transmission or retransmission, the client sets RT 1200 according to the rules given below. If RT expires before the message 1201 exchange terminates, the client recomputes RT and retransmits the 1202 message. 1204 Each of the computations of a new RT include a randomization factor 1205 (RAND), which is a random number chosen with a uniform distribution 1206 between -0.1 and +0.1. The randomization factor is included to 1207 minimize synchronization of messages transmitted by DHCP clients. 1208 The algorithm for choosing a random number does not need to be 1209 cryptographically sound. The algorithm SHOULD produce a different 1210 sequence of random numbers from each invocation of the DHCP client. 1212 RT for the first message transmission is based on IRT: 1214 RT = IRT + RAND*IRT 1216 RT for each subsequent message transmission is based on the previous 1217 value of RT: 1219 RT = 2*RTprev + RAND*RTprev 1221 MRT specifies an upper bound on the value of RT (disregarding the 1222 randomization added by the use of RAND). If MRT has a value of 0, 1223 there is no upper limit on the value of RT. Otherwise: 1225 if (RT > MRT) 1226 RT = MRT + RAND*MRT 1228 MRC specifies an upper bound on the number of times a client may 1229 retransmit a message. Unless MRC is zero, the message exchange fails 1230 once the client has transmitted the message MRC times. 1232 MRD specifies an upper bound on the length of time a client may 1233 retransmit a message. Unless MRD is zero, the message exchange fails 1234 once MRD seconds have elapsed since the client first transmitted the 1235 message. 1237 If both MRC and MRD are non-zero, the message exchange fails whenever 1238 either of the conditions specified in the previous two paragraphs are 1239 met. 1241 If both MRC and MRD are zero, the client continues to transmit the 1242 message until it receives a response. 1244 15. Message Validation 1246 Clients and servers SHOULD discard any messages that contain options 1247 that are not allowed to appear in the received message. For example, 1248 an IA option is not allowed to appear in an Information-request 1249 message. Clients and server MAY choose to extract information from 1250 such a message if the information is of use to the recipient. 1252 A server MUST discard any Solicit, Confirm, Rebind or 1253 Information-request messages it receives with a unicast 1254 destination address. 1256 Message validation based on DHCP authentication is discussed in 1257 section 21.4.2. 1259 If a server receives a message that contains options it should not 1260 contain (such as an Information-request message with an IA option), 1261 is missing options that it should contain, or is otherwise not valid, 1262 it MAY send a Reply (or Advertise as appropriate) with a Server 1263 Identifier option, a Client Identifier option if one was included in 1264 the message and a Status Code option with status UnSpecFail. 1266 15.1. Use of Transaction IDs 1268 The "transaction-id" field holds a value used by clients and servers 1269 to synchronize server responses to client messages. A client 1270 SHOULD generate a random number that cannot easily be guessed or 1271 predicted to use as the transaction ID for each new message it sends. 1272 Note that if a client generates easily predictable transaction 1273 identifiers, it may become more vulnerable to certain kinds of 1274 attacks from off-path intruders. A client MUST leave the transaction 1275 ID unchanged in retransmissions of a message. 1277 15.2. Solicit Message 1279 Clients MUST discard any received Solicit messages. 1281 Servers MUST discard any Solicit messages that do not include a 1282 Client Identifier option or that do include a Server Identifier 1283 option. 1285 15.3. Advertise Message 1287 Clients MUST discard any received Advertise messages that meet any of 1288 the following conditions: 1290 - the message does not include a Server Identifier option 1292 - the message does not include a Client Identifier option 1293 - the contents of the Client Identifier option does not match the 1294 client's DUID 1296 - the "transaction-id" field value does not match the value the 1297 client used in its Solicit message 1299 Servers and relay agents MUST discard any received Advertise 1300 messages. 1302 15.4. Request Message 1304 Clients MUST discard any received Request messages. 1306 Servers MUST discard any received Request message that meet any of 1307 the following conditions: 1309 - the message does not include a Server Identifier option 1311 - the contents of the Server Identifier option do not match the 1312 server's DUID 1314 - the message does not include a Client Identifier option 1316 15.5. Confirm Message 1318 Clients MUST discard any received Confirm messages. 1320 Servers MUST discard any received Confirm messages that do not 1321 include a Client Identifier option or that do include a Server 1322 Identifier option. 1324 15.6. Renew Message 1326 Clients MUST discard any received Renew messages. 1328 Servers MUST discard any received Renew message that meets any of the 1329 following conditions: 1331 - the message MUST include a Server Identifier option 1333 - the contents of the Server Identifier option MUST match the 1334 server's identifier 1336 - the message MUST include a Client Identifier option 1338 15.7. Rebind Message 1340 Clients MUST discard any received Rebind messages. 1342 Servers MUST discard any received Rebind messages that do not include 1343 a Client Identifier option or that do include a Server Identifier 1344 option. 1346 15.8. Decline Messages 1348 Clients MUST discard any received Decline messages. 1350 Servers MUST discard any received Decline message that fails to meet 1351 any of the following conditions: 1353 - the message MUST include a Server Identifier option 1355 - the contents of the Server Identifier option MUST match the 1356 server's identifier 1358 - the message MUST include a Client Identifier option 1360 15.9. Release Message 1362 Clients MUST discard any received Release messages. 1364 Servers MUST discard any received Release message that fails to meet 1365 any of the following conditions: 1367 - the message MUST include a Server Identifier option 1369 - the contents of the Server Identifier option MUST match the 1370 server's identifier 1372 - the message MUST include a Client Identifier option 1374 15.10. Reply Message 1376 Clients MUST discard any received Reply message that fails to meet 1377 any of the following conditions: 1379 - the message MUST include a Server Identifier option 1381 - the "transaction-id" field in the message MUST match the value 1382 used in the original message 1384 - if the client included a Client Identifier option in the original 1385 message, the message MUST include a Client Identifier option 1386 and the contents of the Client Identifier option MUST match the 1387 DUID of the client or, if the client did not include a Client 1388 Identifier option in the original message, the Reply message MUST 1389 NOT include a Client Identifier option 1391 Servers and relay agents MUST discard any received Reply messages. 1393 15.11. Reconfigure Message 1395 Servers and relay agents MUST discard any received Reconfigure 1396 messages. 1398 Clients MUST discard any Reconfigure messages that fails any of the 1399 following conditions: 1401 - the message MUST have been unicast to the client 1403 - the message MUST include a Server Identifier option 1405 - the message MUST include a Client Identifier option that contains 1406 the client's DUID 1408 - the message MUST contain a Reconfigure Message option and the 1409 msg-type must be a valid value 1411 - the message MUST NOT include any IA options if the msg-type in 1412 the Reconfigure Message option is INFORMATION-REQUEST 1414 - the message MUST include DHCP authentication: 1416 * the message MUST contain an authentication option 1418 * the message MUST pass the authentication validation performed 1419 by the client 1421 15.12. Information-request Message 1423 Clients MUST discard any received Information-request messages. 1425 Servers MUST discard any received Information-request message that 1426 fails to meet any of the following conditions: 1428 - The message includes a Server Identifier option and the DUID in 1429 the option does not match the server's DUID 1431 - The message includes an IA option 1433 15.13. Relay-forward Message 1435 Clients MUST discard any received Relay-forward messages. 1437 15.14. Relay-reply Message 1439 Clients and servers MUST discard any received Relay-reply messages. 1441 16. Client Source Address and Interface Selection 1443 When a client sends a DHCP message to the 1444 All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the 1445 message through the interface for which configuration information is 1446 being requested. However, the client MAY send the message through 1447 another interface attached to the same link if and only if the 1448 client is certain the two interface are attached to the same link. 1449 The client MUST use a link-local address assigned to the interface 1450 for which is is requesting configuration information as the source 1451 address in the header of the IP datagram. 1453 When a client sends a DHCP message directly to a server using unicast 1454 (after receiving the Server Unicast option from that server), the 1455 source address in the header of the IP datagram MUST be an address 1456 assigned to the interface for which the client is interested in 1457 obtaining configuration and which is suitable for use by the server 1458 in responding to the client. 1460 17. DHCP Server Solicitation 1462 This section describes how a client locates servers that will assign 1463 addresses to IAs belonging to the client. 1465 The client is responsible for creating IAs and requesting that a 1466 server assign IPv6 addresses to the IA. The client first creates 1467 an IA and assigns it an IAID. The client then transmits a Solicit 1468 message containing an IA option describing the IA. Servers that can 1469 assign addresses to the IA respond to the client with an Advertise 1470 message. The client then initiates a configuration exchange as 1471 described in section 18. 1473 If the client will accept a Reply message with committed address 1474 assignments and other resources in response to the Solicit message, 1475 the client includes a Rapid Commit option (see section 22.14) in the 1476 Solicit message. 1478 17.1. Client Behavior 1480 A client uses the Solicit message to discover DHCP servers configured 1481 to assign addresses or return other configuration parameters on the 1482 link to which the client is attached. 1484 17.1.1. Creation of Solicit Messages 1486 The client sets the "msg-type" field to SOLICIT. The client generates 1487 a transaction ID and inserts this value in the "transaction-id" 1488 field. 1490 The client MUST include a Client Identifier option to identify itself 1491 to the server. The client includes IA options for any IAs to which 1492 it wants the server to assign addresses. The client MAY include 1493 addresses in the IAs as a hint to the server about addresses for 1494 which the client has a preference. The client MUST NOT include any 1495 other options in the Solicit message except as specifically allowed 1496 in the definition of individual options. 1498 The client uses IA_NA options to request the assignment of 1499 non-temporary addresses and uses IA_TA options to request the 1500 assignment of temporary addresses. Either IA_NA or IA_TA options, or 1501 a combination of both can be included in DHCP messages. 1503 The client MUST include an Option Request option (see section 22.7) 1504 to indicate the options the client is interested in receiving. The 1505 client MAY additionally include instances of those options that are 1506 identified in the Option Request option with data values as hints 1507 to the server about parameter values the client would like to have 1508 returned. 1510 The client MUST include a Reconfigure Accept option (see 1511 section 22.20) indicating whether or not the client is willing to 1512 accept Reconfigure messages from the server. 1514 17.1.2. Transmission of Solicit Messages 1516 The first Solicit message from the client on the interface MUST be 1517 delayed by a random amount of time between 0 and SOL_MAX_DELAY. In 1518 the case of a Solicit message transmitted when DHCP is initiated 1519 by IPv6 Neighbor Discovery, the delay gives the amount of time to 1520 wait after IPv6 Neighbor Discovery causes the client to invoke the 1521 stateful address autoconfiguration protocol (see section 5.5.3 of 1522 RFC2462). This random delay desynchronizes clients which start at 1523 the same time (for example, after a power outage). 1525 The client transmits the message according to section 14, using the 1526 following parameters: 1528 IRT SOL_TIMEOUT 1530 MRT SOL_MAX_RT 1532 MRC 0 1534 MRD 0 1536 If the client has included a Rapid Commit option in its Solicit 1537 message, the client terminates the waiting process as soon as a Reply 1538 message with a Rapid Commit option is received. 1540 If the client is waiting for an Advertise message, the mechanism in 1541 section 14 is modified as follows for use in the transmission of 1542 Solicit messages. The message exchange is not terminated by the 1543 receipt of an Advertise before the first RT has elapsed. Rather, the 1544 client collects Advertise messages until the first RT has elapsed. 1545 Also, the first RT MUST be selected to be strictly greater than IRT 1546 by choosing RAND to be strictly greater than 0. 1548 A client MUST collect Advertise messages for the first RT seconds, 1549 unless it receives an Advertise message with a preference value 1550 of 255. The preference value is carried in the Preference option 1551 (section 22.8). Any Advertise that does not include a Preference 1552 option is considered to have a preference value of 0. If the client 1553 receives an Advertise message that includes a Preference option 1554 with a preference value of 255, the client immediately begins a 1555 client-initiated message exchange (as described in section 18) by 1556 sending a Request message to the server from which the Advertise 1557 message was received. If the client receives an Advertise message 1558 that does not include a Preference option with a preference value of 1559 255, the client continues to wait until the first RT elapses. If the 1560 first RT elapses and the client has received an Advertise message, 1561 the client SHOULD continue with a client-initiated message exchange 1562 by sending a Request message. 1564 If the client does not receive any Advertise messages before 1565 the first RT has elapsed, it begins the retransmission mechanism 1566 described in section 14. The client terminates the retransmission 1567 process as soon as it receives any Advertise message, and the client 1568 acts on the received Advertise message without waiting for any 1569 additional Advertise messages. 1571 A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client 1572 is configured with either MRC or MRD set to a value other than 1573 0, it MUST stop trying to configure the interface if the message 1574 exchange fails. After the DHCP client stops trying to configure 1575 the interface, it SHOULD restart the reconfiguration process after 1576 some external event, such as user input, system restart, or when the 1577 client is attached to a new link. 1579 17.1.3. Receipt of Advertise Messages 1581 The client MUST ignore any Advertise message that includes a Status 1582 Code option containing the value NoAddrsAvail, with the exception 1583 that the client MAY display the associated status message to the 1584 user. 1586 Upon receipt of one or more valid Advertise messages, the client 1587 selects one or more Advertise messages based upon the following 1588 criteria. 1590 - Those Advertise messages with the highest server preference value 1591 are preferred over all other Advertise messages. 1593 - Within a group of Advertise messages with the same server 1594 preference value, a client MAY select those servers whose 1595 Advertise messages advertise information of interest to the 1596 client. For example, the client may choose a server that 1597 returned an advertisement with configuration options of interest 1598 to the client. 1600 - The client MAY choose a less-preferred server if that server has 1601 a better set of advertised parameters, such as the available 1602 addresses advertised in IAs. 1604 Once a client has selected Advertise message(s), the client will 1605 typically store information about each server, such as server 1606 preference value, addresses advertised, when the advertisement was 1607 received, and so on. 1609 If the client needs to select an alternate server in the case that a 1610 chosen server does not respond, the client chooses the next server 1611 according to the criteria given above. 1613 17.1.4. Receipt of Reply Message 1615 If the client includes a Rapid Commit option in the Solicit message, 1616 it will expect a Reply message that includes a Rapid Commit option 1617 in response. The client discards any Reply messages it receives 1618 that do not include a Rapid Commit option. If the client receives 1619 a valid Reply message that includes a Rapid Commit option, it 1620 processes the message as described in section 18.1.8. If it does 1621 not receive such a Reply message and does receive a valid Advertise 1622 message, the client processes the Advertise message as described in 1623 section 17.1.3. 1625 17.2. Server Behavior 1627 A server sends an Advertise message in response to valid Solicit 1628 messages it receives to announce the availability of the server to 1629 the client. 1631 17.2.1. Receipt of Solicit Messages 1633 The server determines the information about the client and its 1634 location as described in section 11 and checks its administrative 1635 policy about responding to the client. If the server is not 1636 permitted to respond to the client, the server discards the Solicit 1637 message. For example, if the administrative policy for the server 1638 is that it may only respond to a client that is willing to accept 1639 a Reconfigure message, if the client indicates with a Reconfigure 1640 Accept option in the Solicit message that it will not accept a 1641 Reconfigure message, the servers discards the Solicit message. 1643 If the client has included a Rapid Commit option in the Solicit 1644 message and the server has been configured to respond with committed 1645 address assignments and other resources, the server responds to 1646 the Solicit with a Reply message as described in section 17.2.3. 1647 Otherwise, the server ignores the Rapid Commit option and processes 1648 the remainder of the message as if no Rapid Commit option were 1649 present. 1651 17.2.2. Creation and Transmission of Advertise Messages 1653 The server sets the "msg-type" field to ADVERTISE and copies the 1654 contents of the transaction-id field from the Solicit message 1655 received from the client to the Advertise message. The server 1656 includes its server identifier in a Server Identifier option and 1657 copies the Client Identifier from the Solicit message into the 1658 Advertise message. 1660 The server MAY add a Preference option to carry the preference value 1661 for the Advertise message. The server implementation SHOULD allow 1662 the setting of a server preference value by the administrator. 1663 The server preference value MUST default to zero unless otherwise 1664 configured by the server administrator. 1666 The server MUST add a Reconfigure Accept option to indicate whether 1667 the client is required to accept or discard any Reconfigure messages 1668 it receives. 1670 The server includes options the server will return to the client in 1671 a subsequent Reply message. The information in these options may 1672 be used by the client in the selection of a server if the client 1673 receives more than one Advertise message. If the client has included 1674 an Option Request option in the Solicit message, the server includes 1675 options in the Advertise message containing configuration parameters 1676 for all of the options identified in the Option Request option 1677 that the server has been configured to return to the client. The 1678 server MAY return additional options to the client if it has been 1679 configured to do so. The server SHOULD limit the options returned to 1680 the client so that the DHCP message header and options do not cause 1681 fragmentation. 1683 If the Solicit message from the client included one or more IA 1684 options, the server MUST include IA options in the Advertise message 1685 containing any addresses that would be assigned to IAs contained in 1686 the Solicit message from the client. If the client has included 1687 addresses in the IAs in the Solicit message, the server uses those 1688 addresses as hints about the addresses the client would like to 1689 receive. 1691 If the server will not assign any addresses to any IAs in a 1692 subsequent Request from the client, the server MUST send an Advertise 1693 message to the client that includes only a Status Code option 1694 with code NoAddrsAvail and a status message for the user, a Server 1695 Identifier option with the server's DUID and a Client Identifier 1696 option with the client's DUID. 1698 If the Solicit message was received directly by the server, the 1699 server unicasts the Advertise message directly to the client using 1700 the address in the source address field from the IP datagram in which 1701 the Solicit message was received. The Advertise message MUST be 1702 unicast on the link from which the Solicit message was received. 1704 If the Solicit message was received in a Relay-forward message, the 1705 server constructs a Relay-reply message with the Advertise message 1706 in the payload of a "relay-message" option. If the Relay-forward 1707 messages included an Interface-id option, the server copies 1708 that option to the Relay-reply message. The server unicasts the 1709 Relay-reply message directly to the relay agent using the address 1710 in the source address field from the IP datagram in which the 1711 Relay-forward message was received. 1713 17.2.3. Creation and Transmission of Reply Messages 1715 The server MUST commit the assignment of any addresses or other 1716 configuration information message before sending a Reply message to a 1717 client in response to a Solicit message. 1719 DISCUSSION: 1721 When using the Solicit-Reply message exchange, the server 1722 commits the assignment of any addresses before sending the 1723 Reply message. The client can assume it has been assigned 1724 the addresses in the Reply message and does not need to send 1725 a Request message for those addresses. 1727 Typically, servers that are configured to use the 1728 Solicit-Reply message exchange will be deployed so that only 1729 one server will respond to a Solicit message. If more than 1730 one server responds, the client will only use the addresses 1731 from one of the servers and the addresses from the other 1732 servers will be committed to the client but not used by the 1733 client. 1735 The server includes a Rapid Commit option in the Reply message to 1736 indicate that the Reply is in response to a Solicit message. 1738 The server MUST add a Reconfigure Accept option to indicate whether 1739 the client is required to accept or discard any Reconfigure messages 1740 the client receives. 1742 The server produces the Reply message as though it had received 1743 a Request message, as described in section 18.2.1. The server 1744 transmits the Reply message as described in section 18.2.8. 1746 18. DHCP Client-Initiated Configuration Exchange 1748 A client initiates a message exchange with a server or servers 1749 to acquire or update configuration information of interest. The 1750 client may initiate the configuration exchange as part of the 1751 operating system configuration process, when requested to do 1752 so by the application layer, when required by Stateless Address 1753 Autoconfiguration or as required to extend the lifetime of an address 1754 (Renew and Rebind messages). 1756 18.1. Client Behavior 1758 A client uses Request, Renew, Rebind, Release and Decline messages 1759 during the normal life cycle of addresses. It uses Confirm to 1760 validate addresses when it may have moved to a new link. It uses 1761 Information-Request messages when it needs configuration information 1762 but no addresses. 1764 If the client has a source address of sufficient scope that can be 1765 used by the server as a return address and the client has received 1766 a Server Unicast option (section 22.12) from the server, the client 1767 SHOULD unicast any Request, Renew, Release and Decline messages to 1768 the server. 1770 DISCUSSION: 1772 Use of unicast may avoid delays due to relaying of messages 1773 by relay agents as well as avoid overhead and duplicate 1774 responses by servers due to delivery of client messages to 1775 multiple servers. Requiring the client to relay all DHCP 1776 messages through a relay agent enables the inclusion of 1777 relay agent options in all messages sent by the client. The 1778 server should enable the use of unicast only when relay 1779 agent options will not be used. 1781 18.1.1. Creation and Transmission of Request Messages 1783 The client uses a Request message to populate IAs with addresses and 1784 obtain other configuration information. The client includes one or 1785 more IA options in the Request message. The server then returns 1786 addresses and other information about the IAs to the client in IA 1787 options in a Reply message. 1789 The client generates a transaction ID and inserts this value in the 1790 "transaction-id" field. 1792 The client places the identifier of the destination server in a 1793 Server Identifier option. 1795 The client MUST include a Client Identifier option to identify itself 1796 to the server. The client adds any other appropriate options, 1797 including one or more IA options (if the client is requesting that 1798 the server assign it some network addresses). 1800 The client MUST include an Option Request option (see section 22.7) 1801 to indicate the options the client is interested in receiving. The 1802 client MAY include options with data values as hints to the server 1803 about parameter values the client would like to have returned. 1805 The client MUST include a Reconfigure Accept option (see section 1806 indicating whether or not the client is willing to accept Reconfigure 1807 messages from the server. 1809 The client transmits the message according to section 14, using the 1810 following parameters: 1812 IRT REQ_TIMEOUT 1814 MRT REQ_MAX_RT 1816 MRC REQ_MAX_RC 1818 MRD 0 1820 If the message exchange fails, the client takes an action based on 1821 the client's local policy. Examples of actions the client might take 1822 include: 1824 - Select another server from a list of servers known to the client; 1825 for example, servers that responded with an Advertise message 1827 - Initiate the server discovery process described in section 17 1829 - Terminate the configuration process and report failure 1831 18.1.2. Creation and Transmission of Confirm Messages 1833 Whenever a client may have moved to a new link, the prefixes from the 1834 addresses assigned to the interfaces on that link may no longer be 1835 appropriate to the link to which the client is attached. Examples of 1836 times when a client may have moved to a new link include: 1838 o The client reboots 1840 o The client is physically disconnected from a wired connection 1842 o The client returns from sleep mode 1844 o The client using a wireless technology changes access points 1846 In any situation when a client may have moved to a new link, the 1847 client MUST initiate a Confirm/Reply message exchange. The client 1848 includes any IAs assigned to the interface that may have moved to a 1849 new link, along with the addresses associated with those IAs, in its 1850 Confirm message. Any responding servers will indicate whether those 1851 addresses are appropriate to the link to which the client is attached 1852 with the status in the Reply message it returns to the client. 1854 The client sets the "msg-type" field to CONFIRM. The client generates 1855 a transaction ID and inserts this value in the "transaction-id" 1856 field. 1858 The client MUST include a Client Identifier option to identify 1859 itself to the server. The client includes IA options for all of 1860 the IAs assigned to the interface for which the Confirm message is 1861 being sent. The IA options include all of the addresses the client 1862 currently has associated with those IAs. The client SHOULD set the 1863 T1 and T2 fields in any IA_NA options and the preferred-lifetime and 1864 valid-lifetime fields in the IA Address options to 0, as the server 1865 will ignore these fields. 1867 The first Confirm message from the client on the interface MUST be 1868 delayed by a random amount of time between 0 and CNF_MAX_DELAY. The 1869 client transmits the message according to section 14, using the 1870 following parameters: 1872 IRT CNF_TIMEOUT 1874 MRT CNF_MAX_RT 1876 MRC 0 1878 MRD CNF_MAX_RD 1880 If the client receives no responses before the message transmission 1881 process as described in section 14 terminates, the client SHOULD 1882 continue to use any IP addresses, using the last known lifetimes for 1883 those addresses, and SHOULD continue to use any other previously 1884 obtained configuration parameters. 1886 18.1.3. Creation and Transmission of Renew Messages 1888 To extend the valid and preferred lifetimes for the addresses 1889 associated with an IA, the client sends a Renew message to the server 1890 from which the client obtained the addresses in the IA containing 1891 an IA option for the IA. The client includes IA Address options in 1892 the IA option for the addresses associated with the IA. The server 1893 determines new lifetimes for the addresses in the IA according to the 1894 administrative configuration of the server. The server may also add 1895 new addresses to the IA. The server may remove addresses from the IA 1896 by setting the preferred and valid lifetimes of those addresses to 1897 zero. 1899 The server controls the time at which the client contacts the server 1900 to extend the lifetimes on assigned addresses through the T1 and T2 1901 parameters assigned to an IA. 1903 At time T1 for an IA, the client initiates a Renew/Reply message 1904 exchange to extend the lifetimes on any addresses in the IA. The 1905 client includes an IA option with all addresses currently assigned to 1906 the IA in its Renew message. 1908 If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no 1909 T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind 1910 message, respectively, at the client's discretion. 1912 The client sets the "msg-type" field to RENEW. The client generates a 1913 transaction ID and inserts this value in the "transaction-id" field. 1915 The client places the identifier of the destination server in a 1916 Server Identifier option. 1918 The client MUST include a Client Identifier option to identify 1919 itself to the server. The client adds any appropriate options, 1920 including one or more IA options. The client MUST include the list 1921 of addresses the client currently has associated with the IAs in the 1922 Renew message. 1924 The client MUST include an Option Request option (see section 22.7) 1925 to indicate the options the client is interested in receiving. The 1926 client MAY include options with data values as hints to the server 1927 about parameter values the client would like to have returned. 1929 The client transmits the message according to section 14, using the 1930 following parameters: 1932 IRT REN_TIMEOUT 1934 MRT REN_MAX_RT 1936 MRC 0 1938 MRD Remaining time until T2 1940 The message exchange is terminated when time T2 is reached (see 1941 section 18.1.4), at which time the client begins a Rebind message 1942 exchange. 1944 18.1.4. Creation and Transmission of Rebind Messages 1946 At time T2 for an IA (which will only be reached if the server to 1947 which the Renew message was sent at time T1 has not responded), the 1948 client initiates a Rebind/Reply message exchange with any available 1949 server. The client includes an IA option with all addresses 1950 currently assigned to the IA in its Rebind message. 1952 The client sets the "msg-type" field to REBIND. The client generates 1953 a transaction ID and inserts this value in the "transaction-id" 1954 field. 1956 The client MUST include a Client Identifier option to identify 1957 itself to the server. The client adds any appropriate options, 1958 including one or more IA options. The client MUST include the list 1959 of addresses the client currently has associated with the IAs in the 1960 Rebind message. 1962 The client MUST include an Option Request option (see section 22.7) 1963 to indicate the options the client is interested in receiving. The 1964 client MAY include options with data values as hints to the server 1965 about parameter values the client would like to have returned. 1967 The client transmits the message according to section 14, using the 1968 following parameters: 1970 IRT REB_TIMEOUT 1972 MRT REB_MAX_RT 1974 MRC 0 1976 MRD Remaining time until valid lifetimes of all addresses have 1977 expired 1979 The message exchange is terminated when the valid lifetimes of all of 1980 the addresses assigned to the IA expire (see section 10), at which 1981 time the client has several alternative actions to choose from; for 1982 example: 1984 - The client may choose to use a Solicit message to locate a new 1985 DHCP server and send a Request for the expired IA to the new 1986 server 1988 - The client may have other addresses in other IAs, so the client 1989 may choose to discard the expired IA and use the addresses in the 1990 other IAs 1992 18.1.5. Creation and Transmission of Information-request Messages 1994 The client uses an Information-request message to obtain 1995 configuration information without having addresses assigned to it. 1997 The client sets the "msg-type" field to INFORMATION-REQUEST. The 1998 client generates a transaction ID and inserts this value in the 1999 "transaction-id" field. 2001 The client SHOULD include a Client Identifier option to identify 2002 itself to the server. If the client does not include a Client 2003 Identifier option, the server will not be able to return any 2004 client-specific options to the client, or the server may choose 2005 not to respond to the message at all. The client MUST include a 2006 Client Identifier option if the Information-Request message will be 2007 authenticated. 2009 The client MUST include an Option Request option (see section 22.7) 2010 to indicate the options the client is interested in receiving. The 2011 client MAY include options with data values as hints to the server 2012 about parameter values the client would like to have returned. 2014 The first Information-request message from the client on the 2015 interface MUST be delayed by a random amount of time between 0 2016 and INF_MAX_DELAY.The client transmits the message according to 2017 section 14, using the following parameters: 2019 IRT INF_TIMEOUT 2021 MRT INF_MAX_RT 2023 MRC 0 2025 MRD 0 2027 18.1.6. Creation and Transmission of Release Messages 2029 To release one or more addresses, a client sends a Release message to 2030 the server. 2032 The client sets the "msg-type" field to RELEASE. The client generates 2033 a transaction ID and places this value in the "transaction-id" field. 2035 The client places the identifier of the server that allocated the 2036 address(es) in a Server Identifier option. 2038 The client MUST include a Client Identifier option to identify itself 2039 to the server. The client includes options containing the IAs for 2040 the addresses it is releasing in the "options" field. The addresses 2041 to be released MUST be included in the IAs. Any addresses for the 2042 IAs the client wishes to continue to use MUST NOT be in added to the 2043 IAs. 2045 The client MUST NOT use any of the addresses it is releasing as 2046 the source address in the Release message or in any subsequently 2047 transmitted message. 2049 Because Release messages may be lost, the client should retransmit 2050 the Release if no Reply is received. However, there are scenarios 2051 where the client may not wish to wait for the normal retransmission 2052 timeout before giving up (e.g., on power down). Implementations 2053 SHOULD retransmit one or more times, but MAY choose to terminate the 2054 retransmission procedure early. 2056 The client transmits the message according to section 14, using the 2057 following parameters: 2059 IRT REL_TIMEOUT 2061 MRT 0 2063 MRC REL_MAX_MRC 2065 MRD 0 2067 The client MUST stop using all of the addresses being released as 2068 soon as the client begins the Release message exchange process. If 2069 addresses are released but the Reply from a DHCP server is lost, 2070 the client will retransmit the Release message, and the server may 2071 respond with a Reply indicating a status of NoBinding. Therefore, 2072 the client does not treat a Reply message with a status of NoBinding 2073 in a Release message exchange as if it indicates an error. 2075 Note that if the client fails to release the addresses, each address 2076 assigned to the IA will be reclaimed by the server when the valid 2077 lifetime of that address expires. 2079 18.1.7. Creation and Transmission of Decline Messages 2081 If a client detects that one or more addresses assigned to it by a 2082 server are already in use by another node, the client sends a Decline 2083 message to the server to inform it that the address is suspect. 2085 The client sets the "msg-type" field to DECLINE. The client generates 2086 a transaction ID and places this value in the "transaction-id" field. 2088 The client places the identifier of the server that allocated the 2089 address(es) in a Server Identifier option. 2091 The client MUST include a Client Identifier option to identify itself 2092 to the server. The client includes options containing the IAs for 2093 the addresses it is declining in the "options" field. The addresses 2094 to be declined MUST be included in the IAs. Any addresses for the 2095 IAs the client wishes to continue to use should not be in added to 2096 the IAs. 2098 The client MUST NOT use any of the addresses it is declining as 2099 the source address in the Decline message or in any subsequently 2100 transmitted message. 2102 The client transmits the message according to section 14, using the 2103 following parameters: 2105 IRT DEC_TIMEOUT 2107 MRT 0 2108 MRC DEC_MAX_RC 2110 MRD 0 2112 If addresses are declined but the Reply from a DHCP server is lost, 2113 the client will retransmit the Decline message, and the server may 2114 respond with a Reply indicating a status of NoBinding. Therefore, 2115 the client does not treat a Reply message with a status of NoBinding 2116 in a Decline message exchange as if it indicates an error. 2118 18.1.8. Receipt of Reply Messages 2120 Upon the receipt of a valid Reply message in response to a Solicit 2121 (with a Rapid Commit option), Request, Confirm, Renew, Rebind or 2122 Information-request message, the client extracts the configuration 2123 information contained in the Reply. The client MAY choose to report 2124 any status code or message from the status code option in the Reply 2125 message. 2127 The client SHOULD perform duplicate address detection [20] on each 2128 of the addresses in any IAs it receives in the Reply message before 2129 using that address for traffic. If any of the addresses are found 2130 to be in use on the link, the client sends a Decline message to the 2131 server as described in section 18.1.7. 2133 If the Reply was received in response to a Solicit (with a Rapid 2134 Commit option), Request, Renew or Rebind message, the client updates 2135 the information it has recorded about IAs from the IA options 2136 contained in the Reply message: 2138 - Record T1 and T2 times 2140 - Add any new addresses in the IA option to the IA as recorded by 2141 the client 2143 - Update lifetimes for any addresses in the IA option that the 2144 client already has recorded in the IA 2146 - Discard any addresses from the IA as recorded by the client that 2147 have a lifetime of 0 in the IA Address option 2149 Management of the specific configuration information is detailed in 2150 the definition of each option, in section 22. 2152 If the client receives a Reply message with a Status Code containing 2153 UnspecFail, the server is indicating that it was unable to process 2154 the message due to an unspecified failure condition. If the client 2155 retransmits the original message to the same server to retry the 2156 desired operation, the client MUST limit the rate at which it 2157 retransmits the message and limit the duration of the time during 2158 which it retransmits the message. 2160 When the client receives a Reply message with a Status Code option 2161 with value UseMulticast, the client records the receipt of the 2162 message and sends subsequent messages to the server through the 2163 interface on which the message was received using multicast. The 2164 client resends the original message using multicast. 2166 When the client receives a NotOnLink status from the server in 2167 response to a Confirm message, the client performs DHCP server 2168 solicitation as described in section 17 and client-initiated 2169 configuration as described in section 18. If the client receives any 2170 Reply messages that do not indicate a NotOnLink status, the client 2171 can use the addresses in the IA and ignore any messages that do 2172 indicate a NotOnLink status. 2174 When the client receives a NotOnLink status from the server in 2175 response to a Request, the client can either re-issue the Request 2176 without specifying any addresses or restart the DHCP server discovery 2177 process (see section 17). 2179 When the client receives a NoAddrsAvail status from the server in 2180 response to a Request, the client can either try another server 2181 (perhaps restarting the DHCP server discovery process) or use the 2182 Information-Request to obtain configuration parameters only. 2184 When the client receives a NoBinding status in an IA from the server 2185 in response to a Renew message or a Rebind message, the client sends 2186 a Request to reestablish an IA with the server. 2188 When the client receives a valid Reply message in response to a 2189 Release message, the client considers the Release event completed, 2190 regardless of the Status Code option(s) returned by the server. 2192 When the client receives a valid Reply message in response to a 2193 Decline message, the client considers the Decline event completed, 2194 regardless of the Status Code option(s) returned by the server. 2196 18.2. Server Behavior 2198 For this discussion, the Server is assumed to have been configured in 2199 an implementation specific manner with configuration of interest to 2200 clients. 2202 In most instances, the server will send a Reply in response to a 2203 client message. This Reply message MUST always contain the Server 2204 Identifier option containing the server's DUID and the Client 2205 Identifier option from the client message if one was present. 2207 In most Reply messages, the server includes options containing 2208 configuration information for the client. The server SHOULD limit 2209 the options returned to the client so that the DHCP message header 2210 and options do not cause fragmentation. If the client included an 2211 Option Request option in its message, the server includes options 2212 in the Reply message containing configuration parameters for all of 2213 the options identified in the Option Request option that the server 2214 has been configured to return to the client. The server MAY return 2215 additional options to the client if it has been configured to do so. 2217 18.2.1. Receipt of Request Messages 2219 When the server receives a Request message via unicast from a 2220 client to which the server has not sent a unicast option, the server 2221 discards the Request message and responds with a Reply message 2222 containing a Status Code option with value UseMulticast, a Server 2223 Identifier option containing the server's DUID, the Client Identifier 2224 option from the client message and no other options. 2226 When the server receives a valid Request message, the server creates 2227 the bindings for that client according to the server's policy and 2228 configuration information and records the IAs and other information 2229 requested by the client. 2231 The server constructs a Reply message by setting the "msg-type" field 2232 to REPLY, copying the transaction ID from the Request message into 2233 the transaction-id field. 2235 The server MUST include a Server Identifier option containing the 2236 server's DUID and the Client Identifier option from the Request 2237 message in the Reply message. 2239 If the server finds that the prefix on one or more IP addresses in 2240 any IA in the message from the client is not appropriate to the link 2241 to which the client is connected, the server MUST return the IA to 2242 the client with a Status Code option with value NotOnLink. 2244 If the server cannot assign any addresses to an IA in the message 2245 from the client, the server MUST include the IA in the Reply message 2246 with no addresses in the IA and a Status Code option in the IA 2247 containing status code NoAddrsAvail. 2249 For any IAs to which the server can assign addresses, the server 2250 includes the IA with addresses and other configuration parameters and 2251 records the IA as a new client binding. 2253 The server MUST add a Reconfigure Accept option to indicate whether 2254 the client should accept any Reconfigure messages. 2256 The server includes other options containing configuration 2257 information to be returned to the client as described in 2258 section 18.2. 2260 18.2.2. Receipt of Confirm Messages 2262 When the server receives a Confirm message, the server determines if 2263 the addresses in the Confirm message are appropriate to the link to 2264 which the client is attached. If all of the addresses in the Confirm 2265 message pass this test, the server returns a status of Success. If 2266 any of the addresses do not pass this test, the server returns a 2267 status of NotOnLink. If the server is unable to perform this test 2268 (for example, the server does not have information about prefixes on 2269 the link to which the client is connected) or there were no addresses 2270 in any of the IAs sent by the client, the server MUST NOT send a 2271 reply to the client. 2273 The server ignores the T1 and T2 fields in the IA options and the 2274 preferred-lifetime and valid-lifetime fields in the IA Address 2275 options. 2277 The server constructs a Reply message by setting the "msg-type" field 2278 to REPLY, copying the transaction ID from the Confirm message into 2279 the transaction-id field. 2281 The server MUST include a Server Identifier option containing the 2282 server's DUID and the Client Identifier option from the Confirm 2283 message in the Reply message. The server includes a Status Code 2284 option indicating the status of the Confirm message. 2286 18.2.3. Receipt of Renew Messages 2288 When the server receives a Renew message via unicast from a client to 2289 which the server has not sent a unicast option, the server discards 2290 the Renew message and responds with a Reply message containing a 2291 Status Code option with value UseMulticast, a Server Identifier 2292 option containing the server's DUID, the Client Identifier option 2293 from the client message and no other options. 2295 When the server receives a Renew message that contains an IA option 2296 from a client, it locates the client's binding and verifies that the 2297 information in the IA from the client matches the information stored 2298 for that client. 2300 If the server cannot find a client entry for the IA the server 2301 returns the IA containing no addresses with a Status Code option set 2302 to NoBinding in the Reply message. 2304 If the server finds that any of the addresses are not appropriate 2305 to the link to which the client is attached, the server returns the 2306 address to the client with lifetimes of 0. 2308 If the server finds the addresses in the IA for the client then the 2309 server sends back the IA to the client with new lifetimes and T1/T2 2310 times. The server may choose to change the list of addresses and the 2311 lifetimes of addresses in IAs that are returned to the client. 2313 The server constructs a Reply message by setting the "msg-type" field 2314 to REPLY, copying the transaction ID from the Renew message into the 2315 transaction-id field. 2317 The server MUST include a Server Identifier option containing the 2318 server's DUID and the Client Identifier option from the Renew message 2319 in the Reply message. 2321 The server includes other options containing configuration 2322 information to be returned to the client as described in 2323 section 18.2. 2325 18.2.4. Receipt of Rebind Messages 2327 When the server receives a Rebind message that contains an IA option 2328 from a client, it locates the client's binding and verifies that the 2329 information in the IA from the client matches the information stored 2330 for that client. 2332 If the server cannot find a client entry for the IA the server 2333 returns the IA containing no addresses with a Status Code option set 2334 to NoBinding in the Reply message. 2336 If the server finds that any of the addresses are no longer 2337 appropriate to the link to which the client is attached, the server 2338 returns the address to the client with lifetimes of 0. 2340 If the server finds the addresses in the IA for the client then the 2341 server SHOULD send back the IA to the client with new lifetimes and 2342 T1/T2 times. 2344 The server constructs a Reply message by setting the "msg-type" field 2345 to REPLY, copying the transaction ID from the Rebind message into the 2346 transaction-id field. 2348 The server MUST include a Server Identifier option containing the 2349 server's DUID and the Client Identifier option from the Rebind 2350 message in the Reply message. 2352 The server includes other options containing configuration 2353 information to be returned to the client as described in 2354 section 18.2. 2356 18.2.5. Receipt of Information-request Messages 2358 When the server receives an Information-request message, the 2359 client is requesting configuration information that does not 2360 include the assignment of any addresses. The server determines all 2361 configuration parameters appropriate to the client, based on the 2362 server configuration policies known to the server. 2364 The server constructs a Reply message by setting the "msg-type" field 2365 to REPLY, copying the transaction ID from the Information-request 2366 message into the transaction-id field. 2368 The server MUST include a Server Identifier option containing the 2369 server's DUID in the Reply message. If the client included a Client 2370 Identification option in the Information-request message, the server 2371 copies that option to the Reply message. 2373 The server includes options containing configuration information to 2374 be returned to the client as described in section 18.2. 2376 If the Information-request message received from the client did 2377 not include a Client Identifier option, the server SHOULD respond 2378 with a Reply message containing any configuration parameters 2379 that are not determined by the client's identity. If the server 2380 chooses not to respond, the client may continue to retransmit the 2381 Information-request message indefinitely. 2383 18.2.6. Receipt of Release Messages 2385 When the server receives a Release message via unicast from a 2386 client to which the server has not sent a unicast option, the server 2387 discards the Release message and responds with a Reply message 2388 containing a Status Code option with value UseMulticast, a Server 2389 Identifier option containing the server's DUID, the Client Identifier 2390 option from the client message and no other options. 2392 Upon the receipt of a valid Release message, the server examines 2393 the IAs and the addresses in the IAs for validity. If the IAs in 2394 the message are in a binding for the client and the addresses in 2395 the IAs have been assigned by the server to those IAs, the server 2396 deletes the addresses from the IAs and makes the addresses available 2397 for assignment to other clients. The server ignores addresses not 2398 assigned to the IA, although it may choose to log an error. 2400 After all the addresses have been processed, the server generates a 2401 Reply message and includes a Status Code option with value Success, 2402 a Server Identifier option with the server's DUID and a Client 2403 Identifier option with the client's DUID. For each IA in the Release 2404 message for which the server has no binding information, the server 2405 adds an IA option using the IAID from the Release message and 2406 includes a Status Code option with the value NoBinding in the IA 2407 option. No other options are included in the IA option. 2409 A server may choose to retain a record of assigned addresses and IAs 2410 after the lifetimes on the addresses have expired to allow the server 2411 to reassign the previously assigned addresses to a client. 2413 18.2.7. Receipt of Decline Messages 2415 When the server receives a Decline message via unicast from a 2416 client to which the server has not sent a unicast option, the server 2417 discards the Decline message and responds with a Reply message 2418 containing a Status Code option with value UseMulticast, a Server 2419 Identifier option containing the server's DUID, the Client Identifier 2420 option from the client message and no other options. 2422 Upon the receipt of a valid Decline message, the server examines the 2423 IAs and the addresses in the IAs for validity. If the IAs in the 2424 message are in a binding for the client and the addresses in the IAs 2425 have been assigned by the server to those IA, the server deletes 2426 the addresses from the IAs. The server SHOULD mark the addresses 2427 declined by the client so that those addresses are not assigned to 2428 other clients, and MAY choose to make a notification that addresses 2429 were declined. The server ignores addresses not assigned to the IA 2430 (though it may choose to log an error if it finds such an address). 2432 After all the address have been processed, the server generates a 2433 Reply message and includes a Status Code option with value Success, 2434 a Server Identifier option with the server's DUID and a Client 2435 Identifier option with the client's DUID. For each IA in the Decline 2436 message for which the server has no binding information, the server 2437 adds an IA option using the IAID from the Release message and 2438 includes a Status Code option with the value NoBinding in the IA 2439 option. No other options are included in the IA option. 2441 18.2.8. Transmission of Reply Messages 2443 If the original message was received directly by the server, the 2444 server unicasts the Reply message directly to the client using the 2445 address in the source address field from the IP datagram in which the 2446 original message was received. The Reply message MUST be unicast 2447 through the interface on which the original message was received. 2449 If the original message was received in a Relay-forward message, 2450 the server constructs a Relay-reply message with the Reply message 2451 in the payload of a Relay Message option (see section!22.10). If 2452 the Relay-forward messages included an Interface-id option, the 2453 server copies that option to the Relay-reply message. The server 2454 unicasts the Relay-reply message directly to the relay agent using 2455 the address in the source address field from the IP datagram in which 2456 the Relay-forward message was received. 2458 19. DHCP Server-Initiated Configuration Exchange 2460 A server initiates a configuration exchange to cause DHCP clients 2461 to obtain new addresses and other configuration information. For 2462 example, an administrator may use a server-initiated configuration 2463 exchange when links in the DHCP domain are to be renumbered. Other 2464 examples include changes in the location of directory servers, 2465 addition of new services such as printing, and availability of new 2466 software. 2468 19.1. Server Behavior 2470 A server sends a Reconfigure message to cause a client to initiate 2471 immediately a Renew/Reply or Information-request/Reply message 2472 exchange with the server. 2474 19.1.1. Creation and Transmission of Reconfigure Messages 2476 The server sets the "msg-type" field to RECONFIGURE. The server 2477 sets the transaction-id field to 0. The server includes a Server 2478 Identifier option containing its DUID and a Client Identifier option 2479 containing the client's DUID in the Reconfigure message. 2481 The server MAY include an Option Request option to inform the client 2482 of what information has been changed or new information that has 2483 been added. In particular, the server specifies the IA option in 2484 the Option Request option if the server wants the client to obtain 2485 new address information. If the server identifies the IA option 2486 in the Option Request option, the server MUST include an IA option 2487 that contains no other sub-options to identify each IA that is to be 2488 reconfigured on the client. 2490 Because of the risk of denial of service attacks against DHCP 2491 clients, the use of a security mechanism is mandated in Reconfigure 2492 messages. The server MUST use DHCP authentication in the Reconfigure 2493 message. 2495 The server MUST include a Reconfigure Message option (defined in 2496 section 22.19) to select whether the client responds with a Renew 2497 message or an Information-Request message. 2499 The server MUST NOT include any other options in the Reconfigure 2500 except as specifically allowed in the definition of individual 2501 options. 2503 A server sends each Reconfigure message to a single DHCP client, 2504 using an IPv6 unicast address of sufficient scope belonging to the 2505 DHCP client. If the server does not have an address to which it can 2506 send the Reconfigure message directly to the client, the server uses 2507 a Relay-reply message (as described in section 20.3) to send the 2508 Reconfigure message to a relay agent that will relay the message to 2509 the client. The server may obtain the address of the client (and 2510 the appropriate relay agent, if required) through the information 2511 that the server has about clients that have been in contact with the 2512 server, or through some external agent. 2514 To reconfigure more than one client, the server unicasts a separate 2515 message to each client. The server may initiate the reconfiguration 2516 of multiple clients concurrently; for example, a server may 2517 send a Reconfigure message to additional clients while previous 2518 reconfiguration message exchanges are still in progress. 2520 The Reconfigure message causes the client to initiate a Renew/Reply 2521 or Information-request/Reply message exchange with the server. The 2522 server interprets the receipt of a Renew or Information-request 2523 message (whichever was specified in the original Reconfigure message) 2524 from the client as satisfying the Reconfigure message request. 2526 19.1.2. Time Out and Retransmission of Reconfigure Messages 2528 If the server does not receive a Renew or Information-request 2529 message from the client in REC_TIMEOUT milliseconds, the server 2530 retransmits the Reconfigure message, doubles the REC_TIMEOUT value 2531 and waits again. The server continues this process until REC_MAX_RC 2532 unsuccessful attempts have been made, at which point the server 2533 SHOULD abort the reconfigure process for that client. 2535 Default and initial values for REC_TIMEOUT and REC_MAX_RC are 2536 documented in section 5.5. 2538 19.2. Receipt of Renew Messages 2540 The server generates and sends a Reply message to the client as 2541 described in sections 18.2.3 and 18.2.8, including options for 2542 configuration parameters. 2544 The server MAY include options containing the IAs and new values for 2545 other configuration parameters in the Reply message, even if those 2546 IAs and parameters were not requested in the Renew message from the 2547 client. 2549 19.3. Receipt of Information-request Messages 2551 The server generates and sends a Reply message to the client as 2552 described in sections 18.2.5 and 18.2.8, including options for 2553 configuration parameters. 2555 The server MAY include options containing new values for other 2556 configuration parameters in the Reply message, even if those 2557 parameters were not requested in the Information-request message from 2558 the client. 2560 19.4. Client Behavior 2562 A client receives Reconfigure messages sent to UDP port 546 on 2563 interfaces for which it has acquired configuration information 2564 through DHCP. These messages may be sent at any time. Since the 2565 results of a reconfiguration event may affect application layer 2566 programs, the client SHOULD log these events, and MAY notify these 2567 programs of the change through an implementation-specific interface. 2569 19.4.1. Receipt of Reconfigure Messages 2571 Upon receipt of a valid Reconfigure message, the client responds with 2572 either a Renew message or an Information-request message as indicated 2573 by the Reconfigure Message option (as defined in section 22.19). The 2574 client ignores the transaction-id field in the received Reconfigure 2575 message. While the transaction is in progress, the client silently 2576 discards any Reconfigure messages it receives. 2578 DISCUSSION: 2580 The Reconfigure message acts as a trigger that signals the 2581 client to complete a successful message exchange. Once 2582 the client has received a Reconfigure, the client proceeds 2583 with the message exchange (retransmitting the Renew or 2584 Information-request message if necessary); the client 2585 ignores any additional Reconfigure messages until the 2586 exchange is complete. Subsequent Reconfigure messages cause 2587 the client to initiate a new exchange. 2589 How does this mechanism work in the face of duplicated or 2590 retransmitted Reconfigure messages? Duplicate messages 2591 will be ignored because the client will begin the exchange 2592 after the receipt of the first Reconfigure. Retransmitted 2593 messages will either trigger the exchange (if the first 2594 Reconfigure was not received by the client) or will be 2595 ignored. The server can discontinue retransmission of 2596 Reconfigure messages to the client once the server receives 2597 the Renew or Information-request message from the client. 2599 It might be possible for a duplicate or retransmitted 2600 Reconfigure to be sufficiently delayed (and delivered out of 2601 order) to arrive at the client after the exchange (initiated 2602 by the original Reconfigure) has been completed. In this 2603 case, the client would initiate a redundant exchange. The 2604 likelihood of delayed and out of order delivery is small 2605 enough to be ignored. The consequence of the redundant 2606 exchange is inefficiency rather than incorrect operation. 2608 19.4.2. Creation and Transmission of Renew Messages 2610 When responding to a Reconfigure, the client creates and sends 2611 the Renew message in exactly the same manner as outlined in 2612 section 18.1.3, with the exception that the client copies the Option 2613 Request option and any IA options from the Reconfigure message into 2614 the Renew message. 2616 19.4.3. Creation and Transmission of Information-request Messages 2618 When responding to a Reconfigure, the client creates and sends the 2619 Information-request message in exactly the same manner as outlined in 2620 section 18.1.5, with the exception that the client includes a Server 2621 Identifier option with the identifier from the Reconfigure message to 2622 which the client is responding. 2624 19.4.4. Time Out and Retransmission of Renew or Information-request 2625 Messages 2627 The client uses the same variables and retransmission algorithm as 2628 it does with Renew or Information-request messages generated as part 2629 of a client-initiated configuration exchange. See sections 18.1.3 2630 and 18.1.5 for details. If the client does not receive a response 2631 from the server by the end of the retransmission process, the client 2632 ignores and discards the Reconfigure message. 2634 19.4.5. Receipt of Reply Messages 2636 Upon the receipt of a valid Reply message, the client processes the 2637 options and sets (or resets) configuration parameters appropriately. 2638 The client records and updates the lifetimes for any addresses 2639 specified in IAs in the Reply message. 2641 20. Relay Agent Behavior 2643 The relay agent MAY be configured to use a list of destination 2644 addresses, which MAY include unicast addresses, the All_DHCP_Servers 2645 multicast address, or other addresses selected by the network 2646 administrator. If the relay agent has not been explicitly 2647 configured, it MUST use the All_DHCP_Servers multicast address as the 2648 default. 2650 If the relay agent relays messages to the All_DHCP_Servers multicast 2651 address or other multicast addresses, it sets the Hop Limit field to 2652 32. 2654 20.1. Relaying a Client Message or a Relay-forward Message 2656 A relay agent relays both messages from clients and Relay-forward 2657 messages from other relay agents. When a relay agent receives a 2658 valid message to be relayed, it constructs a new Relay-forward 2659 message. The relay agent copies the source address from the 2660 header of the IP datagram in which the message was received to the 2661 peer-address field of the Relay-forward message. The relay agent 2662 copies the received DHCP message (excluding any IP or UDP headers) 2663 into a Relay Message option in the new message. The relay agent adds 2664 to the Relay-forward message any other options it is configured to 2665 include. 2667 20.1.1. Relaying a Message from a Client 2669 If the relay agent received the message to be relayed from a client, 2670 the relay agent places a global or site-scoped address with a prefix 2671 assigned to the link on which the client should be assigned an 2672 address in the link-address field. This address will be used by the 2673 server to determine the link from which the client should be assigned 2674 an address and other configuration information. The hop-count in the 2675 Relay-forward message is set to 0. 2677 If the relay agent cannot use the address in the link-address field 2678 to identify the interface through which the response to the client 2679 will be relayed, the relay agent MUST include an Interface-id option 2680 (see section 22.18) in the Relay-forward message. The server will 2681 include the Interface-id option in its Relay-reply message. The 2682 relay agent fills in the link-address field as described in the 2683 previous paragraph regardless of whether the relay agent includes an 2684 Interface-id option in the Relay-forward message. 2686 20.1.2. Relaying a Message from a Relay Agent 2688 If the message received by the relay agent is a Relay-forward 2689 message and the hop-count in the message is greater than or equal to 2690 HOP_COUNT_LIMIT, the relay agent discards the received message. 2692 The relay agent copies the source address from the IP datagram in 2693 which the message was received from the client into the peer-address 2694 field in the Relay-forward message and sets the hop-count field to 2695 the value of the hop-count field in the received message incremented 2696 by 1. 2698 If the source address from the IP datagram header of the received 2699 message is a global or site-local address (and the device on which 2700 the relay agent is running belongs to only one site), the relay agent 2701 sets the link-address field to 0; otherwise the relay agent sets 2702 the link-address field to a global or site-local address assigned 2703 to the interface on which the message was received, or includes an 2704 Interface-ID option to identify the interface on which the message 2705 was received. 2707 20.2. Relaying a Relay-reply Message 2709 The relay agent processes any options included in the Relay-reply 2710 message in addition to the Relay Message option and then discards 2711 those options. 2713 The relay agent extracts the message from the Relay Message option 2714 and relays it to the address contained in the peer-address field of 2715 the Relay-reply message. 2717 If the Relay-reply message includes an Interface-id option, the 2718 relay agent relays the message from the server to the client on 2719 the link identified by the Interface-id option. Otherwise, if the 2720 link-address field is not set to zero, the relay agent relays the 2721 message on the link identified by the link-address field. 2723 20.3. Construction of Relay-reply Messages 2725 A server uses a Relay-reply message to return a response to a client 2726 if the original message from the client was relayed to the server in 2727 a Relay-forward message or to send a Reconfigure message to a client 2728 if the server does not have an address it can use to send the message 2729 directly to the client. 2731 A response to the client MUST be relayed through the same relay 2732 agents as the original client message. The server causes this to 2733 happen by creating a Relay-reply message that includes a Relay 2734 Message option containing the message for the next relay agent in 2735 the return path to the client. The contained Relay-reply message 2736 contains another Relay Message option to be sent to the next relay 2737 agent, and so on. The server must record the contents of the 2738 peer-address fields in the received message so it can construct 2739 the appropriate Relay-reply message carrying the response from the 2740 server. 2742 For example, if client C sent a message that was relayed by relay 2743 agent A to relay agent B and then to the server, the server would 2744 send the following Relay-Reply message to relay agent B: 2746 msg-type: RELAY-REPLY 2747 hop-count: 1 2748 link-address: 0 2749 peer-address: A 2750 Relay Message option, containing: 2751 msg-type: RELAY-REPLY 2752 hop-count: 0 2753 link-address: address from link to which C is attached 2754 peer-address: C 2755 Relay Message option: 2757 When sending a Reconfigure message to a client through a relay 2758 agent, the server creates a Relay-reply message that includes a 2759 Relay Message option containing the Reconfigure message for the 2760 next relay agent in the return path to the client. The server sets 2761 the peer-address field in the Relay-reply message header to the 2762 address of the client, and sets the link-address field as required 2763 by the relay agent to relay the Reconfigure message to the client. 2764 The server obtains the addresses of the client and the relay agent 2765 through prior interaction with the client or through some external 2766 mechanism. 2768 21. Authentication of DHCP Messages 2770 Some network administrators may wish to provide authentication of 2771 the source and contents of DHCP messages. For example, clients may 2772 be subject to denial of service attacks through the use of bogus 2773 DHCP servers, or may simply be misconfigured due to unintentionally 2774 instantiated DHCP servers. Network administrators may wish to 2775 constrain the allocation of addresses to authorized hosts to avoid 2776 denial of service attacks in "hostile" environments where the network 2777 medium is not physically secured, such as wireless networks or 2778 college residence halls. 2780 The DHCP authentication mechanism is based on the design of 2781 authentication for DHCPv4 [6]. 2783 21.1. Security of Messages Sent Between Servers and Relay Agents 2785 Relay agents and servers that exchange messages securely use the 2786 IPsec mechanisms for IPv6 [10]. Relay agents and servers MUST 2787 support manual configuration and installation of static keys. If 2788 a client message is relayed through multiple relay agents, each of 2789 the relay agents must have established independent, pairwise trust 2790 relationships. That is, if messages from client C will be relayed by 2791 relay agent A to relay agent B and then to the server, relay agents A 2792 and B must be configured to use IPSec for the messages they exchange, 2793 and relay agent B and the server must be configured to use IPSec for 2794 the messages they exchange. 2796 Relay agents and servers that support secure relay agent to server 2797 or relay agent to relay agent communication, MUST include an IPsec 2798 implementation with the following restrictions: 2800 - The IPsec implementation MUST use ESP 2802 - Packet authentication MUST be applied 2804 - Encryption MAY be applied (i.e., NULL encryption can be used) 2806 21.2. Summary of DHCP Authentication 2808 Authentication of DHCP messages is accomplished through the use of 2809 the Authentication option (see section 22.11). The authentication 2810 information carried in the Authentication option can be used to 2811 reliably identify the source of a DHCP message and to confirm that 2812 the contents of the DHCP message have not been tampered with. 2814 The Authentication option provides a framework for multiple 2815 authentication protocols. Two such protocols are defined here. 2816 Other protocols defined in the future will be specified in separate 2817 documents. 2819 Any DHCP message MUST NOT include more than one Authentication 2820 option. 2822 The protocol field in the Authentication option identifies the 2823 specific protocol used to generate the authentication information 2824 carried in the option. The algorithm field identifies a specific 2825 algorithm within the authentication protocol; for example, the 2826 algorithm field specifies the hash algorithm used to generate the 2827 message authentication code (MAC) in the authentication option. The 2828 replay detection method (RDM) field specifies the type of replay 2829 detection used in the replay detection field. 2831 21.3. Replay Detection 2833 The Replay Detection Method (RDM) field determines the type of replay 2834 detection used in the Replay Detection field. 2836 If the RDM field contains 0x00, the replay detection field MUST 2837 be set to the value of a monotonically increasing counter. Using 2838 a counter value such as the current time of day (for example, an 2839 NTP-format timestamp [12]) can reduce the danger of replay attacks. 2840 This method MUST be supported by all protocols. 2842 21.4. Delayed Authentication Protocol 2844 If the protocol field is 2, the message is using the "delayed 2845 authentication" mechanism. In delayed authentication, the client 2846 requests authentication in its Solicit message and the server replies 2847 with an Advertise message that includes authentication information. 2848 This authentication information contains a nonce value generated by 2849 the source as a message authentication code (MAC) to provide message 2850 authentication and entity authentication. 2852 The use of a particular technique based on the HMAC protocol [11] 2853 using the MD5 hash [19] is defined here. 2855 21.4.1. Use of the Authentication Option in the Delayed Authentication 2856 Protocol 2858 In a Solicit message, the client fills in the protocol, algorithm 2859 and RDM fields in the Authentication option with the client's 2860 preferences. The client sets the replay detection field to zero and 2861 omits the authentication information field. The client sets the 2862 option-len field to 11. 2864 In all other messages, the protocol and algorithm fields identifies 2865 the method used to construct the contents of the authentication 2866 information field. The RDM field identifies the method used to 2867 construct the contents of the replay detection field. The format of 2868 the Authentication information is: 2870 0 1 2 3 2871 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 2872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2873 | DHCP realm | 2874 | (variable length) | 2875 . . 2876 . . 2877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2878 | key ID | 2879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2880 | | 2881 | HMAC-MD5 | 2882 | (128 bits) | 2883 | | 2884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2886 DHCP realm The DHCP realm that identifies the key used to 2887 generate the HMAC-MD5 value 2889 key ID The key identifier that identified the key used to 2890 generate the HMAC-MD5 value 2892 HMAC-MD5 The message signature generated by applying MD5 to 2893 the DHCP message using the key identified by the DHCP 2894 realm, client DUID and key ID 2896 The sender computes the MAC using the HMAC generation algorithm [11] 2897 and the MD5 hash function [19]. The entire DHCP message (setting 2898 the MAC field of the authentication option to zero), including the 2899 DHCP message header and the options field, is used as input to the 2900 HMAC-MD5 computation function. 2902 DISCUSSION: 2904 Algorithm 1 specifies the use of HMAC-MD5. Use of a 2905 different technique, such as HMAC-SHA, will be specified as 2906 a separate protocol. 2908 The DHCP realm used to identify authentication keys is 2909 chosen to be unique among administrative domains. Use of 2910 the DHCP realm allows DHCP administrators to avoid conflict 2911 in the use of key identifiers, and allows a host using 2912 DHCP to use authenticated DHCP while roaming among DHCP 2913 administrative domains. 2915 21.4.2. Message Validation 2917 Any DHCP message that includes more than one authentication option 2918 MUST be discarded. 2920 To validate an incoming message, the receiver first checks that 2921 the value in the replay detection field is acceptable according to 2922 the replay detection method specified by the RDM field. Next, the 2923 receiver computes the MAC as described in [11]. The entire DHCP 2924 message (setting the MAC field of the authentication option to 0), 2925 is used as input to the HMAC-MD5 computation function. If the MAC 2926 computed by the receiver does not match the MAC contained in the 2927 authentication option, the receiver MUST discard the DHCP message. 2929 21.4.3. Key Utilization 2931 Each DHCP client has a set of keys. Each key is identifier by . Each key also has a lifetime. The key 2933 may not be used past the end of its lifetime. The client's keys 2934 are initially distributed to the client through some out-of-band 2935 mechanism. The lifetime for each key is distributed with the key. 2936 Mechanisms for key distribution and lifetime specification are beyond 2937 the scope of this document. 2939 The client and server use one of the client's keys to authenticate 2940 DHCP messages during a session (until the next Solicit message 2941 broadcast by the client). 2943 21.4.4. Client Considerations for Delayed Authentication Protocol 2945 The client announces its intention to use DHCP authentication by 2946 including an Authentication option in its Solicit message. The 2947 server selects a key for the client based on the client's DUID. The 2948 client and server use that key to authenticate all DHCP messages 2949 exchanged during the session. 2951 21.4.4.1. Sending Solicit Messages 2953 When the client sends a Solicit message and wishes to use 2954 authentication, it includes an Authentication option with the desired 2955 protocol, algorithm and RDM as described in section 21.4. The client 2956 does not include any replay detection or authentication information 2957 in the Authentication option. 2959 21.4.4.2. Receiving Advertise Messages 2961 The client validates any Advertise messages containing an 2962 Authentication option specifying the delayed authentication protocol 2963 using the validation test described in section 21.4.2. 2965 Client behavior if no Advertise messages include authentication 2966 information or pass the validation test is controlled by local policy 2967 on the client. According to client policy, the client MAY choose to 2968 respond to a Advertise message that has not been authenticated. 2970 The decision to set local policy to accept unauthenticated messages 2971 should be made with care. Accepting an unauthenticated Advertise 2972 message can make the client vulnerable to spoofing and other 2973 attacks. If local users are not explicitly informed that the client 2974 has accepted an unauthenticated Advertise message, the users may 2975 incorrectly assume that the client has received an authenticated 2976 address and is not subject to DHCP attacks through unauthenticated 2977 messages. 2979 A client MUST be configurable to discard unauthenticated messages, 2980 and SHOULD be configured by default to discard unauthenticated 2981 messages if the client has been configured with an authentication 2982 key or other authentication information. A client MAY choose to 2983 differentiate between Advertise messages with no authentication 2984 information and Advertise messages that do not pass the validation 2985 test; for example, a client might accept the former and discard the 2986 latter. If a client does accept an unauthenticated message, the 2987 client SHOULD inform any local users and SHOULD log the event. 2989 21.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline or Release 2990 Messages 2992 If the client authenticated the Advertise message through which the 2993 client selected the server, the client MUST generate authentication 2994 information for subsequent Request, Confirm, Renew, Rebind or Release 2995 messages sent to the server as described in section 21.4. When the 2996 client sends a subsequent message, it MUST use the same key used by 2997 the server to generate the authentication information. 2999 21.4.4.4. Sending Information-request Messages 3001 If the server has selected a key for the client in a previous message 3002 exchange (see section 21.4.5.1), the client MUST use the same key to 3003 generate the authentication information throughout the session. 3005 21.4.4.5. Receiving Reply Messages 3007 If the client authenticated the Advertise it accepted, the client 3008 MUST validate the associated Reply message from the server. The 3009 client MUST discard the Reply if the message fails to pass the 3010 validation test and MAY log the validation failure. If the Reply 3011 fails to pass the validation test, the client MUST restart the DHCP 3012 configuration process by sending a Solicit message. 3014 If the client accepted an Advertise message that did not include 3015 authentication information or did not pass the validation test, the 3016 client MAY accept an unauthenticated Reply message from the server. 3018 21.4.4.6. Receiving Reconfigure Messages 3020 The client MUST discard the Reconfigure if the message fails to pass 3021 the validation test and MAY log the validation failure. 3023 21.4.5. Server Considerations for Delayed Authentication Protocol 3025 After receiving a Solicit message that contains an Authentication 3026 option, the server selects a key for the client based on the client's 3027 DUID and key selection policies with which the server has been 3028 configured. The server identifies the selected key in the Advertise 3029 message and uses the key to validate subsequent messages between the 3030 client and the server. 3032 21.4.5.1. Receiving Solicit Messages and Sending Advertise Messages 3034 The server selects a key for the client and includes authentication 3035 information in the Advertise message returned to the client as 3036 specified in section 21.4. The server MUST record the identifier of 3037 the key selected for the client and use that same key for validating 3038 subsequent messages with the client. 3040 21.4.5.2. Receiving Request, Confirm, Renew, Rebind or Release Messages 3041 and Sending Reply Messages 3043 The server uses the key identified in the message and validates the 3044 message as specified in section 21.4.2. If the message fails to pass 3045 the validation test or the server does not know the key identified 3046 by the 'key ID' field, the server MUST discard the message and MAY 3047 choose to log the validation failure. 3049 If the message passes the validation test, the server responds to 3050 the specific message as described in section 18.2. The server MUST 3051 include authentication information generated using the key identified 3052 in the received message as specified in section 21.4. 3054 21.5. Reconfigure Key Authentication Protocol 3056 The Reconfigure key authentication protocol provides protection 3057 against misconfiguration of a client caused by a Reconfigure message 3058 sent by a malicious DHCP server. In this protocol, a DHCP server 3059 sends a Reconfigure Key to the client in the initial exchange of 3060 DHCP messages. The client records the Reconfigure Key for use in 3061 authenticating subsequent Reconfigure messages from that server. The 3062 server then includes an HMAC computed from the Reconfigure Key in 3063 subsequent Reconfigure messages. 3065 Both the Reconfigure Key sent from the server to the client and 3066 the HMAC in subsequent Reconfigure messages are carried as the 3067 Authentication information in an Authentication option. The format 3068 of the Authentication information is defined in the following 3069 section. 3071 The Reconfigure Key protocol is used (initiated by the server) only 3072 if the client and server are not using any other authentication 3073 protocol and the client and server have negotiated to use Reconfigure 3074 messages. 3076 21.5.1. Use of the Authentication Option in the Reconfigure Key 3077 Authentication Protocol 3079 The following fields are set in an Authentication option for the 3080 Reconfigure Key Authentication Protocol: 3082 protocol 3 3084 algorithm 1 3086 RDM 0 3088 The format of the Authentication information for the Reconfigure Key 3089 Authentication Protocol is: 3091 0 1 2 3 3092 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 3093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3094 | Type | Value (128 bits) | 3095 +-+-+-+-+-+-+-+-+ | 3096 . . 3097 . . 3098 . +-+-+-+-+-+-+-+-+ 3099 | | 3100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3102 Type Type of data in Value field carried in this option: 3104 1 Reconfigure Key value (used in Reply message) 3105 2 HMAC-MD5 digest of the message (used in Reconfigure 3106 message) 3108 Value Data as defined by field 3110 21.5.2. Server considerations for Reconfigure Key protocol 3112 The server selects a Reconfigure Key for a client during the 3113 Request/Reply, Solicit/Reply or Information-request/Reply message 3114 exchange. The server records the Reconfigure Key and transmits that 3115 key to the client in an Authentication option in the Reply message. 3117 The Reconfigure Key is 128 bits long, and MUST be a cryptographically 3118 strong random or pseudo-random number that cannot easily be 3119 predicted. 3121 To provide authentication for a Reconfigure message, the server 3122 selects a replay detection value according to the RDM selected by 3123 the server, and computes an HMAC-MD5 of the Reconfigure message 3124 using the Reconfigure Key for the client. The server computes the 3125 HMAC-MD5 over then entire DHCP Reconfigure message, including the 3126 Authentication option; the HMAC-MD5 field in the Authentication 3127 option is set to zero for the HMAC-MD5 computation. The server 3128 includes the HMAC-MD5 in the authentication information field in an 3129 Authentication option included in the Reconfigure message sent to the 3130 client. 3132 21.5.3. Client considerations for Reconfigure Key protocol 3134 The client will receive a Reconfigure Key from the server in the 3135 initial Reply message from the server. The client records the 3136 Reconfigure Key for use in authenticating subsequent Reconfigure 3137 messages. 3139 To authenticate a Reconfigure message, the client computes an 3140 HMAC-MD5 over the DHCP Reconfigure message, using the Reconfigure 3141 Key received from the server. If this computed HMAC-MD5 matches 3142 the value in the Authentication option, the client accepts the 3143 Reconfigure message. 3145 22. DHCP Options 3147 Options are used to carry additional information and parameters 3148 in DHCP messages. Every option shares a common base format, as 3149 described in section 22.1. All values in options are represented in 3150 network byte order. 3152 This document describes the DHCP options defined as part of the base 3153 DHCP specification. Other options may be defined in the future in 3154 separate documents. 3156 Unless otherwise noted, each option may appear only in the options 3157 area of a DHCP message and may appear only once. If an option does 3158 appear multiple times, each instance is considered separate and the 3159 data areas of the options MUST NOT be concatenated or otherwise 3160 combined. 3162 22.1. Format of DHCP Options 3164 The format of DHCP options is: 3166 0 1 2 3 3167 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 3168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3169 | option-code | option-len | 3170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3171 | option-data | 3172 | (option-len octets) | 3173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3175 option-code An unsigned integer identifying the specific option 3176 type carried in this option. 3178 option-len An unsigned integer giving the length of the 3179 option-data field in this option in octets. 3181 option-data The data for the option; the format of this data 3182 depends on the definition of the option. 3184 DHCPv6 options are scoped by using encapsulation. Some options apply 3185 generally to the client, some are specific to an IA, and some are 3186 specific to the addresses within an IA. These latter two cases are 3187 discussed in sections 22.4 and 22.6. 3189 22.2. Client Identifier Option 3191 The Client Identifier option is used to carry a DUID (see section 9) 3192 identifying a client between a client and a server. The format of 3193 the Client Identifier option is: 3195 0 1 2 3 3196 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 3197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3198 | OPTION_CLIENTID | option-len | 3199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3200 . . 3201 . DUID . 3202 . (variable length) . 3203 . . 3204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3205 option-code OPTION_CLIENTID (1) 3207 option-len Length of DUID in octets 3209 DUID The DUID for the client 3211 22.3. Server Identifier Option 3213 The Server Identifier option is used to carry a DUID (see section 9) 3214 identifying a server between a client and a server. The format of 3215 the Server Identifier option is: 3217 0 1 2 3 3218 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 3219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3220 | OPTION_SERVERID | option-len | 3221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3222 . . 3223 . DUID . 3224 . (variable length) . 3225 . . 3226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3228 option-code OPTION_SERVERID (2) 3230 option-len Length of DUID in octets 3232 DUID The DUID for the server 3234 22.4. Identity Association for Non-temporary Addresses Option 3236 The Identity Association for Non-temporary Addresses option (IA_NA 3237 option) is used to carry an identity association, the parameters 3238 associated with the IA and the non-temporary addresses associated 3239 with the IA_NA. 3241 Addresses appearing in an IA_NA option are not temporary addresses 3242 (see section 22.5). 3244 The format of the IA_NA option is: 3246 0 1 2 3 3247 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 3248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3249 | OPTION_IA_NA | option-len | 3250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3251 | IAID (4 octets) | 3252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3253 | T1 | 3254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3255 | T2 | 3256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3257 | | 3258 . IA_NA-options . 3259 . . 3260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3262 option-code OPTION_IA_NA (3) 3264 option-len 12 + length of IA_NA-options field 3266 IAID The unique identifier for this IA; the IAID 3267 must be unique among the identifiers for all 3268 of this client's IAs. The number space for 3269 IA_NA IAIDs is separate from the number space 3270 for IA_TA IAIDs. 3272 T1 The time at which the client contacts the 3273 server from which the addresses in the IA_NA 3274 were obtained to extend the lifetimes of the 3275 addresses assigned to the IA_NA; T1 is a 3276 time duration relative to the current time 3277 expressed in units of seconds 3279 T2 The time at which the client contacts any 3280 available server to extend the lifetimes of 3281 the addresses assigned to the IA_NA; T2 is a 3282 time duration relative to the current time 3283 expressed in units of seconds 3285 IA_NA-options Options associated with this IA_NA. 3287 The IA_NA-options field encapsulates those options that are specific 3288 to this IA_NA. For example, all of the IA Address Options carrying 3289 the addresses associated with this IA are in the IA_NA-options field. 3291 An IA_NA option may only appear in the options area of a DHCP 3292 message. A DHCP message may contain multiple IA_NA options. 3294 The status of any operations involving this IA_NA is indicated in a 3295 Status Code option in the IA_NA-options field. 3297 Note that an IA_NA has no explicit "lifetime" or "lease length" of 3298 its own. When the valid lifetimes of all of the addresses in an 3299 IA_NA have expired, the IA_NA can be considered as having expired. 3300 T1 and T2 are included to give servers explicit control over when a 3301 client recontacts the server about a specific IA_NA. 3303 In a message sent by a client to a server, values in the T1 and T2 3304 fields indicate the client's preference for those parameters. The 3305 client sets T1 and T2 to 0 if it has no preference for those values. 3306 In a message sent by a server to a client, the client MUST use the 3307 values in the T1 and T2 fields for the T1 and T2 parameters. The 3308 values in the T1 and T2 fields are the number of seconds until T1 and 3309 T2. 3311 The server selects the T1 and T2 times to allow the client to extend 3312 the lifetimes of any addresses in the IA_NA before the lifetimes 3313 expire, even if the server is unavailable for some short period of 3314 time. Recommended values for T1 and T2 are .5 and .8 times the 3315 shortest preferred lifetime of the addresses in the IA, respectively. 3316 If the time at which the addresses in an IA_NA are to be renewed is 3317 to be left to the discretion of the client, the server sets T1 and T2 3318 to 0. 3320 22.5. Identity Association for Temporary Addresses Option 3322 The Identity Association for Temporary Addresses (IA_TA) option is 3323 used to carry an IA_TA, the parameters associated with the IA_TA and 3324 the addresses associated with the IA_TA. All of the addresses in this 3325 option are used by the client as temporary addresses, as defined in 3326 RFC 3041 [15]. The format of the IA_TA option is: 3328 0 1 2 3 3329 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 3330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3331 | OPTION_IA_TA | option-len | 3332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3333 | IAID (4 octets) | 3334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3335 | | 3336 . IA_TA-options . 3337 . . 3338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3340 option-code OPTION_IA_TA (4) 3342 option-len 4 + length of IA_TA-options field 3343 IAID The unique identifier for this IA_TA; the 3344 IAID must be unique among the identifiers 3345 for all of this client's IA_TAs. The number 3346 space for IA_TA IAIDs is separate from the 3347 number space for IA_NA IAIDs. 3349 IA_TA-options Options associated with this IA_TA. 3351 The IA_TA-Options field encapsulates those options that are specific 3352 to this IA_TA. For example, all of the IA Address Options carrying 3353 the addresses associated with this IA_TA are in the IA_TA-options 3354 field. 3356 Each IA_TA carries one "set" of temporary addresses; that is, at most 3357 one address from each prefix assigned to the link to which the client 3358 is attached. 3360 An IA_TA option may only appear in the options area of a DHCP 3361 message. A DHCP message may contain multiple IA_TA options. 3363 The status of any operations involving this IA_TA is indicated in a 3364 Status Code option in the IA_TA-options field. 3366 Note that an IA has no explicit "lifetime" or "lease length" of its 3367 own. When the valid lifetimes of all of the addresses in an IA_TA 3368 have expired, the IA can be considered as having expired. 3370 An IA_TA option does not include values for T1 and T2. A client 3371 MAY request that the lifetimes on temporary addresses be extended 3372 by including the addresses in a IA_TA option sent in a Renew or 3373 Rebind message to a server. For example, a client would request 3374 an extension on the lifetime of a temporary address to allow an 3375 application to continue to use an established TCP connection. 3377 The client obtains new temporary addresses by sending an IA_TA option 3378 with a new IAID to a server. Requesting new temporary addresses from 3379 the server is the equivalent of generating new temporary addresses 3380 as described in RFC 3041. The server will generate new temporary 3381 addresses and return them to the client. The client should request 3382 new temporary addresses before the lifetimes on the previously 3383 assigned addresses expire. 3385 A server MUST return the same set of temporary address for the same 3386 IA_TA (as identified by the IAID) as long as those addresses are 3387 still valid. After the lifetimes of the addresses in an IA_TA have 3388 expired, the IAID may be reused to identify a new IA_TA with new 3389 temporary addresses. 3391 This option MAY appear in a Confirm message if the lifetimes on the 3392 temporary addresses in the associated IA have not expired. 3394 22.6. IA Address Option 3396 The IA Address option is used to specify IPv6 addresses associated 3397 with an IA. The IA Address option must be encapsulated in the 3398 Options field of an Identity Association option. The Options field 3399 encapsulates those options that are specific to this address. 3401 The format of the IA Address option is: 3403 0 1 2 3 3404 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 3405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3406 | OPTION_IAADDR | option-len | 3407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3408 | | 3409 | IPv6 address | 3410 | | 3411 | | 3412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3413 | preferred-lifetime | 3414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3415 | valid-lifetime | 3416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3417 . . 3418 . IAaddr-options . 3419 . . 3420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3422 option-code OPTION_IAADDR (5) 3424 option-len 24 + length of IAaddr-options field 3426 IPv6 address An IPv6 address 3428 preferred-lifetime The preferred lifetime for the IPv6 address in 3429 the option, expressed in units of seconds 3431 valid-lifetime The valid lifetime for the IPv6 address in the 3432 option, expressed in units of seconds 3434 IAaddr-options Options associated with this address 3436 In a message sent by a client to a server, values in the preferred 3437 and valid lifetime fields indicate the client's preference for those 3438 parameters. The client may send 0 if it has no preference for the 3439 preferred and valid lifetimes. In a message sent by a server to a 3440 client, the client MUST use the values in the preferred and valid 3441 lifetime fields for the preferred and valid lifetimes. The values in 3442 the preferred and valid lifetimes are the number of seconds remaining 3443 in each lifetime. 3445 An IA Address option may appear only in an IA option or an IA_TA 3446 option. More than one IA Address Options can appear in an IA option 3447 or an IA_TA option. 3449 The status of any operations involving this IA Address is indicated 3450 in a Status Code option in the IAaddr-options field. 3452 22.7. Option Request Option 3454 The Option Request option is used to identify a list of options in 3455 a message between a client and a server. The format of the Option 3456 Request option is: 3458 0 1 2 3 3459 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 3460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3461 | OPTION_ORO | option-len | 3462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3463 | requested-option-code-1 | requested-option-code-2 | 3464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3465 | ... | 3466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3468 option-code OPTION_ORO (6) 3470 option-len 2 * number of requested options 3472 requested-option-code-n The option code for an option requested by 3473 the client. 3475 A client MAY include an Option Request option in a Solicit, Request, 3476 Renew, Rebind, Confirm or Information-request message to inform 3477 the server about options the client wants the server to send to 3478 the client. A server MAY include an Option Request option in a 3479 Reconfigure option to indicate which options the client should 3480 request from the server. 3482 22.8. Preference Option 3484 The Preference option is sent by a server to a client to affect the 3485 selection of a server by the client. 3487 The format of the Preference option is: 3489 0 1 2 3 3490 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 3491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3492 | OPTION_PREFERENCE | option-len | 3493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3494 | pref-value | 3495 +-+-+-+-+-+-+-+-+ 3497 option-code OPTION_PREFERENCE (7) 3499 option-len 1 3501 pref-value The preference value for the server in this message. 3503 A server MAY include a Preference option in an Advertise message to 3504 control the selection of a server by the client. See section 17.1.3 3505 for the use of the Preference option by the client and the 3506 interpretation of Preference option data value. 3508 22.9. Elapsed Time Option 3510 0 1 2 3 3511 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 3512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3513 | OPTION_ELAPSED_TIME | option-len | 3514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3515 | elapsed-time | 3516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3518 option-code OPTION_ELAPSED_TIME (8) 3520 option-len 2. 3522 elapsed-time The amount of time since the client began its 3523 current DHCP transaction. This time is expressed in 3524 hundredths of a second (10^-2 seconds). 3526 A client MUST include an Elapsed Time option in messages to indicate 3527 how long the client has been trying to complete a DHCP message 3528 exchange. The elapsed time is measured from the time at which the 3529 client sent the first message in the message exchange, and the 3530 elapsed-time field is set to 0 in the first message in the message 3531 exchange. Servers and Relay Agents use the data value in this option 3532 as input to policy controlling how a server responds to a client 3533 message. For example, the elapsed time option allows a secondary 3534 DHCP server to respond to a request when a primary server hasn't 3535 answered in a reasonable time. 3537 22.10. Relay Message Option 3539 The Relay Message option carries a DHCP message in a Relay-forward or 3540 Relay-reply message. 3542 The format of the Relay Message option is: 3544 0 1 2 3 3545 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 3546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3547 | OPTION_RELAY_MSG | option-len | 3548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3549 | | 3550 . DHCP-relay-message . 3551 . . 3552 . . 3553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3555 option-code OPTION_RELAY_MSG (9) 3557 option-len Length of DHCP-relay-message 3559 DHCP-relay-message In a Relay-forward message, the received 3560 message, relayed verbatim to the next relay agent 3561 or server; in a Relay-reply message, the message to 3562 be copied and relayed to the relay agent or client 3563 whose address is in the peer-address field of the 3564 Relay-reply message 3566 22.11. Authentication Option 3568 The Authentication option carries authentication information to 3569 authenticate the identity and contents of DHCP messages. The use of 3570 the Authentication option is described in section 21. The format of 3571 the Authentication option is: 3573 0 1 2 3 3574 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 3575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3576 | OPTION_AUTH | option-len | 3577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3578 | protocol | algorithm | RDM | | 3579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3580 | | 3581 | replay detection (64 bits) +-+-+-+-+-+-+-+-+ 3582 | | auth-info | 3583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3584 . authentication information . 3585 . (variable length) . 3586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3587 option-code OPTION_AUTH (11) 3589 option-len 15 + length of authentication 3590 information field 3592 protocol The authentication protocol used in 3593 this authentication option 3595 algorithm The algorithm used in the 3596 authentication protocol 3598 RDM The replay detection method used in 3599 this authentication option 3601 Replay detection The replay detection information for 3602 the RDM 3604 authentication information The authentication information, 3605 as specified by the protocol and 3606 algorithm used in this authentication 3607 option 3609 22.12. Server Unicast Option 3611 The server sends this option to a client to indicate to the client 3612 that it is allowed to unicast messages to the server. The format of 3613 the Server Unicast option is: 3615 0 1 2 3 3616 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 3617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3618 | OPTION_UNICAST | option-len | 3619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3620 | | 3621 | server-address | 3622 | | 3623 | | 3624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3626 option-code OPTION_UNICAST (12) 3628 option-len 16 3630 server-address The IP address to which the client should send 3631 messages delivered using unicast 3633 The server specifies the IPv6 address to which the client is to send 3634 unicast messages in the server-address field. When a client receives 3635 this option, where permissible and appropriate, the client sends 3636 messages directly to the server using the IPv6 address specified in 3637 the server-address field of the option. 3639 Details about when the client may send messages to the server using 3640 unicast are in section 18. 3642 22.13. Status Code Option 3644 This option returns a status indication related to the DHCP message 3645 or option in which it appears. The format of the Status Code option 3646 is: 3648 0 1 2 3 3649 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 3650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3651 | OPTION_STATUS_CODE | option-len | 3652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3653 | status-code | | 3654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3655 . . 3656 . status-message . 3657 . . 3658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3660 option-code OPTION_STATUS_CODE (13) 3662 option-len 2 + length of status-message 3664 status-code The numeric code for the status encoded in 3665 this option. The status codes are defined in 3666 section 24.4. 3668 status-message A UTF-8 encoded text string suitable for 3669 display to an end user, which MUST NOT be 3670 null-terminated. 3672 A Status Code option may appear in the options field of a DHCP 3673 message and/or in the options field of another option. If the Status 3674 Code option does not appear in a message in which the option could 3675 appear, the status of the message is assumed to be Success. 3677 22.14. Rapid Commit Option 3679 The Rapid Commit option is used to signal the use of the two message 3680 exchange for address assignment. 3682 The format of the Rapid Commit option is: 3684 0 1 2 3 3685 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 3686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3687 | OPTION_RAPID_COMMIT | 0 | 3688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3690 option-code OPTION_RAPID_COMMIT (14) 3692 option-len 0 3694 A client MAY include this option in a Solicit message if the client 3695 is prepared to perform the Solicit-Reply message exchange described 3696 in section 17.1.1. 3698 A server MUST include this option in a Reply message sent in response 3699 to a Solicit message when completing the Solicit-Reply message 3700 exchange. 3702 DISCUSSION: 3704 Each server that responds with a Reply to a Solicit that 3705 includes a Rapid Commit option will commit the assigned 3706 addresses in the Reply message to the client, and will not 3707 receive any confirmation that the client has received the 3708 Reply message. Therefore, if more than one server responds 3709 to a Solicit that includes a Rapid Commit option, some 3710 servers will commit addresses that are not actually used by 3711 the client. 3713 The problem of unused addresses can be minimized, for 3714 example, by designing the DHCP service so that only one 3715 server responds to the Solicit or by using relatively short 3716 lifetimes for assigned addresses. 3718 22.15. User Class Option 3720 The User Class option is used by a client to identify the type or 3721 category of user or applications it represents. The format of the 3722 User Class option is: 3724 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 3725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3726 | OPTION_USER_CLASS | option-len | 3727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3728 . . 3729 . user-class-data . 3730 . . 3731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3732 option-code OPTION_USER_CLASS (15) 3734 option-len Length of user class data field 3736 user-class-data The user classes carried by the client. 3738 The information contained in the data area of this option is 3739 contained in one or more opaque fields that represent the user 3740 class or classes of which the client is a member. A server selects 3741 configuration information for the client based on the classes 3742 identified in this option. For example, the User Class option can be 3743 used to configure all clients of people in the accounting department 3744 with a different printer than clients of people in the marketing 3745 department. The user class information carried in this option MUST 3746 be configurable on the client. 3748 The data area of the user class option MUST contain one or more 3749 instances of user class data. Each instance of the user class data 3750 is formatted as follows: 3752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 3753 | user-class-len | opaque-data | 3754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 3756 The user-class-len is two octets long and specifies the length of the 3757 opaque user class data in network byte order. 3759 A server interprets the classes identified in this option according 3760 to its configuration to select the appropriate configuration 3761 information for the client. A server may use only those user 3762 classes that it is configured to interpret in selecting configuration 3763 information for a client and ignore any other user classes. In 3764 response to a message containing a User Class option, a server 3765 includes a User Class option containing those classes that were 3766 successfully interpreted by the server, so that the client can be 3767 informed of the classes interpreted by the server. 3769 22.16. Vendor Class Option 3771 This option is used by a client to identify the vendor that 3772 manufactured the hardware on which the client is running. The 3773 information contained in the data area of this option is contained 3774 in one or more opaque fields that identify details of the hardware 3775 configuration. 3777 The format of the Vendor Class option is: 3779 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 3780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3781 | OPTION_VENDOR_CLASS | option-len | 3782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3783 | enterprise-number | 3784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3785 . . 3786 . vendor-class-data . 3787 . . . . . 3788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3790 option-code OPTION_VENDOR_CLASS (16) 3792 option-len 4 + length of vendor class data field 3794 enterprise-number The vendor's registered Enterprise Number as 3795 registered with IANA [9]. 3797 vendor-class-data The hardware configuration of the host on 3798 which the client is running. 3800 The vendor-class-data is composed of a series of separate items, 3801 each of which describes some characteristic of the client's hardware 3802 configuration. Examples of vendor-class-data instances might include 3803 the version of the operating system the client is running or the 3804 amount of memory installed on the client. 3806 Each instance of the vendor-class-data is formatted as follows: 3808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 3809 | vendor-class-len | opaque-data | 3810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 3812 The vendor-class-len is two octets long and specifies the length of 3813 the opaque vendor class data in network byte order. 3815 22.17. Vendor-specific Information Option 3817 This option is used by clients and servers to exchange 3818 vendor-specific information. 3820 The format of the Vendor-specific Information option is: 3822 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 3823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3824 | OPTION_VENDOR_OPTS | option-len | 3825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3826 | enterprise-number | 3827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3828 . . 3829 . option-data . 3830 . . 3831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3833 option-code OPTION_VENDOR_OPTS (17) 3835 option-len 4 + length of option-data field 3837 enterprise-number The vendor's registered Enterprise Number as 3838 registered with IANA [9]. 3840 option-data An opaque object of option-len octets, 3841 interpreted by vendor-specific code on the 3842 clients and servers 3844 The definition of the information carried in this option is vendor 3845 specific. The vendor is indicated in the enterprise-number field. 3846 Use of vendor-specific information allows enhanced operation, 3847 utilizing additional features in a vendor's DHCP implementation. 3848 A DHCP client that does not receive requested vendor-specific 3849 information will still configure the host device's IPv6 stack to be 3850 functional. 3852 The encapsulated vendor-specific options field MUST be encoded as a 3853 sequence of code/length/value fields of identical format to the DHCP 3854 options field. The option codes are defined by the vendor identified 3855 in the enterprise-number field and are not managed by IANA. Each of 3856 the encapsulated options is formatted as follows: 3858 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 3859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3860 | opt-code | option-len | 3861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3862 . . 3863 . option-data . 3864 . . 3865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3867 opt-code The code for the encapsulated option 3868 option-len An unsigned integer giving the length of the 3869 option-data field in this encapsulated option 3870 in octets. 3872 option-data The data area for the encapsulated option 3874 Multiple instances of the Vendor-specific Information option may 3875 appear in a DHCP message. Each instance of the option is interpreted 3876 according to the option codes defined by the vendor identified by the 3877 Enterprise Number in that option. 3879 22.18. Interface-Id Option 3881 The relay agent MAY send the Interface-id option to identify the 3882 interface on which the client message was received. If a relay agent 3883 receives a Relay-reply message with an Interface-id option, the 3884 relay agent relays the message to the client through the interface 3885 identified by the option. 3887 The format of the Interface ID option is: 3889 0 1 2 3 3890 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 3891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3892 | OPTION_INTERFACE_ID | option-len | 3893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3894 . . 3895 . interface-id . 3896 . . 3897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3899 option-code OPTION_INTERFACE_ID (18) 3901 option-len Length of interface-id field 3903 interface-id An opaque value of arbitrary length generated 3904 by the relay agent to identify one of the 3905 relay agent's interfaces 3907 The server MUST copy the Interface-Id option from the Relay-Forward 3908 message into the Relay-Reply message the server sends to the relay 3909 agent in response to the Relay-Forward message. This option MUST NOT 3910 appear in any message except a Relay-Forward or Relay-Reply message. 3912 Servers MAY use the Interface-ID for parameter assignment policies. 3913 The Interface-ID SHOULD be considered an opaque value, with policies 3914 based on exact match only; that is, the Interface-ID SHOULD NOT be 3915 internally parsed by the server. The Interface-ID value for an 3916 interface SHOULD be stable and remain unchanged, for example, after 3917 the relay agent is restarted; if the Interface-ID changes, a server 3918 will not be able to use it reliably in parameter assignment policies. 3920 22.19. Reconfigure Message Option 3922 A server includes a Reconfigure Message option in a Reconfigure 3923 message to indicate to the client whether the client responds with a 3924 Renew message or an Information-request message. The format of this 3925 option is: 3927 0 1 2 3 3928 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 3929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3930 | OPTION_RECONF_MSG | option-len | 3931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3932 | msg-type | 3933 +-+-+-+-+-+-+-+-+ 3935 option-code OPTION_RECONF_MSG (19) 3937 option-len 1 3939 msg-type 5 for Renew message, 11 for 3940 Information-request message 3942 The Reconfigure Message option can only appear in a Reconfigure 3943 message. 3945 22.20. Reconfigure Accept Option 3947 A client uses the Reconfigure Accept option to announce to the server 3948 whether the client is willing to accept Reconfigure messages, and a 3949 server uses this option to tell the client whether or not to accept 3950 Reconfigure messages. The default behavior, in the absence of this 3951 option, means unwillingness to accept Reconfigure messages, or 3952 instruction not to accept Reconfigure messages, for the client and 3953 server messages, respectively. The following figure gives the format 3954 of the Reconfigure Accept option: 3956 0 1 2 3 3957 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 3958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3959 | OPTION_RECONF_ACCEPT | 0 | 3960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3962 option-code OPTION_RECONF_ACCEPT (20) 3963 option-len 0 3965 23. Security Considerations 3967 The threat to DHCP is inherently an insider threat (assuming a 3968 properly configured network where DHCPv6 ports are blocked on the 3969 perimeter gateways of the enterprise). Regardless of the gateway 3970 configuration, however, the potential attacks by insiders and 3971 outsiders are the same. 3973 One attack specific to a DHCP client is the establishment of a 3974 malicious server with the intent of providing incorrect configuration 3975 information to the client. The motivation for doing so may be 3976 to mount a "man in the middle" attack that causes the client to 3977 communicate with a malicious server instead of a valid server for 3978 some service such as DNS or NTP. The malicious server may also mount 3979 a denial of service attack through misconfiguration of the client 3980 that causes all network communication from the client to fail. 3982 There is another threat to DHCP clients from mistakenly or 3983 accidentally configured DHCP servers that answer DHCP client requests 3984 with unintentionally incorrect configuration parameters. 3986 A DHCP client may also be subject to attack through the receipt 3987 of a Reconfigure message from a malicious server that causes the 3988 client to obtain incorrect configuration information from that 3989 server. Note that although a client sends its response (Renew or 3990 Information-request message) through a relay agent and, therefore, 3991 that response will only be received by servers to which DHCP messages 3992 are relayed, a malicious server could send a Reconfigure message to 3993 a client, followed (after an appropriate delay) by a Reply message 3994 that would be accepted by the client. Thus, a malicious server that 3995 is not on the network path between the client and the server may 3996 still be able to mount a Reconfigure attack on a client. The use of 3997 transaction IDs that are cryptographically sound and cannot easily be 3998 predicted will also reduce the probability that such an attack will 3999 be successful. 4001 The threat specific to a DHCP server is an invalid client 4002 masquerading as a valid client. The motivation for this may be 4003 for theft of service, or to circumvent auditing for any number of 4004 nefarious purposes. 4006 The threat common to both the client and the server is the resource 4007 "denial of service" (DoS) attack. These attacks typically involve 4008 the exhaustion of available addresses, or the exhaustion of CPU 4009 or network bandwidth, and are present anytime there is a shared 4010 resource. 4012 In the case where relay agents add additional options to Relay 4013 Forward messages, the messages exchanged between relay agents and 4014 servers may be used to mount a "man in the middle" or denial of 4015 service attack. 4017 This threat model does not consider the privacy of the contents 4018 of DHCP messages to be important. DHCP is not used to exchange 4019 authentication or configuration information that must be kept secret 4020 from other networks nodes. 4022 DHCP authentication provides for authentication of the identity of 4023 DHCP clients and servers, and for the integrity of messages delivered 4024 between DHCP clients and servers. DHCP authentication does not 4025 provide any privacy for the contents of DHCP messages. 4027 The Delayed Authentication protocol described in section 21.4 uses 4028 a secret key that is shared between a client and a server. The 4029 use of a "DHCP realm" in the shared key allows identification of 4030 administrative domains so that a client can select the appropriate 4031 key or keys when roaming between administrative domains. However, 4032 the Delayed Authentication protocol does not define any mechanism 4033 for sharing of keys, so a client may require separate keys for each 4034 administrative domain it encounters. The use of shared keys may not 4035 scale well and does not provide for repudiation of compromised keys. 4036 This protocol is focused on solving the intradomain problem where the 4037 out-of-band exchange of a shared key is feasible. 4039 The Reconfigure Key protocol described in section 21.5 provides 4040 protection against use of a Reconfigure message by a malicious DHCP 4041 server to mount a denial of service or man-in-the-middle attack on a 4042 client. 4044 Communication between a server and a relay agent and communication 4045 between relay agents can be secured through the use of IPSec, as 4046 described in section 21.1. The use of manual configuration and 4047 installation of static keys are acceptable in this instance because 4048 relay agents and the server will belong to the same administrative 4049 domain and the relay agents will require other specific configuration 4050 (for example, configuration of the DHCP server address) as well as 4051 the IPSec configuration. 4053 24. IANA Considerations 4055 This document defines several new name spaces associated with DHCPv6 4056 and DHCPv6 options: 4058 - Message types 4060 - Status codes 4062 - DUID 4064 - Option codes 4066 IANA is requested to manage a registry of values for each of these 4067 name spaces, which are described in the remainder of this section. 4068 These name spaces are all to be managed separately from the name 4069 spaces defined for DHCPv4. 4071 New multicast addresses, message types, status codes and DUID types 4072 are assigned via Standards Action [14]. 4074 New DHCP option codes are tentatively assigned after the 4075 specification for the associated option, published as an Internet 4076 Draft, has received expert review by a designated expert [14]. The 4077 final assignment of DHCP option codes is through Standards Action, as 4078 defined in RFC2434 [14]. 4080 This document also references three name spaces in section 21 that 4081 are associated with the Authentication Option (section 22.11). These 4082 name spaces are defined by the authentication mechanism for DHCPv4 in 4083 RFC3118 [6]. 4085 The authentication name spaces currently registered by IANA will 4086 apply to both DHCPv6 and DHCPv4. In the future, specifications that 4087 define new Protocol, Algorithm and RDM mechanisms will explicitly 4088 define whether the new mechanisms are used with DHCPv4, DHCPv6 or 4089 both. 4091 24.1. Multicast Addresses 4093 Section 5.1 defines the following multicast addresses, which have 4094 been assigned by IANA for use by DHCPv6: 4096 All_DHCP_Relay_Agents_and_Servers address: FF02::1:2 4098 All_DHCP_Servers address: FF05::1:3 4100 24.2. DHCP Message Types 4102 IANA is requested to record the following message types (defined 4103 in section 5.3). IANA is requested to maintain a registry of DHCP 4104 message types. 4106 SOLICIT 1 4108 ADVERTISE 2 4110 REQUEST 3 4112 CONFIRM 4 4114 RENEW 5 4116 REBIND 6 4117 REPLY 7 4119 RELEASE 8 4121 DECLINE 9 4123 RECONFIGURE 10 4125 INFORMATION-REQUEST 11 4127 RELAY-FORW 12 4129 RELAY-REPL 13 4131 24.3. DHCP Options 4133 IANA is requested to record the following option-codes (as defined in 4134 section 22). IANA is requested to maintain a registry of DHCP option 4135 codes. 4137 OPTION_CLIENTID 1 4139 OPTION_SERVERID 2 4141 OPTION_IA_NA 3 4143 OPTION_IA_TA 4 4145 OPTION_IAADDR 5 4147 OPTION_ORO 6 4149 OPTION_PREFERENCE 7 4151 OPTION_ELAPSED_TIME 8 4153 OPTION_RELAY_MSG 9 4155 OPTION_AUTH 11 4157 OPTION_UNICAST 12 4159 OPTION_STATUS_CODE 13 4161 OPTION_RAPID_COMMIT 14 4163 OPTION_USER_CLASS 15 4165 OPTION_VENDOR_CLASS 16 4167 OPTION_VENDOR_OPTS 17 4168 OPTION_INTERFACE_ID 18 4170 OPTION_RECONF_MSG 19 4172 OPTION_RECONF_ACCEPT 20 4174 24.4. Status Codes 4176 IANA is requested to record the status codes defined in the following 4177 table. IANA is requested to manage the definition of additional 4178 status codes in the future. 4180 Name Code Description 4181 ---------- ---- ----------- 4182 Success 0 Success 4183 UnspecFail 1 Failure, reason unspecified; this 4184 status code is sent by either a client 4185 or a server to indicate a failure 4186 not explicitly specified in this 4187 document 4188 NoAddrsAvail 2 Server has no addresses available to assign to 4189 the IA(s) 4190 NoBinding 3 Client record (binding) unavailable 4191 NotOnLink 4 The prefix for the address is not appropriate to 4192 the link to which the client is attached 4193 UseMulticast 5 Sent by a server to a client to force the 4194 client to send messages to the server 4195 using the All_DHCP_Relay_Agents_and_Servers 4196 address 4198 24.5. DUID 4200 IANA is requested to record the following DUID types (as defined in 4201 section 9.1). IANA is requested to manage definition of additional 4202 DUID types in the future. 4204 DUID-LLT 1 4206 DUID-EN 2 4208 DUID-LL 3 4210 25. Acknowledgments 4212 Thanks to the DHC Working Group and the members of the IETF for 4213 their time and input into the specification. In particular, thanks 4214 also for the consistent input, ideas, and review by (in alphabetical 4215 order) Bernard Aboba, Bill Arbaugh, Thirumalesh Bhat, Steve Bellovin, 4216 A. K. Vijayabhaskar, Brian Carpenter, Matt Crawford, Francis Dupont, 4217 Kim Kinnear, Fredrik Lindholm, Tony Lindstrom, Josh Littlefield, 4218 Gerald Maguire, Jack McCann, Shin Miyakawa, Thomas Narten, Erik 4219 Nordmark, Jarno Rajahalme, Yakov Rekhter, Mark Stapp, Matt Thomas, 4220 Sue Thomson, Tatuya Jinmei and Phil Wells. 4222 Thanks to Steve Deering and Bob Hinden, who have consistently 4223 taken the time to discuss the more complex parts of the IPv6 4224 specifications. 4226 And, thanks to Steve Deering for pointing out at IETF 51 in London 4227 that the DHCPv6 specification has the highest revision number of any 4228 Internet Draft. 4230 26. Changes in draft-ietf-dhc-dhcpv6-27.txt 4232 - Wordsmithed 2nd paragraph in section to delete "immediately" from 4233 "a client can immediately use its link-local address" 4235 - Server sets hop limit when using multicast from IANA number 4237 - Server must transmit to client on a specific interface 4239 - Change "forwarding" to "relaying" throughout 4241 - Add desynchronizing randomization for Confirm and 4242 Information-request messages 4244 - Wordsmithed section 15 to clarify actions when message breaks 4245 rules about option inclusion 4247 - Added text to 15.12 to include test for IA option in validation 4248 of Information-Request 4250 - Added requirement for Client Identifier option if 4251 Information-request message is to be authenticated 4253 - Deleted restriction against more than one Vendor-specific 4254 Information option with same enterprise number 4256 - Replaced "forward" with "relay" to describe service provided by 4257 relay agents 4259 - Added text in section 15 requiring that a server discards 4260 messages received via unicast such as Solicit that must be sent 4261 via multicast 4263 - Eliminated use of "message code" in section 5 4265 - Eliminated "AddrUnavail" and "ConfNoMatch" status codes because 4266 they are no longer used 4268 - Edited to use "IA" for a non-differentiated IA; "IA_NA" and 4269 "IA_TA" for specific types of addresses. 4271 - Deleted AuthFailed status code; spec requires that receiver 4272 discard messages that fail authentication with no response to the 4273 sender 4275 - Renamed IA to IA_NA throughout; now IA refers collectively to 4276 IA_NA and IA_TA 4278 - DUID now limited to 128 bytes (was 256) 4280 - Reconfigure message includes IA option to specifically identify 4281 IAs that are to be modified. 4283 - Reconfigure Accept option allows client to tell server if it 4284 will do Reconfigure and allows server to control whether client 4285 accepts Reconfigure 4287 - Use of Reconfigure Key message is a new protocol in DHCP 4288 authentication 4290 References 4292 [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 4293 Extensions, March 1997. RFC 2132. 4295 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 4296 Levels, March 1997. RFC 2119. 4298 [3] M. Crawford. Transmission of IPv6 Packets over Ethernet 4299 Networks, December 1998. RFC 2464. 4301 [4] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 4302 Specification, December 1998. RFC 2460. 4304 [5] R. Droms. Dynamic Host Configuration Protocol, March 1997. RFC 4305 2131. 4307 [6] R. Droms, Editor, W. Arbaugh, and Editor. Authentication for 4308 DHCP Messages, June 2001. RFC 3118. 4310 [7] R. (ed.) Droms. DNS Configuration options for DHCPv6. Internet 4311 Draft, Internet Engineering Task Force, April 2002. Work in 4312 progress. 4314 [8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture, 4315 July 1998. RFC 2373. 4317 [9] IANA. Private Enterprise Numbers. 4318 http://www.iana.org/assignments/enterprise-numbers.html. 4320 [10] S. Kent and R. Atkinson. Security Architecture for the Internet 4321 Protocol, November 1998. RFC 2401. 4323 [11] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 4324 for Message Authentication, February 1997. RFC 2104. 4326 [12] David L. Mills. Network Time Protocol (Version 3) 4327 Specification, Implementation, March 1992. RFC 1305. 4329 [13] P.V. Mockapetris. Domain names - implementation and 4330 specification, November 1987. RFC 1035. 4332 [14] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 4333 Considerations Section in RFCs, October 1998. RFC 2434. 4335 [15] T. Narten and R. Draves. Privacy Extensions for Stateless 4336 Address Autoconfiguration in IPv6, January 2001. RFC 3041. 4338 [16] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 4339 IP Version 6 (IPv6), December 1998. RFC 2461. 4341 [17] D.C. Plummer. Ethernet Address Resolution Protocol: Or 4342 converting network protocol addresses to 48.bit Ethernet address 4343 for transmission on Ethernet hardware, November 1982. RFC 826. 4345 [18] J. Postel. User Datagram Protocol, August 1980. RFC 768. 4347 [19] R. Rivest. The MD5 Message-Digest Algorithm, April 1992. RFC 4348 1321. 4350 [20] S. Thomson and T. Narten. IPv6 Stateless Address 4351 Autoconfiguration, December 1998. RFC 2462. 4353 [21] A. K. Vijayabhaskar. Time Configuration Options for DHCPv6. 4354 Internet Draft, Internet Engineering Task Force, May 2002. Work 4355 in progress. 4357 [22] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic 4358 Updates in the Domain Name System (DNS UPDATE), April 1997. RFC 4359 2136. 4361 Chair's Address 4363 The working group can be contacted via the current chair: 4365 Ralph Droms 4366 Cisco Systems 4367 300 Apollo Drive 4368 Chelmsford, MA 01824 4370 Phone: (978) 244-4733 4371 E-mail: rdroms@cisco.com 4373 Authors' Addresses 4375 Questions about this document can be directed to: 4377 Jim Bound 4378 Hewlett Packard Corporation 4379 ZK3-3/W20 4380 110 Spit Brook Road 4381 Nashua, NH 03062-2698 4382 USA 4383 Voice: +1 603 884 0062 4384 E-mail: Jim.Bound@hp.com 4386 Bernie Volz 4387 Ericsson 4388 959 Concord St 4389 Framingham, MA 01701 4390 USA 4391 Voice: +1-508-875-3162 4392 E-mail: bernie.volz@ericsson.com 4394 Ted Lemon 4395 Nominum, Inc. 4396 950 Charter Street 4397 Redwood City, CA 94043 4398 USA 4399 E-mail: Ted.Lemon@nominum.com 4401 Charles E. Perkins 4402 Communications Systems Lab 4403 Nokia Research Center 4404 313 Fairchild Drive 4405 Mountain View, California 94043 4406 USA 4407 Voice: +1-650 625-2986 4408 E-mail: charliep@iprg.nokia.com 4410 Mike Carney 4411 Sun Microsystems, Inc 4412 Mail Stop: UMPK17-202 4413 901 San Antonio Road 4414 Palo Alto, CA 94303-4900 4415 USA 4416 Voice: +1-650-786-4171 4417 E-mail: mwc@eng.sun.com 4419 A. Appearance of Options in Message Types 4421 The following table indicates with a "*" the options are allowed in 4422 each DHCP message type: 4424 Client Server IA_NA Option Pref Time Relay Auth. Server 4425 ID ID IA_TA Request Msg. Unica. 4426 Solicit * * * * * 4427 Advert. * * * * * * 4428 Request * * * * * * 4429 Confirm * * * * * 4430 Renew * * * * * * 4431 Rebind * * * * * 4432 Decline * * * * * * 4433 Release * * * * * * 4434 Reply * * * * * * * 4435 Reconf. * * * * 4436 Inform. * (see note) * * * 4437 R-forw. * * 4438 R-repl. * * 4440 NOTE: 4442 Only included in Information-Request messages that are sent 4443 in response to a Reconfigure (see section 19.4.3). 4445 Status Rap. User Vendor Vendor Inter. Recon. Recon. 4446 Code Comm. Class Class Spec. ID Msg. Accept 4447 Solicit * * * * * 4448 Advert. * * * * * 4449 Request * * * * 4450 Confirm * * * 4451 Renew * * * * 4452 Rebind * * * * 4453 Decline * * * 4454 Release * * * 4455 Reply * * * * * * 4456 Reconf. * 4457 Inform. * * * * 4458 R-forw. * * * * 4459 R-repl. * * * * 4461 B. Appearance of Options in the Options Field of DHCP Options 4463 The following table indicates with a "*" where options can appear in 4464 the options field of other options: 4466 Option IA_NA/ IAADDR Relay Relay 4467 Field IA_TA Forw. Reply 4468 Client ID * 4469 Server ID * 4470 IA_NA/IA_TA * 4471 IAADDR * 4472 ORO * 4473 Preference * 4474 Elapsed Time * 4475 Relay Message * * 4476 Authentic. * 4477 Server Uni. * 4478 Status Code * * * 4479 Rapid Comm. * 4480 User Class * 4481 Vendor Class * 4482 Vendor Info. * 4483 Interf. ID * * 4484 Reconf. MSG. * 4485 Reconf. Accept * 4487 Note: "Relay Forw" / "Relay Reply" options appear in the options 4488 field of the message but may only appear in these messages. 4490 C. Full Copyright Statement 4492 Copyright (C) The Internet Society (2002). All Rights Reserved. 4494 This document and translations of it may be copied and furnished to 4495 others, and derivative works that comment on or otherwise explain it 4496 or assist in its implementation may be prepared, copied, published 4497 and distributed, in whole or in part, without restriction of any 4498 kind, provided that the above copyright notice and this paragraph 4499 are included on all such copies and derivative works. However, 4500 this document itself may not be modified in any way, such as by 4501 removing the copyright notice or references to the Internet Society 4502 or other Internet organizations, except as needed for the purpose 4503 of developing Internet standards in which case the procedures 4504 for copyrights defined in the Internet Standards process must be 4505 followed, or as required to translate it into languages other than 4506 English. 4508 The limited permissions granted above are perpetual and will not be 4509 revoked by the Internet Society or its successors or assigns. 4511 This document and the information contained herein is provided on an 4512 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4513 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4514 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4515 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4516 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.