idnits 2.17.1 draft-ietf-dhc-dhcpv6-09.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-24) 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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 253: '... MUST This word, or the ...' RFC 2119 keyword, line 257: '... MUST NOT This phrase means ...' RFC 2119 keyword, line 260: '... SHOULD This word, or the ...' RFC 2119 keyword, line 267: '... MAY This word, or the ...' RFC 2119 keyword, line 270: '... MUST be prepared to i...' (122 more instances...) -- The draft header indicates that this document obsoletes draft-ietf-dhc-dhcpv6-08.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- -- No information found for rfcdraft-ietf-dhc-dhcpv6-08.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 (27 February 1997) is 9918 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1885 (ref. '2') (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 1883 (ref. '3') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1884 (ref. '4') (Obsoleted by RFC 2373) ** Obsolete normative reference: RFC 1981 (ref. '5') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 1970 (ref. '6') (Obsoleted by RFC 2461) -- No information found for draft-ietf-dhc-dhcpv6ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' ** Obsolete normative reference: RFC 1971 (ref. '11') (Obsoleted by RFC 2462) -- Unexpected draft version: The latest known version of draft-ietf-dnsind-dynDNS is -10, but you're referring to -11. (However, the state information for draft-ietf-dhc-dhcpv6ext is not up-to-date. The last update was unsuccessful) Summary: 15 errors (**), 0 flaws (~~), 2 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 Digital Equipment Corp. 3 DHC Working Group C. Perkins 4 Obsoletes: draft-ietf-dhc-dhcpv6-08.txt Sun Microsystems 5 27 February 1997 7 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 8 draft-ietf-dhc-dhcpv6-09.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 2 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. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 16 71 5.2. Receiving DHCP Advertise Messages . . . . . . . . . . . . 16 72 5.3. Sending DHCP Request Messages . . . . . . . . . . . . . . 17 73 5.4. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 18 74 5.5. Sending DHCP Release Messages . . . . . . . . . . . . . . 19 75 5.6. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 19 77 6. DHCP Server Considerations 20 78 6.1. Receiving DHCP Solicit Messages . . . . . . . . . . . . . 21 79 6.2. Sending DHCP Advertise Messages . . . . . . . . . . . . . 21 80 6.3. DHCP Request and Reply Messages . . . . . . . . . . . . . 21 81 6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 23 82 6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . . 24 84 7. DHCP Relay Considerations 24 85 7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 24 86 7.2. DHCP Request Message Processing . . . . . . . . . . . . . 25 87 7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 25 89 8. Retransmission and Configuration Variables 26 91 9. Security Considerations 28 93 10. Acknowledgements 29 95 A. Related Work in IPv6 29 97 B. Change History 30 98 B.1. Changes from November 95 to February 96 Drafts . . . . . 30 99 B.2. Changes from February 96 to June 96 Drafts . . . . . . . 31 100 B.3. Changes from June 96 to August 96 Drafts . . . . . . . . 31 101 B.4. Changes from August 96 to November 96 Drafts . . . . . . 32 102 B.5. Changes from November 96 to February 97 Drafts . . . . . 33 104 C. Comparison between DHCPv4 and DHCPv6 34 106 Chair's Address 38 108 Author's Address 38 109 1. Introduction 111 The Dynamic Host Configuration Protocol (DHCPv6, or in this 112 document usually DHCP) provides configuration parameters to Internet 113 nodes. DHCP consists of a protocol for delivering node-specific 114 configuration parameters from a DHCP server to a client, and a 115 mechanism for allocation of network addresses and other related 116 parameters to IPv6 [3] nodes. 118 DHCP is built on a client-server model, where designated DHCP 119 servers allocate network addresses and automatically deliver 120 configuration parameters to dynamically configurable clients. 121 Throughout the remainder of this document, the term "server" 122 refers to a node providing initialization parameters by way of the 123 DHCP protocol, and the term "client" refers to a node requesting 124 initialization parameters from a DHCP server. DHCP servers maintain 125 state for their clients, in contrast to IPv6 Stateless Address 126 Autoconfiguration [11], where IPv6 nodes should get the same results 127 if they repeat the autoconfiguration procedure multiple times. 129 DHCPv6 uses Request and Reply messages to support a client/server 130 processing model whereby both client and server are assured that 131 requested configuration parameters have been received and accepted 132 by the client. DHCP supports optional configuration parameters and 133 processing for nodes through extensions described in its companion 134 document ``Extensions for the Dynamic Host Configuration Protocol for 135 IPv6'' [7]. 137 The IPv6 Addressing Architecture [4] and IPv6 Stateless Address 138 Autoconfiguration specifications provide new features not available 139 in IP version 4 (IPv4) [10], which are used to simplify and 140 generalize the operation of DHCP clients. 142 Section 2 provides definitions for terminology used throughout 143 this document. Section 3 provides an overview of the protocol 144 design model that guided the design choices in the specification; 145 section 3.2 briefly describes the protocol messages and their 146 semantics. Section 4 provides the message formats and field 147 definitions used for each message. Sections 5, 6, and 7 specify 148 how clients, servers, and relays interact. Appendix A summarizes 149 related work in IPv6 that will provide helpful context; it is not 150 part of this specification, but included for informational purposes. 151 Appendix B itemizes changes between different versions of this 152 protocol specification. Appendix C discusses the differences between 153 DHCPv4 and DHCPv6. 155 2. Terminology and Definitions 157 Relevant terminology from the IPv6 Protocol [3], IPv6 Addressing 158 Architecture [4], and IPv6 Stateless Address Autoconfiguration [11] 159 will be provided, and then the DHCPv6 terminology. 161 2.1. IPv6 Terminology 163 IP Internet Protocol Version 6 (IPv6). The terms IPv4 and 164 IPv6 are used only in contexts where necessary to avoid 165 ambiguity. 167 node A device that implements IP. 169 router A node that forwards IP datagrams not explicitly 170 addressed to itself. 172 host Any node that is not a router. 174 link A communication facility or medium over which nodes 175 can communicate at the link layer, i.e., the layer 176 immediately below IP. Examples are Ethernet (simple or 177 bridged); Token Ring; PPP links, X.25, Frame Relay, or 178 ATM networks; and internet (or higher) layer "tunnels", 179 such as tunnels over IPv4 or IPv6 itself. 181 link-layer identifier 182 a link-layer identifier for an interface. Examples 183 include IEEE 802 addresses for Ethernet or Token Ring 184 network interfaces, and E.164 addresses for ISDN links. 186 link-local address 187 An IP address having link-only scope that can be used 188 to reach neighboring nodes attached to the same link. 189 All interfaces have a link-local address. 191 neighbor Nodes attached to the same link. 193 interface 194 A node's attachment to the link. 196 address An IP layer identifier for an interface or a set of 197 interfaces. 199 message A unit of data carried in a datagram, exchanged between 200 DHCP agents and clients. 202 datagram An IP header plus payload. 204 unicast address 205 An identifier for a single interface. A datagram sent 206 to a unicast address is delivered to the interface 207 identified by that address. 209 multicast address 210 An identifier for a set of interfaces (typically 211 belonging to different nodes). A datagram sent to 212 a multicast address is delivered to all interfaces 213 identified by that address. 215 2.2. DHCPv6 Terminology 217 configuration parameter 218 Any parameter that can be used by a node to configure 219 its network environment and enable communication on a 220 link or internetwork. 222 DHCP client A node that initiates requests on a link to obtain 223 configuration parameters. 225 DHCP server A server is a node that responds to requests from 226 clients to provide: addresses, prefix lengths, or 227 other configuration parameters. 229 DHCP relay A node that acts as an intermediary to deliver DHCP 230 messages between clients and servers. 232 DHCP Agent 233 Either a DHCP server or a DHCP relay. 235 agent address 236 The address of a neighboring DHCP relay or DHCP server 237 on the same link as the DHCP client. 239 transaction-ID 240 The transaction-ID is a monotonically increasing 241 integer identifier specified by the client or server, 242 and used to match a response to a pending message. 244 binding A binding (or, client binding) in DHCP contains the 245 data which a DHCP server maintains for each of its 246 clients (see Section 6). 248 2.3. Specification Language 250 In this document, several words are used to signify the requirements 251 of the specification. These words are often capitalized. 253 MUST This word, or the adjective "required", means that 254 the definition is an absolute requirement of the 255 specification. 257 MUST NOT This phrase means that the definition is an absolute 258 prohibition of the specification. 260 SHOULD This word, or the adjective "recommended", means 261 that there may exist valid reasons in particular 262 circumstances to ignore this item, but the full 263 implications must be understood and carefully 264 weighed before choosing a different course. 265 Unexpected results may result otherwise. 267 MAY This word, or the adjective "optional", means that 268 this item is one of an allowed set of alternatives. 269 An implementation which does not include this option 270 MUST be prepared to interoperate with another 271 implementation which does include the option. 273 silently discard 274 The implementation discards the datagram without 275 further processing, and without indicating an error 276 to the sender. The implementation SHOULD provide 277 the capability of logging the error, including the 278 contents of the discarded datagram, and SHOULD 279 record the event in a statistics counter. 281 3. Protocol Design Model 283 This section is provided for implementors to understand the DHCPv6 284 protocol design model from an architectural perspective. The goals, 285 conceptual models and implementation examples presented in this 286 section do not specify requirements of the DHCPv6 protocol. 288 3.1. Design Goals 290 The following list gives general design goals for this DHCP 291 specification. 293 - DHCP should be a mechanism rather than a policy. DHCP MUST allow 294 local system administrators control over configuration parameters 295 where desired; e.g., local system administrators should be able 296 to enforce local policies concerning allocation and access to 297 local resources where desired. 299 - DHCP MUST NOT introduce any requirement for manual configuration 300 of DHCP clients, except possibly for manually configured 301 keys. Each node should be able to discover appropriate 302 local configuration parameters without user intervention, and 303 incorporate those parameters into its own configuration. 305 - DHCP MUST NOT require a server on each link. To allow for scale 306 and economy, DHCP MUST work across DHCP relays. 308 - A DHCP client MUST be prepared to receive multiple (possibly 309 different) responses to solicitations for DHCP servers. Some 310 installations may include multiple, overlapping DHCP servers to 311 enhance reliability and/or to increase performance. 313 - DHCP MUST coexist with statically configured, non-participating 314 nodes and with existing network protocol implementations. 316 - DHCPv6 MUST be compatible with IPv6 Stateless Address 317 Autoconfiguration [11]. 319 - DHCP MUST support the requirements of automated renumbering of IP 320 addresses [1]. 322 - DHCP servers should be able to support Dynamic Updates to 323 DNS [12]. 325 - DHCP servers MUST be able to handle multiple IPv6 addresses for 326 each client. 328 - A DHCP server to server protocol is NOT part of this 329 specification. 331 - It is NOT a design goal of DHCP to specify how a server 332 configuration parameter database is maintained or determined. 333 Methods for configuring DHCP servers are outside the scope of 334 this document. 336 3.2. DHCP Messages 338 Each DHCP message contains a type, which defines their function 339 within the protocol. Processing details for these DHCP messages are 340 specified in Sections 5, 6, and 7. The message types are as follows: 342 01 DHCP Solicit 344 The DHCP Solicit message is a DHCP message sent to one or more 345 DHCP Agents. 347 02 DHCP Advertise 349 The DHCP Advertise is an IP unicast message from a DHCP Agent 350 in response to a client DHCP Solicit message. 352 03 DHCP Request 354 The DHCP Request is an IP unicast message from a client to a 355 server to request configuration parameters on a network. 357 04 DHCP Reply 359 The DHCP Reply is an IP unicast message sent by a server to 360 respond to a client's DHCP Request. Extensions [7] to the DHCP 361 Reply describe the resources that the DHCP Server has committed 362 and allocated to the client, and may contain other information 363 for use by the client. 365 05 DHCP Release 367 The DHCP Release message is used by a DHCP client to inform 368 the server that the client is releasing a particular address, 369 or set of addresses or resources, so that the server may 370 subsequently mark the addresses as invalid, or release 371 resources in the server's binding for the client. 373 06 DHCP Reconfigure 375 The DHCP Reconfigure message is used by a DHCP server to inform 376 its client that the server has new configuration information of 377 importance to the client. The client is expected to initiate a 378 new Request/Reply transaction. 380 3.3. Request/Response Processing Model 382 The request/response processing for DHCPv6 is transaction based 383 and uses a best-effort set of messages to guarantee a completed 384 transaction. 386 Transactions are usually started by a client with a DHCP Request, 387 which may be issued after the client knows the server's address. 388 The response (DHCP Reply) is from the server (possibly via a DHCP 389 Relay). At this point in the flow all data has been transmitted 390 and, hopefully, received. To provide a method of recovery if either 391 the client or server do not receive the messages to complete the 392 transaction, the client is required to retransmit any DHCP Request 393 message until it elicits the corresponding DHCP Reply or Replies, 394 or until it can be reasonably certain that the desired DHCP Server 395 is unavailable. The timeout and retransmission guidelines and 396 configuration variables are discussed in Section 8. 398 All DHCP Agents (Servers and Relays) MUST join the link-local 399 All-DHCP-Agent multicast group at the well-known multicast address 400 FF02:0:0:0:0:0:1:2. All DHCP Servers MUST, in addition, join 401 the site-local All-DHCP-Servers multicast group at the well-known 402 multicast address FF05:0:0:0:0:0:1:3. All DHCP Relays MUST, on the 403 other hand, join in addition the site-local All-DHCP-Relays multicast 404 group at the well-known multicast address FF05:0:0:0:0:0:1:4. 406 DHCP uses the UDP [9] protocol to communicate between clients 407 and servers. UDP is not reliable, but DHCP has to provide some 408 reliability between clients and servers. If a response is not 409 received after transmission of a DHCP message, the message MUST be 410 retransmitted according to the rules specified in Section 8. The 411 All-DHCP-Relays address will be used eventually when DHCP Servers 412 wish to automatically configure all site DHCP Relays. 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 If a DHCP client does not know any DHCP Agent address, or wants 465 to locate a new server to receive configuration parameters, the 466 client SHOULD use, as the destination IP address, the well-known All 467 DHCP Agents multicast address FF02:0:0:0:0:0:1:2. Any DHCP Relay 468 receiving the solicitation MUST forward it to the All-DHCP-Servers 469 multicast address, to instruct DHCP Servers to send their 470 advertisements to the prospective client. In that case, the relay 471 MUST copy the client's link-local address into the message, copy the 472 address of its interface from which the client's solicitation was 473 received into the agent's address field, and set the 'A' bit. 475 4.2. DHCP Advertise Message Format 477 A DHCP agent sends a DHCP Advertise message to inform a prospective 478 client about the IP address of a DHCP Agent to which a DHCP Request 479 message may be sent. When the client and server are on different 480 links, the server sends the advertisement back through the DHCP Relay 481 whence the solicitation came. 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | msg-type |S| reserved | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | agent address | 489 | (16 octets) | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | client's link-local address | 492 | (16 octets) | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | server address | 495 | (16 octets, if present) | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | extensions (variable number and length) ... 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 msg-type 2 502 S If set, the agent address is also a server address. 504 reserved 0 506 agent address 507 The IP address of a DHCP Agent interface on the same 508 link as the client. 510 client's link-local address 511 The IP link-local address of the client interface 512 from which the client issued the DHCP Request message 514 server address 515 The IP address of the DHCP server 517 extensions See [7]. 519 Suppose that a DHCP server on the same link as a client issues the 520 DHCP Advertise in response to a DHCP Solicit message sent to the 521 All-DHCP-Agent multicast address. Then the agent address will be the 522 IP address of one of the server's interfaces, the 'S' bit will be 523 set, the agent address will be an address of the server, and there 524 will be no server address sent in the DHCP Advertise message. It is 525 an error for server-count to be zero if the 'S' bit is not set. 527 The DHCP Server MUST copy the link-local address into the 528 advertisement which is sent in response to a DHCP Solicit. The 529 source IP address of the IP header of any DHCP Advertise message MUST 530 have sufficient scope to be reachable by the DHCP Client. Moreover, 531 the source address of any DHCP Advertise message sent by a DHCP relay 532 MUST NOT be a link-local address. In situations where there are no 533 routers sending Router Advertisements, then a DHCP Server MUST be 534 configured on the same link as prospective clients. 536 4.3. DHCP Request Message Format 538 In order to request parameters from a DHCP server, a client sends a 539 DHCP Request message, and MAY append the appropriate extensions [7]. 540 If the client does not know any DHCP server address, it MUST first 541 obtain a server address by multicasting a DHCP Solicit message (see 542 Section 4.1). If the client does not have a valid IP address of 543 sufficient scope for the DHCP server to communicate with the client, 544 the client MUST use the unicast IP address of a local DHCP relay 545 (which then becomes the agent address in the message header) as the 546 Destination IP address. In this case, the client cannot send the 547 message directly to the DHCP server because the server could not 548 return any response to the client. Otherwise, the client MAY omit 549 the server address in the DHCP Request message; in this case, the 550 client MUST send the DHCP Request message directly to the server, 551 using the server address as the IP destination address in the IP 552 header. 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | msg-type |S|C| reserved | transaction-ID | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | server address | 560 | (16 octets, if present) | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | agent address | 563 | (16 octets) | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | client's link-local address | 566 | (16 octets) | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | extensions (variable number and length) .... 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 msg-type 3 573 S If set, the server address is present 575 C If set, the client requests the server to clear all 576 other existing resources and bindings (not requested 577 in extensions) currently associated with the client, 578 deallocating as needed. 580 reserved 0 582 transaction-ID 583 A monotonically increasing number used to identify this 584 Request, and copied into the Reply. 586 server address 587 If present, the IP address of the DHCP server which 588 should receive the client's DHCP Request message. 590 agent address 591 The IP address of a relay or server interface, copied 592 from a DHCP Advertisement message. 594 client's link-local address 595 The IP link-local address of the client interface from 596 which the client issued the DHCP Request message 598 extensions See [7]. 600 4.4. DHCP Reply Message Format 602 The server sends one DHCP Reply message in response to every DHCP 603 Request or DHCP Release received. If the request comes with the 'S' 604 bit set, the client could not directly send the Request to the server 605 and had to use a neighboring relay agent. In that case, the server 606 sends back the DHCP Reply with the 'L' bit set, and the DHCP Reply is 607 addressed to the agent address found in the DHCP Request message. If 608 the 'L' bit is set, then the client's link-local address will also be 609 present. 611 0 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | msg-type |L| error code | transaction-ID | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | client's link-local address | 617 | (16 octets, if present) | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | extensions (variable number and length) .... 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 msg-type 4 624 L If set, the link-local address is present 626 error code 627 One of the following values: 629 0 Success 630 16 Failure, reason unspecified 631 17 Authentication failed or nonexistent 632 18 Poorly formed Request or Release 633 19 Resources unavailable 634 20 Client record unavailable 635 21 Invalid client IP address in Release 636 23 Relay cannot find Server Address 637 24 Cannot understand selected Character Set 638 64 Server unreachable (ICMP error) 640 transaction-ID 641 A monotonically increasing number used to identify this 642 Reply, and copied from the client's Request. 644 client's link-local address 645 If present, the IP address of the client interface 646 which issued the corresponding DHCP Request message. 648 extensions 649 See [7]. 651 If the 'L' bit is set, and thus the link-local address is present in 652 the Reply message, the Reply is sent by the server to the relay's 653 address which was specified as the agent address in the DHCP Request 654 message, and the relay uses the link-local address to deliver 655 the Reply message to the client. If the length in the UDP header 656 preceding the DHCP message does not match that which is expected in 657 the DHCP Request, error code 23 MUST be sent. 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 (Section 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 693 transaction-ID 694 A monotonically increasing number used to identify this 695 Release, and copied into the Reply. 697 agent address 698 The IP address of the agent interface to which the 699 client issued the DHCP Request message 701 client's link-local address 702 The IP link-local address of the client interface from 703 which the the client issued the DHCP Request message 705 client address 706 The IP address of the client interface from which the 707 the client issued the DHCP Request message. The client 708 address field is present whenever the 'D' bit is set, 709 even if it is equal to the link-local address. 711 extensions See [7] 713 Suppose that the client has an IP address that will still be valid 714 after the server performs the operations requested in the extensions 715 to the DHCP Release message. In that case, and only then, the client 716 SHOULD then specify the 'D' flag. When the 'D' flag is set, the 717 server MUST send the DHCP Reply back to the client's address as shown 718 in the client address field of the Release message. Otherwise, when 719 the 'D' bit is not set, the server MUST use the agent address and 720 link-local address in its DHCP Reply message to forward the Reply 721 message back to the releasing client. 723 4.6. DHCP Reconfigure Message Format 725 The DHCP Reconfigure message is sent without the assistance of any 726 DHCP relay. When a server sends a Reconfigure message, the client 727 to which it is sent is assumed to have a valid IP address with 728 sufficient scope to be accessible by the server. Only the parameters 729 which are specified in the extensions to the Reconfigure message need 730 be requested again by the client. 732 0 1 2 3 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | msg-type | reserved | transaction-ID | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | server address | 738 | (16 octets) | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | extensions (variable number and length) .... 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 msg-type 6 745 reserved 0 747 transaction-ID 748 A monotonically increasing number used to identify 749 this Reconfigure message, and copied into the 750 client's Request. 752 server address 753 The IP address of the DHCP server issuing the DHCP 754 Reconfigure message. 756 extensions See [7] 758 5. DHCP Client Considerations 760 A DHCP client MUST silently discard any DHCP Solicit, DHCP Request, 761 or DHCP Release message it receives. 763 A DHCP client MAY retain its configured parameters and resources 764 across client system reboots and DHCP client program restarts. 765 However, in these circumstances a DHCP client MUST also formulate a 766 DHCP Request message to verify that its configured parameters and 767 resources are still valid. This Request message MUST have the 'C' 768 bit set, to clean up stale client binding information at the server 769 which may no longer be in use by the client; stale information is 770 that which the client does not include in extensions to such request 771 messages. 773 If the server does not respond to the DHCP Request message, the 774 client may still use any addresses which have not yet expired. In 775 this case, however, the client MUST begin to search for another 776 server by multicasting a new DHCP Solicit message, again with the 'C' 777 bit set, containing its IP address in the appropriate extension. 779 This also handles the case wherein a client restarts on a new 780 network, so that its IP address is no longer valid. When the client 781 multicasts a new DHCP Discover message, servers will respond with 782 the information needed for the client to release its old address, if 783 need be, and request an address reachable on the new network. In 784 this situation, when the client receives a new IP address and the old 785 IP address is no longer reachable, the client MUST release its old 786 IP address by issuing a DHCP Release message with the appropriate 787 extension. 789 5.1. Sending DHCP Solicit Messages 791 If a node wishes to become a new DHCP client, it MUST first 792 locate a DHCP Server. The client does this by multicasting a DHCP 793 Solicit message to the All-DHCP-Agents address multicast address 794 FF02:0:0:0:0:0:1:2, setting the Hop Limit == 1. If there are 795 no DHCP servers on the same link as the node, then a DHCP Relay 796 MUST be present for further handling of the solicitation. The 797 prospective client SHOULD wait for ADV_WAIT seconds to get all the 798 DHCP Advertisement messages which may be sent in response to the 799 solicitation. 801 If a DHCP client reboots and does not have a valid IP address, 802 it MUST set the 'C' bit in the DHCP Solicit message it sends 803 when restarting. By setting the 'C' bit in the solicitation, a 804 DHCP client requests that all the DHCP Servers that receive the 805 solicitation should clean up their stale client records that match 806 its link-local address. 808 If a client sends a DHCP Solicit message after it reboots, the 809 solicitation SHOULD be delayed after reception of the first Router 810 Advertisement [6] message, by at least some random amount of time 811 between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY seconds. This delay 812 is intended to help stagger requests to DHCP Servers (and avoid 813 link-layer collisions) after a power outage causes many nodes to 814 reboot all at once. Each subsequent DHCP Solicit message that is 815 issued before receiving an advertisement MUST be delayed by twice the 816 amount by which the previous DHCP Solicit message was delayed. 818 5.2. Receiving DHCP Advertise Messages 820 When a DHCP client receives a DHCP Advertise message, it may 821 formulate a DHCP Request message to receive configuration information 822 and resources from the DHCP servers listed in the advertisement. 823 If the Advertise message has no server address field and does 824 not have the 'S' bit set, the client MUST silently discard the 825 message. If the server's address is shown as a Multicast address, 826 the advertisement MUST be silently discarded. 828 If the 'S' bit is set, the DHCP Advertise message was transmitted 829 by a DHCP server on the same link as the client. In this case, the 830 client MUST use the agent address as the destination address for any 831 future DHCP message transactions sent to that server. 833 Advertisements may have extensions; this might allow the DHCP client 834 to select the configuration that best meets its needs from among 835 several prospective servers. 837 5.3. Sending DHCP Request Messages 839 A DHCP client obtains configuration information from a DHCP server by 840 sending a DHCP Request message. The client MUST know the server's 841 address before sending the Request message, and client MUST have 842 acquired a (possibly identical) DHCP agent address. If the client 843 and server are on the same link, the agent address used by the client 844 MUST be the same as the DHCP server's address. A DHCP Request 845 message MUST NOT be sent to any multicast address, since otherwise 846 multiple DHCP agents would possibly allocate resources to the client 847 in response to the same Request, and the client would have no way to 848 know which servers had made the allocations, if any datagrams were 849 lost due to collisions, etc. 851 If the client has no valid IP address of sufficient scope, and the 852 DHCP server is off-link, then the client MUST include the server 853 address in the appropriate field of the DHCP Request message and set 854 the 'S' bit. In this case, the IP destination address of the Request 855 message will be a DHCP relay address. 857 Otherwise, if the client already has a valid IP address of sufficient 858 scope and knows the IP address of a candidate DHCP server, it 859 SHOULD send the Request message directly to the DHCP server without 860 requiring the services of the local DHCP relay. 862 If a client wishes to instruct a DHCP server to deallocate all 863 unknown previous resources, configuration information, and bindings 864 associated with its agent address and link-local address, it sets the 865 'C' bit in the DHCP Request. A client MAY send in such a Request 866 even when it is no longer attached to the link on which the relay 867 address is attached. 869 In any case, after choosing a transaction-ID which is numerically 870 greater than its previous transaction-ID, and filling in the 871 appropriate fields of the DHCP Request message, the client MAY append 872 various DHCP Extensions to the message. These extensions denote 873 specific requests by the client; for example, a client may request 874 a particular IP address, or request that the server send an update 875 containing the client's new IP address to a Domain Name Server. When 876 all desired extensions have been applied, the DHCP client unicasts 877 the DHCP Request to the appropriate DHCP Agent. 879 For each pending DHCP Request message, a client MUST maintain the 880 following information: 882 - The transaction-ID of the request message, 883 - The server address, 884 - The agent address (which can be the same as the server address), 885 - The time at which the next retransmission will be attempted, and 886 - All extensions appended to the request message. 888 If a client does not receive a DHCP Reply message (Section 5.4) with 889 the same transaction-ID as a pending DHCP Request message within 890 REPLY_MSG_INITIAL_TIMEOUT seconds, or if the received DHCP Reply 891 message contains a DHCP Authentication extension which fails to 892 provide the correct authentication information, the client MUST 893 retransmit the Request with the same transaction-ID and continue to 894 retransmit according to the rules in Section 8. 896 If the client transmits a DHCP Request in response to a DHCP 897 Reconfigure message (see Section5.6), the client can continue to 898 operate with its existing configuration information and resources 899 until it receives the corresponding DHCP Reply from the server. The 900 same retransmission rules apply as for any other DHCP Request message 901 from the client. 903 5.4. Receiving DHCP Reply Messages 905 When a client receives a DHCP Reply message, it MUST check whether 906 the transaction-ID in the Reply message matches the transaction-ID 907 of a pending DHCP Request message. If no match is found, the Reply 908 message MUST be silently discarded. 910 If the Reply message is acceptable, the client processes each 911 Extension [7], extracting the relevant configuration information 912 and parameters for its network operation. The client can determine 913 when all extensions in the Reply have been processed by using the 914 Length field of the Reply. Some extensions in the Reply may have 915 error codes, when the server was unable to honor the request, which 916 will indicate to the client the reason for failure. If the server is 917 simply unable to honor the request in an extension included by the 918 client, that extension may simply be omitted from the Reply. 920 Some configuration information extracted from the extensions to the 921 DHCP Reply message MUST remain associated with the DHCP server that 922 sent the message. The particular extensions that require this extra 923 measure of association with the server are indicated in the DHCP 924 Extensions document [7]. These "resource-server" associations are 925 used when sending DHCP Release messages. 927 5.5. Sending DHCP Release Messages 929 If a DHCP client determines that some of its network configuration 930 parameters are no longer needed, it SHOULD enable the DHCP server to 931 release allocated resources which are no longer in use by sending a 932 DHCP Release message to the server. The client consults its list 933 of resource-server associations in order to determine which server 934 should receive the desired Release message. If a client wishes to 935 ask the server to release all information and resources relevant to 936 the client, the client specifies no extensions; this is preferable 937 to sending a DHCP Request message with the 'C' bit set and no 938 extensions. 940 Suppose a client wishes to release resources which were granted to 941 it on another link. In that case, the client MUST instruct the 942 server to send the DHCP Reply directly back to the client, instead 943 of performing the default processing of sending the DHCP Reply back 944 through the agent-address included in the DHCP Release. This is done 945 by setting the 'D' bit in the DHCP Release message. Note that it is 946 an error (Error Code 21) to include within the DHCP Release message 947 both the 'D' bit and an IP address extension which has the IP address 948 used as the client IP address field of the DHCP Release message 949 header. 951 5.6. Receiving DHCP Reconfigure Messages 953 Each DHCP client MUST listen at UDP port 546 to receive possible 954 DHCP Reconfigure messages, except in cases where the client knows 955 that no Reconfigure message will ever be issued. In some cases, 956 the IP address at which the client listens will be a multicast 957 address sent to the client by the DHCP server in an extension to 958 an earlier DHCP Reply message. If the client does not listen for 959 DHCP Reconfigure messages, it is possible that the client will 960 not receive notification that its DHCP server has deallocated the 961 client's IP address and/or other resources allocated to the client. 963 See discussion in 6.5. The client MAY receive an update to the 964 prefix for their addresses and then MUST use that prefix for their 965 addresses. 967 If a DHCP client receives a DHCP Reconfigure message, it is a request 968 for the client to initiate a new DHCP Request/Reply transaction with 969 the server which sent the Reconfigure message. The server sending 970 the Reconfigure message MAY be different than the server which sent a 971 DHCP Reply message containing the original configuration information. 973 For each Extension which is present in the Reconfigure message, the 974 client appends a matching Extension to its Request message, which 975 it formulates to send to the server specified in the server address 976 field of the message. The client also copies a transaction-ID from 977 the Reconfigure message into the Request message. From then on, 978 processing is the same as specified above in Section 5.3. 980 Resources held by the client which are not identified by Extensions 981 in the server's Reconfigure message are not affected. 983 Note that a server may ask its client to join a multicast group 984 for the purpose of receiving DHCP Reconfigure messages. When a 985 Reconfigure message is delivered to the client by way of the selected 986 multicast address, the client MUST delay its further response for 987 a random amount of time uniformly distributed within the interval 988 between RECONF_MSG_MIN_RESP and RECONF_MSG_MAX_RESP seconds. This 989 will minimize the likelihood that the server will be bombarded with 990 DHCP Request messages all at the same time. 992 6. DHCP Server Considerations 994 A server MUST ignore any DHCP Advertise, DHCP Reply, or DHCP 995 Reconfigure message it receives. 997 A server maintains a collection of client records, called 998 ``bindings''. Each binding is uniquely identifiable by the ordered 999 pair , since the link-local 1000 address is guaranteed to be unique [11] on the link identified 1001 by the agent address. An implementation MUST support bindings 1002 consisting of at least a client's link-local address, agent address, 1003 preferred lifetime and valid lifetime [11] for each client address, 1004 and the transaction-ID. A client binding may be used to store any 1005 other information, resources, and configuration data which will be 1006 associated with the client. A DHCP server MUST retain its clients' 1007 bindings across server reboots, and, whenever possible, a DHCP client 1008 should be assigned the same configuration parameters despite server 1009 system reboots and DHCP server program restarts. A DHCP server MUST 1010 support fixed or permanent allocation of configuration parameters to 1011 specific clients. 1013 Servers on the same link as the client MUST use the source address 1014 in the IP header from the client as the destination address in DHCP 1015 response messages sent by the server to the client. 1017 6.1. Receiving DHCP Solicit Messages 1019 If the DHCP Solicit message was received at the All-DHCP-Servers 1020 multicast address, the DHCP Server MUST check to make sure that the 1021 source address is not a link-local address. In that case, if the 1022 source address is a link-local address, the server MUST silently 1023 discard the packet. If the UDP length disagrees with the length 1024 determined by the format of the DHCP Solicit message, the server 1025 MUST drop the packet and SHOULD log the error. Note that if the 1026 client sends a DHCP Solicit message from a link-local address, the 1027 multicast destination will be the All-DHCP-Agents address, not the 1028 All-DHCP-Servers address. 1030 6.2. Sending DHCP Advertise Messages 1032 Upon receiving and verifying the correctness of a DHCP Solicit 1033 message, a server constructs a DHCP Advertise message and transmits 1034 it on the same link as the solicitation was received from. The 1035 destination address of the advertisement MUST be the source address 1036 of the solicitation. The DHCP server MUST use an IP address of the 1037 interface on which it received the Solicit message as the source 1038 address field of the IP header of the message. 1040 The DHCP server MAY append extensions to the Advertisement, in order 1041 to offer the soliciting node the best possible information about 1042 the services and resources which the server may be able to make 1043 available. 1045 6.3. DHCP Request and Reply Messages 1047 The DHCP server MUST check to ensure that the client's link-local 1048 address field of the Request message contains an address which could 1049 be a valid link-local address. If not, the message MUST be silently 1050 discarded. Otherwise, it checks for the presence of the 'S' bit. If 1051 the 'S' bit is set, the server MUST check that the server address 1052 matches the destination IP address at which the Request message was 1053 received by the server. If the server address does not match, the 1054 Request message MUST be silently discarded. 1056 If the received agent address and link-local address do not 1057 correspond to any binding known to the server, then the server MAY 1058 create a new binding for the previously unknown client; otherwise, it 1059 SHOULD return a DHCP Reply with an error code of 20. 1061 While processing the Request, the server MUST first determine whether 1062 or not the Request is a retransmission of an earlier DHCP Request 1063 from the same client. This is done by comparing the transaction-ID 1064 to all those transaction-IDs received from the same client during the 1065 previous XID_TIMEOUT seconds. If the transaction-ID is the same as 1066 one received during that time, the server MUST take the same action 1067 (e.g., retransmit the same DHCP Reply to the client) as it did after 1068 processing the previous DHCP Request with the same transaction-ID. 1070 Otherwise, if the transaction-ID has not been recently used, the 1071 server identifies and allocates all the relevant information, 1072 resources, and configuration data that is associated with the client. 1073 Then it sends that information to its DHCP client by constructing a 1074 DHCP Reply message and including the client's information in DHCP 1075 Extensions to the Reply message. The DHCP Reply message uses the 1076 same transaction-ID as found in the received DHCP Request message. 1077 Note that the reply message MAY contain information not specifically 1078 requested by the client. 1080 If the DHCP Request message has the 'S' bit set in the message 1081 header, then the Request was sent to the server by a DHCP Relay. In 1082 this case, the DHCP server MUST send the corresponding DHCP Reply 1083 message to the agent address found in the Request (see section 7.2). 1085 The DHCP Request may contain extensions, which are interpreted 1086 (by default) as advisory information from the client about its 1087 configuration preferences. For instance, if the IP Address Extension 1088 is present, the DHCP server SHOULD attempt to allocate or extend the 1089 lifetime of the address indicated by the extension. Some extensions 1090 may be marked by the client as required. 1092 The DHCP server may accept some extensions for successful processing 1093 and allocation, while still rejecting others, or the server may 1094 reject various extensions for different reasons. The server sets 1095 the Error Code appropriately for those extensions which return error 1096 status to the client. The DHCP server sends a single Reply message 1097 in response to each DHCP Request, with the same transaction-ID as the 1098 Request. 1100 Whenever it is able to, the server includes an extension in the 1101 Reply message for every extension sent by the client in the Request 1102 message. If the client requests some extensions that cannot be 1103 supplied by the server, the server can simply fail to provide them, 1104 not including them in the Reply. Other extensions can be rejected by 1105 including them in the Reply with an appropriate error code indicating 1106 failure. 1108 When a client DHCP Request is received that has the 'C' bit set, 1109 the server should check to find out whether the extensions listed 1110 in the Request message match those which it has associated with the 1111 client's binding. Any resources which are not indicated by the 1112 client are presumed to be unknown by the client, and thus possible 1113 candidates for reallocation to satisfy requests from other clients. 1114 The DHCP Server MUST deallocate all resources associated with the 1115 client upon reception of a DHCP Request with the 'C' bit set, except 1116 for those which the server is willing to reallocate response to the 1117 client's request. It may be more efficient to avoid deallocating any 1118 resources until after the list of extensions to the request have been 1119 inspected. 1121 6.4. Receiving DHCP Release Messages 1123 If the server receives a DHCP Release Message, it MUST verify that 1124 the link-local address field of the message contains an address 1125 which could be a valid link-local address (i.e., one with the prefix 1126 FE80::0000/64). If not, the message MUST be silently discarded. 1128 In response to a DHCP Release Message with a valid client's 1129 link-local address and agent address, the DHCP server formulates a 1130 DHCP Reply message that will be sent back to the releasing client by 1131 way of the client's link-local address. A DHCP Reply message sent 1132 in response to a DHCP Release message MUST be sent to the client's 1133 link-local address via the agent address in the Release message 1134 and set the 'L' bit in the Reply, unless the 'D' bit is set in the 1135 Release message. 1137 If the received agent address and link-local address do not 1138 correspond to any binding known to the server, then the server SHOULD 1139 return a DHCP Reply with an error code of 20. 1141 Otherwise, if the agent address and link-local address indicate a 1142 binding known to the server, then the server continues processing the 1143 Release message. If there are any extensions, the server releases 1144 the particular configuration items specified in the extensions. 1145 Otherwise, if there are no extensions, the server releases all 1146 configuration information in the client's binding. 1148 After performing the operations indicated in the DHCP Release message 1149 and its extensions, the DHCP server formulates a DHCP Reply message, 1150 copying the transaction-ID, from the DHCP Release message. For 1151 each Extension in the DHCP Release message successfully processed 1152 by the server, a matching Extension is appended to the DHCP Reply 1153 message. For extensions in the DHCP Release message which cannot be 1154 successfully processed by the server, a DHCP Reply message containing 1155 extensions with the appropriate error codes MUST be returned by the 1156 server. 1158 6.5. Sending DHCP Reconfigure Messages 1160 If a DHCP server needs to change the configuration associated to any 1161 of its clients, it constructs a DHCP Reconfigure message and sends it 1162 to each such client [7]. The Reconfigure MAY be sent to a multicast 1163 address chosen by the server and sent to each of its clients in an 1164 extension to a previous DHCP Reply message. 1166 7. DHCP Relay Considerations 1168 The DHCP protocol is constructed so that a relay does not have 1169 to maintain any state in order to facilitate DHCP client/server 1170 interactions. 1172 All relays MUST use the IP address of the interface from which the 1173 DHCP request was received as the source address for the IP header of 1174 that DHCP message. 1176 The main purpose of the DHCP Relay is to enable clients and servers 1177 to carry out DHCP protocol transactions. DHCP Solicit messages are 1178 issued by the relay when initiated by prospective DHCP clients. 1179 By default, the relay discovers local DHCP Servers by use of 1180 multicasting DHCP solicitations to the All-DHCP-Servers multicast 1181 address, but relays SHOULD allow this behavior to be configurable. 1182 The relay SHOULD NOT send such a multicast solicitation on the 1183 interface from which it received the solicitation from the client. 1185 7.1. DHCP Solicit and DHCP Advertise Message Processing 1187 Upon receiving a DHCP Solicit message from a prospective client, a 1188 relay, by default, forwards the message to all DHCP Servers at a site 1189 according to the following procedure: 1191 - copying the prospective client's solicitation message fields into 1192 the appropriate fields of the outgoing solicitation, 1194 - setting the 'A' bit, 1195 - copying the address of its interface from which the solicitation 1196 was received from the client into the DHCP Relay address field, 1197 and 1199 - finally, sending the resulting message to the All-DHCP-Servers 1200 multicast address, FF05:0:0:0:0:0:1:3, over all interfaces except 1201 that from which the client's solicitation was received. 1203 When the relay receives a DHCP advertisement with the 'A' bit set, it 1204 relays the advertisement to the client at the indicated link-local 1205 address by way of the interface indicated in the agent's address 1206 field. 1208 7.2. DHCP Request Message Processing 1210 When a relay receives a DHCP Request message, it MUST check that the 1211 message is received from a link-local address, that the link-local 1212 address matches the link-local address field in the Request message 1213 header, and that the agent address field of the message matches an 1214 IP address associated to the interface from which the DHCP Request 1215 message was received. If any of these checks fail, the Relay MUST 1216 silently discard the Request message. 1218 The relay MUST also check whether the 'S' bit is set in the message 1219 header. If not, the datagram is discarded, and and the relay SHOULD 1220 return a DHCP Reply message to the source address of the Request 1221 message with error code 18. 1223 If the received request message is acceptable, the relay then 1224 transmits the DHCP Request message to the address of the DHCP 1225 server found in the Server IP Address field of the received DHCP 1226 Request message. All of the fields of DHCP Request message header 1227 transmitted by the relay are copied over unchanged from the DHCP 1228 Request received from the client. Only the fields in the IP header 1229 will differ from the datagram received from the client, not the 1230 payload. If the Relay receives an ICMP error, the Relay SHOULD 1231 return a DHCP Reply message to the client address (which can be found 1232 in the payload of the ICMP message [2]), with error code 64. 1234 7.3. DHCP Reply Message Processing 1236 When the relay receives a DHCP Reply, it MUST check whether the 1237 message has the 'L' bit set. It MUST check whether the link-local 1238 address field contains an IP address that has prefix FE80::0000/64. 1239 If all the checks are satisfied, the relay MUST send a DHCP Reply 1240 message to the link-local address listed in the received Reply 1241 message. Only the fields in the IP header will differ from the 1242 datagram received from the server, not the payload. 1244 8. Retransmission and Configuration Variables 1246 When a DHCP client does not receive a DHCP Reply in response to a 1247 pending DHCP Request, the client MUST retransmit the identical DHCP 1248 Request, with the same transaction-ID, to the same server again 1249 until it can be reasonably sure that the DHCP server is unavailable 1250 and an alternative can be chosen. The DHCP Server assumes that the 1251 client has received the configuration information included with the 1252 extensions to the DHCP Reply message, and it is up to the client 1253 to continue to try for a reasonable amount of time to complete the 1254 transaction in order to make that assumption hold true. All the 1255 actions specified for DHCP Request in this section hold also for DHCP 1256 Release messages sent by the DHCP Client. 1258 Similarly, when a client sends a DHCP Request message in response to 1259 a Reconfigure message from the server, the client assumes that the 1260 DHCP server has received the Request. The server MUST retransmit the 1261 identical DHCP Reconfigure to the client for a reasonable amount of 1262 time, to try to elicit the Request message from the client, in order 1263 to make the best effort for that assumption to hold true. If no 1264 corresponding DHCP Request is ever received by the server, the server 1265 MAY erase or deallocate information as needed from the client's 1266 binding. 1268 These retransmissions occur using the following configuration 1269 variables for a DHCP implementation that MUST be configurable by a 1270 client or server: 1272 ADV_WAIT 1274 The amount of time a client waits to hear DHCP Advertisements 1275 after issuing a DHCP Solicit to the All-DHCP Agents multicast 1276 address. 1278 Default: 5 seconds 1280 REPLY_MSG_INITIAL_TIMEOUT 1282 The time in seconds that a DHCP client waits to receive a 1283 server's DHCP Reply before retransmitting a DHCP Request. 1285 Default: 2 seconds. 1287 REPLY_MSG_MIN_RETRANS 1289 The minimum number of DHCP Request transmissions that a DHCP 1290 client should retransmit, before aborting the request, possibly 1291 retrying the Request with another Server, and logging a DHCP 1292 System Error. 1294 Default: 10 retransmissions. 1296 REPLY_MSG_RETRANS_INTERVAL 1298 The time between successive retransmissions of DHCP Request 1299 messages. 1301 Default: 2 seconds. 1303 RECONF_MSG_INITIAL_TIMEOUT 1305 The time in seconds that a DHCP server waits to receive 1306 a client's DHCP Request before retransmitting its DHCP 1307 Reconfigure. 1309 Default: 2 seconds. 1311 RECONF_MSG_MIN_RETRANS 1313 The minimum number of DHCP Reconfigure messages that a DHCP 1314 server should retransmit, before assuming the the client is 1315 unavailable and that the server can proceed with the needed 1316 reconfiguration of that client's resources, and logging a DHCP 1317 System Error. 1319 Default: 10 retransmissions. 1321 RECONF_MSG_RETRANS_INTERVAL 1323 The least time between successive retransmissions of DHCP 1324 Reconfigure messages. 1326 Default: 2 seconds. 1328 RECONF_MSG_MIN_RESP 1330 The minimum amount of time before a client can respond to a 1331 DHCP Reconfigure message sent to a multicast address. 1333 Default: 2 second. 1335 RECONF_MSG_MAX_RESP 1337 The maximum amount of time before a client MUST respond to a 1338 DHCP Reconfigure message sent to a multicast address. 1340 Default: 10 seconds. 1342 MIN_SOLICIT_DELAY 1344 The maximum amount of time a prospective client is required 1345 to wait, after determining from a Router Discovery message 1346 that the client should perform stateful address configuration, 1347 before sending a DHCP Solicit to a DHCP Server. 1349 Default: 1 second 1351 MAX_SOLICIT_DELAY 1353 The maximum amount of time a prospective client is required 1354 to wait, after determining from a Router Discovery message 1355 that the client should perform stateful address configuration, 1356 before sending a DHCP Solicit to a DHCP Server. 1358 Default: 5 seconds 1360 XID_TIMEOUT 1362 The amount of time a DHCP server has to keep track of 1363 client transaction-IDs in order to make sure that client 1364 retransmissions using the same transaction-ID are idempotent. 1366 Default: 600 seconds 1368 Note that, if a client receives a DHCP message which fails 1369 authentication, it should continue to wait for another message which 1370 might be correctly authenticated just as if the failed message had 1371 never arrived; however, receiving such failed messages SHOULD be 1372 logged. 1374 9. Security Considerations 1376 DHCP clients and servers often have to authenticate the messages they 1377 exchange. For instance, a DHCP server may wish to be certain that a 1378 DHCP Request originated from the client identified by the fields included within the Request message 1380 header. Conversely, it is often essential for a DHCP client to 1381 be certain that the configuration parameters and addresses it has 1382 received were sent to it by an authoritative DHCP server. Similarly, 1383 a DHCP server should only accept a DHCP Release message which seems 1384 to be from one of its clients, if it has some assurance that the 1385 client actually did transmit the Release message. At the time of 1386 this writing, there is no generally accepted mechanism useful with 1387 DHCPv4 that can be extended for use with DHCPv6. 1389 The IPv6 Authentication Header can provide security for DHCPv6 1390 messages when both endpoints have a suitable IP address. However, 1391 a client often has only a link-local address, and such an address 1392 is not sufficient for a DHCP server which is off-link. In those 1393 circumstances the DHCP relay is involved, so that the DHCP message 1394 MUST have the relay's address in the IP destination address field, 1395 even though the client aims to deliver the message to the DHCP 1396 server. The DHCP Client-Server Authentication Extension [7] is 1397 intended to be used in these circumstances. 1399 10. Acknowledgements 1401 Thanks to the DHC Working Group for their time and input into the 1402 specification. A special thanks for the consistent input, ideas, 1403 and review by (in alphabetical order) Brian Carpenter, Ralph Droms, 1404 Thomas Narten, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson, 1405 and Phil Wells. 1407 Thanks to Steve Deering and Bob Hinden, who have consistently 1408 taken the time to discuss the more complex parts of the IPv6 1409 specifications. Thanks to Stuart Cheshire for his excellent minutes. 1411 A. Related Work in IPv6 1413 The related work in IPv6 that would best serve an implementor 1414 to study is the IPv6 Specification [3], the IPv6 Addressing 1415 Architecture [4], IPv6 Stateless Address Autoconfiguration [11], IPv6 1416 Neighbor Discovery Processing [6], and Dynamic Updates to DNS [12]. 1417 These specifications enable DHCP to build upon the IPv6 work to 1418 provide both robust stateful autoconfiguration and autoregistration 1419 of DNS Host Names. 1421 The IPv6 Specification provides the base architecture and design of 1422 IPv6. A key point for DHCP implementors to understand is that IPv6 1423 requires that every link in the internet have an MTU of 576 octets 1424 or greater (in IPv4 the requirement is 68 octets). This means that 1425 a UDP datagram of 536 octets will always pass through an internet 1426 (less 40 octets for the IPv6 header), as long as there are no IP 1427 options prior to the UDP header in the datagram. But, IPv6 does 1428 not support fragmentation at routers, so that fragmentation takes 1429 place end-to-end between hosts. If a DHCP implementation needs 1430 to send a datagram greater than 536 octets it can either fragment 1431 the UDP datagram in UDP or use Path MTU Discovery [5] to determine 1432 the size of the datagram that will traverse a network path. It is 1433 implementation dependent how this is accomplished in DHCP. 1435 The IPv6 Addressing Architecture specification [4] defines the 1436 address scope that can be used in an IPv6 implementation, and the 1437 various configuration architecture guidelines for network designers 1438 of the IPv6 address space. Two advantages of IPv6 are that multicast 1439 addressing is required, and nodes can create link-local addresses 1440 during initialization of the nodes environment. This means that a 1441 client immediately can configure an IP address at initialization 1442 for an interface, before communicating in any manner on the link. 1443 The client can then use a well-known multicast address to begin 1444 communications to discover neighbors on the link, or to send a DHCP 1445 Solicit and locate a DHCP server or relay. 1447 IPv6 Stateless Address Autoconfiguration [11] (addrconf) specifies 1448 procedures by which a node may autoconfigure addresses based on 1449 router advertisements [6], and the use of a validation lifetime to 1450 support renumbering of addresses on the Internet. In addition the 1451 protocol interaction by which a node begins stateless or stateful 1452 autoconfiguration is specified. DHCP is one vehicle to perform 1453 stateful autoconfiguration. Compatibility with addrconf is a design 1454 requirement of DHCP (see Section 3.1). 1456 IPv6 Neighbor Discovery [6] is the node discovery protocol in IPv6 1457 (replaces and enhances functions of ARP [8]). To truly understand 1458 IPv6 and addrconf it is strongly recommended that implementors 1459 understand IPv6 Neighbor Discovery. 1461 Dynamic Updates to DNS [12] is a specification that supports the 1462 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 1463 the dynamic updates to DNS to now integrate addresses and name space 1464 to not only support autoconfiguration, but also autoregistration in 1465 IPv6. 1467 B. Change History 1469 B.1. Changes from November 95 to February 96 Drafts 1471 Substituted use of client's link-local address for previous uses of 1472 client's interface token. 1474 Reorganized DHCP messages into Solicit/Advertise, Request/Reply, 1475 Release, and Reconfigure. 1477 Made message-specific formats instead of using the same DHCP header 1478 for each message. 1480 Eliminated retransmission message types. 1482 Server commits after receiving DHCP Request, and optimistically 1483 depends on client retransmissions as negative acknowledgement. 1485 Eliminated total-addrs. 1487 Eliminated all definitions and most fields related to allocating IPv6 1488 addresses (moved to the Extensions specification). 1490 Renamed "gateway address" to be "agent address". 1492 Added "Considerations" sections. 1494 B.2. Changes from February 96 to June 96 Drafts 1496 Added language referring to DHCP Client-Server Authentication 1497 extension. 1499 Moved the 'L' bit in the DHCP Reply Message format to save 32 bits. 1501 Added language for multicast Reconfigure message handling. 1503 Added initial capability for the DHCP Relay to multicast and obtain 1504 DHCP Server addresses. 1506 Added capability for Servers to add Extensions to their 1507 Advertisements. 1509 Added 'C' bit to DHCP Solicit for deallocating resources after client 1510 crash. 1512 Added DHCP Advertisement lifetimes for use by DHCP Relay agents that 1513 need to periodically update their list of DHCP servers. 1515 B.3. Changes from June 96 to August 96 Drafts 1517 Since the working group indicated that DHCP solicitation traffic 1518 was not considered to be a significant factor affecting network 1519 load, it was decided to modify the handling of solicitations so 1520 that DHCP relays, by default, multicast DHCP Solicit message to all 1521 DHCP servers at a site. This entailed a number of changes to the 1522 protocol, namely: 1524 - Adding fields to the DHCP Solicit and DHCP Advertise messages to 1525 contain the DHCP client's link-local addresses. 1527 - Adding the 'L' bit to the DHCP Solicit and DHCP Advertise 1528 messages to indicate whether the link-local address is present 1530 - Adding a 'P' bit to the DHCP Solicit message so that the client 1531 can allow the Relay to use its non-default behavior, which is to 1532 return cached DHCP Server addresses to the client in response to 1533 the client's DHCP Solicit message. 1535 - Specified a new multicast address (the All-DHCP-Servers address) 1536 for use by DHCP Relays when "relaying" client solicitations. 1538 Added a random backoff after reboot so that clients' solicitations 1539 don't immediately swamp DHCP Servers after power outages. 1541 Added new multicast addresses for All DHCP Servers and All DHCP 1542 Relays. 1544 B.4. Changes from August 96 to November 96 Drafts 1546 Clarified language regarding treatment by the DHCP server of DHCP 1547 Requests with the 'C' bit set. 1549 Specified that the UDP source port for DHCP messages is arbitrary. 1551 Added description for Appendix C. 1553 Changed must to MUST where appropriate. 1555 Changed definitions for client, server, and relay to be definitions 1556 for DHCP client, DHCP server, and DHCP relay. 1558 Changed definitions of DHCP multicast addresses to conform to recent 1559 IANA allocations. 1561 Corrected references to "leases", to more accurately refer to IPv6 1562 address lifetimes. 1564 B.5. Changes from November 96 to February 97 Drafts 1566 Clients can continue to use valid addresses, after restarts or any 1567 request triggered by a DHCP Reconfigure message, at least until it 1568 receives the DHCP Request from the server. 1570 All extensions sent in response to a single DHCP Request now must be 1571 part of the same DHCP Reply message. If some requested resources and 1572 configuration parameters are not available or cannot be allocated, 1573 each particular extension will either have the appropriate error code 1574 indicating the particular problem, or simply will not be included 1575 in the Reply. The extensions are to be modified to have fields for 1576 error codes whenever the server might have to indicate to the client 1577 a reason why the information requested in its extension was unable to 1578 be supplied. 1580 If a client receives a DHCP Reconfigure message which does not list 1581 some the client's configuration information, it can continue to 1582 assume that configuration information is valid. 1584 If a client reboots, it MUST set the 'C' bit and transmit a DHCP 1585 Request. If it doesn't have a valid server address, it MUST set the 1586 'C' bit in its DHCP Solicit message. 1588 Relays are no longer allowed to cache server addresses. The 1589 DHC working group decided to ice this plan until there was some 1590 determination that it might be useful. This caused the elimination 1591 of the 'P' bit, and quite a bit of discussion about the 'P' bit and 1592 DHCP server address caching was eliminated. The 'server count' field 1593 of the Advertisement and the lifetime field were eliminated, since 1594 relays never keep track of server addresses and clients have to 1595 solicit again whenever they lose their DHCP server. 1597 The working group decided to make programming as simple as possible, 1598 and therefore to include IP addresses in the appropriate DHCP 1599 message headers whenever those addresses would otherwise have to be 1600 discovered by manipulating the IP header itself. This caused many 1601 changes to the message header formats. The 'L' bit in the DHCP 1602 Solicit and DHCP Advertise messages is no longer necessary, because 1603 the link-local address of the client is always present in the header. 1605 Previously, there was language which required the client to match 1606 pending Requests with Reply messages with the same destination 1607 agent addresses. Those agent addresses were to be determined by 1608 inspecting the IP headers of the DHCP Reply messages. We deleted 1609 the requirement, in preference to loading possibly two more agent 1610 addresses in every DHCP Advertise message and DHCP Reply message. 1612 The DHCP Reconfigure message now has a transaction ID which the 1613 client copies into the corresponding DHCP Request, and then which 1614 subsequently the server copies again into the corresponding DHCP 1615 Reply message. 1617 Clients now use the DHCP server address found in the appropriate 1618 field of the DHCP Reconfigure message header instead of inspecting 1619 the IP header of the Reconfigure message. 1621 C. Comparison between DHCPv4 and DHCPv6 1623 This appendix is provided for readers who will find it useful to see 1624 a model and architecture comparison between DHCPv4 and DHCPv6. There 1625 are three key reasons for the differences: 1627 o IPv6 inherently supports a new model and architecture for 1628 communications and autoconfiguration of addresses. 1630 o DHCPv6 in its design was able to take advantage of the inherent 1631 benefits of IPv6. 1633 o New features were added to support the evolution and the 1634 existence of mature Internet users in the industry. 1636 IPv6 Architecture/Model Changes: 1638 o The link-local address permits a node to have an address 1639 immediately when the node boots, which means all clients have a 1640 source IP address at all times to locate a server or relay agent 1641 on the local link. 1643 o The need for bootp compatibility and broadcast flags are removed, 1644 which permitted a great deal of freedom in designing the new 1645 packet formats for the client and server interaction. 1647 o Multicast and the scoping methods in IPv6 permitted the design of 1648 discovery packets that would inherently define their range by the 1649 multicast address for the function required. 1651 o Stateful autoconfiguration has to coexist and integrate with 1652 stateless autoconfiguration supporting Duplicate Address 1653 Detection and the two IPv6 lifetimes, to facilitate the dynamic 1654 renumbering of addresses and the management of those addresses. 1656 o Multiple addresses per interface are inherently supported in 1657 IPv6. 1659 o Most DHCPv4 options are unnecessary now because the configuration 1660 parameters are either obtained through IPv6 Neighbor Discovery or 1661 the Service Location protocol. 1663 DHCPv6 Architecture/Model Changes: 1665 o The message type is the first byte in the packet. 1667 o IPv6 Address allocations are now handled in a message extension 1668 as opposed to the main header. 1670 o Client/Server bindings are now mandatory and take advantage of 1671 the client's link-local address to always permit communications 1672 either directly from an on-link server, or from a remote server 1673 through an on-link relay-agent. 1675 o Servers are now discovered by a client solicit and server or 1676 relay-agent advertisement model. 1678 o The client will know if the server is on-link or off-link. 1680 o The client after a solicit will be returned the addresses of 1681 available servers either from an on-link server or from an 1682 on-link relay-agent as agents providing the advertisements. 1684 o The on-link relay-agent will obtain the location of remote server 1685 addresses from system configuration or by the use of a site wide 1686 DHCPv6 Multicast packet. 1688 o The protocol is optimized and removes the use of ACKs and NAKs 1689 once the client and server set-up is complete. 1691 o The server assumes the client receives its responses unless it 1692 receives a retransmission of the same client request. This 1693 permits recovery in the case where the network has faulted. 1695 o DHCPINFORM is inherent in the new packet design; a client can 1696 request configuration parameters other than IPv6 addresses in the 1697 optional extension headers. 1699 o Clients MUST listen to their UDP port for the new Reconfigure 1700 message type from servers, unless they join the appropriate 1701 multicast group as specified by the DHCP server. 1703 o Dynamic Updates to DNS are supported in the IPv6 Address 1704 extension. 1706 o New extensions have been defined. 1708 New Internet User Features: 1710 o Configuration of Dynamic Updates to DNS to support multiple 1711 implementation policy requirements. 1713 o Configuration of what policy is enforced when addresses are 1714 deprecated for dynamic renumbering can be implemented. 1716 o Configuration of how relay-agents locate remote servers for a 1717 link can be implemented. 1719 o An Authentication extension has been added. 1721 o Configuration of additional addresses for server applications can 1722 be requested by a client in an implementation. 1724 o Reclaiming addresses allocated with very long lifetimes can be 1725 implemented using the Reconfigure message type. 1727 o Configuration of tightly coupled integration between stateless 1728 and stateful address autoconfiguration can be implemented. 1730 References 1732 [1] S. Bradner and A. Mankin. The Recommendation for the IP Next 1733 Generation Protocol. RFC 1752, January 1995. 1735 [2] A. Conta and S. Deering. Internet Control Message Protocol 1736 (ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885, 1737 December 1995. 1739 [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1740 Specification. RFC 1883, December 1995. 1742 [4] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 1743 RFC 1884, December 1995. 1745 [5] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP 1746 version 6. RFC 1981, August 1996. 1748 [6] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 1749 IP version 6 (IPv6). RFC 1970, August 1996. 1751 [7] C. Perkins. Extensions to DHCPv6, February 1997. 1752 draft-ietf-dhc-dhcpv6ext-05.txt, work in progress. 1754 [8] David C. Plummer. An Ethernet Address Resolution Protocol: 1755 Or Converting Network Protocol Addresses to 48.bit Ethernet 1756 Addresses for Transmission on Ethernet Hardware. RFC 826, 1757 November 1982. 1759 [9] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 1761 [10] J. B. Postel, Editor. Internet Protocol. RFC 791, September 1762 1981. 1764 [11] S. Thomson and T. Narten. IPv6 stateless address 1765 autoconfiguration. RFC 1971, August 1996. 1767 [12] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. 1768 Dynamic Updates in the Domain Name System (DNS). 1769 draft-ietf-dnsind-dynDNS-11.txt, November 1996. (work 1770 in progress). 1772 Chair's Address 1774 The working group can be contacted via the current chair: 1776 Ralph Droms 1777 Computer Science Department 1778 323 Dana Engineering 1779 Bucknell University 1780 Lewisburg, PA 17837 1782 Phone: (717) 524-1145 1783 E-mail: droms@bucknell.edu 1785 Author's Address 1787 Questions about this memo can be directed to: 1789 Jim Bound Charles Perkins 1790 Digital Equipment Corporation Netcentricity Group 1791 110 Spitbrook Road, ZKO3-3/U14 Sun Microsystems, Inc. 1792 Nashua, NH 03062 2550 Garcia Avenue. 1793 Mountain View, CA 94043 1794 Phone: +1-603-881-0400 +1-415-336-7153 1795 Fax: +1-415-336-0673 1796 E-mail: bound@zk3.dec.com charles.perkins@corp.sun.com