idnits 2.17.1 draft-ietf-dhc-dhcpv6-24.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 85 longer pages, the longest (page 2) being 63 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. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes draft-ietf-dhc-dhcpv6-23.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 == 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-23.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 Apr 2002) is 8039 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) ** Obsolete normative reference: RFC 2460 (ref. '3') (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2373 (ref. '7') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2401 (ref. '8') (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '9') ** Obsolete normative reference: RFC 1305 (ref. '10') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2434 (ref. '13') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3041 (ref. '14') (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 2461 (ref. '15') (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '18') ** Obsolete normative reference: RFC 2462 (ref. '19') (Obsoleted by RFC 4862) Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force J. Bound 2 INTERNET DRAFT Compaq 3 DHC Working Group M. Carney 4 Obsoletes: draft-ietf-dhc-dhcpv6-23.txt Sun Microsystems, Inc 5 C. Perkins 6 Nokia Research Center 7 Ted Lemon 8 Nominum 9 Bernie Volz 10 Ericsson 11 R. Droms(ed.) 12 Cisco Systems 13 22 Apr 2002 15 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 16 draft-ietf-dhc-dhcpv6-24.txt 18 Status of This Memo 20 This document is a submission by the Dynamic Host Configuration 21 Working Group of the Internet Engineering Task Force (IETF). Comments 22 should be submitted to the dhcwg@ietf.org mailing list. 24 Distribution of this memo is unlimited. 26 This document is an Internet-Draft and is in full conformance with 27 all provisions of Section 10 of RFC2026. Internet-Drafts are working 28 documents of the Internet Engineering Task Force (IETF), its areas, 29 and its working groups. Note that other groups may also distribute 30 working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at 34 any time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at: 38 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at: 40 http://www.ietf.org/shadow.html. 42 Abstract 44 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables 45 DHCP servers to pass configuration parameters such as IPv6 network 46 addresses to IPv6 nodes. It offers the capability of automatic 47 allocation of reusable network addresses and additional configuration 48 flexibility. This protocol is a stateful counterpart to "IPv6 49 Stateless Address Autoconfiguration" (RFC2462), and can be used 50 separately or concurrently with the latter to obtain configuration 51 parameters. 53 Contents 55 Status of This Memo i 57 Abstract i 59 1. Introduction and Overview 1 60 1.1. Protocols and addressing . . . . . . . . . . . . . . . . 2 61 1.2. Protocol implementation . . . . . . . . . . . . . . . . . 2 62 1.3. Client-server exchanges involving two messages . . . . . 3 63 1.4. Client-server exchanges involving four messages . . . . . 3 65 2. Requirements 4 67 3. Background 4 69 4. Terminology 5 70 4.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 5 71 4.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 6 73 5. DHCP Constants 8 74 5.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 8 75 5.2. Anycast address . . . . . . . . . . . . . . . . . . . . . 8 76 5.3. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 8 77 5.4. DHCP message types . . . . . . . . . . . . . . . . . . . 9 78 5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 10 79 5.6. Configuration Parameters . . . . . . . . . . . . . . . . 11 81 6. Message Formats 11 83 7. Relay agent messages 12 84 7.1. Relay-forward message . . . . . . . . . . . . . . . . . . 13 85 7.2. Relay-reply message . . . . . . . . . . . . . . . . . . . 14 87 8. Representation and use of domain names 14 89 9. DHCP unique identifier (DUID) 14 90 9.1. DUID contents . . . . . . . . . . . . . . . . . . . . . . 15 91 9.2. DUID based on link-layer address plus time . . . . . . . 15 92 9.3. Vendor-assigned unique ID based on Domain Name (VUID-DN) 16 93 9.4. Vendor-assigned unique ID based on Enterprise Number 94 (VUID-EN) . . . . . . . . . . . . . . . . . . . . . . 17 95 9.5. Link-layer address . . . . . . . . . . . . . . . . . . . 18 97 10. Identity association 19 99 11. Selecting addresses for assignment to an IA 20 101 12. Management of temporary addresses 21 102 13. Transmission of messages by a client 21 104 14. Reliability of Client Initiated Message Exchanges 21 106 15. Message validation 23 107 15.1. Use of Transaction-ID field . . . . . . . . . . . . . . . 23 108 15.2. Solicit message . . . . . . . . . . . . . . . . . . . . . 23 109 15.3. Advertise message . . . . . . . . . . . . . . . . . . . . 24 110 15.4. Request message . . . . . . . . . . . . . . . . . . . . . 24 111 15.5. Confirm message . . . . . . . . . . . . . . . . . . . . . 24 112 15.6. Renew message . . . . . . . . . . . . . . . . . . . . . . 24 113 15.7. Rebind message . . . . . . . . . . . . . . . . . . . . . 25 114 15.8. Decline messages . . . . . . . . . . . . . . . . . . . . 25 115 15.9. Release message . . . . . . . . . . . . . . . . . . . . . 25 116 15.10. Reply message . . . . . . . . . . . . . . . . . . . . . . 25 117 15.11. Reconfigure message . . . . . . . . . . . . . . . . . . . 26 118 15.12. Information-request message . . . . . . . . . . . . . . . 26 119 15.13. Relay-forward message . . . . . . . . . . . . . . . . . . 26 120 15.14. Relay-reply message . . . . . . . . . . . . . . . . . . . 26 122 16. Client Source Address and Interface Selection 26 124 17. DHCP Server Solicitation 27 125 17.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 27 126 17.1.1. Creation of Solicit messages . . . . . . . . . . 27 127 17.1.2. Transmission of Solicit Messages . . . . . . . . 28 128 17.1.3. Receipt of Advertise messages . . . . . . . . . . 29 129 17.1.4. Receipt of Reply message . . . . . . . . . . . . 30 130 17.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 30 131 17.2.1. Receipt of Solicit messages . . . . . . . . . . . 30 132 17.2.2. Creation and transmission of Advertise messages . 30 133 17.2.3. Creation and Transmission of Reply messages . . . 31 135 18. DHCP Client-Initiated Configuration Exchange 32 136 18.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 32 137 18.1.1. Creation and transmission of Request messages . . 32 138 18.1.2. Creation and transmission of Confirm messages . . 34 139 18.1.3. Creation and transmission of Renew messages . . . 35 140 18.1.4. Creation and transmission of Rebind messages . . 36 141 18.1.5. Creation and Transmission of Information-request 142 messages . . . . . . . . . . . . . . . . . 37 143 18.1.6. Receipt of Reply message in response to a Request, 144 Confirm, Renew, Rebind or Information-request 145 message . . . . . . . . . . . . . . . . . 38 146 18.1.7. Creation and transmission of Release messages . . 39 147 18.1.8. Receipt of Reply message in response to a Release 148 message . . . . . . . . . . . . . . . . . 40 149 18.1.9. Creation and transmission of Decline messages . . 40 150 18.1.10. Receipt of Reply message in response to a Decline 151 message . . . . . . . . . . . . . . . . . 41 152 18.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 41 153 18.2.1. Receipt of Request messages . . . . . . . . . . . 41 154 18.2.2. Receipt of Confirm messages . . . . . . . . . . . 42 155 18.2.3. Receipt of Renew messages . . . . . . . . . . . . 43 156 18.2.4. Receipt of Rebind messages . . . . . . . . . . . 44 157 18.2.5. Receipt of Information-request messages . . . . . 44 158 18.2.6. Receipt of Release messages . . . . . . . . . . . 45 159 18.2.7. Receipt of Decline messages . . . . . . . . . . . 45 160 18.2.8. Transmission of Reply messages . . . . . . . . . 46 162 19. DHCP Server-Initiated Configuration Exchange 46 163 19.1. Server Behavior . . . . . . . . . . . . . . . . . . . . . 46 164 19.1.1. Creation and transmission of Reconfigure messages 46 165 19.1.2. Time out and retransmission of Reconfigure 166 messages . . . . . . . . . . . . . . . . . 47 167 19.1.3. Receipt of Renew messages . . . . . . . . . . . . 47 168 19.2. Receipt of Information-request messages . . . . . . . . . 48 169 19.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 48 170 19.3.1. Receipt of Reconfigure messages . . . . . . . . . 48 171 19.3.2. Creation and transmission of Renew messages . . . 49 172 19.3.3. Creation and transmission of Information-request 173 messages . . . . . . . . . . . . . . . . . 49 174 19.3.4. Time out and retransmission of Renew or 175 Information-request messages . . . . . . . 49 176 19.3.5. Receipt of Reply messages . . . . . . . . . . . . 49 178 20. Relay Agent Behavior 50 179 20.1. Relaying of client messages . . . . . . . . . . . . . . . 50 180 20.2. Relaying of server messages . . . . . . . . . . . . . . . 50 182 21. Authentication of DHCP messages 51 183 21.1. DHCP threat model . . . . . . . . . . . . . . . . . . . . 51 184 21.2. Security of messages sent between servers and relay agents 52 185 21.3. Summary of DHCP authentication . . . . . . . . . . . . . 52 186 21.4. Replay detection . . . . . . . . . . . . . . . . . . . . 52 187 21.5. Delayed authentication protocol . . . . . . . . . . . . . 53 188 21.5.1. Management issues in the delayed authentication 189 protocol . . . . . . . . . . . . . . . . . 53 190 21.5.2. Use of the Authentication option in the delayed 191 authentication protocol . . . . . . . . . 53 192 21.5.3. Message validation . . . . . . . . . . . . . . . 54 193 21.5.4. Key utilization . . . . . . . . . . . . . . . . . 54 194 21.5.5. Client considerations for delayed authentication 195 protocol . . . . . . . . . . . . . . . . . 55 196 21.5.6. Server considerations for delayed authentication 197 protocol . . . . . . . . . . . . . . . . . 57 199 22. DHCP options 57 200 22.1. Format of DHCP options . . . . . . . . . . . . . . . . . 58 201 22.2. Client Identifier option . . . . . . . . . . . . . . . . 58 202 22.3. Server Identifier option . . . . . . . . . . . . . . . . 59 203 22.4. Identity Association option . . . . . . . . . . . . . . . 59 204 22.5. Identity Association for Temporary Addresses option . . . 61 205 22.6. IA Address option . . . . . . . . . . . . . . . . . . . . 63 206 22.7. Option Request option . . . . . . . . . . . . . . . . . . 64 207 22.8. Preference option . . . . . . . . . . . . . . . . . . . . 64 208 22.9. Elapsed Time . . . . . . . . . . . . . . . . . . . . . . 65 209 22.10. Client message option . . . . . . . . . . . . . . . . . . 66 210 22.11. Server message option . . . . . . . . . . . . . . . . . . 66 211 22.12. Authentication option . . . . . . . . . . . . . . . . . . 67 212 22.13. Server unicast option . . . . . . . . . . . . . . . . . . 68 213 22.14. Status Code Option . . . . . . . . . . . . . . . . . . . 68 214 22.15. Rapid Commit option . . . . . . . . . . . . . . . . . . . 69 215 22.16. User Class Option . . . . . . . . . . . . . . . . . . . . 69 216 22.17. Vendor Class Option . . . . . . . . . . . . . . . . . . . 70 217 22.18. Vendor-specific Information option . . . . . . . . . . . 71 218 22.19. Interface-Id Option . . . . . . . . . . . . . . . . . . . 72 219 22.20. Reconfigure Message option . . . . . . . . . . . . . . . 73 221 23. Security Considerations 73 223 24. Year 2000 considerations 73 225 25. IANA Considerations 73 226 25.1. Multicast addresses . . . . . . . . . . . . . . . . . . . 74 227 25.2. Anycast addresses . . . . . . . . . . . . . . . . . . . . 74 228 25.3. DHCPv6 message types . . . . . . . . . . . . . . . . . . 74 229 25.4. DUID . . . . . . . . . . . . . . . . . . . . . . . . . . 75 230 25.5. DHCPv6 options . . . . . . . . . . . . . . . . . . . . . 75 231 25.6. Status codes . . . . . . . . . . . . . . . . . . . . . . 76 232 25.7. Authentication option . . . . . . . . . . . . . . . . . . 76 234 26. Acknowledgments 77 236 References 77 238 Chair's Address 79 240 Authors' Addresses 79 242 A. Appearance of Options in Message Types 81 244 B. Appearance of Options in the Options Field of DHCP Options 81 246 C. Full Copyright Statement 82 248 1. Introduction and Overview 250 This document describes DHCP for IPv6 (DHCP), a client/server 251 protocol that provides managed configuration of devices. 253 DHCP can provide a device with addresses assigned by a DHCP server 254 and other configuration information. The addresses and additional 255 configuration are carried in options. DHCP can be extended through 256 the definition of new options to carry configuration information not 257 specified in this document. 259 DHCP is the "stateful address autoconfiguration protocol" and the 260 "stateful autoconfiguration protocol" referred to in RFC2462, "IPv6 261 Stateless Address Autoconfiguration". 263 The remainder of this introduction summarizes DHCP, explaining 264 the message exchange mechanisms and example message flows. The 265 message flows in sections 1.3 and 1.4 are intended as illustrations 266 of DHCP operation rather than an exhaustive list of all possible 267 client-server interactions. Sections 17, 18 and 19 explain client 268 and server operation in detail. 270 1.1. Protocols and addressing 272 Clients and servers exchange DHCP messages using UDP [17]. The 273 client uses its link-local address determined through stateless 274 autoconfiguration for transmitting and receiving DHCP messages. 276 DHCP servers receive messages from clients using a reserved, 277 link-scoped multicast address. A DHCP client transmits most messages 278 to this reserved multicast address, so that the client need not be 279 configured with the address or addresses of DHCP servers. 281 To allow a DHCP client to send a message to a DHCP server that is not 282 attached to the same link, a DHCP relay agent on the client's link 283 will forward messages between the client and server. The operation 284 of the relay agent is transparent to the client and the discussion 285 of message exchanges in the remainder of this section will omit the 286 description of message forwarding by relay agents. 288 Once the client has determined the address of a server, it may 289 under some circumstances send messages directly to the server using 290 unicast. 292 1.2. Protocol implementation 294 This specification for DHCP includes messages and descriptions of 295 client and server behavior for several different functions. Some 296 clients and servers will be deployed in situations in which not all 297 of the functions will be required. For example, a client that uses 298 stateless autoconfiguration to determine its IPv6 addresses would 299 use only the Information-request and Reply messages to obtain other 300 configuration information. 302 Clients and servers that do not use all of the functions of DHCP 303 need not implement processing for those DHCP messages that will not 304 be used. A client or server that receives a message that it is not 305 prepared to process may simply discard that message. For example, a 306 DHCP server that only provides configuration information and does not 307 do IPv6 address assignment can respond to only Information-request 308 messages and discard other messages such as Solicit or Request 309 messages. 311 1.3. Client-server exchanges involving two messages 313 A DHCP client can obtain configuration information such as a list 314 of available DNS servers or NTP servers through a single message 315 and reply exchanged with a DHCP server. To obtain configuration 316 information the client first sends an Information-Request message 317 to the All_DHCP_Relay_Agents_and_Servers multicast address. The 318 server responds with a Reply message containing the configuration 319 information for the client. 321 This message exchange assumes that the client requires only 322 configuration information and does not require the assignment of any 323 IPv6 addresses. Because the server need not keep any dynamic state 324 information about individual clients to support this two message 325 exchange, a server that provides just configuration information can 326 be realized with a relatively simple and small implementation. 328 When a server has IPv6 addresses and other configuration information 329 committed to a client, the client and server may be able to complete 330 the exchange using only two messages, instead of four messages as 331 described in the next section. In this case, the client sends a 332 Solicit message to the All_DHCP_Relay_Agents_and_Servers requesting 333 the assignment of addresses and other configuration information. 334 This message includes an indication that the client is willing to 335 accept an immediate Reply message from the server. The server that 336 is willing to commit the assignment of addresses to the client 337 immediately responds with a Reply message. The configuration 338 information and the addresses in the Reply message are then 339 immediately available for use by the client. 341 Each address assigned to the client has associated preferred and 342 valid lifetimes specified by the server. To request an extension 343 of the lifetimes assigned to an address, the client sends a Renew 344 message to the server. The server sends a Reply message to the 345 client with the new lifetimes, allowing the client to continue to use 346 the address without interruption. 348 1.4. Client-server exchanges involving four messages 350 To request the assignment of one or more IPv6 addresses, a 351 client first locates a DHCP server and then requests the 352 assignment of addresses and other configuration information 353 from the server. The client sends a Solicit message to the 354 All_DHCP_Relay_Agents_and_Servers address to find available DHCP 355 servers. Any server that can meet the client's requirements 356 responds with an Advertise message. The client then chooses one 357 of the servers and sends a Request message to the server asking 358 for confirmed assignment of addresses and other configuration 359 information. The server responds with a Reply message that contains 360 the confirmed addresses and configuration. 362 As described in the previous section, the client sends a Renew 363 messages to the server to extend the lifetimes associated with its 364 addresses, allowing the client to continue to use those addresses 365 without interruption. 367 2. Requirements 369 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 370 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 371 document, are to be interpreted as described in [2]. 373 This document also makes use of internal conceptual variables 374 to describe protocol behavior and external variables that an 375 implementation must allow system administrators to change. The 376 specific variable names, how their values change, and how their 377 settings influence protocol behavior are provided to demonstrate 378 protocol behavior. An implementation is not required to have them in 379 the exact form described here, so long as its external behavior is 380 consistent with that described in this document. 382 3. Background 384 The IPv6 Specification provides the base architecture and design of 385 IPv6. Related work in IPv6 that would best serve an implementor 386 to study includes the IPv6 Specification [3], the IPv6 Addressing 387 Architecture [7], IPv6 Stateless Address Autoconfiguration [19], IPv6 388 Neighbor Discovery Processing [15], and Dynamic Updates to DNS [20]. 389 These specifications enable DHCP to build upon the IPv6 work to 390 provide both robust stateful autoconfiguration and autoregistration 391 of DNS Host Names. 393 The IPv6 Addressing Architecture specification [7] defines the 394 address scope that can be used in an IPv6 implementation, and the 395 various configuration architecture guidelines for network designers 396 of the IPv6 address space. Two advantages of IPv6 are that support 397 for multicast is required, and nodes can create link-local addresses 398 during initialization. This means that a client can immediately use 399 its link-local address and a well-known multicast address to begin 400 communications to discover neighbors on the link. For instance, a 401 client can send a Solicit message and locate a server or relay agent. 403 IPv6 Stateless Address Autoconfiguration [19] specifies procedures 404 by which a node may autoconfigure addresses based on router 405 advertisements [15], and the use of a valid lifetime to support 406 renumbering of addresses on the Internet. In addition the 407 protocol interaction by which a node begins stateless or stateful 408 autoconfiguration is specified. DHCP is one vehicle to perform 409 stateful autoconfiguration. Compatibility with stateless address 410 autoconfiguration is a design requirement of DHCP. 412 IPv6 Neighbor Discovery [15] is the node discovery protocol in IPv6 413 which replaces and enhances functions of ARP [16]. To understand 414 IPv6 and stateless address autoconfiguration it is strongly 415 recommended that implementors understand IPv6 Neighbor Discovery. 417 Dynamic Updates to DNS [20] is a specification that supports the 418 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 419 the dynamic updates to DNS to integrate addresses and name space to 420 not only support autoconfiguration, but also autoregistration in 421 IPv6. 423 4. Terminology 425 This sections defines terminology specific to IPv6 and DHCP used in 426 this document. 428 4.1. IPv6 Terminology 430 IPv6 terminology relevant to this specification from the IPv6 431 Protocol [3], IPv6 Addressing Architecture [7], and IPv6 Stateless 432 Address Autoconfiguration [19] is included below. 434 address An IP layer identifier for an interface 435 or a set of interfaces. 437 anycast address An anycast address identifies a group 438 of nodes; message sent to an anycast 439 address is delivered to one node out of 440 the group of nodes associated with the 441 address 443 host Any node that is not a router. 445 IP Internet Protocol Version 6 (IPv6). The 446 terms IPv4 and IPv6 are used only in 447 contexts where it is necessary to avoid 448 ambiguity. 450 interface A node's attachment to a link. 452 link A communication facility or medium over 453 which nodes can communicate at the link 454 layer, i.e., the layer immediately below 455 IP. Examples are Ethernet (simple or 456 bridged); Token Ring; PPP links, X.25, 458 Frame Relay, or ATM networks; and 459 Internet (or higher) layer "tunnels", 460 such as tunnels over IPv4 or IPv6 461 itself. 463 link-layer identifier A link-layer identifier for an 464 interface. Examples include IEEE 802 465 addresses for Ethernet or Token Ring 466 network interfaces, and E.164 addresses 467 for ISDN links. 469 link-local address An IPv6 address having link-only 470 scope, indicated by having the prefix 471 (FE80::0000/64), that can be used to 472 reach neighboring nodes attached to 473 the same link. Every interface has a 474 link-local address. 476 multicast address An identifier for a set of interfaces 477 (typically belonging to different 478 nodes). A packet sent to a multicast 479 address is delivered to all interfaces 480 identified by that address. 482 neighbor A node attached to the same link. 484 node A device that implements IP. 486 packet An IP header plus payload. 488 prefix The initial bits of an address, or a 489 set of IP address that share the same 490 initial bits. 492 prefix length The number of bits in a prefix. 494 router A node that forwards IP packets not 495 explicitly addressed to itself. 497 unicast address An identifier for a single interface. 498 A packet sent to a unicast address is 499 delivered to the interface identified by 500 that address. 502 4.2. DHCP Terminology 504 Terminology specific to DHCP can be found below. 506 binding A binding (or, client binding) is a 507 group of server data records containing 508 the information the server has about 509 the addresses in an IA and any other 510 configuration information assigned to 511 the client. A binding is indexed by 512 the tuple (where 513 IA-type is the type of address in the 514 IA; for example, temporary) 516 configuration parameter An element of the configuration 517 information set on the server and 518 delivered to the client using DHCP. 519 Such parameters may be used to carry 520 information to be used by a node to 521 configure its network subsystem and 522 enable communication on a link or 523 internetwork, for example. 525 DHCP Dynamic Host Configuration Protocol 526 for IPv6. The terms DHCPv4 and DHCPv6 527 are used only in contexts where it is 528 necessary to avoid ambiguity. 530 DHCP client (or client) A node that initiates requests on a link 531 to obtain configuration parameters from 532 one or more DHCP servers. 534 DHCP domain A set of links managed by DHCP and 535 operated by a single administrative 536 entity. 538 DHCP relay agent (or relay agent) A node that acts as an 539 intermediary to deliver DHCP messages 540 between clients and servers, and is on 541 the same link as the client. 543 DHCP server (or server) A server is a node that responds to 544 requests from clients, and may or 545 may not be on the same link as the 546 client(s). 548 DUID A DHCP Unique IDentifier for a DHCP 549 participant; each DHCP client and server 550 has exactly one DUID. See section 9 for 551 details of the ways in which a DUID may 552 be constructed. 554 Identity association (IA) A collection of addresses assigned to 555 a client. Each IA has an associated 556 IAID. A client may have more than one 557 IA assigned to it; for example, one for 558 each of its interfaces. 560 Identity association identifier (IAID) An identifier for an IA, 561 chosen by the client. Each IA has an 562 IAID, which is chosen to be unique among 563 all IAIDs for IAs belonging to that 564 client. 566 message A unit of data carried in a packet, 567 exchanged among DHCP servers, relay 568 agents and clients. 570 transaction-ID An unsigned integer to match responses 571 with replies initiated either by a 572 client or server. 574 5. DHCP Constants 576 This section describes various program and networking constants used 577 by DHCP. 579 5.1. Multicast Addresses 581 DHCP makes use of the following multicast addresses: 583 All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped 584 multicast address used by a client to communicate with 585 neighboring (i.e., on-link) relay agents and servers. 586 All servers and relay agents are members of this 587 multicast group. 589 All_DHCP_Servers (FF05::1:3) A site-scoped multicast address 590 used by a client or relay agent to communicate with 591 servers, either because the client or relay agent 592 wants to send messages to all servers or because it 593 does not know the unicast addresses of the servers. 594 Note that in order for a client or relay agent to use 595 this address, it must have an address of sufficient 596 scope to be reachable by the servers. All servers 597 within the site are members of this multicast group. 599 5.2. Anycast address 601 DHCP proposes to use the following reserved anycast address: 603 DHCP_Anycast (FEC0:0:0:0:FFFF::4) This document proposes the 604 assignment of the DHCP_Anycast address for use 605 by clients attached to links that do not support 606 multicast. 608 5.3. UDP ports 610 Clients listen for DHCP messages on UDP port 546. Servers and relay 611 agents listen for DHCP messages on UDP port 547. 613 5.4. DHCP message types 615 DHCP defines the following message types. More detail on these 616 message types can be found in Section 6. Message types not listed 617 here are reserved for future use. The message code for each message 618 type is shown with the message name. 620 SOLICIT (1) A client sends a Solicit message to locate 621 servers. 623 ADVERTISE (2) A server sends an Advertise message to indicate 624 that it is available for DHCP service, in 625 response to a Solicit message received from a 626 client. 628 REQUEST (3) A client sends a Request message to request 629 configuration parameters from a server. 631 CONFIRM (4) A client sends a Confirm message to servers to 632 request that the server validate and confirm 633 that the addresses and current configuration 634 parameters assigned by the server to the client 635 are still valid. 637 RENEW (5) A client sends a Renew message to the server 638 that originally provided the client's addresses 639 and configuration addresses to update the 640 addresses assigned to the client and the 641 lifetimes for those addresses, as well as the 642 current configuration parameters assigned by 643 the server to the client. 645 REBIND (6) A client sends a Rebind message to update 646 the addresses assigned to the client and the 647 lifetimes for those addresses, as well as the 648 current configuration parameters assigned by 649 the server to the client; this message is sent 650 after a client receives no response to a Renew 651 message. 653 REPLY (7) A server sends a Reply message containing 654 assigned addresses and configuration parameters 655 in response to a Solicit, Request, Renew, 656 Rebind or Information-request message received 657 from a client. A server sends a Reply message 658 confirming or denying the validity of the 659 client's addresses and configuration parameters 660 in response to a Confirm message. A server 661 sends a Reply message to acknowledge receipt of 662 a Release or Decline message. 664 RELEASE (8) A client sends a Release message to the server 665 that assigned addresses to the client to 666 indicate that the client will no longer use one 667 or more of the assigned addresses. 669 DECLINE (9) A client sends a Decline message to a server to 670 indicate that the client has determined that 671 one or more addresses assigned by the server 672 are already in use on the link to which the 673 client is connected. 675 RECONFIGURE (10) A server sends a Reconfigure message to a 676 client to inform the client that the server has 677 new or updated configuration parameters, and 678 that the client is to initiate a Renew/Reply 679 or Information-request/Reply transaction with 680 the server in order to receive the updated 681 information. 683 INFORMATION-REQUEST (11) A client sends an Information-request 684 message to a server to request configuration 685 parameters without the assignment of any IP 686 addresses to the client. 688 RELAY-FORW (12) A relay agent sends a Relay-forward message to 689 forward client messages to servers. The client 690 message is encapsulated in an option in the 691 Relay-forward message. 693 RELAY-REPL (13) A server sends a Relay-reply message to a relay 694 agent to send messages to clients through the 695 relay agent. The server encapsulates the 696 client message as an option in the Relay-reply 697 message, which the relay agent extracts and 698 forwards to the client. 700 5.5. Status Codes 702 DHCPv6 uses status codes to communicate the success or failure of 703 operations requested in messages from clients and servers, and to 704 provide additional information about the specific cause of the 705 failure of a message. The specific status codes are defined in 706 section 25.6. 708 5.6. Configuration Parameters 710 This section presents a table of configuration parameters used to 711 describe the message transmission behavior of clients and servers. 713 Parameter Default Description 714 ------------------------------------- 715 MIN_SOL_DELAY 1 sec Min delay of first Solicit 716 MAX_SOL_DELAY 5 secs Max delay of first Solicit 717 SOL_TIMEOUT 500 msecs Initial Solicit timeout 718 SOL_MAX_RT 30 secs Max Solicit timeout value 719 REQ_TIMEOUT 250 msecs Initial Request timeout 720 REQ_MAX_RT 30 secs Max Request timeout value 721 REQ_MAX_RC 10 Max Request retry attempts 722 CNF_TIMEOUT 250 msecs Initial Confirm timeout 723 CNF_MAX_RT 1 sec Max Confirm timeout 724 CNF_MAX_RD 10 secs Max Confirm duration 725 REN_TIMEOUT 10 sec Initial Renew timeout 726 REN_MAX_RT 600 secs Max Renew timeout value 727 REB_TIMEOUT 10 secs Initial Rebind timeout 728 REB_MAX_RT 600 secs Max Rebind timeout value 729 INF_TIMEOUT 500 ms Initial Information-request timeout 730 INF_MAX_RT 30 secs Max Information-request timeout value 731 REL_TIMEOUT 250 msecs Initial Release timeout 732 REL_MAX_RT 1 sec Max Release timeout 733 REL_MAX_RC 5 MAX Release attempts 734 DEC_TIMEOUT 250 msecs Initial Decline timeout 735 DEC_MAX_RT 1 sec Max Decline timeout 736 DEC_MAX_RC 5 Max Decline attempts 738 6. Message Formats 740 All DHCP messages sent between clients and servers share an identical 741 fixed format header and a variable format area for options. 743 All values in the message header and in options are in network order. 745 The following diagram illustrates the format of DHCP messages sent 746 between clients and servers: 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | msg-type | transaction-ID | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | | 754 . options . 755 . (variable) . 756 | | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 msg-type Identifies the DHCP message type; the 760 available message types are listed in 761 section 5.4. 763 transaction-id An unsigned integer used by a client or 764 server to match a response message to a 765 request message. 767 options Options carried in this message; options are 768 described in section 22. 770 7. Relay agent messages 772 Relay agents exchange messages with servers to forward messages 773 between clients and servers that are not connected to the same link. 775 There are two relay agent messages, which share the following format: 777 0 1 2 3 778 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 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | msg-type | | 781 +-+-+-+-+-+-+-+-+ | 782 | link-address | 783 | | 784 | | 785 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 786 | | | 787 +-+-+-+-+-+-+-+-+ | 788 | client-address | 789 | | 790 | | 791 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 792 | | | 793 +-+-+-+-+-+-+-+-+ | 794 . . 795 . options (variable number and length) .... . 796 | | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 The following sections describe the use of the Relay Agent message 800 header. 802 7.1. Relay-forward message 804 The following table defines the use of message fields in a 805 Relay-forward message. 807 msg-type RELAY-FORW 809 link-address A global or site-local address that will be used 810 by the server to identify the link on which the 811 client is located. 813 client-address The address of the client from which the message 814 to be forwarded was received 816 options MUST include a "Client message option" (see 817 section 22.10); MAY include other options added 818 by the relay agent 820 7.2. Relay-reply message 822 The following table defines the use of message fields in a 823 Relay-reply message. 825 msg-type RELAY-REPL 827 link-address The link-address copied from the Relay-forward 828 message 830 client-address The client's address, copied from the 831 relay-forward message 833 options MUST include a "Server message option"; see 834 section 22.11; MAY include other options 836 8. Representation and use of domain names 838 So that domain names may be encoded uniformly and compactly, a 839 domain name or a list of domain names is encoded using the technique 840 described in sections 3.1 and 4.1.4 of RFC1035 [12]. Section 4.1.4 841 of RFC1035 describes how more than one domain name can be represented 842 in a list of domain names. For use in this specification, in a 843 list of domain names, the compression pointer (see section 4.1.4 of 844 RFC1035) refers to the offset within the list. 846 9. DHCP unique identifier (DUID) 848 Each DHCP client and server has a DUID. DHCP servers use DUIDs to 849 identify clients for the selection of configuration parameters and 850 in the association of IAs with clients. DHCP clients use DUIDs to 851 identify a server in messages where a server needs to be identified. 852 See sections 22.2 and 22.3 for the representation of a DUID in a DHCP 853 message. 855 Clients and servers MUST treat DUIDs as opaque values and MUST only 856 compare DUIDs for equality. Clients and servers MUST NOT in any 857 other way interpret DUIDs. Clients and servers MUST NOT restrict 858 DUIDs to the types defined in this document as additional DUID types 859 may be defined in the future. 861 The DUID is carried in an option because it may be variable length 862 and because it is not required in all DHCP messages. The DUID is 863 designed to be unique across all DHCP clients and servers, and 864 consistent for any specific client or server - that is, the DUID 865 used by a client or server SHOULD NOT change over time; for example, 866 a device's DUID should not change as a result of a change in the 867 device's network hardware. 869 The motivation for having more than one type of DUID is that the DUID 870 must be globally unique, and must also be easy to generate. The sort 871 of globally-unique identifier that is easy to generate for any given 872 device can differ quite widely. Also, some devices may not contain 873 any persistent storage. Retaining a generated DUID in such a device 874 is not possible, so the DUID scheme must accommodate such devices. 876 9.1. DUID contents 878 A DUID consists of a two octet type code represented in network 879 order, followed by a variable number of octets that make up the 880 actual identifier. A DUID can be no more than 256 octets long. The 881 following types are currently defined: 883 1 Link-layer address plus time 884 2 Vendor-assigned unique ID based on domain name 885 3 Vendor-assigned unique ID based on Enterprise Number 886 4 Link-layer address 888 Formats for the variable field of the DUID for each of the above 889 types are shown below. 891 9.2. DUID based on link-layer address plus time 893 This type of DUID consists of a two octet type field containing the 894 value 1, a two octet hardware type code, four octets containing 895 a time value, followed by link-layer address of any one network 896 interface that is connected to the DHCP device at the time that the 897 DUID is generated. The time value is the time that the DUID is 898 generated represented in seconds since midnight (UTC), January 1, 899 2000, modulo 2^32. The hardware type MUST be a valid hardware type 900 assigned by the IANA as described in the section on ARP in RFC 826. 901 Both the time and the hardware type are stored in network order. 903 The following diagram illustrates the format of a DUID based on 904 link-layer address plus time: 906 0 1 2 3 907 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 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | 1 | Hardware type (16 bits) | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Time (32 bits) | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 . . 914 . link-layer address (variable length) . 915 . . 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 The choice of network interface can be completely arbitrary, as long 918 as that interface provides a unique link-layer address, and the same 919 DUID should be used in configuring all network interfaces connected 920 to the device, regardless of which interface's link-layer address was 921 used to generate the DUID. 923 Clients and servers using this type of DUID MUST store the DUID 924 in stable storage, and MUST continue to use this DUID even if the 925 network interface used to generate the DUID is removed. Clients and 926 servers that do not have any stable storage MUST NOT use this type of 927 DUID. 929 Clients and servers that use this DUID SHOULD attempt to configure 930 the time prior to generating the DUID, if that is possible, and MUST 931 use some sort of time source (for example, a real-time clock) in 932 generating the DUID, even if that time source could not be configured 933 prior to generating the DUID. The use of a time source makes it 934 unlikely that two identical DUIDs will be generated if the network 935 interface is removed from the client and another client then uses 936 the same network interface to generate a DUID. A DUID collision is 937 very unlikely even if the clocks haven't been configured prior to 938 generating the DUID. 940 This method of DUID generation is recommended for all general purpose 941 computing devices such as desktop computers and laptop computers, and 942 also for devices such as printers, routers, and so on, that contain 943 some form of writable non-volatile storage. 945 Despite our best efforts, it is possible that this algorithm for 946 generating a DUID could result in a client identifier collision. A 947 DHCP client that generates a DUID using this mechanism MUST provide 948 an administrative interface that replaces the existing DUID with a 949 newly-generated DUID of this type. 951 9.3. Vendor-assigned unique ID based on Domain Name (VUID-DN) 953 The vendor-assigned unique ID based on the domain name consists of a 954 two-octet value giving the length of the identifier, the value of the 955 identifier and the vendor's registered domain name. 957 The following diagram summarizes the structure of a VUID-DN: 959 0 1 2 3 960 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 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | 2 | identifier length | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 . . 965 . identifier . 966 . (variable length) . 967 . . 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 . . 970 . domain name (variable length) . 971 . . 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 The source of the identifier is left up to the vendor defining it, 975 but each identifier part of each VUID-DN MUST be unique to the device 976 that is using it, and MUST be assigned to the device at the time of 977 manufacture and stored in some form of non-volatile storage. The 978 VUID-DN SHOULD be recorded in non-erasable storage. The domain name 979 is simply any domain name that has been legally registered by the 980 vendor in the domain name system [11], stored in the form described 981 in section 8. 983 If a domain name is being used by a vendor as a vendor identifier, 984 then the vendor MUST ensure that the domain name has not previously 985 been used by a different vendor. 987 An example DUID of this type might look like this: 989 +---+---+---+---+---+---+---+---+ 990 | 0 | 2 | 0 | 8 | 12|192|132|221| 991 +---+---+---+---+---+---+---+---+ 992 | 3 | 0 | 9 | 18|101|120| 97|109| 993 +---+---+---+---+---+---+---+---+ 994 |112|108|101| 46| 99|111|109| 995 +---+---+---+---+---+---+---+ 997 This example includes the two-octet type of 2, the two-octet length 998 of 8, eight octets of identifier data, followed by "example.com" 999 represented in ASCII. 1001 9.4. Vendor-assigned unique ID based on Enterprise Number (VUID-EN) 1003 The vendor-assigned unique ID based on Enterprise Number consists 1004 of the vendor's registered Enterprise Number as maintained by IANA 1005 followed by the value of the identifier. 1007 The following diagram summarizes the structure of a VUID-EN: 1009 0 1 2 3 1010 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 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | 3 | Enterprise Number | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Enterprise Number (contd) | | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1016 . identifier . 1017 . (variable length) . 1018 . . 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 The source of the identifier is left up to the vendor defining it, 1022 but each identifier part of each VUID-EN MUST be unique to the device 1023 that is using it, and MUST be assigned to the device at the time of 1024 manufacture and stored in some form of non-volatile storage. The 1025 VUID SHOULD be recorded in non-erasable storage. The Enterprise 1026 Number is the vendor's Enterprise code from the list "SMI Network 1027 Management Private Enterprise Codes", as maintained by IANA in file 1028 ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers. The 1029 Enterprise Number is stored as an unsigned 32 bit number. 1031 An example DUID of this type might look like this: 1033 +---+---+---+---+---+---+---+---+ 1034 | 0 | 3 | 0 | 0 | 0 | 9| 12|192| 1035 +---+---+---+---+---+---+---+---+ 1036 |132|221| 3 | 0 | 9 | 18| 1037 +---+---+---+---+---+---+ 1039 This example includes the two-octet type of 3, the Enterprise Number 1040 (9), followed by eight octets of identifier data. 1042 9.5. Link-layer address 1044 This type of DUID consists of two octets containing the DUID type 4, 1045 a two octet network hardware type code, followed by the link-layer 1046 address of any one network interface that is permanently connected to 1047 the client or server device. For example, this DUID could be used 1048 by a host that has a network interface implemented in a chip that is 1049 unlikely to be removed and used elsewhere. The hardware type MUST 1050 be a valid hardware type assigned by the IANA as described in the 1051 section on ARP in RFC 826. The hardware type is stored in network 1052 order. 1054 The following diagram illustrates the format of a DUID based on 1055 link-layer address: 1057 0 1 2 3 1058 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 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | 4 | Hardware type (16 bits) | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 . . 1063 . link-layer address (variable length) . 1064 . . 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 The choice of network interface can be completely arbitrary, as 1068 long as that interface provides a unique link-layer address and 1069 is permanently attached to the device on which the DUID is being 1070 generated. The same DUID should be used in configuring all network 1071 interfaces connected to the device, regardless of which interface's 1072 link-layer address was used to generate the DUID. 1074 This type of DUID is recommended for devices that have a 1075 permanently-connected network interface with a link-layer address and 1076 do not have nonvolatile, writable stable storage. This type of DUID 1077 MUST NOT be used by DHCP clients or servers that cannot tell whether 1078 or not a network interface is permanently attached to the device on 1079 which the DHCP client is running. 1081 10. Identity association 1083 An "identity-association" (IA) is a construct through which a server 1084 and a client can identify, group and manage IPv6 addresses. Each IA 1085 consists of an IAID and associated configuration information. 1087 A client must associate at least one distinct IA with each of 1088 its network interfaces and uses that IA to obtain configuration 1089 information from a server for that interface. Each IA must be 1090 associated with exactly one interface. 1092 The IAID uniquely identifies the IA and must be chosen to be unique 1093 among the IAIDs on the client. The IAID is chosen by the client. 1094 For any given use of an IA by the client, the IAID for that IA MUST 1095 be consistent across restarts of the DHCP client. The client may 1096 maintain consistency either by storing the IAID in non-volatile 1097 storage or by using an algorithm that will consistently produce the 1098 same IAID as long as the configuration of the client has not changed. 1099 There may be no way for a client to maintain consistency of the IAIDs 1100 if it does not have non-volatile storage and the client's hardware 1101 configuration changes. 1103 The configuration information in an IA consists of one or more IPv6 1104 addresses and other parameters. The parameters are specified as DHCP 1105 options within the IA, and are associated with the addresses in the 1106 IA and the interface to which the IA belongs. Other parameters that 1107 are not associated with a particular interface may be specified in 1108 the options section of a DHCP message, outside the scope of any IA. 1110 Each address in an IA has a preferred lifetime and a valid lifetime, 1111 as defined in RFC2462 [19]. The lifetimes are transmitted from the 1112 DHCP server to the client in the IA option. The lifetimes apply to 1113 the use of IPv6 addresses as described in section 5.5.4 of RFC2462. 1115 See section 22.4 for the representation of an IA in a DHCP message. 1117 11. Selecting addresses for assignment to an IA 1119 A server selects addresses to be assigned to an IA according to the 1120 address assignment policies determined by the server administrator 1121 and the specific information the server determines about the client 1122 from some combination of the following sources: 1124 - The link to which the client is attached. The server determines 1125 the link as follows: 1127 * If the server receives the message directly from the client 1128 and the source address in the IP datagram in which the 1129 message was received is a link-local address, then the client 1130 is on the same link to which the interface over which the 1131 message was received is attached 1133 * If the server receives the message from a forwarding relay 1134 agent, then the client is on the same link as the one to 1135 which the interface identified by the link-address field in 1136 the message from the relay agent is attached 1138 * If the server receives the message directly from the client 1139 and the source address in the IP datagram in which the 1140 message was received is not a link-local address, then the 1141 client is on the link identified by the source address in the 1142 IP datagram (note that this situation can occur only if the 1143 server has enabled the use of unicast message delivery by the 1144 client and the client has sent a message for which unicast 1145 delivery is allowed) 1147 - The DUID supplied by the client 1149 - Other information in options supplied by the client 1151 - Other information in options supplied by the relay agent 1153 A server MUST generate link identifiers for unicast addresses with 1154 the "u" (universal/local) and "g" (individual/group) bits of the 1155 EUI-64 identifier set to 0 (see RFC 2373). 1157 A server MUST NOT assign an address that is otherwise reserved by 1158 IANA. 1160 12. Management of temporary addresses 1162 A client may be assigned temporary addresses (temporary addresses 1163 are defined in RFC 3041 [14]). Clients and servers simply identify 1164 addresses as "temporary". DHCPv6 handling of address assignment is 1165 no different for temporary addresses. DHCPv6 says nothing about 1166 details of temporary addresses like lifetimes, how clients use 1167 temporary addresses, rules for generating successive temporary 1168 addresses, etc. 1170 Clients ask for temporary addresses and servers assign them. 1171 Temporary addresses are carried in the Identity Association for 1172 Temporary Addresses (IA_TA) option (see section 22.5). Each IA_TA 1173 option contains at most one temporary address for each of the 1174 prefixes on the link to which the client is attached. 1176 Unless otherwise stated, an IA_TA option is used in the same way in 1177 as an IA option. In the protocol specification, unless otherwise 1178 stated, a reference to an IA should be read as either an IA or an 1179 IA_TA. 1181 The IAID number space for the IA_TA option IAID number space is 1182 separate from the IA option IAID number space. 1184 The server MAY update the DNS for a temporary address as described in 1185 section 4 of RFC3041, and MUST NOT update the DNS in any other way 1186 for a temporary address. 1188 13. Transmission of messages by a client 1190 Unless otherwise specified, a client sends DHCP messages to the 1191 All_DHCP_Relay_Agents_and_Servers or the DHCP_Anycast address. 1193 If the client is attached to a link that supports multicast 1194 transmission, the client sends DHCP messages to the 1195 All_DHCP_Relay_Agents_and_Servers address. If the client is 1196 attached to a link that does not support multicast transmission, the 1197 client uses the DHCP_Anycast address. 1199 A client may send some messages directly to a server using unicast, 1200 as described in section 22.13. 1202 14. Reliability of Client Initiated Message Exchanges 1204 DHCP clients are responsible for reliable delivery of messages in the 1205 client-initiated message exchanges described in sections 17 and 18. 1206 If a DHCP client fails to receive an expected response from a server, 1207 the client must retransmit its message. This section describes the 1208 retransmission strategy to be used by clients in client-initiated 1209 message exchanges. 1211 Note that the procedure described in this section is slightly 1212 modified for use with the Solicit message (section 17.1.2). 1214 The client begins the message exchange by transmitting a message to 1215 the server. The message exchange terminates when either the client 1216 successfully receives the appropriate response or responses from a 1217 server or servers, or when the message exchange is considered to have 1218 failed according to the retransmission mechanism described below. 1220 The client retransmission behavior is controlled and described by the 1221 following variables: 1223 RT Retransmission timeout 1225 IRT Initial retransmission time 1227 MRC Maximum retransmission count 1229 MRT Maximum retransmission time 1231 MRD Maximum retransmission duration 1233 RAND Randomization factor 1235 With each message transmission or retransmission, the client sets RT 1236 according to the rules given below. If RT expires before the message 1237 exchange terminates, the client recomputes RT and retransmits the 1238 message. 1240 Each of the computations of a new RT include a randomization factor 1241 (RAND), which is a random number chosen with a uniform distribution 1242 between -0.1 and +0.1. The randomization factor is included to 1243 minimize synchronization of messages transmitted by DHCP clients. 1244 The algorithm for choosing a random number does not need to be 1245 cryptographically sound. The algorithm SHOULD produce a different 1246 sequence of numbers from each invocation of the DHCP client. 1248 RT for the first message transmission is based on IRT: 1250 RT = 2*IRT + RAND*IRT 1252 RT for each subsequent message transmission is based on the previous 1253 value of RT: 1255 RT = 2*RTprev + RAND*RTprev 1257 MRT specifies an upper bound on the value of RT. If MRT has a value 1258 of 0, there is no upper limit on the value of RT. Otherwise: 1260 if (RT > MRT) 1261 RT = MRT + RAND*MRT 1263 MRC specifies an upper bound on the number of times a client may 1264 retransmit a message. If MRC has a value of 0, the client MUST 1265 continue to retransmit the original message until a response is 1266 received. Otherwise, the message exchange fails once the client has 1267 transmitted the message MRC times. 1269 MRD specifies an upper bound on the length of time a client may 1270 retransmit a message. If MRD has a value of 0, the client MUST 1271 continue to retransmit the original message until a response is 1272 received. Otherwise, the message exchange fails once the client has 1273 transmitted the message MRD seconds. 1275 If both MRC and MRD are non-zero, the message exchange fails whenever 1276 either of the conditions specified in the previous two paragraphs are 1277 met. 1279 15. Message validation 1281 Servers MUST discard any received messages that include 1282 authentication information and fail the authentication check by the 1283 server. 1285 Clients MUST discard any received messages that include 1286 authentication information and fail the authentication check by the 1287 client, except as noted in section 21.5.5.2. 1289 15.1. Use of Transaction-ID field 1291 The "transaction-ID" field holds a value used by clients and servers 1292 to synchronize server responses to client messages. A client SHOULD 1293 choose a different transaction-ID for each new message it sends. A 1294 client MUST leave the transaction-ID unchanged in retransmissions of 1295 a message. 1297 15.2. Solicit message 1299 Clients MUST discard any received Solicit messages. 1301 Servers MUST discard any Solicit messages that do not include a 1302 Client Identifier option. 1304 15.3. Advertise message 1306 Clients MUST discard any received Advertise messages that meet any of 1307 the following conditions: 1309 - the message does not include a Server Identifier option 1311 - the message does not include a Client Identifier option 1313 - the contents of the Client Identifier option does not match the 1314 client's DUID 1316 - the "Transaction-ID" field value does not match the value the 1317 client used in its Solicit message 1319 Servers and relay agents MUST discard any received Advertise 1320 messages. 1322 15.4. Request message 1324 Clients MUST discard any received Request messages. 1326 Servers MUST discard any received Request message that meet any of 1327 the following conditions: 1329 - the message does not include a Server Identifier option 1331 - the contents of the Server Identifier option do not match the 1332 server's identifier 1334 - the message does not include a Client Identifier option 1336 15.5. Confirm message 1338 Clients MUST discard any received Confirm messages. 1340 Servers MUST discard any Confirm messages received that do not 1341 include a Client Identifier option. 1343 15.6. Renew message 1345 Clients MUST discard any received Renew messages. 1347 Servers MUST discard any received Renew message that meets any of the 1348 following conditions: 1350 - the message does not include a Server Identifier option 1352 - the contents of the Server Identifier option do not match the 1353 server's identifier 1355 - the message does not include a Client Identifier option 1357 15.7. Rebind message 1359 Clients MUST discard any received Rebind messages. 1361 Servers MUST discard any received Rebind message that does not 1362 include a Client Identifier option. 1364 15.8. Decline messages 1366 Clients MUST discard any received Decline messages. 1368 Servers MUST discard any received Decline message that meets any of 1369 the following conditions: 1371 - the message does not include a Server Identifier option 1373 - the contents of the Server Identifier option do not match the 1374 server's identifier 1376 - the message does not include a Client Identifier option 1378 15.9. Release message 1380 Clients MUST discard any received Release messages. 1382 Servers MUST discard any received Decline message that meets any of 1383 the following conditions: 1385 - the message does not include a Server Identifier option 1387 - the contents of the Server Identifier option do not match the 1388 server's identifier 1390 - the message does not include a Client Identifier option 1392 15.10. Reply message 1394 Clients MUST discard any received Reply messages that meet any of the 1395 following conditions: 1397 - the message does not include a Server Identifier option 1399 - the "transaction-ID" field in the message does not match the 1400 value used in the original message 1402 - the message does not include a Client Identifier option and the 1403 original message from the client contained a Client Identifier 1404 option 1406 - the message includes a Client Identifier option and the contents 1407 of the Client Identifier option does not match the DUID of the 1408 client 1410 Servers and relay agents MUST discard any received Reply messages. 1412 15.11. Reconfigure message 1414 Servers and relay agents MUST discard any received Reconfigure 1415 messages. 1417 Clients MUST discard any Reconfigure messages that meet any of the 1418 following conditions: 1420 - the message does not include a Server Identifier option 1422 - the message does not contain an authentication option 1424 - the message fails the authentication validation performed by the 1425 client 1427 15.12. Information-request message 1429 Clients MUST discard any received Information-request messages. 1431 Servers MAY discard any received Information-request messages that do 1432 not include a Client Identifier option. 1434 Servers MUST discard any received Information-request message that 1435 includes a Server Identifier option and the DUID in the option does 1436 not match the server's DUID. 1438 15.13. Relay-forward message 1440 Clients MUST discard any received Relay-forward messages. 1442 15.14. Relay-reply message 1444 Clients and servers MUST discard any received Relay-reply messages. 1446 16. Client Source Address and Interface Selection 1448 When a client sends a DHCP message to the 1449 All_DHCP_Relay_Agents_and_Servers multicast address, it MUST 1450 use the IPv6 link-local address assigned to the interface for which 1451 the client is interested in obtaining configuration as the source 1452 address in the header of the IP datagram. 1454 When a client sends a DHCP message to the DHCP_Anycast address, it 1455 MUST use an address assigned to the interface for which the client 1456 is interested in obtaining configuration, which is suitable for use 1457 by the server in responding to the client, as the source address in 1458 the header of the IP datagram. See "Default Address Selection for 1459 IPv6" [4] for more details. 1461 When a client sends a DHCP message directly to a server using unicast 1462 (after receiving the Server Unicast option from that server), it MUST 1463 use an address assigned to the interface for which the client is 1464 interested in obtaining configuration, which is suitable for use by 1465 the server in responding to the client, as the source address in the 1466 header of the IP datagram. 1468 The client MUST transmit the message on the link that the interface 1469 for which configuration information is being obtained is attached 1470 to. The client SHOULD send the message through that interface. The 1471 client MAY send the message through another interface attached to the 1472 same link if and only if the client is certain the two interface are 1473 attached to the same link. 1475 17. DHCP Server Solicitation 1477 This section describes how a client locates servers that will assign 1478 addresses to IAs belonging to the client. 1480 The client is responsible for creating IAs and requesting that a 1481 server assign configuration information, including IPv6 addresses, 1482 to the IA. The client first creates an IA and assigns it an IAID. 1483 The client then transmits a Solicit message containing an IA option 1484 describing the IA. Servers that can assign configuration information 1485 to the IA respond to the client with an Advertise message. The 1486 client then initiates a configuration exchange as described in 1487 section 18. 1489 17.1. Client Behavior 1491 A client uses the Solicit message to discover DHCP servers configured 1492 to serve addresses on the link to which the client is attached. 1494 17.1.1. Creation of Solicit messages 1496 The client sets the "msg-type" field to SOLICIT. The client generates 1497 a transaction ID and inserts this value in the "transaction-ID" 1498 field. 1500 The client MUST include a Client Identifier option to identify itself 1501 to the server. The client MUST include one or more IA options for 1502 any IAs to which it wants the server to assign addresses. The client 1503 MAY include addresses in the IAs as a hint to the server about 1504 addresses for which the client has a preference. The client MUST 1505 NOT include any other options except those specifically allowed as 1506 defined by specific options. 1508 The client may send just IA options for the assignment of 1509 non-temporary addresses, just IA_TA options for the assignment of 1510 only temporary options, or a mix of both IA and IA_TA options. 1512 The client MAY request specific options from the server by including 1513 an Option Request option (see section 22.7) indicating the options 1514 the client is interested in receiving. The client MAY include 1515 options with data values as hints to the server about parameter 1516 values the client would like to have returned. 1518 If the client will accept a Reply message with committed address 1519 assignments and other resources in response to the Solicit message, 1520 the client includes a Rapid Commit option (see section 22.15) in the 1521 Solicit message. 1523 17.1.2. Transmission of Solicit Messages 1525 The first Solicit message from the client on the interface MUST 1526 be delayed by a random amount of time between MIN_SOL_DELAY and 1527 MAX_SOL_DELAY. In the case of a Solicit message transmitted when DHCP 1528 is initiated by IPv6 Neighbor Discovery, the delay gives the amount 1529 of time to wait after the ManagedFlag changes from FALSE to TRUE (see 1530 section 5.5.3 of RFC2462). This random delay desynchronizes clients 1531 which start at the same time (for example, after a power outage). 1533 The client transmits the message according to section 14, using the 1534 following parameters: 1536 IRT SOL_TIMEOUT 1538 MRT SOL_MAX_RT 1540 MRC 0 1542 MRD 0 1544 If the client has included a Rapid Commit option and is waiting for 1545 a Reply message, the client terminates the retransmission process as 1546 soon as a Reply message is received. 1548 If the client is waiting for an Advertise message, the mechanism in 1549 section 14 is modified as follows for use in the transmission of 1550 Solicit messages. The message exchange is not terminated by the 1551 receipt of an Advertise before IRT has elapsed. Rather, the client 1552 collects Advertise messages until IRT has elapsed. Also, the first 1553 RT MUST be selected to be strictly greater than IRT by choosing RAND 1554 to be strictly greater than 0. 1556 A client MUST collect Advertise messages for IRT seconds, unless it 1557 receives an Advertise message with a preference value of 255. The 1558 preference value is carried in the Preference option (section 22.8). 1559 Any Solicit that does not include a Preference option is considered 1560 to have a preference value of 0. If the client receives an Advertise 1561 message with a preference value of 255, then the client SHOULD 1562 act immediately on that Advertise message without waiting for any 1563 additional Advertise messages. 1565 If the client does not receive any Advertise messages before IRT 1566 has elapsed, it begins the retransmission mechanism described in 1567 section 14. The client terminates the retransmission process as 1568 soon as it receives any Advertise message, and the client acts on 1569 the received Advertise message without waiting for any additional 1570 Advertise messages. 1572 A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client 1573 is configured with either MRC or MRD set to a value other than 1574 0, it MUST stop trying to configure the interface if the message 1575 exchange fails. After the DHCP client stops trying to configure the 1576 interface, it SHOULD choose to restart the reconfiguration process 1577 after some external event, such as user input, system restart, or 1578 when the client is attached to a new link. 1580 17.1.3. Receipt of Advertise messages 1582 The client MUST ignore any Advertise message that includes a Status 1583 Code option containing the value AddrUnavail, with the exception that 1584 the client MAY display the associated status message to the 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. If the client receives a Reply message, it processes 1618 the message as described in section 18.1.6. If the client does not 1619 receive a Reply message, the client restarts the server solicitation 1620 process by sending a Solicit message that does not include a Rapid 1621 Commit option. 1623 17.2. Server Behavior 1625 A server sends an Advertise message in response to Solicit messages 1626 it receives to announce the availability of the server to the client. 1628 17.2.1. Receipt of Solicit messages 1630 The server determines the information about the client and its 1631 location as described in section 11 and checks its administrative 1632 policy about responding to the client. If the server is not 1633 permitted to respond to the client, the server discards the Solicit 1634 message. 1636 If the client has included a Rapid Commit option in the Solicit 1637 message and the server has been configured to respond with committed 1638 address assignments and other resources, the server responds to the 1639 Solicit with a Reply message as described in section 17.2.3. 1641 Otherwise, the server generates and sends an Advertise message to the 1642 client. 1644 17.2.2. Creation and transmission of Advertise messages 1646 The server sets the "msg-type" field to ADVERTISE and copies the 1647 contents of the transaction-ID field from the Solicit message 1648 received from the client to the Advertise message. The server 1649 includes its server identifier in a Server Identifier option. 1651 The server MAY add a Preference option to carry the preference value 1652 for the Advertise message. The server implementation SHOULD allow 1653 the setting of a server preference value by the administrator. 1654 The server preference value MUST default to zero unless otherwise 1655 configured by the server administrator. 1657 The server MUST include IA options in the Advertise message 1658 containing any addresses that would be assigned to IAs contained in 1659 the Solicit message from the client. 1661 If the server will not assign any addresses to IAs in a subsequent 1662 Request from the client, the server MUST send an Advertise message to 1663 the client that includes only a status code option with the status 1664 code set to AddrUnavail and a status message for the user. 1666 The server MAY include other options the server will return to the 1667 client in a subsequent Reply message. The information in these 1668 options will be used by the client in the selection of a server if 1669 the client receives more than one Advertise message. The server 1670 SHOULD include options specifying values for options requested by the 1671 client in an Option Request Option included in the Solicit message. 1673 If the Solicit message was received directly by the server, the 1674 server unicasts the Advertise message directly to the client using 1675 the address in the source address field from the IP datagram in 1676 which the Solicit message was received. The Advertise message MUST 1677 be unicast through the interface on which the Solicit message was 1678 received. 1680 If the Solicit message was received in a Relay-forward message, 1681 the server constructs a Relay-reply message with the Advertise 1682 message in the payload of a "server-message" option. The server 1683 unicasts the Relay-reply message directly to the relay agent using 1684 the address in the source address field from the IP datagram in which 1685 the Relay-forward message was received. 1687 17.2.3. Creation and Transmission of Reply messages 1689 The server MUST commit the assignment of any addresses or other 1690 configuration information message before sending a Reply message to a 1691 client in response to a Solicit message. 1693 DISCUSSION: 1695 When using the Solicit-Advertise message exchange, a server 1696 need not commit the assignment of configuration information 1697 to the client or otherwise keep state about the client 1698 before the server sends the Advertise message to the client. 1699 The client will choose one of the responding servers and 1700 send a Request message to obtain configuration information. 1701 The other servers can make any addresses they might have 1702 offered to the client available for assignment to other 1703 clients. 1705 When using the Solicit-Reply message exchange, the server 1706 commits the assignment of any addresses before sending the 1707 Reply message. The client can assume it has been assigned 1708 the addresses in the Reply message and does not need to send 1709 a Request message for those addresses. 1711 Typically, servers that are configured to use the 1712 Solicit-Reply message exchange will be deployed so that only 1713 one server will respond to a Solicit message. If more than 1714 one server responds, the client will only use the addresses 1715 from one of the servers and the addresses from the other 1716 servers will be committed to the client but not used by the 1717 client. 1719 The server includes a Rapid Commit option in the Reply message to 1720 indicate that the Reply is in response to a Solicit message. 1722 The server produces the Reply message as though it had received 1723 a Request message, as described in section 18.2.1. The server 1724 transmits the Reply message as described in section 18.2.8. 1726 18. DHCP Client-Initiated Configuration Exchange 1728 A client initiates a message exchange with a server or servers 1729 to acquire or update configuration information of interest. The 1730 client may initiate the configuration exchange as part of the 1731 operating system configuration process, when requested to do 1732 so by the application layer, when required by Stateless Address 1733 Autoconfiguration or as required to extend the lifetime of an address 1734 (Rebind and Renew messages). 1736 18.1. Client Behavior 1738 A client will use Request, Confirm, Renew, Rebind and 1739 Information-request messages to acquire and confirm the 1740 validity of configuration information. The client uses the server 1741 identifier information and information about IAs from previous 1742 Advertise messages for use in constructing Request messages. 1744 18.1.1. Creation and transmission of Request messages 1746 The client uses a Request message to populate IAs with addresses 1747 and obtain other configuration information. The client includes 1748 one or more IA options in the Request message, with addresses and 1749 information about the IAs that were obtained from the server in a 1750 previous Advertise message. The server then returns addresses and 1751 other information about the IAs to the client in IA options in a 1752 Reply message. 1754 The client generates a transaction ID and inserts this value in the 1755 "transaction-ID" field. 1757 The client places the identifier of the destination server in a 1758 Server Identifier option. 1760 The client MUST include a Client Identifier option to identify itself 1761 to the server. The client adds any other appropriate options, 1762 including one or more IA options (if the client is requesting that 1763 the server assign it some network addresses). 1765 If the client chooses to request specific options from the server, 1766 it does so by including an Option Request option (see section 22.7), 1767 which MUST include all of the options the client is requesting. The 1768 client MAY include options with data values as hints to the server 1769 about parameter values the client would like to have returned. 1771 If the client has a source address of sufficient scope that can be 1772 used by the server as a return address and the client has received 1773 a Server Unicast option (section 22.13) from the server, the client 1774 SHOULD unicast the Request message to the server. 1776 DISCUSSION: 1778 Use of multicast or anycast on a link and relay agents 1779 enables the inclusion of relay agent options in all messages 1780 sent by the client. The server should enable the use of 1781 unicast only when relay agent options will not be used. 1783 The client transmits the message according to section 14, using the 1784 following parameters: 1786 IRT REQ_TIMEOUT 1788 MRT REQ_MAX_RT 1790 MRC REQ_MAX_RC 1792 MRD 0 1794 If the message exchange fails, the client MAY choose one of the 1795 following actions: 1797 - Select another server from a list of servers known to the client; 1798 for example, servers that responded with an Advertise message 1800 - Initiate the server discovery process described in section 17 1802 - Terminate the configuration process and report failure 1804 18.1.2. Creation and transmission of Confirm messages 1806 Whenever a client may have moved to a new link, its IPv6 addresses 1807 and other configuration information may no longer be valid. Examples 1808 of times when a client may have moved to a new link include: 1810 o The client reboots 1812 o The client is physically disconnected from a wired connection 1814 o The client returns from sleep mode 1816 o The client using a wireless technology changes access points 1818 In any situation when a client may have moved to a new link, the 1819 client MUST initiate a Confirm/Reply message exchange. The client 1820 includes any IAs, along with the addresses associated with those IAs, 1821 in its Confirm message. Any responding servers will indicate the 1822 acceptability of the addresses with the status in the Reply message 1823 it returns to the client. 1825 The client sets the "msg-type" field to CONFIRM. The client generates 1826 a transaction ID and inserts this value in the "transaction-ID" 1827 field. 1829 The client MUST include a Client Identifier option to identify itself 1830 to the server. The client adds any appropriate options, including 1831 one or more IA options. The client MUST include the addresses the 1832 client currently has associated with those IAs. 1834 If the client chooses to request specific options from the server, 1835 it does so by including an Option Request option (see section 22.7, 1836 which MUST include all of the options the client is requesting. The 1837 client MAY include options with data values as hints to the server 1838 about parameter values the client would like to have returned. 1840 When the client sends the Confirm message, it MUST use an IPv6 1841 address that the client has confirmed to be valid on the link to 1842 which it is currently attached and that is assigned to the interface 1843 for which the client is interested in obtaining configuration 1844 information as the source address in the IP header of the datagram 1845 carrying the Confirm message. 1847 The client transmits the message according to section 14, using the 1848 following parameters: 1850 IRT CNF_TIMEOUT 1852 MRT CNF_MAX_RT 1854 MRC 0 1856 MRD CNF_MAX_RD 1858 If the client receives no responses before the message transmission 1859 process as described in section 14 terminates, the client SHOULD 1860 continue to use any IP addresses, using the last known lifetimes for 1861 those addresses, and SHOULD continue to use any other previously 1862 obtained configuration parameters. 1864 18.1.3. Creation and transmission of Renew messages 1866 To extend the valid and preferred lifetimes associated with 1867 addresses, the client sends a Renew message to the server containing 1868 an IA option for the IA and its associated addresses. The server 1869 determines new lifetimes for the addresses in the IA according to the 1870 administrative configuration of the server. The server may also add 1871 new addresses to the IA. The server may remove addresses from the IA 1872 by setting the preferred and valid lifetimes of those addresses to 1873 zero. 1875 The server controls the time at which the client contacts the server 1876 to extend the lifetimes on assigned addresses through the T1 and T2 1877 parameters assigned to an IA. 1879 If T1 or T2 is set to 0 by the server, the client does not send a 1880 Renew or Rebind message, respectively, for the IA. 1882 At time T1 for an IA, the client initiates a Renew/Reply message 1883 exchange to extend the lifetimes on any addresses in the IA. The 1884 client includes an IA option with all addresses currently assigned to 1885 the IA in its Renew message. 1887 The client sets the "msg-type" field to RENEW. The client generates a 1888 transaction ID and inserts this value in the "transaction-ID" field. 1890 The client places the identifier of the destination server in a 1891 Server Identifier option. 1893 The client MUST include a Client Identifier option to identify 1894 itself to the server. The client adds any appropriate options, 1895 including one or more IA options. The client MUST include the list 1896 of addresses the client currently has associated with the IAs in the 1897 Renew message. 1899 If the client chooses to request specific options from the server, 1900 it does so by including an Option Request option (see section 22.7), 1901 which MUST include all of the options the client is requesting. The 1902 client MAY include options with data values as hints to the server 1903 about parameter values the client would like to have returned. 1905 If the client has a source address of sufficient scope that can be 1906 used by the server as a return address and the client has received a 1907 Server Unicast option (see section 22.13) from the server, the client 1908 SHOULD unicast the Renew message to the server. 1910 DISCUSSION: 1912 Use of multicast or anycast on a link and relay agents 1913 enables the inclusion of relay agent options in all messages 1914 sent by the client. The server MUST NOT enable the use of 1915 unicast for a client when relay agent options are required 1916 for that client. 1918 The client transmits the message according to section 14, using the 1919 following parameters: 1921 IRT REN_TIMEOUT 1923 MRT REP_MAX_RT 1925 MRC 0 1927 MRD 0 1929 The mechanism in section 14 is modified as follows for use in the 1930 transmission of Renew messages. The message exchange is terminated 1931 when time T2 is reached (see section 18.1.4), at which time the 1932 client begins a Rebind message exchange. 1934 18.1.4. Creation and transmission of Rebind messages 1936 At time T2 for an IA (which will only be reached if the server to 1937 which the Renew message was sent at time T1 has not responded), 1938 the client initiates a Rebind/Reply message exchange. The client 1939 includes an IA option with all addresses currently assigned to the IA 1940 in its Rebind message. 1942 The client sets the "msg-type" field to REBIND. The client generates 1943 a transaction ID and inserts this value in the "transaction-ID" 1944 field. 1946 The client MUST include a Client Identifier option to identify 1947 itself to the server. The client adds any appropriate options, 1948 including one or more IA options. The client MUST include the list 1949 of addresses the client currently has associated with the IAs in the 1950 Rebind message. 1952 If the client chooses to request specific options from the server, 1953 it does so by including an Option Request option (see section 22.7), 1954 which MUST include all of the options the client is requesting. The 1955 client MAY include options with data values as hints to the server 1956 about parameter values the client would like to have returned. 1958 The client transmits the message according to section 14, using the 1959 following parameters: 1961 IRT REB_TIMEOUT 1962 MRT REB_MAX_RT 1964 MRC 0 1966 MRD 0 1968 The mechanism in section 14 is modified as follows for use in the 1969 transmission of Rebind messages. The message exchange is terminated 1970 when the lifetimes of all of the addresses assigned to the IA expire 1971 (see section 10), at which time the client has several alternative 1972 actions to choose from: 1974 - The client may choose to use a Solicit message to locate a new 1975 DHCP server and send a Request for the expired IA to the new 1976 server 1978 - The client may have other addresses in other IAs, so the client 1979 may choose to discard the expired IA and use the addresses in the 1980 other IAs 1982 18.1.5. Creation and Transmission of Information-request messages 1984 The client uses an Information-request message to obtain 1985 configuration information without having addresses assigned to it. 1987 The client sets the "msg-type" field to INFORMATION-REQUEST. The 1988 client generates a transaction ID and inserts this value in the 1989 "transaction-ID" field. 1991 The client SHOULD include a Client Identifier option to identify 1992 itself to the server. If the client does not include a Client 1993 Identifier option, the server will not be able to return any 1994 client-specific options to the client, or the server may choose not 1995 to respond to the message at all. 1997 If the client chooses to request specific options from the server, 1998 it does so by including an Option Request option (see section 22.7), 1999 which MUST include all of the options the client is requesting. The 2000 client MAY include options with data values as hints to the server 2001 about parameter values the client would like to have returned. The 2002 client MUST NOT include any IA options. 2004 If the client has an IPv6 address of sufficient scope, the 2005 client MAY choose to send the Information-request message to the 2006 All_DHCP_Servers multicast address. 2008 The client transmits the message according to section 14, using the 2009 following parameters: 2011 IRT INF_TIMEOUT 2013 MRT INF_MAX_RT 2014 MRC 0 2016 MRD 0 2018 18.1.6. Receipt of Reply message in response to a Request, Confirm, 2019 Renew, Rebind or Information-request message 2021 Upon the receipt of a valid Reply message in response to a Request, 2022 Confirm, Renew, Rebind or Information-request message, the client 2023 extracts the configuration information contained in the Reply. The 2024 client MAY choose to report any status code or message from the 2025 status code option in the Reply message. 2027 The client SHOULD perform duplicate address detection [19] on each 2028 of the addresses in any IAs it receives in the Reply message before 2029 using that address for traffic. If any of the addresses are found 2030 to be in use on the link, the client sends a Decline message to the 2031 server as described in section 18.1.9. 2033 The client records the T1 and T2 times for each IA in the Reply 2034 message. The client records any addresses included with IAs in 2035 the Reply message. The client updates the preferred and valid 2036 lifetimes for the addresses in the IA from the lifetime information 2037 in the IA option. The client leaves any addresses that the client 2038 has associated with the IA that are not included in the IA option 2039 unchanged. 2041 If the Reply was received in response to a Renew or Rebind message, 2042 the client must update the information in any IA option contained in 2043 the Reply message. The client adds any new addresses from the IA 2044 option to the IA, updates lifetimes for existing addresses in the IA 2045 from the IA option and discards any addresses with a lifetime of zero 2046 in the IA option. 2048 Management of the specific configuration information is detailed in 2049 the definition of each option, in section 22. 2051 When the client receives a NotOnLink status in an IA from the server 2052 in response to a Confirm message, the client can assume it needs to 2053 send a Request to the server to obtain appropriate addresses for the 2054 IA. If the client receives any Reply messages that do not indicate 2055 a NotOnLink status, the client can use the addresses in the IA and 2056 ignore any messages that do indicate a NotOnLink status. 2058 When the client receives an AddrUnavail status in an IA from the 2059 server for a Request message the client will have to find a new 2060 server to create an IA. 2062 When the client receives a NoBinding status in an IA from the server 2063 for a Renew message the client can assume it needs to send a Request 2064 to reestablish an IA with the server. 2066 When the client receives an AddrUnavail status in an IA from the 2067 server for a Renew message the client can assume it needs to send a 2068 Request to reestablish an IA with the server. 2070 When the client receives a NoBinding status in an IA from the server 2071 for a Rebind message the client can assume it needs to send a Request 2072 to reestablish an IA with the server or try another server. 2074 When the client receives an AddrUnavail status in an IA from the 2075 server for a Rebind message the client can assume it needs to send a 2076 Request to reestablish an IA with the server or try another server. 2078 18.1.7. Creation and transmission of Release messages 2080 To release one or more addresses, a client sends a Release message to 2081 the server. 2083 The client sets the "msg-type" field to RELEASE. The client generates 2084 a transaction ID and places this value in the "transaction-ID" field. 2086 The client places the identifier of the server that allocated the 2087 address(es) in a Server Identifier option. 2089 The client MUST include a Client Identifier option to identify itself 2090 to the server. The client includes options containing the IAs for 2091 the addresses it is releasing in the "options" field. The addresses 2092 to be released MUST be included in the IAs. Any addresses for the 2093 IAs the client wishes to continue to use should not be in added to 2094 the IAs. 2096 The client MUST NOT use any of the addresses if is releasing as 2097 the source address in the Release message or in any subsequently 2098 transmitted message. 2100 If the client has a source address of sufficient scope that can be 2101 used by the server as a return address and the client has received 2102 a Server Unicast option (section 22.13) from the server, the client 2103 SHOULD unicast the Release message to the server. 2105 DISCUSSION: 2107 Use of multicast or anycast on a link and relay agents 2108 enables the inclusion of relay agent options in all messages 2109 sent by the client. The server MUST NOT enable the use of 2110 unicast for a client when relay agent options are required 2111 for that client. 2113 The client SHOULD choose to guarantee the delivery of the Release 2114 message using the retransmission strategy in section 14. An example 2115 of a situation in which a client would not guarantee delivery would 2116 be when the client is powering down or restarting because of some 2117 error condition. 2119 The client transmits the message according to section 14, using the 2120 following parameters: 2122 IRT REL_TIMEOUT 2124 MRT 0 2126 MRC REL_MAX_MRC 2128 MRD 0 2130 The client MUST abandon the attempt to release addresses if the 2131 Release message exchange fails. 2133 The client MUST stop using all of the addresses being released as 2134 soon as the client begins the Release message exchange process. 2135 If addresses are released but the Reply from a DHCP server is 2136 lost, the client will retransmit the Release message, and the 2137 server may respond with a Reply indicating a status of "Nobinding". 2138 Therefore, the client does not treat a Reply message with a status 2139 of "Nobinding" in a Release message exchange as if it indicates an 2140 error. 2142 Note that if the client fails to release the addresses, the addresses 2143 assigned to the IA will be reclaimed by the server when the lifetime 2144 of the address expires. 2146 18.1.8. Receipt of Reply message in response to a Release message 2148 Upon receipt of a valid Reply message, the client can consider the 2149 Release event successful. 2151 18.1.9. Creation and transmission of Decline messages 2153 The client sets the "msg-type" field to DECLINE. The client generates 2154 a transaction ID and places this value in the "transaction-ID" field. 2156 The client places the identifier of the server that allocated the 2157 address(es) in a Server Identifier option. 2159 The client MUST include a Client Identifier option to identify itself 2160 to the server. The client includes options containing the IAs for 2161 the addresses it is declining in the "options" field. The addresses 2162 to be declined MUST be included in the IAs. Any addresses for the 2163 IAs the client wishes to continue to use should not be in added to 2164 the IAs. 2166 The client MUST NOT use any of the addresses it is declining as 2167 the source address in the Decline message or in any subsequently 2168 transmitted message. 2170 If the client has a source address of sufficient scope that can be 2171 used by the server as a return address and the client has received 2172 a Server Unicast option (section 22.13) from the server, the client 2173 SHOULD unicast the Decline message to the server. 2175 DISCUSSION: 2177 Use of multicast or anycast on a link and relay agents 2178 enables the inclusion of relay agent options in all messages 2179 sent by the client. The server MUST NOT enable the use of 2180 unicast for a client when relay agent options are required 2181 for that client. 2183 The client transmits the message according to section 14, using the 2184 following parameters: 2186 IRT DEC_TIMEOUT 2188 MRT DEC_MAX_RT 2190 MRC DEC_MAX_RC 2192 MRD 0 2194 The client MUST abandon the attempt to decline addresses if the 2195 Decline message exchange fails. 2197 18.1.10. Receipt of Reply message in response to a Decline message 2199 Upon receipt of a valid Reply message, the client can consider the 2200 Decline event successful. 2202 18.2. Server Behavior 2204 For this discussion, the Server is assumed to have been configured in 2205 an implementation specific manner with configuration of interest to 2206 clients. 2208 18.2.1. Receipt of Request messages 2210 When the server receives a Request message via unicast from a 2211 client to which the server has not sent a unicast option, the server 2212 discards the Request message and responds with a Reply message 2213 containing a status code option with value UseMulticast and no other 2214 options. 2216 When the server receives a Request the client is requesting the 2217 configuration of IAs by the server. The server creates the bindings 2218 for that client according to the server's policy and configuration 2219 information and records the IAs and other information about the 2220 client. 2222 The server contructs a Reply message by setting the "msg-type" field 2223 to REPLY, copying the transaction ID from the Request message into 2224 the transaction-ID field. 2226 The server MUST include a Server Identifier option containing the 2227 server's DUID and the Client Identifier option from the Request 2228 message in the Reply message. 2230 If the server finds that the prefix on one or more IP addresses in 2231 any IA in the message from the client is not a valid prefix for the 2232 link to which the client is connected, the server MUST return the IA 2233 to the client with the status field set to NotOnLink. 2235 If the server cannot assign any addresses to any of the IAs in the 2236 message from the client, the server MUST include the IAs in the Reply 2237 message with the status field set to AddrUnavail and no addresses in 2238 the IA. 2240 For any IAs to which the server can assign addresses, the server 2241 includes the IA with addresses and other configuration parameters and 2242 records the IA as a new client binding. 2244 The server adds options to the Reply message for any other 2245 configuration information to be assigned to the client. If the 2246 Request message contained an Option Request option, the server MUST 2247 include options in the Reply message for any options in the Option 2248 Request option the server is configured to return to the client. The 2249 server MAY choose to return other options not specified in the Option 2250 Request option. 2252 18.2.2. Receipt of Confirm messages 2254 When the server receives a Confirm message, the client is requesting 2255 confirmation that the configuration information it will use is valid. 2256 The server locates the binding for that client and compares the 2257 information in the Confirm message from the client to the information 2258 associated with that client. 2260 If the server finds that the information for the client does not 2261 match what is in the binding for that client or the configuration 2262 information is not valid, the server sends a Reply message containing 2263 a Status Code option with the value ConfNoMatch. 2265 If the server finds that the information for the client does match 2266 the information in the binding for that client, and the configuration 2267 information is still valid, the server sends a Reply message 2268 containing a Status Code option with the value Success. 2270 If the server cannot determine if the information in the Confirm 2271 message is valid or invalid, the server MUST NOT send a reply to the 2272 client. For example, if the server does not have a binding for the 2273 client, but the configuration information in the Confirm message 2274 appears valid, the server does not reply. 2276 The server contructs a Reply message by setting the "msg-type" field 2277 to REPLY, copying the transaction ID from the Confirm message into 2278 the transaction-ID field. 2280 The server MUST include a Server Identifier option containing the 2281 server's DUID and the Client Identifier option from the Confirm 2282 message in the Reply message. 2284 The Reply message from the server MUST include a Status Code option. 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 and no other options. 2293 When the server receives a Renew and IA option from a client it 2294 locates the client's binding and verifies that the information in the 2295 IA from the client matches the information stored for that client. 2297 If the server cannot find a client entry for the IA the server 2298 returns the IA containing no addresses with status set to NoBinding 2299 in the Renew message. 2301 If the server finds that any of the addresses are no longer valid 2302 for the client, the server returns the address to the client with 2303 lifetimes of 0. 2305 If the server finds the addresses in the IA for the client then the 2306 server sends back the IA to the client with new lifetimes and T1/T2 2307 times, and includes a Status Code option with value Success. The 2308 server may choose to change the list of addresses and the lifetimes 2309 of addresses in IAs that are returned to the client. 2311 The server contructs a Reply message by setting the "msg-type" field 2312 to REPLY, copying the transaction ID from the Renew message into the 2313 transaction-ID field. 2315 The server MUST include a Server Identifier option containing the 2316 server's DUID and the Client Identifier option from the Renew message 2317 in the Reply message. 2319 18.2.4. Receipt of Rebind messages 2321 When the server receives a Rebind and IA option from a client it 2322 locates the client's binding and verifies that the information in the 2323 IA from the client matches the information stored for that client. 2325 If the server cannot find a client entry for the IA the server 2326 returns the IA containing no addresses with status set to NoBinding 2327 in the Rebind message. 2329 If the server finds that the any of the addresses are no longer valid 2330 for the client, the server returns the address to the client with 2331 lifetimes of 0. 2333 If the server finds the addresses in the IA for the client then the 2334 server SHOULD send back the IA to the client with new lifetimes and 2335 T1/T2 times if the default is not being used. 2337 The server contructs a Reply message by setting the "msg-type" field 2338 to REPLY, copying the transaction ID from the Rebind message into the 2339 transaction-ID field. 2341 The server MUST include a Server Identifier option containing the 2342 server's DUID and the Client Identifier option from the Rebind 2343 message in the Reply message. 2345 The server adds options to the Reply message for any other 2346 configuration information to be assigned to the client. If the 2347 Rebind message contained an Option Request option, the server MUST 2348 include options in the Reply message for any options in the Option 2349 Request option the server is configured to return to the client. The 2350 server MAY choose to return other options not specified in the Option 2351 Request option. 2353 18.2.5. Receipt of Information-request messages 2355 When the server receives an Information-request message, the 2356 client is requesting configuration information that does not 2357 include the assignment of any addresses. The server determines all 2358 configuration parameters appropriate to the client, based on the 2359 server configuration policies known to the server. 2361 The server contructs a Reply message by setting the "msg-type" field 2362 to REPLY, copying the transaction ID from the Rebind message into the 2363 transaction-ID field. 2365 The server MUST include a Server Identifier option containing the 2366 server's DUID and the Client Identifier option from the Rebind 2367 message in the Reply message. 2369 The server adds options to the Reply message for all of the 2370 configuration parameters to be returned to the client. If the 2371 Information-request message contained an Option Request option, the 2372 server MUST include options in the Reply message for any options in 2373 the Option Request option the server is configured to return to the 2374 client. The server MAY choose to return other options not specified 2375 in the Option Request option. 2377 If the Information-request message received from the client did 2378 not include a Client Identifier option, the server SHOULD respond 2379 with a Reply message containing any configuration parameters 2380 that are not determined by the client's identity. If the server 2381 chooses not to respond, the client may continue to retransmit the 2382 Information-request message indefinitely. 2384 18.2.6. Receipt of Release messages 2386 When the server receives a Release message via unicast from a 2387 client to which the server has not sent a unicast option, the server 2388 discards the Release message and responds with a Reply message 2389 containing a status code option with value UseMulticast and no other 2390 options. 2392 Upon the receipt of a valid Release message, the server examines the 2393 IAs and the addresses in the IAs for validity. If the IAs in the 2394 message are in a binding for the client and the addresses in the IAs 2395 have been assigned by the server to those IAs, the server deletes 2396 the addresses from the IAs and makes the addresses available for 2397 assignment to other clients. The server ignores invalid addresses 2398 (though it may choose to log an error if it finds an invalid 2399 address). 2401 After all the addresses have been processed, the server generates a 2402 Reply message and includes a Status Code option with value Success 2403 and a Server Identifier option with the server's DUID. The server 2404 MUST NOT include any other options in the Reply message. 2406 If the server cannot find a binding for the client, the server 2407 sends a Reply message that includes a Status Code option with value 2408 NoBinding. 2410 A server may choose to retain a record of assigned addresses and IAs 2411 after the lifetimes on the addresses have expired to allow the server 2412 to reassign the previously assigned addresses to a client. 2414 18.2.7. Receipt of Decline messages 2416 When the server receives a Decline message via unicast from a 2417 client to which the server has not sent a unicast option, the server 2418 discards the Decline message and responds with a Reply message 2419 containing a status code option with value UseMulticast and no other 2420 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 invalid addresses (though it may 2430 choose to log an error if it finds an invalid 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 and a Server Identifier option with the server's DUID. The server 2435 MUST NOT include any other options in the Reply message. 2437 18.2.8. Transmission of Reply messages 2439 If the Request, Confirm, Renew, Rebind, Release, Decline or 2440 Information-request message from the client was originally received 2441 in a Relay-forward message from a relay, the server places the Reply 2442 message in the options field of a Relay-response message and copies 2443 the link-address and client-address fields from the Relay-forward 2444 message into the Relay-response message. 2446 The server then unicasts the Reply or Relay-reply to the source 2447 address from the IP datagram in which the original message was 2448 received. 2450 19. DHCP Server-Initiated Configuration Exchange 2452 A server initiates a configuration exchange to cause DHCP clients 2453 to obtain new addresses and other configuration information. For 2454 example, an administrator may use a server-initiated configuration 2455 exchange when links in the DHCP domain are to be renumbered. Other 2456 examples include changes in the location of directory servers, 2457 addition of new services such as printing, and availability of new 2458 software. 2460 19.1. Server Behavior 2462 A server sends a Reconfigure message to cause a client to initiate 2463 immediately a Renew/Reply or Information-request/Reply message 2464 exchange with the server. 2466 19.1.1. Creation and transmission of Reconfigure messages 2468 The server sets the "msg-type" field to RECONFIGURE. The server sets 2469 the transaction-id field to 0. The server places its identifier in a 2470 Server Identifier option. 2472 The server MAY include an Option Request option to inform the client 2473 of what information has been changed or new information that has been 2474 added. In particular, the server specifies the IA option in the 2475 Option Request option if the server wants the client to obtain new 2476 address information. 2478 The server MUST include an authentication option in the Reconfigure 2479 message. The server MUST include a Reconfigure Message option 2480 (defined in section 22.20) to select whether the client responds with 2481 a Renew message or an Information-Request message. 2483 The server MUST NOT include any other options in the Reconfigure 2484 except as specifically allowed in the definition of individual 2485 options. 2487 A server sends each Reconfigure message to a single DHCP client, 2488 using an IPv6 unicast address of sufficient scope belonging to the 2489 DHCP client. The server may obtain the address of the client through 2490 the information that the server has about clients that have been in 2491 contact with the server, or the server may be configured with the 2492 address of the client through some external agent. 2494 To reconfigure more than one client, the server unicasts a separate 2495 message to each client. The server may initiate the reconfiguration 2496 of multiple clients concurrently; for example, a server may 2497 send a Reconfigure message to additional clients while previous 2498 reconfiguration message exchanges are still in progress. 2500 The Reconfigure message causes the client to initiate a Renew/Reply 2501 or Information-request/Reply message exchange with the server. The 2502 server interprets the receipt of a Renew or Information-request 2503 message from the client as satisfying the Reconfigure message 2504 request. 2506 19.1.2. Time out and retransmission of Reconfigure messages 2508 If the server does not receive a Renew or Information-request message 2509 from the client in RECREP_MSG_TIMEOUT milliseconds, the server 2510 retransmits the Reconfigure message, doubles the RECREP_MSG_TIMEOUT 2511 value and waits again. The server continues this process until 2512 REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point 2513 the server SHOULD abort the reconfigure process for that client. 2515 Default and initial values for RECREP_MSG_TIMEOUT and 2516 REC_MSG_ATTEMPTS are documented in section 5.6. 2518 19.1.3. Receipt of Renew messages 2520 The server generates and sends Reply message(s) to the client as 2521 described in sections 18.2.3 and 18.2.8, including options for 2522 configuration parameters. 2524 The server MAY choose to send a Reply with the IAs and other 2525 parameters to be reconfigured, even if those IAs and parameters were 2526 not requested in the Renew message from the client. 2528 19.2. Receipt of Information-request messages 2530 The server generates and sends Reply message(s) to the client as 2531 described in sections 18.2.5 and 18.2.8, including options for 2532 configuration parameters. 2534 The server MAY choose to send a Reply with the other parameters to 2535 be reconfigured, even if those parameters were not specified in the 2536 Information-request message from the client. 2538 19.3. Client Behavior 2540 A client MUST accept Reconfigure messages sent to UDP port 546on 2541 interfaces for which it has acquired configuration information 2542 through DHCP. These messages may be sent at any time. Since the 2543 results of a reconfiguration event may affect application layer 2544 programs, the client SHOULD log these events, and MAY notify these 2545 programs of the change through an implementation-specific interface. 2547 19.3.1. Receipt of Reconfigure messages 2549 Upon receipt of a valid Reconfigure message, the client initiates a 2550 transaction with the server by sending a Reply or Information-request 2551 message. While the transaction is in progress, the client silently 2552 discards any Reconfigure messages it receives. 2554 The client responds with either a Renew message or an 2555 Information-request message as indicated by the Reconfigure 2556 Message option (as defined in section 22.20). 2558 DISCUSSION: 2560 The Reconfigure message acts as a trigger that signals the 2561 client to complete a successful message exchange. Once 2562 the client has received a Reconfigure, the client proceeds 2563 with the message exchange (retransmitting the Renew or 2564 Information-request message if necessary); the client 2565 ignores any additional Reconfigure messages (regardless 2566 of the transaction ID in the Reconfigure message) until 2567 the exchange is complete. Subsequent Reconfigure messages 2568 (again independent of the transaction ID) cause the client 2569 to initiate a new exchange. 2571 How does this mechanism work in the face of duplicated or 2572 retransmitted Reconfigure messages? Duplicate messages 2573 will be ignored because the client will begin the exchange 2574 after the receipt of the first Reconfigure. Retransmitted 2575 messages will either trigger the exchange (if the first 2576 Reconfigure was not received by the client) or will be 2577 ignored. The server can discontinue retransmission of 2578 Reconfigure messages to the client once the server receives 2579 the Renew or Information-request message from the client. 2581 It might be possible for a duplicate or retransmitted 2582 Reconfigure to be sufficiently delayed (and delivered out of 2583 order) to arrive at the client after the exchange (initiated 2584 by the original Reconfigure) has been completed. In this 2585 case, the client would initiate a redundant exchange. The 2586 likelihood of delayed and out of order delivery is small 2587 enough to be ignored. The consequence of the redundant 2588 exchange is inefficiency rather than incorrect operation. 2590 19.3.2. Creation and transmission of Renew messages 2592 When responding to a Reconfigure, the client creates and sends 2593 the Renew message in exactly the same manner as outlined in 2594 section 18.1.3, with the exception: if the server included on Option 2595 Request option specifying the IA option, the client MUST include IA 2596 options containing the addresses the client currently has assigned to 2597 ALL IAs for the interface through which the Reconfigure message was 2598 received. 2600 19.3.3. Creation and transmission of Information-request messages 2602 When responding to a Reconfigure, the client creates and sends the 2603 Information-request message in exactly the same manner as outlined in 2604 section 18.1.5, with the exception that the client includes a Server 2605 Identifier option with the identifier from the Reconfigure message to 2606 which the client is responding. 2608 19.3.4. Time out and retransmission of Renew or Information-request 2609 messages 2611 The client uses the same variables and retransmission algorithm as 2612 it does with Renew or Information-request messages generated as part 2613 of a client-initiated configuration exchange. See sections 18.1.3 2614 and 18.1.5 for details. 2616 19.3.5. Receipt of Reply messages 2618 Upon the receipt of a valid Reply message, the client extracts the 2619 contents of the "options" field, and sets (or resets) configuration 2620 parameters appropriately. The client records and updates the 2621 lifetimes for any addresses specified in IAs in the Reply message. 2623 20. Relay Agent Behavior 2625 For this discussion, the relay agent MAY be configured to use a 2626 list of server destination addresses, which MAY include unicast 2627 addresses, the All_DHCP_Servers multicast address, or other multicast 2628 addresses selected by the network administrator. If the relay agent 2629 has not been explicitly configured, it MUST use the All_DHCP_Servers 2630 multicast address as the default. 2632 20.1. Relaying of client messages 2634 When a relay agent receives a valid client message, it constructs 2635 a Relay-forward message. The relay agent places a global or 2636 site-scoped address with a prefix assigned to the link on which the 2637 client should be assigned an address in the link-address field. This 2638 address will be used by the server to determine the link from which 2639 the client should be assigned an address and other configuration 2640 information. 2642 If the relay agent cannot use the address in the link-address field 2643 to identify the interface through which the response to the client 2644 will be forwarded, the relay agent MUST include an Interface-id 2645 option (see section 22.19) in the Relay-forward message. The server 2646 will include the Interface-id option in its Relay-reply message. 2647 The relay agent puts the client's address in the link-address field 2648 regardless of whether the relay agent includes an Interface-id option 2649 in the Relay-forward message. 2651 The relay agent copies the source address from the IP datagram 2652 in which the message was received from the client into the 2653 client-address field in the Relay-forward message. 2655 The relay agent constructs a Client Message option (see 2656 section 22.10) that contains the entire message from the client in 2657 the data field of the option. The relay agent places the Client 2658 Message option along with any "relay agent-specific" options in the 2659 options field of the Relay-forward message. The relay agent sends 2660 the Relay-forward message to the list of server destination addresses 2661 with which it has been configured or to the All_DHCP_Servers address 2662 if it has not been explicitly configured with server destination 2663 addresses. 2665 20.2. Relaying of server messages 2667 The relay agent processes any other options included in the 2668 Relay-reply message as appropriate to those options. The relay 2669 agents then discards those options. 2671 If the Relay-reply message includes a Interface-id option, the relay 2672 agent forwards the message from the server to the client on the link 2673 identified by the Interface-id option. Otherwise, the relay agent 2674 forwards the message on the link identified by the link-address 2675 field. 2677 In either case, the relay agent extracts the server message from the 2678 Server Message option (see section 22.11) and forwards the message to 2679 the address in the client-address field in the Relay-reply message. 2681 21. Authentication of DHCP messages 2683 Some network administrators may wish to provide authentication of 2684 the source and contents of DHCP messages. For example, clients may 2685 be subject to denial of service attacks through the use of bogus 2686 DHCP servers, or may simply be misconfigured due to unintentionally 2687 instantiated DHCP servers. Network administrators may wish to 2688 constrain the allocation of addresses to authorized hosts to avoid 2689 denial of service attacks in "hostile" environments where the network 2690 medium is not physically secured, such as wireless networks or 2691 college residence halls. 2693 Because of the risk of denial of service attacks against DHCP 2694 clients, the use of authentication is mandated in Reconfigure 2695 messages. A DHCP server MUST include an authentication option in 2696 Reconfigure messages sent to clients. 2698 The DHCP authentication mechanism is based on the design of 2699 authentication for DHCP for IPv4 [6]. 2701 21.1. DHCP threat model 2703 The threat to DHCP is inherently an insider threat (assuming a 2704 properly configured network where DHCPv6 ports are blocked on the 2705 perimeter gateways of the enterprise). Regardless of the gateway 2706 configuration, however, the potential attacks by insiders and 2707 outsiders are the same. 2709 The attack specific to a DHCP client is the possibility of the 2710 establishment of a "rogue" server with the intent of providing 2711 incorrect configuration information to the client. The motivation 2712 for doing so may be to establish a "man in the middle" attack or it 2713 may be for a "denial of service" attack. 2715 There is another threat to DHCP clients from mistakenly or 2716 accidentally configured DHCP servers that answer DHCP client requests 2717 with unintentionally incorrect configuration parameters. 2719 The threat specific to a DHCP server is an invalid client 2720 masquerading as a valid client. The motivation for this may be for 2721 "theft of service", or to circumvent auditing for any number of 2722 nefarious purposes. 2724 The threat common to both the client and the server is the resource 2725 "denial of service" (DoS) attack. These attacks typically involve 2726 the exhaustion of valid addresses, or the exhaustion of CPU or 2727 network bandwidth, and are present anytime there is a shared 2728 resource. 2730 21.2. Security of messages sent between servers and relay agents 2732 Relay agents and servers that choose to exchange messages securely 2733 use the IPsec mechanisms for IPv6 [8]. The way in which IPsec 2734 is employed by relay agents and servers is not specified in this 2735 document. 2737 21.3. Summary of DHCP authentication 2739 Authentication of DHCP messages is accomplished through the use of 2740 the Authentication option (see section 22.12). The authentication 2741 information carried in the Authentication option can be used to 2742 reliably identify the source of a DHCP message and to confirm that 2743 the contents of the DHCP message have not been tampered with. 2745 The Authentication option provides a framework for multiple 2746 authentication protocols. One such protocols is defined here. 2747 Other protocols defined in the future will be specified in separate 2748 documents. 2750 The protocol field in the Authentication option identifies the 2751 specific protocol used to generate the authentication information 2752 carried in the option. The algorithm field identifies a specific 2753 algorithm within the authentication protocol; for example, the 2754 algorithm field specifies the hash algorithm used to generate the 2755 message authentication code (MAC) in the authentication option. The 2756 replay detection method (RDM) field specifies the type of replay 2757 detection used in the replay detection field. 2759 21.4. Replay detection 2761 The Replay Detection Method (RDM) field determines the type of replay 2762 detection used in the Replay Detection field. 2764 If the RDM field contains 0x00, the replay detection field MUST 2765 be set to the value of a monotonically increasing counter. Using 2766 a counter value such as the current time of day (for example, an 2767 NTP-format timestamp [10]) can reduce the danger of replay attacks. 2768 This method MUST be supported by all protocols. 2770 21.5. Delayed authentication protocol 2772 If the protocol field is 1, the message is using the "delayed 2773 authentication" mechanism. In delayed authentication, the client 2774 requests authentication in its Solicit message and the server replies 2775 with an Advertise message that includes authentication information. 2776 This authentication information contains a nonce value generated by 2777 the source as a message authentication code (MAC) to provide message 2778 authentication and entity authentication. 2780 The use of a particular technique based on the HMAC protocol [9] 2781 using the MD5 hash [18] is defined here. 2783 21.5.1. Management issues in the delayed authentication protocol 2785 The "delayed authentication" protocol does not attempt to address 2786 situations where a client may roam from one administrative domain 2787 to another, i.e. interdomain roaming. This protocol is focused on 2788 solving the intradomain problem where the out-of-band exchange of a 2789 shared key is feasible. 2791 21.5.2. Use of the Authentication option in the delayed authentication 2792 protocol 2794 In a Solicit message, the Authentication option carries the Protocol, 2795 Algorithm, RDM and Replay detection fields, but no Authentication 2796 information. 2798 In an Advertise, Request, Renew, Rebind, Confirm, Decline, Release 2799 or Information-request message, the Authentication option carries 2800 the Protocol, Algorithm, RDM and Replay detection fields and 2801 Authentication information. 2803 A DHCP message MUST NOT contain more than one Authentication option 2804 when using the delayed authentication protocol. The Authentication 2805 option should appear as close to the beginning of the options area 2806 in the DHCP message to facilitate processing of the authentication 2807 information.The format of the Authentication information is: 2809 0 1 2 3 2810 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 2811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2812 | Key ID | 2813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2814 | | 2815 | HMAC-MD5 | 2816 | | 2817 | | 2818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2819 The following definitions will be used in the description of the 2820 authentication information for delayed authentication, algorithm 1: 2822 Replay Detection - as defined by the RDM field 2823 K - a key (secret value) shared 2824 between the source and 2825 destination of the message; 2826 each key has a unique 2827 identifier (key ID) 2828 key ID - the unique identifier for the key value 2829 used to generate the MAC for this message 2830 HMAC-MD5 - the MAC generating function. 2832 The sender computes the MAC using the HMAC generation algorithm [9] 2833 and the MD5 hash function [18]. The entire DHCP message (except 2834 the MAC field of the authentication option itself), including the 2835 DHCP message header and the options field, is used as input to the 2836 HMAC-MD5 computation function. The 'key ID' field MUST be set to the 2837 identifier of the key used to generate the MAC. 2839 DISCUSSION: 2841 Algorithm 1 specifies the use of HMAC-MD5. Use of a 2842 different technique, such as HMAC-SHA, will be specified as 2843 a separate protocol. 2845 Delayed authentication requires a shared secret key for each 2846 client on each DHCP server with which that client may wish 2847 to use the DHCP protocol. Each key has a unique identifier 2848 that can be used by a receiver to determine which key was 2849 used to generate the MAC in the DHCP message. Therefore, 2850 delayed authentication may not scale well in an architecture 2851 in which a DHCP client connects to multiple administrative 2852 domains. 2854 21.5.3. Message validation 2856 To validate an incoming message, the receiver first checks that 2857 the value in the replay detection field is acceptable according to 2858 the replay detection method specified by the RDM field. Next, the 2859 receiver computes the MAC as described in [9]. The entire DHCP 2860 message (except the MAC field of the authentication option itself), 2861 is used as input to the HMAC-MDS computation function. If the MAC 2862 computed by the receiver does not match the MAC contained in the 2863 authentication option, the receiver MUST discard the DHCP message. 2865 21.5.4. Key utilization 2867 Each DHCP client has a key, K. The client uses its key to encode 2868 any messages it sends to the server and to authenticate and verify 2869 any messages it receives from the server. The client's key SHOULD 2870 be initially distributed to the client through some out-of-band 2871 mechanism, and SHOULD be stored locally on the client for use in all 2872 authenticated DHCP messages. Once the client has been given its key, 2873 it SHOULD use that key for all transactions even if the client's 2874 configuration changes; for example, if the client is assigned a new 2875 network address. 2877 Each DHCP server MUST know, or be able to obtain in a secure manner, 2878 the keys for all authorized clients. If all clients use the same 2879 key, clients can perform both entity and message authentication for 2880 all messages received from servers. However, the sharing of keys 2881 is strongly discouraged as it allows for unauthorized clients to 2882 masquerade as authorized clients by obtaining a copy of the shared 2883 key and allows for trivial spoofing of an authenticated DHCP server. 2884 To authenticate the identity of individual clients, each client must 2885 be configured with a unique key. 2887 21.5.5. Client considerations for delayed authentication protocol 2889 21.5.5.1. Sending Solicit messages 2891 When the client sends a Solicit message and wishes to use 2892 authentication, it includes an Authentication option with the desired 2893 protocol, algorithm, RDM and replay detection field as described 2894 in section 21.5. The client does not include any authentication 2895 information in the Authentication option. 2897 21.5.5.2. Receiving Advertise messages 2899 The client validates any Advertise messages containing an 2900 Authentication option specifying the delayed authentication protocol 2901 using the validation test described in section 21.5.3. 2903 Client behavior if no Advertise messages include authentication 2904 information or pass the validation test is controlled by local policy 2905 on the client. According to client policy, the client MAY choose to 2906 respond to a Advertise message that has not been authenticated. 2908 The decision to set local policy to accept unauthenticated messages 2909 should be made with care. Accepting an unauthenticated Advertise 2910 message can make the client vulnerable to spoofing and other 2911 attacks. If local users are not explicitly informed that the client 2912 has accepted an unauthenticated Advertise message, the users may 2913 incorrectly assume that the client has received an authenticated 2914 address and is not subject to DHCP attacks through unauthenticated 2915 messages. 2917 A client MUST be configurable to discard unauthenticated messages, 2918 and SHOULD be configured by default to discard unauthenticated 2919 messages if the client has been configured with an authentication 2920 key or other authentication information. A client MAY choose to 2921 differentiate between Advertise messages with no authentication 2922 information and Advertise messages that do not pass the validation 2923 test; for example, a client might accept the former and discard the 2924 latter. If a client does accept an unauthenticated message, the 2925 client SHOULD inform any local users and SHOULD log the event. 2927 21.5.5.3. Sending Request, Confirm, Renew, Rebind, Decline or Release 2928 messages 2930 If the client authenticated the Advertise message through which the 2931 client selected the server, the client MUST generate authentication 2932 information for subsequent Request, Confirm, Renew, Rebind or Release 2933 messages sent to the server as described in section 21.5. When the 2934 client sends a subsequent message, it MUST use the same key used by 2935 the server to generate the authentication information. 2937 21.5.5.4. Sending Information-request messages 2939 If the server has selected a key for the client in a previous message 2940 exchange (see section 21.5.6.1, the client MUST use the same key 2941 to generate the authentication information. If the client has not 2942 previously been given a key with the server, the client MUST use 2943 a key that has been selected for the client through some external 2944 mechanism. 2946 21.5.5.5. Receiving Reply messages 2948 If the client authenticated the Advertise it accepted, the client 2949 MUST validate the associated Reply message from the server. The 2950 client MUST discard the Reply if the message fails to pass validation 2951 and MAY log the validation failure. If the Reply fails to pass 2952 validation, the client MUST restart the DHCP configuration process by 2953 sending a Solicit message. The client MAY choose to remember which 2954 server replied with a Reply message that failed to pass validation 2955 and discard subsequent messages from that server. 2957 If the client accepted an Advertise message that did not include 2958 authentication information or did not pass the validation test, the 2959 client MAY accept an unauthenticated Reply message from the server. 2961 21.5.5.6. Receiving Reconfigure messages 2963 The client MUST discard the Reconfigure if the message fails to pass 2964 validation and MAY log the validation failure. 2966 21.5.6. Server considerations for delayed authentication protocol 2968 21.5.6.1. Receiving Solicit messages and Sending Advertise messages 2970 The server selects a key for the client and includes authentication 2971 information in the Advertise message returned to the client as 2972 specified in section 21.5. The server MUST record the identifier of 2973 the key selected for the client and use that same key for validating 2974 subsequent messages with the client. 2976 21.5.6.2. Receiving Request, Confirm, Renew, Rebind or Release messages 2977 and Sending Reply messages 2979 The server uses the key identified in the message and validates the 2980 message as specified in section 21.5.3. If the message fails to pass 2981 validation or the server does not know the key identified by the 'key 2982 ID' field, the server MUST discard the message and MAY choose to log 2983 the validation failure. 2985 If the message passes the validation procedure, the server responds 2986 to the specific message as described in section 18.2. The server 2987 MUST include authentication information generated using the key 2988 identified in the received message as specified in section 21.5. 2990 21.5.6.3. Sending Reconfigure messages 2992 The server MUST include an Authentication option in a Reconfigure 2993 message, generated as specified in section 21.5 using the key the 2994 server initially selected for the client to which the Reconfigure 2995 message is to be sent. 2997 If the server has not previously selected a key for the client, the 2998 server MUST use a key that has been selected for the client through 2999 some external mechanism. 3001 22. DHCP options 3003 Options are used to carry additional information and parameters 3004 in DHCP messages. Every option shares a common base format, as 3005 described in section 22.1. All values in options are represented in 3006 network order. 3008 This document describes the DHCP options defined as part of the base 3009 DHCP specification. Other options may be defined in the future in 3010 separate documents. 3012 Unless otherwise noted, each option may appear only in the options 3013 area of a DHCP message and may appear only once. If an option does 3014 appear multiple times, each instance is considered separate and the 3015 data areas of the options MUST NOT be concatenated or otherwise 3016 combined. 3018 22.1. Format of DHCP options 3020 0 1 2 3 3021 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 3022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3023 | option-code | option-len | 3024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3025 | option-data | 3026 | (option-len octets) | 3027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3029 option-code An unsigned integer identifying the specific option 3030 type carried in this option. 3032 option-len An unsigned integer giving the length of the 3033 option-data field in this option in octets. 3035 option-data The data for the option; the format of this data 3036 depends on the definition of the option. 3038 DHCPv6 options are scoped by using encapsulation. Some options apply 3039 generally to the client, some are specific to an IA, and some are 3040 specific to the addresses within an IA. These latter two cases are 3041 discussed in sections 22.4 and 22.6. 3043 22.2. Client Identifier option 3045 The Client Identifier option is used to carry a DUID identifying a 3046 client between a client and a server. The Client Identifier option 3047 MUST appear before any IA options in the DHCP message. The format of 3048 the Client Identifier option is: 3050 0 1 2 3 3051 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 3052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3053 | OPTION_CLIENTID | option-len | 3054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3055 . . 3056 . DUID . 3057 . (variable length) . 3058 . . 3059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3061 option-code OPTION_CLIENTID (1) 3063 option-len Length of DUID in octets 3065 DUID The DUID for the client 3067 22.3. Server Identifier option 3069 The Server Identifier option is used to carry a DUID identifying 3070 a server between a client and a server. The format of the Server 3071 Identifier option is: 3073 0 1 2 3 3074 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 3075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3076 | OPTION_SERVERID | option-len | 3077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3078 . . 3079 . DUID . 3080 . (variable length) . 3081 . . 3082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3084 option-code OPTION_SERVERID (2) 3086 option-len Length of DUID in octets 3088 DUID The DUID for the server 3090 22.4. Identity Association option 3092 The Identity Association option (IA option) is used to carry an 3093 identity association, the parameters associated with the IA and the 3094 addresses associated with the IA. 3096 Addresses appearing in an IA option are not temporary addresses (see 3097 section 22.5). 3099 The format of the IA option is: 3101 0 1 2 3 3102 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 3103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3104 | OPTION_IA | option-len | 3105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3106 | IAID (4 octets) | 3107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3108 | T1 | 3109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3110 | T2 | 3111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3112 | | 3113 . IA-options . 3114 . . 3115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3117 option-code OPTION_IA (3) 3119 option-len 12 + length of IA-options field 3121 IAID The unique identifier for this IA; the IAID 3122 must be unique among the identifiers for all 3123 of this client's IAs. The number space for 3124 IA IAIDs is separate from the number space 3125 for IA_TA IAIDs. 3127 T1 The time at which the client contacts the 3128 server from which the addresses in the IA 3129 were obtained to extend the lifetimes of 3130 the addresses assigned to the IA; T1 is a 3131 time duration relative to the current time 3132 expressed in units of seconds 3134 T2 The time at which the client contacts any 3135 available server to extend the lifetimes of 3136 the addresses assigned to the IA; T2 is a 3137 time duration relative to the current time 3138 expressed in units of seconds 3140 IA-options Options associated with this IA. 3142 The IA-options field encapsulates those options that are specific 3143 to this IA. For example, all of the IA Address Options carrying the 3144 addresses associated with this IA are in the IA-options field. 3146 An IA option may only appear in the options area of a DHCP message. 3147 A DHCP message may contain multiple IA options. 3149 The status of any operations involving this IA is indicated in a 3150 Status Code option in the IA-options field. 3152 Note that an IA has no explicit "lifetime" or "lease length" of 3153 its own. When the lifetimes of all of the addresses in an IA have 3154 expired, the IA can be considered as having expired. T1 and T2 3155 are included to give servers explicit control over when a client 3156 recontacts the server about a specific IA. 3158 In a message sent by a client to a server, values in the T1 and 3159 T2 fields indicate the client's preference for those parameters. 3160 The client may send 0 if it has no preference for T1 and T2. In a 3161 message sent by a server to a client, the client MUST use the values 3162 in the T1 and T2 fields for the T1 and T2 parameters. The values in 3163 the T1 and T2 fields are the number of seconds until T1 and T2. 3165 The server selects the T1 and T2 times to allow the client to extend 3166 the lifetimes of any addresses in the IA before the lifetimes expire, 3167 even if the server is unavailable for some short period of time. 3168 Recommended values for T1 and T2 are .5 and .8 times the shortest 3169 preferred lifetime of the addresses in the IA, respectively. If the 3170 server does not intend for a client to extend the lifetimes of the 3171 addresses in an IA, the server sets T1 and T2 to 0. 3173 T1 is the time at which the client begins the lifetime extension 3174 process by sending a Renew message to the server that originally 3175 assigned the addresses to the IA. T2 is the time at which the client 3176 starts sending a Rebind message to any server. 3178 T1 and T2 are specified as unsigned integers that specify the time 3179 in seconds relative to the time at which the messages containing the 3180 option is received. 3182 22.5. Identity Association for Temporary Addresses option 3184 The Identity Association for Temporary Addresses (IA_TA) option is 3185 used to carry an IA, the parameters associated with the IA and the 3186 addresses associated with the IA. All of the addresses in this option 3187 are used by the client as temporary addresses, as defined in RFC 3188 3041. 3190 The format of the IA_TA option is: 3192 0 1 2 3 3193 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 3194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3195 | OPTION_IA_TA | option-len | 3196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3197 | IAID (4 octets) | 3198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3199 | | 3200 . IA-options . 3201 . . 3202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3204 option-code OPTION_IA_TA (4) 3206 option-len 4 + length of IA-options field 3208 IAID The unique identifier for this IA; the IAID 3209 must be unique among the identifiers for all 3210 of this client's IAs. The number space for 3211 IA_TA IAIDs is separate from the number space 3212 for IA IAIDs. 3214 IA-options Options associated with this IA. 3216 The IA-Options field encapsulates those options that are specific 3217 to this IA. For example, all of the IA Address Options carrying the 3218 addresses associated with this IA are in the IA-options field. 3220 Each IA_TA carries one "set" of temporary addresses; that is, at most 3221 one address from each prefix assigned to the link to which the client 3222 is attached. 3224 An IA_TA option may only appear in the options area of a DHCP 3225 message. A DHCP message may contain multiple IA_TA options. 3227 The status of any operations involving this IA is indicated in a 3228 Status Code option in the IA-options field. 3230 Note that an IA has no explicit "lifetime" or "lease length" of 3231 its own. When the lifetimes of all of the addresses in an IA have 3232 expired, the IA can be considered as having expired. 3234 A server MUST return the same set of temporary address for the same 3235 IA_TA (as identified by the IAID) as long as those addresses are 3236 still valid. After the lifetimes of the addresses in an IA_TA have 3237 expired, the IAID may be reused to identify a new IA_TA with new 3238 temporary addresses. 3240 An identity association for temporary addresses option MUST NOT 3241 appear in a Renew or Rebind message. This option MAY appear in a 3242 Confirm message if the lifetimes on the temporary addresses in the 3243 associated IA have not expired. 3245 22.6. IA Address option 3247 The IA Address option is used to specify IPv6 addresses associated 3248 with an IA. The IA Address option must be encapsulated in the 3249 Options field of an Identity Association option. The Options field 3250 encapsulates those options that are specific to this address. 3252 The format of the IA Address option is: 3254 0 1 2 3 3255 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 3256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3257 | OPTION_IAADDR | option-len | 3258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3259 | | 3260 | IPv6 address | 3261 | | 3262 | | 3263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3264 | preferred-lifetime | 3265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3266 | valid-lifetime | 3267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3268 . . 3269 . IAaddr-options . 3270 . . 3271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3273 option-code OPTION_IADDR (5) 3275 option-len 24 + length of IAaddr-options field 3277 IPv6 address An IPv6 address 3279 preferred-lifetime The preferred lifetime for the IPv6 address in 3280 the option, expressed in units of seconds 3282 valid-lifetime The valid lifetime for the IPv6 address in the 3283 option, expressed in units of seconds 3285 IAaddr-options Options associated with this address 3287 In a message sent by a client to a server, values in the preferred 3288 and valid lifetime fields indicate the client's preference for those 3289 parameters. The client may send 0 if it has no preference for the 3290 preferred and valid lifetimes. In a message sent by a server to a 3291 client, the client MUST use the values in the preferred and valid 3292 lifetime fields for the preferred and valid lifetimes. The values in 3293 the preferred and valid lifetimes are the number of seconds remaining 3294 in each lifetime. 3296 An IA Address option may appear only in an IA option or an IA_TA 3297 option. More than one IA Address Options can appear in an IA option 3298 or an IA_TA option. 3300 The status of any operations involving this IA Address is indicated 3301 in a Status Code option in the IAaddr-options field. 3303 22.7. Option Request option 3305 The Option Request option is used to identify a list of options in a 3306 message between a client and a server. 3308 The format of the Option Request option is: 3310 0 1 2 3 3311 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 3312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3313 | OPTION_ORO | option-len | 3314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3315 | requested-option-code-1 | requested-option-code-2 | 3316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3317 | ... | 3318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3320 option-code OPTION_ORO (6) 3322 option-len 2 * number of requested options 3324 requested-option-code-n The option code for an option requested by 3325 the client. 3327 A client MAY include an Option Request option in a Solicit, Request, 3328 Renew, Rebind, Confirm or Information-request message to inform the 3329 server about options the client wants the server to send to the 3330 client. 3332 22.8. Preference option 3334 0 1 2 3 3335 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 3336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3337 | OPTION_PREFERENCE | option-len | 3338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3339 | pref-value | 3340 +-+-+-+-+-+-+-+-+ 3342 option-code OPTION_PREFERENCE (7) 3343 option-len 1. 3345 pref-value The preference value for the server in this message. 3347 A server MAY include a Preference option in an Advertise message to 3348 control the selection of a server by the client. See section 17.1.3 3349 for the use of the Preference option by the client and the 3350 interpretation of Preference option data value. 3352 22.9. Elapsed Time 3354 0 1 2 3 3355 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 3356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3357 | OPTION_ELAPSED_TIME | option-len | 3358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3359 | elapsed-time | 3360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3362 option-code OPTION_ELAPSED_TIME (8) 3364 option-len 2. 3366 elapsed-time The amount of time since the client began its 3367 current DHCP transaction. This time is expressed in 3368 hundredths of a second (10^-2 seconds). 3370 A client SHOULD include an Elapsed Time option in messages to 3371 indicate how long the client has been trying to complete a DHCP 3372 transaction. Servers and Relay Agents use the data value in this 3373 option as input to policy controlling how a server responds to a 3374 client message. For example, the elapsed time option allows a 3375 secondary DHCP server to respond to a request when a primary server 3376 hasn't answered in a reasonable time. 3378 22.10. Client message option 3380 0 1 2 3 3381 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 3382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3383 | OPTION_CLIENT_MSG | option-len | 3384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3385 | | 3386 . DHCP-client-message . 3387 . . 3388 . . 3389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3391 option-code OPTION_CLIENT_MSG (9) 3393 option-len Length of DHCP client message. 3395 DHCP-client-message The message received from the client; 3396 forwarded verbatim to the server. 3398 A relay agent forwards a message from a client to a server as the 3399 contents of a Client Message option in a Relay-forward message. 3401 22.11. Server message option 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_SERVER_MSG | option-len | 3407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3408 | | 3409 . DHCP-server-message . 3410 . . 3411 . . 3412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3414 option-code OPTION_SERVER_MSG (10) 3416 option-len Length of DHCP server message. 3418 DHCP-server-message The message received from the server; 3419 forwarded verbatim to the client. 3421 A server sends a DHCP message to be forwarded to a client by a relay 3422 agent as the contents of a Server Message option in a Relay-reply 3423 message. 3425 22.12. Authentication option 3427 The Authentication option carries authentication information to 3428 authenticate the identity and contents of DHCP messages. The 3429 use of the Authentication option is described in section 21. If 3430 the Authentication option appears in a DHCP message, it should be 3431 included as close to the beginning of the options field as possible 3432 for improved efficiency of authentication processing. 3434 The format of the Authentication option is: 3436 0 1 2 3 3437 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 3438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3439 | OPTION_AUTH | option-len | 3440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3441 | Protocol | Algorithm | RDM | Replay detect.| 3442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3443 | Replay Detection (64 bits) | 3444 | | 3445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3446 | Replay cont. | Auth. Info | 3447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3448 | | 3449 | Authentication Information | 3450 | | 3451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3453 option-code OPTION_AUTH (11) 3455 option-len 12 + length of Authentication 3456 Information field 3458 protocol The authentication protocol used in 3459 this authentication option 3461 algorithm The algorithm used in the 3462 authentication protocol 3464 RDM The replay detection method used in 3465 this authentication option 3467 Replay detection The replay detection information for 3468 the RDM 3470 Authentication information The authentication information, 3471 as specified by the protocol and 3472 algorithm used in this authentication 3473 option 3475 22.13. Server unicast option 3477 The server sends this option to a client to indicate to the client 3478 that it is allowed to unicast messages to the server. The server 3479 specifies the IPv6 address to which the client is to send unicast 3480 messages in the server-address field. When a client receives this 3481 option, where permissible and appropriate, the client sends messages 3482 directly to the server using the IPv6 address specified in the 3483 server-address field of the option. 3485 Details about when the client may send messages to the server using 3486 unicast are in section 18. 3488 0 1 2 3 3489 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 3490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3491 | OPTION_UNICAST | option-len | 3492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3493 | | 3494 | server-address | 3495 | | 3496 | | 3497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3499 option-code OPTION_UNICAST (12) 3501 option-len 16 3503 server-address The IP address to which the client should send 3504 messages delivered using unicast 3506 22.14. Status Code Option 3508 This option returns a status indication related to the DHCP message 3509 or option in which it appears. 3511 0 1 2 3 3512 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 3513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3514 | OPTION_STATUS_CODE | option-len | 3515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3516 | status-code | | 3517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3518 . . 3519 . status-message . 3520 . . 3521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3523 option-code OPTION_STATUS_CODE (13) 3524 option-len 2 + length of status-message 3526 status-code The numeric code for the status encoded in 3527 this option. The status codes are defined in 3528 section 5.5. 3530 status-message A UTF-8 encoded text string, which MUST NOT 3531 be null-terminated. 3533 A Status Code option may appear in a DHCP message option, or in the 3534 options area of another option. 3536 22.15. Rapid Commit option 3538 A client MAY include this option in a Solicit message if the client 3539 is prepared to perform the Solicit-Reply message exchange described 3540 in section 17.1.1. 3542 A server MUST include this option in a Reply message sent in response 3543 to a Solicit message when completing the Solicit-Reply message 3544 exchange. 3546 0 1 2 3 3547 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 3548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3549 | OPTION_RAPID_COMMIT | 0 | 3550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3552 option-code OPTION_RAPID_COMMIT (14) 3554 option-len 0 3556 22.16. User Class Option 3558 This option is used by a client to identify the type or category of 3559 user or applications it represents. The information contained in the 3560 data area of this option is contained in one or more opaque fields 3561 that represent the user class or classes of which the client is a 3562 member. The user class information carried in this option MUST be 3563 configurable on the client. 3565 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 3566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3567 | OPTION_USER_CLASS | option-len | 3568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3569 . . 3570 . user-class-data . 3571 . . 3572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3573 option-code OPTION_USER_CLASS (15) 3575 option-len Length of user class data field 3577 user-class-data The user classes carried by the client. 3579 The data area of the user class option MUST contain one or more 3580 instances of user class data. Each instance of the user class data 3581 is formatted as follows: 3583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 3584 | user-class-len | opaque-data | 3585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 3587 The user-class-len is two octets long and specifies the length of the 3588 opaque user class data in network order. 3590 Servers can interpret the meanings of multiple class specifications 3591 in an implementation dependent or configuration dependent manner, and 3592 so the use of multiple classes by a DHCP client should be based on 3593 the specific server implementation and configuration which will be 3594 used to process that User class option. 3596 22.17. Vendor Class Option 3598 This option is used by a client to identify the vendor that 3599 manufactured the hardware on which the client is running. The 3600 information contained in the data area of this option is contained 3601 in one or more opaque fields that identify details of the hardware 3602 configuration. 3604 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 3605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3606 | OPTION_VENDOR_CLASS | option-len | 3607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3608 | enterprise-number | 3609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3610 . . 3611 . vendor-class-data . 3612 . . . . . 3613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3615 option-code OPTION_VENDOR_CLASS (16) 3617 option-len 4 + length of vendor class data field 3619 enterprise-number The vendor's registered Enterprise Number as 3620 registered with IANA. 3622 vendor-class-data The hardware configuration of the host on 3623 which the client is running. 3625 Each instance of the vendor-class-data is formatted as follows: 3627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 3628 | vendor-class-len | opaque-data | 3629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 3631 The vendor-class-len is two octets long and specifies the length of 3632 the opaque vendor class data in network order. 3634 A DHCP message MUST NOT contain more than one Vendor Class option. 3636 22.18. Vendor-specific Information option 3638 This option is used by clients and servers to exchange 3639 vendor-specific information. The definition of this information is 3640 vendor specific. The vendor is indicated in the enterprise-number 3641 field. Clients that do not receive desired vendor-specific 3642 information SHOULD make an attempt to operate without it, although 3643 they may do so (and announce they are doing so) in a degraded mode. 3645 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 3646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3647 | OPTION_VENDOR_OPTS | option-len | 3648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3649 | enterprise-number | 3650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3651 . . 3652 . option-data . 3653 . . 3654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3656 option-code OPTION_VENDOR_OPTS (17) 3658 option-len 4 + length of option-data field 3660 enterprise-number The vendor's registered Enterprise Number as 3661 registered with IANA. 3663 option-data An opaque object of option-len octets, 3664 interpreted by vendor-specific code on the 3665 clients and servers 3667 The encapsulated vendor-specific options field MUST be encoded as a 3668 sequence of code/length/value fields of identical format to the DHCP 3669 options field. The option codes are defined by the vendor identified 3670 in the enterprise-number field and are not managed by IANA. Each of 3671 the encapsulated options is formatted as follows. 3673 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 3674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3675 | opt-code | option-len | 3676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3677 . . 3678 . option-data . 3679 . . 3680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3682 opt-code The code for the encapsulated option 3684 option-len An unsigned integer giving the length of the 3685 option-data field in this encapsulated option 3686 in octets. 3688 option-data The data area for the encapsulated option 3690 Multiple instances of the Vendor-specific Information option may 3691 appear in a DHCP message. Each instance of the option is interpreted 3692 according to the option codes defined by the vendor identified by the 3693 Enterprise Number in that option. A DHCP message MUST NOT contain 3694 more than one Vendor-specific Information option with the same 3695 Enterprise Number. 3697 22.19. Interface-Id Option 3699 The relay agent MAY send the Interface-id option to identify the 3700 interface on which the client message was received. If a relay agent 3701 receives a Relay-reply message with an Interface-id option, the 3702 relay agent forwards the message to the client through the interface 3703 identified by the option. 3705 0 1 2 3 3706 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 3707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3708 | OPTION_INTERFACE_ID | option-len | 3709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3710 . . 3711 . interface-id . 3712 . . 3713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3715 option-code OPTION_INTERFACE_ID (18) 3717 option-len Length of interface-id field 3719 interface-id An opaque value of arbitrary length generated 3720 by the relay agent to identify one of the 3721 relay agent's interfaces 3723 The server MUST copy the Interface-Id option from the Relay-Forward 3724 message into the Relay-Reply message the server sends to the relay 3725 agent in response to the Relay-Forward message. This option MUST NOT 3726 appear in any message except a Relay-Forward or Relay-Reply message. 3728 Servers MAY use the Interface-ID for parameter assignment policies. 3729 The Interface-ID SHOULD be considered an opaque value, with policies 3730 based on exact string match only; that is, the Interface-ID SHOULD 3731 NOT be internally parsed by the server. 3733 22.20. Reconfigure Message option 3735 A server includes a Reconfigure Message option in a Reconfigure 3736 message to indicate to the client whether the client responds with a 3737 Renew message or an Information-request message. 3739 0 1 2 3 3740 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 3741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3742 | OPTION_RECONF_MSG | option-len | 3743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3744 | msg-type | 3745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3747 option-code OPTION_RECONF_MSG (19) 3749 option-len 1 3751 msg-type 1 for Renew message, 2 for 3752 Information-request message 3754 23. Security Considerations 3756 Section 21 describes a threat model and an option that provides an 3757 authentication framework to defend against that threat model. 3759 24. Year 2000 considerations 3761 Since all times are relative to the current time of the transaction, 3762 there is no problem within the DHCPv6 protocol related to any 3763 hardcoded dates or two-digit representation of the current year. 3765 25. IANA Considerations 3767 This document defines several new name spaces associated with DHCPv6 3768 and DHCPv6 options. IANA is requested to manage the allocation of 3769 values from these name spaces, which are described in the remainder 3770 of this section. These name spaces are all to be managed separately 3771 from the name spaces defined for DHCPv4 [5, 1]. 3773 New values in each of these name spaces should be approved by the 3774 process of IETF consensus [13]. 3776 25.1. Multicast addresses 3778 Section 5.1 defines the following multicast addresses, which have 3779 been assigned by IANA for use by DHCPv6: 3781 All_DHCP_Relay_Agents_and_Servers address: FF02::1:2 3783 All_DHCP_Servers address: FF05::1:3 3785 IANA is requested to manage definition of additional multicast 3786 addresses in the future. 3788 25.2. Anycast addresses 3790 Section 5.2 defines the following anycast address, which is requested 3791 for assignment to DHCP by IANA: 3793 DHCP_Anycast: FEC0:0:0:0:FFFF::4 3795 IANA is requested to manage definition of additional anycast 3796 addresses in the future. 3798 25.3. DHCPv6 message types 3800 IANA is requested to record the following message types (defined in 3801 section 5.4). IANA is requested to manage definition of additional 3802 message types in the future. 3804 SOLICIT 1 3806 ADVERTISE 2 3808 REQUEST 3 3810 CONFIRM 4 3812 RENEW 5 3814 REBIND 6 3816 REPLY 7 3818 RELEASE 8 3819 DECLINE 9 3821 RECONFIGURE 10 3823 INFORMATION-REQUEST 11 3825 RELAY-FORW 12 3827 RELAY-REPL 13 3829 25.4. DUID 3831 IANA is requested to record the following DUID types (as defined in 3832 section 9.1). IANA is requested to manage definition of additional 3833 DUID types in the future. 3835 Link-layer address plus time 1 3837 VUID-DN 2 3839 VUID-EN 3 3841 Link-layer address 4 3843 25.5. DHCPv6 options 3845 IANA is requested to record the following option-codes (as defined 3846 in section 22). IANA is requested to manage the definition of 3847 additional DHCPv6 option-codes in the future. 3849 OPTION_CLIENTID 1 3851 OPTION_SERVERID 2 3853 OPTION_IA 3 3855 OPTION_IA_TMP 4 3857 OPTION_IADDR 5 3859 OPTION_ORO 6 3861 OPTION_PREFERENCE 7 3863 OPTION_ELAPSED_TIME 8 3865 OPTION_CLIENT_MSG 9 3867 OPTION_SERVER_MSG 10 3869 OPTION_AUTH 11 3870 OPTION_UNICAST 12 3872 OPTION_STATUS_CODE 13 3874 OPTION_RAPID_COMMIT 14 3876 OPTION_USER_CLASS 15 3878 OPTION_VENDOR_CLASS 16 3880 OPTION_VENDOR_OPTS 17 3882 OPTION_INTERFACE_ID 18 3884 OPTION_RECONF_MSG 19 3886 25.6. Status codes 3888 IANA is requested to record the status codes defined in the following 3889 table. IANA is requested to manage the definition of additional 3890 status codes in the future. 3892 Name Code Description 3893 ---------- ---- ----------- 3894 Success 0 Success 3895 UnspecFail 1 Failure, reason unspecified; this 3896 status code is sent by either a client 3897 or a server to indicate a failure 3898 not explicitly specified in this 3899 document 3900 AuthFailed 2 Authentication failed or nonexistent 3901 AddrUnavail 3 Addresses unavailable 3902 NoBinding 4 Client record (binding) unavailable 3903 ConfNoMatch 5 Client record Confirm doesn't match IA 3904 NotOnLink 6 One or more prefixes of the addresses 3905 in the IA is not valid for the link 3906 from which the client message was received 3907 UseMulticast 7 Sent by a server to a client to force the 3908 client to send messages to the server 3909 using the All\_DHCP\_Relay\_Agents\_and\_Servers 3910 address 3912 25.7. Authentication option 3914 Section 21 defines three new name spaces associated with the 3915 Authentication Option (section 22.12), which are to be created and 3916 maintained by IANA: Protocol, Algorithm and RDM. 3918 Initial values assigned from the Protocol name space are 0 (reserved) 3919 and 1 (for the delayed authentication Protocol in section 21.5). 3920 Additional protocols may be defined in the future. 3922 The Algorithm name space is specific to individual Protocols. That 3923 is, each Protocol has its own Algorithm name space. The guidelines 3924 for assigning Algorithm name space values for a particular protocol 3925 should be specified along with the definition of a new Protocol. 3927 For the delayed authentication Protocol, the Algorithm value 1 3928 is assigned to the HMAC-MD5 generating function as defined in 3929 section 21.5. Additional algorithms for the delayed authentication 3930 protocol may be defined in the future. 3932 The initial value of 0 from the RDM name space is assigned to the 3933 use of a monotonically increasing value as defined in section 21.4. 3934 Additional replay detection methods may be defined in the future. 3936 26. Acknowledgments 3938 Thanks to the DHC Working Group for their time and input into the 3939 specification. In particular, thanks also for the consistent input, 3940 ideas, and review by (in alphabetical order) Thirumalesh Bhat, 3941 Vijayabhaskar, Brian Carpenter, Matt Crawford, Francis Dupont, Tony 3942 Lindstrom, Josh Littlefield, Gerald Maguire, Jack McCann, Thomas 3943 Narten, Erik Nordmark, Yakov Rekhter, Mark Stapp, Matt Thomas, Sue 3944 Thomson, and Phil Wells. 3946 Thanks to Steve Deering and Bob Hinden, who have consistently 3947 taken the time to discuss the more complex parts of the IPv6 3948 specifications. 3950 Bill Arbaugh reviewed the authentication mechanism described in 3951 section 21. 3953 And, thanks to Steve Deering for pointing out at IETF 51 in London 3954 that the DHCPv6 specification has the highest revision number of any 3955 Internet Draft. 3957 References 3959 [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 3960 Extensions, March 1997. RFC 2132. 3962 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 3963 Levels, March 1997. RFC 2119. 3965 [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 3966 Specification, December 1998. RFC 2460. 3968 [4] R. Draves. Default Address Selection for IPv6, September 2001. 3969 work in progress. 3971 [5] R. Droms. Dynamic Host Configuration Protocol, March 1997. RFC 3972 2131. 3974 [6] R. Droms, Editor, W. Arbaugh, and Editor. Authentication for 3975 DHCP Messages, June 2001. RFC 3118. 3977 [7] R. Hinden and S. Deering. IP Version 6 Addressing Architecture, 3978 July 1998. RFC 2373. 3980 [8] S. Kent and R. Atkinson. Security Architecture for the Internet 3981 Protocol, November 1998. RFC 2401. 3983 [9] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 3984 for Message Authentication, February 1997. RFC 2104. 3986 [10] David L. Mills. Network Time Protocol (Version 3) 3987 Specification, Implementation, March 1992. RFC 1305. 3989 [11] P.V. Mockapetris. Domain names - concepts and facilities, 3990 November 1987. RFC 1034. 3992 [12] P.V. Mockapetris. Domain names - implementation and 3993 specification, November 1987. RFC 1035. 3995 [13] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 3996 Considerations Section in RFCs, October 1998. RFC 2434. 3998 [14] T. Narten and R. Draves. Privacy Extensions for Stateless 3999 Address Autoconfiguration in IPv6, January 2001. RFC 3041. 4001 [15] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 4002 IP Version 6 (IPv6), December 1998. RFC 2461. 4004 [16] D.C. Plummer. Ethernet Address Resolution Protocol: Or 4005 converting network protocol addresses to 48.bit Ethernet address 4006 for transmission on Ethernet hardware, November 1982. RFC 826. 4008 [17] J. Postel. User Datagram Protocol, August 1980. RFC 768. 4010 [18] R. Rivest. The MD5 Message-Digest Algorithm, April 1992. RFC 4011 1321. 4013 [19] S. Thomson and T. Narten. IPv6 Stateless Address 4014 Autoconfiguration, December 1998. RFC 2462. 4016 [20] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic 4017 Updates in the Domain Name System (DNS UPDATE), April 1997. RFC 4018 2136. 4020 Chair's Address 4022 The working group can be contacted via the current chair: 4024 Ralph Droms 4025 Cisco Systems 4026 300 Apollo Drive 4027 Chelmsford, MA 01824 4029 Phone: (978) 244-4733 4030 E-mail: rdroms@cisco.com 4032 Authors' Addresses 4034 Questions about this memo can be directed to: 4036 Jim Bound 4037 Compaq Computer Corporation 4038 ZK3-3/W20 4039 110 Spit Brook Road 4040 Nashua, NH 03062-2698 4041 USA 4042 Voice: +1 603 884 0062 4043 E-mail: Jim.Bound@compaq.com 4045 Mike Carney 4046 Sun Microsystems, Inc 4047 Mail Stop: UMPK17-202 4048 901 San Antonio Road 4049 Palo Alto, CA 94303-4900 4050 USA 4051 Voice: +1-650-786-4171 4052 E-mail: mwc@eng.sun.com 4054 Charles E. Perkins 4055 Communications Systems Lab 4056 Nokia Research Center 4057 313 Fairchild Drive 4058 Mountain View, California 94043 4059 USA 4060 Voice: +1-650 625-2986 4061 E-mail: charliep@iprg.nokia.com 4062 Fax: +1 650 625-2502 4064 Ted Lemon 4065 Nominum, Inc. 4066 950 Charter Street 4067 Redwood City, CA 94043 4068 E-mail: Ted.Lemon@nominum.com 4070 Bernie Volz 4071 Ericsson 4072 959 Concord St 4073 Framingham, MA 01701 4074 Voice: +1-508-875-3162 4075 Fax: +1-508-875-3018 4076 E-mail: bernie.volz@ericsson.com 4078 Ralph Droms 4079 Cisco Systems 4080 300 Apollo Drive 4081 Chelmsford, MA 01824 4082 USA 4083 Voice: +1 978 479 4733 4084 E-mail: rdroms@cisco.com 4086 A. Appearance of Options in Message Types 4088 The following table indicates with a "*" the options are allowed in 4089 each DHCP message type: 4091 Client Server IA/ Option Pref Time Client Server 4092 ID ID IA_TA Request Msg. Msg. 4093 Solicit * * * * 4094 Advert. * * * * * 4095 Request * * * * * 4096 Confirm * * * * 4097 Renew * * * * * 4098 Rebind * * * * 4099 Decline * * * * * 4100 Release * * * * * 4101 Reply * * * * * 4102 Reconf. * * * 4103 Inform. * (see note) * * 4104 R-forw. * 4105 R-repl. * 4107 NOTE: 4109 Only included in Information-Request messages that are sent 4110 in response to a Reconfigure (see section 19.3.3). 4112 Auth Server Status Rap. User Vendor Vendor Inter. Recon. 4113 Unica. Code Comm. Class Class Spec. ID Msg. 4114 Solicit * * * * * 4115 Advert. * * * * * 4116 Request * * * * 4117 Confirm * * * * 4118 Renew * * * * 4119 Rebind * * * * 4120 Decline * * * * * 4121 Release * * * * * 4122 Reply * * * * * * 4123 Reconf. * * 4124 Inform. * * * * 4125 R-forw. * * * * * 4126 R-repl. * * * * * 4128 B. Appearance of Options in the Options Field of DHCP Options 4130 The following table indicates with a "*" where options can appear in 4131 the options field of other options: 4133 Option IA/ IAADDR Client Server 4134 Field IA_TA Msg. Msg. 4135 Client ID * 4136 Server ID * 4137 IA/IA_TA * 4138 IAADDR * 4139 ORO * 4140 Pref * 4141 Time * 4142 Authentic. * 4143 Server Uni. * 4144 Status Code * * * * * 4145 Rapid Comm. * 4146 User Class * 4147 Vendor Class * 4148 Vendor Info. * 4149 Interf. ID * * 4150 Reconf. msg. * 4152 C. Full Copyright Statement 4154 Copyright (C) The Internet Society (2001). All Rights Reserved. 4156 This document and translations of it may be copied and furnished to 4157 others, and derivative works that comment on or otherwise explain it 4158 or assist in its implementation may be prepared, copied, published 4159 and distributed, in whole or in part, without restriction of any 4160 kind, provided that the above copyright notice and this paragraph 4161 are included on all such copies and derivative works. However, 4162 this document itself may not be modified in any way, such as by 4163 removing the copyright notice or references to the Internet Society 4164 or other Internet organizations, except as needed for the purpose 4165 of developing Internet standards in which case the procedures 4166 for copyrights defined in the Internet Standards process must be 4167 followed, or as required to translate it into languages other than 4168 English. 4170 The limited permissions granted above are perpetual and will not be 4171 revoked by the Internet Society or its successors or assigns. 4173 This document and the information contained herein is provided on an 4174 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4175 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4176 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4177 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4178 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.