idnits 2.17.1 draft-ietf-dhc-dhcpv6-25.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 88 longer pages, the longest (page 0) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. -- The draft header indicates that this document obsoletes draft-ietf-dhc-dhcpv6-24.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 3857 has weird spacing: '...e-nonce rec...' == 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-24.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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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) ** Obsolete normative reference: RFC 2373 (ref. '6') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** 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. '12') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3041 (ref. '13') (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 2461 (ref. '14') (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '17') ** Obsolete normative reference: RFC 2462 (ref. '18') (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 Hewlett Packard 3 DHC Working Group M. Carney 4 Obsoletes: draft-ietf-dhc-dhcpv6-24.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 May 24 2002 15 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 16 draft-ietf-dhc-dhcpv6-25.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. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5.3. DHCP message types . . . . . . . . . . . . . . . . . . . 8 77 5.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 10 78 5.5. Configuration Parameters . . . . . . . . . . . . . . . . 10 80 6. Message Formats 11 82 7. Relay agent messages 12 83 7.1. Relay-forward message . . . . . . . . . . . . . . . . . . 12 84 7.2. Relay-reply message . . . . . . . . . . . . . . . . . . . 13 86 8. Representation and use of domain names 13 88 9. DHCP unique identifier (DUID) 13 89 9.1. DUID contents . . . . . . . . . . . . . . . . . . . . . . 14 90 9.2. DUID based on link-layer address plus time . . . . . . . 14 91 9.3. Vendor-assigned unique ID based on Enterprise Number 92 (VUID-EN) . . . . . . . . . . . . . . . . . . . . . . 15 93 9.4. Link-layer address . . . . . . . . . . . . . . . . . . . 16 95 10. Identity association 17 97 11. Selecting addresses for assignment to an IA 17 99 12. Management of temporary addresses 18 101 13. Transmission of messages by a client 19 102 14. Reliability of Client Initiated Message Exchanges 19 104 15. Message validation 21 105 15.1. Use of Transaction-ID field . . . . . . . . . . . . . . . 21 106 15.2. Solicit message . . . . . . . . . . . . . . . . . . . . . 21 107 15.3. Advertise message . . . . . . . . . . . . . . . . . . . . 21 108 15.4. Request message . . . . . . . . . . . . . . . . . . . . . 22 109 15.5. Confirm message . . . . . . . . . . . . . . . . . . . . . 22 110 15.6. Renew message . . . . . . . . . . . . . . . . . . . . . . 22 111 15.7. Rebind message . . . . . . . . . . . . . . . . . . . . . 22 112 15.8. Decline messages . . . . . . . . . . . . . . . . . . . . 23 113 15.9. Release message . . . . . . . . . . . . . . . . . . . . . 23 114 15.10. Reply message . . . . . . . . . . . . . . . . . . . . . . 23 115 15.11. Reconfigure message . . . . . . . . . . . . . . . . . . . 24 116 15.12. Information-request message . . . . . . . . . . . . . . . 24 117 15.13. Relay-forward message . . . . . . . . . . . . . . . . . . 24 118 15.14. Relay-reply message . . . . . . . . . . . . . . . . . . . 24 120 16. Client Source Address and Interface Selection 24 122 17. DHCP Server Solicitation 25 123 17.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 25 124 17.1.1. Creation of Solicit messages . . . . . . . . . . 25 125 17.1.2. Transmission of Solicit Messages . . . . . . . . 26 126 17.1.3. Receipt of Advertise messages . . . . . . . . . . 27 127 17.1.4. Receipt of Reply message . . . . . . . . . . . . 28 128 17.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 28 129 17.2.1. Receipt of Solicit messages . . . . . . . . . . . 28 130 17.2.2. Creation and transmission of Advertise messages . 29 131 17.2.3. Creation and Transmission of Reply messages . . . 30 133 18. DHCP Client-Initiated Configuration Exchange 30 134 18.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 31 135 18.1.1. Creation and transmission of Request messages . . 31 136 18.1.2. Creation and transmission of Confirm messages . . 32 137 18.1.3. Creation and transmission of Renew messages . . . 33 138 18.1.4. Creation and transmission of Rebind messages . . 35 139 18.1.5. Creation and Transmission of Information-request 140 messages . . . . . . . . . . . . . . . . . 36 141 18.1.6. Receipt of Reply message in response to a Request, 142 Confirm, Renew, Rebind or Information-request 143 message . . . . . . . . . . . . . . . . . 36 144 18.1.7. Creation and transmission of Release messages . . 37 145 18.1.8. Receipt of Reply message in response to a Release 146 message . . . . . . . . . . . . . . . . . 39 147 18.1.9. Creation and transmission of Decline messages . . 39 148 18.1.10. Receipt of Reply message in response to a Decline 149 message . . . . . . . . . . . . . . . . . 40 150 18.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 40 151 18.2.1. Receipt of Request messages . . . . . . . . . . . 40 152 18.2.2. Receipt of Confirm messages . . . . . . . . . . . 41 153 18.2.3. Receipt of Renew messages . . . . . . . . . . . . 42 154 18.2.4. Receipt of Rebind messages . . . . . . . . . . . 43 155 18.2.5. Receipt of Information-request messages . . . . . 43 156 18.2.6. Receipt of Release messages . . . . . . . . . . . 44 157 18.2.7. Receipt of Decline messages . . . . . . . . . . . 45 158 18.2.8. Transmission of Reply messages . . . . . . . . . 45 160 19. DHCP Server-Initiated Configuration Exchange 45 161 19.1. Server Behavior . . . . . . . . . . . . . . . . . . . . . 46 162 19.1.1. Creation and transmission of Reconfigure messages 46 163 19.1.2. Time out and retransmission of Reconfigure 164 messages . . . . . . . . . . . . . . . . . 47 165 19.1.3. Receipt of Renew messages . . . . . . . . . . . . 47 166 19.2. Receipt of Information-request messages . . . . . . . . . 47 167 19.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 47 168 19.3.1. Receipt of Reconfigure messages . . . . . . . . . 48 169 19.3.2. Creation and transmission of Renew messages . . . 48 170 19.3.3. Creation and transmission of Information-request 171 messages . . . . . . . . . . . . . . . . . 49 172 19.3.4. Time out and retransmission of Renew or 173 Information-request messages . . . . . . . 49 174 19.3.5. Receipt of Reply messages . . . . . . . . . . . . 49 176 20. Relay Agent Behavior 49 177 20.1. Relaying of client messages . . . . . . . . . . . . . . . 49 178 20.2. Relaying of server messages . . . . . . . . . . . . . . . 50 180 21. Authentication of DHCP messages 50 181 21.1. DHCP threat model . . . . . . . . . . . . . . . . . . . . 51 182 21.2. Security of messages sent between servers and relay agents 51 183 21.3. Summary of DHCP authentication . . . . . . . . . . . . . 51 184 21.4. Replay detection . . . . . . . . . . . . . . . . . . . . 52 185 21.5. Delayed authentication protocol . . . . . . . . . . . . . 52 186 21.5.1. Management issues in the delayed authentication 187 protocol . . . . . . . . . . . . . . . . . 52 188 21.5.2. Use of the Authentication option in the delayed 189 authentication protocol . . . . . . . . . 53 190 21.5.3. Message validation . . . . . . . . . . . . . . . 54 191 21.5.4. Key utilization . . . . . . . . . . . . . . . . . 54 192 21.5.5. Client considerations for delayed authentication 193 protocol . . . . . . . . . . . . . . . . . 55 194 21.5.6. Server considerations for delayed authentication 195 protocol . . . . . . . . . . . . . . . . . 56 197 22. DHCP options 57 198 22.1. Format of DHCP options . . . . . . . . . . . . . . . . . 57 199 22.2. Client Identifier option . . . . . . . . . . . . . . . . 58 200 22.3. Server Identifier option . . . . . . . . . . . . . . . . 58 201 22.4. Identity Association option . . . . . . . . . . . . . . . 59 202 22.5. Identity Association for Temporary Addresses option . . . 61 203 22.6. IA Address option . . . . . . . . . . . . . . . . . . . . 62 204 22.7. Option Request option . . . . . . . . . . . . . . . . . . 63 205 22.8. Preference option . . . . . . . . . . . . . . . . . . . . 64 206 22.9. Elapsed Time . . . . . . . . . . . . . . . . . . . . . . 64 207 22.10. Client message option . . . . . . . . . . . . . . . . . . 65 208 22.11. Server message option . . . . . . . . . . . . . . . . . . 65 209 22.12. Authentication option . . . . . . . . . . . . . . . . . . 66 210 22.13. Server unicast option . . . . . . . . . . . . . . . . . . 67 211 22.14. Status Code Option . . . . . . . . . . . . . . . . . . . 67 212 22.15. Rapid Commit option . . . . . . . . . . . . . . . . . . . 68 213 22.16. User Class Option . . . . . . . . . . . . . . . . . . . . 69 214 22.17. Vendor Class Option . . . . . . . . . . . . . . . . . . . 70 215 22.18. Vendor-specific Information option . . . . . . . . . . . 71 216 22.19. Interface-Id Option . . . . . . . . . . . . . . . . . . . 72 217 22.20. Reconfigure Message option . . . . . . . . . . . . . . . 73 218 22.21. Reconfigure Nonce option . . . . . . . . . . . . . . . . 73 220 23. Security Considerations 74 222 24. IANA Considerations 74 223 24.1. Multicast addresses . . . . . . . . . . . . . . . . . . . 75 224 24.2. DHCP message types . . . . . . . . . . . . . . . . . . . 75 225 24.3. DHCP options . . . . . . . . . . . . . . . . . . . . . . 76 226 24.4. Status codes . . . . . . . . . . . . . . . . . . . . . . 76 227 24.5. DUID . . . . . . . . . . . . . . . . . . . . . . . . . . 77 228 24.6. Authentication option . . . . . . . . . . . . . . . . . . 77 230 25. Acknowledgments 77 232 26. Changes in draft-ietf-dhc-dhcpv6-25.txt 78 234 References 80 236 Chair's Address 81 238 Authors' Addresses 81 240 A. Appearance of Options in Message Types 83 242 B. Appearance of Options in the Options Field of DHCP Options 83 244 C. Full Copyright Statement 84 246 1. Introduction and Overview 248 This document describes DHCP for IPv6 (DHCP), a client/server 249 protocol that provides managed configuration of devices. 251 DHCP can provide a device with addresses assigned by a DHCP server 252 and other configuration information. The addresses and additional 253 configuration are carried in options. DHCP can be extended through 254 the definition of new options to carry configuration information not 255 specified in this document. 257 DHCP is the "stateful address autoconfiguration protocol" and the 258 "stateful autoconfiguration protocol" referred to in RFC2462, "IPv6 259 Stateless Address Autoconfiguration". 261 The remainder of this introduction summarizes DHCP, explaining 262 the message exchange mechanisms and example message flows. The 263 message flows in sections 1.3 and 1.4 are intended as illustrations 264 of DHCP operation rather than an exhaustive list of all possible 265 client-server interactions. Sections 17, 18 and 19 explain client 266 and server operation in detail. 268 1.1. Protocols and addressing 270 Clients and servers exchange DHCP messages using UDP [16]. The 271 client uses its link-local address determined through stateless 272 autoconfiguration for transmitting and receiving DHCP messages. 274 DHCP servers receive messages from clients using a reserved, 275 link-scoped multicast address. A DHCP client transmits most messages 276 to this reserved multicast address, so that the client need not be 277 configured with the address or addresses of DHCP servers. 279 To allow a DHCP client to send a message to a DHCP server that is not 280 attached to the same link, a DHCP relay agent on the client's link 281 will forward messages between the client and server. The operation 282 of the relay agent is transparent to the client and the discussion 283 of message exchanges in the remainder of this section will omit the 284 description of message forwarding by relay agents. 286 Once the client has determined the address of a server, it may 287 under some circumstances send messages directly to the server using 288 unicast. 290 1.2. Protocol implementation 292 This specification for DHCP includes messages and descriptions of 293 client and server behavior for several different functions. Some 294 clients and servers will be deployed in situations in which not all 295 of the functions will be required. For example, a client that uses 296 stateless autoconfiguration to determine its IPv6 addresses would 297 use only the Information-request and Reply messages to obtain other 298 configuration information. 300 Clients and servers that do not use all of the functions of DHCP 301 need not implement processing for those DHCP messages that will not 302 be used. A client or server that receives a message that it is not 303 prepared to process may simply discard that message. For example, a 304 DHCP server that only provides configuration information and does not 305 do IPv6 address assignment can respond to only Information-request 306 messages and discard other messages such as Solicit or Request 307 messages. 309 1.3. Client-server exchanges involving two messages 311 A DHCP client can obtain configuration information such as a list 312 of available DNS servers or NTP servers through a single message 313 and reply exchanged with a DHCP server. To obtain configuration 314 information the client first sends an Information-Request message 315 to the All_DHCP_Relay_Agents_and_Servers multicast address. The 316 server responds with a Reply message containing the configuration 317 information for the client. 319 This message exchange assumes that the client requires only 320 configuration information and does not require the assignment of any 321 IPv6 addresses. Because the server need not keep any dynamic state 322 information about individual clients to support this two message 323 exchange, a server that provides just configuration information can 324 be realized with a relatively simple and small implementation. 326 When a server has IPv6 addresses and other configuration information 327 committed to a client, the client and server may be able to complete 328 the exchange using only two messages, instead of four messages as 329 described in the next section. In this case, the client sends a 330 Solicit message to the All_DHCP_Relay_Agents_and_Servers requesting 331 the assignment of addresses and other configuration information. 332 This message includes an indication that the client is willing to 333 accept an immediate Reply message from the server. The server that 334 is willing to commit the assignment of addresses to the client 335 immediately responds with a Reply message. The configuration 336 information and the addresses in the Reply message are then 337 immediately available for use by the client. 339 Each address assigned to the client has associated preferred and 340 valid lifetimes specified by the server. To request an extension 341 of the lifetimes assigned to an address, the client sends a Renew 342 message to the server. The server sends a Reply message to the 343 client with the new lifetimes, allowing the client to continue to use 344 the address without interruption. 346 1.4. Client-server exchanges involving four messages 348 To request the assignment of one or more IPv6 addresses, a 349 client first locates a DHCP server and then requests the 350 assignment of addresses and other configuration information 351 from the server. The client sends a Solicit message to the 352 All_DHCP_Relay_Agents_and_Servers address to find available DHCP 353 servers. Any server that can meet the client's requirements 354 responds with an Advertise message. The client then chooses one 355 of the servers and sends a Request message to the server asking 356 for confirmed assignment of addresses and other configuration 357 information. The server responds with a Reply message that contains 358 the confirmed addresses and configuration. 360 As described in the previous section, the client sends a Renew 361 messages to the server to extend the lifetimes associated with its 362 addresses, allowing the client to continue to use those addresses 363 without interruption. 365 2. Requirements 367 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 368 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 369 document, are to be interpreted as described in [2]. 371 This document also makes use of internal conceptual variables 372 to describe protocol behavior and external variables that an 373 implementation must allow system administrators to change. The 374 specific variable names, how their values change, and how their 375 settings influence protocol behavior are provided to demonstrate 376 protocol behavior. An implementation is not required to have them in 377 the exact form described here, so long as its external behavior is 378 consistent with that described in this document. 380 3. Background 382 The IPv6 Specification provides the base architecture and design of 383 IPv6. Related work in IPv6 that would best serve an implementor 384 to study includes the IPv6 Specification [3], the IPv6 Addressing 385 Architecture [6], IPv6 Stateless Address Autoconfiguration [18], IPv6 386 Neighbor Discovery Processing [14], and Dynamic Updates to DNS [19]. 387 These specifications enable DHCP to build upon the IPv6 work to 388 provide both robust stateful autoconfiguration and autoregistration 389 of DNS Host Names. 391 The IPv6 Addressing Architecture specification [6] defines the 392 address scope that can be used in an IPv6 implementation, and the 393 various configuration architecture guidelines for network designers 394 of the IPv6 address space. Two advantages of IPv6 are that support 395 for multicast is required, and nodes can create link-local addresses 396 during initialization. This means that a client can immediately use 397 its link-local address and a well-known multicast address to begin 398 communications to discover neighbors on the link. For instance, a 399 client can send a Solicit message and locate a server or relay agent. 401 IPv6 Stateless Address Autoconfiguration [18] specifies procedures 402 by which a node may autoconfigure addresses based on router 403 advertisements [14], and the use of a valid lifetime to support 404 renumbering of addresses on the Internet. In addition the 405 protocol interaction by which a node begins stateless or stateful 406 autoconfiguration is specified. DHCP is one vehicle to perform 407 stateful autoconfiguration. Compatibility with stateless address 408 autoconfiguration is a design requirement of DHCP. 410 IPv6 Neighbor Discovery [14] is the node discovery protocol in IPv6 411 which replaces and enhances functions of ARP [15]. To understand 412 IPv6 and stateless address autoconfiguration it is strongly 413 recommended that implementors understand IPv6 Neighbor Discovery. 415 Dynamic Updates to DNS [19] is a specification that supports the 416 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 417 the dynamic updates to DNS to integrate addresses and name space to 418 not only support autoconfiguration, but also autoregistration in 419 IPv6. 421 4. Terminology 423 This sections defines terminology specific to IPv6 and DHCP used in 424 this document. 426 4.1. IPv6 Terminology 428 IPv6 terminology relevant to this specification from the IPv6 429 Protocol [3], IPv6 Addressing Architecture [6], and IPv6 Stateless 430 Address Autoconfiguration [18] is included below. 432 address An IP layer identifier for an interface 433 or a set of interfaces. 435 host Any node that is not a router. 437 IP Internet Protocol Version 6 (IPv6). The 438 terms IPv4 and IPv6 are used only in 439 contexts where it is necessary to avoid 440 ambiguity. 442 interface A node's attachment to a link. 444 link A communication facility or medium over 445 which nodes can communicate at the link 446 layer, i.e., the layer immediately 447 below IP. Examples are Ethernet (simple 448 or bridged); Token Ring; PPP links, 449 X.25, Frame Relay, or ATM networks; and 450 Internet (or higher) layer "tunnels", 451 such as tunnels over IPv4 or IPv6 452 itself. 454 link-layer identifier A link-layer identifier for an 455 interface. Examples include IEEE 802 456 addresses for Ethernet or Token Ring 457 network interfaces, and E.164 addresses 458 for ISDN links. 460 link-local address An IPv6 address having link-only 461 scope, indicated by having the prefix 462 (FE80::0000/10), that can be used to 463 reach neighboring nodes attached to 464 the same link. Every interface has a 465 link-local address. 467 multicast address An identifier for a set of interfaces 468 (typically belonging to different 469 nodes). A packet sent to a multicast 470 address is delivered to all interfaces 471 identified by that address. 473 neighbor A node attached to the same link. 475 node A device that implements IP. 477 packet An IP header plus payload. 479 prefix The initial bits of an address, or a 480 set of IP addresses that share the same 481 initial bits. 483 prefix length The number of bits in a prefix. 485 router A node that forwards IP packets not 486 explicitly addressed to itself. 488 unicast address An identifier for a single interface. 489 A packet sent to a unicast address is 490 delivered to the interface identified by 491 that address. 493 4.2. DHCP Terminology 495 Terminology specific to DHCP can be found below. 497 binding A binding (or, client binding) is a 498 group of server data records containing 499 the information the server has about 500 the addresses in an IA and any other 501 configuration information assigned to 502 the client. A binding is indexed by 503 the tuple (where 504 IA-type is the type of address in the 505 IA; for example, temporary) 507 configuration parameter An element of the configuration 508 information set on the server and 509 delivered to the client using DHCP. 510 Such parameters may be used to carry 511 information to be used by a node to 512 configure its network subsystem and 513 enable communication on a link or 514 internetwork, for example. 516 DHCP Dynamic Host Configuration Protocol 517 for IPv6. The terms DHCPv4 and DHCPv6 518 are used only in contexts where it is 519 necessary to avoid ambiguity. 521 DHCP client (or client) A node that initiates requests on a link 522 to obtain configuration parameters from 523 one or more DHCP servers. 525 DHCP domain A set of links managed by DHCP and 526 operated by a single administrative 527 entity. 529 DHCP relay agent (or relay agent) A node that acts as an 530 intermediary to deliver DHCP messages 531 between clients and servers, and is on 532 the same link as the client. 534 DHCP server (or server) A node that responds to requests from 535 clients, and may or may not be on the 536 same link as the client(s). 538 DUID A DHCP Unique IDentifier for a DHCP 539 participant; each DHCP client and server 540 has exactly one DUID. See section 9 for 541 details of the ways in which a DUID may 542 be constructed. 544 Identity association (IA) A collection of addresses assigned to 545 a client. Each IA has an associated 546 IAID. A client may have more than one 547 IA assigned to it; for example, one for 548 each of its interfaces. 550 Identity association identifier (IAID) An identifier for an IA, 551 chosen by the client. Each IA has an 552 IAID, which is chosen to be unique among 553 all IAIDs for IAs belonging to that 554 client. 556 message A unit of data carried as the payload 557 of a UDP datagram, exchanged among DHCP 558 servers, relay agents and clients. 560 reconfiguration nonce A 64 bit opaque value used to provide 561 security for Reconfigure messages. A 562 server generates a cryptographically 563 strong random number as a nonce and 564 sends that nonce value to the client. 565 The server then includes the nonce in 566 any Reconfigure messages it sends to the 567 client. 569 transaction-ID An opaque value used to match responses 570 with replies initiated either by a 571 client or server. 573 5. DHCP Constants 575 This section describes various program and networking constants used 576 by DHCP. 578 5.1. Multicast Addresses 580 DHCP makes use of the following multicast addresses: 582 All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped 583 multicast address used by a client to communicate with 584 neighboring (i.e., on-link) relay agents and servers. 585 All servers and relay agents are members of this 586 multicast group. 588 All_DHCP_Servers (FF05::1:3) A site-scoped multicast address 589 used by a client or relay agent to communicate with 590 servers, either because the client or relay agent 591 wants to send messages to all servers or because it 592 does not know the unicast addresses of the servers. 593 Note that in order for a client or relay agent to use 594 this address, it must have an address of sufficient 595 scope to be reachable by the servers. All servers 596 within the site are members of this multicast group. 598 5.2. UDP ports 600 Clients listen for DHCP messages on UDP port 546. Servers and relay 601 agents listen for DHCP messages on UDP port 547. 603 5.3. DHCP message types 605 DHCP defines the following message types. More detail on these 606 message types can be found in Section 6. Message types not listed 607 here are reserved for future use. The message code for each message 608 type is shown with the message name. 610 SOLICIT (1) A client sends a Solicit message to locate 611 servers. 613 ADVERTISE (2) A server sends an Advertise message to indicate 614 that it is available for DHCP service, in 615 response to a Solicit message received from a 616 client. 618 REQUEST (3) A client sends a Request message to request 619 configuration parameters from a server. 621 CONFIRM (4) A client sends a Confirm message to any 622 available server when it detects that it may 623 have moved to a new link to request that the 624 servers verify that the addresses and current 625 configuration parameters assigned by the server 626 to the client are still valid. 628 RENEW (5) A client sends a Renew message to the server 629 that originally provided the client's addresses 630 and configuration parameters to extend the 631 leases on the addresses assigned to the client 632 and to update other configuration parameters. 634 REBIND (6) A client sends a Rebind message to any 635 available server to extend the leases on the 636 addresses assigned to the client and to update 637 other configuration parameters; this message is 638 sent after a client receives no response to a 639 Renew message. 641 REPLY (7) A server sends a Reply message containing 642 assigned addresses and configuration parameters 643 in response to a Solicit, Request, Renew, 644 Rebind or Information-request message received 645 from a client. A server sends a Reply message 646 confirming or denying the validity of the 647 client's addresses and configuration parameters 648 in response to a Confirm message. A server 649 sends a Reply message to acknowledge receipt of 650 a Release or Decline message. 652 RELEASE (8) A client sends a Release message to the server 653 that assigned addresses to the client to 654 indicate that the client will no longer use one 655 or more of the assigned addresses. 657 DECLINE (9) A client sends a Decline message to a server to 658 indicate that the client has determined that 659 one or more addresses assigned by the server 660 are already in use on the link to which the 661 client is connected. 663 RECONFIGURE (10) A server sends a Reconfigure message to a 664 client to inform the client that the server has 665 new or updated configuration parameters, and 666 that the client is to initiate a Renew/Reply 667 or Information-request/Reply transaction with 668 the server in order to receive the updated 669 information. 671 INFORMATION-REQUEST (11) A client sends an Information-request 672 message to a server to request configuration 673 parameters without the assignment of any IP 674 addresses to the client. 676 RELAY-FORW (12) A relay agent sends a Relay-forward message to 677 forward client messages to servers. The client 678 message is encapsulated in an option in the 679 Relay-forward message. 681 RELAY-REPL (13) A server sends a Relay-reply message to a relay 682 agent to send messages to clients through the 683 relay agent. The server encapsulates the 684 client message as an option in the Relay-reply 685 message, which the relay agent extracts and 686 forwards to the client. 688 5.4. Status Codes 690 DHCPv6 uses status codes to communicate the success or failure of 691 operations requested in messages from clients and servers, and to 692 provide additional information about the specific cause of the 693 failure of a message. The specific status codes are defined in 694 section 24.4. 696 5.5. Configuration Parameters 698 This section presents a table of configuration parameters used to 699 describe the message transmission behavior of clients and servers. 701 Parameter Default Description 702 ------------------------------------- 703 MIN_SOL_DELAY 1 sec Min delay of first Solicit 704 MAX_SOL_DELAY 5 secs Max delay of first Solicit 705 SOL_TIMEOUT 500 msecs Initial Solicit timeout 706 SOL_MAX_RT 30 secs Max Solicit timeout value 707 REQ_TIMEOUT 250 msecs Initial Request timeout 708 REQ_MAX_RT 30 secs Max Request timeout value 709 REQ_MAX_RC 10 Max Request retry attempts 710 CNF_TIMEOUT 250 msecs Initial Confirm timeout 711 CNF_MAX_RT 1 sec Max Confirm timeout 712 CNF_MAX_RD 10 secs Max Confirm duration 713 REN_TIMEOUT 10 sec Initial Renew timeout 714 REN_MAX_RT 600 secs Max Renew timeout value 715 REB_TIMEOUT 10 secs Initial Rebind timeout 716 REB_MAX_RT 600 secs Max Rebind timeout value 717 INF_TIMEOUT 500 ms Initial Information-request timeout 718 INF_MAX_RT 30 secs Max Information-request timeout value 719 REL_TIMEOUT 250 msecs Initial Release timeout 720 REL_MAX_RT 1 sec Max Release timeout 721 REL_MAX_RC 5 MAX Release attempts 722 DEC_TIMEOUT 250 msecs Initial Decline timeout 723 DEC_MAX_RT 1 sec Max Decline timeout 724 DEC_MAX_RC 5 Max Decline attempts 725 REC_TIMEOUT 1 sec Initial Reconfigure timeout 726 REC_MAX_RC 8 Max Reconfigure attempts 728 6. Message Formats 730 All DHCP messages sent between clients and servers share an identical 731 fixed format header and a variable format area for options. 733 All values in the message header and in options are in network byte 734 order. 736 Options are stored serially in the options field, with no padding 737 between the options. Options are byte-aligned but are not aligned in 738 any other way such as on 2 or 4 byte boundaries. 740 The following diagram illustrates the format of DHCP messages sent 741 between clients and servers: 743 0 1 2 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | msg-type | transaction-ID | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | | 749 . options . 750 . (variable) . 751 | | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 msg-type Identifies the DHCP message type; the 755 available message types are listed in 756 section 5.3. 758 transaction-id An unsigned integer used by a client or 759 server to match a response message to a 760 request message. 762 options Options carried in this message; options are 763 described in section 22. 765 7. Relay agent messages 767 Relay agents exchange messages with servers to forward messages 768 between clients and servers that are not connected to the same link. 770 There are two relay agent messages, which share the following format: 772 0 1 2 3 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | msg-type | | 776 +-+-+-+-+-+-+-+-+ | 777 | link-address | 778 | | 779 | | 780 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 781 | | | 782 +-+-+-+-+-+-+-+-+ | 783 | client-address | 784 | | 785 | | 786 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 787 | | | 788 +-+-+-+-+-+-+-+-+ | 789 . . 790 . options (variable number and length) .... . 791 | | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 The following sections describe the use of the Relay Agent message 795 header. 797 7.1. Relay-forward message 799 The following table defines the use of message fields in a 800 Relay-forward message. 802 msg-type RELAY-FORW 804 link-address A global or site-local address that will be used 805 by the server to identify the link on which the 806 client is located. 808 client-address The address of the client from which the message 809 to be forwarded was received 811 options MUST include a "Client message option" (see 812 section 22.10); MAY include other options added 813 by the relay agent 815 7.2. Relay-reply message 817 The following table defines the use of message fields in a 818 Relay-reply message. 820 msg-type RELAY-REPL 822 link-address The link-address copied from the Relay-forward 823 message 825 client-address The client's address, copied from the 826 relay-forward message 828 options MUST include a "Server message option"; see 829 section 22.11; MAY include other options 831 8. Representation and use of domain names 833 So that domain names may be encoded uniformly, a domain name or a 834 list of domain names is encoded using the technique described in 835 section 3.1 of RFC1035 [11]. A domain name or list of domain names 836 in DHCP MUST NOT be stored in compressed form as described in section 837 4.1.4 of RFC1035. 839 9. DHCP unique identifier (DUID) 841 Each DHCP client and server has a DUID. DHCP servers use DUIDs to 842 identify clients for the selection of configuration parameters and 843 in the association of IAs with clients. DHCP clients use DUIDs to 844 identify a server in messages where a server needs to be identified. 845 See sections 22.2 and 22.3 for the representation of a DUID in a DHCP 846 message. 848 Clients and servers MUST treat DUIDs as opaque values and MUST only 849 compare DUIDs for equality. Clients and servers MUST NOT in any 850 other way interpret DUIDs. Clients and servers MUST NOT restrict 851 DUIDs to the types defined in this document as additional DUID types 852 may be defined in the future. 854 The DUID is carried in an option because it may be variable length 855 and because it is not required in all DHCP messages. The DUID is 856 designed to be unique across all DHCP clients and servers, and 857 consistent for any specific client or server - that is, the DUID used 858 by a client or server SHOULD NOT change over time if at all possible; 859 for example, a device's DUID should not change as a result of a 860 change in the device's network hardware. 862 The motivation for having more than one type of DUID is that the DUID 863 must be globally unique, and must also be easy to generate. The sort 864 of globally-unique identifier that is easy to generate for any given 865 device can differ quite widely. Also, some devices may not contain 866 any persistent storage. Retaining a generated DUID in such a device 867 is not possible, so the DUID scheme must accommodate such devices. 869 9.1. DUID contents 871 A DUID consists of a two octet type code represented in network byte 872 order, followed by a variable number of octets that make up the 873 actual identifier. A DUID can be no more than 256 octets long. The 874 following types are currently defined: 876 1 Link-layer address plus time 877 2 Vendor-assigned unique ID based on domain name 878 3 Vendor-assigned unique ID based on Enterprise Number 879 4 Link-layer address 881 Formats for the variable field of the DUID for each of the above 882 types are shown below. 884 9.2. DUID based on link-layer address plus time 886 This type of DUID consists of a two octet type field containing the 887 value 1, a two octet hardware type code, four octets containing 888 a time value, followed by link-layer address of any one network 889 interface that is connected to the DHCP device at the time that the 890 DUID is generated. The time value is the time that the DUID is 891 generated represented in seconds since midnight (UTC), January 1, 892 2000, modulo 2^32. The hardware type MUST be a valid hardware type 893 assigned by the IANA as described in the section on ARP in RFC 826. 894 Both the time and the hardware type are stored in network byte order. 896 The following diagram illustrates the format of a DUID based on 897 link-layer address plus time: 899 0 1 2 3 900 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 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | 1 | Hardware type (16 bits) | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Time (32 bits) | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 . . 907 . link-layer address (variable length) . 908 . . 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 The choice of network interface can be completely arbitrary, as long 912 as that interface provides a globally unique link-layer address for 913 the link type, and the same DUID should be used in configuring all 914 network interfaces connected to the device, regardless of which 915 interface's link-layer address was used to generate the DUID. 917 Clients and servers using this type of DUID MUST store the DUID 918 in stable storage, and MUST continue to use this DUID even if the 919 network interface used to generate the DUID is removed. Clients and 920 servers that do not have any stable storage MUST NOT use this type of 921 DUID. 923 Clients and servers that use this DUID SHOULD attempt to configure 924 the time prior to generating the DUID, if that is possible, and MUST 925 use some sort of time source (for example, a real-time clock) in 926 generating the DUID, even if that time source could not be configured 927 prior to generating the DUID. The use of a time source makes it 928 unlikely that two identical DUIDs will be generated if the network 929 interface is removed from the client and another client then uses 930 the same network interface to generate a DUID. A DUID collision is 931 very unlikely even if the clocks haven't been configured prior to 932 generating the DUID. 934 This method of DUID generation is recommended for all general purpose 935 computing devices such as desktop computers and laptop computers, and 936 also for devices such as printers, routers, and so on, that contain 937 some form of writable non-volatile storage. 939 Despite our best efforts, it is possible that this algorithm for 940 generating a DUID could result in a client identifier collision. A 941 DHCP client that generates a DUID using this mechanism MUST provide 942 an administrative interface that replaces the existing DUID with a 943 newly-generated DUID of this type. 945 9.3. Vendor-assigned unique ID based on Enterprise Number (VUID-EN) 947 The vendor-assigned unique ID based on Enterprise Number consists of 948 the vendor's registered Private Enterprise Number as maintained by 949 IANA [7] followed by the value of the identifier. 951 The following diagram summarizes the structure of a VUID-EN: 953 0 1 2 3 954 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 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | 3 | enterprise-number | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | enterprise-number (contd) | | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 960 . identifier . 961 . (variable length) . 962 . . 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 The source of the identifier is left up to the vendor defining it, 965 but each identifier part of each VUID-EN MUST be unique to the 966 device that is using it, and MUST be assigned to the device at 967 the time of manufacture and stored in some form of non-volatile 968 storage. The VUID SHOULD be recorded in non-erasable storage. The 969 enterprise-number is the vendor's registered Private Enterprise 970 Number as maintained by IANA [7]. The enterprise-number is stored as 971 an unsigned 32 bit number. 973 An example DUID of this type might look like this: 975 +---+---+---+---+---+---+---+---+ 976 | 0 | 3 | 0 | 0 | 0 | 9| 12|192| 977 +---+---+---+---+---+---+---+---+ 978 |132|221| 3 | 0 | 9 | 18| 979 +---+---+---+---+---+---+ 981 This example includes the two-octet type of 3, the Enterprise Number 982 (9), followed by eight octets of identifier data. 984 9.4. Link-layer address 986 This type of DUID consists of two octets containing the DUID type 4, 987 a two octet network hardware type code, followed by the link-layer 988 address of any one network interface that is permanently connected to 989 the client or server device. For example, this DUID could be used 990 by a host that has a network interface implemented in a chip that is 991 unlikely to be removed and used elsewhere. The hardware type MUST 992 be a valid hardware type assigned by the IANA as described in the 993 section on ARP in RFC 826. The hardware type is stored in network 994 byte order. 996 The following diagram illustrates the format of a DUID based on 997 link-layer address: 999 0 1 2 3 1000 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 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | 4 | Hardware type (16 bits) | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 . . 1005 . link-layer address (variable length) . 1006 . . 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 The choice of network interface can be completely arbitrary, as 1010 long as that interface provides a unique link-layer address and 1011 is permanently attached to the device on which the DUID is being 1012 generated. The same DUID should be used in configuring all network 1013 interfaces connected to the device, regardless of which interface's 1014 link-layer address was used to generate the DUID. 1016 This type of DUID is recommended for devices that have a 1017 permanently-connected network interface with a link-layer address and 1018 do not have nonvolatile, writable stable storage. This type of DUID 1019 MUST NOT be used by DHCP clients or servers that cannot tell whether 1020 or not a network interface is permanently attached to the device on 1021 which the DHCP client is running. 1023 10. Identity association 1025 An "identity-association" (IA) is a construct through which a server 1026 and a client can identify, group and manage IPv6 addresses. Each IA 1027 consists of an IAID and associated configuration information. 1029 A client must associate at least one distinct IA with each of 1030 its network interfaces and uses that IA to obtain configuration 1031 information from a server for that interface. Each IA must be 1032 associated with exactly one interface. 1034 The IAID uniquely identifies the IA and must be chosen to be unique 1035 among the IAIDs on the client. The IAID is chosen by the client. 1036 For any given use of an IA by the client, the IAID for that IA MUST 1037 be consistent across restarts of the DHCP client. The client may 1038 maintain consistency either by storing the IAID in non-volatile 1039 storage or by using an algorithm that will consistently produce the 1040 same IAID as long as the configuration of the client has not changed. 1041 There may be no way for a client to maintain consistency of the IAIDs 1042 if it does not have non-volatile storage and the client's hardware 1043 configuration changes. 1045 The configuration information in an IA consists of one or more IPv6 1046 addresses and other parameters. The parameters are specified as DHCP 1047 options within the IA, and are associated with the addresses in the 1048 IA and the interface to which the IA belongs. Other parameters that 1049 are not associated with a particular interface may be specified in 1050 the options section of a DHCP message, outside the scope of any IA. 1052 Each address in an IA has a preferred lifetime and a valid lifetime, 1053 as defined in RFC2462 [18]. The lifetimes are transmitted from the 1054 DHCP server to the client in the IA option. The lifetimes apply to 1055 the use of IPv6 addresses as described in section 5.5.4 of RFC2462. 1057 See section 22.4 for the representation of an IA in a DHCP message. 1059 11. Selecting addresses for assignment to an IA 1061 A server selects addresses to be assigned to an IA according to the 1062 address assignment policies determined by the server administrator 1063 and the specific information the server determines about the client 1064 from some combination of the following sources: 1066 - The link to which the client is attached. The server determines 1067 the link as follows: 1069 * If the server receives the message directly from the client 1070 and the source address in the IP datagram in which the 1071 message was received is a link-local address, then the client 1072 is on the same link to which the interface over which the 1073 message was received is attached 1075 * If the server receives the message from a forwarding relay 1076 agent, then the client is on the same link as the one to 1077 which the interface identified by the link-address field in 1078 the message from the relay agent is attached 1080 * If the server receives the message directly from the client 1081 and the source address in the IP datagram in which the 1082 message was received is not a link-local address, then the 1083 client is on the link identified by the source address in the 1084 IP datagram (note that this situation can occur only if the 1085 server has enabled the use of unicast message delivery by the 1086 client and the client has sent a message for which unicast 1087 delivery is allowed) 1089 - The DUID supplied by the client 1091 - Other information in options supplied by the client 1093 - Other information in options supplied by the relay agent 1095 Any unicast address assigned by a server that is based on an 1096 EUI-64 identifier MUST include an interface identifier with the "u" 1097 (universal/local) and "g" (individual/group) bits of the interface 1098 identifier set appropriately, as indicated in section 2.5.1 of RFC 1099 2373. 1101 A server MUST NOT assign an address that is otherwise reserved for 1102 some other purpose. These reserved addresses may be specified as 1103 128-bit IPv6 addresses or as interface identifiers that are reserved 1104 for all subnets. For example, a server MUST NOT assign reserved 1105 anycast addresses, as defined in RFC2526, from any subnet. 1107 12. Management of temporary addresses 1109 A client may be assigned temporary addresses (temporary addresses 1110 are defined in RFC 3041 [13]). Clients and servers simply identify 1111 addresses as "temporary". DHCPv6 handling of address assignment is 1112 no different for temporary addresses. DHCPv6 says nothing about 1113 details of temporary addresses like lifetimes, how clients use 1114 temporary addresses, rules for generating successive temporary 1115 addresses, etc. 1117 Clients ask for temporary addresses and servers assign them. 1118 Temporary addresses are carried in the Identity Association for 1119 Temporary Addresses (IA_TA) option (see section 22.5). Each IA_TA 1120 option contains at most one temporary address for each of the 1121 prefixes on the link to which the client is attached. 1123 Unless otherwise stated, an IA_TA option is used in the same way in 1124 as an IA option. In the protocol specification, unless otherwise 1125 stated, a reference to an IA should be read as either an IA or an 1126 IA_TA. 1128 The IAID number space for the IA_TA option IAID number space is 1129 separate from the IA option IAID number space. 1131 The server MAY update the DNS for a temporary address as described in 1132 section 4 of RFC3041. 1134 13. Transmission of messages by a client 1136 Unless otherwise specified, a client sends DHCP messages to the 1137 All_DHCP_Relay_Agents_and_Servers. 1139 If the client is attached to a link that supports multicast 1140 transmission, the client sends DHCP messages to the 1141 All_DHCP_Relay_Agents_and_Servers address. 1143 A client may send some messages directly to a server using unicast, 1144 as described in section 22.13. 1146 14. Reliability of Client Initiated Message Exchanges 1148 DHCP clients are responsible for reliable delivery of messages in the 1149 client-initiated message exchanges described in sections 17 and 18. 1150 If a DHCP client fails to receive an expected response from a server, 1151 the client must retransmit its message. This section describes the 1152 retransmission strategy to be used by clients in client-initiated 1153 message exchanges. 1155 Note that the procedure described in this section is slightly 1156 modified when used with the Solicit message. The modified procedure 1157 is described in section 17.1.2. 1159 The client begins the message exchange by transmitting a message to 1160 the server. The message exchange terminates when either the client 1161 successfully receives the appropriate response or responses from a 1162 server or servers, or when the message exchange is considered to have 1163 failed according to the retransmission mechanism described below. 1165 The client retransmission behavior is controlled and described by the 1166 following variables: 1168 RT Retransmission timeout 1170 IRT Initial retransmission time 1172 MRC Maximum retransmission count 1174 MRT Maximum retransmission time 1176 MRD Maximum retransmission duration 1178 RAND Randomization factor 1180 With each message transmission or retransmission, the client sets RT 1181 according to the rules given below. If RT expires before the message 1182 exchange terminates, the client recomputes RT and retransmits the 1183 message. 1185 Each of the computations of a new RT include a randomization factor 1186 (RAND), which is a random number chosen with a uniform distribution 1187 between -0.1 and +0.1. The randomization factor is included to 1188 minimize synchronization of messages transmitted by DHCP clients. 1189 The algorithm for choosing a random number does not need to be 1190 cryptographically sound. The algorithm SHOULD produce a different 1191 sequence of random numbers from each invocation of the DHCP client. 1193 RT for the first message transmission is based on IRT: 1195 RT = IRT + RAND*IRT 1197 RT for each subsequent message transmission is based on the previous 1198 value of RT: 1200 RT = 2*RTprev + RAND*RTprev 1202 MRT specifies an upper bound on the value of RT. If MRT has a value 1203 of 0, there is no upper limit on the value of RT. Otherwise: 1205 if (RT > MRT) 1206 RT = MRT + RAND*MRT 1208 MRC specifies an upper bound on the number of times a client may 1209 retransmit a message. Unless MRC is zero, the message exchange fails 1210 once the client has transmitted the message MRC times. 1212 MRD specifies an upper bound on the length of time a client may 1213 retransmit a message. Unless MRD is zero, the message exchange fails 1214 once MRD seconds have elapsed since the client first transmitted the 1215 message. 1217 If both MRC and MRD are non-zero, the message exchange fails whenever 1218 either of the conditions specified in the previous two paragraphs are 1219 met. 1221 If both MRC and MRD are zero, the client continues to transmit the 1222 message until it receives a response. 1224 15. Message validation 1226 Clients and servers SHOULD discard any messages that contain options 1227 that are not allowed to appear in the received message. For example, 1228 an Information-request message must not include an IA option. 1229 Clients and server MAY choose to extract information from such a 1230 message if the information is of use to the recipient. 1232 Message validation based on DHCP authentication is discussed in 1233 section 21.5.3. 1235 15.1. Use of Transaction-ID field 1237 The "transaction-ID" field holds a value used by clients and servers 1238 to synchronize server responses to client messages. A client SHOULD 1239 choose a different transaction-ID for each new message it sends. A 1240 client MUST leave the transaction-ID unchanged in retransmissions of 1241 a message. 1243 15.2. Solicit message 1245 Clients MUST discard any received Solicit messages. 1247 Servers MUST discard any Solicit messages that do not include a 1248 Client Identifier option or that do include a Server Identifier 1249 option. 1251 15.3. Advertise message 1253 Clients MUST discard any received Advertise messages that meet any of 1254 the following conditions: 1256 - the message does not include a Server Identifier option 1258 - the message does not include a Client Identifier option 1260 - the contents of the Client Identifier option does not match the 1261 client's DUID 1263 - the "Transaction-ID" field value does not match the value the 1264 client used in its Solicit message 1266 Servers and relay agents MUST discard any received Advertise 1267 messages. 1269 15.4. Request message 1271 Clients MUST discard any received Request messages. 1273 Servers MUST discard any received Request message that meet any of 1274 the following conditions: 1276 - the message does not include a Server Identifier option 1278 - the contents of the Server Identifier option do not match the 1279 server's identifier 1281 - the message does not include a Client Identifier option 1283 15.5. Confirm message 1285 Clients MUST discard any received Confirm messages. 1287 Servers MUST discard any Confirm messages received that do not 1288 include a Client Identifier option or that do include a Server 1289 Identifier option. 1291 15.6. Renew message 1293 Clients MUST discard any received Renew messages. 1295 Servers MUST discard any received Renew message that meets any of the 1296 following conditions: 1298 - the message does not include a Server Identifier option 1300 - the contents of the Server Identifier option do not match the 1301 server's identifier 1303 - the message does not include a Client Identifier option 1305 15.7. Rebind message 1307 Clients MUST discard any received Rebind messages. 1309 Servers MUST discard any received Rebind messages that do not include 1310 a Client Identifier option or that do include a Server Identifier 1311 option. 1313 15.8. Decline messages 1315 Clients MUST discard any received Decline messages. 1317 Servers MUST discard any received Decline message that meets any of 1318 the following conditions: 1320 - the message does not include a Server Identifier option 1322 - the contents of the Server Identifier option do not match the 1323 server's identifier 1325 - the message does not include a Client Identifier option 1327 15.9. Release message 1329 Clients MUST discard any received Release messages. 1331 Servers MUST discard any received Release message that meets any of 1332 the following conditions: 1334 - the message does not include a Server Identifier option 1336 - the contents of the Server Identifier option do not match the 1337 server's identifier 1339 - the message does not include a Client Identifier option 1341 15.10. Reply message 1343 Clients MUST discard any received Reply messages that meet any of the 1344 following conditions: 1346 - the message does not include a Server Identifier option 1348 - the "transaction-ID" field in the message does not match the 1349 value used in the original message 1351 - the message does not include a Client Identifier option and the 1352 original message from the client contained a Client Identifier 1353 option 1355 - the message includes a Client Identifier option and the contents 1356 of the Client Identifier option does not match the DUID of the 1357 client or the client did not include a Client Identifier option 1358 in the original message 1360 Servers and relay agents MUST discard any received Reply messages. 1362 15.11. Reconfigure message 1364 Servers and relay agents MUST discard any received Reconfigure 1365 messages. 1367 Clients MUST discard any Reconfigure messages that fails any of the 1368 following conditions: 1370 - the message MUST include a Server Identifier option 1372 - the message MUST include one of the available security 1373 mechanisms: 1375 * the server sends a Reconfigure Nonce option whose value 1376 matches the current server nonce value known to the client 1378 * the server uses DHCP authentication: beginitemize 1380 * the message MUST contain an authentication option 1382 * the message MUST pass the authentication validation performed 1383 by the client 1385 15.12. Information-request message 1387 Clients MUST discard any received Information-request messages. 1389 Servers MUST discard any received Information-request message that 1390 includes a Server Identifier option and the DUID in the option does 1391 not match the server's DUID. 1393 15.13. Relay-forward message 1395 Clients MUST discard any received Relay-forward messages. 1397 15.14. Relay-reply message 1399 Clients and servers MUST discard any received Relay-reply messages. 1401 16. Client Source Address and Interface Selection 1403 When a client sends a DHCP message to the 1404 All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the 1405 message through the interface for which configuration information is 1406 being requested. However, the client MAY send the message through 1407 another interface attached to the same link if and only if the client 1408 is certain the two interface are attached to the same link. In 1409 addition, the client MUST use the IPv6 link-local address assigned to 1410 the interface for which it is requesting configuration information as 1411 the source address in the header of the IP datagram. 1413 When a client sends a DHCP message directly to a server using unicast 1414 (after receiving the Server Unicast option from that server), the 1415 source address in the header of the IP datagram MUST be an address 1416 assigned to the interface for which the client is interested in 1417 obtaining configuration and which is suitable for use by the server 1418 in responding to the client. 1420 17. DHCP Server Solicitation 1422 This section describes how a client locates servers that will assign 1423 addresses to IAs belonging to the client. 1425 The client is responsible for creating IAs and requesting that a 1426 server assign configuration information, including IPv6 addresses, 1427 to the IA. The client first creates an IA and assigns it an IAID. 1428 The client then transmits a Solicit message containing an IA option 1429 describing the IA. Servers that can assign configuration information 1430 to the IA respond to the client with an Advertise message. The 1431 client then initiates a configuration exchange as described in 1432 section 18. 1434 Whenever a client initiates server solicitation with a Solicit 1435 message, it discards any reconfigure nonce values it may have 1436 previously recorded. 1438 17.1. Client Behavior 1440 A client uses the Solicit message to discover DHCP servers configured 1441 to serve addresses on the link to which the client is attached. 1443 17.1.1. Creation of Solicit messages 1445 The client sets the "msg-type" field to SOLICIT. The client generates 1446 a transaction ID and inserts this value in the "transaction-ID" 1447 field. 1449 The client MUST include a Client Identifier option to identify itself 1450 to the server. The client MUST include one or more IA options for 1451 any IAs to which it wants the server to assign addresses. The 1452 client MAY include addresses in the IAs as a hint to the server 1453 about addresses for which the client has a preference. The client 1454 MUST NOT include any other options in the Solicit message except as 1455 specifically allowed in the definition of individual options. 1457 The client uses IA options to request the assignment of non-temporary 1458 addresses and uses IA_TA options to request the assignment of 1459 temporary addresses. Either IA or IA_TA options, or a combination of 1460 both can be included in DHCP messages. 1462 The client MAY request specific options from the server by including 1463 an Option Request option (see section 22.7) as a hint about the 1464 options the client is interested in receiving. If the client 1465 requires a consistent prioritization of the options it receives, it 1466 includes an Option Request option indicating the options it needs 1467 (see section 17.2.2). The client MAY include options with data 1468 values as hints to the server about parameter values the client would 1469 like to have returned. 1471 If the client will accept a Reply message with committed address 1472 assignments and other resources in response to the Solicit message, 1473 the client includes a Rapid Commit option (see section 22.15) in the 1474 Solicit message. 1476 17.1.2. Transmission of Solicit Messages 1478 The first Solicit message from the client on the interface MUST 1479 be delayed by a random amount of time between MIN_SOL_DELAY and 1480 MAX_SOL_DELAY. In the case of a Solicit message transmitted when DHCP 1481 is initiated by IPv6 Neighbor Discovery, the delay gives the amount 1482 of time to wait after IPv6 Neighbor Discovery causes the client to 1483 invoke the stateful address autoconfiguration protocol (see section 1484 5.5.3 of RFC2462). This random delay desynchronizes clients which 1485 start at the same time (for example, after a power outage). 1487 The client transmits the message according to section 14, using the 1488 following parameters: 1490 IRT SOL_TIMEOUT 1492 MRT SOL_MAX_RT 1494 MRC 0 1496 MRD 0 1498 If the client has included a Rapid Commit option and is waiting for 1499 a Reply message, the client terminates the retransmission process 1500 as soon as a Reply message is received. If the client receives an 1501 Advertise message that includes a Preference option with a preference 1502 value of 255, the client immediately begins a client-initiated 1503 message exchange (as described in section 18) by sending a Request 1504 message to the server from which the Advertise message was received. 1505 If the client receives an Advertise message that does not include 1506 a Preference option with a preference value of 255, the client 1507 continues to wait until the first RT elapses. If the first RT 1508 elapses and the client has received an Advertise message, the client 1509 SHOULD continue with a client-initiated message exchange by sending a 1510 Request message. 1512 If the client is waiting for an Advertise message, the mechanism in 1513 section 14 is modified as follows for use in the transmission of 1514 Solicit messages. The message exchange is not terminated by the 1515 receipt of an Advertise before the first RT has elapsed. Rather, the 1516 client collects Advertise messages until the first RT has elapsed. 1517 Also, the first RT MUST be selected to be strictly greater than IRT 1518 by choosing RAND to be strictly greater than 0. 1520 A client MUST collect Advertise messages for the first RT seconds, 1521 unless it receives an Advertise message with a preference value 1522 of 255. The preference value is carried in the Preference option 1523 (section 22.8). Any Solicit that does not include a Preference 1524 option is considered to have a preference value of 0. If the client 1525 receives an Advertise message with a preference value of 255, then 1526 the client SHOULD act immediately on that Advertise message without 1527 waiting for any additional Advertise messages. 1529 If the client does not receive any Advertise messages before 1530 the first RT has elapsed, it begins the retransmission mechanism 1531 described in section 14. The client terminates the retransmission 1532 process as soon as it receives any Advertise message, and the client 1533 acts on the received Advertise message without waiting for any 1534 additional Advertise messages. 1536 A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client 1537 is configured with either MRC or MRD set to a value other than 1538 0, it MUST stop trying to configure the interface if the message 1539 exchange fails. After the DHCP client stops trying to configure the 1540 interface, it SHOULD choose to restart the reconfiguration process 1541 after some external event, such as user input, system restart, or 1542 when the client is attached to a new link. 1544 17.1.3. Receipt of Advertise messages 1546 The client MUST ignore any Advertise message that includes a Status 1547 Code option containing the value AddrUnavail, with the exception that 1548 the client MAY display the associated status message to the user. 1550 Upon receipt of one or more valid Advertise messages, the client 1551 selects one or more Advertise messages based upon the following 1552 criteria. 1554 - Those Advertise messages with the highest server preference value 1555 are preferred over all other Advertise messages. 1557 - Within a group of Advertise messages with the same server 1558 preference value, a client MAY select those servers whose 1559 Advertise messages advertise information of interest to the 1560 client. For example, the client may choose a server that 1561 returned an advertisement with configuration options of interest 1562 to the client. 1564 - The client MAY choose a less-preferred server if that server has 1565 a better set of advertised parameters, such as the available 1566 addresses advertised in IAs. 1568 Once a client has selected Advertise message(s), the client will 1569 typically store information about each server, such as server 1570 preference value, addresses advertised, when the advertisement was 1571 received, and so on. 1573 If the client needs to select an alternate server in the case that a 1574 chosen server does not respond, the client chooses the next server 1575 according to the criteria given above. 1577 17.1.4. Receipt of Reply message 1579 If the client includes a Rapid Commit option in the Solicit message, 1580 it will expect a Reply message that includes a Rapid Commit option in 1581 response. If the client receives a valid Reply message that includes 1582 a Rapid Commit option, it processes the message as described in 1583 section 18.1.6. 1585 17.2. Server Behavior 1587 A server sends an Advertise message in response to valid Solicit 1588 messages it receives to announce the availability of the server to 1589 the client. 1591 17.2.1. Receipt of Solicit messages 1593 The server determines the information about the client and its 1594 location as described in section 11 and checks its administrative 1595 policy about responding to the client. If the server is not 1596 permitted to respond to the client, the server discards the Solicit 1597 message. 1599 If the client has included a Rapid Commit option in the Solicit 1600 message and the server has been configured to respond with committed 1601 address assignments and other resources, the server responds to the 1602 Solicit with a Reply message as described in section 17.2.3. If the 1603 server has been configured to respond to the client but has not been 1604 configured to respond with committed address assignments and other 1605 resources, the server responds with an Advertise message. 1607 Otherwise, the server generates and sends an Advertise message to the 1608 client. 1610 17.2.2. Creation and transmission of Advertise messages 1612 The server sets the "msg-type" field to ADVERTISE and copies the 1613 contents of the transaction-ID field from the Solicit message 1614 received from the client to the Advertise message. The server 1615 includes its server identifier in a Server Identifier option and 1616 copies the Client Identifier from the Solicit message into the 1617 Advertise message. 1619 The server MAY add a Preference option to carry the preference value 1620 for the Advertise message. The server implementation SHOULD allow 1621 the setting of a server preference value by the administrator. 1622 The server preference value MUST default to zero unless otherwise 1623 configured by the server administrator. 1625 The server MUST include IA options in the Advertise message 1626 containing any addresses that would be assigned to IAs contained in 1627 the Solicit message from the client. 1629 If the server will not assign any addresses to IAs in a subsequent 1630 Request from the client, the server MUST send an Advertise message to 1631 the client that includes only a status code option with the status 1632 code set to AddrUnavail and a status message for the user. 1634 The server includes other options the server will return to the 1635 client in a subsequent Reply message. The server SHOULD limit the 1636 options returned to the client so that the DHCP message header and 1637 options do not cause fragmentation. The information in these options 1638 will be used by the client in the selection of a server if the client 1639 receives more than one Advertise message. If the client has included 1640 an Option Request option in the Solicit message, the server uses that 1641 option as a hint about the options the client has a preference for 1642 receiving from the server. 1644 If the Solicit message was received directly by the server, the 1645 server unicasts the Advertise message directly to the client using 1646 the address in the source address field from the IP datagram in 1647 which the Solicit message was received. The Advertise message MUST 1648 be unicast through the interface on which the Solicit message was 1649 received. 1651 If the Solicit message was received in a Relay-forward message, 1652 the server constructs a Relay-reply message with the Advertise 1653 message in the payload of a "server-message" option. If the 1654 Relay-forward messages included an Interface-id option, the server 1655 copies that option to the Relay-reply message. The server unicasts 1656 the Relay-reply message directly to the relay agent using the 1657 address in the source address field from the IP datagram in which the 1658 Relay-forward message was received. 1660 17.2.3. Creation and Transmission of Reply messages 1662 The server MUST commit the assignment of any addresses or other 1663 configuration information message before sending a Reply message to a 1664 client in response to a Solicit message. 1666 DISCUSSION: 1668 When using the Solicit-Advertise message exchange, a server 1669 need not commit the assignment of configuration information 1670 to the client or otherwise keep state about the client 1671 before the server sends the Advertise message to the client. 1672 The client will choose one of the responding servers and 1673 send a Request message to obtain configuration information. 1674 The other servers can make any addresses they might have 1675 offered to the client available for assignment to other 1676 clients. 1678 When using the Solicit-Reply message exchange, the server 1679 commits the assignment of any addresses before sending the 1680 Reply message. The client can assume it has been assigned 1681 the addresses in the Reply message and does not need to send 1682 a Request message for those addresses. 1684 Typically, servers that are configured to use the 1685 Solicit-Reply message exchange will be deployed so that only 1686 one server will respond to a Solicit message. If more than 1687 one server responds, the client will only use the addresses 1688 from one of the servers and the addresses from the other 1689 servers will be committed to the client but not used by the 1690 client. 1692 The problem of unused addresses can be minimized, for 1693 example, by designing the DHCP service so that only one 1694 server responds to the Solicit or by using relatively short 1695 lifetimes for assigned addresses. 1697 The server includes a Rapid Commit option in the Reply message to 1698 indicate that the Reply is in response to a Solicit message. 1700 The server produces the Reply message as though it had received 1701 a Request message, as described in section 18.2.1. The server 1702 transmits the Reply message as described in section 18.2.8. 1704 18. DHCP Client-Initiated Configuration Exchange 1706 A client initiates a message exchange with a server or servers 1707 to acquire or update configuration information of interest. The 1708 client may initiate the configuration exchange as part of the 1709 operating system configuration process, when requested to do 1710 so by the application layer, when required by Stateless Address 1711 Autoconfiguration or as required to extend the lifetime of an address 1712 (Rebind and Renew messages). 1714 18.1. Client Behavior 1716 A client will use Request, Confirm, Renew, Rebind and 1717 Information-request messages to acquire and confirm the 1718 validity of configuration information. The client uses the server 1719 identifier information and information about IAs from previous 1720 Advertise messages for use in constructing these messages. 1722 18.1.1. Creation and transmission of Request messages 1724 The client uses a Request message to populate IAs with addresses 1725 and obtain other configuration information. The client includes 1726 one or more IA options in the Request message, with addresses and 1727 information about the IAs that were obtained from the server in a 1728 previous Advertise message. The server then returns addresses and 1729 other information about the IAs to the client in IA options in a 1730 Reply message. 1732 The client generates a transaction ID and inserts this value in the 1733 "transaction-ID" field. 1735 The client places the identifier of the destination server in a 1736 Server Identifier option. 1738 The client MUST include a Client Identifier option to identify itself 1739 to the server. The client adds any other appropriate options, 1740 including one or more IA options (if the client is requesting that 1741 the server assign it some network addresses). 1743 The client MAY request specific options from the server by including 1744 an Option Request option (see section 22.7) as a hint about the 1745 options the client is interested in receiving. If the client 1746 requires a consistent prioritization of the options it receives, it 1747 includes an Option Request option indicating the options it needs 1748 (see section 18.2.1). The client MAY include options with data 1749 values as hints to the server about parameter values the client would 1750 like to have returned. 1752 If the client has a source address of sufficient scope that can be 1753 used by the server as a return address and the client has received 1754 a Server Unicast option (section 22.13) from the server, the client 1755 SHOULD unicast the Request message to the server. 1757 DISCUSSION: 1759 Use of multicast on a link and relay agents enables the 1760 inclusion of relay agent options in all messages sent by the 1761 client. The server should enable the use of unicast only 1762 when relay agent options will not be used. 1764 The client transmits the message according to section 14, using the 1765 following parameters: 1767 IRT REQ_TIMEOUT 1769 MRT REQ_MAX_RT 1771 MRC REQ_MAX_RC 1773 MRD 0 1775 If the message exchange fails, the client MAY choose one of the 1776 following actions: 1778 - Select another server from a list of servers known to the client; 1779 for example, servers that responded with an Advertise message 1781 - Initiate the server discovery process described in section 17 1783 - Terminate the configuration process and report failure 1785 18.1.2. Creation and transmission of Confirm messages 1787 Whenever a client may have moved to a new link, its IPv6 addresses 1788 and other configuration information may no longer be valid. Examples 1789 of times when a client may have moved to a new link include: 1791 o The client reboots 1793 o The client is physically disconnected from a wired connection 1795 o The client returns from sleep mode 1797 o The client using a wireless technology changes access points 1799 In any situation when a client may have moved to a new link, the 1800 client MUST initiate a Confirm/Reply message exchange. The client 1801 includes any IAs, along with the addresses associated with those IAs, 1802 in its Confirm message. Any responding servers will indicate the 1803 acceptability of the addresses with the status in the Reply message 1804 it returns to the client. 1806 The client sets the "msg-type" field to CONFIRM. The client generates 1807 a transaction ID and inserts this value in the "transaction-ID" 1808 field. 1810 The client MUST include a Client Identifier option to identify itself 1811 to the server. The client adds any appropriate options, including 1812 one or more IA options. The client MUST include the addresses the 1813 client currently has associated with those IAs. The client fills in 1814 the T1 and T2 fields in the IA options and the preferred-lifetime and 1815 valid-lifetime fields in the IA Address options with preferred values 1816 or 0 if the client has no preference about those values. 1818 The client MAY request specific options from the server by including 1819 an Option Request option (see section 22.7) as a hint about the 1820 options the client is interested in receiving. If the client 1821 requires a consistent prioritization of the options it receives, it 1822 includes an Option Request option indicating the options it needs 1823 (see section 18.2.2). The client MAY include options with data 1824 values as hints to the server about parameter values the client would 1825 like to have returned. 1827 When the client sends the Confirm message, it MUST use an IPv6 1828 address that the client has confirmed to be valid on the link to 1829 which it is currently attached and that is assigned to the interface 1830 for which the client is interested in obtaining configuration 1831 information as the source address in the IP header of the datagram 1832 carrying the Confirm message. 1834 The client transmits the message according to section 14, using the 1835 following parameters: 1837 IRT CNF_TIMEOUT 1839 MRT CNF_MAX_RT 1841 MRC 0 1843 MRD CNF_MAX_RD 1845 If the client receives no responses before the message transmission 1846 process as described in section 14 terminates, the client SHOULD 1847 continue to use any IP addresses, using the last known lifetimes for 1848 those addresses, and SHOULD continue to use any other previously 1849 obtained configuration parameters. 1851 18.1.3. Creation and transmission of Renew messages 1853 To extend the valid and preferred lifetimes associated with 1854 addresses, the client sends a Renew message to the server containing 1855 an IA option for the IA and its associated addresses. The server 1856 determines new lifetimes for the addresses in the IA according to the 1857 administrative configuration of the server. The server may also add 1858 new addresses to the IA. The server may remove addresses from the IA 1859 by setting the preferred and valid lifetimes of those addresses to 1860 zero. 1862 The server controls the time at which the client contacts the server 1863 to extend the lifetimes on assigned addresses through the T1 and T2 1864 parameters assigned to an IA. 1866 If T1 or T2 is set to 0 by the server, the client does not send a 1867 Renew or Rebind message, respectively, for the IA. 1869 At time T1 for an IA, the client initiates a Renew/Reply message 1870 exchange to extend the lifetimes on any addresses in the IA. The 1871 client includes an IA option with all addresses currently assigned to 1872 the IA in its Renew message. 1874 The client sets the "msg-type" field to RENEW. The client generates a 1875 transaction ID and inserts this value in the "transaction-ID" field. 1877 The client places the identifier of the destination server in a 1878 Server Identifier option. 1880 The client MUST include a Client Identifier option to identify 1881 itself to the server. The client adds any appropriate options, 1882 including one or more IA options. The client MUST include the list 1883 of addresses the client currently has associated with the IAs in the 1884 Renew message. 1886 The client MAY request specific options from the server by including 1887 an Option Request option (see section 22.7) as a hint about the 1888 options the client is interested in receiving. If the client 1889 requires a consistent prioritization of the options it receives, it 1890 includes an Option Request option indicating the options it needs 1891 (see section 18.2.3). The client MAY include options with data 1892 values as hints to the server about parameter values the client would 1893 like to have returned. 1895 If the client has a source address of sufficient scope that can be 1896 used by the server as a return address and the client has received a 1897 Server Unicast option (see section 22.13) from the server, the client 1898 SHOULD unicast the Renew message to the server. 1900 DISCUSSION: 1902 Use of multicast on a link and relay agents enables the 1903 inclusion of relay agent options in all messages sent by 1904 the client. The server MUST NOT enable the use of unicast 1905 for a client when relay agent options are required for that 1906 client. 1908 The client transmits the message according to section 14, using the 1909 following parameters: 1911 IRT REN_TIMEOUT 1913 MRT REP_MAX_RT 1915 MRC 0 1917 MRD Remaining time until T2 1919 The message exchange is terminated when time T2 is reached (see 1920 section 18.1.4), at which time the client begins a Rebind message 1921 exchange. 1923 18.1.4. Creation and transmission of Rebind messages 1925 At time T2 for an IA (which will only be reached if the server to 1926 which the Renew message was sent at time T1 has not responded), 1927 the client initiates a Rebind/Reply message exchange with any 1928 available server. The client sends the Rebind message to the 1929 All_DHCP_Relay_Agents_and_Servers multicast address. The client 1930 includes an IA option with all addresses currently assigned to the IA 1931 in its Rebind message. 1933 The client sets the "msg-type" field to REBIND. The client generates 1934 a transaction ID and inserts this value in the "transaction-ID" 1935 field. 1937 The client MUST include a Client Identifier option to identify 1938 itself to the server. The client adds any appropriate options, 1939 including one or more IA options. The client MUST include the list 1940 of addresses the client currently has associated with the IAs in the 1941 Rebind message. 1943 The client MAY request specific options from the server by including 1944 an Option Request option (see section 22.7) as a hint about the 1945 options the client is interested in receiving. If the client 1946 requires a consistent prioritization of the options it receives, it 1947 includes an Option Request option indicating the options it needs 1948 (see section 18.2.4). The client MAY include options with data 1949 values as hints to the server about parameter values the client would 1950 like to have returned. 1952 The client transmits the message according to section 14, using the 1953 following parameters: 1955 IRT REB_TIMEOUT 1957 MRT REB_MAX_RT 1959 MRC 0 1961 MRD Remaining time until valid lifetimes of all addresses have 1962 expired 1964 The mechanism in section 14 is modified as follows for use in the 1965 transmission of Rebind messages. The message exchange is terminated 1966 when the valid lifetimes of all of the addresses assigned to the 1967 IA expire (see section 10), at which time the client has several 1968 alternative actions to choose from: 1970 - The client may choose to use a Solicit message to locate a new 1971 DHCP server and send a Request for the expired IA to the new 1972 server 1974 - The client may have other addresses in other IAs, so the client 1975 may choose to discard the expired IA and use the addresses in the 1976 other IAs 1978 18.1.5. Creation and Transmission of Information-request messages 1980 The client uses an Information-request message to obtain 1981 configuration information without having addresses assigned to it. 1983 The client sets the "msg-type" field to INFORMATION-REQUEST. The 1984 client generates a transaction ID and inserts this value in the 1985 "transaction-ID" field. 1987 The client SHOULD include a Client Identifier option to identify 1988 itself to the server. If the client does not include a Client 1989 Identifier option, the server will not be able to return any 1990 client-specific options to the client, or the server may choose not 1991 to respond to the message at all. 1993 The client MAY request specific options from the server by including 1994 an Option Request option (see section 22.7) as a hint about the 1995 options the client is interested in receiving. If the client 1996 requires a consistent prioritization of the options it receives, it 1997 includes an Option Request option indicating the options it needs 1998 (see section 18.2.5). The client MAY include options with data 1999 values as hints to the server about parameter values the client would 2000 like to have returned. 2002 The client transmits the message according to section 14, using the 2003 following parameters: 2005 IRT INF_TIMEOUT 2007 MRT INF_MAX_RT 2009 MRC 0 2011 MRD 0 2013 18.1.6. Receipt of Reply message in response to a Request, Confirm, 2014 Renew, Rebind or Information-request message 2016 Upon the receipt of a valid Reply message in response to a Request, 2017 Confirm, Renew, Rebind or Information-request message, the client 2018 extracts the configuration information contained in the Reply. The 2019 client MAY choose to report any status code or message from the 2020 status code option in the Reply message. 2022 The client SHOULD perform duplicate address detection [18] on each 2023 of the addresses in any IAs it receives in the Reply message before 2024 using that address for traffic. If any of the addresses are found 2025 to be in use on the link, the client sends a Decline message to the 2026 server as described in section 18.1.9. 2028 The client records the T1 and T2 times for each IA in the Reply 2029 message. The client records any addresses included with IAs in 2030 the Reply message. The client updates the preferred and valid 2031 lifetimes for the addresses in the IA from the lifetime information 2032 in the IA option. The client leaves any addresses that the client 2033 has associated with the IA that are not included in the IA option 2034 unchanged. 2036 If the Reply was received in response to a Request, Renew or Rebind 2037 message, the client must update the information in any IA option 2038 contained in the Reply message. The client adds any new addresses 2039 from the IA option to the IA, updates lifetimes for existing 2040 addresses in the IA from the IA option and discards any addresses 2041 with a lifetime of zero in the IA option. 2043 Management of the specific configuration information is detailed in 2044 the definition of each option, in section 22. 2046 When the client receives a NotOnLink status in an IA from the server 2047 in response to a Confirm message, the client can assume it needs to 2048 send a Request to the server to obtain appropriate addresses for the 2049 IA. If the client receives any Reply messages that do not indicate 2050 a NotOnLink status, the client can use the addresses in the IA and 2051 ignore any messages that do indicate a NotOnLink status. 2053 When the client receives a NoBinding status in an IA from the server 2054 for a Renew message the client can assume it needs to send a Request 2055 to reestablish an IA with the server. 2057 When the client receives a NoBinding status in an IA from the server 2058 for a Rebind message the client can assume it needs to send a Request 2059 to reestablish an IA with the server or try another server. 2061 When the client receives an AddrUnavail status in an IA from the 2062 server for a Rebind message the client can assume it needs to send a 2063 Request to reestablish an IA with the server or try another server. 2065 18.1.7. Creation and transmission of Release messages 2067 To release one or more addresses, a client sends a Release message to 2068 the server. 2070 The client sets the "msg-type" field to RELEASE. The client generates 2071 a transaction ID and places this value in the "transaction-ID" field. 2073 The client places the identifier of the server that allocated the 2074 address(es) in a Server Identifier option. 2076 The client MUST include a Client Identifier option to identify itself 2077 to the server. The client includes options containing the IAs for 2078 the addresses it is releasing in the "options" field. The addresses 2079 to be released MUST be included in the IAs. Any addresses for the 2080 IAs the client wishes to continue to use should not be in added to 2081 the IAs. 2083 The client MUST NOT use any of the addresses if is releasing as 2084 the source address in the Release message or in any subsequently 2085 transmitted message. 2087 If the client has a source address of sufficient scope that can be 2088 used by the server as a return address and the client has received 2089 a Server Unicast option (section 22.13) from the server, the client 2090 SHOULD unicast the Release message to the server. 2092 DISCUSSION: 2094 Use of multicast on a link and relay agents enables the 2095 inclusion of relay agent options in all messages sent by 2096 the client. The server MUST NOT enable the use of unicast 2097 for a client when relay agent options are required for that 2098 client. 2100 The client SHOULD choose to guarantee the delivery of the Release 2101 message using the retransmission strategy in section 14. An example 2102 of a situation in which a client would not guarantee delivery would 2103 be when the client is powering down or restarting because of some 2104 error condition. 2106 The client transmits the message according to section 14, using the 2107 following parameters: 2109 IRT REL_TIMEOUT 2111 MRT 0 2113 MRC REL_MAX_MRC 2115 MRD 0 2117 The client MUST abandon the attempt to release addresses if the 2118 Release message exchange fails. 2120 The client MUST stop using all of the addresses being released as 2121 soon as the client begins the Release message exchange process. If 2122 addresses are released but the Reply from a DHCP server is lost, 2123 the client will retransmit the Release message, and the server may 2124 respond with a Reply indicating a status of NoBinding. Therefore, 2125 the client does not treat a Reply message with a status of NoBinding 2126 in a Release message exchange as if it indicates an error. 2128 Note that if the client fails to release the addresses, the addresses 2129 assigned to the IA will be reclaimed by the server when the lifetime 2130 of the address expires. 2132 18.1.8. Receipt of Reply message in response to a Release message 2134 Upon receipt of a valid Reply message, the client can consider the 2135 Release event successful. 2137 18.1.9. Creation and transmission of Decline messages 2139 The client sets the "msg-type" field to DECLINE. The client generates 2140 a transaction ID and places this value in the "transaction-ID" field. 2142 The client places the identifier of the server that allocated the 2143 address(es) in a Server Identifier option. 2145 The client MUST include a Client Identifier option to identify itself 2146 to the server. The client includes options containing the IAs for 2147 the addresses it is declining in the "options" field. The addresses 2148 to be declined MUST be included in the IAs. Any addresses for the 2149 IAs the client wishes to continue to use should not be in added to 2150 the IAs. 2152 The client MUST NOT use any of the addresses it is declining as 2153 the source address in the Decline message or in any subsequently 2154 transmitted message. 2156 If the client has a source address of sufficient scope that can be 2157 used by the server as a return address and the client has received 2158 a Server Unicast option (section 22.13) from the server, the client 2159 SHOULD unicast the Decline message to the server. 2161 DISCUSSION: 2163 Use of multicast on a link and relay agents enables the 2164 inclusion of relay agent options in all messages sent by 2165 the client. The server MUST NOT enable the use of unicast 2166 for a client when relay agent options are required for that 2167 client. 2169 The client transmits the message according to section 14, using the 2170 following parameters: 2172 IRT DEC_TIMEOUT 2174 MRT DEC_MAX_RT 2175 MRC DEC_MAX_RC 2177 MRD 0 2179 The client MUST abandon the attempt to decline addresses if the 2180 Decline message exchange fails. 2182 If addresses are released but the Reply from a DHCP server is lost, 2183 the client will retransmit the Decline message, and the server may 2184 respond with a Reply indicating a status of NoBinding. Therefore, 2185 the client does not treat a Reply message with a status of NoBinding 2186 in a Decline message exchange as if it indicates an error. 2188 18.1.10. Receipt of Reply message in response to a Decline message 2190 Upon receipt of a valid Reply message, the client can consider the 2191 Decline event successful. 2193 18.2. Server Behavior 2195 For this discussion, the Server is assumed to have been configured in 2196 an implementation specific manner with configuration of interest to 2197 clients. 2199 18.2.1. Receipt of Request messages 2201 When the server receives a Request message via unicast from a 2202 client to which the server has not sent a unicast option, the server 2203 discards the Request message and responds with a Reply message 2204 containing a status code option with value UseMulticast and no other 2205 options. 2207 When the server receives a Request the client is requesting the 2208 configuration of IAs by the server. The server creates the bindings 2209 for that client according to the server's policy and configuration 2210 information and records the IAs and other information about the 2211 client. 2213 The server constructs a Reply message by setting the "msg-type" field 2214 to REPLY, copying the transaction ID from the Request message into 2215 the transaction-ID field. 2217 The server MUST include a Server Identifier option containing the 2218 server's DUID and the Client Identifier option from the Request 2219 message in the Reply message. 2221 If the server finds that the prefix on one or more IP addresses in 2222 any IA in the message from the client is not a valid prefix for the 2223 link to which the client is connected, the server MUST return the IA 2224 to the client with the status field set to NotOnLink. 2226 If the server cannot assign any addresses to any of the IAs in the 2227 message from the client, the server MUST include the IAs in the Reply 2228 message with the status field set to AddrUnavail and no addresses in 2229 the IA. 2231 For any IAs to which the server can assign addresses, the server 2232 includes the IA with addresses and other configuration parameters and 2233 records the IA as a new client binding. 2235 If the server will use a reconfigure nonce value for security of 2236 Reconfigure messages, the server generates a new nonce value for the 2237 client, records the value and includes it in a Reconfigure Nonce 2238 option (see section 22.21) in the Reply message. 2240 The server includes other options containing configuration 2241 information to be returned to the client. The server SHOULD limit 2242 the options returned to the client so that the DHCP message header 2243 and options do not cause fragmentation. If the client has included 2244 an Option Request option in the Solicit message, the server uses that 2245 option as a hint about the options the client has a preference for 2246 receiving from the server. 2248 18.2.2. Receipt of Confirm messages 2250 When the server receives a Confirm message, the client is requesting 2251 confirmation that the IP addresses it will use is valid and 2252 requesting the most current configuration information for the client. 2253 The server compares the addresses in the IA Address options in the 2254 Confirm message from the client with the addresses in the binding for 2255 the client. 2257 If the server finds that the addresses in the Confirm message do not 2258 match what is in the binding for that client or the addresses in 2259 the Confirm message are not appropriate for the link from which the 2260 client sent the Confirm message, the server sends a Reply message 2261 containing a Status Code option with the value ConfNoMatch. 2263 If the server finds that the addresses in the Confirm message match 2264 the addresses in the binding for that client, and the configuration 2265 information is still valid, the server sends a Reply message 2266 containing a Status Code option with the value Success. 2268 If the server cannot determine if the information in the Confirm 2269 message is valid or invalid, the server MUST NOT send a reply to the 2270 client. For example, if the server does not have a binding for the 2271 client, but the configuration information in the Confirm message 2272 appears valid, the server does not reply. 2274 The server constructs a Reply message by setting the "msg-type" field 2275 to REPLY, copying the transaction ID from the Confirm message into 2276 the transaction-ID field. 2278 The server MUST include a Server Identifier option containing the 2279 server's DUID and the Client Identifier option from the Confirm 2280 message in the Reply message. 2282 The server includes IA options for each of the IA options in the 2283 Confirm message. The server chooses values for T1, T2 and lifetimes 2284 for each of the addresses in the IAs according to the server's 2285 configured policies. The values for T1, T2 and the lifetimes sent by 2286 the client are the client's preferences for those values. The server 2287 also includes options for any other configuration information to be 2288 sent to the client. 2290 The server includes other options containing configuration 2291 information to be returned to the client. The server SHOULD limit 2292 the options returned to the client so that the DHCP message header 2293 and options do not cause fragmentation. If the client has included 2294 an Option Request option in the Renew message, the server uses that 2295 option as a hint about the options the client has a preference for 2296 receiving from the server. 2298 The Reply message from the server MUST include a Status Code option. 2300 18.2.3. Receipt of Renew messages 2302 When the server receives a Renew message via unicast from a client to 2303 which the server has not sent a unicast option, the server discards 2304 the Renew message and responds with a Reply message containing a 2305 status code option with value UseMulticast and no other options. 2307 When the server receives a Renew and IA option from a client it 2308 locates the client's binding and verifies that the information in the 2309 IA from the client matches the information stored for that client. 2311 If the server cannot find a client entry for the IA the server 2312 returns the IA containing no addresses with status set to NoBinding 2313 in the Renew message. 2315 If the server finds that any of the addresses are no longer valid 2316 for the client, the server returns the address to the client with 2317 lifetimes of 0. 2319 If the server finds the addresses in the IA for the client then the 2320 server sends back the IA to the client with new lifetimes and T1/T2 2321 times, and includes a Status Code option with value Success. The 2322 server may choose to change the list of addresses and the lifetimes 2323 of addresses in IAs that are returned to the client. 2325 The server constructs a Reply message by setting the "msg-type" field 2326 to REPLY, copying the transaction ID from the Renew message into the 2327 transaction-ID field. 2329 The server MUST include a Server Identifier option containing the 2330 server's DUID and the Client Identifier option from the Renew message 2331 in the Reply message. 2333 18.2.4. Receipt of Rebind messages 2335 When the server receives a Rebind and IA option from a client it 2336 locates the client's binding and verifies that the information in the 2337 IA from the client matches the information stored for that client. 2339 If the server cannot find a client entry for the IA the server 2340 returns the IA containing no addresses with status set to NoBinding 2341 in the Rebind message. 2343 If the server finds that the any of the addresses are no longer valid 2344 for the client, the server returns the address to the client with 2345 lifetimes of 0. 2347 If the server finds the addresses in the IA for the client then the 2348 server SHOULD send back the IA to the client with new lifetimes and 2349 T1/T2 times. 2351 The server constructs a Reply message by setting the "msg-type" field 2352 to REPLY, copying the transaction ID from the Rebind message into the 2353 transaction-ID field. 2355 The server MUST include a Server Identifier option containing the 2356 server's DUID and the Client Identifier option from the Rebind 2357 message in the Reply message. 2359 The server includes other options containing configuration 2360 information to be returned to the client. The server SHOULD limit 2361 the options returned to the client so that the DHCP message header 2362 and options do not cause fragmentation. If the client has included 2363 an Option Request option in the Rebind message, the server uses that 2364 option as a hint about the options the client has a preference for 2365 receiving from the server. 2367 18.2.5. Receipt of Information-request messages 2369 When the server receives an Information-request message, the 2370 client is requesting configuration information that does not 2371 include the assignment of any addresses. The server determines all 2372 configuration parameters appropriate to the client, based on the 2373 server configuration policies known to the server. 2375 The server constructs a Reply message by setting the "msg-type" field 2376 to REPLY, copying the transaction ID from the Information-request 2377 message into the transaction-ID field. 2379 The server MUST include a Server Identifier option containing the 2380 server's DUID in the Reply message. If the client included a Client 2381 Identification option in the Information-request message, the server 2382 copies that option to the Reply message. 2384 The server includes options containing configuration information 2385 to be returned to the client. The server SHOULD limit the options 2386 returned to the client so that the DHCP message header and options 2387 do not cause fragmentation. If the client has included an Option 2388 Request option in the Information-request message, the server uses 2389 that option as a hint about the options the client has a preference 2390 for receiving from the server. 2392 If the Information-request message received from the client did 2393 not include a Client Identifier option, the server SHOULD respond 2394 with a Reply message containing any configuration parameters 2395 that are not determined by the client's identity. If the server 2396 chooses not to respond, the client may continue to retransmit the 2397 Information-request message indefinitely. 2399 18.2.6. Receipt of Release messages 2401 When the server receives a Release message via unicast from a 2402 client to which the server has not sent a unicast option, the server 2403 discards the Release message and responds with a Reply message 2404 containing a status code option with value UseMulticast and no other 2405 options. 2407 Upon the receipt of a valid Release message, the server examines 2408 the IAs and the addresses in the IAs for validity. If the IAs in 2409 the message are in a binding for the client and the addresses in 2410 the IAs have been assigned by the server to those IAs, the server 2411 deletes the addresses from the IAs and makes the addresses available 2412 for assignment to other clients. The server ignores addresses not 2413 assigned to the IA (though it may choose to log an error if it finds 2414 such an address). 2416 After all the addresses have been processed, the server generates a 2417 Reply message and includes a Status Code option with value Success, 2418 a Server Identifier option with the server's DUID and a Client 2419 Identifier option with the client's DUID. For each IA in the Release 2420 message for which the server has no binding information, the server 2421 adds an IA option using the IAID from the Release message and 2422 includes a Status Code option with the value NoBinding in the IA 2423 option. No other options are included in the IA option. 2425 A server may choose to retain a record of assigned addresses and IAs 2426 after the lifetimes on the addresses have expired to allow the server 2427 to reassign the previously assigned addresses to a client. 2429 18.2.7. Receipt of Decline messages 2431 When the server receives a Decline message via unicast from a 2432 client to which the server has not sent a unicast option, the server 2433 discards the Decline message and responds with a Reply message 2434 containing a status code option with value UseMulticast and no other 2435 options. 2437 Upon the receipt of a valid Decline message, the server examines the 2438 IAs and the addresses in the IAs for validity. If the IAs in the 2439 message are in a binding for the client and the addresses in the IAs 2440 have been assigned by the server to those IA, the server deletes 2441 the addresses from the IAs. The server SHOULD mark the addresses 2442 declined by the client so that those addresses are not assigned to 2443 other clients, and MAY choose to make a notification that addresses 2444 were declined. The server ignores addresses not assigned to the IA 2445 (though it may choose to log an error if it finds such an address). 2447 After all the address have been processed, the server generates a 2448 Reply message and includes a Status Code option with value Success, 2449 a Server Identifier option with the server's DUID and a Client 2450 Identifier option with the client's DUID. For each IA in the Release 2451 message for which the server has no binding information, the server 2452 adds an IA option using the IAID from the Release message and 2453 includes a Status Code option with the value NoBinding in the IA 2454 option. No other options are included in the IA option. 2456 18.2.8. Transmission of Reply messages 2458 If the original message was received directly by the server, the 2459 server unicasts the Reply message directly to the client using the 2460 address in the source address field from the IP datagram in which the 2461 original message was received. The Reply message MUST be unicast 2462 through the interface on which the original message was received. 2464 If the original message was received in a Relay-forward message, the 2465 server constructs a Relay-reply message with the Reply message in the 2466 payload of a "server-message" option. If the Relay-forward messages 2467 included an Interface-id option, the server copies that option to the 2468 Relay-reply message. The server unicasts the Relay-reply message 2469 directly to the relay agent using the address in the source address 2470 field from the IP datagram in which the Relay-forward message was 2471 received. 2473 19. DHCP Server-Initiated Configuration Exchange 2475 A server initiates a configuration exchange to cause DHCP clients 2476 to obtain new addresses and other configuration information. For 2477 example, an administrator may use a server-initiated configuration 2478 exchange when links in the DHCP domain are to be renumbered. Other 2479 examples include changes in the location of directory servers, 2480 addition of new services such as printing, and availability of new 2481 software. 2483 19.1. Server Behavior 2485 A server sends a Reconfigure message to cause a client to initiate 2486 immediately a Renew/Reply or Information-request/Reply message 2487 exchange with the server. 2489 19.1.1. Creation and transmission of Reconfigure messages 2491 The server sets the "msg-type" field to RECONFIGURE. The server sets 2492 the transaction-id field to 0. The server places its identifier in a 2493 Server Identifier option. 2495 The server MAY include an Option Request option to inform the client 2496 of what information has been changed or new information that has been 2497 added. In particular, the server specifies the IA option in the 2498 Option Request option if the server wants the client to obtain new 2499 address information. 2501 Because of the risk of denial of service attacks against DHCP 2502 clients, the use of a security mechanism is mandated in Reconfigure 2503 messages.The server MUST use one of the following two security 2504 mechanisms: 2506 - The server includes a Reconfigure Nonce option containing the 2507 reconfiugre nonce value currently assigned to the client 2509 - The server includes an authentication option in the Reconfigure 2510 message 2512 The server MUST include a Reconfigure Message option (defined in 2513 section 22.20) to select whether the client responds with a Renew 2514 message or an Information-Request message. 2516 The server MUST NOT include any other options in the Reconfigure 2517 except as specifically allowed in the definition of individual 2518 options. 2520 A server sends each Reconfigure message to a single DHCP client, 2521 using an IPv6 unicast address of sufficient scope belonging to the 2522 DHCP client. The server may obtain the address of the client through 2523 the information that the server has about clients that have been in 2524 contact with the server, or the server may be configured with the 2525 address of the client through some external agent. 2527 To reconfigure more than one client, the server unicasts a separate 2528 message to each client. The server may initiate the reconfiguration 2529 of multiple clients concurrently; for example, a server may 2530 send a Reconfigure message to additional clients while previous 2531 reconfiguration message exchanges are still in progress. 2533 The Reconfigure message causes the client to initiate a Renew/Reply 2534 or Information-request/Reply message exchange with the server. The 2535 server interprets the receipt of a Renew or Information-request 2536 message (whichever was specified in the original Reconfigure message) 2537 from the client as satisfying the Reconfigure message request. 2539 19.1.2. Time out and retransmission of Reconfigure messages 2541 If the server does not receive a Renew or Information-request message 2542 from the client in REC_TIMEOUT milliseconds, the server retransmits 2543 the Reconfigure message, doubles the RECREP_TIMEOUT value and 2544 waits again. The server continues this process until REC_MAX_R 2545 unsuccessful attempts have been made, at which point the server 2546 SHOULD abort the reconfigure process for that client. 2548 Default and initial values for REC_TIMEOUT and REC_MAX_RT are 2549 documented in section 5.5. 2551 19.1.3. Receipt of Renew messages 2553 The server generates and sends Reply message(s) to the client as 2554 described in sections 18.2.3 and 18.2.8, including options for 2555 configuration parameters. 2557 The server MAY choose to send a Reply with the IAs and other 2558 parameters to be reconfigured, even if those IAs and parameters were 2559 not requested in the Renew message from the client. 2561 19.2. Receipt of Information-request messages 2563 The server generates and sends Reply message(s) to the client as 2564 described in sections 18.2.5 and 18.2.8, including options for 2565 configuration parameters. 2567 The server MAY choose to send a Reply with the other parameters to 2568 be reconfigured, even if those parameters were not specified in the 2569 Information-request message from the client. 2571 19.3. Client Behavior 2573 A client MUST accept Reconfigure messages sent to UDP port 546 on 2574 interfaces for which it has acquired configuration information 2575 through DHCP. These messages may be sent at any time. Since the 2576 results of a reconfiguration event may affect application layer 2577 programs, the client SHOULD log these events, and MAY notify these 2578 programs of the change through an implementation-specific interface. 2580 19.3.1. Receipt of Reconfigure messages 2582 Upon receipt of a valid Reconfigure message, the client initiates a 2583 transaction with the server by sending a Reply or Information-request 2584 message. While the transaction is in progress, the client silently 2585 discards any Reconfigure messages it receives. 2587 The client responds with either a Renew message or an 2588 Information-request message as indicated by the Reconfigure 2589 Message option (as defined in section 22.20). 2591 DISCUSSION: 2593 The Reconfigure message acts as a trigger that signals the 2594 client to complete a successful message exchange. Once 2595 the client has received a Reconfigure, the client proceeds 2596 with the message exchange (retransmitting the Renew or 2597 Information-request message if necessary); the client 2598 ignores any additional Reconfigure messages (regardless 2599 of the transaction ID in the Reconfigure message) until 2600 the exchange is complete. Subsequent Reconfigure messages 2601 (again independent of the transaction ID) cause the client 2602 to initiate a new exchange. 2604 How does this mechanism work in the face of duplicated or 2605 retransmitted Reconfigure messages? Duplicate messages 2606 will be ignored because the client will begin the exchange 2607 after the receipt of the first Reconfigure. Retransmitted 2608 messages will either trigger the exchange (if the first 2609 Reconfigure was not received by the client) or will be 2610 ignored. The server can discontinue retransmission of 2611 Reconfigure messages to the client once the server receives 2612 the Renew or Information-request message from the client. 2614 It might be possible for a duplicate or retransmitted 2615 Reconfigure to be sufficiently delayed (and delivered out of 2616 order) to arrive at the client after the exchange (initiated 2617 by the original Reconfigure) has been completed. In this 2618 case, the client would initiate a redundant exchange. The 2619 likelihood of delayed and out of order delivery is small 2620 enough to be ignored. The consequence of the redundant 2621 exchange is inefficiency rather than incorrect operation. 2623 19.3.2. Creation and transmission of Renew messages 2625 When responding to a Reconfigure, the client creates and sends 2626 the Renew message in exactly the same manner as outlined in 2627 section 18.1.3, with the exception: if the server included on Option 2628 Request option specifying the IA option, the client MUST include IA 2629 options containing the addresses the client currently has assigned to 2630 ALL IAs for the interface through which the Reconfigure message was 2631 received. 2633 19.3.3. Creation and transmission of Information-request messages 2635 When responding to a Reconfigure, the client creates and sends the 2636 Information-request message in exactly the same manner as outlined in 2637 section 18.1.5, with the exception that the client includes a Server 2638 Identifier option with the identifier from the Reconfigure message to 2639 which the client is responding. 2641 19.3.4. Time out and retransmission of Renew or Information-request 2642 messages 2644 The client uses the same variables and retransmission algorithm as 2645 it does with Renew or Information-request messages generated as part 2646 of a client-initiated configuration exchange. See sections 18.1.3 2647 and 18.1.5 for details. 2649 19.3.5. Receipt of Reply messages 2651 Upon the receipt of a valid Reply message, the client extracts the 2652 contents of the "options" field, and sets (or resets) configuration 2653 parameters appropriately. The client records and updates the 2654 lifetimes for any addresses specified in IAs in the Reply message. 2656 20. Relay Agent Behavior 2658 For this discussion, the relay agent MAY be configured to use a 2659 list of server destination addresses, which MAY include unicast 2660 addresses, the All_DHCP_Servers multicast address, or other multicast 2661 addresses selected by the network administrator. If the relay agent 2662 has not been explicitly configured, it MUST use the All_DHCP_Servers 2663 multicast address as the default. 2665 20.1. Relaying of client messages 2667 When a relay agent receives a valid client message, it constructs 2668 a Relay-forward message. The relay agent places a global or 2669 site-scoped address with a prefix assigned to the link on which the 2670 client should be assigned an address in the link-address field. This 2671 address will be used by the server to determine the link from which 2672 the client should be assigned an address and other configuration 2673 information. 2675 If the relay agent cannot use the address in the link-address field 2676 to identify the interface through which the response to the client 2677 will be forwarded, the relay agent MUST include an Interface-id 2678 option (see section 22.19) in the Relay-forward message. The server 2679 will include the Interface-id option in its Relay-reply message. 2680 The relay agent fills in the link-address field as described in the 2681 previous paragraph regardless of whether the relay agent includes an 2682 Interface-id option in the Relay-forward message. 2684 The relay agent copies the source address from the IP datagram 2685 in which the message was received from the client into the 2686 client-address field in the Relay-forward message. 2688 The relay agent constructs a Client Message option (see 2689 section 22.10) that contains the entire DHCP message (excluding 2690 the IP and UDP headers) from the client in the data field of 2691 the option. The relay agent places the Client Message option 2692 along with any "relay agent-specific" options in the options 2693 field of the Relay-forward message. The relay agent sends the 2694 Relay-forward message to all the servers in the list of server 2695 destination addresses with which it has been configured or to the 2696 All_DHCP_Servers address if it has not been explicitly configured 2697 with server destination addresses. 2699 20.2. Relaying of server messages 2701 The relay agent processes any other options included in the 2702 Relay-reply message as appropriate to those options. The relay 2703 agents then discards those options. 2705 If the Relay-reply message includes a Interface-id option, the relay 2706 agent forwards the message from the server to the client on the link 2707 identified by the Interface-id option. Otherwise, the relay agent 2708 forwards the message on the link identified by the link-address 2709 field. 2711 In either case, the relay agent extracts the server message from the 2712 Server Message option (see section 22.11) and forwards the message to 2713 the address in the client-address field in the Relay-reply message. 2715 21. Authentication of DHCP messages 2717 Some network administrators may wish to provide authentication of 2718 the source and contents of DHCP messages. For example, clients may 2719 be subject to denial of service attacks through the use of bogus 2720 DHCP servers, or may simply be misconfigured due to unintentionally 2721 instantiated DHCP servers. Network administrators may wish to 2722 constrain the allocation of addresses to authorized hosts to avoid 2723 denial of service attacks in "hostile" environments where the network 2724 medium is not physically secured, such as wireless networks or 2725 college residence halls. 2727 The DHCP authentication mechanism is based on the design of 2728 authentication for DHCPv4 [5]. 2730 21.1. DHCP threat model 2732 The threat to DHCP is inherently an insider threat (assuming a 2733 properly configured network where DHCPv6 ports are blocked on the 2734 perimeter gateways of the enterprise). Regardless of the gateway 2735 configuration, however, the potential attacks by insiders and 2736 outsiders are the same. 2738 The attack specific to a DHCP client is the possibility of the 2739 establishment of a "rogue" server with the intent of providing 2740 incorrect configuration information to the client. The motivation 2741 for doing so may be to establish a "man in the middle" attack or it 2742 may be for a "denial of service" attack. 2744 There is another threat to DHCP clients from mistakenly or 2745 accidentally configured DHCP servers that answer DHCP client requests 2746 with unintentionally incorrect configuration parameters. 2748 The threat specific to a DHCP server is an invalid client 2749 masquerading as a valid client. The motivation for this may be for 2750 "theft of service", or to circumvent auditing for any number of 2751 nefarious purposes. 2753 The threat common to both the client and the server is the resource 2754 "denial of service" (DoS) attack. These attacks typically involve 2755 the exhaustion of valid addresses, or the exhaustion of CPU or 2756 network bandwidth, and are present anytime there is a shared 2757 resource. 2759 This threat model does not consider the privacy of the contents 2760 of DHCP messages to be important. DHCP is not used to exchange 2761 authentication or configuration information that must be kept secret 2762 from other networks nodes. 2764 21.2. Security of messages sent between servers and relay agents 2766 Relay agents and servers that choose to exchange messages securely 2767 use the IPsec mechanisms for IPv6 [8]. The way in which IPsec 2768 is employed by relay agents and servers is not specified in this 2769 document. 2771 21.3. Summary of DHCP authentication 2773 Authentication of DHCP messages is accomplished through the use of 2774 the Authentication option (see section 22.12). The authentication 2775 information carried in the Authentication option can be used to 2776 reliably identify the source of a DHCP message and to confirm that 2777 the contents of the DHCP message have not been tampered with. 2779 The Authentication option provides a framework for multiple 2780 authentication protocols. One such protocol is defined here. 2782 Other protocols defined in the future will be specified in separate 2783 documents. 2785 The protocol field in the Authentication option identifies the 2786 specific protocol used to generate the authentication information 2787 carried in the option. The algorithm field identifies a specific 2788 algorithm within the authentication protocol; for example, the 2789 algorithm field specifies the hash algorithm used to generate the 2790 message authentication code (MAC) in the authentication option. The 2791 replay detection method (RDM) field specifies the type of replay 2792 detection used in the replay detection field. 2794 21.4. Replay detection 2796 The Replay Detection Method (RDM) field determines the type of replay 2797 detection used in the Replay Detection field. 2799 If the RDM field contains 0x00, the replay detection field MUST 2800 be set to the value of a monotonically increasing counter. Using 2801 a counter value such as the current time of day (for example, an 2802 NTP-format timestamp [10]) can reduce the danger of replay attacks. 2803 This method MUST be supported by all protocols. 2805 21.5. Delayed authentication protocol 2807 If the protocol field is 1, the message is using the "delayed 2808 authentication" mechanism. In delayed authentication, the client 2809 requests authentication in its Solicit message and the server replies 2810 with an Advertise message that includes authentication information. 2811 This authentication information contains a nonce value generated by 2812 the source as a message authentication code (MAC) to provide message 2813 authentication and entity authentication. 2815 The use of a particular technique based on the HMAC protocol [9] 2816 using the MD5 hash [17] is defined here. 2818 21.5.1. Management issues in the delayed authentication protocol 2820 The "delayed authentication" protocol does not attempt to address 2821 situations where a client may roam from one administrative domain 2822 to another, i.e. interdomain roaming. This protocol is focused on 2823 solving the intradomain problem where the out-of-band exchange of a 2824 shared key is feasible. 2826 21.5.2. Use of the Authentication option in the delayed authentication 2827 protocol 2829 In a Solicit message, the Authentication option carries the Protocol, 2830 Algorithm and fields, but no Replay detection or Authentication 2831 information. 2833 In an Advertise, Request, Renew, Rebind, Confirm, Decline, Release 2834 or Information-request message, the Authentication option carries 2835 the Protocol, Algorithm, RDM and Replay detection fields and 2836 Authentication information. 2838 A DHCP message MUST NOT contain more than one Authentication option 2839 when using the delayed authentication protocol. 2841 The format of the Authentication information is: 2843 0 1 2 3 2844 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 2845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2846 | Key ID | 2847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2848 | | 2849 | HMAC-MD5 | 2850 | (128 bits) | 2851 | | 2852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2854 The following definitions will be used in the description of the 2855 authentication information for delayed authentication, algorithm 1: 2857 Replay Detection - as defined by the RDM field 2858 K - a key (secret value) shared 2859 between the source and 2860 destination of the message; 2861 each key has a unique 2862 identifier (key ID) 2863 key ID - the unique identifier for the key value 2864 used to generate the MAC for this message 2865 HMAC-MD5 - the MAC generating function. 2867 The sender computes the MAC using the HMAC generation algorithm [9] 2868 and the MD5 hash function [17]. The entire DHCP message (setting 2869 the MAC field to zero), including the DHCP message header and the 2870 options field, is used as input to the HMAC-MD5 computation function. 2871 The 'key ID' field MUST be set to the identifier of the key used to 2872 generate the MAC. 2874 DISCUSSION: 2876 Algorithm 1 specifies the use of HMAC-MD5. Use of a 2877 different technique, such as HMAC-SHA, will be specified as 2878 a separate protocol. 2880 Delayed authentication requires a shared secret key for each 2881 client on each DHCP server with which that client may wish 2882 to use the DHCP protocol. Each key has a unique identifier 2883 that can be used by a receiver to determine which key was 2884 used to generate the MAC in the DHCP message. Therefore, 2885 delayed authentication may not scale well in an architecture 2886 in which a DHCP client connects to multiple administrative 2887 domains. 2889 21.5.3. Message validation 2891 To validate an incoming message, the receiver first checks that 2892 the value in the replay detection field is acceptable according to 2893 the replay detection method specified by the RDM field. Next, the 2894 receiver computes the MAC as described in [9]. The entire DHCP 2895 message (except the MAC field of the authentication option itself), 2896 is used as input to the HMAC-MD5 computation function. If the MAC 2897 computed by the receiver does not match the MAC contained in the 2898 authentication option, the receiver MUST discard the DHCP message. 2900 21.5.4. Key utilization 2902 Each DHCP client has a key, K. The server uses the client's DUID to 2903 identify the client's key. The client uses its key to encode any 2904 messages it sends to the server and to authenticate and verify any 2905 messages it receives from the server. The client's key is initially 2906 distributed to the client through some out-of-band mechanism, and 2907 is stored locally on the client for use in all authenticated DHCP 2908 messages. Once the client has been given its key, it uses that key 2909 for all transactions even if the client's configuration changes; for 2910 example, if the client is assigned a new network address. 2912 Each DHCP server knows, or be able to obtain in a secure manner, 2913 the keys for all authorized clients. If all clients use the same 2914 key, clients can perform both entity and message authentication for 2915 all messages received from servers. However, the sharing of keys 2916 is strongly discouraged as it allows for unauthorized clients to 2917 masquerade as authorized clients by obtaining a copy of the shared 2918 key and allows for trivial spoofing of an authenticated DHCP server. 2919 To authenticate the identity of individual clients, each client must 2920 be configured with a unique key and a key ID for that key. 2922 21.5.5. Client considerations for delayed authentication protocol 2924 21.5.5.1. Sending Solicit messages 2926 When the client sends a Solicit message and wishes to use 2927 authentication, it includes an Authentication option with the desired 2928 protocol, algorithm and RDM as described in section 21.5. The client 2929 does not include any replay detection or authentication information 2930 in the Authentication option. 2932 21.5.5.2. Receiving Advertise messages 2934 The client validates any Advertise messages containing an 2935 Authentication option specifying the delayed authentication protocol 2936 using the validation test described in section 21.5.3. 2938 Client behavior if no Advertise messages include authentication 2939 information or pass the validation test is controlled by local policy 2940 on the client. According to client policy, the client MAY choose to 2941 respond to a Advertise message that has not been authenticated. 2943 The decision to set local policy to accept unauthenticated messages 2944 should be made with care. Accepting an unauthenticated Advertise 2945 message can make the client vulnerable to spoofing and other 2946 attacks. If local users are not explicitly informed that the client 2947 has accepted an unauthenticated Advertise message, the users may 2948 incorrectly assume that the client has received an authenticated 2949 address and is not subject to DHCP attacks through unauthenticated 2950 messages. 2952 A client MUST be configurable to discard unauthenticated messages, 2953 and SHOULD be configured by default to discard unauthenticated 2954 messages if the client has been configured with an authentication 2955 key or other authentication information. A client MAY choose to 2956 differentiate between Advertise messages with no authentication 2957 information and Advertise messages that do not pass the validation 2958 test; for example, a client might accept the former and discard the 2959 latter. If a client does accept an unauthenticated message, the 2960 client SHOULD inform any local users and SHOULD log the event. 2962 21.5.5.3. Sending Request, Confirm, Renew, Rebind, Decline or Release 2963 messages 2965 If the client authenticated the Advertise message through which the 2966 client selected the server, the client MUST generate authentication 2967 information for subsequent Request, Confirm, Renew, Rebind or Release 2968 messages sent to the server as described in section 21.5. When the 2969 client sends a subsequent message, it MUST use the same key used by 2970 the server to generate the authentication information. 2972 21.5.5.4. Sending Information-request messages 2974 If the server has selected a key for the client in a previous message 2975 exchange (see section 21.5.6.1, the client MUST use the same key 2976 to generate the authentication information. If the client has not 2977 previously been given a key with the server, the client MUST use 2978 a key that has been selected for the client through some external 2979 mechanism. 2981 21.5.5.5. Receiving Reply messages 2983 If the client authenticated the Advertise it accepted, the client 2984 MUST validate the associated Reply message from the server. The 2985 client MUST discard the Reply if the message fails to pass validation 2986 and MAY log the validation failure. If the Reply fails to pass 2987 validation, the client MUST restart the DHCP configuration process by 2988 sending a Solicit message. 2990 If the client accepted an Advertise message that did not include 2991 authentication information or did not pass the validation test, the 2992 client MAY accept an unauthenticated Reply message from the server. 2994 21.5.5.6. Receiving Reconfigure messages 2996 The client MUST discard the Reconfigure if the message fails to pass 2997 validation and MAY log the validation failure. 2999 21.5.6. Server considerations for delayed authentication protocol 3001 21.5.6.1. Receiving Solicit messages and Sending Advertise messages 3003 The server selects a key for the client and includes authentication 3004 information in the Advertise message returned to the client as 3005 specified in section 21.5. The server MUST record the identifier of 3006 the key selected for the client and use that same key for validating 3007 subsequent messages with the client. 3009 21.5.6.2. Receiving Request, Confirm, Renew, Rebind or Release messages 3010 and Sending Reply messages 3012 The server uses the key identified in the message and validates the 3013 message as specified in section 21.5.3. If the message fails to pass 3014 validation or the server does not know the key identified by the 'key 3015 ID' field, the server MUST discard the message and MAY choose to log 3016 the validation failure. 3018 If the message passes the validation procedure, the server responds 3019 to the specific message as described in section 18.2. The server 3020 MUST include authentication information generated using the key 3021 identified in the received message as specified in section 21.5. 3023 21.5.6.3. Sending Reconfigure messages 3025 The server MUST include an Authentication option in a Reconfigure 3026 message, generated as specified in section 21.5 using the key the 3027 server initially selected for the client to which the Reconfigure 3028 message is to be sent. 3030 If the server has not previously selected a key for the client, the 3031 server MUST use a key that has been selected for the client through 3032 some external mechanism. 3034 22. DHCP options 3036 Options are used to carry additional information and parameters 3037 in DHCP messages. Every option shares a common base format, as 3038 described in section 22.1. All values in options are represented in 3039 network byte order. 3041 This document describes the DHCP options defined as part of the base 3042 DHCP specification. Other options may be defined in the future in 3043 separate documents. 3045 Unless otherwise noted, each option may appear only in the options 3046 area of a DHCP message and may appear only once. If an option does 3047 appear multiple times, each instance is considered separate and the 3048 data areas of the options MUST NOT be concatenated or otherwise 3049 combined. 3051 22.1. Format of DHCP options 3053 0 1 2 3 3054 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 3055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3056 | option-code | option-len | 3057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3058 | option-data | 3059 | (option-len octets) | 3060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3062 option-code An unsigned integer identifying the specific option 3063 type carried in this option. 3065 option-len An unsigned integer giving the length of the 3066 option-data field in this option in octets. 3068 option-data The data for the option; the format of this data 3069 depends on the definition of the option. 3071 DHCPv6 options are scoped by using encapsulation. Some options apply 3072 generally to the client, some are specific to an IA, and some are 3073 specific to the addresses within an IA. These latter two cases are 3074 discussed in sections 22.4 and 22.6. 3076 22.2. Client Identifier option 3078 The Client Identifier option is used to carry a DUID identifying 3079 a client between a client and a server. The format of the Client 3080 Identifier option is: 3082 0 1 2 3 3083 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 3084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3085 | OPTION_CLIENTID | option-len | 3086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3087 . . 3088 . DUID . 3089 . (variable length) . 3090 . . 3091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3093 option-code OPTION_CLIENTID (1) 3095 option-len Length of DUID in octets 3097 DUID The DUID for the client 3099 22.3. Server Identifier option 3101 The Server Identifier option is used to carry a DUID identifying 3102 a server between a client and a server. The format of the Server 3103 Identifier option is: 3105 0 1 2 3 3106 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 3107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3108 | OPTION_SERVERID | option-len | 3109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3110 . . 3111 . DUID . 3112 . (variable length) . 3113 . . 3114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3115 option-code OPTION_SERVERID (2) 3117 option-len Length of DUID in octets 3119 DUID The DUID for the server 3121 A server MUST process any message it receives that contains a Server 3122 Identifier option with a DUID that matches the server's DUID. 3124 22.4. Identity Association option 3126 The Identity Association option (IA option) is used to carry an 3127 identity association, the parameters associated with the IA and the 3128 addresses associated with the IA. 3130 Addresses appearing in an IA option are not temporary addresses (see 3131 section 22.5). 3133 The format of the IA option is: 3135 0 1 2 3 3136 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 3137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3138 | OPTION_IA | option-len | 3139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3140 | IAID (4 octets) | 3141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3142 | T1 | 3143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3144 | T2 | 3145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3146 | | 3147 . IA-options . 3148 . . 3149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3151 option-code OPTION_IA (3) 3153 option-len 12 + length of IA-options field 3155 IAID The unique identifier for this IA; the IAID 3156 must be unique among the identifiers for all 3157 of this client's IAs. The number space for 3158 IA IAIDs is separate from the number space 3159 for IA_TA IAIDs. 3161 T1 The time at which the client contacts the 3162 server from which the addresses in the IA 3163 were obtained to extend the lifetimes of 3164 the addresses assigned to the IA; T1 is a 3165 time duration relative to the current time 3166 expressed in units of seconds 3168 T2 The time at which the client contacts any 3169 available server to extend the lifetimes of 3170 the addresses assigned to the IA; T2 is a 3171 time duration relative to the current time 3172 expressed in units of seconds 3174 IA-options Options associated with this IA. 3176 The IA-options field encapsulates those options that are specific 3177 to this IA. For example, all of the IA Address Options carrying the 3178 addresses associated with this IA are in the IA-options field. 3180 An IA option may only appear in the options area of a DHCP message. 3181 A DHCP message may contain multiple IA options. 3183 The status of any operations involving this IA is indicated in a 3184 Status Code option in the IA-options field. 3186 Note that an IA has no explicit "lifetime" or "lease length" of its 3187 own. When the valid lifetimes of all of the addresses in an IA 3188 have expired, the IA can be considered as having expired. T1 and 3189 T2 are included to give servers explicit control over when a client 3190 recontacts the server about a specific IA. 3192 In a message sent by a client to a server, values in the T1 and 3193 T2 fields indicate the client's preference for those parameters. 3194 The client may send 0 if it has no preference for T1 and T2. In a 3195 message sent by a server to a client, the client MUST use the values 3196 in the T1 and T2 fields for the T1 and T2 parameters. The values in 3197 the T1 and T2 fields are the number of seconds until T1 and T2. 3199 The server selects the T1 and T2 times to allow the client to extend 3200 the lifetimes of any addresses in the IA before the lifetimes expire, 3201 even if the server is unavailable for some short period of time. 3202 Recommended values for T1 and T2 are .5 and .8 times the shortest 3203 preferred lifetime of the addresses in the IA, respectively. If the 3204 server does not intend for a client to extend the lifetimes of the 3205 addresses in an IA, the server sets T1 and T2 to 0. 3207 T1 is the time at which the client begins the lifetime extension 3208 process by sending a Renew message to the server that originally 3209 assigned the addresses to the IA. T2 is the time at which the client 3210 starts sending a Rebind message to any server. 3212 T1 and T2 are specified as unsigned integers that specify the time 3213 in seconds relative to the time at which the messages containing the 3214 option is received. 3216 22.5. Identity Association for Temporary Addresses option 3218 The Identity Association for Temporary Addresses (IA_TA) option is 3219 used to carry an IA, the parameters associated with the IA and the 3220 addresses associated with the IA. All of the addresses in this option 3221 are used by the client as temporary addresses, as defined in RFC 3222 3041. 3224 The format of the IA_TA option is: 3226 0 1 2 3 3227 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 3228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3229 | OPTION_IA_TA | option-len | 3230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3231 | IAID (4 octets) | 3232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3233 | | 3234 . IA-options . 3235 . . 3236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3238 option-code OPTION_IA_TA (4) 3240 option-len 4 + length of IA-options field 3242 IAID The unique identifier for this IA; the IAID 3243 must be unique among the identifiers for all 3244 of this client's IAs. The number space for 3245 IA_TA IAIDs is separate from the number space 3246 for IA IAIDs. 3248 IA-options Options associated with this IA. 3250 The IA-Options field encapsulates those options that are specific 3251 to this IA. For example, all of the IA Address Options carrying the 3252 addresses associated with this IA are in the IA-options field. 3254 Each IA_TA carries one "set" of temporary addresses; that is, at most 3255 one address from each prefix assigned to the link to which the client 3256 is attached. 3258 An IA_TA option may only appear in the options area of a DHCP 3259 message. A DHCP message may contain multiple IA_TA options. 3261 The status of any operations involving this IA is indicated in a 3262 Status Code option in the IA-options field. 3264 Note that an IA has no explicit "lifetime" or "lease length" of its 3265 own. When the valid lifetimes of all of the addresses in an IA have 3266 expired, the IA can be considered as having expired. 3268 An IA_TA option does not include values for T1 and T2. A client 3269 MAY request that the lifetimes on temporary addresses be extended 3270 by including the addresses in a IA_TA option sent in a Renew or 3271 Rebind message to a server. For example, a client would request 3272 an extension on the lifetime of a temporary address to allow an 3273 application to continue to use an established TCP connection. 3275 The client obtains new temporary addresses by sending an IA_TA option 3276 with a new IAID to a server. Requesting new temporary addresses from 3277 the server is the equivalent of generating new temporary addresses 3278 as described in RFC 3041. The server will generate new temporary 3279 addresses and return them to the client. The client should request 3280 new temporary addresses before the lifetimes on the previously 3281 assigned addresses expire. 3283 A server MUST return the same set of temporary address for the same 3284 IA_TA (as identified by the IAID) as long as those addresses are 3285 still valid. After the lifetimes of the addresses in an IA_TA have 3286 expired, the IAID may be reused to identify a new IA_TA with new 3287 temporary addresses. 3289 This option MAY appear in a Confirm message if the lifetimes on the 3290 temporary addresses in the associated IA have not expired. 3292 22.6. IA Address option 3294 The IA Address option is used to specify IPv6 addresses associated 3295 with an IA. The IA Address option must be encapsulated in the 3296 Options field of an Identity Association option. The Options field 3297 encapsulates those options that are specific to this address. 3299 The format of the IA Address option is: 3301 0 1 2 3 3302 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 3303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3304 | OPTION_IAADDR | option-len | 3305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3306 | | 3307 | IPv6 address | 3308 | | 3309 | | 3310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3311 | preferred-lifetime | 3312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3313 | valid-lifetime | 3314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3315 . . 3316 . IAaddr-options . 3317 . . 3318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3319 option-code OPTION_IADDR (5) 3321 option-len 24 + length of IAaddr-options field 3323 IPv6 address An IPv6 address 3325 preferred-lifetime The preferred lifetime for the IPv6 address in 3326 the option, expressed in units of seconds 3328 valid-lifetime The valid lifetime for the IPv6 address in the 3329 option, expressed in units of seconds 3331 IAaddr-options Options associated with this address 3333 In a message sent by a client to a server, values in the preferred 3334 and valid lifetime fields indicate the client's preference for those 3335 parameters. The client may send 0 if it has no preference for the 3336 preferred and valid lifetimes. In a message sent by a server to a 3337 client, the client MUST use the values in the preferred and valid 3338 lifetime fields for the preferred and valid lifetimes. The values in 3339 the preferred and valid lifetimes are the number of seconds remaining 3340 in each lifetime. 3342 An IA Address option may appear only in an IA option or an IA_TA 3343 option. More than one IA Address Options can appear in an IA option 3344 or an IA_TA option. 3346 The status of any operations involving this IA Address is indicated 3347 in a Status Code option in the IAaddr-options field. 3349 22.7. Option Request option 3351 The Option Request option is used to identify a list of options in a 3352 message between a client and a server. 3354 The format of the Option Request option is: 3356 0 1 2 3 3357 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 3358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3359 | OPTION_ORO | option-len | 3360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3361 | requested-option-code-1 | requested-option-code-2 | 3362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3363 | ... | 3364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3365 option-code OPTION_ORO (6) 3367 option-len 2 * number of requested options 3369 requested-option-code-n The option code for an option requested by 3370 the client. 3372 A client MAY include an Option Request option in a Solicit, Request, 3373 Renew, Rebind, Confirm or Information-request message to inform 3374 the server about options the client wants the server to send to 3375 the client. A server MAY include an Option Request option in a 3376 Reconfigure option to indicate which options the client should 3377 request from the server. 3379 22.8. Preference option 3381 0 1 2 3 3382 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 3383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3384 | OPTION_PREFERENCE | option-len | 3385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3386 | pref-value | 3387 +-+-+-+-+-+-+-+-+ 3389 option-code OPTION_PREFERENCE (7) 3391 option-len 1. 3393 pref-value The preference value for the server in this message. 3395 A server MAY include a Preference option in an Advertise message to 3396 control the selection of a server by the client. See section 17.1.3 3397 for the use of the Preference option by the client and the 3398 interpretation of Preference option data value. 3400 22.9. Elapsed Time 3402 0 1 2 3 3403 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 3404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3405 | OPTION_ELAPSED_TIME | option-len | 3406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3407 | elapsed-time | 3408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3410 option-code OPTION_ELAPSED_TIME (8) 3412 option-len 2. 3414 elapsed-time The amount of time since the client began its 3415 current DHCP transaction. This time is expressed in 3416 hundredths of a second (10^-2 seconds). 3418 A client MUST include an Elapsed Time option in messages to indicate 3419 how long the client has been trying to complete a DHCP transaction. 3420 Servers and Relay Agents use the data value in this option as input 3421 to policy controlling how a server responds to a client message. 3422 For example, the elapsed time option allows a secondary DHCP server 3423 to respond to a request when a primary server hasn't answered in a 3424 reasonable time. 3426 22.10. Client message option 3428 0 1 2 3 3429 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 3430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3431 | OPTION_CLIENT_MSG | option-len | 3432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3433 | | 3434 . DHCP-client-message . 3435 . . 3436 . . 3437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3439 option-code OPTION_CLIENT_MSG (9) 3441 option-len Length of DHCP client message. 3443 DHCP-client-message The message received from the client; 3444 forwarded verbatim to the server. 3446 A relay agent forwards a message from a client to a server as the 3447 contents of a Client Message option in a Relay-forward message. 3449 22.11. Server message option 3451 0 1 2 3 3452 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 3453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3454 | OPTION_SERVER_MSG | option-len | 3455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3456 | | 3457 . DHCP-server-message . 3458 . . 3459 . . 3460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3461 option-code OPTION_SERVER_MSG (10) 3463 option-len Length of DHCP server message. 3465 DHCP-server-message The message received from the server; 3466 forwarded verbatim to the client. 3468 A server sends a DHCP message to be forwarded to a client by a relay 3469 agent as the contents of a Server Message option in a Relay-reply 3470 message. 3472 22.12. Authentication option 3474 The Authentication option carries authentication information to 3475 authenticate the identity and contents of DHCP messages. The use of 3476 the Authentication option is described in section 21. 3478 The format of the Authentication option is: 3480 0 1 2 3 3481 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 3482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3483 | OPTION_AUTH | option-len | 3484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3485 | Protocol | Algorithm | RDM | | 3486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3487 | | 3488 | Replay Detection (64 bits) +-+-+-+-+-+-+-+-+ 3489 | | Auth. Info | 3490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3491 . . 3492 . Authentication Information . 3493 . (variable length) . 3494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3496 option-code OPTION_AUTH (11) 3498 option-len 15 + length of Authentication 3499 Information field 3501 protocol The authentication protocol used in 3502 this authentication option 3504 algorithm The algorithm used in the 3505 authentication protocol 3507 RDM The replay detection method used in 3508 this authentication option 3510 Replay detection The replay detection information for 3511 the RDM 3513 Authentication information The authentication information, 3514 as specified by the protocol and 3515 algorithm used in this authentication 3516 option 3518 22.13. Server unicast option 3520 The server sends this option to a client to indicate to the client 3521 that it is allowed to unicast messages to the server. The server 3522 specifies the IPv6 address to which the client is to send unicast 3523 messages in the server-address field. When a client receives this 3524 option, where permissible and appropriate, the client sends messages 3525 directly to the server using the IPv6 address specified in the 3526 server-address field of the option. 3528 Details about when the client may send messages to the server using 3529 unicast are in section 18. 3531 0 1 2 3 3532 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 3533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3534 | OPTION_UNICAST | option-len | 3535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3536 | | 3537 | server-address | 3538 | | 3539 | | 3540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3542 option-code OPTION_UNICAST (12) 3544 option-len 16 3546 server-address The IP address to which the client should send 3547 messages delivered using unicast 3549 22.14. Status Code Option 3551 This option returns a status indication related to the DHCP message 3552 or option in which it appears. 3554 0 1 2 3 3555 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 3556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3557 | OPTION_STATUS_CODE | option-len | 3558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3559 | status-code | | 3560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3561 . . 3562 . status-message . 3563 . . 3564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3566 option-code OPTION_STATUS_CODE (13) 3568 option-len 2 + length of status-message 3570 status-code The numeric code for the status encoded in 3571 this option. The status codes are defined in 3572 section 24.4. 3574 status-message A UTF-8 encoded text string, which MUST NOT 3575 be null-terminated. 3577 A Status Code option may appear in a DHCP message option, or in the 3578 options area of another option. If the Status Code option does not 3579 appear in a message in which the option could appear, the status of 3580 the message is assumed to be Success. 3582 22.15. Rapid Commit option 3584 A client MAY include this option in a Solicit message if the client 3585 is prepared to perform the Solicit-Reply message exchange described 3586 in section 17.1.1. 3588 A server MUST include this option in a Reply message sent in response 3589 to a Solicit message when completing the Solicit-Reply message 3590 exchange. 3592 0 1 2 3 3593 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 3594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3595 | OPTION_RAPID_COMMIT | 0 | 3596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3598 option-code OPTION_RAPID_COMMIT (14) 3600 option-len 0 3602 DISCUSSION: 3604 Each server that responds with a Reply to a Solicit that 3605 includes a Rapid Commit option will commit the assigned 3606 addresses in the Reply message to the client, and will not 3607 receive any confirmation that the client has received the 3608 Reply message. Therefore, if more than one server responds 3609 to a Solicit that includes a Rapid Commit option, some 3610 servers will commit addresses that are not actually used by 3611 the client. 3613 The problem of unused addresses can be minimized, for 3614 example, by designing the DHCP service so that only one 3615 server responds to the Solicit or by using relatively short 3616 lifetimes for assigned addresses. 3618 22.16. User Class Option 3620 This option is used by a client to identify the type or category of 3621 user or applications it represents. The information contained in the 3622 data area of this option is contained in one or more opaque fields 3623 that represent the user class or classes of which the client is a 3624 member. A server selects configuration information for the client 3625 based on the classes identified in this option. For example, the 3626 User Class option can be used to configure all clients of people 3627 in the accounting department with a different printer than clients 3628 of people in the marketing department. The user class information 3629 carried in this option MUST be configurable on the client. 3631 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 3632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3633 | OPTION_USER_CLASS | option-len | 3634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3635 . . 3636 . user-class-data . 3637 . . 3638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3640 option-code OPTION_USER_CLASS (15) 3642 option-len Length of user class data field 3644 user-class-data The user classes carried by the client. 3646 The data area of the user class option MUST contain one or more 3647 instances of user class data. Each instance of the user class data 3648 is formatted as follows: 3650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 3651 | user-class-len | opaque-data | 3652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 3654 The user-class-len is two octets long and specifies the length of the 3655 opaque user class data in network byte order. 3657 A server interprets the classes identified in this option according 3658 to its configuration to select the appropriate configuration 3659 information for the client. A server may use only those user 3660 classes that it is configured to interpret in selecting configuration 3661 information for a client and ignore any other user classes. In 3662 response to a message containing a User Class option, a server 3663 includes a User Class option containing those classes that were 3664 successfully interpreted by the server, so that the client can be 3665 informed of the classes interpreted by the server. 3667 22.17. Vendor Class Option 3669 This option is used by a client to identify the vendor that 3670 manufactured the hardware on which the client is running. The 3671 information contained in the data area of this option is contained 3672 in one or more opaque fields that identify details of the hardware 3673 configuration. 3675 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 3676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3677 | OPTION_VENDOR_CLASS | option-len | 3678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3679 | enterprise-number | 3680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3681 . . 3682 . vendor-class-data . 3683 . . . . . 3684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3686 option-code OPTION_VENDOR_CLASS (16) 3688 option-len 4 + length of vendor class data field 3690 enterprise-number The vendor's registered Enterprise Number as 3691 registered with IANA. 3693 vendor-class-data The hardware configuration of the host on 3694 which the client is running. 3696 The vendor-class-data is composed of a series of separate items, 3697 each of which describes some characteristic of the client's hardware 3698 configuration. Examples of vendor-class-data instances might include 3699 the version of the operating system the client is running or the 3700 amount of memory installed on the client. 3702 Each instance of the vendor-class-data is formatted as follows: 3704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 3705 | vendor-class-len | opaque-data | 3706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 3708 The vendor-class-len is two octets long and specifies the length of 3709 the opaque vendor class data in network byte order. 3711 22.18. Vendor-specific Information option 3713 This option is used by clients and servers to exchange 3714 vendor-specific information. The definition of this information is 3715 vendor specific. The vendor is indicated in the enterprise-number 3716 field. Clients that do not receive desired vendor-specific 3717 information SHOULD make an attempt to operate without it, although 3718 they may do so (and announce they are doing so) in a degraded mode. 3720 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 3721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3722 | OPTION_VENDOR_OPTS | option-len | 3723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3724 | enterprise-number | 3725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3726 . . 3727 . option-data . 3728 . . 3729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3731 option-code OPTION_VENDOR_OPTS (17) 3733 option-len 4 + length of option-data field 3735 enterprise-number The vendor's registered Enterprise Number as 3736 registered with IANA. 3738 option-data An opaque object of option-len octets, 3739 interpreted by vendor-specific code on the 3740 clients and servers 3742 The encapsulated vendor-specific options field MUST be encoded as a 3743 sequence of code/length/value fields of identical format to the DHCP 3744 options field. The option codes are defined by the vendor identified 3745 in the enterprise-number field and are not managed by IANA. 3747 Each of the encapsulated options is formatted as follows. 3749 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 3750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3751 | opt-code | option-len | 3752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3753 . . 3754 . option-data . 3755 . . 3756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3758 opt-code The code for the encapsulated option 3760 option-len An unsigned integer giving the length of the 3761 option-data field in this encapsulated option 3762 in octets. 3764 option-data The data area for the encapsulated option 3766 Multiple instances of the Vendor-specific Information option may 3767 appear in a DHCP message. Each instance of the option is interpreted 3768 according to the option codes defined by the vendor identified by the 3769 Enterprise Number in that option. A DHCP message MUST NOT contain 3770 more than one Vendor-specific Information option with the same 3771 Enterprise Number. 3773 22.19. Interface-Id Option 3775 The relay agent MAY send the Interface-id option to identify the 3776 interface on which the client message was received. If a relay agent 3777 receives a Relay-reply message with an Interface-id option, the 3778 relay agent forwards the message to the client through the interface 3779 identified by the option. 3781 0 1 2 3 3782 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 3783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3784 | OPTION_INTERFACE_ID | option-len | 3785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3786 . . 3787 . interface-id . 3788 . . 3789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3791 option-code OPTION_INTERFACE_ID (18) 3793 option-len Length of interface-id field 3794 interface-id An opaque value of arbitrary length generated 3795 by the relay agent to identify one of the 3796 relay agent's interfaces 3798 The server MUST copy the Interface-Id option from the Relay-Forward 3799 message into the Relay-Reply message the server sends to the relay 3800 agent in response to the Relay-Forward message. This option MUST NOT 3801 appear in any message except a Relay-Forward or Relay-Reply message. 3803 Servers MAY use the Interface-ID for parameter assignment policies. 3804 The Interface-ID SHOULD be considered an opaque value, with policies 3805 based on exact string match only; that is, the Interface-ID SHOULD 3806 NOT be internally parsed by the server. The Interface-ID value for 3807 an interface SHOULD be stable and remain unchanged, for example, 3808 after the relay agent is restarted; if the Interface-ID changes, a 3809 server will not be able to use it reliably in parameter assignment 3810 policies. 3812 22.20. Reconfigure Message option 3814 A server includes a Reconfigure Message option in a Reconfigure 3815 message to indicate to the client whether the client responds with a 3816 Renew message or an Information-request message. 3818 0 1 2 3 3819 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 3820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3821 | OPTION_RECONF_MSG | option-len | 3822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3823 | msg-type | 3824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3826 option-code OPTION_RECONF_MSG (19) 3828 option-len 1 3830 msg-type 1 for Renew message, 2 for 3831 Information-request message 3833 22.21. Reconfigure Nonce option 3835 If a server uses a reconfigure nonce to provide security for 3836 Reconfigure messages, the server maintains a nonce value for each 3837 client. It initially informs the client of the nonce value and then 3838 includes the nonce value in any Reconfigure message sent to the 3839 client. 3841 The following figure gives the format of the Reconfigure Nonce 3842 option: 3844 0 1 2 3 3845 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 3846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3847 | OPTION_RECONF_NONCE | option-len | 3848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3849 | reconfigure-nonce | 3850 | | 3851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3853 option-code OPTION_RECONF_NONCE (20) 3855 option-len 8 3857 reconfigure-nonce reconfigure nonce value sent to the client 3859 The Reconfigure Nonce option MUST NOT appear in any DHCP message 3860 other than Reply or Reconfigure. 3862 23. Security Considerations 3864 Section 21 describes a threat model and an option that provides an 3865 authentication framework to defend against that threat model. 3867 24. IANA Considerations 3869 This document defines several new name spaces associated with DHCPv6 3870 and DHCPv6 options: 3872 - Multicast addresses 3874 - Message types 3876 - Option codes 3878 - Status codes 3880 - DUID 3882 - Authentication 3884 * Protocol 3886 * Algorithm 3888 * RDM 3890 IANA is requested to manage a registry of values for each of these 3891 name spaces, which are described in the remainder of this section. 3893 These name spaces are all to be managed separately from the name 3894 spaces defined for DHCPv4 [4, 1]. 3896 New values in each of these name spaces except for DHCP option codes 3897 should be approved by the process of IETF consensus [12]. New DHCP 3898 option codes should be approved through expert review by a designated 3899 expert [12]. 3901 24.1. Multicast addresses 3903 Section 5.1 defines the following multicast addresses, which have 3904 been assigned by IANA for use by DHCPv6: 3906 All_DHCP_Relay_Agents_and_Servers address: FF02::1:2 3908 All_DHCP_Servers address: FF05::1:3 3910 24.2. DHCP message types 3912 IANA is requested to record the following message types (defined 3913 in section 5.3). IANA is requested to maintain a registry of DHCP 3914 message types. 3916 SOLICIT 1 3918 ADVERTISE 2 3920 REQUEST 3 3922 CONFIRM 4 3924 RENEW 5 3926 REBIND 6 3928 REPLY 7 3930 RELEASE 8 3932 DECLINE 9 3934 RECONFIGURE 10 3936 INFORMATION-REQUEST 11 3938 RELAY-FORW 12 3940 RELAY-REPL 13 3942 24.3. DHCP options 3944 IANA is requested to record the following option-codes (as defined in 3945 section 22). IANA is requested to maintain a registry of DHCP option 3946 codes. 3948 OPTION_CLIENTID 1 3950 OPTION_SERVERID 2 3952 OPTION_IA 3 3954 OPTION_IA_TMP 4 3956 OPTION_IADDR 5 3958 OPTION_ORO 6 3960 OPTION_PREFERENCE 7 3962 OPTION_ELAPSED_TIME 8 3964 OPTION_CLIENT_MSG 9 3966 OPTION_SERVER_MSG 10 3968 OPTION_AUTH 11 3970 OPTION_UNICAST 12 3972 OPTION_STATUS_CODE 13 3974 OPTION_RAPID_COMMIT 14 3976 OPTION_USER_CLASS 15 3978 OPTION_VENDOR_CLASS 16 3980 OPTION_VENDOR_OPTS 17 3982 OPTION_INTERFACE_ID 18 3984 OPTION_RECONF_MSG 19 3986 OPTION_RECONF_NONCE 20 3988 24.4. Status codes 3990 IANA is requested to record the status codes defined in the following 3991 table. IANA is requested to manage the definition of additional 3992 status codes in the future. 3994 Name Code Description 3995 ---------- ---- ----------- 3996 Success 0 Success 3997 UnspecFail 1 Failure, reason unspecified; this 3998 status code is sent by either a client 3999 or a server to indicate a failure 4000 not explicitly specified in this 4001 document 4002 AuthFailed 2 Authentication failed or nonexistent 4003 AddrUnavail 3 Addresses unavailable 4004 NoBinding 4 Client record (binding) unavailable 4005 ConfNoMatch 5 Client record Confirm doesn't match IA 4006 NotOnLink 6 One or more prefixes of the addresses 4007 in the IA is not valid for the link 4008 from which the client message was received 4009 UseMulticast 7 Sent by a server to a client to force the 4010 client to send messages to the server 4011 using the All_DHCP_Relay_Agents_and_Servers 4012 address 4014 24.5. DUID 4016 IANA is requested to record the following DUID types (as defined in 4017 section 9.1). IANA is requested to manage definition of additional 4018 DUID types in the future. 4020 Link-layer address plus time 1 4022 VUID-EN 2 4024 Link-layer address 3 4026 24.6. Authentication option 4028 Section 21 references three name spaces associated with the 4029 Authentication Option (section 22.12), which are defined in the 4030 authentication mechanism for DHCPv4 [5]. 4032 The authentication name spaces currently registered by IANA will 4033 apply to both DHCPv6 and DHCPv4. In the future, specifications that 4034 define new Protocol, Algorithm and RDM mechanisms will explicitly 4035 define whether the new mechanisms are used with DHCPv4, DHCPv6 or 4036 both. 4038 25. Acknowledgments 4040 Thanks to the DHC Working Group and the members of the IETF for 4041 their time and input into the specification. In particular, thanks 4042 also for the consistent input, ideas, and review by (in alphabetical 4043 order) Bill Arbaugh, Thirumalesh Bhat, Steve Bellovin, Vijayabhaskar, 4044 Brian Carpenter, Matt Crawford, Francis Dupont, Tony Lindstrom, 4045 Josh Littlefield, Gerald Maguire, Jack McCann, Thomas Narten, Erik 4046 Nordmark, Yakov Rekhter, Mark Stapp, Matt Thomas, Sue Thomson, and 4047 Phil Wells. 4049 Thanks to Steve Deering and Bob Hinden, who have consistently 4050 taken the time to discuss the more complex parts of the IPv6 4051 specifications. 4053 And, thanks to Steve Deering for pointing out at IETF 51 in London 4054 that the DHCPv6 specification has the highest revision number of any 4055 Internet Draft. 4057 26. Changes in draft-ietf-dhc-dhcpv6-25.txt 4059 - Eliminated definition of VUID-DN. 4061 - Changed the second sentence in section 17.1.2 to: 4063 In the case of a Solicit message transmitted when DHCP is 4064 initiated by IPv6 Neighbor Discovery, the delay gives the amount 4065 of time to wait after IPv6 Neighbor Discovery causes the client 4066 to invoke the stateful address autoconfiguration protocol (see 4067 section 5.5.3 of RFC2462). 4069 - Changed Rapid Commit to allow client to use Advertise messages 4070 received while waiting for Reply, rather than restarting with 4071 Solicit; if client receives Advertise with preference 255, client 4072 immediately sends Request to that server. 4074 - Removed the use of All_DHCP_Servers multicast address as 4075 destination address in section 18.1.5. 4077 - Added text improving summary description of Confirm, Renew, 4078 Rebind. 4080 - Removed restriction on extension of lifetimes for temporary 4081 addresses; added text pointing to RFC 3041 for guidance on 4082 extending lifetimes for temporary addresses and when to request 4083 additional temporary addresses. 4085 - Clarified text in section 20 to emphasize that the relay agent 4086 puts an address in the link-address field regardless of whether 4087 it includes an Interface-ID option; added text explaining why the 4088 interface-identifier for an interface should remain stable. 4090 - Changed use of T1/T2 and lifetimes in Confirm message from 4091 client: client uses those fields for preferred values or sets 4092 to 0; server checks only addresses for correctness and returns 4093 values chosen by server for T1/T2 and lifetimes. Clarified 4094 that server checks addresses and returns current configuration 4095 information for the client. 4097 - Description of User Class option extended with an example 4098 and clarified to indicate that use of User Class options is 4099 determined by configuration/policies on server. 4101 - Clarified description of the use of Vendor-specific information 4102 to indicate that client need not receive all requested 4103 vendor-specific information before proceeding with normal 4104 operation. 4106 - Clarified use of Status Code option in Release message. 4108 - Edited section 14 to make clear that a client transmits until it 4109 receives a response only if both MRC and MRD are zero. 4111 - Removed suggestions about ordering options (for example, for 4112 improved performance). 4114 - Edited section 16 to clarify interface selection. 4116 - Removed use of anycast; use of anycast over individual link 4117 technologies will be specified in separate documents. 4119 - Removed replay detection information field from Solicit message 4120 to avoid potential DOS attack. 4122 - Clarified capabilities and constraints on relay agent forwarding. 4124 - Edited definition of vendor class data to clarify that instances 4125 of vendor-class-data are individual characteristics of the 4126 client. 4128 - Added text in section 21.5.4 to specify that client key is 4129 identified by client DUID. 4131 - Removed "Year 2000 Considerations" section; hope we don't need a 4132 "Year 3000 Consideration" section. 4134 - Authentication mechanism now shares Protocol, Algorithm and RDM 4135 name spaces with DHCPv4. 4137 - Added text to specify return of NoBinding if server cannot 4138 find binding for IA in Decline; added text allowing client to 4139 disregard NoBinding in Reply to Decline. 4141 - Clarify that Solicit, Confirm and Rebind are invalid if Server 4142 Identifier option is included. 4144 - Edited text about Option Request option to clarify that the 4145 option is a hint from the client to the server about options the 4146 client has a preference to receive; includes recommendation that 4147 client send Option Request option if it has options it requires. 4149 - Added nonce value for security of Reconfigure messages. 4151 References 4153 [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 4154 Extensions, March 1997. RFC 2132. 4156 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 4157 Levels, March 1997. RFC 2119. 4159 [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 4160 Specification, December 1998. RFC 2460. 4162 [4] R. Droms. Dynamic Host Configuration Protocol, March 1997. RFC 4163 2131. 4165 [5] R. Droms, Editor, W. Arbaugh, and Editor. Authentication for 4166 DHCP Messages, June 2001. RFC 3118. 4168 [6] R. Hinden and S. Deering. IP Version 6 Addressing Architecture, 4169 July 1998. RFC 2373. 4171 [7] IANA. Private Enterprise Numbers. 4172 http://www.iana.org/assignments/enterprise-numbers. 4174 [8] S. Kent and R. Atkinson. Security Architecture for the Internet 4175 Protocol, November 1998. RFC 2401. 4177 [9] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 4178 for Message Authentication, February 1997. RFC 2104. 4180 [10] David L. Mills. Network Time Protocol (Version 3) 4181 Specification, Implementation, March 1992. RFC 1305. 4183 [11] P.V. Mockapetris. Domain names - implementation and 4184 specification, November 1987. RFC 1035. 4186 [12] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 4187 Considerations Section in RFCs, October 1998. RFC 2434. 4189 [13] T. Narten and R. Draves. Privacy Extensions for Stateless 4190 Address Autoconfiguration in IPv6, January 2001. RFC 3041. 4192 [14] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 4193 IP Version 6 (IPv6), December 1998. RFC 2461. 4195 [15] D.C. Plummer. Ethernet Address Resolution Protocol: Or 4196 converting network protocol addresses to 48.bit Ethernet address 4197 for transmission on Ethernet hardware, November 1982. RFC 826. 4199 [16] J. Postel. User Datagram Protocol, August 1980. RFC 768. 4201 [17] R. Rivest. The MD5 Message-Digest Algorithm, April 1992. RFC 4202 1321. 4204 [18] S. Thomson and T. Narten. IPv6 Stateless Address 4205 Autoconfiguration, December 1998. RFC 2462. 4207 [19] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic 4208 Updates in the Domain Name System (DNS UPDATE), April 1997. RFC 4209 2136. 4211 Chair's Address 4213 The working group can be contacted via the current chair: 4215 Ralph Droms 4216 Cisco Systems 4217 300 Apollo Drive 4218 Chelmsford, MA 01824 4220 Phone: (978) 244-4733 4221 E-mail: rdroms@cisco.com 4223 Authors' Addresses 4225 Questions about this memo can be directed to: 4227 Jim Bound 4228 Hewlett Packard Corporation 4229 ZK3-3/W20 4230 110 Spit Brook Road 4231 Nashua, NH 03062-2698 4232 USA 4233 Voice: +1 603 884 0062 4234 E-mail: Jim.Bound@hp.com 4236 Mike Carney 4237 Sun Microsystems, Inc 4238 Mail Stop: UMPK17-202 4239 901 San Antonio Road 4240 Palo Alto, CA 94303-4900 4241 USA 4242 Voice: +1-650-786-4171 4243 E-mail: mwc@eng.sun.com 4245 Charles E. Perkins 4246 Communications Systems Lab 4247 Nokia Research Center 4248 313 Fairchild Drive 4249 Mountain View, California 94043 4250 USA 4251 Voice: +1-650 625-2986 4252 E-mail: charliep@iprg.nokia.com 4253 Fax: +1 650 625-2502 4255 Ted Lemon 4256 Nominum, Inc. 4257 950 Charter Street 4258 Redwood City, CA 94043 4259 E-mail: Ted.Lemon@nominum.com 4261 Bernie Volz 4262 Ericsson 4263 959 Concord St 4264 Framingham, MA 01701 4265 Voice: +1-508-875-3162 4266 Fax: +1-508-875-3018 4267 E-mail: bernie.volz@ericsson.com 4269 Ralph Droms 4270 Cisco Systems 4271 300 Apollo Drive 4272 Chelmsford, MA 01824 4273 USA 4274 Voice: +1 978 479 4733 4275 E-mail: rdroms@cisco.com 4277 A. Appearance of Options in Message Types 4279 The following table indicates with a "*" the options are allowed in 4280 each DHCP message type: 4282 Client Server IA/ Option Pref Time Client Server 4283 ID ID IA_TA Request Msg. Msg. 4284 Solicit * * * * 4285 Advert. * * * * * 4286 Request * * * * * 4287 Confirm * * * * 4288 Renew * * * * * 4289 Rebind * * * * 4290 Decline * * * * * 4291 Release * * * * * 4292 Reply * * * * * 4293 Reconf. * * * 4294 Inform. * (see note) * * 4295 R-forw. * 4296 R-repl. * 4298 NOTE: 4300 Only included in Information-Request messages that are sent 4301 in response to a Reconfigure (see section 19.3.3). 4303 Auth Server Status Rap. User Vendor Vendor Inter. Recon. 4304 Unica. Code Comm. Class Class Spec. ID Msg. 4305 Solicit * * * * * 4306 Advert. * * * * * 4307 Request * * * * 4308 Confirm * * * * 4309 Renew * * * * 4310 Rebind * * * * 4311 Decline * * * * * 4312 Release * * * * * 4313 Reply * * * * * * 4314 Reconf. * * 4315 Inform. * * * * 4316 R-forw. * * * * * 4317 R-repl. * * * * * 4319 B. Appearance of Options in the Options Field of DHCP Options 4321 The following table indicates with a "*" where options can appear in 4322 the options field of other options: 4324 Option IA/ IAADDR Relay Relay 4325 Field IA_TA Forw. Reply 4326 Client ID * 4327 Server ID * 4328 IA/IA_TA * 4329 IAADDR * 4330 ORO * 4331 Pref * 4332 Time * 4333 Authentic. * 4334 Server Uni. * 4335 Status Code * * * * * 4336 Rapid Comm. * 4337 User Class * 4338 Vendor Class * 4339 Vendor Info. * 4340 Interf. ID * * 4341 Reconf. msg. * 4343 C. Full Copyright Statement 4345 Copyright (C) The Internet Society (2001). All Rights Reserved. 4347 This document and translations of it may be copied and furnished to 4348 others, and derivative works that comment on or otherwise explain it 4349 or assist in its implementation may be prepared, copied, published 4350 and distributed, in whole or in part, without restriction of any 4351 kind, provided that the above copyright notice and this paragraph 4352 are included on all such copies and derivative works. However, 4353 this document itself may not be modified in any way, such as by 4354 removing the copyright notice or references to the Internet Society 4355 or other Internet organizations, except as needed for the purpose 4356 of developing Internet standards in which case the procedures 4357 for copyrights defined in the Internet Standards process must be 4358 followed, or as required to translate it into languages other than 4359 English. 4361 The limited permissions granted above are perpetual and will not be 4362 revoked by the Internet Society or its successors or assigns. 4364 This document and the information contained herein is provided on an 4365 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4366 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4367 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4368 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4369 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.