idnits 2.17.1 draft-ietf-dhc-dhcpv6-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 4 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-11.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- No information found for rfcdraft-ietf-dhc-dhcpv6-11.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 (13 March 1998) is 9540 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1885 (ref. '5') (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 1883 (ref. '6') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1884 (ref. '8') (Obsoleted by RFC 2373) == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-auth-header-03 ** Obsolete normative reference: RFC 1981 (ref. '10') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 1970 (ref. '11') (Obsoleted by RFC 2461) -- No information found for draft-ietf-dhc-dhcpv6ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '12' ** Obsolete normative reference: RFC 1971 (ref. '16') (Obsoleted by RFC 2462) == Outdated reference: A later version (-01) exists of draft-ietf-ipngwg-addrconf-v2-00 Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 7 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 Digital Equipment Corp. 4 DHC Working Group C. Perkins 5 Obsoletes: draft-ietf-dhc-dhcpv6-11.txt Sun Microsystems 6 13 March 1998 8 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 9 draft-ietf-dhc-dhcpv6-12.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. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at 27 any time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 To view the entire list of current Internet-Drafts, please check 31 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 32 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 33 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 34 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 36 Distribution of this memo is unlimited. 38 Abstract 40 The Dynamic Host Configuration Protocol (DHCPv6) provides a framework 41 for passing configuration information, via extensions, to IPv6 nodes. 42 It offers the capability of automatic allocation of reusable network 43 addresses and additional configuration flexibility. This protocol 44 should be considered a stateful counterpart to the IPv6 Stateless 45 Address Autoconfiguration protocol specification, and can be used 46 separately or together with the latter to obtain configuration 47 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 . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Protocol Design Model 5 64 3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. DHCP Messages . . . . . . . . . . . . . . . . . . . . . . 6 66 3.3. Request/Response Processing Model . . . . . . . . . . . . 7 68 4. DHCP Message Formats and Field Definitions 9 69 4.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 9 70 4.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 10 71 4.3. DHCP Request Message Format . . . . . . . . . . . . . . . 11 72 4.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 13 73 4.5. DHCP Release Message Format . . . . . . . . . . . . . . . 14 74 4.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 16 76 5. DHCP Client Considerations 16 77 5.1. Verifying Resource Allocations After Restarts . . . . . . 17 78 5.2. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 17 79 5.3. Receiving DHCP Advertise Messages . . . . . . . . . . . . 18 80 5.4. Sending DHCP Request Messages . . . . . . . . . . . . . . 19 81 5.5. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 20 82 5.6. Sending DHCP Release Messages . . . . . . . . . . . . . . 21 83 5.7. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 21 84 5.8. Interaction with Stateless Address Autoconfiguration . . 23 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 . . . . . . . . . . . . . . 29 102 8. Retransmission and Configuration Variables 30 104 9. Security Considerations 33 106 10. Year 2000 considerations 33 108 11. Acknowledgements 34 110 A. Changes for this revision 34 112 B. Related Work in IPv6 35 114 C. Comparison between DHCPv4 and DHCPv6 36 116 Chair's Address 41 118 Author's Address 41 119 1. Introduction 121 The Dynamic Host Configuration Protocol (DHCPv6, or in this 122 document usually DHCP) provides configuration parameters to Internet 123 nodes. DHCP consists of a protocol for delivering node-specific 124 configuration parameters from a DHCP server to a client, and a 125 mechanism for allocation of network addresses and other related 126 parameters to IPv6 [6] nodes. 128 DHCP is built on a client-server model, where designated DHCP servers 129 allocate network addresses and automatically deliver configuration 130 parameters to dynamically configurable clients. Throughout the 131 remainder of this document, the term "server" refers to a node 132 providing initialization parameters by way of the DHCP protocol, 133 and the term "client" refers to a node requesting initialization 134 parameters from a DHCP server. 136 Since it is typically impractical to deploy a DHCP server on 137 each network on which DHCP clients are to be served, a DHCP relay 138 function is defined to assist clients in finding DHCP servers, 139 and in delivering packets for clients that do not have sufficient 140 address scope to complete a transaction with a DHCP server on another 141 network. Either a DHCP server or a DHCP relay is required to be 142 present on every network on which DHCP clients will need to be 143 served. 145 DHCPv6 uses Request and Reply messages to support a client/server 146 processing model whereby both client and server are assured that 147 requested configuration parameters have been received and accepted 148 by the client. DHCP supports optional configuration parameters and 149 processing for nodes through extensions described in its companion 150 document ``Extensions for the Dynamic Host Configuration Protocol for 151 IPv6'' [12]. DHCP only provides a mechanism, but does not provide 152 any policy with respect to parameter and resource assignments. 154 The IPv6 Addressing Architecture [8] and IPv6 Stateless Address 155 Autoconfiguration [16] specifications provide new features not 156 available in IP version 4 (IPv4) [15], which are used to simplify 157 and generalize the operation of DHCP clients. This document is 158 intended to complement those specifications for clients attached to 159 the kinds of Internet media for which those specifications apply. In 160 particular, the specification in this document does not necessarily 161 apply to nodes which do not enjoy a broadcast link to the Internet. 163 Section 2 provides definitions for terminology used throughout 164 this document. Section 3 provides an overview of the protocol 165 design model that guided the design choices in the specification; 166 section 3.2 briefly describes the protocol messages and their 167 semantics. Section 4 provides the message formats and field 168 definitions used for each message. Sections 5, 6, and 7 specify 169 how clients, servers, and relays interact. The timeout and 170 retransmission guidelines and configuration variables are discussed 171 in Section 8. Appendix B summarizes related work in IPv6 that will 172 provide helpful context; it is not part of this specification, but 173 included for informational purposes. Appendix C discusses the 174 differences between DHCPv4 and DHCPv6. 176 2. Terminology and Definitions 178 Relevant terminology from the IPv6 Protocol [6], IPv6 Addressing 179 Architecture [8], and IPv6 Stateless Address Autoconfiguration [16] 180 will be provided, and then the DHCPv6 terminology. 182 2.1. IPv6 Terminology 184 address An IP layer identifier for an interface or a set of 185 interfaces. 187 unicast address 188 An identifier for a single interface. A packet sent 189 to a unicast address is delivered to the interface 190 identified by that address. 192 multicast address 193 An identifier for a set of interfaces (typically 194 belonging to different nodes). A packet sent to a 195 multicast address is delivered to all interfaces 196 identified by that address. 198 host Any node that is not a router. 200 IP Internet Protocol Version 6 (IPv6). The terms IPv4 and 201 IPv6 are used only in contexts where it is necessary to 202 avoid ambiguity. 204 interface 205 A node's attachment to a link. 207 link A communication facility or medium over which nodes 208 can communicate at the link layer, i.e., the layer 209 immediately below IP. Examples are Ethernet (simple or 210 bridged); Token Ring; PPP links, X.25, Frame Relay, or 211 ATM networks; and internet (or higher) layer "tunnels", 212 such as tunnels over IPv4 or IPv6 itself. 214 link-layer identifier 215 a link-layer identifier for an interface. Examples 216 include IEEE 802 addresses for Ethernet or Token Ring 217 network interfaces, and E.164 addresses for ISDN links. 219 link-local address 220 An IP address having link-only scope, indicated by 221 having the routing prefix FE80::0000/64), that can be 222 used to reach neighboring nodes attached to the same 223 link. Every interface has a link-local address. 225 message A unit of data carried in a packet, exchanged between 226 DHCP agents and clients. 228 neighbor A node attached to the same link. 230 node A device that implements IP. 232 packet An IP header plus payload. 234 prefix A bit string that consists of some number of initial 235 bits of an address. 237 router A node that forwards IP packets not explicitly 238 addressed to itself. 240 2.2. DHCPv6 Terminology 242 Agent Address 243 The address of a DHCP agent (server or relay). 245 binding A binding (or, client binding) in DHCP contains the 246 data which a DHCP server maintains for each of its 247 clients (see Section 6). 249 resource-server association 250 An association between a resource and a DHCP server 251 maintained by the client which received that resource 252 from that DHCP server. 254 configuration parameter 255 Any parameter that can be used by a node to configure 256 its network subsystem and enable communication on a 257 link or internetwork. 259 DHCP agent (or agent) 260 Either a DHCP server or a DHCP relay. 262 DHCP client (or client) 263 A node that initiates requests on a link to obtain 264 configuration parameters. 266 DHCP relay (or relay) 267 A node that acts as an intermediary to deliver DHCP 268 messages between clients and servers. 270 DHCP server (or server) 271 A server is a node that responds to requests from 272 clients to provide: addresses, prefix lengths, or 273 other configuration parameters. 275 transaction-ID 276 The transaction-ID is a monotonically increasing 277 unsigned integer identifier specified by the client 278 or server, and used to match a response to a pending 279 message. 281 2.3. Specification Language 283 In this document, several words are used to signify the requirements 284 of the specification, in accordance with RFC 2119 [2]. These words 285 are often capitalized. 287 MUST This word, or the adjective "required", means that 288 the definition is an absolute requirement of the 289 specification. 291 MUST NOT This phrase means that the definition is an absolute 292 prohibition of the specification. 294 SHOULD This word, or the adjective "recommended", means 295 that there may exist valid reasons in particular 296 circumstances to ignore this item, but the full 297 implications must be understood and carefully 298 weighed before choosing a different course. 299 Unexpected results may result otherwise. 301 MAY This word, or the adjective "optional", means that 302 this item is one of an allowed set of alternatives. 303 An implementation which does not include this option 304 MUST be prepared to interoperate with another 305 implementation which does include the option. 307 silently discard 308 The implementation discards the packet without 309 further processing, and without indicating an error 310 to the sender. The implementation SHOULD provide 311 the capability of logging the error, including the 312 contents of the discarded packet, and SHOULD record 313 the event in a statistics counter. 315 2.4. Error Values 317 This specification document uses symbolic names for the errors known 318 to DHCP clients and servers, as used for instance in the status field 319 of the DHCP Reply message (see section 4.4). The symbolic names have 320 the actual values listed below: 322 Message Name Value 324 UnspecFailure 16 325 BadAuth 17 326 Unavail 19 327 NoBinding 20 328 InvalidSource 21 329 NoServer 23 330 BadCharset 24 331 ICMPError 64 333 3. Protocol Design Model 335 This section is provided for implementors to understand the DHCPv6 336 protocol design model from an architectural perspective. Goals and 337 conceptual models are presented in this section. 339 3.1. Design Goals 341 The following list gives general design goals for this DHCP 342 specification. 344 - DHCP should be a mechanism rather than a policy. DHCP MUST allow 345 local system administrators control over configuration parameters 346 where desired; e.g., local system administrators should be able 347 to enforce local policies concerning allocation and access to 348 local resources where desired. 350 - DHCP MUST NOT introduce any requirement for manual configuration 351 of DHCP clients, except when security requirements need 352 authentication or encryption keys. Each node should be able to 353 obtain appropriate local configuration parameters without user 354 intervention, and incorporate those parameters into its own 355 configuration. 357 - DHCP MUST NOT require a server on each link. To allow for scale 358 and economy, DHCP MUST work across DHCP relays. 360 - A DHCP client MUST be prepared to receive multiple (possibly 361 different) responses to solicitations for DHCP servers. Some 362 installations may include multiple, overlapping DHCP servers to 363 enhance reliability and/or to increase performance. 365 - DHCP MUST coexist with statically configured, non-participating 366 nodes and with existing network protocol implementations. 368 - DHCPv6 MUST be compatible with IPv6 Stateless Address 369 Autoconfiguration [16]. 371 - A DHCPv6 Client implementation MAY be started in the absence of 372 any IPv6 routers on the client's link. 374 - DHCP architecture MUST support the requirements of automated 375 renumbering of IP addresses [3]. 377 - DHCP servers SHOULD be able to support Dynamic Updates to 378 DNS [19]. 380 - DHCP servers MUST be able to support multiple IPv6 addresses for 381 each client. 383 - DHCP MUST work on isolated network links, as long as a DHCP 384 server is present on the link. 386 - A DHCP server to server protocol is NOT part of this 387 specification. 389 - It is NOT a design goal of DHCP to specify how a server 390 configuration parameter database is maintained or determined. 391 Methods for configuring DHCP servers are outside the scope of 392 this document. 394 3.2. DHCP Messages 396 Each DHCP message contains a type, which defines its function 397 within the protocol. Processing details for these DHCP messages are 398 specified in Sections 5, 6, and 7. The specified message types are 399 as follows: 401 01 DHCP Solicit 403 The DHCP Solicit message is an IP multicast message sent by a 404 DHCP client to one or more DHCP agents. 406 02 DHCP Advertise 408 The DHCP Advertise is an IP unicast message sent by a DHCP 409 Agent in response to a DHCP client's DHCP Solicit message. 411 03 DHCP Request 413 The DHCP Request is an IP unicast message sent by a DHCP client 414 to a DHCP server to request configuration parameters on a 415 network. 417 04 DHCP Reply 419 The DHCP Reply is an IP unicast message sent by a DHCP server 420 in response to a client's DHCP Request, or by the DHCP relay 421 that relayed that client's DHCP Request. Extensions [12] to 422 the DHCP Reply describe the resources that the DHCP server has 423 committed and allocated to this client, and may contain other 424 information for use by this client. 426 05 DHCP Release 428 The DHCP Release is an IP unicast message sent by a DHCP 429 client to inform the DHCP server that the client is releasing 430 resources. 432 06 DHCP Reconfigure 434 The DHCP Reconfigure is an IP unicast or multicast message sent 435 by a DHCP server to inform one or more clients that the server 436 has new configuration information of importance. Each client 437 is expected to initiate a new Request/Reply transaction. 439 DHCP message types not defined here (msg-types 0 and 7-255) are 440 reserved and SHOULD be silently ignored. 442 3.3. Request/Response Processing Model 444 The request/response processing for DHCPv6 is transaction based and 445 uses a set of best-effort messages to complete the transaction. 447 To find a server, a client sends a DHCP Solicit message from the 448 interface which it wishes to configure. The client then awaits 449 a DHCP Advertise message, which will provide an IP address of a 450 DHCP server. Transactions are started by a client with a DHCP 451 Request, which may be issued after the client knows the server's 452 address. The response (DHCP Reply) is sent from the server (possibly 453 via a DHCP Relay). At this point in the flow all data has been 454 transmitted and is presumed to have been received. To provide a 455 method of recovery if either the client or server do not receive the 456 messages to complete the transaction, the client retransmits each 457 DHCP Request message until it elicits the corresponding DHCP Reply, 458 or until it can be reasonably certain that the desired DHCP server 459 is unavailable, or it determines that it does not want a response 460 (i.e., it MAY abort the transaction). The timeout and retransmission 461 guidelines and configuration variables are discussed in Section 8. 463 DHCP uses the UDP [14] protocol to communicate between clients and 464 servers. UDP is not reliable, but the DHCP retransmission scheme 465 in the referenced section provides reliability between clients and 466 servers. The following well-known multicast addresses are used by 467 DHCP agents and clients: 469 FF02:0:0:0:0:0:1:2 470 All DHCP Agents (Servers and Relays) MUST join the 471 link-local All-DHCP-Agents multicast group at the address 472 FF02:0:0:0:0:0:1:2. 474 FF05:0:0:0:0:0:1:3 475 All DHCP servers MUST join the site-local 476 All-DHCP-Servers multicast group at the address 477 FF05:0:0:0:0:0:1:3. 479 FF05:0:0:0:0:0:1:4 480 All DHCP Relays MUST join the site-local All-DHCP-Relays 481 multicast group at the address FF05:0:0:0:0:0:1:4. 483 Note that All-DHCP-Relay is currently unused in this specification. 485 A DHCP server or agent MUST transmit all messages to DHCP clients on 486 UDP port 546. A DHCP client MUST transmit all messages to a DHCP 487 agent over UDP using port 547. A DHCP server MUST transmit all 488 messages to DHCP Relays over UDP on port 546. The source port for 489 DHCP messages is arbitrary. 491 For the proper operation of the DHCP protocol to operate within a 492 network where one or more firewalls [4] are used, DHCP transactions 493 using UDP destination ports 546 and 547 will need to be permitted. 495 4. DHCP Message Formats and Field Definitions 497 All fields in DHCP messages MUST be initialized to binary zeroes by 498 both the client and server unless otherwise noted. All reserved 499 fields in a message MUST be ignored by the receiver of the message. 501 4.1. DHCP Solicit Message Format 503 A DHCP client transmits a DHCP Solicit message over the interface it 504 is trying to configure, to obtain one or more DHCP server addresses. 505 In the event that there is no DHCP server on this link, such a 506 request MAY be forwarded by a DHCP relay attached to this link (if 507 such a relay exists) on behalf of a client to a DHCP server. 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | msg-type=1 |C| reserved | prefix size | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | client's link-local address | 515 | (16 octets) | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | relay address | 518 | (16 octets) | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 C If set, the client requests that all servers receiving 522 the message deallocate the resources associated with 523 the client. 525 prefix size A nonzero prefix size is the number of leftmost bits 526 of the agent's IPv6 address which make up the routing 527 prefix. 529 reserved 0 531 client's link-local address 532 The IP link-local address of the client interface from 533 which the client issued the DHCP Request message 535 relay address 536 If nonzero, the IP address of the interface on which 537 the relay received the client's DHCP Solicit message 539 To obtain a neighboring DHCP Agent address a DHCP client SHOULD send 540 a DHCP Solicit message to the All-DHCP-Agents multicast address 541 (see section 3.3). Any DHCP Relay receiving the solicitation, that 542 does not have the address of a DHCP Server configured, MUST forward 543 the solicitation to the All-DHCP-Servers multicast address (see 544 Section 7). The solicitation is sent in order to instruct DHCP 545 servers to send their advertisements to the prospective client. 546 When forwarding solicitations, the relay MUST copy a non-link-local 547 address of its interface from which the client's solicitation was 548 received into the relay address field. 550 4.2. DHCP Advertise Message Format 552 A DHCP agent sends a DHCP Advertise message to inform a prospective 553 client about the IP address of a DHCP Agent to which a DHCP Request 554 message may be sent. When the client and server are on different 555 links, the server sends the advertisement back through the DHCP Relay 556 whence the solicitation came. 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | msg-type=2 |S|P| reserved | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | server preference | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | client's link-local address | 566 | (16 octets) | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | agent address | 569 | (16 octets) | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | server address | 572 | (16 octets, if present) | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | extensions (variable number and length) ... 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 S If set, the server address is present. 579 P If set, the server preference is valid. 581 reserved 0 583 server preference 584 A 32-bit unsigned integer indicating a server's 585 willingness to provide service to the client (see 586 Section 5.3). 588 client's link-local address 589 The IP link-local address of the client interface 590 from which the client issued the DHCP Request message 592 agent address 593 The IP address of a DHCP Agent interface on the same 594 link as the client. 596 server address 597 If present, the IP address of the DHCP server 599 extensions See [12]. 601 Suppose that a DHCP server on the same link as a client issues the 602 DHCP Advertise in response to a DHCP Solicit message sent to the 603 All-DHCP-Agents multicast address. Then the agent address will be an 604 IP address of one of the server's interfaces on the same link as the 605 client, and the 'S' bit will be set to zero. No server address will 606 be present in the DHCP Advertise message. 608 If the `P' bit is set, the server preference field is valid. If the 609 `P' bit is not set, the server preference field is not valid, but 610 implicitly has the value of 0xffffffff (in other words, the highest 611 possible value). 613 The DHCP server MUST copy the client's link-local address into the 614 advertisement which is sent in response to a DHCP Solicit. Both 615 agent address and server address (if present) of the DHCP Advertise 616 message MUST have sufficient scope to be reachable by the DHCP 617 client. Moreover, the agent address of any DHCP Advertise message 618 sent by a DHCP relay MUST NOT be a link-local address. In situations 619 where there are no routers sending Router Advertisements, then a DHCP 620 server MUST be configured on the same link as prospective clients. 621 The DHCPv6 protocol design does not apply to situations where the 622 client has no way to route messages to a server not on the same link. 624 See section 5.3 for information about how clients handle the server 625 preference field. 627 4.3. DHCP Request Message Format 629 In order to request configuration parameters from a DHCP server, a 630 client sends a DHCP Request message, and MAY append extensions [12]. 631 If the client does not know any DHCP server address, it MUST first 632 obtain a server address by multicasting a DHCP Solicit message (see 633 Section 4.1). If the client does not have a valid IP address of 634 sufficient scope for the DHCP server to communicate with the client, 635 the client MUST send the message to the local DHCP relay and insert 636 the DHCP relay address as the agent address in the message header. 637 In this case, the client cannot send the message directly to the 638 DHCP server because the server could not return any response to the 639 client. Otherwise, the client MAY omit the server address in the 640 DHCP Request message; in this case, the client MUST clear the S-bit 641 in the DHCP Request message and send it directly to to the server, 642 using the server address as the IP destination address in the IP 643 header. 645 0 1 2 3 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | msg-type=3 |C|S|R| rsvd | transaction-ID | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | client's link-local address | 651 | (16 octets) | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | agent address | 654 | (16 octets) | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | server address | 657 | (16 octets, if present) | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | extensions (variable number and length) .... 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 C If set, the client requests the server to remove 663 all resources associated with the client binding, 664 except those resources provided as extensions. 666 S If set, the server address is present 668 R If set, the client has rebooted and requests that 669 all of its previous transaction-IDs be expunged 670 and made available for re-use. 672 rsvd 0 674 transaction-ID 675 A monotonically increasing unsigned integer used 676 to identify this Request, and copied into the 677 Reply. 679 client's link-local address 680 The IP link-local address of the client interface 681 from which the client issued the DHCP Request 682 message 684 agent address 685 The IP address of a neighboring agent's 686 interface, copied from a DHCP Advertisement 687 message. 689 server address 690 If present, the IP address of the DHCP server 691 which should receive the client's DHCP Request 692 message. 694 extensions See [12]. 696 When the client sets the 'C' bit and adds extensions, the server 697 is expected to deallocate all other resources not listed in the 698 extension. The resources explicitly requested in extensions to the 699 Request message SHOULD be reallocated by the server to the client, 700 assuming the client is still authorized to receive them. 702 4.4. DHCP Reply Message Format 704 The server sends one DHCP Reply message in response to every DHCP 705 Request or DHCP Release received. If the request comes with the 'S' 706 bit set, the client could not directly send the Request to the server 707 and had to use a neighboring relay agent. In that case, the server 708 sends back the DHCP Reply with the 'L' bit set, and the DHCP Reply is 709 addressed to the agent address found in the DHCP Request message. If 710 the 'L' bit is set, then the client's link-local address will also be 711 present. 713 0 1 2 3 714 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 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | msg-type=4 |L| status | transaction-ID | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | client's link-local address | 719 | (16 octets, if present) | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | extensions (variable number and length) .... 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 L If set, the client's link-local address is present 726 status One of the following decimal values: 728 0 Success 729 16 Failure, reason unspecified 730 17 Authentication failed or nonexistent 731 18 Poorly formed Request or Release 732 19 Resources unavailable 733 20 Client record unavailable 734 21 Invalid client IP address in Release 735 23 Relay cannot find Server Address 736 24 Cannot understand selected Character Set 737 64 Server unreachable (ICMP error) 739 transaction-ID 740 A monotonically increasing unsigned integer used to 741 identify this Reply, and copied from the client's 742 Request. 744 client's link-local address 745 If present, the IP address of the client interface 746 which issued the corresponding DHCP Request message. 748 extensions 749 See [12]. 751 If the 'L' bit is set, and thus the link-local address is present in 752 the Reply message, the Reply is sent by the server to the relay's 753 address which was specified as the agent address in the DHCP Request 754 message, and the relay uses the link-local address to deliver the 755 Reply message to the client. 757 4.5. DHCP Release Message Format 759 The DHCP Release message is sent without the assistance of any DHCP 760 relay. When a client sends a Release message, it is assumed to have 761 a valid IP address with sufficient scope to allow access to the 762 target server. If parameters are specified in the extensions, only 763 those parameters are released. The DHCP server acknowledges the 764 Release message by sending a DHCP Reply (Sections 4.4, 6.3). The 765 DHCP Client MUST wait for a DHCP Reply, and follow the retransmission 766 rules in section 8. 768 0 1 2 3 769 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 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | msg-type=5 |D| reserved | transaction-ID | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | client's link-local address | 774 | (16 octets) | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | agent address | 777 | (16 octets) | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | client address | 780 | (16 octets, if present) | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | extensions (variable number and length) .... 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 D If the 'D' ("Direct") flag is set, the client instructs 785 the server to send the DHCP Reply directly back to the 786 client, instead of using the given agent address and 787 link-local address to relay the Reply message. 789 reserved 0 791 transaction-ID 792 A monotonically increasing unsigned integer used to 793 identify this Release, and copied into the Reply. 795 client's link-local address 796 The IP link-local address of the client interface from 797 which the the client issued the DHCP Release message 799 agent address 800 The IP address of the agent interface to which the 801 client issued a previous DHCP Request message 803 client address 804 The IP address of the client interface from which the 805 the client issued the DHCP Release message. The client 806 address field is present whenever the 'D' bit is set, 807 even if it is equal to the link-local address. 809 extensions See [12] 811 Suppose that the client has an IP address that will still be valid 812 after the server performs the operations requested in the extensions 813 to the DHCP Release message, and which has sufficient scope to be 814 reachable from the server. In that case, and only then, the client 815 SHOULD set the 'D' flag. When the 'D' flag is set, the server MUST 816 send the DHCP Reply back to the client using the client address field 817 of the Release message. Otherwise, when the 'D' bit is not set, the 818 server MUST send its DHCP Reply message to the agent address in the 819 Release message, so that the relay agent can subsequently forward 820 the Reply back to the releasing client at the client's link-local 821 address indicated in the Reply message. Note that it is an error 822 (status code ``InvalidSource'' (see Section 2.4)) to include within 823 the DHCP Release message both the 'D' bit and an IP address extension 824 which has the IP address used as the client IP address field of the 825 DHCP Release message header. If the clients link-local address and 826 agent address do not match a client binding (see section 6) an error 827 (status code ``NoBinding'' (see Section 2.4)) will be returned to the 828 client. 830 4.6. DHCP Reconfigure Message Format 832 Reconfigure messages can only be sent to clients which have 833 established an IP address which routes to the link at which they are 834 reachable, hence the DHCP Reconfigure message is sent without the 835 assistance of any DHCP relay. When a server sends a Reconfigure 836 message, the client to which it is sent is assumed to have a valid 837 IP address with sufficient scope to be accessible by the server. 838 Only the parameters which are specified in the extensions to the 839 Reconfigure message need be requested again by the client. A 840 Reconfigure message can either be unicast or multicast by the server. 842 0 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | msg-type=6 |N| reserved | transaction-ID | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | server address | 848 | (16 octets) | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | extensions (variable number and length) .... 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 N The 'N' flag indicates that the client should not 854 expect a DHCP Reply in response to the DHCP Request 855 it sends as a result of the DHCP Reconfigure message. 857 reserved 0 859 transaction-ID 860 A monotonically increasing unsigned integer used to 861 identify this Reconfigure message, and copied into 862 the client's Request. 864 server address 865 The IP address of the DHCP server issuing the DHCP 866 Reconfigure message. 868 extensions See [12] 870 5. DHCP Client Considerations 872 A node which is not a DHCP agent MUST silently discard any DHCP 873 Solicit, DHCP Request, or DHCP Release message it receives. 875 5.1. Verifying Resource Allocations After Restarts 877 A DHCP client MAY retain its configured parameters and resources 878 across client system reboots and DHCP client program restarts. 879 However, in these circumstances a DHCP client MUST also formulate a 880 DHCP Request message to verify that its configured parameters and 881 resources are still valid. This Request message MUST have the 'C' 882 bit set, to clean up stale client binding information at the server 883 which may no longer be in use by the client; stale information is 884 that which the client does not include in extensions to such request 885 messages. 887 If the server does not respond to the DHCP Request message after 888 REQUEST_MSG_MIN_RETRANS (see section 8), the client may still use 889 any resources whose lifetimes have not yet expired. In such cases, 890 however, the client MUST begin to search for another server by 891 multicasting a new DHCP Solicit message, again with the 'C' bit set. 893 This also handles the case wherein a client restarts on a new 894 network, where its IP address is no longer valid. In this situation, 895 when the client receives a new IP address and the old IP address 896 is no longer needed, the client MUST release its old IP address by 897 issuing a DHCP Release message with the appropriate extension if it 898 can communicate with its previous server. 900 5.2. Sending DHCP Solicit Messages 902 A DHCP client MUST have the address of a DHCP server to send 903 a Request message. The client SHOULD locate a DHCP server by 904 multicasting a DHCP Solicit message to the All-DHCP-Agents link-local 905 multicast address, setting the Hop Limit == 1 (see Section 3.3). 906 If there are no DHCP servers on the same link as the node, then a 907 DHCP relay MUST be present if solicitations sent from a client's 908 link-local address are to be handled. The prospective client SHOULD 909 wait for ADV_CLIENT_WAIT to get all the DHCP Advertisement messages 910 which may be sent in response to the solicitation. 912 When sending a DHCP Solicit message, a client MUST set the Relay 913 Address field to 16 octets of zeros. 915 If a DHCP client reboots and does not have a valid IP address, 916 it MUST set the 'C' bit in the DHCP Solicit message it sends 917 when restarting. By setting the 'C' bit in the solicitation, a 918 DHCP client requests that all the DHCP servers that receive the 919 solicitation should clean up their client records that match its 920 link-local address. 922 If a client sends a DHCP Solicit message after it reboots, the 923 solicitation SHOULD be delayed after reception of the first Router 924 Advertisement [11] message, by at least some random amount of time 925 between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY (see section 8). 926 This delay is intended to help stagger requests to DHCP servers (and 927 avoid link-layer collisions) after a power outage causes many nodes 928 to reboot all at once. Each subsequent DHCP Solicit message that is 929 issued before receiving an advertisement MUST be delayed by twice the 930 amount by which the previous DHCP Solicit message was delayed, plus 931 a small random delay between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY 932 seconds. 934 5.3. Receiving DHCP Advertise Messages 936 After a DHCP client has received a DHCP Advertise message, it has the 937 address of a DHCP server for subsequent DHCP Request messages. If 938 the 'S' bit is zero, the DHCP Advertise message was transmitted by 939 a DHCP server on the same link as the client, and the client uses 940 the agent address as the address of a DHCP server; otherwise, the 941 DHCP server address is located in the server address field. If the 942 server's address is shown as a Multicast address, the advertisement 943 MUST be silently discarded. 945 A DHCP server MAY append extensions to its Advertisements; this might 946 allow the DHCP client to select the configuration that best meets its 947 needs from among several prospective servers. 949 If a DHCP Advertisement is received with a "server preference" 950 field invalid (the 'P' bit is not set), or equal to 0xffffffff 951 (see Section 4.2), the DHCP client can use the information in 952 the DHCP Solicit message immediately without waitin for any more 953 advertisements. Otherwise, the DHCP client MUST wait ADV_CLIENT_WAIT 954 seconds after issuing the DHCP Solicit message in order to receive 955 the Advertisement with the highest preference. After waiting for 956 that period of time, a client MUST select the highest preference DHCP 957 server as the target of its DHCP request. 959 If a DHCP client sends a DHCP Request to a more highly preferred 960 DHCP server but fails to receive a DHCP reply from that server after 961 following the retransmission algorithm in section 8, the client may 962 subsequently attempt to send a DHCP Request to a less preferred 963 server. 965 A DHCP client is free to cache the result of any DHCP Advertisement 966 it hears. However, it should be noted that this is purely a 967 potential performance enhancement as the results need not be constant 968 over time, hence it may not get a response if it uses the address 969 obtained from this message and may have to emit its own DHCP Solicit 970 message subsequently. 972 5.4. Sending DHCP Request Messages 974 A DHCP client obtains configuration information from a DHCP server by 975 sending a DHCP Request message. The client MUST know the server's 976 address before sending the Request message, and the client MUST 977 have acquired a (possibly identical) DHCP agent address. If the 978 client and server are on the same link, the agent address used by 979 the client MUST be the same as the DHCP server's address. A DHCP 980 Request message MUST NOT be sent to any multicast address. Otherwise 981 multiple DHCP servers would possibly allocate resources to the client 982 in response to the same Request, and the client would have no way to 983 know which servers had made the allocations, if any packets were lost 984 due to collisions, etc. 986 If the DHCP server is off-link, and the client has no valid IP 987 address of sufficient scope, then the client MUST include the server 988 address in the appropriate field and set the 'S' bit in the DHCP 989 Request message. In this case, the IP destination address in the IP 990 header will be a DHCP relay address. 992 Otherwise, if the client already has a valid IP address of sufficient 993 scope and knows the IP address of a candidate DHCP server, it 994 MUST send the Request message directly to the DHCP server without 995 requiring the services of the local DHCP relay. 997 If a client wishes to instruct a DHCP server to deallocate all 998 unknown previous resources, configuration information, and bindings 999 associated with its agent address and link-local address, it sets the 1000 'C' bit in the DHCP Request. A client MAY send in such a Request 1001 even when it is no longer attached to the link on which the relay 1002 address is attached. The 'C' bit allows better reclamation of 1003 available resources, since otherwise a client might not be able to 1004 release resources that it has no record of using. 1006 In any case, after choosing a transaction-ID which is numerically 1007 greater than its previous transaction-ID, and filling in the 1008 appropriate fields of the DHCP Request message, the client MAY append 1009 various DHCP Extensions to the message. These extensions denote 1010 specific requests by the client; for example, a client may request 1011 a particular IP address, or request that the server send an update 1012 containing the client's new IP address to a Domain Name Server. When 1013 all desired extensions have been applied, the DHCP client sends the 1014 DHCP Request to the appropriate DHCP Agent. 1016 For each pending DHCP Request message, a client MUST maintain the 1017 following information: 1019 The transaction-ID of the request message, 1020 The server address, 1021 The agent address (which can be the same as the server 1022 address), 1023 The time at which the next retransmission will be attempted, 1024 and 1025 All extensions appended to the request message. 1027 If a client does not receive a DHCP Reply message (Section 5.5) with 1028 the same transaction-ID as a pending DHCP Request message within 1029 REPLY_MSG_TIMEOUT (see section 8) seconds, or if the received DHCP 1030 Reply message contains a DHCP Authentication extension which fails 1031 to provide the correct authentication information, the client MUST 1032 retransmit the Request with the same transaction-ID and continue to 1033 retransmit according to the rules in Section 8. If (after following 1034 those rules) the client never receives a Reply message, it naturally 1035 SHOULD start over again by sending a new DHCP Solicit message to find 1036 a different server. 1038 If the client receives an ICMP error message in response to such 1039 a DHCP Request, it likewise naturally SHOULD start over again by 1040 sending a new DHCP Solicit message, to find a different server. 1042 If the client transmits a DHCP Request in response to a DHCP 1043 Reconfigure message (see Section 5.7), the client can continue to 1044 operate with its existing configuration information and resources 1045 until it receives the corresponding DHCP Reply from the server. The 1046 same retransmission rules apply as for any other DHCP Request message 1047 from the client. When the 'N' bit is set, a DHCP Request sent in 1048 response to a DHCP Reconfigure message will not elicit a DHCP Reply 1049 message from the server. 1051 5.5. Receiving DHCP Reply Messages 1053 When a client receives a DHCP Reply message, it MUST check whether 1054 the transaction-ID in the Reply message matches the transaction-ID 1055 of a pending DHCP Request message. If no match is found, the Reply 1056 message MUST be silently discarded. 1058 If the Reply message is acceptable, the client processes each 1059 Extension [12], extracting the relevant configuration information 1060 and parameters for its network operation. The client can determine 1061 when all extensions in the Reply have been processed by using the UDP 1062 Length field of the Reply. Some extensions in the Reply may have 1063 status codes, which indicate to the client the reason for failure 1064 when the server was unable to honor the request. If the server is 1065 unable to honor the request in an extension included by the client, 1066 that extension may simply be omitted from the Reply. The server MAY 1067 also provide the client with configuration parameters the client did 1068 not specifically request. 1070 Some configuration information extracted from the extensions to the 1071 DHCP Reply message MUST remain associated with the DHCP server that 1072 sent the message. The particular extensions that require this extra 1073 measure of association with the server are indicated in the DHCP 1074 Extensions document [12]. These "resource-server" associations are 1075 used when sending DHCP Release messages. 1077 5.6. Sending DHCP Release Messages 1079 If a client wishes to ask the server to release all information and 1080 resources relevant to the client, the client SHOULD send a DHCP 1081 Release message without any extensions; this is preferable to sending 1082 a DHCP Request message with the 'C' bit set and no extensions. If 1083 a DHCP client wishes to retain some of its network configuration 1084 parameters, but determines that others are no longer needed, it 1085 SHOULD enable the DHCP server to release allocated resources which 1086 are no longer in use by sending a DHCP Release message to the 1087 server, and including extensions to identify the unneeded items. The 1088 client consults its list of resource-server associations in order to 1089 determine which server should receive the desired Release message. 1091 Suppose a client wishes to release resources which were granted to 1092 it on another link, and the client has an IP address with enough 1093 scope so that the DHCP server can reach it. In that case, the client 1094 MUST instruct the server to send the DHCP Reply directly back to the 1095 client at that address, instead of performing the default processing 1096 of sending the DHCP Reply back through the agent-address included in 1097 the DHCP Release. This is done by setting the 'D' bit in the DHCP 1098 Release message (see section 4.5). 1100 5.7. Receiving DHCP Reconfigure Messages 1102 Each DHCP client implementation MUST support listening at UDP port 1103 546 to receive possible DHCP Reconfigure messages; in cases where the 1104 client knows that no Reconfigure message will ever be issued, the 1105 client MAY be configured to avoid executing this supported feature. 1106 In some cases, the IP address at which the client listens will be 1107 a multicast address sent to the client by the DHCP server in an 1108 extension to an earlier DHCP Reply message. If the client does not 1109 listen for DHCP Reconfigure messages, it is possible that the client 1110 will not receive notification that its DHCP server has deallocated 1111 the client's IP address and/or other resources allocated to the 1112 client. See discussion in 6.5. The client MAY receive a prefix 1113 update for one or more of their addresses and then MUST use that 1114 prefix for those addresses. 1116 If a DHCP client receives a DHCP Reconfigure message, it is a request 1117 for the client to initiate a new DHCP Request/Reply transaction with 1118 the server which sent the Reconfigure message. The server sending 1119 the Reconfigure message MAY be different than the server which sent a 1120 DHCP Reply message containing the original configuration information. 1122 For each Extension which is present in the Reconfigure message, the 1123 client MUST append a matching Extension to its Request message, which 1124 it formulates to send to the server specified in the server address 1125 field of the message. The client also copies a transaction-ID from 1126 the Reconfigure message into the Request message. If the 'N' bit is 1127 not set, processing from then on is the same as specified above in 1128 Section 5.4. 1130 Resources held by the client which are not identified by Extensions 1131 in the server's Reconfigure message are not affected. 1133 If a client has recently sent a DHCP Request to the server from which 1134 it subsequently received the DHCP Reconfigure message, the client 1135 SHOULD silently discard the Reconfigure message until the server 1136 sends the DHCP Reply message with the same transaction-ID as the 1137 client's DHCP Request message. 1139 A server may ask its client to join a multicast group for the 1140 purpose of receiving DHCP Reconfigure messages. When a Reconfigure 1141 message is delivered to the client by way of the selected multicast 1142 address, the client MUST delay its further response for a random 1143 amount of time uniformly distributed within the interval between 1144 RECONF_MSG_MIN_RESP and RECONF_MSG_MAX_RESP seconds (see section 8). 1145 This will minimize the likelihood that the server will be flooded 1146 with DHCP Request messages. 1148 Reconfigure messages can be retransmitted by the DHCP server with 1149 the same transaction-ID. When a client receives such a retransmitted 1150 Reconfigure message within XID_TIMEOUT of the last received 1151 Reconfigure message with the same transaction-ID, the client MUST 1152 reformulate exactly the same DHCP Request message and retransmit the 1153 request message to the server again. In this way, the DHCP server 1154 can make use of the retransmission algorithm to ensure that all 1155 affected clients have received the Reconfigure message. 1157 5.8. Interaction with Stateless Address Autoconfiguration 1159 Please refer to the Stateless Address Autoconfiguration 1160 Protocol specification [16] and its follow-on, Stateless Address 1161 Autoconfiguration version 2 [17] for details regarding the actions 1162 taken by DHCP clients upon receiving Router Advertisements with 1163 changing values for the 'M' and 'O' bits. 1165 6. DHCP Server Considerations 1167 A node which is not a DHCP client or DHCP relay MUST ignore any DHCP 1168 Advertise, DHCP Reply, or DHCP Reconfigure message it receives. 1170 A server maintains a collection of client records, called 1171 ``bindings''. Each binding is uniquely identifiable by the ordered 1172 pair , since the link-local 1173 address is guaranteed to be unique [16] on the link identified by the 1174 agent address. An implementation MUST support bindings consisting 1175 of at least a client's link-local address, agent address prefix, 1176 preferred lifetime and valid lifetime [16] for each client address. 1177 A server MAY, at the discretion of the network administrator, be 1178 configured so that client bindings are identified by the client's 1179 MAC address, without need to use the additional information supplied 1180 by the relay address. A client binding may be used to store any 1181 other information, resources, and configuration data which will be 1182 associated with the client. A DHCP server MUST retain its clients' 1183 bindings across server reboots, and, whenever possible, a DHCP client 1184 should be assigned the same configuration parameters despite server 1185 system reboots and DHCP server program restarts. A DHCP server MUST 1186 support fixed or permanent allocation of configuration parameters to 1187 specific clients. 1189 In addition to the client binding a Server must maintain an 1190 XID_TIMEOUT binding cache to determine if a previous transaction-ID 1191 is being retransmitted by a client. An implementation of an 1192 XID_TIMEOUT binding cache MUST support at least a tuple consisting of 1193 the client's link-local address, agent address prefix, IPv6 address, 1194 and XID_TIMEOUT value when the cache entry can be deleted (see 1195 Section 8). 1197 6.1. Receiving DHCP Solicit Messages 1199 If the DHCP Solicit message was received at the All-DHCP-Servers 1200 multicast address, the DHCP server MUST check to make sure that the 1201 relay address is present, and not a link-local address. If the 1202 relay address is not present, or if it is a link-local address, 1203 the server MUST silently discard the packet. Note that if the 1204 client sends a DHCP Solicit message from a link-local address, the 1205 multicast destination will be the All-DHCP-Agents address, not the 1206 All-DHCP-Servers address. 1208 When the 'C' bit is set in the solicitation, the DHCP server 1209 deallocates all resources that match its link-local address. The 1210 server MUST take the Relay Address Field and use it as the agent 1211 address prefix to locate the client binding. 1213 As an optimization, a server processing a Solicit message from relays 1214 MAY check the prefix of the IP source address in the IP header to 1215 determine whether the server has received the Solicit from multiple 1216 relays on the same link. The prefix size field in the solicitation 1217 enables the server ascertain exactly when two agent IP addresses 1218 belong to the same link. 1220 6.2. Sending DHCP Advertise Messages 1222 Upon receiving and verifying the correctness of a DHCP Solicit 1223 message, a server constructs a DHCP Advertise message and transmits 1224 it on the same link as the solicitation was received from. When 1225 the solicitation is received at the DHCP Servers multicast address, 1226 the server SHOULD delay the transmission of its advertisement 1227 for a random amount of time between SERVER_MIN_ADV_DELAY and 1228 SERVER_MAX_ADV_DELAY (see section 8). 1230 If the relay address is nonzero, the server MUST put the relay 1231 address in the agent address field of the advertisement message, and 1232 MUST send the advertisement message to the relay address; otherwise, 1233 the server MUST send the advertisement to the client's link-local 1234 address. An IP address of the interface on which the server received 1235 the Solicit message MUST appear in the server address field of the 1236 corresponding advertisement. 1238 The DHCP server MAY append extensions to the Advertisement, in order 1239 to offer the soliciting node the best possible information about 1240 the services and resources which the server may be able to make 1241 available. 1243 6.3. DHCP Request and Reply Message Processing 1245 The DHCP server MUST check to ensure that the client's link-local 1246 address field of the Request message contains a link-local address. 1247 If not, the message MUST be silently discarded. If the 'S' bit 1248 is set, the server MUST check that the server address matches the 1249 destination IP address at which the Request message was received 1250 by the server. If the server address does not match, the Request 1251 message MUST be silently discarded. 1253 If the received agent address and link-local address do not 1254 correspond to any binding known to the server, then the server 1255 MAY create a new binding for the previously unknown client, and 1256 send a DHCP Reply with any resources allocated to the new binding. 1257 Otherwise, if the server cannot create a new binding, it SHOULD 1258 return a DHCP Reply with a status of ``NoBinding'' (see Section 2.4). 1259 If the client is updating its resources but the database is 1260 temporarily unavailable, the server SHOULD return a DHCP Reply with a 1261 status of ``Unavail'' (see Section 2.4). 1263 While processing the Request, the server MUST first determine whether 1264 or not the Request is a retransmission of an earlier DHCP Request 1265 from the same client. This is done by comparing the transaction-ID 1266 to all those transaction-IDs received from the same client during the 1267 previous XID_TIMEOUT seconds. If the transaction-ID is the same as 1268 one received during that time, the server MUST take the same action 1269 (e.g., retransmit the same DHCP Reply to the client) as it did after 1270 processing the previous DHCP Request with the same transaction-ID. 1272 Otherwise, if the server has no record of a message from the client 1273 with the same transaction-ID, the server identifies and allocates 1274 all the relevant information, resources, and configuration data that 1275 is associated with the client. Then it sends that information to 1276 its DHCP client by constructing a DHCP Reply message and including 1277 the client's information in DHCP Extensions to the Reply message. 1278 The DHCP Reply message uses the same transaction-ID as found in the 1279 received DHCP Request message. Note that the reply message MAY 1280 contain information not specifically requested by the client. 1282 If the DHCP Request message has the 'S' bit set in the message 1283 header, the DHCP server MUST send the corresponding DHCP Reply 1284 message to the agent address found in the Request (see section 7.2). 1285 Otherwise, the server SHOULD send the corresponding DHCP Reply 1286 message to the IP source address in the IP header received from the 1287 client Request message. 1289 6.3.1. Processing for Extensions to DHCP Request and Reply Messages 1291 The DHCP Request may contain extensions [12], which are interpreted 1292 (by default) as advisory information from the client about its 1293 configuration preferences. For instance, if the IP Address Extension 1294 is present, the DHCP server SHOULD attempt to allocate or extend the 1295 lifetime of the address indicated by the extension. Some extensions 1296 may be marked by the client as required. 1298 The DHCP server may accept some extensions for successful processing 1299 and allocation, while still rejecting others, or the server may 1300 reject various extensions for different reasons. The server sets the 1301 status appropriately for those extensions which return status to the 1302 client. The DHCP server sends a single Reply message in response to 1303 each DHCP Request, with the same transaction-ID as the Request. 1305 Whenever it is able to, the server includes an extension in the 1306 Reply message for every extension sent by the client in the Request 1307 message. If the client requests some extensions that cannot be 1308 supplied by the server, the server can simply fail to provide them, 1309 not including them in the Reply. Other extensions can be rejected 1310 by including them in the Reply with an appropriate status indicating 1311 failure. The server can include extensions in the reply that were 1312 not requested by the client. 1314 6.3.2. Client Requests to Deallocate Unknown Resources 1316 When a client DHCP Request is received that has the 'C' bit set, the 1317 server should check to find out whether the extensions listed in the 1318 Request message match those which it has associated with the client's 1319 binding. Any resources which are not indicated by the client are 1320 presumed to be unknown by the client, and thus possible candidates 1321 for reallocation to satisfy requests from other clients. The DHCP 1322 server MUST deallocate all resources associated with the client 1323 upon reception of a DHCP Request with the 'C' bit set, except for 1324 those which the server is willing to reallocate in response to the 1325 client's request. It may be more efficient to avoid deallocating any 1326 resources until after the list of extensions to the request have been 1327 inspected. 1329 6.4. Receiving DHCP Release Messages 1331 If the server receives a DHCP Release Message, it MUST verify that 1332 the link-local address field of the message contains an address which 1333 could be a valid link-local address (see Section 2.1). If not, the 1334 message MUST be silently discarded. 1336 In response to a DHCP Release Message with a valid client's 1337 link-local address and agent address, the DHCP server formulates a 1338 DHCP Reply message that will be sent back to the releasing client by 1339 way of the client's link-local address. A DHCP Reply message sent 1340 in response to a DHCP Release message MUST be sent to the client's 1341 link-local address via the agent address in the Release message 1342 with the 'L' bit set in the Reply, unless the 'D' bit is set in the 1343 Release message. 1345 If the received agent address and link-local address do not 1346 correspond to any binding known to the server, then the server SHOULD 1347 return a DHCP Reply, indicating the error by setting the status code 1348 to ``NoBinding'' (see Section 2.4). 1350 Otherwise, if the agent address and link-local address indicate a 1351 binding known to the server, then the server continues processing the 1352 Release message. If there are any extensions, the server releases 1353 the particular configuration items specified in the extensions. 1354 If there are no extensions, the server releases all configuration 1355 information in the client's binding. 1357 After performing the operations indicated in the DHCP Release message 1358 and its extensions, the DHCP server formulates a DHCP Reply message, 1359 copying the transaction-ID from the DHCP Release message. For 1360 each Extension in the DHCP Release message successfully processed 1361 by the server, a matching Extension is appended to the DHCP Reply 1362 message. For extensions in the DHCP Release message which cannot be 1363 successfully processed by the server, a DHCP Reply message containing 1364 extensions with the appropriate status MUST be returned by the 1365 server. If the Release message contains no extensions, the server 1366 does not include any extensions in the corresponding DHCP Reply 1367 message to the client. 1369 6.5. Sending DHCP Reconfigure Messages 1371 If a DHCP server needs to change the configuration associated with 1372 any of its clients, it constructs a DHCP Reconfigure message and 1373 sends it to each such client. The Reconfigure MAY be sent to a 1374 multicast address chosen by the server and previously sent to each of 1375 its clients in an extension to a previous DHCP Reply message. 1377 It may happen that a client does not send DHCP Request messages 1378 after the DHCP Reconfigure message has been issued and retransmitted 1379 according to the algorithm specified in Section 8. This can happen 1380 when the client is not listening for the Reconfigure message, 1381 possibly because the client is a mobile node disconnected from the 1382 network, or because the client node has sustained a power outage 1383 or operating system crash. In such cases, the DHCP server SHOULD 1384 reserve any resources issued to the client until the client responds 1385 at some future time, until the resource allocation times out (see 1386 section 6.6), or until administrative intervention causes the 1387 resources to be manually returned to use. 1389 If the server gets another DHCP Request from a client, with a 1390 transaction-ID which does not match that of the recently transmitted 1391 reconfigure message, the server SHOULD send the DHCP Reply to 1392 the client, and wait for RECONF_MSG_RETRANS_INTERVAL, before 1393 retransmitting the DHCP Reconfigure again. 1395 6.6. Client-Resource timeouts 1397 Some resources (for instance, a client's IP address) may only be 1398 allocated to a DHCP client for a particular length of time (for 1399 instance, the valid lifetime of an IP address). If the client does 1400 not renew the resource allocation for such a resource, the DHCP 1401 server MAY make the resource available for allocation to another 1402 client. However, under administrative control, the DHCP server MAY 1403 reserve any resources issued to the client until the client responds 1404 at some future time. 1406 7. DHCP Relay Considerations 1408 The DHCP protocol is constructed so that a relay does not have 1409 to maintain any state in order to mediate DHCP client/server 1410 interactions. 1412 All relays MUST send DHCP Request messages using the source IP 1413 address from the interface where the DHCP request was received. 1415 The purpose of the DHCP relay is to enable clients and servers to 1416 carry out DHCP protocol transactions. DHCP Solicit messages are 1417 issued by the relay when initiated by prospective DHCP clients. By 1418 default, the relay locates DHCP servers by use of multicasting DHCP 1419 solicitations to the All-DHCP-Servers multicast address, but relays 1420 SHOULD allow this behavior to be configurable. The relay SHOULD NOT 1421 send such a multicast solicitation on the interface from which it 1422 received the solicitation from the client. The source address must 1423 be a site-local or global-scope address belonging to the relay's 1424 interface on which the client's original solicitation was received. 1426 7.1. DHCP Solicit and DHCP Advertise Message Processing 1428 Upon receiving a DHCP Solicit message from a prospective client, a 1429 relay, by default, forwards the message to all DHCP servers at a site 1430 according to the following procedure: 1432 - copying the prospective client's solicitation message fields into 1433 the appropriate fields of the outgoing solicitation, 1435 - copying a non-link-local address of its interface from which the 1436 solicitation was received from the client into the DHCP relay 1437 address field, and 1439 - by default, setting the TTL field in the solicitation to the 1440 value DEFAULT_SOLICIT_TTL (see section 8). 1442 - finally, sending the resulting message to one or more DHCP 1443 Servers. 1445 By default, the relay sends solicitations to the All-DHCP-Servers 1446 multicast address, FF05:0:0:0:0:0:1:3. However, the relay MAY be 1447 configured with an alternate DHCP server address, or the FQDN of a 1448 DHCP server. Methods for automatically updating such alternately 1449 configured DHCP server addresses are not specified in this document. 1451 When the relay receives a DHCP advertisement, it relays the 1452 advertisement to the client at the client's link-local address by way 1453 of the interface indicated in the agent's address field. 1455 7.2. DHCP Request Message Processing 1457 When a relay receives a DHCP Request message, it SHOULD check that 1458 the IP source address in the IP header is a link-local address, 1459 that the link-local address matches the link-local address field in 1460 the Request message header, and that the agent address field of the 1461 message matches an IP address associated with the interface from 1462 which the DHCP Request message was received. If any of these checks 1463 fail, the relay MUST silently discard the Request message. 1465 The relay MUST check whether the 'S' bit is set in the message 1466 header. If not, the packet is discarded, and the relay SHOULD 1467 return a DHCP Reply message to the address contained in the client's 1468 link-local address field of the Request message, with status 1469 ``PoorlyFormed'' (see Section 2.4). 1471 If the received request message is acceptable, the relay then 1472 transmits the DHCP Request message to the address of the DHCP server 1473 found in the Server IP Address field of the received DHCP Request 1474 message. All of the fields of DHCP Request message transmitted by 1475 the relay are copied over unchanged from the DHCP Request received 1476 from the client. Only the fields in the IP header will differ from 1477 the packet received from the client. If the Relay receives an ICMP 1478 error, the Relay SHOULD return a DHCP Reply message to the client 1479 address (which can be found in the payload of the ICMP message [5]), 1480 with status ``ICMPError'' (see Section 2.4). 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 link-local address field 1486 contains a link-local address. If either check fails, the packet 1487 MUST be silently discarded. If both checks are satisfied, the relay 1488 MUST send a DHCP Reply message to the link-local address listed in 1489 the received Reply message. Only the fields in the IP header will 1490 differ from the packet received from the server, not the payload. 1492 8. Retransmission and Configuration Variables 1494 When a DHCP client does not receive a DHCP Reply in response to a 1495 pending DHCP Request, the client MUST retransmit the identical DHCP 1496 Request, with the same transaction-ID, to the same server again 1497 until it can be reasonably sure that the DHCP server is unavailable 1498 and an alternative can be chosen. The DHCP server assumes that the 1499 client has received the configuration information included with the 1500 extensions to the DHCP Reply message, and it is up to the client 1501 to continue to try for a reasonable amount of time to complete the 1502 transaction. All the actions specified for DHCP Request in this 1503 section hold also for DHCP Release messages sent by the DHCP client. 1505 Similarly, when a client sends a DHCP Request message in response to 1506 a Reconfigure message from the server, the client assumes that the 1507 DHCP server has received the Request. The server MUST retransmit 1508 the identical DHCP Reconfigure to the client a reasonable number 1509 of times to try to elicit the Request message from the client. 1510 If no corresponding DHCP Request is received by the server after 1511 REQUEST_MSG_MIN_RETRANS retransmissions. time, the server MAY erase 1512 or deallocate information as needed from the client's binding, but 1513 see section 6.5. 1515 When a client reboots and loses its previous state, the server 1516 should no longer keep track of the transaction IDs associated with 1517 that previous state. In order to inform the server that the client 1518 no longer wishes any association to be maintained between used 1519 transaction-IDs and previous transactions, the client should set the 1520 'R' bit in its DHCP Request. 1522 Retransmissions occur using the following configuration variables 1523 for a DHCP implementation. These configuration variables MUST be 1524 configurable by a client or server: 1526 ADV_CLIENT_WAIT 1528 The minimum amount of time a client waits to receive DHCP 1529 Advertisements after transmitting a DHCP Solicit to the 1530 All-DHCP Agents multicast address. 1532 Default: 2 seconds 1534 DEFAULT_SOLICIT_TTL 1536 The default TTL value used by DHCP relays when sending DHCP 1537 Solicit messages on behalf of a client. 1539 Default: 4 1541 SERVER_MIN_ADV_DELAY 1543 The minimum amount of time a server waits to transmit a DHCP 1544 Advertisement after receiving a DHCP Solicit at the All-DHCP 1545 Servers or All-DHCP Agents multicast address. 1547 Default: 100 milliseconds 1549 SERVER_MAX_ADV_DELAY 1551 The maximum amount of time a server waits to transmit a DHCP 1552 Advertisement after receiving a DHCP Solicit at the All-DHCP 1553 Agents multicast address. 1555 Default: 1 second 1557 REPLY_MSG_TIMEOUT 1559 The time in seconds that a DHCP client waits to receive a 1560 server's DHCP Reply before retransmitting a DHCP Request. 1562 Default: 2 seconds. 1564 REQUEST_MSG_MIN_RETRANS 1566 The minimum number of DHCP Request transmissions that a DHCP 1567 client should retransmit, before aborting the request, possibly 1568 retrying the Request with another Server, and logging a DHCP 1569 System Error. 1571 Default: 10 retransmissions. 1573 RECONF_MSG_TIMEOUT 1575 The time in seconds that a DHCP server waits to receive 1576 a client's DHCP Request before retransmitting its DHCP 1577 Reconfigure. 1579 Default: 12 seconds. 1581 RECONF_MSG_MIN_RETRANS 1583 The minimum number of DHCP Reconfigure messages that a DHCP 1584 server should retransmit, before assuming the the client is 1585 unavailable and that the server can proceed with logging a DHCP 1586 System Error. 1588 Default: 10 retransmissions. 1590 RECONF_MSG_RETRANS_INTERVAL 1592 The least time between successive retransmissions of DHCP 1593 Reconfigure messages. 1595 Default: RECONF_MSG_TIMEOUT 1597 RECONF_MSG_MIN_RESP 1599 The minimum amount of time before a client can respond to a 1600 DHCP Reconfigure message sent to a multicast address. 1602 Default: 2 seconds. 1604 RECONF_MSG_MAX_RESP 1606 The maximum amount of time before a client MUST respond to a 1607 DHCP Reconfigure message sent to a multicast address. 1609 Default: 10 seconds. 1611 MIN_SOLICIT_DELAY 1613 The minimum amount of time a prospective client is required to 1614 wait, after determining from a Router Advertisement message 1615 that the client should perform stateful address configuration, 1616 before sending a DHCP Solicit to a DHCP server. 1618 Default: 1 second 1620 MAX_SOLICIT_DELAY 1622 The maximum amount of time a prospective client is required to 1623 wait, after determining from a Router Advertisement message 1624 that the client should perform stateful address configuration, 1625 before sending a DHCP Solicit to a DHCP server. 1627 Default: 5 seconds 1629 XID_TIMEOUT 1631 The amount of time a DHCP server has to keep track of 1632 client transaction-IDs in order to make sure that client 1633 retransmissions using the same transaction-ID are idempotent. 1635 Default: 600 seconds 1637 Note that, if a client receives a DHCP message which fails 1638 authentication, it should continue to wait for another message which 1639 might be correctly authenticated just as if the failed message had 1640 never arrived; however, receiving such failed messages SHOULD be 1641 logged. 1643 9. Security Considerations 1645 DHCP clients and servers often have to authenticate the messages they 1646 exchange. For instance, a DHCP server may wish to be certain that a 1647 DHCP Request originated from the client identified by the fields included within the Request message 1649 header. Conversely, it is quite often essential for a DHCP client 1650 to be certain that the configuration parameters and addresses it has 1651 received were sent to it by an authoritative DHCP server. Similarly, 1652 a DHCP server should only accept a DHCP Release message which seems 1653 to be from one of its clients, if it has some assurance that the 1654 client actually did transmit the Release message. Again, a client 1655 might wish to only accept DHCP Reconfigure messages that are certain 1656 to have originated from a server with authority to issue them. 1658 The IPv6 Authentication Header can provide security for DHCPv6 1659 messages when both endpoints have a suitable IP address. However, 1660 a client often has only a link-local address, and such an address 1661 is not sufficient for a DHCP server which is off-link. In those 1662 circumstances the DHCP relay is involved, so that the DHCP message 1663 MUST have the relay's address in the IP destination address field, 1664 even though the client aims to deliver the message to the DHCP 1665 server. The DHCP Client-Server Authentication Extension [12] is 1666 intended to be used in these circumstances. 1668 10. Year 2000 considerations 1670 Since all times are relative to the current time of the transaction, 1671 there is no problem within the DHCPv6 protocol related to any 1672 hardcoded dates or two-digit representation of the current year. 1674 11. Acknowledgements 1676 Thanks to the DHC Working Group for their time and input into the 1677 specification. Ralph Droms and Thomas Narten have had a major role 1678 in shaping the continued improvement of the protocol by their careful 1679 reviews. Many thanks to Matt Crawford, Erik Nordmark, and Mike 1680 Carney for their studied review as part of the Last Call process. 1681 Thanks also for the consistent input, ideas, and review by (in 1682 alphabetical order) Brian Carpenter, Gerald Maguire, Jack McCann, 1683 Yakov Rekhter, Matt Thomas, Sue Thomson, and Phil Wells. 1685 Thanks to Steve Deering and Bob Hinden, who have consistently 1686 taken the time to discuss the more complex parts of the IPv6 1687 specifications. 1689 A. Changes for this revision 1691 Should this be here? 1693 - Allowed relays to use configured DHCP Server addresses instead of 1694 multicasting to the All-DHCP Servers address. 1696 - Specified that clients have to keep around enough information to 1697 retransmit the same DHCP Request if they receive a retransmitted 1698 DHCP Reconfigure from a server. 1700 - Specified that servers MAY reallocate resources after a client 1701 fails to renew them. This differs from the case when a client 1702 does not answer a Reconfigure message. 1704 - Eliminated the 'N' bit from the DHCP Request message. 1706 - Added a pfx-size to the DHCP Solicit message. 1708 - Renamed REPLY_MSG_MIN_RETRANS to be REQUEST_MSG_MIN_RETRANS 1710 - Deleted REPLY_MSG_RETRANS_INTERVAL. 1712 - Clarified use of RECONF_MSG_MIN_RETRANS. 1714 - Deleted transaction-ID from client bindings. 1716 - Clarified resource handling by server when 'C' bit is set in the 1717 DHCP Solicit message. 1719 - Changed specification to use symbolic error names instead of 1720 numeric error values. 1722 - Specified that a client should silently discard a Reconfigure 1723 message if it is waiting for a DHCP Reply. 1725 - Specified that a server MAY be configured so that client bindings 1726 are identified by the client's MAC address, without need to use 1727 the additional information supplied by the relay address. 1729 - Changed preference field to be "optional", and specified that 1730 invalid preference fields are implicitly equal to 0xffffffff. 1732 - Various typos and fixups. 1734 B. Related Work in IPv6 1736 The related work in IPv6 that would best serve an implementor 1737 to study is the IPv6 Specification [6], the IPv6 Addressing 1738 Architecture [8], IPv6 Stateless Address Autoconfiguration [16], IPv6 1739 Neighbor Discovery Processing [11], and Dynamic Updates to DNS [19]. 1740 These specifications enable DHCP to build upon the IPv6 work to 1741 provide both robust stateful autoconfiguration and autoregistration 1742 of DNS Host Names. 1744 The IPv6 Specification provides the base architecture and design of 1745 IPv6. A key point for DHCP implementors to understand is that IPv6 1746 requires that every link in the internet have an MTU of 1500 octets 1747 or greater (in IPv4 the requirement is 68 octets). This means that 1748 a UDP packet of 536 octets will always pass through an internet 1749 (less 40 octets for the IPv6 header), as long as there are no IP 1750 options prior to the UDP header in the packet. But, IPv6 does not 1751 support fragmentation at routers, so that fragmentation takes place 1752 end-to-end between hosts. If a DHCP implementation needs to send a 1753 packet greater than 1500 octets it can either fragment the UDP packet 1754 into fragments of 1500 octets or less, or use Path MTU Discovery [10] 1755 to determine the size of the packet that will traverse a network 1756 path. It is implementation dependent how this is accomplished in 1757 DHCP. Path MTU Discovery for IPv6 is supported for both UDP and TCP 1758 and can cause end-to-end fragmentation when the PMTU changes for a 1759 destination. 1761 The IPv6 Addressing Architecture specification [8] defines the 1762 address scope that can be used in an IPv6 implementation, and the 1763 various configuration architecture guidelines for network designers 1764 of the IPv6 address space. Two advantages of IPv6 are that support 1765 for multicast is required, and nodes can create link-local addresses 1766 during initialization. This means that a client can immediately use 1767 its link-local address and a well-known multicast address to begin 1768 communications to discover neighbors on the link, or to send a DHCP 1769 Solicit and locate a DHCP server or relay. 1771 IPv6 Stateless Address Autoconfiguration [16] (addrconf) specifies 1772 procedures by which a node may autoconfigure addresses based on 1773 router advertisements [11], and the use of a valid lifetime to 1774 support renumbering of addresses on the Internet. In addition the 1775 protocol interaction by which a node begins stateless or stateful 1776 autoconfiguration is specified. DHCP is one vehicle to perform 1777 stateful autoconfiguration. Compatibility with addrconf is a design 1778 requirement of DHCP (see Section 3.1). 1780 IPv6 Neighbor Discovery [11] is the node discovery protocol in IPv6 1781 which replaces and enhances functions of ARP [13]. To understand 1782 IPv6 and addrconf it is strongly recommended that implementors 1783 understand IPv6 Neighbor Discovery. 1785 Dynamic Updates to DNS [19] is a specification that supports the 1786 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 1787 the dynamic updates to DNS to integrate addresses and name space to 1788 not only support autoconfiguration, but also autoregistration in 1789 IPv6. The security model to be used with DHCPv6 should conform as 1790 closely as possible to the authentication model outlined in [9]. 1792 C. Comparison between DHCPv4 and DHCPv6 1794 This appendix is provided for readers who will find it useful to see 1795 a model and architecture comparison between DHCPv4 [7, 1] and DHCPv6. 1796 There are three key reasons for the differences: 1798 o IPv6 inherently supports a new model and architecture for 1799 communications and autoconfiguration of addresses. 1801 o DHCPv6 in its design was able to take advantage of the inherent 1802 benefits of IPv6. 1804 o New features were added to support the expected evolution and 1805 the existence of more complicated Internet network service 1806 requirements. 1808 IPv6 Architecture/Model Changes: 1810 o The link-local address permits a node to have an address 1811 immediately when the node boots, which means all clients have a 1812 source IP address at all times to locate a server or relay agent 1813 on the local link. 1815 o The need for bootp compatibility and broadcast flags are removed, 1816 which permitted a great deal of freedom in designing the new 1817 packet formats for the client and server interaction. 1819 o Multicast and the scoping methods in IPv6 permitted the design of 1820 discovery packets that would inherently define their range by the 1821 multicast address for the function required. 1823 o Stateful autoconfiguration has to coexist and integrate with 1824 stateless autoconfiguration supporting Duplicate Address 1825 Detection and the two IPv6 lifetimes, to facilitate the dynamic 1826 renumbering of addresses and the management of those addresses. 1828 o Multiple addresses per interface are inherently supported in 1829 IPv6. 1831 o Most DHCPv4 options are unnecessary now because the configuration 1832 parameters are either obtained through IPv6 Neighbor Discovery or 1833 the Service Location protocol [18]. 1835 DHCPv6 Architecture/Model Changes: 1837 o The message type is the first byte in the packet. 1839 o IPv6 Address allocations are now handled in a message extension 1840 as opposed to the main header. 1842 o Client/Server bindings are now mandatory and take advantage of 1843 the client's link-local address to always permit communications 1844 either directly from an on-link server, or from a remote server 1845 through an on-link relay-agent. 1847 o Servers are now discovered by a client solicit and server or 1848 relay-agent advertisement model. 1850 o The client will know if the server is on-link or off-link. 1852 o The client after a solicit will be returned the addresses of 1853 available servers either from an on-link server or from an 1854 on-link relay-agent as agents providing the advertisements. 1856 o The on-link relay-agent will obtain the location of remote server 1857 addresses from system configuration or by the use of a site wide 1858 DHCPv6 Multicast packet. 1860 o The protocol is optimized and removes the use of ACKs and NAKs 1861 once the client and server set-up is complete. 1863 o The server assumes the client receives its responses unless it 1864 receives a retransmission of the same client request. This 1865 permits recovery in the case where the network has faulted. 1867 o The function of DHCPINFORM is inherent in the new packet design; 1868 a client can request configuration parameters other than IPv6 1869 addresses in the optional extension headers. 1871 o Clients MUST listen to their UDP port for the new Reconfigure 1872 message from servers. 1874 o Dynamic Updates to DNS are supported in the IPv6 Address 1875 extension. 1877 o New extensions have been defined. 1879 New Internet User Features: 1881 o Configuration of Dynamic Updates to DNS to support different 1882 requirements. 1884 o Configuration of what policy is enforced when addresses are 1885 deprecated for dynamic renumbering can be implemented. 1887 o Configuration of how relay-agents locate remote servers for a 1888 link can be implemented. 1890 o An Authentication extension has been added. 1892 o Configuration of additional addresses for server applications can 1893 be requested by a client in an implementation. 1895 o Reclaiming addresses allocated with very long lifetimes can be 1896 implemented using the Reconfigure message type. 1898 o Configuration of tightly coupled integration between stateless 1899 and stateful address autoconfiguration can be implemented. 1901 References 1903 [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 1904 Extensions. RFC 2132, March 1997. 1906 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 1907 Levels. RFC 2119, March 1997. 1909 [3] S. Bradner and A. Mankin. The Recommendation for the IP Next 1910 Generation Protocol. RFC 1752, January 1995. 1912 [4] William R. Cheswick and Steven Bellovin. Firewalls and Internet 1913 Security. Addison-Wesley, Reading, Massachusetts, 1994. (ISBN: 1914 0-201-63357-4). 1916 [5] A. Conta and S. Deering. Internet Control Message Protocol 1917 (ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885, 1918 December 1995. 1920 [6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1921 Specification. RFC 1883, December 1995. 1923 [7] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March 1924 1997. 1926 [8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 1927 RFC 1884, December 1995. 1929 [9] Stephen Kent and Randall Atkinson. IP Authentication Header. 1930 draft-ietf-ipsec-auth-header-03.txt, November 1997. (work in 1931 progress). 1933 [10] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP 1934 version 6. RFC 1981, August 1996. 1936 [11] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 1937 IP version 6 (IPv6). RFC 1970, August 1996. 1939 [12] C. Perkins. Extensions for the Dynamic Host Configuration 1940 Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-09.txt, October 1941 1997. (work in progress). 1943 [13] David C. Plummer. An Ethernet Address Resolution Protocol: 1944 Or Converting Network Protocol Addresses to 48.bit Ethernet 1945 Addresses for Transmission on Ethernet Hardware. RFC 826, 1946 November 1982. 1948 [14] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 1950 [15] J. B. Postel, Editor. Internet Protocol. RFC 791, September 1951 1981. 1953 [16] S. Thomson and T. Narten. IPv6 Stateless Address 1954 Autoconfiguration. RFC 1971, August 1996. 1956 [17] S. Thomson and T. Narten. IPv6 Address Autoconfiguration. 1957 draft-ietf-ipngwg-addrconf-v2-00.txt, November 1997. (work in 1958 progress). 1960 [18] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 1961 Location Protocol. RFC 2165, July 1997. 1963 [19] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates 1964 in the Domain Name System (DNS). RFC 2136, April 1997. 1966 Chair's Address 1968 The working group can be contacted via the current chair: 1970 Ralph Droms 1971 Computer Science Department 1972 323 Dana Engineering 1973 Bucknell University 1974 Lewisburg, PA 17837 1976 Phone: (717) 524-1145 1977 E-mail: droms@bucknell.edu 1979 Author's Address 1981 Questions about this memo can be directed to: 1983 Jim Bound Charles Perkins 1984 Digital Equipment Corporation Technology Development 1985 110 Spitbrook Road, ZKO3-3/U14 Sun Microsystems, Inc. 1986 Nashua, NH 03062 901 San Antonio Rd. 1987 Palo Alto, CA 94303 1988 Phone: +1-603-884-0400 +1-650-786-6464 1989 Fax: +1-650-786-6445 1990 E-mail: bound@zk3.dec.com charles.perkins@sun.com