idnits 2.17.1 draft-ietf-dhc-dhcpv6-18.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 63 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 264: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 265: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 303: '...ess, that client MUST fragment its pac...' RFC 2119 keyword, line 570: '... source ports MAY be arbitrary, clie...' RFC 2119 keyword, line 587: '...are reserved and MUST be silently igno...' (131 more instances...) -- The draft header indicates that this document obsoletes draft-ietf-dhc-dhcpv6-18.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-18.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 (15 April 2001) is 8412 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 2971, 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-18.txt Sun Microsystems, Inc 5 C. Perkins 6 Nokia Research Center 7 R. Droms(ed.) 8 Cisco Systems 9 15 April 2001 11 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 12 draft-ietf-dhc-dhcpv6-18.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? 12 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 . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . 17 99 9.10. DHCP Reconfigure-init Message Format . . . . . . . . . . 17 101 10. Relay messages 17 102 10.1. Relay-forward message . . . . . . . . . . . . . . . . . . 18 103 10.2. Relay-reply message . . . . . . . . . . . . . . . . . . . 18 105 11. Identity association 19 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 . . . 20 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 . . . . . . . . . . . . . . . . 23 120 13.2. Server Message Validation . . . . . . . . . . . . . . . . 23 121 13.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 24 122 13.3.1. Creation and sending of Request messages . . . . 24 123 13.3.2. Creation and sending of Confirm messages . . . . 25 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 . . . . 30 129 13.3.7. Time out and retransmission of Release Messages . 30 130 13.3.8. Creation and sending of Decline messages . . . . 30 131 13.3.9. Time out and retransmission of Decline Messages . 31 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 . . . . . . . . . . . 32 136 13.4.2. Receipt of Confirm messages . . . . . . . . . . . 32 137 13.4.3. Receipt of Renew messages . . . . . . . . . . . . 33 138 13.4.4. Receipt of Rebind messages . . . . . . . . . . . 34 139 13.4.5. Receipt of Release messages . . . . . . . . . . . 35 140 13.4.6. Sending of Reply messages . . . . . . . . . . . . 35 142 14. DHCP Server-Initiated Configuration Exchange 36 143 14.1. Reconfigure-init Message Validation . . . . . . . . . . . 36 144 14.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 36 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 . . . . . . . . 38 150 14.2.4. Receipt of Request messages . . . . . . . . . . . 38 152 14.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 38 153 14.3.1. Receipt of Reconfigure-init messages . . . . . . 38 154 14.3.2. Creation and sending of Request messages . . . . 38 155 14.3.3. Time out and retransmission of Request messages . 39 156 14.3.4. Receipt of Reply messages . . . . . . . . . . . . 39 158 15. Relay Behavior 39 159 15.1. Relaying of client messages . . . . . . . . . . . . . . . 39 160 15.2. Relaying of server messages . . . . . . . . . . . . . . . 40 162 16. DHCP options 40 163 16.1. Format of DHCP options . . . . . . . . . . . . . . . . . 40 164 16.2. Identity association option . . . . . . . . . . . . . . . 41 165 16.3. Option request option . . . . . . . . . . . . . . . . . . 43 166 16.4. Client message option . . . . . . . . . . . . . . . . . . 43 167 16.5. Server message option . . . . . . . . . . . . . . . . . . 44 168 16.6. Retransmission parameter option . . . . . . . . . . . . . 44 169 16.7. Reconfigure-delay option . . . . . . . . . . . . . . . . 44 170 16.8. DSTM Global IPv4 Address Option . . . . . . . . . . . . . 45 171 16.9. Authentication option . . . . . . . . . . . . . . . . . . 46 173 17. DHCP Client Implementor Notes 46 174 17.1. Primary Interface . . . . . . . . . . . . . . . . . . . . 46 175 17.2. Advertise Message and Configuration Parameter Caching . . 46 176 17.3. Time out and retransmission variables . . . . . . . . . . 47 177 17.4. Server Preference . . . . . . . . . . . . . . . . . . . . 47 179 18. DHCP Server Implementor Notes 47 180 18.1. Client Bindings . . . . . . . . . . . . . . . . . . . . . 47 181 18.2. Reconfigure-init Considerations . . . . . . . . . . . . . 47 182 18.2.1. Reliable transmission of multicast Reconfigure-init 183 messages . . . . . . . . . . . . . . . . . 48 184 18.3. Server Preference . . . . . . . . . . . . . . . . . . . . 48 185 18.4. Request Message Transaction-ID Cache . . . . . . . . . . 48 187 19. DHCP Relay Implementor Notes 48 189 20. Open Issues for Working Group Discussion 49 190 20.1. Authentication . . . . . . . . . . . . . . . . . . . . . 49 191 20.2. Identification of IAs by servers . . . . . . . . . . . . 49 192 20.3. DHCP-DNS interaction . . . . . . . . . . . . . . . . . . 49 193 20.4. Temporary addresses . . . . . . . . . . . . . . . . . . . 49 194 20.5. Use of term "agent" . . . . . . . . . . . . . . . . . . . 49 195 20.6. Client behavior when response to Rebind is not received . 49 196 20.7. Additional options . . . . . . . . . . . . . . . . . . . 50 197 20.8. Operational parameters . . . . . . . . . . . . . . . . . 50 199 21. Security 50 201 22. Year 2000 considerations 50 203 23. IANA Considerations 50 204 24. Acknowledgments 51 206 A. Comparison between DHCPv4 and DHCPv6 51 208 B. Full Copyright Statement 53 210 C. Changes in this draft 53 211 C.1. New messages for confirming addresses and extending the lease 212 on an IA . . . . . . . . . . . . . . . . . . . . . . . 54 213 C.2. New message formats . . . . . . . . . . . . . . . . . . . 54 214 C.3. Renamed Server-forward message . . . . . . . . . . . . . 54 215 C.4. Clarified relay forwarding of messages . . . . . . . . . 54 216 C.5. Addresses and options in Advertise messages . . . . . . . 54 217 C.6. Clarification of IA option format . . . . . . . . . . . . 54 218 C.7. Specification of transaction ID in Solicit message . . . 54 219 C.8. Edits to definitions . . . . . . . . . . . . . . . . . . 55 220 C.9. Relay agent messages . . . . . . . . . . . . . . . . . . 55 221 C.10. Relay agent behavior . . . . . . . . . . . . . . . . . . 55 222 C.11. Transmission of all client messages through relays . . . 55 223 C.12. Reconfigure-init messages . . . . . . . . . . . . . . . . 55 224 C.13. Ordering of sections . . . . . . . . . . . . . . . . . . 55 225 C.14. DSTM option . . . . . . . . . . . . . . . . . . . . . . . 55 226 C.15. Message and option numbering . . . . . . . . . . . . . . 55 227 C.16. Inclusion of IAs in Solicit message by client . . . . . . 56 228 C.17. Clarification of destination of client messages . . . . . 56 229 C.18. Clarification of client use of Confirm messages . . . . . 56 231 Chair's Address 58 233 Author's Address 58 234 1. Introduction 236 This document describes DHCP for IPv6 (DHCP), a UDP [12] 237 client/server protocol designed to reduce the cost of management 238 of IPv6 nodes in environments where network managers require more 239 control over the allocation of IPv6 addresses and configuration 240 of network stack parameters than that offered by "IPv6 Stateless 241 Autoconfiguration" [13]. DHCP is a stateful counterpart to 242 stateless autoconfiguration. Note that both stateful and stateless 243 autoconfiguration can be used concurrently in the same environment, 244 leveraging the strengths of both mechanisms in order to reduce the 245 cost of ownership and management of network nodes. 247 DHCP reduces the cost of ownership by centralizing the management 248 of network resources such as IP addresses, routing information, OS 249 installation information, directory service information, and other 250 such information on a few DHCP servers, rather than distributing such 251 information in local configuration files among each network node. 252 DHCP is designed to be easily extended to carry new configuration 253 parameters through the addition of new DHCP "options" defined to 254 carry this information. 256 Those readers familiar with DHCP for IPv4 [6] will find DHCP for IPv6 257 provides a superset of features, and benefits from the additional 258 features of IPv6 and freedom from BOOTP [4]-backward compatibility 259 constraints. For more information about the differences between DHCP 260 for IPv6 and DHCP for IPv4, see Appendix A. 262 2. Requirements 264 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 265 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 266 document, are to be interpreted as described in [2]. 268 This document also makes use of internal conceptual variables 269 to describe protocol behavior and external variables that an 270 implementation must allow system administrators to change. The 271 specific variable names, how their values change, and how their 272 settings influence protocol behavior are provided to demonstrate 273 protocol behavior. An implementation is not required to have them in 274 the exact form described here, so long as its external behavior is 275 consistent with that described in this document. 277 3. Background 279 Related work in IPv6 that would best serve an implementor to study 280 is the IPv6 Specification [5], the IPv6 Addressing Architecture [7], 281 IPv6 Stateless Address Autoconfiguration [13], IPv6 Neighbor 282 Discovery Processing [10], and Dynamic Updates to DNS [15]. These 283 specifications enable DHCP to build upon the IPv6 work to provide 284 both robust stateful autoconfiguration and autoregistration of DNS 285 Host Names. 287 The IPv6 Specification provides the base architecture and design of 288 IPv6. A key point for DHCP implementors to understand is that IPv6 289 requires that every link in the Internet have an MTU of 1280 octets 290 or greater (in IPv4 the requirement is 68 octets). This means that 291 a UDP packet of 536 octets will always pass through an internetwork 292 (less 40 octets for the IPv6 header), as long as there are no IP 293 options prior to the UDP header in the packet. But, IPv6 does not 294 support fragmentation at routers, so that fragmentation takes place 295 end-to-end between hosts. If a DHCP implementation needs to send a 296 packet greater than 1500 octets it can either fragment the UDP packet 297 into fragments of 1500 octets or less, or use Path MTU Discovery [8] 298 to determine the size of the packet that will traverse a network 299 path. 301 DHCP clients use Path MTU discovery when they have an address of 302 sufficient scope to reach the DHCP server. If a DHCP client does not 303 have such an address, that client MUST fragment its packets if the 304 resultant message size is greater than the minimum 1280 octets. 306 Path MTU Discovery for IPv6 is supported for both UDP and TCP and 307 can cause end-to-end fragmentation when the PMTU changes for a 308 destination. 310 The IPv6 Addressing Architecture specification [7] defines the 311 address scope that can be used in an IPv6 implementation, and the 312 various configuration architecture guidelines for network designers 313 of the IPv6 address space. Two advantages of IPv6 are that support 314 for multicast is required, and nodes can create link-local addresses 315 during initialization. This means that a client can immediately use 316 its link-local address and a well-known multicast address to begin 317 communications to discover neighbors on the link. For instance, a 318 client can send a Solicit message and locate a server or relay. 320 IPv6 Stateless Address Autoconfiguration [13] (Addrconf) specifies 321 procedures by which a node may autoconfigure addresses based on 322 router advertisements [10], and the use of a valid lifetime to 323 support renumbering of addresses on the Internet. In addition the 324 protocol interaction by which a node begins stateless or stateful 325 autoconfiguration is specified. DHCP is one vehicle to perform 326 stateful autoconfiguration. Compatibility with addrconf is a design 327 requirement of DHCP (see Section 4). 329 IPv6 Neighbor Discovery [10] is the node discovery protocol in IPv6 330 which replaces and enhances functions of ARP [11]. To understand 331 IPv6 and Addrconf it is strongly recommended that implementors 332 understand IPv6 Neighbor Discovery. 334 Dynamic Updates to DNS [15] is a specification that supports the 335 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 336 the dynamic updates to DNS to integrate addresses and name space to 337 not only support autoconfiguration, but also autoregistration in 338 IPv6. 340 4. Design Goals 342 - DHCP is a mechanism rather than a policy. Network administrators 343 set their administrative policies through the configuration 344 parameters they place upon the DHCP servers in the DHCP domain 345 they're managing. DHCP is simply used to deliver parameters 346 according to that policy to each of the DHCP clients within the 347 domain. 349 - DHCP is compatible with IPv6 stateless autoconf [13]. 351 - DHCP does not require manual configuration of network parameters 352 on DHCP clients, except in cases where such configuration is 353 needed for security reasons. A node configuring itself using 354 DHCP should require no user intervention. 356 - DHCP does not require a server on each link. To allow for scale 357 and economy, DHCP must work across DHCP relays. 359 - DHCP coexists with statically configured, non-participating nodes 360 and with existing network protocol implementations. 362 - DHCP clients can operate on a link without IPv6 routers present. 364 - DHCP will provide the ability to renumber network(s) when 365 required by network administrators [3]. 367 - A DHCP client can make multiple, different requests for 368 configuration parameters when necessary from one or more DHCP 369 servers at any time. 371 - DHCP will contain the appropriate time out and retransmission 372 mechanisms to efficiently operate in environments with high 373 latency and low bandwidth characteristics. 375 5. Non-Goals 377 This specification explicitly does not cover the following: 379 - Specification of a DHCP server to server protocol. 381 - How a DHCP server stores its DHCP data. 383 - How to manage a DHCP domain or DHCP server. 385 - How a DHCP relay is configured or what sort of information it may 386 log. 388 6. Terminology 390 6.1. IPv6 Terminology 392 IPv6 terminology relevant to this specification from the IPv6 393 Protocol [5], IPv6 Addressing Architecture [7], and IPv6 Stateless 394 Address Autoconfiguration [13] is included below. 396 address An IP layer identifier for an interface or 397 a set of interfaces. 399 unicast address An identifier for a single interface. 400 A packet sent to a unicast address is 401 delivered to the interface identified by 402 that address. 404 multicast address An identifier for a set of interfaces 405 (typically belonging to different nodes). 406 A packet sent to a multicast address is 407 delivered to all interfaces identified by 408 that address. 410 host Any node that is not a router. 412 IP Internet Protocol Version 6 (IPv6). The 413 terms IPv4 and IPv6 are used only in 414 contexts where it is necessary to avoid 415 ambiguity. 417 interface A node's attachment to a link. 419 link A communication facility or medium over 420 which nodes can communicate at the link 421 layer, i.e., the layer immediately below 422 IP. Examples are Ethernet (simple or 423 bridged); Token Ring; PPP links, X.25, 424 Frame Relay, or ATM networks; and Internet 425 (or higher) layer "tunnels", such as 426 tunnels over IPv4 or IPv6 itself. 428 link-layer identifier A link-layer identifier for an interface. 429 Examples include IEEE 802 addresses for 430 Ethernet or Token Ring network interfaces, 431 and E.164 addresses for ISDN links. 433 link-local address An IP address having link-only 434 scope, indicated by having the prefix 435 (FE80::0000/64), that can be used to reach 436 neighboring nodes attached to the same 437 link. Every interface has a link-local 438 address. 440 message A unit of data carried in a packet, 441 exchanged between DHCP agents and clients. 443 neighbor A node attached to the same link. 445 node A device that implements IP. 447 packet An IP header plus payload. 449 prefix The initial bits of an address, or a set 450 of IP address that share the same initial 451 bits. 453 prefix length The number of bits in a prefix. 455 router A node that forwards IP packets not 456 explicitly addressed to itself. 458 6.2. DHCP Terminology 460 Terminology specific to DHCP can be found below. 462 abort status A status value returned to the 463 application that has invoked a DHCP 464 client operation, indicating anything 465 other than success. 467 agent address The address of a neighboring DHCP Agent 468 on the same link as the DHCP client. 470 binding A binding (or, client binding) is a 471 group of server data records containing 472 the server's information about the 473 addresses in an IA and any other 474 configuration information assigned to 475 the client. A binding is indexed by the 476 tuple , where the 'prefix' 477 is a prefix assigned to the link to 478 which the client is attached and 'DUID' 479 is the DUID from the IA in the binding. 481 DISCUSSION: 483 The indexing of an IA by is still under discussion. 486 DHCP Dynamic Host Configuration Protocol 487 for IPv6. The terms DHCPv4 and DHCPv6 488 are used only in contexts where it is 489 necessary to avoid ambiguity. 491 configuration parameter An element of the configuration 492 information set on the server and 493 delivered to the client using DHCP. 494 Such parameters may be used to carry 495 information to be used by a node to 496 configure its network subsystem and 497 enable communication on a link or 498 internetwork, for example. 500 DHCP client (or client) A node that initiates requests on a link 501 to obtain configuration parameters from 502 one or more DHCP servers. 504 DHCP domain A set of links managed by DHCP and 505 operated by a single administrative 506 entity. 508 DHCP server (or server) A server is a node that responds to 509 requests from clients, and may or 510 may not be on the same link as the 511 client(s). 513 DHCP relay (or relay) A node that acts as an intermediary to 514 deliver DHCP messages between clients 515 and servers, and is on the same link as 516 a client. 518 DHCP agent (or agent) Either a DHCP server on the same link as 519 a client, or a DHCP relay. 521 DUID A DHCP unique identifier for a client. 523 DISCUSSION: 525 Rules for choosing a DUID are TBD. 527 Identity association (IA) A collection of addresses assigned to 528 a client. Each IA has an associated 529 DUID. An IA may have 0 or more addresses 530 associated with it. 532 transaction-ID An unsigned integer to match responses 533 with replies initiated either by a 534 client or server. 536 7. DHCP Constants 538 This section describes various program and networking constants used 539 by DHCP. 541 7.1. Multicast Addresses 543 DHCP makes use of the following multicast addresses: 545 All DHCP Agents address: FF02::1:2 This link-scoped multicast 546 address is used by clients to communicate with the 547 on-link agent(s) when they do not know those agents' 548 link-local address(es). All agents (servers and 549 relays) are members of this multicast group. 551 All DHCP Servers address: FF05::1:3 This site-scoped multicast 552 address is used by clients or relays to communicate 553 with server(s), either because they want to send 554 messages to all servers or because they do not know 555 the server(s) unicast address(es). Note that in order 556 for a client to use this address, it must have an 557 address of sufficient scope to be reachable by the 558 server(s). All servers within the site are members of 559 this multicast group. 561 DISCUSSION: 563 Is there a requirement for a site-scoped "All DHCP Clients" 564 multicast address, to be used as the default in sending 565 Reconfigure messages. 567 7.2. UDP ports 569 DHCP uses the following destination UDP [12] port numbers. While 570 source ports MAY be arbitrary, client implementations SHOULD permit 571 their specification through a local configuration parameter to 572 facilitate the use of DHCP through firewalls. 574 546 Client port. Used by servers as the destination port 575 for messages sent to clients and relays. Used by relay 576 agents as the destination port for messages sent to 577 clients. 579 547 Agent port. Used as the destination port by clients 580 for messages sent to agents. Used as the destination 581 port by relays for messages sent to servers. 583 7.3. DHCP message types 585 DHCP defines the following message types. More detail on these 586 message types can be found in Section 9. Message types 0 and 587 TBD--255 are reserved and MUST be silently ignored. The message code 588 for each message type is shown with the message name. 590 SOLICIT (1) The DHCP Solicit (or Solicit) message is used by 591 clients to locate servers. 593 ADVERTISE (2) The DHCP Advertise (or Advertise) message is used 594 by servers responding to Solicits. 596 REQUEST (3) The DHCP Request (or Request) message is used by 597 clients to request configuration parameters from 598 servers. 600 CONFIRM (4) The DHCP Confirm (or Confirm) message is used by 601 clients to confirm that the addresses assigned 602 to an IA and the lifetimes for those addresses, 603 as well as the current configuration parameters 604 assigned by the server to the client are still 605 valid. 607 RENEW (5) The DHCP Renew (or Renew) message is used by 608 clients to obtain the addresses assigned to an IA 609 and the lifetimes for those addresses, as well as 610 the current configuration parameters assigned by 611 the server to the client. A client sends a Renew 612 message to the server that originally assigned the 613 IA when the lease on an IA is about to expire. 615 REBIND (6) The DHCP Rebind (or Rebind) message is used by 616 clients to obtain the addresses assigned to an IA 617 and the lifetimes for those addresses, as well 618 as the current configuration parameters assigned 619 by the server to the client. A clients sends a 620 Rebind message to all available DHCP servers when 621 the lease on an IA is about to expire. 623 REPLY (7) The DHCP Reply (or Reply) message is used by 624 servers responding to Request, Confirm, Renew, 625 Rebind, Release and Decline messages. In the case 626 of responding to a Request, Confirm, Renew or 627 Rebind message, the Reply contains configuration 628 parameters destined for the client. 630 RELEASE (8) The DHCP Release (or Release) message is used by 631 clients to return one or more IP addresses to 632 servers. 634 DECLINE (9) The DHCP Decline (or Decline) message is used by 635 clients to indicate that the client has determined 636 that one or more addresses in an IA are already in 637 use on the link to which the client is connected. 639 RECONFIG (10) The DHCP Reconfigure-init (or Reconfigure-init) 640 message is sent by server(s) to inform 641 client(s) that the server(s) has new or updated 642 configuration parameters, and that the client(s) 643 are to initiate a Request/Reply transaction with 644 the server(s) in order to receive the updated 645 information. 647 RELAY-FORW (11) The DHCP Relay-forward (or Relay-forward) message 648 is used by relays to forward client messages to 649 servers. The client message is encapsulated in an 650 option in the Relay-forward message. 652 RELAY-REPL (12) The DHCP Relay-reply (or Relay-reply) message 653 is used by servers to send messages to clients 654 through a relay. The server encapsulates the 655 client message as an option in the Relay-reply 656 message, which the relay extracts and forwards to 657 the client. 659 7.4. Error Values 661 This section describes error values exchanged between DHCP 662 implementations. 664 7.4.1. Generic Error Values 666 The following symbolic names are used between client and server 667 implementations to convey error conditions. The following table 668 contains the actual numeric values for each name. Note that the 669 numeric values do not start at 1, nor are they consecutive. The 670 errors are organized in logical groups. 672 _______________________________________________________________ 673 |Error_Name___|Error_ID|_Description_________________________|_ 674 |Success______|00______|_Success_____________________________|_ 675 |UnspecFail___|16______|_Failure,_reason_unspecified_________|_ 676 |AuthFailed___|17______|_Authentication_failed_or_nonexistent|_ 677 |PoorlyFormed_|18______|_Poorly_formed_message_______________|_ 678 |Unavail______|19______|_Addresses_unavailable_______________|_ 680 7.4.2. Server-specific Error Values 682 The following symbolic names are used by server implementations to 683 convey error conditions to clients. The following table contains the 684 actual numeric values for each name. 685 _______________________________________________________________ 686 |Error_Name____|Error_ID|_Description________________________|_ 687 |NoBinding_____|20______|_Client_record_(binding)_unavailable|_ 688 |ConfNoMatch___|21______|_Client_record_Confirm_not_match_IA_|_ 690 |RenwNoMatch___|22______|_Client_record_Renew_not_match_IA___|_ 691 |RebdNoMatch___|23______|_Client_record_Rebind_not_match_IA__|_ 692 |InvalidSource_|24______|_Invalid_Client_IP_address__________|_ 693 |NoServer______|25______|_Relay_cannot_find_Server_Address___|_ 694 |ICMPError_____|64______|_Server_unreachable_(ICMP_error)____|_ 696 7.5. Configuration Variables 698 This section presents a table of client and server configuration 699 variables and the default or initial values for these variables. The 700 client-specific variables MAY be configured on the server and MAY be 701 delivered to the client through the "DHCP Retransmission Parameter 702 Option" in a Reply message. 704 _________________________________________________________________________ 705 |Parameter__________|Default|_Description______________________________|_ 706 |MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg_____________|_ 707 |MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg_____________|_ 708 |ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)________________|_ 709 |ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)___________________|_ 710 |SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)_____________|_ 711 |REP_MSG_TIMEOUT____|250____|_Retrans_timer_(msecs)_for_Reply__________|_ 712 |QRY_MSG_ATTEMPTS___|10_____|_MAX_Request/Confirm/Renew/Rebind_attempts|_ 713 |REL_MSG_ATTEMPTS___|5______|_MAX_Release/Decline_attempts_____________|_ 714 |RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)____________________|_ 715 |REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts_____________________|_ 716 |REC_REP_MIN________|5______|_Minimum_pause_interval_(secs)____________|_ 717 |REC_REP_MAX________|7200___|_Maximum_pause_interval_(secs)____________|_ 718 |REC_THRESHOLD______|100____|_%_of_required_clients____________________|_ 719 |SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)___________|_ 721 8. Overview 723 This section provides a general overview of the interaction between 724 the functional entities of DHCP. The overview is organized as a 725 series of questions and answers. Details of DHCP such as message 726 formats and retransmissions can be found in later sections of this 727 document. 729 8.1. How does a node know to use DHCP? 731 An unconfigured node determines that it is to use DHCP for 732 configuration of an interface by detecting the presence (or absence) 733 of routers on the link. If router(s) are present, the node examines 734 router advertisements to determine if DHCP should be used to 735 configure the interface. If there are no routers present, then 736 the node MUST use DHCP to configure the interface. Detail on 737 this process can be found in neighbor discovery [10] and stateless 738 autoconfiguration [13]. 740 8.2. What if the client and server(s) are on different links? 742 Use of DHCP in such environments requires one or more DHCP relays 743 be set up on the client's link, because a client may only have a 744 link-local address. Relays receive messages from the client and 745 forward them to some set of servers within the DHCP domain. The 746 client message is forwarded verbatim as an option in the message 747 from the relay to the server. A relay will include one of its own 748 addresses (of sufficient scope) from the interface on the same link 749 as the client, as well as the prefix length of that address, in its 750 message to the server. Servers receiving the forwarded traffic 751 use this information to aid in selecting configuration parameters 752 appropriate to the client's link. 754 Servers use relays to forward messages to clients. The message 755 intended for the client is carried as an option in the message to the 756 relay. The relay extracts the message from the optin and forwards it 757 to the client. Servers use the relay's address as the destination to 758 forward client-destined messages for final delivery by the relay. 760 Relays forward client messages to servers using some combination 761 of the All DHCP Servers site-local multicast address, some other 762 (perhaps a combination) of site-local multicast addresses set up 763 within the DHCP domain to include the servers in that domain, or a 764 list of unicast addresses for servers. The network administrator 765 makes relay configuration decisions based upon the topological 766 requirements (scope) of the DHCP domain they are managing. Note 767 that if the DHCP domain spans more than the site-local scope, then 768 the relays MUST be configured with global addresses for the client's 769 link so as to be reachable by servers outside the relays' site-local 770 environment. 772 8.3. How does a client request configuration parameters from servers? 774 To request configuration parameters, the client forms a Request 775 message, and sends it to the server either directly (the server is 776 on the same link as the client) or indirectly (through the on-link 777 relay). The client MAY include a Option Request Option 16.3 (ORO) 778 along with other options to request specific information from the 779 server. Note that the client MAY form multiple Request messages 780 and send each of them to different servers to request potentially 781 different information (perhaps based upon what was advertised) in 782 order to satisfy its needs. As a client's needs may change over time 783 (perhaps based upon an application's requirements), the client may 784 form additional Request messages to request additional information as 785 it is needed. 787 The server(s) respond with Reply messages containing the requested 788 configuration parameters, which can include status information 789 regarding the information requested by the client. The Reply MAY 790 also include additional information, such as a reconfiguration event 791 multicast group for the client to join to monitor reconfiguration 792 events, as described in section 8.7. 794 8.4. How do clients and servers identify and manage addresses? 796 Servers and clients manage addresses in groups called "identity 797 associations." Each identity associations is identified using a 798 unique identifier. An identity association may contain one or 799 more IPv6 addresses. DHCP servers assign addresses to identity 800 associations. DHCP clients use the addresses in an identity 801 association to configure interfaces. There is always at least one 802 identity association per interface that a client wishes to configure. 803 Each address in an IA has its own preferred and valid lifetime. Over 804 time, the server may change the characteristics of the addresses in 805 an IA; for example, by changing the preferred or valid lifetime for 806 an address in the IA. The server may also add or delete addresses 807 from an IA; for example, deleting old addresses and adding new 808 addresses to renumber a client. A client can request the current 809 list of addresses assigned to an IA from a server through an exchange 810 of protocol messages. 812 8.5. Can a client release its assigned addresses before the lease 813 expires? 815 A client forms a Release message, including options identifying 816 the IA to be released. The client sends the Release to the server 817 which assigned the addresses to the client initially. If that 818 server cannot be reached after a certain number of attempts (see 819 section 7.5), the client can abandon the Release attempt. In this 820 case, the address(es) in the IA will be reclaimed by the server(s) 821 when the lifetimes on the addresses expire. 823 8.6. What if the client determines one or more of its assigned addresses 824 are already being used by another client? 826 If the client determines through a mechanism like Duplicate Address 827 Detection [13] that the address it was assigned by the server is 828 already in use by another client, the client will form a Decline 829 message, including the option carrying the in-use address. The 830 option's status field MUST be set to the value reflecting the "in 831 use" status of the address. 833 8.7. How are clients notified of server configuration changes? 835 There are two possibilities. Either the clients discover the new 836 information when they revisit the server(s) to request additional 837 configuration information/extend the lifetime on an address. or 838 through a server-initiated event known as a reconfigure event. 840 The reconfiguration feature of DHCP offers network administrators 841 the opportunity to update configuration information on DHCP clients 842 whenever necessary. To signal the need for client reconfiguration, 843 the server will unicast a Reconfigure-init message to each 844 client individually. The server may use multicast to signal the 845 reconfiguration to multiple clients simultaneously. (Note that 846 there is no mechanism defined in the protocol to guarantee that 847 every client actually performs a reconfiguration in response to a 848 multicast reconfigure-init message.) A Reconfigure-init is a trigger 849 which will cause the client(s) to initiate a standard Request/Reply 850 exchange with the server in order to acquire the new or updated 851 addresses. 853 9. Message Formats 855 Each DHCP message has an identical fixed format header; some messages 856 also allow a variable format area for options. Not all fields in 857 the header are used in every message. In this section, every field 858 is described for every message and fields that are not used in a 859 message are marked as "unused". All unused fields in a message MUST 860 be transmitted as zeroes and ignored by the receiver of the message. 862 The DHCP message header: 864 0 1 2 3 865 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 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | msg-type | preference | transaction-ID | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | | 870 | client-link-local-address | 871 | (16 octets) | 872 | | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | | 875 | server-address | 876 | (16 octets) | 877 | | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 . . 880 . options . 881 | (variable) | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 9.1. DHCP Solicit Message Format 886 msg-type SOLICIT 888 preference (unused) MUST be 0 890 transaction-ID An unsigned integer generated by the 891 client used to identify this Solicit 892 message. 894 client-link-local-address The link-local address of the 895 interface for which the client is 896 using DHCP. 898 server-address (unused) MUST be 0 900 options See section 16. 902 9.2. DHCP Advertise Message Format 904 msg-type ADVERTISE 906 preference An unsigned integer indicating a 907 server's willingness to provide 908 service to the client. 910 transaction-ID An unsigned integer used to identify 911 this Advertise message. Copied from 912 the client's Solicit message. 914 client-link-local-address The IP link-local address of the 915 client interface from which the client 916 issued the Solicit message. 918 server-address The IP address of the server that 919 generated this message. If the DHCP 920 domain crosses site boundaries, then 921 this address MUST be globally-scoped. 923 options See section 16. 925 9.3. DHCP Request Message Format 927 msg-type REQUEST 929 preference (unused) MUST be 0 931 transaction-ID An unsigned integer generated by the 932 client used to identify this Request 933 message. 935 client-link-local-address The link-local address of the client 936 interface from which the client will 937 issue the Request message. 939 server-address The IP address of the server to which 940 the this message is directed, copied 941 from an Advertise message. 943 options See section 16. 945 9.4. DHCP Confirm Message Format 947 msg-type CONFIRM 949 preference (unused) MUST be 0 951 transaction-ID An unsigned integer generated by the 952 client used to identify this Confirm 953 message. 955 client-link-local-address The link-local address of the client 956 interface from which the client will 957 issue the Confirm message. 959 server-address MUST be zero. 961 options See section 16. 963 9.5. DHCP Renew Message Format 965 msg-type RENEW 967 preference (unused) MUST be 0 969 transaction-ID An unsigned integer generated by the 970 client used to identify this Renew 971 message. 973 client-link-local-address The link-local address of the client 974 interface from which the client will 975 issue the Renew message. 977 server-address The IP address of the server to which 978 this Renew message is directed, which 979 MUST be the address of the server from 980 which the IAs in this message were 981 originally assigned. 983 options See section 16. 985 9.6. DHCP Rebind Message Format 987 msg-type REBIND 989 preference (unused) MUST be 0 991 transaction-ID An unsigned integer generated by the 992 client used to identify this Rebind 993 message. 995 client-link-local-address The link-local address of the client 996 interface from which the client will 997 issue the Rebind message. 999 server-address MUST be zero. 1001 options See section 16. 1003 9.7. DHCP Reply Message Format 1005 msg-type REPLY 1007 preference An unsigned integer indicating a 1008 server's willingness to provide 1009 service to the client. 1011 transaction-ID An unsigned integer used to identify 1012 this Reply message. Copied from the 1013 client's Request, Confirm, Renew or 1014 Rebind message. 1016 client-link-local-address The link-local address of the 1017 interface for which the client is 1018 using DHCP. 1020 server-address The IP address of the server. 1021 If the DHCP domain crosses site 1022 boundaries, then this address MUST be 1023 globally-scoped. 1025 options See section 16. 1027 9.8. DHCP Release Message Format 1029 msg-type RELEASE 1031 preference (unused) MUST be 0 1033 transaction-ID An unsigned integer generated by the 1034 client used to identify this Release 1035 message. 1037 client-link-local-address The client's link-local address for 1038 the interface from which the client 1039 will send the Release message. 1041 server-address The IP address of the server that 1042 assigned the IA. 1044 options See section 16. 1046 9.9. DHCP Decline Message Format 1048 msg-type DECLINE 1050 preference (unused) MUST be 0 1052 transaction-ID An unsigned integer generated by the 1053 client used to identify this Decline 1054 message. 1056 client-link-local-address The client's link-local address for 1057 the interface from which the client 1058 will send the Decline message. 1060 server-address The IP address of the server that 1061 assigned the addresses. 1063 options See section 16. 1065 9.10. DHCP Reconfigure-init Message Format 1067 preference (unused) MUST be 0 1069 transaction-ID An unsigned integer generated 1070 by the server to identify this 1071 Reconfigure-init message 1073 client-link-local-address (unused) MUST be 0 1075 server-address The IP address of the DHCP server 1076 issuing the Reconfigure-init message. 1077 MUST be of sufficient scope to be 1078 reachable by all clients. 1080 options See section 16. 1082 10. Relay messages 1084 Relay agents exchange messages with servers to forward messages 1085 between clients and servers that are not connected to the same link. 1087 10.1. Relay-forward message 1089 0 1 2 3 1090 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 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | msg-type | prefix length | | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1094 | | 1095 | relay-address | 1096 | | 1097 | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1099 | options (variable number and length) .... | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 msg-type RELAY-FORW 1104 prefix-length The length of the prefix in the address in the 1105 "relay-address" field. 1107 relay-address An address assigned to the interface through which 1108 the message from the client was received. 1110 options MUST include a "Client message option"; see 1111 section 16.4. 1113 10.2. Relay-reply message 1115 0 1 2 3 1116 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 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | msg-type | prefix length | | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1120 | | 1121 | relay-address | 1122 | | 1123 | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1125 | options (variable number and length) .... | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 msg-type RELAY-REPL 1130 prefix-length The length of the prefix in the address in the 1131 "relay-address" field. 1133 relay-address An address identifying the interface through which 1134 the message from the server should be forwarded; 1135 copied from the "client-forward" message. 1137 options MUST include a "Server message option"; see 1138 section 16.5. 1140 11. Identity association 1142 An "identity-association" (IA) is a construct through which a server 1143 and a client can identify, group and manage IPv6 addresses. Each IA 1144 consists of a DUID and a list of associated IPv6 addresses (the list 1145 may be empty). A client associates an IA with one of its interfaces 1146 and uses the IA to obtain IPv6 addresses for that interface from a 1147 server. 1149 See section 16.2 for the representation of an IA in a DHCP message. 1151 12. DHCP Server Solicitation 1153 This section describes how a client locates servers. The behavior 1154 of client and server implementations is discussed, along with the 1155 messages they use. 1157 12.1. Solicit Message Validation 1159 Clients MUST silently discard any received Solicit messages. 1161 Agents MUST silently discard any received Solicit messages if the 1162 "client-link-local-address" field does not contain a valid link-local 1163 address. 1165 12.2. Advertise Message Validation 1167 Servers MUST discard any received Advertise messages. 1169 Clients MUST discard any Advertise messages that meet any of the 1170 following criteria: 1172 o The "Transaction-ID" field value does not match the value the 1173 client used in its Solicit message. 1175 o The "client-link-local-address" field value does not match the 1176 link-local address of the interface upon which the client sent 1177 the Solicit message. 1179 12.3. Client Behavior 1181 Clients use the Solicit message to discover DHCP servers configured 1182 to serve addresses on the link to which the client is attached. 1184 12.3.1. Creation and sending of the Solicit message 1186 The client sets the "msg-type" field to SOLICIT, and places the 1187 link-local address of the interface it wishes to configure in the 1188 "client-link-local-address" field. 1190 The client generates a transaction ID inserts this value in the 1191 "transaction-ID" field. 1193 The client MUST include options for any IAs to which the client is 1194 expecting to have the server assign addresses. Because the client 1195 does not have any IAs with addresses when sending a Solicit message, 1196 all of the IAs MUST be empty. The client MAY include an Option 1197 Request Option in the Solicit message. The client MUST NOT include 1198 any other options except those specifically allowed as defined by 1199 specific options. 1201 The client sends the Solicit message to the All DHCP Agents 1202 multicast address, destination port 547. The source port selection 1203 can be arbitrary, although it SHOULD be possible using a client 1204 configuration facility to set a specific source port value. 1206 12.3.2. Time out and retransmission of Solicit Messages 1208 The client's first Solicit message on the interface MUST be delayed 1209 by a random amount of time between the interval of MIN_SOL_DELAY and 1210 MAX_SOL_DELAY. This random delay desynchronizes clients which start 1211 at the same time (e.g., after a power outage). 1213 The client waits ADV_MSG_TIMEOUT, collecting Advertise messages. 1214 If no Advertise messages are received, the client retransmits 1215 the Solicit, and doubles the ADV_MSG_TIMEOUT value. This process 1216 continues until either one or more Advertise messages are received or 1217 ADV_MSG_TIMEOUT reaches the ADV_MSG_MAX value. Thereafter, Solicits 1218 are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been 1219 made, at which time the client stops trying to DHCP configure the 1220 interface. An event external to DHCP is required to restart the DHCP 1221 configuration process. 1223 Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY, 1224 ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 7.5. 1226 12.3.3. Receipt of Advertise messages 1228 Upon receipt of one or more validated Advertise messages, the client 1229 selects one or more Advertise messages based upon the following 1230 criteria. 1232 - Those Advertise messages with the highest server preference 1233 value (see section 17.4) are preferred over all other Advertise 1234 messages. 1236 - Within a group of Advertise messages with the same server 1237 preference value, a client MAY select those servers whose 1238 Advertise messages advertise information of interest to 1239 the client. For example, one server may be advertising the 1240 availability of IP addresses which have an address scope of 1241 interest to the client. 1243 Once a client has selected Advertise message(s), the client will 1244 typically store information about each server, such as server 1245 preference value, addresses advertised, when the advertisement was 1246 received, and so on. Depending on the requirements of the client's 1247 invoking user, the client MAY initiate a configuration exchange with 1248 the server(s) immediately, or MAY defer this exchange until later. 1250 If the client needs to select an alternate server in the case that a 1251 chosen server does not respond, the client chooses the server with 1252 the next highest preference value. 1254 The client MAY choose a less-preferred server if that server has a 1255 better set of advertised parameters, such as the available addresses 1256 advertised in IAs. 1258 12.4. Server Behavior 1260 For this discussion, the server is assumed to have been configured in 1261 an implementation specific manner. This configuration is assumed to 1262 contain all network topology information for the DHCP domain, as well 1263 as any necessary authentication information. 1265 12.4.1. Receipt of Solicit messages 1267 If the server receives a Solicit message, the client must be on the 1268 same link as the server. If the server receives a Relay-forward 1269 message containing a Solicit message, the client must be on the 1270 link to which the prefix identified by the "relay-address" and 1271 "prefix-length" fields in the Relay-forward message is assigned. 1272 The server records the "relay-address" field from the Relay-forward 1273 message and extracts the solicit message from the "client-message" 1274 option. 1276 If administrative policy permits the server to respond to a client on 1277 that link, the server will generate and send an Advertise message to 1278 the client. 1280 12.4.2. Creation and sending of Advertise messages 1282 The server sets the "msg-type" field to ADVERTISE and copies the 1283 values of the following fields from the client's Solicit to the 1284 Advertise message: 1286 o transaction-ID 1288 o client-link-local-address 1290 The server places one of its IP addresses (determined through 1291 administrator setting) in the "server-address" field of the Advertise 1292 message. The server sets the "preference" field according to its 1293 configuration information. See section 18.3 for a description of 1294 server preference. 1296 The server MUST include options to the Advertise message containing 1297 any addresses that would be assigned to IAs contained in the Solicit 1298 message from the client. The server MAY include other options the 1299 server will return to the client in a subsequent Reply message. 1300 The information in these options will be used by the client in the 1301 selection of a server if the client receives more than one Advertise 1302 message. 1304 If the Solicit message was received in a Relay-forward message, the 1305 server constructs a Relay-reply message with the Advertise message in 1306 the payload of a "server-message" option. The server unicasts the 1307 Relay-reply message to the address in the "relay-address" field from 1308 the Relay-forward message. 1310 If the Solicit message was received directly by the server, the 1311 server unicasts the Advertise message directly to the client using 1312 the "client-link-local-address" field value as the destination 1313 address. The Advertise message MUST be unicast through the interface 1314 on which the Solicit message was received. 1316 13. DHCP Client-Initiated Configuration Exchange 1318 A client initiates a message exchange with a server or servers to 1319 acquire or update configuration information of interest. The client 1320 may initiate the configuration exchange as part of the operating 1321 system configuration process or when requested to do so by the 1322 application layer. 1324 The client uses the following messages to initiate a configuration 1325 event with a server or servers: 1327 Request Obtain initial configuration information (from a server 1328 identified in a previously received Advertise message) 1329 when the client has no assigned addresses 1331 Confirm Confirm the validity of assigned addresses and other 1332 configuration changes through the server from which the 1333 configuration information was obtained when the client's 1334 assigned addresses may not be valid; for example, when 1335 the client reboots or loses its connection to a link 1337 Renew Extend the lease on an IA through the server that 1338 originally assigned the IA 1340 Rebind Extend the lease on an IA through any server willing to 1341 extend the lease 1343 A client uses the Release/Reply message exchange to indicate to the 1344 DHCP server that the client will no longer be using the addresses in 1345 the released IA. 1347 A client uses the Decline/Reply message exchange to indicate to the 1348 DHCP server that the client has detected that one or more addresses 1349 assigned by the server is already in use on the client's link. 1351 13.1. Client Message Validation 1353 Clients MUST silently discard any received client messages (Request, 1354 Confirm, Renew, Rebind, Release or Decline messages). 1356 Agents MUST discard any received client messages in which the 1357 "client-link-local-address" field does not contain a valid link-local 1358 address. 1360 Servers MUST discard any received client messages in which the 1361 "options" field contains an authentication option, and the server 1362 cannot successfully authenticate the client. 1364 Servers MUST discard any received Request, Renew, Release or Decline 1365 message in which the "server-address" field value does not match any 1366 of the server's addresses. 1368 13.2. Server Message Validation 1370 Servers MUST silently discard any received server messages (Reply or 1371 Reconfigure-init messages). 1373 Clients MUST discard any server messages that meet any of the 1374 following criteria: 1376 o The "transaction-ID" field value in the server message does 1377 not match the value the client used in its Request or Release 1378 message. 1380 o The "client-link-local-address" field value in the server message 1381 does not match the link-local address of the interface from which 1382 the client sent in its Request, Confirm, Renew, Rebind, Release 1383 or Decline message. 1385 o The server message contains an authentication option, and the 1386 client's attempt to authenticate the message fails. 1388 Relays MUST discard any Relay-reply message in which the 1389 "client-link-local-address" in the encapsulated Reply message does 1390 not contain a valid link-local address. 1392 13.3. Client Behavior 1394 A client will use Request, Confirm, Renew and Rebind messages to 1395 acquire and confirm the validity of configuration information. A 1396 client may initiate such an exchange automatically in order to 1397 acquire the necessary network parameters to communicate with nodes 1398 off-link. The client uses the server address information from 1399 previous Advertise message(s) for use in constructing Request and 1400 Renew message(s). Note that a client may request configuration 1401 information from one or more servers at any time. 1403 A client uses the Release message in the management of IAs when 1404 the client has been instructed to release the IA prior to the IA 1405 expiration time since it is no longer needed. 1407 A client uses the Decline message when the client has determined 1408 through DAD or some other method that one or more of the addresses 1409 assigned by the server in the IA is already in use by a different 1410 client. 1412 13.3.1. Creation and sending of Request messages 1414 If a client has no valid IPv6 addresses of sufficient scope to 1415 communicate with a DHCP server, it may send a Request message to 1416 obtain new addresses. The client includes one or more IAs in the 1417 Request message, to which the server assigns new addresses. The 1418 server then returns IA(s) to the client in a Reply message. 1420 The client sets the "msg-type" field to REQUEST, and places 1421 the link-local address of the interface it wishes to acquire 1422 configuration information for in the "client-link-local-address" 1423 field. 1425 The client generates a transaction ID inserts this value in the 1426 "transaction-ID" field. 1428 The client places the address of the destination server in the 1429 "server-address" field. 1431 The client adds any appropriate options, including one or more IA 1432 options (if the client is requesting that the server assign it some 1433 network addresses). The list of addresses in each included IA MUST 1434 be empty. 1436 The client sends the Request message to the All DHCP Agents 1437 multicast address, destination port 547. The source port selection 1438 can be arbitrary, although it SHOULD be possible using a client 1439 configuration facility to set a specific source port value. 1441 The server will respond to the Request message with a Reply 1442 message. If no Reply message is received within REP_MSG_TIMEOUT 1443 milliseconds, the client retransmits the Request with the same 1444 transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits 1445 again. The client continues this process until a Reply is received 1446 or REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at 1447 which time the client MUST abort the configuration attempt. The 1448 client SHOULD report the abort status to the application layer. 1450 Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS 1451 are documented in section 7.5. 1453 13.3.2. Creation and sending of Confirm messages 1455 Whenever a client may have moved to a new link, its IPv6 addresses 1456 may no longer be valid. Examples of times when a client may have 1457 moved to a new link include: 1459 o The client reboots 1461 o The client is physically disconnected from a wired connection 1463 o The client returns from sleep mode 1465 o The client using a wireless technology changes cells 1467 In any situation when a client may have moved to a new link, the 1468 client MUST initiate a Confirm/Reply message exchange. The client 1469 includes any IAs, along with the addresses associated with those IAs, 1470 in its Confirm message. The server will indicate the acceptability 1471 of the addresses with the status in the IA it returns to the client. 1473 DISCUSSION: 1475 This section used to allow servers to change the addresses 1476 in an IA. Without some additional mechanism, servers 1477 responding to Confirm messages can't change safely 1478 change the addresses in IAs (although they can change 1479 the lifetimes), because servers may send back different 1480 addresses. 1482 The client sets the "msg-type" field to CONFIRM, and places 1483 the link-local address of the interface it wishes to acquire 1484 configuration information for in the "client-link-local-address" 1485 field. 1487 The client generates a transaction ID inserts this value in the 1488 "transaction-ID" field. 1490 The client sets the "server-address" field to 0. 1492 The client adds any appropriate options, including one or more IA 1493 options (if the client is requesting that the server confirm the 1494 validity of some network addresses). If the client does include 1495 any IA options, it MUST include the list of addresses the client 1496 currently has associated with that IA. 1498 The client sends the Confirm message to the All DHCP Agents 1499 multicast address, destination port 547. The source port selection 1500 can be arbitrary, although it SHOULD be possible using a client 1501 configuration facility to set a specific source port value. 1503 Servers will respond to the Confirm message with a Reply message. If 1504 no Confirm message is received within REP_MSG_TIMEOUT milliseconds, 1505 the client retransmits the Confirm with the same transaction-ID, 1506 and doubles the REP_MSG_TIMEOUT value, and waits again. The client 1507 continues this process until a Reply is received or QRY_MSG_ATTEMPTS 1508 unsuccessful attempts have been made, at which time the client MUST 1509 abort the configuration attempt. The client SHOULD report the abort 1510 status to the application layer. 1512 Default and initial values for REP_MSG_TIMEOUT and QRY_MSG_ATTEMPTS 1513 are documented in section 7.5. 1515 If the client receives no response to its Confirm message, it MAY 1516 restart the configuration process by locating a DHCP server with an 1517 Advertise message and sending a Request to that server, as described 1518 in section 13.3.1. 1520 13.3.3. Creation and sending of Renew messages 1522 IPv6 addresses assigned to a client through an IA use the same 1523 preferred and valid lifetimes as IPv6 addresses obtained through 1524 stateless autoconfiguration. The server assigns preferred and valid 1525 lifetimes to the IPv6 addresses it assigns to an IA. To extend those 1526 lifetimes, the client sends a Request to the server containing an 1527 "IA option" for the IA and its associated addresses. The server 1528 determines new lifetimes for the addresses in the IA according to 1529 the server's administrative configuration. The server may also add 1530 new addresses to the IA. The server remove addresses from the IA by 1531 setting the preferred and valid lifetimes of those addresses to zero. 1533 The server controls the time at which the client contacts the server 1534 to extend the lifetimes on assigned addresses through the T1 and 1535 T2 parameters assigned to an IA. If the server does not assign an 1536 explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the 1537 shortest preferred lifetime of any address assigned to the IA and 1538 T2 defaults to 0.875 times the shortest preferred lifetime of any 1539 address assigned to the IA. 1541 At time T1 for an IA, the client initiates a Request/Reply message 1542 exchange to extend the lifetimes on any addresses in the IA. The 1543 client includes an IA option with all addresses currently assigned to 1544 the IA in its Request message. The client multicasts this Request 1545 message to the All DHCP Agents multicast address. 1547 The client sets the "msg-type" field to RENEW, and places 1548 the link-local address of the interface it wishes to acquire 1549 configuration information for in the "client-link-local-address" 1550 field. 1552 The client generates a transaction ID inserts this value in the 1553 "transaction-ID" field. 1555 The client places the address of the destination server in the 1556 "server-address" field. 1558 The client adds any appropriate options, including one or more IA 1559 options (if the client is requesting that the server extend the lease 1560 on some IAs; note that the client may check the status of other 1561 configuration parameters without asking for lease extensions). If 1562 the client does include any IA options, it MUST include the list of 1563 addresses the client currently has associated with that IA. 1565 The client sends the Renew message to the All DHCP Agents multicast 1566 address, destination port 547. The source port selection can 1567 be arbitrary, although it SHOULD be possible using a client 1568 configuration facility to set a specific source port value. 1570 The server will respond to the Renew message with a Reply message. 1571 If no Reply message is received within REP_MSG_TIMEOUT milliseconds, 1572 the client retransmits the Renew with the same transaction-ID, and 1573 doubles the REP_MSG_TIMEOUT value, and waits again. The client 1574 continues this process until a Reply is received or until time T2 is 1575 reached (see section 13.3.4). 1577 Default and initial values for REP_MSG_TIMEOUT are documented in 1578 section 7.5. 1580 13.3.4. Creation and sending of Rebind messages 1582 At time T2 for an IA (which will only be reached if the server to 1583 which the Renew message was sent at time T1 has not responded), 1584 the client initiates a Rebind/Reply message exchange. The client 1585 includes an IA option with all addresses currently assigned to the IA 1586 in its Rebind message. The client multicasts this message to the All 1587 DHCP Agents multicast address. 1589 The client sets the "msg-type" field to REBIND, and places 1590 the link-local address of the interface it wishes to acquire 1591 configuration information for in the "client-link-local-address" 1592 field. 1594 The client generates a transaction ID inserts this value in the 1595 "transaction-ID" field. 1597 The client sets the "server-address" field to 0. 1599 The client adds any appropriate options, including one or more IA 1600 options. If the client does include any IA options (if the client is 1601 requesting that the server extend the lease on some IAs; note that 1602 the client may check the status of other configuration parameters 1603 without asking for lease extensions), it MUST include the list of 1604 addresses the client currently has associated with that IA. 1606 The client sends the Rebind message to the All DHCP Agents multicast 1607 address, destination port 547. The source port selection can 1608 be arbitrary, although it SHOULD be possible using a client 1609 configuration facility to set a specific source port value. 1611 The server will respond to the Rebind message with a Reply message. 1612 If no Reply message is received within REP_MSG_TIMEOUT milliseconds, 1613 the client retransmits the Rebind with the same transaction-ID, and 1614 doubles the REP_MSG_TIMEOUT value, and waits again. The client 1615 continues this process until a Reply is received. 1617 Default and initial values for REP_MSG_TIMEOUT are documented in 1618 section 7.5. 1620 DISCUSSION: 1622 The client has several alternatives to choose from if it 1623 receives no response to its Rebind message. 1625 - When the lease on the IA expires, the client may choose 1626 to use a Solicit message to locate a new DHCP server and 1627 send a Request for the expired IA to the new server 1629 - Some addresses in the IA may have lifetimes that extend 1630 beyond the lease of the IA, so the client may choose 1631 to continue to use those addresses; once all of the 1632 addresses have expired, the client may choose to locate 1633 a new DHCP server 1635 - The client may have other addresses in other IAs, so the 1636 client may choose to discard the expired IA and use the 1637 addresses in the other IAs 1639 13.3.5. Receipt of Reply message in response to a Reply, Confirm, Renew 1640 or Rebind message 1642 Upon the receipt of a valid Reply message in response to a 1643 Request, Confirm, Renew or Rebind message, the client extracts the 1644 configuration information contained in the Reply. If the "status" 1645 field contains a non-zero value, the client reports the error status 1646 to the application layer. 1648 The client records the T1 and T2 times for each IA in the Reply 1649 message. The client records any addresses included with IAs in 1650 the Reply message. The client updates the preferred and valid 1651 lifetimes for the addresses in the IA from the lifetime information 1652 in the IA option. The client leaves any addresses that the client 1653 has associated with the IA that are not included in the IA option 1654 unchanged. 1656 Management of the specific configuration information is detailed in 1657 the definition of each option, in section 16. 1659 When the client receives an Unavail error status in an IA from the 1660 server for a Request message the client will have to find a new 1661 server to create an IA. 1663 When the client receives a NoBinding error status in an IA from the 1664 server for a Confirm message the client can assume it needs to send a 1665 Request to reestablish an IA with the server. 1667 When the client receives a Conf_NoMatch error status in an IA from 1668 the server for a Confirm message the client can send a Renew message 1669 to the server to extend the lease for the addresses. 1671 When the client receives a NoBinding error status in an IA from the 1672 server for a Renew message the client can assume it needs to send a 1673 Request to reestablish an IA with the server. 1675 When the client receives a Renw_NoMatch error status in an IA from 1676 the server for a Renew message the client can assume it needs to send 1677 a Request to reestablish an IA with the server. 1679 When the client receives an Unavail error status in an IA from the 1680 server for a Renew message the client can assume it needs to send a 1681 Request to reestablish an IA with the server. 1683 When the client receives a NoBinding error status in an IA from the 1684 server for a Rebind message the client can assume it needs to send a 1685 Request to reestablish an IA with the server or try another server. 1687 When the client receives a Rebd_NoMatch error status in an IA from 1688 the server for a Rebind message the client can assume it needs to 1689 send a Request to reestablish an IA with the server or try another 1690 server. 1692 When the client receives an Unavail error status in an IA from the 1693 server for a Rebind message the client can assume it needs to send a 1694 Request to reestablish an IA with the server or try another server. 1696 13.3.6. Creation and sending of Release messages 1698 The client sets the "msg-type" field to RELEASE, and places the 1699 link-local address of the interface associated with the configuration 1700 information it wishes to release in the "client-link-local-address" 1701 field. 1703 The client generates a transaction ID and places this value in the 1704 "transaction-ID" field. 1706 The client places the IP address of the server that allocated the 1707 address(es) in the "server-address" field. 1709 The client includes options containing the IAs it is releasing in the 1710 "options" field. The addresses to be released MUST be included in 1711 the IAs. The appropriate "status" field in the options MUST be set 1712 to indicate the reason for the release. 1714 If the client is configured to use authentication, the client 1715 generates the appropriate authentication option, and adds this option 1716 to the "options" field. Note that the authentication option MUST be 1717 the last option in the "options" field. See section 16.9 for more 1718 details about the authentication option. 1720 The client send the Release message to the All DHCP Agents multicast 1721 address. 1723 13.3.7. Time out and retransmission of Release Messages 1725 If no Reply message is received within REP_MSG_TIMEOUT milliseconds, 1726 the client retransmits the Release, doubles the REP_MSG_TIMEOUT 1727 value, and waits again. The client continues this process until a 1728 Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have been 1729 made, at which time the client SHOULD abort the release attempt. 1730 The client SHOULD return the abort status to the application, if an 1731 application initiated the release. 1733 Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS 1734 are documented in section 7.5. 1736 Note that if the client fails to release the IA, the addresses 1737 assigned to the IA will be reclaimed by the server when the lease 1738 associated with it expires. 1740 13.3.8. Creation and sending of Decline messages 1742 The client sets the "msg-type" field to DECLINE, and places the 1743 link-local address of the interface associated with the configuration 1744 information it wishes to decline in the "client-link-local-address" 1745 field. 1747 The client generates a transaction ID and places this value in the 1748 "transaction-ID" field. 1750 The client places the IP address of the server that allocated the 1751 address(es) in the "server-address" field. 1753 The client includes options containing the IAs it is declining in the 1754 "options" field. The addresses to be released MUST be included in 1755 the IAs. The appropriate "status" field in the options MUST be set 1756 to indicate the reason for declining the address. 1758 If the client is configured to use authentication, the client 1759 generates the appropriate authentication option, and adds this option 1760 to the "options" field. Note that the authentication option MUST be 1761 the last option in the "options" field. See section 16.9 for more 1762 details about the authentication option. 1764 The client send the Decline message to the All DHCP Agents multicast 1765 address. 1767 13.3.9. Time out and retransmission of Decline Messages 1769 If no Reply message is received within REP_MSG_TIMEOUT milliseconds, 1770 the client retransmits the Decline, doubles the REP_MSG_TIMEOUT 1771 value, and waits again. The client continues this process until a 1772 Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have 1773 been made, at which time the client SHOULD abort the attempt to 1774 decline the address. The client SHOULD return the abort status to 1775 the application, if an application initiated the release. 1777 Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS 1778 are documented in section 7.5. 1780 13.3.10. Receipt of Reply message in response to a Release message 1782 Upon receipt of a valid Reply message, the client can consider the 1783 Release event successful, and SHOULD return the successful status to 1784 the application layer, if an application initiated the release. 1786 13.4. Server Behavior 1788 For this discussion, the Server is assumed to have been configured in 1789 an implementation specific manner with configuration of interest to 1790 clients. 1792 13.4.1. Receipt of Request messages 1794 Upon the receipt of a valid Request message from a client the server 1795 can respond to, (implementation-specific administrative policy 1796 satisfied) the server scans the options field. 1798 The server then constructs a Reply message and sends it to the 1799 client. 1801 The server SHOULD process each option for the client in an 1802 implementation-specific manner. The server MUST construct a Reply 1803 message containing the following values: 1805 msg-type REPLY 1807 preference Enter the servers preference to 1808 provide services to the client. 1810 transaction-ID Enter the transaction-ID from the 1811 Request message. 1813 client-link-local address Enter the client-link-local address 1814 from the Request message. 1816 server address Enter the IP address of the server. 1818 When the server receives a Request and IA option is included the 1819 client is requesting the configuration of a new IA by the server. 1820 The server MUST take the clients IA and associate a binding for 1821 that client in an implementation-specific manner within the servers 1822 configuration parameter database for DHCP clients. 1824 If the server cannot provide addresses to the client it SHOULD send 1825 back an empty IA to the client with the status field set to Unavail. 1827 If the server can provide addresses to the client it MUST send back 1828 the IA to the client with all fields entered and a status of Success, 1829 and add the IA as a new client binding. 1831 The server adds options to the Reply message for any other 1832 configuration information to be assigned to the client. 1834 13.4.2. Receipt of Confirm messages 1836 Upon the receipt of a valid Confirm message from a client the server 1837 can respond to, (implementation-specific administrative policy 1838 satisfied) the server scans the options field. 1840 The server then constructs a Reply message and sends it to the 1841 client. 1843 The server SHOULD process each option for the client in an 1844 implementation-specific manner. The server MUST construct a Reply 1845 message containing the following values: 1847 msg-type REPLY 1849 preference Enter the servers preference to 1850 provide services to the client. 1852 transaction-ID Enter the transaction-ID from the 1853 Confirm message. 1855 client-link-local address Enter the client-link-local address 1856 from the Confirm message. 1858 server address Enter the server's address. 1860 When the server receives a Confirm and an IA option is included the 1861 client is requesting confirmation that the addresses in the IA are 1862 valid. The server SHOULD locate the clients binding and verify the 1863 information in the IA from the client matches the information stored 1864 for that client. 1866 If the server cannot find a client entry for this IA the server 1867 SHOULD return an empty IA with status set to NoBinding. 1869 If the server finds that the information for the client does not 1870 match what is in the servers records for that client the server 1871 should send back an empty IA with status set to Conf_NoMatch. 1873 If the server finds a match to the Confirm then the server should 1874 send back the IA to the client with status set to success. 1876 13.4.3. Receipt of Renew messages 1878 Upon the receipt of a valid Renew message from a client the server 1879 can respond to, (implementation-specific administrative policy 1880 satisfied) the server scans the options field. 1882 The server then constructs a Reply message and sends it to the 1883 client. 1885 The server SHOULD process each option for the client in an 1886 implementation-specific manner. The server MUST construct a Reply 1887 message containing the following values: 1889 msg-type REPLY 1891 preference Enter the servers preference to 1892 provide services to the client. 1894 transaction-ID Enter the transaction-ID from the 1895 Confirm message. 1897 client-link-local address Enter the client-link-local address 1898 from the Confirm message. 1900 server address Enter the server's address. 1902 When the server receives a Renew and IA option from a client it 1903 SHOULD locate the clients binding and verify the information in the 1904 IA from the client matches the information stored for that client. 1906 If the server cannot find a client entry for this IA the server 1907 SHOULD return an empty IA with status set to NoBinding. 1909 If the server finds that the addresses in the IA for the client do 1910 not match the clients binding the server should return an empty IA 1911 with status set to Renw_NoMatch. 1913 If the server cannot Renew addresses for the client it SHOULD send 1914 back an empty IA to the client with the status field set to Unavail. 1916 If the server finds the addresses in the IA for the client then the 1917 server SHOULD send back the IA to the client with new lease times 1918 and T1/T2 times if the default is not being used, and set status to 1919 Success. 1921 13.4.4. Receipt of Rebind messages 1923 Upon the receipt of a valid Rebind message from a client the server 1924 can respond to, (implementation-specific administrative policy 1925 satisfied) the server scans the options field. 1927 The server then constructs a Reply message and sends it to the 1928 client. 1930 The server SHOULD process each option for the client in an 1931 implementation-specific manner. The server MUST construct a Reply 1932 message containing the following values: 1934 msg-type REPLY 1936 preference Enter the servers preference to 1937 provide services to the client. 1939 transaction-ID Enter the transaction-ID from the 1940 Confirm message. 1942 client-link-local address Enter the client-link-local address 1943 from the Confirm message. 1945 server address Enter the server's address. 1947 When the server receives a Rebind and IA option from a client it 1948 SHOULD locate the clients binding and verify the information in the 1949 IA from the client matches the information stored for that client. 1951 If the server cannot find a client entry for this IA the server 1952 SHOULD return an empty IA with status set to NoBinding. 1954 If the server finds that the addresses in the IA for the client do 1955 not match the clients binding the server should return an empty IA 1956 with status set to Rebd_NoMatch. 1958 If the server cannot Rebind addresses for the client it SHOULD send 1959 back an empty IA to the client with the status field set to Unavail. 1961 If the server finds the addresses in the IA for the client then the 1962 server SHOULD send back the IA to the client with new lease times 1963 and T1/T2 times if the default is not being used, and set status to 1964 Success. 1966 13.4.5. Receipt of Release messages 1968 Upon the receipt of a valid Release message, the server examines the 1969 IAs and the addresses in the IAs for validity. If the IAs in the 1970 message are in a binding for the client and the addresses in the IAs 1971 have been assigned by the server to those IA, the server deletes 1972 the addresses from the IAs and makes the addresses available for 1973 assignment to other clients. 1975 The server then generates a Reply message. If all of the IAs were 1976 valid and the addresses successfully released,, the server sets the 1977 "status" field to "Success". If any of the IAs were invalid or if 1978 any of the addresses were not successfully released, the server 1979 releases none of the addresses in the message and sets the "status" 1980 field to "NoBinding"(section 7.4). 1982 DISCUSSION: 1984 What is the behavior of the server relative to a "partially 1985 released" IA; i.e., an IA for which some but not all 1986 addresses are released? 1988 Can a client send an empty IA to release all addresses in 1989 the IA? 1991 If the IA becomes empty - all addresses are released - can 1992 the server discard any record of the IA? 1994 13.4.6. Sending of Reply messages 1996 If the Request, Confirm, Renew, Rebind or Release message from 1997 the client was originally received by the server, the server 1998 unicasts the Reply message to the link-local address in the 1999 "client-link-local-address" field. 2001 If the message was originally received in a Forward-request or 2002 Forward-release message from a relay, the server places the Reply 2003 message in the options field of a Response-reply message and unicasts 2004 the message to the relay's address from the original message. 2006 14. DHCP Server-Initiated Configuration Exchange 2008 A server initiates a configuration exchange to force DHCP clients 2009 to obtain new addresses and other configuration information. For 2010 example, an administrator may use a server-initiated configuration 2011 exchange when links in the DHCP domain are to be renumbered. Other 2012 examples include changes in the location of directory servers, 2013 addition of new services such as printing, and availability of new 2014 software (system or application). 2016 14.1. Reconfigure-init Message Validation 2018 Agents MUST silently discard any received Reconfigure-init messages. 2020 Clients MUST discard any Reconfigure-init messages that do 2021 not contain an authentication option or that fail the client's 2022 authentication check. 2024 Clients MUST discard any Reconfigure-init messages that contain a 2025 transaction-ID that matches the transaction-ID in a Reconfigure-init 2026 message previously received from the same DHCP server. 2028 14.2. Server Behavior 2030 A server sends a Reconfigure-init message to trigger a client to 2031 initiate immediately a Request/Reply message exchange with the 2032 server. A server may unicast a Reconfigure-init message directly 2033 to a single client or use multicast to deliver a Reconfigure-init 2034 message to multiple clients. 2036 14.2.1. Creation and sending of Reconfigure-init messages 2038 The server sets the "msg-type" field to RECONFIG. The server 2039 generates a transaction-ID and inserts it in the "transaction-ID" 2040 field. The server places its address (of appropriate scope) in the 2041 "server-address" field. 2043 The server MAY include an ORO option to inform the client of what 2044 information has been changed or new information that has been added. 2046 The server MUST include an authentication option with the appropriate 2047 settings and add that option as the last option in the "options" 2048 field of the Reconfigure-init message. 2050 The server MAY include a Reconfigure-delay option in a 2051 Reconfigure-init message to be unicast to a client, and MUST 2052 include a Reconfigure-delay option in a Reconfigure-init message to 2053 be multicast to a group of clients. 2055 The server MUST NOT include any other options in the Reconfigure-init 2056 except as specifically allowed in the definition of individual 2057 options. 2059 The server may either unicast the Reconfigure-init message to one 2060 client or multicast the message to one or more Reconfigure Multicast 2061 Addresses previously sent as options to the clients. The server 2062 may unicast Reconfigure-init messages to more than one client 2063 concurrently; for example, to reliably reconfigure all clients, the 2064 server will unicast a Reconfigure-init message to each client. 2066 If the server unicasts to one or more clients, it waits for a Request 2067 message from those clients confirming that it has received the 2068 Reconfigure-init and are thus initiating a Request/Reply transaction 2069 with the server. The server can determine that a Request message is 2070 in response to a Reconfigure-init because the transaction-ID in the 2071 Request will be the same value as was used in the Reconfigure-init 2072 message. 2074 If the server multicasts the Reconfigure-init message, it must use 2075 some TBD authentication mechanism that can authenticate the server to 2076 multiple clients. There is no reliability mechanism for multicast 2077 Reconfigure-init messages. A server might use multicast in the 2078 case where it does not have a list of its clients; for example, a 2079 server that distributes configuration information to clients using 2080 stateless autoconfiguration might not keep a list of clients it has 2081 communicated with. 2083 DISCUSSION: 2085 Authentication of multicast reconfigure-init is still an 2086 open issue. 2088 See section 18.2 for recommendations on the use of multicast 2089 and unicast Reconfigure-init messages for reliable client 2090 reconfiguration. 2092 14.2.2. Time out and retransmission of unicast Reconfigure-init messages 2094 If the server does not receive a Request message from the client 2095 in RECREP_MSG_TIMEOUT milliseconds, the server retransmits 2096 the Reconfigure-init message, doubles the RECREP_MSG_TIMEOUT 2097 value and waits again. The server continues this process until 2098 REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point 2099 the server SHOULD abort the reconfigure process. 2101 Default and initial values for RECREP_MSG_TIMEOUT and 2102 REC_MSG_ATTEMPTS are documented in section 7.5. 2104 14.2.3. Time out and retransmission of multicast Reconfigure-init 2105 messages 2107 After the server transmits the initial Reconfigure-init message, 2108 the server waits RECREP_MSG_TIMEOUT milliseconds. The server 2109 then retransmits the Reconfigure-init message, doubles the 2110 RECREP_MSG_TIMEOUT value and waits again. The server repeats this 2111 process until a total of REC_MSG_ATTEMPTS Reconfigure-init messages 2112 have been transmitted. 2114 Default and initial values for RECREP_MSG_TIMEOUT and 2115 REC_MSG_ATTEMPTS are documented in section 7.5. 2117 14.2.4. Receipt of Request messages 2119 The server generates and sends Reply message(s) to the client as 2120 described in section 13.4.6, including in the "option" field new 2121 values for configuration parameters. 2123 14.3. Client Behavior 2125 A client MUST always monitor UDP port 546 for Reconfigure-init 2126 messages on interfaces upon which it has acquired DHCP parameters. 2127 Since the results of a reconfiguration event may affect application 2128 layer programs, the client SHOULD log these events, and MAY notify 2129 these programs of the change through an implementation-specific 2130 interface. 2132 14.3.1. Receipt of Reconfigure-init messages 2134 Upon receipt of a valid Reconfigure-init message, the client 2135 initiates a Request/Reply transaction with the server. 2137 14.3.2. Creation and sending of Request messages 2139 When responding to a Reconfigure-init, the client creates and 2140 sends the Request message in exactly the same manner as outlined in 2141 section 13.3.1 with the following differences: 2143 transaction-ID The client copies the 2144 transaction-ID from the 2145 Reconfigure-init message into the 2146 Request message. 2148 IAs The client includes IA options 2149 containing the addresses the client 2150 currently has assigned to those IAs 2151 for the interface through which 2152 the Reconfigure-init message was 2153 received. 2155 Pause before sending Request The client pauses before sending 2156 the Request for a random value 2157 within the range REC_REP_MIN and 2158 REC_REP_MAX seconds. This delay 2159 helps reduce the load on the 2160 server generated by processing 2161 large numbers of triggered 2162 Request messages from a multicast 2163 Reconfigure-init message. 2165 14.3.3. Time out and retransmission of Request messages 2167 The client uses the same variables and retransmission algorithm as it 2168 does with Request messages generated as part of a client-initiated 2169 configuration exchange. See section 13.3.1 for details. 2171 14.3.4. Receipt of Reply messages 2173 Upon the receipt of a valid Reply message, the client extracts the 2174 contents of the "option" field, and sets (or resets) configuration 2175 parameters appropriately. The client records and updates the 2176 lifetimes for any addresses specified in IAs in the Reply message. 2177 If the configuration parameters changed were requested by the 2178 application layer, the client notifies the application layer of the 2179 changes using an implementation-specific interface. 2181 15. Relay Behavior 2183 For this discussion, the Relay may be configured to use a list of 2184 server destination addresses, which may include unicast addresses, 2185 the All DHCP Servers multicast address, or other multicast addresses 2186 selected by the network administrator. If the Relay has not been 2187 explicitly configured, it will use the All DHCP Servers multicast 2188 address as the default. 2190 15.1. Relaying of client messages 2192 When a Relay receives a valid client message, it constructs 2193 a Relay-forward message. The relay places an address from 2194 the interface on which the client message was received in the 2195 "relay-address" field and the prefix length for that address in the 2196 "prefix-length" field. This address will be used by the server to 2197 identify the link to which the client is connected and will be used 2198 by the relay to forward the Advertise message from the server back to 2199 the client. 2201 The relay constructs a "client-message" option 16.4 that contains 2202 the entire message from the client in the data field of the 2203 option. The relay places the "relay-message" option along with any 2204 "relay-specific" options in the options field of the Relay-forward 2205 message. The Relay then sends the Relay-forward message to the list 2206 of server destination addresses that it has been configured with. 2208 15.2. Relaying of server messages 2210 When the relay receives a Relay-reply message, it extracts the server 2211 message from the "server-message" option and forwards the message 2212 to the address in the client-link-local-address field in the server 2213 message. The relay forwards the server message through the interface 2214 identified in the "relay-address" field in the Relay-reply message. 2216 16. DHCP options 2218 Options are used to carry additional information and parameters 2219 in DHCP messages. Every option shares a common base format, as 2220 described in section 16.1. 2222 this document describes the DHCP options defined as part of the base 2223 DHCP specification. Other options may be defined in the future in a 2224 separate document. 2226 16.1. Format of DHCP options 2228 0 1 2 3 2229 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 2230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2231 | option-code | option-len | 2232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2233 | option-data | 2234 | (option-len octets) | 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 option-code An unsigned integer identifying the specific option 2238 type carried in this option. 2240 option-len An unsigned integer giving the length of the data in 2241 this option in octets. 2243 option-data The data for the option; the format of this data 2244 depends on the definition of the option. 2246 16.2. Identity association option 2248 The identity association option is used to carry an identity 2249 association, the parameters associated with the IA and the addresses 2250 assigned to the IA. 2252 The format of the IA option is: 2254 0 1 2 3 2255 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 2256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2257 | OPTION IA | option-len | 2258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2259 | IA DUID | 2260 | (8 octets) | 2261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2262 | T1 | 2263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2264 | T2 | 2265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2266 | IA status | num-addrs | addr status | prefix length | 2267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2268 | | 2269 | IPv6 address | 2270 | (16 octets) | 2271 | | 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 | preferred lifetime | 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2275 | valid lifetime | 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 | addr status | prefix length | | 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2279 | IPv6 address | 2280 | (16 octets) | 2281 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2282 | | preferred lifetime | 2283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2284 | pref. lifetime (cont.) | valid lifetime | 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 | valid lifetime (cont.) | IPv6 address | 2287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2288 | ... | 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 option-code OPTION_IA (1) 2292 option-len Variable; equal to 18 + num-addrs*25 2294 IA DUID The unique identifier for this IA; chosen by the client 2296 T1 The time at which the client contacts the server from 2297 which the addresses in the IA were obtained to extend 2298 the lifetimes of the addresses assigned to the IA. 2300 T2 The time at which the client contacts any available 2301 server to extend the lifetimes of the addresses assigned 2302 to the IA. 2304 IA status Status of the IA in this option. 2306 num-addrs An unsigned integer giving the number of addresses 2307 carried in this IA option (MAY be zero). 2309 addr status Status of this address. 2311 prefix length Prefix length for this address. 2313 IPv6 address An IPv6 address assigned to this IA. 2315 preferred lifetime The preferred lifetime for the associated IPv6 2316 address. 2318 valid lifetime The valid lifetime for the associated IPv6 address. 2320 The "IPv6 address", "preferred lifetime" and "valid lifetime" fields 2321 are repeated for each address in the IA option (as determined by the 2322 "num-addrs" field). 2324 DISCUSSION: 2326 The details of the format and the selection of an IA's DUID 2327 are TBD. 2329 Note that an IA has no explicit "lifetime" or "lease length" of 2330 its own. When the lifetimes of all of the addresses in an IA have 2331 expired, the IA can be considered as having expired. T1 and T2 2332 are included to give servers explicit control over when a client 2333 recontacts the server about a specific IA. 2335 16.3. Option request option 2337 0 1 2 3 2338 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 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 | OPTION_ORO | option-len | 2341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 | requested-option-code-1 | requested-option-code-2 | 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 | ... | 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 option-code OPTION_ORO (2) 2349 option-len Variable; equal to twice the number of option codes 2350 carried in this option. 2352 option-data A list of the option codes for the options requested 2353 in this option. 2355 16.4. Client message option 2357 0 1 2 3 2358 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 2359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2360 | OPTION_CLIENT_MSG | option-len | 2361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2362 | DHCP client message | 2363 | | 2364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2366 option-code OPTION_CLIENT_MSG (3) 2368 option-len Variable; equal to the length of the forwarded DHCP 2369 client message. 2371 option-data The message received from the client; forwarded 2372 verbatim to the server. 2374 16.5. Server message option 2376 0 1 2 3 2377 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 2378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2379 | OPTION_SERVER_MSG | option-len | 2380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2381 | DHCP server message | 2382 | | 2383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 option-code OPTION_SERVER_MSG (4) 2387 option-len Variable; equal to the length of the forwarded DHCP 2388 server message. 2390 option-data The message received from the server; forwarded 2391 verbatim to the client. 2393 16.6. Retransmission parameter option 2395 0 1 2 3 2396 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 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 | OPTION_RETRANS_PARM | option-len | 2399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2400 | option-data | 2401 | (option-len octets) | 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 option-code OPTION_RETRANS_PARM (5) 2406 option-len An unsigned integer giving the length of the data in 2407 this option in octets. 2409 option-data TBD - The details of the operational parameters to be 2410 set in the client 2412 16.7. Reconfigure-delay option 2414 The Reconfigure-delay option specifies the amount of time a client 2415 should delay before sending a Request message in response to a 2416 Reconfigure-init message. 2418 0 1 2 3 2419 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 2420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2421 | OPTION_RECONF_DELAY | option-len | 2422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2423 | minimum delay time (msec) | maximum delay time (msec) | 2424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2426 option-code OPTION_RECONF_DELAY (6) 2428 option-len An unsigned integer giving the length of the data in 2429 this option in octets. 2431 minimum delay time An unsigned integer giving the minimum delay 2432 time in milliseconds 2434 maximum delay time An unsigned integer giving the maximum delay 2435 time in milliseconds 2437 The client chooses a random number between the minimum delay time and 2438 the maximum delay time and delays that number of milliseconds before 2439 sending its Request message. 2441 16.8. DSTM Global IPv4 Address Option 2443 The DSTM Global IPv4 Address Option informs a client or server that 2444 the Identity Association Option (IA) following this option will 2445 contain an IPv4-Mapped IPv6 Address [7] in the case of a Client 2446 receiving the option, or is a Request for an IPv4-Mapped IPv6 Address 2447 from a client in the case of a DHCPv6 Server receiving the option. 2448 The option can also provide an IPv6 address to be used as the Tunnel 2449 Endpoint (TEP) to encapsulate an IPv4 packet within IPv6. 2451 This option can be used with the Request, Reply, and Reconfigure-Init 2452 Messages for cases where a server wants to assign to clients 2453 IPv4-Mapped IPv6 Addresses, thru the Option Request Option (ORO). 2455 0 1 2 3 2456 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 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2458 | OPTION_DSTM | option-length | 2459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2460 | Tunnel End Point (TEP) | 2461 | (If Present) | 2462 | (16 octets) | 2463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2464 option code OPTION_DSTM (7) 2466 option length Variable: 0 or 16 2468 tunnel end point IPv6 Address if Present 2470 A DSTM IPv4 Global Address Option MUST only apply to the IA following 2471 this option. 2473 16.9. Authentication option 2475 The authentication option is TBD. 2477 17. DHCP Client Implementor Notes 2479 This section provides helpful information for the client implementor 2480 regarding their implementations. The text described here is not part 2481 of the protocol, but rather a discussion of implementation features 2482 we feel the implementor should consider during implementation. 2484 17.1. Primary Interface 2486 Since configuration parameters acquired through DHCP can be 2487 interface-specific or more general, the client implementor SHOULD 2488 provide a mechanism by which the client implementation can be 2489 configured to specify which interface is the primary interface. The 2490 client SHOULD always query the DHCP data associated with the primary 2491 interface for non-interface specific configuration parameters. An 2492 implementation MAY implement a list of interfaces which would be 2493 scanned in order to satisfy the general request. In either case, the 2494 first interface scanned is considered the primary interface. 2496 By allowing the specification of a primary interface, the client 2497 implementor identifies which interface is authoritative for 2498 non-interface specific parameters, which prevents configuration 2499 information ambiguity within the client implementation. 2501 17.2. Advertise Message and Configuration Parameter Caching 2503 If the hardware the client is running on permits it, the implementor 2504 SHOULD provide a cache for Advertise messages and a cache of 2505 configuration parameters received through DHCP. Providing these 2506 caches prevents unnecessary DHCP traffic and the subsequent load 2507 this generates on the servers. The implementor SHOULD provide a 2508 configuration knob for setting the amount of time the cache(s) are 2509 valid. 2511 17.3. Time out and retransmission variables 2513 Note that the client time out and retransmission variables outlined 2514 in section 7.5 can be configured on the server and sent to the client 2515 through the use of the "DHCP Retransmission Parameter Option", which 2516 is documented in section 16.6. A client implementation SHOULD be 2517 able to reset these variables using the values from this option. 2519 17.4. Server Preference 2521 A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP 2522 Solicit message to collect Advertise messages and compare their 2523 preferences (see section 18.3), unless it receives an Advertise 2524 message with a preference of 255. If the client receives an 2525 Advertise message with a preference of 255, then the client MAY act 2526 immediately on that Advertise without waiting for any more additional 2527 Advertise messages. 2529 18. DHCP Server Implementor Notes 2531 This section provides helpful information for the server implementor. 2533 18.1. Client Bindings 2535 A server implementation MUST use the IA's DUID and the prefix 2536 specification from which the client sent its Request message(s) as an 2537 index for finding configuration parameters assigned to the client. 2538 While it isn't critical to keep track of the other parameters 2539 assigned to a client, the server MUST keep track of the addresses it 2540 has assigned to an IA. 2542 The server should periodically scan its bindings for addresses whose 2543 leases have expired. When the server finds expired addresses, it 2544 MUST delete the assignment of those addresses, thereby making these 2545 addresses available to other clients. 2547 The client bindings MUST be stored in non-volatile storage. 2549 The server implementation should provide policy knobs to control 2550 whether or not the lifetimes on assigned addresses are renewable, and 2551 by how long. 2553 18.2. Reconfigure-init Considerations 2555 A server implementation MUST provide an interface to the 2556 administrator for initiating reconfigure-init events. 2558 A server implementation may provide a mechanism for allowing the 2559 specification of how many clients comprise a reconfigure multicast 2560 group. This enables the administrator to control the processing load 2561 impact of the multicast of a Reconfigure-init message. 2563 18.2.1. Reliable transmission of multicast Reconfigure-init messages 2565 Because clients will ignore Reconfigure-init messages with the 2566 same transaction-ID, a server can retransmit a Reconfigure-init 2567 message (using the same transaction-ID) without causing any 2568 client to reply more than once. A server SHOULD retransmit a 2569 multicast Reconfigure-init message several times to maximize the 2570 probability that all clients in the multicast group have received the 2571 Reconfigure-init message. 2573 If a server does not receive a Reply message from some clients in a 2574 multicast group, the server MAY choose to unicast a Reconfigure-init 2575 message to those clients. Because the clients may have received the 2576 multicast Reconfigure-init messages while the server did not receive 2577 the clients' Reply messages, the server SHOULD use a different 2578 transaction-ID in the unicast Reconfigure-init messages to trigger 2579 the client to reconfigure. 2581 18.3. Server Preference 2583 The server implementation SHOULD allow the setting of a server 2584 preference value by the administrator. The server preference 2585 variable is an unsigned single octet value (0--255), with the lowest 2586 preference being 0 and the highest 255. Clients will choose higher 2587 preference servers over those with lower preference values. If you 2588 don't choose to implement this feature in your server, you MUST set 2589 the server preference field to 0 in the Advertise messages generated 2590 by your server. 2592 18.4. Request Message Transaction-ID Cache 2594 In order to improve performance, a server implementation MAY include 2595 an in memory transaction-ID cache. This cache is indexed by client 2596 binding and transaction-ID, and enables the server to quickly 2597 determine whether a Request is a retransmission or a new Request 2598 without the cost of a database lookup. If an implementor chooses to 2599 implement this cache, then they SHOULD provide a configuration knob 2600 to tune the lifetime of the cache entries. 2602 19. DHCP Relay Implementor Notes 2604 A relay implementation SHOULD allow the specification of a list of 2605 destination addresses for forwarded messages. This list MAY contain 2606 any mixture of unicast addresses and multicast addresses. 2608 If a relay receives an ICMP message in response to a DHCP message it 2609 has forwarded, it SHOULD log this event. 2611 20. Open Issues for Working Group Discussion 2613 This section contains some items for discussion by the working group. 2615 20.1. Authentication 2617 Authentication is not discussed in this document. Authentication 2618 will be modeled on DHCPv4 authentication. Authentication of 2619 multicast Reconfigure-init messages is a special problem. 2621 20.2. Identification of IAs by servers 2623 Do servers identify an IA just by its DUID or by ? If 2624 just by DUID, are DUIDs guaranteed unique (within the DHCP universe)? 2625 If so, how is that guarantee implemented? 2627 20.3. DHCP-DNS interaction 2629 Interaction among DHCP servers, clients and DNS servers is not 2630 discussed in this document. 2632 20.4. Temporary addresses 2634 How does DHCPv6 interact with temporary addresses? If the server 2635 assigns temporary addresses (e.g., addresses with short lifetimes), 2636 how can a client application choose an temporary address as a source 2637 address in preference to a non-temporary address? 2639 20.5. Use of term "agent" 2641 The term "agent", taken to mean "relay agent or server", may be 2642 confusing. "relay agent or server" might be clearer. 2644 20.6. Client behavior when response to Rebind is not received 2646 Section 13.3.4 describes several plausible ways in which a client 2647 might respond when it does not receive a Reply to a Rebind message. 2648 The acceptable client behaviors need to be defined and described 2649 in 13.3.4. 2651 20.7. Additional options 2653 Which additional options should be included in this base spec 2654 document? 2656 20.8. Operational parameters 2658 Should servers have an option to set operational parameters - 2659 retransmission timeouts, number of retries - in clients? 2661 21. Security 2663 This document references an "authentication option" which is TBD. 2665 DISCUSSION: 2667 Based on the discussion of security issues at the 8/31/00 2668 design team teleconference and subsequent DHC WG mailing 2669 list discussion, DHCPv6 will use the security model from 2670 DHCPv4, as described in draft-ietf-dhc-authentication-16.txt 2671 (which is soon to be an RFC). 2673 22. Year 2000 considerations 2675 Since all times are relative to the current time of the transaction, 2676 there is no problem within the DHCPv6 protocol related to any 2677 hardcoded dates or two-digit representation of the current year. 2679 23. IANA Considerations 2681 This document defines message types TBD to be received by UDP at port 2682 numbers 546 and 547. Additional message types may be defined in the 2683 future. 2685 Section 7.1 lists several multicast addresses used by DHCP. 2687 This document also defines several status codes that are to be 2688 returned with the Reply message (see section 9.7). The non-zero 2689 values for these status codes which are currently specified are shown 2690 in the table in section 7.4. 2692 There is a DHCPv6 option described in section 16.6, which allows 2693 clients and servers to exchange values for some of the timing 2694 and retransmission parameters defined in section 7.5. Adding new 2695 parameters in the future would require extending the values by which 2696 the parameters are indicated in the DHCP option. Since there needs 2697 to be a list kept, the default values for each parameter should also 2698 be stored as part of the list. 2700 All of these protocol elements may be specified to assume new values 2701 at some point in the future. New values should be approved by the 2702 process of IETF Consensus [9]. 2704 24. Acknowledgments 2706 Thanks to the DHC Working Group for their time and input into the 2707 specification. Ralph Droms and Thomas Narten have had a major 2708 role in shaping the continued improvement of the protocol by their 2709 careful reviews. Many thanks to Matt Crawford, Erik Nordmark, Gerald 2710 Maguire, and Mike Carney for their studied review as part of the 2711 Last Call process. Thanks also for the consistent input, ideas, and 2712 review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov 2713 Rekhter, Matt Thomas, Sue Thomson, and Phil Wells. 2715 Thanks to Steve Deering and Bob Hinden, who have consistently 2716 taken the time to discuss the more complex parts of the IPv6 2717 specifications. 2719 A. Comparison between DHCPv4 and DHCPv6 2721 This appendix is provided for readers who will find it useful to see 2722 a model and architecture comparison between DHCPv4 [6, 1] and DHCPv6. 2723 There are three key reasons for the differences: 2725 o IPv6 inherently supports a new model and architecture for 2726 communications and autoconfiguration of addresses. 2728 o DHCPv6 benefits from the new IPv6 features. 2730 o New features were added to support the expected evolution and 2731 the existence of more complicated Internet network service 2732 requirements. 2734 IPv6 Architecture/Model Changes: 2736 o The link-local address permits a node to have an address 2737 immediately when the node boots, which means all clients have a 2738 source IP address at all times to locate an on-link server or 2739 relay. 2741 o The need for BOOTP compatibility and the broadcast flag have been 2742 removed. 2744 o Multicast and address scoping in IPv6 permit the design of 2745 discovery packets that would inherently define their range by the 2746 multicast address for the function required. 2748 o Stateful autoconfiguration has to coexist and integrate with 2749 stateless autoconfiguration supporting Duplicate Address 2750 Detection and the two IPv6 lifetimes, to facilitate the dynamic 2751 renumbering of addresses and the management of those addresses. 2753 o Multiple addresses per interface are inherently supported in 2754 IPv6. 2756 o Some DHCPv4 options are unnecessary now because the configuration 2757 parameters are either obtained through IPv6 Neighbor Discovery or 2758 the Service Location protocol [14]. 2760 DHCPv6 Architecture/Model Changes: 2762 o The message type is the first octet in the packet. 2764 o IPv6 Address allocations are now handled in a message option as 2765 opposed to the message header. 2767 o Client/Server bindings are now mandatory and take advantage of 2768 the client's link-local address to always permit communications 2769 either directly from an on-link server, or from a off-link server 2770 through an on-link relay. 2772 o Servers are discovered by a client Solicit, followed by a server 2773 Advertise message 2775 o The client will know if the server is on-link or off-link. 2777 o The on-link relay may locate off-link server addresses from 2778 system configuration or by the use of a site-wide multicast 2779 packet. 2781 o ACKs and NAKs are not used. 2783 o The server assumes the client receives its responses unless it 2784 receives a retransmission of the same client request. This 2785 permits recovery in the case where the network has faulted. 2787 o Clients can issue multiple, unrelated Request messages to the 2788 same or different servers. 2790 o The function of DHCPINFORM is inherent in the new packet design; 2791 a client can request configuration parameters other than IPv6 2792 addresses in the optional option headers. 2794 o Clients MUST listen to their UDP port for the new Reconfigure 2795 message from servers. 2797 o New options have been defined. 2799 With the changes just enumerated, we can support new user features, 2800 including 2802 o Configuration of Dynamic Updates to DNS 2803 o Address deprecation, for dynamic renumbering. 2805 o Relays can be preconfigured with server addresses, or use of 2806 multicast. 2808 o Authentication 2810 o Clients can ask for multiple IP addresses. 2812 o Addresses can be reclaimed using the Reconfigure-init message. 2814 o Integration between stateless and stateful address 2815 autoconfiguration. 2817 o Enabling relays to locate off-link servers. 2819 B. Full Copyright Statement 2821 Copyright (C) The Internet Society (2001). All Rights Reserved. 2823 This document and translations of it may be copied and furnished to 2824 others, and derivative works that comment on or otherwise explain it 2825 or assist in its implementation may be prepared, copied, published 2826 and distributed, in whole or in part, without restriction of any 2827 kind, provided that the above copyright notice and this paragraph 2828 are included on all such copies and derivative works. However, 2829 this document itself may not be modified in any way, such as by 2830 removing the copyright notice or references to the Internet Society 2831 or other Internet organizations, except as needed for the purpose 2832 of developing Internet standards in which case the procedures 2833 for copyrights defined in the Internet Standards process must be 2834 followed, or as required to translate it into languages other than 2835 English. 2837 The limited permissions granted above are perpetual and will not be 2838 revoked by the Internet Society or its successors or assigns. 2840 This document and the information contained herein is provided on an 2841 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2842 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2843 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2844 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2845 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2847 C. Changes in this draft 2849 This section describes the changes between this version of the DHCPv6 2850 specification and draft-ietf-dhc-dhcpv6-16.txt. 2852 C.1. New messages for confirming addresses and extending the lease on an 2853 IA 2855 Four new messages, DHCP Confirm, DHCP Renew, DHCP Rebind and DHCP 2856 Decline, have been added and are described in section 13. Client 2857 behavior - when and how to send these new messages - and server 2858 behavior - how to respond to each - has been defined. The message 2859 type codes for these messages have been added to section 7.3. 2861 C.2. New message formats 2863 Section 9 has been restructured to include only one copy of the DHCP 2864 message header, because now all the messages have the same header 2865 format. Descriptions of the use of header fields in the Confirm, 2866 Renew, Rebind and Decline messages have been added to 9. 2868 C.3. Renamed Server-forward message 2870 Section 10.2 has been renamed "relay-reply" for consistency with the 2871 rest of the document 2873 C.4. Clarified relay forwarding of messages 2875 Added text to sections on relay behavior to clarify encapsulation and 2876 decapsulation of client messages in Relay-forward and Relay-reply 2877 messages. 2879 C.5. Addresses and options in Advertise messages 2881 Modified section 12.4.2 so that servers include addresses to be 2882 assigned and other options in Advertise messages. Also added text to 2883 section 12.3.1 to disallow option values (except as noted in option 2884 definitions) in Solicit messages. 2886 C.6. Clarification of IA option format 2888 Changed the label of the prefix length field in an IA option to 2889 "prefix length" in the option format diagram, and moved the prefix 2890 before the address for consistency with relay messages and other IPv6 2891 protocols. 2893 C.7. Specification of transaction ID in Solicit message 2895 Add text (which was missing) to specify the insertion of a 2896 transaction ID in Solicit messages. 2898 C.8. Edits to definitions 2900 Some of the definitions in section 6 have been edited for clarity. 2902 C.9. Relay agent messages 2904 The formats of relay agent messages are now described in a separate 2905 section, 10. 2907 C.10. Relay agent behavior 2909 The behavior of relay agents for all client and server messages is 2910 now described in a single section, 15. 2912 C.11. Transmission of all client messages through relays 2914 All client messages are now multicast to the All Agents multicast 2915 address and forwarded by relays as appropriate. 2917 C.12. Reconfigure-init messages 2919 Client behavior in response to a Reconfigure-init messages has 2920 been extended to accommodate receipt of multiple copies of a 2921 Reconfigure-init message due to duplicate messages or retransmission. 2923 Server use of multicast Reconfigure-init has been specified. 2925 Hints about use of multicast and unicast for reliable reconfiguration 2926 have been added to server implementor's hints. 2928 C.13. Ordering of sections 2930 Several sections have been re-ordered for clarity. 2932 C.14. DSTM option 2934 The DSTM option has been added (section 16.8). 2936 C.15. Message and option numbering 2938 (In rev -18) Replaced TBD for message and option code numbering with 2939 names and temporary values. 2941 C.16. Inclusion of IAs in Solicit message by client 2943 Added text to section 12.3.1 explaining that clients include empty 2944 IA(s) in a Solicit message and to section 12.3.3 explaining that 2945 server advertises addresses in client IAs. 2947 C.17. Clarification of destination of client messages 2949 Added text to section 13 clarifying the destination (specific server 2950 or any available server) of client messages 2952 C.18. Clarification of client use of Confirm messages 2954 Changed text in section 13.3.2 to correctly describe behavior of 2955 clients in response to Replay messages from servers. 2957 References 2959 [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 2960 Extensions. Request for Comments (Draft Standard) 2132, 2961 Internet Engineering Task Force, March 1997. 2963 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 2964 Levels. Request for Comments (Best Current Practice) 2119, 2965 Internet Engineering Task Force, March 1997. 2967 [3] S. Bradner and A. Mankin. The Recommendation for the IP Next 2968 Generation Protocol. Request for Comments (Proposed Standard) 2969 1752, Internet Engineering Task Force, January 1995. 2971 [4] W. J. Croft and J. Gilmore. Bootstrap Protocol. Request for 2972 Comments 951, Internet Engineering Task Force, September 1985. 2974 [5] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 2975 Specification. Request for Comments (Draft Standard) 2460, 2976 Internet Engineering Task Force, December 1998. 2978 [6] R. Droms. Dynamic Host Configuration Protocol. Request for 2979 Comments (Draft Standard) 2131, Internet Engineering Task Force, 2980 March 1997. 2982 [7] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 2983 Request for Comments (Proposed Standard) 2373, Internet 2984 Engineering Task Force, July 1998. 2986 [8] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for 2987 IP version 6. Request for Comments (Proposed Standard) 1981, 2988 Internet Engineering Task Force, August 1996. 2990 [9] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 2991 Considerations Section in RFCs. Request for Comments (Best 2992 Current Practice) 2434, Internet Engineering Task Force, October 2993 1998. 2995 [10] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 2996 IP Version 6 (IPv6). Request for Comments (Draft Standard) 2997 2461, Internet Engineering Task Force, December 1998. 2999 [11] D. C. Plummer. Ethernet Address Resolution Protocol: Or 3000 converting network protocol addresses to 48.bit Ethernet address 3001 for transmission on Ethernet hardware. Request for Comments 3002 (Standard) 826, Internet Engineering Task Force, November 1982. 3004 [12] J. Postel. User Datagram Protocol. Request for Comments 3005 (Standard) 768, Internet Engineering Task Force, August 1980. 3007 [13] S. Thomson and T. Narten. IPv6 Stateless Address 3008 Autoconfiguration. Request for Comments (Draft Standard) 2462, 3009 Internet Engineering Task Force, December 1998. 3011 [14] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 3012 Location Protocol. Request for Comments (Proposed Standard) 3013 2165, Internet Engineering Task Force, June 1997. 3015 [15] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic 3016 Updates in the Domain Name System (DNS UPDATE). Request for 3017 Comments (Proposed Standard) 2136, Internet Engineering Task 3018 Force, April 1997. 3020 Chair's Address 3022 The working group can be contacted via the current chair: 3024 Ralph Droms 3025 Cisco Systems 3026 300 Apollo Drive 3027 Chelmsford, MA 01824 3029 Phone: (978) 244-4733 3030 E-mail: rdroms@cisco.com 3032 Author's Address 3034 Questions about this memo can be directed to: 3036 Jim Bound 3037 Nokia Networks 3038 5 Wayside Road 3039 Burlington, MA 01803 3040 USA 3041 Phone: +1-781-492-6010 3042 Email: jim.bound@nokia.com 3044 Mike Carney 3045 Sun Microsystems, Inc 3046 Mail Stop: UMPK17-202 3047 901 San Antonio Road 3048 Palo Alto, CA 94303-4900 3049 USA 3050 Phone: +1-650-786-4171 3051 Email: mwc@eng.sun.com 3053 Charles E. Perkins 3054 Communications Systems Lab 3055 Nokia Research Center 3056 313 Fairchild Drive 3057 Mountain View, California 94043 3058 USA 3059 Phone: +1-650 625-2986 3060 EMail: charliep@iprg.nokia.com 3061 Fax: +1 650 625-2502