idnits 2.17.1 draft-ietf-dhc-dhcpv6-08.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-26) 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 is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == 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...' (143 more instances...) -- The draft header indicates that this document obsoletes draft-ietf-dhc-dhcpv6-07.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- -- No information found for rfcdraft-ietf-dhc-dhcpv6-07.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 (22 November 1996) is 10017 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) -- No information found for draft-ietf-dhc-dhcpv6ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-07) exists of draft-ietf-addrconf-ipv6-auto-06 == Outdated reference: A later version (-10) exists of draft-ietf-dnsind-dynDNS-06 Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force J. Bound 2 INTERNET DRAFT Digital Equipment Corp. 3 DHC Working Group C. Perkins 4 Obsoletes: draft-ietf-dhc-dhcpv6-07.txt IBM Research 5 22 November 1996 7 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 8 draft-ietf-dhc-dhcpv6-08.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 . . . . . . . . . . . . . . 15 71 5.2. Receiving DHCP Advertise Messages . . . . . . . . . . . . 16 72 5.3. Sending DHCP Request Messages . . . . . . . . . . . . . . 16 73 5.4. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 18 74 5.5. Sending DHCP Release Messages . . . . . . . . . . . . . . 18 75 5.6. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 19 77 6. DHCP Server Considerations 19 78 6.1. Receiving DHCP Solicit Messages . . . . . . . . . . . . . 20 79 6.2. Sending DHCP Advertise Messages . . . . . . . . . . . . . 20 80 6.3. DHCP Request and Reply Messages . . . . . . . . . . . . . 21 81 6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 22 82 6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . . 23 84 7. DHCP Relay Considerations 23 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 . . . . . . . . . . . . . . 26 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 103 C. Comparison between DHCPv4 and DHCPv6 33 105 Chair's Address 37 107 Author's Address 37 108 1. Introduction 110 The Dynamic Host Configuration Protocol (DHCPv6, or in this 111 document usually DHCP) provides configuration parameters to Internet 112 nodes. DHCP consists of a protocol for delivering node-specific 113 configuration parameters from a DHCP server to a client, and a 114 mechanism for allocation of network addresses and other related 115 parameters to IPv6 [3] nodes. 117 DHCP is built on a client-server model, where designated DHCP 118 servers allocate network addresses and automatically deliver 119 configuration parameters to dynamically configurable clients. 120 Throughout the remainder of this document, the term "server" 121 refers to a node providing initialization parameters by way of the 122 DHCP protocol, and the term "client" refers to a node requesting 123 initialization parameters from a DHCP server. DHCP servers maintain 124 state for their clients, in contrast to IPv6 Stateless Address 125 Autoconfiguration [11], where IPv6 nodes should get the same results 126 if they repeat the autoconfiguration procedure multiple times. 128 DHCPv6 uses Request and Reply messages to support a client/server 129 processing model whereby both client and server are assured that 130 requested configuration parameters have been received and accepted 131 by the client. DHCP supports optional configuration parameters and 132 processing for nodes through extensions described in its companion 133 document ``Extensions for the Dynamic Host Configuration Protocol for 134 IPv6'' [7]. 136 The IPv6 Addressing Architecture [4] and IPv6 Stateless Address 137 Autoconfiguration specifications provide new features not available 138 in IP version 4 (IPv4) [10], which are used to simplify and 139 generalize the operation of DHCP clients. 141 Section 2 provides definitions for terminology used throughout 142 this document. Section 3 provides an overview of the protocol 143 design model that guided the design choices in the specification; 144 section 3.2 briefly describes the protocol messages and their 145 semantics. Section 4 provides the message formats and field 146 definitions used for each message. Sections 5, 6, and 7 specify 147 how clients, servers, and relays interact. Appendix A summarizes 148 related work in IPv6 that will provide helpful context; it is not 149 part of this specification, but included for informational purposes. 150 Appendix B itemizes changes between different versions of this 151 protocol specification. Appendix C discusses the differences between 152 DHCPv4 and DHCPv6. 154 2. Terminology and Definitions 156 Relevant terminology from the IPv6 Protocol, IPv6 Addressing 157 Architecture, and IPv6 Stateless Address Autoconfiguration will be 158 provided, and then the DHCPv6 terminology. 160 2.1. IPv6 Terminology 162 IP Internet Protocol Version 6 (IPv6). The terms IPv4 and 163 IPv6 are used only in contexts where necessary to avoid 164 ambiguity. 166 node A device that implements IP. 168 router A node that forwards IP datagrams not explicitly 169 addressed to itself. 171 host Any node that is not a router. 173 link A communication facility or medium over which nodes 174 can communicate at the link layer, i.e., the layer 175 immediately below IP. Examples are Ethernet (simple or 176 bridged); Token Ring; PPP links, X.25, Frame Relay, or 177 ATM networks; and internet (or higher) layer "tunnels", 178 such as tunnels over IPv4 or IPv6 itself. 180 link-layer identifier 181 a link-layer identifier for an interface. Examples 182 include IEEE 802 addresses for Ethernet or Token Ring 183 network interfaces, and E.164 addresses for ISDN links. 185 link-local address 186 An IP address having link-only scope that can be used 187 to reach neighboring nodes attached to the same link. 188 All interfaces have a link-local address. 190 neighbors 191 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 219 configure its network environment and enable 220 communication on a 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 237 server 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 and used 242 to match a DHCP Reply to a pending DHCP Request. 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 from a client to one 345 or more 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 355 a server, when the client knows the IP unicast address of a 356 server, to request configuration parameters on a network. 358 04 DHCP Reply 360 The DHCP Reply is an IP unicast message sent by a server to 361 respond to a client's DHCP Request. Extensions [7] to the DHCP 362 Reply describe the resources that the DHCP Server has committed 363 and allocated to the client, and may contain other information 364 for use by the client. 366 05 DHCP Release 368 The DHCP Release message is used by a DHCP client to inform 369 the server that the client is releasing a particular address, 370 or set of addresses or resources, so that the server may 371 subsequently mark the addresses or resources as invalid in the 372 server's binding for the client. 374 06 DHCP Reconfigure 376 The DHCP Reconfigure message is used by a DHCP server to inform 377 its client that the server has new configuration information of 378 importance to the client. The client is expected to initiate a 379 new Request/Reply transaction. 381 3.3. Request/Response Processing Model 383 The request/response processing for DHCPv6 is transaction based 384 and uses a best-effort set of messages to guarantee a completed 385 transaction. 387 Transactions are usually started by a client with a DHCP Request, 388 which may be issued after the client knows the server's address. 389 The response (DHCP Reply) is from the server (possibly via a DHCP 390 Relay). At this point in the flow all data has been transmitted 391 and, hopefully, received. To provide a method of recovery if either 392 the client or server do not receive the messages to complete the 393 transaction, the client is required to retransmit any DHCP Request 394 message until it elicits the corresponding DHCP Reply or Replies, 395 or until it can be reasonably certain that the desired DHCP Server 396 is unavailable. The timeout and retransmission guidelines and 397 configuration variables are discussed in Section 8. 399 All DHCP Agents (Servers and Relays) MUST join the All-DHCP-Agents 400 multicast group at the well-known multicast address 401 FF02:0:0:0:0:0:1:2. All DHCP Servers MUST, in addition, join 402 the All-DHCP-Servers multicast group at the well-known multicast 403 address FF05:0:0:0:0:0:1:3. All DHCP Relays MUST, on other 404 hand, join in addition the ALL-DHCP-Relays multicast group at the 405 well-known multicast address FF05:0:0:0:0:0:1:4. 407 DHCP uses the UDP [9] protocol to communicate between clients 408 and servers. UDP is not reliable, but DHCP has to provide some 409 reliability between clients and servers. If a response is not 410 received after transmission of a DHCP message, the message MUST be 411 retransmitted according to the rules specified in Section 8. The 412 DHCP Relays address will be used eventually when DHCP Servers wish to 413 automatically configure all site DHCP Relays. 415 A client MUST transmit all messages over UDP using port 547 as the 416 destination port. A client MUST receive all messages from UDP port 417 546. 419 A DHCP Agent MUST transmit all messages to clients over UDP using 420 port 546 as the destination port. A DHCP Agent MUST receive all 421 messages over UDP using port 547. The source port for DHCP messages 422 is arbitrary. 424 4. DHCP Message Formats and Field Definitions 426 All fields in DHCP messages MUST be initialized to binary zeroes by 427 both the client and server unless otherwise noted. DHCP message 428 types not defined here (msg-types 0 and 7-255) are reserved. 430 4.1. DHCP Solicit Message Format 432 A DHCP client (or DHCP relay on behalf of a client) transmits a DHCP 433 Solicit message to obtain one or more DHCP server addresses. 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | msg-type |C|L|A|P| RESERVED | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | link-local address (if present) | 441 | (16 octets) | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | DHCP relay address (if present) | 444 | (16 octets) | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 msg-type 1 449 C If set, the client requests that all servers receiving 450 the message deallocate the resources associated with 451 the client. 453 L If set, the link-local address is present 455 A If set, the relay's address is present 457 P If set, the client is willing to accept previously 458 cached server addresses from relays 460 RESERVED 0 462 If a DHCP client does not know any DHCP Agent address, or wants 463 to locate a new server to receive configuration parameters, the 464 client SHOULD use, as the destination IP address, the 465 All-DHCP-Agent multicast address FF02:0:0:0:0:0:1:2. If the 466 'P' bit is not set, any DHCP Relay receiving the solicitation MUST 467 forward it to the All-DHCP-Servers multicast address, to instruct 468 DHCP Servers to send their advertisements to the prospective client. 469 In that case, the relay MUST copy the client's link-local address 470 into the message, set the 'L' bit, copy the address of its interface 471 from which the client's solicitation was received into the agent's 472 address field, and set the 'A' bit. 474 4.2. DHCP Advertise Message Format 476 A DHCP agent sends a DHCP Advertise message to inform a prospective 477 client about the IP address of a DHCP Agent to which a DHCP Request 478 message may be sent. When the client and server are on different 479 links, the server sends the advertisement back through the DHCP Relay 480 whence the solicitation came. Relays MAY cache DHCP server addresses 481 gleaned from DHCP advertisements with nonzero lifetimes, in order to 482 satisfy possible future client solicitations. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | msg-type |S|L| rsvd | server-count | lifetime | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | agent address | 490 | (16 octets) | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | link-local address (if present) | 493 | (16 octets) | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | server addresses | 496 | (16 octets each) | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | extensions (variable number and length) ... 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 msg-type 2 503 S If set, the agent address is also a server address. 505 L If set, the link-local address is present 507 rsvd 0 509 server-count 510 The number of addresses listed in the server 511 addresses field. 513 lifetime Lifetime for the server advertisement, in units of 514 4096 seconds. If the destination address of the 515 DHCP Advertisement is a link-local address, then the 516 Lifetime MUST be 0. A value of 0 means that this 517 field is not used. 519 agent address 520 The IP address of a DHCP Agent interface on the same 521 link as the client. 523 server addresses 524 The IP address(es) of the DHCP server(s) 526 extensions See [7]. 528 Suppose that a DHCP server on the same link as a client issues the 529 DHCP Advertise in response to a DHCP Solicit message sent to the 530 All-DHCP-Agents multicast address. Then the agent address will be 531 the IP address of one of the server's interfaces, the 'S' bit will be 532 set, the agent address will be an address of the server, and there 533 may be zero server addresses sent in the DHCP Advertise message. It 534 is an error for server-count to be zero if the 'S' bit is not set. 536 If the DHCP Server is sending the advertisement in response to a 537 solicitation with the client's link-local address present, the server 538 MUST copy the link-local address into the advertisement. 540 The source IP address of the IP header of any DHCP Advertise message 541 MUST have sufficient scope to be reachable by the DHCP Client. In 542 particular, the source address of any DHCP Advertise message sent 543 by a DHCP relay MUST NOT be a link-local address. In situations 544 where there are no routers sending Router Advertisements, then a DHCP 545 Server MUST be configured on the same link as prospective clients. 547 4.3. DHCP Request Message Format 549 In order to request parameters from a DHCP server, a client sends a 550 DHCP Request message, and MAY append the appropriate extensions [7]. 551 If the client does not know any DHCP server address, it MUST first 552 obtain a server address by multicasting a DHCP Solicit message (see 553 Section 4.1). If the client does not have a valid IP address of 554 sufficient scope for the DHCP server to communicate with the client, 555 the client MUST use the unicast IP address of a local DHCP relay 556 as the destination IP address. Otherwise, the client MAY omit the 557 server address in the DHCP Request message; in this case, the client 558 MUST send the DHCP Request message directly to the server, using the 559 server address as the IP destination address in the IP header. 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | msg-type |S|C| reserved | transaction-ID | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | (if present) | 567 | server address (16 octets) | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | agent address | 570 | (16 octets) | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | link-local address | 573 | (16 octets) | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | extensions (variable number and length) .... 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 msg-type 3 580 S If set, the server address is present 582 C If set, the client requests the server to clear all 583 existing resources and bindings currently associated 584 with the client, deallocating as needed. 586 reserved 0 588 transaction-ID 589 A monotonically increasing number which the client asks 590 the server to copy into its DHCP Reply, so that the 591 client can match Replies with pending Requests. 593 server address 594 If present, the IP address of the DHCP server which 595 should receive the client's DHCP Request message. 597 agent address 598 The IP address of a relay or server interface, copied 599 from a DHCP Advertisement message. 601 link-local address 602 The IP link-local address of the client interface from 603 which the client issued the DHCP Request message 605 extensions See [7]. 607 4.4. DHCP Reply Message Format 609 The server sends one or more DHCP Reply message in response to every 610 DHCP Request received. If the request comes with the 'S' bit set, 611 the client could not directly send the Request to the server and had 612 to use a neighboring relay agent. In that case, the server sends 613 back the DHCP Reply with the 'L' bit set, and the DHCP Reply is 614 addressed to the agent address found in the DHCP Request message. If 615 the 'L' bit is set, then the client's link-local address will also be 616 present. 618 0 1 2 3 619 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 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | msg-type |L| error code | transaction-ID | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | (if present) | 624 | link-local address (16 octets) | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | extensions (variable number and length) .... 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 msg-type 4 631 L If set, the link-local address is present 633 error code 634 One of the following values: 636 0 Success 637 16 Failure, reason unspecified 638 17 Authentication failed or nonexistent 639 18 Poorly formed request 640 19 Resources unavailable 641 20 Client record unavailable 642 21 Invalid source address in Release 643 22 Unable to honor required extension parameters 644 64 Server unreachable (ICMP error) 646 transaction-ID 647 Copied from the transaction-ID which the DHCP server 648 received in the DHCP Request, to help the client match 649 this reply with an outstanding Request. 651 link-local address 652 If present, the IP address of the client interface 653 which issued the corresponding DHCP Request message. 655 extensions 656 See [7]. 658 If the 'L' bit is set, and thus the link-local address is present in 659 the Reply message, the Reply is sent by the server to the relay's 660 address which was specified as the agent address in the DHCP Request 661 message, and the relay uses the link-local address to deliver the 662 Reply message to the client. Error code 22 MUST be sent only in the 663 case that the Server could otherwise honor the requested resource, 664 if the client had not made the parameter values (included in the 665 relevant Extension requesting the resource) required for the server 666 to obey. If the length in the UDP header preceding the DHCP message 667 does not match that which is expected in the DHCP Request, error code 668 18 MUST be sent. 670 4.5. DHCP Release Message Format 672 The DHCP Release message is sent without the assistance of any DHCP 673 relay. When a client sends a Release message, it is assumed to 674 have a valid IP address with sufficient scope to allow access to 675 the target server. Only the parameters which are specified in the 676 extensions are released. The DHCP server acknowledges the Release 677 message by sending a DHCP Reply (Section 4.4, 6.3). 679 0 1 2 3 680 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 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | msg-type |D| msg-flags | transaction-ID | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | agent address | 685 | (16 octets) | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | link-local address | 688 | (16 octets) | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | extensions (variable number and length) .... 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 msg-type 5 695 D If the 'D' ("Direct") flag is set, the client instructs 696 the server to send the DHCP Reply directly back to the 697 client, instead of using the given agent address and 698 link-local address to relay the Reply message. 700 msg-flags 0 701 transaction-ID 702 A monotonically increasing number which the client asks 703 the server to use in its DHCP Reply, to help the client 704 match Replies with outstanding Releases. 706 agent address 707 The IP address of the agent interface to which the 708 client issued the DHCP Request message 710 link-local address 711 The IP link-local address of the client interface from 712 which the the client issued the DHCP Request message 714 extensions 715 See [7] 717 Suppose that the client knows that the address it uses as the source 718 IP address in its IP header will still be valid after the server 719 performs the operations requested in the extensions to the DHCP 720 Release message. In that case, and only then, the client SHOULD then 721 specify the 'D' flag. When the 'D' flag is set, the server MUST send 722 the DHCP Reply back to the client's address as shown in the source 723 address of the IP header of the Release message. Otherwise, when 724 the 'D' bit is not set, the server MUST use the agent address and 725 link-local address in its DHCP Reply message to forward the Reply 726 message back to the releasing client. 728 4.6. DHCP Reconfigure Message Format 730 The DHCP Reconfigure message is sent without the assistance of any 731 DHCP relay. When a server sends a Reconfigure message, the client 732 to which it is sent is assumed to have a valid IP address with 733 sufficient scope to be accessible by the server. Only the parameters 734 which are specified in the extensions to the Reconfigure message need 735 be requested again by the client. 737 The client SHOULD listen at UDP port 546 to receive possible 738 DHCP Reconfigure messages, except in cases where the client knows 739 that no Reconfigure message will ever be issued. In some cases, 740 the IP address at which the client listens will be a multicast 741 address sent to the client by the DHCP server in an extension to an 742 earlier DHCP Reply message. If the client does not listen for DHCP 743 Reconfigure messages, it is possible that the client will not receive 744 notification that its DHCP server has deallocated the client's 745 The client MAY receive an update to the prefix for their addresses 746 and then MUST use that prefix for their addreses. 748 IP address and/or other resources allocated to the client. See 749 discussion in 6.5. 751 0 1 2 3 752 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 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | msg-type | msg-flags | reserved | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | extensions (variable number and length) .... 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 msg-type 6 761 msg-flags 0 763 reserved 0 765 extensions See [7] 767 5. DHCP Client Considerations 769 A DHCP client MUST silently discard any DHCP Solicit, DHCP Request, 770 or DHCP Release message it receives. 772 A DHCP client MAY retain its configured parameters and resources 773 across client system reboots and DHCP client program restarts. 774 However, in these circumstances a DHCP client MUST also formulate a 775 DHCP Request message to verify that its configured parameters and 776 resources are still valid. This Request message MUST have the 'C' 777 bit set, to clean up stale client binding information at the server 778 which may no longer be in use by the client; stale information is 779 that which the client does not include in extensions to such request 780 messages. 782 5.1. Sending DHCP Solicit Messages 784 If a node wishes to become a new DHCP client, it MUST first 785 locate a DHCP Server. The client does this by multicasting a DHCP 786 Solicit message to the All-DHCP-Agents address multicast address 787 FF02:0:0:0:0:0:1:2, setting the Hop Limit == 1. If there are no 788 DHCP servers on the same link as the node, then a DHCP Relay MUST be 789 present for further handling of the solicitation. If the node is 790 willing to accept cached server addresses from the DHCP Relay instead 791 of requesting the Relay to multicast its solicitation over all site 792 networks, then the node MAY set the 'P' bit in its solicitation. 794 By setting the 'C' bit in the solicitation, a DHCP client requests 795 that all the DHCP Servers that receive the solicitation should clean 796 up their stale client records that match its link-local address. 798 If a client sends a DHCP Solicit message after it reboots, the 799 solicitation MUST be delayed after reception of the first Router 800 Advertisement [6] message, by at least some random amount of time 801 between zero and MAX_SOLICIT_DELAY seconds. This delay is intended 802 to help stagger requests to DHCP Servers (and avoid link-layer 803 collisions) after a power outage causes many nodes to reboot all at 804 once. Each subsequent DHCP Solicit message that is issued before 805 receiving an advertisement MUST be delayed by twice the amount by 806 which the previous DHCP Solicit message was delayed. 808 5.2. Receiving DHCP Advertise Messages 810 When a DHCP client receives a DHCP Advertise message, it may 811 formulate a DHCP Request message to receive configuration information 812 and resources from the DHCP servers listed in the advertisement. If 813 the Advertise message has zero server addresses and does not have the 814 'S' bit set, the client MUST silently discard the message. If the 815 server's address is shown as a Multicast address, the advertisement 816 MUST be silently discarded. 818 If the 'S' bit is set, the DHCP Advertise message was transmitted 819 by a DHCP server on the same link as the client. In this case, the 820 client MUST use the agent address as the destination address for any 821 future DHCP message transactions sent to that server. 823 Advertisements may have extensions; this might allow the DHCP client 824 to select the configuration that best meets its needs from among 825 several prospective servers. 827 5.3. Sending DHCP Request Messages 829 A DHCP client obtains configuration information from a DHCP server by 830 sending a DHCP Request message. The client MUST know the server's 831 address before sending the Request message, and client MUST have 832 acquired a (possibly different) DHCP agent address. If the client 833 and server are on the same link, the agent address used by the client 834 MUST be the same as the DHCP server's address. A DHCP Request 835 message MUST NOT be sent to any multicast address, since otherwise 836 multiple DHCP agents would possibly allocate resources to the client 837 in response to the same Request, and the client would have no way to 838 know which servers had made the allocations, if any datagrams were 839 lost due to collisions, etc. 841 If the client has no valid IP address of sufficient scope, and the 842 DHCP server is off-link, then the client MUST include the server 843 address in the appropriate field of the DHCP Request message and set 844 the 'S' bit. In this case, the IP destination address of the Request 845 message will be a DHCP relay address. 847 Otherwise, if the client already has a valid IP address and knows 848 the IP address of a candidate IP server, it SHOULD send the Request 849 message directly to the DHCP server without requiring the services of 850 the local DHCP relay. 852 If a client wishes to instruct a DHCP server to deallocate all 853 unknown previous resources, configuration information, and bindings 854 associated with its agent address and link-local address, it sets the 855 'C' bit in the DHCP Request. A client MAY send in such a Request 856 even when it is no longer attached to the link on which the relay 857 address is attached. 859 In any case, after choosing a transaction-ID which is numerically 860 greater than its previous transaction-ID, and filling in the 861 appropriate fields of the DHCP Request message, the client MAY append 862 various DHCP Extensions to the message. These extensions denote 863 specific requests by the client; for example, a client may request 864 a particular IP address, or request that the server send an update 865 containing the client's new IP address to a Domain Name Server. When 866 all desired extensions have been applied, the DHCP client unicasts 867 the DHCP Request to the appropriate DHCP Agent. 869 For each pending DHCP Request message, a client MUST maintain the 870 following information: 872 - The transaction-ID of the request message, 873 - The server address, 874 - The agent address, 875 - The time at which the next retransmission will be attempted, and 876 - All extensions appended to the request message. 878 If a client does not receive all the relevant DHCP Reply messages 879 (Section 5.4) with the same transaction-ID as a pending DHCP Request 880 message within REPLY_MSG_INITIAL_TIMEOUT seconds, or if the received 881 DHCP Request messages contain DHCP Authentication extensions which 882 fail to provide the correct authentication information, the client 883 MUST retransmit the Request with the same transaction-ID and continue 884 to retransmit according to the rules in Section 8. 886 5.4. Receiving DHCP Reply Messages 888 When a client receives a DHCP Reply message, it MUST check whether 889 the transaction-ID in the Reply message matches the transaction-ID 890 of a pending DHCP Request message. If no match is found, the Reply 891 message MUST be silently discarded. If the transaction-ID matches 892 that of a pending Request, and the 'L' bit is set, but the source 893 address in the IP header does not match the pending agent address, 894 the client MUST discard the message, and SHOULD log the event. 895 Likewise, if the transaction-ID matches that of a pending Request, 896 and the 'L' bit is not set, but the source address in the IP header 897 does not match the pending server address, the client MUST discard 898 the message, and SHOULD log the event. 900 If the Reply message is acceptable, the client processes each 901 Extension [7], extracting the relevant configuration information 902 and parameters for its network operation. The Error Code found in 903 the Reply message applies to all extensions found in the Reply. If 904 all expected extensions are not found in the same Reply message, 905 then they are likely to be located in another Reply, possibly 906 with a different Error Code, but with the same transaction-ID. The 907 DHCP Client MUST continue processing DHCP Reply messages until all 908 requested extensions are accounted for. If some requested extensions 909 are not accounted for within DHCP Reply messages sent by the server, 910 the client MUST reissue the entire DHCP Request again, with all 911 extensions, and the same transaction-ID. 913 Some configuration information extracted from the extensions to the 914 DHCP Reply message MUST remain associated with the DHCP server that 915 sent the message. The particular extensions that require this extra 916 measure of association with the server are indicated in the DHCP 917 Extensions document [7]. These "resource-server" associations are 918 used when sending DHCP Release messages. 920 5.5. Sending DHCP Release Messages 922 If a DHCP client determines that some of its network configuration 923 parameters are no longer needed, it SHOULD enable the DHCP server to 924 release allocated resources which are no longer in use by sending a 925 DHCP Release message to the server. The client consults its list 926 of resource-server associations in order to determine which server 927 should receive the desired Release message. If a client wishes to 928 ask the server to release all information and resources relevant to 929 the client, the client specifies no extensions; this is preferable 930 to sending a DHCP Request message with the 'C' bit set and no 931 extensions. 933 Suppose a client wishes to release resources which were granted to 934 it on another link. In that case, the client MUST instruct the 935 server to send the DHCP Reply directly back to the client, instead 936 of performing the default processing of sending the DHCP Reply back 937 through the agent-address included in the DHCP Release. This is done 938 by setting the 'D' bit in the DHCP Release message. Note that it is 939 an error (Error Code 21) to include within the DHCP Release message 940 both the 'D' bit and an IP address extension which has the IP address 941 used as the source address of the datagram containing DHCP Release 942 message. 944 5.6. Receiving DHCP Reconfigure Messages 946 If a DHCP client receives a DHCP Reconfigure message, it is a request 947 for the client to initiate a new DHCP Request/Reply transaction with 948 the server which sent the Reconfigure message. The server sending 949 the Reconfigure message MAY be different than the server which sent a 950 DHCP Reply message containing the original configuration information. 952 For each Extension which is present in the Reconfigure message, the 953 client appends a matching Extension to its DHCP Request message 954 which it formulates to send to the DHCP server which is found in 955 the IP source address of the message. The client also selects a 956 transaction-ID numerically greater than its last choice and inserts 957 it into the Request message. From then on, processing is the same as 958 specified above in Section 5.3. 960 Note that a client may be requested by its server to join a multicast 961 group for the purpose of receiving DHCP Reconfigure messages. When a 962 Reconfigure message is delivered to the client by way of the selected 963 multicast address, the client MUST delay its further response for 964 a random amount of time uniformly distributed within the interval 965 between RECONF_MSG_MIN_RESP and RECONF_MSG_MAX_RESP seconds. This 966 will minimize the likelihood that the server will be bombarded with 967 DHCP Request messages all at the same time. 969 6. DHCP Server Considerations 971 A server maintains a collection of client records, called 972 ``bindings''. Each binding is uniquely identifiable by the ordered 973 pair , since the link-local 974 address is guaranteed to be unique [11] on the link identified 975 by the agent address. An implementation MUST support bindings 976 consisting of at least a client's link-local address, agent address, 977 preferred lifetime and valid lifetime [11] for each client address, 978 and the transaction-ID. A client binding may be used to store any 979 other information, resources, and configuration data which will be 980 associated with the client. A DHCP server MUST retain its clients' 981 bindings across server reboots, and, whenever possible, a DHCP client 982 should be assigned the same configuration parameters despite server 983 system reboots and DHCP server program restarts. A DHCP server MUST 984 support fixed or permanent allocation of configuration parameters to 985 specific clients. 987 Servers on the same link as the client MUST use the source address 988 in the IP header from the client as the destination address in DHCP 989 response messages sent by the server to the client. 991 A server MUST ignore any DHCP Advertise, DHCP Reply, or DHCP 992 Reconfigure message it receives. 994 6.1. Receiving DHCP Solicit Messages 996 If the DHCP Solicit message was received at the All-DHCP-Servers 997 multicast address, the DHCP Server MUST check to make sure that the 998 source address is not a link-local address. In that case, if the 999 source address is a link-local address, the server MUST silently 1000 discard the packet. If any solicitation has the 'L' bit set without 1001 the 'A' bit also being set, the server MUST discard the packet, and 1002 SHOULD log the error, in case the packet was sent by a malfunctioning 1003 relay agent. If the UDP length disagrees with the length determined 1004 by the format of the DHCP Solicit message, the server MUST drop the 1005 packet and SHOULD log the error. 1007 6.2. Sending DHCP Advertise Messages 1009 Upon receiving and verifying the correctness of a DHCP Solicit 1010 message, a server constructs a DHCP Advertise message and transmits 1011 it on the same link as the solicitation was received from. The 1012 destination address of the advertisement MUST be the source address 1013 of the solicitation. The DHCP server MUST use an IP address of the 1014 interface on which it received the Solicit message as the source 1015 address field of the IP header of the message. 1017 The DHCP server MAY append extensions to the Advertisement, in order 1018 to offer the soliciting node the best possible information about 1019 the services and resources which the server may be able to make 1020 available. 1022 6.3. DHCP Request and Reply Messages 1024 The DHCP server MUST check to ensure that the client's link-local 1025 address field of the Request message contains an address which could 1026 be a valid link-local address. If not, the message MUST be silently 1027 discarded. Otherwise, it checks for the presence of the 'S' bit. If 1028 the 'S' bit is set, the server MUST check that the server address 1029 matches the destination IP address at which the Request message was 1030 received by the server. If the server address does not match, the 1031 Request message MUST be silently discarded. 1033 If the received agent address and link-local address do not 1034 correspond to any binding known to the server, then the server MAY 1035 create a new binding for the previously unknown client; otherwise, it 1036 SHOULD return a DHCP Reply with an error code of 20. 1038 Before processing the Request, the server MUST determine whether or 1039 not the Request is a retransmission of an earlier DHCP Request from 1040 the same client. This is done by comparing the transaction-ID to 1041 all those transaction-IDs received from the same client during the 1042 previous XID_TIMEOUT seconds. If the transaction-ID is the same as 1043 one received during that time, the server MUST take the same action 1044 (e.g., retransmit the same DHCP Reply to the client) as it did after 1045 processing the previous DHCP Request with the same transaction-ID. 1047 Otherwise (the transaction-ID has not been recently used), when the 1048 server has identified and allocated all the relevant information, 1049 resources, and configuration data that is associated with the client, 1050 it sends that information to its DHCP client by constructing a 1051 DHCP Reply message and including the client's information in DHCP 1052 Extensions to the Reply message. The DHCP Reply message uses the 1053 same transaction-ID as found in the received DHCP Request message. 1054 Note that the reply message MAY (and often will) contain information 1055 not specifically requested by the client. 1057 If the DHCP Request message has the 'S' bit set in the message 1058 header, then the Request was sent to the server by a DHCP Relay. In 1059 this case, the DHCP server MUST send the corresponding DHCP Reply 1060 message to the agent address found in the Request (see section 7.2). 1062 The DHCP Request may contain extensions, which are interpreted 1063 (by default) as advisory information from the client about its 1064 configuration preferences. For instance, if the IP Address Extension 1065 is present, the DHCP server SHOULD attempt to allocate or extend the 1066 lifetime of the address indicated by the extension. Some extensions 1067 may be marked by the client as required. 1069 The DHCP server may accept some extensions for successful processing 1070 and allocation, while still rejecting others, or the server may 1071 reject various extensions for different reasons (and therefore 1072 different Error Codes). The Error Code found in the Reply message 1073 applies to all extensions found in the Reply. The DHCP server can 1074 send multiple Reply messages in response to the same DHCP Request, 1075 each possibly with a different Error Code, but all with the same 1076 transaction-ID. The DHCP server MUST send enough DHCP Reply messages 1077 to account for all requested extensions. The DHCP server SHOULD 1078 attempt to put all the extensions that were processed with the same 1079 Error Code into the same DHCP Reply, in the order in which they were 1080 received. 1082 When a client DHCP Request is received that has the 'C' bit set, the 1083 server should check to find out whether the extensions listed in the 1084 Request message match those which it has associated with the client's 1085 binding. Any resources which are not indicated by the client are 1086 presumed to be unknown by the client, and thus possible candidates 1087 for reallocation to satisfy requests from other clients. The DHCP 1088 Server MUST deallocate all resources associated with the client upon 1089 reception of a DHCP Request with the 'C' bit set, except for those 1090 which meet the following two conditions: 1092 - they are requested by the client in extensions to the same 1093 Request message , and 1095 - the server is willing to reallocate them in response to the 1096 client's request. 1098 . Wise implementations will not deallocate any resources until after 1099 the list of extensions to the request have been inspected. 1101 6.4. Receiving DHCP Release Messages 1103 If the server receives a DHCP Release Message, it MUST verify that 1104 the link-local address field of the message contains an address 1105 which could be a valid link-local address (i.e., one with the prefix 1106 FE80:00:00:00/64). If not, the message MUST be silently discarded. 1108 In response to a DHCP Release Message with a valid link-local address 1109 and relay address, the DHCP server formulates a DHCP Reply message 1110 that will be sent back to the releasing client by way of the client's 1111 link-local address. A DHCP Reply message sent in response to a DHCP 1112 Release message MUST be sent to the client's link-local address via 1113 the agent address in the Release message and set the 'L' bit in the 1114 Reply, unless the 'D' bit is set in the Release message. 1116 If the received agent address and link-local address do not 1117 correspond to any binding known to the server, then the server SHOULD 1118 return a DHCP Reply with an error code of 20. 1120 If the agent address and link-local address indicate a binding 1121 known to the server, then the server continues processing the 1122 Release message. If there are any extensions, the server releases 1123 the particular configuration items specified in the extensions. 1124 Otherwise, if there are no extensions, the server releases all 1125 configuration information in the client's binding. 1127 After performing the operations indicated in the DHCP Release message 1128 and its extensions, the DHCP server formulates a DHCP Reply message, 1129 copying the transaction-ID, from the DHCP Release message. For 1130 each Extension in the DHCP Release message successfully processed 1131 by the server, a matching Extension is appended to the DHCP Reply 1132 message. For extensions in the DHCP Release message which cannot be 1133 successfully processed by the server, DHCP Reply messages with the 1134 appropriate error codes MUST be returned by the server. 1136 6.5. Sending DHCP Reconfigure Messages 1138 If a DHCP server needs to change the configuration associated to any 1139 of its clients, it constructs a DHCP Reconfigure message and sends 1140 it to each such client. The Reconfigure MAY be sent to a multicast 1141 address chosen by the server and sent to each of its clients. 1143 7. DHCP Relay Considerations 1145 The DHCP protocol is constructed so that a relay does not have 1146 to maintain any state in order to facilitate DHCP client/server 1147 interactions. 1149 All relays MUST use the IP address of the interface from which the 1150 DHCP request was received as the source address for the IP header of 1151 that DHCP message. 1153 The main purpose of the DHCP Relay is to assist clients and servers 1154 to carry out DHCP protocol transactions. DHCP Solicit messages are 1155 issued by the relay when initiated by prospective DHCP clients. 1156 By default, the relay discovers local DHCP Servers by use of 1157 multicasting DHCP solicitations to the All-DHCP-Servers multicast 1158 address, but relays SHOULD allow this behavior to be configurable. 1159 The relay SHOULD NOT send such a multicast solicitation on the 1160 interface from which it received the solicitation from the client. 1161 The relay MAY update its list of available servers after whenever it 1162 receives an updated advertisement (with a nonzero lifetime) from any 1163 DHCP Servers. 1165 The DHCP Relay SHOULD be able to be configured with additional DHCP 1166 Server IP addresses for its subsequent advertisements in response 1167 to link-local DHCP Solicit messages with the 'P' bit set. Such 1168 configured Server addresses MAY still be updated by way of the 1169 abovementioned multicast solicitations, but on the other hand MAY be 1170 configured with infinite lifetimes. 1172 7.1. DHCP Solicit and DHCP Advertise Message Processing 1174 Upon receiving a DHCP Solicit message from a prospective client, a 1175 relay, by default, forwards the message to all DHCP Servers at a site 1176 according to the following procedure: 1178 - setting the 'L' bit, 1180 - copying the prospective client's link-local address into the 1181 appropriate field of the outgoing solicitation, 1183 - setting the 'A' bit, 1185 - copying the address of its interface from which the solicitation 1186 was received from the client, and finally, 1188 - sending the resulting message to the All-DHCP-Servers multicast 1189 address, FF05:0:0:0:0:0:1:3, over all interfaces except that from 1190 which the client's solicitation was received. 1192 When the relay receives a DHCP advertisement with the 'L' and 'A' 1193 bits set, it relays the advertisement to the client at the indicated 1194 link-local address by way of the interface indicated in the agent's 1195 address field. Any datagram with the 'L' bit set and the 'A' bit not 1196 set MUST be silently discarded. 1198 If the relay receives a DHCP solicit message with the 'P' bit 1199 set, the relay MAY construct a DHCP Advertise message and transmit 1200 it to the soliciting client on the same link as the solicitation 1201 was received from. In that case, the destination address of the 1202 advertisement MUST be the source address of the solicitation. When 1203 transmitting such a DHCP Advertise message to a prospective client, 1204 a relay indicates how many server addresses are included in the 1205 advertisement, and includes each address in the DHCP Advertise 1206 message. DHCP Advertise messages constructed by DHCP relays from 1207 cached server addresses MUST NOT include a server address on the same 1208 link as the soliciting client. 1210 If the Relay receives a nonzero lifetime in a DHCP Advertise 1211 message from one of the DHCP Servers responding to the solicitation, 1212 the Relay MAY unicast a new solicitation to that server before 1213 the lifetime expires, even if that occurs before the passing of 1214 RELAY_DISCOVERY_PERIOD seconds. Such a unicast solicitation MUST 1215 have the 'A' bit set, the address of the agent's interface for 1216 which DHCP Server addresses are desired, and finally the 'L' bit 1217 not set (no link-local address present). If the relay receives a 1218 DHCP advertisement with the 'A' bit set, and the 'L' bit not set, 1219 the relay MAY cache the server addresses even though no link-local 1220 address is present. 1222 The Relay MUST strip off all extensions to DHCP Advertise messages 1223 before storing them in its cache of DHCP Server addresses, except 1224 where specifically noted in the specification of particular DHCP 1225 extensions. 1227 7.2. DHCP Request Message Processing 1229 When a relay receives a DHCP Request message, it MUST check that the 1230 message is received from a link-local address, that the link-local 1231 address matches the link-local address field in the Request message 1232 header, and that the agent address field of the message matches an 1233 IP address associated to the interface from which the DHCP Request 1234 message was received. If any of these checks fail, the Relay MUST 1235 silently discard the Request message. 1237 The relay MUST also check whether the 'S' bit is set in the message 1238 header. If not, the datagram is discarded, and and the relay SHOULD 1239 return a DHCP Reply message to the source address of the Request 1240 message with error code 18. 1242 If the received request message is acceptable, the relay then 1243 transmits the DHCP Request message to the DHCP server found in the 1244 Server Address field of the received DHCP Request message. All 1245 of the fields of DHCP Request message header transmitted by the 1246 relay are copied over unchanged from the DHCP Request received from 1247 the client. Only the fields in the IP header will differ from the 1248 datagram received from the client, not the payload. If the Relay 1249 receives an ICMP error, the Relay SHOULD return a DHCP Reply message 1250 to the client address (which can be found in the payload of the ICMP 1251 message [2]), with error code 64. 1253 7.3. DHCP Reply Message Processing 1255 When the relay receives a DHCP Reply, it MUST check whether 1256 the message has the 'L' bit set. It MUST check whether the 1257 link-local address field contains an IP address that has prefix 1258 FE80:00:00:00/64. If all the checks are satisfied, the relay MUST 1259 send a DHCP Reply message to the link-local address listed in the 1260 received Reply message. Only the fields in the IP header will differ 1261 from the datagram received from the server, not the payload. 1263 8. Retransmission and Configuration Variables 1265 When a DHCP client does not receive a DHCP Reply in response to a 1266 pending DHCP Request, the client MUST retransmit the identical DHCP 1267 Request, with the same transaction-ID, to the same server again until 1268 it can be reasonably sure that the DHCP server is unavailable and an 1269 alternative can be chosen. It is important for the DHCP Server to 1270 be sure that its client has received the configuration information 1271 included with the extensions to the DHCP Reply message. All the 1272 actions specified for DHCP Request in this section hold also for DHCP 1273 Release messages received by the DHCP Server. 1275 Likewise, but less commonly, when a DHCP server does not receive a 1276 DHCP Request message in response to its DHCP Reconfigure message to 1277 the client, the server MUST retransmit the identical DHCP Reconfigure 1278 to the client until it is reasonably certain that the client is not 1279 available for reconfiguration. If no corresponding DHCP Request 1280 is ever received by the server, the server MAY erase or deallocate 1281 information as needed from the client's binding. 1283 These retransmissions occur using the following configuration 1284 variables for a DHCP implementation that MUST be configurable by a 1285 client or server: 1287 REPLY_MSG_INITIAL_TIMEOUT 1289 The time in seconds that a DHCP client waits to receive a 1290 server's DHCP Reply before retransmitting a DHCP Request. 1292 Default: 2 seconds. 1294 REPLY_MSG_MIN_RETRANS 1296 The minimum number of DHCP Request transmissions that a DHCP 1297 client should retransmit, before aborting the request, possibly 1298 retrying the Request with another Server, and logging a DHCP 1299 System Error. 1301 Default: 10 retransmissions. 1303 REPLY_MSG_RETRANS_INTERVAL 1305 The time between successive retransmissions of DHCP Request 1306 messages. 1308 Default: 2 seconds. 1310 RECONF_MSG_INITIAL_TIMEOUT 1312 The time in seconds that a DHCP server waits to receive 1313 a client's DHCP Request before retransmitting its DHCP 1314 Reconfigure. 1316 Default: 2 seconds. 1318 RECONF_MSG_MIN_RETRANS 1320 The minimum number of DHCP Reconfigure messages that a DHCP 1321 server should retransmit, before assuming the the client is 1322 unavailable and that the server can proceed with the needed 1323 reconfiguration of that client's resources, and logging a DHCP 1324 System Error. 1326 Default: 10 retransmissions. 1328 RECONF_MSG_RETRANS_INTERVAL 1330 The least time between successive retransmissions of DHCP 1331 Reconfigure messages. 1333 Default: 2 seconds. 1335 RECONF_MSG_MIN_RESP 1337 The minimum amount of time before a client can respond to a 1338 DHCP Reconfigure message sent to a multicast address. 1340 Default: 2 second. 1342 RECONF_MSG_MAX_RESP 1344 The maximum amount of time before a client MUST respond to a 1345 DHCP Reconfigure message sent to a multicast address. 1347 Default: 10 seconds. 1349 RELAY_DISCOVERY_PERIOD 1351 The period of time between successive attempts by the DHCP 1352 Relay to discover available DHCP Servers. 1354 Default: 3600 seconds (1 hour). 1356 MAX_SOLICIT_DELAY 1358 The maximum amount of time a prospective client is required 1359 to wait, after determining from a Router Discovery message 1360 that the client should perform stateful address configuration, 1361 before sending a DHCP Solicit to a DHCP Server. 1363 Default: 5 seconds 1365 MAX_ADV_WAIT 1367 The amount of time a client waits to hear DHCP Advertisements 1368 after issuing a DHCP Solicit to the All-DHCP Agents multicast 1369 address. 1371 Default: 5 seconds 1373 Note that, if a client receives a DHCP message which fails 1374 authentication, it should continue to wait for another message which 1375 might be correctly authenticated just as if the failed message had 1376 never arrived; however, receiving such failed messages SHOULD be 1377 logged. 1379 XID_TIMEOUT 1381 The amount of time a DHCP server has to keep track of 1382 client transaction-IDs in order to make sure that client 1383 retransmissions using the same transaction-ID are idempotent. 1385 Default: 10800 seconds 1387 9. Security Considerations 1389 DHCP clients and servers often have to authenticate the messages they 1390 exchange. For instance, a DHCP server may wish to be certain that a 1391 DHCP Request originated from the client identified by the fields included within the Request message 1393 header. Conversely, it is often essential for a DHCP client to 1394 be certain that the configuration parameters and addresses it has 1395 received were sent to it by an authoritative DHCP server. Similarly, 1396 a DHCP server should only accept a DHCP Release message which seems 1397 to be from one of its clients, if it has some assurance that the 1398 client actually did transmit the Release message. At the time of 1399 this writing, there is no generally accepted mechanism useful with 1400 DHCPv4 that can be extended for use with DHCP. 1402 The IPv6 Authentication Header can provide security for DHCP 1403 messages when both endpoints have a suitable IP address. However, 1404 a client often has only a link-local address, and such an address 1405 is not sufficient for a DHCP server which is off-link. In those 1406 circumstances the DHCP relay is involved, so that the DHCP message 1407 MUST have the relay's address in the IP destination address field, 1408 even though the client aims to deliver the message to the DHCP 1409 server. The DHCP Client-Server Authentication Extension [7] is 1410 intended to be used in these circumstances. 1412 10. Acknowledgements 1414 Thanks to the DHC Working Group for their time and input into the 1415 specification. A special thanks for the consistent input, ideas, 1416 and review by (in alphabetical order) Brian Carpenter, Ralph Droms, 1417 Thomas Narten, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson, 1418 and Phil Wells. 1420 Thanks to Steve Deering and Bob Hinden, who have consistently 1421 taken the time to discuss the more complex parts of the IPv6 1422 specifications. 1424 The authors MUST also thank their employers for the opportunity and 1425 funding to work on DHCP as individuals within the IETF. 1427 A. Related Work in IPv6 1429 The related work in IPv6 that would best serve an implementor 1430 to study is the IPv6 Specification [3], the IPv6 Addressing 1431 Architecture [4], IPv6 Stateless Address Autoconfiguration [11], IPv6 1432 Neighbor Discovery Processing [6], and Dynamic Updates to DNS [12]. 1433 These specifications enable DHCP to build upon the IPv6 work to 1434 provide both robust stateful autoconfiguration and autoregistration 1435 of DNS Host Names. 1437 The IPv6 Specification provides the base architecture and design of 1438 IPv6. A key point for DHCP implementors to understand is that IPv6 1439 requires that every link in the internet have an MTU of 576 octets 1440 or greater (in IPv4 the requirement is 68 octets). This means that 1441 a UDP datagram of 536 octets will always pass through an internet 1442 (less 40 octets for the IPv6 header), as long as there are no IP 1443 options prior to the UDP header in the datagram. But, IPv6 does 1444 not support fragmentation at routers, so that fragmentation takes 1445 place end-to-end between hosts. If a DHCP implementation needs 1446 to send a datagram greater than 536 octets it can either fragment 1447 the UDP datagram in UDP or use Path MTU Discovery [5] to determine 1448 the size of the datagram that will traverse a network path. It is 1449 implementation dependent how this is accomplished in DHCP. 1451 The IPv6 Addressing Architecture specification [4] defines the 1452 address scope that can be used in an IPv6 implementation, and the 1453 various configuration architecture guidelines for network designers 1454 of the IPv6 address space. Two advantages of IPv6 are that multicast 1455 addressing is required, and nodes can create link-local addresses 1456 during initialization of the nodes environment. This means that a 1457 client immediately can configure an IP address at initialization 1458 for an interface, before communicating in any manner on the link. 1459 The client can then use a well-known multicast address to begin 1460 communications to discover neighbors on the link, or to send a DHCP 1461 Solicit and locate a DHCP server or relay. 1463 IPv6 Stateless Address Autoconfiguration [11] (addrconf) specifies 1464 procedures by which a node may autoconfigure addresses based on 1465 router advertisements [6], and the use of a validation lifetime to 1466 support renumbering of addresses on the Internet. In addition the 1467 protocol interaction by which a node begins stateless or stateful 1468 autoconfiguration is specified. DHCP is one vehicle to perform 1469 stateful autoconfiguration. Compatibility with addrconf is a design 1470 requirement of DHCP (see Section 3.1). 1472 IPv6 Neighbor Discovery [6] is the node discovery protocol in IPv6 1473 (replaces and enhances functions of ARP [8]). To truly understand 1474 IPv6 and addrconf it is strongly recommended that implementors 1475 understand IPv6 Neighbor Discovery. 1477 Dynamic Updates to DNS [12] is a specification that supports the 1478 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 1479 the dynamic updates to DNS to now integrate addresses and name space 1480 to not only support autoconfiguration, but also autoregistration in 1481 IPv6. 1483 B. Change History 1485 B.1. Changes from November 95 to February 96 Drafts 1487 Substituted use of client's link-local address for previous uses of 1488 client's interface token. 1490 Reorganized DHCP messages into Solicit/Advertise, Request/Reply, 1491 Release, and Reconfigure. 1493 Made message-specific formats instead of using the same DHCP header 1494 for each message. 1496 Eliminated retransmission message types. 1498 Server commits after receiving DHCP Request, and optimistically 1499 depends on client retransmissions as negative acknowledgement. 1501 Eliminated total-addrs. 1503 Eliminated all definitions and most fields related to allocating IPv6 1504 addresses (moved to the Extensions specification). 1506 Renamed "gateway address" to be "agent address". 1508 Added "Considerations" sections. 1510 B.2. Changes from February 96 to June 96 Drafts 1512 Added language referring to DHCP Client-Server Authentication 1513 extension. 1515 Moved the 'L' bit in the DHCP Reply Message format to save 32 bits. 1517 Added language for multicast Reconfigure message handling. 1519 Added initial capability for the DHCP Relay to multicast and obtain 1520 DHCP Server addresses. 1522 Added capability for Servers to add Extensions to their 1523 Advertisements. 1525 Added 'C' bit to DHCP Solicit for deallocating resources after client 1526 crash. 1528 Added DHCP Advertisement lifetimes for use by DHCP Relay agents that 1529 need to periodically update their list of DHCP servers. 1531 B.3. Changes from June 96 to August 96 Drafts 1533 Since the working group indicated that DHCP solicitation traffic 1534 was not considered to be a significant factor affecting network 1535 load, it was decided to modify the handling of solicitations so 1536 that DHCP relays, by default, multicast DHCP Solicit message to all 1537 DHCP servers at a site. This entailed a number of changes to the 1538 protocol, namely: 1540 - Adding fields to the DHCP Solicit and DHCP Advertise messages to 1541 contain the DHCP client's link-local addresses. 1543 - Adding the 'L' bit to the DHCP Solicit and DHCP Advertise 1544 messages to indicate whether the link-local address is present 1546 - Adding a 'P' bit to the DHCP Solicit message so that the client 1547 can allow the Relay to use its non-default behavior, which is to 1548 return cached DHCP Server addresses to the client in response to 1549 the client's DHCP Solicit message. 1551 - Specified a new multicast address (the All-DHCP-Servers address) 1552 for use by DHCP Relays when "relaying" client solicitations. 1554 Added a random backoff after reboot so that clients' solicitations 1555 don't immediately swamp DHCP Servers after power outages. 1557 Added new multicast addresses for All DHCP Servers and All DHCP 1558 Relays. 1560 B.4. Changes from August 96 to November 96 Drafts 1562 Clarified language regarding treatment by the DHCP server of DHCP 1563 Requests with the 'C' bit set. 1565 Specified that the UDP source port for DHCP messages is arbitrary. 1567 Added description for Appendix C. 1569 Changed must to MUST where appropriate. 1571 Changed definitions for client, server, and relay to be definitions 1572 for DHCP client, DHCP server, and DHCP relay. 1574 Changed definitions of DHCP multicast addresses to conform to recent 1575 IANA allocations. 1577 Corrected references to "leases", to more accurately refer to IPv6 1578 address lifetimes. 1580 C. Comparison between DHCPv4 and DHCPv6 1582 This appendix is provided for readers who will find it useful to see 1583 a model and architecture comparison between DHCPv4 and DHCPv6. There 1584 are three key reasons for the differences: 1586 o IPv6 inherently supports a new model and architecture for 1587 communications and autoconfiguration of addresses. 1589 o DHCPv6 in its design was able to take advantage of the inherent 1590 benefits of IPv6. 1592 o New features were added to support the evolution and the 1593 existence of mature Internet users in the industry. 1595 IPv6 Architecuture/Model Changes: 1597 o The link-local address permits a node to have an address 1598 immediately when the node boots, which means all clients have a 1599 source IP address at all times to locate a server or relay agent 1600 on the local link. 1602 o The need for bootp compatibility and broadcast flags are removed, 1603 which permitted a great deal of freedom in designing the new 1604 packet formats for the client and server interaction. 1606 o Multicast and the scoping methods in IPv6 permitted the design of 1607 discovery packets that would inherently define their range by the 1608 multicast address for the function required. 1610 o Stateful autoconfiguration has to coexist and integrate with 1611 stateless autoconfiguration supporting Duplicate Address 1612 Detection and the two IPv6 lifetimes, to facilitate the dynamic 1613 renumbering of addresses and the management of those addresses. 1615 o Multiple addresses per interface are inherently supported in 1616 IPv6. 1618 o Most DHCPv4 options are unnecessary now because the configuration 1619 parameters are either obtained through IPv6 Neighbor Discovery or 1620 the Service Location protocol. 1622 DHCPv6 Architecture/Model Changes: 1624 o The message type is the first byte in the packet. 1626 o IPv6 Address allocations are now handled in a message extension 1627 as opposed to the main header. 1629 o Client/Server bindings are now mandatory and take advantage of 1630 the client's link-local address to always permit communications 1631 either directly from an on-link server, or from a remote server 1632 through an on-link relay-agent. 1634 o Servers are now discovered by a client solicit and server or 1635 relay-agent advertisement model. 1637 o The client will know if the server is on-link or off-link. 1639 o The client after a solicit will be returned the addresses of 1640 available servers either from an on-link server or from an 1641 on-link relay-agent as agents providing the advertisements. 1643 o The on-link relay-agent will obtain the location of remote server 1644 addresses from system configuration or by the use of a site wide 1645 DHCPv6 Multicast packet. 1647 o The protocol is optimized and removes the use of ACKs and NAKs 1648 once the client and server set-up is complete. 1650 o The server assumes the client receives its responses unless it 1651 receives a retransmission of the same client request. This 1652 permits recovery in the case where the network has faulted. 1654 o DHCPINFORM is inherent in the new packet design; a client can 1655 request configuration parameters other than IPv6 addresses in the 1656 optional extension headers. 1658 o Clients MUST listen to their UDP port for the new Reconfigure 1659 message type from servers, unless they join the appropriate 1660 multicast group as specified by the DHCP server. 1662 o Dynamic Updates to DNS are supported in the IPv6 Address 1663 extension. 1665 o New extensions have been defined. 1667 New Internet User Features: 1669 o Configuration of Dynamic Updates to DNS to support multiple 1670 implementation policy requirements. 1672 o Configuration of what policy is enforced when addresses are 1673 deprecated for dynamic renumbering can be implemented. 1675 o Configuration of how relay-agents locate remote servers for a 1676 link can be implemented. 1678 o An Authentication extension has been added. 1680 o Configuration of additional addresses for server applications can 1681 be requested by a client in an implementation. 1683 o Reclaiming addresses allocated with very long lifetimes can be 1684 implemented using the Reconfigure message type. 1686 o Configuration of tightly coupled integration between stateless 1687 and stateful address autoconfiguration can be implemented. 1689 References 1691 [1] S. Bradner and A. Mankin. The Recommendation for the IP Next 1692 Generation Protocol. RFC 1752, January 1995. 1694 [2] A. Conta and S. Deering. Internet Control Message Protocol 1695 (ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885, 1696 December 1995. 1698 [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1699 Specification. RFC 1883, December 1995. 1701 [4] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 1702 RFC 1884, December 1995. 1704 [5] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP 1705 version 6. RFC 1981, August 1996. 1707 [6] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 1708 IP Version 6 (IPv6). draft-ietf-ipngwg-discovery-06.txt -- work 1709 in progress, March 1996. 1711 [7] C. Perkins. Extensions to DHCPv6. draft-ietf-dhc-dhcpv6ext-02.txt 1712 -- work in progress, June 1996. 1714 [8] David C. Plummer. An Ethernet Address Resolution Protocol: 1715 Or Converting Network Protocol Addresses to 48.bit Ethernet 1716 Addresses for Transmission on Ethernet Hardware. RFC 826, 1717 November 1982. 1719 [9] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 1721 [10] J. B. Postel, Editor. Internet Protocol. RFC 791, September 1722 1981. 1724 [11] S. Thomson and T. Narten. IPv6 Stateless Address 1725 Autoconfiguration. draft-ietf-addrconf-ipv6-auto-06.txt 1726 - work in progress, November 1995. 1728 [12] S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the 1729 Domain Name System (DNS). draft-ietf-dnsind-dynDNS-06.txt -- 1730 work in progress, February 1996. 1732 Chair's Address 1734 The working group can be contacted via the current chair: 1736 Ralph Droms 1737 Computer Science Department 1738 323 Dana Engineering 1739 Bucknell University 1740 Lewisburg, PA 17837 1742 Phone: (717) 524-1145 1743 E-mail: droms@bucknell.edu 1745 Author's Address 1747 Questions about this memo can be directed to: 1749 Jim Bound Charles Perkins 1750 Digital Equipment Corporation T. J. Watson Research Center 1751 110 Spitbrook Road, ZKO3-3/U14 IBM Corporation 1752 Nashua, NH 03062 30 Saw Mill River Rd., Rm H3-D34 1753 Hawthorne, NY 10532 1754 Phone: +1-603-881-0400 +1-914-784-7350 1755 Fax: +1-914-784-6205 1756 E-mail: bound@zk3.dec.com perk@watson.ibm.com