idnits 2.17.1 draft-ietf-dhc-dhcpv6-15.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: ---------------------------------------------------------------------------- ** 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 15 longer pages, the longest (page 51) being 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([15]), 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 407: '... source ports MAY be arbitrary, clie...' RFC 2119 keyword, line 422: '...are reserved and MUST be silently igno...' RFC 2119 keyword, line 547: '...ecific variables MAY be configured on ...' RFC 2119 keyword, line 571: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 572: '... SHOULD NOT, RECOMMENDED, MAY, and O...' (122 more instances...) -- The draft header indicates that this document obsoletes draft-ietf-dhc-dhcpv6-14.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-14.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 (5 May 2000) is 8750 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) -- Missing reference section? '15' on line 2571 looks like a reference -- Missing reference section? '14' on line 2568 looks like a reference -- Missing reference section? '2' on line 2519 looks like a reference -- Missing reference section? '7' on line 2538 looks like a reference -- Missing reference section? '6' on line 2534 looks like a reference -- Missing reference section? '8' on line 2542 looks like a reference -- Missing reference section? '3' on line 2523 looks like a reference -- Missing reference section? '12' on line 2559 looks like a reference -- Missing reference section? '17' on line 2579 looks like a reference -- Missing reference section? '10' on line 2550 looks like a reference -- Missing reference section? '13' on line 2563 looks like a reference -- Missing reference section? '9' on line 2546 looks like a reference -- Missing reference section? '4' on line 2527 looks like a reference -- Missing reference section? '11' on line 2554 looks like a reference -- Missing reference section? '1' on line 2515 looks like a reference -- Missing reference section? '16' on line 2575 looks like a reference -- Missing reference section? '5' on line 2531 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force J. Bound 2 INTERNET DRAFT Compaq Computer Corp. 3 DHC Working Group M. Carney 4 Obsoletes: draft-ietf-dhc-dhcpv6-14.txt Sun Microsystems, Inc 5 C. Perkins 6 Nokia Research Center 7 5 May 2000 8 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 9 draft-ietf-dhc-dhcpv6-15.txt 10 Status of This Memo 12 This document is a submission by the Dynamic Host Configuration 13 Working Group of the Internet Engineering Task Force (IETF). Comments 14 should be submitted to the dhcp-v6@bucknell.edu mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 Abstract 36 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables 37 DHCP servers to pass configuration parameters using extensions to 38 IPv6 nodes. It offers the capability of automatic allocation of 39 reusable network addresses and additional configuration flexibility. 40 This protocol is a stateful counterpart to ``IPv6 Stateless Address 41 Autoconfiguration'' [15], and can be used separately or concurrently 42 with the latter to obtain configuration parameters. 44 Contents 45 Status of This Memo i 47 Abstract i 49 1. Introduction 1 51 2. Terminology 2 52 2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2 53 2.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 3 55 3. DHCP Constants 5 56 3.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 5 57 3.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.3. DHCP message types . . . . . . . . . . . . . . . . . . . 6 59 3.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 8 60 3.4.1. Generic Error Values . . . . . . . . . . . . . . 8 61 3.4.2. Server-specific Error Values . . . . . . . . . . 8 62 3.5. Configuration Variables . . . . . . . . . . . . . . . . . 8 64 4. Requirements 9 66 5. Background 9 68 6. Design Goals 11 70 7. Non-Goals 11 72 8. Overview 12 73 8.1. How does a node know to use DHCP? . . . . . . . . . . . . 12 74 8.2. How does a client find out about DHCP agents? . . . . . . 12 75 8.3. What if the client and server(s) are on different links? 12 76 8.4. How does a client request configuration parameters from 77 servers? . . . . . . . . . . . . . . . . . . . . . . . 13 78 8.5. What are releasable resources, and when are they used? . 13 79 8.6. Can a client release its releasable resources before the lease 80 expires? . . . . . . . . . . . . . . . . . . . . . . . 14 81 8.7. What if the client determines its releasable resource is 82 already being used by another client? . . . . . . . . 14 83 8.8. How are clients notified of server configuration changes? 14 85 9. Message Formats 15 86 9.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 15 87 9.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 16 88 9.3. DHCP Request Message Format . . . . . . . . . . . . . . . 18 89 9.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 19 90 9.5. DHCP Release Message Format . . . . . . . . . . . . . . . 20 91 9.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 22 92 9.7. DHCP Reconfigure-reply Message Format . . . . . . . . . . 23 93 9.8. DHCP Reconfigure-init Message Format . . . . . . . . . . 24 95 10. DHCP Server Solicitation and Subnet Prefix Discovery 25 96 10.1. Solicit Message Validation . . . . . . . . . . . . . . . 25 97 10.2. Advertise Message Validation . . . . . . . . . . . . . . 25 98 10.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 26 99 10.3.1. Creation and sending of the Solicit message . . . 26 100 10.3.2. Time out and retransmission of Solicit Messages . 27 101 10.3.3. Receipt of Advertise messages . . . . . . . . . . 27 102 10.4. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 28 103 10.4.1. Relaying of Solicit messages . . . . . . . . . . 28 104 10.4.2. Relaying of Advertise messages . . . . . . . . . 28 105 10.5. Server Behavior . . . . . . . . . . . . . . . . . . . . . 28 106 10.5.1. Receipt of Solicit messages . . . . . . . . . . . 28 107 10.5.2. Creation and sending of Advertise messages . . . 29 109 11. DHCP Client-Initiated Configuration Exchange 29 110 11.1. Request Message Validation . . . . . . . . . . . . . . . 29 111 11.2. Reply Message Validation . . . . . . . . . . . . . . . . 30 112 11.3. Release Message Validation . . . . . . . . . . . . . . . 31 113 11.4. Client Behavior . . . . . . . . . . . . . . . . . . . . . 31 114 11.4.1. Creation and sending of Request messages . . . . 32 115 11.4.2. Time out and retransmission of Request Messages . 33 116 11.4.3. Receipt of Reply message in response to a Request 33 117 11.4.4. Creation and sending of Release messages . . . . 33 118 11.4.5. Time out and retransmission of Release Messages . 34 119 11.4.6. Receipt of Reply message in response to a Release 35 120 11.5. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 35 121 11.5.1. Relaying of Request or Release messages . . . . . 35 122 11.6. Server Behavior . . . . . . . . . . . . . . . . . . . . . 35 123 11.6.1. Receipt of Request messages . . . . . . . . . . . 35 124 11.6.2. Receipt of Release messages . . . . . . . . . . . 36 125 11.6.3. Creation and sending of Reply messages . . . . . 36 127 12. DHCP Server-Initiated Configuration Exchange 37 128 12.1. Reconfigure Message Validation . . . . . . . . . . . . . 37 129 12.2. Reconfigure-reply Message Validation . . . . . . . . . . 38 130 12.3. Reconfigure-init Message Validation . . . . . . . . . . . 38 131 12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 38 132 12.4.1. Creation and sending of Reconfigure messages . . 39 133 12.4.2. Time out and retransmission of Reconfigure 134 messages . . . . . . . . . . . . . . . . . 40 135 12.4.3. Receipt of Reconfigure-reply messages . . . . . . 40 136 12.4.4. Creation and sending of Reconfigure-init messages 40 137 12.4.5. Time out and retransmission of Reconfigure-init 138 messages . . . . . . . . . . . . . . . . . 41 139 12.4.6. Receipt of Request messages . . . . . . . . . . . 41 140 12.5. Client Behavior . . . . . . . . . . . . . . . . . . . . . 41 141 12.5.1. Receipt of Reconfigure messages . . . . . . . . . 42 142 12.5.2. Creation and sending of Reconfigure-reply messages 42 143 12.5.3. Receipt of Reconfigure-init messages . . . . . . 43 144 12.5.4. Creation and sending of Request messages . . . . 43 145 12.5.5. Time out and retransmission of Request messages . 43 146 12.5.6. Receipt of Reply messages . . . . . . . . . . . . 43 148 13. Using DHCP for network renumbering 43 149 13.1. Passive Renumbering . . . . . . . . . . . . . . . . . . . 44 150 13.2. Active Renumbering . . . . . . . . . . . . . . . . . . . 44 152 14. DHCP Client Implementator Notes 44 153 14.1. Primary Interface . . . . . . . . . . . . . . . . . . . . 45 154 14.2. Advertise Message and Configuration Parameter Caching . . 45 155 14.3. Time out and retransmission variables . . . . . . . . . . 45 156 14.4. Server Preference . . . . . . . . . . . . . . . . . . . . 45 158 15. DHCP Server Implementator Notes 46 159 15.1. Client Bindings . . . . . . . . . . . . . . . . . . . . . 46 160 15.2. Reconfigure Considerations . . . . . . . . . . . . . . . 46 161 15.3. Server Preference . . . . . . . . . . . . . . . . . . . . 46 162 15.4. Request Message Transaction-ID Cache . . . . . . . . . . 47 164 16. DHCP Relay Implementator Notes 47 166 17. Open Issues for Working Group Discussion 47 167 17.1. Trade-offs: Optional fields in DHCP messages . . . . . . 47 168 17.2. Use DHCPv4 authentication or the current DHCPv6 method? . 48 169 17.3. The Reconfigure Message and Subnet Prefix Extensions . . 48 170 17.4. ``R'' bit in Request message not needed? . . . . . . . . 48 172 18. Security Considerations 48 174 19. Year 2000 considerations 49 176 20. IANA Considerations 49 178 21. Acknowledgements 50 180 A. Comparison between DHCPv4 and DHCPv6 50 182 B. Full Copyright Statement 52 184 Chair's Address 55 185 Author's Address 55 186 1. Introduction 188 This document describes DHCP for IPv6 (DHCP), a UDP [14] client / 189 server protocol designed to reduce the cost of management of IPv6 190 nodes in environments where network managers require more control 191 over the allocation of network resources more varied than that 192 offered by ``IPv6 Stateless Autoconfiguration'' [15]. The DHCP is a 193 stateful counterpart to stateless autoconfiguration. Note that both 194 stateful and stateless autoconfiguration can be used concurrently in 195 the same environment, leveraging the strengths of both mechanisms 196 in order to reduce the cost of ownership and management of network 197 nodes. 199 The DHCP reduces the cost of ownership by centralizing the management 200 of network resources such as IP addresses, routing information, OS 201 installation information, directory service information, and other 202 such information on a few DHCP servers, rather than distributing such 203 information in local configuration files among each network node. 204 The DHCP is designed to be easily extended to carry new configuration 205 parameters through the addition of new DHCP ``extensions'' defined to 206 carry this information. See this document's companion specification, 207 ``Extensions for the Dynamic Host Configuration Protocol for 208 IPv6'' [2] for specifications of existing extensions as well as 209 information on the process by which an interested party might specify 210 new extensions. 212 Those readers familiar with DHCP for IPv4 [7] will find DHCP for IPv6 213 provides a superset of features, and benefits from the additional 214 features of IPv6 and freedom from BOOTP [5]-backward compatibility 215 constraints. For more information about the differences between DHCP 216 for IPv6 and DHCP for IPv4, see Appendix A. 218 This document is organized as follows. Section 2 defines terminology 219 used throughout this document. Section 3 defines constant values 220 used by DHCP. Section 4 briefly discusses requirement levels. 221 Section 5 points the reader to helpful background specifications 222 covering related IPv6 protocols. Section 6 discusses the design 223 goals that influenced DHCP. Section 7 identifies some of the 224 non-goals of this specification. Section 8 gives a high level 225 overview of DHCP, its message types, and identifies DHCP functional 226 entities (client, relay, server). Section 9 describes in detail the 227 format of each DHCP message type. Section 10 discusses DHCP server 228 solicitation and subnet prefix discovery. Section 11 discusses DHCP 229 client-initiated configuration information exchange. Section 12 230 discusses DHCP server-initiated configuration information exchange. 231 Section 13 describes how DHCP can be used to renumber networks. 232 Section 14 presents helpful notes for DHCP client implementators. 233 Section 15 presents helpful notes for DHCP server implementors. 235 Section 16 presents helpful notes for DHCP relay implementors. 236 Section 18 discusses security considerations for DHCP. 237 2. Terminology 239 2.1. IPv6 Terminology 241 IPv6 terminology relevant to this specification from the IPv6 242 Protocol [6], IPv6 Addressing Architecture [8], and IPv6 Stateless 243 Address Autoconfiguration [15] is included below. 245 address An IP layer identifier for an interface or a set of 246 interfaces. 248 unicast address 249 An identifier for a single interface. A packet sent 250 to a unicast address is delivered to the interface 251 identified by that address. 253 multicast address 254 An identifier for a set of interfaces (typically 255 belonging to different nodes). A packet sent to a 256 multicast address is delivered to all interfaces 257 identified by that address. 259 host Any node that is not a router. 261 IP Internet Protocol Version 6 (IPv6). The terms IPv4 and 262 IPv6 are used only in contexts where it is necessary to 263 avoid ambiguity. 265 interface 266 A node's attachment to a link. 268 link A communication facility or medium over which nodes 269 can communicate at the link layer, i.e., the layer 270 immediately below IP. Examples are Ethernet (simple or 271 bridged); Token Ring; PPP links, X.25, Frame Relay, or 272 ATM networks; and Internet (or higher) layer "tunnels", 273 such as tunnels over IPv4 or IPv6 itself. 275 link-layer identifier 276 a link-layer identifier for an interface. Examples 277 include IEEE 802 addresses for Ethernet or Token Ring 278 network interfaces, and E.164 addresses for ISDN links. 280 link-local address 281 An IP address having link-only scope, indicated by 282 having the subnet prefix (FE80::0000/64), that can be 283 used to reach neighboring nodes attached to the same 284 link. Every interface has a link-local address. 286 message A unit of data carried in a packet, exchanged between 287 DHCP agents and clients. 289 neighbor A node attached to the same link. 291 node A device that implements IP. 293 packet An IP header plus payload. 295 prefix A bit string that consists of some number of initial 296 bits of an address. 298 router A node that forwards IP packets not explicitly 299 addressed to itself. 300 2.2. DHCP Terminology 302 Terminology specific to DHCP can be found below. 303 abort status 304 A status value returned to the application that has 305 invoked a DHCP client operation, indicating anything 306 other than success. 308 agent address 309 The address of a neighboring DHCP Agent on the same 310 link as the DHCP client. 312 binding A binding (or, client binding) is a group of server 313 data records indexed by containing the releasable resource data 315 which a DHCP server has assigned to a client. 317 Note that the transaction-ID from the Request message 318 that produced the assignment of the releasable resource 319 is also stored in the server data record including the 320 releasable resource identifier. 322 DHCP Dynamic Host Configuration Protocol for IPv6. The 323 terms DHCPv4 and DHCPv6 are used only in contexts where 324 it is necessary to avoid ambiguity. 326 configuration parameter 327 An element of the configuration information set on the 328 server and delivered to the client using DHCP. Such 329 parameters may be used to carry information to be used 330 by a node to configure its network subsystem and enable 331 communication on a link or internetwork, for example. 333 DHCP client (or client) 334 A node that initiates requests on a link to obtain 335 configuration parameters from one or more DHCP servers. 337 DHCP domain 338 A chunk of network topology managed by DHCP and 339 operated by a single administrative entity. 341 DHCP server (or server) 342 A server is a node that responds to requests from 343 clients, and may or may not be on the same link as the 344 client(s). 346 DHCP relay (or relay) 347 A node that acts as an intermediary to deliver DHCP 348 messages between clients and servers, and is on the 349 same link as a client. 351 DHCP agent (or agent) 352 Either a DHCP server on the same link as a client, or a 353 DHCP relay. 355 Releasable resource 356 Any configuration resource allocated by a server for 357 a finite period of time. As of this writing, the 358 only example of such a resource is the IP address. 359 Releasable resources are carried in extensions 360 allocated out of the 1--8192 range. 362 solicit-ID 363 An unsigned integer generated by the client and 364 inserted into its DHCP Solicit messages, and echoed 365 back to the client by the server in its resultant DHCP 366 Advertise message(s). The client uses the solicit-ID 367 to match received Advertise messages to Solicit 368 messages it has generated. 370 transaction-ID 371 An unsigned integer to match responses with replies 372 initiated either by a client or server. Servers 373 allocate their transaction-IDs from the range of 374 0--1023, and clients allocate their transaction-IDs 375 from the range of 1024--65535. Limiting clients and 376 servers to different ranges prevents transaction-ID 377 collisions (e.g. client and server happen to use the 378 same transaction-ID for unrelated transactions (e.g. 379 client Request, server Reconfigure-init). 380 3. DHCP Constants 382 This section describes various program and networking constants used 383 by DHCP. 384 3.1. Multicast Addresses 386 The DHCP makes use of the following multicast addresses: 388 All DHCP Agents address: FF02::1:2 389 This link-local multicast address is used by clients to 390 communicate with the on-link agent(s) when they do not 391 know those agents' link-local address(es). All agents 392 (servers and relays) are members of this multicast 393 group. 395 All DHCP Servers address: FF05::1:3 396 This site-local multicast address is used by clients or 397 relays to communicate with server(s), either because 398 they want to send messages to all servers or because 399 they do not know the server(s) unicast address(es). 400 Note that in order for a client to use this address, 401 it must have an address of sufficient scope to be 402 reachable by the server(s). All servers within the 403 site are members of this multicast group. 404 3.2. UDP ports 406 The DHCP uses the following destination UDP [14] port numbers. While 407 source ports MAY be arbitrary, client implementations SHOULD permit 408 their specification through a local configuration parameter to 409 facilitate the use of DHCP through firewalls. 411 546 Client port. Used by agents to send messages to 412 clients. Also used by servers to send messages to 413 relays. 415 547 Agent port. Used by clients to send messages to 416 agents. Also used by relays to send messages to 417 servers. 418 3.3. DHCP message types 420 The DHCP defines the following message types. More detail on these 421 message types can be found in Section 9. Message types 0 and 9--255 422 are reserved and MUST be silently ignored. 424 01 DHCP Solicit 426 The DHCP Solicit (or Solicit) message is used by clients to 427 locate servers and (optionally) learn about the subnet prefixes 428 on the client's link for networks that are managed by DHCP. 429 This message is multicast using the All-DHCP-Agents address. 430 Relay(s) forward Solicits as necessary to off-link servers. 432 Section 9.1 contains more details about the Solicit message. 434 02 DHCP Advertise 436 The DHCP Advertise (or Advertise) message is used by servers 437 responding to Solicits. This message is unicast to the 438 client's link-local address (if the server and client are 439 on the same link) or unicast to the relay through which the 440 Solicit was sent for final delivery to the client. 442 Section 9.2 contains more details about the Advertise message. 444 03 DHCP Request 446 The DHCP Request (or Request) message is used by clients to 447 request configuration parameters from servers. This message 448 is unicast to the server if the client has an address with 449 sufficient scope to be reachable by the server, otherwise it 450 is unicast to the on-link relay through which the Advertise 451 message was relayed. 453 Section 9.3 contains more details about the Request message. 455 04 DHCP Reply 457 The DHCP Reply (or Reply) message is used by servers responding 458 to Request and Release messages. In the case of responding to 459 a Request message, the Reply contains configuration parameters 460 destined for the client. This message is unicast to the client 461 if the client has an address of sufficient scope that is 462 reachable by the server. Otherwise, it is unicast to the relay 463 through which the Request or Release message was sent for final 464 delivery to the client. 466 Section 9.4 contains more details about the Reply message. 468 05 DHCP Release 470 The DHCP Release (or Release) message is used by clients to 471 return one or more instances of releasable resources (e.g. IP 472 addresses) to servers. This message is unicast to the server 473 if the client will have an address of sufficient scope after 474 the Release operation to receive a Reply message. Otherwise, 475 the Release message is sent through the relay. The server will 476 acknowledge the receipt of the Release message by sending the 477 client a Reply message. 479 Section 9.5 contains more details about the Release message. 481 06 DHCP Reconfigure 483 The DHCP Reconfigure (or Reconfigure) message is sent by 484 servers to client(s). It contains new or updated configuration 485 parameters for use by the client(s). This message may be 486 unicast or multicast to the client(s). 488 Section 9.6 contains more details about the Reconfigure 489 message. 491 07 DHCP Reconfigure-reply 493 The DHCP Reconfigure-reply (or Reconfigure-reply) message is 494 unicast by client(s) to the server to acknowledge the receipt 495 of a Reconfigure message. 497 Section 9.7 contains more details about the Reconfigure-reply 498 message. 500 08 DHCP Reconfigure-init 502 The DHCP Reconfigure-init (or Reconfigure-init) message is set 503 by server(s) to inform client(s) that the server(s) has new or 504 updated configuration parameters, and that the client(s) are 505 to initiate a Request/Reply transaction with the server(s) in 506 order to receive the updated information. 508 Section 9.8 contains more details about the Reconfigure-init 509 message. 511 3.4. Error Values 513 This section describes error values exchanged between DHCP 514 implementations. 515 3.4.1. Generic Error Values 517 The following symbolic names are used between client and server 518 implementations to convey error conditions. The following table 519 contains the actual numeric values for each name. Note that the 520 numeric values do not start at 1, nor are they consecutive. The 521 errors are organized in logical groups. 523 _______________________________________________________________ 524 |_Error_Name___|Error_ID_|Description__________________________| 525 |_Success______|00_______|Success______________________________| 526 |_UnspecFail___|16_______|Failure,_reason_unspecified__________| 527 |_AuthFailed___|17_______|Authentication_failed_or_nonexistent_| 528 |_PoorlyFormed_|18_______|Poorly_formed_message________________| 529 |_Unavail______|19_______|Resources_unavailable________________| 531 3.4.2. Server-specific Error Values 533 The following symbolic names are used by server implementations to 534 convey error conditions to clients. The following table contains the 535 actual numeric values for each name. 536 _______________________________________________________________ 537 |_Error_Name____|Error_ID_|Description_________________________| 538 |_NoBinding_____|20_______|Client_record_(binding)_unavailable_| 539 |_InvalidSource_|21_______|Invalid_Client_IP_address___________| 540 |_NoServer______|23_______|Relay_cannot_find_Server_Address____| 541 |_ICMPError_____|64_______|Server_unreachable_(ICMP_error)_____| 543 3.5. Configuration Variables 545 This section presents a table of client and server configuration 546 variables and the default or initial values for these variables. The 547 client-specific variables MAY be configured on the server and MAY be 548 delivered to the client through the ``DHCP Retransmission Parameter 549 Extension''carried in a Reply message. This extension is documented 550 in the ``extensions document'' [2]. 552 ______________________________________________________________ 553 |_Parameter__________|Default_|Description____________________| 554 |_MIN_SOL_DELAY______|1_______|MIN_(secs)_to_delay_1st_mesg___| 555 |_MAX_SOL_DELAY______|5_______|MAX_(secs)_to_delay_1st_mesg___| 556 |_ADV_MSG_TIMEOUT____|500_____|SOL_Retrans_timer_(msecs)______| 557 |_ADV_MSG_MAX________|30______|MAX_timer_value_(secs)_________| 558 |_SOL_MAX_ATTEMPTS___|-1______|MAX_attempts_(-1_=_infinite)___| 559 |_REP_MSG_TIMEOUT____|250_____|REQ_Retrans_timer_(msecs)______| 560 |_REQ_MSG_ATTEMPTS___|10______|MAX_Request_attempts___________| 561 |_REL_MSG_ATTEMPTS___|5_______|MAX_Release_attempts___________| 562 |_RECREP_MSG_TIMEOUT_|2000____|Retrans_timer_(msecs)__________| 563 |_REC_MSG_ATTEMPTS___|10______|Reconfigure_attempts___________| 564 |_REC_REP_MIN________|5_______|Minimum_pause_interval_(secs)__| 565 |_REC_REP_MAX________|7200____|Maximum_pause_interval_(secs)__| 566 |_REC_THRESHOLD______|100_____|%_of_required_clients__________| 567 |_SRVR_PREF_WAIT_____|2_______|Advertise_Collect_timer_(secs)_| 569 4. Requirements 571 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 572 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 573 document, are to be interpreted as described in [3]. 575 This document also makes use of internal conceptual variables 576 to describe protocol behavior and external variables that an 577 implementation must allow system administrators to change. The 578 specific variable names, how their values change, and how their 579 settings influence protocol behavior are provided to demostrate 580 protocol behavior. An implementation is not required to have them in 581 the exact form described here, so long as its external behavior is 582 consistent with that described in this document. 583 5. Background 585 Related work in IPv6 that would best serve an implementor to study 586 is the IPv6 Specification [6], the IPv6 Addressing Architecture [8], 587 IPv6 Stateless Address Autoconfiguration [15], IPv6 Neighbor 588 Discovery Processing [12], and Dynamic Updates to DNS [17]. These 589 specifications enable DHCP to build upon the IPv6 work to provide 590 both robust stateful autoconfiguration and autoregistration of DNS 591 Host Names. 593 The IPv6 Specification provides the base architecture and design of 594 IPv6. A key point for DHCP implementors to understand is that IPv6 595 requires that every link in the Internet have an MTU of 1280 octets 596 or greater (in IPv4 the requirement is 68 octets). This means that 597 a UDP packet of 536 octets will always pass through an internetwork 598 (less 40 octets for the IPv6 header), as long as there are no IP 599 options prior to the UDP header in the packet. But, IPv6 does not 600 support fragmentation at routers, so that fragmentation takes place 601 end-to-end between hosts. If a DHCP implementation needs to send a 602 packet greater than 1500 octets it can either fragment the UDP packet 603 into fragments of 1500 octets or less, or use Path MTU Discovery [10] 604 to determine the size of the packet that will traverse a network 605 path. 607 DHCP clients use Path MTU discovery when they have an address of 608 sufficient scope to reach the DHCP server. If a DHCP client does not 609 have such an address, that client MUST fragment its packets if the 610 resultant message size is greater than the minimum 1280 octets. 612 Path MTU Discovery for IPv6 is supported for both UDP and TCP and 613 can cause end-to-end fragmentation when the PMTU changes for a 614 destination. 616 The IPv6 Addressing Architecture specification [8] defines the 617 address scope that can be used in an IPv6 implementation, and the 618 various configuration architecture guidelines for network designers 619 of the IPv6 address space. Two advantages of IPv6 are that support 620 for multicast is required, and nodes can create link-local addresses 621 during initialization. This means that a client can immediately use 622 its link-local address and a well-known multicast address to begin 623 communications to discover neighbors on the link. For instance, a 624 client can send a Solicit message and locate a server or relay. 626 IPv6 Stateless Address Autoconfiguration [15] (Addrconf) specifies 627 procedures by which a node may autoconfigure addresses based on 628 router advertisements [12], and the use of a valid lifetime to 629 support renumbering of addresses on the Internet. In addition the 630 protocol interaction by which a node begins stateless or stateful 631 autoconfiguration is specified. The DHCP is one vehicle to perform 632 stateful autoconfiguration. Compatibility with addrconf is a design 633 requirement of DHCP (see Section 6). 635 IPv6 Neighbor Discovery [12] is the node discovery protocol in IPv6 636 which replaces and enhances functions of ARP [13]. To understand 637 IPv6 and Addrconf it is strongly recommended that implementors 638 understand IPv6 Neighbor Discovery. 640 Dynamic Updates to DNS [17] is a specification that supports the 641 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 642 the dynamic updates to DNS to integrate addresses and name space 643 to not only support autoconfiguration, but also autoregistration 644 in IPv6. The security model to be used with DHCPv6 should conform 645 as closely as possible to the authentication model outlined in 646 RFC2402 [9]. 648 6. Design Goals 650 - DHCP is a mechanism rather than a policy. Network administrators 651 set their administrative policies through the configuration 652 parameters they place upon the DHCP servers in the DHCP domain 653 they're managing. DHCP is simply used to deliver parameters 654 according to that policy to each of the DHCP clients within the 655 domain. 657 - DHCP is compatible with IPv6 stateless autoconf [15]. 659 - DHCP does not require manual configuration of network parameters 660 on DHCP clients, except in cases where such configuration is 661 needed for security reasons. A node configuring itself using 662 DHCP should require no user intervention. 664 - DHCP does not require a server on each link. To allow for scale 665 and economy, DHCP must work across DHCP relays. 667 - DHCP coexists with statically configured, non-participating nodes 668 and with existing network protocol implementations. 670 - DHCP clients can operate on a link without IPv6 routers present. 672 - DHCP will provide the ability to renumber network(s) when 673 required by network administrators [4]. 675 - A DHCP client can make multiple, different requests for 676 configuration parameters when necessary from one or more DHCP 677 servers at any time. DHCP will provide enough information 678 to enable a DHCP server to keep track of a DHCP client's 679 configuration state. 681 - DHCP will contain the appropriate time out and retransmission 682 mechanisms to efficiently operate in environments with high 683 latency and low bandwidth characteristics. 684 7. Non-Goals 686 This specification explicitly does not cover the following: 688 - Specification of a DHCP server to server protocol. 690 - How a DHCP server stores its DHCP data. 692 - How to manage a DHCP domain or DHCP server. 694 - How a DHCP relay is configured or what sort of information it may 695 log. 696 8. Overview 698 This section provides a general overview of the interaction 699 between the functional entities of DHCP. The overview is organized 700 as a series of questions and answers. Details of DHCP such 701 as message formats and retransmissions are left to sections 9, 702 10, 11, 12, 14, 15, and 16. 703 8.1. How does a node know to use DHCP? 705 An unconfigured node determines that it is to use DHCP for 706 configuration of an interface by detecting the presence (or absence) 707 of routers on the link. If router(s) are present, the node examines 708 router advertisements to determine if DHCP should be used to 709 configure the interface. If there are no routers present, then 710 the node MUST use DHCP to configure the interface. Detail on 711 this process can be found in neighbor discovery [12] and stateless 712 autoconfiguration [15]. 713 8.2. How does a client find out about DHCP agents? 715 The client forms a Solicit message, and multicasts it to the 716 FF02::1:2(All DHCP Agents) address. Server(s) receiving the Solicit 717 respond with Advertise message(s). If requested in the client's 718 Solicit message, the Advertise message(s) can include one or more 719 subnet prefix extensions [2], informing the client of subnet prefixes 720 for the networks(s) managed by the server(s) on the client's link. 721 Now that the client knows the IP address(es) of agents(s) on the 722 link, it can request configuration parameters from servers. 723 8.3. What if the client and server(s) are on different links? 725 Use of DHCP in such environments requires one or more DHCP relays 726 be set up on the client's link, because a client may only have a 727 link-local address. Relays pick up the Solicit and Request messages 728 from the client and forward them to some set of servers within the 729 DHCP domain. A relay will include one of its own addresses (of 730 sufficient scope) of the interface on the same link as the client. 731 The relay also includes the subnet prefix length of that address 732 in the client's messages. Servers receiving the forwarded traffic 733 use this information to aid in selecting configuration parameters 734 appropriate to the client's link. The servers also use the relay's 735 address as the destination to forward client-destined messages 736 for final delivery by the relay. Relays forward client messages 737 to servers using some combination of the FF05::1:3(All Servers) 738 site-local multicast address, some other (perhaps a combination) 739 of site-local multicast addresses set up within the DHCP domain to 740 include the servers in that domain, or a list of unicast addresses 741 for servers. The network administrator makes relay configuration 742 decisions based upon the topological requirements (scope) of the 743 DHCP domain they are managing. Note that if the DHCP domain spans 744 more than the site-local scope, then the relays MUST be configured 745 with global addresses for the client's link so as to be reachable by 746 servers outside the relays' site-local environment. 747 8.4. How does a client request configuration parameters from servers? 749 To request configuration parameters, the client forms a Request 750 message, and sends it to the server either directly (client has an 751 address of sufficient scope) or indirectly (through the on-link 752 relay). The client MAY include a Extension Request Extension [2] 753 along with other extensions to request specific information from the 754 server. Note that the client MAY form multiple Request messages 755 and send each of them to different servers to request potentially 756 different information (perhaps based upon what was advertised) in 757 order to satisfy its needs. As a client's needs may change over time 758 (perhaps based upon an application's requirements), the client may 759 form additional Request messages to request additional information as 760 it is needed. 762 The server(s) respond with Reply messages containing the requested 763 configuration parameters, which can include status information 764 regarding the information requested by the client. The Reply MAY 765 also include additional information, such as a reconfiguration event 766 multicast group for the client to join to monitor reconfiguration 767 events, as described in section 8.8. 769 The receipt of a Reply from a server concludes the basic 770 request/reply transaction of the protocol. 771 8.5. What are releasable resources, and when are they used? 773 A releasable resource is configuration information leased to a client 774 by a server for some finite period of time. When negotiating for a 775 releasable resource, the client and server agree upon a finite period 776 of time the client may use the resource. The client MAY request a 777 renewal of the lease on the resource at any time. The length of time 778 of the lease (and whether it is renewable) are server-based policy 779 tunables. The client MUST stop using the resource when the lease on 780 the resource expires. The server MUST NOT reallocate an assigned 781 resource before either its lease expires or the client releases the 782 resource. 784 See the ``extensions document'' [2] for more information about 785 releasable resources. 786 8.6. Can a client release its releasable resources before the lease 787 expires? 789 A client forms a Release message, including extensions carrying the 790 resource(s) to be released. The client sends the Release to the 791 server which leased the resource(s) to the client initially. If that 792 server cannot be reached after a certain number of attempts (see 793 section 3.5), the client can abandon the Release attempt. In this 794 case, the resource(s) will be reclaimed by the server(s) when the 795 client's lease(s) expire. 796 8.7. What if the client determines its releasable resource is already 797 being used by another client? 799 If the client determines through a releasable resource-specific 800 manner that the resource it was assigned by the server is already 801 in use by another client, the client will form a Release message, 802 including the extension carrying the in-use resource. The 803 extension's status field MUST be set to the extension-specific value 804 reflecting the ``in use'' status of the resource. 806 For example, if the releasable resource is an IP address, the client 807 uses Duplicate Address Detection (DAD) to verify that the IP address 808 is not in use. If the client determines that the IP address is 809 already in use, it forms a Release message including the IP address 810 extension containing the appropriate status value and sends it to the 811 server. See the ``extensions document''for details on the IP address 812 extension. [2]. 813 8.8. How are clients notified of server configuration changes? 815 There are two possibilities. Either the clients discover the new 816 information when they revisit the server(s) to request additional 817 configuration information / renew the lease on a releasable resource, 818 or through a server-initiated event known as a reconfigure event. 820 The reconfiguration feature of DHCP offers network administrators 821 the opportunity to update configuration information on DHCP clients 822 whenever necessary. If the information to be updated is not 823 client-specific, the server will form a Reconfigure message and add 824 the new or changed configuration information to it. The Reconfigure 825 may be unicast or multicast (to a preassigned multicast address for 826 this purpose) to one or more client(s) to which the new or updated 827 information needs to be directed. The client(s) will acknowledge the 828 receipt of the Reconfigure message by forming a Reconfigure-reply 829 message and unicasting it to the server. If the configuration 830 information change is different for each client (e.g. a change in 831 subnet prefix, perhaps, which would affect the IP address releasable 832 resource(s)), the server will form a Reconfigure-init message and 833 unicast / multicast as needed to the client(s). A Reconfigure-init 834 is a trigger which will cause the client(s) to initiate a standard 835 Request/Reply exchange with the server in order to acquire the new or 836 updated resources. 837 9. Message Formats 839 All reserved fields in a message MUST be transmitted as zeroes and 840 ignored by the receiver of the message. 841 9.1. DHCP Solicit Message Format 843 A client multicasts a DHCP Solicit message to the FF02::1:2(All DHCP 844 agents) address over the interface to be configured to locate one or 845 more servers which are configured to provide configuration parameters 846 to nodes on the client's link. 848 Unless otherwise noted, the value of all fields are set by the 849 client. 851 0 1 2 3 852 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 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | msg-type = 1 |C|P| reserved | prefix-len | solicit-ID | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | client's link-local address | 857 | (16 octets) | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | relay-address | 860 | (16 octets) | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 C If set, the client requests that all servers receiving 863 the message deallocate the releasable resources (e.g. 864 IP addresses) associated with the client's binding. 866 P If set, the client requests that all servers receiving 867 the message SHOULD return a list of subnet prefix 868 extensions identifying the networks on the client's 869 link that the server(s) are configured to manage. 871 reserved 0 873 prefix-len 874 An unsigned 7 bit number (0-127) non-zero prefix-len is 875 the number of leftmost bits of the agent's IPv6 address 876 which make up the subnet prefix. The prefix-len field 877 is set by the relay if the relay receives the Solicit 878 message and forwards it to one or more servers. 880 solicit-ID 881 An unsigned 9 bit number (0-511) generated by the 882 client used to identify this Solicit message. 884 client's link-local address 885 The IP link-local address of the client interface 886 through which the client will issue the Solicit 887 message. 889 relay-address 890 Set by the client to be zero. If received by a relay, 891 set by the relay to the site-local IP address of the 892 interface on which the relay received the client's 893 Solicit message. Note that if the DHCP domain crosses 894 site boundaries, the relay MUST place a globally-scoped 895 address in this field. 897 A client MUST send the Solicit message to the All-DHCP-Agents 898 multicast group (see section 3.1), setting the relay-address to zero. 899 9.2. DHCP Advertise Message Format 901 A server sends an Advertise message in response to a client's 902 Solicit message. The Advertise message notifies the client of the 903 server's IP address. If the server is so configured by the network 904 administrator and the client requests it through the ``P'' bit in 905 its Solicit message, the server SHOULD add a list of subnet prefix 906 extensions to the Advertise message to notify the client of the 907 networks it manages on the client's link. 909 When the client and server are on different links, the server sends 910 the Advertise message back through the relay whence the corresponding 911 Solicit came. The solicit-ID is copied from the client's Solicit 912 Message. The value of all fields in the Advertise message are filled 913 in by the server and not changed in any way by any intervening relay. 915 0 1 2 3 916 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 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | msg-type = 2 | reserved | solicit-ID | preference | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | client's link-local address | 921 | (16 octets) | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | relay-address | 924 | (16 octets) | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | server-address | 927 | (16 octets) | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | extensions (variable number and length) ... | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 reserved 0 933 solicit-ID An unsigned 9 bit number (0-511) used to identify 934 this Advertise message. Copied from the client's 935 Solicit message. 937 preference An octet (unsigned) indicating a server's willingness 938 to provide service to the client. 940 client's link-local address 941 The IP link-local address of the client interface 942 from which the client issued the Solicit message. 944 relay-address 945 The IP address of the relay interface on the same 946 link as the client. Copied from the client's 947 Solicit. If the server is on the same link as the 948 client, then this field MUST be zero. 950 server-address 951 The site-local IP address of the server. If the DHCP 952 domain crosses site boundaries, then this address 953 MUST be globally-scoped. 955 extensions See the ``extensions document'' for details [2]. 957 See Sections 14.4 and 15.3 for information about how clients and 958 servers handle the preference field. 960 9.3. DHCP Request Message Format 962 A client sends a Request message to request configuration parameters 963 from a server. It MAY append appropriate extensions [2]. 965 When a client reboots, it often does not have a valid IP address of 966 sufficient scope for the server to communicate with the client. In 967 such cases, the client MUST NOT unicast the message to the server 968 because the server could not return a response to the client. The 969 client MUST send the message to the server indirectly, by using the 970 on-link relay. The client MUST fill in the relay address field with 971 the on-link relay's IP address. 973 If the Request message is being formed in response to a 974 Reconfigure-init message from the server, then the transaction ID 975 used must be copied from the Reconfigure-init. 977 All fields in the DHCP Request message are entered by the client. 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | msg-type = 3 |C|R| reserved | transaction-ID | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | client's link-local address | 985 | (16 octets) | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | relay-address | 988 | (16 octets) | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | server-address | 991 | (16 octets) | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | extensions (variable number and length) .... | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 C If set, the client requests the server to remove 996 all releasable resources associated with the client 997 binding, except those releasable resources provided as 998 extensions. 1000 R If set, the client has rebooted and requests that the 1001 server clear any transaction-ID cache entries for the 1002 client. 1004 reserved 0 1005 transaction-ID 1006 An unsigned integer identifier used to identify this 1007 request. 1009 client's link-local address 1010 The link-local address of the client interface from 1011 which the client will issue the Request message. 1013 relay-address 1014 The IP address of a relay's interface, copied from an 1015 Advertise message. If the server is on the same link 1016 as the client, then this field MUST BE zero. 1018 server-address 1019 The IP address of the server to which the the client's 1020 Request message is directed, copied from an Advertise 1021 message. 1023 extensions 1024 See the ``extensions document'' [2]. 1026 A DHCP client selects the transaction-ID from the range of 1027 1024--65535 used to identify its Request. In contrast, a 1028 transaction-ID from the range of 0--1023is selected by a DHCP server 1029 to identify a Reconfigure-init. In the latter case, the transaction 1030 ID from the Reconfigure-init is copied by the client into its Request 1031 message. 1033 When the client sets the `C' bit and adds extensions documenting 1034 the releasable resources the client wishes to keep, the server is 1035 expected to deallocate all other releasable resources not listed. 1036 The server SHOULD examine the included extensions to check whether 1037 the client is still authorized to use them. 1038 9.4. DHCP Reply Message Format 1040 A server sends a Reply message in response to a client's Request 1041 message or Release message. 1043 If a Request message is received which contains a non-zero relay 1044 address field, then the client could not unicast the Request message 1045 to the server and thus had to use a on-link relay. In that case, the 1046 server unicasts the Reply message to the relay address found in the 1047 Request message. 1049 If a Release message is received which contains a non-zero relay 1050 address field, then the client will not have an IP address of 1051 sufficient scope after the Release to receive the Reply message. In 1052 this case, the server unicasts the Reply message to the relay address 1053 found in the Release message. 1055 All the fields in the DHCP Reply message are set by the DHCP server. 1057 0 1 2 3 1058 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 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | msg-type = 4 |R| status | transaction-ID | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | client's link-local address | 1063 | (16 octets) | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | relay-address (if present) | 1066 | (16 octets) | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | extensions (variable number and length) .... | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 R If set, the ``relay-address'' field is present. 1072 status 1073 This 7-bit field contains one of the values in the 1074 errors table in section 3.4. 1076 transaction-ID 1077 Copied from the client's Request or Release. 1079 client's link-local address 1080 Copied from the client's Request or Release message. 1082 relay-address 1083 The IP address of a relay's interface, copied from the 1084 Request or Release message. If the server is on the 1085 same link as the client, then the ``R'' bit is not set 1086 and this field is not present. 1088 extensions 1089 See the ``extensions document'' [2]. 1090 9.5. DHCP Release Message Format 1092 A client sends a Release message to a server when it wishes to return 1093 one or more releasable resources to the server which allocated 1094 them. This can occur either because the client no longer needs the 1095 resource(s) or the client has determined through a resource-specific 1096 manner that the resource(s) are already in use by different 1097 client(s). The client communicates the reason for the premature 1098 release of the resource in the status field of the resource's 1099 extension. See ``extensions document'' [2] for more details. 1101 When a client sends a Release message, it needs to have a valid IP 1102 address with sufficient scope to allow access by the target server. 1103 If such an address is not available, a relay is used. Only those 1104 releasable resources identified by extensions are released. If no 1105 extensions are included in the Release message, then all releasable 1106 resources associated with the client's binding are to be released. 1108 The values of all fields of the Release message are set by the 1109 client. The DHCP server acknowledges the Release message by sending 1110 a Reply message. 1112 0 1 2 3 1113 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 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | msg-type = 5 |R| reserved | transaction-ID | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | client's link-local address | 1118 | (16 octets) | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | server-address | 1121 | (16 octets) | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | X-address | 1124 | (16 octets) | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | extensions (variable number and length) .... | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 R If set, the ``X-address'' field contains the address of 1129 relay. If not set, the ``X-address'' field contains a 1130 non-local scope client address. 1132 reserved 0 1134 transaction-ID 1135 An unsigned integer identifier used to identify this 1136 Release message. 1138 client's link-local address 1139 The client's link-local address for the interface 1140 from which the client issued the Release message (and 1141 to which the releasable resources are bound at the 1142 server). 1144 server-address 1145 The IP address of the server which allocated the 1146 resource. 1148 X-address 1149 If the ``R'' bit is set, the ``X-address'' field 1150 contains the IP address of the relay interface on the 1151 same link as the client. If the ``R'' bit is not set, 1152 this field contains a non-link-local IP address of the 1153 client interface from which the the client issued the 1154 Release message. 1156 extensions See the ``extensions document'' [2]. 1158 A client selects the transaction-ID from the range of 1159 1024--65535 used to identify the Release message. 1161 A client MUST NOT specify an IP address in the client-address field 1162 that it is releasing in the extensions field. 1163 9.6. DHCP Reconfigure Message Format 1165 A server sends a Reconfigure message when it wishes to inform one or 1166 more clients of new or updated values for configuration parameters. 1167 The new configuration parameters are carried in the extensions 1168 portion of the Reconfigure message. Note that a Reconfigure message 1169 MUST NOT carry releasable resource extensions. 1171 Reconfigure messages can ONLY be sent to clients which have 1172 established an IP address of sufficient scope as to be directly 1173 reachable by the server. 1175 Clients acknowledge Reconfigure messages with Reconfigure-reply 1176 messages. 1178 0 1 2 3 1179 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 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | msg-type = 6 | reserved | transaction-ID | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | server-address | 1184 | (16 octets) | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 | extensions (variable number and length) .... | 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 reserved 0 1189 transaction-ID 1190 An unsigned integer identifier in the range of 1191 0--1023 chosen by the server to identify this 1192 Reconfigure message. 1194 server-address 1195 The IP address of the DHCP server issuing the 1196 Reconfigure message. MUST be of sufficient scope to be 1197 reachable by all clients. 1199 extensions 1200 See the ``extensions document'' [2]. 1201 9.7. DHCP Reconfigure-reply Message Format 1203 A client sends a Reconfigure-reply message to acknowledge receipt of 1204 a Reconfigure message from a server. 1206 A Reconfigure-reply message can only be sent if the client has an IP 1207 address of sufficient scope to contact the server. No interaction 1208 with a relay is possible. 1210 All fields in the DHCP Reconfigure-reply message are entered by the 1211 client. 1213 0 1 2 3 1214 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 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | msg-type = 7 |r| status | transaction-ID | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | client's link-local address | 1219 | (16 octets) | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | server-address | 1222 | (16 octets) | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 r reserved (0) 1226 status 1227 This 7-bit field contains one of the values from the 1228 errors table in section 3.4. 1230 transaction-ID 1231 An unsigned integer identifier copied from the server's 1232 Reconfigure message. 1234 client's link-local address 1235 The client's link-local address for the interface from 1236 which the client issued the Reconfigure-reply message. 1238 server-address 1239 Copied from the Reconfigure message. 1240 9.8. DHCP Reconfigure-init Message Format 1242 A server sends a Reconfigure-init message when it wishes to notify 1243 one or more clients of new or updated values for configuration 1244 parameters available on the server. 1246 Reconfigure-init messages can ONLY be sent to clients which have 1247 established an IP address of sufficient scope as to be directly 1248 reachable by the server. 1250 A ``Reconfigure-init'' serves as a trigger which will cause the 1251 clients to initiate a Request/Reply exchange with the server in order 1252 to receive the new information. 1254 0 1 2 3 1255 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 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | msg-type = 8 | reserved | transaction-ID | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | server-address | 1260 | (16 octets) | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | extensions (variable number and length) .... | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 reserved 0 1266 transaction-ID 1267 An unsigned integer identifier in the range of 1268 0--1023 chosen by the server to identify this 1269 Reconfigure-init message. 1271 server-address 1272 The IP address of the DHCP server issuing the 1273 Reconfigure-init message. MUST be of sufficient scope 1274 to be reachable by all clients. 1276 extensions SHOULD only include an ERE and/or authentication 1277 extensions. No configuration information SHOULD be 1278 included. See the ``extensions document'' [2] for more 1279 information about extensions. 1280 10. DHCP Server Solicitation and Subnet Prefix Discovery 1282 This section describes how a client locates agents (relays and 1283 servers) and how it can learn about the networks on its link that are 1284 managed by these servers. The behavior of client, server, and relay 1285 implementations is discussed, along with the messages they use. 1286 10.1. Solicit Message Validation 1288 Clients MUST silently discard any received Solicit messages. 1290 Agents MUST discard any received Solicit messages if the ``client's 1291 link-local address'' field does not contain a valid link-local 1292 address. 1294 Servers MUST discard each received Solicit message which meet the 1295 following criteria: 1297 o The ``relay-address'' field does not contain an address of 1298 sufficient scope that is reachable by the server. 1300 o The ``relay-address'' field is non-zero, but prefix-len is zero. 1302 An error message MAY be logged by the agent. The logging of 1303 such messages SHOULD be controlled by an agent implementation 1304 configuration flag. 1305 10.2. Advertise Message Validation 1307 Servers MUST silently discard any received Advertise messages. 1309 Clients MUST discard any Advertise messages that meet any of the 1310 following criteria: 1312 o The ``Solicit-ID'' field value does not match the value the 1313 client used in its Solicit message. 1315 o The ``client's link-local address'' field value does not match 1316 the link-local address of the interface upon which the client 1317 sent the Solicit message. 1319 Relays MUST discard any Advertise messages that meet any of the 1320 following criteria: 1322 o The ``relay-address'' field does not contain the relay's address 1323 on the same link as the client. 1325 o The ``client's link-local address'' field does not contain a 1326 valid link-local address. 1327 10.3. Client Behavior 1329 Clients use the Solicit message primarily to discover DHCP servers 1330 configured to serve networks on the link containing the client. 1331 Optionally, the client MAY set the ``P'' bit which has the effect 1332 of requesting that the server return subnet prefix extensions 1333 identifying the networks on the client's link the server is 1334 configured to manage. 1335 10.3.1. Creation and sending of the Solicit message 1337 When creating a Solicit message, the client SHOULD start out with 1338 a buffer initialized with zeroed octets. The client sets the 1339 ``msg-type'' field to 1, and places the link-local address of the 1340 interface it wishes to configure in the link-local address field. 1342 If the client is prepared to process multiple Advertise messages 1343 in response to its Solicit message, the client will set the 1344 Solicit-ID field to 1. Every time the client initiates a new server 1345 solicitation attempt (not a retransmission), the client increments 1346 the Solicit-ID by one. If the 9-bit field rolls over to 0, then the 1347 client sets the Solicit-ID to 1. A client which will only accept 1348 the first Advertise message it receives leaves the Solicit-ID field 1349 initialized to zero. 1351 The ``C'' bit of the Solicit message is set by the client when the 1352 client has no cached knowledge of previous DHCP configuration for the 1353 interface. Setting this bit requests that the server release any 1354 information assigned to the client for the networks on the client's 1355 link. 1357 If the client desires to learn of the networks managed by DHCP on 1358 the link its interface is attached to, it sets the ``P'' bit in the 1359 Solicit message. 1361 The client transmits the Solicit message to the FF02::1:2 (All DHCP 1362 Agents) multicast address, destination port 547. The source port 1363 selection can be arbitrary, although it SHOULD be possible using a 1364 client configuration facility to set a specific source port value. 1366 10.3.2. Time out and retransmission of Solicit Messages 1368 The client's first Solicit message on the interface MUST be delayed 1369 by a random amount of time between the interval of MIN_SOL_DELAY and 1370 MAX_SOL_DELAY. This random delay desynchronizes clients which start 1371 at the same time (e.g., after a power outage). 1373 The client waits ADV_MSG_TIMEOUT, collecting Advertise messages. 1374 If no Advertise messages are received, the client retransmits 1375 the Solicit, and doubles the ADV_MSG_TIMEOUT value. This process 1376 continues until either one or more Advertise messages are received or 1377 ADV_MSG_TIMEOUT reaches the ADV_MSG_MAX value. Thereafter, Solicits 1378 are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been 1379 made, at which time the client stops trying to DHCP configure the 1380 interface. An event external to DHCP is required to restart the DHCP 1381 configuration process. 1383 Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY, 1384 ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 3.5. 1385 10.3.3. Receipt of Advertise messages 1387 Upon receipt of one or more validated Advertise messages, the client 1388 selects one or more Advertise messages based upon the following 1389 criteria. 1391 - Those Advertise messages with the highest server preference 1392 value (see section 14.4) are preferred over all other Advertise 1393 messages. 1395 - Within a group of Advertise messages with the same server 1396 preference value, a client MAY select those servers whose 1397 Advertise messages advertise information of interest to 1398 the client. For example, one server may be advertising the 1399 availability of IP addresses on networks which have an address 1400 scope of interest to the client. 1402 Once a client has selected Advertise message(s), the client will 1403 typically store information about each server, such as relay address 1404 and prefix length, server preference value, networks advertised, 1405 when the advertisement was received, and so on. Depending on the 1406 requirements of the client's invoking user, the client MAY initiate a 1407 configuration exchange with the server(s) immediately, or MAY defer 1408 this exchange until later. 1410 10.4. Relay Behavior 1412 For this discussion, the Relay is assumed to have been configured 1413 with some list of server destination addresses, which may be unicast, 1414 the FF05::1:3 (All DHCP Servers) multicast address, or some other 1415 multicast address selected by the network administrator. 1416 10.4.1. Relaying of Solicit messages 1418 When a Relay receives a valid Solicit message, it places the IP 1419 address of the interface upon which it received the Solicit message 1420 in the ``relay-address'' field of the Solicit. The Relay also places 1421 the number of bits of that make up the subnet prefix for this address 1422 in the ``prefix-len'' field of the Solicit. 1424 The Relay then forwards this Solicit to the list of server 1425 destination addresses that it has been configured with. 1426 10.4.2. Relaying of Advertise messages 1428 When a Relay receives a valid Advertise message, it unicasts the 1429 message to the link-local address found in the ``client's link-local 1430 address'' field by way of the appropriate network interface. 1431 10.5. Server Behavior 1433 For this discussion, the Server is assumed to have been configured in 1434 an implementation specific manner. This configuration is assumed to 1435 contain all network topology information for the DHCP domain, as well 1436 as any necessary authentication information. 1437 10.5.1. Receipt of Solicit messages 1439 Upon the receipt of a valid Solicit message, the server first 1440 identifies the client's location within the DHCP domain. If the 1441 ``relay-address'' and / or ``prefix-len'' fields of the Solicit are 1442 zeroed, then the client is attached to the same link as the server. 1443 If these fields are non-zero, then the client exists on the same link 1444 as the network identified by these two fields. 1446 If administrative policy permits the server to respond to a client on 1447 that link, the server will generate and send an Advertise message to 1448 the client. 1450 10.5.2. Creation and sending of Advertise messages 1452 When creating an Advertise message, the server SHOULD start out 1453 with a buffer initialized with zeroed octets. The server sets the 1454 ``msg-type'' field to 2 and copies the values of the following fields 1455 from the client's Solicit to the Advertise message: 1457 o solicit-ID 1459 o client's link-local address 1461 o relay-address 1463 The server places one of its IP addresses (determined through 1464 administrator setting) in the ``server-address'' field of the 1465 Advertise message. The server initializes the ``preference'' 1466 field from its configuration information. See section 15.3 for a 1467 description of server preference. 1469 If the client requests subnet prefix extensions (by setting the ``P'' 1470 bit in its Solicit) and the server implements and is configured to 1471 provide prefix extensions, the server will generate and insert a 1472 subnet prefix extension for each network on the client's link it is 1473 configured to manage. 1475 If the ``relay-address'' field of the Advertise message is zero, then 1476 the server unicasts the Advertise message directly to the client 1477 using the ``client's link-local address'' field value as destination 1478 address. If the ``relay-address'' field is non-zero, then the server 1479 unicasts the Advertise message directly to the relay using the 1480 ``relay-address'' field value as the destination address. 1481 11. DHCP Client-Initiated Configuration Exchange 1483 A client initiates a configuration exchange with one or more servers 1484 it has found through DHCP server solicitation whenever requested to 1485 do so by the application layer in order to acquire configuration 1486 information of interest. 1487 11.1. Request Message Validation 1489 Clients MUST silently discard any received Request messages. 1491 Agents MUST discard any Request messages in which the ``client's 1492 link-local address'' field does not contain a valid link-local 1493 address. 1495 Relays MUST discard any received Request messages in which the 1496 ``relay-address'' field value does not match any of the relay's 1497 addresses. 1499 Servers MUST discard any received Request message which meets any of 1500 the following criteria: 1502 o The ``server-address'' field value does not match any of the 1503 server's addresses. 1505 o If the ``relay-address'' field is set, and that field's value 1506 does not contain an address of sufficient scope as to be 1507 reachable by the server. 1509 o The ``extensions'' field contains an authentication extension, 1510 and the server cannot successfully authenticate the client. 1511 11.2. Reply Message Validation 1513 Servers MUST silently discard any received Reply messages. 1515 Clients MUST discard any Reply message that meets any of the 1516 following criteria: 1518 o The ``transaction-ID'' field value does not match the value the 1519 client used in its Request or Release message. 1521 o The ``client's link-local address'' field value does not match 1522 the link-local address of the interface upon which the client 1523 sent in its Request or Release message. 1525 o The Reply message contains an authentication extension, and the 1526 client's attempt to authenticate the message fails. 1528 Relays MUST discard any Reply message that meets any of the following 1529 criteria: 1531 o The ``R'' bit isn't set. 1533 o The ``relay-address'' field value does not contain the relay's 1534 address on the same link as the client. 1536 o The ``client's link-local address'' field value does not contain 1537 a valid link-local address. 1539 11.3. Release Message Validation 1541 Clients MUST silently discard any received Release messages. 1543 Agents MUST discard any Release message that meets any of the 1544 following criteria: 1546 o The ``transaction-ID'' field contains a value not in the 1547 1024--65535 range. 1549 o The ``client's link-local address'' field does not contain a 1550 valid link-local address. 1552 Relays MUST discard any received Release message that meets any of 1553 the following criteria: 1555 o The ``R'' bit is not set. 1557 o The ``X-address'' field value does not match any of the relay's 1558 addresses. 1560 Servers MUST discard any received Release message which meets any of 1561 the following criteria: 1563 o The ``X-address'' field does not contain an address of sufficient 1564 scope as to be reachable by the server. 1566 o The ``extensions'' field contains an authentication extension, 1567 and the server cannot successfully authenticate the client. 1568 11.4. Client Behavior 1570 A client will generate one or more Request messages when prompted by 1571 the application layer in order to acquire configuration information. 1572 A client may initiate such an exchange automatically in order to 1573 acquire the necessary network parameters to communicate with nodes 1574 off-link. The client uses the server and relay address information 1575 from previous Advertise message(s) for use in delivering Request 1576 message(s). Note that a client may request configuration information 1577 from one or more servers at any time. 1579 A client uses the Release message in the management of releasable 1580 resources when: 1582 o The client has determined through a resource-specific manner 1583 that the resource assigned by the server is already in use by a 1584 different client. 1586 o The client has been instructed to release the resource prior to 1587 the lease expiration time since it is no longer needed. 1588 11.4.1. Creation and sending of Request messages 1590 When creating a Request message, the client SHOULD start out with 1591 a buffer initialized with zeroed octets. The client sets the 1592 ``msg-type'' field to 3, and places the link-local address of the 1593 interface it wishes to associate with the configuration information 1594 with in the ``client's link-local address'' field. 1596 Unless the Request message is created in response to a 1597 Reconfigure-init message, the client generates a transaction 1598 ID in the range of 1024--65535 and inserts this value in the 1599 ``transaction-ID'' field. 1601 The client places the address of the destination server in the 1602 ``server-address'' field. 1604 If the client is not on the same link as the destination 1605 server, the client places the appropriate relay's address in the 1606 ``relay-address'' field. 1608 If the client is acquiring configuration information on the interface 1609 for the first time, the client SHOULD set the ``C'' bit in the 1610 header. How the client determines if this is the first configuration 1611 attempt on the interface is implementation-specific. A client may 1612 implement a cache of configuration information on a per-interface 1613 basis; if that cache does not exist, that client would set the 1614 ``C'' bit. Clients which do not implement caching of per-interface 1615 configuration information MUST always set the ``C'', and include 1616 any extensions carrying releasable resources received from earlier 1617 configuration exchanges in the extensions field of the Request. 1619 If the client has determined through an implementation-specific 1620 manner that the client implementation itself has restarted, it MUST 1621 set the ``R'' bit in the header. After the first successful exchange 1622 with the server, the client MUST NOT set the ``R'' bit in subsequent 1623 Request messages. 1625 Client considerations for extensions are now considered (see the 1626 ``extensions document'', [2] for more details). 1628 If the client already has an IP address of sufficient scope to 1629 directly reach the server, then the client SHOULD unicast the Request 1630 to the server. Otherwise, if the server is off-link, the client 1631 unicasts the Request message to the appropriate relay. 1633 11.4.2. Time out and retransmission of Request Messages 1635 The client waits REP_MSG_TIMEOUT milliseconds, collecting 1636 Reply messages. If no Reply messages are received, the client 1637 retransmits the Request with the same transaction-ID, and doubles 1638 the REP_MSG_TIMEOUT value, and waits again. The client continues 1639 this process until a Reply is received or REQUEST_MSG_ATTEMPTS 1640 unsuccessful attempts have been made, at which time the client MUST 1641 abort the configuration attempt. The client SHOULD report the abort 1642 status to the application layer. 1644 Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS 1645 are documented in section 3.5. 1646 11.4.3. Receipt of Reply message in response to a Request 1648 Upon the receipt of a valid Reply message, the client extracts the 1649 configuration information contained in the Reply. If the ``status'' 1650 field contains a non-zero value, the client reports the error status 1651 to the application layer. 1653 If the extensions field contains one or more ``Reconfigure Multicast 1654 Address'' extensions (see ``extensions document'', ``Reconfigure 1655 Multicast Address Extension'' section [2]), the client MUST join 1656 these multicast groups, and MUST monitor the UDP 546 port for 1657 Reconfigure or Reconfigure-init messages on the networks configured 1658 by DHCP. 1660 If the configuration information returned in the Reply contains 1661 releasable resources, then the client MUST take over lease management 1662 of the resource. A client MUST NOT request releasable resources 1663 unless it is prepared to appropriately manage the resource lease. 1664 11.4.4. Creation and sending of Release messages 1666 When creating a Release message, the client SHOULD start out with 1667 a buffer initialized with zeroed octets. The client sets the 1668 ``msg-type'' field to 5, and places the link-local address of the 1669 interface the configuration information it wishes to release is 1670 associated with in the ``client's link-local address'' field. 1672 The client generates a transaction ID in the range of 1673 1024--65535 and inserts this value in the ``transaction-ID'' 1674 field. 1676 The client includes extensions containing the releasable resources it 1677 is releasing in the ``extensions'' field. The appropriate ``status'' 1678 field in the extensions MUST be set to indicate the reason for the 1679 release. 1681 The client places the IP address of the server who allocated the 1682 resource(s) in the ``server-address'' field. 1684 If the client will have an appropriately scoped IP address after the 1685 release transaction is completed, the client clears the ``R'' bit 1686 and places this address in the ``X-address'' field. If the client 1687 will not have an appropriately scoped IP address after the release 1688 transaction is completed, the client sets the ``R'' bit and places 1689 the address of the appropriate relay in the ``X-address'' field. 1691 If the client is configured to use authentication, the client 1692 generates the appropriate authentication extension, and adds this 1693 extension to the ``extensions'' field. Note that the authentication 1694 extension MUST be the last extension in the ``extensions'' 1695 field. See the ``extension document'' for more details about the 1696 authentication extension [2]. 1698 If the ``R'' bit is set, then the client MUST unicast the Release 1699 to the relay indicated in the ``X-address'' field. Otherwise, the 1700 client unicasts the Release message directly to the server indicated 1701 in the ``server-address'' field. 1702 11.4.5. Time out and retransmission of Release Messages 1704 The client waits REP_MSG_TIMEOUT milliseconds, collecting Reply 1705 messages. If no Reply messages are received, the client retransmits 1706 the Release, and doubles the REP_MSG_TIMEOUT value, and waits again. 1707 The client continues this process until a Reply is received or 1708 REL_MSG_ATTEMPTS unsuccessful attempts have been made, at which 1709 time the client SHOULD abort the release attempt. The client 1710 SHOULD return the abort status to the application, if an application 1711 initiated the release. 1713 Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS 1714 are documented in section 3.5. 1716 Note that if the client fails to release the resource, the resource 1717 will be reclaimed by the server when the lease associated with it 1718 expires. 1720 11.4.6. Receipt of Reply message in response to a Release 1722 Upon receipt of a valid Reply message, the client can consider the 1723 Release event successful, and SHOULD return the successful status to 1724 the application layer, if an application initiated the release. 1725 11.5. Relay Behavior 1727 11.5.1. Relaying of Request or Release messages 1729 When a Relay receives a valid Request or Release message, it forwards 1730 it to the IP address found in the ``server-address'' field of the 1731 message. 1732 11.6. Server Behavior 1734 For this discussion, the Server is assumed to have been configured 1735 in an implementation specific manner with configuration of interest 1736 to clients. Such configuration information MAY contain releasable 1737 resources such as IP addresses. 1738 11.6.1. Receipt of Request messages 1740 Upon the receipt of a valid Request message from a client the server 1741 can respond to, (implementation-specific administrative policy 1742 satisfied) the server scans the extensions field. 1744 If the client has set the ``C'' bit, the server MUST release all 1745 releasable resources currently associated with the client's binding 1746 that do not appear in the ``extensions'' field. 1748 If the client has set the ``R'' bit, the server MUST delete any 1749 transaction-ID cache entries it is maintaining for this client, if 1750 the server implements such a cache. 1752 Server considerations for extensions are now evaluated (see the 1753 ``extensions document'', [2] for more details). 1755 If the configuration information to be returned to the client 1756 includes releasable resources, the server checks if a binding 1757 already exists for the client. If so, the server examines the 1758 data records within the binding to determine if the client's 1759 Request is a retransmission of an earlier Request or a new Request. 1760 Releasable resource identifiers are stored within the binding with 1761 the transaction-ID used by the client to request the resource's 1762 assignment. If the transaction-ID's match, this is a retransmission 1763 and the server simply return the contents of the client's binding 1764 which satisfy its request. If the transaction-ID's do not match, 1765 the server records the additional resources it is assigning in the 1766 existing binding with the new Request's transaction-ID. 1768 If the client does not have an existing binding, the server creates a 1769 binding for the client and records the resources it is assigning in 1770 this binding along with the transaction-ID from the client's Request. 1772 The server then constructs a Reply message and sends it to the 1773 client. 1774 11.6.2. Receipt of Release messages 1776 Upon the receipt of a valid Release message, the server performs a 1777 lookup to find the client's binding. If the binding is found, the 1778 server examines the binding to see if the resource(s) identified by 1779 the client in the Release message's extensions field are in fact 1780 assigned to the client. If they are, the server deletes these 1781 resources from the client's binding, making them available to other 1782 clients. 1784 The server then generates a Reply message. If a binding was 1785 found and the resources presented to the server were deleted from 1786 the client's binding, the server sets the ``status'' field to 1787 ``Success''. If no binding is found, the server sets the ``status'' 1788 field to ``NoBinding''(section 3.4). 1789 11.6.3. Creation and sending of Reply messages 1791 When creating a Reply message, the server SHOULD start out with 1792 a buffer initialized with zeroed octets. The server sets the 1793 ``msg-type'' field to 4 and copies the values of the following fields 1794 from the client's Request or Release to the Reply message: 1796 o transaction-ID 1798 o client's link-local address 1800 o If the client's message is a Request with a non-zero 1801 ``relay-address'' field value, the server sets the ``R'' bit in 1802 the Reply and copies the ``relay-address'' field value from the 1803 Request to the Reply. If the client's message is a Release with 1804 the ``R'' bit set, the server sets the ``R'' bit in the Reply and 1805 sets the ``relay-agent'' field to the contents of the Release's 1806 X-address field. 1808 The server sets the ``status'' field appropriately (see the table 1809 in section 3.4) based upon the results of processing the client's 1810 request. 1812 If configured to do so, a server will include ``Reconfigure Multicast 1813 Address'' extensions (see ``extensions document'', ``Reconfigure 1814 Multicast Address Extension'' [2]), in Reply messages sent in 1815 response to a Request, informing the client of one or more multicast 1816 groups it should join to facilitate the receipt of Reconfigure or 1817 Reconfigure-init messages. 1819 If the DHCP domain is using authentication, the server will generate 1820 an authentication extension with the appropriate settings and add 1821 that extension as the last extension in the ``extensions'' field of 1822 the Reply message. 1824 If the ``relay-address'' field of the Reply message is zero, then the 1825 server unicasts the Reply directly to the client using the ``client's 1826 link-local address'' field value as destination address. If the 1827 ``relay-address'' field is non-zero, then the server unicasts the 1828 Reply directly to the relay using the ``relay-address'' field value 1829 as the destination address. 1831 If the server implements a transaction-ID cache, the server would add 1832 an entry for the client to this cache. 1833 12. DHCP Server-Initiated Configuration Exchange 1835 A server initiates a configuration exchange on behalf of the 1836 administrator of the DHCP domain. An administrator may initiate such 1837 an exchange when new networks are added to the domain or existing 1838 networks are to be renumbered. Other examples include changes in 1839 the location of directory servers, addition of new services such as 1840 printing, and availability of new software (system or application). 1841 12.1. Reconfigure Message Validation 1843 Agents MUST silently discard any received Reconfigure messages. 1845 Clients MUST discard any Reconfigure message that meets any of the 1846 following criteria: 1848 o The ``transaction-ID'' field value is not within 1849 the 0--1023 range. 1851 o The Reconfigure message contains an authentication extension, and 1852 the client's attempt to authenticate the message fails. 1854 12.2. Reconfigure-reply Message Validation 1856 Clients and Relays MUST silently discard any received 1857 Reconfigure-reply messages. 1859 Servers MUST discard any Reconfigure-reply message that meets any of 1860 the following criteria: 1862 o The ``transaction-ID'' field value is not that same value the 1863 server used in its Reconfigure message. 1865 o The ``server-address'' field value does not match the value the 1866 server placed in its Reconfigure message. 1867 12.3. Reconfigure-init Message Validation 1869 Agents MUST silently discard any received Reconfigure-init messages. 1871 Clients MUST discard any Reconfigure-init messages that meets any of 1872 the following criteria: 1874 o The ``transaction-ID'' field value is not within 1875 the 0--1023 range. 1877 o The Reconfigure-init message contains an authentication 1878 extension, and the client's attempt to authenticate the message 1879 fails. 1880 12.4. Server Behavior 1882 For this discussion, the server is assumed to have a 1883 implementation-specific interface by which an administrator 1884 may initiate a reconfiguration event with some set of clients. 1886 There are two methods of initiating a reconfiguration event. Each 1887 has its advantages: 1889 Reconfigure with payload 1890 This method uses the Reconfigure message. Items 1891 to be changed are included as extensions in the 1892 ``extensions'' field. This method MUST NOT be used 1893 to reconfigure releasable resources. Examples of 1894 information which can be reconfigured using this 1895 method are DNS domain and servers, NTP servers, other 1896 name service parameters. The server generates and 1897 sends the Reconfigure message; clients respond with 1898 Reconfigure-reply messages. 1900 Reconfigure Trigger 1901 This method uses the Reconfigure-init message. When 1902 a client receives a Reconfigure-init message, it 1903 initiates a Request/Reply exchange with the server. 1904 Any kind of resource can be reconfigured using this 1905 method, including releasable resources. An example 1906 of an releasable resource is an IP address. 1908 A server can send Reconfigure and Reconfigure-init messages only to 1909 those clients who have an address of sufficient scope to be reachable 1910 by the server. Thus, those clients who have not requested an IP 1911 address and are off-link cannot be reconfigured by the server. 1913 Before initiating a reconfigure process, the server SHOULD be 1914 configured with a REC_THRESHOLD threshold value which represents 1915 the percentage of clients successfully reconfigured before the 1916 reconfigure process is considered a success. See section 3.5 for the 1917 default setting of REC_THRESHOLD. Note that the server MUST be able 1918 to determine the set of clients that should receive the reconfigure, 1919 in order to determine when the reconfigure process is complete. 1920 12.4.1. Creation and sending of Reconfigure messages 1922 When creating a Reconfigure message, the server SHOULD start out 1923 with a buffer initialized with zeroed octets. The server sets the 1924 ``msg-type'' field to 6. The server generates a transaction-ID 1925 from the 0--1023 range and inserts it in the ``transaction-ID'' 1926 field. The server places its address (of appropriate scope) in the 1927 ``server-address'' field. 1929 The server then generates extensions for the non-releasable resources 1930 to be changed and places them in the ``extensions'' field. 1932 If the DHCP domain is using authentication, the server will generate 1933 an authentication extension with the appropriate settings and add 1934 that extension as the last extension in the ``extensions'' field of 1935 the Reconfigure message. 1937 The server multicasts the Reconfigure message to one or more 1938 Reconfigure Multicast Addresses previously sent as extensions to the 1939 clients. Note that a server MAY unicast Reconfigure message(s) to 1940 specific clients by walking its list of bindings to determine the 1941 unicast address(es) of the clients. Whether or not the Reconfigure 1942 is multicast or unicast is an implementation detail. 1944 A server waits for Reconfigure-reply messages from clients confirming 1945 that they have received the Reconfigure. 1947 12.4.2. Time out and retransmission of Reconfigure messages 1949 The server waits RECREP_MSG_TIMEOUT milliseconds, collecting 1950 Reconfigure-reply messages. If all the expected Reconfigure-reply 1951 messages are received, then the reconfigure process is successful. 1952 If some or all of the expected Reconfigure-reply messages are not 1953 received, then the server retransmits the Reconfigure, and doubles 1954 the RECREP_MSG_TIMEOUT value, and waits again. The server continues 1955 this process until all Reconfigure-reply messages are received or 1956 REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which time 1957 the server SHOULD abort the reconfigure process. The server SHOULD 1958 log the result of the reconfigure process. 1960 Default and initial values for RECREP_MSG_TIMEOUT and 1961 REC_MSG_ATTEMPTS are documented in section 3.5. 1962 12.4.3. Receipt of Reconfigure-reply messages 1964 Upon receipt of a valid Reconfigure-reply message, the server 1965 removes that client from the list of clients it is expecting a 1966 Reconfigure-reply message from. 1967 12.4.4. Creation and sending of Reconfigure-init messages 1969 When creating a Reconfigure-init message, the server SHOULD start 1970 out with a buffer initialized with zeroed octets. The server sets 1971 the ``msg-type'' field to 8. The server generates a transaction-ID 1972 from the 0--1023 range and inserts it in the ``transaction-ID'' 1973 field. The server places its address (of appropriate scope) in the 1974 ``server-address'' field. 1976 The server MAY generate an ERE extension to inform the client of what 1977 information has been changed or new information that has been added. 1979 If the DHCP domain is using authentication, the server will generate 1980 an authentication extension with the appropriate settings and add 1981 that extension as the last extension in the ``extensions'' field of 1982 the Reconfigure-init message. 1984 Typically, the server will not provide more than an ERE and / or 1985 Authentication extension, since it will provide the new configuration 1986 information as part of the Request/Reply transaction triggered by the 1987 Reconfigure-init message. 1989 The server multicasts the Reconfigure-init message to one or more 1990 Reconfigure Multicast Addresses previously sent as extensions 1991 to the clients. Note that a server MAY unicast Reconfigure-init 1992 message(s) to specific clients by walking its list of bindings to 1993 determine the unicast address(es) of the clients. Whether or not the 1994 Reconfigure-init is multicast or unicast is an implementation detail. 1996 A server waits for a Request message from each client confirming that 1997 they have received the Reconfigure-init and are thus initiating a 1998 Request/Reply transaction with the server. The server can determine 1999 that a Request message is in response to a Reconfigure-init because 2000 the transaction-ID in the Request will be the same value as was used 2001 in the Reconfigure-init message. 2002 12.4.5. Time out and retransmission of Reconfigure-init messages 2004 The server uses the same algorithm and configuration values for 2005 sending Reconfigure-init messages as it does with Reconfigure 2006 messages. See Section 12.4.2 for this algorithm. 2007 12.4.6. Receipt of Request messages 2009 Upon receipt of a valid Request message with the same transaction-ID 2010 as the Reconfigure-init messages it sent, the server removes that 2011 client from the list of clients it is expecting to initiate a 2012 Request/Reply transaction. 2014 The server generates and sends Reply message(s) to the client as 2015 described in section 11.6.3, including in the ``extension'' field 2016 new values for configuration parameters. If the extensions include 2017 releasable resources, the server will include two extensions for each 2018 resource - one with the original values with the lease times set to 2019 zero, and another with new values and lease times. Note that the 2020 server can terminate the client's ability to use a resource simply by 2021 including only the first extension value. 2022 12.5. Client Behavior 2024 A client MUST always monitor UDP port 546 for Reconfigure and 2025 Reconfigure-init messages on interfaces upon which it has acquired 2026 DHCP parameters. Since the results of a reconfiguration event may 2027 affect application layer programs, the client SHOULD log these 2028 events, and MAY notify these programs of the change through an 2029 implementation-specific interface. 2031 12.5.1. Receipt of Reconfigure messages 2033 Upon receipt of a valid Reconfigure message, the client extracts 2034 the configuration parameters contained in the ``extensions'' 2035 field, and notifies the application layer that new values for these 2036 parameters are available. The client then generates and sends a 2037 Reconfigure-reply message to the server. 2038 12.5.2. Creation and sending of Reconfigure-reply messages 2040 When creating a Reconfigure-reply message, the client SHOULD start 2041 out with a buffer initialized with zeroed octets. The client sets 2042 the ``msg-type'' field to 7, and places the link-local address of 2043 the interface upon which it received the Reconfigure message in 2044 the ``client's link-local address'' field. The client copies the 2045 values of the following fields from the Reconfigure message to the 2046 Reconfigure-reply message: 2048 o transaction-ID 2050 o server-address 2052 The client sets the ``status'' field appropriately (see the table 2053 in section 3.4) based upon the results of processing the server's 2054 reconfigure-reply. 2056 The client places the address of the destination server in the 2057 ``server-address'' field. 2059 If the client is configured to use authentication, the client 2060 generates the appropriate authentication extension, and adds this 2061 extension to the ``extensions'' field. Note that the authentication 2062 extension MUST be the last extension in the ``extensions'' field. 2064 The client delays the sending of the Reconfigure-reply by some 2065 random value selected in the range of REC_REP_MIN and REC_REP_MAX 2066 seconds. This delay helps reduce the load on the server generated by 2067 processing large numbers of Reconfigure-reply messages. 2069 Default and initial values for REC_REP_MIN and REC_REP_MAX are 2070 documented in section 3.5. 2072 The client unicasts the Reconfigure-reply to the address identified 2073 in the ``server-address'' field. Sending the Reconfigure-reply 2074 completes the reconfiguration process for the client. 2076 12.5.3. Receipt of Reconfigure-init messages 2078 Upon receipt of a valid Reconfigure-init message, the client 2079 initiates a Request/Reply transaction with the server. 2080 12.5.4. Creation and sending of Request messages 2082 When responding to a Reconfigure-init, the client creates and 2083 sends the Request message in exactly the same manner as outlined in 2084 section 11.4.1 with the following differences: 2086 transaction-ID 2087 The client copies the transaction-ID from the 2088 Reconfigure-init message into the Request message. 2090 Pause before sending Request 2091 The client pauses before sending the Request for 2092 a random value within the range REC_REP_MIN and 2093 REC_REP_MAX seconds, as outlined in section 12.5.2. 2094 12.5.5. Time out and retransmission of Request messages 2096 The client uses the same variables and retransmission algorithm as it 2097 does with Request messages generated as part of a client-initiated 2098 configuration exchange. See section 11.4.2 for details. 2099 12.5.6. Receipt of Reply messages 2101 Upon the receipt of a valid Reply message, the client extracts 2102 the contents of the ``extension'' field, and sets (or resets) 2103 configuration parameters appropriately. If the configuration 2104 parameters changed were requested by the application layer, the 2105 client notifies the application layer of the changes using an 2106 implementation-specific interface. If the resources changed are 2107 releasable, the client makes the appropriate adjustments to its 2108 management of the leases of these resources. 2109 13. Using DHCP for network renumbering 2111 An administrator can use DHCP to renumber links within her DHCP 2112 domain through two techniques, passive renumbering and active 2113 renumbering. 2115 13.1. Passive Renumbering 2117 The administrator can configure her servers to return relatively 2118 short preferred and valid lifetimes for the IP addresses she 2119 makes available to clients. When she determines that she'd like 2120 to renumber a network, she configures her servers through an 2121 implementation-specific manner to disallow the extension of the IP 2122 address lifetimes on the original network, and adds the new network 2123 configuration data to the server's database. 2125 The clients on the original network will fail to acquire lifetime 2126 extensions on their IP addresses, and will request and acquire 2127 IP addresses from the new network when the valid lifetime of the 2128 original IP addresses approaches expiration. 2130 When the lifetimes for all of the IP addresses on the original 2131 network expire, the network can be considered renumbered. 2132 13.2. Active Renumbering 2134 The administrator can force the renumbering of networks in her DHCP 2135 domain by using the reconfigure feature of DHCP. She instructs her 2136 servers of the network renumbering through an implementation-specific 2137 interface. The servers in the domain will generate Reconfigure-init 2138 messages, which will cause the clients to initiate a Request/Reply 2139 transaction with the server. The servers will include two IP address 2140 extensions for each IP address being changed. The first will contain 2141 the original IP address, with the preferred and valid lifetimes set 2142 to zero. The second will contain the new IP address, with non-zero 2143 preferred and valid lifetimes. 2145 A server implementation MAY permit the administrator to set the 2146 original IP address lifetimes to some small value greater than zero, 2147 to allow applications running on the client to orderly transfer to 2148 the new network over time. 2149 14. DHCP Client Implementator Notes 2151 This section provides helpful information for the client implementor 2152 regarding their implementations. The text described here is not part 2153 of the protocol, but rather a discussion of implementation features 2154 we feel the implementor should consider during implementation. 2156 14.1. Primary Interface 2158 Since configuration parameters acquired through DHCP can be 2159 interface-specific or more general, the client implementor SHOULD 2160 provide a mechanism by which the client implementation can be 2161 configured to specify which interface is the primary interface. The 2162 client SHOULD always query the DHCP data associated with the primary 2163 interface for non-interface specific configuration parameters. An 2164 implementation MAY implement a list of interfaces which would be 2165 scanned in order to satisfy the general request. In either case, the 2166 first interface scanned is considered the primary interface. 2168 By allowing the specification of a primary interface, the client 2169 implementor identifies which interface is authoritative for 2170 non-interface specific parameters, which prevents configuration 2171 information ambiguity within the client implementation. 2172 14.2. Advertise Message and Configuration Parameter Caching 2174 If the hardware the client is running on permits it, the implementor 2175 SHOULD provide a cache for Advertise messages and a cache of 2176 configuration parameters received through DHCP. Providing these 2177 caches prevents unnecessary DHCP traffic and the subsequent load 2178 this generates on the servers. The implementor SHOULD provide a 2179 configuration knob for setting the amount of time the cache(s) are 2180 valid. 2181 14.3. Time out and retransmission variables 2183 Note that the client time out and retransmission variables outlined 2184 in section 3.5 can be configured on the server and sent to the client 2185 through the use of the ``DHCP Retransmission Parameter Extension'', 2186 which is documented in the ``extensions document'' [2]. A client 2187 implementation SHOULD be able to reset these variables using the 2188 values from this extension. 2189 14.4. Server Preference 2191 A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP 2192 Solicit message to collect Advertise messages and compare their 2193 preferences (see section 15.3), unless it receives an Advertise 2194 message with a preference of 255. If the client receives an 2195 Advertise message with a preference of 255, then the client MAY act 2196 immediately on that Advertise without waiting for any more additional 2197 Advertise messages. 2199 15. DHCP Server Implementator Notes 2201 This section provides helpful information for the server implementor. 2202 15.1. Client Bindings 2204 A server implementation can use the client's link-local address 2205 and the subnet prefix specification from which the client sent its 2206 Request message(s) as an index for finding configuration parameters 2207 assigned to the client. While it isn't critical to keep track 2208 of which clients were given information (resources) that isn't 2209 releasable, it IS critical for the server to keep track of which 2210 client it has assigned releasable resources. The server MUST 2211 include the transaction-ID from the client's Request along with 2212 the releasable resource identifier(s) within the binding. This is 2213 done so that the server can detect whether a client Request is a 2214 retransmission of an earlier Request or an entirely new Request. 2216 The server should periodically scan its bindings for releasable 2217 resources whose leases have expired. When the server finds expired 2218 resource assignments, it MUST delete these assignments, thereby 2219 making these resources available to other clients. 2221 The client bindings MUST be stored in non-volatile storage. 2223 The server implementation should provide policy knobs to control 2224 whether or not the lease on a releasable resource is renewable, and 2225 by how long. 2226 15.2. Reconfigure Considerations 2228 A server implementation MUST provide an interface to the 2229 administrator for initiating reconfigure events. 2231 A server implementation may provide a mechanism for allowing the 2232 specification of how many clients comprise a reconfigure multicast 2233 group. This enables the administrator to control the hit a server 2234 takes when a reconfigure event occurs. 2235 15.3. Server Preference 2237 The server implementation SHOULD allow the setting of a server 2238 preference value by the administrator. The server preference 2239 variable is an unsigned single octet value (0--255), with the lowest 2240 preference being 0 and the highest 255. Clients will choose higher 2241 preference servers over those with lower preference values. If you 2242 don't choose to implement this feature in your server, you MUST set 2243 the server preference field to 0 in the Advertise messages generated 2244 by your server. 2245 15.4. Request Message Transaction-ID Cache 2247 In order to improve performance, a server implementation MAY include 2248 an in memory transaction-ID cache. This cache is indexed by client 2249 binding and transaction-ID, and enables the server to quickly 2250 determine whether a Request is a retransmission or a new Request 2251 without the cost of a database lookup. If an implementor chooses to 2252 implement this cache, then they SHOULD provide a configuration knob 2253 to tune the lifetime of the cache entries. 2254 16. DHCP Relay Implementator Notes 2256 A relay implementation SHOULD allow the specification of a list of 2257 destination addresses for Solicit messages. This list MAY contain 2258 any mixture of unicast addresses and multicast addresses. 2260 If a relay receives an ICMP message in response to a DHCP message it 2261 has forwarded, it SHOULD log this event. 2262 17. Open Issues for Working Group Discussion 2264 This section contains some items for discussion by the working group. 2265 17.1. Trade-offs: Optional fields in DHCP messages 2267 You'll notice that the message formats have changed. In particular, 2268 some of the optional fields are now required. This will increase the 2269 size of DHCP messages in some cases, consuming network bandwidth and 2270 memory on the DHCP client (an issue for small devices such as PDAs). 2272 The changes were made for the following reasons: 2274 o Fields that were used most of the time were made required. 2276 o Some fields that were optional were either made required or added 2277 to messages which previously didn't have them. This was done for 2278 robustness reasons (receivers can validate that the message is 2279 for them, and in the case of clients, know which interface the 2280 message is intended for). 2282 o Simplicity. 2284 Please look at the messages as they are now defined, and let us know 2285 your opinion. 2286 17.2. Use DHCPv4 authentication or the current DHCPv6 method? 2288 Now that the DHCPv4 authentication draft is in last call, should 2289 we use the technique described in that document to provide 2290 authentication for DHCPv6, or should we continue with the 2291 authentication technique currently documented in the extensions 2292 draft? 2293 17.3. The Reconfigure Message and Subnet Prefix Extensions 2295 The drafts currently specify that Releasable resources (such as an IP 2296 address) can only be reconfigured using the Reconfigure-init trigger 2297 message. This was done for simplicity (enables clients to perform 2298 DAD on the new address and return the appropriate result to the 2299 server) using the same mechanism as a standard Request/Reply/Release 2300 exchange. This method also makes no assumptions about the 2301 charactistics of the releasable resource. 2303 However, for IP addresses with interface IDs, one could send out 2304 two IP address extensions, one for the old prefix and one for the 2305 new, and cause clients to change the prefix and thus renumber over 2306 time. This scheme avoids the added DHCP Request traffic - clients 2307 acknowledge with a Reconfigure-reply message. 2308 17.4. ``R'' bit in Request message not needed? 2310 Now that the transaction-ID is stored along with the releasable 2311 resource identifier in a client's binding, the transaction-ID cache 2312 becomes an optional feature of the DHCP server implementation, not a 2313 requirement of the protocol. Should we do away with the ``R'' bit? 2314 18. Security Considerations 2316 Clients and servers often have to authenticate the messages they 2317 exchange. For instance, a server may wish to be certain that a 2318 Request originated from the client identified by the fields included within the Request message 2320 header. Conversely, it is quite often essential for a client to 2321 be certain that the configuration parameters and addresses it has 2322 received were sent to it by an authoritative server. Similarly, a 2323 server should only accept a Release message which seems to be from 2324 one of its clients, if it has some assurance that the client actually 2325 did transmit the Release message. Again, a client might wish to only 2326 accept Reconfigure or Reconfigure-init messages that are certain to 2327 have originated from a server with authority to issue them. 2329 The IPv6 Authentication Header can provide security for DHCPv6 2330 messages when both endpoints have a suitable IP address. However, 2331 a client often has only a link-local address, and such an address 2332 is not sufficient for a server which is off-link. In those 2333 circumstances the relay is involved, so that the DHCP message MUST 2334 have the relay's address in the IP destination address field, even 2335 though the client aims to deliver the message to the server. The 2336 DHCP Client-Server Authentication Extension [2] is intended to be 2337 used in these circumstances. 2339 Note that, if a client receives a DHCP message which fails 2340 authentication, it should continue to wait for another message which 2341 might be correctly authenticated just as if the failed message had 2342 never arrived; however, receiving such failed messages SHOULD be 2343 logged. 2344 19. Year 2000 considerations 2346 Since all times are relative to the current time of the transaction, 2347 there is no problem within the DHCPv6 protocol related to any 2348 hardcoded dates or two-digit representation of the current year. 2349 20. IANA Considerations 2351 This document defines message types 1--8 to be received by UDP at 2352 port numbers 546 and 547. Additional message types may be defined in 2353 the future. 2355 Section 3.1 lists several multicast addresses used by DHCP. 2357 This document also defines several status codes that are to 2358 be returned with the Reply and Reconfigure-reply messages (see 2359 sections 9.4 and 9.7). The non-zero values for these status codes 2360 which are currently specified are shown in the table in section 3.4. 2362 There is a DHCPv6 extension [2] which allows clients and servers to 2363 exchange values for some of the timing and retransmission parameters 2364 defined in section 3.5. Adding new parameters in the future would 2365 require extending the values by which the parameters are indicated in 2366 the DHCP extension. Since there needs to be a list kept, the default 2367 values for each parameter should also be stored as part of the list. 2369 All of these protocol elements may be specified to assume new values 2370 at some point in the future. New values should be approved by the 2371 process of IETF Consensus [11]. 2372 21. Acknowledgements 2374 Thanks to the DHC Working Group for their time and input into the 2375 specification. Ralph Droms and Thomas Narten have had a major 2376 role in shaping the continued improvement of the protocol by their 2377 careful reviews. Many thanks to Matt Crawford, Erik Nordmark, Gerald 2378 Maguire, and Mike Carney for their studied review as part of the 2379 Last Call process. Thanks also for the consistent input, ideas, and 2380 review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov 2381 Rekhter, Matt Thomas, Sue Thomson, and Phil Wells. 2383 Thanks to Steve Deering and Bob Hinden, who have consistently 2384 taken the time to discuss the more complex parts of the IPv6 2385 specifications. 2386 A. Comparison between DHCPv4 and DHCPv6 2388 This appendix is provided for readers who will find it useful to see 2389 a model and architecture comparison between DHCPv4 [7, 1] and DHCPv6. 2390 There are three key reasons for the differences: 2392 o IPv6 inherently supports a new model and architecture for 2393 communications and autoconfiguration of addresses. 2395 o DHCPv6 benefits from the new IPv6 features. 2397 o New features were added to support the expected evolution and 2398 the existence of more complicated Internet network service 2399 requirements. 2401 IPv6 Architecture/Model Changes: 2403 o The link-local address permits a node to have an address 2404 immediately when the node boots, which means all clients have a 2405 source IP address at all times to locate an on-link server or 2406 relay. 2408 o The need for BOOTP compatibility and the broadcast flag have been 2409 removed. 2411 o Multicast and address scoping in IPv6 permit the design of 2412 discovery packets that would inherently define their range by the 2413 multicast address for the function required. 2415 o Stateful autoconfiguration has to coexist and integrate with 2416 stateless autoconfiguration supporting Duplicate Address 2417 Detection and the two IPv6 lifetimes, to facilitate the dynamic 2418 renumbering of addresses and the management of those addresses. 2420 o Multiple addresses per interface are inherently supported in 2421 IPv6. 2423 o Some DHCPv4 options are unnecessary now because the configuration 2424 parameters are either obtained through IPv6 Neighbor Discovery or 2425 the Service Location protocol [16]. 2427 DHCPv6 Architecture/Model Changes: 2429 o The message type is the first byte in the packet. 2431 o IPv6 Address allocations are now handled in a message extension 2432 as opposed to the message header. 2434 o Client/Server bindings are now mandatory and take advantage of 2435 the client's link-local address to always permit communications 2436 either directly from an on-link server, or from a off-link server 2437 through an on-link relay. 2439 o Servers are discovered by a client Solicit, followed by a server 2440 Advertise message 2442 o The client will know if the server is on-link or off-link. 2444 o The on-link relay may locate off-link server addresses from 2445 system configuration or by the use of a site-wide multicast 2446 packet. 2448 o ACKs and NAKs are not used. 2450 o The server assumes the client receives its responses unless it 2451 receives a retransmission of the same client request. This 2452 permits recovery in the case where the network has faulted. 2454 o Clients can issue multiple, unrelated Request messages to the 2455 same or different servers. 2457 o The function of DHCPINFORM is inherent in the new packet design; 2458 a client can request configuration parameters other than IPv6 2459 addresses in the optional extension headers. 2461 o Clients MUST listen to their UDP port for the new Reconfigure 2462 message from servers. 2464 o New extensions have been defined. 2466 With the changes just enumerated, we can support new user features, 2467 including 2469 o Configuration of Dynamic Updates to DNS 2471 o Address deprecation, for dynamic renumbering. 2473 o Relays can be preconfigured with server addresses, or use of 2474 multicast. 2476 o Authentication 2478 o Clients can ask for multiple IP addresses. 2480 o Addresses can be reclaimed using the Reconfigure-init message. 2482 o Integration between stateless and stateful address 2483 autoconfiguration. 2485 o Enabling relays to locate off-link servers. 2486 B. Full Copyright Statement 2488 Copyright (C) The Internet Society (2000). All Rights Reserved. 2490 This document and translations of it may be copied and furnished to 2491 others, and derivative works that comment on or otherwise explain it 2492 or assist in its implementation may be prepared, copied, published 2493 and distributed, in whole or in part, without restriction of any 2494 kind, provided that the above copyright notice and this paragraph 2495 are included on all such copies and derivative works. However, 2496 this document itself may not be modified in any way, such as by 2497 removing the copyright notice or references to the Internet Society 2498 or other Internet organizations, except as needed for the purpose 2499 of developing Internet standards in which case the procedures 2500 for copyrights defined in the Internet Standards process must be 2501 followed, or as required to translate it into languages other than 2502 English. 2504 The limited permissions granted above are perpetual and will not be 2505 revoked by the Internet Society or its successors or assigns. 2507 This document and the information contained herein is provided on an 2508 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2509 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2510 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2511 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2512 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2513 References 2515 [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 2516 Extensions. Request for Comments (Draft Standard) 2132, 2517 Internet Engineering Task Force, March 1997. 2519 [2] J. Bound, M. Carney, and C. Perkins. Extensions for the Dynamic 2520 Host Configuration Protocol for IPv6. 2521 draft-ietf-dhc-dhcpv6ext-12.txt, May 2000. (work in progress). 2523 [3] S. Bradner. Key words for use in RFCs to Indicate Requirement 2524 Levels. Request for Comments (Best Current Practice) 2119, 2525 Internet Engineering Task Force, March 1997. 2527 [4] S. Bradner and A. Mankin. The Recommendation for the IP Next 2528 Generation Protocol. Request for Comments (Proposed Standard) 2529 1752, Internet Engineering Task Force, January 1995. 2531 [5] W. J. Croft and J. Gilmore. Bootstrap Protocol. Request for 2532 Comments 951, Internet Engineering Task Force, September 1985. 2534 [6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 2535 Specification. Request for Comments (Draft Standard) 2460, 2536 Internet Engineering Task Force, December 1998. 2538 [7] R. Droms. Dynamic Host Configuration Protocol. Request for 2539 Comments (Draft Standard) 2131, Internet Engineering Task Force, 2540 March 1997. 2542 [8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 2543 Request for Comments (Proposed Standard) 2373, Internet 2544 Engineering Task Force, July 1998. 2546 [9] S. Kent and R. Atkinson. IP Authentication Header. Request for 2547 Comments (Proposed Standard) 2402, Internet Engineering Task 2548 Force, November 1998. 2550 [10] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for 2551 IP version 6. Request for Comments (Proposed Standard) 1981, 2552 Internet Engineering Task Force, August 1996. 2554 [11] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 2555 Considerations Section in RFCs. Request for Comments (Best 2556 Current Practice) 2434, Internet Engineering Task Force, October 2557 1998. 2559 [12] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 2560 IP Version 6 (IPv6). Request for Comments (Draft Standard) 2561 2461, Internet Engineering Task Force, December 1998. 2563 [13] D. C. Plummer. Ethernet Address Resolution Protocol: Or 2564 converting network protocol addresses to 48.bit Ethernet address 2565 for transmission on Ethernet hardware. Request for Comments 2566 (Standard) 826, Internet Engineering Task Force, November 1982. 2568 [14] J. Postel. User Datagram Protocol. Request for Comments 2569 (Standard) 768, Internet Engineering Task Force, August 1980. 2571 [15] S. Thomson and T. Narten. IPv6 Stateless Address 2572 Autoconfiguration. Request for Comments (Draft Standard) 2462, 2573 Internet Engineering Task Force, December 1998. 2575 [16] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 2576 Location Protocol. Request for Comments (Proposed Standard) 2577 2165, Internet Engineering Task Force, June 1997. 2579 [17] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic 2580 Updates in the Domain Name System (DNS UPDATE). Request for 2581 Comments (Proposed Standard) 2136, Internet Engineering Task 2582 Force, April 1997. 2584 Chair's Address 2586 The working group can be contacted via the current chair: 2588 Ralph Droms 2589 Computer Science Department 2590 323 Dana Engineering 2591 Bucknell University 2592 Lewisburg, PA 17837 2594 Phone: (570) 577-1145 2595 E-mail: droms@bucknell.edu 2597 Author's Address 2599 Questions about this memo can be directed to: 2601 Jim Bound 2602 Compaq Computer Corporation 2603 Mail Stop: ZK03-3/U14 2604 110 Spitbrook Road 2605 Nashua, NH 03062 2606 USA 2607 Phone: +1-603-884-0400 2608 Email: bound@zk3.dec.com 2610 Mike Carney 2611 Sun Microsystems, Inc 2612 Mail Stop: UMPK17-202 2613 901 San Antonio Road 2614 Palo Alto, CA 94303-4900 2615 USA 2616 Phone: +1-650-786-4171 2617 Email: mwc@eng.sun.com 2619 Charles E. Perkins 2620 Communications Systems Lab 2621 Nokia Research Center 2622 313 Fairchild Drive 2623 Mountain View, California 94043 2624 USA 2625 Phone: +1-650 625-2986 2626 EMail: charliep@iprg.nokia.com 2627 Fax: +1 650 625-2502