idnits 2.17.1 draft-ietf-dhc-dhcpv6-10.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-19) 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-09.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-09.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 (26 May 1997) is 9825 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1825 (ref. '2') (Obsoleted by RFC 2401) ** 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) ** Obsolete normative reference: RFC 1981 (ref. '9') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 1970 (ref. '10') (Obsoleted by RFC 2461) -- No information found for draft-ietf-dhc-dhcpv6ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '11' ** Obsolete normative reference: RFC 1971 (ref. '15') (Obsoleted by RFC 2462) Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force J. Bound 2 INTERNET DRAFT Digital Equipment Corp. 3 DHC Working Group C. Perkins 4 Obsoletes: draft-ietf-dhc-dhcpv6-09.txt Sun Microsystems 5 26 May 1997 7 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 8 draft-ietf-dhc-dhcpv6-10.txt 10 Status of This Memo 12 This document is a submission to the DHC Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be submitted 14 to the dhcp-v6@bucknell.edu mailing list. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at 23 any time. It is inappropriate to use Internet Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 28 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Distribution of this document is unlimited. 34 Abstract 36 The Dynamic Host Configuration Protocol (DHCPv6) provides a framework 37 for passing configuration information, via extensions, to IPv6 nodes. 38 It offers the capability of automatic allocation of reusable network 39 addresses and additional configuration flexibility. This protocol 40 should be considered a stateful counterpart to the IPv6 Stateless 41 Address Autoconfiguration protocol specification. 43 Contents 45 Status of This Memo i 47 Abstract i 49 1. Introduction 1 51 2. Terminology and Definitions 1 52 2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2 53 2.2. DHCPv6 Terminology . . . . . . . . . . . . . . . . . . . 3 54 2.3. Specification Language . . . . . . . . . . . . . . . . . 4 56 3. Protocol Design Model 4 57 3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. DHCP Messages . . . . . . . . . . . . . . . . . . . . . . 6 59 3.3. Request/Response Processing Model . . . . . . . . . . . . 7 61 4. DHCP Message Formats and Field Definitions 8 62 4.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 8 63 4.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 9 64 4.3. DHCP Request Message Format . . . . . . . . . . . . . . . 10 65 4.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12 66 4.5. DHCP Release Message Format . . . . . . . . . . . . . . . 13 67 4.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 14 69 5. DHCP Client Considerations 15 70 5.1. Verifying Resource Allocations After Restarts . . . . . . 15 71 5.2. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 16 72 5.3. Receiving DHCP Advertise Messages . . . . . . . . . . . . 17 73 5.4. Sending DHCP Request Messages . . . . . . . . . . . . . . 17 74 5.5. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 18 75 5.6. Sending DHCP Release Messages . . . . . . . . . . . . . . 19 76 5.7. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 19 78 6. DHCP Server Considerations 20 79 6.1. Receiving DHCP Solicit Messages . . . . . . . . . . . . . 21 80 6.2. Sending DHCP Advertise Messages . . . . . . . . . . . . . 21 81 6.3. DHCP Request and Reply Message Processing . . . . . . . . 21 82 6.3.1. Processing for Extensions to DHCP Request and Reply 83 Messages . . . . . . . . . . . . . . . . . 22 84 6.3.2. Client Requests to Deallocate Unknown Resources . 23 85 6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 23 86 6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . . 24 88 7. DHCP Relay Considerations 24 89 7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 24 90 7.2. DHCP Request Message Processing . . . . . . . . . . . . . 25 91 7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 26 93 8. Retransmission and Configuration Variables 26 95 9. Security Considerations 29 97 10. Acknowledgements 29 99 A. Related Work in IPv6 29 101 B. Comparison between DHCPv4 and DHCPv6 31 103 Chair's Address 36 105 Author's Address 36 106 1. Introduction 108 The Dynamic Host Configuration Protocol (DHCPv6, or in this 109 document usually DHCP) provides configuration parameters to Internet 110 nodes. DHCP consists of a protocol for delivering node-specific 111 configuration parameters from a DHCP server to a client, and a 112 mechanism for allocation of network addresses and other related 113 parameters to IPv6 [6] nodes. 115 DHCP is built on a client-server model, where designated DHCP servers 116 allocate network addresses and automatically deliver configuration 117 parameters to dynamically configurable clients. Throughout the 118 remainder of this document, the term "server" refers to a node 119 providing initialization parameters by way of the DHCP protocol, 120 and the term "client" refers to a node requesting initialization 121 parameters from a DHCP server. 123 DHCPv6 uses Request and Reply messages to support a client/server 124 processing model whereby both client and server are assured that 125 requested configuration parameters have been received and accepted 126 by the client. DHCP supports optional configuration parameters and 127 processing for nodes through extensions described in its companion 128 document ``Extensions for the Dynamic Host Configuration Protocol for 129 IPv6'' [11]. 131 The IPv6 Addressing Architecture [8] and IPv6 Stateless Address 132 Autoconfiguration specifications provide new features not available 133 in IP version 4 (IPv4) [14], which are used to simplify and 134 generalize the operation of DHCP clients. 136 Section 2 provides definitions for terminology used throughout 137 this document. Section 3 provides an overview of the protocol 138 design model that guided the design choices in the specification; 139 section 3.2 briefly describes the protocol messages and their 140 semantics. Section 4 provides the message formats and field 141 definitions used for each message. Sections 5, 6, and 7 specify 142 how clients, servers, and relays interact. Appendix A summarizes 143 related work in IPv6 that will provide helpful context; it is not 144 part of this specification, but included for informational purposes. 145 Appendix B discusses the differences between DHCPv4 and DHCPv6. 147 2. Terminology and Definitions 149 Relevant terminology from the IPv6 Protocol [6], IPv6 Addressing 150 Architecture [8], and IPv6 Stateless Address Autoconfiguration [15] 151 will be provided, and then the DHCPv6 terminology. 153 2.1. IPv6 Terminology 155 IP Internet Protocol Version 6 (IPv6). The terms IPv4 and 156 IPv6 are used only in contexts where necessary to avoid 157 ambiguity. 159 node A device that implements IP. 161 router A node that forwards IP datagrams not explicitly 162 addressed to itself. 164 host Any node that is not a router. 166 link A communication facility or medium over which nodes 167 can communicate at the link layer, i.e., the layer 168 immediately below IP. Examples are Ethernet (simple or 169 bridged); Token Ring; PPP links, X.25, Frame Relay, or 170 ATM networks; and internet (or higher) layer "tunnels", 171 such as tunnels over IPv4 or IPv6 itself. 173 link-layer identifier 174 a link-layer identifier for an interface. Examples 175 include IEEE 802 addresses for Ethernet or Token Ring 176 network interfaces, and E.164 addresses for ISDN links. 178 link-local address 179 An IP address having link-only scope that can be used 180 to reach neighboring nodes attached to the same link. 181 All interfaces have a link-local address. 183 neighbor Nodes attached to the same link. 185 interface 186 A node's attachment to the link. 188 address An IP layer identifier for an interface or a set of 189 interfaces. 191 message A unit of data carried in a datagram, exchanged between 192 DHCP agents and clients. 194 datagram An IP header plus payload. 196 unicast address 197 An identifier for a single interface. A datagram sent 198 to a unicast address is delivered to the interface 199 identified by that address. 201 multicast address 202 An identifier for a set of interfaces (typically 203 belonging to different nodes). A datagram sent to 204 a multicast address is delivered to all interfaces 205 identified by that address. 207 2.2. DHCPv6 Terminology 209 configuration parameter 210 Any parameter that can be used by a node to configure 211 its network environment and enable communication on a 212 link or internetwork. 214 DHCP Client (or Client) 215 A node that initiates requests on a link to obtain 216 configuration parameters. 218 DHCP Server (or Server) 219 A server is a node that responds to requests from 220 clients to provide: addresses, prefix lengths, or 221 other configuration parameters. 223 DHCP Relay (or Relay) 224 A node that acts as an intermediary to deliver DHCP 225 messages between clients and servers. 227 DHCP Agent (or Agent) 228 Either a DHCP server or a DHCP relay. 230 Agent Address 231 The address of a neighboring DHCP Agent on the same 232 link as the DHCP client. 234 transaction-ID 235 The transaction-ID is a monotonically increasing 236 integer identifier specified by the client or server, 237 and used to match a response to a pending message. 239 binding A binding (or, client binding) in DHCP contains the 240 data which a DHCP server maintains for each of its 241 clients (see Section 6). 243 2.3. Specification Language 245 In this document, several words are used to signify the requirements 246 of the specification, in accordance with RFC 2119 [3]. These words 247 are often capitalized. 249 MUST This word, or the adjective "required", means that 250 the definition is an absolute requirement of the 251 specification. 253 MUST NOT This phrase means that the definition is an absolute 254 prohibition of the specification. 256 SHOULD This word, or the adjective "recommended", means 257 that there may exist valid reasons in particular 258 circumstances to ignore this item, but the full 259 implications must be understood and carefully 260 weighed before choosing a different course. 261 Unexpected results may result otherwise. 263 MAY This word, or the adjective "optional", means that 264 this item is one of an allowed set of alternatives. 265 An implementation which does not include this option 266 MUST be prepared to interoperate with another 267 implementation which does include the option. 269 silently discard 270 The implementation discards the datagram without 271 further processing, and without indicating an error 272 to the sender. The implementation SHOULD provide 273 the capability of logging the error, including the 274 contents of the discarded datagram, and SHOULD 275 record the event in a statistics counter. 277 3. Protocol Design Model 279 This section is provided for implementors to understand the DHCPv6 280 protocol design model from an architectural perspective. The goals, 281 conceptual models and implementation examples presented in this 282 section do not specify requirements of the DHCPv6 protocol. 284 3.1. Design Goals 286 The following list gives general design goals for this DHCP 287 specification. 289 - DHCP should be a mechanism rather than a policy. DHCP MUST allow 290 local system administrators control over configuration parameters 291 where desired; e.g., local system administrators should be able 292 to enforce local policies concerning allocation and access to 293 local resources where desired. 295 - DHCP MUST NOT introduce any requirement for manual configuration 296 of DHCP clients, except possibly for manually configured 297 keys. Each node should be able to discover appropriate 298 local configuration parameters without user intervention, and 299 incorporate those parameters into its own configuration. 301 - DHCP MUST NOT require a server on each link. To allow for scale 302 and economy, DHCP MUST work across DHCP relays. 304 - A DHCP client MUST be prepared to receive multiple (possibly 305 different) responses to solicitations for DHCP servers. Some 306 installations may include multiple, overlapping DHCP servers to 307 enhance reliability and/or to increase performance. 309 - DHCP MUST coexist with statically configured, non-participating 310 nodes and with existing network protocol implementations. 312 - DHCPv6 MUST be compatible with IPv6 Stateless Address 313 Autoconfiguration [15]. 315 - DHCP MUST support the requirements of automated renumbering of IP 316 addresses [4]. 318 - DHCP servers should be able to support Dynamic Updates to 319 DNS [16]. 321 - DHCP servers MUST be able to handle multiple IPv6 addresses for 322 each client. 324 - A DHCP server to server protocol is NOT part of this 325 specification. 327 - It is NOT a design goal of DHCP to specify how a server 328 configuration parameter database is maintained or determined. 329 Methods for configuring DHCP servers are outside the scope of 330 this document. 332 3.2. DHCP Messages 334 Each DHCP message contains a type, which defines their function 335 within the protocol. Processing details for these DHCP messages are 336 specified in Sections 5, 6, and 7. The message types are as follows: 338 01 DHCP Solicit 340 The DHCP Solicit message is a DHCP message sent to one or more 341 DHCP Agents. 343 02 DHCP Advertise 345 The DHCP Advertise is an IP unicast message from a DHCP Agent 346 in response to a client DHCP Solicit message. 348 03 DHCP Request 350 The DHCP Request is an IP unicast message from a client to a 351 server to request configuration parameters on a network. 353 04 DHCP Reply 355 The DHCP Reply is an IP unicast message sent by a server to 356 respond to a client's DHCP Request. Extensions [11] to the 357 DHCP Reply describe the resources that the DHCP Server has 358 committed and allocated to the client, and may contain other 359 information for use by the client. 361 05 DHCP Release 363 The DHCP Release message is used by a DHCP client to inform 364 the server that the client is releasing a particular address, 365 or set of addresses or resources, so that the server may 366 subsequently mark the addresses as invalid, or release 367 resources in the server's binding for the client. 369 06 DHCP Reconfigure 371 The DHCP Reconfigure message is used by a DHCP server to inform 372 its client that the server has new configuration information of 373 importance to the client. The client is expected to initiate a 374 new Request/Reply transaction. 376 3.3. Request/Response Processing Model 378 The request/response processing for DHCPv6 is transaction based 379 and uses a best-effort set of messages to guarantee a completed 380 transaction. 382 Transactions are usually started by a client with a DHCP Request, 383 which may be issued after the client knows the server's address. 384 The response (DHCP Reply) is from the server (possibly via a DHCP 385 Relay). At this point in the flow all data has been transmitted 386 and, hopefully, received. To provide a method of recovery if either 387 the client or server do not receive the messages to complete the 388 transaction, the client is required to retransmit any DHCP Request 389 message until it elicits the corresponding DHCP Reply or Replies, 390 or until it can be reasonably certain that the desired DHCP Server 391 is unavailable. The timeout and retransmission guidelines and 392 configuration variables are discussed in Section 8. DHCP uses the 393 UDP [13] protocol to communicate between clients and servers. UDP is 394 not reliable, but DHCP the retransmission scheme in the referenced 395 section provides reliability between clients and servers. 397 The following well-known multicast addresses are used by DHCP Agents: 399 FF02:0:0:0:0:0:1:2 400 All DHCP Agents (Servers and Relays) MUST join the 401 link-local All-DHCP-Agents multicast group at the address 402 FF02:0:0:0:0:0:1:2. 404 FF05:0:0:0:0:0:1:3 405 All DHCP Servers MUST, in addition, join the site-local 406 All-DHCP-Servers multicast group at the address 407 FF05:0:0:0:0:0:1:3. 409 FF05:0:0:0:0:0:1:4 410 All DHCP Relays MUST, on the other hand, join in addition 411 the site-local All-DHCP-Relays multicast group at the 412 address FF05:0:0:0:0:0:1:4. 414 A client MUST transmit all messages over UDP using port 547 as the 415 destination port. A client MUST receive all messages from UDP port 416 546. 418 A DHCP Agent MUST transmit all messages to clients over UDP using 419 port 546 as the destination port. A DHCP Agent MUST receive all 420 messages over UDP using port 547. The source port for DHCP messages 421 is arbitrary. 423 4. DHCP Message Formats and Field Definitions 425 All fields in DHCP messages MUST be initialized to binary zeroes by 426 both the client and server unless otherwise noted. DHCP message 427 types not defined here (msg-types 0 and 7-255) are reserved. 429 4.1. DHCP Solicit Message Format 431 A DHCP client (or DHCP relay on behalf of a client) transmits a DHCP 432 Solicit message to obtain one or more DHCP server addresses. 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | msg-type |C|A| reserved | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | client's link-local address | 440 | (16 octets) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | relay address | 443 | (16 octets, if present) | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 msg-type 1 448 C If set, the client requests that all servers receiving 449 the message deallocate the resources associated with 450 the client. 452 A If set, the relay's address is present 454 reserved 0 456 client's link-local address 457 The IP link-local address of the client interface from 458 which the client issued the DHCP Request message 460 relay address 461 If present, the IP address of the interface on which 462 the relay received the client's DHCP Solicit message 464 To discover a DHCP Agent address a DHCP client SHOULD send a DHCP 465 Solicit message to the All-DHCP-Agents multicast address (see 466 section 3.3). Any DHCP Relay receiving the solicitation MUST forward 467 it to the All-DHCP-Servers multicast address, to instruct DHCP 468 Servers to send their advertisements to the prospective client. In 469 that case, the relay MUST insert the address of its interface from 470 which the client's solicitation was received into the agent's address 471 field, and set the 'A' bit. 473 DHCP clients MUST NOT issue any DHCP solicitation which is long 474 enough so that inserting the Relay Address field would cause the 475 message to exceed the MTU advertised on the link. 477 4.2. DHCP Advertise Message Format 479 A DHCP agent sends a DHCP Advertise message to inform a prospective 480 client about the IP address of a DHCP Agent to which a DHCP Request 481 message may be sent. When the client and server are on different 482 links, the server sends the advertisement back through the DHCP Relay 483 whence the solicitation came. 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | msg-type |S| reserved | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | agent address | 491 | (16 octets) | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | client's link-local address | 494 | (16 octets) | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | server address | 497 | (16 octets, if present) | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | extensions (variable number and length) ... 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 msg-type 2 504 S If set, the agent address is also a server address. 506 reserved 0 508 agent address 509 The IP address of a DHCP Agent interface on the same 510 link as the client. 512 client's link-local address 513 The IP link-local address of the client interface 514 from which the client issued the DHCP Request message 516 server address 517 The IP address of the DHCP server 519 extensions See [11]. 521 Suppose that a DHCP server on the same link as a client issues the 522 DHCP Advertise in response to a DHCP Solicit message sent to the 523 All-DHCP-Agents multicast address. Then the agent address will be 524 the IP address of one of the server's interfaces, the 'S' bit will be 525 set, the agent address will be an address of the server, and there 526 will be no server address sent in the DHCP Advertise message. 528 The DHCP Server MUST copy the client's link-local address into the 529 advertisement which is sent in response to a DHCP Solicit. Both 530 Agent address and server address (if present) of the DHCP Advertise 531 message MUST have sufficient scope to be reachable by the DHCP 532 Client. Moreover, the Agent address of any DHCP Advertise message 533 sent by a DHCP relay MUST NOT be a link-local address. In situations 534 where there are no routers sending Router Advertisements, then a DHCP 535 Server MUST be configured on the same link as prospective clients. 536 The DHCPv6 protocol design does not apply to sitations where the 537 client has no way to route messages to a server not on the same link 539 4.3. DHCP Request Message Format 541 In order to request parameters from a DHCP server, a client sends a 542 DHCP Request message, and MAY append extensions [11]. If the client 543 does not know any DHCP server address, it MUST first obtain a server 544 address by multicasting a DHCP Solicit message (see Section 4.1). If 545 the client does not have a valid IP address of sufficient scope for 546 the DHCP server to communicate with the client, client MUST send the 547 message to the local DHCP Relay and insert the DHCP Relay address as 548 the agent address in the message header. In this case, the client 549 cannot send the message directly to the DHCP server because the 550 server could not return any response to the client. Otherwise, the 551 client MAY omit the server address in the DHCP Request message; in 552 this case, the client MUST send the DHCP Request message directly to 553 the server, using the server address as the IP destination address in 554 the IP header. 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | msg-type |S|C| reserved | transaction-ID | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | server address | 562 | (16 octets, if present) | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | agent address | 565 | (16 octets) | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | client's link-local address | 568 | (16 octets) | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | extensions (variable number and length) .... 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 msg-type 3 575 S If set, the server address is present 577 C If set, the client requests the server to clear all 578 other existing resources and bindings (not requested 579 in extensions) currently associated with the client, 580 deallocating as needed. 582 reserved 0 584 transaction-ID 585 A monotonically increasing number used to identify this 586 Request, and copied into the Reply. 588 server address 589 If present, the IP address of the DHCP server which 590 should receive the client's DHCP Request message. 592 agent address 593 The IP address of an agent interface, copied from a 594 DHCP Advertisement message. 596 client's link-local address 597 The IP link-local address of the client interface from 598 which the client issued the DHCP Request message 600 extensions See [11]. 602 4.4. DHCP Reply Message Format 604 The server sends one DHCP Reply message in response to every DHCP 605 Request or DHCP Release received. If the request comes with the 'S' 606 bit set, the client could not directly send the Request to the server 607 and had to use a neighboring relay agent. In that case, the server 608 sends back the DHCP Reply with the 'L' bit set, and the DHCP Reply is 609 addressed to the agent address found in the DHCP Request message. If 610 the 'L' bit is set, then the client's link-local address will also be 611 present. 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | msg-type |L| error code | transaction-ID | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | client's link-local address | 619 | (16 octets, if present) | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | extensions (variable number and length) .... 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 msg-type 4 626 L If set, the link-local address is present 628 error code 629 One of the following values: 631 0 Success 632 16 Failure, reason unspecified 633 17 Authentication failed or nonexistent 634 18 Poorly formed Request or Release 635 19 Resources unavailable 636 20 Client record unavailable 637 21 Invalid client IP address in Release 638 23 Relay cannot find Server Address 639 24 Cannot understand selected Character Set 640 64 Server unreachable (ICMP error) 642 transaction-ID 643 A monotonically increasing number used to identify this 644 Reply, and copied from the client's Request. 646 client's link-local address 647 If present, the IP address of the client interface 648 which issued the corresponding DHCP Request message. 650 extensions 651 See [11]. 653 If the 'L' bit is set, and thus the link-local address is present in 654 the Reply message, the Reply is sent by the server to the relay's 655 address which was specified as the agent address in the DHCP Request 656 message, and the relay uses the link-local address to deliver the 657 Reply message to the client. 659 4.5. DHCP Release Message Format 661 The DHCP Release message is sent without the assistance of any DHCP 662 relay. When a client sends a Release message, it is assumed to 663 have a valid IP address with sufficient scope to allow access to 664 the target server. Only the parameters which are specified in the 665 extensions are released. The DHCP server acknowledges the Release 666 message by sending a DHCP Reply (Sections 4.4, 6.3). 668 0 1 2 3 669 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 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | msg-type |D| reserved | transaction-ID | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | agent address | 674 | (16 octets) | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | client's link-local address | 677 | (16 octets) | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | client address | 680 | (16 octets, if present) | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | extensions (variable number and length) .... 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 msg-type 5 687 D If the 'D' ("Direct") flag is set, the client instructs 688 the server to send the DHCP Reply directly back to the 689 client, instead of using the given agent address and 690 link-local address to relay the Reply message. 692 reserved 0 694 transaction-ID 695 A monotonically increasing number used to identify this 696 Release, and copied into the Reply. 698 agent address 699 The IP address of the agent interface to which the 700 client issued the DHCP Request message 702 client's link-local address 703 The IP link-local address of the client interface from 704 which the the client issued the DHCP Request message 706 client address 707 The IP address of the client interface from which the 708 the client issued the DHCP Request message. The client 709 address field is present whenever the 'D' bit is set, 710 even if it is equal to the link-local address. 712 extensions See [11] 714 Suppose that the client has an IP address that will still be valid 715 after the server performs the operations requested in the extensions 716 to the DHCP Release message. In that case, and only then, the client 717 SHOULD then specify the 'D' flag. When the 'D' flag is set, the 718 server MUST send the DHCP Reply back to the client's address as shown 719 in the client address field of the Release message. Otherwise, when 720 the 'D' bit is not set, the server MUST send its DHCP Reply message 721 to the agent address in the Release message, so that the relay agent 722 can subsequently forward the Reply back to the releasing client at 723 the client's link-local address indicated in the Reply message. 724 Note that it is an error (Error Code 21) to include within the DHCP 725 Release message both the 'D' bit and an IP address extension which 726 has the IP address used as the client IP address field of the DHCP 727 Release message header. 729 4.6. DHCP Reconfigure Message Format 731 The DHCP Reconfigure message is sent without the assistance of any 732 DHCP relay. When a server sends a Reconfigure message, the client 733 to which it is sent is assumed to have a valid IP address with 734 sufficient scope to be accessible by the server. Only the parameters 735 which are specified in the extensions to the Reconfigure message need 736 be requested again by the client. 738 0 1 2 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | msg-type | reserved | transaction-ID | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | server address | 744 | (16 octets) | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | extensions (variable number and length) .... 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 msg-type 6 751 reserved 0 753 transaction-ID 754 A monotonically increasing number used to identify 755 this Reconfigure message, and copied into the 756 client's Request. 758 server address 759 The IP address of the DHCP server issuing the DHCP 760 Reconfigure message. 762 extensions See [11] 764 5. DHCP Client Considerations 766 A DHCP client MUST silently discard any DHCP Solicit, DHCP Request, 767 or DHCP Release message it receives. 769 5.1. Verifying Resource Allocations After Restarts 771 A DHCP client MAY retain its configured parameters and resources 772 across client system reboots and DHCP client program restarts. 773 However, in these circumstances a DHCP client MUST also formulate a 774 DHCP Request message to verify that its configured parameters and 775 resources are still valid. This Request message MUST have the 'C' 776 bit set, to clean up stale client binding information at the server 777 which may no longer be in use by the client; stale information is 778 that which the client does not include in extensions to such request 779 messages. 781 If the server does not respond to the DHCP Request message, the 782 client may still use any resources whose lifetimes have not yet 783 expired. In such cases, however, the client MUST begin to search 784 for another server by multicasting a new DHCP Solicit message, again 785 with the 'C' bit set, containing its IP address in the appropriate 786 extension. 788 This also handles the case wherein a client restarts on a new 789 network, so that its IP address is no longer valid. When the client 790 multicasts a new DHCP Discover message, servers will respond with 791 the information needed for the client to release its old address, if 792 need be, and request an address reachable on the new network. In 793 this situation, when the client receives a new IP address and the old 794 IP address is no longer reachable, the client MUST release its old 795 IP address by issuing a DHCP Release message with the appropriate 796 extension. 798 5.2. Sending DHCP Solicit Messages 800 A DHCP client MUST have the address of a DHCP Server to send a 801 Request message. The client may locate a DHCP Server by multicasting 802 a DHCP Solicit message to the All-DHCP-Agents link-local multicast 803 address, setting the Hop Limit == 1 (see Section 3.3). If there 804 are no DHCP servers on the same link as the node, then a DHCP Relay 805 MUST be present for further handling of the solicitation. The 806 prospective client SHOULD wait for ADV_WAIT seconds to get all the 807 DHCP Advertisement messages which may be sent in response to the 808 solicitation. 810 If a DHCP client reboots and does not have a valid IP address, 811 it MUST set the 'C' bit in the DHCP Solicit message it sends 812 when restarting. By setting the 'C' bit in the solicitation, a 813 DHCP client requests that all the DHCP Servers that receive the 814 solicitation should clean up their stale client records that match 815 its link-local address. 817 If a client sends a DHCP Solicit message after it reboots, the 818 solicitation SHOULD be delayed after reception of the first Router 819 Advertisement [10] message, by at least some random amount of time 820 between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY seconds. This delay 821 is intended to help stagger requests to DHCP Servers (and avoid 822 link-layer collisions) after a power outage causes many nodes to 823 reboot all at once. Each subsequent DHCP Solicit message that is 824 issued before receiving an advertisement MUST be delayed by twice the 825 amount by which the previous DHCP Solicit message was delayed, plus 826 a small random delay between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY 827 seconds. 829 5.3. Receiving DHCP Advertise Messages 831 After a DHCP Client has received a DHCP Advertise message, it has 832 the address of a DHCP Server for subsequent DHCP Request messages. 833 If the Advertise message has no server address field and does 834 not have the 'S' bit set, the client MUST silently discard the 835 message. If the server's address is shown as a Multicast address, 836 the advertisement MUST be silently discarded. 838 If the 'S' bit is set, the DHCP Advertise message was transmitted 839 by a DHCP server on the same link as the client. In this case, any 840 future DHCP message transactions sent to that server MUST be sent by 841 the client to the agent address indicated by the 'S' bit. 843 Advertisements may have extensions; this might allow the DHCP client 844 to select the configuration that best meets its needs from among 845 several prospective servers. 847 5.4. Sending DHCP Request Messages 849 A DHCP client obtains configuration information from a DHCP server by 850 sending a DHCP Request message. The client MUST know the server's 851 address before sending the Request message, and client MUST have 852 acquired a (possibly identical) DHCP agent address. If the client 853 and server are on the same link, the agent address used by the client 854 MUST be the same as the DHCP server's address. A DHCP Request 855 message MUST NOT be sent to any multicast address, since otherwise 856 multiple DHCP agents would possibly allocate resources to the client 857 in response to the same Request, and the client would have no way to 858 know which servers had made the allocations, if any datagrams were 859 lost due to collisions, etc. 861 If the client has no valid IP address of sufficient scope, and the 862 DHCP server is off-link, then the client MUST include the server 863 address in the appropriate field of the DHCP Request message and set 864 the 'S' bit. In this case, the IP destination address of the Request 865 message will be a DHCP relay address. 867 Otherwise, if the client already has a valid IP address of sufficient 868 scope and knows the IP address of a candidate DHCP server, it 869 SHOULD send the Request message directly to the DHCP server without 870 requiring the services of the local DHCP relay. 872 If a client wishes to instruct a DHCP server to deallocate all 873 unknown previous resources, configuration information, and bindings 874 associated with its agent address and link-local address, it sets the 875 'C' bit in the DHCP Request. A client MAY send in such a Request 876 even when it is no longer attached to the link on which the relay 877 address is attached. 879 In any case, after choosing a transaction-ID which is numerically 880 greater than its previous transaction-ID, and filling in the 881 appropriate fields of the DHCP Request message, the client MAY append 882 various DHCP Extensions to the message. These extensions denote 883 specific requests by the client; for example, a client may request 884 a particular IP address, or request that the server send an update 885 containing the client's new IP address to a Domain Name Server. When 886 all desired extensions have been applied, the DHCP client unicasts 887 the DHCP Request to the appropriate DHCP Agent. 889 For each pending DHCP Request message, a client MUST maintain the 890 following information: 892 - The transaction-ID of the request message, 893 - The server address, 894 - The agent address (which can be the same as the server address), 895 - The time at which the next retransmission will be attempted, and 896 - All extensions appended to the request message. 898 If a client does not receive a DHCP Reply message (Section 5.5) with 899 the same transaction-ID as a pending DHCP Request message within 900 REPLY_MSG_INITIAL_TIMEOUT seconds, or if the received DHCP Reply 901 message contains a DHCP Authentication extension which fails to 902 provide the correct authentication information, the client MUST 903 retransmit the Request with the same transaction-ID and continue to 904 retransmit according to the rules in Section 8. 906 If the client transmits a DHCP Request in response to a DHCP 907 Reconfigure message (see Section5.7), the client can continue to 908 operate with its existing configuration information and resources 909 until it receives the corresponding DHCP Reply from the server. The 910 same retransmission rules apply as for any other DHCP Request message 911 from the client. 913 5.5. Receiving DHCP Reply Messages 915 When a client receives a DHCP Reply message, it MUST check whether 916 the transaction-ID in the Reply message matches the transaction-ID 917 of a pending DHCP Request message. If no match is found, the Reply 918 message MUST be silently discarded. 920 If the Reply message is acceptable, the client processes each 921 Extension [11], extracting the relevant configuration information 922 and parameters for its network operation. The client can determine 923 when all extensions in the Reply have been processed by using the 924 Length field of the Reply. Some extensions in the Reply may have 925 error codes, when the server was unable to honor the request, which 926 will indicate to the client the reason for failure. If the server is 927 unable to honor the request in an extension included by the client, 928 that extension may simply be omitted from the Reply. 930 Some configuration information extracted from the extensions to the 931 DHCP Reply message MUST remain associated with the DHCP server that 932 sent the message. The particular extensions that require this extra 933 measure of association with the server are indicated in the DHCP 934 Extensions document [11]. These "resource-server" associations are 935 used when sending DHCP Release messages. 937 5.6. Sending DHCP Release Messages 939 If a DHCP client determines that some of its network configuration 940 parameters are no longer needed, it SHOULD enable the DHCP server to 941 release allocated resources which are no longer in use by sending a 942 DHCP Release message to the server. The client consults its list 943 of resource-server associations in order to determine which server 944 should receive the desired Release message. If a client wishes to 945 ask the server to release all information and resources relevant to 946 the client, the client specifies no extensions; this is preferable 947 to sending a DHCP Request message with the 'C' bit set and no 948 extensions. 950 Suppose a client wishes to release resources which were granted to 951 it on another link. In that case, the client MUST instruct the 952 server to send the DHCP Reply directly back to the client, instead 953 of performing the default processing of sending the DHCP Reply back 954 through the agent-address included in the DHCP Release. This is done 955 by setting the 'D' bit in the DHCP Release message (see section 4.5). 957 5.7. Receiving DHCP Reconfigure Messages 959 Each DHCP client MUST listen at UDP port 546 to receive possible 960 DHCP Reconfigure messages, except in cases where the client knows 961 that no Reconfigure message will ever be issued. In some cases, 962 the IP address at which the client listens will be a multicast 963 address sent to the client by the DHCP server in an extension to 964 an earlier DHCP Reply message. If the client does not listen for 965 DHCP Reconfigure messages, it is possible that the client will 966 not receive notification that its DHCP server has deallocated the 967 client's IP address and/or other resources allocated to the client. 968 See discussion in 6.5. The client MAY receive an update to the 969 prefix for their addresses and then MUST use that prefix for their 970 addresses. 972 If a DHCP client receives a DHCP Reconfigure message, it is a request 973 for the client to initiate a new DHCP Request/Reply transaction with 974 the server which sent the Reconfigure message. The server sending 975 the Reconfigure message MAY be different than the server which sent a 976 DHCP Reply message containing the original configuration information. 978 For each Extension which is present in the Reconfigure message, the 979 client appends a matching Extension to its Request message, which 980 it formulates to send to the server specified in the server address 981 field of the message. The client also copies a transaction-ID from 982 the Reconfigure message into the Request message. From then on, 983 processing is the same as specified above in Section 5.4. 985 Resources held by the client which are not identified by Extensions 986 in the server's Reconfigure message are not affected. 988 Note that a server may ask its client to join a multicast group 989 for the purpose of receiving DHCP Reconfigure messages. When a 990 Reconfigure message is delivered to the client by way of the selected 991 multicast address, the client MUST delay its further response for 992 a random amount of time uniformly distributed within the interval 993 between RECONF_MSG_MIN_RESP and RECONF_MSG_MAX_RESP seconds. This 994 will minimize the likelihood that the server will be bombarded with 995 DHCP Request messages all at the same time. 997 6. DHCP Server Considerations 999 A server MUST ignore any DHCP Advertise, DHCP Reply, or DHCP 1000 Reconfigure message it receives. 1002 A server maintains a collection of client records, called 1003 ``bindings''. Each binding is uniquely identifiable by the ordered 1004 pair , since the link-local 1005 address is guaranteed to be unique [15] on the link identified 1006 by the agent address. An implementation MUST support bindings 1007 consisting of at least a client's link-local address, agent address, 1008 preferred lifetime and valid lifetime [15] for each client address, 1009 and the transaction-ID. A client binding may be used to store any 1010 other information, resources, and configuration data which will be 1011 associated with the client. A DHCP server MUST retain its clients' 1012 bindings across server reboots, and, whenever possible, a DHCP client 1013 should be assigned the same configuration parameters despite server 1014 system reboots and DHCP server program restarts. A DHCP server MUST 1015 support fixed or permanent allocation of configuration parameters to 1016 specific clients. 1018 6.1. Receiving DHCP Solicit Messages 1020 If the DHCP Solicit message was received at the All-DHCP-Servers 1021 multicast address, the DHCP Server MUST check to make sure that the 1022 agent address is present, and not a link-local address. Otherwise, 1023 if the agent address is not present, or if it is a link-local 1024 address, the server MUST silently discard the packet. If the UDP 1025 length disagrees with the length determined by the format of the 1026 DHCP Solicit message, the server MUST drop the packet and SHOULD log 1027 the error. Note that if the client sends a DHCP Solicit message 1028 from a link-local address, the multicast destination will be the 1029 All-DHCP-Agents address, not the All-DHCP-Servers address. 1031 6.2. Sending DHCP Advertise Messages 1033 Upon receiving and verifying the correctness of a DHCP Solicit 1034 message, a server constructs a DHCP Advertise message and transmits 1035 it on the same link as the solicitation was received from. If the 1036 'A' bit is set, the advertisement MUST be sent to the relay address; 1037 otherwise, the server MUST send the advertisement to the client's 1038 link-local address. An IP address of the interface on which the 1039 server receives the Solicit message MUST appear in the server address 1040 field of the corresponding advertisement. 1042 The DHCP server MAY append extensions to the Advertisement, in order 1043 to offer the soliciting node the best possible information about 1044 the services and resources which the server may be able to make 1045 available. 1047 6.3. DHCP Request and Reply Message Processing 1049 The DHCP server MUST check to ensure that the client's link-local 1050 address field of the Request message contains a link-local address. 1051 If not, the message MUST be silently discarded. Otherwise, it checks 1052 for the presence of the 'S' bit. If the 'S' bit is set, the server 1053 MUST check that the server address matches the destination IP address 1054 at which the Request message was received by the server. If the 1055 server address does not match, the Request message MUST be silently 1056 discarded. 1058 If the received agent address and link-local address do not 1059 correspond to any binding known to the server, then the server 1060 MAY create a new binding for the previously unknown client, and 1061 send a DHCP Reply with any resources allocated to the new binding. 1062 Otherwise, it SHOULD return a DHCP Reply with an error code of 19. 1064 While processing the Request, the server MUST first determine whether 1065 or not the Request is a retransmission of an earlier DHCP Request 1066 from the same client. This is done by comparing the transaction-ID 1067 to all those transaction-IDs received from the same client during the 1068 previous XID_TIMEOUT seconds. If the transaction-ID is the same as 1069 one received during that time, the server MUST take the same action 1070 (e.g., retransmit the same DHCP Reply to the client) as it did after 1071 processing the previous DHCP Request with the same transaction-ID. 1073 Otherwise, if the server has no record of a message from the client 1074 with the same transaction-ID, the server identifies and allocates 1075 all the relevant information, resources, and configuration data that 1076 is associated with the client. Then it sends that information to 1077 its DHCP client by constructing a DHCP Reply message and including 1078 the client's information in DHCP Extensions to the Reply message. 1079 The DHCP Reply message uses the same transaction-ID as found in the 1080 received DHCP Request message. Note that the reply message MAY 1081 contain information not specifically requested by the client. 1083 If the DHCP Request message has the 'S' bit set in the message 1084 header, then the Request was sent to the server by a DHCP Relay. In 1085 this case, the DHCP server MUST send the corresponding DHCP Reply 1086 message to the agent address found in the Request (see section 7.2). 1088 6.3.1. Processing for Extensions to DHCP Request and Reply Messages 1090 The DHCP Request may contain extensions, which are interpreted 1091 (by default) as advisory information from the client about its 1092 configuration preferences. For instance, if the IP Address Extension 1093 is present, the DHCP server SHOULD attempt to allocate or extend the 1094 lifetime of the address indicated by the extension. Some extensions 1095 may be marked by the client as required. 1097 The DHCP server may accept some extensions for successful processing 1098 and allocation, while still rejecting others, or the server may 1099 reject various extensions for different reasons. The server sets 1100 the Error Code appropriately for those extensions which return error 1101 status to the client. The DHCP server sends a single Reply message 1102 in response to each DHCP Request, with the same transaction-ID as the 1103 Request. 1105 Whenever it is able to, the server includes an extension in the 1106 Reply message for every extension sent by the client in the Request 1107 message. If the client requests some extensions that cannot be 1108 supplied by the server, the server can simply fail to provide them, 1109 not including them in the Reply. Other extensions can be rejected by 1110 including them in the Reply with an appropriate error code indicating 1111 failure. 1113 6.3.2. Client Requests to Deallocate Unknown Resources 1115 When a client DHCP Request is received that has the 'C' bit set, the 1116 server should check to find out whether the extensions listed in the 1117 Request message match those which it has associated with the client's 1118 binding. Any resources which are not indicated by the client are 1119 presumed to be unknown by the client, and thus possible candidates 1120 for reallocation to satisfy requests from other clients. The DHCP 1121 Server MUST deallocate all resources associated with the client 1122 upon reception of a DHCP Request with the 'C' bit set, except for 1123 those which the server is willing to reallocate in response to the 1124 client's request. It may be more efficient to avoid deallocating any 1125 resources until after the list of extensions to the request have been 1126 inspected. 1128 6.4. Receiving DHCP Release Messages 1130 If the server receives a DHCP Release Message, it MUST verify that 1131 the link-local address field of the message contains an address 1132 which could be a valid link-local address (i.e., one with the prefix 1133 FE80::0000/64). If not, the message MUST be silently discarded. 1135 In response to a DHCP Release Message with a valid client's 1136 link-local address and agent address, the DHCP server formulates a 1137 DHCP Reply message that will be sent back to the releasing client by 1138 way of the client's link-local address. A DHCP Reply message sent 1139 in response to a DHCP Release message MUST be sent to the client's 1140 link-local address via the agent address in the Release message 1141 and set the 'L' bit in the Reply, unless the 'D' bit is set in the 1142 Release message. 1144 If the received agent address and link-local address do not 1145 correspond to any binding known to the server, then the server SHOULD 1146 return a DHCP Reply with an error code of 20. 1148 Otherwise, if the agent address and link-local address indicate a 1149 binding known to the server, then the server continues processing the 1150 Release message. If there are any extensions, the server releases 1151 the particular configuration items specified in the extensions. 1153 Otherwise, if there are no extensions, the server releases all 1154 configuration information in the client's binding. 1156 After performing the operations indicated in the DHCP Release message 1157 and its extensions, the DHCP server formulates a DHCP Reply message, 1158 copying the transaction-ID, from the DHCP Release message. For 1159 each Extension in the DHCP Release message successfully processed 1160 by the server, a matching Extension is appended to the DHCP Reply 1161 message. For extensions in the DHCP Release message which cannot be 1162 successfully processed by the server, a DHCP Reply message containing 1163 extensions with the appropriate error codes MUST be returned by the 1164 server. 1166 6.5. Sending DHCP Reconfigure Messages 1168 If a DHCP server needs to change the configuration associated to any 1169 of its clients, it constructs a DHCP Reconfigure message and sends it 1170 to each such client [11]. The Reconfigure MAY be sent to a multicast 1171 address chosen by the server and sent to each of its clients in an 1172 extension to a previous DHCP Reply message. 1174 7. DHCP Relay Considerations 1176 The DHCP protocol is constructed so that a relay does not have 1177 to maintain any state in order to facilitate DHCP client/server 1178 interactions. 1180 All relays MUST send DHCP Request messages out from an IP address of 1181 the interface from which the DHCP request was received. 1183 The main purpose of the DHCP Relay is to enable clients and servers 1184 to carry out DHCP protocol transactions. DHCP Solicit messages are 1185 issued by the relay when initiated by prospective DHCP clients. 1186 By default, the relay discovers local DHCP Servers by use of 1187 multicasting DHCP solicitations to the All-DHCP-Servers multicast 1188 address, but relays SHOULD allow this behavior to be configurable. 1189 The relay SHOULD NOT send such a multicast solicitation on the 1190 interface from which it received the solicitation from the client. 1192 7.1. DHCP Solicit and DHCP Advertise Message Processing 1194 Upon receiving a DHCP Solicit message from a prospective client, a 1195 relay, by default, forwards the message to all DHCP Servers at a site 1196 according to the following procedure: 1198 - copying the prospective client's solicitation message fields into 1199 the appropriate fields of the outgoing solicitation, 1201 - setting the 'A' bit, 1203 - copying the address of its interface from which the solicitation 1204 was received from the client into the DHCP Relay address field, 1205 and 1207 - finally, sending the resulting message to the All-DHCP-Servers 1208 multicast address, FF05:0:0:0:0:0:1:3, over all interfaces except 1209 that from which the client's solicitation was received. 1211 When the relay receives a DHCP advertisement, it relays the 1212 advertisement to the client at the client's link-local address by way 1213 of the interface indicated in the agent's address field. 1215 7.2. DHCP Request Message Processing 1217 When a relay receives a DHCP Request message, it SHOULD check 1218 that the message is received from a link-local address, that the 1219 link-local address matches the link-local address field in the 1220 Request message header, and that the agent address field of the 1221 message matches an IP address associated to the interface from which 1222 the DHCP Request message was received. If any of these checks fail, 1223 the Relay MUST silently discard the Request message. 1225 The relay MUST also check whether the 'S' bit is set in the message 1226 header. If not, the datagram is discarded, and the relay SHOULD 1227 return a DHCP Reply message to the address contained in the client's 1228 link-local address field of the Request message, with error code 18. 1230 If the received request message is acceptable, the relay then 1231 transmits the DHCP Request message to the address of the DHCP 1232 server found in the Server IP Address field of the received DHCP 1233 Request message. All of the fields of DHCP Request message header 1234 transmitted by the relay are copied over unchanged from the DHCP 1235 Request received from the client. Only the fields in the IP header 1236 will differ from the datagram received from the client, not the 1237 payload. If the Relay receives an ICMP error, the Relay SHOULD 1238 return a DHCP Reply message to the client address (which can be found 1239 in the payload of the ICMP message [5]), with error code 64. 1241 7.3. DHCP Reply Message Processing 1243 When the relay receives a DHCP Reply, it MUST check whether the 1244 message has the 'L' bit set. It MUST check whether the link-local 1245 address field contains a link-local address. If all the checks are 1246 satisfied, the relay MUST send a DHCP Reply message to the link-local 1247 address listed in the received Reply message. Only the fields in the 1248 IP header will differ from the datagram received from the server, not 1249 the payload. 1251 8. Retransmission and Configuration Variables 1253 When a DHCP client does not receive a DHCP Reply in response to a 1254 pending DHCP Request, the client MUST retransmit the identical DHCP 1255 Request, with the same transaction-ID, to the same server again 1256 until it can be reasonably sure that the DHCP server is unavailable 1257 and an alternative can be chosen. The DHCP Server assumes that the 1258 client has received the configuration information included with the 1259 extensions to the DHCP Reply message, and it is up to the client 1260 to continue to try for a reasonable amount of time to complete the 1261 transaction in order to make that assumption hold true. All the 1262 actions specified for DHCP Request in this section hold also for DHCP 1263 Release messages sent by the DHCP Client. 1265 Similarly, when a client sends a DHCP Request message in response to 1266 a Reconfigure message from the server, the client assumes that the 1267 DHCP server has received the Request. The server MUST retransmit the 1268 identical DHCP Reconfigure to the client for a reasonable amount of 1269 time, to try to elicit the Request message from the client, in order 1270 to make the best effort for that assumption to hold true. If no 1271 corresponding DHCP Request is ever received by the server, the server 1272 MAY erase or deallocate information as needed from the client's 1273 binding. 1275 These retransmissions occur using the following configuration 1276 variables for a DHCP implementation that MUST be configurable by a 1277 client or server: 1279 ADV_WAIT 1281 The amount of time a client waits to hear DHCP Advertisements 1282 after issuing a DHCP Solicit to the All-DHCP Agents multicast 1283 address. 1285 Default: 5 seconds 1287 REPLY_MSG_INITIAL_TIMEOUT 1289 The time in seconds that a DHCP client waits to receive a 1290 server's DHCP Reply before retransmitting a DHCP Request. 1292 Default: 2 seconds. 1294 REPLY_MSG_MIN_RETRANS 1296 The minimum number of DHCP Request transmissions that a DHCP 1297 client should retransmit, before aborting the request, possibly 1298 retrying the Request with another Server, and logging a DHCP 1299 System Error. 1301 Default: 10 retransmissions. 1303 REPLY_MSG_RETRANS_INTERVAL 1305 The time between successive retransmissions of DHCP Request 1306 messages. 1308 Default: 2 seconds. 1310 RECONF_MSG_INITIAL_TIMEOUT 1312 The time in seconds that a DHCP server waits to receive 1313 a client's DHCP Request before retransmitting its DHCP 1314 Reconfigure. 1316 Default: 2 seconds. 1318 RECONF_MSG_MIN_RETRANS 1320 The minimum number of DHCP Reconfigure messages that a DHCP 1321 server should retransmit, before assuming the the client is 1322 unavailable and that the server can proceed with the needed 1323 reconfiguration of that client's resources, and logging a DHCP 1324 System Error. 1326 Default: 10 retransmissions. 1328 RECONF_MSG_RETRANS_INTERVAL 1330 The least time between successive retransmissions of DHCP 1331 Reconfigure messages. 1333 Default: 2 seconds. 1335 RECONF_MSG_MIN_RESP 1337 The minimum amount of time before a client can respond to a 1338 DHCP Reconfigure message sent to a multicast address. 1340 Default: 2 second. 1342 RECONF_MSG_MAX_RESP 1344 The maximum amount of time before a client MUST respond to a 1345 DHCP Reconfigure message sent to a multicast address. 1347 Default: 10 seconds. 1349 MIN_SOLICIT_DELAY 1351 The maximum amount of time a prospective client is required 1352 to wait, after determining from a Router Discovery message 1353 that the client should perform stateful address configuration, 1354 before sending a DHCP Solicit to a DHCP Server. 1356 Default: 1 second 1358 MAX_SOLICIT_DELAY 1360 The maximum amount of time a prospective client is required 1361 to wait, after determining from a Router Discovery message 1362 that the client should perform stateful address configuration, 1363 before sending a DHCP Solicit to a DHCP Server. 1365 Default: 5 seconds 1367 XID_TIMEOUT 1369 The amount of time a DHCP server has to keep track of 1370 client transaction-IDs in order to make sure that client 1371 retransmissions using the same transaction-ID are idempotent. 1373 Default: 600 seconds 1375 Note that, if a client receives a DHCP message which fails 1376 authentication, it should continue to wait for another message which 1377 might be correctly authenticated just as if the failed message had 1378 never arrived; however, receiving such failed messages SHOULD be 1379 logged. 1381 9. Security Considerations 1383 DHCP clients and servers often have to authenticate the messages they 1384 exchange. For instance, a DHCP server may wish to be certain that a 1385 DHCP Request originated from the client identified by the fields included within the Request message 1387 header. Conversely, it is often essential for a DHCP client to 1388 be certain that the configuration parameters and addresses it has 1389 received were sent to it by an authoritative DHCP server. Similarly, 1390 a DHCP server should only accept a DHCP Release message which seems 1391 to be from one of its clients, if it has some assurance that the 1392 client actually did transmit the Release message. At the time of 1393 this writing, there is no generally accepted mechanism useful with 1394 DHCPv4 that is appropriate for use with DHCPv6. 1396 The IPv6 Authentication Header can provide security for DHCPv6 1397 messages when both endpoints have a suitable IP address. However, 1398 a client often has only a link-local address, and such an address 1399 is not sufficient for a DHCP server which is off-link. In those 1400 circumstances the DHCP relay is involved, so that the DHCP message 1401 MUST have the relay's address in the IP destination address field, 1402 even though the client aims to deliver the message to the DHCP 1403 server. The DHCP Client-Server Authentication Extension [11] is 1404 intended to be used in these circumstances. 1406 10. Acknowledgements 1408 Thanks to the DHC Working Group for their time and input into the 1409 specification. Ralph Droms and Thomas Narten have had a major role 1410 in shaping the continued improvement of the protocol by their careful 1411 reviews. Thanks also for the consistent input, ideas, and review by 1412 (in alphabetical order) Brian Carpenter, Jack McCann, Yakov Rekhter, 1413 Matt Thomas, Sue Thomson, and Phil Wells. 1415 Thanks to Steve Deering and Bob Hinden, who have consistently 1416 taken the time to discuss the more complex parts of the IPv6 1417 specifications. Thanks to Stuart Cheshire for his excellent minutes. 1419 A. Related Work in IPv6 1421 The related work in IPv6 that would best serve an implementor 1422 to study is the IPv6 Specification [6], the IPv6 Addressing 1423 Architecture [8], IPv6 Stateless Address Autoconfiguration [15], IPv6 1424 Neighbor Discovery Processing [10], and Dynamic Updates to DNS [16]. 1425 These specifications enable DHCP to build upon the IPv6 work to 1426 provide both robust stateful autoconfiguration and autoregistration 1427 of DNS Host Names. 1429 The IPv6 Specification provides the base architecture and design of 1430 IPv6. A key point for DHCP implementors to understand is that IPv6 1431 requires that every link in the internet have an MTU of 576 octets 1432 or greater (in IPv4 the requirement is 68 octets). This means that 1433 a UDP datagram of 536 octets will always pass through an internet 1434 (less 40 octets for the IPv6 header), as long as there are no IP 1435 options prior to the UDP header in the datagram. But, IPv6 does 1436 not support fragmentation at routers, so that fragmentation takes 1437 place end-to-end between hosts. If a DHCP implementation needs 1438 to send a datagram greater than 536 octets it can either fragment 1439 the UDP datagram in UDP or use Path MTU Discovery [9] to determine 1440 the size of the datagram that will traverse a network path. It is 1441 implementation dependent how this is accomplished in DHCP. 1443 The IPv6 Addressing Architecture specification [8] defines the 1444 address scope that can be used in an IPv6 implementation, and the 1445 various configuration architecture guidelines for network designers 1446 of the IPv6 address space. Two advantages of IPv6 are that multicast 1447 addressing is required, and nodes can create link-local addresses 1448 during initialization of the nodes environment. This means that a 1449 client immediately can configure an IP address at initialization 1450 for an interface, before communicating in any manner on the link. 1451 The client can then use a well-known multicast address to begin 1452 communications to discover neighbors on the link, or to send a DHCP 1453 Solicit and locate a DHCP server or relay. 1455 IPv6 Stateless Address Autoconfiguration [15] (addrconf) specifies 1456 procedures by which a node may autoconfigure addresses based on 1457 router advertisements [10], and the use of a validation lifetime to 1458 support renumbering of addresses on the Internet. In addition the 1459 protocol interaction by which a node begins stateless or stateful 1460 autoconfiguration is specified. DHCP is one vehicle to perform 1461 stateful autoconfiguration. Compatibility with addrconf is a design 1462 requirement of DHCP (see Section 3.1). 1464 IPv6 Neighbor Discovery [10] is the node discovery protocol in IPv6 1465 (replaces and enhances functions of ARP [12]). To truly understand 1466 IPv6 and addrconf it is strongly recommended that implementors 1467 understand IPv6 Neighbor Discovery. 1469 Dynamic Updates to DNS [16] is a specification that supports the 1470 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 1471 the dynamic updates to DNS to now integrate addresses and name space 1472 to not only support autoconfiguration, but also autoregistration in 1473 IPv6. The security model to be used with DHCPv6 should conform as 1474 closely as possible to that outlined in RFC 1825 [2]. 1476 B. Comparison between DHCPv4 and DHCPv6 1478 This appendix is provided for readers who will find it useful to see 1479 a model and architecture comparison between DHCPv4 [7, 1] and DHCPv6. 1480 There are three key reasons for the differences: 1482 o IPv6 inherently supports a new model and architecture for 1483 communications and autoconfiguration of addresses. 1485 o DHCPv6 in its design was able to take advantage of the inherent 1486 benefits of IPv6. 1488 o New features were added to support the evolution and the 1489 existence of mature Internet users in the industry. 1491 IPv6 Architecture/Model Changes: 1493 o The link-local address permits a node to have an address 1494 immediately when the node boots, which means all clients have a 1495 source IP address at all times to locate a server or relay agent 1496 on the local link. 1498 o The need for bootp compatibility and broadcast flags are removed, 1499 which permitted a great deal of freedom in designing the new 1500 packet formats for the client and server interaction. 1502 o Multicast and the scoping methods in IPv6 permitted the design of 1503 discovery packets that would inherently define their range by the 1504 multicast address for the function required. 1506 o Stateful autoconfiguration has to coexist and integrate with 1507 stateless autoconfiguration supporting Duplicate Address 1508 Detection and the two IPv6 lifetimes, to facilitate the dynamic 1509 renumbering of addresses and the management of those addresses. 1511 o Multiple addresses per interface are inherently supported in 1512 IPv6. 1514 o Most DHCPv4 options are unnecessary now because the configuration 1515 parameters are either obtained through IPv6 Neighbor Discovery or 1516 the Service Location protocol. 1518 DHCPv6 Architecture/Model Changes: 1520 o The message type is the first byte in the packet. 1522 o IPv6 Address allocations are now handled in a message extension 1523 as opposed to the main header. 1525 o Client/Server bindings are now mandatory and take advantage of 1526 the client's link-local address to always permit communications 1527 either directly from an on-link server, or from a remote server 1528 through an on-link relay-agent. 1530 o Servers are now discovered by a client solicit and server or 1531 relay-agent advertisement model. 1533 o The client will know if the server is on-link or off-link. 1535 o The client after a solicit will be returned the addresses of 1536 available servers either from an on-link server or from an 1537 on-link relay-agent as agents providing the advertisements. 1539 o The on-link relay-agent will obtain the location of remote server 1540 addresses from system configuration or by the use of a site wide 1541 DHCPv6 Multicast packet. 1543 o The protocol is optimized and removes the use of ACKs and NAKs 1544 once the client and server set-up is complete. 1546 o The server assumes the client receives its responses unless it 1547 receives a retransmission of the same client request. This 1548 permits recovery in the case where the network has faulted. 1550 o DHCPINFORM is inherent in the new packet design; a client can 1551 request configuration parameters other than IPv6 addresses in the 1552 optional extension headers. 1554 o Clients MUST listen to their UDP port for the new Reconfigure 1555 message type from servers, unless they join the appropriate 1556 multicast group as specified by the DHCP server. 1558 o Dynamic Updates to DNS are supported in the IPv6 Address 1559 extension. 1561 o New extensions have been defined. 1563 New Internet User Features: 1565 o Configuration of Dynamic Updates to DNS to support multiple 1566 implementation policy requirements. 1568 o Configuration of what policy is enforced when addresses are 1569 deprecated for dynamic renumbering can be implemented. 1571 o Configuration of how relay-agents locate remote servers for a 1572 link can be implemented. 1574 o An Authentication extension has been added. 1576 o Configuration of additional addresses for server applications can 1577 be requested by a client in an implementation. 1579 o Reclaiming addresses allocated with very long lifetimes can be 1580 implemented using the Reconfigure message type. 1582 o Configuration of tightly coupled integration between stateless 1583 and stateful address autoconfiguration can be implemented. 1585 References 1587 [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 1588 Extensions. RFC 2132, March 1997. 1590 [2] R. Atkinson. Security Architecture for the Internet Protocol. 1591 RFC 1825, August 1995. 1593 [3] S. Bradner. Key words for use in RFCs to Indicate Requirement 1594 Levels. RFC 2119, March 1997. 1596 [4] S. Bradner and A. Mankin. The Recommendation for the IP Next 1597 Generation Protocol. RFC 1752, January 1995. 1599 [5] A. Conta and S. Deering. Internet Control Message Protocol 1600 (ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885, 1601 December 1995. 1603 [6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1604 Specification. RFC 1883, December 1995. 1606 [7] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March 1607 1997. 1609 [8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 1610 RFC 1884, December 1995. 1612 [9] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP 1613 version 6. RFC 1981, August 1996. 1615 [10] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 1616 IP version 6 (IPv6). RFC 1970, August 1996. 1618 [11] C. Perkins. Extensions to DHCPv6. 1619 draft-ietf-dhc-dhcpv6ext-06.txt (work in progress), May 1997. 1621 [12] David C. Plummer. An Ethernet Address Resolution Protocol: 1622 Or Converting Network Protocol Addresses to 48.bit Ethernet 1623 Addresses for Transmission on Ethernet Hardware. RFC 826, 1624 November 1982. 1626 [13] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 1628 [14] J. B. Postel, Editor. Internet Protocol. RFC 791, September 1629 1981. 1631 [15] S. Thomson and T. Narten. IPv6 stateless address 1632 autoconfiguration. RFC 1971, August 1996. 1634 [16] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates 1635 in the Domain Name System (DNS). RFC 2136, April 1997. 1637 Chair's Address 1639 The working group can be contacted via the current chair: 1641 Ralph Droms 1642 Computer Science Department 1643 323 Dana Engineering 1644 Bucknell University 1645 Lewisburg, PA 17837 1647 Phone: (717) 524-1145 1648 E-mail: droms@bucknell.edu 1650 Author's Address 1652 Questions about this memo can be directed to: 1654 Jim Bound Charles Perkins 1655 Digital Equipment Corporation Netcentricity Group 1656 110 Spitbrook Road, ZKO3-3/U14 Sun Microsystems, Inc. 1657 Nashua, NH 03062 2550 Garcia Avenue. 1658 Mountain View, CA 94043 1659 Phone: +1-603-881-0400 +1-415-336-7153 1660 Fax: +1-415-336-0673 1661 E-mail: bound@zk3.dec.com charles.perkins@corp.sun.com