idnits 2.17.1 draft-ietf-dhc-dhcpv6-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 85 longer pages, the longest (page 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 abstract seems to contain references ([21]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes draft-ietf-dhc-dhcpv6-22.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- No information found for rfcdraft-ietf-dhc-dhcpv6-22.txt - is the name correct? -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 Feb 2002) is 8120 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (ref. '5') (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2373 (ref. '9') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2401 (ref. '10') (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '11') ** Obsolete normative reference: RFC 1305 (ref. '12') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2434 (ref. '15') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3041 (ref. '16') (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 2461 (ref. '17') (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '20') ** Obsolete normative reference: RFC 2462 (ref. '21') (Obsoleted by RFC 4862) Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force J. Bound 2 INTERNET DRAFT Compaq 3 DHC Working Group M. Carney 4 Obsoletes: draft-ietf-dhc-dhcpv6-22.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 1 Feb 2002 15 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 16 draft-ietf-dhc-dhcpv6-23.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" [21], and can be used separately 50 or concurrently with the latter to obtain configuration parameters. 52 Contents 54 Status of This Memo i 56 Abstract i 58 1. Introduction 1 60 2. Requirements 2 62 3. Background 2 64 4. Design Goals 3 66 5. Non-Goals 4 68 6. Terminology 4 69 6.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 4 70 6.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 5 72 7. DHCP Constants 7 73 7.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 7 74 7.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 7 75 7.3. DHCP message types . . . . . . . . . . . . . . . . . . . 8 76 7.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 9 77 7.4.1. Generic Status Codes . . . . . . . . . . . . . . 9 78 7.4.2. Server-specific Status Codes . . . . . . . . . . 10 79 7.5. Configuration Variables . . . . . . . . . . . . . . . . . 11 81 8. Message Formats 11 82 8.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 12 83 8.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 12 84 8.3. DHCP Request Message Format . . . . . . . . . . . . . . . 12 85 8.4. DHCP Confirm Message Format . . . . . . . . . . . . . . . 13 86 8.5. DHCP Renew Message Format . . . . . . . . . . . . . . . . 13 87 8.6. DHCP Rebind Message Format . . . . . . . . . . . . . . . 13 88 8.7. DHCP Reply Message Format . . . . . . . . . . . . . . . . 13 89 8.8. DHCP Release Message Format . . . . . . . . . . . . . . . 13 90 8.9. DHCP Decline Message Format . . . . . . . . . . . . . . . 14 91 8.10. DHCP Reconfigure Message Format . . . . . . . . . . . . . 14 92 8.11. Information-Request Message Format . . . . . . . . . . . 14 94 9. Relay messages 14 95 9.1. Relay-forward message . . . . . . . . . . . . . . . . . . 15 96 9.2. Relay-reply message . . . . . . . . . . . . . . . . . . . 16 98 10. Representation and use of domain names 16 100 11. DHCP unique identifier (DUID) 16 101 11.1. DUID contents . . . . . . . . . . . . . . . . . . . . . . 17 102 11.2. DUID based on link-layer address plus time . . . . . . . 17 103 11.3. Vendor-assigned unique ID (VUID) . . . . . . . . . . . . 18 104 11.4. Link-layer address . . . . . . . . . . . . . . . . . . . 19 106 12. Identity association 20 108 13. Selecting addresses for assignment to an IA 21 110 14. Management of temporary addresses 22 112 15. Reliability of Client Initiated Message Exchanges 23 114 16. Message validation 24 115 16.1. Use of Transaction-ID field . . . . . . . . . . . . . . . 24 116 16.2. Solicit message . . . . . . . . . . . . . . . . . . . . . 25 117 16.3. Advertise message . . . . . . . . . . . . . . . . . . . . 25 118 16.4. Request message . . . . . . . . . . . . . . . . . . . . . 25 119 16.5. Confirm message . . . . . . . . . . . . . . . . . . . . . 25 120 16.6. Renew message . . . . . . . . . . . . . . . . . . . . . . 26 121 16.7. Rebind message . . . . . . . . . . . . . . . . . . . . . 26 122 16.8. Decline messages . . . . . . . . . . . . . . . . . . . . 26 123 16.9. Release message . . . . . . . . . . . . . . . . . . . . . 27 124 16.10. Reply message . . . . . . . . . . . . . . . . . . . . . . 27 125 16.11. Reconfigure message . . . . . . . . . . . . . . . . . . . 27 126 16.12. Information-request message . . . . . . . . . . . . . . . 27 127 16.13. Relay-forward message . . . . . . . . . . . . . . . . . . 28 128 16.14. Relay-reply message . . . . . . . . . . . . . . . . . . . 28 130 17. Client Source Address and Interface Selection 28 132 18. DHCP Server Solicitation 28 133 18.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 29 134 18.1.1. Creation of Solicit messages . . . . . . . . . . 29 135 18.1.2. Transmission of Solicit Messages . . . . . . . . 29 136 18.1.3. Receipt of Advertise messages . . . . . . . . . . 30 137 18.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 31 138 18.2.1. Receipt of Solicit messages . . . . . . . . . . . 31 139 18.2.2. Creation and transmission of Advertise messages . 31 141 19. DHCP Client-Initiated Configuration Exchange 32 142 19.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 33 143 19.1.1. Creation and transmission of Request messages . . 33 144 19.1.2. Creation and transmission of Confirm messages . . 34 145 19.1.3. Creation and transmission of Renew messages . . . 35 146 19.1.4. Creation and transmission of Rebind messages . . 37 147 19.1.5. Creation and Transmission of Information-request 148 messages . . . . . . . . . . . . . . . . . 38 149 19.1.6. Receipt of Reply message in response to a Request, 150 Confirm, Renew, Rebind or Information-request 151 message . . . . . . . . . . . . . . . . . 38 152 19.1.7. Creation and transmission of Release messages . . 40 153 19.1.8. Receipt of Reply message in response to a Release 154 message . . . . . . . . . . . . . . . . . 41 155 19.1.9. Creation and transmission of Decline messages . . 41 156 19.1.10. Receipt of Reply message in response to a Decline 157 message . . . . . . . . . . . . . . . . . 42 158 19.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 42 159 19.2.1. Receipt of Request messages . . . . . . . . . . . 42 160 19.2.2. Receipt of Confirm messages . . . . . . . . . . . 43 161 19.2.3. Receipt of Renew messages . . . . . . . . . . . . 44 162 19.2.4. Receipt of Rebind messages . . . . . . . . . . . 45 163 19.2.5. Receipt of Information-request messages . . . . . 46 164 19.2.6. Receipt of Release messages . . . . . . . . . . . 47 165 19.2.7. Receipt of Decline messages . . . . . . . . . . . 47 166 19.2.8. Transmission of Reply messages . . . . . . . . . 47 168 20. DHCP Server-Initiated Configuration Exchange 48 169 20.1. Server Behavior . . . . . . . . . . . . . . . . . . . . . 48 170 20.1.1. Creation and transmission of Reconfigure messages 48 171 20.1.2. Time out and retransmission of Reconfigure 172 messages . . . . . . . . . . . . . . . . . 49 173 20.1.3. Receipt of Renew messages . . . . . . . . . . . . 49 174 20.2. Receipt of Information-request messages . . . . . . . . . 49 175 20.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 50 176 20.3.1. Receipt of Reconfigure messages . . . . . . . . . 50 177 20.3.2. Creation and transmission of Renew messages . . . 51 178 20.3.3. Creation and transmission of Information-request 179 messages . . . . . . . . . . . . . . . . . 51 180 20.3.4. Time out and retransmission of Renew or 181 Information-request messages . . . . . . . 51 182 20.3.5. Receipt of Reply messages . . . . . . . . . . . . 51 184 21. Relay Behavior 52 185 21.1. Relaying of client messages . . . . . . . . . . . . . . . 52 186 21.2. Relaying of server messages . . . . . . . . . . . . . . . 52 188 22. Authentication of DHCP messages 53 189 22.1. DHCP threat model . . . . . . . . . . . . . . . . . . . . 53 190 22.2. Security of messages sent between servers and relay agents 54 191 22.3. Summary of DHCP authentication . . . . . . . . . . . . . 54 192 22.4. Replay detection . . . . . . . . . . . . . . . . . . . . 54 193 22.5. Configuration token protocol . . . . . . . . . . . . . . 54 194 22.6. Delayed authentication protocol . . . . . . . . . . . . . 55 195 22.6.1. Management issues in the delayed authentication 196 protocol . . . . . . . . . . . . . . . . . 55 197 22.6.2. Use of the Authentication option in the delayed 198 authentication protocol . . . . . . . . . 55 199 22.6.3. Message validation . . . . . . . . . . . . . . . 56 200 22.6.4. Key utilization . . . . . . . . . . . . . . . . . 57 201 22.6.5. Client considerations for delayed authentication 202 protocol . . . . . . . . . . . . . . . . . 57 203 22.6.6. Server considerations for delayed authentication 204 protocol . . . . . . . . . . . . . . . . . 59 206 23. DHCP options 60 207 23.1. Format of DHCP options . . . . . . . . . . . . . . . . . 60 208 23.2. Client Identifier option . . . . . . . . . . . . . . . . 60 209 23.3. Server Identifier option . . . . . . . . . . . . . . . . 61 210 23.4. Identity association option . . . . . . . . . . . . . . . 61 211 23.5. IA Address option . . . . . . . . . . . . . . . . . . . . 63 212 23.6. Requested Temporary Addresses (RTA) Option . . . . . . . 65 213 23.7. Option Request option . . . . . . . . . . . . . . . . . . 65 214 23.8. Preference option . . . . . . . . . . . . . . . . . . . . 66 215 23.9. Elapsed Time . . . . . . . . . . . . . . . . . . . . . . 67 216 23.10. Client message option . . . . . . . . . . . . . . . . . . 67 217 23.11. Server message option . . . . . . . . . . . . . . . . . . 68 218 23.12. Authentication option . . . . . . . . . . . . . . . . . . 68 219 23.13. Server unicast option . . . . . . . . . . . . . . . . . . 69 220 23.14. Status Code Option . . . . . . . . . . . . . . . . . . . 70 221 23.15. User Class Option . . . . . . . . . . . . . . . . . . . . 70 222 23.16. Vendor Class Option . . . . . . . . . . . . . . . . . . . 71 223 23.17. Interface-Id Option . . . . . . . . . . . . . . . . . . . 72 225 24. Security Considerations 73 227 25. Year 2000 considerations 73 229 26. IANA Considerations 74 230 26.1. Multicast addresses . . . . . . . . . . . . . . . . . . . 74 231 26.2. DHCPv6 message types . . . . . . . . . . . . . . . . . . 74 232 26.3. DUID . . . . . . . . . . . . . . . . . . . . . . . . . . 74 233 26.4. DHCPv6 options . . . . . . . . . . . . . . . . . . . . . 74 234 26.5. Status codes . . . . . . . . . . . . . . . . . . . . . . 74 235 26.6. Authentication option . . . . . . . . . . . . . . . . . . 75 237 27. Acknowledgments 75 239 References 75 241 Chair's Address 77 243 Authors' Addresses 77 245 A. Appearance of Options in Message Types 79 247 B. Appearance of Options in the Options Field of DHCP Messages 79 249 C. Full Copyright Statement 80 251 1. Introduction 253 This document describes DHCP for IPv6 (DHCP), a UDP [19] 254 client/server protocol designed to reduce the cost of management 255 of IPv6 nodes in environments where network managers require more 256 control over the allocation of IPv6 addresses and configuration 257 of network stack parameters than that offered by "IPv6 Stateless 258 Address Autoconfiguration" [21]. DHCP is a stateful counterpart to 259 stateless autoconfiguration. Note that both stateful and stateless 260 autoconfiguration can be used concurrently in the same environment, 261 leveraging the strengths of both mechanisms in order to reduce the 262 cost of ownership and management of network nodes. 264 DHCP reduces the cost of ownership by centralizing the management 265 of network resources such as IP addresses, routing information, OS 266 installation information, directory service information, and other 267 such information on a few DHCP servers, rather than distributing such 268 information in local configuration files among all network node. 269 DHCP is designed to be easily extended to carry new configuration 270 parameters through the addition of new DHCP "options" defined to 271 carry this information. 273 Those readers familiar with DHCP for IPv4 [7] will find DHCP for 274 IPv6 provides a superset of the features of DHCP and benefits from 275 the additional features of IPv6 and freedom from the constraints of 276 backward compatibility with BOOTP [4]. 278 2. Requirements 280 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 281 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 282 document, are to be interpreted as described in [2]. 284 This document also makes use of internal conceptual variables 285 to describe protocol behavior and external variables that an 286 implementation must allow system administrators to change. The 287 specific variable names, how their values change, and how their 288 settings influence protocol behavior are provided to demonstrate 289 protocol behavior. An implementation is not required to have them in 290 the exact form described here, so long as its external behavior is 291 consistent with that described in this document. 293 3. Background 295 The IPv6 Specification provides the base architecture and design of 296 IPv6. Related work in IPv6 that would best serve an implementor 297 to study includes the IPv6 Specification [5], the IPv6 Addressing 298 Architecture [9], IPv6 Stateless Address Autoconfiguration [21], IPv6 299 Neighbor Discovery Processing [17], and Dynamic Updates to DNS [22]. 300 These specifications enable DHCP to build upon the IPv6 work to 301 provide both robust stateful autoconfiguration and autoregistration 302 of DNS Host Names. 304 The IPv6 Addressing Architecture specification [9] defines the 305 address scope that can be used in an IPv6 implementation, and the 306 various configuration architecture guidelines for network designers 307 of the IPv6 address space. Two advantages of IPv6 are that support 308 for multicast is required, and nodes can create link-local addresses 309 during initialization. This means that a client can immediately use 310 its link-local address and a well-known multicast address to begin 311 communications to discover neighbors on the link. For instance, a 312 client can send a Solicit message and locate a server or relay. 314 IPv6 Stateless Address Autoconfiguration [21] specifies procedures 315 by which a node may autoconfigure addresses based on router 316 advertisements [17], and the use of a valid lifetime to support 317 renumbering of addresses on the Internet. In addition the 318 protocol interaction by which a node begins stateless or stateful 319 autoconfiguration is specified. DHCP is one vehicle to perform 320 stateful autoconfiguration. Compatibility with stateless address 321 autoconfiguration is a design requirement of DHCP (see Section 4). 323 IPv6 Neighbor Discovery [17] is the node discovery protocol in IPv6 324 which replaces and enhances functions of ARP [18]. To understand 325 IPv6 and stateless address autoconfiguration it is strongly 326 recommended that implementors understand IPv6 Neighbor Discovery. 328 Dynamic Updates to DNS [22] is a specification that supports the 329 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 330 the dynamic updates to DNS to integrate addresses and name space to 331 not only support autoconfiguration, but also autoregistration in 332 IPv6. 334 4. Design Goals 336 - DHCP is a mechanism rather than a policy. Network administrators 337 set their administrative policies through the configuration 338 parameters they place upon the DHCP servers in the DHCP domain 339 they're managing. DHCP is simply used to deliver parameters 340 according to that policy to each of the DHCP clients within the 341 domain. 343 - DHCP is compatible with IPv6 stateless address 344 autoconfiguration [21], statically configured, non-participating 345 nodes and with existing network protocol implementations. 347 - DHCP does not require manual configuration of network parameters 348 on DHCP clients, except in cases where such configuration is 349 needed for security reasons. A node configuring itself using 350 DHCP should require no user intervention. 352 - DHCP does not require a server on each link. To allow for scale 353 and economy, DHCP must work across DHCP relays. 355 - DHCP clients can operate on a link without IPv6 routers present. 357 - DHCP will provide the ability to renumber network(s) when 358 required by network administrators [3]. 360 - A DHCP client can make multiple, different requests for 361 configuration parameters when necessary from one or more DHCP 362 servers at any time. 364 - DHCP will contain the appropriate time out and retransmission 365 mechanisms to efficiently operate in environments with high 366 latency and low bandwidth characteristics. 368 5. Non-Goals 370 This specification explicitly does not cover the following: 372 - Specification of a DHCP server to server protocol. 374 - How a DHCP server stores its DHCP data. 376 - How to manage a DHCP domain or DHCP server. 378 - How a DHCP relay is configured or what sort of information it may 379 log. 381 6. Terminology 383 This sections defines terminology specific to IPv6 and DHCP used in 384 this document. 386 6.1. IPv6 Terminology 388 IPv6 terminology relevant to this specification from the IPv6 389 Protocol [5], IPv6 Addressing Architecture [9], and IPv6 Stateless 390 Address Autoconfiguration [21] is included below. 392 address An IP layer identifier for an interface 393 or a set of interfaces. 395 unicast address An identifier for a single interface. 396 A packet sent to a unicast address is 397 delivered to the interface identified by 398 that address. 400 multicast address An identifier for a set of interfaces 401 (typically belonging to different 402 nodes). A packet sent to a multicast 403 address is delivered to all interfaces 404 identified by that address. 406 host Any node that is not a router. 408 IP Internet Protocol Version 6 (IPv6). The 409 terms IPv4 and IPv6 are used only in 410 contexts where it is necessary to avoid 411 ambiguity. 413 interface A node's attachment to a link. 415 link A communication facility or medium over 416 which nodes can communicate at the link 417 layer, i.e., the layer immediately below 418 IP. Examples are Ethernet (simple or 419 bridged); Token Ring; PPP links, X.25, 421 Frame Relay, or ATM networks; and 422 Internet (or higher) layer "tunnels", 423 such as tunnels over IPv4 or IPv6 424 itself. 426 link-layer identifier A link-layer identifier for an 427 interface. Examples include IEEE 802 428 addresses for Ethernet or Token Ring 429 network interfaces, and E.164 addresses 430 for ISDN links. 432 link-local address An IPv6 address having link-only 433 scope, indicated by having the prefix 434 (FE80::0000/64), that can be used to 435 reach neighboring nodes attached to 436 the same link. Every interface has a 437 link-local address. 439 neighbor A node attached to the same link. 441 node A device that implements IP. 443 packet An IP header plus payload. 445 prefix The initial bits of an address, or a 446 set of IP address that share the same 447 initial bits. 449 prefix length The number of bits in a prefix. 451 router A node that forwards IP packets not 452 explicitly addressed to itself. 454 6.2. DHCP Terminology 456 Terminology specific to DHCP can be found below. 458 agent address The address of a neighboring DHCP Agent 459 on the same link as the DHCP client. 461 binding A binding (or, client binding) is a 462 group of server data records containing 463 the information the server has about 464 the addresses in an IA and any other 465 configuration information assigned to 466 the client. A binding is indexed by the 467 tuple . 469 DHCP Dynamic Host Configuration Protocol 470 for IPv6. The terms DHCPv4 and DHCPv6 471 are used only in contexts where it is 472 necessary to avoid ambiguity. 474 configuration parameter An element of the configuration 475 information set on the server and 476 delivered to the client using DHCP. 477 Such parameters may be used to carry 478 information to be used by a node to 479 configure its network subsystem and 480 enable communication on a link or 481 internetwork, for example. 483 DHCP client (or client) A node that initiates requests on a link 484 to obtain configuration parameters from 485 one or more DHCP servers. 487 DHCP domain A set of links managed by DHCP and 488 operated by a single administrative 489 entity. 491 DHCP server (or server) A server is a node that responds to 492 requests from clients, and may or 493 may not be on the same link as the 494 client(s). 496 DHCP relay (or relay) A node that acts as an intermediary to 497 deliver DHCP messages between clients 498 and servers, and is on the same link as 499 a client. 501 DHCP agent (or agent) Either a DHCP server on the same link as 502 a client, or a DHCP relay. 504 DUID A DHCP Unique IDentifier for a DHCP 505 participant; each DHCP client and server 506 has exactly one DUID. 508 Identity association (IA) A collection of addresses assigned to 509 a client. Each IA has an associated 510 IAID. An IA may have 0 or more addresses 511 associated with it. 513 Identity association identifier (IAID) An identifier for an IA, 514 chosen by the client. Each IA has an 515 IAID, which is chosen to be unique among 516 all IAIDs for IAs belonging to that 517 client. 519 message A unit of data carried in a packet, 520 exchanged between DHCP agents and 521 clients. 523 transaction-ID An unsigned integer to match responses 524 with replies initiated either by a 525 client or server. 527 7. DHCP Constants 529 This section describes various program and networking constants used 530 by DHCP. 532 7.1. Multicast Addresses 534 DHCP makes use of the following multicast addresses: 536 All_DHCP_Agents (FF02::1:2) This link-scoped multicast address 537 is used by clients to communicate with the 538 on-link agent(s) when they do not know the 539 link-local address(es) for those agents. All 540 agents (servers and relays) are members of this 541 multicast group. 543 All_DHCP_Servers (FF05::1:3) This site-scoped multicast address is 544 used by clients or relays to communicate with 545 server(s), either because they want to send 546 messages to all servers or because they do not 547 know the server(s) unicast address(es). Note 548 that in order for a client to use this address, 549 it must have an address of sufficient scope to 550 be reachable by the server(s). All servers 551 within the site are members of this multicast 552 group. 554 7.2. UDP ports 556 DHCP uses the following destination UDP [19] port numbers. While 557 source ports MAY be arbitrary, client implementations SHOULD permit 558 their specification through a local configuration parameter to 559 facilitate the use of DHCP through firewalls. 561 546 Client port. Used by servers as the destination port 562 for messages sent to clients and relays. Used by relay 563 agents as the destination port for messages sent to 564 clients. 566 547 Agent port. Used as the destination port by clients 567 for messages sent to agents. Used as the destination 568 port by relays for messages sent to servers. 570 7.3. DHCP message types 572 DHCP defines the following message types. More detail on these 573 message types can be found in Section 8. Message types not listed 574 here are reserved for future use. The message code for each message 575 type is shown with the message name. 577 SOLICIT (1) The Solicit message is used by clients to 578 locate servers. 580 ADVERTISE (2) The Advertise message is used by servers 581 responding to Solicits. 583 REQUEST (3) The Request message is used by clients to 584 request configuration parameters from servers. 586 CONFIRM (4) The Confirm message is used by clients to 587 confirm that the addresses assigned to an IA 588 and the lifetimes for those addresses, as 589 well as the current configuration parameters 590 assigned by the server to the client are still 591 valid. 593 RENEW (5) The Renew message is used by clients to 594 update the addresses assigned to an IA and the 595 lifetimes for those addresses, as well as the 596 current configuration parameters assigned by 597 the server to the client. A client sends a 598 Renew message to the server that originally 599 populated the IA at time T1. 601 REBIND (6) The Rebind message is used by clients to extend 602 the lifetimes of addresses assigned to an IA, 603 as well as the current configuration parameters 604 assigned by the server to the client. A 605 client sends a Rebind message to all available 606 DHCP servers at time T2 only after the client 607 has been unable to contact the server that 608 originally populated the IA with a Renew 609 message. 611 REPLY (7) The Reply message is used by servers 612 responding to Request, Confirm, Renew, Rebind, 613 Information-request, Release and Decline 614 messages. In the case of responding to 615 a Request, Confirm, Information-request, 616 Renew or Rebind message, the Reply contains 617 configuration parameters destined for the 618 client. 620 RELEASE (8) The Release message is used by clients to 621 indicate to a server that the client will no 622 longer use one or more addresses in an IA. 624 DECLINE (9) The Decline message is used by clients to 625 indicate that the client has determined that 626 one or more addresses in an IA are already 627 in use on the link to which the client is 628 connected. 630 RECONFIGURE (10) The Reconfigure message is sent by a server 631 to inform a client that the server has new or 632 updated configuration parameters, and that 633 the client is to initiate a Renew/Reply or 634 Information-request/Reply transaction with 635 the server in order to receive the updated 636 information. 638 INFORMATION-REQUEST (11) The Information-request message is sent 639 by clients to request configuration parameters 640 without the assignment of any IP addresses to 641 the client. 643 RELAY-FORW (12) The Relay-forward message is used by relays to 644 forward client messages to servers. The client 645 message is encapsulated in an option in the 646 Relay-forward message. 648 RELAY-REPL (13) The Relay-reply message is used by servers to 649 send messages to clients through a relay. The 650 server encapsulates the client message as an 651 option in the Relay-reply message, which the 652 relay extracts and forwards to the client. 654 7.4. Status Codes 656 This section describes status codes exchanged between DHCP 657 implementations. These status codes may appear in the Status Code 658 option or in the status field of an IA. 660 7.4.1. Generic Status Codes 662 The status codes in this section are used between clients and servers 663 to convey status conditions. The following table contains the status 664 codes, the name for each code (as used in this document) and a brief 665 description. Note that the numeric values do not start at 1, nor are 666 they consecutive. The status codes are organized in logical groups. 668 Name Code Description 669 ---------- ---- ----------- 670 Success 0 Success 671 UnspecFail 16 Failure, reason unspecified 672 AuthFailed 17 Authentication failed or nonexistent 673 PoorlyFormed 18 Poorly formed message 674 AddrUnavail 19 Addresses unavailable 675 OptionUnavail 20 Requested options unavailable 677 7.4.2. Server-specific Status Codes 679 The status codes in this section are used by servers to convey status 680 conditions to clients. The following table contains the status 681 codes, the name for each code (as used in this document) and a brief 682 description. Note that the numeric values do not start at 1, nor are 683 they consecutive. The status codes are organized in logical groups. 685 Name Code Description 686 ---- ---- ----------- 687 NoBinding 32 Client record (binding) unavailable 688 ConfNoMatch 33 Client record Confirm doesn't match IA 689 RenwNoMatch 34 Client record Renew doesn't match IA 690 RebdNoMatch 35 Client record Rebind doesn't match IA 691 InvalidSource 36 Invalid Client IP address 692 NoPrefixMatch 37 One or more prefixes of the addresses 693 in the IA is not valid for the link 694 from which the client message was received 696 7.5. Configuration Variables 698 This section presents a table of client and server configuration 699 variables and the default or initial values for these variables. 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 726 8. Message Formats 728 All DHCP messages sent between clients and servers share an identical 729 fixed format header and a variable format area for options. Not all 730 fields in the header are used in every message. 732 All values in the message header and in options are in network order. 734 The following diagram illustrates the format of DHCP messages sent 735 between clients and servers: 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | msg-type | transaction-ID | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | | 743 . options . 744 . (variable) . 745 | | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 The following sections describe the use of the fields in the DHCP 749 message header in each of the DHCP messages. In these descriptions, 750 fields that are not used in a message are marked as "unused". All 751 unused fields in a message MUST be transmitted as zeroes and ignored 752 by the receiver of the message. 754 8.1. DHCP Solicit Message Format 756 msg-type SOLICIT 758 transaction-ID An unsigned integer generated by the client used 759 to identify this Solicit message. 761 options See section 23. 763 8.2. DHCP Advertise Message Format 765 msg-type ADVERTISE 767 transaction-ID An unsigned integer used to identify this 768 Advertise message. Copied from the Solicit 769 message received from the client. 771 options See section 23. 773 8.3. DHCP Request Message Format 775 msg-type REQUEST 777 transaction-ID An unsigned integer generated by the client used 778 to identify this Request message. 780 options See section 23. 782 8.4. DHCP Confirm Message Format 784 msg-type CONFIRM 786 transaction-ID An unsigned integer generated by the client used 787 to identify this Confirm message. 789 options See section 23. 791 8.5. DHCP Renew Message Format 793 msg-type RENEW 795 transaction-ID An unsigned integer generated by the client used 796 to identify this Renew message. 798 options See section 23. 800 8.6. DHCP Rebind Message Format 802 msg-type REBIND 804 transaction-ID An unsigned integer generated by the client used 805 to identify this Rebind message. 807 options See section 23. 809 8.7. DHCP Reply Message Format 811 msg-type REPLY 813 transaction-ID An unsigned integer used to identify this 814 Reply message. Copied from the client Request, 815 Confirm, Renew or Rebind message received from 816 the client. 818 options See section 23. 820 8.8. DHCP Release Message Format 822 msg-type RELEASE 824 transaction-ID An unsigned integer generated by the client used 825 to identify this Release message. 827 options See section 23. 829 8.9. DHCP Decline Message Format 831 msg-type DECLINE 833 transaction-ID An unsigned integer generated by the client used 834 to identify this Decline message. 836 options See section 23. 838 8.10. DHCP Reconfigure Message Format 840 msg-type RECONFIG 842 transaction-ID An unsigned integer generated by the server used 843 to identify this Reconfigure message. 845 options See section 23. 847 8.11. Information-Request Message Format 849 msg-type INFORMATION-REQUEST 851 transaction-ID An unsigned integer generated by the client used 852 to identify this Information-request message. 854 options See section 23. 856 9. Relay messages 858 Relay agents exchange messages with servers to forward messages 859 between clients and servers that are not connected to the same link. 861 There are two relay messages, which share the following format: 863 0 1 2 3 864 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 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | msg-type | | 867 +-+-+-+-+-+-+-+-+ | 868 | link-address | 869 | | 870 | | 871 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 872 | | | 873 +-+-+-+-+-+-+-+-+ | 874 | client-return-address | 875 | | 876 | | 877 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 878 | | | 879 +-+-+-+-+-+-+-+-+ | 880 . . 881 . options (variable number and length) .... . 882 | | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 The following sections describe the use of the Relay message header. 887 9.1. Relay-forward message 889 The following table defines the use of message fields in a 890 Relay-forward message. 892 msg-type RELAY-FORW 894 link-address An address with a prefix that is assigned 895 to the link from which the client should 896 be assigned an address. 898 client-return-address The IPv6 source address in which the 899 message from the client was received by 900 the relay agent 902 options MUST include a "Client message option"; 903 see section 23.10; MAY include other 904 options added by the relay agent 906 9.2. Relay-reply message 908 The following table defines the use of message fields in a 909 Relay-reply message. 911 msg-type RELAY-REPL 913 link-address The link-address copied from the 914 Relay-forward message; used by the relay 915 agent to select the link on which the 916 message is returned to the client 918 client-return-address The source address from the IP datagram 919 in which the message from the client was 920 received by the relay agent 922 options MUST include a "Server message option"; 923 see section 23.11; MAY include other 924 options 926 10. Representation and use of domain names 928 So that domain names may be encoded uniformly and compactly, a 929 domain name or a list of domain names is encoded using the technique 930 described in sections 3.1 and 4.1.4 of RFC1035 [14]. Section 4.1.4 931 of RFC1035 describes how more than one domain name can be represented 932 in a list of domain names. For use in this specification, in a 933 list of domain names, the compression pointer (see section 4.1.4 of 934 RFC1035) refers to the offset within the list. 936 If a single domain name is being used by a vendor as a vendor 937 identifier, then the vendor MUST ensure that the domain name has not 938 previously been used by a different vendor. 940 11. DHCP unique identifier (DUID) 942 Each DHCP client and server has a DUID. DHCP servers use DUIDs to 943 identify clients for the selection of configuration parameters and 944 in the association of IAs with clients. DHCP clients use DUIDs to 945 identify a server in messages where a server needs to be identified. 946 See sections 23.3 and 23.2 for the representation of a DUID in a DHCP 947 message. 949 Clients and servers MUST treat DUIDs as opaque values and MUST only 950 compare DUIDs for equality. Clients and servers MUST NOT in any 951 other way interpret DUIDs. Clients and servers MUST NOT restrict 952 DUIDs to the types defined in this document as additional DUID types 953 may be defined in the future. 955 The DUID is carried in an option because it may be variable length 956 and because it is not required in all DHCP options. The DUID is 957 designed to be unique across all DHCP clients and servers, and 958 consistent for any specific client or server - that is, the DUID used 959 by a client or server SHOULD NOT change over time, for example, as a 960 result of network hardware reconfiguration. 962 The motivation for having more than one type of DUID is that the DUID 963 must be globally unique, and must also be easy to generate. The sort 964 of globally-unique identifier that is easy to generate for any given 965 device can differ quite widely. Also, some devices may not contain 966 any persistent storage. Retaining a generated DUID in such a device 967 is not possible, so the DUID scheme must accommodate such devices. 969 11.1. DUID contents 971 A DUID consists of a sixteen-bit type code represented in network 972 order, followed by a variable number of octets that make up the 973 actual identifier. A DUID can be no more than 256 octets long. The 974 following types are currently defined: 976 1 Link-layer address plus time 977 2 Vendor-assigned unique ID 978 3 Link-layer address 980 Formats for the variable field of the DUID for each of the above 981 types are shown below. 983 11.2. DUID based on link-layer address plus time 985 This type of DUID consists of a two octet type field containing the 986 value 1, a two octet hardware type code, four octets containing 987 a time value, followed by link-layer address of any one network 988 interface that is connected to the DHCP device at the time that the 989 DUID is generated. The time value is the time that the DUID is 990 generated represented in seconds since midnight (UTC), January 1, 991 2000, modulo 2^32. The hardware type MUST be a valid hardware type 992 assigned by the IANA as described in the section on ARP in RFC 826. 993 Both the time and the hardware type are stored in network order. 995 The following diagram illustrates the format of a DUID based on 996 link-layer address plus time: 998 0 1 2 3 999 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 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | 1 | Hardware type (16 bits) | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | Time (32 bits) | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 . . 1006 . link-layer address (variable length) . 1007 . . 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 The choice of network interface can be completely arbitrary, as long 1011 as that interface provides a unique link-layer address, and the same 1012 DUID should be used in configuring all network interfaces connected 1013 to the device, regardless of which interface's link-layer address was 1014 used to generate the DUID. 1016 Clients and servers using this type of DUID MUST store the DUID 1017 in stable storage, and MUST continue to use this DUID even if the 1018 network interface used to generate the DUID is removed. Clients and 1019 servers that do not have any stable storage MUST NOT use this type of 1020 DUID. 1022 Clients and servers that use this DUID SHOULD attempt to configure 1023 the time prior to generating the DUID, if that is possible, and MUST 1024 use some sort of time source (e.g., a real-time clock) in generating 1025 the DUID, even if that time source could not be configured prior to 1026 generating the DUID. The use of a time source makes it unlikely that 1027 two identical DUIDs will be generated if the network interface is 1028 removed from the client and another client then uses the same network 1029 interface to generate a DUID. A DUID collision is very unlikely even 1030 if the clocks haven't been configured prior to generating the DUID. 1032 This method of DUID generation is recommended for all general purpose 1033 computing devices such as desktop computers and laptop computers, and 1034 also for devices such as printers, routers, and so on, that contain 1035 some form of writable non-volatile storage. 1037 11.3. Vendor-assigned unique ID (VUID) 1039 The vendor-assigned unique ID consists of a two-octet value giving 1040 the length of the identifier, the value of the idnetifier and the 1041 vendor's registered domain name. 1043 The following diagram summarizes the structure of a VUID: 1045 0 1 2 3 1046 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 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | 2 | identifier length | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 . . 1051 . identifier . 1052 . (variable length) . 1053 . . 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 . . 1056 . domain name (variable length) . 1057 . . 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 The source of the identifier is left up to the vendor defining it, 1061 but each identifier part of each VUID MUST be unique to the device 1062 that is using it, and MUST be assigned to the device at the time of 1063 manufacture and stored in some form of non-volatile storage. The 1064 VUID SHOULD be recorded in non-erasable storage. The domain name 1065 is simply any domain name that has been legally registered by the 1066 vendor in the domain name system [13], stored in the form described 1067 in section 10. 1069 An example DUID of this type might look like this: 1071 +---+---+---+---+---+---+---+---+ 1072 | 0 | 2 | 0 | 8 | 12|192|132|221| 1073 +---+---+---+---+---+---+---+---+ 1074 | 3 | 0 | 9 | 18|101|120| 97|109| 1075 +---+---+---+---+---+---+---+---+ 1076 |112|108|101| 46| 99|111|109| 1077 +---+---+---+---+---+---+---+ 1079 This example includes the two-octet type of 2, the two-octet length 1080 of 8, eight octets of identifier data, followed by "example.com" 1081 represented in ASCII. 1083 11.4. Link-layer address 1085 This type of DUID consists of two octets containing the DUID type 3, 1086 a two octet network hardware type code, followed by the link-layer 1087 address of any one network interface that is permanently connected 1088 to the client or server device and cannot be removed. The hardware 1089 type MUST be a valid hardware type assigned by the IANA as described 1090 in the section on ARP in RFC 826. The hardware type is stored in 1091 network order. 1093 The following diagram illustrates the format of a DUID based on 1094 link-layer address: 1096 0 1 2 3 1097 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 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | 3 | Hardware type (16 bits) | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 . . 1102 . link-layer address (variable length) . 1103 . . 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 The choice of network interface can be completely arbitrary, as 1107 long as that interface provides a unique link-layer address and 1108 is permanently attached to the device on which the DUID is being 1109 generated. The same DUID should be used in configuring all network 1110 interfaces connected to the device, regardless of which interface's 1111 link-layer address was used to generate the DUID. 1113 This type of DUID is recommended for devices that have a 1114 permanently-connected network interface with a link-layer address and 1115 do not have nonvolatile, writable stable storage. This type of DUID 1116 MUST NOT be used by DHCP clients or servers that cannot tell whether 1117 or not a network interface is permanently attached to the device on 1118 which the DHCP client is running. 1120 12. Identity association 1122 An "identity-association" (IA) is a construct through which a server 1123 and a client can identify, group and manage IPv6 addresses. Each IA 1124 consists of an IAID and associated configuration information. 1126 A client must associate at least one distinct IA with each of 1127 its network interfaces and uses that IA to obtain configuration 1128 information from a server for that interface. Other distinct IAs may 1129 be associated with applications. Each IA must be associated with 1130 exactly one interface. 1132 The IAID uniquely identifies the IA and must be chosen to be unique 1133 among the IAIDs on the client. The IAID is chosen by the client. 1134 For any given use of an IA by the client, the IAID for that IA MUST 1135 be consistent across restarts of the DHCP client. The client may 1136 maintain consistency either by storing the IAID in non-volatile 1137 storage or by using an algorithm that will consistently produce the 1138 same IAID as long as the configuration of the client has not changed. 1139 There may be no way for a client to maintain consistency of the IAIDs 1140 if it does not have non-volatile storage and the client's hardware 1141 configuration changes. 1143 The configuration information in an IA consists of one or more IPv6 1144 addresses and other parameters. The parameters are specified as DHCP 1145 options within the IA, and are associated with the addresses in the 1146 IA and the interface to which the IA belongs. Other parameters that 1147 are not associated with a particular interface may be specified in 1148 the options section of a DHCP message, outside the scope of any IA. 1150 Each address in an IA has a preferred lifetime and a valid lifetime, 1151 as defined in RFC2462 [21]. The lifetimes are transmitted from the 1152 DHCP server to the client in the IA option. The lifetimes apply to 1153 the use of IPv6 addresses as described in section 5.5.4 of RFC2462. 1154 An address whose valid lifetime has expired MAY be discarded from the 1155 IA. 1157 See section 23.4 for the representation of an IA in a DHCP message. 1159 13. Selecting addresses for assignment to an IA 1161 A server selects addresses to be assigned to an IA according to the 1162 address assignment policies determined by the server administrator 1163 and the specific information the server determines about the client 1164 from the following sources: 1166 - The link to which the client is attached. The server determines 1167 the link as follows: 1169 * If the server receives the message directly from the client 1170 and the source address in the IP datagram in which the 1171 message was received is a link-local address, then the client 1172 is on the same link to which the interface over which the 1173 message was received is attached 1175 * If the server receives the message from a forwarding relay 1176 agent, then the client is on the same link as the one to 1177 which the interface identified by the link-address field in 1178 the message from the relay is attached 1180 - The DUID supplied by the client 1182 - Other information in options supplied by the client 1184 - Other information in options supplied by the relay agent 1186 - If the server receives the message directly from the client and 1187 the source address in the IP datagram in which the message was 1188 received is not a link-local address, then the client is on the 1189 link identified by the source address in the IP datagram (note 1190 that this situation can occur only if the server has enabled the 1191 use of unicast message delivery by the client and the client has 1192 sent a message for which unicast delivery is allowed) 1194 The addresses that the server selects for the client MUST be valid on 1195 the link to which the interface is attached, regardless of the way in 1196 which the server selects the addresses. 1198 14. Management of temporary addresses 1200 A client may be assigned temporary addresses [16]. Clients and 1201 servers simply label addresses as "temporary". DHCPv6 handling 1202 of address lifetimes and lifetime extensions is no different for 1203 temporary addresses. DHCPv6 says nothing about details of temporary 1204 addresses like lifetimes, lifetime extensions, how clients use 1205 temporary addresses, rules for generating successive temporary 1206 addresses, etc. 1208 In DHCP, temporary addresses are identified with T-bit set in the IA 1209 Address Option(see section 23.5). A client may have zero or more 1210 temporary addresses. Addresses with the T-bit set MUST be intended 1211 for the client to use for the general purposes described in RFC3041. 1212 Addresses that otherwise have short lifetimes or are not intended to 1213 be renewed by the server MUST NOT have the T-bit set. 1215 Clients ask for temporary addresses and servers assign them. When 1216 a client sends an IA to a server, the client lists all of the 1217 temporary addresses it knows about and optionally indicates how many 1218 additional temporary addresses it wants in the Requested Temporary 1219 Addresses Option(see section 23.6). The server compares the number 1220 of requested additional temporary addresses against any previously 1221 allocated temporary addresses for the IA that were not reported 1222 by the client in the IA but still have some reasonable preferred 1223 lifetime left. If the number of temporary addresses is less than the 1224 requested number, the server adds additional temporary addresses to 1225 the IA to satisfy the requested number (subject to server policy). 1227 DISCUSSION: 1229 It is important that the server include any allocated 1230 temporary addresses that were not reported by the client as 1231 it is possible the client never received an earlier Reply 1232 that contained these additional temporary addresses. If 1233 the server did not consider these, a client that fails to 1234 receive a server's reply might cause the server to allocate 1235 many temporary addresses. 1237 When the valid lifetime on a temporary address expires, both the 1238 client and server silently discard the address from the IA. The 1239 discarded address no longer counts against the client's allotment of 1240 temporary addresses. 1242 A server SHOULD NOT assign a client temporary addresses without the 1243 client having specifically asked for it. The client is not obligated 1244 to install address(es) that it receives and did not request and can 1245 release any addresses it does not want. 1247 The server MAY update the DNS for a temporary address as described in 1248 section 4 of RFC3041, and MUST NOT update the DNS in any other way 1249 for a temporary address. 1251 15. Reliability of Client Initiated Message Exchanges 1253 DHCP clients are responsible for reliable delivery of messages in the 1254 client-initiated message exchanges described in sections 18 and 19. 1255 If a DHCP client fails to receive an expected response from a server, 1256 the client must retransmit its message. This section describes the 1257 retransmission strategy to be used by clients in client-initiated 1258 message exchanges. 1260 Note that the procedure described in this section is slightly 1261 modified for use with the Solicit message (section 18.1.2). 1263 The client begins the message exchange by transmitting a message to 1264 the server. The message exchange terminates when either the client 1265 successfully receives the appropriate response or responses from a 1266 server or servers, or when the message exchange is considered to have 1267 failed according to the retransmission mechanism described below. 1269 The client retransmission behavior is controlled and described by the 1270 following variables: 1272 RT Retransmission timeout 1274 IRT Initial retransmission time 1276 MRC Maximum retransmission count 1278 MRT Maximum retransmission time 1280 MRD Maximum retransmission duration 1282 RAND Randomization factor 1284 With each message transmission or retransmission, the client sets RT 1285 according to the rules given below. If RT expires before the message 1286 exchange terminates, the client recomputes RT and retransmits the 1287 message. 1289 Each of the computations of a new RT include a randomization factor 1290 (RAND), which is a random number chosen with a uniform distribution 1291 between -0.1 and +0.1. The randomization factor is included to 1292 minimize synchronization of messages transmitted by DHCP clients. 1293 The algorithm for choosing a random number does not need to be 1294 cryptographically sound. The algorithm SHOULD produce a different 1295 sequence of numbers from each invocation of the DHCP client. 1297 RT for the first message transmission is based on IRT: 1299 RT = 2*IRT + RAND*IRT 1301 RT for each subsequent message transmission is based on the previous 1302 value of RT: 1304 RT = 2*RTprev + RAND*RTprev 1306 MRT specifies an upper bound on the value of RT. If MRT has a value 1307 of 0, there is no upper limit on the value of RT. Otherwise: 1309 if (RT > MRT) 1310 RT = MRT + RAND*MRT 1312 MRC specifies an upper bound on the number of times a client may 1313 retransmit a message. If MRC has a value of 0, the client MUST 1314 continue to retransmit the original message until a response is 1315 received. Otherwise, the message exchange fails once the client has 1316 transmitted the message MRC times. 1318 MRD specifies an upper bound on the length of time a client may 1319 retransmit a message. If MRD has a value of 0, the client MUST 1320 continue to retransmit the original message until a response is 1321 received. Otherwise, the message exchange fails once the client has 1322 transmitted the message MRD seconds. 1324 If both MRC and MRD are non-zero, the message exchange fails whenever 1325 either of the conditions specified in the previous two paragraphs are 1326 met. 1328 16. Message validation 1330 Servers MUST discard any received messages that include 1331 authentication information and fail the authentication check by the 1332 server. 1334 Clients MUST discard any received messages that include 1335 authentication information and fail the authentication check by the 1336 client, except as noted in section 22.6.5.2. 1338 16.1. Use of Transaction-ID field 1340 The "transaction-ID" field holds a value used by clients and servers 1341 to synchronize server responses to client messages. A client SHOULD 1342 choose a different transaction-ID for each new message it sends. A 1343 client MUST leave the transaction-ID unchanged in retransmissions of 1344 a message. 1346 16.2. Solicit message 1348 Clients MUST discard any received Solicit messages. 1350 Relay agents MUST discard any Solicit messages received through port 1351 546. 1353 Servers MUST discard any Solicit messages that do not include a 1354 Client Identifier option. 1356 16.3. Advertise message 1358 Clients MUST discard any received Advertise messages that meet any of 1359 the following conditions: 1361 - the message does not include a Server Identifier option 1363 - the message does not include a Client Identifier option 1365 - the contents of the Client Identifier option does not match the 1366 client's DUID 1368 - the "Transaction-ID" field value does not match the value the 1369 client used in its Solicit message 1371 Servers and relay agents MUST discard any received Advertise 1372 messages. 1374 16.4. Request message 1376 Clients MUST discard any received Request messages. 1378 Relay agents MUST discard any Request messages received through port 1379 546. 1381 Servers MUST discard any received Request message that meet any of 1382 the following conditions: 1384 - the message does not include a Server Identifier option 1386 - the contents of the Server Identifier option do not match the 1387 server's identifier 1389 - the message does not include a Client Identifier option 1391 16.5. Confirm message 1393 Clients MUST discard any received Confirm messages. 1395 Relay agents MUST discard any Confirm messages received through port 1396 546. 1398 Servers MUST discard any Confirm messages received that do not 1399 include a Client Identifier option. 1401 16.6. Renew message 1403 Clients MUST discard any received Renew messages. 1405 Relay agents MUST discard any Renew messages received through port 1406 546. 1408 Servers MUST discard any received Renew message that meets any of the 1409 following conditions: 1411 - the message does not include a Server Identifier option 1413 - the contents of the Server Identifier option do not match the 1414 server's identifier 1416 - the message does not include a Client Identifier option 1418 16.7. Rebind message 1420 Clients MUST discard any received Rebind messages. 1422 Relay agents MUST discard any Rebind messages received through port 1423 546. 1425 Servers MUST discard any received Rebind message that does not 1426 include a Client Identifier option. 1428 16.8. Decline messages 1430 Clients MUST discard any received Decline messages. 1432 Relay agents MUST discard any Decline messages received through port 1433 546. 1435 Servers MUST discard any received Decline message that meets any of 1436 the following conditions: 1438 - the message does not include a Server Identifier option 1440 - the contents of the Server Identifier option do not match the 1441 server's identifier 1443 - the message does not include a Client Identifier option 1445 16.9. Release message 1447 Clients MUST discard any received Release messages. 1449 Relay agents MUST discard any Release messages received through port 1450 546. 1452 - the message does not include a Server Identifier option 1454 - the contents of the Server Identifier option do not match the 1455 server's identifier 1457 - the message does not include a Client Identifier option 1459 16.10. Reply message 1461 Clients MUST discard any received Reply messages that meet any of the 1462 following conditions: 1464 - the message does not include a Server Identifier option 1466 - the "transaction-ID" field in the message does not match the 1467 value used in the original message 1469 - the message does not include a Client Identifier option 1471 - the contents of the Client Identifier option does not match the 1472 DUID of the client 1474 Servers and relay agents MUST discard any received Reply messages. 1476 16.11. Reconfigure message 1478 Servers and relay agents MUST discard any received Reconfigure 1479 messages. 1481 Clients MUST discard any Reconfigure messages that meet any of the 1482 following conditions: 1484 - the message does not include a Server Identifier option 1486 - the message does not contain an authentication option 1488 - the message fails the authentication validation performed by the 1489 client 1491 16.12. Information-request message 1493 Clients MUST discard any received Information-request messages. 1495 Relay agents MUST discard any Information-request messages received 1496 through port 546. 1498 Servers MAY choose to discard any received Information-request 1499 messages that do not include a Client Identifier option. 1501 Servers MUST discard any received Information-request message that 1502 includes a Server Identifier option and the DUID in the option does 1503 not match the server's DUID. 1505 16.13. Relay-forward message 1507 Clients MUST discard any received Relay-forward messages. 1509 16.14. Relay-reply message 1511 Clients and servers MUST discard any received Relay-reply messages. 1513 17. Client Source Address and Interface Selection 1515 When a client sends a DHCP message to the All_DHCP_Agents multicast 1516 address, it MUST use the IPv6 link-local address assigned to 1517 the interface for which the client is interested in obtaining 1518 configuration as the source address in the header of the IP datagram. 1520 When a client sends a DHCP message directly to a server using unicast 1521 (after receiving the Server Unicast option from that server), it 1522 MUST use an address assigned to the interafce for which the client 1523 is interested in obtaining configuration, which is suitable for use 1524 by the server in responding to the client, as the source address in 1525 the header of the IP datagram. See "Default Address Selection for 1526 IPv6" [6] for more details. 1528 The client MUST transmit the message on the link that the interface 1529 for which configuration information is being obtained is attached 1530 to. The client SHOULD send the message through that interface. The 1531 client MAY send the message through another interface attached to the 1532 same link if and only if the client is certain the two interface are 1533 attached to the same link. 1535 18. DHCP Server Solicitation 1537 This section describes how a client locates servers that will assign 1538 addresses to IAs belonging to the client. 1540 The client is responsible for creating IAs and requesting that a 1541 server assign configuration information, including IPv6 addresses, 1542 to the IA. The client first creates an IA and assigns it an IAID. 1543 The client then transmits a Solicit message containing an IA option 1544 describing the IA. Servers that can assign configuration information 1545 to the IA respond to the client with an Advertise message. The 1546 client then initiates a configuration exchange as described in 1547 section 19. 1549 18.1. Client Behavior 1551 A client uses the Solicit message to discover DHCP servers configured 1552 to serve addresses on the link to which the client is attached. 1554 18.1.1. Creation of Solicit messages 1556 The client sets the "msg-type" field to SOLICIT. The client generates 1557 a transaction ID and inserts this value in the "transaction-ID" 1558 field. 1560 The client MUST include a Client Identifier option to identify itself 1561 to the server. The client MUST include one or more IA options for 1562 any IAs to which it wants the server to assign addresses. The client 1563 MAY include addresses in the IAs as a hint to the server about 1564 addresses for which the client has a preference. The client MAY 1565 include an Option Request Option in the Solicit message. The client 1566 MUST NOT include any other options except those specifically allowed 1567 as defined by specific options. 1569 If the client chooses to request specific options from the server, 1570 it does so by including an Option Request option (see section 23.7, 1571 which MUST include all of the options the client is requesting. The 1572 client MAY include options with data values as hints to the server 1573 about parameter values the client would like to have returned. 1575 18.1.2. Transmission of Solicit Messages 1577 The client sends the Solicit message to the All_DHCP_Agents multicast 1578 address. 1580 The first Solicit message from the client on the interface MUST 1581 be delayed by a random amount of time between MIN_SOL_DELAY and 1582 MAX_SOL_DELAY. This random delay desynchronizes clients which start 1583 at the same time (e.g., after a power outage). 1585 The client transmits the message according to section 15, using the 1586 following parameters: 1588 IRT SOL_TIMEOUT 1590 MRT SOL_MAX_RT 1592 MRC 0 1594 MRD 0 1596 The mechanism in section 15 is modified as follows for use in the 1597 transmission of Solicit messages. The message exchange is not 1598 terminated by the receipt of an Advertise before IRT has elapsed. 1599 Rather, the client collects Advertise messages until IRT has elapsed. 1600 Also, the first RT MUST be selected to be strictly greater than IRT 1601 by choosing RAND to be strictly greater than 0. 1603 A client MUST collect Advertise messages for IRT seconds, unless 1604 it receives an Advertise message with a preference value of 255. 1605 The preference value is carried in the Preference option (section 1606 23.8). Any Solicit that does not include a Preference option is 1607 considered to have a preference value of 0. If the client receives 1608 an Advertise message with a preference value of 255, then the client 1609 MAY act immediately on that Advertise message without waiting for any 1610 additional Advertise messages. 1612 If the client does not receive any Advertise messages before IRT 1613 has elapsed, it begins the retransmission mechanism described in 1614 section 15. The client terminates the retransmission process as 1615 soon as it recieves any Advertise message, and the client acts on 1616 the received Advertise message without waiting for any additional 1617 Advertise messages. 1619 A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client 1620 is configured with either MRC or MRD set to a value other than 1621 0, it MUST stop trying to configure the interface if the message 1622 exchange fails. After the DHCP client stops trying to configure the 1623 interface, it SHOULD choose to restart the reconfiguration process 1624 after some external event, such as user input, system restart, or 1625 when the client is attached to a new link. 1627 18.1.3. Receipt of Advertise messages 1629 The client MUST ignore any Advertise message that includes a Status 1630 Code option containing the value AddrUnavail, with the exception that 1631 the client MAY display the associated status message to the user. 1633 Upon receipt of one or more valid Advertise messages, the client 1634 selects one or more Advertise messages based upon the following 1635 criteria. 1637 - Those Advertise messages with the highest server preference value 1638 are preferred over all other Advertise messages. 1640 - Within a group of Advertise messages with the same server 1641 preference value, a client MAY select those servers whose 1642 Advertise messages advertise information of interest to the 1643 client. For example, the client may choose a server that 1644 returned an advertisement with configuration options of interest 1645 to the client. 1647 - The client MAY choose a less-preferred server if that server has 1648 a better set of advertised parameters, such as the available 1649 addresses advertised in IAs. 1651 Once a client has selected Advertise message(s), the client will 1652 typically store information about each server, such as server 1653 preference value, addresses advertised, when the advertisement was 1654 received, and so on. Depending on the requirements of the user that 1655 invoked the DHCP client, the client MAY initiate a configuration 1656 exchange with the server(s) immediately, or MAY defer this exchange 1657 until later. 1659 If the client needs to select an alternate server in the case that a 1660 chosen server does not respond, the client chooses the next server 1661 according to the criteria given above. 1663 18.2. Server Behavior 1665 A server sends an Advertise message in response to Solicit messages 1666 it receives to announce the availability of the server to the client. 1668 18.2.1. Receipt of Solicit messages 1670 The server determines the information about the client and its 1671 location as described in section 13. If administrative policy 1672 permits the server to respond to the client, the server will generate 1673 and send an Advertise message to the client. 1675 18.2.2. Creation and transmission of Advertise messages 1677 The server sets the "msg-type" field to ADVERTISE and copies the 1678 contents of the transaction-ID field from the Solicit message 1679 received from the client to the Advertise message. The server 1680 includes its server identifier in a Server Identifier option. 1682 The server MAY add a Preference option to carry the preference value 1683 for the Advertise message. The server implementation SHOULD allow 1684 the setting of a server preference value by the administrator. 1685 The server preference value MUST default to zero unless otherwise 1686 configured by the server administrator. 1688 The server MUST include IA options in the Advertise message 1689 containing any addresses that would be assigned to IAs contained in 1690 the Solicit message from the client. The server MAY include some or 1691 all of the IA options from the client in the Advertise message. 1693 If the server will not assign any addresses to IAs in a subsequent 1694 Request from the client, the server SHOULD either send an Advertise 1695 message to the client that includes only a status code option with 1696 the status code set to AddrUnavail and a status message for the user 1697 or not respond to the Solicit message. 1699 The server may choose to assign fewer temporary addresses than 1700 the client requested with an RTA option (see section 23.6) and 1701 includes a status code of Success in the IA. If the server will 1702 assign no temporary addresses, the server includes a status code of 1703 AddrUnavail. 1705 The server MAY include other options the server will return to the 1706 client in a subsequent Reply message. The information in these 1707 options will be used by the client in the selection of a server if 1708 the client receives more than one Advertise message. The server 1709 SHOULD include options specifying values for options requested by the 1710 client in an Option Request Option included in the Solicit message. 1712 If the Solicit message was received directly by the server, the 1713 server unicasts the Advertise message directly to the client using 1714 the address in the source address field from the IP datagram in 1715 which the Solicit message was received. The Advertise message MUST 1716 be unicast through the interface on which the Solicit message was 1717 received. 1719 If the Solicit message was received in a Relay-forward message, 1720 the server constructs a Relay-reply message with the Advertise 1721 message in the payload of a "server-message" option. The server 1722 unicasts the Relay-reply message directly to the relay agent using 1723 the address in the source address field from the IP datagram in which 1724 the Relay-forward message was received. 1726 19. DHCP Client-Initiated Configuration Exchange 1728 A client initiates a message exchange with a server or servers to 1729 acquire or update configuration information of interest. The client 1730 may initiate the configuration exchange as part of the operating 1731 system configuration process or when requested to do so by the 1732 application layer. 1734 19.1. Client Behavior 1736 A client will use Request, Confirm, Renew, Rebind and 1737 Information-request messages to acquire and confirm the 1738 validity of configuration information. The client uses the server 1739 identifier information and information about IAs from previous 1740 Advertise messages for use in constructing Request messages. Note 1741 that a client may request configuration information from one or more 1742 servers at any time. 1744 19.1.1. Creation and transmission of Request messages 1746 The client uses a Request message to populate IAs with addresses 1747 and obtain other configuration information. The client includes 1748 one or more IA options in the Request message, with addresses and 1749 information about the IAs that were obtained from the server in a 1750 previous Advertise message. The server then returns addresses and 1751 other information about the IAs to the client in IA options in a 1752 Reply message. 1754 The client generates a transaction ID and inserts this value in the 1755 "transaction-ID" field. 1757 The client places the identifier of the destination server in a 1758 Server Identifier option. 1760 The client MUST include a Client Identifier option to identify itself 1761 to the server. The client adds any other appropriate options, 1762 including one or more IA options (if the client is requesting that 1763 the server assign it some network addresses). The list of addresses 1764 in each included IA MUST include the addresses received by the client 1765 in a previous Advertise message. 1767 If the client chooses to request specific options from the server, 1768 it does so by including an Option Request option (see section 23.7, 1769 which MUST include all of the options the client is requesting. The 1770 client MAY include options with data values as hints to the server 1771 about parameter values the client would like to have returned. 1773 If the client has a source address of sufficient scope that can be 1774 used by the server as a return address and the client has received 1775 a Server Unicast option (section 23.13) from the server, the client 1776 SHOULD unicast the Request message to the server. Otherwise, the 1777 client MUST send the Request message to the All_DHCP_Agents multicast 1778 address. 1780 DISCUSSION: 1782 Use of multicast and relay agents enables the inclusion of 1783 relay agent options in all messages sent by the client. The 1784 server should enable the use of unicast only when relay 1785 agent options will not be used. 1787 The client transmits the message according to section 15, using the 1788 following parameters: 1790 IRT REQ_TIMEOUT 1792 MRT REQ_MAX_RT 1794 MRC REQ_MAX_RC 1796 MRD 0 1798 If the message exchange fails, the client MAY choose one of the 1799 following actions: 1801 - Select another server from a list of servers known to the client; 1802 e. g., servers that responded with an Advertise message 1804 - Initiate the server discovery process described in section 18 1806 - Terminate the configuration process and report failure 1808 19.1.2. Creation and transmission of Confirm messages 1810 Whenever a client may have moved to a new link, its IPv6 addresses 1811 and other configuration information may no longer be valid. Examples 1812 of times when a client may have moved to a new link include: 1814 o The client reboots 1816 o The client is physically disconnected from a wired connection 1818 o The client returns from sleep mode 1820 o The client using a wireless technology changes access points 1822 In any situation when a client may have moved to a new link, the 1823 client MUST initiate a Confirm/Reply message exchange. The client 1824 includes any IAs, along with the addresses associated with those IAs, 1825 in its Confirm message. Any responding servers will indicate the 1826 acceptability of the addresses with the status in the Reply message 1827 it returns to the client. 1829 The client sets the "msg-type" field to CONFIRM. The client generates 1830 a transaction ID and inserts this value in the "transaction-ID" 1831 field. 1833 The client MUST include a Client Identifier option to identify itself 1834 to the server. The client adds any appropriate options, including 1835 one or more IA options. The client MUST include the addresses the 1836 client currently has associated with those IAs. 1838 If the client chooses to request specific options from the server, 1839 it does so by including an Option Request option (see section 23.7, 1840 which MUST include all of the options the client is requesting. The 1841 client MAY include options with data values as hints to the server 1842 about parameter values the client would like to have returned. 1844 The client sends the Confirm message to the All_DHCP_Agents multicast 1845 address. The client MUST use an IPv6 address that the client has 1846 confirmed to be valid on the link to which it is currently attached 1847 and that is assigned to the interface for which the client is 1848 interested in obtaining configuration information as the source 1849 address in the IP header of the datagram carrying the Confirm 1850 message. 1852 The client transmits the message according to section 15, using the 1853 following parameters: 1855 IRT CNF_TIMEOUT 1857 MRT CNF_MAX_RT 1859 MRC 0 1861 MRD CNF_MAX_RD 1863 If the client receives no responses before the message transmission 1864 process as described in section 15 terminates, the client SHOULD 1865 continue to use any IP addresses, using the last known lifetimes for 1866 those addresses, and SHOULD continue to use any other previously 1867 obtained configuration parameters. 1869 19.1.3. Creation and transmission of Renew messages 1871 To extend the valid and preferred lifetimes associated with 1872 addresses, the client sends a Renew message to the server containing 1873 an "IA option" for the IA and its associated addresses. The server 1874 determines new lifetimes for the addresses in the IA according to the 1875 administrative configuration of the server. The server may also add 1876 new addresses to the IA. The server may remove addresses from the IA 1877 by setting the preferred and valid lifetimes of those addresses to 1878 zero. 1880 The server controls the time at which the client contacts the server 1881 to extend the lifetimes on assigned addresses through the T1 and T2 1882 parameters assigned to an IA. 1884 At time T1 for an IA, the client initiates a Renew/Reply message 1885 exchange to extend the lifetimes on any addresses in the IA. The 1886 client includes an IA option with all addresses currently assigned to 1887 the IA in its Renew message. 1889 The client sets the "msg-type" field to RENEW. The client generates a 1890 transaction ID and inserts this value in the "transaction-ID" field. 1892 The client places the identifier of the destination server in a 1893 Server Identifier option. 1895 The client MUST include a Client Identifier option to identify 1896 itself to the server. The client adds any appropriate options, 1897 including one or more IA options (if the client is requesting that 1898 the server extend the lifetimes of the addresses assigned to those 1899 IAs; note that the client may check the status of other configuration 1900 parameters without asking for lifetime extensions). The client MUST 1901 include the list of addresses the client currently has associated 1902 with the IAs in the Renew message. 1904 If the client chooses to request specific options from the server, 1905 it does so by including an Option Request option (see section 23.7, 1906 which MUST include all of the options the client is requesting. The 1907 client MAY include options with data values as hints to the server 1908 about parameter values the client would like to have returned. 1910 If the client has a source address of sufficient scope that can be 1911 used by the server as a return address and the client has received 1912 a Server Unicast option (section 23.13) from the server, the client 1913 SHOULD unicast the Renew message to the server. Otherwise, the 1914 client sends the Renew message to the All_DHCP_Agents multicast 1915 address. 1917 DISCUSSION: 1919 Use of multicast and relay agents enables the inclusion of 1920 relay agent options in all messages sent by the client. The 1921 server MUST NOT enable the use of unicast for a client when 1922 relay agent options are required for that client. 1924 The client transmits the message according to section 15, using the 1925 following parameters: 1927 IRT REN_TIMEOUT 1929 MRT REP_MAX_RT 1931 MRC 0 1933 MRD 0 1935 The mechanism in section 15 is modified as follows for use in the 1936 transmission of Renew messages. The message exchange is terminated 1937 when time T2 is reached (see section 19.1.4), at which time the 1938 client begins a Rebind message exchange. 1940 19.1.4. Creation and transmission of Rebind messages 1942 At time T2 for an IA (which will only be reached if the server to 1943 which the Renew message was sent at time T1 has not responded), 1944 the client initiates a Rebind/Reply message exchange. The client 1945 includes an IA option with all addresses currently assigned to the 1946 IA in its Rebind message. The client sends this message to the 1947 All_DHCP_Agents multicast address. 1949 The client sets the "msg-type" field to REBIND. The client generates 1950 a transaction ID and inserts this value in the "transaction-ID" 1951 field. 1953 The client MUST include a Client Identifier option to identify 1954 itself to the server. The client adds any appropriate options, 1955 including one or more IA options. The client MUST include the list 1956 of addresses the client currently has associated with the IAs in the 1957 Rebind message. 1959 If the client chooses to request specific options from the server, 1960 it does so by including an Option Request option (see section 23.7, 1961 which MUST include all of the options the client is requesting. The 1962 client MAY include options with data values as hints to the server 1963 about parameter values the client would like to have returned. 1965 The client sends the Rebind message to the All_DHCP_Agents multicast 1966 address. 1968 The client transmits the message according to section 15, using the 1969 following parameters: 1971 IRT REB_TIMEOUT 1973 MRT REB_MAX_RT 1975 MRC 0 1977 MRD 0 1979 The mechanism in section 15 is modified as follows for use in the 1980 transmission of Rebind messages. The message exchange is terminated 1981 when the lifetimes of all of the addresses assigned to the IA expire 1982 (see section 12), at which time the client has several alternative 1983 actions to choose from: 1985 - The client may choose to use a Solicit message to locate a new 1986 DHCP server and send a Request for the expired IA to the new 1987 server 1989 - The client may have other addresses in other IAs, so the client 1990 may choose to discard the expired IA and use the addresses in the 1991 other IAs 1993 19.1.5. Creation and Transmission of Information-request messages 1995 The client uses an Information-request message to obtain 1996 configuration information without having addresses assigned to it. 1997 The client sets the "msg-type" field to INFORMATION-REQUEST. The 1998 client generates a transaction ID and inserts this value in the 1999 "transaction-ID" field. 2001 The client SHOULD include a Client Identifier option to identify 2002 itself to the server. If the client does not include a Client 2003 Identifier option, the server will not be able to return any 2004 client-specific options to the client. 2006 If the client chooses to request specific options from the server, 2007 it does so by including an Option Request option (see section 23.7, 2008 which MUST include all of the options the client is requesting. The 2009 client MAY include options with data values as hints to the server 2010 about parameter values the client would like to have returned. The 2011 client MUST NOT include any IA options. 2013 If the client has an IPv6 address of sufficient scope, the 2014 client MAY choose to send the Information-request message to the 2015 All_DHCP_Servers multicast address. Otherwise, the client MUST send 2016 the Information-request message to the All_DHCP_Agents multicast 2017 address. 2019 The client transmits the message according to section 15, using the 2020 following parameters: 2022 IRT INF_TIMEOUT 2024 MRT INF_MAX_RT 2026 MRC 0 2028 MRD 0 2030 19.1.6. Receipt of Reply message in response to a Request, Confirm, 2031 Renew, Rebind or Information-request message 2033 Upon the receipt of a valid Reply message in response to a Request, 2034 Confirm, Renew, Rebind or Information-request message, the client 2035 extracts the configuration information contained in the Reply. The 2036 client MAY choose to report any status code or message from the 2037 status code option in the Reply message. 2039 The client SHOULD perform duplicate address detection [21] on each 2040 of the addresses in any IAs it receives in the Reply message after 2041 a Request message. If any of the addresses are found to be in use 2042 on the link, the client sends a Decline message to the server as 2043 described in section 19.1.9. 2045 The client records the T1 and T2 times for each IA in the Reply 2046 message. The client records any addresses included with IAs in 2047 the Reply message. The client updates the preferred and valid 2048 lifetimes for the addresses in the IA from the lifetime information 2049 in the IA option. The client leaves any addresses that the client 2050 has associated with the IA that are not included in the IA option 2051 unchanged. 2053 The client SHOULD respond to the server with a Release message for 2054 any addresses in the Reply message that have a valid lifetime of 0. 2055 The client constructs and transmits this message as described in 2056 section 19.1.7. 2058 If the Reply was received in response to a Renew or Rebind message, 2059 the client must update the information in any IA option contained in 2060 the Reply message. The client adds any new addresses from the IA 2061 option to the IA, updates lifetimes for existing addresses in the IA 2062 from the IA option and discards any addresses with a lifetime of zero 2063 in the IA option. 2065 Management of the specific configuration information is detailed in 2066 the definition of each option, in section 23. 2068 When the client receives a NoPrefixMatch status in an IA from the 2069 server the client can assume it needs to send a Request to the server 2070 to obtain appropriate addresses for the IA. If the client receives 2071 any Reply messages that do not indicate a NoPrefixMatch status, the 2072 client can use the addresses in the IA and ignore any messages that 2073 do indicate a NoPrefixMatch status. 2075 When the client receives an AddrUnavail status in an IA from the 2076 server for a Request message the client will have to find a new 2077 server to create an IA. 2079 When the client receives a NoBinding status in an IA from the server 2080 for a Confirm message the client can assume it needs to send a 2081 Request to reestablish an IA with the server. 2083 When the client receives a ConfNoMatch status in an IA from the 2084 server for a Confirm message the client can send a Renew message to 2085 the server to extend the lifetimes of the addresses. 2087 When the client receives a NoBinding status in an IA from the server 2088 for a Renew message the client can assume it needs to send a Request 2089 to reestablish an IA with the server. 2091 When the client receives a RenwNoMatch status in an IA from the 2092 server for a Renew message the client can assume it needs to send a 2093 Request to reestablish an IA with the server. 2095 When the client receives an AddrUnavail status in an IA from the 2096 server for a Renew message the client can assume it needs to send a 2097 Request to reestablish an IA with the server. 2099 When the client receives a NoBinding status in an IA from the server 2100 for a Rebind message the client can assume it needs to send a Request 2101 to reestablish an IA with the server or try another server. 2103 When the client receives a RebdNoMatch status in an IA from the 2104 server for a Rebind message the client can assume it needs to send a 2105 Request to reestablish an IA with the server or try another server. 2107 When the client receives an AddrUnavail status in an IA from the 2108 server for a Rebind message the client can assume it needs to send a 2109 Request to reestablish an IA with the server or try another server. 2111 19.1.7. Creation and transmission of Release messages 2113 The client sets the "msg-type" field to RELEASE. The client generates 2114 a transaction ID and places this value in the "transaction-ID" field. 2116 The client places the identifier of the server that allocated the 2117 address(es) a Server Identifier option. 2119 The client MUST include a Client Identifier option to identify itself 2120 to the server. The client includes options containing the IAs it 2121 is releasing in the "options" field. The addresses to be released 2122 MUST be included in the IAs. The client continues to use any other 2123 addresses in the IAs. The appropriate "status" field in the options 2124 MUST be set to indicate the reason for the release. 2126 The client MUST NOT use any of the addresses in the IAs in the 2127 message as the source address in the Release message or in any 2128 subsequently transmitted message. 2130 If the client has a source address of sufficient scope that can be 2131 used by the server as a return address and the client has received 2132 a Server Unicast option (section 23.13) from the server, the client 2133 SHOULD unicast the Release message to the server. Otherwise, the 2134 client MUST send the Release message to the All_DHCP_Agents multicast 2135 address. 2137 DISCUSSION: 2139 Use of multicast and relay agents enables the inclusion of 2140 relay agent options in all messages sent by the client. The 2141 server MUST NOT enable the use of unicast for a client when 2142 relay agent options are required for that client. 2144 A client MAY choose to wait for a Reply message from the server in 2145 response to the Release message. If the client does wait for a 2146 Reply, the client MAY choose to retransmit the Release message. 2148 The client transmits the message according to section 15, using the 2149 following parameters: 2151 IRT REL_TIMEOUT 2153 MRT 0 2155 MRC REL_MAX_MRC 2157 MRD 0 2159 The client MUST abandon the attempt to release addresses if the 2160 Release message exchange fails. 2162 The client MUST stop using all of the addresses in the IA(s) being 2163 released as soon as the client begins the Release message exchange 2164 process. If an IA is released but the Reply from a DHCP server 2165 is lost, the client will retransmit the Release message, and the 2166 server may respond with a Reply indicating a status of "Nobinding". 2167 Therefore, the client does not treat a Reply message with a status 2168 of "Nobinding" in a Release message exchange as if it indicates an 2169 error. 2171 Note that if the client fails to release the IA, the addresses 2172 assigned to the IA will be reclaimed by the server when the lifetime 2173 of the address expires. 2175 19.1.8. Receipt of Reply message in response to a Release message 2177 Upon receipt of a valid Reply message, the client can consider the 2178 Release event successful. 2180 19.1.9. Creation and transmission of Decline messages 2182 The client sets the "msg-type" field to DECLINE. The client generates 2183 a transaction ID and places this value in the "transaction-ID" field. 2185 The client places the identifier of the server that allocated the 2186 address(es) in a Server Identifier option. 2188 The client MUST include a Client Identifier option to identify itself 2189 to the server. The client includes options containing the IAs it is 2190 declining in the "options" field. The addresses to be declined MUST 2191 be included in the IAs. The client continues to use other addresses 2192 in the IAs. The appropriate "status" field in the options MUST be 2193 set to indicate the reason for declining the address. 2195 The client MUST NOT use any of the addresses in the IAs in the 2196 message as the source address in the Decline message or in any 2197 subsequently transmitted message. 2199 If the client has a source address of sufficient scope that can be 2200 used by the server as a return address and the client has received 2201 a Server Unicast option (section 23.13) from the server, the client 2202 SHOULD unicast the Decline message to the server. Otherwise, the 2203 client MUST send the Decline message to the All_DHCP_Agents multicast 2204 address. 2206 DISCUSSION: 2208 Use of multicast and relay agents enables the inclusion of 2209 relay agent options in all messages sent by the client. The 2210 server MUST NOT enable the use of unicast for a client when 2211 relay agent options are required for that client. 2213 The client transmits the message according to section 15, using the 2214 following parameters: 2216 IRT DEC_TIMEOUT 2218 MRT DEC_MAX_RT 2220 MRC DEC_MAX_RC 2222 MRD 0 2224 The client MUST abandon the attempt to decline addresses if the 2225 Decline message exchange fails. 2227 19.1.10. Receipt of Reply message in response to a Decline message 2229 Upon receipt of a valid Reply message, the client can consider the 2230 Decline event successful. 2232 19.2. Server Behavior 2234 For this discussion, the Server is assumed to have been configured in 2235 an implementation specific manner with configuration of interest to 2236 clients. 2238 19.2.1. Receipt of Request messages 2240 The server MAY choose to discard Request messages received via 2241 unicast from a client to which the server has not sent a unicast 2242 option. 2244 When the server receives a Request the client is requesting the 2245 configuration of a new IA by the server. The server MUST take the 2246 IA from the client and associate a binding for that client in an 2247 implementation-specific manner within the configuration parameter 2248 database for DHCP clients managed by the server. 2250 Upon the receipt of a valid Request message from a client the server 2251 can respond to, (implementation-specific administrative policy 2252 satisfied) the server scans the options field. 2254 The server then constructs a Reply message and sends it to the 2255 client. 2257 The server SHOULD process each option for the client in an 2258 implementation-specific manner. The server MUST construct a Reply 2259 message containing the following values: 2261 msg-type REPLY 2263 transaction-ID The transaction-ID from the Request message. 2265 The server MUST include a Server Identifier option containing the 2266 server's DUID in the Reply message. 2268 If the server finds that the prefix on one or more IP addresses in 2269 any IA in the message from the client is not a valid prefix for the 2270 link to which the client is connected, the server MUST return the IA 2271 to the client with the status field set to NoPrefixMatch. 2273 If the server cannot assign any addresses to any of the IAs in 2274 the message from the client, the server SHOULD include the IAs in 2275 the Reply message with the status field set to AddrUnavail and no 2276 addresses in the IA. 2278 For any IAs to which the server can assign addresses, server includes 2279 the IA with addresses and other configuration parameters a status of 2280 Success, and add the IA as a new client binding. 2282 The server may choose to assign fewer temporary addresses than 2283 the client requested with an RTA option (see section 23.6) and 2284 includes a status code of Success in the IA. If the server chooses to 2285 assign no temporary addresses, the server includes a status code of 2286 AddrUnavail. 2288 The server adds options to the Reply message for any other 2289 configuration information to be assigned to the client. 2291 19.2.2. Receipt of Confirm messages 2293 When the server receives a Confirm message, the client is requesting 2294 confirmation that the configuration information it will use is valid. 2295 The server SHOULD locate the binding for that client and compare the 2296 information in the Confirm message from the client to the information 2297 associated with that client. 2299 Upon the receipt of a valid Confirm message from a client the server 2300 can respond to, (implementation-specific administrative policy 2301 satisfied) the server scans the options field. 2303 If the server cannot determine if the information in the Confirm 2304 message is valid or invalid, the server MUST NOT send a reply to the 2305 client. For example, if the server does not have a binding for the 2306 client, but the configuration information in the Confirm message 2307 appears valid, the server does not reply. 2309 If the server finds that the information for the client does not 2310 match what is in the binding for that client or the configuration 2311 information is not valid, the server sends a Reply message containing 2312 a Status Code option with the value ConfNoMatch. 2314 If the server finds that the information for the client does match 2315 the information in the binding for that client, and the configuration 2316 information is still valid, the server sends a Reply message 2317 containing a Status Code option with the value Success. 2319 The server SHOULD process each option for the client in an 2320 implementation-specific manner. The server MUST construct a Reply 2321 message containing the following values: 2323 msg-type REPLY 2325 transaction-ID The transaction-ID from the Confirm message. 2327 The server MUST include a Server Identifier option containing the 2328 server's DUID in the Reply message. 2330 The Reply message from the server MUST contain a Status Code option 2331 and MUST NOT include any other options. 2333 19.2.3. Receipt of Renew messages 2335 The server MAY choose to discard Renew messages received via unicast 2336 from a client to which the server has not sent a unicast option. 2338 Upon the receipt of a valid Renew message from a client the server 2339 can respond to, (implementation-specific administrative policy 2340 satisfied) the server scans the options field. 2342 When the server receives a Renew and IA option from a client it 2343 SHOULD locate the clients binding and verify the information in the 2344 IA from the client matches the information stored for that client. 2346 If the server cannot find a client entry for this IA the server 2347 SHOULD return an IA containing no addresses with status set to 2348 NoBinding. 2350 If the server finds that the addresses in the IA for the client 2351 do not match the client binding the server should return an IA 2352 containing no addresses with status set to RenwNoMatch. 2354 If the server cannot Renew addresses for the client it SHOULD send 2355 back an IA containing no addresses to the client with the status 2356 field set to AddrUnavail. 2358 If the server finds the addresses in the IA for the client then the 2359 server SHOULD send back the IA to the client with new lifetimes and 2360 T1/T2 times if the default is not being used, and set status to 2361 Success. The server may choose to change the list of addresses and 2362 the lifetimes of addresses in IAs that are returned to the client. 2364 The server may choose to assign fewer temporary addresses than 2365 the client requested with an RTA option (see section 23.6) and 2366 includes a status code of Success in the IA. If the server chooses to 2367 assign no temporary addresses, the server includes a status code of 2368 AddrUnavail. 2370 The server SHOULD process each option for the client in an 2371 implementation-specific manner. The server MUST construct a Reply 2372 message containing the following values: 2374 msg-type REPLY 2376 transaction-ID The transaction-ID from the Confirm message. 2378 The server MUST include a Server Identifier option containing the 2379 server's DUID in the Reply message. 2381 19.2.4. Receipt of Rebind messages 2383 Upon the receipt of a valid Rebind message from a client the server 2384 can respond to, (implementation-specific administrative policy 2385 satisfied) the server scans the options field. 2387 When the server receives a Rebind and IA option from a client it 2388 SHOULD locate the clients binding and verify the information in the 2389 IA from the client matches the information stored for that client. 2391 If the server cannot find a client entry for this IA the server 2392 SHOULD return an IA containing no addresses with status set to 2393 NoBinding. 2395 If the server finds that the addresses in the IA for the client 2396 do not match the client binding the server should return an IA 2397 containing no addresses with status set to RebdNoMatch. 2399 If the server cannot Rebind addresses for the client it SHOULD send 2400 back an IA containing no addresses to the client with the status 2401 field set to AddrUnavail. 2403 If the server finds the addresses in the IA for the client then the 2404 server SHOULD send back the IA to the client with new lifetimes and 2405 T1/T2 times if the default is not being used, and set status to 2406 Success. 2408 The server may choose to assign fewer temporary addresses than 2409 the client requested with an RTA option (see section 23.6) and 2410 includes a status code of Success in the IA. If the server will 2411 assign no temporary addresses, the server includes a status code of 2412 AddrUnavail. 2414 The server SHOULD process each option for the client in an 2415 implementation-specific manner. The server MUST construct a Reply 2416 message containing the following values: 2418 msg-type REPLY 2420 transaction-ID The transaction-ID from the Confirm message. 2422 The server MUST include a Server Identifier option containing the 2423 server's DUID in the Reply message. 2425 19.2.5. Receipt of Information-request messages 2427 When the server receives an Information-request message, the client 2428 is requesting configuration information that does not include 2429 the assignment of any addresses. The server SHOULD determine all 2430 configuration parameters appropriate to the client, based on the 2431 server configuration policies known to the server. 2433 Upon the receipt of a valid Information-request message from a client 2434 the server can respond to, (implementation-specific administrative 2435 policy satisfied) the server scans the options field. The server 2436 then constructs a Reply message and sends it to the client. 2438 The server SHOULD process each option for the client in an 2439 implementation-specific manner. The server MUST construct a Reply 2440 message containing the following values: 2442 msg-type REPLY 2444 transaction-ID The transaction-ID from the Confirm message. 2446 The server MUST include a Server Identifier option containing the 2447 server's DUID in the Reply message. 2449 The server adds options to the Reply message for all of the 2450 configuration parameters to be returned to the client. 2452 19.2.6. Receipt of Release messages 2454 The server MAY choose to discard Release messages received via 2455 unicast from a client to which the server has not sent a unicast 2456 option. 2458 Upon the receipt of a valid Release message, the server examines the 2459 IAs and the addresses in the IAs for validity. If the IAs in the 2460 message are in a binding for the client and the addresses in the IAs 2461 have been assigned by the server to those IAs, the server deletes 2462 the addresses from the IAs and makes the addresses available for 2463 assignment to other clients. The server ignores invalid addresses 2464 (though it may choose to log an error if it finds an invalid 2465 address). 2467 After all the addresses have been processed, the server generates a 2468 Reply message and includes a Status Code option with value Success 2469 and a Server Identifier option with the server's DUID. The server 2470 MUST NOT include any other options in the Reply message. 2472 A server is not required to (but may choose to as an implementation 2473 strategy) retain any record of an IA from which all of the addresses 2474 have been released. 2476 19.2.7. Receipt of Decline messages 2478 The server MAY choose to discard Decline messages received via 2479 unicast from a client to which the server has not sent a unicast 2480 option. 2482 Upon the receipt of a valid Decline message, the server examines the 2483 IAs and the addresses in the IAs for validity. If the IAs in the 2484 message are in a binding for the client and the addresses in the IAs 2485 have been assigned by the server to those IA, the server deletes 2486 the addresses from the IAs. The server SHOULD mark the addresses 2487 declined by the client so that those addresses are not assigned to 2488 other clients, and MAY choose to make a notification that addresses 2489 were declined. The server ignores invalid addresses (though it may 2490 choose to log an error if it finds an invalid address). 2492 After all the address have been processed, the server generates a 2493 Reply message and includes a Status Code option with value Success 2494 and a Server Identifier option with the server' DUID. The server MUST 2495 NOT include any other options in the Reply message. 2497 19.2.8. Transmission of Reply messages 2499 If the Request, Confirm, Renew, Rebind, Release, Decline or 2500 Information-request message from the client was originally received 2501 in a Relay-forward message from a relay, the server places the 2502 Reply message in the options field of a Relay-response message and 2503 copies the link-address and client-return-address fields from the 2504 Relay-forward message into the Relay-response message. 2506 The server then unicasts the Reply or Relay-reply to the source 2507 address from the IP datagram in which the original message was 2508 received. 2510 20. DHCP Server-Initiated Configuration Exchange 2512 A server initiates a configuration exchange to cause DHCP clients 2513 to obtain new addresses and other configuration information. For 2514 example, an administrator may use a server-initiated configuration 2515 exchange when links in the DHCP domain are to be renumbered. Other 2516 examples include changes in the location of directory servers, 2517 addition of new services such as printing, and availability of new 2518 software (system or application). 2520 20.1. Server Behavior 2522 A server sends a Reconfigure message to cause a client to initiate 2523 immediately a Renew/Reply or Information-request/Reply message 2524 exchange with the server. 2526 20.1.1. Creation and transmission of Reconfigure messages 2528 The server sets the "msg-type" field to RECONFIGURE. The server 2529 generates a transaction-ID and inserts it in the "transaction-ID" 2530 field. The server places its identifier in a Server Identifier 2531 option. 2533 The server MAY include an Option Request option to inform the client 2534 of what information has been changed or new information that has been 2535 added. In particular, the server specifies the IA option in the 2536 Option Request option if the server wants the client to obtain new 2537 address information. 2539 The server MUST include an authentication option with the appropriate 2540 settings and add that option as the last option in the "options" 2541 field of the Reconfigure message. 2543 The server MUST NOT include any other options in the Reconfigure 2544 except as specifically allowed in the definition of individual 2545 options. 2547 A server sends each Reconfigure message to a single DHCP client, 2548 using an IPv6 unicast address of sufficient scope belonging to the 2549 DHCP client. The server may obtain the address of the client through 2550 the information that the server has about clients that have been in 2551 contact with the server, or the server may be configured with the 2552 address of the client through some external agent. 2554 To reconfigure more than one client, the server unicasts a separate 2555 message to each client. The server may initiate the reconfiguration 2556 of multiple clients concurrently; for example, a server may 2557 send a Reconfigure message to additional clients while previous 2558 reconfiguration message exchanges are still in progress. 2560 The Reconfigure message causes the client to initiate a Renew/Reply 2561 or Information-request/Reply message exchange with the server. The 2562 server interprets the receipt of a Renew or Information-request 2563 message from the client as satisfying the Reconfigure message 2564 request. 2566 20.1.2. Time out and retransmission of Reconfigure messages 2568 If the server does not receive a Renew or Information-request message 2569 from the client in RECREP_MSG_TIMEOUT milliseconds, the server 2570 retransmits the Reconfigure message, doubles the RECREP_MSG_TIMEOUT 2571 value and waits again. The server continues this process until 2572 REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point 2573 the server SHOULD abort the reconfigure process for that client. 2575 Default and initial values for RECREP_MSG_TIMEOUT and 2576 REC_MSG_ATTEMPTS are documented in section 7.5. 2578 20.1.3. Receipt of Renew messages 2580 The server generates and sends Reply message(s) to the client as 2581 described in section 19.2.8, including in the "options" field new 2582 values for configuration parameters. 2584 It is possible that the client may send a Renew message after the 2585 server has sent a Reconfigure but before the Reconfigure is received 2586 by the client. In this case, the Renew message from the client 2587 may not include all of the IAs and requests for parameters to be 2588 reconfigured by the server. To accommodate this scenario, the server 2589 MAY choose to send a Reply with the IAs and other parameters to be 2590 reconfigured, even if those IAs and parameters were not in the Renew 2591 message from the client. 2593 20.2. Receipt of Information-request messages 2595 If the server has assigned addresses to one or more IAs that belong 2596 to the responding client, the server MUST silently discard the 2597 Information-request message. 2599 If the client has requested options in an Option Request option that 2600 the server is unable to provide to the client, the server MAY send 2601 a Reply message with only those options it can provide. If the 2602 server sends a Reply message that does not include all of the options 2603 requested by the client, it MUST include a Status Code option with 2604 code OptionUnavail. 2606 The server generates and sends Reply message(s) to the client as 2607 described in section 19.2.8, including in the "options" field new 2608 values for configuration parameters. 2610 It is possible that the client may send an Information-request 2611 message after the server has sent a Reconfigure but before 2612 the Reconfigure is received by the client. In this case, the 2613 Information-request message from the client may not request all of 2614 the parameters to be reconfigured by the server. To accommodate 2615 this scenario, the server MAY choose to send a Reply with the other 2616 parameters to be reconfigured, even if those parameters were not 2617 specified in the Information-request message from the client. 2619 20.3. Client Behavior 2621 A client MUST always monitor UDP port 546 for Reconfigure messages 2622 on interfaces for which it has acquired DHCP parameters. Since the 2623 results of a reconfiguration event may affect application layer 2624 programs, the client SHOULD log these events, and MAY notify these 2625 programs of the change through an implementation-specific interface. 2627 20.3.1. Receipt of Reconfigure messages 2629 Upon receipt of a valid Reconfigure message, the client initiates a 2630 transaction with the server. While the transaction is in progress, 2631 the client silently discards any Reconfigure messages it receives. 2633 If the client has IAs with addresses that have been assigned by the 2634 server from which the Reconfigure message was received, the client 2635 MUST respond with a Renew message. Otherwise, the client responds 2636 with an Information-request message. 2638 DISCUSSION: 2640 The Reconfigure message acts as a trigger that signals the 2641 client to complete a successful message exchange. Once 2642 the client has received a Reconfigure, the client proceeds 2643 with the message exchange (retransmitting the Renew or 2644 Information-request message if necessary); the client 2645 ignores any additional Reconfigure messages (regardless 2646 of the transaction ID in the Reconfigure message) until 2647 the exchange is complete. Subsequent Reconfigure messages 2648 (again independent of the transaction ID) cause the client 2649 to initiate a new exchange. 2651 How does this mechanism work in the face of duplicated or 2652 retransmitted Reconfigure messages? Duplicate messages 2653 will be ignored because the client will begin the exchange 2654 after the receipt of the first Reconfigure. Retransmitted 2655 messages will either trigger the exchange (if the first 2656 Reconfigure was not received by the client) or will be 2657 ignored. The server can discontinue retransmission of 2658 Reconfigure messages to the client once the server receives 2659 the Renew or Information-request message from the client. 2661 It might be possible for a duplicate or retransmitted 2662 Reconfigure to be sufficiently delayed (and delivered out of 2663 order) to arrive at the client after the exchange (initiated 2664 by the original Reconfigure) has been completed. In this 2665 case, the client would initiate a redundant exchange. The 2666 likelihood of delayed and out of order delivery is small 2667 enough to be ignored. The consequence of the redundant 2668 exchange is inefficiency rather than incorrect operation. 2670 20.3.2. Creation and transmission of Renew messages 2672 When responding to a Reconfigure, the client creates and sends 2673 the Renew message in exactly the same manner as outlined in 2674 section 19.1.3, with the exception: if the server included on Option 2675 Request option specifying the IA option, the client MUST include IA 2676 options containing the addresses the client currently has assigned to 2677 ALL IAs for the interface through which the Reconfigure message was 2678 received. 2680 20.3.3. Creation and transmission of Information-request messages 2682 When responding to a Reconfigure, the client creates and sends the 2683 Information-request message in exactly the same manner as outlined in 2684 section 19.1.5, with the exception that the client includes a Server 2685 Identifier option with the identifier from the Reconfigure message to 2686 which the client is responding. 2688 20.3.4. Time out and retransmission of Renew or Information-request 2689 messages 2691 The client uses the same variables and retransmission algorithm as 2692 it does with Renew or Information-request messages generated as part 2693 of a client-initiated configuration exchange. See sections 19.1.3 2694 and 19.1.5 for details. 2696 20.3.5. Receipt of Reply messages 2698 Upon the receipt of a valid Reply message, the client extracts the 2699 contents of the "options" field, and sets (or resets) configuration 2700 parameters appropriately. The client records and updates the 2701 lifetimes for any addresses specified in IAs in the Reply message. 2702 If the configuration parameters changed were requested by the 2703 application layer, the client notifies the application layer of the 2704 changes using an implementation-specific interface. 2706 21. Relay Behavior 2708 For this discussion, the Relay MAY be configured to use a list of 2709 server destination addresses, which MAY include unicast addresses, 2710 the All_DHCP_Servers multicast address, or other multicast addresses 2711 selected by the network administrator. If the Relay has not been 2712 explicitly configured, it MUST use the All_DHCP_Servers multicast 2713 address as the default. 2715 21.1. Relaying of client messages 2717 When a Relay receives a valid client message, it constructs a 2718 Relay-forward message. The relay places an address with a prefix 2719 assigned to the link on which the client should be assigned an 2720 address in the link-address field. This address will be used by the 2721 server to determine the link from which the client should be assigned 2722 an address and other configuration information. 2724 If the relay cannot use the address in the link-address field to 2725 identify the interface through which the response to the client will 2726 be forwarded, the relay MUST include an Interface-id option (see 2727 section 23.17) in the Relay-forward message. The server will include 2728 the Interface-id option in its Relay-reply message. 2730 The relay copies the source address from the IP datagram in which the 2731 message was received from the client into the client-return-address 2732 field in the Relay-forward message. 2734 The relay constructs a "client-message" option 23.10 that contains 2735 the entire message from the client in the data field of the 2736 option. The relay places the "relay-message" option along with any 2737 "relay-specific" options in the options field of the Relay-forward 2738 message. The Relay MUST send the Relay-forward message to the list 2739 of server destination addresses with which it has been configured. 2741 21.2. Relaying of server messages 2743 When the relay receives a Relay-reply message, it extracts the server 2744 message from the "server-message" option. If the Relay-reply message 2745 includes a Interface-id option, the relay forwards the message from 2746 the server to the client on the link identified by the Interface-id 2747 option. Otherwise, the relay forwards the message on the link 2748 identified by the link-address field. In either case, the relay 2749 forwards the message to the address in the client-return-address 2750 field in the Relay-reply message. 2752 22. Authentication of DHCP messages 2754 Some network administrators may wish to provide authentication of 2755 the source and contents of DHCP messages. For example, clients may 2756 be subject to denial of service attacks through the use of bogus 2757 DHCP servers, or may simply be misconfigured due to unintentionally 2758 instantiated DHCP servers. Network administrators may wish to 2759 constrain the allocation of addresses to authorized hosts to avoid 2760 denial of service attacks in "hostile" environments where the network 2761 medium is not physically secured, such as wireless networks or 2762 college residence halls. 2764 Because of the risk of denial of service attacks against DHCP 2765 clients, the use of authentication is mandated in Reconfigure 2766 messages. A DHCP server MUST include an authentication option in 2767 Reconfigure messages sent to clients. 2769 The DHCP authentication mechanism is based on the design of 2770 authentication for DHCP for IPv4 [8]. 2772 22.1. DHCP threat model 2774 The threat to DHCP is inherently an insider threat (assuming a 2775 properly configured network where DHCPv6 ports are blocked on the 2776 perimeter gateways of the enterprise). Regardless of the gateway 2777 configuration, however, the potential attacks by insiders and 2778 outsiders are the same. 2780 The attack specific to a DHCP client is the possibility of the 2781 establishment of a "rogue" server with the intent of providing 2782 incorrect configuration information to the client. The motivation 2783 for doing so may be to establish a "man in the middle" attack or it 2784 may be for a "denial of service" attack. 2786 There is another threat to DHCP clients from mistakenly or 2787 accidentally configured DHCP servers that answer DHCP client requests 2788 with unintentionally incorrect configuration parameters. 2790 The threat specific to a DHCP server is an invalid client 2791 masquerading as a valid client. The motivation for this may be for 2792 "theft of service", or to circumvent auditing for any number of 2793 nefarious purposes. 2795 The threat common to both the client and the server is the resource 2796 "denial of service" (DoS) attack. These attacks typically involve 2797 the exhaustion of valid addresses, or the exhaustion of CPU or 2798 network bandwidth, and are present anytime there is a shared 2799 resource. In current practice, redundancy mitigates DoS attacks the 2800 best. 2802 22.2. Security of messages sent between servers and relay agents 2804 Relay agents and servers that choose to exchange messages securely 2805 use the IPsec mechanisms for IPv6 [10]. The way in which IPsec 2806 is employed by relay agents and servers is not specified in this 2807 document. 2809 22.3. Summary of DHCP authentication 2811 Authentication of DHCP messages is accomplished through the use of 2812 the Authentication option. The authentication information carried 2813 in the Authentication option can be used to reliably identify the 2814 source of a DHCP message and to confirm that the contents of the DHCP 2815 message have not been tampered with. 2817 The Authentication option provides a framework for multiple 2818 authentication protocols. Two such protocols are defined here. 2819 Other protocols defined in the future will be specified in separate 2820 documents. 2822 The protocol field in the Authentication option identifies the 2823 specific protocol used to generate the authentication information 2824 carried in the option. The algorithm field identifies a specific 2825 algorithm within the authentication protocol; for example, the 2826 algorithm field specifies the hash algorithm used to generate the 2827 message authentication code (MAC) in the authentication option. The 2828 replay detection method (RDM) field specifies the type of replay 2829 detection used in the replay detection field. 2831 22.4. Replay detection 2833 The Replay Detection Method (RDM) field determines the type of replay 2834 detection used in the Replay Detection field. 2836 If the RDM field contains 0x00, the replay detection field MUST be 2837 set to the value of a monotonically increasing counter. Using a 2838 counter value such as the current time of day (e.g., an NTP-format 2839 timestamp [12]) can reduce the danger of replay attacks. This method 2840 MUST be supported by all protocols. 2842 22.5. Configuration token protocol 2844 If the protocol field is 0, the authentication information field 2845 holds a simple configuration token. The configuration token is an 2846 opaque, unencoded value known to both the sender and receiver. The 2847 sender inserts the configuration token in the DHCP message and the 2848 receiver matches the token from the message to the shared token. If 2849 the configuration option is present and the token from the message 2850 does not match the shared token, the receiver MUST discard the 2851 message. 2853 Configuration token may be used to pass a plain-text configuration 2854 token and provides only weak entity authentication and no message 2855 authentication. This protocol is only useful for rudimentary 2856 protection against inadvertently instantiated DHCP servers. 2858 DISCUSSION: 2860 The intent here is to pass a constant, non-computed token 2861 such as a plain-text password. Other types of entity 2862 authentication using computed tokens such as Kerberos 2863 tickets or one-time passwords will be defined as separate 2864 protocols. 2866 22.6. Delayed authentication protocol 2868 If the protocol field is 1, the message is using the "delayed 2869 authentication" mechanism. In delayed authentication, the client 2870 requests authentication in its Solicit message and the server replies 2871 with an Advertise message that includes authentication information. 2872 This authentication information contains a nonce value generated by 2873 the source as a message authentication code (MAC) to provide message 2874 authentication and entity authentication. 2876 The use of a particular technique based on the HMAC protocol [11] 2877 using the MD5 hash [20] is defined here. 2879 22.6.1. Management issues in the delayed authentication protocol 2881 The "delayed authentication" protocol does not attempt to address 2882 situations where a client may roam from one administrative domain 2883 to another, i.e. interdomain roaming. This protocol is focused on 2884 solving the intradomain problem where the out-of-band exchange of a 2885 shared secret is feasible. 2887 22.6.2. Use of the Authentication option in the delayed authentication 2888 protocol 2890 In a Solicit message, the Authentication option carries the Protocol, 2891 Algorithm, RDM and Replay detection fields, but no Authentication 2892 information. 2894 In an Advertise, Request, Renew, Rebind, Confirm, Decline, Release 2895 or Information-request message, the Authentication option carries 2896 the Protocol, Algorithm, RDM and Replay detection fields and 2897 Authentication information. 2899 The format of the Authentication information is: 2901 0 1 2 3 2902 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 2903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2904 | Secret ID (32 bits) | 2905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2906 | | 2907 | HMAC-MD5 (128 bits) | 2908 | | 2909 | | 2910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2912 The following definitions will be used in the description of the 2913 authentication information for delayed authentication, algorithm 1: 2915 Replay Detection - as defined by the RDM field 2916 K - a secret value shared between the source and 2917 destination of the message; each secret has a 2918 unique identifier (secret ID) 2919 secret ID - the unique identifier for the secret value 2920 used to generate the MAC for this message 2921 HMAC-MD5 - the MAC generating function. 2923 The sender computes the MAC using the HMAC generation algorithm [11] 2924 and the MD5 hash function [20]. The entire DHCP message (except 2925 the MAC field of the authentication option itself), including the 2926 DHCP message header and the options field, is used as input to the 2927 HMAC-MD5 computation function. The 'secret ID' field MUST be set to 2928 the identifier of the secret used to generate the MAC. 2930 DISCUSSION: 2932 Algorithm 1 specifies the use of HMAC-MD5. Use of a 2933 different technique, such as HMAC-SHA, will be specified as 2934 a separate protocol. 2936 Delayed authentication requires a shared secret key for each 2937 client on each DHCP server with which that client may wish 2938 to use the DHCP protocol. Each secret key has a unique 2939 identifier that can be used by a receiver to determine which 2940 secret was used to generate the MAC in the DHCP message. 2941 Therefore, delayed authentication may not scale well in an 2942 architecture in which a DHCP client connects to multiple 2943 administrative domains. 2945 22.6.3. Message validation 2947 To validate an incoming message, the receiver first checks that 2948 the value in the replay detection field is acceptable according 2949 to the replay detection method specified by the RDM field. Next, 2950 the receiver computes the MAC as described in [11]. The receiver 2951 MUST set the 'MAC' field of the authentication option to all 0s for 2952 computation of the MAC. If the MAC computed by the receiver does not 2953 match the MAC contained in the authentication option, the receiver 2954 MUST discard the DHCP message. 2956 22.6.4. Key utilization 2958 Each DHCP client has a key, K. The client uses its key to encode 2959 any messages it sends to the server and to authenticate and verify 2960 any messages it receives from the server. The client's key SHOULD 2961 be initially distributed to the client through some out-of-band 2962 mechanism, and SHOULD be stored locally on the client for use in all 2963 authenticated DHCP messages. Once the client has been given its key, 2964 it SHOULD use that key for all transactions even if the client's 2965 configuration changes; e.g., if the client is assigned a new network 2966 address. 2968 Each DHCP server MUST know, or be able to obtain in a secure manner, 2969 the keys for all authorized clients. If all clients use the same 2970 key, clients can perform both entity and message authentication for 2971 all messages received from servers. However, the sharing of keys 2972 is strongly discouraged as it allows for unauthorized clients to 2973 masquerade as authorized clients by obtaining a copy of the shared 2974 key. To authenticate the identity of individual clients, each client 2975 MUST be configured with a unique key. 2977 22.6.5. Client considerations for delayed authentication protocol 2979 22.6.5.1. Sending Solicit messages 2981 When the client sends a Solicit message and wishes to use 2982 authentication, it includes an Authentication option with the desired 2983 protocol, algorithm, RDM and replay detection field as described 2984 in section 22.6. The client does not include any authentication 2985 information in the Authentication option. 2987 22.6.5.2. Receiving Advertise messages 2989 The client validates any Advertise messages containing an 2990 Authentication option specifying the delayed authentication protocol 2991 using the validation test described in section 22.6.3. 2993 Client behavior if no Advertise messages include authentication 2994 information or pass the validation test is controlled by local policy 2995 on the client. According to client policy, the client MAY choose to 2996 respond to a Advertise message that has not been authenticated. 2998 The decision to set local policy to accept unauthenticated messages 2999 should be made with care. Accepting an unauthenticated Advertise 3000 message can make the client vulnerable to spoofing and other 3001 attacks. If local users are not explicitly informed that the client 3002 has accepted an unauthenticated Advertise message, the users may 3003 incorrectly assume that the client has received an authenticated 3004 address and is not subject to DHCP attacks through unauthenticated 3005 messages. 3007 A client MUST be configurable to discard unauthenticated messages, 3008 and SHOULD be configured by default to discard unauthenticated 3009 messages. A client MAY choose to differentiate between Advertise 3010 messages with no authentication information and Advertise messages 3011 that do not pass the validation test; for example, a client might 3012 accept the former and discard the latter. If a client does accept an 3013 unauthenticated message, the client SHOULD inform any local users and 3014 SHOULD log the event. 3016 22.6.5.3. Sending Request, Confirm, Renew, Rebind, Decline or Release 3017 messages 3019 If the client authenticated the Advertise message through which the 3020 client selected the server, the client MUST generate authentication 3021 information for subsequent Request, Confirm, Renew, Rebind or Release 3022 messages sent to the server as described in section 22.6. When the 3023 client sends a subsequent message, it MUST use the same secret used 3024 by the server to generate the authentication information. 3026 22.6.5.4. Sending Information-request messages 3028 If the client has negotiated a secret with the server through a 3029 previous message exchange, the client MUST use the same secret used 3030 by the server to generate the authentication information. If the 3031 client has not negotiated a secret with the server, the client MUST 3032 use a secret that has been selected for the client through some 3033 external mechanism. 3035 22.6.5.5. Receiving Reply messages 3037 If the client authenticated the Advertise it accepted, the client 3038 MUST validate the associated Reply message from the server. The 3039 client MUST discard the Reply if the message fails to pass validation 3040 and MAY log the validation failure. If the Reply fails to pass 3041 validation, the client MUST restart the DHCP configuration process by 3042 sending a Solicit message. The client MAY choose to remember which 3043 server replied with a Reply message that failed to pass validation 3044 and discard subsequent messages from that server. 3046 If the client accepted an Advertise message that did not include 3047 authentication information or did not pass the validation test, the 3048 client MAY accept an unauthenticated Reply message from the server. 3050 22.6.5.6. Receiving Reconfigure messages 3052 The client MUST validate the Reconfigure message from the server. 3053 The client MUST discard the Reconfigure if the message fails to pass 3054 validation and MAY log the validation failure. 3056 22.6.6. Server considerations for delayed authentication protocol 3058 22.6.6.1. Receiving Solicit messages and Sending Advertise messages 3060 The server selects a secret for the client and includes 3061 authentication information in the Advertise message returned to the 3062 client as specified in section 22.6. The server MUST record the 3063 identifier of the secret selected for the client and use that same 3064 secret for validating subsequent messages with the client. 3066 22.6.6.2. Receiving Request, Confirm, Renew, Rebind or Release messages 3067 and Sending Reply messages 3069 The server uses the secret identified in the message and validates 3070 the message as specified in section 22.6.3. If the message fails to 3071 pass validation or the server does not know the secret identified by 3072 the 'secret ID' field, the server MUST discard the message and MAY 3073 choose to log the validation failure. 3075 If the message passes the validation procedure, the server responds 3076 to the specific message as described in section 19.2. The server 3077 MUST include authentication information generated using the secret 3078 identified in the received message as specified in section 22.6. 3080 22.6.6.3. Sending Reconfigure messages 3082 The server MUST include authentication information in a Reconfigure 3083 message, generated as specified in section 22.6 using the secret the 3084 server initially negotiated with the client to which the Reconfigure 3085 message is to be sent. 3087 If the server has not previously negotiated a secret with the client, 3088 the server MUST use a secret that has been selected for the client 3089 through some external mechanism. 3091 23. DHCP options 3093 Options are used to carry additional information and parameters 3094 in DHCP messages. Every option shares a common base format, as 3095 described in section 23.1. All values in options is represented in 3096 network order. 3098 This document describes the DHCP options defined as part of the base 3099 DHCP specification. Other options may be defined in the future in a 3100 separate document. 3102 23.1. Format of DHCP options 3104 0 1 2 3 3105 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 3106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3107 | option-code | option-len | 3108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3109 | option-data | 3110 | (option-len octets) | 3111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3113 option-code An unsigned integer identifying the specific option 3114 type carried in this option. 3116 option-len An unsigned integer giving the length of the 3117 option-data field in this option in octets. 3119 option-data The data for the option; the format of this data 3120 depends on the definition of the option. 3122 DHCPv6 options are scoped by using encapsulation. Some options apply 3123 generally to the client, some are specific to an IA, and some are 3124 specific to the addresses within an IA. These latter two cases are 3125 discussed in sections 23.4 and 23.5. 3127 23.2. Client Identifier option 3129 The Client Identifier option is used to carry a DUID identifying a 3130 client between a client and a server. The Client Identifier option 3131 MUST appear before any IA options in the DHCP message. The format of 3132 the DUID option is: 3134 0 1 2 3 3135 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 3136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3137 | OPTION_CLIENTID | option-len | 3138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3139 . . 3140 . DUID . 3141 . (variable length) . 3142 . . 3143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3145 option-code OPTION_CLIENTID (TBD) 3147 option-len Length of DUID in octets 3149 option-data The DUID for the client 3151 23.3. Server Identifier option 3153 The Server Identifier option is used to carry a DUID identifying 3154 a server between a client and a server. The format of the Server 3155 Identifier option is: 3157 0 1 2 3 3158 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 3159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3160 | OPTION_SERVERID | option-len | 3161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3162 . . 3163 . DUID . 3164 . (variable length) . 3165 . . 3166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3168 option-code OPTION_SERVERID (TBD) 3170 option-len Length of DUID in octets 3172 option-data The DUID for the server 3174 23.4. Identity association option 3176 The identity association option is used to carry an identity 3177 association, the parameters associated with the IA and the addresses 3178 assigned to the IA. 3180 The format of the IA option is: 3182 0 1 2 3 3183 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 3184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3185 | OPTION IA | option-len | 3186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3187 | IAID (4 octets) | 3188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3189 | T1 | 3190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3191 | T2 | 3192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3193 | IA Status | | 3194 +-+-+-+-+-+-+-+-+ | 3195 . Options . 3196 . . 3197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3199 option-code OPTION_IA (TBD) 3201 option-len See section 23. 3203 IAID The unique identifier for this IA. 3205 T1 The time at which the client contacts the 3206 server from which the addresses in the IA 3207 were obtained to extend the lifetimes of the 3208 addresses assigned to the IA. 3210 T2 The time at which the client contacts any 3211 available server to extend the lifetimes of 3212 the addresses assigned to the IA. 3214 IA status Status of the IA in this option. 3216 options Options associated with this IA. 3218 The Options field encapsulates those options that are specific 3219 to this IA. For example, all of the Address Options carrying the 3220 addresses associated with this IA are in the Options field. 3222 Note that an IA has no explicit "lifetime" or "lease length" of 3223 its own. When the lifetimes of all of the addresses in an IA have 3224 expired, the IA can be considered as having expired. T1 and T2 3225 are included to give servers explicit control over when a client 3226 recontacts the server about a specific IA. 3228 In a message sent by a client to a server, values in the T1 and 3229 T2 fields indicate the client's preference for those parameters. 3230 The client may send 0 if it has no preference for T1 and T2. In a 3231 message sent by a server to a client, the client MUST use the values 3232 in the T1 and T2 fields for the T1 and T2 parameters. The values in 3233 the T1 and T2 fields are the number of seconds until T1 and T2. 3235 The server MUST set the T1 and T2 times to values that will allow 3236 the client to extend as appropriate the lifetimes of any addresses 3237 in the IA. If the server does not intend for a client to extend the 3238 lifetimes of a particular address in an IA, the server MAY set the 3239 renewal time values to occur after the lifetimes on that address 3240 expire. 3242 T1 is the time at which the client SHOULD begin the lifetime 3243 extension process by sending a Renew message to the server that 3244 originally assigned the addresses to the IA. T2 is the time at which 3245 the client SHOULD start sending a Rebind message to any server. A 3246 client MAY begin the lifetime extension process prior to T1 if it 3247 needs additional addresses for some reason. 3249 T1 and T2 are specified as unsigned integers that specify the time 3250 in seconds relative to the time at which the messages containing the 3251 option is received. 3253 23.5. IA Address option 3255 The IA Address option is used to specify IPv6 addresses associated 3256 with an IA. The IA Address option must be encapsulated in the 3257 Options field of an Identity Association option. The Options field 3258 encapsulates those options that are specific to this address. 3260 The format of the IA Address option is: 3262 0 1 2 3 3263 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 3264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3265 | OPTION_IAADDR | option-len | 3266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3267 |T| addr status | prefix length | | 3268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3269 | IPv6 address | 3270 | (16 octets) | 3271 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3272 | | preferred lifetime | 3273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3274 | pref. lifetime (cont.) | valid lifetime | 3275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3276 | valid lifetime (cont.) | | 3277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3278 . . 3279 . Options . 3280 . . 3281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3283 option-code OPTION_IADDR (TBD) 3285 option-len See section 23. 3287 T When set to 1, indicates that this address is a 3288 "temporary address" [16]; when set to 0, the address 3289 is not a temporary address. 3291 addr status Status of this address in this IA. 3293 prefix length Prefix length for this address. 3295 IPv6 address An IPv6 address 3297 preferred lifetime The preferred lifetime for the IPv6 address in 3298 the option. 3300 valid lifetime The valid lifetime for the IPv6 address in the 3301 option 3303 options Options associated with this address 3305 In a message sent by a client to a server, values in the preferred 3306 and valid lifetime fields indicate the client's preference for those 3307 parameters. The client may send 0 if it has no preference for the 3308 preferred and valid lifetimes. In a message sent by a server to a 3309 client, the client MUST use the values in the preferred and valid 3310 lifetime fields for the preferred and valid lifetimes. The values in 3311 the preferred and valid lifetimes are the number of seconds remaining 3312 in each lifetime. 3314 One or more IA Address Options can appear anywhere in an IA option. 3316 23.6. Requested Temporary Addresses (RTA) Option 3318 The Requested Temporary Addresses (RTA) option is used by a client to 3319 request a server to assign additional temporary addresses to an IA. 3321 0 1 2 3 3322 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 3323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3324 | OPTION_RTA | option-len | 3325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3326 | num-requested | 3327 +-+-+-+-+-+-+-+-+ 3329 option-code OPTION_RTA (TBD) 3331 option-len See section 23. 3333 num-requested The number of additional temporary addresses the 3334 client is requesting. This is an unsigned value. 3336 This option MUST only be sent by a client and only in a Solicit, 3337 Request, Renew, or Rebind message. It MUST only appear encapsulated 3338 within an Identity association option. A client MUST only include 3339 this option when it wants to have additional temporary address 3340 allocated; a client SHOULD NOT send this option if 'num-requested' is 3341 0. 3343 23.7. Option Request option 3345 The Option Request option is used to identify a list of options in a 3346 message between a client and a server. 3348 The format of the Option Request option is: 3350 0 1 2 3 3351 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 3352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3353 | OPTION_ORO | option-len | 3354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3355 | requested-option-code-1 | requested-option-code-2 | 3356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3357 | ... | 3358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3360 option-code OPTION_ORO (TBD) 3362 option-len See section 23. 3364 requested-option-code-n The option code for an option requested by 3365 the client. 3367 A client MAY include an Option Request option in a Solicit, Request, 3368 Renew, Rebind, Confirm or Information-request message to inform the 3369 server about options the client wants the server to send to the 3370 client. 3372 23.8. Preference option 3374 0 1 2 3 3375 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 3376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3377 | OPTION_PREFERENCE | option-len | 3378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3379 | pref value | 3380 +-+-+-+-+-+-+-+-+ 3382 option-code OPTION_PREFERENCE (TBD) 3384 option-len See section 23. 3386 pref value The preference value for the server in this message. 3388 A server MAY include a Preference option in an Advertise message to 3389 control the selection of a server by the client. See section 18.1.3 3390 for the use of the Preference option by the client and the 3391 interpretation of Preference option data value. 3393 23.9. Elapsed Time 3395 0 1 2 3 3396 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 3397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3398 | OPTION_ELAPSED_TIME | option-len | 3399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3400 | elapsed time | 3401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3403 option-code OPTION_ELAPSED_TIME (TBD) 3405 option-len See section 23. 3407 elapsed time The amount of time since the client began its 3408 current DHCP transaction. This time is expressed in 3409 hundredths of a second (10^-2 seconds). 3411 A client MAY include an Elapsed Time option in messages to indicate 3412 how long the client has been trying to complete a DHCP transaction. 3413 Servers and Relay Agents MAY use the data value in this option 3414 as input to policy controlling how a server responds to a client 3415 message. 3417 23.10. Client message option 3419 0 1 2 3 3420 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 3421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3422 | OPTION_CLIENT_MSG | option-len | 3423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3424 | | 3425 . DHCP client message . 3426 . . 3427 . . 3428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3430 option-code OPTION_CLIENT_MSG (TBD) 3432 option-len See section 23. 3434 DHCP client message The message received from the client; 3435 forwarded verbatim to the server. 3437 A relay agent forwards a message from a client to a server as the 3438 contents of a Client Message option in a Relay-forward message. 3440 23.11. Server message option 3442 0 1 2 3 3443 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 3444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3445 | OPTION_SERVER_MSG | option-len | 3446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3447 | | 3448 . DHCP server message . 3449 . . 3450 . . 3451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3453 option-code OPTION_SERVER_MSG (TBD) 3455 option-len See section 23. 3457 DHCP server message The message received from the server; 3458 forwarded verbatim to the client. 3460 A server sends a DHCP message to be forwarded to a client by a relay 3461 agent as the contents of a Server Message option in a Relay-reply 3462 message. 3464 23.12. Authentication option 3466 The Authentication option carries authentication information to 3467 authenticate the identity and contents of DHCP messages. The use of 3468 the Authentication option is described in section 22. If present, 3469 the Authentication option MUST appear as the first option in the DHCP 3470 message. 3472 The format of the Authentication option is: 3474 0 1 2 3 3475 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 3476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3477 | OPTION_AUTH | option-len | 3478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3479 | Protocol | Algorithm | RDM | Replay detect.| 3480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3481 | Replay Detection (64 bits) | 3482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3483 | Replay cont. | Auth. Info | 3484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3485 | | 3486 | Authentication Information | 3487 | | 3488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3490 option-code OPTION_AUTH (TBD) 3492 option-len See section 23. 3494 protocol The authentication protocol used in 3495 this authentication option 3497 algorithm The algorithm used in the 3498 authentication protocol 3500 RDM The replay detection method used in 3501 this authentication option 3503 Replay detection The replay detection information for 3504 the RDM 3506 Authentication information The authentication information, 3507 as specified by the protocol and 3508 algorithm used in this authentication 3509 option 3511 23.13. Server unicast option 3513 The server MAY send this option to a client to indicate to the client 3514 that is allowed to unicast messages to the server. The server 3515 specifies the IPv6 address to which the client is to send unicast 3516 messages in the server-address field. When a client receives this 3517 option, where permissible, the client MAY send messages directly to 3518 the server using the IPv6 address specified in the server-address 3519 field of the option. 3521 Details about when the client may send messages to the server using 3522 unicast are in section 19. 3524 0 1 2 3 3525 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 3526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3527 | OPTION_UNICAST | option-len | 3528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3529 | | 3530 | server-address | 3531 | | 3532 | | 3533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3535 option-code OPTION_UNICAST (TBD) 3537 option-len See section 23. 3539 server-address The IP address to which the client should send 3540 messages delivered using unicast 3542 23.14. Status Code Option 3544 This option returns a status indication related to the DHCP message 3545 in which it appears. 3547 0 1 2 3 3548 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 3549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3550 | OPTION_STATUS_CODE | option-len | 3551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3552 | status-code | status-message | 3553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3554 | ... | 3555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3557 option-code OPTION_STATUS_CODE (TBD) 3559 option-len See section 23. 3561 status-code The numeric code for the status encoded in 3562 this option. The status codes are defined in 3563 section 7.4. 3565 status-message A UTF-8 encoded text string, which MUST NOT 3566 be null-terminated. 3568 23.15. User Class Option 3570 This option is used by a client to identify the type or category of 3571 user or applications it represents. The information contained in the 3572 data area of this option is contained in one or more opaque fields 3573 that represent the user class or classes of which the client is a 3574 member. The user class information carried in this option MUST be 3575 configurable on the client. 3577 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 3578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3579 | OPTION_USER_CLASS | option-len | 3580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3581 | user class data | 3582 | . . . | 3583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3585 option-code TBD 3587 option-len See section 23. 3589 user class data The user classes carried by the client. 3591 The data area of the user class option MUST contain one or more 3592 instances of user class data. Each instance of the user class data 3593 is formatted as follows: 3595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 3596 | user class len | user class data | 3597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 3599 The user class len is two octets long and specifies the length of the 3600 opaque user class data in network order. 3602 Servers can interpret the meanings of multiple class specifications 3603 in an implementation dependent or configuration dependent manner, 3604 and so the use of multiple classes by a DHCP client should be based 3605 on the specific server implementation and configuration which will 3606 be used to process that User class option. Servers not equipped to 3607 interpret the user class information sent by a client MUST ignore it 3608 (although it may be reported). 3610 23.16. Vendor Class Option 3612 This option is used by clients and servers to exchange 3613 vendor-specific information. The definition of this information 3614 is vendor specific. The vendor is indicated in the vendor 3615 class identifier option. Servers not equipped to interpret 3616 the vendor-specific information sent by a client MUST ignore it 3617 (although it may be reported). Clients which do not receive desired 3618 vendor-specific information SHOULD make an attempt to operate without 3619 it, although they may do so (and announce they are doing so) in a 3620 degraded mode. 3622 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 3623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3624 | OPTION_VENDOR_CLASS | option-len | 3625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3626 | vendor-id | 3627 . . 3628 . . 3629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3630 | option-data | 3631 . . 3632 . . 3633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3635 option-code TBD 3637 option-len See section 23. 3639 vendor-id A domain name belonging to the vendor used to 3640 identify the vendor that defined this vendor 3641 class option. 3643 option-data An opaque object of option-len octets, 3644 presumably interpreted by vendor-specific 3645 code on the clients and servers 3647 The vendor-id must adhere to the rules in section 10. 3649 The Encapsulated vendor-specific options field MUST be encoded as 3650 a sequence of code/length/value fields of identical format to the 3651 DHCP options field. Each of the encapsulated options is formatted as 3652 follows. 3654 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 3655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3656 | opt-code | option-len | 3657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3658 | option-data | 3659 | . . . | 3660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3662 opt-code The code for the encapsulated option 3664 option-len See section 23. 3666 option-data The data area for the encapsulated option 3668 23.17. Interface-Id Option 3670 The relay agent MAY send the Interface-id option to identify the 3671 interface on which the client message was received. If a relay 3672 receives a Relay-reply message with an Interface-id option, the relay 3673 forwards the message to the client through the interface identified 3674 by the option 3676 0 1 2 3 3677 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 3678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3679 | OPTION_INTERFACE_ID | option-len | 3680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3681 | | 3682 | Interface-Id | 3683 . . 3684 . . 3685 . . 3686 | | 3687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3689 option-code OPTION_INTERFACE_ID (TBD) 3691 option-len See section 23. 3693 Interface-Id An opaque value of arbitrary length generated 3694 by the relay agent to identify one of the 3695 relay agent's interfaces 3697 The server MUST copy the Interface-Id option from the Relay-Forward 3698 message into the Relay-Reply message the server sends to the relay 3699 agent in response to the Relay-Forward message. This option MUST NOT 3700 appear in any message except a Relay-Forward or Relay-Reply message. 3702 Servers MAY use the Interface-ID for parameter assignment policies. 3703 The Interface-ID SHOULD be considered an opaque value, with policies 3704 based on exact string match only; that is, the Interface-ID SHOULD 3705 NOT be internally parsed by the server. 3707 24. Security Considerations 3709 Section 22 describes a threat model and an option that provides an 3710 authentication framework to defend against that threat model. 3712 25. Year 2000 considerations 3714 Since all times are relative to the current time of the transaction, 3715 there is no problem within the DHCPv6 protocol related to any 3716 hardcoded dates or two-digit representation of the current year. 3718 26. IANA Considerations 3720 This document defines several new name spaces associated with DHCPv6 3721 and DHCPv6 options. IANA is requested to manage the allocation of 3722 values from these name spaces, which are described in the remainder 3723 of this section. These name spaces are all to be managed separately 3724 from the name spaces defined for DHCPv4 [7, 1]. 3726 New values in each of these name spaces should be approved by the 3727 process of IETF consensus [15]. 3729 26.1. Multicast addresses 3731 Section 7.1 defines the following multicast addresses, which have 3732 been assigned by IANA for use by DHCPv6: 3734 All_DHCP_Agents address: FF02::1:2 3736 All_DHCP_Servers address: FF05::1:3 3738 IANA is requested to manage definition of additional multicast 3739 addresses in the future. 3741 26.2. DHCPv6 message types 3743 IANA is requested to record the message types defined in section 7.3. 3744 IANA is requested to manage definition of additional message types in 3745 the future. 3747 26.3. DUID 3749 IANA is requested to record the DUID types defined in section 11.1. 3750 IANA is requested to manage definition of additional DUID types in 3751 the future. 3753 26.4. DHCPv6 options 3755 IANA is requested to assign option-codes to the options defined in 3756 section 23. IANA is requested to manage the definition of additional 3757 DHCPv6 option-codes in the future. 3759 26.5. Status codes 3761 IANA is requested to record the status codes defined in section 7.4. 3762 IANA is requested to manage the definition of additional status codes 3763 in the future. 3765 26.6. Authentication option 3767 Section 22 defines three new name spaces associated with the 3768 Authentication Option (section 23.12), which are to be created and 3769 maintained by IANA: Protocol, Algorithm and RDM. 3771 Initial values assigned from the Protocol name space are 0 (for the 3772 configuration token Protocol in section 22.5) and 1 (for the delayed 3773 authentication Protocol in section 22.6). Additional protocols may 3774 be defined in the future. 3776 The Algorithm name space is specific to individual Protocols. That 3777 is, each Protocol has its own Algorithm name space. The guidelines 3778 for assigning Algorithm name space values for a particular protocol 3779 should be specified along with the definition of a new Protocol. 3781 For the configuration token Protocol, the Algorithm field MUST be 3782 0, as described in section 22.5. For the delayed authentication 3783 Protocol, the Algorithm value 1 is assigned to the HMAC-MD5 3784 generating function as defined in section 22.6. Additional 3785 algorithms for the delayed authentication protocol may be defined in 3786 the future. 3788 The initial value of 0 from the RDM name space is assigned to the 3789 use of a monotonically increasing value as defined in section 22.4. 3790 Additional replay detection methods may be defined in the future. 3792 27. Acknowledgments 3794 Thanks to the DHC Working Group for their time and input into the 3795 specification. In particular, thanks also for the consistent input, 3796 ideas, and review by (in alphabetical order) Thirumalesh Bhat, 3797 Vijayabhaskar, Brian Carpenter, Matt Crawford, Francis Dupont, 3798 Josh Littlefield, Gerald Maguire, Jack McCann, Thomas Narten, Erik 3799 Nordmark, Yakov Rekhter, Mark Stapp, Matt Thomas, Sue Thomson, and 3800 Phil Wells. 3802 Thanks to Steve Deering and Bob Hinden, who have consistently 3803 taken the time to discuss the more complex parts of the IPv6 3804 specifications. 3806 Bill Arbaugh reviewed the authentication mechanism described in 3807 section 22. 3809 And, thanks to Steve Deering for pointing out at IETF 51 in London 3810 that the DHCPv6 specification has the highest revision number of any 3811 Internet Draft. 3813 References 3815 [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 3816 Extensions, March 1997. RFC 2132. 3818 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 3819 Levels, March 1997. RFC 2119. 3821 [3] S. Bradner and A. Mankin. The Recommendation for the IP Next 3822 Generation Protocol, January 1995. RFC 1752. 3824 [4] W.J. Croft and J. Gilmore. Bootstrap Protocol, September 1985. 3825 RFC 951. 3827 [5] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 3828 Specification, December 1998. RFC 2460. 3830 [6] R. Draves. Default Address Selection for IPv6, September 2001. 3831 work in progress. 3833 [7] R. Droms. Dynamic Host Configuration Protocol, March 1997. RFC 3834 2131. 3836 [8] R. Droms, Editor, W. Arbaugh, and Editor. Authentication for 3837 DHCP Messages, June 2001. RFC 3118. 3839 [9] R. Hinden and S. Deering. IP Version 6 Addressing Architecture, 3840 July 1998. RFC 2373. 3842 [10] S. Kent and R. Atkinson. Security Architecture for the Internet 3843 Protocol, November 1998. RFC 2401. 3845 [11] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 3846 for Message Authentication, February 1997. RFC 2104. 3848 [12] David L. Mills. Network Time Protocol (Version 3) 3849 Specification, Implementation, March 1992. RFC 1305. 3851 [13] P.V. Mockapetris. Domain names - concepts and facilities, 3852 November 1987. RFC 1034. 3854 [14] P.V. Mockapetris. Domain names - implementation and 3855 specification, November 1987. RFC 1035. 3857 [15] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 3858 Considerations Section in RFCs, October 1998. RFC 2434. 3860 [16] T. Narten and R. Draves. Privacy Extensions for Stateless 3861 Address Autoconfiguration in IPv6, January 2001. RFC 3041. 3863 [17] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 3864 IP Version 6 (IPv6), December 1998. RFC 2461. 3866 [18] D.C. Plummer. Ethernet Address Resolution Protocol: Or 3867 converting network protocol addresses to 48.bit Ethernet address 3868 for transmission on Ethernet hardware, November 1982. RFC 826. 3870 [19] J. Postel. User Datagram Protocol, August 1980. RFC 768. 3872 [20] R. Rivest. The MD5 Message-Digest Algorithm, April 1992. RFC 3873 1321. 3875 [21] S. Thomson and T. Narten. IPv6 Stateless Address 3876 Autoconfiguration, December 1998. RFC 2462. 3878 [22] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic 3879 Updates in the Domain Name System (DNS UPDATE), April 1997. RFC 3880 2136. 3882 Chair's Address 3884 The working group can be contacted via the current chair: 3886 Ralph Droms 3887 Cisco Systems 3888 300 Apollo Drive 3889 Chelmsford, MA 01824 3891 Phone: (978) 244-4733 3892 E-mail: rdroms@cisco.com 3894 Authors' Addresses 3896 Questions about this memo can be directed to: 3898 Jim Bound 3899 Compaq Computer Corporation 3900 ZK3-3/W20 3901 110 Spit Brook Road 3902 Nashua, NH 03062-2698 3903 USA 3904 Voice: +1 603 884 0062 3905 E-mail: Jim.Bound@compaq.com 3907 Mike Carney 3908 Sun Microsystems, Inc 3909 Mail Stop: UMPK17-202 3910 901 San Antonio Road 3911 Palo Alto, CA 94303-4900 3912 USA 3913 Voice: +1-650-786-4171 3914 E-mail: mwc@eng.sun.com 3916 Charles E. Perkins 3917 Communications Systems Lab 3918 Nokia Research Center 3919 313 Fairchild Drive 3920 Mountain View, California 94043 3921 USA 3922 Voice: +1-650 625-2986 3923 E-mail: charliep@iprg.nokia.com 3924 Fax: +1 650 625-2502 3926 Ted Lemon 3927 Nominum, Inc. 3928 950 Charter Street 3929 Redwood City, CA 94043 3930 E-mail: Ted.Lemon@nominum.com 3932 Bernie Volz 3933 Ericsson 3934 959 Concord St 3935 Framingham, MA 01701 3936 Voice: +1-508-875-3162 3937 Fax: +1-508-875-3018 3938 E-mail: bernie.volz@ericsson.com 3940 Ralph Droms 3941 Cisco Systems 3942 300 Apollo Drive 3943 Chelmsford, MA 01824 3944 USA 3945 Voice: +1 978 479 4733 3946 E-mail: rdroms@cisco.com 3948 A. Appearance of Options in Message Types 3950 The following table indicates with a "*" the options are allowed in 3951 each DHCP message type: 3953 Client Server IA RTA Option Pref Time Client Server 3954 ID ID Request Forw. Forw. 3955 Solicit * * * * 3956 Advert. * * * * * * 3957 Request * * * * * 3958 Confirm * * * * 3959 Renew * * * * * 3960 Rebind * * * * 3961 Decline * * * * * 3962 Release * * * * * 3963 Reply * * * * * * 3964 Reconf. * * * 3965 Inform. * (see note) * 3966 R-forw. * * 3967 R-repl. * * 3969 NOTE: 3971 Only included in Information-Request messages that are sent 3972 in response to a Reconfigure (see section 20.3.3). 3974 Auth Server Status User Vendor 3975 Unica. Code Class Class 3976 Solicit * * * 3977 Advert. * * * 3978 Request * * * 3979 Confirm * * * 3980 Renew * * * 3981 Rebind * * * 3982 Decline * * * * 3983 Release * * * * 3984 Reply * * * 3985 Reconf. * 3986 Inform. * * * 3987 R-forw. * * 3988 R-repl. * * 3990 B. Appearance of Options in the Options Field of DHCP Messages 3992 The following table indicates with a "*" where options can appear in 3993 the options field or encapsulated in other options: 3995 Option IA IAADDR RTA Client Server 3996 Field Forw. Forw. 3997 Client msg. * * 3998 Server msg. * * 3999 DUID * 4000 IA * 4001 IAADDR * 4002 RTA * 4003 ORO * 4004 Pref * 4005 Time * 4006 Client Forw. * 4007 Server Forw. * 4008 DSTM Addr. * 4009 DSTM Tunnel * 4010 Authentic. * 4011 Server Uni. * 4012 Dom. Srch. * 4013 Dom. Server * 4014 Status Cod. * * * 4015 Circ. ID * * 4016 User Class * 4017 Vend. Class * 4019 C. Full Copyright Statement 4021 Copyright (C) The Internet Society (2001). All Rights Reserved. 4023 This document and translations of it may be copied and furnished to 4024 others, and derivative works that comment on or otherwise explain it 4025 or assist in its implementation may be prepared, copied, published 4026 and distributed, in whole or in part, without restriction of any 4027 kind, provided that the above copyright notice and this paragraph 4028 are included on all such copies and derivative works. However, 4029 this document itself may not be modified in any way, such as by 4030 removing the copyright notice or references to the Internet Society 4031 or other Internet organizations, except as needed for the purpose 4032 of developing Internet standards in which case the procedures 4033 for copyrights defined in the Internet Standards process must be 4034 followed, or as required to translate it into languages other than 4035 English. 4037 The limited permissions granted above are perpetual and will not be 4038 revoked by the Internet Society or its successors or assigns. 4040 This document and the information contained herein is provided on an 4041 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4042 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4043 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4044 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4045 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.