idnits 2.17.1 draft-ietf-dhc-dhcpv6-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 5 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes draft-ietf-dhc-dhcpv6-13.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When a client receives a retransmitted multicast Reconfigure message within XID_TIMEOUT of the last received Reconfigure message with the same transaction-ID, the client MUST not resend the the Request message if RECONF_MULTICAST_REQUEST_WAIT (see section 8) has not expired. If RECONF_MULTICAST_REQUEST_WAIT has expired then the client MUST reformulate exactly the same DHCP Request message and retransmit the Request message to the server again, and then reset RECONF_MULTICAST_REQUEST_WAIT to its default value or the value that was provided from a retransmission extension [15] provided by the server. In this way, the server can make use of the retransmission algorithm to ensure that all affected clients have received the multicast Reconfigure message. -- No information found for rfcdraft-ietf-dhc-dhcpv6-13.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 (25 February 1999) is 9191 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1885 (ref. '4') (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 2463 (ref. '5') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 1883 (ref. '6') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 2460 (ref. '7') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2373 (ref. '9') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2402 (ref. '10') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 1981 (ref. '11') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2434 (ref. '12') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 1970 (ref. '13') (Obsoleted by RFC 2461) ** Obsolete normative reference: RFC 2461 (ref. '14') (Obsoleted by RFC 4861) -- No information found for draft-ietf-dhc-dhcpv6ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '15' ** Obsolete normative reference: RFC 1971 (ref. '19') (Obsoleted by RFC 2462) ** Obsolete normative reference: RFC 2462 (ref. '20') (Obsoleted by RFC 4862) Summary: 18 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Bound 3 INTERNET DRAFT Compaq Computer Corp. 4 DHC Working Group C. Perkins 5 Obsoletes: draft-ietf-dhc-dhcpv6-13.txt Sun Microsystems Laboratories 6 25 February 1999 8 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 9 draft-ietf-dhc-dhcpv6-14.txt 11 Status of This Memo 13 This document is a submission by the Dynamic Host Configuration 14 Working Group of the Internet Engineering Task Force (IETF). 15 Comments should be submitted to the dhcp-v6@bucknell.edu mailing 16 list. 18 Distribution of this memo is unlimited. 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at 28 any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at: 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at: 37 http://www.ietf.org/shadow.html. 39 Abstract 41 The Dynamic Host Configuration Protocol (DHCPv6) enables DHCP 42 servers to pass configuration information, via extensions, to IPv6 43 nodes. It offers the capability of automatic allocation of reusable 44 network addresses and additional configuration flexibility. This 45 protocol is a stateful counterpart to the IPv6 Stateless Address 46 Autoconfiguration protocol, and can be used separately or together 47 with the latter to obtain configuration information. 49 Contents 51 Status of This Memo i 53 Abstract i 55 1. Introduction 1 57 2. Terminology and Definitions 2 58 2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2 59 2.2. DHCPv6 Terminology . . . . . . . . . . . . . . . . . . . 3 60 2.3. Specification Language . . . . . . . . . . . . . . . . . 4 61 2.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Protocol Design Model 4 64 3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. DHCP Messages . . . . . . . . . . . . . . . . . . . . . . 5 66 3.3. Request/Response Processing Model . . . . . . . . . . . . 7 68 4. DHCP Message Formats and Field Definitions 8 69 4.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 8 70 4.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 9 71 4.3. DHCP Request Message Format . . . . . . . . . . . . . . . 10 72 4.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12 73 4.5. DHCP Release Message Format . . . . . . . . . . . . . . . 13 74 4.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 15 76 5. DHCP Client Considerations 16 77 5.1. Verifying Resource Allocations After Restarts . . . . . . 16 78 5.2. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 16 79 5.3. Receiving DHCP Advertise Messages . . . . . . . . . . . . 17 80 5.4. Sending DHCP Request Messages . . . . . . . . . . . . . . 18 81 5.5. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 20 82 5.6. Sending DHCP Release Messages . . . . . . . . . . . . . . 20 83 5.7. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 21 84 5.8. Interaction with Stateless Address Autoconfiguration . . 22 86 6. DHCP Server Considerations 23 87 6.1. Receiving DHCP Solicit Messages . . . . . . . . . . . . . 23 88 6.2. Sending DHCP Advertise Messages . . . . . . . . . . . . . 24 89 6.3. DHCP Request and Reply Message Processing . . . . . . . . 24 90 6.3.1. Processing for Extensions to DHCP Request and Reply 91 Messages . . . . . . . . . . . . . . . . . 25 92 6.3.2. Client Requests to Deallocate Unknown Resources . 26 93 6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 26 94 6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . . 27 95 6.6. Client-Resource timeouts . . . . . . . . . . . . . . . . 28 97 7. DHCP Relay Considerations 28 98 7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 28 99 7.2. DHCP Request Message Processing . . . . . . . . . . . . . 29 100 7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 30 102 8. Retransmission and Configuration Variables 30 104 9. Security Considerations 33 106 10. Year 2000 considerations 33 108 11. IANA Considerations 34 110 12. Acknowledgements 34 112 A. Changes for this revision 34 114 B. Related Protocol Specifications 35 116 C. Comparison between DHCPv4 and DHCPv6 37 118 D. Full Copyright Statement 40 120 Chair's Address 43 122 Author's Address 43 123 1. Introduction 125 The Dynamic Host Configuration Protocol (DHCPv6, or in this 126 document usually DHCP) provides configuration parameters to Internet 127 nodes. DHCP consists of a protocol for delivering node-specific 128 configuration parameters from a DHCP server to a client, and 129 extensions for allocation of network addresses and other related 130 parameters to IPv6 [7] nodes. 132 DHCP uses a client-server model, where designated DHCP servers 133 automatically allocate network addresses and deliver configuration 134 parameters to dynamically configurable clients. Throughout the 135 remainder of this document, the term "server" refers to a node 136 providing initialization parameters by way of the DHCP protocol, 137 and the term "client" refers to a node requesting initialization 138 parameters from a DHCP server. 140 DHCPv6 uses Request and Reply messages to support a client/server 141 processing model whereby both client and server are assured that 142 requested configuration parameters have been received and accepted 143 by the client. DHCP supports optional configuration parameters and 144 processing for nodes through extensions described in its companion 145 document ``Extensions for the Dynamic Host Configuration Protocol for 146 IPv6'' [15]. 148 The IPv6 Addressing Architecture [9] and IPv6 Stateless Address 149 Autoconfiguration [20] specifications provide new features not 150 available in IP version 4 (IPv4) [18], which are used to simplify 151 and generalize the operation of DHCP clients. This document is 152 intended to complement those specifications for clients attached to 153 the kinds of Internet media for which those specifications apply. In 154 particular, the specification in this document does not necessarily 155 apply to nodes which do not enjoy a bidirectional link to the 156 Internet. 158 Section 2 provides definitions for terminology used throughout 159 this document. Section 3 provides an overview of the protocol 160 design model that guided the design choices in the specification; 161 section 3.2 briefly describes the protocol messages and their 162 semantics. Section 4 provides the message formats and field 163 definitions used for each message. Sections 5, 6, and 7 specify 164 how clients, servers, and relays respectively interact. The timeout 165 and retransmission guidelines as well as configuration variables for 166 DHCP protocol operations are discussed in Section 8. Appendix B 167 summarizes related work in IPv6 that will provide helpful context; 168 it is not part of this specification, but included for informational 169 purposes. Appendix C discusses the differences between DHCPv4 and 170 DHCPv6. 172 2. Terminology and Definitions 174 Relevant terminology from the IPv6 Protocol [7], IPv6 Addressing 175 Architecture [9], and IPv6 Stateless Address Autoconfiguration [20] 176 is given, followed by DHCPv6 terminology. 178 2.1. IPv6 Terminology 180 address An IP layer identifier for an interface or a set of 181 interfaces. 183 unicast address 184 An identifier for a single interface. A packet sent 185 to a unicast address is delivered to the interface 186 identified by that address. 188 multicast address 189 An identifier for a set of interfaces (typically 190 belonging to different nodes). A packet sent to a 191 multicast address is delivered to all interfaces 192 identified by that address. 194 host Any node that is not a router. 196 IP Internet Protocol Version 6 (IPv6). The terms IPv4 and 197 IPv6 are used only in contexts where it is necessary to 198 avoid ambiguity. 200 interface 201 A node's attachment to a link. 203 link A communication facility or medium over which nodes 204 can communicate at the link layer, i.e., the layer 205 immediately below IP. Examples are Ethernet (simple or 206 bridged); Token Ring; PPP links, X.25, Frame Relay, or 207 ATM networks; and internet (or higher) layer "tunnels", 208 such as tunnels over IPv4 or IPv6 itself. 210 link-layer identifier 211 a link-layer identifier for an interface. Examples 212 include IEEE 802 addresses for Ethernet or Token Ring 213 network interfaces, and E.164 addresses for ISDN links. 215 link-local address 216 An IP address having link-only scope, indicated by 217 having the routing prefix (FE80::0000/64), that can be 218 used to reach neighboring nodes attached to the same 219 link. Every interface has a link-local address. 221 message A unit of data carried in a packet, exchanged between 222 DHCP agents and clients. 224 neighbor A node attached to the same link. 226 node A device that implements IP. 228 packet An IP header plus payload. 230 prefix A bit string that consists of some number of initial 231 bits of an address. 233 router A node that forwards IP packets not explicitly 234 addressed to itself. 236 2.2. DHCPv6 Terminology 238 agent address 239 The address of a neighboring DHCP Agent on the same 240 link as the DHCP client. 242 binding A binding (or, client binding) containing the data 243 which a DHCP server maintains for each of its clients 244 (see Section 6). 246 resource-server association 247 An association between a resource and a DHCP server, 248 maintained by the client which received that resource 249 from that DHCP server. 251 configuration parameter 252 Any parameter that can be used by a node to configure 253 its network subsystem and enable communication on a 254 link or internetwork. 256 DHCP client (or client) 257 A node that initiates requests on a link to obtain 258 configuration parameters. 260 DHCP server (or server) 261 A server is a node that responds to requests from 262 clients, and may or may not be on the same link as as 263 the client. 265 DHCP relay (or relay) 266 A node that acts as an intermediary to deliver DHCP 267 messages between clients and servers, and is on the 268 same link as a client. 270 DHCP agent (or agent) 271 Either a DHCP server on the same link as a client, or a 272 DHCP relay. 274 transaction-ID 275 An unsigned integer to match responses with replies 276 initiated either by a client or server. Clients MUST 277 use integers from 1 to 1000, and servers use integers 278 greater than 1000 for transaction-ID's. 280 2.3. Specification Language 282 In this document, the words MUST, MUST NOT, SHOULD, SHOULD NOT, and 283 MAY are used to signify the requirements of the specification, in 284 accordance with RFC 2119 [2]. 286 2.4. Error Values 288 This specification document uses symbolic names for the errors known 289 to DHCP clients and servers, as used for instance in the status field 290 of the DHCP Reply message (see section 4.4). The symbolic names have 291 the actual values listed below: 293 Error Name ErrorID 294 ================================ 295 PoorlyFormed 18 296 Unavail 19 297 NoBinding 20 298 InvalidSource 21 299 NoServer 23 300 ICMPError 64 302 3. Protocol Design Model 304 This section is provided for implementors to understand the DHCPv6 305 protocol design model from an architectural perspective. Goals and 306 conceptual models are presented in this section. 308 3.1. Design Goals 310 The following list gives general design goals for this DHCP 311 specification. 313 - DHCP should be a mechanism rather than a policy. DHCP must allow 314 local system administrators control over configuration parameters 315 where desired; e.g., local system administrators should be able 316 to enforce local policies concerning allocation and access to 317 local resources where desired. 319 - DHCP must not require manual configuration of DHCP clients, 320 except as dictated by security requirements. Each node should be 321 able to obtain appropriate local configuration parameters without 322 user intervention. 324 - DHCP must not require a server on each link. To allow for scale 325 and economy, DHCP must work across DHCP relays. 327 - In some installations, clients on certain subnets can be served 328 by more than one DHCP server, improving reliability and/or 329 performance. Therefore, a DHCP client must be prepared to 330 receive multiple (possibly different) responses to a DHCP Solicit 331 message. 333 - DHCP must coexist with statically configured, non-participating 334 nodes and with existing network protocol implementations. 336 - DHCPv6 must be compatible with IPv6 Stateless Address 337 Autoconfiguration [20]. 339 - A DHCPv6 Client implementation may be started in the absence of 340 any IPv6 routers on the client's link. 342 - DHCP architecture must support automated renumbering of IP 343 addresses [3]. 345 - DHCP servers should be able to support Dynamic Updates to 346 DNS [22]. 348 - DHCP servers must be able to support multiple IPv6 addresses for 349 each client. 351 On the other hand, a DHCP server to server protocol is NOT part of 352 this specification. Furthermore, it is NOT a design goal of DHCP to 353 specify how a server configuration parameter database is maintained 354 or determined. Methods for configuring DHCP servers are outside the 355 scope of this document. 357 3.2. DHCP Messages 359 Each DHCP message contains a type, which defines its function within 360 the protocol. Formats for the messages are found in section 4, with 361 an initial description and discussion. Processing details for these 362 DHCP messages are specified in Sections 5, 6, and 7. The message 363 types are as follows: 365 01 DHCP Solicit 367 The DHCP Solicit message is an IP multicast message sent by a 368 client to one or more agents, or forwarded by a relay to one or 369 more servers. 371 02 DHCP Advertise 373 The DHCP Advertise is an IP unicast message sent by a DHCP 374 Agent in response to a client's DHCP Solicit message. 376 03 DHCP Request 378 The DHCP Request is an IP unicast message sent by a client to a 379 server to request configuration parameters on a network. 381 04 DHCP Reply 383 The DHCP Reply is an IP unicast message sent by a server in 384 response to a client's DHCP Request, or by the relay that 385 relayed that client's DHCP Request. Extensions [15] to the 386 DHCP Reply describe the resources that the server has committed 387 and allocated to this client, and may contain other information 388 for use by this client. 390 05 DHCP Release 392 The DHCP Release is an IP unicast message sent by a client to 393 inform the server that the client is releasing resources. 395 06 DHCP Reconfigure 397 The DHCP Reconfigure is an IP unicast or multicast message sent 398 by a server to inform one or more clients that the server has 399 new configuration information of importance to the client. 400 Each client is expected to initiate a new DHCP Request in 401 response to the Reconfiure message. 403 DHCP message types not defined here (msg-types 0 and 7-255) are 404 reserved and SHOULD be silently ignored. 406 3.3. Request/Response Processing Model 408 The request/response processing for DHCPv6 is transaction based and 409 uses a set of best-effort messages to complete the transaction. 411 To find a server, a client sends a DHCP Solicit from the interface 412 which it wishes to configure. The client then awaits a DHCP 413 Advertise message containing an IP address of a DHCP server. 414 Transactions are started by a client with a DHCP Request, which may 415 be issued after the client knows the server's address. The server 416 then unicasts a DHCP Reply, possibly via a relay. At this point in 417 the flow all data has been transmitted and is presumed to have been 418 received. To provide a method of recovery if either the client or 419 server does not receive its messages, the client retransmits each 420 DHCP Request message until it elicits the corresponding DHCP Reply, 421 or until it can be reasonably certain that the desired DHCP server 422 is unavailable, or it determines that it does not want a response 423 (i.e., it MAY abort the transaction). The timeout and retransmission 424 guidelines and configuration variables are discussed in Section 8. 426 DHCP uses UDP [17] to communicate between clients and servers. UDP 427 is not reliable, but the DHCP retransmission scheme just described 428 provides reliability between clients and servers. The following 429 well-known multicast addresses are used by DHCP agents and clients: 431 FF02:0:0:0:0:0:1:2 432 All DHCP Agents (servers and relays) MUST join the 433 link-local All-DHCP-Agents multicast group at the address 434 FF02:0:0:0:0:0:1:2. 436 FF05:0:0:0:0:0:1:3 437 All DHCP servers MUST join the site-local 438 All-DHCP-Servers multicast group at the address 439 FF05:0:0:0:0:0:1:3. 441 FF05:0:0:0:0:0:1:4 442 All DHCP relays MUST join the site-local All-DHCP-Relays 443 multicast group at the address FF05:0:0:0:0:0:1:4. 445 A DHCP server or agent MUST transmit all messages to DHCP clients on 446 UDP port 546. A DHCP client MUST transmit all messages to a DHCP 447 agent over UDP using port 547. A DHCP server MUST transmit all 448 messages to DHCP relays over UDP on port 546. The source port for 449 DHCP messages is arbitrary. 451 For the proper operation of the DHCP protocol to operate within a 452 network where one or more firewallsare used, DHCP transactions sent 453 to the IP addresses of DHCP servers at UDP destination ports 546 and 454 547 will need to be permitted. 456 4. DHCP Message Formats and Field Definitions 458 All reserved fields in a message MUST be transmitted as zeroes and 459 ignored by the receiver of the message. 461 4.1. DHCP Solicit Message Format 463 A client transmits a DHCP Solicit message over the interface to be 464 configured, to obtain one or more server addresses. Unless otherwise 465 noted, the value of all fields are set by the client. 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | msg-type = 1 |C| reserved | prefix-size | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | client's link-local address | 473 | (16 octets) | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | relay-address | 476 | (16 octets) | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | saved agent-address | 479 | (if present, 16 octets) | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 C If set, the client requests that all servers receiving 483 the message deallocate the resources associated with 484 the client. If set, the client SHOULD provide a saved 485 agent-address to locate the clients binding by a 486 server. 488 prefix-size A nonzero prefix-size is the number of leftmost bits 489 of the agent's IPv6 address which make up the routing 490 prefix. The prefix-size field is set by the DHCP relay 491 if the relay receives the solicitation and forwards it 492 to one or more DHCP Servers. 494 reserved 0 496 client's link-local address 497 The IP link-local address of the client interface from 498 which the client issued the DHCP Request message 500 relay-address 501 Set by the client to be zero. If received by a DHCP 502 relay, set by the relay to the IP address of the 503 interface on which the relay received the client's DHCP 504 Solicit message 506 saved agent-address 507 If present, the IP address of an agent's interface 508 retained by the client from a previous DHCP 509 transaction. 511 A client SHOULD send a DHCP Solicit message to the All-DHCP-Agents 512 multicast group (see section 3.3), setting the relay-address to 513 zero. Any relay receiving the solicitation MUST forward it to the 514 All-DHCP-Servers multicast group. In that case, the relay MUST copy 515 a non-link-local address of its interface from which the client's 516 solicitation was received into the relay-address field. Servers 517 receiving the solicitation then send their advertisements to the 518 prospective client. 520 4.2. DHCP Advertise Message Format 522 A DHCP agent sends a DHCP Advertise message to inform a prospective 523 client about the IP address of a server to which a DHCP Request 524 message may be sent. When the client and server are on different 525 links, the server sends the advertisement back through the relay 526 whence the solicitation came. The value of all fields in the DHCP 527 Adverstise message are filled in by the DHCP Server and not changed 528 by any DHCP Relay. 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | msg-type = 2 |S| reserved | preference | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | client's link-local address | 536 | (16 octets) | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | agent-address | 539 | (16 octets) | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | server-address | 542 | (16 octets, if present) | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | extensions (variable number and length) ... 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 S If set, the server-address is present. 549 reserved 0 550 preference An octet (unsigned) indicating a server's willingness 551 to provide service to the client (see Section 5.3). 553 client's link-local address 554 The IP link-local address of the client interface 555 from which the client issued the DHCP Request message 557 agent-address 558 The IP address of a DHCP Agent interface on the same 559 link as the client. 561 server-address 562 If present, the IP address of the DHCP server 564 extensions See [15]. 566 Suppose that a server on the same link as a client issues the 567 DHCP Advertise in response to a DHCP Solicit message sent to the 568 All-DHCP-Agents multicast address. Then the agent-address will be an 569 IP address of one of the server's interfaces on the same link as the 570 client, and the `S' bit will be set to zero, indicating the absence 571 of the server-address in the DHCP Advertise message. See section 5.3 572 for information about how clients handle the preference field. 574 The server MUST copy the client's link-local address into the 575 advertisement which is sent in response to a DHCP Solicit. Both 576 server-address (if present) and agent-address of the DHCP Advertise 577 message MUST have sufficient scope to be reachable by the client. 578 Moreover, the agent-address of any DHCP Advertise message sent by a 579 relay MUST NOT be a link-local address. In situations where there 580 are no routers sending Router Advertisements, then a DHCP server MUST 581 be configured on the same link as prospective clients. The DHCPv6 582 protocol design does not apply to situations where the client is 583 unable to route messages to a server not on the same link. 585 4.3. DHCP Request Message Format 587 In order to request configuration parameters from a server, a client 588 sends a DHCP Request message, and MAY append extensions [15]. If 589 the client does not know any server address, it MUST first obtain 590 one by multicasting a DHCP Solicit message (see Section 4.1). 591 Typically, when a client reboots, it does not have a valid IP address 592 of sufficient scope for the server to communicate with the client. 593 In such cases, the client MUST NOT send the message directly to 594 the server because the server could not return any response to the 595 client; the client MUST send the message to the local relay and 596 insert the relay-address as the agent-address in the message header. 598 Otherwise, the client MAY omit the server-address in the DHCP Request 599 message; in this case, the client MUST clear the S-bit and send the 600 message directly to the server, using the server's address as the IP 601 destination address in the IP header. In either case, all fields in 602 the DHCP Request message are entered by the client. 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | msg-type = 3 |C|S|R| rsvd | transaction-ID | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | client's link-local address | 610 | (16 octets) | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | agent-address | 613 | (16 octets) | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | server-address | 616 | (16 octets, if present) | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | extensions (variable number and length) .... 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 C If set, the client requests the server to remove all 622 resources associated with the client binding, except 623 those resources provided as extensions. 625 S If set, the server-address is present 627 R If set, the client has rebooted and requests that all 628 of its previous transaction-IDs be expunged and made 629 available for re-use. 631 rsvd 0 633 transaction-ID 634 A unsigned integer identifier used to identify this 635 Request. 637 client's link-local address 638 The IP link-local address of the client interface from 639 which the client issued the DHCP Request message 641 agent-address 642 The IP address of an agent's interface, copied from a 643 DHCP Advertisement message. 645 server-address 646 If present, the IP address of the server which should 647 receive the client's DHCP Request message. 649 extensions See [15]. 651 When the client sets the `C' bit and adds extensions, the server 652 is expected to deallocate all other resources not listed in the 653 extension. The resources explicitly requested in extensions to the 654 Request message SHOULD be reallocated by the server to the client, 655 assuming the client is still authorized to receive them. 657 The transaction-ID is selected by the client to be greater than or 658 equal to 1024, unless the DHCP Request is sent in response to a 659 Reconfigure msg (see section 4.6). In that case, the transaction-ID 660 is copied from the transaction-ID in the Reconfigure message. 662 4.4. DHCP Reply Message Format 664 The server sends one DHCP Reply message in response to every DHCP 665 Request or DHCP Release received. If the request comes with the `S' 666 bit set, the client could not directly send the Request to the server 667 and had to use a neighboring relay agent. In that case, the server 668 sends back the DHCP Reply with the `L' bit set, and the DHCP Reply 669 is addressed to the agent-address found in the DHCP Request message. 670 ALl the fields in the DHCP Reply message are set by the DHCP server. 672 0 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | msg-type = 4 |L| status | transaction-ID | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | client's link-local address | 678 | (16 octets, if present) | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | extensions (variable number and length) .... 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 L If set, the client's link-local address is present 684 status One of the following decimal values: 686 0 Success 687 16 Failure, reason unspecified 688 17 Authentication failed or nonexistent 689 18 Poorly formed Request or Release 690 19 Resources unavailable 691 20 Client record unavailable 692 21 Invalid client IP address in Release 693 23 Relay cannot find Server Address 694 64 Server unreachable (ICMP error) 696 transaction-ID 697 An unsigned integer identifier used to identify this 698 Reply, and copied from the client's Request. 700 client's link-local address 701 If present, the IP address of the client interface 702 which issued the corresponding DHCP Request message. 704 extensions 705 See [15]. 707 If the `L' bit is set, the client's link-local address is present 708 in the Reply message. Then the Reply is sent by the server to the 709 relay's address which was specified as the agent-address in the DHCP 710 Request message, and the relay uses the link-local address to deliver 711 the Reply message to the client. The transaction-ID in the DHCP 712 Reply is copied by the server from the client Request message. 714 4.5. DHCP Release Message Format 716 The DHCP Release message is sent without the assistance of any DHCP 717 relay. When a client sends a Release message, it is assumed to 718 have a valid IP address with sufficient scope to allow access to 719 the target server. If parameters are specified in the extensions, 720 only those parameters are released. The values of all fields 721 of the DHCP Release message are entered by the Client. The DHCP 722 server acknowledges the Release message by sending a DHCP Reply 723 (Sections 4.4, 6.3). 725 0 1 2 3 726 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 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | msg-type = 1 |D| reserved | transaction-ID | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | client's link-local address | 731 | (16 octets) | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | agent-address | 734 | (16 octets) | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | client-address | 737 | (16 octets, if present) | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | extensions (variable number and length) .... 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 msg-type 5 744 D If the `D' flag is set, the client instructs the server 745 to send the DHCP Reply directly back to the client, 746 instead of using the given agent-address and link-local 747 address to relay the Reply message. 749 reserved 0 751 transaction-ID 752 A unsigned integer identifier used to identify this 753 Release, and copied into the Reply. 755 client's link-local address 756 The IP link-local address of the client interface from 757 which the the client issued the DHCP Release message 759 agent-address 760 The IP address of the agent interface for the IP 761 address to be released. 763 client-address 764 The IP address of the client interface from which 765 the the client issued the DHCP Release message. The 766 client-address field is present whenever the `D' bit is 767 set, even if it is equal to the link-local address. 769 extensions See [15] 771 It is an error (status code ``InvalidSource'' (see Section 2.4)) to 772 include within the DHCP Release message both the `D' bit and an IP 773 address extension which has the IP address used as the client-address 774 field of the DHCP Release message header. 776 4.6. DHCP Reconfigure Message Format 778 DHCP Reconfigure messages can only be sent to clients which have 779 established an IP address which routes to the link at which they are 780 reachable, hence the DHCP Reconfigure message is sent without the 781 assistance of any DHCP relay. When a server sends a Reconfigure 782 message, the receivers are assumed to have a valid IP address with 783 sufficient scope to be accessible by the server. Only the parameters 784 which are specified in the extensions to the Reconfigure message need 785 be requested again by the client. A Reconfigure message can either 786 be unicast or multicast by the server. The client will extract the 787 extensions provided by the server and send a DHCP Request message to 788 the server using those extensions (see section 5.7). 790 0 1 2 3 791 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 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | msg-type = 6 |N| reserved | transaction-ID | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | server-address | 796 | (16 octets) | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | extensions (variable number and length) .... 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 N The `N' flag indicates that the client should not 802 expect a DHCP Reply in response to the DHCP Request 803 it sends as a result of the DHCP Reconfigure message. 805 reserved 0 807 transaction-ID 808 A unsigned integer identifier used to identify this 809 Reconfigure, to by copied into the following DHCP 810 Request message that will be transmitted by the 811 client. 813 server-address 814 The IP address of the DHCP server issuing the DHCP 815 Reconfigure message. 817 extensions See [15] 819 5. DHCP Client Considerations 821 A node which is not a DHCP agent MUST silently discard any DHCP 822 Solicit, DHCP Request, or DHCP Release message it receives. 824 5.1. Verifying Resource Allocations After Restarts 826 A client MAY retain its configured parameters and resources across 827 client system reboots and program restarts. Any client wishing 828 to use this feature MUST also maintain state for the address of 829 its DHCP agent address. When the client restarts, the client MUST 830 also formulate a DHCP Request message to verify that its configured 831 parameters and resources are still valid. This Request message MUST 832 have the `C' bit set, to clean up stale client binding information 833 at the server which may no longer be in use by the client; stale 834 information is that which the client does not include in extensions 835 to such request messages. 837 If the server does not respond to the DHCP Request message after 838 REQUEST_MSG_MIN_RETRANS (see section 8), the client may still 839 use any resources whose lifetimes have not yet expired. In such 840 cases, however, the client MUST begin to search for another server 841 by multicasting a DHCP Solicit message with the `C' bit set (see 842 section 5.2). The client SHOULD log a DHCP System Error. 844 This also handles the case wherein a client restarts on a new 845 network, where its IP address is no longer valid. In this situation, 846 when the client receives a new IP address and the old IP address 847 is no longer needed, the client MUST release its old IP address by 848 issuing a DHCP Release message with the appropriate extension if it 849 can communicate with its previous server. 851 A mobile client (that is not stationary on a network) SHOULD keep its 852 agent-address, and possibly the relevant server address, along with 853 all resource-server associations [15] on non-volatile storage. This 854 will allow the client to release resources with the DHCP Solicit or 855 Release messages if it enters a different network location before 856 releasing its resources. 858 5.2. Sending DHCP Solicit Messages 860 A client MUST have the address of a server to send a Request message. 861 The client SHOULD locate a DHCP server by multicasting a DHCP Solicit 862 message to the All-DHCP-Agents link-local multicast address (see 863 Section 3.3), setting the Hop Limit == 1. If there are no DHCP 864 servers on the same link as the node, then a DHCP relay MUST be 865 present if solicitations sent from a client's link-local address are 866 to be handled. 868 When sending a DHCP Solicit message, a client MUST set the Relay 869 Address field to 16 octets of zeros, and zero the prefix-size field. 871 If a client reboots and does not have a valid IP address, it SHOULD 872 set the `C' bit in the DHCP Solicit message it sends when restarting. 873 By setting the `C' bit in the solicitation, a client requests that 874 all the DHCP servers that receive the solicitation should clean up 875 their client records that match its link-local address. 877 If a client sends a DHCP Solicit message after it reboots, the 878 solicitation SHOULD be delayed after reception of the first Router 879 Advertisement [14] message (see section 5.8), by at least some random 880 amount of time between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY (see 881 section 8). This delay is intended to help stagger requests to 882 DHCP servers (and avoid link-layer collisions) after a power outage 883 causes many nodes to reboot all at once. Each subsequent DHCP 884 Solicit message that is issued before receiving an advertisement 885 MUST be delayed by twice the amount by which the previous DHCP 886 Solicit message was delayed, plus a small random delay between 887 MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY seconds. 889 5.3. Receiving DHCP Advertise Messages 891 After a client has received a DHCP Advertise message, it has the 892 address of a server for subsequent DHCP Request messages. If the `S' 893 bit is zero, the DHCP Advertise message was transmitted by a server 894 on the same link as the client, and the client uses the agent-address 895 as the server's address; otherwise, the server's IP address is 896 located in the server-address field. If the server-address is a 897 multicast address, the advertisement MUST be silently discarded. 899 A server MAY append extensions to its advertisements; this might 900 allow the client to select the configuration that best meets its 901 needs from among several prospective servers. 903 Unless a DHCP Advertisement is received with a preference equal 904 to 255 (see Section 4.2), the client MUST wait CLIENT_ADV_WAIT 905 seconds after issuing the DHCP Solicit message in order to receive 906 the Advertisement with the highest preference. After waiting for 907 that period of time, a client MUST select the highest preference 908 server as the target of its DHCP request. If a client receives an 909 advertisement with a preference of 255, it does not have to wait for 910 any more advertisements. 912 If a client sends a DHCP Request to a highly preferred server but 913 fails to receive a DHCP reply from that server after following the 914 retransmission algorithm in section 8, the client MUST then try to 915 send a DHCP Request to a less preferred server. 917 A client is free to cache the result of any DHCP Advertisement it 918 receives. This is purely a potential performance enhancement, 919 because the results might change over time. A client may not get 920 a DHCP Reply if it uses a cached server-address, and in that case 921 SHOULD multicast another DHCP Solicit message. 923 5.4. Sending DHCP Request Messages 925 A client obtains configuration information from a server by sending 926 a DHCP Request message. The client MUST know the server's address 927 before sending the Request message, and the client MUST have acquired 928 a (possibly identical) DHCP agent address. If the client and server 929 are on the same link, the agent-address used by the client MUST be 930 the same as the DHCP server's address. A DHCP Request message MUST 931 NOT be sent to any multicast address, since otherwise multiple DHCP 932 servers would possibly allocate resources to the client in response 933 to the same Request, and the client would have no way to know which 934 servers had made the allocations, if any packets were lost due to 935 collisions, etc. 937 If the DHCP server is off-link, and the client has no valid IP 938 address of sufficient scope, then the client MUST include the 939 server-address and set the `S' bit in the DHCP Request message. In 940 this case, the IP destination address in the IP header will be a DHCP 941 relay address. 943 Otherwise, if the client has a valid IP address of sufficient scope 944 and knows the IP address of a candidate server, it MUST send the 945 Request message directly to the server without requiring the services 946 of the local DHCP relay. 948 If a client wishes to instruct a server to deallocate all unknown 949 previous resources, configuration information, and bindings 950 associated with its agent-address and link-local address, it 951 sets the `C' bit in the DHCP Request. A client MAY send in 952 such a Request even when it is no longer attached to the link on 953 which the relay-address is attached. The `C' bit allows better 954 reclamation of available resources when a client lost records for 955 its resource-server associations and might not otherwise be able to 956 release the associated resources. 958 When a client reboots and loses its previous state, the server 959 should no longer keep track of the the XID-TIMEOUT binding cache of 960 transaction IDs (see section 6) associated with that previous state. 961 In order to inform the server that the client no longer wishes 962 any association to be maintained between used transaction-IDs and 963 previous transactions, the client SHOULD set the `R' bit in its DHCP 964 Request. 966 In any case, after choosing a transaction-ID which is numerically 967 greater than its last recorded transaction-ID, and filling in the 968 appropriate fields of the DHCP Request message, the client MAY append 969 various DHCP Extensions to the message. These extensions denote 970 specific requests by the client; for example, a client may request 971 a particular IP address, or request that the server send an update 972 containing the client's new IP address to a Domain Name Server. When 973 all desired extensions have been applied, the client sends the DHCP 974 Request to the appropriate agent. 976 For each pending DHCP Request message, a client MUST maintain the 977 following information: 979 - The transaction-ID of the request message, 980 - The server-address, 981 - The agent-address (which can be the same as the server-address), 982 - The time at which the next retransmission will be attempted, and 983 - All extensions appended to the request message. 985 If a client does not receive a DHCP Reply message (Section 5.5) with 986 the same transaction-ID as a pending DHCP Request message within 987 REPLY_MSG_TIMEOUT (see section 8) seconds, or if the received DHCP 988 Reply message contains a DHCP Authentication extension which fails 989 to provide the correct authentication information, the client MUST 990 retransmit the Request with the same transaction-ID and continue to 991 retransmit according to the rules in Section 8. If (after following 992 those rules) the client has not received a Reply message, it SHOULD 993 start over again by multicasting a new DHCP Solicit message to find a 994 different server. 996 If the client receives an ICMP error message in response to such a 997 DHCP Request, it likewise SHOULD start over again by multicasting a 998 new DHCP Solicit message, to find a different server. 1000 If the client transmits a DHCP Request in response to a DHCP 1001 Reconfigure message, further processing is as specified in 1002 Section 5.7. The client can continue to operate with its existing 1003 configuration information and resources until it receives the 1004 corresponding DHCP Reply from the server. The same retransmission 1005 rules apply as for any other DHCP Request message from the client. 1006 When the `N' bit is set, a DHCP Request sent in response to a DHCP 1007 Reconfigure message will not elicit a DHCP Reply message from the 1008 server. 1010 5.5. Receiving DHCP Reply Messages 1012 When a client receives a DHCP Reply message, it MUST check whether 1013 the transaction-ID in the Reply message matches the transaction-ID 1014 of a pending DHCP Request message. If no match is found, the Reply 1015 message MUST be silently discarded. 1017 If the Reply message is acceptable, the client processes each 1018 Extension [15], extracting the relevant configuration information 1019 and parameters for its network operation. The client can determine 1020 when all extensions in the Reply have been processed by using the UDP 1021 Length field of the Reply. Some extensions in the Reply may have 1022 status codes, which indicate to the client the reason for failure 1023 when the server was unable to honor the request. If the server is 1024 unable to honor the request in an extension included by the client, 1025 that extension may simply be omitted from the Reply. The server MAY 1026 also provide the client with configuration parameters the client did 1027 not specifically request. 1029 Some configuration information extracted from the extensions to the 1030 DHCP Reply message MUST remain associated with the server that sent 1031 the message. The particular extensions that require this extra 1032 measure of association with the server are indicated in the DHCP 1033 Extensions document [15]. These "resource-server" associations are 1034 used when sending DHCP Release messages. 1036 5.6. Sending DHCP Release Messages 1038 If a client wishes to ask the server to release all information and 1039 resources relevant to the client, the client SHOULD send a DHCP 1040 Release message without any extensions; this is preferable to sending 1041 a DHCP Request message with the `C' bit set and no extensions. If a 1042 client wishes to retain some of its network configuration parameters, 1043 but determines that others are no longer needed, it SHOULD enable 1044 the server to release allocated resources which are no longer in 1045 use by sending a DHCP Release message to the server, and including 1046 extensions to identify the unneeded items. The client consults its 1047 list of resource-server associations in order to determine which 1048 server should receive the desired Release message. The Release 1049 MUST be transmitted to the server that provided the configuration 1050 parameters. 1052 Suppose a client wishes to release resources which were granted to 1053 it at another IP address. Further, suppose that the client has an 1054 IP address that will still be valid after the server performs the 1055 operations requested in the extensions to the DHCP Release message, 1056 and which has sufficient scope to be reachable from the server. In 1057 that case, and only then, the client MUST set the `D' bit in the DHCP 1058 Release message (see section 4.5). This instructs the server to 1059 send the DHCP Reply directly back to the client at the latter valid 1060 IP address, instead of performing the default processing of sending 1061 the DHCP Reply back through the agent-address included in the DHCP 1062 Release. 1064 5.7. Receiving DHCP Reconfigure Messages 1066 Each client implementation MUST support listening at UDP port 546 to 1067 receive possible DHCP Reconfigure messages; in cases where the client 1068 knows that no Reconfigure message will ever be issued, the client MAY 1069 be configured to avoid executing this supported feature. Any DHCP 1070 Reconfigure message received with a transaction-ID greater than or 1071 equal to 1024 MUST be silently discarded. 1073 In some cases, the IP address at which the client listens will be a 1074 multicast address sent to the client by the server in an extension 1075 to an earlier DHCP Reply message. If the client does not listen for 1076 DHCP Reconfigure messages, it is possible that the client will not 1077 receive notification that its server has deallocated the client's 1078 IP address and/or other resources allocated to the client. See 1079 discussion in 6.5. The client MAY receive a prefix update for one 1080 or more of their addresses and then MUST use that prefix for those 1081 addresses. 1083 If a client receives a DHCP Reconfigure message, it is a request for 1084 the client to send a new DHCP Request to the server which sent the 1085 Reconfigure message. Unless the `N' bit is set, the client MUST 1086 await a DHCP Reply with a matching transaction-ID, retransmitting 1087 (as specified in section 8) until the Reply is received. The server 1088 sending the Reconfigure message MAY be different than the server 1089 which sent a DHCP Reply message containing the original configuration 1090 information. 1092 Reconfigure messages MAY be retransmitted by the server with the same 1093 transaction-ID. 1095 When a client receives a retransmitted unicast Reconfigure message 1096 within XID_TIMEOUT of the last received Reconfigure message with the 1097 same transaction-ID, the client MUST reformulate exactly the same 1098 DHCP Request message and retransmit the request message to the server 1099 again. In this way, the server can make use of the retransmission 1100 algorithm to ensure that a client has received the Reconfigure 1101 message. 1103 When a client receives a retransmitted multicast Reconfigure message 1104 within XID_TIMEOUT of the last received Reconfigure message with 1105 the same transaction-ID, the client MUST not resend the the Request 1106 message if RECONF_MULTICAST_REQUEST_WAIT (see section 8) has not 1107 expired. If RECONF_MULTICAST_REQUEST_WAIT has expired then the 1108 client MUST reformulate exactly the same DHCP Request message and 1109 retransmit the Request message to the server again, and then reset 1110 RECONF_MULTICAST_REQUEST_WAIT to its default value or the value that 1111 was provided from a retransmission extension [15] provided by the 1112 server. In this way, the server can make use of the retransmission 1113 algorithm to ensure that all affected clients have received the 1114 multicast Reconfigure message. 1116 For each Extension which is present in the Reconfigure message, the 1117 client MUST append a matching Extension to its Request message, which 1118 it formulates to send to the server specified in the server-address 1119 field of the message. The client also copies a transaction-ID from 1120 the Reconfigure message into the Request message. Processing for the 1121 Request is the same as specified in Section 5.4, except: 1123 - the client retransmits as stated above in this section 1125 - the client never needs a Relay to send the Request to the DHCP 1126 Server 1128 - the client MUST NOT set the `S' or `R' bits 1130 - if the `N' Bit is set, the client will not get a Reply from the 1131 server 1133 - if the client receives an ICMP error message it should abort the 1134 Reconfigure transaction and log an error message. The client 1135 MUST NOT transmit a DHCP Solicit message in order to rediscover 1136 the IP address of the DHCP Server. 1138 Resources held by the client which are not identified by Extensions 1139 in the server's Reconfigure message are not affected. 1141 A server may ask its client to join a multicast group for the 1142 purpose of receiving DHCP Reconfigure messages. When a Reconfigure 1143 message is delivered to the client by way of the selected multicast 1144 address, the client MUST delay its further response for a random 1145 amount of time uniformly distributed within the interval between 1146 RECONF_MMSG_MIN_RESP and RECONF_MMSG_MAX_RESP seconds (see 1147 section 8). This will minimize the likelihood that the server will 1148 be flooded with DHCP Request messages. 1150 5.8. Interaction with Stateless Address Autoconfiguration 1152 Please refer to the Stateless Address Autoconfiguration Protocol 1153 specification [20] for details regarding the actions taken by clients 1154 upon receiving Router Advertisements with changing values for the `M' 1155 and `O' bits. 1157 6. DHCP Server Considerations 1159 A node which is not a client or relay MUST ignore any DHCP Advertise, 1160 DHCP Reply, or DHCP Reconfigure message it receives. 1162 A server maintains a collection of client records, called 1163 ``bindings''. Each binding is uniquely identifiable by the ordered 1164 pair , since the link-local 1165 address is guaranteed to be unique [20] on the link identified by the 1166 agent-address and prefix. An implementation MUST support bindings 1167 consisting of at least a client's link-local address, agent-address, 1168 preferred lifetime and valid lifetime [20] for each client address. 1170 A server MAY, at the discretion of the network administrator, be 1171 configured so that client bindings are identified by the client's 1172 link-local address, without need to use the additional information 1173 supplied by the agent-address. 1175 A client binding may be used to store any other information, 1176 resources, and configuration data which will be associated with the 1177 client. A server MUST retain its clients' bindings across server 1178 reboots, and, whenever possible, a client should be assigned the 1179 same configuration parameters despite server system reboots and DHCP 1180 server program restarts. A server MUST support fixed or permanent 1181 allocation of configuration parameters to specific clients. 1183 In addition to the client binding a server must maintain an 1184 XID_TIMEOUT binding cache to determine if a previous transaction-ID 1185 is being retransmitted by a client. An implementation of an 1186 XID_TIMEOUT binding cache MUST support at least a tuple consisting of 1187 the client's link-local address, agent-address prefix, IPv6 address, 1188 and XID_TIMEOUT value when the cache entry can be deleted (see 1189 Section 8). 1191 6.1. Receiving DHCP Solicit Messages 1193 If the DHCP Solicit message was received at the All-DHCP-Servers 1194 multicast address, the server MUST check to make sure that the 1195 relay-address is present, and is not a link-local address. If the 1196 relay-address is not present, or if it is a link-local address, 1197 the server MUST silently discard the packet. Note that if the 1198 client sends a DHCP Solicit message from a link-local address, the 1199 multicast destination will be the All-DHCP-Agents address, not the 1200 All-DHCP-Servers address. 1202 When the `C' bit is set in the solicitation, the server deallocates 1203 all resources that match the link-local address and saved 1204 agent-address in the solicitation message, if a binding for the 1205 client can be found. If a client binding cannot be found the server 1206 SHOULD continue to process the Solicit message. 1208 As an optimization, a server processing a Solicit message from relays 1209 MAY check the prefix of the IP source address in the IP header to 1210 determine whether the server has received the Solicit from multiple 1211 relays on the same link. The prefix-size field in the solicitation 1212 enables the server to ascertain when two relay addresses belong to 1213 the same link. 1215 6.2. Sending DHCP Advertise Messages 1217 Upon receiving and verifying the correctness of a DHCP Solicit 1218 message, a server constructs a DHCP Advertise message and transmits 1219 it on the same link as the solicitation was received from. When the 1220 solicitation is received at the All-DHCP-Servers multicast address, 1221 the server SHOULD delay the transmission of its advertisement 1222 for a random amount of time between SERVER_MIN_ADV_DELAY and 1223 SERVER_MAX_ADV_DELAY (see section 8). 1225 If the relay-address is nonzero, the server MUST copy it into the 1226 agent-address field of the advertisement message, and send the 1227 advertisement to the relay-address. Otherwise, the server MUST 1228 send the advertisement to the client's link-local address. An IP 1229 address of the interface on which the server received the Solicit 1230 message MUST appear in the server-address field of the corresponding 1231 advertisement, and the 'S' bit MUST be set. 1233 The server MAY append extensions to the Advertisement, in order to 1234 offer the soliciting node the best possible information about the 1235 available services and resources. 1237 6.3. DHCP Request and Reply Message Processing 1239 DHCP server MUST check to ensure that the client's link-local address 1240 field of the Request message contains a link-local address. If not, 1241 the message MUST be silently discarded. If the `S' bit is set, the 1242 server MUST check that the server-address matches one of its own IP 1243 addresses. If the server-address does not match, the Request message 1244 MUST be silently discarded. 1246 If the received agent-address and link-local address do not 1247 correspond to any binding known to the server, then the server 1248 SHOULD create a new binding for the previously unknown client, 1249 and send a DHCP Reply with any resources allocated to the new 1250 binding. Otherwise, if the server cannot create a new binding, 1251 it SHOULD return a DHCP Reply with a status of ``NoBinding'' (see 1252 Section 2.4). If the client is updating its resources but the 1253 database is temporarily unavailable, the server SHOULD return a DHCP 1254 Reply with a status of ``Unavail'' (see Section 2.4). 1256 While processing the Request, the server MUST first determine whether 1257 or not the Request is a retransmission of an earlier DHCP Request 1258 from the same client. This is done by comparing the transaction-ID 1259 to all those transaction-IDs in the XID_TIMEOUT binding cache 1260 received from the same client during the previous XID_TIMEOUT 1261 seconds. If the transaction-ID is the same as one received during 1262 that time, the server MUST take the same action (e.g., retransmit 1263 the same DHCP Reply to the client) as it did after processing the 1264 previous DHCP Request with the same transaction-ID. 1266 Otherwise, if the server has no record of a message from the client 1267 with the same transaction-ID, the server identifies and allocates 1268 all the relevant information, resources, and configuration data that 1269 is associated with the client. Then it sends that information to 1270 its client by constructing a DHCP Reply message and including the 1271 client's information in DHCP Extensions to the Reply message. The 1272 DHCP Reply message uses the same transaction-ID as found in the 1273 received DHCP Request message. Note that the reply message MAY 1274 contain information not specifically requested by the client. 1276 If the DHCP Request message has the `S' bit set in the message 1277 header, the server MUST send the corresponding DHCP Reply message to 1278 the agent-address found in the Request (see section 7.2). Otherwise, 1279 the server SHOULD send the corresponding DHCP Reply message to the 1280 IP source address in the IP header received from the client Request 1281 message. 1283 6.3.1. Processing for Extensions to DHCP Request and Reply Messages 1285 The DHCP Request may contain extensions [15], which are interpreted 1286 (by default) as advisory information from the client about its 1287 configuration preferences. For instance, if the IP Address Extension 1288 is present, the server SHOULD attempt to allocate or extend the 1289 lifetime of the address indicated by the extension. Some extensions 1290 may be marked by the client as required. 1292 The server may accept some extensions for successful processing and 1293 allocation, while still rejecting others, or it may reject various 1294 extensions for different reasons, and set the status appropriately 1295 for those extensions which return status to the client. The server 1296 sends a single DHCP Reply message in response to each DHCP Request, 1297 with the same transaction-ID as the Request. 1299 Whenever it is able to, the server includes an extension in the 1300 Reply message for every extension sent by the client in the Request 1301 message. If the client requests some extensions that cannot be 1302 supplied by the server, the server can simply fail to provide them, 1303 not including them in the Reply. Other extensions can be rejected 1304 by including them in the Reply with an appropriate status indicating 1305 failure. The server can include extensions in the reply that were 1306 not requested by the client. 1308 6.3.2. Client Requests to Deallocate Unknown Resources 1310 When a client DHCP Request is received that has the `C' bit set, 1311 the server should check to find out whether the extensions listed 1312 in the Request message match those which it has associated with the 1313 client's binding. Any resources which are not indicated by the 1314 client are presumed to be unknown by the client, and thus possible 1315 candidates for reallocation to satisfy requests from other clients. 1316 The server MUST deallocate all resources associated with the client 1317 upon reception of a DHCP Request with the `C' bit set, except for 1318 those which the server is willing to reallocate in response to the 1319 client's request. It may be more efficient to avoid deallocating any 1320 resources until after the list of extensions to the request has been 1321 inspected. 1323 6.4. Receiving DHCP Release Messages 1325 If the server receives a DHCP Release Message, it MUST verify that 1326 the link-local address field of the message contains an address which 1327 could be a valid link-local address (see Section 2.1). If not, the 1328 message MUST be silently discarded. 1330 In response to a DHCP Release Message with a valid client's 1331 link-local address and agent-address, the server formulates a DHCP 1332 Reply message that will be sent back to the releasing client. When 1333 the `D' flag is set, the server MUST send the DHCP Reply back to 1334 the client using the client-address field of the Release message. 1335 Otherwise, if the `D' bit is not set, the server MUST send its DHCP 1336 Reply message (with the `L' bit set) to the agent-address in the 1337 Release message, so that the relay agent can subsequently forward the 1338 Reply back to the releasing client at the client's link-local address 1339 indicated in the Reply message. 1341 If the received agent-address and link-local address do not 1342 correspond to any binding known to the server, then the server SHOULD 1343 return a DHCP Reply, indicating the error by setting the status code 1344 to ``NoBinding'' (see Section 2.4). 1346 Otherwise, if the agent-address and link-local address indicate a 1347 binding known to the server, then the server continues processing the 1348 Release message. If there are any extensions, the server releases 1349 the particular configuration items specified in the extensions. 1350 If there are no extensions, the server releases all configuration 1351 information in the client's binding. 1353 After performing the operations indicated in the DHCP Release message 1354 and its extensions, the server formulates a DHCP Reply message, 1355 copying the transaction-ID from the DHCP Release message. For 1356 each Extension in the DHCP Release message successfully processed 1357 by the server, a matching Extension is appended to the DHCP Reply 1358 message. For extensions in the DHCP Release message which cannot be 1359 successfully processed by the server, a DHCP Reply message containing 1360 extensions with the appropriate status MUST be returned by the 1361 server. If the Release message contains no extensions, the server 1362 does not include any extensions in the corresponding DHCP Reply 1363 message to the client. 1365 6.5. Sending DHCP Reconfigure Messages 1367 If a server needs to change the configuration associated with any 1368 of its clients, it constructs a DHCP Reconfigure message (possibly 1369 including relevant extensions) and sends it to each such client. The 1370 Reconfigure MAY be sent to a multicast address chosen by the server, 1371 which was previously sent to each such client in an extension to a 1372 previous DHCP Reply message. 1374 It may happen that a client does not send a DHCP Request message 1375 after the DHCP Reconfigure message has been issued and retransmitted 1376 RECONF_MSG_MIN_RETRANS times, according to the algorithm specified 1377 in Section 8. This can happen when the client is not listening for 1378 the Reconfigure message, possibly because the client is a mobile 1379 node disconnected from the network, or because the client node 1380 has sustained a power outage or operating system crash. In such 1381 cases, the server SHOULD reserve any resources issued to the client 1382 until the client responds at some future time, until the resource 1383 allocation times out (see section 6.6), or until administrative 1384 intervention causes the resources to be manually returned to use. 1385 The server SHOULD also log a DHCP System Error. 1387 If the server gets another DHCP Request from a client, with a 1388 transaction-ID which does not match that of the recently transmitted 1389 reconfigure message, the server SHOULD send a DHCP Reply to 1390 the client, and wait for RECONF_MSG_RETRANS_INTERVAL, before 1391 retransmitting the DHCP Reconfigure again. 1393 6.6. Client-Resource timeouts 1395 Some resources (for instance, a client's IP address) may only be 1396 allocated to a client for a particular length of time (for instance, 1397 the valid lifetime of an IP address). If the client does not renew 1398 the resource allocation for such a resource, the server MAY make the 1399 resource available for allocation to another client. However, under 1400 administrative control, the server MAY reserve any resources issued 1401 to the client until the client responds at some future time. 1403 7. DHCP Relay Considerations 1405 The DHCP protocol is constructed so that a relay does not have 1406 to maintain any state in order to mediate DHCP client/server 1407 interactions. 1409 The DHCP relay enables clients and servers to carry out DHCP protocol 1410 transactions. DHCP Solicit messages are issued by the relay when 1411 initiated by prospective clients. By default, the relay locates 1412 servers by use of multicasting solicitations to the All-DHCP-Servers 1413 multicast group, but relays SHOULD allow this behavior to be 1414 configurable. The relay MUST be able to determine which of its 1415 interfaces received the client's solicitation message. 1417 7.1. DHCP Solicit and DHCP Advertise Message Processing 1419 Upon receiving a DHCP Solicit message from a prospective client, 1420 a relay, by default, forwards the message to servers at a site 1421 according to the following procedure: 1423 - copying the prospective client's solicitation message fields into 1424 the appropriate fields of the outgoing solicitation, 1426 - copying a non-link-local address of its interface from which the 1427 solicitation was received from the client into the relay-address 1428 field, and 1430 - setting the prefix-size field appropriately, 1432 - by default, setting the hop-count field in the IP header of 1433 the solicitation to the value DEFAULT_SOLICIT_HOPCOUNT (see 1434 section 8). 1436 - setting the IP source address to be a site-local or global-scope 1437 address belonging to the relay's interface on which the client's 1438 original solicitation was received, 1440 - finally, sending the resulting message to one or more servers. 1442 By default, the relay sends solicitations to the All-DHCP-Servers 1443 multicast address, FF05:0:0:0:0:0:1:3. However, the relay MAY be 1444 configured with an alternate server address, or the FQDN of a server. 1445 Methods for automatically updating such alternately configured server 1446 addresses are not specified in this document. 1448 When the relay receives a DHCP advertisement, it relays the 1449 advertisement to the client at the client's link-local address by way 1450 of the interface indicated in the agent's address field. 1452 7.2. DHCP Request Message Processing 1454 When a relay receives a DHCP Request message, it SHOULD check that 1455 the IP source address in the IP header is a link-local address, 1456 that the link-local address matches the link-local address field in 1457 the Request message header, and that the agent-address field of the 1458 message matches an IP address associated with the interface from 1459 which the DHCP Request message was received. If any of these checks 1460 fail, the relay MUST silently discard the Request message. 1462 The relay MUST check whether the `S' bit is set in the message 1463 header. If not, the packet is discarded, and the relay SHOULD 1464 return a DHCP Reply message to the address contained in the client's 1465 link-local address field of the Request message, with status 1466 ``PoorlyFormed'' (see Section 2.4). 1468 If the received request message is acceptable, the relay then 1469 transmits the DHCP Request message to the address of the server found 1470 in the server-address field of the received DHCP Request message. 1471 All of the fields of DHCP Request message transmitted by the relay 1472 are copied over unchanged from the DHCP Request received from the 1473 client. Only the fields in the IP header will differ from the 1474 packet received from the client. All relays MUST send DHCP Request 1475 messages using the source IP address from the interface where the 1476 DHCP request was received. If the Relay receives an ICMP error, the 1477 Relay SHOULD return a DHCP Reply message to the client address (which 1478 can be found in the payload of the ICMP message [5]), with status 1479 ``ICMPError'' (see Section 2.4), along with the DHCP Relay ICMP Error 1480 extension [15]. 1482 7.3. DHCP Reply Message Processing 1484 When the relay receives a DHCP Reply, it MUST check that the message 1485 has the `L' bit set. It MUST check that the client's link-local 1486 address field contains a link-local address. If either check fails, 1487 the packet MUST be silently discarded. If both checks are satisfied, 1488 the relay MUST send a DHCP Reply message to the link-local address 1489 listed in the received Reply message. Only the fields in the IP 1490 header will differ from the packet received from the server, not the 1491 payload. 1493 8. Retransmission and Configuration Variables 1495 When a client does not receive a DHCP Reply in response to a pending 1496 DHCP Request, the client MUST retransmit the identical DHCP Request, 1497 with the same transaction-ID, to the same server again until it can 1498 be reasonably sure that the server is unavailable and an alternative 1499 can be chosen. The DHCP server assumes that the client has received 1500 the configuration information included with the extensions to the 1501 DHCP Reply message, and it is up to the client to continue to try for 1502 a reasonable amount of time to complete the transaction. All the 1503 actions specified for DHCP Request in this section hold also for DHCP 1504 Release messages sent by the client. 1506 Similarly, when a client sends a DHCP Request message in response to 1507 a Reconfigure message from the server, the client assumes that the 1508 DHCP server has received the Request. The server MUST retransmit 1509 the identical DHCP Reconfigure to the client a reasonable number 1510 of times to try to elicit the Request message from the client. 1511 If no corresponding DHCP Request is received by the server after 1512 REQUEST_MSG_MIN_RETRANS retransmissions, the server MAY erase or 1513 deallocate information as needed from the client's binding, but see 1514 section 6.5. 1516 Retransmissions occur using the following configuration variables 1517 for a DHCP implementation. These configuration variables MUST be 1518 configurable by a client or server: 1520 CLIENT_ADV_WAIT 1522 The minimum amount of time a client waits to receive DHCP 1523 Advertisements after transmitting a DHCP Solicit to the 1524 All-DHCP Agents multicast address (see section 5.3). 1526 Default: 2 seconds 1528 DEFAULT_SOLICIT_HOPCOUNT 1530 The default hop-count used in the IP header by DHCP relays when 1531 sending DHCP Solicit messages on behalf of a client. 1533 Default: 4 1535 SERVER_MIN_ADV_DELAY 1537 The minimum amount of time a server waits to transmit a 1538 DHCP Advertisement after receiving a DHCP Solicit at the 1539 All-DHCP-Servers or All-DHCP-Agents multicast address. 1541 Default: 100 milliseconds 1543 SERVER_MAX_ADV_DELAY 1545 The maximum amount of time a server waits to transmit a DHCP 1546 Advertisement after receiving a DHCP Solicit at the All-DHCP 1547 Agents multicast address. 1549 Default: 1 second 1551 REPLY_MSG_TIMEOUT 1553 The time in seconds that a client waits to receive a server's 1554 DHCP Reply before retransmitting a DHCP Request. The 1555 client MUST multiply REPLY_MSG_TIMEOUT by a factor of 2 in 1556 an exponential manner for each time it retransmits until 1557 REQUEST_MSG_MIN_RETRANS (below) is attained. A client MAY be 1558 configured to attempt 2 retransmissions before beginning the 1559 exponential backoff retransmission in the previous sentence. 1561 Default: 2 seconds. 1563 REQUEST_MSG_MIN_RETRANS 1565 The minimum number of DHCP Request transmissions that a client 1566 should retransmit, before aborting the request. 1568 Default: 10 retransmissions. 1570 RECONF_MSG_MIN_RETRANS 1572 The minimum number of DHCP Reconfigure messages that a 1573 server should retransmit, before assuming the the client is 1574 unavailable. 1576 Default: 10 retransmissions. 1578 RECONF_MSG_RETRANS_INTERVAL 1580 The least time in seconds that a server waits for a 1581 client's DHCP Request before each retransmission of the DHCP 1582 Reconfigure. 1584 Default: 12 seconds. 1586 RECONF_MMSG_MIN_RESP 1588 The minimum amount of time before a client can respond to a 1589 DHCP Reconfigure message sent to a multicast address. 1591 Default: 2 seconds. 1593 RECONF_MMSG_MAX_RESP 1595 The maximum amount of time before a client MUST respond to a 1596 DHCP Reconfigure message sent to a multicast address. 1598 Default: 10 seconds. 1600 RECONF_MULTICAST_REQUEST_WAIT 1602 The time a client should wait before retransmitting a Request 1603 message in reponse to a retransmitted multicast Reconfigure 1604 message. 1606 Default: 120 seconds 1608 MIN_SOLICIT_DELAY 1610 The minimum amount of time a prospective client is required to 1611 wait, after determining from a Router Advertisement message 1612 that the client should perform stateful address configuration, 1613 before sending a DHCP Solicit to a server. 1615 Default: 1 second 1617 MAX_SOLICIT_DELAY 1619 The maximum amount of time a prospective client is required to 1620 wait, after determining from a Router Advertisement message 1621 that the client should perform stateful address configuration, 1622 before sending a DHCP Solicit to a server. 1624 Default: 5 seconds 1626 XID_TIMEOUT 1628 The amount of time a DHCP server has to keep track of 1629 client transaction-IDs in order to make sure that client 1630 retransmissions using the same transaction-ID are idempotent. 1632 Default: 600 seconds 1634 9. Security Considerations 1636 Clients and servers often have to authenticate the messages they 1637 exchange. For instance, a server may wish to be certain that a DHCP 1638 Request originated from the client identified by the fields included within the Request message 1640 header. Conversely, it is quite often essential for a client to 1641 be certain that the configuration parameters and addresses it has 1642 received were sent to it by an authoritative server. Similarly, a 1643 server should only accept a DHCP Release message which seems to be 1644 from one of its clients, if it has some assurance that the client 1645 actually did transmit the Release message. Again, a client might 1646 wish to only accept DHCP Reconfigure messages that are certain to 1647 have originated from a server with authority to issue them. 1649 The IPv6 Authentication Header can provide security for DHCPv6 1650 messages when both endpoints have a suitable IP address. However, 1651 a client often has only a link-local address, and such an address 1652 is not sufficient for a server which is off-link. In those 1653 circumstances the DHCP relay is involved, so that the DHCP message 1654 MUST have the relay's address in the IP destination address field, 1655 even though the client aims to deliver the message to the server. 1656 The DHCP Client-Server Authentication Extension [15] is intended to 1657 be used in these circumstances. 1659 Note that, if a client receives a DHCP message which fails 1660 authentication, it should continue to wait for another message which 1661 might be correctly authenticated just as if the failed message had 1662 never arrived; however, receiving such failed messages SHOULD be 1663 logged. 1665 10. Year 2000 considerations 1667 Since all times are relative to the current time of the transaction, 1668 there is no problem within the DHCPv6 protocol related to any 1669 hardcoded dates or two-digit representation of the current year. 1671 11. IANA Considerations 1673 This document defines message types 1-7 to be received by UDP at port 1674 numbers 546 and 547. Additional message types may be defined in the 1675 future. 1677 Section 3.3 specifies the use of several multicast groups, with 1678 multicast addresses FF02:0:0:0:0:0:1:2, FF05:0:0:0:0:0:1:3, and 1679 FF05:0:0:0:0:0:1:4. 1681 This document also defines several status codes that are to be 1682 returned with the DHCP Reply message (see section 4.4). The nonzero 1683 values for these status codes which are currently specified are shown 1684 in section 2.4. 1686 There is a DHCPv6 extension [15] which allows clients and servers to 1687 exchange values for some of the timing and retransmission parameters 1688 defines in section 8. Adding new parameters in the future would 1689 require extending the values by which the parameters are indicated in 1690 the DHCP extension. Since there needs to be a list kept, the default 1691 values for each parameter should also be stored as part of the list. 1693 All of these protocol elements may be specified to assume new values 1694 at some point in the future. New values should be approved by the 1695 process of IETF Consensus [12]. 1697 12. Acknowledgements 1699 Thanks to the DHC Working Group for their time and input into the 1700 specification. Ralph Droms and Thomas Narten have had a major 1701 role in shaping the continued improvement of the protocol by their 1702 careful reviews. Many thanks to Matt Crawford, Erik Nordmark, Gerald 1703 Maguire, and Mike Carney for their studied review as part of the 1704 Last Call process. Thanks also for the consistent input, ideas, and 1705 review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov 1706 Rekhter, Matt Thomas, Sue Thomson, and Phil Wells. 1708 Thanks to Steve Deering and Bob Hinden, who have consistently 1709 taken the time to discuss the more complex parts of the IPv6 1710 specifications. 1712 A. Changes for this revision 1714 - Fixed grammatical and clarity problems. 1716 - Added saved agent-address field to the solicit message and 1717 altered and enhanced references to the C bit use. 1719 - Removed all references of agent-address prefix as it is implied 1720 by the agent-address and can be used as such by implementors. 1722 - Verified all binding dependencies use the link-local address and 1723 agent-address. 1725 - Added clients in what cases SHOULD retain specific addresses when 1726 the client is not stationary. 1728 - Updated DHCP terminology section and re-ordered. 1730 - Put RFC 2119 terms in lower case, in section 3.1. 1732 - Changed definition of transaction-ID and specified ranges for 1733 client and server use. 1735 - Added and fixed text to clarify use of Reconfigure message for 1736 clients in all relevant sections. 1738 - Added words in spec to differentiate format section from 1739 processing section. 1741 - Added retransmission algorithm for Reconfigure multicast messages 1742 and new configuration parameter. 1744 - Differentiated processing for requests by clients when received 1745 from Reconfigure message. 1747 - Added more words when binding cache is used for XID timeout. 1749 - Added exponential backoff to client retransmissions. 1751 - Updated the references section. 1753 B. Related Protocol Specifications 1755 Related work in IPv6 that would best serve an implementor to study 1756 is the IPv6 Specification [7], the IPv6 Addressing Architecture [9], 1757 IPv6 Stateless Address Autoconfiguration [20], IPv6 Neighbor 1758 Discovery Processing [14], and Dynamic Updates to DNS [22]. These 1759 specifications enable DHCP to build upon the IPv6 work to provide 1760 both robust stateful autoconfiguration and autoregistration of DNS 1761 Host Names. 1763 The IPv6 Specification provides the base architecture and design of 1764 IPv6. A key point for DHCP implementors to understand is that IPv6 1765 requires that every link in the internet have an MTU of 1500 octets 1766 or greater (in IPv4 the requirement is 68 octets). This means that 1767 a UDP packet of 536 octets will always pass through an internet 1768 (less 40 octets for the IPv6 header), as long as there are no IP 1769 options prior to the UDP header in the packet. But, IPv6 does not 1770 support fragmentation at routers, so that fragmentation takes place 1771 end-to-end between hosts. If a DHCP implementation needs to send a 1772 packet greater than 1500 octets it can either fragment the UDP packet 1773 into fragments of 1500 octets or less, or use Path MTU Discovery [11] 1774 to determine the size of the packet that will traverse a network 1775 path. It is implementation dependent how this is accomplished in 1776 DHCP. Path MTU Discovery for IPv6 is supported for both UDP and TCP 1777 and can cause end-to-end fragmentation when the PMTU changes for a 1778 destination. 1780 The IPv6 Addressing Architecture specification [9] defines the 1781 address scope that can be used in an IPv6 implementation, and the 1782 various configuration architecture guidelines for network designers 1783 of the IPv6 address space. Two advantages of IPv6 are that support 1784 for multicast is required, and nodes can create link-local addresses 1785 during initialization. This means that a client can immediately use 1786 its link-local address and a well-known multicast address to begin 1787 communications to discover neighbors on the link. For instance, a 1788 client can send a DHCP Solicit and locate a server or relay. 1790 IPv6 Stateless Address Autoconfiguration [20] (Addrconf) specifies 1791 procedures by which a node may autoconfigure addresses based on 1792 router advertisements [14], and the use of a valid lifetime to 1793 support renumbering of addresses on the Internet. In addition the 1794 protocol interaction by which a node begins stateless or stateful 1795 autoconfiguration is specified. DHCP is one vehicle to perform 1796 stateful autoconfiguration. Compatibility with Addrconf is a design 1797 requirement of DHCP (see Section 3.1). 1799 IPv6 Neighbor Discovery [14] is the node discovery protocol in IPv6 1800 which replaces and enhances functions of ARP [16]. To understand 1801 IPv6 and Addrconf it is strongly recommended that implementors 1802 understand IPv6 Neighbor Discovery. 1804 Dynamic Updates to DNS [22] is a specification that supports the 1805 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 1806 the dynamic updates to DNS to integrate addresses and name space to 1807 not only support autoconfiguration, but also autoregistration in 1808 IPv6. The security model to be used with DHCPv6 should conform as 1809 closely as possible to the authentication model outlined in [10]. 1811 C. Comparison between DHCPv4 and DHCPv6 1813 This appendix is provided for readers who will find it useful to see 1814 a model and architecture comparison between DHCPv4 [8, 1] and DHCPv6. 1815 There are three key reasons for the differences: 1817 o IPv6 inherently supports a new model and architecture for 1818 communications and autoconfiguration of addresses. 1820 o DHCPv6 benefits from the new IPv6 features. 1822 o New features were added to support the expected evolution and 1823 the existence of more complicated Internet network service 1824 requirements. 1826 IPv6 Architecture/Model Changes: 1828 o The link-local address permits a node to have an address 1829 immediately when the node boots, which means all clients have a 1830 source IP address at all times to locate a server or relay agent 1831 on the local link. 1833 o The need for BOOTP compatibility and broadcast flags is removed. 1835 o Multicast and address scoping in IPv6 permit the design of 1836 discovery packets that would inherently define their range by the 1837 multicast address for the function required. 1839 o Stateful autoconfiguration has to coexist and integrate with 1840 stateless autoconfiguration supporting Duplicate Address 1841 Detection and the two IPv6 lifetimes, to facilitate the dynamic 1842 renumbering of addresses and the management of those addresses. 1844 o Multiple addresses per interface are inherently supported in 1845 IPv6. 1847 o Many DHCPv4 options are unnecessary now because the configuration 1848 parameters are either obtained through IPv6 Neighbor Discovery or 1849 the Service Location protocol [21]. 1851 DHCPv6 Architecture/Model Changes: 1853 o The message type is the first byte in the packet. 1855 o IPv6 Address allocations are now handled in a message extension 1856 as opposed to the message header. 1858 o Client/Server bindings are now mandatory and take advantage of 1859 the client's link-local address to always permit communications 1860 either directly from an on-link server, or from a remote server 1861 through an on-link relay-agent. 1863 o Servers are discovered by a client solicit, followed by a server 1864 or relay-agent advertisement. 1866 o The client will know if the server is on-link or off-link. 1868 o The on-link relay-agent locates remote server addresses from 1869 system configuration or by the use of a site wide multicast 1870 packet. 1872 o ACKs and NAKs are not used. 1874 o The server assumes the client receives its responses unless it 1875 receives a retransmission of the same client request. This 1876 permits recovery in the case where the network has faulted. 1878 o Clients can issue multiple, unrelated DHCP Request messages to 1879 the same or different servers. 1881 o The function of DHCPINFORM is inherent in the new packet design; 1882 a client can request configuration parameters other than IPv6 1883 addresses in the optional extension headers. 1885 o Clients MUST listen to their UDP port for the new Reconfigure 1886 message from servers. 1888 o New extensions have been defined. 1890 With the changes just enumerated, we can support new user features, 1891 including 1893 o Configuration of Dynamic Updates to DNS 1895 o Address deprecation, for dynamic renumbering. 1897 o Relays can be preconfigured with server addresses, or use of 1898 multicast. 1900 o Authentication 1902 o Clients can ask for multiple IP addresses. 1904 o Addresses allocated with too-long lifetimes can be reclaimed 1905 using the Reconfigure message. 1907 o Integration between stateless and stateful address 1908 autoconfiguration. 1910 o Enabling relay-agents to locate remote servers for a link. 1912 D. Full Copyright Statement 1914 Copyright (C) The Internet Society (1998). All Rights Reserved. 1916 This document and translations of it may be copied and furnished to 1917 others, and derivative works that comment on or otherwise explain it 1918 or assist in its implementation may be prepared, copied, published 1919 and distributed, in whole or in part, without restriction of any 1920 kind, provided that the above copyright notice and this paragraph 1921 are included on all such copies and derivative works. However, 1922 this document itself may not be modified in any way, such as by 1923 removing the copyright notice or references to the Internet Society 1924 or other Internet organizations, except as needed for the purpose 1925 of developing Internet standards in which case the procedures 1926 for copyrights defined in the Internet Standards process must be 1927 followed, or as required to translate it into languages other than 1928 English. 1930 The limited permissions granted above are perpetual and will not be 1931 revoked by the Internet Society or its successors or assigns. 1933 This document and the information contained herein is provided on an 1934 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1935 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1936 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1937 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1938 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1940 References 1942 [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 1943 Extensions. RFC 2132, March 1997. 1945 [2] S. Bradner. Key Words for Use in RFCs to Indicate Requirement 1946 Levels. RFC 2119, March 1997. 1948 [3] S. Bradner and A. Mankin. The Recommendation for the IP Next 1949 Generation Protocol. RFC 1752, January 1995. 1951 [4] A. Conta and S. Deering. Internet Control Message Protocol 1952 (ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885, 1953 December 1995. 1955 [5] A. Conta and S. Deering. RFC 2463: Internet Control Message 1956 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1957 Specification, December 1998. Obsoletes RFC1885 [4]. Status: 1958 DRAFT STANDARD. 1960 [6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1961 Specification. RFC 1883, December 1995. 1963 [7] S. Deering and R. Hinden. RFC 2460: Internet Protocol, Version 1964 6 (IPv6) specification, December 1998. Obsoletes RFC1883 [6]. 1965 Status: DRAFT STANDARD. 1967 [8] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March 1968 1997. 1970 [9] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 1971 RFC 2373, July 1998. 1973 [10] S. Kent and R. Atkinson. RFC 2402: IP authentication header, 1974 November 1998. Status: PROPOSED STANDARD. 1976 [11] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP 1977 version 6. RFC 1981, August 1996. 1979 [12] T. Narten and H. Alvestrand. RFC 2434: Guidelines for writing 1980 an IANA considerations section in RFCs, October 1998. Status: 1981 BEST CURRENT PRACTICE. 1983 [13] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 1984 IP version 6 (IPv6). RFC 1970, August 1996. 1986 [14] T. Narten, E. Nordmark, and W. Simpson. RFC 2461: Neighbor 1987 discovery for IP Version 6 (IPv6), December 1998. Obsoletes 1988 RFC1970 [13]. Status: DRAFT STANDARD. 1990 [15] C. Perkins. Extensions for the Dynamic Host Configuration 1991 Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-11.txt, February 1992 1999. (work in progress). 1994 [16] David C. Plummer. An Ethernet Address Resolution Protocol: 1995 Or Converting Network Protocol Addresses to 48.bit Ethernet 1996 Addresses for Transmission on Ethernet Hardware. RFC 826, 1997 November 1982. 1999 [17] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 2001 [18] J. B. Postel, Editor. Internet Protocol. RFC 791, September 2002 1981. 2004 [19] S. Thomson and T. Narten. IPv6 Stateless Address 2005 Autoconfiguration. RFC 1971, August 1996. 2007 [20] S. Thomson and T. Narten. RFC 2462: IPv6 stateless address 2008 autoconfiguration, December 1998. Obsoletes RFC1971 [19]. 2009 Status: DRAFT STANDARD. 2011 [21] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 2012 Location Protocol. RFC 2165, July 1997. 2014 [22] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates 2015 in the Domain Name System (DNS). RFC 2136, April 1997. 2017 Chair's Address 2019 The working group can be contacted via the current chair: 2021 Ralph Droms 2022 Computer Science Department 2023 323 Dana Engineering 2024 Bucknell University 2025 Lewisburg, PA 17837 2027 Phone: (717) 524-1145 2028 E-mail: droms@bucknell.edu 2030 Author's Address 2032 Questions about this memo can be directed to: 2034 Jim Bound Charles E. Perkins 2035 Compaq Computer Corporation Sun Microsystems Laboratories 2036 110 Spitbrook Road, ZKO3-3/U14 15 Network Circle 2037 Nashua, NH 03062 Menlo Park, CA 94025 2038 USA USA 2040 Phone: +1-603-884-0400 Phone: +1 650 786-6464 2041 EMail: bound@zk3.dec.com EMail: cperkins@eng.sun.com 2042 Fax: +1 650 786-6445