idnits 2.17.1 draft-ietf-dhc-dhcpv6-22.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 86 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 ([23]), 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-21.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-21.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 (21 Dec 2001) is 8161 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2460 (ref. '7') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2373 (ref. '10') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2401 (ref. '11') (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '12') ** Obsolete normative reference: RFC 1305 (ref. '13') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2434 (ref. '16') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3041 (ref. '17') (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 2461 (ref. '18') (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '21') -- Possible downref: Non-RFC (?) normative reference: ref. '22' ** Obsolete normative reference: RFC 2462 (ref. '23') (Obsoleted by RFC 4862) Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 7 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-21.txt Sun Microsystems, Inc 5 C. Perkins 6 Nokia Research Center 7 R. Droms(ed.) 8 Cisco Systems 9 21 Dec 2001 11 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 12 draft-ietf-dhc-dhcpv6-22.txt 14 Status of This Memo 16 This document is a submission by the Dynamic Host Configuration 17 Working Group of the Internet Engineering Task Force (IETF). Comments 18 should be submitted to the dhcwg@ietf.org mailing list. 20 Distribution of this memo is unlimited. 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, 25 and its working groups. Note that other groups may also distribute 26 working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at 30 any time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at: 34 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at: 36 http://www.ietf.org/shadow.html. 38 Abstract 40 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables 41 DHCP servers to pass configuration parameters such as IPv6 network 42 addresses to IPv6 nodes. It offers the capability of automatic 43 allocation of reusable network addresses and additional configuration 44 flexibility. This protocol is a stateful counterpart to "IPv6 45 Stateless Address Autoconfiguration" [23], and can be used separately 46 or concurrently with the latter to obtain configuration parameters. 48 Contents 50 Status of This Memo i 52 Abstract i 54 1. Introduction 1 56 2. Requirements 2 58 3. Background 2 60 4. Design Goals 3 62 5. Non-Goals 4 64 6. Terminology 4 65 6.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 4 66 6.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 5 68 7. DHCP Constants 7 69 7.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 7 70 7.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 7 71 7.3. DHCP message types . . . . . . . . . . . . . . . . . . . 8 72 7.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 9 73 7.4.1. Generic Status Codes . . . . . . . . . . . . . . 9 74 7.4.2. Server-specific Status Codes . . . . . . . . . . 11 75 7.5. Configuration Variables . . . . . . . . . . . . . . . . . 11 77 8. Message Formats 12 78 8.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 12 79 8.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 12 80 8.3. DHCP Request Message Format . . . . . . . . . . . . . . . 13 81 8.4. DHCP Confirm Message Format . . . . . . . . . . . . . . . 13 82 8.5. DHCP Renew Message Format . . . . . . . . . . . . . . . . 13 83 8.6. DHCP Rebind Message Format . . . . . . . . . . . . . . . 14 84 8.7. DHCP Reply Message Format . . . . . . . . . . . . . . . . 14 85 8.8. DHCP Release Message Format . . . . . . . . . . . . . . . 14 86 8.9. DHCP Decline Message Format . . . . . . . . . . . . . . . 14 87 8.10. DHCP Reconfigure Message Format . . . . . . . . . . . . . 15 88 8.11. Information-Request Message Format . . . . . . . . . . . 15 90 9. Relay messages 16 91 9.1. Relay-forward message . . . . . . . . . . . . . . . . . . 16 92 9.2. Relay-reply message . . . . . . . . . . . . . . . . . . . 17 94 10. Representation and use of domain names 17 96 11. DHCP unique identifier (DUID) 17 97 11.1. DUID contents . . . . . . . . . . . . . . . . . . . . . . 18 98 11.2. DUID based on link-layer address plus time . . . . . . . 18 99 11.3. Vendor-assigned unique ID . . . . . . . . . . . . . . . . 19 100 11.4. Link-layer address . . . . . . . . . . . . . . . . . . . 20 102 12. Identity association 20 104 13. Selecting addresses for assignment to an IA 21 106 14. Management of temporary addresses 22 108 15. Reliability of Client Initiated Message Exchanges 23 110 16. Message validation 24 111 16.1. Use of Transaction-ID field . . . . . . . . . . . . . . . 25 112 16.2. Solicit message . . . . . . . . . . . . . . . . . . . . . 25 113 16.3. Advertise message . . . . . . . . . . . . . . . . . . . . 25 114 16.4. Request message . . . . . . . . . . . . . . . . . . . . . 25 115 16.5. Confirm message . . . . . . . . . . . . . . . . . . . . . 25 116 16.6. Renew message . . . . . . . . . . . . . . . . . . . . . . 26 117 16.7. Rebind message . . . . . . . . . . . . . . . . . . . . . 26 118 16.8. Decline messages . . . . . . . . . . . . . . . . . . . . 26 119 16.9. Release message . . . . . . . . . . . . . . . . . . . . . 26 120 16.10. Reply message . . . . . . . . . . . . . . . . . . . . . . 26 121 16.11. Reconfigure message . . . . . . . . . . . . . . . . . . . 27 122 16.12. Inform message . . . . . . . . . . . . . . . . . . . . . 27 123 16.13. Relay-forward message . . . . . . . . . . . . . . . . . . 27 124 16.14. Relay-reply message . . . . . . . . . . . . . . . . . . . 27 126 17. DHCP Server Solicitation 27 127 17.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 27 128 17.1.1. Creation of Solicit messages . . . . . . . . . . 28 129 17.1.2. Transmission of Solicit Messages . . . . . . . . 28 130 17.1.3. Receipt of Advertise messages . . . . . . . . . . 29 131 17.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 30 132 17.2.1. Receipt of Solicit messages . . . . . . . . . . . 30 133 17.2.2. Creation and transmission of Advertise messages . 30 135 18. DHCP Client-Initiated Configuration Exchange 31 136 18.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 31 137 18.1.1. Creation and transmission of Request messages . . 31 138 18.1.2. Creation and transmission of Confirm messages . . 33 139 18.1.3. Creation and transmission of Renew messages . . . 34 140 18.1.4. Creation and transmission of Rebind messages . . 35 141 18.1.5. Creation and Transmission of Inform messages . . 36 142 18.1.6. Receipt of Reply message in response to a Request, 143 Confirm, Renew, Rebind or Inform message . 37 144 18.1.7. Creation and transmission of Release messages . . 39 145 18.1.8. Receipt of Reply message in response to a Release 146 message . . . . . . . . . . . . . . . . . 40 147 18.1.9. Creation and transmission of Decline messages . . 40 148 18.1.10. Receipt of Reply message in response to a Decline 149 message . . . . . . . . . . . . . . . . . 41 150 18.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 41 151 18.2.1. Receipt of Request messages . . . . . . . . . . . 41 152 18.2.2. Receipt of Confirm messages . . . . . . . . . . . 42 153 18.2.3. Receipt of Renew messages . . . . . . . . . . . . 43 154 18.2.4. Receipt of Rebind messages . . . . . . . . . . . 44 155 18.2.5. Receipt of Inform messages . . . . . . . . . . . 45 156 18.2.6. Receipt of Release messages . . . . . . . . . . . 45 157 18.2.7. Receipt of Decline messages . . . . . . . . . . . 46 158 18.2.8. Receipt of Information-Request messages . . . . . 46 159 18.2.9. Sending of Reply messages . . . . . . . . . . . . 46 161 19. DHCP Server-Initiated Configuration Exchange 47 162 19.1. Server Behavior . . . . . . . . . . . . . . . . . . . . . 47 163 19.1.1. Creation and transmission of Reconfigure messages 47 164 19.1.2. Time out and retransmission of Reconfigure 165 messages . . . . . . . . . . . . . . . . . 48 166 19.1.3. Receipt of Renew messages . . . . . . . . . . . . 48 167 19.2. Receipt of Information-request messages . . . . . . . . . 48 168 19.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 49 169 19.3.1. Receipt of Reconfigure messages . . . . . . . . . 49 170 19.3.2. Creation and sending of Renew messages . . . . . 50 171 19.3.3. Creation and sending of Renew messages . . . . . 50 172 19.3.4. Time out and retransmission of Renew or 173 Information-request messages . . . . . . . 50 174 19.3.5. Receipt of Reply messages . . . . . . . . . . . . 50 176 20. Relay Behavior 50 177 20.1. Relaying of client messages . . . . . . . . . . . . . . . 50 178 20.2. Relaying of server messages . . . . . . . . . . . . . . . 51 180 21. Authentication of DHCP messages 51 181 21.1. DHCP threat model . . . . . . . . . . . . . . . . . . . . 52 182 21.2. Security of messages sent between servers and relay agents 52 183 21.3. Summary of DHCP authentication . . . . . . . . . . . . . 52 184 21.4. Replay detection . . . . . . . . . . . . . . . . . . . . 53 185 21.5. Configuration token protocol . . . . . . . . . . . . . . 53 186 21.6. Delayed authentication protocol . . . . . . . . . . . . . 54 187 21.6.1. Management issues in the delayed authentication 188 protocol . . . . . . . . . . . . . . . . . 54 189 21.6.2. Use of the Authentication option in the delayed 190 authentication protocol . . . . . . . . . 54 191 21.6.3. Message validation . . . . . . . . . . . . . . . 55 192 21.6.4. Key utilization . . . . . . . . . . . . . . . . . 55 193 21.6.5. Client considerations for delayed authentication 194 protocol . . . . . . . . . . . . . . . . . 56 195 21.6.6. Server considerations for delayed authentication 196 protocol . . . . . . . . . . . . . . . . . 58 198 22. DHCP options 58 199 22.1. Format of DHCP options . . . . . . . . . . . . . . . . . 59 200 22.2. DHCP unique identifier option . . . . . . . . . . . . . . 59 201 22.3. Identity association option . . . . . . . . . . . . . . . 60 202 22.4. IA Address option . . . . . . . . . . . . . . . . . . . . 62 203 22.5. Requested Temporary Addresses (RTA) Option . . . . . . . 63 204 22.6. Option request option . . . . . . . . . . . . . . . . . . 64 205 22.7. Preference option . . . . . . . . . . . . . . . . . . . . 64 206 22.8. Elapsed Time . . . . . . . . . . . . . . . . . . . . . . 65 207 22.9. Client message option . . . . . . . . . . . . . . . . . . 65 208 22.10. Server message option . . . . . . . . . . . . . . . . . . 66 209 22.11. DSTM Global IPv4 Address Option . . . . . . . . . . . . . 66 210 22.12. DSTM Tunnel EndPoint Option . . . . . . . . . . . . . . 67 211 22.13. Authentication option . . . . . . . . . . . . . . . . . . 67 212 22.14. Server unicast option . . . . . . . . . . . . . . . . . . 68 213 22.15. Domain Search Option . . . . . . . . . . . . . . . . . . 69 214 22.16. Domain Name Server Option . . . . . . . . . . . . . . . . 70 215 22.17. Status Code Option . . . . . . . . . . . . . . . . . . . 70 216 22.18. Circuit-ID Option . . . . . . . . . . . . . . . . . . . . 71 217 22.19. User Class Option . . . . . . . . . . . . . . . . . . . . 72 218 22.20. Vendor Class Option . . . . . . . . . . . . . . . . . . . 72 219 22.21. SIP Servers Domain Name List . . . . . . . . . . . . . . 74 220 22.22. SIP Servers IPv6 Address List . . . . . . . . . . . . . . 74 222 23. Security Considerations 75 224 24. Year 2000 considerations 75 226 25. IANA Considerations 75 227 25.1. Multicast addresses . . . . . . . . . . . . . . . . . . . 75 228 25.2. DHCPv6 message types . . . . . . . . . . . . . . . . . . 75 229 25.3. DUID . . . . . . . . . . . . . . . . . . . . . . . . . . 76 230 25.4. DHCPv6 options . . . . . . . . . . . . . . . . . . . . . 76 231 25.5. Status codes . . . . . . . . . . . . . . . . . . . . . . 76 232 25.6. Authentication option . . . . . . . . . . . . . . . . . . 76 234 26. Acknowledgments 76 236 A. Full Copyright Statement 77 238 B. Appearance of Options in Message Types 78 240 C. Appearance of Options in the Options Field of DHCP Messages 79 242 References 79 244 Chair's Address 81 246 Authors' Addresses 82 248 1. Introduction 250 This document describes DHCP for IPv6 (DHCP), a UDP [20] 251 client/server protocol designed to reduce the cost of management 252 of IPv6 nodes in environments where network managers require more 253 control over the allocation of IPv6 addresses and configuration 254 of network stack parameters than that offered by "IPv6 Stateless 255 Address Autoconfiguration" [23]. DHCP is a stateful counterpart to 256 stateless autoconfiguration. Note that both stateful and stateless 257 autoconfiguration can be used concurrently in the same environment, 258 leveraging the strengths of both mechanisms in order to reduce the 259 cost of ownership and management of network nodes. 261 DHCP reduces the cost of ownership by centralizing the management 262 of network resources such as IP addresses, routing information, OS 263 installation information, directory service information, and other 264 such information on a few DHCP servers, rather than distributing such 265 information in local configuration files among all network node. 266 DHCP is designed to be easily extended to carry new configuration 267 parameters through the addition of new DHCP "options" defined to 268 carry this information. 270 Those readers familiar with DHCP for IPv4 [8] will find DHCP for 271 IPv6 provides a superset of the features of DHCP and benefits from 272 the additional features of IPv6 and freedom from the constraints of 273 backward compatibility with BOOTP [6]. 275 2. Requirements 277 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 278 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 279 document, are to be interpreted as described in [4]. 281 This document also makes use of internal conceptual variables 282 to describe protocol behavior and external variables that an 283 implementation must allow system administrators to change. The 284 specific variable names, how their values change, and how their 285 settings influence protocol behavior are provided to demonstrate 286 protocol behavior. An implementation is not required to have them in 287 the exact form described here, so long as its external behavior is 288 consistent with that described in this document. 290 3. Background 292 The IPv6 Specification provides the base architecture and design of 293 IPv6. Related work in IPv6 that would best serve an implementor 294 to study includes the IPv6 Specification [7], the IPv6 Addressing 295 Architecture [10], IPv6 Stateless Address Autoconfiguration [23], 296 IPv6 Neighbor Discovery Processing [18], and Dynamic Updates to 297 DNS [24]. These specifications enable DHCP to build upon the 298 IPv6 work to provide both robust stateful autoconfiguration and 299 autoregistration of DNS Host Names. 301 The IPv6 Addressing Architecture specification [10] defines the 302 address scope that can be used in an IPv6 implementation, and the 303 various configuration architecture guidelines for network designers 304 of the IPv6 address space. Two advantages of IPv6 are that support 305 for multicast is required, and nodes can create link-local addresses 306 during initialization. This means that a client can immediately use 307 its link-local address and a well-known multicast address to begin 308 communications to discover neighbors on the link. For instance, a 309 client can send a Solicit message and locate a server or relay. 311 IPv6 Stateless Address Autoconfiguration [23] specifies procedures 312 by which a node may autoconfigure addresses based on router 313 advertisements [18], and the use of a valid lifetime to support 314 renumbering of addresses on the Internet. In addition the 315 protocol interaction by which a node begins stateless or stateful 316 autoconfiguration is specified. DHCP is one vehicle to perform 317 stateful autoconfiguration. Compatibility with stateless address 318 autoconfiguration is a design requirement of DHCP (see Section 4). 320 IPv6 Neighbor Discovery [18] is the node discovery protocol in IPv6 321 which replaces and enhances functions of ARP [19]. To understand 322 IPv6 and stateless address autoconfiguration it is strongly 323 recommended that implementors understand IPv6 Neighbor Discovery. 325 Dynamic Updates to DNS [24] is a specification that supports the 326 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 327 the dynamic updates to DNS to integrate addresses and name space to 328 not only support autoconfiguration, but also autoregistration in 329 IPv6. 331 4. Design Goals 333 - DHCP is a mechanism rather than a policy. Network administrators 334 set their administrative policies through the configuration 335 parameters they place upon the DHCP servers in the DHCP domain 336 they're managing. DHCP is simply used to deliver parameters 337 according to that policy to each of the DHCP clients within the 338 domain. 340 - DHCP is compatible with IPv6 stateless address 341 autoconfiguration [23], statically configured, non-participating 342 nodes and with existing network protocol implementations. 344 - DHCP does not require manual configuration of network parameters 345 on DHCP clients, except in cases where such configuration is 346 needed for security reasons. A node configuring itself using 347 DHCP should require no user intervention. 349 - DHCP does not require a server on each link. To allow for scale 350 and economy, DHCP must work across DHCP relays. 352 - DHCP clients can operate on a link without IPv6 routers present. 354 - DHCP will provide the ability to renumber network(s) when 355 required by network administrators [5]. 357 - A DHCP client can make multiple, different requests for 358 configuration parameters when necessary from one or more DHCP 359 servers at any time. 361 - DHCP will contain the appropriate time out and retransmission 362 mechanisms to efficiently operate in environments with high 363 latency and low bandwidth characteristics. 365 5. Non-Goals 367 This specification explicitly does not cover the following: 369 - Specification of a DHCP server to server protocol. 371 - How a DHCP server stores its DHCP data. 373 - How to manage a DHCP domain or DHCP server. 375 - How a DHCP relay is configured or what sort of information it may 376 log. 378 6. Terminology 380 This sections defines terminology specific to IPv6 and DHCP used in 381 this document. 383 6.1. IPv6 Terminology 385 IPv6 terminology relevant to this specification from the IPv6 386 Protocol [7], IPv6 Addressing Architecture [10], and IPv6 Stateless 387 Address Autoconfiguration [23] is included below. 389 address An IP layer identifier for an interface 390 or a set of interfaces. 392 unicast address An identifier for a single interface. 393 A packet sent to a unicast address is 394 delivered to the interface identified by 395 that address. 397 multicast address An identifier for a set of interfaces 398 (typically belonging to different 399 nodes). A packet sent to a multicast 400 address is delivered to all interfaces 401 identified by that address. 403 host Any node that is not a router. 405 IP Internet Protocol Version 6 (IPv6). The 406 terms IPv4 and IPv6 are used only in 407 contexts where it is necessary to avoid 408 ambiguity. 410 interface A node's attachment to a link. 412 link A communication facility or medium over 413 which nodes can communicate at the link 414 layer, i.e., the layer immediately below 415 IP. Examples are Ethernet (simple or 416 bridged); Token Ring; PPP links, X.25, 418 Frame Relay, or ATM networks; and 419 Internet (or higher) layer "tunnels", 420 such as tunnels over IPv4 or IPv6 421 itself. 423 link-layer identifier A link-layer identifier for an 424 interface. Examples include IEEE 802 425 addresses for Ethernet or Token Ring 426 network interfaces, and E.164 addresses 427 for ISDN links. 429 link-local address An IPv6 address having link-only 430 scope, indicated by having the prefix 431 (FE80::0000/64), that can be used to 432 reach neighboring nodes attached to 433 the same link. Every interface has a 434 link-local address. 436 neighbor A node attached to the same link. 438 node A device that implements IP. 440 packet An IP header plus payload. 442 prefix The initial bits of an address, or a 443 set of IP address that share the same 444 initial bits. 446 prefix length The number of bits in a prefix. 448 router A node that forwards IP packets not 449 explicitly addressed to itself. 451 6.2. DHCP Terminology 453 Terminology specific to DHCP can be found below. 455 agent address The address of a neighboring DHCP Agent 456 on the same link as the DHCP client. 458 binding A binding (or, client binding) is a 459 group of server data records containing 460 the information the server has about 461 the addresses in an IA and any other 462 configuration information assigned to 463 the client. A binding is indexed by the 464 tuple . 466 DHCP Dynamic Host Configuration Protocol 467 for IPv6. The terms DHCPv4 and DHCPv6 468 are used only in contexts where it is 469 necessary to avoid ambiguity. 471 configuration parameter An element of the configuration 472 information set on the server and 473 delivered to the client using DHCP. 474 Such parameters may be used to carry 475 information to be used by a node to 476 configure its network subsystem and 477 enable communication on a link or 478 internetwork, for example. 480 DHCP client (or client) A node that initiates requests on a link 481 to obtain configuration parameters from 482 one or more DHCP servers. 484 DHCP domain A set of links managed by DHCP and 485 operated by a single administrative 486 entity. 488 DHCP server (or server) A server is a node that responds to 489 requests from clients, and may or 490 may not be on the same link as the 491 client(s). 493 DHCP relay (or relay) A node that acts as an intermediary to 494 deliver DHCP messages between clients 495 and servers, and is on the same link as 496 a client. 498 DHCP agent (or agent) Either a DHCP server on the same link as 499 a client, or a DHCP relay. 501 DUID A DHCP Unique IDentifier for a client; 502 each DHCP client has exactly one DUID 504 Identity association (IA) A collection of addresses assigned to 505 a client. Each IA has an associated 506 IAID. An IA may have 0 or more addresses 507 associated with it. 509 Identity association identifier (IAID) An identifier for an IA, 510 chosen by the client. Each IA has an 511 IAID, which is chosen to be unique among 512 all IAIDs for IAs belonging to that 513 client. 515 message A unit of data carried in a packet, 516 exchanged between DHCP agents and 517 clients. 519 transaction-ID An unsigned integer to match responses 520 with replies initiated either by a 521 client or server. 523 7. DHCP Constants 525 This section describes various program and networking constants used 526 by DHCP. 528 7.1. Multicast Addresses 530 DHCP makes use of the following multicast addresses: 532 All_DHCP_Agents address: FF02::1:2 This link-scoped multicast 533 address is used by clients to communicate with the 534 on-link agent(s) when they do not know the link-local 535 address(es) for those agents. All agents (servers and 536 relays) are members of this multicast group. 538 All_DHCP_Servers address: FF05::1:3 This site-scoped multicast 539 address is used by clients or relays to communicate 540 with server(s), either because they want to send 541 messages to all servers or because they do not know 542 the server(s) unicast address(es). Note that in order 543 for a client to use this address, it must have an 544 address of sufficient scope to be reachable by the 545 server(s). All servers within the site are members of 546 this multicast group. 548 7.2. UDP ports 550 DHCP uses the following destination UDP [20] port numbers. While 551 source ports MAY be arbitrary, client implementations SHOULD permit 552 their specification through a local configuration parameter to 553 facilitate the use of DHCP through firewalls. 555 546 Client port. Used by servers as the destination port 556 for messages sent to clients and relays. Used by relay 557 agents as the destination port for messages sent to 558 clients. 560 547 Agent port. Used as the destination port by clients 561 for messages sent to agents. Used as the destination 562 port by relays for messages sent to servers. 564 7.3. DHCP message types 566 DHCP defines the following message types. More detail on these 567 message types can be found in Section 8. Message types not listed 568 here are reserved for future use. The message code for each message 569 type is shown with the message name. 571 SOLICIT (1) The Solicit message is used by clients to 572 locate servers. 574 ADVERTISE (2) The Advertise message is used by servers 575 responding to Solicits. 577 REQUEST (3) The Request message is used by clients to 578 request configuration parameters from servers. 580 CONFIRM (4) The Confirm message is used by clients to 581 confirm that the addresses assigned to an IA 582 and the lifetimes for those addresses, as 583 well as the current configuration parameters 584 assigned by the server to the client are still 585 valid. 587 RENEW (5) The Renew message is used by clients to 588 update the addresses assigned to an IA and the 589 lifetimes for those addresses, as well as the 590 current configuration parameters assigned by 591 the server to the client. A client sends a 592 Renew message to the server that originally 593 populated the IA at time T1. 595 REBIND (6) The Rebind message is used by clients to extend 596 the lifetimes of addresses assigned to an IA, 597 as well as the current configuration parameters 598 assigned by the server to the client. A 599 client sends a Rebind message to all available 600 DHCP servers at time T2 only after the client 601 has been unable to contact the server that 602 originally populated the IA with a Renew 603 message. 605 REPLY (7) The Reply message is used by servers responding 606 to Request, Confirm, Renew, Rebind, Release and 607 Decline messages. In the case of responding to 608 a Request, Confirm, Renew or Rebind message, 609 the Reply contains configuration parameters 610 destined for the client. 612 RELEASE (8) The Release message is used by clients to 613 indicate to a server that the client will no 614 longer use one or more addresses in an IA. 616 DECLINE (9) The Decline message is used by clients to 617 indicate that the client has determined that 618 one or more addresses in an IA are already 619 in use on the link to which the client is 620 connected. 622 RECONFIGURE (10) The Reconfigure message is sent by server(s) 623 to inform client(s) that the server(s) has new 624 or updated configuration parameters, and that 625 the client(s) are to initiate a Request/Reply 626 transaction with the server(s) in order to 627 receive the updated information. 629 INFORMATION-REQUEST (11) The Information-request message is sent 630 by clients to request configuration parameters 631 without the assignment of any IP addresses to 632 the client. 634 RELAY-FORW (12) The Relay-forward message is used by relays to 635 forward client messages to servers. The client 636 message is encapsulated in an option in the 637 Relay-forward message. 639 RELAY-REPL (13) The Relay-reply message is used by servers to 640 send messages to clients through a relay. The 641 server encapsulates the client message as an 642 option in the Relay-reply message, which the 643 relay extracts and forwards to the client. 645 7.4. Status Codes 647 This section describes status codes exchanged between DHCP 648 implementations. These status codes may appear in the Status Code 649 option or in the status field of an IA. 651 7.4.1. Generic Status Codes 653 The status codes in this section are used between clients and servers 654 to convey status conditions. The following table contains the status 655 codes, the name for each code (as used in this document) and a brief 656 description. Note that the numeric values do not start at 1, nor are 657 they consecutive. The status codes are organized in logical groups. 659 Name Code Description 660 ---------- ---- ----------- 661 Success 0 Success 662 UnspecFail 16 Failure, reason unspecified 663 AuthFailed 17 Authentication failed or nonexistent 664 PoorlyFormed 18 Poorly formed message 665 AddrUnavail 19 Addresses unavailable 666 OptionUnavail 20 Requested options unavailable 668 7.4.2. Server-specific Status Codes 670 The status codes in this section are used by servers to convey status 671 conditions to clients. The following table contains the status 672 codes, the name for each code (as used in this document) and a brief 673 description. Note that the numeric values do not start at 1, nor are 674 they consecutive. The status codes are organized in logical groups. 676 Name Code Description 677 ---- ---- ----------- 678 NoBinding 32 Client record (binding) unavailable 679 ConfNoMatch 33 Client record Confirm doesn't match IA 680 RenwNoMatch 34 Client record Renew doesn't match IA 681 RebdNoMatch 35 Client record Rebind doesn't match IA 682 InvalidSource 36 Invalid Client IP address 683 NoPrefixMatch 37 One or more prefixes of the addresses 684 in the IA is not valid for the link 685 from which the client message was received 687 7.5. Configuration Variables 689 This section presents a table of client and server configuration 690 variables and the default or initial values for these variables. 692 Parameter Default Description 693 ------------------------------------- 694 MIN_SOL_DELAY 1 sec Min delay of first Solicit 695 MAX_SOL_DELAY 5 secs Max delay of first Solicit 696 SOL_TIMEOUT 500 msecs Initial Solicit timeout 697 SOL_MAX_RT 30 secs Max Solicit timeout value 698 REQ_TIMEOUT 250 msecs Initial Request timeout 699 REQ_MAX_RT 30 secs Max Request timeout value 700 REQ_MAX_RC 10 Max Request retry attempts 701 CNF_TIMEOUT 250 msecs Initial Confirm timeout 702 CNF_MAX_RT 1 sec Max Confirm timeout 703 CNF_MAX_RD 10 secs Max Confirm duration 704 REN_TIMEOUT 10 sec Initial Renew timeout 705 REN_MAX_RT 600 secs Max Renew timeout value 706 REB_TIMEOUT 10 secs Initial Rebind timeout 707 REB_MAX_RT 600 secs Max Rebind timeout value 708 INF_TIMEOUT 500 ms Initial Inform timeout 709 INF_MAX_RT 30 secs Max Inform timeout value 710 REL_TIMEOUT 250 msecs Initial Release timeout 711 REL_MAX_RT 1 sec Max Release timeout 712 REL_MAX_RC 5 MAX Release/Decline attempts 713 DEC_TIMEOUT 250 msecs Initial Release timeout 714 DEC_MAX_RT 1 sec Max Release timeout 715 DEC_MAX_RC 5 MAX Release/Decline attempts 717 8. Message Formats 719 All DHCP messages sent between clients and servers share an identical 720 fixed format header and a variable format area for options. Not all 721 fields in the header are used in every message. 723 All values in the message header and in options are in network order. 725 The following diagram illustrates the format of DHCP messages sent 726 between clients and servers: 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | msg-type | transaction-ID | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | | 734 | server-address | 735 | (16 octets) | 736 | | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | | 739 . options . 740 . (variable) . 741 | | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 The following sections describe the use of the fields in the DHCP 745 message header in each of the DHCP messages. In these descriptions, 746 fields that are not used in a message are marked as "unused". All 747 unused fields in a message MUST be transmitted as zeroes and ignored 748 by the receiver of the message. 750 8.1. DHCP Solicit Message Format 752 msg-type SOLICIT 754 transaction-ID An unsigned integer generated by the client used 755 to identify this Solicit message. 757 server-address (Unused) MUST be zero 759 options See section 22. 761 8.2. DHCP Advertise Message Format 763 msg-type ADVERTISE 764 transaction-ID An unsigned integer used to identify this 765 Advertise message. Copied from the Solicit 766 message received from the client. 768 server-address The IP address of the server that generated this 769 message. The address must have sufficient scope 770 to be reachable from the client. 772 options See section 22. 774 8.3. DHCP Request Message Format 776 msg-type REQUEST 778 transaction-ID An unsigned integer generated by the client used 779 to identify this Request message. 781 server-address The IP address of the server to which this 782 message is directed, copied from an Advertise 783 message. 785 options See section 22. 787 8.4. DHCP Confirm Message Format 789 msg-type CONFIRM 791 transaction-ID An unsigned integer generated by the client used 792 to identify this Confirm message. 794 server-address MUST be zero. 796 options See section 22. 798 8.5. DHCP Renew Message Format 800 msg-type RENEW 802 transaction-ID An unsigned integer generated by the client used 803 to identify this Renew message. 805 server-address The IP address of the server to which this Renew 806 message is directed, which MUST be the address 807 of the server from which the IAs in this message 808 were originally assigned. 810 options See section 22. 812 8.6. DHCP Rebind Message Format 814 msg-type REBIND 816 transaction-ID An unsigned integer generated by the client used 817 to identify this Rebind message. 819 server-address MUST be zero. 821 options See section 22. 823 8.7. DHCP Reply Message Format 825 msg-type REPLY 827 transaction-ID An unsigned integer used to identify this 828 Reply message. Copied from the client Request, 829 Confirm, Renew or Rebind message received from 830 the client. 832 server-address The IP address of the server. 834 options See section 22. 836 8.8. DHCP Release Message Format 838 msg-type RELEASE 840 transaction-ID An unsigned integer generated by the client used 841 to identify this Release message. 843 server-address The IP address of the server that assigned the 844 addresses. 846 options See section 22. 848 8.9. DHCP Decline Message Format 850 msg-type DECLINE 852 transaction-ID An unsigned integer generated by the client used 853 to identify this Decline message. 855 server-address The IP address of the server that assigned the 856 addresses. 858 options See section 22. 860 8.10. DHCP Reconfigure Message Format 862 msg-type RECONFIG 864 transaction-ID An unsigned integer generated by the server used 865 to identify this Reconfigure message. 867 server-address The IP address of the DHCP server issuing the 868 Reconfigure message. The address must have 869 sufficient scope to be reachable from the client. 871 options See section 22. 873 8.11. Information-Request Message Format 875 msg-type INFORM 877 transaction-ID An unsigned integer generated by the client used 878 to identify this Inform message. 880 server-address Contains IP address of server to which this 881 message is directed, or 0 if any server may 882 respond. 884 options See section 22. 886 9. Relay messages 888 Relay agents exchange messages with servers to forward messages 889 between clients and servers that are not connected to the same link. 890 There are two relay messages, which share the following format: 892 0 1 2 3 893 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 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | msg-type | | 896 +-+-+-+-+-+-+-+-+ | 897 | link-address | 898 | | 899 | | 900 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 901 | | | 902 +-+-+-+-+-+-+-+-+ | 903 | client-return-address | 904 | | 905 | | 906 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 907 | | | 908 +-+-+-+-+-+-+-+-+ | 909 . . 910 . options (variable number and length) .... . 911 | | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 The following sections describe the use of the Relay message header. 916 9.1. Relay-forward message 918 The following table defines the use of message fields in a 919 Relay-forward message. 921 msg-type RELAY-FORW 923 link-address An address with a prefix that is assigned 924 to the link from which the client should 925 be assigned an address. 927 client-return-address The IPv6 source address in which the 928 message from the client was received by 929 the relay agent 931 options MUST include a "Client message option"; 932 see section 22.9; MAY include other 933 options added by the relay agent 935 9.2. Relay-reply message 937 The following table defines the use of message fields in a 938 Relay-reply message. 940 msg-type RELAY-REPL 942 link-address The link-address copied from the 943 Relay-forward message; used by the relay 944 agent to select the link on which the 945 message is returned to the client 947 client-return-address The source address from the IP datagram 948 in which the message from the client was 949 received by the relay agent 951 options MUST include a "Server message option"; 952 see section 22.10; MAY include other 953 options 955 10. Representation and use of domain names 957 So that domain names may be encoded uniformly and compactly, a 958 domain name or a list of domain names is encoded using the technique 959 described in sections 3.1 and 4.1.4 of RFC1035 [15]. Section 4.1.4 960 of RFC1035 describes how more than one domain name can be represented 961 in a list of domain names. For use in this specification, in a 962 list of domain names, the compression pointer (see section 4.1.4 of 963 RFC1035) refers to the offset within the list. 965 If a single domain name is being used by a vendor as a vendor 966 identifier, then the vendor MUST ensure that the domain name has not 967 previously been used by a different vendor. 969 11. DHCP unique identifier (DUID) 971 Each DHCP client has a DUID. DHCP servers use DUIDs to identify 972 clients for the selection of configuration parameters and in 973 the association of IAs with clients. See section 22.2 for the 974 representation of a DUID in a DHCP message. 976 Servers MUST treat DUIDs as opaque values and MUST only compare DUIDs 977 for equality. Servers MUST NOT in any other way interpret DUIDs. 978 Servers MUST NOT restrict DUIDs to the types defined in this document 979 as additional DUID types may be defined in the future. 981 The DUID is carried in an option because it may be variable length 982 and because it is not required in all DHCP options (e.g., messages 983 sent by servers need not include a DUID). The DUID is designed to 984 be unique across all DHCP clients, and consistent for any specific 985 client - that is, the DUID used by a client SHOULD NOT change over 986 time, for example, as a result of network hardware reconfiguration. 988 The motivation for having more than one type of DUID is that the DUID 989 must be globally unique, and must also be easy to generate. The sort 990 of globally-unique identifier that is easy to generate for any given 991 device can differ quite widely. Also, some devices may not contain 992 any persistent storage. Retaining a generated DUID in such a device 993 is not possible, so the DUID scheme must accommodate such devices. 995 11.1. DUID contents 997 A DUID consists of a sixteen-bit type code represented in network 998 order, followed by a variable number of octets that make up the 999 actual identifier. A DUID can be no more than 256 octets long. The 1000 following types are currently defined: 1002 1 Link-layer address plus time 1003 2 Vendor-assigned unique ID 1004 3 Link-layer address 1006 Formats for the variable field of the DUID for each of the above 1007 types are shown below. 1009 11.2. DUID based on link-layer address plus time 1011 This type of DUID consists of four octets containing a time value, 1012 followed by a two octet network hardware type code, followed by 1013 link-layer address of any one network interface that is connected 1014 to the DHCP client device at the time that the DUID is generated. 1015 The time value is the time that the DUID is generated represented 1016 in seconds since midnight (UTC), January 1, 2000, modulo 2^32. The 1017 hardware type MUST be a valid hardware type assigned by the IANA as 1018 described in the section on ARP in RFC 826. Both the time and the 1019 hardware type are stored in network order. 1021 0 1 2 3 1022 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 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Time (32 bits) | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Hardware type (16 bits) | | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1028 . . 1029 . link-layer address (variable length) . 1030 . . 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 The choice of network interface can be completely arbitrary, as long 1033 as that interface provides a unique link-layer address, and the same 1034 DUID should be used in configuring all network interfaces connected 1035 to the device, regardless of which interface's link-layer address was 1036 used to generate the DUID. 1038 DHCP clients using this type of DUID MUST store the DUID in stable 1039 storage, and MUST continue to use this DUID even if the network 1040 interface used to generate the DUID is removed. DHCP clients that do 1041 not have any stable storage MUST NOT use this type of DUID. 1043 DHCP clients that use this DUID SHOULD attempt to configure the time 1044 prior to generating the DUID, if that is possible, and MUST use 1045 some sort of time source (e.g., a real-time clock) in generating 1046 the DUID, even if that time source could not be configured prior to 1047 generating the DUID. The use of a time source makes it unlikely that 1048 two identical DUIDs will be generated if the network interface is 1049 removed from the client and another client then uses the same network 1050 interface to generate a DUID. A DUID collision is very unlikely even 1051 if the clocks haven't been configured prior to generating the DUID. 1053 This method of DUID generation is recommended for all general purpose 1054 computing devices such as desktop computers and laptop computers, and 1055 also for devices such as printers, routers, and so on, that contain 1056 some form of writable non-volatile storage. 1058 11.3. Vendor-assigned unique ID 1060 The vendor-assigned unique ID consists of an eight-octet 1061 vendor-unique identifier, followed by the vendor's registered domain 1062 name. 1064 0 1 2 3 1065 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 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | VUID (64 bits) | 1068 | | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 . . 1071 . domain name (variable length) . 1072 . . 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 The structure of the VUID is left up to the vendor defining it, but 1076 each device containing such a VUID MUST be unique to each device 1077 that is using it, and MUST be assigned to the device at the time of 1078 manufacture and stored in some form of non-volatile storage. The 1079 VUID SHOULD be recorded in non-erasable storage. The domain name 1080 is simply any domain name that has been legally registered by the 1081 vendor in the domain name system [14], stored in the form described 1082 in section 10. 1084 An example DUID of this type might look like this: 1086 +--+---+---+---+-+-+-+--+---+---+--+---+---+---+---+--+--+---+---+ 1087 |12|192|132|221|3|0|9|18|101|120|97|109|112|108|101|46|99|111|109| 1088 +--+---+---+---+-+-+-+--+---+---+--+---+---+---+---+--+--+---+---+ 1090 This is eight octets of VUID data, followed by "example.com" 1091 represented in ASCII. 1093 11.4. Link-layer address 1095 This type of DUID consists of a two octet network hardware type code, 1096 followed by the link-layer address of any one network interface that 1097 is permanently connected to the DHCP client device and cannot be 1098 removed. The hardware type MUST be a valid hardware type assigned by 1099 the IANA as described in the section on ARP in RFC 826. The hardware 1100 type is stored in network order. 1102 0 1 2 3 1103 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 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Hardware type (16 bits) | | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1107 . . 1108 . link-layer address (variable length) . 1109 . . 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 The choice of network interface can be completely arbitrary, as 1113 long as that interface provides a unique link-layer address and 1114 is permanently attached to the device on which the DUID is being 1115 generated. The same DUID should be used in configuring all network 1116 interfaces connected to the device, regardless of which interface's 1117 link-layer address was used to generate the DUID. 1119 This type of DUID is recommended for devices that have a 1120 permanently-connected network interface with a link-layer address and 1121 do not have nonvolatile, writable stable storage. This type of DUID 1122 MUST NOT be used by DHCP clients that cannot tell whether or not a 1123 network interface is permanently attached to the device on which the 1124 DHCP client is running. 1126 12. Identity association 1128 An "identity-association" (IA) is a construct through which a server 1129 and a client can identify, group and manage IPv6 addresses. Each IA 1130 consists of an IAID and associated configuration information. 1132 A client must associate at least one distinct IA with each of 1133 its network interfaces and uses that IA to obtain configuration 1134 information from a server for that interface. Other distinct IAs may 1135 be associated with applications. Each IA must be associated with 1136 exactly one interface. 1138 The IAID uniquely identifies the IA and must be chosen to be unique 1139 among the IAIDs on the client. The IAID is chosen by the client. 1140 For any given use of an IA by the client, the IAID for that IA MUST 1141 be consistent across restarts of the DHCP client. The client may 1142 maintain consistency either by storing the IAID in non-volatile 1143 storage or by using an algorithm that will consistently produce the 1144 same IAID as long as the configuration of the client has not changed. 1145 There may be no way for a client to maintain consistency of the IAIDs 1146 if it does not have non-volatile storage and the client's hardware 1147 configuration changes. 1149 The configuration information in an IA consists of one or more IPv6 1150 addresses and other parameters. The parameters are specified as DHCP 1151 options within the IA, and are associated with the addresses in the 1152 IA and the interface to which the IA belongs. Other parameters that 1153 are not associated with a particular interface may be specified in 1154 the options section of a DHCP message, outside the scope of any IA. 1156 Each address in an IA has a preferred lifetime and a valid lifetime, 1157 as defined in RFC2462 [23]. The lifetimes are transmitted from the 1158 DHCP server to the client in the IA option. The lifetimes apply to 1159 the use of IPv6 addresses as described in section 5.5.4 of RFC2462. 1160 An address whose valid lifetime has expired MAY be discarded from the 1161 IA. 1163 See section 22.3 for the representation of an IA in a DHCP message. 1165 13. Selecting addresses for assignment to an IA 1167 A server selects addresses to be assigned to an IA according to the 1168 address assignment policies determined by the server administrator 1169 and the specific information the server determines about the client 1170 from the following sources: 1172 - The link to which the client is attached: 1174 * If the server receives the message directly from the client 1175 and the source address in the IP datagram in which the 1176 message was received is a link-local address, then the client 1177 is on the same link to which the interface over which the 1178 message was received is attached 1180 * If the server receives the message directly from the client 1181 and the source address in the IP datagram in which the 1182 message was received is not a link-local address, then the 1183 client is on the link identified by the source address in the 1184 IP datagram 1186 * If the server receives the message from a forwarding relay 1187 agent, then the client is on the same link as the one to 1188 which the interface identified by the link-address field in 1189 the message from the relay is attached 1191 - The DUID supplied by the client 1193 - Other information in options supplied by the client 1195 - Other information in options supplied by the relay agent 1197 The addresses that the server selects for the client MUST be valid on 1198 the link to which the interface is attached, regardless of the way in 1199 which the server selects the addresses. 1201 14. Management of temporary addresses 1203 A client may be assigned temporary addresses [17]. Clients and 1204 servers simply label addresses as "temporary". DHCPv6 handling 1205 of address lifetimes and lifetime extensions is no different for 1206 temporary addresses. DHCPv6 says nothing about details of temporary 1207 addresses like lifetimes, lifetime extensions, how clients use 1208 temporary addresses, rules for generating successive temporary 1209 addresses, etc. 1211 In DHCP, temporary addresses are identified with T-bit set in the IA 1212 Address Option(see section 22.4). A client may have zero or more 1213 temporary addresses. Addresses with the T-bit set MUST be intended 1214 for the client to use for the general purposes described in RFC3041. 1215 Addresses that otherwise have short lifetimes or are not intended to 1216 be renewed by the server MUST NOT have the T-bit set. 1218 Clients ask for temporary addresses and servers assign them. When a 1219 client sends an IA to a server, the client lists all of the temporary 1220 addresses it knows about and optionally indicates how many additional 1221 temporary addresses it wants in the Requested Temporary Addresses 1222 Option 22.5. The server compares the number of requested additional 1223 temporary addresses against any previously allocated temporary 1224 addresses for the IA that were not reported by the client in the 1225 IA but still have some reasonable preferred lifetime left. If the 1226 number of temporary addresses is less than the requested number, the 1227 server adds additional temporary addresses to the IA to satisfy the 1228 requested number (subject to server policy). 1230 DISCUSSION: 1232 It is important that the server include any allocated 1233 temporary addresses that were not reported by the client as 1234 it is possible the client never received an earlier Reply 1235 that contained these additional temporary addresses. If 1236 the server did not consider these, a client that fails to 1237 receive a server's reply might cause the server to allocate 1238 many temporary addresses. 1240 When the valid lifetime on a temporary address expires, both the 1241 client and server silently discard the address from the IA. The 1242 discarded address no longer counts against the client's allotment of 1243 temporary addresses. 1245 A server SHOULD NOT assign a client temporary addresses without the 1246 client having specifically asked for it. The client is not obligated 1247 to install address(es) that it receives and did not request and can 1248 release any addresses it does not want. 1250 The server MAY update the DNS for a temporary address as described in 1251 section 4 of RFC3041, and MUST NOT update the DNS in any other way 1252 for a temporary address. 1254 15. Reliability of Client Initiated Message Exchanges 1256 DHCP clients are responsible for reliable delivery of messages in the 1257 client-initiated message exchanges described in sections 17 and 18. 1258 If a DHCP client fails to receive an expected response from a server, 1259 the client must retransmit its message. This section describes the 1260 retransmission strategy to be used by clients in client-initiated 1261 message exchanges. 1263 Note that the procedure described in this section is slightly 1264 modified for use with the Solicit message (section 17.1.2). 1266 The client begins the message exchange by transmitting a message to 1267 the server. The message exchange terminates when either the client 1268 successfully receives the appropriate response or responses from a 1269 server or servers, or when the message exchange is considered to have 1270 failed according to the retransmission mechanism described below. 1272 The client retransmission behavior is controlled and described by the 1273 following variables: 1275 RT Retransmission timeout 1277 IRT Initial retransmission time 1279 MRC Maximum retransmission count 1281 MRT Maximum retransmission time 1283 MRD Maximum retransmission duration 1285 RAND Randomization factor 1287 With each message transmission or retransmission, the client sets RT 1288 according to the rules given below. If RT expires before the message 1289 exchange terminates, the client recomputes RT and retransmits the 1290 message. 1292 Each of the computations of a new RT include a randomization factor 1293 (RAND), which is a random number chosen with a uniform distribution 1294 between -0.1 and +0.1. The randomization factor is included to 1295 minimize synchronization of messages transmitted by DHCP clients. 1296 The algorithm for choosing a random number does not need to be 1297 cryptographically sound. The algorithm SHOULD produce a different 1298 sequence of numbers from each invocation of the DHCP client. 1300 RT for the first message transmission is based on IRT: 1302 RT = 2*IRT + RAND*IRT 1304 RT for each subsequent message transmission is based on the previous 1305 value of RT: 1307 RT = 2*RTprev + RAND*RTprev 1309 MRT specifies an upper bound on the value of RT. If MRT has a value 1310 of 0, there is no upper limit on the value of RT. Otherwise: 1312 if (RT > MRT) 1313 RT = MRT + RAND*MRT 1315 MRC specifies an upper bound on the number of times a client may 1316 retransmit a message. If MRC has a value of 0, the client MUST 1317 continue to retransmit the original message until a response is 1318 received. Otherwise, the message exchange fails once the client has 1319 transmitted the message MRC times. 1321 MRD specifies an upper bound on the length of time a client may 1322 retransmit a message. If MRD has a value of 0, the client MUST 1323 continue to retransmit the original message until a response is 1324 received. Otherwise, the message exchange fails once the client has 1325 transmitted the message MRD seconds. 1327 If both MRC and MRD are non-zero, the message exchange fails whenever 1328 either of the conditions specified in the previous two paragraphs are 1329 met. 1331 16. Message validation 1333 Servers MUST discard any received messages that include 1334 authentication information and fail the authentication check by the 1335 server. 1337 Clients MUST discard any received messages that include 1338 authentication information and fail the authentication check by the 1339 client, except as noted in section 21.6.5.2. 1341 16.1. Use of Transaction-ID field 1343 The "transaction-ID" field holds a value used by clients and servers 1344 to synchronize server responses to client messages. A client SHOULD 1345 choose a different transaction-ID for each new message it sends. A 1346 client MUST leave the transaction-ID unchanged in retransmissions of 1347 a message. 1349 16.2. Solicit message 1351 Clients MUST discard any received Solicit messages. 1353 Relay agents MUST discard any Solicit messages received through port 1354 546. 1356 16.3. Advertise message 1358 Clients MUST discard any received Advertise messages in which the 1359 "Transaction-ID" field value does not match the value the client used 1360 in its Solicit message. 1362 Servers and relay agents MUST discard any received Advertise 1363 messages. 1365 16.4. Request message 1367 Clients MUST discard any received Request messages. 1369 Relay agents MUST discard any Request messages received through port 1370 546. 1372 Servers MUST discard any received Request message in which the value 1373 in the "server-address" field does not match any of the addresses 1374 used by the server. 1376 16.5. Confirm message 1378 Clients MUST discard any received Confirm messages. 1380 Relay agents MUST discard any Confirm messages received through port 1381 546. 1383 16.6. Renew message 1385 Clients MUST discard any received Renew messages. 1387 Relay agents MUST discard any Renew messages received through port 1388 546. 1390 Servers MUST discard any received Renew message in which the value in 1391 the "server-address" field does not match any of the addresses used 1392 by the server. 1394 16.7. Rebind message 1396 Clients MUST discard any received Rebind messages. 1398 Relay agents MUST discard any Rebind messages received through port 1399 546. 1401 16.8. Decline messages 1403 Clients MUST discard any received Decline messages. 1405 Relay agents MUST discard any Decline messages received through port 1406 546. 1408 Servers MUST discard any received Decline message in which the value 1409 in the "server-address" field does not match any of the addresses 1410 used by the server. 1412 16.9. Release message 1414 Clients MUST discard any received Release messages. 1416 Relay agents MUST discard any Release messages received through port 1417 546. 1419 Servers MUST discard any received Release message in which the value 1420 in the "server-address" field does not match any of the addresses 1421 used by the server. 1423 16.10. Reply message 1425 Clients MUST discard any received Reply messages in which the 1426 "transaction-ID" field in the message does not match the value used 1427 in the original message. 1429 Servers and relay agents MUST discard any received Reply messages. 1431 16.11. Reconfigure message 1433 Servers and relay agents MUST discard any received Reconfigure 1434 messages. 1436 Clients MUST discard any Reconfigure messages that do not contain an 1437 authentication option or that fail the authentication performed by 1438 the client. 1440 16.12. Inform message 1442 Clients MUST discard any received Inform messages. 1444 Relay agents MUST discard any Inform messages received through port 1445 546. 1447 16.13. Relay-forward message 1449 Clients MUST discard any received Relay-forward messages. 1451 16.14. Relay-reply message 1453 Clients and servers MUST discard any received Relay-reply messages. 1455 17. DHCP Server Solicitation 1457 This section describes how a client locates servers that will assign 1458 addresses to IAs belonging to the client. 1460 The client is responsible for creating IAs and requesting that a 1461 server assign configuration information, including IPv6 addresses, 1462 to the IA. The client first creates an IA and assigns it an IAID. 1463 The client then transmits a Solicit message containing an IA option 1464 describing the IA. Servers that can assign configuration information 1465 to the IA respond to the client with an Advertise message. The 1466 client then initiates a configuration exchange as described in 1467 section 18. 1469 17.1. Client Behavior 1471 A client uses the Solicit message to discover DHCP servers configured 1472 to serve addresses on the link to which the client is attached. 1474 17.1.1. Creation of Solicit messages 1476 The client sets the "msg-type" field to SOLICIT. The client generates 1477 a transaction ID and inserts this value in the "transaction-ID" 1478 field. 1480 The client MUST include a DUID option to identify itself to the 1481 server. The client MUST include one or more IA options for any IAs 1482 to which it wants the server to assign addresses. The client MAY 1483 include addresses in the IAs as a hint to the server about addresses 1484 for which the client has a preference. The client MAY include an 1485 Option Request Option in the Solicit message. The client MUST NOT 1486 include any other options except those specifically allowed as 1487 defined by specific options. 1489 17.1.2. Transmission of Solicit Messages 1491 The client sends the Solicit message to the All_DHCP_Agents 1492 multicast address. The client MUST use an IPv6 address assigned 1493 to the interface for which the client is interested in obtaining 1494 configuration information as the source address in the IP header of 1495 the datagram carrying the Solicit message. 1497 The Solicit message MUST be transmitted on the link that the 1498 interface for which configuration information is being obtained 1499 is attached to. The client SHOULD send the message through that 1500 interface. The client MAY send the message through another interface 1501 attached to the same link if and only if the client is certain the 1502 two interface are attached to the same link. 1504 The first Solicit message from the client on the interface MUST 1505 be delayed by a random amount of time between MIN_SOL_DELAY and 1506 MAX_SOL_DELAY. This random delay desynchronizes clients which start 1507 at the same time (e.g., after a power outage). 1509 The client transmits the message according to section 15, using the 1510 following parameters: 1512 IRT SOL_TIMEOUT 1514 MRT SOL_MAX_RT 1516 MRC 0 1518 MRD 0 1520 The mechanism in section 15 is modified as follows for use in the 1521 transmission of Solicit messages. The message exchange is not 1522 terminated by the receipt of an Advertise before SOL_TIMEOUT has 1523 elapsed. Rather, the client collects Advertise messages until 1524 SOL_TIMEOUT has elapsed. Also, the first RT MUST be selected to be 1525 strictly greater than SOL_TIMEOUT by choosing RAND to be strictly 1526 greater than 0. 1528 A client MUST collect Advertise messages for SOL_TIMEOUT seconds, 1529 unless it receives an Advertise message with a preference value 1530 of 255. The preference value is carried in the Preference option 1531 (section 22.7). Any Solicit that does not include a Preference 1532 option is considered to have a preference value of 0. If the client 1533 receives an Advertise message with a preference value of 255, then 1534 the client MAY act immediately on that Advertise message without 1535 waiting for any additional Advertise messages. 1537 A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client 1538 is configured with either MRC or MRD set to a value other than 1539 0, it MUST stop trying to configure the interface if the message 1540 exchange fails. After the DHCP client stops trying to configure the 1541 interface, it SHOULD choose to restart the reconfiguration process 1542 after some external event, such as user input, system restart, or 1543 when the client is attached to a new link. 1545 17.1.3. Receipt of Advertise messages 1547 The client MUST ignore any Advertise message that includes a Status 1548 Code option containing the value AddrUnavail, with the exception that 1549 the client MAY display the associated status message to the user. 1551 Upon receipt of one or more valid Advertise messages, the client 1552 selects one or more Advertise messages based upon the following 1553 criteria. 1555 - Those Advertise messages with the highest server preference value 1556 are preferred over all other Advertise messages. 1558 - Within a group of Advertise messages with the same server 1559 preference value, a client MAY select those servers whose 1560 Advertise messages advertise information of interest to the 1561 client. For example, the client may choose a server that 1562 returned an advertisement with configuration options of interest 1563 to the client. 1565 - The client MAY choose a less-preferred server if that server has 1566 a better set of advertised parameters, such as the available 1567 addresses advertised in IAs. 1569 Once a client has selected Advertise message(s), the client will 1570 typically store information about each server, such as server 1571 preference value, addresses advertised, when the advertisement was 1572 received, and so on. Depending on the requirements of the user that 1573 invoked the DHCP client, the client MAY initiate a configuration 1574 exchange with the server(s) immediately, or MAY defer this exchange 1575 until later. 1577 If the client needs to select an alternate server in the case that a 1578 chosen server does not respond, the client chooses the next server 1579 according to the criteria given above. 1581 17.2. Server Behavior 1583 A server sends an Advertise message in response to Solicit messages 1584 it receives to announce the availability of the server to the client. 1586 17.2.1. Receipt of Solicit messages 1588 The server determines the information about the client and its 1589 location as described in section 13. If administrative policy 1590 permits the server to respond to the client, the server will generate 1591 and send an Advertise message to the client. 1593 17.2.2. Creation and transmission of Advertise messages 1595 The server sets the "msg-type" field to ADVERTISE and copies the 1596 contents of the transaction-ID field from the Solicit message 1597 received from the client to the Advertise message. The server 1598 places one of its IP addresses in the "server-address" field of the 1599 Advertise message. The administrator must be able to configure the 1600 address used in the "server-address" field. The server MAY add a 1601 Preference option to carry the preference value for the Advertise 1602 message. 1604 The server implementation SHOULD allow the setting of a server 1605 preference value by the administrator. The server preference value 1606 MUST default to zero unless otherwise configured by the server 1607 administrator. 1609 The server MUST include IA options in the Advertise message 1610 containing any addresses that would be assigned to IAs contained in 1611 the Solicit message from the client. The server MAY include some or 1612 all of the IA options from the client in the Advertise message. 1614 If the server will not assign any addresses to IAs in a subsequent 1615 Request from the client, the server SHOULD either send an Advertise 1616 message to the client that includes only a status code option with 1617 the status code set to AddrUnavail and a status message for the user 1618 or not respond to the Solicit message. 1620 The server MAY include other options the server will return to the 1621 client in a subsequent Reply message. The information in these 1622 options will be used by the client in the selection of a server if 1623 the client receives more than one Advertise message. The server 1624 SHOULD include options specifying values for options requested by the 1625 client in an Option Request Option included in the Solicit message. 1627 If the Solicit message was received directly by the server, the 1628 server unicasts the Advertise message directly to the client using 1629 the address in the source address field from the IP datagram in 1630 which the Solicit message was received. The Advertise message MUST 1631 be unicast through the interface on which the Solicit message was 1632 received. 1634 If the Solicit message was received in a Relay-forward message, 1635 the server constructs a Relay-reply message with the Advertise 1636 message in the payload of a "server-message" option. The server 1637 unicasts the Relay-reply message directly to the relay agent using 1638 the address in the source address field from the IP datagram in which 1639 the Relay-forward message was received. 1641 18. DHCP Client-Initiated Configuration Exchange 1643 A client initiates a message exchange with a server or servers to 1644 acquire or update configuration information of interest. The client 1645 may initiate the configuration exchange as part of the operating 1646 system configuration process or when requested to do so by the 1647 application layer. 1649 18.1. Client Behavior 1651 A client will use Request, Confirm, Renew, Rebind and Inform messages 1652 to acquire and confirm the validity of configuration information. 1653 The client uses the server address information and information about 1654 IAs from previous Advertise messages for use in constructing Request 1655 messages. Note that a client may request configuration information 1656 from one or more servers at any time. 1658 18.1.1. Creation and transmission of Request messages 1660 The client uses a Request message to populate IAs with addresses 1661 and obtain other configuration information. The client includes 1662 one or more IA options in the Request message, with addresses and 1663 information about the IAs that were obtained from the server in a 1664 previous Advertise message. The server then returns addresses and 1665 other information about the IAs to the client in IA options in a 1666 Reply message. 1668 The client generates a transaction ID and inserts this value in the 1669 "transaction-ID" field. 1671 The client places the address of the destination server in the 1672 "server-address" field. 1674 The client MUST include a DUID option to identify itself to the 1675 server. The client adds any other appropriate options, including 1676 one or more IA options (if the client is requesting that the server 1677 assign it some network addresses). The list of addresses in each 1678 included IA MUST include the addresses received by the client in a 1679 previous Advertise message. 1681 If the client has a source address of sufficient scope that can be 1682 used by the server as a return address and the client has received 1683 a Server Unicast option (section 22.14) from the server, the client 1684 SHOULD unicast the Request message to the server. Otherwise, the 1685 client MUST send the Request message to the All_DHCP_Agents multicast 1686 address. The client MUST use an address assigned to the interface 1687 for which the client is interested in obtaining configuration 1688 information as the source address in the IP header of the datagram 1689 carrying the Request message. 1691 DISCUSSION: 1693 Use of multicast and relay agents enables the inclusion of 1694 relay agent options in all messages sent by the client. The 1695 server should enable the use of unicast only when relay 1696 agent options will not be used. 1698 If the client multicasts the Request message, the message MUST be 1699 transmitted on the link that the interface for which configuration 1700 information is being obtained is attached to. The client SHOULD send 1701 the message through that interface. The client MAY send the message 1702 through another interface attached to the same link if and only if 1703 the client is certain the the two interface are attached to the same 1704 link. 1706 The client transmits the message according to section 15, using the 1707 following parameters: 1709 IRT REQ_TIMEOUT 1711 MRT REQ_MAX_RT 1713 MRC REQ_MAX_RC 1715 MRD 0 1717 If the message exchange fails, the client MAY choose one of the 1718 following actions: 1720 - Select another server from a list of servers known to the client; 1721 e. g., servers that responded with an Advertise message 1723 - Initiate the server discovery process described in section 17 1725 - Terminate the configuration process and report failure 1727 18.1.2. Creation and transmission of Confirm messages 1729 Whenever a client may have moved to a new link, its IPv6 addresses 1730 and other configuration information may no longer be valid. Examples 1731 of times when a client may have moved to a new link include: 1733 o The client reboots 1735 o The client is physically disconnected from a wired connection 1737 o The client returns from sleep mode 1739 o The client using a wireless technology changes access points 1741 In any situation when a client may have moved to a new link, the 1742 client MUST initiate a Confirm/Reply message exchange. The client 1743 includes any IAs, along with the addresses associated with those IAs, 1744 in its Confirm message. Any responding servers will indicate the 1745 acceptability of the addresses with the status in the Reply message 1746 it returns to the client. 1748 The client sets the "msg-type" field to CONFIRM. The client generates 1749 a transaction ID and inserts this value in the "transaction-ID" 1750 field. 1752 The client sets the "server-address" field to 0. 1754 The client MUST include a DUID option to identify itself to the 1755 server. The client adds any appropriate options, including one or 1756 more IA options. The client MUST include the addresses the client 1757 currently has associated with those IAs. 1759 The client sends the Confirm message to the All_DHCP_Agents multicast 1760 address. The client MUST use an IPv6 address that the client has 1761 confirmed to be valid on the link to which it is currently attached 1762 and that is assigned to the interface for which the client is 1763 interested in obtaining configuration information as the source 1764 address in the IP header of the datagram carrying the Confirm 1765 message. 1767 The Confirm message MUST be transmitted on the link that the 1768 interface for which configuration information is being obtained 1769 is attached to. The client SHOULD send the message through that 1770 interface. The client MAY send the message through another interface 1771 attached to the same link if and only if the client is certain the 1772 the two interface are attached to the same link. 1774 The client transmits the message according to section 15, using the 1775 following parameters: 1777 IRT CNF_TIMEOUT 1779 MRT CNF_MAX_RT 1780 MRC 0 1782 MRD CNF_MAX_RD 1784 If the client receives no responses before the message transmission 1785 process as described in section 15 terminates, the client SHOULD 1786 continue to use any IP addresses, using the last known lifetimes for 1787 those addresses, and SHOULD continue to use any other previously 1788 obtained configuration parameters. 1790 18.1.3. Creation and transmission of Renew messages 1792 To extend the valid and preferred lifetimes associated with 1793 addresses, the client sends a Renew message to the server containing 1794 an "IA option" for the IA and its associated addresses. The server 1795 determines new lifetimes for the addresses in the IA according to the 1796 administrative configuration of the server. The server may also add 1797 new addresses to the IA. The server may remove addresses from the IA 1798 by setting the preferred and valid lifetimes of those addresses to 1799 zero. 1801 The server controls the time at which the client contacts the server 1802 to extend the lifetimes on assigned addresses through the T1 and T2 1803 parameters assigned to an IA. 1805 At time T1 for an IA, the client initiates a Renew/Reply message 1806 exchange to extend the lifetimes on any addresses in the IA. The 1807 client includes an IA option with all addresses currently assigned to 1808 the IA in its Renew message. 1810 The client sets the "msg-type" field to RENEW. The client generates a 1811 transaction ID and inserts this value in the "transaction-ID" field. 1813 The client places the address of the destination server in the 1814 "server-address" field. 1816 The client MUST include a DUID option to identify itself to the 1817 server. The client adds any appropriate options, including one or 1818 more IA options (if the client is requesting that the server extend 1819 the lifetimes of the addresses assigned to those IAs; note that the 1820 client may check the status of other configuration parameters without 1821 asking for lifetime extensions). The client MUST include the list 1822 of addresses the client currently has associated with the IAs in the 1823 Renew message. 1825 If the client has a source address of sufficient scope that can be 1826 used by the server as a return address and the client has received 1827 a Server Unicast option (section 22.14) from the server, the client 1828 SHOULD unicast the Renew message to the server. Otherwise, the 1829 client sends the Renew message to the All_DHCP_Agents multicast 1830 address. The client MUST use an address assigned to the interface 1831 for which the client is interested in obtaining configuration 1832 information as the source address in the IP header of the datagram 1833 carrying the Renew message. 1835 If the Renew message is multicast, it MUST be transmitted on the 1836 link that the interface for which configuration information is being 1837 obtained is attached to. The client SHOULD send the message through 1838 that interface. The client MAY send the message through another 1839 interface attached to the same link if and only if the client is 1840 certain the the two interface are attached to the same link. 1842 The client transmits the message according to section 15, using the 1843 following parameters: 1845 IRT REN_TIMEOUT 1847 MRT REP_MAX_RT 1849 MRC 0 1851 MRD 0 1853 The mechanism in section 15 is modified as follows for use in the 1854 transmission of Renew messages. The message exchange is terminated 1855 when time T2 is reached (see section 18.1.4), at which time the 1856 client begins a Rebind message exchange. 1858 18.1.4. Creation and transmission of Rebind messages 1860 At time T2 for an IA (which will only be reached if the server to 1861 which the Renew message was sent at time T1 has not responded), 1862 the client initiates a Rebind/Reply message exchange. The client 1863 includes an IA option with all addresses currently assigned to the 1864 IA in its Rebind message. The client sends this message to the 1865 All_DHCP_Agents multicast address. 1867 The client sets the "msg-type" field to REBIND. The client generates 1868 a transaction ID and inserts this value in the "transaction-ID" 1869 field. 1871 The client sets the "server-address" field to 0. 1873 The client MUST include a DUID option to identify itself to the 1874 server. The client adds any appropriate options, including one or 1875 more IA options. The client MUST include the list of addresses the 1876 client currently has associated with the IAs in the Rebind message. 1878 The client sends the Rebind message to the All_DHCP_Agents 1879 multicast address. The client MUST use an IPv6 address assigned 1880 to the interface for which the client is interested in obtaining 1881 configuration information as the source address in the IP header of 1882 the datagram carrying the Rebind message. 1884 The Rebind message MUST be transmitted on the link that the interface 1885 for which configuration information is being obtained is attached 1886 to. The client SHOULD send the message through that interface. The 1887 client MAY send the message through another interface attached to the 1888 same link if and only if the client is certain the the two interface 1889 are attached to the same link. 1891 The client transmits the message according to section 15, using the 1892 following parameters: 1894 IRT REB_TIMEOUT 1896 MRT REB_MAX_RT 1898 MRC 0 1900 MRD 0 1902 The mechanism in section 15 is modified as follows for use in the 1903 transmission of Rebind messages. The message exchange is terminated 1904 when the lifetimes of all of the addresses assigned to the IA expire 1905 (see section 12), at which time the client has several alternative 1906 actions to choose from: 1908 - The client may choose to use a Solicit message to locate a new 1909 DHCP server and send a Request for the expired IA to the new 1910 server 1912 - The client may have other addresses in other IAs, so the client 1913 may choose to discard the expired IA and use the addresses in the 1914 other IAs 1916 18.1.5. Creation and Transmission of Inform messages 1918 The client uses an Inform message to obtain configuration information 1919 without having addresses assigned to it. The client sets the 1920 "msg-type" field to INFORM. The client generates a transaction ID and 1921 inserts this value in the "transaction-ID" field. 1923 The client sets the "server-address" field to 0. 1925 The client MUST include a DUID option to identify itself to the 1926 server. The client adds any appropriate options such as an ORO to 1927 indicate to the server what configuration information the client is 1928 interested in obtaining. The client MUST NOT include any IA options. 1930 The client MUST use an IPv6 address assigned to the interface for 1931 which the client is interested in obtaining configuration information 1932 as the source address in the IP header of the datagram carrying the 1933 Rebind message. 1935 If the client has an IPv6 address of sufficient scope, the client MAY 1936 choose to send the Inform message to the All_DHCP_Servers multicast 1937 address. Otherwise, the client MUST send the Inform message to the 1938 All_DHCP_Agents multicast address. 1940 The Inform message MUST be transmitted on the link that the interface 1941 for which configuration information is being obtained is attached 1942 to. The client SHOULD send the message through that interface. The 1943 client MAY send the message through another interface attached to the 1944 same link if and only if the client is certain the the two interface 1945 are attached to the same link. 1947 The client transmits the message according to section 15, using the 1948 following parameters: 1950 IRT INF_TIMEOUT 1952 MRT INF_MAX_RT 1954 MRC 0 1956 MRD 0 1958 18.1.6. Receipt of Reply message in response to a Request, Confirm, 1959 Renew, Rebind or Inform message 1961 Upon the receipt of a valid Reply message in response to a Request, 1962 Confirm, Renew, Rebind or Inform message, the client extracts the 1963 configuration information contained in the Reply. The client MAY 1964 choose to report any status code or message from the status code 1965 option in the Reply message. 1967 The client SHOULD perform duplicate address detection [23] on each 1968 of the addresses in any IAs it receives in the Reply message after 1969 a Request message. If any of the addresses are found to be in use 1970 on the link, the client sends a Decline message to the server as 1971 described in section 18.1.9. 1973 The client records the T1 and T2 times for each IA in the Reply 1974 message. The client records any addresses included with IAs in 1975 the Reply message. The client updates the preferred and valid 1976 lifetimes for the addresses in the IA from the lifetime information 1977 in the IA option. The client leaves any addresses that the client 1978 has associated with the IA that are not included in the IA option 1979 unchanged. 1981 The client SHOULD respond to the server with a Release message for 1982 any addresses in the Reply message that have a valid lifetime of 0. 1983 The client constructs and transmits this message as described in 1984 section 18.1.7. 1986 If the Reply was received in response to a Renew or Rebind message, 1987 the client must update the information in any IA option contained in 1988 the Reply message. The client adds any new addresses from the IA 1989 option to the IA, updates lifetimes for existing addresses in the IA 1990 from the IA option and discards any addresses with a lifetime of zero 1991 in the IA option. 1993 Management of the specific configuration information is detailed in 1994 the definition of each option, in section 22. 1996 When the client receives a NoPrefixMatch status in an IA from the 1997 server the client can assume it needs to send a Request to the server 1998 to obtain appropriate addresses for the IA. If the client receives 1999 any Reply messages that do not indicate a NoPrefixMatch status, the 2000 client can use the addresses in the IA and ignore any messages that 2001 do indicate a NoPrefixMatch status. 2003 When the client receives an AddrUnavail status in an IA from the 2004 server for a Request message the client will have to find a new 2005 server to create an IA. 2007 When the client receives a NoBinding status in an IA from the server 2008 for a Confirm message the client can assume it needs to send a 2009 Request to reestablish an IA with the server. 2011 When the client receives a ConfNoMatch status in an IA from the 2012 server for a Confirm message the client can send a Renew message to 2013 the server to extend the lifetimes of the addresses. 2015 When the client receives a NoBinding status in an IA from the server 2016 for a Renew message the client can assume it needs to send a Request 2017 to reestablish an IA with the server. 2019 When the client receives a RenwNoMatch status in an IA from the 2020 server for a Renew message the client can assume it needs to send a 2021 Request to reestablish an IA with the server. 2023 When the client receives an AddrUnavail status in an IA from the 2024 server for a Renew message the client can assume it needs to send a 2025 Request to reestablish an IA with the server. 2027 When the client receives a NoBinding status in an IA from the server 2028 for a Rebind message the client can assume it needs to send a Request 2029 to reestablish an IA with the server or try another server. 2031 When the client receives a RebdNoMatch status in an IA from the 2032 server for a Rebind message the client can assume it needs to send a 2033 Request to reestablish an IA with the server or try another server. 2035 When the client receives an AddrUnavail status in an IA from the 2036 server for a Rebind message the client can assume it needs to send a 2037 Request to reestablish an IA with the server or try another server. 2039 18.1.7. Creation and transmission of Release messages 2041 The client sets the "msg-type" field to RELEASE. The client generates 2042 a transaction ID and places this value in the "transaction-ID" field. 2044 The client places the IP address of the server that allocated the 2045 address(es) in the "server-address" field. 2047 The client MUST include a DUID option to identify itself to the 2048 server. The client includes options containing the IAs it is 2049 releasing in the "options" field. The addresses to be released 2050 MUST be included in the IAs. The client continues to use any other 2051 addresses in the IAs. The appropriate "status" field in the options 2052 MUST be set to indicate the reason for the release. 2054 The client MUST NOT use any of the addresses in the IAs in the 2055 message as the source address in the Release message or in any 2056 subsequently transmitted message. 2058 If the client has a source address of sufficient scope that can be 2059 used by the server as a return address and the client has received 2060 a Server Unicast option (section 22.14) from the server, the client 2061 SHOULD unicast the Release message to the server. Otherwise, the 2062 client MUST send the Release message to the All_DHCP_Agents multicast 2063 address. The client MUST use an address for the interface to which 2064 the IAs in the Release message are assigned as the source address for 2065 the Release message. 2067 DISCUSSION: 2069 Use of multicast and relay agents enables the inclusion of 2070 relay agent options in all messages sent by the client. The 2071 server MUST NOT enable the use of unicast for a client when 2072 relay agent options are required for that client. 2074 If the Release message is multicast, it MUST be transmitted on the 2075 link that the interface for which configuration information is being 2076 obtained is attached to. The client SHOULD send the message through 2077 that interface. The client MAY send the message through another 2078 interface attached to the same link if and only if the client is 2079 certain the the two interface are attached to the same link. 2081 A client MAY choose to wait for a Reply message from the server in 2082 response to the Release message. If the client does wait for a 2083 Reply, the client MAY choose to retransmit the Release message. 2085 The client transmits the message according to section 15, using the 2086 following parameters: 2088 IRT REL_TIMEOUT 2090 MRT 0 2091 MRC REL_MAX_MRC 2093 MRD 0 2095 The client MUST abandon the attempt to release addresses if the 2096 Release message exchange fails. 2098 The client MUST stop using all of the addresses in the IA(s) being 2099 released as soon as the client begins the Release message exchange 2100 process. If an IA is released but the Reply from a DHCP server 2101 is lost, the client will retransmit the Release message, and the 2102 server may respond with a Reply indicating a status of "Nobinding". 2103 Therefore, the client does not treat a Reply message with a status 2104 of "Nobinding" in a Release message exchange as if it indicates an 2105 error. 2107 Note that if the client fails to release the IA, the addresses 2108 assigned to the IA will be reclaimed by the server when the lifetime 2109 of the address expires. 2111 18.1.8. Receipt of Reply message in response to a Release message 2113 Upon receipt of a valid Reply message, the client can consider the 2114 Release event successful. 2116 18.1.9. Creation and transmission of Decline messages 2118 The client sets the "msg-type" field to DECLINE. The client generates 2119 a transaction ID and places this value in the "transaction-ID" field. 2121 The client places the IP address of the server that allocated the 2122 address(es) in the "server-address" field. 2124 The client MUST include a DUID option to identify itself to the 2125 server. The client includes options containing the IAs it is 2126 declining in the "options" field. The addresses to be declined MUST 2127 be included in the IAs. The client continues to use other addresses 2128 in the IAs. The appropriate "status" field in the options MUST be 2129 set to indicate the reason for declining the address. 2131 The client MUST NOT use any of the addresses in the IAs in the 2132 message as the source address in the Decline message or in any 2133 subsequently transmitted message. 2135 If the client has a source address of sufficient scope that can be 2136 used by the server as a return address and the client has received 2137 a Server Unicast option (section 22.14) from the server, the client 2138 SHOULD unicast the Decline message to the server. Otherwise, the 2139 client MUST send the Decline message to the All_DHCP_Agents multicast 2140 address. The client MUST use an IPv6 address for the interface to 2141 which the IAs in the Decline message are assigned as the source 2142 address for the Decline message. 2144 DISCUSSION: 2146 Use of multicast and relay agents enables the inclusion of 2147 relay agent options in all messages sent by the client. The 2148 server MUST NOT enable the use of unicast for a client when 2149 relay agent options are required for that client. 2151 If the Decline message is multicast, it MUST be transmitted on the 2152 link that the interface for which configuration information is being 2153 obtained is attached to. The client SHOULD send the message through 2154 that interface. The client MAY send the message through another 2155 interface attached to the same link if and only if the client is 2156 certain the the two interface are attached to the same link. 2158 The client transmits the message according to section 15, using the 2159 following parameters: 2161 IRT DEC_TIMEOUT 2163 MRT DEC_MAX_RT 2165 MRC DEC_MAX_RC 2167 MRD 0 2169 The client MUST abandon the attempt to decline addresses if the 2170 Decline message exchange fails. 2172 18.1.10. Receipt of Reply message in response to a Decline message 2174 Upon receipt of a valid Reply message, the client can consider the 2175 Decline event successful. 2177 18.2. Server Behavior 2179 For this discussion, the Server is assumed to have been configured in 2180 an implementation specific manner with configuration of interest to 2181 clients. 2183 18.2.1. Receipt of Request messages 2185 The server MAY choose to discard Request messages received via 2186 unicast from a client to which the server has not sent a unicast 2187 option. 2189 When the server receives a Request the client is requesting the 2190 configuration of a new IA by the server. The server MUST take the 2191 IA from the client and associate a binding for that client in an 2192 implementation-specific manner within the configuration parameter 2193 database for DHCP clients managed by the server. 2195 Upon the receipt of a valid Request message from a client the server 2196 can respond to, (implementation-specific administrative policy 2197 satisfied) the server scans the options field. 2199 The server then constructs a Reply message and sends it to the 2200 client. 2202 The server SHOULD process each option for the client in an 2203 implementation-specific manner. The server MUST construct a Reply 2204 message containing the following values: 2206 msg-type REPLY 2208 transaction-ID The transaction-ID from the Request message. 2210 server address One of the IP addresses assigned to the interface 2211 through which the server received the message 2212 from the client. 2214 If the server finds that the prefix on one or more IP addresses in 2215 any IA in the message from the client is not a valid prefix for the 2216 link to which the client is connected, the server MUST return the IA 2217 to the client with the status field set to NoPrefixMatch. 2219 If the server cannot assign any addresses to any of the IAs in 2220 the message from the client, the server SHOULD include the IAs in 2221 the Reply message with the status field set to AddrUnavail and no 2222 addresses in the IA. 2224 For any IAs to which the server can assign addresses, server includes 2225 the IA with addresses and other configuration parameters a status of 2226 Success, and add the IA as a new client binding. 2228 The server adds options to the Reply message for any other 2229 configuration information to be assigned to the client. 2231 18.2.2. Receipt of Confirm messages 2233 When the server receives a Confirm message, the client is requesting 2234 confirmation that the configuration information it will use is valid. 2235 The server SHOULD locate the binding for that client and compare the 2236 information in the Confirm message from the client to the information 2237 associated with that client. 2239 Upon the receipt of a valid Confirm message from a client the server 2240 can respond to, (implementation-specific administrative policy 2241 satisfied) the server scans the options field. 2243 If the server cannot determine if the information in the Confirm 2244 message is valid or invalid, the server MUST NOT send a reply to the 2245 client. For example, if the server does not have a binding for the 2246 client, but the configuration information in the Confirm message 2247 appears valid, the server does not reply. 2249 If the server finds that the information for the client does not 2250 match what is in the binding for that client or the configuration 2251 information is not valid, the server sends a Reply message containing 2252 a Status Code option with the value ConfNoMatch. 2254 If the server finds that the information for the client does match 2255 the information in the binding for that client, and the configuration 2256 information is still valid, the server sends a Reply message 2257 containing a Status Code option with the value Success. 2259 The server SHOULD process each option for the client in an 2260 implementation-specific manner. The server MUST construct a Reply 2261 message containing the following values: 2263 msg-type REPLY 2265 transaction-ID The transaction-ID from the Confirm message. 2267 server address One of the IP addresses assigned to the interface 2268 through which the server received the message 2269 from the client. 2271 The Reply message from the server MUST contain a Status Code option 2272 and MUST NOT include any other options. 2274 18.2.3. Receipt of Renew messages 2276 The server MAY choose to discard Renew messages received via unicast 2277 from a client to which the server has not sent a unicast option. 2279 Upon the receipt of a valid Renew message from a client the server 2280 can respond to, (implementation-specific administrative policy 2281 satisfied) the server scans the options field. 2283 When the server receives a Renew and IA option from a client it 2284 SHOULD locate the clients binding and verify the information in the 2285 IA from the client matches the information stored for that client. 2287 If the server cannot find a client entry for this IA the server 2288 SHOULD return an IA containing no addresses with status set to 2289 NoBinding. 2291 If the server finds that the addresses in the IA for the client 2292 do not match the client binding the server should return an IA 2293 containing no addresses with status set to RenwNoMatch. 2295 If the server cannot Renew addresses for the client it SHOULD send 2296 back an IA containing no addresses to the client with the status 2297 field set to AddrUnavail. 2299 If the server finds the addresses in the IA for the client then the 2300 server SHOULD send back the IA to the client with new lifetimes and 2301 T1/T2 times if the default is not being used, and set status to 2302 Success. The server may choose to change the list of addresses and 2303 the lifetimes of addresses in IAs that are returned to the client. 2305 The server SHOULD process each option for the client in an 2306 implementation-specific manner. The server MUST construct a Reply 2307 message containing the following values: 2309 msg-type REPLY 2311 transaction-ID The transaction-ID from the Confirm message. 2313 server address One of the IP addresses assigned to the interface 2314 through which the server received the message 2315 from the client. 2317 18.2.4. Receipt of Rebind messages 2319 Upon the receipt of a valid Rebind message from a client the server 2320 can respond to, (implementation-specific administrative policy 2321 satisfied) the server scans the options field. 2323 When the server receives a Rebind and IA option from a client it 2324 SHOULD locate the clients binding and verify the information in the 2325 IA from the client matches the information stored for that client. 2327 If the server cannot find a client entry for this IA the server 2328 SHOULD return an IA containing no addresses with status set to 2329 NoBinding. 2331 If the server finds that the addresses in the IA for the client 2332 do not match the client binding the server should return an IA 2333 containing no addresses with status set to RebdNoMatch. 2335 If the server cannot Rebind addresses for the client it SHOULD send 2336 back an IA containing no addresses to the client with the status 2337 field set to AddrUnavail. 2339 If the server finds the addresses in the IA for the client then the 2340 server SHOULD send back the IA to the client with new lifetimes and 2341 T1/T2 times if the default is not being used, and set status to 2342 Success. 2344 The server SHOULD process each option for the client in an 2345 implementation-specific manner. The server MUST construct a Reply 2346 message containing the following values: 2348 msg-type REPLY 2350 transaction-ID The transaction-ID from the Confirm message. 2352 server address One of the IP addresses assigned to the interface 2353 through which the server received the message 2354 from the client. 2356 18.2.5. Receipt of Inform messages 2358 When the server receives an Inform message, the client is requesting 2359 configuration information that does not include the assignment of any 2360 addresses. The server SHOULD determine all configuration parameters 2361 appropriate to the client, based on the server configuration policies 2362 known to the server. 2364 Upon the receipt of a valid Inform message from a client the server 2365 can respond to, (implementation-specific administrative policy 2366 satisfied) the server scans the options field. The server then 2367 constructs a Reply message and sends it to the client. 2369 The server SHOULD process each option for the client in an 2370 implementation-specific manner. The server MUST construct a Reply 2371 message containing the following values: 2373 msg-type REPLY 2375 transaction-ID The transaction-ID from the Confirm message. 2377 server address One of the IP addresses assigned to the interface 2378 through which the server received the message 2379 from the client. 2381 The server adds options to the Reply message for all of the 2382 configuration parameters to be returned to the client. 2384 18.2.6. Receipt of Release messages 2386 The server MAY choose to discard Release messages received via 2387 unicast from a client to which the server has not sent a unicast 2388 option. 2390 Upon the receipt of a valid Release message, the server examines the 2391 IAs and the addresses in the IAs for validity. If the IAs in the 2392 message are in a binding for the client and the addresses in the IAs 2393 have been assigned by the server to those IAs, the server deletes 2394 the addresses from the IAs and makes the addresses available for 2395 assignment to other clients. The server ignores invalid addresses 2396 (though it may choose to log an error if it finds an invalid 2397 address). 2399 After all the addresses have been processed, the server generates a 2400 Reply message and includes a Status Code option with value Success. 2401 The server MUST NOT include any other options in the Reply message. 2403 A server is not required to (but may choose to as an implementation 2404 strategy) retain any record of an IA from which all of the addresses 2405 have been released. 2407 18.2.7. Receipt of Decline messages 2409 The server MAY choose to discard Decline messages received via 2410 unicast from a client to which the server has not sent a unicast 2411 option. 2413 Upon the receipt of a valid Decline message, the server examines the 2414 IAs and the addresses in the IAs for validity. If the IAs in the 2415 message are in a binding for the client and the addresses in the IAs 2416 have been assigned by the server to those IA, the server deletes 2417 the addresses from the IAs. The server SHOULD mark the addresses 2418 declined by the client so that those addresses are not assigned to 2419 other clients, and MAY choose to make a notification that addresses 2420 were declined. The server ignores invalid addresses (though it may 2421 choose to log an error if it finds an invalid address). 2423 After all the address have been processed, the server generates a 2424 Reply message and includes a Status Code option with value Success. 2425 The server MUST NOT include any other options in the Reply message. 2427 18.2.8. Receipt of Information-Request messages 2429 Upon the receipt of a valid Inform message, the server determines the 2430 appropriate configuration parameters and returns those parameters to 2431 the client in a Reply message. The server MUST NOT include any IA 2432 options in the Reply message. 2434 18.2.9. Sending of Reply messages 2436 If the Request, Confirm, Renew, Rebind, Release, Decline or Inform 2437 message from the client was originally received in a Relay-forward 2438 message from a relay, the server places the Reply message in the 2439 options field of a Relay-response message and copies the link-address 2440 and client-return-address fields from the Relay-forward message into 2441 the Relay-response message. 2443 The server then unicasts the Reply or Relay-reply to the source 2444 address from the IP datagram in which the original message was 2445 received. 2447 19. DHCP Server-Initiated Configuration Exchange 2449 A server initiates a configuration exchange to cause DHCP clients 2450 to obtain new addresses and other configuration information. For 2451 example, an administrator may use a server-initiated configuration 2452 exchange when links in the DHCP domain are to be renumbered. Other 2453 examples include changes in the location of directory servers, 2454 addition of new services such as printing, and availability of new 2455 software (system or application). 2457 19.1. Server Behavior 2459 A server sends a Reconfigure message to cause a client to initiate 2460 immediately a Renew/Reply or Information-request/Reply message 2461 exchange with the server. 2463 19.1.1. Creation and transmission of Reconfigure messages 2465 The server sets the "msg-type" field to RECONFIGURE. The server 2466 generates a transaction-ID and inserts it in the "transaction-ID" 2467 field. The server places its address (of appropriate scope) in the 2468 "server-address" field. 2470 The server MAY include an ORO option to inform the client of what 2471 information has been changed or new information that has been added. 2472 In particular, the server specifies the IA option in the ORO if the 2473 server wants the client to obtain new address information. 2475 The server MUST include an authentication option with the appropriate 2476 settings and add that option as the last option in the "options" 2477 field of the Reconfigure message. 2479 The server MUST NOT include any other options in the Reconfigure 2480 except as specifically allowed in the definition of individual 2481 options. 2483 A server sends each Reconfigure message to a single DHCP client, 2484 using an IPv6 unicast address of sufficient scope belonging to the 2485 DHCP client. The server may obtain the address of the client through 2486 the information that the server has about clients that have been in 2487 contact with the server, or the server may be configured with the 2488 address of the client through some external agent. 2490 To reconfigure more than one client, the server unicasts a separate 2491 message to each client. The server may initiate the reconfiguration 2492 of multiple clients concurrently; for example, a server may 2493 send a Reconfigure message to additional clients while previous 2494 reconfiguration message exchanges are still in progress. 2496 The Reconfigure message causes the client to initiate a Renew/Reply 2497 or Information-request/Reply message exchange with the server. The 2498 server interprets the receipt of a Renew or Information-request 2499 message from the client as satisfying the Reconfigure message 2500 request. 2502 19.1.2. Time out and retransmission of Reconfigure messages 2504 If the server does not receive a Renew or Information-request message 2505 from the client in RECREP_MSG_TIMEOUT milliseconds, the server 2506 retransmits the Reconfigure message, doubles the RECREP_MSG_TIMEOUT 2507 value and waits again. The server continues this process until 2508 REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point 2509 the server SHOULD abort the reconfigure process for that client. 2511 Default and initial values for RECREP_MSG_TIMEOUT and 2512 REC_MSG_ATTEMPTS are documented in section 7.5. 2514 19.1.3. Receipt of Renew messages 2516 The server generates and sends Reply message(s) to the client as 2517 described in section 18.2.9, including in the "options" field new 2518 values for configuration parameters. 2520 It is possible that the client may send a Renew message after the 2521 server has sent a Reconfigure but before the Reconfigure is received 2522 by the client. In this case, the Renew message from the client 2523 may not include all of the IAs and requests for parameters to be 2524 reconfigured by the server. To accommodate this scenario, the server 2525 MAY choose to send a Reply with the IAs and other parameters to be 2526 reconfigured, even if those IAs and parameters were not in the Renew 2527 message from the client. 2529 19.2. Receipt of Information-request messages 2531 If the server has assigned addresses to one or more IAs that belong 2532 to the responding client, the server MUST silently discard the 2533 Information-request message. 2535 The server generates and sends Reply message(s) to the client as 2536 described in section 18.2.9, including in the "options" field new 2537 values for configuration parameters. 2539 It is possible that the client may send an Information-request 2540 message after the server has sent a Reconfigure but before 2541 the Reconfigure is received by the client. In this case, the 2542 Information-request message from the client may not include all of 2543 the IAs and requests for parameters to be reconfigured by the server. 2544 To accommodate this scenario, the server MAY choose to send a Reply 2545 with the IAs and other parameters to be reconfigured, even if those 2546 IAs and parameters were not in the Information-request message from 2547 the client. 2549 19.3. Client Behavior 2551 A client MUST always monitor UDP port 546 for Reconfigure messages 2552 on interfaces for which it has acquired DHCP parameters. Since the 2553 results of a reconfiguration event may affect application layer 2554 programs, the client SHOULD log these events, and MAY notify these 2555 programs of the change through an implementation-specific interface. 2557 19.3.1. Receipt of Reconfigure messages 2559 Upon receipt of a valid Reconfigure message, the client initiates a 2560 transaction with the server. While the transaction is in progress, 2561 the client silently discards any Reconfigure messages it receives. 2563 If the client has IAs with addresses that have been assigned by the 2564 server from which the Reconfigure message was received, the client 2565 MUST respond with a Renew message. Otherwise, the client responds 2566 with an Information-request message. 2568 DISCUSSION: 2570 The Reconfigure message acts as a trigger that signals the 2571 client to complete a successful message exchange. Once 2572 the client has received a Reconfigure, the client proceeds 2573 with the message exchange (retransmitting the Renew or 2574 Information-request message if necessary); the client 2575 ignores any additional Reconfigure messages (regardless 2576 of the transaction ID in the Reconfigure message) until 2577 the exchange is complete. Subsequent Reconfigure messages 2578 (again independent of the transaction ID) cause the client 2579 to initiate a new exchange. 2581 How does this mechanism work in the face of duplicated or 2582 retransmitted Reconfigure messages? Duplicate messages 2583 will be ignored because the client will begin the exchange 2584 after the receipt of the first Reconfigure. Retransmitted 2585 messages will either trigger the exchange (if the first 2586 Reconfigure was not received by the client) or will be 2587 ignored. The server can discontinue retransmission of 2588 Reconfigure messages to the client once the server receives 2589 the Renew or Information-request message from the client. 2591 It might be possible for a duplicate or retransmitted 2592 Reconfigure to be sufficiently delayed (and delivered out of 2593 order) to arrive at the client after the exchange (initiated 2594 by the original Reconfigure) has been completed. In this 2595 case, the client would initiate a redundant exchange. The 2596 likelihood of delayed and out of order delivery is small 2597 enough to be ignored. The consequence of the redundant 2598 exchange is inefficiency rather than incorrect operation. 2600 19.3.2. Creation and sending of Renew messages 2602 When responding to a Reconfigure, the client creates and sends 2603 the Renew message in exactly the same manner as outlined in 2604 section 18.1.3, with the exception: if the server included on ORO 2605 option specifying the IA option, the client MUST include IA options 2606 containing the addresses the client currently has assigned to ALL IAs 2607 for the interface through which the Reconfigure message was received. 2609 19.3.3. Creation and sending of Renew messages 2611 When responding to a Reconfigure, the client creates and sends the 2612 Information-request message in exactly the same manner as outlined in 2613 section 18.1.5. 2615 19.3.4. Time out and retransmission of Renew or Information-request 2616 messages 2618 The client uses the same variables and retransmission algorithm as it 2619 does with Rebind or Information-request messages generated as part 2620 of a client-initiated configuration exchange. See section 18.1.3 2621 and 18.1.5 for details. 2623 19.3.5. Receipt of Reply messages 2625 Upon the receipt of a valid Reply message, the client extracts the 2626 contents of the "options" field, and sets (or resets) configuration 2627 parameters appropriately. The client records and updates the 2628 lifetimes for any addresses specified in IAs in the Reply message. 2629 If the configuration parameters changed were requested by the 2630 application layer, the client notifies the application layer of the 2631 changes using an implementation-specific interface. 2633 20. Relay Behavior 2635 For this discussion, the Relay MAY be configured to use a list of 2636 server destination addresses, which MAY include unicast addresses, 2637 the All_DHCP_Servers multicast address, or other multicast addresses 2638 selected by the network administrator. If the Relay has not been 2639 explicitly configured, it MUST use the All_DHCP_Servers multicast 2640 address as the default. 2642 20.1. Relaying of client messages 2644 When a Relay receives a valid client message, it constructs a 2645 Relay-forward message. The relay places an address with a prefix 2646 assigned to the link on which the client should be assigned an 2647 address in the link-address field. This address will be used by the 2648 server to determine the link from which the client should be assigned 2649 an address and other configuration information. 2651 If the relay cannot use the address in the link-address field to 2652 identify the interface through which the response to the client 2653 will be forwarded, the relay MUST include a circuit-id option (see 2654 section 22.18)in the Relay-forward message. The server will include 2655 the circuit-id option in its Relay-reply message. 2657 The relay copies the source address from the IP datagram in which the 2658 message was received from the client into the client-return-address 2659 field in the Relay-forward message. 2661 The relay constructs a "client-message" option 22.9 that contains 2662 the entire message from the client in the data field of the 2663 option. The relay places the "relay-message" option along with any 2664 "relay-specific" options in the options field of the Relay-forward 2665 message. The Relay MUST send the Relay-forward message to the list 2666 of server destination addresses that it has been configured with and 2667 MUST NOT send the message just to the server (if present) identified 2668 in the server-address field in the client message. 2670 20.2. Relaying of server messages 2672 When the relay receives a Relay-reply message, it extracts the server 2673 message from the "server-message" option. If the Relay-reply message 2674 includes a circuit-id option, the relay forwards the message from the 2675 server to the client on the link identified by the circuit-id option. 2676 Otherwise, the relay forwards the message on the link identified 2677 by the link-address field. In either case, the relay forwards the 2678 message to the address in the client-return-address field in the 2679 Relay-reply message. 2681 21. Authentication of DHCP messages 2683 Some network administrators may wish to provide authentication of 2684 the source and contents of DHCP messages. For example, clients may 2685 be subject to denial of service attacks through the use of bogus 2686 DHCP servers, or may simply be misconfigured due to unintentionally 2687 instantiated DHCP servers. Network administrators may wish to 2688 constrain the allocation of addresses to authorized hosts to avoid 2689 denial of service attacks in "hostile" environments where the network 2690 medium is not physically secured, such as wireless networks or 2691 college residence halls. 2693 Because of the risk of denial of service attacks against DHCP 2694 clients, the use of authentication is mandated in Reconfigure 2695 messages. A DHCP server MUST include an authentication option in 2696 Reconfigure messages sent to clients. 2698 The DHCP authentication mechanism is based on the design of 2699 authentication for DHCP for IPv4 [9]. 2701 21.1. DHCP threat model 2703 The threat to DHCP is inherently an insider threat (assuming a 2704 properly configured network where DHCPv6 ports are blocked on the 2705 perimeter gateways of the enterprise). Regardless of the gateway 2706 configuration, however, the potential attacks by insiders and 2707 outsiders are the same. 2709 The attack specific to a DHCP client is the possibility of the 2710 establishment of a "rogue" server with the intent of providing 2711 incorrect configuration information to the client. The motivation 2712 for doing so may be to establish a "man in the middle" attack or it 2713 may be for a "denial of service" attack. 2715 There is another threat to DHCP clients from mistakenly or 2716 accidentally configured DHCP servers that answer DHCP client requests 2717 with unintentionally incorrect configuration parameters. 2719 The threat specific to a DHCP server is an invalid client 2720 masquerading as a valid client. The motivation for this may be for 2721 "theft of service", or to circumvent auditing for any number of 2722 nefarious purposes. 2724 The threat common to both the client and the server is the resource 2725 "denial of service" (DoS) attack. These attacks typically involve 2726 the exhaustion of valid addresses, or the exhaustion of CPU or 2727 network bandwidth, and are present anytime there is a shared 2728 resource. In current practice, redundancy mitigates DoS attacks the 2729 best. 2731 21.2. Security of messages sent between servers and relay agents 2733 Relay agents and servers that choose to exchange messages securely 2734 use the IPsec mechanisms for IPv6 [11]. The way in which IPsec 2735 is employed by relay agents and servers is not specified in this 2736 document. 2738 21.3. Summary of DHCP authentication 2740 Authentication of DHCP messages is accomplished through the use of 2741 the Authentication option. The authentication information carried 2742 in the Authentication option can be used to reliably identify the 2743 source of a DHCP message and to confirm that the contents of the DHCP 2744 message have not been tampered with. 2746 The Authentication option provides a framework for multiple 2747 authentication protocols. Two such protocols are defined here. 2749 Other protocols defined in the future will be specified in separate 2750 documents. 2752 The protocol field in the Authentication option identifies the 2753 specific protocol used to generate the authentication information 2754 carried in the option. The algorithm field identifies a specific 2755 algorithm within the authentication protocol; for example, the 2756 algorithm field specifies the hash algorithm used to generate the 2757 message authentication code (MAC) in the authentication option. The 2758 replay detection method (RDM) field specifies the type of replay 2759 detection used in the replay detection field. 2761 21.4. Replay detection 2763 The Replay Detection Method (RDM) field determines the type of replay 2764 detection used in the Replay Detection field. 2766 If the RDM field contains 0x00, the replay detection field MUST be 2767 set to the value of a monotonically increasing counter. Using a 2768 counter value such as the current time of day (e.g., an NTP-format 2769 timestamp [13]) can reduce the danger of replay attacks. This method 2770 MUST be supported by all protocols. 2772 21.5. Configuration token protocol 2774 If the protocol field is 0, the authentication information field 2775 holds a simple configuration token. The configuration token is an 2776 opaque, unencoded value known to both the sender and receiver. The 2777 sender inserts the configuration token in the DHCP message and the 2778 receiver matches the token from the message to the shared token. If 2779 the configuration option is present and the token from the message 2780 does not match the shared token, the receiver MUST discard the 2781 message. 2783 Configuration token may be used to pass a plain-text configuration 2784 token and provides only weak entity authentication and no message 2785 authentication. This protocol is only useful for rudimentary 2786 protection against inadvertently instantiated DHCP servers. 2788 DISCUSSION: 2790 The intent here is to pass a constant, non-computed token 2791 such as a plain-text password. Other types of entity 2792 authentication using computed tokens such as Kerberos 2793 tickets or one-time passwords will be defined as separate 2794 protocols. 2796 21.6. Delayed authentication protocol 2798 If the protocol field is 1, the message is using the "delayed 2799 authentication" mechanism. In delayed authentication, the client 2800 requests authentication in its Solicit message and the server replies 2801 with an Advertise message that includes authentication information. 2802 This authentication information contains a nonce value generated by 2803 the source as a message authentication code (MAC) to provide message 2804 authentication and entity authentication. 2806 The use of a particular technique based on the HMAC protocol [12] 2807 using the MD5 hash [21] is defined here. 2809 21.6.1. Management issues in the delayed authentication protocol 2811 The "delayed authentication" protocol does not attempt to address 2812 situations where a client may roam from one administrative domain 2813 to another, i.e. interdomain roaming. This protocol is focused on 2814 solving the intradomain problem where the out-of-band exchange of a 2815 shared secret is feasible. 2817 21.6.2. Use of the Authentication option in the delayed authentication 2818 protocol 2820 In a Solicit message, the Authentication option carries the Protocol, 2821 Algorithm, RDM and Replay detection fields, but no Authentication 2822 information. 2824 In an Advertise, Request, Renew, Rebind, Confirm, Decline, Release 2825 or Information-request message, the Authentication option carries 2826 the Protocol, Algorithm, RDM and Replay detection fields and 2827 Authentication information. The format of the Authentication 2828 information is: 2830 0 1 2 3 2831 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 2832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2833 | Secret ID (32 bits) | 2834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2835 | | 2836 | HMAC-MD5 (128 bits) | 2837 | | 2838 | | 2839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2841 The following definitions will be used in the description of the 2842 authentication information for delayed authentication, algorithm 1: 2844 Replay Detection - as defined by the RDM field 2845 K - a secret value shared between the source and 2846 destination of the message; each secret has a 2847 unique identifier (secret ID) 2848 secret ID - the unique identifier for the secret value 2849 used to generate the MAC for this message 2850 HMAC-MD5 - the MAC generating function. 2852 The sender computes the MAC using the HMAC generation algorithm [12] 2853 and the MD5 hash function [21]. The entire DHCP message (except 2854 the MAC field of the authentication option itself), including the 2855 DHCP message header and the options field, is used as input to the 2856 HMAC-MD5 computation function. The 'secret ID' field MUST be set to 2857 the identifier of the secret used to generate the MAC. 2859 DISCUSSION: 2861 Algorithm 1 specifies the use of HMAC-MD5. Use of a 2862 different technique, such as HMAC-SHA, will be specified as 2863 a separate protocol. 2865 Delayed authentication requires a shared secret key for each 2866 client on each DHCP server with which that client may wish 2867 to use the DHCP protocol. Each secret key has a unique 2868 identifier that can be used by a receiver to determine which 2869 secret was used to generate the MAC in the DHCP message. 2870 Therefore, delayed authentication may not scale well in an 2871 architecture in which a DHCP client connects to multiple 2872 administrative domains. 2874 21.6.3. Message validation 2876 To validate an incoming message, the receiver first checks that 2877 the value in the replay detection field is acceptable according 2878 to the replay detection method specified by the RDM field. Next, 2879 the receiver computes the MAC as described in [12]. The receiver 2880 MUST set the 'MAC' field of the authentication option to all 0s for 2881 computation of the MAC. If the MAC computed by the receiver does not 2882 match the MAC contained in the authentication option, the receiver 2883 MUST discard the DHCP message. 2885 21.6.4. Key utilization 2887 Each DHCP client has a key, K. The client uses its key to encode 2888 any messages it sends to the server and to authenticate and verify 2889 any messages it receives from the server. The client's key SHOULD 2890 be initially distributed to the client through some out-of-band 2891 mechanism, and SHOULD be stored locally on the client for use in all 2892 authenticated DHCP messages. Once the client has been given its key, 2893 it SHOULD use that key for all transactions even if the client's 2894 configuration changes; e.g., if the client is assigned a new network 2895 address. 2897 Each DHCP server MUST know, or be able to obtain in a secure manner, 2898 the keys for all authorized clients. If all clients use the same 2899 key, clients can perform both entity and message authentication for 2900 all messages received from servers. However, the sharing of keys 2901 is strongly discouraged as it allows for unauthorized clients to 2902 masquerade as authorized clients by obtaining a copy of the shared 2903 key. To authenticate the identity of individual clients, each client 2904 MUST be configured with a unique key. 2906 21.6.5. Client considerations for delayed authentication protocol 2908 21.6.5.1. Sending Solicit messages 2910 When the client sends a Solicit message and wishes to use 2911 authentication, it includes an Authentication option with the desired 2912 protocol, algorithm, RDM and replay detection field as described 2913 in section 21.6. The client does not include any authentication 2914 information in the Authentication option. 2916 21.6.5.2. Receiving Advertise messages 2918 The client validates any Advertise messages containing an 2919 Authentication option specifying the delayed authentication protocol 2920 using the validation test described in section 21.6.3. 2922 Client behavior if no Advertise messages include authentication 2923 information or pass the validation test is controlled by local policy 2924 on the client. According to client policy, the client MAY choose to 2925 respond to a Advertise message that has not been authenticated. 2927 The decision to set local policy to accept unauthenticated messages 2928 should be made with care. Accepting an unauthenticated Advertise 2929 message can make the client vulnerable to spoofing and other 2930 attacks. If local users are not explicitly informed that the client 2931 has accepted an unauthenticated Advertise message, the users may 2932 incorrectly assume that the client has received an authenticated 2933 address and is not subject to DHCP attacks through unauthenticated 2934 messages. 2936 A client MUST be configurable to discard unauthenticated messages, 2937 and SHOULD be configured by default to discard unauthenticated 2938 messages. A client MAY choose to differentiate between Advertise 2939 messages with no authentication information and Advertise messages 2940 that do not pass the validation test; for example, a client might 2941 accept the former and discard the latter. If a client does accept an 2942 unauthenticated message, the client SHOULD inform any local users and 2943 SHOULD log the event. 2945 21.6.5.3. Sending Request, Confirm, Renew, Rebind, Decline or Release 2946 messages 2948 If the client authenticated the Advertise message through which the 2949 client selected the server, the client MUST generate authentication 2950 information for subsequent Request, Confirm, Renew, Rebind or Release 2951 messages sent to the server as described in section 21.6. When the 2952 client sends a subsequent message, it MUST use the same secret used 2953 by the server to generate the authentication information. 2955 21.6.5.4. Sending Information-request messages 2957 If the client has negotiated a secret with the server through a 2958 previous message exchange, the client MUST use the same secret used 2959 by the server to generate the authentication information. If the 2960 client has not negotiated a secret with the server, the client MUST 2961 use a secret that has been selected for the client through some 2962 external mechanism. 2964 21.6.5.5. Receiving Reply messages 2966 If the client authenticated the Advertise it accepted, the client 2967 MUST validate the associated Reply message from the server. The 2968 client MUST discard the Reply if the message fails to pass validation 2969 and MAY log the validation failure. If the Reply fails to pass 2970 validation, the client MUST restart the DHCP configuration process by 2971 sending a Solicit message. The client MAY choose to remember which 2972 server replied with a Reply message that failed to pass validation 2973 and discard subsequent messages from that server. 2975 If the client accepted an Advertise message that did not include 2976 authentication information or did not pass the validation test, the 2977 client MAY accept an unauthenticated Reply message from the server. 2979 21.6.5.6. Receiving Reconfigure messages 2981 The client MUST validate the Reconfigure message from the server. 2982 The client MUST discard the Reconfigure if the message fails to pass 2983 validation and MAY log the validation failure. 2985 21.6.6. Server considerations for delayed authentication protocol 2987 21.6.6.1. Receiving Solicit messages and Sending Advertise messages 2989 The server selects a secret for the client and includes 2990 authentication information in the Advertise message returned to the 2991 client as specified in section 21.6. The server MUST record the 2992 identifier of the secret selected for the client and use that same 2993 secret for validating subsequent messages with the client. 2995 21.6.6.2. Receiving Request, Confirm, Renew, Rebind or Release messages 2996 and Sending Reply messages 2998 The server uses the secret identified in the message and validates 2999 the message as specified in section 21.6.3. If the message fails to 3000 pass validation or the server does not know the secret identified by 3001 the 'secret ID' field, the server MUST discard the message and MAY 3002 choose to log the validation failure. 3004 If the message passes the validation procedure, the server responds 3005 to the specific message as described in section 18.2. The server 3006 MUST include authentication information generated using the secret 3007 identified in the received message as specified in section 21.6. 3009 21.6.6.3. Sending Reconfigure messages 3011 The server MUST include authentication information in a Reconfigure 3012 message, generated as specified in section 21.6 using the secret the 3013 server initially negotiated with the client to which the Reconfigure 3014 message is to be sent. 3016 If the server has not previously negotiated a secret with the client, 3017 the server MUST use a secret that has been selected for the client 3018 through some external mechanism. 3020 22. DHCP options 3022 Options are used to carry additional information and parameters 3023 in DHCP messages. Every option shares a common base format, as 3024 described in section 22.1. All values in options is represented in 3025 network order. 3027 This document describes the DHCP options defined as part of the base 3028 DHCP specification. Other options may be defined in the future in a 3029 separate document. 3031 22.1. Format of DHCP options 3033 0 1 2 3 3034 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 3035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3036 | option-code | option-len | 3037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3038 | option-data | 3039 | (option-len octets) | 3040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3042 option-code An unsigned integer identifying the specific option 3043 type carried in this option. 3045 option-len An unsigned integer giving the length of the 3046 option-data field in this option in octets. 3048 option-data The data for the option; the format of this data 3049 depends on the definition of the option. 3051 DHCPv6 options are scoped by using encapsulation. Some options apply 3052 generally to the client, some are specific to an IA, and some are 3053 specific to the addresses within an IA. These latter two cases are 3054 discussed in sections 22.3 and 22.4. 3056 22.2. DHCP unique identifier option 3058 The DHCP unique identifier option is used to carry a DUID. The format 3059 for the DUID is keyed to mark the type of identifier and is of 3060 variable length. The format of the DUID option is: 3062 0 1 2 3 3063 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 3064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3065 | OPTION DUID | option-len | 3066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3067 | DUID type | DUID | 3068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3069 | | 3070 . DUID (cont.) . 3071 . . 3072 . . 3073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3075 22.3. Identity association option 3077 The identity association option is used to carry an identity 3078 association, the parameters associated with the IA and the addresses 3079 assigned to the IA. 3081 The format of the IA option is: 3083 0 1 2 3 3084 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 3085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3086 | OPTION IA | option-len | 3087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3088 | IAID (4 octets) | 3089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3090 | T1 | 3091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3092 | T2 | 3093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3094 | IA Status | | 3095 +-+-+-+-+-+-+-+-+ | 3096 . Options . 3097 . . 3098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3100 option-code OPTION_IA (TBD) 3102 option-len See section 22. 3104 IAID The unique identifier for this IA. 3106 T1 The time at which the client contacts the 3107 server from which the addresses in the IA 3108 were obtained to extend the lifetimes of the 3109 addresses assigned to the IA. 3111 T2 The time at which the client contacts any 3112 available server to extend the lifetimes of 3113 the addresses assigned to the IA. 3115 IA status Status of the IA in this option. 3117 options Options associated with this IA. 3119 The Options field encapsulates those options that are specific 3120 to this IA. For example, all of the Address Options carrying the 3121 addresses associated with this IA are in the Options field. 3123 Note that an IA has no explicit "lifetime" or "lease length" of 3124 its own. When the lifetimes of all of the addresses in an IA have 3125 expired, the IA can be considered as having expired. T1 and T2 3126 are included to give servers explicit control over when a client 3127 recontacts the server about a specific IA. 3129 In a message sent by a client to a server, values in the T1 and 3130 T2 fields indicate the client's preference for those parameters. 3131 The client may send 0 if it has no preference for T1 and T2. In a 3132 message sent by a server to a client, the client MUST use the values 3133 in the T1 and T2 fields for the T1 and T2 parameters. The values in 3134 the T1 and T2 fields are the number of seconds until T1 and T2. 3136 The server MUST set the T1 and T2 times to values that will allow 3137 the client to extend as appropriate the lifetimes of any addresses 3138 in the IA. If the server does not intend for a client to extend the 3139 lifetimes of a particular address in an IA, the server MAY set the 3140 renewal time values to occur after the lifetimes on that address 3141 expire. 3143 T1 is the time at which the client SHOULD begin the lifetime 3144 extension process by sending a Renew message to the server that 3145 originally assigned the addresses to the IA. T2 is the time at which 3146 the client SHOULD start sending a Rebind message to any server. A 3147 client MAY begin the lifetime extension process prior to T1 if it 3148 needs additional addresses for some reason. 3150 T1 and T2 are specified as unsigned integers that specify the time 3151 in seconds relative to the time at which the messages containing the 3152 option is received. 3154 22.4. IA Address option 3156 The IA Address option is used to specify IPv6 addresses associated 3157 with an IA. The IA Address option must be encapsulated in the 3158 Options field of an Identity Association option. The Options field 3159 encapsulates those options that are specific to this address. 3161 The format of the IA Address option is: 3163 0 1 2 3 3164 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 3165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3166 | OPTION_IAADDR | option-len | 3167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3168 |T| addr status | prefix length | | 3169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3170 | IPv6 address | 3171 | (16 octets) | 3172 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3173 | | preferred lifetime | 3174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3175 | pref. lifetime (cont.) | valid lifetime | 3176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3177 | valid lifetime (cont.) | | 3178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3179 . . 3180 . Options . 3181 . . 3182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3184 option-code OPTION_IADDR (TBD) 3186 option-len See section 22. 3188 T When set to 1, indicates that this address is a 3189 "temporary address" [17]; when set to 0, the address 3190 is not a temporary address. 3192 addr status Status of this address in this IA. 3194 prefix length Prefix length for this address. 3196 IPv6 address An IPv6 address 3198 preferred lifetime The preferred lifetime for the IPv6 address in 3199 the option. 3201 valid lifetime The valid lifetime for the IPv6 address in the 3202 option 3204 options Options associated with this address 3206 In a message sent by a client to a server, values in the preferred 3207 and valid lifetime fields indicate the client's preference for those 3208 parameters. The client may send 0 if it has no preference for the 3209 preferred and valid lifetimes. In a message sent by a server to a 3210 client, the client MUST use the values in the preferred and valid 3211 lifetime fields for the preferred and valid lifetimes. The values in 3212 the preferred and valid lifetimes are the number of seconds remaining 3213 in each lifetime. 3215 One or more IA Address Options can appear anywhere in an IA option. 3217 22.5. Requested Temporary Addresses (RTA) Option 3219 The Requested Temporary Addresses (RTA) option is used by a client to 3220 request a server to assign additional temporary addresses to an IA. 3222 0 1 2 3 3223 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 3224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3225 | OPTION_RTA | option-len | 3226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3227 | num-requested | 3228 +-+-+-+-+-+-+-+-+ 3230 option-code OPTION_RTA (TBD) 3232 option-len See section 22. 3234 num-requested The number of additional temporary addresses the 3235 client is requesting. This is an unsigned value. 3237 This option MUST only be sent by a client and only in a Solicit, 3238 Request, Renew, or Rebind message. It MUST only appear encapsulated 3239 within an Identity association option. A client that does not need 3240 any additional temporary addresses does not need to include this 3241 option. 3243 22.6. Option request option 3245 0 1 2 3 3246 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 3247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3248 | OPTION_ORO | option-len | 3249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3250 | requested-option-code-1 | requested-option-code-2 | 3251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3252 | ... | 3253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3255 option-code OPTION_ORO (TBD) 3257 option-len See section 22. 3259 requested-option-code-n The option code for an option requested by 3260 the client. 3262 A client MAY include an Option Request option in a Solicit, Request, 3263 Renew, Rebind or Confirm message to inform the server about options 3264 the client wants the server to send to the client. 3266 22.7. Preference option 3268 0 1 2 3 3269 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 3270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3271 | OPTION_PREFERENCE | option-len | 3272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3273 | pref value | 3274 +-+-+-+-+-+-+-+-+ 3276 option-code OPTION_PREFERENCE (TBD) 3278 option-len See section 22. 3280 pref value The preference value for the server in this message. 3282 A server MAY include a Preference option in an Advertise message to 3283 control the selection of a server by the client. See section 17.1.3 3284 for the use of the Preference option by the client and the 3285 interpretation of Preference option data value. 3287 22.8. Elapsed Time 3289 0 1 2 3 3290 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 3291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3292 | OPTION_ELAPSED_TIME | option-len | 3293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3294 | elapsed time | 3295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3297 option-code OPTION_ELAPSED_TIME (TBD) 3299 option-len See section 22. 3301 elapsed time The amount of time since the client began its 3302 current DHCP transaction. This time is expressed in 3303 hundredths of a second (10^-2 seconds). 3305 A client MAY include an Elapsed Time option in messages to indicate 3306 how long the client has been trying to complete a DHCP transaction. 3307 Servers and Relay Agents MAY use the data value in this option 3308 as input to policy controlling how a server responds to a client 3309 message. 3311 22.9. Client message option 3313 0 1 2 3 3314 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 3315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3316 | OPTION_CLIENT_MSG | option-len | 3317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3318 | | 3319 . DHCP client message . 3320 . . 3321 . . 3322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3324 option-code OPTION_CLIENT_MSG (TBD) 3326 option-len See section 22. 3328 DHCP client message The message received from the client; 3329 forwarded verbatim to the server. 3331 A relay agent forwards a message from a client to a server as the 3332 contents of a Client Message option in a Relay-forward message. 3334 22.10. Server message option 3336 0 1 2 3 3337 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 3338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3339 | OPTION_SERVER_MSG | option-len | 3340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3341 | | 3342 . DHCP server message . 3343 . . 3344 . . 3345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3347 option-code OPTION_SERVER_MSG (TBD) 3349 option-len See section 22. 3351 DHCP server message The message received from the server; 3352 forwarded verbatim to the client. 3354 A server sends a DHCP message to be forwarded to a client by a relay 3355 agent as the contents of a Server Message option in a Relay-reply 3356 message. 3358 22.11. DSTM Global IPv4 Address Option 3360 The DSTM Global IPv4 Address Option informs a client or server that 3361 the Identity Association Option (IA) encapsulated in this option 3362 contains or requests an IPv4-Mapped IPv6 Address [10], as used in the 3363 ``Dual Stack Transition Mechanism'' (DSTM) [3]. 3365 0 1 2 3 3366 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 3367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3368 | OPTION_DSTM | option-len | 3369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3370 . . 3371 . options . 3372 . . 3373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3375 option-code OPTION_DSTM (TBD) 3377 option-len See section 22. 3379 options Options associated with DSTM. 3381 One Identity Association Option MUST always be encapsulated within 3382 the DSTM Global IPv4 Address Option options field and that Identity 3383 Association MUST only be used for IPv4-Mapped IPv6 Addresses. 3385 A DSTM Tunnel End Point Option MAY be encapsulated within the DSTM 3386 Global IPv4 Address Option to specify one or more tunnel endpoints. 3388 DISCUSSION: 3390 By encapsulation the Identity Association Option within 3391 the DSTM Global IPv4 Address Option, a server that does 3392 not support the address type will simply ignore the entire 3393 option and therefore not improperly allocate any addresses 3394 to the Identity Association. This technique of using an 3395 address typing option, SHOULD be used for other address 3396 types that may be needed in the future. 3398 22.12. DSTM Tunnel EndPoint Option 3400 A DSTM Tunnel EndPoint Option can be used to provide a set of IPv6 3401 addresses to be used as the Tunnel Endpoint (TEP) to encapsulate an 3402 IPv6 packet within IPv6. 3404 0 1 2 3 3405 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 3406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3407 | OPTION_DSTM_TEP | option-length | 3408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3409 | Tunnel End Point (TEP) | 3410 | (16 octets) | 3411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3413 option-code OPTION_DSTM_TEP (TBD) 3415 option-len See section 22. 3417 tunnel end point IPv6 address or addresses. 3419 A DSTM Tunnel EndPoint Option MUST NOT be used except when 3420 encapsulated in a DSTM Global IPv4 Address option. 3422 22.13. Authentication option 3424 The Authentication option carries authentication information to 3425 authenticate the identity and contents of DHCP messages. The use of 3426 the Authentication option is described in section 21. 3428 The format of the Authentication option is: 3430 0 1 2 3 3431 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 3432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3433 | OPTION_AUTH | option-len | 3434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3435 | Protocol | Algorithm | RDM | Replay detect.| 3436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3437 | Replay Detection (64 bits) | 3438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3439 | Replay cont. | Auth. Info | 3440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3441 | | 3442 | Authentication Information | 3443 | | 3444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3446 option-code OPTION_AUTH (TBD) 3448 option-len See section 22. 3450 protocol The authentication protocol used in 3451 this authentication option 3453 algorithm The algorithm used in the 3454 authentication protocol 3456 RDM The replay detection method used in 3457 this authentication option 3459 Replay detection The replay detection information for 3460 the RDM 3462 Authentication information The authentication information, 3463 as specified by the protocol and 3464 algorithm used in this authentication 3465 option 3467 22.14. Server unicast option 3469 The server MAY send this option to a client to indicate to the client 3470 that is allowed to unicast messages to the server. When a client 3471 receives this option, where permissible, the client MAY send messages 3472 to the server using the IPv6 address that the server specifies in the 3473 server address field in this option. 3475 Details about when the client may send messages to the server using 3476 unicast are in section 18. 3478 0 1 2 3 3479 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 3480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3481 | OPTION_UNICAST | option-len | 3482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3484 option-code OPTION_UNICAST (TBD) 3486 option-len See section 22. 3488 22.15. Domain Search Option 3490 This option provides a list of domain names a client can use to 3491 resolve DNS names. 3493 0 1 2 3 3494 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 3495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3496 | OPTION_DOMAIN_SEARCH_LIST | option-len | 3497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3498 | Domain Search List | 3499 | ... | 3500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3502 option-code OPTION_DOMAIN_SEARCH_LIST (TBD) 3504 option-len See section 22. 3506 Domain Search List The DNS domain search list the client 3507 should use to resolve names. 3509 The domain search list is stored in the option according to 3510 section 10. 3512 22.16. Domain Name Server Option 3514 This option provides a list of one or more IP addresses of DNS 3515 servers to which a client's DNS resolver MAY send DNS [14] queries. 3516 The DNS servers are listed in the order of preference for use by the 3517 client resolver. 3519 0 1 2 3 3520 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 3521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3522 | OPTION_DNS_SERVERS | option-len | 3523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3524 | | 3525 | DNS server (IP address) | 3526 | | 3527 | | 3528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3529 | | 3530 | DNS server (IP address) | 3531 | | 3532 | | 3533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3534 | ... | 3535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3537 option-code OPTION_DNS_SERVERS (11) 3539 option-len See section 22. 3541 DNS server IPv6 address of a DNS name server for the 3542 client to use. 3544 22.17. Status Code Option 3546 This option returns a status indication related to the DHCP message 3547 in which it appears. 3549 0 1 2 3 3550 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 3551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3552 | OPTION_STATUS_CODE | option-len | 3553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3554 | status-code | status-message | 3555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3556 | ... | 3557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3559 option-code OPTION_STATUS_CODE (TBD) 3560 option-len See section 22. 3562 status-code The numeric code for the status encoded in 3563 this option. The status codes are defined in 3564 section 7.4. 3566 status-message A UTF-8 encoded text string, which MUST NOT 3567 be null-terminated. 3569 22.18. Circuit-ID Option 3571 The relay agent MAY send the Circuit-ID option to identify the 3572 circuit-id on which the client message was received. 3574 0 1 2 3 3575 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 3576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3577 | OPTION_CIRCUIT_ID | option-len | 3578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3579 | | 3580 | Circuit-ID | 3581 . . 3582 . . 3583 . . 3584 | | 3585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3587 option-code OPTION_CIRCUIT_ID (TBD) 3589 option-len See section 22. 3591 Circuit-ID An opaque value of arbitrary length generated 3592 by the relay agent. 3594 The server MUST copy the Circuit-ID option from the Relay-Forward 3595 message into the Relay-Reply message the server sends to the relay 3596 agent in response to the Relay-Forward message. This option MUST NOT 3597 appear in any message except a Relay-Forward or Relay-Reply message. 3599 22.19. User Class Option 3601 This option is used by a client to identify the type or category of 3602 user or applications it represents. The information contained in 3603 this option is an opaque field that represents the user class of 3604 which the client is a member. The user class information carried in 3605 this option MUST be configurable on the client. 3607 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 3608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3609 | OPTION_USER_CLASS | option-len | 3610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3611 | user class data | 3612 | . . . | 3613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3615 option-code TBD 3617 option-len See section 22. 3619 user class data The user classes carried by the client. 3621 The user class option MUST contain one or more instances of user 3622 class data. Each instance of the user class data is formatted as 3623 follows: 3625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 3626 | user class len | user class data | 3627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 3629 The user class len is two octets long and specifies the length of the 3630 opaque user class data in network order. 3632 Servers can interpret the meanings of multiple class specifications 3633 in an implementation dependent or configuration dependent manner, 3634 and so the use of multiple classes by a DHCP client should be based 3635 on the specific server implementation and configuration which will 3636 be used to process that User class option. Servers not equipped to 3637 interpret the user class information sent by a client MUST ignore it 3638 (although it may be reported). 3640 22.20. Vendor Class Option 3642 This option is used by clients and servers to exchange 3643 vendor-specific information. The definition of this information 3644 is vendor specific. The vendor is indicated in the vendor 3645 class identifier option. Servers not equipped to interpret 3646 the vendor-specific information sent by a client MUST ignore it 3647 (although it may be reported). Clients which do not receive desired 3648 vendor-specific information SHOULD make an attempt to operate without 3649 it, although they may do so (and announce they are doing so) in a 3650 degraded mode. 3652 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 3653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3654 | OPTION_VENDOR_CLASS | option-len | 3655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3656 | vendor-id | 3657 . . 3658 . . 3659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3660 | option-data | 3661 . . 3662 . . 3663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3665 option-code TBD 3667 option-len See section 22. 3669 vendor-id A domain name belonging to the vendor used to 3670 identify the vendor that defined this vendor 3671 class option. 3673 option-data An opaque object of option-len octets, 3674 presumably interpreted by vendor-specific 3675 code on the clients and servers 3677 The vendor-id must adhere to the rules in section 10. 3679 The Encapsulated vendor-specific options field MUST be encoded as 3680 a sequence of code/length/value fields of identical format to the 3681 DHCP options field. Each of the encapsulated options is formatted as 3682 follows. 3684 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 3685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3686 | opt-code | option-len | 3687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3688 | option-data | 3689 | . . . | 3690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3692 opt-code The code for the encapsulated option 3694 option-len See section 22. 3696 option-data The data area for the encapsulated option 3698 22.21. SIP Servers Domain Name List 3700 This option specifies a list of fully-qualified domain names 3701 to be used by the SIP client to locate a SIP server (see 3702 [22] for more details. 3704 The option MAY contain multiple domain names, but these SHOULD refer 3705 to different SRV records, rather than different A records. Domain 3706 names SHOULD be listed in order of preference. 3708 0 1 2 3 3709 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 3710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3711 | OPTION_SIP_SERVER_D | option-len | 3712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3713 | SIP Server Domain Name List | 3714 | ... | 3715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3717 option-code OPTION_SIP_SERVER_D (TBD) 3719 option-len See section 22. 3721 SIP Server Domain List The list of SIP servers the client 3722 should use (see section 10 for 3723 encoding details). 3725 22.22. SIP Servers IPv6 Address List 3727 This option specifies a list of IPv6 addresses indicating 3728 SIP outbound proxy servers available to the client (see 3729 [22] for more details. Servers SHOULD be 3730 listed in order of preference. 3732 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 3733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3734 | OPTION_SIP_SERVER_A | option-len | 3735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3736 | | 3737 | SIP Server (IP address) | 3738 | | 3739 | | 3740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3741 | | 3742 | SIP Server (IP address) | 3743 | | 3744 | | 3745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3746 | ... | 3747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3748 option-code OPTION_SIP_SERVER_A (TBD) 3750 option-len See section 22. 3752 SIP Server IPv6 address of a SIP server for the client to use. 3753 The servers are listed in the order of preference for 3754 use by the client. 3756 23. Security Considerations 3758 Section 21 describes a threat model and an option that provides an 3759 authentication framework to defend against that threat model. 3761 24. Year 2000 considerations 3763 Since all times are relative to the current time of the transaction, 3764 there is no problem within the DHCPv6 protocol related to any 3765 hardcoded dates or two-digit representation of the current year. 3767 25. IANA Considerations 3769 This document defines several new name spaces associated with DHCPv6 3770 and DHCPv6 options. IANA is requested to manage the allocation of 3771 values from these name spaces, which are described in the remainder 3772 of this section. These name spaces are all to be managed separately 3773 from the name spaces defined for DHCPv4 [8, 2]. 3775 New values in each of these name spaces should be approved by the 3776 process of IETF consensus [16]. 3778 25.1. Multicast addresses 3780 Section 7.1 defines the following multicast addresses, which have 3781 been assigned by IANA for use by DHCPv6: 3783 All_DHCP_Agents address: FF02::1:2 3785 All_DHCP_Servers address: FF05::1:3 3787 IANA is requested to manage definition of additional multicast 3788 addresses in the future. 3790 25.2. DHCPv6 message types 3792 IANA is requested to record the message types defined in section 7.3. 3793 IANA is requested to manage definition of additional message types in 3794 the future. 3796 25.3. DUID 3798 IANA is requested to record the DUID types defined in section 11.1. 3799 IANA is requested to manage definition of additional DUID types in 3800 the future. 3802 25.4. DHCPv6 options 3804 IANA is requested to assign option-codes to the options defined 3805 in section 22.1. IANA is requested to manage the definition of 3806 additional DHCPv6 option-codes in the future. 3808 25.5. Status codes 3810 IANA is requested to record the status codes defined in section 7.4. 3811 IANA is requested to manage the definition of additional status codes 3812 in the future. 3814 25.6. Authentication option 3816 Section 21 defines three new name spaces associated with the 3817 Authentication Option (section 22.13), which are to be created and 3818 maintained by IANA: Protocol, Algorithm and RDM. 3820 Initial values assigned from the Protocol name space are 0 (for the 3821 configuration token Protocol in section 21.5) and 1 (for the delayed 3822 authentication Protocol in section 21.6). Additional protocols may 3823 be defined in the future. 3825 The Algorithm name space is specific to individual Protocols. That 3826 is, each Protocol has its own Algorithm name space. The guidelines 3827 for assigning Algorithm name space values for a particular protocol 3828 should be specified along with the definition of a new Protocol. 3830 For the configuration token Protocol, the Algorithm field MUST be 3831 0, as described in section 21.5. For the delayed authentication 3832 Protocol, the Algorithm value 1 is assigned to the HMAC-MD5 3833 generating function as defined in section 21.6. Additional 3834 algorithms for the delayed authentication protocol may be defined in 3835 the future. 3837 The initial value of 0 from the RDM name space is assigned to the 3838 use of a monotonically increasing value as defined in section 21.4. 3839 Additional replay detection methods may be defined in the future. 3841 26. Acknowledgments 3843 Thanks to the DHC Working Group for their time and input into 3844 the specification. In particular, thanks also for the consistent 3845 input, ideas, and review by (in alphabetical order) Brian Carpenter, 3846 Matt Crawford, Francis Dupont, Ted Lemon, Josh Littlefield, Gerald 3847 Maguire, Jack McCann, Thomas Narten, Erik Nordmark, Yakov Rekhter, 3848 Mark Stapp, Matt Thomas, Sue Thomson, Bernie Volz and Phil Wells. 3850 Thanks to Steve Deering and Bob Hinden, who have consistently 3851 taken the time to discuss the more complex parts of the IPv6 3852 specifications. 3854 Bill Arbaugh reviewed the authentication mechanism described in 3855 section 21. 3857 The Domain Search option described in section 22.15 is based on the 3858 DHCPv4 domain search option, [1], and was reviewed by Bernard Aboba. 3860 And, thanks to Steve Deering for pointing out at IETF 51 in London 3861 that the DHCPv6 specification has (at least currently) the highest 3862 revision number of any Internet Draft. 3864 A. Full Copyright Statement 3866 Copyright (C) The Internet Society (2001). All Rights Reserved. 3868 This document and translations of it may be copied and furnished to 3869 others, and derivative works that comment on or otherwise explain it 3870 or assist in its implementation may be prepared, copied, published 3871 and distributed, in whole or in part, without restriction of any 3872 kind, provided that the above copyright notice and this paragraph 3873 are included on all such copies and derivative works. However, 3874 this document itself may not be modified in any way, such as by 3875 removing the copyright notice or references to the Internet Society 3876 or other Internet organizations, except as needed for the purpose 3877 of developing Internet standards in which case the procedures 3878 for copyrights defined in the Internet Standards process must be 3879 followed, or as required to translate it into languages other than 3880 English. 3882 The limited permissions granted above are perpetual and will not be 3883 revoked by the Internet Society or its successors or assigns. 3885 This document and the information contained herein is provided on an 3886 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3887 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3888 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3889 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3890 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3892 B. Appearance of Options in Message Types 3894 The following table indicates with a "*" the options are allowed in 3895 each DHCP message type: 3897 DUID IA RTA ORO Pref Time Client Server DSTM DSTM 3898 Forw. Forw. Addr Tunn 3899 Solicit * * * * 3900 Advert. * * * * * * * 3901 Request * * * * 3902 Confirm * * * * 3903 Renew * * * * 3904 Rebind * * * * 3905 Decline * * * * 3906 Release * * * * 3907 Reply * * * * * * * 3908 Reconf. * * 3909 Inform. * * 3910 R-forw. * * 3911 R-repl. * * 3913 Auth Server Domain Domain Status Circ. User Vendor 3914 Unica. Search Server Code ID Class Class 3915 Solicit * * * 3916 Advert. * * * 3917 Request * * * 3918 Confirm * * * 3919 Renew * * * 3920 Rebind * * * 3921 Decline * * * * 3922 Release * * * * 3923 Reply * * * * * 3924 Reconf. * 3925 Inform. * * * 3926 R-forw. * * 3927 R-repl. * * 3928 C. Appearance of Options in the Options Field of DHCP Messages 3930 The following table indicates with a "*" where options can appear in 3931 the options field or encapsulated in other options: 3933 Option IA IAADDR RTA DSTM Client Server 3934 Field Addr Forw. Forw. 3935 Client msg. * * 3936 Server msg. * * 3937 DUID * 3938 IA * * 3939 IAADDR * 3940 RTA * 3941 ORO * 3942 Pref * 3943 Time * 3944 Client Forw. * 3945 Server Forw. * 3946 DSTM Addr. * 3947 DSTM Tunnel * 3948 Authentic. * 3949 Server Uni. * 3950 Dom. Srch. * 3951 Dom. Server * 3952 Status Cod. * * * 3953 Circ. ID * * 3954 User Class * 3955 Vend. Class * 3957 References 3959 [1] B. Aboba. DHCP Domain Search Option. Internet Draft, Internet 3960 Engineering Task Force, December 2000. Work in progress. 3962 [2] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 3963 Extensions, March 1997. RFC 2132. 3965 [3] J. Bound, L. Toutain, F. Dupont, O. Medina, A. Hossam, and 3966 A. Durand. Dual Stack Transition Mechanism (DSTM). Internet 3967 Draft, Internet Engineering Task Force, November 2001. Work in 3968 progress. 3970 [4] S. Bradner. Key words for use in RFCs to Indicate Requirement 3971 Levels, March 1997. RFC 2119. 3973 [5] S. Bradner and A. Mankin. The Recommendation for the IP Next 3974 Generation Protocol, January 1995. RFC 1752. 3976 [6] W.J. Croft and J. Gilmore. Bootstrap Protocol, September 1985. 3977 RFC 951. 3979 [7] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 3980 Specification, December 1998. RFC 2460. 3982 [8] R. Droms. Dynamic Host Configuration Protocol, March 1997. RFC 3983 2131. 3985 [9] R. Droms, Editor, W. Arbaugh, and Editor. Authentication for 3986 DHCP Messages, June 2001. RFC 3118. 3988 [10] R. Hinden and S. Deering. IP Version 6 Addressing Architecture, 3989 July 1998. RFC 2373. 3991 [11] S. Kent and R. Atkinson. Security Architecture for the Internet 3992 Protocol, November 1998. RFC 2401. 3994 [12] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 3995 for Message Authentication, February 1997. RFC 2104. 3997 [13] David L. Mills. Network Time Protocol (Version 3) 3998 Specification, Implementation, March 1992. RFC 1305. 4000 [14] P.V. Mockapetris. Domain names - concepts and facilities, 4001 November 1987. RFC 1034. 4003 [15] P.V. Mockapetris. Domain names - implementation and 4004 specification, November 1987. RFC 1035. 4006 [16] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 4007 Considerations Section in RFCs, October 1998. RFC 2434. 4009 [17] T. Narten and R. Draves. Privacy Extensions for Stateless 4010 Address Autoconfiguration in IPv6, January 2001. RFC 3041. 4012 [18] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 4013 IP Version 6 (IPv6), December 1998. RFC 2461. 4015 [19] D.C. Plummer. Ethernet Address Resolution Protocol: Or 4016 converting network protocol addresses to 48.bit Ethernet address 4017 for transmission on Ethernet hardware, November 1982. RFC 826. 4019 [20] J. Postel. User Datagram Protocol, August 1980. RFC 768. 4021 [21] R. Rivest. The MD5 Message-Digest Algorithm, April 1992. RFC 4022 1321. 4024 [22] H. Schulzrinne and J. Rosenberg. SIP: Session Initiation 4025 Protocol -- Locating SIP Servers. Internet Draft, Internet 4026 Engineering Task Force, March 2001. Work in progress. 4028 [23] S. Thomson and T. Narten. IPv6 Stateless Address 4029 Autoconfiguration, December 1998. RFC 2462. 4031 [24] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic 4032 Updates in the Domain Name System (DNS UPDATE), April 1997. RFC 4033 2136. 4035 Chair's Address 4037 The working group can be contacted via the current chair: 4039 Ralph Droms 4040 Cisco Systems 4041 300 Apollo Drive 4042 Chelmsford, MA 01824 4044 Phone: (978) 244-4733 4045 E-mail: rdroms@cisco.com 4047 Authors' Addresses 4049 Questions about this memo can be directed to: 4051 Jim Bound 4052 Compaq Computer Corporation 4053 ZK3-3/W20 4054 110 Spit Brook Road 4055 Nashua, NH 03062-2698 4056 USA 4057 Phone: +1 603 884 0062 4058 Email: Jim.Bound@compaq.com 4060 Mike Carney 4061 Sun Microsystems, Inc 4062 Mail Stop: UMPK17-202 4063 901 San Antonio Road 4064 Palo Alto, CA 94303-4900 4065 USA 4066 Phone: +1-650-786-4171 4067 Email: mwc@eng.sun.com 4069 Charles E. Perkins 4070 Communications Systems Lab 4071 Nokia Research Center 4072 313 Fairchild Drive 4073 Mountain View, California 94043 4074 USA 4075 Phone: +1-650 625-2986 4076 Email: charliep@iprg.nokia.com 4077 Fax: +1 650 625-2502 4079 Ralph Droms 4080 Cisco Systems 4081 300 Apollo Drive 4082 Chelmsford, MA 01824 4083 USA 4084 Phone: +1 978 244 4733 4085 Email: rdroms@cisco.com