idnits 2.17.1 draft-ietf-dhc-dhcpv6-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 5 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes draft-ietf-dhc-dhcpv6-12.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- No information found for rfcdraft-ietf-dhc-dhcpv6-12.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 (28 June 1998) is 9432 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) ** Obsolete normative reference: RFC 1981 (ref. '10') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 1970 (ref. '11') (Obsoleted by RFC 2461) == Outdated reference: A later version (-05) exists of draft-iesg-iana-considerations-04 -- No information found for draft-ietf-dhc-dhcpv6ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '13' ** Obsolete normative reference: RFC 1971 (ref. '17') (Obsoleted by RFC 2462) == Outdated reference: A later version (-01) exists of draft-ietf-ipngwg-addrconf-v2-00 Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force J. Bound 2 INTERNET DRAFT Compaq Computer Corp. 3 DHC Working Group C. Perkins 4 Obsoletes: draft-ietf-dhc-dhcpv6-12.txt Sun Microsystems 5 28 June 1998 7 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 8 draft-ietf-dhc-dhcpv6-13.txt 10 Status of This Memo 12 This document is a submission by the Dynamic Host Configuration 13 Working Group of the Internet Engineering Task Force (IETF). 14 Comments should be submitted to the dhcp-v6@bucknell.edu mailing 15 list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 To view the entire list of current Internet-Drafts, please check 30 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 31 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 32 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 33 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 35 Abstract 37 The Dynamic Host Configuration Protocol (DHCPv6) enables DHCP 38 servers to pass configuration information, via extensions, to IPv6 39 nodes. It offers the capability of automatic allocation of reusable 40 network addresses and additional configuration flexibility. This 41 protocol is a stateful counterpart to the IPv6 Stateless Address 42 Autoconfiguration protocol, and can be used separately or together 43 with the latter to obtain configuration information. 45 Contents 47 Status of This Memo i 49 Abstract i 51 1. Introduction 1 53 2. Terminology and Definitions 2 54 2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2 55 2.2. DHCPv6 Terminology . . . . . . . . . . . . . . . . . . . 3 56 2.3. Specification Language . . . . . . . . . . . . . . . . . 4 57 2.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Protocol Design Model 4 60 3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. DHCP Messages . . . . . . . . . . . . . . . . . . . . . . 5 62 3.3. Request/Response Processing Model . . . . . . . . . . . . 6 64 4. DHCP Message Formats and Field Definitions 7 65 4.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 8 66 4.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 9 67 4.3. DHCP Request Message Format . . . . . . . . . . . . . . . 10 68 4.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12 69 4.5. DHCP Release Message Format . . . . . . . . . . . . . . . 13 70 4.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 14 72 5. DHCP Client Considerations 15 73 5.1. Verifying Resource Allocations After Restarts . . . . . . 15 74 5.2. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 16 75 5.3. Receiving DHCP Advertise Messages . . . . . . . . . . . . 16 76 5.4. Sending DHCP Request Messages . . . . . . . . . . . . . . 17 77 5.5. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 19 78 5.6. Sending DHCP Release Messages . . . . . . . . . . . . . . 19 79 5.7. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 20 80 5.8. Interaction with Stateless Address Autoconfiguration . . 21 82 6. DHCP Server Considerations 21 83 6.1. Receiving DHCP Solicit Messages . . . . . . . . . . . . . 22 84 6.2. Sending DHCP Advertise Messages . . . . . . . . . . . . . 22 85 6.3. DHCP Request and Reply Message Processing . . . . . . . . 23 86 6.3.1. Processing for Extensions to DHCP Request and Reply 87 Messages . . . . . . . . . . . . . . . . . 24 88 6.3.2. Client Requests to Deallocate Unknown Resources . 24 89 6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 25 90 6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . . 26 91 6.6. Client-Resource timeouts . . . . . . . . . . . . . . . . 26 93 7. DHCP Relay Considerations 26 94 7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 27 95 7.2. DHCP Request Message Processing . . . . . . . . . . . . . 27 96 7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 28 98 8. Retransmission and Configuration Variables 28 100 9. Security Considerations 31 102 10. Year 2000 considerations 32 104 11. IANA Considerations 32 106 12. Acknowledgements 32 108 A. Changes for this revision 33 110 B. Related Protocol Specifications 33 112 C. Comparison between DHCPv4 and DHCPv6 34 114 D. Full Copyright Statement 37 116 Chair's Address 40 118 Author's Address 40 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 125 extensions for allocation of network addresses and other related 126 parameters to IPv6 [6] nodes. 128 DHCP uses a client-server model, where designated DHCP servers 129 automatically allocate network addresses and 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 DHCPv6 uses Request and Reply messages to support a client/server 137 processing model whereby both client and server are assured that 138 requested configuration parameters have been received and accepted 139 by the client. DHCP supports optional configuration parameters and 140 processing for nodes through extensions described in its companion 141 document ``Extensions for the Dynamic Host Configuration Protocol for 142 IPv6'' [13]. 144 The IPv6 Addressing Architecture [8] and IPv6 Stateless Address 145 Autoconfiguration [17] specifications provide new features not 146 available in IP version 4 (IPv4) [16], which are used to simplify 147 and generalize the operation of DHCP clients. This document is 148 intended to complement those specifications for clients attached to 149 the kinds of Internet media for which those specifications apply. In 150 particular, the specification in this document does not necessarily 151 apply to nodes which do not enjoy a bidirectional link to the 152 Internet. 154 Section 2 provides definitions for terminology used throughout 155 this document. Section 3 provides an overview of the protocol 156 design model that guided the design choices in the specification; 157 section 3.2 briefly describes the protocol messages and their 158 semantics. Section 4 provides the message formats and field 159 definitions used for each message. Sections 5, 6, and 7 specify 160 how clients, servers, and relays respectively interact. The timeout 161 and retransmission guidelines as well as configuration variables for 162 DHCP protocol operations are discussed in Section 8. Appendix B 163 summarizes related work in IPv6 that will provide helpful context; 164 it is not part of this specification, but included for informational 165 purposes. Appendix C discusses the differences between DHCPv4 and 166 DHCPv6. 168 2. Terminology and Definitions 170 Relevant terminology from the IPv6 Protocol [6], IPv6 Addressing 171 Architecture [8], and IPv6 Stateless Address Autoconfiguration [17] 172 is given, followed by DHCPv6 terminology. 174 2.1. IPv6 Terminology 176 address An IP layer identifier for an interface or a set of 177 interfaces. 179 unicast address 180 An identifier for a single interface. A packet sent 181 to a unicast address is delivered to the interface 182 identified by that address. 184 multicast address 185 An identifier for a set of interfaces (typically 186 belonging to different nodes). A packet sent to a 187 multicast address is delivered to all interfaces 188 identified by that address. 190 host Any node that is not a router. 192 IP Internet Protocol Version 6 (IPv6). The terms IPv4 and 193 IPv6 are used only in contexts where it is necessary to 194 avoid ambiguity. 196 interface 197 A node's attachment to a link. 199 link A communication facility or medium over which nodes 200 can communicate at the link layer, i.e., the layer 201 immediately below IP. Examples are Ethernet (simple or 202 bridged); Token Ring; PPP links, X.25, Frame Relay, or 203 ATM networks; and internet (or higher) layer "tunnels", 204 such as tunnels over IPv4 or IPv6 itself. 206 link-layer identifier 207 a link-layer identifier for an interface. Examples 208 include IEEE 802 addresses for Ethernet or Token Ring 209 network interfaces, and E.164 addresses for ISDN links. 211 link-local address 212 An IP address having link-only scope, indicated by 213 having the routing prefix (FE80::0000/64), that can be 214 used to reach neighboring nodes attached to the same 215 link. Every interface has a link-local address. 217 message A unit of data carried in a packet, exchanged between 218 DHCP agents and clients. 220 neighbor A node attached to the same link. 222 node A device that implements IP. 224 packet An IP header plus payload. 226 prefix A bit string that consists of some number of initial 227 bits of an address. 229 router A node that forwards IP packets not explicitly 230 addressed to itself. 232 2.2. DHCPv6 Terminology 234 Agent Address 235 The address of a neighboring DHCP Agent on the same 236 link as the DHCP client. 238 binding A binding (or, client binding) containing the data 239 which a DHCP server maintains for each of its clients 240 (see Section 6). 242 resource-server association 243 An association between a resource and a DHCP server, 244 maintained by the client which received that resource 245 from that DHCP server. 247 configuration parameter 248 Any parameter that can be used by a node to configure 249 its network subsystem and enable communication on a 250 link or internetwork. 252 DHCP agent (or agent) 253 Either a DHCP server or a DHCP relay. 255 DHCP client (or client) 256 A node that initiates requests on a link to obtain 257 configuration parameters. 259 DHCP relay (or relay) 260 A node that acts as an intermediary to deliver DHCP 261 messages between clients and servers. 263 DHCP server (or server) 264 A server is a node that responds to requests from 265 clients 267 transaction-ID 268 A monotonically increasing unsigned integer used to 269 match a response to a pending message. 271 2.3. Specification Language 273 In this document, the words MUST, MUST NOT, SHOULD, SHOULD NOT, and 274 MAY are used to signify the requirements of the specification, in 275 accordance with RFC 2119 [2]. 277 2.4. Error Values 279 This specification document uses symbolic names for the errors known 280 to DHCP clients and servers, as used for instance in the status field 281 of the DHCP Reply message (see section 4.4). The symbolic names have 282 the actual values listed below: 284 Error Name ErrorID 285 ================================ 286 PoorlyFormed 18 287 Unavail 19 288 NoBinding 20 289 InvalidSource 21 290 NoServer 23 291 ICMPError 64 293 3. Protocol Design Model 295 This section is provided for implementors to understand the DHCPv6 296 protocol design model from an architectural perspective. Goals and 297 conceptual models are presented in this section. 299 3.1. Design Goals 301 The following list gives general design goals for this DHCP 302 specification. 304 - DHCP should be a mechanism rather than a policy. DHCP MUST allow 305 local system administrators control over configuration parameters 306 where desired; e.g., local system administrators should be able 307 to enforce local policies concerning allocation and access to 308 local resources where desired. 310 - DHCP MUST NOT require manual configuration of DHCP clients, 311 except as dictated by security requirements. Each node should be 312 able to obtain appropriate local configuration parameters without 313 user intervention. 315 - DHCP MUST NOT require a server on each link. To allow for scale 316 and economy, DHCP MUST work across DHCP relays. 318 - In some installations, clients on certain subnets can be served 319 by more than one DHCP server, improving reliability and/or 320 performance. Therefore, a DHCP client MUST be prepared to 321 receive multiple (possibly different) responses to a DHCP Solicit 322 message. 324 - DHCP MUST coexist with statically configured, non-participating 325 nodes and with existing network protocol implementations. 327 - DHCPv6 MUST be compatible with IPv6 Stateless Address 328 Autoconfiguration [17]. 330 - A DHCPv6 Client implementation MAY be started in the absence of 331 any IPv6 routers on the client's link. 333 - DHCP architecture MUST support automated renumbering of IP 334 addresses [3]. 336 - DHCP servers SHOULD be able to support Dynamic Updates to 337 DNS [20]. 339 - DHCP servers MUST be able to support multiple IPv6 addresses for 340 each client. 342 On the other hand, a DHCP server to server protocol is NOT part of 343 this specification. Furthermore, it is NOT a design goal of DHCP to 344 specify how a server configuration parameter database is maintained 345 or determined. Methods for configuring DHCP servers are outside the 346 scope of this document. 348 3.2. DHCP Messages 350 Each DHCP message contains a type, which defines its function within 351 the protocol. Formats for the messages are found in section 4. 352 Processing details for these DHCP messages are specified in 353 Sections 5, 6, and 7. The message types are as follows: 355 01 DHCP Solicit 357 The DHCP Solicit message is an IP multicast message sent by a 358 client to one or more agents, or forwarded by a relay to one or 359 more servers. 361 02 DHCP Advertise 363 The DHCP Advertise is an IP unicast message sent by a DHCP 364 Agent in response to a client's DHCP Solicit message. 366 03 DHCP Request 368 The DHCP Request is an IP unicast message sent by a client to a 369 server to request configuration parameters on a network. 371 04 DHCP Reply 373 The DHCP Reply is an IP unicast message sent by a server in 374 response to a client's DHCP Request, or by the relay that 375 relayed that client's DHCP Request. Extensions [13] to the 376 DHCP Reply describe the resources that the server has committed 377 and allocated to this client, and may contain other information 378 for use by this client. 380 05 DHCP Release 382 The DHCP Release is an IP unicast message sent by a client to 383 inform the server that the client is releasing resources. 385 06 DHCP Reconfigure 387 The DHCP Reconfigure is an IP unicast or multicast message sent 388 by a server to inform one or more clients that the server has 389 new configuration information of importance to the client. 390 Each client is expected to initiate a new Request/Reply 391 transaction. 393 DHCP message types not defined here (msg-types 0 and 7-255) are 394 reserved and SHOULD be silently ignored. 396 3.3. Request/Response Processing Model 398 The request/response processing for DHCPv6 is transaction based and 399 uses a set of best-effort messages to complete the transaction. 401 To find a server, a client sends a DHCP Solicit from the interface 402 which it wishes to configure. The client then awaits a DHCP 403 Advertise message containing an IP address of a DHCP server. 404 Transactions are started by a client with a DHCP Request, which may 405 be issued after the client knows the server's address. The server 406 then unicasts a DHCP Reply, possibly via a relay. At this point in 407 the flow all data has been transmitted and is presumed to have been 408 received. To provide a method of recovery if either the client or 409 server does not receive its messages, the client retransmits each 410 DHCP Request message until it elicits the corresponding DHCP Reply, 411 or until it can be reasonably certain that the desired DHCP server 412 is unavailable, or it determines that it does not want a response 413 (i.e., it MAY abort the transaction). The timeout and retransmission 414 guidelines and configuration variables are discussed in Section 8. 416 DHCP uses UDP [15] to communicate between clients and servers. UDP 417 is not reliable, but the DHCP retransmission scheme just described 418 provides reliability between clients and servers. The following 419 well-known multicast addresses are used by DHCP agents and clients: 421 FF02:0:0:0:0:0:1:2 422 All DHCP Agents (servers and relays) MUST join the 423 link-local All-DHCP-Agents multicast group at the address 424 FF02:0:0:0:0:0:1:2. 426 FF05:0:0:0:0:0:1:3 427 All DHCP servers MUST join the site-local 428 All-DHCP-Servers multicast group at the address 429 FF05:0:0:0:0:0:1:3. 431 FF05:0:0:0:0:0:1:4 432 All DHCP relays MUST join the site-local All-DHCP-Relays 433 multicast group at the address FF05:0:0:0:0:0:1:4. 435 A DHCP server or agent MUST transmit all messages to DHCP clients on 436 UDP port 546. A DHCP client MUST transmit all messages to a DHCP 437 agent over UDP using port 547. A DHCP server MUST transmit all 438 messages to DHCP relays over UDP on port 546. The source port for 439 DHCP messages is arbitrary. 441 For the proper operation of the DHCP protocol to operate within a 442 network where one or more firewalls [4] are used, DHCP transactions 443 sent to the IP addresses of DHCP servers at UDP destination ports 546 444 and 547 will need to be permitted. 446 4. DHCP Message Formats and Field Definitions 448 All reserved fields in a message MUST be transmitted as zeroes and 449 ignored by the receiver of the message. 451 4.1. DHCP Solicit Message Format 453 A client transmits a DHCP Solicit message over the interface to be 454 configured, to obtain one or more server addresses. 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | msg-type |C| reserved | prefix-size | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | client's link-local address | 462 | (16 octets) | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | relay-address | 465 | (16 octets) | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 msg-type 1 470 C If set, the client requests that all servers receiving 471 the message deallocate the resources associated with 472 the client. 474 prefix-size A nonzero prefix-size is the number of leftmost bits 475 of the agent's IPv6 address which make up the routing 476 prefix. 478 reserved 0 480 client's link-local address 481 The IP link-local address of the client interface from 482 which the client issued the DHCP Request message 484 relay-address 485 If nonzero, the IP address of the interface on which 486 the relay received the client's DHCP Solicit message 488 A client SHOULD send a DHCP Solicit message to the All-DHCP-Agents 489 multicast group (see section 3.3), setting the relay-address to 490 zero. Any relay receiving the solicitation MUST forward it to the 491 All-DHCP-Servers multicast group. In that case, the relay MUST copy 492 a non-link-local address of its interface from which the client's 493 solicitation was received into the relay-address field. Servers 494 receiving the solicitation then send their advertisements to the 495 prospective client. 497 4.2. DHCP Advertise Message Format 499 A DHCP agent sends a DHCP Advertise message to inform a prospective 500 client about the IP address of a server to which a DHCP Request 501 message may be sent. When the client and server are on different 502 links, the server sends the advertisement back through the relay 503 whence the solicitation came. 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | msg-type |S| reserved | preference | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | client's link-local address | 511 | (16 octets) | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | agent-address | 514 | (16 octets) | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | server-address | 517 | (16 octets, if present) | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | extensions (variable number and length) ... 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 msg-type 2 524 S If set, the server-address is present. 526 reserved 0 528 preference An octet (unsigned) indicating a server's willingness 529 to provide service to the client (see Section 5.3). 531 client's link-local address 532 The IP link-local address of the client interface 533 from which the client issued the DHCP Request message 535 agent-address 536 The IP address of a DHCP Agent interface on the same 537 link as the client. 539 server-address 540 If present, the IP address of the DHCP server 542 extensions See [13]. 544 Suppose that a server on the same link as a client issues the 545 DHCP Advertise in response to a DHCP Solicit message sent to the 546 All-DHCP-Agents multicast address. Then the agent-address will be an 547 IP address of one of the server's interfaces on the same link as the 548 client, and the `S' bit will be set to zero, indicating the absence 549 of the server-address in the DHCP Advertise message. See section 5.3 550 for information about how clients handle the preference field. 552 The server MUST copy the client's link-local address into the 553 advertisement which is sent in response to a DHCP Solicit. Both 554 server-address (if present) and agent-address of the DHCP Advertise 555 message MUST have sufficient scope to be reachable by the client. 556 Moreover, the agent-address of any DHCP Advertise message sent by a 557 relay MUST NOT be a link-local address. In situations where there 558 are no routers sending Router Advertisements, then a DHCP server MUST 559 be configured on the same link as prospective clients. The DHCPv6 560 protocol design does not apply to situations where the client is 561 unable to route messages to a server not on the same link. 563 4.3. DHCP Request Message Format 565 In order to request configuration parameters from a server, a client 566 sends a DHCP Request message, and MAY append extensions [13]. If 567 the client does not know any server address, it MUST first obtain 568 one by multicasting a DHCP Solicit message (see Section 4.1). 569 Typically, when a client reboots, it does not have a valid IP address 570 of sufficient scope for the server to communicate with the client. 571 In such cases, the client MUST NOT send the message directly to 572 the server because the server could not return any response to the 573 client; the client MUST send the message to the local relay and 574 insert the relay-address as the agent-address in the message header. 576 Otherwise, the client MAY omit the server-address in the DHCP Request 577 message; in this case, the client MUST clear the S-bit and send the 578 message directly to the server, using the server's address as the IP 579 destination address in the IP header. 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | msg-type |C|S|R| rsvd | transaction-ID | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | client's link-local address | 587 | (16 octets) | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | agent-address | 590 | (16 octets) | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | server-address | 593 | (16 octets, if present) | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | extensions (variable number and length) .... 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 msg-type 3 600 C If set, the client requests the server to remove all 601 resources associated with the client binding, except 602 those resources provided as extensions. 604 S If set, the server-address is present 606 R If set, the client has rebooted and requests that all 607 of its previous transaction-IDs be expunged and made 608 available for re-use. 610 rsvd 0 612 transaction-ID 613 A monotonically increasing unsigned integer used to 614 identify this Request, and copied into the Reply. 616 client's link-local address 617 The IP link-local address of the client interface from 618 which the client issued the DHCP Request message 620 agent-address 621 The IP address of an agent's interface, copied from a 622 DHCP Advertisement message. 624 server-address 625 If present, the IP address of the server which should 626 receive the client's DHCP Request message. 628 extensions See [13]. 630 When the client sets the `C' bit and adds extensions, the server 631 is expected to deallocate all other resources not listed in the 632 extension. The resources explicitly requested in extensions to the 633 Request message SHOULD be reallocated by the server to the client, 634 assuming the client is still authorized to receive them. 636 4.4. DHCP Reply Message Format 638 The server sends one DHCP Reply message in response to every DHCP 639 Request or DHCP Release received. If the request comes with the `S' 640 bit set, the client could not directly send the Request to the server 641 and had to use a neighboring relay agent. In that case, the server 642 sends back the DHCP Reply with the `L' bit set, and the DHCP Reply is 643 addressed to the agent-address found in the DHCP Request message. If 644 the `L' bit is set, then the client's link-local address will also be 645 present. 647 0 1 2 3 648 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 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | msg-type |L| status | transaction-ID | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | client's link-local address | 653 | (16 octets, if present) | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | extensions (variable number and length) .... 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 msg-type 4 660 L If set, the client's link-local address is present 662 status One of the following decimal values: 664 0 Success 665 16 Failure, reason unspecified 666 17 Authentication failed or nonexistent 667 18 Poorly formed Request or Release 668 19 Resources unavailable 669 20 Client record unavailable 670 21 Invalid client IP address in Release 671 23 Relay cannot find Server Address 672 64 Server unreachable (ICMP error) 674 transaction-ID 675 A monotonically increasing unsigned integer used to 676 identify this Reply, and copied from the client's 677 Request. 679 client's link-local address 680 If present, the IP address of the client interface 681 which issued the corresponding DHCP Request message. 683 extensions 684 See [13]. 686 If the `L' bit is set, and thus the link-local address is present in 687 the Reply message, the Reply is sent by the server to the relay's 688 address which was specified as the agent-address in the DHCP Request 689 message, and the relay uses the link-local address to deliver the 690 Reply message to the client. 692 4.5. DHCP Release Message Format 694 The DHCP Release message is sent without the assistance of any DHCP 695 relay. When a client sends a Release message, it is assumed to have 696 a valid IP address with sufficient scope to allow access to the 697 target server. If parameters are specified in the extensions, only 698 those parameters are released. The DHCP server acknowledges the 699 Release message by sending a DHCP Reply (Sections 4.4, 6.3). 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | msg-type |D| reserved | transaction-ID | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | client's link-local address | 707 | (16 octets) | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | agent-address | 710 | (16 octets) | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | client-address | 713 | (16 octets, if present) | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | extensions (variable number and length) .... 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 msg-type 5 720 D If the `D' flag is set, the client instructs the server 721 to send the DHCP Reply directly back to the client, 722 instead of using the given agent-address and link-local 723 address to relay the Reply message. 725 reserved 0 726 transaction-ID 727 A monotonically increasing unsigned integer used to 728 identify this Release, and copied into the Reply. 730 client's link-local address 731 The IP link-local address of the client interface from 732 which the the client issued the DHCP Release message 734 agent-address 735 The IP address of the agent interface to which the 736 client issued a previous DHCP Request message 738 client-address 739 The IP address of the client interface from which 740 the the client issued the DHCP Release message. The 741 client-address field is present whenever the `D' bit is 742 set, even if it is equal to the link-local address. 744 extensions See [13] 746 It is an error (status code ``InvalidSource'' (see Section 2.4)) to 747 include within the DHCP Release message both the `D' bit and an IP 748 address extension which has the IP address used as the client-address 749 field of the DHCP Release message header. 751 4.6. DHCP Reconfigure Message Format 753 DHCP Reconfigure messages can only be sent to clients which have 754 established an IP address which routes to the link at which they are 755 reachable, hence the DHCP Reconfigure message is sent without the 756 assistance of any DHCP relay. When a server sends a Reconfigure 757 message, the receivers are assumed to have a valid IP address with 758 sufficient scope to be accessible by the server. Only the parameters 759 which are specified in the extensions to the Reconfigure message need 760 be requested again by the client. A Reconfigure message can either 761 be unicast or multicast by the server. 763 0 1 2 3 764 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | msg-type |N| reserved | transaction-ID | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | server-address | 769 | (16 octets) | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | extensions (variable number and length) .... 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 msg-type 6 775 N The `N' flag indicates that the client should not 776 expect a DHCP Reply in response to the DHCP Request 777 it sends as a result of the DHCP Reconfigure message. 779 reserved 0 781 transaction-ID 782 A monotonically increasing unsigned integer used to 783 identify this Reconfigure message, and copied into 784 the client's Request. 786 server-address 787 The IP address of the DHCP server issuing the DHCP 788 Reconfigure message. 790 extensions See [13] 792 5. DHCP Client Considerations 794 A node which is not a DHCP agent MUST silently discard any DHCP 795 Solicit, DHCP Request, or DHCP Release message it receives. 797 5.1. Verifying Resource Allocations After Restarts 799 A client MAY retain its configured parameters and resources across 800 client system reboots and program restarts. However, in these 801 circumstances the client MUST also formulate a DHCP Request message 802 to verify that its configured parameters and resources are still 803 valid. This Request message MUST have the `C' bit set, to clean up 804 stale client binding information at the server which may no longer be 805 in use by the client; stale information is that which the client does 806 not include in extensions to such request messages. 808 If the server does not respond to the DHCP Request message after 809 REQUEST_MSG_MIN_RETRANS (see section 8), the client may still 810 use any resources whose lifetimes have not yet expired. In such 811 cases, however, the client MUST begin to search for another server 812 by multicasting a DHCP Solicit message with the `C' bit set (see 813 section 5.2). The client SHOULD log a DHCP System Error. 815 This also handles the case wherein a client restarts on a new 816 network, where its IP address is no longer valid. In this situation, 817 when the client receives a new IP address and the old IP address 818 is no longer needed, the client MUST release its old IP address by 819 issuing a DHCP Release message with the appropriate extension if it 820 can communicate with its previous server. 822 5.2. Sending DHCP Solicit Messages 824 A client MUST have the address of a server to send a Request message. 825 The client SHOULD locate a DHCP server by multicasting a DHCP Solicit 826 message to the All-DHCP-Agents link-local multicast address (see 827 Section 3.3), setting the Hop Limit == 1. If there are no DHCP 828 servers on the same link as the node, then a DHCP relay MUST be 829 present if solicitations sent from a client's link-local address are 830 to be handled. 832 When sending a DHCP Solicit message, a client MUST set the Relay 833 Address field to 16 octets of zeros, and zero the prefix-size field. 835 If a client reboots and does not have a valid IP address, it MUST set 836 the `C' bit in the DHCP Solicit message it sends when restarting. By 837 setting the `C' bit in the solicitation, a client requests that all 838 the DHCP servers that receive the solicitation should clean up their 839 client records that match its link-local address. 841 If a client sends a DHCP Solicit message after it reboots, the 842 solicitation SHOULD be delayed after reception of the first Router 843 Advertisement [11] message, by at least some random amount of time 844 between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY (see section 8). 845 This delay is intended to help stagger requests to DHCP servers (and 846 avoid link-layer collisions) after a power outage causes many nodes 847 to reboot all at once. Each subsequent DHCP Solicit message that is 848 issued before receiving an advertisement MUST be delayed by twice the 849 amount by which the previous DHCP Solicit message was delayed, plus 850 a small random delay between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY 851 seconds. 853 5.3. Receiving DHCP Advertise Messages 855 After a client has received a DHCP Advertise message, it has the 856 address of a server for subsequent DHCP Request messages. If the `S' 857 bit is zero, the DHCP Advertise message was transmitted by a server 858 on the same link as the client, and the client uses the agent-address 859 as the server's address; otherwise, the server's IP address is 860 located in the server-address field. If the server-address is a 861 multicast address, the advertisement MUST be silently discarded. 863 A server MAY append extensions to its advertisements; this might 864 allow the client to select the configuration that best meets its 865 needs from among several prospective servers. 867 Unless a DHCP Advertisement is received with a preference equal 868 to 255 (see Section 4.2), the client MUST wait CLIENT_ADV_WAIT 869 seconds after issuing the DHCP Solicit message in order to receive 870 the Advertisement with the highest preference. After waiting for 871 that period of time, a client MUST select the highest preference 872 server as the target of its DHCP request. If a client receives an 873 advertisement with a preference of 255, it does not have to wait for 874 any more advertisements. 876 If a client sends a DHCP Request to a highly preferred server but 877 fails to receive a DHCP reply from that server after following the 878 retransmission algorithm in section 8, the client SHOULD then try to 879 send a DHCP Request to a less preferred server. 881 A client is free to cache the result of any DHCP Advertisement it 882 hears. This is purely a potential performance enhancement, because 883 the results might change over time. A client may not get a DHCP 884 Reply if it uses a cached server-address, and in that case SHOULD 885 multicast another DHCP Solicit message. 887 5.4. Sending DHCP Request Messages 889 A client obtains configuration information from a server by sending 890 a DHCP Request message. The client MUST know the server's address 891 before sending the Request message, and the client MUST have acquired 892 a (possibly identical) DHCP agent address. If the client and server 893 are on the same link, the agent-address used by the client MUST be 894 the same as the DHCP server's address. A DHCP Request message MUST 895 NOT be sent to any multicast address, since otherwise multiple DHCP 896 agents would possibly allocate resources to the client in response 897 to the same Request, and the client would have no way to know which 898 servers had made the allocations, if any packets were lost due to 899 collisions, etc. 901 If the DHCP server is off-link, and the client has no valid IP 902 address of sufficient scope, then the client MUST include the 903 server-address and set the `S' bit in the DHCP Request message. In 904 this case, the IP destination address in the IP header will be a DHCP 905 relay address. 907 Otherwise, if the client has a valid IP address of sufficient scope 908 and knows the IP address of a candidate server, it MUST send the 909 Request message directly to the server without requiring the services 910 of the local DHCP relay. 912 If a client wishes to instruct a server to deallocate all unknown 913 previous resources, configuration information, and bindings 914 associated with its agent-address and link-local address, it 915 sets the `C' bit in the DHCP Request. A client MAY send in 916 such a Request even when it is no longer attached to the link on 917 which the relay-address is attached. The `C' bit allows better 918 reclamation of available resources when a client lost records for 919 its resource-server associations and might not otherwise be able to 920 release the associated resources. 922 When a client reboots and loses its previous state, the server 923 should no longer keep track of the transaction IDs associated with 924 that previous state. In order to inform the server that the client 925 no longer wishes any association to be maintained between used 926 transaction-IDs and previous transactions, the client SHOULD set the 927 `R' bit in its DHCP Request. 929 In any case, after choosing a transaction-ID which is numerically 930 greater than its last recorded transaction-ID, and filling in the 931 appropriate fields of the DHCP Request message, the client MAY append 932 various DHCP Extensions to the message. These extensions denote 933 specific requests by the client; for example, a client may request 934 a particular IP address, or request that the server send an update 935 containing the client's new IP address to a Domain Name Server. When 936 all desired extensions have been applied, the client sends the DHCP 937 Request to the appropriate agent. 939 For each pending DHCP Request message, a client MUST maintain the 940 following information: 942 - The transaction-ID of the request message, 943 - The server-address, 944 - The agent-address (which can be the same as the server-address), 945 - The time at which the next retransmission will be attempted, and 946 - All extensions appended to the request message. 948 If a client does not receive a DHCP Reply message (Section 5.5) with 949 the same transaction-ID as a pending DHCP Request message within 950 REPLY_MSG_TIMEOUT (see section 8) seconds, or if the received DHCP 951 Reply message contains a DHCP Authentication extension which fails 952 to provide the correct authentication information, the client MUST 953 retransmit the Request with the same transaction-ID and continue to 954 retransmit according to the rules in Section 8. If (after following 955 those rules) the client has not received a Reply message, it SHOULD 956 start over again by multicasting a new DHCP Solicit message to find a 957 different server. 959 If the client receives an ICMP error message in response to such a 960 DHCP Request, it likewise SHOULD start over again by multicasting a 961 new DHCP Solicit message, to find a different server. 963 If the client transmits a DHCP Request in response to a DHCP 964 Reconfigure message (see Section 5.7) with the `N' bit not set, 965 the client can continue to operate with its existing configuration 966 information and resources until it receives the corresponding DHCP 967 Reply from the server. The same retransmission rules apply as for 968 any other DHCP Request message from the client. When the `N' bit is 969 set, a DHCP Request sent in response to a DHCP Reconfigure message 970 will not elicit a DHCP Reply message from the server. 972 5.5. Receiving DHCP Reply Messages 974 When a client receives a DHCP Reply message, it MUST check whether 975 the transaction-ID in the Reply message matches the transaction-ID 976 of a pending DHCP Request message. If no match is found, the Reply 977 message MUST be silently discarded. 979 If the Reply message is acceptable, the client processes each 980 Extension [13], extracting the relevant configuration information 981 and parameters for its network operation. The client can determine 982 when all extensions in the Reply have been processed by using the UDP 983 Length field of the Reply. Some extensions in the Reply may have 984 status codes, which indicate to the client the reason for failure 985 when the server was unable to honor the request. If the server is 986 unable to honor the request in an extension included by the client, 987 that extension may simply be omitted from the Reply. The server MAY 988 also provide the client with configuration parameters the client did 989 not specifically request. 991 Some configuration information extracted from the extensions to the 992 DHCP Reply message MUST remain associated with the server that sent 993 the message. The particular extensions that require this extra 994 measure of association with the server are indicated in the DHCP 995 Extensions document [13]. These "resource-server" associations are 996 used when sending DHCP Release messages. 998 5.6. Sending DHCP Release Messages 1000 If a client wishes to ask the server to release all information and 1001 resources relevant to the client, the client SHOULD send a DHCP 1002 Release message without any extensions; this is preferable to sending 1003 a DHCP Request message with the `C' bit set and no extensions. If a 1004 client wishes to retain some of its network configuration parameters, 1005 but determines that others are no longer needed, it SHOULD enable 1006 the server to release allocated resources which are no longer in 1007 use by sending a DHCP Release message to the server, and including 1008 extensions to identify the unneeded items. The client consults its 1009 list of resource-server associations in order to determine which 1010 server should receive the desired Release message. 1012 Suppose a client wishes to release resources which were granted to 1013 it at another IP address. Further, suppose that the client has an 1014 IP address that will still be valid after the server performs the 1015 operations requested in the extensions to the DHCP Release message, 1016 and which has sufficient scope to be reachable from the server. In 1017 that case, and only then, the client MUST set the `D' bit in the DHCP 1018 Release message (see section 4.5). This instructs the server to 1019 send the DHCP Reply directly back to the client at the latter valid 1020 IP address, instead of performing the default processing of sending 1021 the DHCP Reply back through the agent-address included in the DHCP 1022 Release. 1024 5.7. Receiving DHCP Reconfigure Messages 1026 Each client implementation MUST support listening at UDP port 546 1027 to receive possible DHCP Reconfigure messages; in cases where the 1028 client knows that no Reconfigure message will ever be issued, the 1029 client MAY be configured to avoid executing this supported feature. 1030 In some cases, the IP address at which the client listens will be a 1031 multicast address sent to the client by the server in an extension 1032 to an earlier DHCP Reply message. If the client does not listen for 1033 DHCP Reconfigure messages, it is possible that the client will not 1034 receive notification that its server has deallocated the client's 1035 IP address and/or other resources allocated to the client. See 1036 discussion in 6.5. The client MAY receive a prefix update for one 1037 or more of their addresses and then MUST use that prefix for those 1038 addresses. 1040 If a client receives a DHCP Reconfigure message, it is a request for 1041 the client to initiate a new DHCP Request/Reply transaction with the 1042 server which sent the Reconfigure message. The server sending the 1043 Reconfigure message MAY be different than the server which sent a 1044 DHCP Reply message containing the original configuration information. 1046 Reconfigure messages can be retransmitted by the server with the 1047 same transaction-ID. When a client receives such a retransmitted 1048 Reconfigure message within XID_TIMEOUT of the last received 1049 Reconfigure message with the same transaction-ID, the client MUST 1050 reformulate exactly the same DHCP Request message and retransmit the 1051 request message to the server again. In this way, the server can 1052 make use of the retransmission algorithm to ensure that all affected 1053 clients have received the Reconfigure message. 1055 For each Extension which is present in the Reconfigure message, the 1056 client MUST append a matching Extension to its Request message, which 1057 it formulates to send to the server specified in the server-address 1058 field of the message. The client also copies a transaction-ID from 1059 the Reconfigure message into the Request message. If the `N' bit is 1060 not set, processing from then on is the same as specified above in 1061 Section 5.4. 1063 Resources held by the client which are not identified by Extensions 1064 in the server's Reconfigure message are not affected. 1066 If a client has recently sent a DHCP Request to the server from which 1067 it subsequently received the DHCP Reconfigure message, the client 1068 SHOULD silently discard the Reconfigure message until the server 1069 sends the DHCP Reply message with the same transaction-ID as the 1070 client's DHCP Request message. 1072 A server may ask its client to join a multicast group for the 1073 purpose of receiving DHCP Reconfigure messages. When a Reconfigure 1074 message is delivered to the client by way of the selected multicast 1075 address, the client MUST delay its further response for a random 1076 amount of time uniformly distributed within the interval between 1077 RECONF_MMSG_MIN_RESP and RECONF_MMSG_MAX_RESP seconds (see 1078 section 8). This will minimize the likelihood that the server will 1079 be flooded with DHCP Request messages. 1081 5.8. Interaction with Stateless Address Autoconfiguration 1083 Please refer to the Stateless Address Autoconfiguration 1084 Protocol specification [17] and its follow-on, Stateless Address 1085 Autoconfiguration version 2 [18] for details regarding the actions 1086 taken by clients upon receiving Router Advertisements with changing 1087 values for the `M' and `O' bits. 1089 6. DHCP Server Considerations 1091 A node which is not a client or relay MUST ignore any DHCP Advertise, 1092 DHCP Reply, or DHCP Reconfigure message it receives. 1094 A server maintains a collection of client records, called 1095 ``bindings''. Each binding is uniquely identifiable by the ordered 1096 pair , since the link-local 1097 address is guaranteed to be unique [17] on the link identified 1098 by the agent-address and prefix. An implementation MUST support 1099 bindings consisting of at least a client's link-local address, 1100 agent-address prefix, preferred lifetime and valid lifetime [17] for 1101 each client address. A server MAY, at the discretion of the network 1102 administrator, be configured so that client bindings are identified 1103 by the client's MAC address, without need to use the additional 1104 information supplied by the agent-address. A client binding may be 1105 used to store any other information, resources, and configuration 1106 data which will be associated with the client. A server MUST retain 1107 its clients' bindings across server reboots, and, whenever possible, 1108 a client should be assigned the same configuration parameters 1109 despite server system reboots and DHCP server program restarts. A 1110 server MUST support fixed or permanent allocation of configuration 1111 parameters to specific clients. 1113 In addition to the client binding a server must maintain an 1114 XID_TIMEOUT binding cache to determine if a previous transaction-ID 1115 is being retransmitted by a client. An implementation of an 1116 XID_TIMEOUT binding cache MUST support at least a tuple consisting of 1117 the client's link-local address, agent-address prefix, IPv6 address, 1118 and XID_TIMEOUT value when the cache entry can be deleted (see 1119 Section 8). 1121 6.1. Receiving DHCP Solicit Messages 1123 If the DHCP Solicit message was received at the All-DHCP-Servers 1124 multicast address, the server MUST check to make sure that the 1125 relay-address is present, and is not a link-local address. If the 1126 relay-address is not present, or if it is a link-local address, 1127 the server MUST silently discard the packet. Note that if the 1128 client sends a DHCP Solicit message from a link-local address, the 1129 multicast destination will be the All-DHCP-Agents address, not the 1130 All-DHCP-Servers address. 1132 When the `C' bit is set in the solicitation, the server deallocates 1133 all resources that match its link-local address. The server MUST 1134 take the relay-address and use the prefix-size to locate the client 1135 binding. 1137 As an optimization, a server processing a Solicit message from relays 1138 MAY check the prefix of the IP source address in the IP header to 1139 determine whether the server has received the Solicit from multiple 1140 relays on the same link. The prefix-size field in the solicitation 1141 enables the server to ascertain when two relay addresses belong to 1142 the same link. 1144 6.2. Sending DHCP Advertise Messages 1146 Upon receiving and verifying the correctness of a DHCP Solicit 1147 message, a server constructs a DHCP Advertise message and transmits 1148 it on the same link as the solicitation was received from. When the 1149 solicitation is received at the All-DHCP-Servers multicast address, 1150 the server SHOULD delay the transmission of its advertisement 1151 for a random amount of time between SERVER_MIN_ADV_DELAY and 1152 SERVER_MAX_ADV_DELAY (see section 8). 1154 If the relay-address is nonzero, the server MUST copy it into the 1155 agent-address field of the advertisement message, and send the 1156 advertisement to the relay-address. Otherwise, the server MUST 1157 send the advertisement to the client's link-local address. An IP 1158 address of the interface on which the server received the Solicit 1159 message MUST appear in the server-address field of the corresponding 1160 advertisement. 1162 The server MAY append extensions to the Advertisement, in order to 1163 offer the soliciting node the best possible information about the 1164 available services and resources. 1166 6.3. DHCP Request and Reply Message Processing 1168 DHCP server MUST check to ensure that the client's link-local address 1169 field of the Request message contains a link-local address. If not, 1170 the message MUST be silently discarded. If the `S' bit is set, the 1171 server MUST check that the server-address matches one of its own IP 1172 addresses. If the server-address does not match, the Request message 1173 MUST be silently discarded. 1175 If the received agent-address and link-local address do not 1176 correspond to any binding known to the server, then the server 1177 SHOULD create a new binding for the previously unknown client, 1178 and send a DHCP Reply with any resources allocated to the new 1179 binding. Otherwise, if the server cannot create a new binding, 1180 it SHOULD return a DHCP Reply with a status of ``NoBinding'' (see 1181 Section 2.4). If the client is updating its resources but the 1182 database is temporarily unavailable, the server SHOULD return a DHCP 1183 Reply with a status of ``Unavail'' (see Section 2.4). 1185 While processing the Request, the server MUST first determine whether 1186 or not the Request is a retransmission of an earlier DHCP Request 1187 from the same client. This is done by comparing the transaction-ID 1188 to all those transaction-IDs received from the same client during the 1189 previous XID_TIMEOUT seconds. If the transaction-ID is the same as 1190 one received during that time, the server MUST take the same action 1191 (e.g., retransmit the same DHCP Reply to the client) as it did after 1192 processing the previous DHCP Request with the same transaction-ID. 1194 Otherwise, if the server has no record of a message from the client 1195 with the same transaction-ID, the server identifies and allocates 1196 all the relevant information, resources, and configuration data that 1197 is associated with the client. Then it sends that information to 1198 its client by constructing a DHCP Reply message and including the 1199 client's information in DHCP Extensions to the Reply message. The 1200 DHCP Reply message uses the same transaction-ID as found in the 1201 received DHCP Request message. Note that the reply message MAY 1202 contain information not specifically requested by the client. 1204 If the DHCP Request message has the `S' bit set in the message 1205 header, the server MUST send the corresponding DHCP Reply message to 1206 the agent-address found in the Request (see section 7.2). Otherwise, 1207 the server SHOULD send the corresponding DHCP Reply message to the 1208 IP source address in the IP header received from the client Request 1209 message. 1211 6.3.1. Processing for Extensions to DHCP Request and Reply Messages 1213 The DHCP Request may contain extensions [13], which are interpreted 1214 (by default) as advisory information from the client about its 1215 configuration preferences. For instance, if the IP Address Extension 1216 is present, the server SHOULD attempt to allocate or extend the 1217 lifetime of the address indicated by the extension. Some extensions 1218 may be marked by the client as required. 1220 The server may accept some extensions for successful processing and 1221 allocation, while still rejecting others, or it may reject various 1222 extensions for different reasons, and set the status appropriately 1223 for those extensions which return status to the client. The server 1224 sends a single DHCP Reply message in response to each DHCP Request, 1225 with the same transaction-ID as the Request. 1227 Whenever it is able to, the server includes an extension in the 1228 Reply message for every extension sent by the client in the Request 1229 message. If the client requests some extensions that cannot be 1230 supplied by the server, the server can simply fail to provide them, 1231 not including them in the Reply. Other extensions can be rejected 1232 by including them in the Reply with an appropriate status indicating 1233 failure. The server can include extensions in the reply that were 1234 not requested by the client. 1236 6.3.2. Client Requests to Deallocate Unknown Resources 1238 When a client DHCP Request is received that has the `C' bit set, 1239 the server should check to find out whether the extensions listed 1240 in the Request message match those which it has associated with the 1241 client's binding. Any resources which are not indicated by the 1242 client are presumed to be unknown by the client, and thus possible 1243 candidates for reallocation to satisfy requests from other clients. 1244 The server MUST deallocate all resources associated with the client 1245 upon reception of a DHCP Request with the `C' bit set, except for 1246 those which the server is willing to reallocate in response to the 1247 client's request. It may be more efficient to avoid deallocating any 1248 resources until after the list of extensions to the request has been 1249 inspected. 1251 6.4. Receiving DHCP Release Messages 1253 If the server receives a DHCP Release Message, it MUST verify that 1254 the link-local address field of the message contains an address which 1255 could be a valid link-local address (see Section 2.1). If not, the 1256 message MUST be silently discarded. 1258 In response to a DHCP Release Message with a valid client's 1259 link-local address and agent-address, the server formulates a DHCP 1260 Reply message that will be sent back to the releasing client. When 1261 the `D' flag is set, the server MUST send the DHCP Reply back to 1262 the client using the client-address field of the Release message. 1263 Otherwise, if the `D' bit is not set, the server MUST send its DHCP 1264 Reply message (with the `L' bit set) to the agent-address in the 1265 Release message, so that the relay agent can subsequently forward the 1266 Reply back to the releasing client at the client's link-local address 1267 indicated in the Reply message. 1269 If the received agent-address and link-local address do not 1270 correspond to any binding known to the server, then the server SHOULD 1271 return a DHCP Reply, indicating the error by setting the status code 1272 to ``NoBinding'' (see Section 2.4). 1274 Otherwise, if the agent-address and link-local address indicate a 1275 binding known to the server, then the server continues processing the 1276 Release message. If there are any extensions, the server releases 1277 the particular configuration items specified in the extensions. 1278 If there are no extensions, the server releases all configuration 1279 information in the client's binding. 1281 After performing the operations indicated in the DHCP Release message 1282 and its extensions, the server formulates a DHCP Reply message, 1283 copying the transaction-ID from the DHCP Release message. For 1284 each Extension in the DHCP Release message successfully processed 1285 by the server, a matching Extension is appended to the DHCP Reply 1286 message. For extensions in the DHCP Release message which cannot be 1287 successfully processed by the server, a DHCP Reply message containing 1288 extensions with the appropriate status MUST be returned by the 1289 server. If the Release message contains no extensions, the server 1290 does not include any extensions in the corresponding DHCP Reply 1291 message to the client. 1293 6.5. Sending DHCP Reconfigure Messages 1295 If a server needs to change the configuration associated with any of 1296 its clients, it constructs a DHCP Reconfigure message and sends it to 1297 each such client. The Reconfigure MAY be sent to a multicast address 1298 chosen by the server and previously sent to each such client in an 1299 extension to a previous DHCP Reply message. 1301 It may happen that a client does not send a DHCP Request message 1302 after the DHCP Reconfigure message has been issued and retransmitted 1303 RECONF_MSG_MIN_RETRANS times, according to the algorithm specified 1304 in Section 8. This can happen when the client is not listening for 1305 the Reconfigure message, possibly because the client is a mobile 1306 node disconnected from the network, or because the client node 1307 has sustained a power outage or operating system crash. In such 1308 cases, the server SHOULD reserve any resources issued to the client 1309 until the client responds at some future time, until the resource 1310 allocation times out (see section 6.6), or until administrative 1311 intervention causes the resources to be manually returned to use. 1312 The server SHOULD also log a DHCP System Error. 1314 If the server gets another DHCP Request from a client, with a 1315 transaction-ID which does not match that of the recently transmitted 1316 reconfigure message, the server SHOULD send a DHCP Reply to 1317 the client, and wait for RECONF_MSG_RETRANS_INTERVAL, before 1318 retransmitting the DHCP Reconfigure again. 1320 6.6. Client-Resource timeouts 1322 Some resources (for instance, a client's IP address) may only be 1323 allocated to a client for a particular length of time (for instance, 1324 the valid lifetime of an IP address). If the client does not renew 1325 the resource allocation for such a resource, the server MAY make the 1326 resource available for allocation to another client. However, under 1327 administrative control, the server MAY reserve any resources issued 1328 to the client until the client responds at some future time. 1330 7. DHCP Relay Considerations 1332 The DHCP protocol is constructed so that a relay does not have 1333 to maintain any state in order to mediate DHCP client/server 1334 interactions. 1336 The DHCP relay enables clients and servers to carry out DHCP protocol 1337 transactions. DHCP Solicit messages are issued by the relay when 1338 initiated by prospective clients. By default, the relay locates 1339 servers by use of multicasting solicitations to the All-DHCP-Servers 1340 multicast group, but relays SHOULD allow this behavior to be 1341 configurable. The relay MUST be able to determine which of its 1342 interfaces received the client's solicitation message. 1344 7.1. DHCP Solicit and DHCP Advertise Message Processing 1346 Upon receiving a DHCP Solicit message from a prospective client, 1347 a relay, by default, forwards the message to servers at a site 1348 according to the following procedure: 1350 - copying the prospective client's solicitation message fields into 1351 the appropriate fields of the outgoing solicitation, 1353 - copying a non-link-local address of its interface from which the 1354 solicitation was received from the client into the relay-address 1355 field, and 1357 - setting the prefix-size field appropriately, 1359 - by default, setting the hop-count field in the IP header of 1360 the solicitation to the value DEFAULT_SOLICIT_HOPCOUNT (see 1361 section 8). 1363 - setting the IP source address to be a site-local or global-scope 1364 address belonging to the relay's interface on which the client's 1365 original solicitation was received, 1367 - finally, sending the resulting message to one or more servers. 1369 By default, the relay sends solicitations to the All-DHCP-Servers 1370 multicast address, FF05:0:0:0:0:0:1:3. However, the relay MAY be 1371 configured with an alternate server address, or the FQDN of a server. 1372 Methods for automatically updating such alternately configured server 1373 addresses are not specified in this document. 1375 When the relay receives a DHCP advertisement, it relays the 1376 advertisement to the client at the client's link-local address by way 1377 of the interface indicated in the agent's address field. 1379 7.2. DHCP Request Message Processing 1381 When a relay receives a DHCP Request message, it SHOULD check that 1382 the IP source address in the IP header is a link-local address, 1383 that the link-local address matches the link-local address field in 1384 the Request message header, and that the agent-address field of the 1385 message matches an IP address associated with the interface from 1386 which the DHCP Request message was received. If any of these checks 1387 fail, the relay MUST silently discard the Request message. 1389 The relay MUST check whether the `S' bit is set in the message 1390 header. If not, the packet is discarded, and the relay SHOULD 1391 return a DHCP Reply message to the address contained in the client's 1392 link-local address field of the Request message, with status 1393 ``PoorlyFormed'' (see Section 2.4). 1395 If the received request message is acceptable, the relay then 1396 transmits the DHCP Request message to the address of the server found 1397 in the server-address field of the received DHCP Request message. 1398 All of the fields of DHCP Request message transmitted by the relay 1399 are copied over unchanged from the DHCP Request received from the 1400 client. Only the fields in the IP header will differ from the 1401 packet received from the client. All relays MUST send DHCP Request 1402 messages using the source IP address from the interface where the 1403 DHCP request was received. If the Relay receives an ICMP error, the 1404 Relay SHOULD return a DHCP Reply message to the client address (which 1405 can be found in the payload of the ICMP message [5]), with status 1406 ``ICMPError'' (see Section 2.4), along with the DHCP Relay ICMP Error 1407 extension [13]. 1409 7.3. DHCP Reply Message Processing 1411 When the relay receives a DHCP Reply, it MUST check that the message 1412 has the `L' bit set. It MUST check that the client's link-local 1413 address field contains a link-local address. If either check fails, 1414 the packet MUST be silently discarded. If both checks are satisfied, 1415 the relay MUST send a DHCP Reply message to the link-local address 1416 listed in the received Reply message. Only the fields in the IP 1417 header will differ from the packet received from the server, not the 1418 payload. 1420 8. Retransmission and Configuration Variables 1422 When a client does not receive a DHCP Reply in response to a pending 1423 DHCP Request, the client MUST retransmit the identical DHCP Request, 1424 with the same transaction-ID, to the same server again until it can 1425 be reasonably sure that the server is unavailable and an alternative 1426 can be chosen. The DHCP server assumes that the client has received 1427 the configuration information included with the extensions to the 1428 DHCP Reply message, and it is up to the client to continue to try for 1429 a reasonable amount of time to complete the transaction. All the 1430 actions specified for DHCP Request in this section hold also for DHCP 1431 Release messages sent by the client. 1433 Similarly, when a client sends a DHCP Request message in response to 1434 a Reconfigure message from the server, the client assumes that the 1435 DHCP server has received the Request. The server MUST retransmit 1436 the identical DHCP Reconfigure to the client a reasonable number 1437 of times to try to elicit the Request message from the client. 1438 If no corresponding DHCP Request is received by the server after 1439 REQUEST_MSG_MIN_RETRANS retransmissions, the server MAY erase or 1440 deallocate information as needed from the client's binding, but see 1441 section 6.5. 1443 Retransmissions occur using the following configuration variables 1444 for a DHCP implementation. Note that the retransmission algorithm 1445 does not use exponential backoff techniques. These configuration 1446 variables MUST be configurable by a client or server: 1448 CLIENT_ADV_WAIT 1450 The minimum amount of time a client waits to receive DHCP 1451 Advertisements after transmitting a DHCP Solicit to the 1452 All-DHCP Agents multicast address (see section 5.3). 1454 Default: 2 seconds 1456 DEFAULT_SOLICIT_HOPCOUNT 1458 The default hop-count used in the IP header by DHCP relays when 1459 sending DHCP Solicit messages on behalf of a client. 1461 Default: 4 1463 SERVER_MIN_ADV_DELAY 1465 The minimum amount of time a server waits to transmit a 1466 DHCP Advertisement after receiving a DHCP Solicit at the 1467 All-DHCP-Servers or All-DHCP-Agents multicast address. 1469 Default: 100 milliseconds 1471 SERVER_MAX_ADV_DELAY 1473 The maximum amount of time a server waits to transmit a DHCP 1474 Advertisement after receiving a DHCP Solicit at the All-DHCP 1475 Agents multicast address. 1477 Default: 1 second 1479 REPLY_MSG_TIMEOUT 1481 The time in seconds that a client waits to receive a server's 1482 DHCP Reply before retransmitting a DHCP Request. 1484 Default: 2 seconds. 1486 REQUEST_MSG_MIN_RETRANS 1488 The minimum number of DHCP Request transmissions that a client 1489 should retransmit, before aborting the request. 1491 Default: 10 retransmissions. 1493 RECONF_MSG_MIN_RETRANS 1495 The minimum number of DHCP Reconfigure messages that a 1496 server should retransmit, before assuming the the client is 1497 unavailable. 1499 Default: 10 retransmissions. 1501 RECONF_MSG_RETRANS_INTERVAL 1503 The least time in seconds that a server waits for a 1504 client's DHCP Request before each retransmission of the DHCP 1505 Reconfigure. 1507 Default: 12 seconds. 1509 RECONF_MMSG_MIN_RESP 1511 The minimum amount of time before a client can respond to a 1512 DHCP Reconfigure message sent to a multicast address. 1514 Default: 2 seconds. 1516 RECONF_MMSG_MAX_RESP 1518 The maximum amount of time before a client MUST respond to a 1519 DHCP Reconfigure message sent to a multicast address. 1521 Default: 10 seconds. 1523 MIN_SOLICIT_DELAY 1525 The minimum amount of time a prospective client is required to 1526 wait, after determining from a Router Advertisement message 1527 that the client should perform stateful address configuration, 1528 before sending a DHCP Solicit to a server. 1530 Default: 1 second 1532 MAX_SOLICIT_DELAY 1534 The maximum amount of time a prospective client is required to 1535 wait, after determining from a Router Advertisement message 1536 that the client should perform stateful address configuration, 1537 before sending a DHCP Solicit to a server. 1539 Default: 5 seconds 1541 XID_TIMEOUT 1543 The amount of time a DHCP server has to keep track of 1544 client transaction-IDs in order to make sure that client 1545 retransmissions using the same transaction-ID are idempotent. 1547 Default: 600 seconds 1549 9. Security Considerations 1551 Clients and servers often have to authenticate the messages they 1552 exchange. For instance, a server may wish to be certain that a DHCP 1553 Request originated from the client identified by the fields included within the Request message 1555 header. Conversely, it is quite often essential for a client to 1556 be certain that the configuration parameters and addresses it has 1557 received were sent to it by an authoritative server. Similarly, a 1558 server should only accept a DHCP Release message which seems to be 1559 from one of its clients, if it has some assurance that the client 1560 actually did transmit the Release message. Again, a client might 1561 wish to only accept DHCP Reconfigure messages that are certain to 1562 have originated from a server with authority to issue them. 1564 The IPv6 Authentication Header can provide security for DHCPv6 1565 messages when both endpoints have a suitable IP address. However, 1566 a client often has only a link-local address, and such an address 1567 is not sufficient for a server which is off-link. In those 1568 circumstances the DHCP relay is involved, so that the DHCP message 1569 MUST have the relay's address in the IP destination address field, 1570 even though the client aims to deliver the message to the server. 1571 The DHCP Client-Server Authentication Extension [13] is intended to 1572 be used in these circumstances. 1574 Note that, if a client receives a DHCP message which fails 1575 authentication, it should continue to wait for another message which 1576 might be correctly authenticated just as if the failed message had 1577 never arrived; however, receiving such failed messages SHOULD be 1578 logged. 1580 10. Year 2000 considerations 1582 Since all times are relative to the current time of the transaction, 1583 there is no problem within the DHCPv6 protocol related to any 1584 hardcoded dates or two-digit representation of the current year. 1586 11. IANA Considerations 1588 This document defines message types 1-7 to be received by UDP at port 1589 numbers 546 and 547. Additional message types may be defined in the 1590 future. 1592 Section 3.3 specifies the use of several multicast groups, with 1593 multicast addresses FF02:0:0:0:0:0:1:2, FF05:0:0:0:0:0:1:3, and 1594 FF05:0:0:0:0:0:1:4. 1596 This document also defines several status codes that are to be 1597 returned with the DHCP Reply message (see section 4.4). The nonzero 1598 values for these status codes which are currently specified are shown 1599 in section 2.4. 1601 There is a DHCPv6 extension [13] which allows clients and servers to 1602 exchange values for some of the timing and retransmission parameters 1603 defines in section 8. Adding new parameters in the future would 1604 require extending the values by which the parameters are indicated in 1605 the DHCP extension. Since there needs to be a list kept, the default 1606 values for each parameter should also be stored as part of the list. 1608 All of these protocol elements may be specified to assume new values 1609 at some point in the future. New values should be approved by the 1610 process of IETF Consensus [12]. 1612 12. Acknowledgements 1614 Thanks to the DHC Working Group for their time and input into the 1615 specification. Ralph Droms and Thomas Narten have had a major 1616 role in shaping the continued improvement of the protocol by their 1617 careful reviews. Many thanks to Matt Crawford, Erik Nordmark, Gerald 1618 Maguire, and Mike Carney for their studied review as part of the 1619 Last Call process. Thanks also for the consistent input, ideas, and 1620 review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov 1621 Rekhter, Matt Thomas, Sue Thomson, and Phil Wells. 1623 Thanks to Steve Deering and Bob Hinden, who have consistently 1624 taken the time to discuss the more complex parts of the IPv6 1625 specifications. 1627 A. Changes for this revision 1629 - Changed the preference field to be 8 bits and always present 1631 - Eliminated the `P' bit from the DHCP Advertise message 1633 - Noted that relays SHOULD be able to determine which interface 1634 receives a message 1636 Should this be here? 1638 B. Related Protocol Specifications 1640 Related work in IPv6 that would best serve an implementor to study 1641 is the IPv6 Specification [6], the IPv6 Addressing Architecture [8], 1642 IPv6 Stateless Address Autoconfiguration [17], IPv6 Neighbor 1643 Discovery Processing [11], and Dynamic Updates to DNS [20]. These 1644 specifications enable DHCP to build upon the IPv6 work to provide 1645 both robust stateful autoconfiguration and autoregistration of DNS 1646 Host Names. 1648 The IPv6 Specification provides the base architecture and design of 1649 IPv6. A key point for DHCP implementors to understand is that IPv6 1650 requires that every link in the internet have an MTU of 1500 octets 1651 or greater (in IPv4 the requirement is 68 octets). This means that 1652 a UDP packet of 536 octets will always pass through an internet 1653 (less 40 octets for the IPv6 header), as long as there are no IP 1654 options prior to the UDP header in the packet. But, IPv6 does not 1655 support fragmentation at routers, so that fragmentation takes place 1656 end-to-end between hosts. If a DHCP implementation needs to send a 1657 packet greater than 1500 octets it can either fragment the UDP packet 1658 into fragments of 1500 octets or less, or use Path MTU Discovery [10] 1659 to determine the size of the packet that will traverse a network 1660 path. It is implementation dependent how this is accomplished in 1661 DHCP. Path MTU Discovery for IPv6 is supported for both UDP and TCP 1662 and can cause end-to-end fragmentation when the PMTU changes for a 1663 destination. 1665 The IPv6 Addressing Architecture specification [8] defines the 1666 address scope that can be used in an IPv6 implementation, and the 1667 various configuration architecture guidelines for network designers 1668 of the IPv6 address space. Two advantages of IPv6 are that support 1669 for multicast is required, and nodes can create link-local addresses 1670 during initialization. This means that a client can immediately use 1671 its link-local address and a well-known multicast address to begin 1672 communications to discover neighbors on the link. For instance, a 1673 client can send a DHCP Solicit and locate a server or relay. 1675 IPv6 Stateless Address Autoconfiguration [17] (Addrconf) specifies 1676 procedures by which a node may autoconfigure addresses based on 1677 router advertisements [11], and the use of a valid lifetime to 1678 support renumbering of addresses on the Internet. In addition the 1679 protocol interaction by which a node begins stateless or stateful 1680 autoconfiguration is specified. DHCP is one vehicle to perform 1681 stateful autoconfiguration. Compatibility with Addrconf is a design 1682 requirement of DHCP (see Section 3.1). 1684 IPv6 Neighbor Discovery [11] is the node discovery protocol in IPv6 1685 which replaces and enhances functions of ARP [14]. To understand 1686 IPv6 and Addrconf it is strongly recommended that implementors 1687 understand IPv6 Neighbor Discovery. 1689 Dynamic Updates to DNS [20] is a specification that supports the 1690 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 1691 the dynamic updates to DNS to integrate addresses and name space to 1692 not only support autoconfiguration, but also autoregistration in 1693 IPv6. The security model to be used with DHCPv6 should conform as 1694 closely as possible to the authentication model outlined in [9]. 1696 C. Comparison between DHCPv4 and DHCPv6 1698 This appendix is provided for readers who will find it useful to see 1699 a model and architecture comparison between DHCPv4 [7, 1] and DHCPv6. 1700 There are three key reasons for the differences: 1702 o IPv6 inherently supports a new model and architecture for 1703 communications and autoconfiguration of addresses. 1705 o DHCPv6 benefits from the new IPv6 features. 1707 o New features were added to support the expected evolution and 1708 the existence of more complicated Internet network service 1709 requirements. 1711 IPv6 Architecture/Model Changes: 1713 o The link-local address permits a node to have an address 1714 immediately when the node boots, which means all clients have a 1715 source IP address at all times to locate a server or relay agent 1716 on the local link. 1718 o The need for BOOTP compatibility and broadcast flags is removed. 1720 o Multicast and address scoping in IPv6 permit the design of 1721 discovery packets that would inherently define their range by the 1722 multicast address for the function required. 1724 o Stateful autoconfiguration has to coexist and integrate with 1725 stateless autoconfiguration supporting Duplicate Address 1726 Detection and the two IPv6 lifetimes, to facilitate the dynamic 1727 renumbering of addresses and the management of those addresses. 1729 o Multiple addresses per interface are inherently supported in 1730 IPv6. 1732 o Many DHCPv4 options are unnecessary now because the configuration 1733 parameters are either obtained through IPv6 Neighbor Discovery or 1734 the Service Location protocol [19]. 1736 DHCPv6 Architecture/Model Changes: 1738 o The message type is the first byte in the packet. 1740 o IPv6 Address allocations are now handled in a message extension 1741 as opposed to the message header. 1743 o Client/Server bindings are now mandatory and take advantage of 1744 the client's link-local address to always permit communications 1745 either directly from an on-link server, or from a remote server 1746 through an on-link relay-agent. 1748 o Servers are discovered by a client solicit, followed by a server 1749 or relay-agent advertisement. 1751 o The client will know if the server is on-link or off-link. 1753 o The on-link relay-agent locates remote server addresses from 1754 system configuration or by the use of a site wide multicast 1755 packet. 1757 o ACKs and NAKs are not used. 1759 o The server assumes the client receives its responses unless it 1760 receives a retransmission of the same client request. This 1761 permits recovery in the case where the network has faulted. 1763 o Clients can issue multiple, unrelated DHCP Request messages to 1764 the same or different servers. 1766 o The function of DHCPINFORM is inherent in the new packet design; 1767 a client can request configuration parameters other than IPv6 1768 addresses in the optional extension headers. 1770 o Clients MUST listen to their UDP port for the new Reconfigure 1771 message from servers. 1773 o New extensions have been defined. 1775 With the changes just enumerated, we can support new user features, 1776 including 1778 o Configuration of Dynamic Updates to DNS 1780 o Address deprecation, for dynamic renumbering. 1782 o Relays can be preconfigured with server addresses, or use of 1783 multicast. 1785 o Authentication 1787 o Clients can ask for multiple IP addresses. 1789 o Addresses allocated with too-long lifetimes can be reclaimed 1790 using the Reconfigure message. 1792 o Integration between stateless and stateful address 1793 autoconfiguration. 1795 o Enabling relay-agents to locate remote servers for a link. 1797 D. Full Copyright Statement 1799 Copyright (C) The Internet Society (1998). All Rights Reserved. 1801 This document and translations of it may be copied and furnished to 1802 others, and derivative works that comment on or otherwise explain it 1803 or assist in its implementation may be prepared, copied, published 1804 and distributed, in whole or in part, without restriction of any 1805 kind, provided that the above copyright notice and this paragraph 1806 are included on all such copies and derivative works. However, 1807 this document itself may not be modified in any way, such as by 1808 removing the copyright notice or references to the Internet Society 1809 or other Internet organizations, except as needed for the purpose 1810 of developing Internet standards in which case the procedures 1811 for copyrights defined in the Internet Standards process must be 1812 followed, or as required to translate it into languages other than 1813 English. 1815 The limited permissions granted above are perpetual and will not be 1816 revoked by the Internet Society or its successors or assigns. 1818 This document and the information contained herein is provided on an 1819 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1820 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1821 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1822 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1823 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1825 References 1827 [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 1828 Extensions. RFC 2132, March 1997. 1830 [2] S. Bradner. Key Words for Use in RFCs to Indicate Requirement 1831 Levels. RFC 2119, March 1997. 1833 [3] S. Bradner and A. Mankin. The Recommendation for the IP Next 1834 Generation Protocol. RFC 1752, January 1995. 1836 [4] William R. Cheswick and Steven Bellovin. Firewalls and Internet 1837 Security. Addison-Wesley, Reading, Massachusetts, 1994. (ISBN: 1838 0-201-63357-4). 1840 [5] A. Conta and S. Deering. Internet Control Message Protocol 1841 (ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885, 1842 December 1995. 1844 [6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1845 Specification. RFC 1883, December 1995. 1847 [7] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March 1848 1997. 1850 [8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 1851 RFC 1884, December 1995. 1853 [9] Stephen Kent and Randall Atkinson. IP Authentication Header. 1854 draft-ietf-ipsec-auth-header-06.txt, May 1998. (work in 1855 progress). 1857 [10] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP 1858 version 6. RFC 1981, August 1996. 1860 [11] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 1861 IP version 6 (IPv6). RFC 1970, August 1996. 1863 [12] Thomas Narten and Harald Tveit Alvestrand. Guidelines 1864 for Writing an IANA Considerations Section in RFCs. 1865 draft-iesg-iana-considerations-04.txt, May 1998. (work in 1866 progress). 1868 [13] C. Perkins. Extensions for the Dynamic Host Configuration 1869 Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-11.txt, June 1998. 1870 (work in progress). 1872 [14] David C. Plummer. An Ethernet Address Resolution Protocol: 1873 Or Converting Network Protocol Addresses to 48.bit Ethernet 1874 Addresses for Transmission on Ethernet Hardware. RFC 826, 1875 November 1982. 1877 [15] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 1879 [16] J. B. Postel, Editor. Internet Protocol. RFC 791, September 1880 1981. 1882 [17] S. Thomson and T. Narten. IPv6 Stateless Address 1883 Autoconfiguration. RFC 1971, August 1996. 1885 [18] S. Thomson and T. Narten. IPv6 Address Autoconfiguration. 1886 draft-ietf-ipngwg-addrconf-v2-00.txt, November 1997. (work in 1887 progress). 1889 [19] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 1890 Location Protocol. RFC 2165, July 1997. 1892 [20] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates 1893 in the Domain Name System (DNS). RFC 2136, April 1997. 1895 Chair's Address 1897 The working group can be contacted via the current chair: 1899 Ralph Droms 1900 Computer Science Department 1901 323 Dana Engineering 1902 Bucknell University 1903 Lewisburg, PA 17837 1905 Phone: (717) 524-1145 1906 E-mail: droms@bucknell.edu 1908 Author's Address 1910 Questions about this memo can be directed to: 1912 Jim Bound Charles Perkins 1913 Compaq Computer Corporation Technology Development 1914 110 Spitbrook Road, ZKO3-3/U14 Sun Microsystems, Inc. 1915 Nashua, NH 03062 901 San Antonio Rd. 1916 Palo Alto, CA 94303 1917 Phone: +1-603-884-0400 +1-650-786-6464 1918 Fax: +1-650-786-6445 1919 E-mail: bound@zk3.dec.com charles.perkins@sun.com