idnits 2.17.1 draft-ietf-dhc-dhcpv6-17.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 62 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. ** There are 16 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([13]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 260: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 261: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 299: '...ess, that client MUST fragment its pac...' RFC 2119 keyword, line 566: '... source ports MAY be arbitrary, clie...' RFC 2119 keyword, line 583: '...are reserved and MUST be silently igno...' (128 more instances...) -- The draft header indicates that this document obsoletes draft-ietf-dhc-dhcpv6-16.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 -- No information found for rfcdraft-ietf-dhc-dhcpv6-16.txt - is the name correct? -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 March 2001) is 8450 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) == Unused Reference: '4' is defined on line 2905, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. '5') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2373 (ref. '7') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 1981 (ref. '8') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2434 (ref. '9') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2461 (ref. '10') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '13') (Obsoleted by RFC 4862) Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 4 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 Nokia 3 DHC Working Group M. Carney 4 Obsoletes: draft-ietf-dhc-dhcpv6-16.txt Sun Microsystems, Inc 5 C. Perkins 6 Nokia Research Center 7 R. Droms(ed.) 8 Cisco Systems 9 1 March 2001 11 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 12 draft-ietf-dhc-dhcpv6-17.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 dhcp-v6@bucknell.edu 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" [13], 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 1 58 3. Background 1 60 4. Design Goals 3 62 5. Non-Goals 3 64 6. Terminology 4 65 6.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 4 66 6.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 5 68 7. DHCP Constants 6 69 7.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 7 70 7.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 7 71 7.3. DHCP message types . . . . . . . . . . . . . . . . . . . 7 72 7.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 9 73 7.4.1. Generic Error Values . . . . . . . . . . . . . . 9 74 7.4.2. Server-specific Error Values . . . . . . . . . . 9 75 7.5. Configuration Variables . . . . . . . . . . . . . . . . . 10 77 8. Overview 10 78 8.1. How does a node know to use DHCP? . . . . . . . . . . . . 10 79 8.2. What if the client and server(s) are on different links? 10 80 8.3. How does a client request configuration parameters from 81 servers? . . . . . . . . . . . . . . . . . . . . . . . 11 82 8.4. How do clients and servers identify and manage addresses? 11 83 8.5. Can a client release its assigned addresses before the lease 84 expires? . . . . . . . . . . . . . . . . . . . . . . . 12 85 8.6. What if the client determines one or more of its assigned 86 addresses are already being used by another client? . 12 87 8.7. How are clients notified of server configuration changes? 12 89 9. Message Formats 13 90 9.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 13 91 9.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 14 92 9.3. DHCP Request Message Format . . . . . . . . . . . . . . . 14 93 9.4. DHCP Confirm Message Format . . . . . . . . . . . . . . . 14 94 9.5. DHCP Renew Message Format . . . . . . . . . . . . . . . . 15 95 9.6. DHCP Rebind Message Format . . . . . . . . . . . . . . . 15 96 9.7. DHCP Reply Message Format . . . . . . . . . . . . . . . . 16 97 9.8. DHCP Release Message Format . . . . . . . . . . . . . . . 16 98 9.9. DHCP Decline Message Format . . . . . . . . . . . . . . . 16 99 9.10. DHCP Reconfigure-init Message Format . . . . . . . . . . 17 101 10. Relay messages 17 102 10.1. Relay-forward message . . . . . . . . . . . . . . . . . . 17 103 10.2. Relay-reply message . . . . . . . . . . . . . . . . . . . 18 105 11. Identity association 18 107 12. DHCP Server Solicitation 19 108 12.1. Solicit Message Validation . . . . . . . . . . . . . . . 19 109 12.2. Advertise Message Validation . . . . . . . . . . . . . . 19 110 12.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 19 111 12.3.1. Creation and sending of the Solicit message . . . 19 112 12.3.2. Time out and retransmission of Solicit Messages . 20 113 12.3.3. Receipt of Advertise messages . . . . . . . . . . 20 114 12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 21 115 12.4.1. Receipt of Solicit messages . . . . . . . . . . . 21 116 12.4.2. Creation and sending of Advertise messages . . . 21 118 13. DHCP Client-Initiated Configuration Exchange 22 119 13.1. Client Message Validation . . . . . . . . . . . . . . . . 22 120 13.2. Server Message Validation . . . . . . . . . . . . . . . . 23 121 13.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 23 122 13.3.1. Creation and sending of Request messages . . . . 24 123 13.3.2. Creation and sending of Confirm messages . . . . 24 124 13.3.3. Creation and sending of Renew messages . . . . . 26 125 13.3.4. Creation and sending of Rebind messages . . . . . 27 126 13.3.5. Receipt of Reply message in response to a Reply, 127 Confirm, Renew or Rebind message . . . . . 28 128 13.3.6. Creation and sending of Release messages . . . . 29 129 13.3.7. Time out and retransmission of Release Messages . 29 130 13.3.8. Creation and sending of Decline messages . . . . 30 131 13.3.9. Time out and retransmission of Decline Messages . 30 132 13.3.10. Receipt of Reply message in response to a Release 133 message . . . . . . . . . . . . . . . . . 31 134 13.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 31 135 13.4.1. Receipt of Request messages . . . . . . . . . . . 31 136 13.4.2. Receipt of Confirm messages . . . . . . . . . . . 32 137 13.4.3. Receipt of Renew messages . . . . . . . . . . . . 32 138 13.4.4. Receipt of Rebind messages . . . . . . . . . . . 33 139 13.4.5. Receipt of Release messages . . . . . . . . . . . 34 140 13.4.6. Sending of Reply messages . . . . . . . . . . . . 35 142 14. DHCP Server-Initiated Configuration Exchange 35 143 14.1. Reconfigure-init Message Validation . . . . . . . . . . . 35 144 14.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 35 145 14.2.1. Creation and sending of Reconfigure-init messages 36 146 14.2.2. Time out and retransmission of unicast 147 Reconfigure-init messages . . . . . . . . 37 148 14.2.3. Time out and retransmission of multicast 149 Reconfigure-init messages . . . . . . . . 37 150 14.2.4. Receipt of Request messages . . . . . . . . . . . 37 152 14.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 37 153 14.3.1. Receipt of Reconfigure-init messages . . . . . . 37 154 14.3.2. Creation and sending of Request messages . . . . 38 155 14.3.3. Time out and retransmission of Request messages . 38 156 14.3.4. Receipt of Reply messages . . . . . . . . . . . . 38 158 15. Relay Behavior 38 159 15.1. Relaying of Solicit messages . . . . . . . . . . . . . . 39 160 15.2. Relaying of Advertise messages . . . . . . . . . . . . . 39 162 16. DHCP options 39 163 16.1. Format of DHCP options . . . . . . . . . . . . . . . . . 40 164 16.2. Identity association option . . . . . . . . . . . . . . . 40 165 16.3. Option request option . . . . . . . . . . . . . . . . . . 42 166 16.4. Client message option . . . . . . . . . . . . . . . . . . 43 167 16.5. Server message option . . . . . . . . . . . . . . . . . . 43 168 16.6. Retransmission parameter option . . . . . . . . . . . . . 44 169 16.7. Authentication option . . . . . . . . . . . . . . . . . . 44 170 16.8. Reconfigure-delay option . . . . . . . . . . . . . . . . 44 171 16.9. DSTM Global IPv4 Address Option . . . . . . . . . . . . . 44 173 17. DHCP Client Implementor Notes 45 174 17.1. Primary Interface . . . . . . . . . . . . . . . . . . . . 45 175 17.2. Advertise Message and Configuration Parameter Caching . . 46 176 17.3. Time out and retransmission variables . . . . . . . . . . 46 177 17.4. Server Preference . . . . . . . . . . . . . . . . . . . . 46 179 18. DHCP Server Implementor Notes 46 180 18.1. Client Bindings . . . . . . . . . . . . . . . . . . . . . 46 181 18.2. Reconfigure-init Considerations . . . . . . . . . . . . . 47 182 18.2.1. Reliable transmission of multicast Reconfigure-init 183 messages . . . . . . . . . . . . . . . . . 47 184 18.3. Server Preference . . . . . . . . . . . . . . . . . . . . 47 185 18.4. Request Message Transaction-ID Cache . . . . . . . . . . 47 187 19. DHCP Relay Implementor Notes 48 189 20. Open Issues for Working Group Discussion 48 190 20.1. Authentication . . . . . . . . . . . . . . . . . . . . . 48 191 20.2. Identification of IAs by servers . . . . . . . . . . . . 48 192 20.3. DHCP-DNS interaction . . . . . . . . . . . . . . . . . . 48 193 20.4. Anonymous addresses . . . . . . . . . . . . . . . . . . . 48 194 20.5. Use of term "agent" . . . . . . . . . . . . . . . . . . . 48 195 20.6. Client behavior when response to Rebind is not received . 49 196 20.7. Additional options . . . . . . . . . . . . . . . . . . . 49 197 20.8. Operational parameters . . . . . . . . . . . . . . . . . 49 199 21. Security 49 201 22. Year 2000 considerations 49 203 23. IANA Considerations 49 204 24. Acknowledgments 50 206 A. Comparison between DHCPv4 and DHCPv6 50 208 B. Full Copyright Statement 52 210 C. Changes in this draft 53 211 C.1. New messages for confirming addresses and extending the lease 212 on an IA . . . . . . . . . . . . . . . . . . . . . . . 53 213 C.2. New message formats . . . . . . . . . . . . . . . . . . . 53 214 C.3. Renamed Server-forward message . . . . . . . . . . . . . 53 215 C.4. Clarified relay forwarding of messages . . . . . . . . . 53 216 C.5. Addresses and options in Advertise messages . . . . . . . 53 217 C.6. Clarification of IA option format . . . . . . . . . . . . 53 218 C.7. Specification of transaction ID in Solicit message . . . 54 219 C.8. Edits to definitions . . . . . . . . . . . . . . . . . . 54 220 C.9. Relay agent messages . . . . . . . . . . . . . . . . . . 54 221 C.10. Relay agent behavior . . . . . . . . . . . . . . . . . . 54 222 C.11. Transmission of all client messages through relays . . . 54 223 C.12. Reconfigure-init messages . . . . . . . . . . . . . . . . 54 224 C.13. Ordering of sections . . . . . . . . . . . . . . . . . . 54 225 C.14. DSTM option . . . . . . . . . . . . . . . . . . . . . . . 54 227 Chair's Address 57 229 Author's Address 57 230 1. Introduction 232 This document describes DHCP for IPv6 (DHCP), a UDP [12] 233 client/server protocol designed to reduce the cost of management 234 of IPv6 nodes in environments where network managers require more 235 control over the allocation of IPv6 addresses and configuration 236 of network stack parameters than that offered by "IPv6 Stateless 237 Autoconfiguration" [13]. DHCP is a stateful counterpart to 238 stateless autoconfiguration. Note that both stateful and stateless 239 autoconfiguration can be used concurrently in the same environment, 240 leveraging the strengths of both mechanisms in order to reduce the 241 cost of ownership and management of network nodes. 243 DHCP reduces the cost of ownership by centralizing the management 244 of network resources such as IP addresses, routing information, OS 245 installation information, directory service information, and other 246 such information on a few DHCP servers, rather than distributing such 247 information in local configuration files among each network node. 248 DHCP is designed to be easily extended to carry new configuration 249 parameters through the addition of new DHCP "options" defined to 250 carry this information. 252 Those readers familiar with DHCP for IPv4 [6] will find DHCP for IPv6 253 provides a superset of features, and benefits from the additional 254 features of IPv6 and freedom from BOOTP [4]-backward compatibility 255 constraints. For more information about the differences between DHCP 256 for IPv6 and DHCP for IPv4, see Appendix A. 258 2. Requirements 260 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 261 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 262 document, are to be interpreted as described in [2]. 264 This document also makes use of internal conceptual variables 265 to describe protocol behavior and external variables that an 266 implementation must allow system administrators to change. The 267 specific variable names, how their values change, and how their 268 settings influence protocol behavior are provided to demonstrate 269 protocol behavior. An implementation is not required to have them in 270 the exact form described here, so long as its external behavior is 271 consistent with that described in this document. 273 3. Background 275 Related work in IPv6 that would best serve an implementor to study 276 is the IPv6 Specification [5], the IPv6 Addressing Architecture [7], 277 IPv6 Stateless Address Autoconfiguration [13], IPv6 Neighbor 278 Discovery Processing [10], and Dynamic Updates to DNS [15]. These 279 specifications enable DHCP to build upon the IPv6 work to provide 280 both robust stateful autoconfiguration and autoregistration of DNS 281 Host Names. 283 The IPv6 Specification provides the base architecture and design of 284 IPv6. A key point for DHCP implementors to understand is that IPv6 285 requires that every link in the Internet have an MTU of 1280 octets 286 or greater (in IPv4 the requirement is 68 octets). This means that 287 a UDP packet of 536 octets will always pass through an internetwork 288 (less 40 octets for the IPv6 header), as long as there are no IP 289 options prior to the UDP header in the packet. But, IPv6 does not 290 support fragmentation at routers, so that fragmentation takes place 291 end-to-end between hosts. If a DHCP implementation needs to send a 292 packet greater than 1500 octets it can either fragment the UDP packet 293 into fragments of 1500 octets or less, or use Path MTU Discovery [8] 294 to determine the size of the packet that will traverse a network 295 path. 297 DHCP clients use Path MTU discovery when they have an address of 298 sufficient scope to reach the DHCP server. If a DHCP client does not 299 have such an address, that client MUST fragment its packets if the 300 resultant message size is greater than the minimum 1280 octets. 302 Path MTU Discovery for IPv6 is supported for both UDP and TCP and 303 can cause end-to-end fragmentation when the PMTU changes for a 304 destination. 306 The IPv6 Addressing Architecture specification [7] defines the 307 address scope that can be used in an IPv6 implementation, and the 308 various configuration architecture guidelines for network designers 309 of the IPv6 address space. Two advantages of IPv6 are that support 310 for multicast is required, and nodes can create link-local addresses 311 during initialization. This means that a client can immediately use 312 its link-local address and a well-known multicast address to begin 313 communications to discover neighbors on the link. For instance, a 314 client can send a Solicit message and locate a server or relay. 316 IPv6 Stateless Address Autoconfiguration [13] (Addrconf) specifies 317 procedures by which a node may autoconfigure addresses based on 318 router advertisements [10], and the use of a valid lifetime to 319 support renumbering of addresses on the Internet. In addition the 320 protocol interaction by which a node begins stateless or stateful 321 autoconfiguration is specified. DHCP is one vehicle to perform 322 stateful autoconfiguration. Compatibility with addrconf is a design 323 requirement of DHCP (see Section 4). 325 IPv6 Neighbor Discovery [10] is the node discovery protocol in IPv6 326 which replaces and enhances functions of ARP [11]. To understand 327 IPv6 and Addrconf it is strongly recommended that implementors 328 understand IPv6 Neighbor Discovery. 330 Dynamic Updates to DNS [15] is a specification that supports the 331 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 332 the dynamic updates to DNS to integrate addresses and name space to 333 not only support autoconfiguration, but also autoregistration in 334 IPv6. 336 4. Design Goals 338 - DHCP is a mechanism rather than a policy. Network administrators 339 set their administrative policies through the configuration 340 parameters they place upon the DHCP servers in the DHCP domain 341 they're managing. DHCP is simply used to deliver parameters 342 according to that policy to each of the DHCP clients within the 343 domain. 345 - DHCP is compatible with IPv6 stateless autoconf [13]. 347 - DHCP does not require manual configuration of network parameters 348 on DHCP clients, except in cases where such configuration is 349 needed for security reasons. A node configuring itself using 350 DHCP should require no user intervention. 352 - DHCP does not require a server on each link. To allow for scale 353 and economy, DHCP must work across DHCP relays. 355 - DHCP coexists with statically configured, non-participating nodes 356 and with existing network protocol implementations. 358 - DHCP clients can operate on a link without IPv6 routers present. 360 - DHCP will provide the ability to renumber network(s) when 361 required by network administrators [3]. 363 - A DHCP client can make multiple, different requests for 364 configuration parameters when necessary from one or more DHCP 365 servers at any time. 367 - DHCP will contain the appropriate time out and retransmission 368 mechanisms to efficiently operate in environments with high 369 latency and low bandwidth characteristics. 371 5. Non-Goals 373 This specification explicitly does not cover the following: 375 - Specification of a DHCP server to server protocol. 377 - How a DHCP server stores its DHCP data. 379 - How to manage a DHCP domain or DHCP server. 381 - How a DHCP relay is configured or what sort of information it may 382 log. 384 6. Terminology 386 6.1. IPv6 Terminology 388 IPv6 terminology relevant to this specification from the IPv6 389 Protocol [5], IPv6 Addressing Architecture [7], and IPv6 Stateless 390 Address Autoconfiguration [13] is included below. 392 address An IP layer identifier for an interface or 393 a set of interfaces. 395 unicast address An identifier for a single interface. 396 A packet sent to a unicast address is 397 delivered to the interface identified by 398 that address. 400 multicast address An identifier for a set of interfaces 401 (typically belonging to different nodes). 402 A packet sent to a multicast address is 403 delivered to all interfaces identified by 404 that address. 406 host Any node that is not a router. 408 IP Internet Protocol Version 6 (IPv6). The 409 terms IPv4 and IPv6 are used only in 410 contexts where it is necessary to avoid 411 ambiguity. 413 interface A node's attachment to a link. 415 link A communication facility or medium over 416 which nodes can communicate at the link 417 layer, i.e., the layer immediately below 418 IP. Examples are Ethernet (simple or 419 bridged); Token Ring; PPP links, X.25, 420 Frame Relay, or ATM networks; and Internet 421 (or higher) layer "tunnels", such as 422 tunnels over IPv4 or IPv6 itself. 424 link-layer identifier A link-layer identifier for an interface. 425 Examples include IEEE 802 addresses for 426 Ethernet or Token Ring network interfaces, 427 and E.164 addresses for ISDN links. 429 link-local address An IP address having link-only 430 scope, indicated by having the prefix 431 (FE80::0000/64), that can be used to reach 432 neighboring nodes attached to the same 433 link. Every interface has a link-local 434 address. 436 message A unit of data carried in a packet, 437 exchanged between DHCP agents and clients. 439 neighbor A node attached to the same link. 441 node A device that implements IP. 443 packet An IP header plus payload. 445 prefix The initial bits of an address, or a set 446 of IP address that share the same initial 447 bits. 449 prefix length The number of bits in a prefix. 451 router A node that forwards IP packets not 452 explicitly addressed to itself. 454 6.2. DHCP Terminology 456 Terminology specific to DHCP can be found below. 458 abort status A status value returned to the 459 application that has invoked a DHCP 460 client operation, indicating anything 461 other than success. 463 agent address The address of a neighboring DHCP Agent 464 on the same link as the DHCP client. 466 binding A binding (or, client binding) is a 467 group of server data records containing 468 the server's information about the 469 addresses in an IA and any other 470 configuration information assigned to 471 the client. A binding is indexed by the 472 tuple , where the 'prefix' 473 is a prefix assigned to the link to 474 which the client is attached and 'DUID' 475 is the DUID from the IA in the binding. 477 DISCUSSION: 479 The indexing of an IA by is still under discussion. 482 DHCP Dynamic Host Configuration Protocol 483 for IPv6. The terms DHCPv4 and DHCPv6 484 are used only in contexts where it is 485 necessary to avoid ambiguity. 487 configuration parameter An element of the configuration 488 information set on the server and 489 delivered to the client using DHCP. 490 Such parameters may be used to carry 491 information to be used by a node to 492 configure its network subsystem and 493 enable communication on a link or 494 internetwork, for example. 496 DHCP client (or client) A node that initiates requests on a link 497 to obtain configuration parameters from 498 one or more DHCP servers. 500 DHCP domain A set of links managed by DHCP and 501 operated by a single administrative 502 entity. 504 DHCP server (or server) A server is a node that responds to 505 requests from clients, and may or 506 may not be on the same link as the 507 client(s). 509 DHCP relay (or relay) A node that acts as an intermediary to 510 deliver DHCP messages between clients 511 and servers, and is on the same link as 512 a client. 514 DHCP agent (or agent) Either a DHCP server on the same link as 515 a client, or a DHCP relay. 517 DUID A DHCP unique identifier for a client. 519 DISCUSSION: 521 Rules for choosing a DUID are TBD. 523 Identity association (IA) A collection of addresses assigned to 524 a client. Each IA has an associated 525 DUID. An IA may have 0 or more addresses 526 associated with it. 528 transaction-ID An unsigned integer to match responses 529 with replies initiated either by a 530 client or server. 532 7. DHCP Constants 534 This section describes various program and networking constants used 535 by DHCP. 537 7.1. Multicast Addresses 539 DHCP makes use of the following multicast addresses: 541 All DHCP Agents address: FF02::1:2 This link-scoped multicast 542 address is used by clients to communicate with the 543 on-link agent(s) when they do not know those agents' 544 link-local address(es). All agents (servers and 545 relays) are members of this multicast group. 547 All DHCP Servers address: FF05::1:3 This site-scoped multicast 548 address is used by clients or relays to communicate 549 with server(s), either because they want to send 550 messages to all servers or because they do not know 551 the server(s) unicast address(es). Note that in order 552 for a client to use this address, it must have an 553 address of sufficient scope to be reachable by the 554 server(s). All servers within the site are members of 555 this multicast group. 557 DISCUSSION: 559 Is there a requirement for a site-scoped "All DHCP Clients" 560 multicast address, to be used as the default in sending 561 Reconfigure messages. 563 7.2. UDP ports 565 DHCP uses the following destination UDP [12] port numbers. While 566 source ports MAY be arbitrary, client implementations SHOULD permit 567 their specification through a local configuration parameter to 568 facilitate the use of DHCP through firewalls. 570 546 Client port. Used by servers as the destination port 571 for messages sent to clients and relays. Used by relay 572 agents as the destination port for messages sent to 573 clients. 575 547 Agent port. Used as the destination port by clients 576 for messages sent to agents. Used as the destination 577 port by relays for messages sent to servers. 579 7.3. DHCP message types 581 DHCP defines the following message types. More detail on these 582 message types can be found in Section 9. Message types 0 and 583 TBD--255 are reserved and MUST be silently ignored. The message code 584 for each message type is shown with the message name. 586 TBD DHCP Solicit The DHCP Solicit (or Solicit) message 587 is used by clients to locate servers. 589 TBD DHCP Advertise The DHCP Advertise (or Advertise) 590 message is used by servers responding 591 to Solicits. 593 TBD DHCP Request The DHCP Request (or Request) 594 message is used by clients to request 595 configuration parameters from servers. 597 TBD DHCP Confirm The DHCP Confirm (or Confirm) message 598 is used by clients to confirm that 599 the addresses assigned to an IA and 600 the lifetimes for those addresses, 601 as well as the current configuration 602 parameters assigned by the server to 603 the client are still valid. 605 TBD DHCP Renew The DHCP Renew (or Renew) message 606 is used by clients to obtain the 607 addresses assigned to an IA and the 608 lifetimes for those addresses, as 609 well as the current configuration 610 parameters assigned by the server to 611 the client. A client sends a Renew 612 message to the server that originally 613 assigned the IA when the lease on an 614 IA is about to expire. 616 TBD DHCP Rebind The DHCP Rebind (or Rebind) message 617 is used by clients to obtain the 618 addresses assigned to an IA and the 619 lifetimes for those addresses, as 620 well as the current configuration 621 parameters assigned by the server to 622 the client. A clients sends a Rebind 623 message to all available DHCP servers 624 when the lease on an IA is about to 625 expire. 627 TBD DHCP Reply The DHCP Reply (or Reply) message is 628 used by servers responding to Request, 629 Confirm, Renew, Rebind, Release and 630 Decline messages. In the case of 631 responding to a Request, Confirm, 632 Renew or Rebind message, the Reply 633 contains configuration parameters 634 destined for the client. 636 TBD DHCP Release The DHCP Release (or Release) message 637 is used by clients to return one or 638 more IP addresses to servers. 640 TBD DHCP Decline The DHCP Decline (or Decline) message 641 is used by clients to indicate that 642 the client has determined that one or 643 more addresses in an IA are already in 644 use on the link to which the client is 645 connected. 647 TBD DHCP Reconfigure-init The DHCP Reconfigure-init (or 648 Reconfigure-init) message is set by 649 server(s) to inform client(s) that 650 the server(s) has new or updated 651 configuration parameters, and that 652 the client(s) are to initiate a 653 Request/Reply transaction with the 654 server(s) in order to receive the 655 updated information. 657 7.4. Error Values 659 This section describes error values exchanged between DHCP 660 implementations. 662 7.4.1. Generic Error Values 664 The following symbolic names are used between client and server 665 implementations to convey error conditions. The following table 666 contains the actual numeric values for each name. Note that the 667 numeric values do not start at 1, nor are they consecutive. The 668 errors are organized in logical groups. 670 _______________________________________________________________ 671 |Error_Name___|Error_ID|_Description_________________________|_ 672 |Success______|00______|_Success_____________________________|_ 673 |UnspecFail___|16______|_Failure,_reason_unspecified_________|_ 674 |AuthFailed___|17______|_Authentication_failed_or_nonexistent|_ 675 |PoorlyFormed_|18______|_Poorly_formed_message_______________|_ 676 |Unavail______|19______|_Addresses_unavailable_______________|_ 678 7.4.2. Server-specific Error Values 680 The following symbolic names are used by server implementations to 681 convey error conditions to clients. The following table contains the 682 actual numeric values for each name. 683 _______________________________________________________________ 684 |Error_Name____|Error_ID|_Description________________________|_ 685 |NoBinding_____|20______|_Client_record_(binding)_unavailable|_ 686 |ConfNoMatch___|21______|_Client_record_Confirm_not_match_IA_|_ 688 |RenwNoMatch___|22______|_Client_record_Renew_not_match_IA___|_ 689 |RebdNoMatch___|23______|_Client_record_Rebind_not_match_IA__|_ 690 |InvalidSource_|24______|_Invalid_Client_IP_address__________|_ 691 |NoServer______|25______|_Relay_cannot_find_Server_Address___|_ 692 |ICMPError_____|64______|_Server_unreachable_(ICMP_error)____|_ 694 7.5. Configuration Variables 696 This section presents a table of client and server configuration 697 variables and the default or initial values for these variables. The 698 client-specific variables MAY be configured on the server and MAY be 699 delivered to the client through the "DHCP Retransmission Parameter 700 Option" in a Reply message. 702 _________________________________________________________________________ 703 |Parameter__________|Default|_Description______________________________|_ 704 |MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg_____________|_ 705 |MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg_____________|_ 706 |ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)________________|_ 707 |ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)___________________|_ 708 |SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)_____________|_ 709 |REP_MSG_TIMEOUT____|250____|_Retrans_timer_(msecs)_for_Reply__________|_ 710 |QRY_MSG_ATTEMPTS___|10_____|_MAX_Request/Confirm/Renew/Rebind_attempts|_ 711 |REL_MSG_ATTEMPTS___|5______|_MAX_Release/Decline_attempts_____________|_ 712 |RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)____________________|_ 713 |REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts_____________________|_ 714 |REC_REP_MIN________|5______|_Minimum_pause_interval_(secs)____________|_ 715 |REC_REP_MAX________|7200___|_Maximum_pause_interval_(secs)____________|_ 716 |REC_THRESHOLD______|100____|_%_of_required_clients____________________|_ 717 |SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)___________|_ 719 8. Overview 721 This section provides a general overview of the interaction between 722 the functional entities of DHCP. The overview is organized as a 723 series of questions and answers. Details of DHCP such as message 724 formats and retransmissions can be found in later sections of this 725 document. 727 8.1. How does a node know to use DHCP? 729 An unconfigured node determines that it is to use DHCP for 730 configuration of an interface by detecting the presence (or absence) 731 of routers on the link. If router(s) are present, the node examines 732 router advertisements to determine if DHCP should be used to 733 configure the interface. If there are no routers present, then 734 the node MUST use DHCP to configure the interface. Detail on 735 this process can be found in neighbor discovery [10] and stateless 736 autoconfiguration [13]. 738 8.2. What if the client and server(s) are on different links? 740 Use of DHCP in such environments requires one or more DHCP relays 741 be set up on the client's link, because a client may only have a 742 link-local address. Relays receive the Solicit and Request messages 743 from the client and forward them to some set of servers within the 744 DHCP domain. The client message is forwarded verbatim as the payload 745 in a message from the relay to the server. A relay will include 746 one of its own addresses (of sufficient scope) from the interface 747 on the same link as the client, as well as the prefix length of 748 that address, in its message to the server. Servers receiving 749 the forwarded traffic use this information to aid in selecting 750 configuration parameters appropriate to the client's link. The 751 servers also use the relay's address as the destination to forward 752 client-destined messages for final delivery by the relay. 754 Relays forward client messages to servers using some combination 755 of the All DHCP Servers site-local multicast address, some other 756 (perhaps a combination) of site-local multicast addresses set up 757 within the DHCP domain to include the servers in that domain, or a 758 list of unicast addresses for servers. The network administrator 759 makes relay configuration decisions based upon the topological 760 requirements (scope) of the DHCP domain they are managing. Note 761 that if the DHCP domain spans more than the site-local scope, then 762 the relays MUST be configured with global addresses for the client's 763 link so as to be reachable by servers outside the relays' site-local 764 environment. 766 8.3. How does a client request configuration parameters from servers? 768 To request configuration parameters, the client forms a Request 769 message, and sends it to the server either directly (client has an 770 address of sufficient scope) or indirectly (through the on-link 771 relay). The client MAY include a Option Request Option 16.3 (ORO) 772 along with other options to request specific information from the 773 server. Note that the client MAY form multiple Request messages 774 and send each of them to different servers to request potentially 775 different information (perhaps based upon what was advertised) in 776 order to satisfy its needs. As a client's needs may change over time 777 (perhaps based upon an application's requirements), the client may 778 form additional Request messages to request additional information as 779 it is needed. 781 The server(s) respond with Reply messages containing the requested 782 configuration parameters, which can include status information 783 regarding the information requested by the client. The Reply MAY 784 also include additional information, such as a reconfiguration event 785 multicast group for the client to join to monitor reconfiguration 786 events, as described in section 8.7. 788 8.4. How do clients and servers identify and manage addresses? 790 Servers and clients manage addresses in groups called "identity 791 associations." Each identity associations is identified using a 792 unique identifier. An identity association may contain one or 793 more IPv6 addresses. DHCP servers assign addresses to identity 794 associations. DHCP clients use the addresses in an identity 795 association to configure interfaces. There is always at least one 796 identity association per interface that a client wishes to configure. 797 Each address in an IA has its own preferred and valid lifetime. Over 798 time, the server may change the characteristics of the addresses in 799 an IA; for example, by changing the preferred or valid lifetime for 800 an address in the IA. The server may also add or delete addresses 801 from an IA; for example, deleting old addresses and adding new 802 addresses to renumber a client. A client can request the current 803 list of addresses assigned to an IA from a server through an exchange 804 of protocol messages. 806 8.5. Can a client release its assigned addresses before the lease 807 expires? 809 A client forms a Release message, including options identifying 810 the IA to be released. The client sends the Release to the server 811 which assigned the addresses to the client initially. If that 812 server cannot be reached after a certain number of attempts (see 813 section 7.5), the client can abandon the Release attempt. In this 814 case, the address(es) in the IA will be reclaimed by the server(s) 815 when the lifetimes on the addresses expire. 817 8.6. What if the client determines one or more of its assigned addresses 818 are already being used by another client? 820 If the client determines through a mechanism like Duplicate Address 821 Detection [13] that the address it was assigned by the server is 822 already in use by another client, the client will form a Release 823 message, including the option carrying the in-use address. The 824 option's status field MUST be set to the value reflecting the "in 825 use" status of the address. 827 8.7. How are clients notified of server configuration changes? 829 There are two possibilities. Either the clients discover the new 830 information when they revisit the server(s) to request additional 831 configuration information/extend the lifetime on an address. or 832 through a server-initiated event known as a reconfigure event. 834 The reconfiguration feature of DHCP offers network administrators 835 the opportunity to update configuration information on DHCP clients 836 whenever necessary. To signal the need for client reconfiguration, 837 the server will unicast a Reconfigure-init message to each 838 client individually. The server may use multicast to signal the 839 reconfiguration to multiple clients simultaneously. (Note that 840 there is no mechanism defined in the protocol to guarantee that 841 every client actually performs a reconfiguration in response to a 842 multicast reconfigure-init message.) A Reconfigure-init is a trigger 843 which will cause the client(s) to initiate a standard Request/Reply 844 exchange with the server in order to acquire the new or updated 845 addresses. 847 9. Message Formats 849 Each DHCP message has an identical fixed format header; some messages 850 also allow a variable format area for options. Not all fields in 851 the header are used in every message. In this section, every field 852 is described for every message and fields that are not used in a 853 message are marked as "unused". All unused fields in a message MUST 854 be transmitted as zeroes and ignored by the receiver of the message. 856 The DHCP message header: 858 0 1 2 3 859 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 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | msg-type | preference | transaction-ID | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | | 864 | client-link-local-address | 865 | (16 octets) | 866 | | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | | 869 | server-address | 870 | (16 octets) | 871 | | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 . . 874 . options . 875 | (variable) | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 9.1. DHCP Solicit Message Format 880 msg-type TBD 882 preference (unused) MUST be 0 884 transaction-ID An unsigned integer generated by the 885 client used to identify this Solicit 886 message. 888 client-link-local-address The link-local address of the 889 interface for which the client is 890 using DHCP. 892 server-address (unused) MUST be 0 893 options See section 16. 895 9.2. DHCP Advertise Message Format 897 msg-type TBD 899 preference An unsigned integer indicating a 900 server's willingness to provide 901 service to the client. 903 transaction-ID An unsigned integer used to identify 904 this Advertise message. Copied from 905 the client's Solicit message. 907 client-link-local-address The IP link-local address of the 908 client interface from which the client 909 issued the Solicit message. 911 server-address The IP address of the server that 912 generated this message. If the DHCP 913 domain crosses site boundaries, then 914 this address MUST be globally-scoped. 916 options See section 16. 918 9.3. DHCP Request Message Format 920 msg-type TBD 922 preference (unused) MUST be 0 924 transaction-ID An unsigned integer generated by the 925 client used to identify this Request 926 message. 928 client-link-local-address The link-local address of the client 929 interface from which the client will 930 issue the Request message. 932 server-address The IP address of the server to which 933 the this message is directed, copied 934 from an Advertise message. 936 options See section 16. 938 9.4. DHCP Confirm Message Format 940 msg-type TBD 942 preference (unused) MUST be 0 943 transaction-ID An unsigned integer generated by the 944 client used to identify this Confirm 945 message. 947 client-link-local-address The link-local address of the client 948 interface from which the client will 949 issue the Request message. 951 server-address MUST be zero. 953 options See section 16. 955 9.5. DHCP Renew Message Format 957 msg-type TBD 959 preference (unused) MUST be 0 961 transaction-ID An unsigned integer generated by the 962 client used to identify this Request 963 message. 965 client-link-local-address The link-local address of the client 966 interface from which the client will 967 issue the Request message. 969 server-address The IP address of the server to which 970 this Renew message is directed, which 971 MUST be the address of the server from 972 which the IAs in this message were 973 originally assigned. 975 options See section 16. 977 9.6. DHCP Rebind Message Format 979 msg-type TBD 981 preference (unused) MUST be 0 983 transaction-ID An unsigned integer generated by the 984 client used to identify this Request 985 message. 987 client-link-local-address The link-local address of the client 988 interface from which the client will 989 issue the Request message. 991 server-address MUST be zero. 993 options See section 16. 995 9.7. DHCP Reply Message Format 997 msg-type TBD 999 preference An unsigned integer indicating a 1000 server's willingness to provide 1001 service to the client. 1003 transaction-ID An unsigned integer used to identify 1004 this Reply message. Copied from the 1005 client's Request message. 1007 client-link-local-address The link-local address of the 1008 interface for which the client is 1009 using DHCP. 1011 server-address The IP address of the server. 1012 If the DHCP domain crosses site 1013 boundaries, then this address MUST be 1014 globally-scoped. 1016 options See section 16. 1018 9.8. DHCP Release Message Format 1020 msg-type TBD 1022 preference (unused) MUST be 0 1024 transaction-ID An unsigned integer generated by the 1025 client used to identify this Release 1026 message. 1028 client-link-local-address The client's link-local address for 1029 the interface from which the client 1030 issued the Release message. 1032 server-address The IP address of the server that 1033 assigned the addresses. 1035 options See section 16. 1037 9.9. DHCP Decline Message Format 1039 msg-type TBD 1041 preference (unused) MUST be 0 1043 transaction-ID An unsigned integer generated by the 1044 client used to identify this Release 1045 message. 1047 client-link-local-address The client's link-local address for 1048 the interface from which the client 1049 issued the Release message. 1051 server-address The IP address of the server that 1052 assigned the addresses. 1054 options See section 16. 1056 9.10. DHCP Reconfigure-init Message Format 1058 preference (unused) MUST be 0 1060 transaction-ID An unsigned integer generated 1061 by the server to identify this 1062 Reconfigure-init message 1064 client-link-local-address (unused) MUST be 0 1066 server-address The IP address of the DHCP server 1067 issuing the Reconfigure-init message. 1068 MUST be of sufficient scope to be 1069 reachable by all clients. 1071 options See section 16. 1073 10. Relay messages 1075 Relay agents exchange messages with servers to forward messages 1076 between clients and servers that are not connected to the same link. 1078 10.1. Relay-forward message 1080 0 1 2 3 1081 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 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | msg-type | prefix length | | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1085 | | 1086 | relay-address | 1087 | | 1088 | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1090 | options (variable number and length) .... | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 msg-type TBD 1094 prefix-length The length of the prefix in the address in the 1095 "relay-address" field. 1097 relay-address An address assigned to the interface through which 1098 the message from the client was received. 1100 options MUST include a "Client message option"; see 1101 section 16.4. 1103 10.2. Relay-reply message 1105 0 1 2 3 1106 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 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | msg-type | prefix length | | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1110 | | 1111 | relay-address | 1112 | | 1113 | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1115 | options (variable number and length) .... | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 msg-type TBD 1120 prefix-length The length of the prefix in the address in the 1121 "relay-address" field. 1123 relay-address An address identifying the interface through which 1124 the message from the server should be forwarded; 1125 copied from the "client-forward" message. 1127 options MUST include a "Server message option"; see 1128 section 16.5. 1130 11. Identity association 1132 An "identity-association" (IA) is a construct through which a server 1133 and a client can identify, group and manage IPv6 addresses. Each IA 1134 consists of a DUID and a list of associated IPv6 addresses (the list 1135 may be empty). A client associates an IA with one of its interfaces 1136 and uses the IA to obtain IPv6 addresses for that interface from a 1137 server. 1139 See section 16.2 for the representation of an IA in a DHCP message. 1141 12. DHCP Server Solicitation 1143 This section describes how a client locates servers. The behavior of 1144 client, server, and relay implementations is discussed, along with 1145 the messages they use. 1147 12.1. Solicit Message Validation 1149 Clients MUST silently discard any received Solicit messages. 1151 Agents MUST silently discard any received Solicit messages if the 1152 "client-link-local-address" field does not contain a valid link-local 1153 address. 1155 12.2. Advertise Message Validation 1157 Servers MUST discard any received Advertise messages. 1159 Clients MUST discard any Advertise messages that meet any of the 1160 following criteria: 1162 o The "Transaction-ID" field value does not match the value the 1163 client used in its Solicit message. 1165 o The "client-link-local-address" field value does not match the 1166 link-local address of the interface upon which the client sent 1167 the Solicit message. 1169 12.3. Client Behavior 1171 Clients use the Solicit message to discover DHCP servers configured 1172 to serve addresses on the link to which the client is attached. 1174 12.3.1. Creation and sending of the Solicit message 1176 The client sets the "msg-type" field to TBD, and places the 1177 link-local address of the interface it wishes to configure in the 1178 "client-link-local-address" field. 1180 The client generates a transaction ID inserts this value in the 1181 "transaction-ID" field. 1183 The client MAY include an Option Request Option in the Solicit 1184 message. The client MUST NOT include any other options except those 1185 specifically allowed as defined by specific options. 1187 The client sends the Solicit message to the All DHCP Agents 1188 multicast address, destination port 547. The source port selection 1189 can be arbitrary, although it SHOULD be possible using a client 1190 configuration facility to set a specific source port value. 1192 12.3.2. Time out and retransmission of Solicit Messages 1194 The client's first Solicit message on the interface MUST be delayed 1195 by a random amount of time between the interval of MIN_SOL_DELAY and 1196 MAX_SOL_DELAY. This random delay desynchronizes clients which start 1197 at the same time (e.g., after a power outage). 1199 The client waits ADV_MSG_TIMEOUT, collecting Advertise messages. 1200 If no Advertise messages are received, the client retransmits 1201 the Solicit, and doubles the ADV_MSG_TIMEOUT value. This process 1202 continues until either one or more Advertise messages are received or 1203 ADV_MSG_TIMEOUT reaches the ADV_MSG_MAX value. Thereafter, Solicits 1204 are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been 1205 made, at which time the client stops trying to DHCP configure the 1206 interface. An event external to DHCP is required to restart the DHCP 1207 configuration process. 1209 Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY, 1210 ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 7.5. 1212 12.3.3. Receipt of Advertise messages 1214 Upon receipt of one or more validated Advertise messages, the client 1215 selects one or more Advertise messages based upon the following 1216 criteria. 1218 - Those Advertise messages with the highest server preference 1219 value (see section 17.4) are preferred over all other Advertise 1220 messages. 1222 - Within a group of Advertise messages with the same server 1223 preference value, a client MAY select those servers whose 1224 Advertise messages advertise information of interest to 1225 the client. For example, one server may be advertising the 1226 availability of IP addresses which have an address scope of 1227 interest to the client. 1229 Once a client has selected Advertise message(s), the client will 1230 typically store information about each server, such as server 1231 preference value, addresses advertised, when the advertisement was 1232 received, and so on. Depending on the requirements of the client's 1233 invoking user, the client MAY initiate a configuration exchange with 1234 the server(s) immediately, or MAY defer this exchange until later. 1236 If the client needs to select an alternate server in the case that a 1237 chosen server does not respond, the client choose the server with the 1238 next highest preference value. 1240 The client MAY choose a less-preferred server if that server has a 1241 better set of advertised parameters. 1243 12.4. Server Behavior 1245 For this discussion, the Server is assumed to have been configured in 1246 an implementation specific manner. This configuration is assumed to 1247 contain all network topology information for the DHCP domain, as well 1248 as any necessary authentication information. 1250 12.4.1. Receipt of Solicit messages 1252 If the server receives a Solicit message, the client must be on the 1253 same link as the server. If the server receives a Relay-forward 1254 message containing a Solicit message, the client must be on the 1255 link to which the prefix identified by the "relay-address" and 1256 "prefix-length" fields in the Relay-forward message is assigned. 1257 The server records the "relay-address" field from the Relay-forward 1258 message and extracts the solicit message from the "client-message" 1259 option. 1261 If administrative policy permits the server to respond to a client on 1262 that link, the server will generate and send an Advertise message to 1263 the client. 1265 12.4.2. Creation and sending of Advertise messages 1267 The server sets the "msg-type" field to TBD and copies the values 1268 of the following fields from the client's Solicit to the Advertise 1269 message: 1271 o transaction-ID 1273 o client-link-local-address 1275 The server places one of its IP addresses (determined through 1276 administrator setting) in the "server-address" field of the Advertise 1277 message. The server sets the "preference" field according to its 1278 configuration information. See section 18.3 for a description of 1279 server preference. 1281 The server MUST include options to the Advertise message containing 1282 any addresses that would be assigned to IAs contained in the Solicit 1283 message from the client. The server MAY include other options the 1284 server will return to the client in a subsequent Reply message. 1285 The information in these options will be used by the client in the 1286 selection of a server if the client receives more than one Advertise 1287 message. 1289 If the Solicit message was received in a Relay-forward message, the 1290 server constructs a Relay-reply message with the Advertise message in 1291 the payload of a "server-message" option. The server unicasts the 1292 Relay-reply message to the address in the "relay-address" field from 1293 the Relay-forward message. 1295 If the Solicit message was received directly by the server, the 1296 server unicasts the Advertise message directly to the client using 1297 the "client-link-local-address" field value as the destination 1298 address. The Advertise message MUST be unicast through the interface 1299 on which the Solicit message was received. 1301 13. DHCP Client-Initiated Configuration Exchange 1303 A client initiates a message exchange with the server to acquire 1304 or update configuration information of interest. The client may 1305 initiate the configuration exchange as part of the operating system 1306 configuration process or when requested to do so by the application 1307 layer. 1309 The client uses the following messages to initiate a configuration 1310 event with the server: 1312 Request Obtain initial configuration information when the client 1313 has no assigned addresses 1315 Confirm Confirm the validity of assigned addresses and other 1316 configuration changes when the client's assigned 1317 addresses may not be valid; for example, when the client 1318 reboots or loses its connection to a link 1320 Renew Extend the lease on an IA through the server that 1321 originally assigned the IA 1323 Rebind Extend the lease on an IA through any server willing to 1324 extend the lease 1326 A client uses the Release-Reply message exchange to indicate to the 1327 DHCP server that the client will no longer be using the addresses in 1328 the released IA. 1330 A client uses the Decline-Reply message exchange to indicate to the 1331 DHCP server that the client has detected that one or more addresses 1332 assigned by the server is already in use on the client's link. 1334 13.1. Client Message Validation 1336 Clients MUST silently discard any received client messages (Request, 1337 Confirm, Renew, Rebind, Release or Decline messages). 1339 Agents MUST discard any received client messages in which the 1340 "client-link-local-address" field does not contain a valid link-local 1341 address. 1343 Servers MUST discard any received client messages in which the 1344 "options" field contains an authentication option, and the server 1345 cannot successfully authenticate the client. 1347 Servers MUST discard any received Request or Renew message in which 1348 the "server-address" field value does not match any of the server's 1349 addresses. 1351 13.2. Server Message Validation 1353 Servers MUST silently discard any received server messages (Reply 1354 messages). 1356 Clients MUST discard any server messages that meet any of the 1357 following criteria: 1359 o The "transaction-ID" field value in the server message does 1360 not match the value the client used in its Request or Release 1361 message. 1363 o The "client-link-local-address" field value in the server message 1364 does not match the link-local address of the interface upon which 1365 the client sent in its Request or Release message. 1367 o The server message contains an authentication option, and the 1368 client's attempt to authenticate the message fails. 1370 Relays MUST discard any Relay-reply message in which the 1371 "client-link-local-address" in the encapsulated Reply message does 1372 not contain a valid link-local address. 1374 13.3. Client Behavior 1376 A client will use Request, Confirm, Renew and Rebind messages to 1377 acquire and confirm the validity of configuration information. 1378 A client may initiate such an exchange automatically in order 1379 to acquire the necessary network parameters to communicate with 1380 nodes off-link. The client uses the server address information 1381 from previous Advertise message(s) for use in constructing Request 1382 message(s). Note that a client may request configuration information 1383 from one or more servers at any time. 1385 A client uses the Release message in the management of IAs when 1386 the client has been instructed to release the IA prior to the IA 1387 expiration time since it is no longer needed. 1389 A client uses the Decline message when the client has determined 1390 through DAD or some other method that one or more of the addresses 1391 assigned by the server in the IA is already in use by a different 1392 client. 1394 13.3.1. Creation and sending of Request messages 1396 If a client has no valid IPv6 addresses of sufficient scope to 1397 communicate with a DHCP server, it may send a Request message to 1398 obtain new addresses. The client includes one or more IAs in the 1399 Request message, to which the server assigns new addresses. The 1400 server then returns to IA(s) to the client in a Reply message. 1402 The client sets the "msg-type" field to TBD, and places the 1403 link-local address of the interface it wishes to acquire 1404 configuration information for in the "client-link-local-address" 1405 field. 1407 The client generates a transaction ID inserts this value in the 1408 "transaction-ID" field. 1410 The client places the address of the destination server in the 1411 "server-address" field. 1413 The client adds any appropriate options, including one or more IA 1414 options (if the client is requesting that the server assign it some 1415 network addresses). The list of addresses in each included IA MUST 1416 be empty. 1418 The client sends the Request message to the All DHCP Agents 1419 multicast address, destination port 547. The source port selection 1420 can be arbitrary, although it SHOULD be possible using a client 1421 configuration facility to set a specific source port value. 1423 The server will respond to the Request message with a Reply 1424 message. If no Reply message is received within REP_MSG_TIMEOUT 1425 milliseconds, the client retransmits the Request with the same 1426 transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits 1427 again. The client continues this process until a Reply is received 1428 or REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at 1429 which time the client MUST abort the configuration attempt. The 1430 client SHOULD report the abort status to the application layer. 1432 Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS 1433 are documented in section 7.5. 1435 13.3.2. Creation and sending of Confirm messages 1437 Whenever a client may have moved to a new link, its IPv6 addresses 1438 may no longer be valid. Examples of times when a client may have 1439 moved to a new link include: 1441 o The client reboots 1443 o The client is physically disconnected from a wired connection 1445 o The client returns from sleep mode 1447 o The client using a wireless technology changes cells 1449 In any situation when a client may have moved to a new link, the 1450 client MUST initiate a Confirm/Reply message exchange. The client 1451 includes any IAs, along with the addresses associated with those IAs, 1452 in its Request message. The server returns the IAs with updated list 1453 of addresses and associated lifetimes. 1455 The client sets the "msg-type" field to TBD, and places the 1456 link-local address of the interface it wishes to acquire 1457 configuration information for in the "client-link-local-address" 1458 field. 1460 The client generates a transaction ID inserts this value in the 1461 "transaction-ID" field. 1463 The client sets the "server-address" field to 0. 1465 The client adds any appropriate options, including one or more IA 1466 options (if the client is requesting that the server confirm the 1467 validity of some network addresses). If the client does include 1468 any IA options, it MUST include the list of addresses the client 1469 currently has associated with that IA. 1471 The client sends the Confirm message to the All DHCP Agents 1472 multicast address, destination port 547. The source port selection 1473 can be arbitrary, although it SHOULD be possible using a client 1474 configuration facility to set a specific source port value. 1476 Servers will respond to the Confirm message with a Reply message. If 1477 no Confirm message is received within REP_MSG_TIMEOUT milliseconds, 1478 the client retransmits the Confirm with the same transaction-ID, 1479 and doubles the REP_MSG_TIMEOUT value, and waits again. The client 1480 continues this process until a Reply is received or QRY_MSG_ATTEMPTS 1481 unsuccessful attempts have been made, at which time the client MUST 1482 abort the configuration attempt. The client SHOULD report the abort 1483 status to the application layer. 1485 Default and initial values for REP_MSG_TIMEOUT and QRY_MSG_ATTEMPTS 1486 are documented in section 7.5. 1488 If the client receives no response to its Confirm message, it MAY 1489 restart the configuration process by locating a different DHCP server 1490 with an Advertise message and sending a Request to that server, as 1491 described in section 13.3.1. 1493 13.3.3. Creation and sending of Renew messages 1495 IPv6 addresses assigned to a client through an IA use the same 1496 preferred and valid lifetimes as IPv6 addresses obtained through 1497 stateless autoconfiguration. The server assigns preferred and valid 1498 lifetimes to the IPv6 addresses it assigns to an IA. To extend those 1499 lifetimes, the client sends a Request to the server containing an 1500 "IA option" for the IA and its associated addresses. The server 1501 determines new lifetimes for the addresses in the IA according to 1502 the server's administrative configuration. The server may also add 1503 new addresses to the IA. The server remove addresses from the IA by 1504 setting the preferred and valid lifetimes of those addresses to zero. 1506 The server controls the time at which the client contacts the server 1507 to extend the lifetimes on assigned addresses through the T1 and 1508 T2 parameters assigned to an IA. If the server does not assign an 1509 explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the 1510 shortest preferred lifetime of any address assigned to the IA and 1511 T2 defaults to 0.875 times the shortest preferred lifetime of any 1512 address assigned to the IA. 1514 At time T1 for an IA, the client initiates a Request/Reply message 1515 exchange to extend the lifetimes on any addresses in the IA. The 1516 client includes an IA option with all addresses currently assigned 1517 to the IA in its Request message. The client unicasts this Request 1518 message to the server that originally assigned the addresses to the 1519 IA. 1521 The client sets the "msg-type" field to TBD, and places the 1522 link-local address of the interface it wishes to acquire 1523 configuration information for in the "client-link-local-address" 1524 field. 1526 The client generates a transaction ID inserts this value in the 1527 "transaction-ID" field. 1529 The client places the address of the destination server in the 1530 "server-address" field. 1532 The client adds any appropriate options, including one or more IA 1533 options (if the client is requesting that the server extend the lease 1534 on some IAs; note that the client may check the status of other 1535 configuration parameters without asking for lease extensions). If 1536 the client does include any IA options, it MUST include the list of 1537 addresses the client currently has associated with that IA. 1539 The client sends the Renew message to the All DHCP Agents multicast 1540 address, destination port 547. The source port selection can 1541 be arbitrary, although it SHOULD be possible using a client 1542 configuration facility to set a specific source port value. 1544 The server will respond to the Renew message with a Reply message. 1545 If no Reply message is received within REP_MSG_TIMEOUT milliseconds, 1546 the client retransmits the Renew with the same transaction-ID, and 1547 doubles the REP_MSG_TIMEOUT value, and waits again. The client 1548 continues this process until a Reply is received or until time T2 is 1549 reached (see section 13.3.4). 1551 Default and initial values for REP_MSG_TIMEOUT are documented in 1552 section 7.5. 1554 13.3.4. Creation and sending of Rebind messages 1556 At time T2 for an IA (which will only be reached if the server to 1557 which the Request message was sent at time T1 has not responded), 1558 the client initiates a Request/Reply message exchange. The client 1559 includes an IA option with all addresses currently assigned to the IA 1560 in its Request message. The client multicasts this message to the 1561 All DHCP Agents multicast address. 1563 The client sets the "msg-type" field to TBD, and places the 1564 link-local address of the interface it wishes to acquire 1565 configuration information for in the "client-link-local-address" 1566 field. 1568 The client generates a transaction ID inserts this value in the 1569 "transaction-ID" field. 1571 The client sets the "server-address" field to 0. 1573 The client adds any appropriate options, including one or more IA 1574 options. If the client does include any IA options (if the client is 1575 requesting that the server extend the lease on some IAs; note that 1576 the client may check the status of other configuration parameters 1577 without asking for lease extensions), it MUST include the list of 1578 addresses the client currently has associated with that IA. 1580 The client sends the Rebind message to the All DHCP Agents multicast 1581 address, destination port 547. The source port selection can 1582 be arbitrary, although it SHOULD be possible using a client 1583 configuration facility to set a specific source port value. 1585 The server will respond to the Rebind message with a Reply message. 1586 If no Reply message is received within REP_MSG_TIMEOUT milliseconds, 1587 the client retransmits the Rebind with the same transaction-ID, and 1588 doubles the REP_MSG_TIMEOUT value, and waits again. The client 1589 continues this process until a Reply is received. 1591 Default and initial values for REP_MSG_TIMEOUT are documented in 1592 section 7.5. 1594 DISCUSSION: 1596 The client has several alternatives to choose from if it 1597 receives no response to its Rebind message. 1599 - When the lease on the IA expires, the client may choose 1600 to use a Solicit message to locate a new DHCP server and 1601 send a Request for the expired IA to the new server 1603 - Some addresses in the IA may have lifetimes that extend 1604 beyond the lease of the IA, so the client may choose 1605 to continue to use those addresses; once all of the 1606 addresses have expired, the client may choose to locate 1607 a new DHCP server 1609 - The client may have other addresses in other IAs, so the 1610 client may choose to discard the expired IA and use the 1611 addresses in the other IAs 1613 13.3.5. Receipt of Reply message in response to a Reply, Confirm, Renew 1614 or Rebind message 1616 Upon the receipt of a valid Reply, Confirm, Renew or Rebind message, 1617 the client extracts the configuration information contained in the 1618 Reply. If the "status" field contains a non-zero value, the client 1619 reports the error status to the application layer. 1621 The client records the T1 and T2 times for each IA in the Reply 1622 message. The client records any addresses included with IAs in 1623 the Reply message. The client updates the preferred and valid 1624 lifetimes for the addresses in the IA from the lifetime information 1625 in the IA option. The client leaves any addresses that the client 1626 has associated with the IA that are not included in the IA option 1627 unchanged. 1629 Management of the specific configuration information is detailed in 1630 the definition of each option, in section 16. 1632 When the client receives an Unavail error status in an IA from the 1633 server for a Request message the client will have to find a new 1634 server to create an IA Association. 1636 When the client receives a NoBinding error status in an IA from the 1637 server for a Confirm message the client can assume it needs to send a 1638 Request to reestablish an IA Association with the server. 1640 When the client receives a Conf_NoMatch error status in an IA from 1641 the server for a Confirm message the client can send a Renew message 1642 to the server to extend the lease for the addresses. 1644 When the client receives a NoBinding error status in an IA from the 1645 server for a Renew message the client can assume it needs to send a 1646 Request to reestablish an IA Association with the server. 1648 When the client receives a Renw_NoMatch error status in an IA from 1649 the server for a Renew message the client can assume it needs to send 1650 a Request to reestablish an IA Association with the server. 1652 When the client receives an Unavail error status in an IA from the 1653 server for a Renew message the client can assume it needs to send a 1654 Request to reestablish an IA Association set of addresses with the 1655 server. 1657 When the client receives a NoBinding error status in an IA from the 1658 server for a Rebind message the client can assume it needs to send 1659 a Request to reestablish an IA Association with the server or try 1660 another server. 1662 When the client receives a Rebd_NoMatch error status in an IA from 1663 the server for a Rebind message the client can assume it needs to 1664 send a Request to reestablish an IA Association with the server or 1665 try another server. 1667 When the client receives an Unavail error status in an IA from the 1668 server for a Rebind message the client can assume it needs to send a 1669 Request to reestablish an IA Association set of addresses with the 1670 server or try another server. 1672 13.3.6. Creation and sending of Release messages 1674 The client sets the "msg-type" field to TBD, and places the 1675 link-local address of the interface associated with the configuration 1676 information it wishes to release in the "client-link-local-address" 1677 field. 1679 The client generates a transaction ID and places this value in the 1680 "transaction-ID" field. 1682 The client places the IP address of the server that allocated the 1683 address(es) in the "server-address" field. 1685 The client includes options containing the IAs it is releasing in the 1686 "options" field. The appropriate "status" field in the options MUST 1687 be set to indicate the reason for the release. 1689 If the client is configured to use authentication, the client 1690 generates the appropriate authentication option, and adds this option 1691 to the "options" field. Note that the authentication option MUST be 1692 the last option in the "options" field. See section 16.7 for more 1693 details about the authentication option. 1695 13.3.7. Time out and retransmission of Release Messages 1697 If no Reply message is received within REP_MSG_TIMEOUT milliseconds, 1698 the client retransmits the Release, doubles the REP_MSG_TIMEOUT 1699 value, and waits again. The client continues this process until a 1700 Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have been 1701 made, at which time the client SHOULD abort the release attempt. 1703 The client SHOULD return the abort status to the application, if an 1704 application initiated the release. 1706 Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS 1707 are documented in section 7.5. 1709 Note that if the client fails to release the IA, the addresses 1710 assigned to the IA will be reclaimed by the server when the lease 1711 associated with it expires. 1713 13.3.8. Creation and sending of Decline messages 1715 The client sets the "msg-type" field to TBD, and places the 1716 link-local address of the interface associated with the configuration 1717 information it wishes to decline in the "client-link-local-address" 1718 field. 1720 The client generates a transaction ID and places this value in the 1721 "transaction-ID" field. 1723 The client places the IP address of the server that allocated the 1724 address(es) in the "server-address" field. 1726 The client includes options containing the IAs it is declining in the 1727 "options" field. The appropriate "status" field in the options MUST 1728 be set to indicate the reason for declining the address. 1730 If the client is configured to use authentication, the client 1731 generates the appropriate authentication option, and adds this option 1732 to the "options" field. Note that the authentication option MUST be 1733 the last option in the "options" field. See section 16.7 for more 1734 details about the authentication option. 1736 13.3.9. Time out and retransmission of Decline Messages 1738 If no Reply message is received within REP_MSG_TIMEOUT milliseconds, 1739 the client retransmits the Decline, doubles the REP_MSG_TIMEOUT 1740 value, and waits again. The client continues this process until a 1741 Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have 1742 been made, at which time the client SHOULD abort the attempt to 1743 decline the address. The client SHOULD return the abort status to 1744 the application, if an application initiated the release. 1746 Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS 1747 are documented in section 7.5. 1749 13.3.10. Receipt of Reply message in response to a Release message 1751 Upon receipt of a valid Reply message, the client can consider the 1752 Release event successful, and SHOULD return the successful status to 1753 the application layer, if an application initiated the release. 1755 13.4. Server Behavior 1757 For this discussion, the Server is assumed to have been configured in 1758 an implementation specific manner with configuration of interest to 1759 clients. 1761 13.4.1. Receipt of Request messages 1763 Upon the receipt of a valid Request message from a client the server 1764 can respond to, (implementation-specific administrative policy 1765 satisfied) the server scans the options field. 1767 The server then constructs a Reply message and sends it to the 1768 client. 1770 The server SHOULD process each option for the client in an 1771 implementation-specific manner. The server MUST construct a Reply 1772 message containing the following values: 1774 msg-type TBD 1776 preference Enter the servers preference to 1777 provide services to the client. 1779 transaction-ID Enter the transaction-ID from the 1780 Request message. 1782 client-link-local address Enter the client-link-local address 1783 from the Request message. 1785 server address Enter the IP address of the server. 1787 When the server receives a Request and IA option is included the 1788 client is requesting the configuration of a new IA by the server. 1789 The server MUST take the clients IA and associate a binding for 1790 that client in an implementation-specific manner within the servers 1791 configuration parameter database for DHCP clients. 1793 If the server cannot provide addresses to the client it SHOULD send 1794 back an empty IA to the client with the status field set to Unavail. 1796 If the server can provide addresses to the client it MUST send back 1797 the IA to the client with all fields entered and a status of Success, 1798 and add the IA as a new client binding. 1800 13.4.2. Receipt of Confirm messages 1802 Upon the receipt of a valid Confirm message from a client the server 1803 can respond to, (implementation-specific administrative policy 1804 satisfied) the server scans the options field. 1806 The server then constructs a Reply message and sends it to the 1807 client. 1809 The server SHOULD process each option for the client in an 1810 implementation-specific manner. The server MUST construct a Reply 1811 message containing the following values: 1813 msg-type TBD 1815 preference Enter the servers preference to 1816 provide services to the client. 1818 transaction-ID Enter the transaction-ID from the 1819 Confirm message. 1821 client-link-local address Enter the client-link-local address 1822 from the Confirm message. 1824 server address Enter the server's address. 1826 When the server receives a Confirm and an IA option is included the 1827 client is requesting confirmation that the addresses in the IA are 1828 valid. The server SHOULD locate the clients binding and verify the 1829 information in the IA from the client matches the information stored 1830 for that client. 1832 If the server cannot find a client entry for this IA the server 1833 SHOULD return an empty IA with status set to NoBinding. 1835 If the server finds that the information for the client does not 1836 match what is in the servers records for that client the server 1837 should send back an empty IA with status set to Conf_NoMatch. 1839 If the server finds a match to the Confirm then the server should 1840 send back the IA to the client with status set to success. 1842 13.4.3. Receipt of Renew messages 1844 Upon the receipt of a valid Renew message from a client the server 1845 can respond to, (implementation-specific administrative policy 1846 satisfied) the server scans the options field. 1848 The server then constructs a Reply message and sends it to the 1849 client. 1851 The server SHOULD process each option for the client in an 1852 implementation-specific manner. The server MUST construct a Reply 1853 message containing the following values: 1855 msg-type TBD 1857 preference Enter the servers preference to 1858 provide services to the client. 1860 transaction-ID Enter the transaction-ID from the 1861 Confirm message. 1863 client-link-local address Enter the client-link-local address 1864 from the Confirm message. 1866 server address Enter the server's address. 1868 When the server receives a Renew and IA option from a client it 1869 SHOULD locate the clients binding and verify the information in the 1870 IA from the client matches the information stored for that client. 1872 If the server cannot find a client entry for this IA the server 1873 SHOULD return an empty IA with status set to NoBinding. 1875 If the server finds that the addresses in the IA for the client do 1876 not match the clients binding the server should return an empty IA 1877 with status set to Renw_NoMatch. 1879 If the server cannot Renew addresses for the client it SHOULD send 1880 back an empty IA to the client with the status field set to Unavail. 1882 If the server finds the addresses in the IA for the client then the 1883 server SHOULD send back the IA to the client with new lease times 1884 and T1/T2 times if the default is not being used, and set status to 1885 Success. 1887 13.4.4. Receipt of Rebind messages 1889 Upon the receipt of a valid Rebind message from a client the server 1890 can respond to, (implementation-specific administrative policy 1891 satisfied) the server scans the options field. 1893 The server then constructs a Reply message and sends it to the 1894 client. 1896 The server SHOULD process each option for the client in an 1897 implementation-specific manner. The server MUST construct a Reply 1898 message containing the following values: 1900 msg-type TBD 1901 preference Enter the servers preference to 1902 provide services to the client. 1904 transaction-ID Enter the transaction-ID from the 1905 Confirm message. 1907 client-link-local address Enter the client-link-local address 1908 from the Confirm message. 1910 server address Enter the server's address. 1912 When the server receives a Renew and IA option from a client it 1913 SHOULD locate the clients binding and verify the information in the 1914 IA from the client matches the information stored for that client. 1916 If the server cannot find a client entry for this IA the server 1917 SHOULD return an empty IA with status set to NoBinding. 1919 If the server finds that the addresses in the IA for the client do 1920 not match the clients binding the server should return an empty IA 1921 with status set to Rebd_NoMatch. 1923 If the server cannot Rebind addresses for the client it SHOULD send 1924 back an empty IA to the client with the status field set to Unavail. 1926 If the server finds the addresses in the IA for the client then the 1927 server SHOULD send back the IA to the client with new lease times 1928 and T1/T2 times if the default is not being used, and set status to 1929 Success. 1931 13.4.5. Receipt of Release messages 1933 Upon the receipt of a valid Release message, the server examines the 1934 IAs and the addresses in the IAs for validity. If the IAs in the 1935 message are in a binding for the client and the addresses in the IAs 1936 have been assigned by the server to those IA, the server deletes 1937 the addresses from the IAs and makes the addresses available for 1938 assignment to other clients. 1940 The server then generates a Reply message. If all of the IAs were 1941 valid and the addresses successfully released,, the server sets the 1942 "status" field to "Success". If any of the IAs were invalid or if 1943 any of the addresses were not successfully released, the server 1944 releases none of the addresses in the message and sets the "status" 1945 field to "NoBinding"(section 7.4). 1947 DISCUSSION: 1949 What is the behavior of the server relative to a "partially 1950 released" IA; i.e., an IA for which some but not all 1951 addresses are released? 1952 Can a client send an empty IA to release all addresses in 1953 the IA? 1955 If the IA becomes empty - all addresses are released - can 1956 the server discard any record of the IA? 1958 13.4.6. Sending of Reply messages 1960 If the Request or Release message from the client was originally 1961 received by the server, the server unicasts the Reply message to the 1962 link-local address in the "client-link-local-address" field. 1964 If the message was originally received in a Forward-request or 1965 Forward-release message from a relay, the server places the Reply 1966 message in the options field of a Response-reply message and unicasts 1967 the message to the relay's address from the original message. 1969 14. DHCP Server-Initiated Configuration Exchange 1971 A server initiates a configuration exchange to force DHCP clients 1972 to obtain new addresses and other configuration information. For 1973 example, an administrator may use a server-initiated configuration 1974 exchange when links in the DHCP domain are to be renumbered. Other 1975 examples include changes in the location of directory servers, 1976 addition of new services such as printing, and availability of new 1977 software (system or application). 1979 14.1. Reconfigure-init Message Validation 1981 Agents MUST silently discard any received Reconfigure-init messages. 1983 Clients MUST discard any Reconfigure-init messages that do 1984 not contain an authentication option or that fail the client's 1985 authentication check. 1987 Clients MUST discard any Reconfigure-init messages that contain a 1988 transaction-ID that matches the transaction-ID in a Reconfigure-init 1989 message previously received from the same DHCP server. 1991 14.2. Server Behavior 1993 A server sends a Reconfigure-init message to trigger a client to 1994 initiate immediately a Request/Reply message exchange with the 1995 server. A server may unicast a Reconfigure-init message directly 1996 to a single client or use multicast to deliver a Reconfigure-init 1997 message to multiple clients. 1999 14.2.1. Creation and sending of Reconfigure-init messages 2001 The server sets the "msg-type" field to TBD. The server generates 2002 a transaction-ID and inserts it in the "transaction-ID" field. 2003 The server places its address (of appropriate scope) in the 2004 "server-address" field. 2006 The server MAY include an ORO option to inform the client of what 2007 information has been changed or new information that has been added. 2009 The server MUST include an authentication option with the appropriate 2010 settings and add that option as the last option in the "options" 2011 field of the Reconfigure-init message. 2013 The server MAY include a Reconfigure-delay option in a 2014 Reconfigure-init message to be unicast to a client, and MUST 2015 include a Reconfigure-delay option in a Reconfigure-init message to 2016 be multicast to a group of clients. 2018 The server MUST NOT include any other options in the Reconfigure-init 2019 except as specifically allowed in the definition of individual 2020 options. 2022 The server may either unicast the Reconfigure-init message to one 2023 client or multicast the message to one or more Reconfigure Multicast 2024 Addresses previously sent as options to the clients. The server 2025 may unicast Reconfigure-init messages to more than one client 2026 concurrently; for example, to reliably reconfigure all clients, the 2027 server will unicast a Reconfigure-init message to each client. 2029 If the server unicasts to one or more clients, it waits for a Request 2030 message from those clients confirming that it has received the 2031 Reconfigure-init and are thus initiating a Request/Reply transaction 2032 with the server. The server can determine that a Request message is 2033 in response to a Reconfigure-init because the transaction-ID in the 2034 Request will be the same value as was used in the Reconfigure-init 2035 message. 2037 If the server multicasts the Reconfigure-init message, it must use 2038 some TBD authentication mechanism that can authenticate the server to 2039 multiple clients. There is no reliability mechanism for multicast 2040 Reconfigure-init messages. A server might use multicast in the 2041 case where it does not have a list of its clients; for example, a 2042 server that distributes configuration information to clients using 2043 stateless autoconfiguration might not keep a list of clients it has 2044 communicated with. 2046 DISCUSSION: 2048 Authentication of multicast reconfigure-init is still an 2049 open issue. 2051 See section 18.2 for recommendations on the use of multicast 2052 and unicast Reconfigure-init messages for reliable client 2053 reconfiguration. 2055 14.2.2. Time out and retransmission of unicast Reconfigure-init messages 2057 If the server does not receive a Request message from the client 2058 in RECREP_MSG_TIMEOUT milliseconds, the server retransmits 2059 the Reconfigure-init message, doubles the RECREP_MSG_TIMEOUT 2060 value and waits again. The server continues this process until 2061 REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point 2062 the server SHOULD abort the reconfigure process. 2064 Default and initial values for RECREP_MSG_TIMEOUT and 2065 REC_MSG_ATTEMPTS are documented in section 7.5. 2067 14.2.3. Time out and retransmission of multicast Reconfigure-init 2068 messages 2070 After the server transmits the initial Reconfigure-init message, 2071 the server waits RECREP_MSG_TIMEOUT milliseconds. The server 2072 then retransmits the Reconfigure-init message, doubles the 2073 RECREP_MSG_TIMEOUT value and waits again. The server repeats this 2074 process until a total of REC_MSG_ATTEMPTS Reconfigure-init messages 2075 have been transmitted. 2077 Default and initial values for RECREP_MSG_TIMEOUT and 2078 REC_MSG_ATTEMPTS are documented in section 7.5. 2080 14.2.4. Receipt of Request messages 2082 The server generates and sends Reply message(s) to the client as 2083 described in section 13.4.6, including in the "option" field new 2084 values for configuration parameters. 2086 14.3. Client Behavior 2088 A client MUST always monitor UDP port 546 for Reconfigure-init 2089 messages on interfaces upon which it has acquired DHCP parameters. 2090 Since the results of a reconfiguration event may affect application 2091 layer programs, the client SHOULD log these events, and MAY notify 2092 these programs of the change through an implementation-specific 2093 interface. 2095 14.3.1. Receipt of Reconfigure-init messages 2097 Upon receipt of a valid Reconfigure-init message, the client 2098 initiates a Request/Reply transaction with the server. 2100 14.3.2. Creation and sending of Request messages 2102 When responding to a Reconfigure-init, the client creates and 2103 sends the Request message in exactly the same manner as outlined in 2104 section 13.3.1 with the following differences: 2106 transaction-ID The client copies the 2107 transaction-ID from the 2108 Reconfigure-init message into the 2109 Request message. 2111 IAs The client includes IA options 2112 containing the addresses the client 2113 currently has assigned to those IAs 2114 for the interface through which 2115 the Reconfigure-init message was 2116 received. 2118 Pause before sending Request The client pauses before sending 2119 the Request for a random value 2120 within the range REC_REP_MIN and 2121 REC_REP_MAX seconds. This delay 2122 helps reduce the load on the 2123 server generated by processing 2124 large numbers of triggered 2125 Request messages from a multicast 2126 Reconfigure-init message. 2128 14.3.3. Time out and retransmission of Request messages 2130 The client uses the same variables and retransmission algorithm as it 2131 does with Request messages generated as part of a client-initiated 2132 configuration exchange. See section 13.3.1 for details. 2134 14.3.4. Receipt of Reply messages 2136 Upon the receipt of a valid Reply message, the client extracts the 2137 contents of the "option" field, and sets (or resets) configuration 2138 parameters appropriately. The client records and updates the 2139 lifetimes for any addresses specified in IAs in the Reply message. 2140 If the configuration parameters changed were requested by the 2141 application layer, the client notifies the application layer of the 2142 changes using an implementation-specific interface. 2144 15. Relay Behavior 2146 For this discussion, the Relay may be configured to use a list of 2147 server destination addresses, which may include unicast addresses, 2148 the All DHCP Servers multicast address, or other multicast addresses 2149 selected by the network administrator. If the Relay has not been 2150 explicitly configured, it will use the All DHCP Servers multicast 2151 address as the default. 2153 15.1. Relaying of Solicit messages 2155 When a Relay receives a valid Solicit message, it constructs 2156 a Relay-forward message. The relay places an address from 2157 the interface on which the Solicit message was received in the 2158 "relay-address" field and the prefix length for that address in the 2159 "prefix-length" field. This address will be used by the server to 2160 identify the link to which the client is connected and will be used 2161 by the relay to forward the Advertise message from the server back to 2162 the client. 2164 The relay constructs a "relay-message" option 16.4 that contains 2165 the entire Solicit message from the client in the data field of the 2166 option. The relay places the "relay-message" option along with any 2167 "relay-specific" options in the options field of the Relay-forward 2168 message. The Relay then sends the Relay-forward message to the list 2169 of server destination addresses that it has been configured with. 2171 15.2. Relaying of Advertise messages 2173 When the relay receives a Relay-reply message, it extracts the 2174 Advertise message from the "server-message" option and forwards the 2175 server message to the address in the client-link-local-address field 2176 in the Advertise message. The relay forwards the server message 2177 through the interface identified in the "relay-address" field in the 2178 Relay-reply message. 2180 16. DHCP options 2182 Options are used to carry additional information and parameters 2183 in DHCP messages. Every option shares a common base format, as 2184 described in section 16.1. 2186 this document describes the DHCP options defined as part of the base 2187 DHCP specification. Other options may be defined in the future in a 2188 separate document. 2190 16.1. Format of DHCP options 2192 0 1 2 3 2193 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 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 | option-code | option-len | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 | option-data | 2198 | (option-len octets) | 2199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 option-code An unsigned integer identifying the specific option 2202 type carried in this option. 2204 option-len An unsigned integer giving the length of the data in 2205 this option in bytes. 2207 option-data The data for the option; the format of this data 2208 depends on the definition of the option. 2210 16.2. Identity association option 2212 The identity association option is used to carry an identity 2213 association, the parameters associated with the IA and the addresses 2214 assigned to the IA. 2216 The format of the IA option is: 2218 0 1 2 3 2219 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 2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2221 | TBD | option-len | 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 | IA DUID | 2224 | (8 octets) | 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 | T1 | 2227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2228 | T2 | 2229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2230 | IA status | num-addrs | addr status | prefix length | 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 | | 2233 | IPv6 address | 2234 | (16 octets) | 2235 | | 2236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 | preferred lifetime | 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 | valid lifetime | 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | addr status | prefix length | | 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2243 | IPv6 address | 2244 | (16 octets) | 2245 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 | | preferred lifetime | 2247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2248 | pref. lifetime (cont.) | valid lifetime | 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2250 | valid lifetime (cont.) | IPv6 address | 2251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2252 | ... | 2253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2255 option-code TBD 2257 option-len Variable; equal to 17 + num-addrs*25 2259 IA DUID The unique identifier for this IA; chosen by the client 2261 T1 The time at which the client contacts the server from 2262 which the addresses in the IA were obtained to extend 2263 the lifetimes of the addresses assigned to the IA. 2265 T2 The time at which the client contacts any available 2266 server to extend the lifetimes of the addresses assigned 2267 to the IA. 2269 IA status Status of the IA in this option. 2271 num-addrs An unsigned integer giving the number of addresses 2272 carried in this IA option (MAY be zero). 2274 addr status Status of this address. 2276 prefix length Prefix length for this address. 2278 IPv6 address An IPv6 address assigned to this IA. 2280 preferred lifetime The preferred lifetime for the associated IPv6 2281 address. 2283 valid lifetime The valid lifetime for the associated IPv6 address. 2285 The "IPv6 address", "preferred lifetime" and "valid lifetime" fields 2286 are repeated for each address in the IA option (as determined by the 2287 "num-addrs" field). 2289 DISCUSSION: 2291 The details of the format and the selection of an IA's DUID 2292 are TBD. 2294 Note that an IA has no explicit "lifetime" or "lease length" of 2295 its own. When the lifetimes of all of the addresses in an IA have 2296 expired, the IA can be considered as having expired. T1 and T2 2297 are included to give servers explicit control over when a client 2298 recontacts the server about a specific IA. 2300 16.3. Option request option 2302 0 1 2 3 2303 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 2304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2305 | option-code | option-len | 2306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2307 | requested-option-code-1 | requested-option-code-2 | 2308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2309 | ... | 2310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2312 option-code TBD. 2314 option-len Variable; equal to twice the number of option codes 2315 carried in this option. 2317 option-data A list of the option codes for the options requested 2318 in this option. 2320 16.4. Client message option 2322 0 1 2 3 2323 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 2324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2325 | option-code | option-len | 2326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2327 | DHCP client message | 2328 | | 2329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2331 option-code TBD 2333 option-len Variable; equal to the length of the forwarded DHCP 2334 client message. 2336 option-data The message received from the client; forwarded 2337 verbatim to the server. 2339 16.5. Server message option 2341 0 1 2 3 2342 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 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 | option-code | option-len | 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 | DHCP server message | 2347 | | 2348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 option-code TBD 2352 option-len Variable; equal to the length of the forwarded DHCP 2353 server message. 2355 option-data The message received from the server; forwarded 2356 verbatim to the client. 2358 16.6. Retransmission parameter option 2360 0 1 2 3 2361 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 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 | option-code | option-len | 2364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2365 | option-data | 2366 | (option-len octets) | 2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2369 option-code An unsigned integer identifying the specific option 2370 type carried in this option. 2372 option-len An unsigned integer giving the length of the data in 2373 this option in bytes. 2375 option-data The data for the option; the format of this data 2376 depends on the definition of the option. 2378 16.7. Authentication option 2380 The authentication option is TBD. 2382 16.8. Reconfigure-delay option 2384 The Reconfigure-delay option specifies the amount of time a client 2385 should delay before sending a Request message in response to a 2386 Reconfigure-init message. 2388 0 1 2 3 2389 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 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2391 | option-code | option-len | 2392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2393 | minimum delay time (msec) | maximum delay time (msec) | 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2396 The client chooses a random number between the minimum delay time and 2397 the maximum delay time and delays that number of milliseconds before 2398 sending its Request message. 2400 16.9. DSTM Global IPv4 Address Option 2402 The DSTM Global IPv4 Address Option informs a client or server that 2403 the Identity Association Option (IA) following this option will 2404 contain an IPv4-Mapped IPv6 Address [?] in the case of a Client 2405 receiving the option, or is a Request for an IPv4-Mapped IPv6 Address 2406 from a client in the case of a DHCPv6 Server receiving the option. 2407 The option can also provide an IPv6 address to be used as the Tunnel 2408 Endpoint (TEP) to encapsulate an IPv4 packet within IPv6. 2410 This option can be used with the Request, Reply, and Reconfigure-Init 2411 Messages for cases where a server wants to assign to clients 2412 IPv4-Mapped IPv6 Addresses, thru the Option Request Option (ORO). 2414 0 1 2 3 2415 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 2416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2417 | option-code | option-length | 2418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2419 | Tunnel End Point (TEP) | 2420 | (If Present) | 2421 | (16 octets) | 2422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 option-code: TBD 2425 option-length: Variable: 0 or 16 2426 Tunnel End Point: IPv6 Address if Present 2428 A DSTM IPv4 Global Address Option MUST only apply to the IA following 2429 this option. 2431 17. DHCP Client Implementor Notes 2433 This section provides helpful information for the client implementor 2434 regarding their implementations. The text described here is not part 2435 of the protocol, but rather a discussion of implementation features 2436 we feel the implementor should consider during implementation. 2438 17.1. Primary Interface 2440 Since configuration parameters acquired through DHCP can be 2441 interface-specific or more general, the client implementor SHOULD 2442 provide a mechanism by which the client implementation can be 2443 configured to specify which interface is the primary interface. The 2444 client SHOULD always query the DHCP data associated with the primary 2445 interface for non-interface specific configuration parameters. An 2446 implementation MAY implement a list of interfaces which would be 2447 scanned in order to satisfy the general request. In either case, the 2448 first interface scanned is considered the primary interface. 2450 By allowing the specification of a primary interface, the client 2451 implementor identifies which interface is authoritative for 2452 non-interface specific parameters, which prevents configuration 2453 information ambiguity within the client implementation. 2455 17.2. Advertise Message and Configuration Parameter Caching 2457 If the hardware the client is running on permits it, the implementor 2458 SHOULD provide a cache for Advertise messages and a cache of 2459 configuration parameters received through DHCP. Providing these 2460 caches prevents unnecessary DHCP traffic and the subsequent load 2461 this generates on the servers. The implementor SHOULD provide a 2462 configuration knob for setting the amount of time the cache(s) are 2463 valid. 2465 17.3. Time out and retransmission variables 2467 Note that the client time out and retransmission variables outlined 2468 in section 7.5 can be configured on the server and sent to the client 2469 through the use of the "DHCP Retransmission Parameter Option", which 2470 is documented in section 16.6. A client implementation SHOULD be 2471 able to reset these variables using the values from this option. 2473 17.4. Server Preference 2475 A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP 2476 Solicit message to collect Advertise messages and compare their 2477 preferences (see section 18.3), unless it receives an Advertise 2478 message with a preference of 255. If the client receives an 2479 Advertise message with a preference of 255, then the client MAY act 2480 immediately on that Advertise without waiting for any more additional 2481 Advertise messages. 2483 18. DHCP Server Implementor Notes 2485 This section provides helpful information for the server implementor. 2487 18.1. Client Bindings 2489 A server implementation MUST use the IA's DUID and the prefix 2490 specification from which the client sent its Request message(s) as an 2491 index for finding configuration parameters assigned to the client. 2492 While it isn't critical to keep track of the other parameters 2493 assigned to a client, the server MUST keep track of the addresses it 2494 has assigned to an IA. 2496 The server should periodically scan its bindings for addresses whose 2497 leases have expired. When the server finds expired addresses, it 2498 MUST delete the assignment of those addresses, thereby making these 2499 addresses available to other clients. 2501 The client bindings MUST be stored in non-volatile storage. 2503 The server implementation should provide policy knobs to control 2504 whether or not the lifetimes on assigned addresses are renewable, and 2505 by how long. 2507 18.2. Reconfigure-init Considerations 2509 A server implementation MUST provide an interface to the 2510 administrator for initiating reconfigure-init events. 2512 A server implementation may provide a mechanism for allowing the 2513 specification of how many clients comprise a reconfigure multicast 2514 group. This enables the administrator to control the processing load 2515 impact of the multicast of a Reconfigure-init message. 2517 18.2.1. Reliable transmission of multicast Reconfigure-init messages 2519 Because clients will ignore Reconfigure-init messages with the 2520 same transaction-ID, a server can retransmit a Reconfigure-init 2521 message (using the same transaction-ID) without causing any 2522 client to reply more than once. A server SHOULD retransmit a 2523 multicast Reconfigure-init message several times to maximize the 2524 probability that all clients in the multicast group have received the 2525 Reconfigure-init message. 2527 If a server does not receive a Reply message from some clients in a 2528 multicast group, the server MAY choose to unicast a Reconfigure-init 2529 message to those clients. Because the clients may have received the 2530 multicast Reconfigure-init messages while the server did not receive 2531 the clients' Reply messages, the server SHOULD use a different 2532 transaction-ID in the unicast Reconfigure-init messages to trigger 2533 the client to reconfigure. 2535 18.3. Server Preference 2537 The server implementation SHOULD allow the setting of a server 2538 preference value by the administrator. The server preference 2539 variable is an unsigned single octet value (0--255), with the lowest 2540 preference being 0 and the highest 255. Clients will choose higher 2541 preference servers over those with lower preference values. If you 2542 don't choose to implement this feature in your server, you MUST set 2543 the server preference field to 0 in the Advertise messages generated 2544 by your server. 2546 18.4. Request Message Transaction-ID Cache 2548 In order to improve performance, a server implementation MAY include 2549 an in memory transaction-ID cache. This cache is indexed by client 2550 binding and transaction-ID, and enables the server to quickly 2551 determine whether a Request is a retransmission or a new Request 2552 without the cost of a database lookup. If an implementor chooses to 2553 implement this cache, then they SHOULD provide a configuration knob 2554 to tune the lifetime of the cache entries. 2556 19. DHCP Relay Implementor Notes 2558 A relay implementation SHOULD allow the specification of a list of 2559 destination addresses for forwarded messages. This list MAY contain 2560 any mixture of unicast addresses and multicast addresses. 2562 If a relay receives an ICMP message in response to a DHCP message it 2563 has forwarded, it SHOULD log this event. 2565 20. Open Issues for Working Group Discussion 2567 This section contains some items for discussion by the working group. 2569 20.1. Authentication 2571 Authentication is not discussed in this document. Authentication 2572 will be modeled on DHCPv4 authentication. Authentication of 2573 multicast Reconfigure-init messages is a special problem. 2575 20.2. Identification of IAs by servers 2577 Do servers identify an IA just by its DUID or by ? If 2578 just by DUID, are DUIDs guaranteed unique (within the DHCP universe)? 2579 If so, how is that guarantee implemented? 2581 20.3. DHCP-DNS interaction 2583 Interaction among DHCP servers, clients and DNS servers is not 2584 discussed in this document. 2586 20.4. Anonymous addresses 2588 How does DHCPv6 interact with anonymous addresses? If the server 2589 assigns anonymous addresses (e.g., addresses with short lifetimes), 2590 how can a client application choose an anonymous address as a source 2591 address in preference to a non-anonymous address? 2593 20.5. Use of term "agent" 2595 The term "agent", taken to mean "relay agent or server", may be 2596 confusing. "relay agent or server" might be clearer. 2598 20.6. Client behavior when response to Rebind is not received 2600 Section 13.3.4 describes several plausible ways in which a client 2601 might respond when it does not receive a Reply to a Rebind message. 2602 The acceptable client behaviors need to be defined and described 2603 in 13.3.4. 2605 20.7. Additional options 2607 Which additional options should be included in this base spec 2608 document? 2610 20.8. Operational parameters 2612 Should servers have an option to set operational parameters - 2613 retransmission timeouts, number of retries - in clients? 2615 21. Security 2617 This document references an "authentication option" which is TBD. 2619 DISCUSSION: 2621 Based on the discussion of security issues at the 2622 8/31/00 design team teleconference and subsequent 2623 DHC WG mailing list discussion, DHCPv6 will use 2624 the security model from DHCPv4, as described in 2625 draft-ietf-dhc-authentication-15.txt. 2627 22. Year 2000 considerations 2629 Since all times are relative to the current time of the transaction, 2630 there is no problem within the DHCPv6 protocol related to any 2631 hardcoded dates or two-digit representation of the current year. 2633 23. IANA Considerations 2635 This document defines message types TBD to be received by UDP at port 2636 numbers 546 and 547. Additional message types may be defined in the 2637 future. 2639 Section 7.1 lists several multicast addresses used by DHCP. 2641 This document also defines several status codes that are to be 2642 returned with the Reply message (see section 9.7). The non-zero 2643 values for these status codes which are currently specified are shown 2644 in the table in section 7.4. 2646 There is a DHCPv6 option described in section 16.6, which allows 2647 clients and servers to exchange values for some of the timing 2648 and retransmission parameters defined in section 7.5. Adding new 2649 parameters in the future would require extending the values by which 2650 the parameters are indicated in the DHCP option. Since there needs 2651 to be a list kept, the default values for each parameter should also 2652 be stored as part of the list. 2654 All of these protocol elements may be specified to assume new values 2655 at some point in the future. New values should be approved by the 2656 process of IETF Consensus [9]. 2658 24. Acknowledgments 2660 Thanks to the DHC Working Group for their time and input into the 2661 specification. Ralph Droms and Thomas Narten have had a major 2662 role in shaping the continued improvement of the protocol by their 2663 careful reviews. Many thanks to Matt Crawford, Erik Nordmark, Gerald 2664 Maguire, and Mike Carney for their studied review as part of the 2665 Last Call process. Thanks also for the consistent input, ideas, and 2666 review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov 2667 Rekhter, Matt Thomas, Sue Thomson, and Phil Wells. 2669 Thanks to Steve Deering and Bob Hinden, who have consistently 2670 taken the time to discuss the more complex parts of the IPv6 2671 specifications. 2673 A. Comparison between DHCPv4 and DHCPv6 2675 This appendix is provided for readers who will find it useful to see 2676 a model and architecture comparison between DHCPv4 [6, 1] and DHCPv6. 2677 There are three key reasons for the differences: 2679 o IPv6 inherently supports a new model and architecture for 2680 communications and autoconfiguration of addresses. 2682 o DHCPv6 benefits from the new IPv6 features. 2684 o New features were added to support the expected evolution and 2685 the existence of more complicated Internet network service 2686 requirements. 2688 IPv6 Architecture/Model Changes: 2690 o The link-local address permits a node to have an address 2691 immediately when the node boots, which means all clients have a 2692 source IP address at all times to locate an on-link server or 2693 relay. 2695 o The need for BOOTP compatibility and the broadcast flag have been 2696 removed. 2698 o Multicast and address scoping in IPv6 permit the design of 2699 discovery packets that would inherently define their range by the 2700 multicast address for the function required. 2702 o Stateful autoconfiguration has to coexist and integrate with 2703 stateless autoconfiguration supporting Duplicate Address 2704 Detection and the two IPv6 lifetimes, to facilitate the dynamic 2705 renumbering of addresses and the management of those addresses. 2707 o Multiple addresses per interface are inherently supported in 2708 IPv6. 2710 o Some DHCPv4 options are unnecessary now because the configuration 2711 parameters are either obtained through IPv6 Neighbor Discovery or 2712 the Service Location protocol [14]. 2714 DHCPv6 Architecture/Model Changes: 2716 o The message type is the first byte in the packet. 2718 o IPv6 Address allocations are now handled in a message option as 2719 opposed to the message header. 2721 o Client/Server bindings are now mandatory and take advantage of 2722 the client's link-local address to always permit communications 2723 either directly from an on-link server, or from a off-link server 2724 through an on-link relay. 2726 o Servers are discovered by a client Solicit, followed by a server 2727 Advertise message 2729 o The client will know if the server is on-link or off-link. 2731 o The on-link relay may locate off-link server addresses from 2732 system configuration or by the use of a site-wide multicast 2733 packet. 2735 o ACKs and NAKs are not used. 2737 o The server assumes the client receives its responses unless it 2738 receives a retransmission of the same client request. This 2739 permits recovery in the case where the network has faulted. 2741 o Clients can issue multiple, unrelated Request messages to the 2742 same or different servers. 2744 o The function of DHCPINFORM is inherent in the new packet design; 2745 a client can request configuration parameters other than IPv6 2746 addresses in the optional option headers. 2748 o Clients MUST listen to their UDP port for the new Reconfigure 2749 message from servers. 2751 o New options have been defined. 2753 With the changes just enumerated, we can support new user features, 2754 including 2756 o Configuration of Dynamic Updates to DNS 2758 o Address deprecation, for dynamic renumbering. 2760 o Relays can be preconfigured with server addresses, or use of 2761 multicast. 2763 o Authentication 2765 o Clients can ask for multiple IP addresses. 2767 o Addresses can be reclaimed using the Reconfigure-init message. 2769 o Integration between stateless and stateful address 2770 autoconfiguration. 2772 o Enabling relays to locate off-link servers. 2774 B. Full Copyright Statement 2776 Copyright (C) The Internet Society (2001). All Rights Reserved. 2778 This document and translations of it may be copied and furnished to 2779 others, and derivative works that comment on or otherwise explain it 2780 or assist in its implementation may be prepared, copied, published 2781 and distributed, in whole or in part, without restriction of any 2782 kind, provided that the above copyright notice and this paragraph 2783 are included on all such copies and derivative works. However, 2784 this document itself may not be modified in any way, such as by 2785 removing the copyright notice or references to the Internet Society 2786 or other Internet organizations, except as needed for the purpose 2787 of developing Internet standards in which case the procedures 2788 for copyrights defined in the Internet Standards process must be 2789 followed, or as required to translate it into languages other than 2790 English. 2792 The limited permissions granted above are perpetual and will not be 2793 revoked by the Internet Society or its successors or assigns. 2795 This document and the information contained herein is provided on an 2796 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2797 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2798 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2799 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2800 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2802 C. Changes in this draft 2804 This section describes the changes between this version of the DHCPv6 2805 specification and draft-ietf-dhc-dhcpv6-16.txt. 2807 C.1. New messages for confirming addresses and extending the lease on an 2808 IA 2810 Four new messages, DHCP Confirm, DHCP Renew, DHCP Rebind and DHCP 2811 Decline, have been added and are described in section 13. Client 2812 behavior - when and how to send these new messages - and server 2813 behavior - how to respond to each - has been defined. The message 2814 type codes for these messages have been added to section 7.3. 2816 C.2. New message formats 2818 Section 9 has been restructured to include only one copy of the DHCP 2819 message header, because now all the messages have the same header 2820 format. Descriptions of the use of header fields in the Confirm, 2821 Renew, Rebind and Decline messages have been added to 9. 2823 C.3. Renamed Server-forward message 2825 Section 10.2 has been renamed "relay-reply" for consistency with the 2826 rest of the document 2828 C.4. Clarified relay forwarding of messages 2830 Added text to sections on relay behavior to clarify encapsulation and 2831 decapsulation of client messages in Relay-forward and Relay-reply 2832 messages. 2834 C.5. Addresses and options in Advertise messages 2836 Modified section 12.4.2 so that servers include addresses to be 2837 assigned and other options in Advertise messages. Also added text to 2838 section 12.3.1 to disallow option values (except as noted in option 2839 definitions) in Solicit messages. 2841 C.6. Clarification of IA option format 2843 Changed the label of the prefix length field in an IA option to 2844 "prefix length" in the option format diagram, and moved the prefix 2845 before the address for consistency with relay messages and other IPv6 2846 protocols. 2848 C.7. Specification of transaction ID in Solicit message 2850 Add text (which was missing) to specify the insertion of a 2851 transaction ID in Solicit messages. 2853 C.8. Edits to definitions 2855 Some of the definitions in section 6 have been edited for clarity. 2857 C.9. Relay agent messages 2859 The formats of relay agent messages are now described in a separate 2860 section, 10. 2862 C.10. Relay agent behavior 2864 The behavior of relay agents for all client and server messages is 2865 now described in a single section, 15. 2867 C.11. Transmission of all client messages through relays 2869 All client messages are now multicast to the All Agents multicast 2870 address and forwarded by relays as appropriate. 2872 C.12. Reconfigure-init messages 2874 Client behavior in response to a Reconfigure-init messages has 2875 been extended to accommodate receipt of multiple copies of a 2876 Reconfigure-init message due to duplicate messages or retransmission. 2878 Server use of multicast Reconfigure-init has been specified. 2880 Hints about use of multicast and unicast for reliable reconfiguration 2881 have been added to server implementor's hints. 2883 C.13. Ordering of sections 2885 Several sections have been re-ordered for clarity. 2887 C.14. DSTM option 2889 The DSTM option has been added (section 16.9). 2891 References 2893 [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 2894 Extensions. Request for Comments (Draft Standard) 2132, 2895 Internet Engineering Task Force, March 1997. 2897 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 2898 Levels. Request for Comments (Best Current Practice) 2119, 2899 Internet Engineering Task Force, March 1997. 2901 [3] S. Bradner and A. Mankin. The Recommendation for the IP Next 2902 Generation Protocol. Request for Comments (Proposed Standard) 2903 1752, Internet Engineering Task Force, January 1995. 2905 [4] W. J. Croft and J. Gilmore. Bootstrap Protocol. Request for 2906 Comments 951, Internet Engineering Task Force, September 1985. 2908 [5] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 2909 Specification. Request for Comments (Draft Standard) 2460, 2910 Internet Engineering Task Force, December 1998. 2912 [6] R. Droms. Dynamic Host Configuration Protocol. Request for 2913 Comments (Draft Standard) 2131, Internet Engineering Task Force, 2914 March 1997. 2916 [7] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 2917 Request for Comments (Proposed Standard) 2373, Internet 2918 Engineering Task Force, July 1998. 2920 [8] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for 2921 IP version 6. Request for Comments (Proposed Standard) 1981, 2922 Internet Engineering Task Force, August 1996. 2924 [9] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 2925 Considerations Section in RFCs. Request for Comments (Best 2926 Current Practice) 2434, Internet Engineering Task Force, October 2927 1998. 2929 [10] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 2930 IP Version 6 (IPv6). Request for Comments (Draft Standard) 2931 2461, Internet Engineering Task Force, December 1998. 2933 [11] D. C. Plummer. Ethernet Address Resolution Protocol: Or 2934 converting network protocol addresses to 48.bit Ethernet address 2935 for transmission on Ethernet hardware. Request for Comments 2936 (Standard) 826, Internet Engineering Task Force, November 1982. 2938 [12] J. Postel. User Datagram Protocol. Request for Comments 2939 (Standard) 768, Internet Engineering Task Force, August 1980. 2941 [13] S. Thomson and T. Narten. IPv6 Stateless Address 2942 Autoconfiguration. Request for Comments (Draft Standard) 2462, 2943 Internet Engineering Task Force, December 1998. 2945 [14] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 2946 Location Protocol. Request for Comments (Proposed Standard) 2947 2165, Internet Engineering Task Force, June 1997. 2949 [15] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic 2950 Updates in the Domain Name System (DNS UPDATE). Request for 2951 Comments (Proposed Standard) 2136, Internet Engineering Task 2952 Force, April 1997. 2954 Chair's Address 2956 The working group can be contacted via the current chair: 2958 Ralph Droms 2959 Cisco Systems 2960 300 Apollo Drive 2961 Chelmsford, MA 01824 2963 Phone: (978) 244-4733 2964 E-mail: rdroms@cisco.com 2966 Author's Address 2968 Questions about this memo can be directed to: 2970 Jim Bound 2971 Nokia Networks 2972 5 Wayside Road 2973 Burlington, MA 01803 2974 USA 2975 Phone: +1-781-492-6010 2976 Email: jim.bound@nokia.com 2978 Mike Carney 2979 Sun Microsystems, Inc 2980 Mail Stop: UMPK17-202 2981 901 San Antonio Road 2982 Palo Alto, CA 94303-4900 2983 USA 2984 Phone: +1-650-786-4171 2985 Email: mwc@eng.sun.com 2987 Charles E. Perkins 2988 Communications Systems Lab 2989 Nokia Research Center 2990 313 Fairchild Drive 2991 Mountain View, California 94043 2992 USA 2993 Phone: +1-650 625-2986 2994 EMail: charliep@iprg.nokia.com 2995 Fax: +1 650 625-2502