idnits 2.17.1 draft-ietf-dhc-dhcpv6-07.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 is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 3 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 251: '... MUST This word, or the ...' RFC 2119 keyword, line 255: '... MUST NOT This phrase means ...' RFC 2119 keyword, line 258: '... SHOULD This word, or the ...' RFC 2119 keyword, line 265: '... MAY This word, or the ...' RFC 2119 keyword, line 268: '... MUST be prepared to i...' (121 more instances...) -- The draft header indicates that this document obsoletes draft-ietf-dhc-dhcpv6-06.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- -- No information found for rfcdraft-ietf-dhc-dhcpv6-06.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 August 1996) is 10102 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-06.txt IBM Research 5 27 August 1996 7 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 8 draft-ietf-dhc-dhcpv6-07.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 7 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 . . . . . . . . . . . . . . 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 102 C. Comparison between DHCPv4 and DHCPv6 32 104 Chair's Address 36 106 Author's Address 36 107 1. Introduction 109 The Dynamic Host Configuration Protocol (DHCPv6, or in this 110 document usually DHCP) provides configuration parameters to Internet 111 nodes. DHCP consists of a protocol for delivering node-specific 112 configuration parameters from a DHCP server to a client, and a 113 mechanism for allocation of network addresses and other related 114 parameters to IPv6 [3] nodes. 116 DHCP is built on a client-server model, where designated DHCP 117 servers allocate network addresses and automatically deliver 118 configuration parameters to dynamically configurable clients. 119 Throughout the remainder of this document, the term "server" 120 refers to a node providing initialization parameters by way of the 121 DHCP protocol, and the term "client" refers to a node requesting 122 initialization parameters from a DHCP server. DHCP servers maintain 123 state for their clients, in contrast to IPv6 Stateless Address 124 Autoconfiguration [11], where IPv6 nodes should get the same results 125 if they repeat the autoconfiguration procedure multiple times. 127 DHCPv6 uses Request and Reply messages to support a client/server 128 processing model whereby both client and server are assured that 129 requested configuration parameters have been received and accepted 130 by the client. DHCP supports optional configuration parameters and 131 processing for nodes through extensions described in its companion 132 document ``Extensions for the Dynamic Host Configuration Protocol for 133 IPv6'' [7]. 135 The IPv6 Addressing Architecture [4] and IPv6 Stateless Address 136 Autoconfiguration specifications provide new features not available 137 in IP version 4 (IPv4) [10], which are used to simplify and 138 generalize the operation of DHCP clients. 140 Section 2 provides definitions for terminology used throughout 141 this document. Section 3 provides an overview of the protocol 142 design model that guided the design choices in the specification; 143 section 3.2 briefly describes the protocol messages and their 144 semantics. Section 4 provides the message formats and field 145 definitions used for each message. Sections 5, 6, and 7 specify 146 how clients, servers, and relays interact. Appendix A summarizes 147 related work in IPv6 that will provide helpful context; it is not 148 part of this specification, but included for informational purposes. 149 Appendix B itemizes changes between different versions of this 150 protocol specification. 152 2. Terminology and Definitions 154 Relevant terminology from the IPv6 Protocol, IPv6 Addressing 155 Architecture, and IPv6 Stateless Address Autoconfiguration will be 156 provided, and then the DHCPv6 terminology. 158 2.1. IPv6 Terminology 160 IP Internet Protocol Version 6 (IPv6). The terms IPv4 and 161 IPv6 are used only in contexts where necessary to avoid 162 ambiguity. 164 node A device that implements IP. 166 router A node that forwards IP datagrams not explicitly 167 addressed to itself. 169 host Any node that is not a router. 171 link A communication facility or medium over which nodes 172 can communicate at the link layer, i.e., the layer 173 immediately below IP. Examples are Ethernet (simple or 174 bridged); Token Ring; PPP links, X.25, Frame Relay, or 175 ATM networks; and internet (or higher) layer "tunnels", 176 such as tunnels over IPv4 or IPv6 itself. 178 link-layer identifier 179 a link-layer identifier for an interface. Examples 180 include IEEE 802 addresses for Ethernet or Token Ring 181 network interfaces, and E.164 addresses for ISDN links. 183 link-local address 184 An IP address having link-only scope that can be used 185 to reach neighboring nodes attached to the same link. 186 All interfaces have a link-local address. 188 neighbors 189 Nodes attached to the same link. 191 interface 192 A node's attachment to the link. 194 address An IP layer identifier for an interface or a set of 195 interfaces. 197 message A unit of data carried in a datagram, exchanged between 198 DHCP agents and clients. 200 datagram An IP header plus payload. 202 unicast address 203 An identifier for a single interface. A datagram sent 204 to a unicast address is delivered to the interface 205 identified by that address. 207 multicast address 208 An identifier for a set of interfaces (typically 209 belonging to different nodes). A datagram sent to 210 a multicast address is delivered to all interfaces 211 identified by that address. 213 2.2. DHCPv6 Terminology 215 configuration parameter 216 Any parameter that can be used by a node to configure 217 its network environment and enable communication on a 218 link or internetwork. 220 client A node that initiates requests on a link to obtain 221 configuration parameters. 223 server A server is a node that responds to requests from 224 clients to provide: addresses, prefix lengths, or 225 other configuration parameters. 227 relay A node that acts as an intermediary to deliver DHCP 228 messages between clients and servers. 230 DHCP Agent 231 Either a DHCP server or a DHCP relay. 233 agent address 234 The address of a neighboring DHCP relay or DHCP server 235 on the same link as the DHCP client. 237 transaction-ID 238 The transaction-ID is a monotonically increasing 239 integer identifier specified by the client and used to 240 match a DHCP Reply to a pending DHCP Request. 242 binding A binding (or, client binding) in DHCP contains the 243 data which a DHCP server maintains for each of its 244 clients (see Section 6). 246 2.3. Specification Language 248 In this document, several words are used to signify the requirements 249 of the specification. These words are often capitalized. 251 MUST This word, or the adjective "required", means that 252 the definition is an absolute requirement of the 253 specification. 255 MUST NOT This phrase means that the definition is an absolute 256 prohibition of the specification. 258 SHOULD This word, or the adjective "recommended", means 259 that there may exist valid reasons in particular 260 circumstances to ignore this item, but the full 261 implications must be understood and carefully 262 weighed before choosing a different course. 263 Unexpected results may result otherwise. 265 MAY This word, or the adjective "optional", means that 266 this item is one of an allowed set of alternatives. 267 An implementation which does not include this option 268 MUST be prepared to interoperate with another 269 implementation which does include the option. 271 silently discard 272 The implementation discards the datagram without 273 further processing, and without indicating an error 274 to the sender. The implementation SHOULD provide 275 the capability of logging the error, including the 276 contents of the discarded datagram, and SHOULD 277 record the event in a statistics counter. 279 3. Protocol Design Model 281 This section is provided for implementors to understand the DHCPv6 282 protocol design model from an architectural perspective. The goals, 283 conceptual models and implementation examples presented in this 284 section do not specify requirements of the DHCPv6 protocol. 286 3.1. Design Goals 288 The following list gives general design goals for this DHCP 289 specification. 291 - DHCP should be a mechanism rather than a policy. DHCP must allow 292 local system administrators control over configuration parameters 293 where desired; e.g., local system administrators should be able 294 to enforce local policies concerning allocation and access to 295 local resources where desired. 297 - DHCP MUST NOT introduce any requirement for manual configuration 298 of DHCP clients, except possibly for manually configured 299 keys. Each node should be able to discover appropriate 300 local configuration parameters without user intervention, and 301 incorporate those parameters into its own configuration. 303 - DHCP MUST NOT require a server on each link. To allow for scale 304 and economy, DHCP must work across relay agents. 306 - A DHCP client must be prepared to receive multiple (possibly 307 different) responses to solicitations for DHCP servers. Some 308 installations may include multiple, overlapping DHCP servers to 309 enhance reliability and/or to increase performance. 311 - DHCP must coexist with statically configured, non-participating 312 nodes and with existing network protocol implementations. 314 - DHCPv6 MUST be compatible with IPv6 Stateless Address 315 Autoconfiguration [11]. 317 - DHCP must support the requirements of automated renumbering of IP 318 addresses [1]. 320 - DHCP servers should be able to support Dynamic Updates to 321 DNS [12]. 323 - DHCP servers MUST be able to handle multiple IPv6 addresses for 324 each client. 326 - A DHCP server to server protocol is NOT part of this 327 specification. 329 - It is NOT a design goal of DHCP to specify how a server 330 configuration parameter database is maintained or determined. 331 Methods for configuring DHCP servers are outside the scope of 332 this document. 334 3.2. DHCP Messages 336 Each DHCP message contains a type, which defines their function 337 within the protocol. Processing details for these DHCP messages are 338 specified in Sections 5, 6, and 7. The message types are as follows: 340 01 DHCP Solicit 342 The DHCP Solicit message is a DHCP message from a client to one 343 or more DHCP Agents. 345 02 DHCP Advertise 347 The DHCP Advertise is an IP unicast message from a DHCP Agent 348 in response to a client DHCP Solicit message. 350 03 DHCP Request 352 The DHCP Request is an IP unicast message from a client to 353 a server, when the client knows the IP unicast address of a 354 server, to request configuration parameters on a network. 356 04 DHCP Reply 358 The DHCP Reply is an IP unicast message sent by a server to 359 respond to a client's DHCP Request. Extensions [7] to the DHCP 360 Reply describe the resources that the DHCP Server has committed 361 and allocated to the client, and may contain other information 362 for use by the client. 364 05 DHCP Release 366 The DHCP Release message is used by a DHCP client to inform 367 the server that the client is releasing a particular address, 368 or set of addresses or resources, so that the server may 369 subsequently mark the addresses or resources as invalid in the 370 server's binding for the client. 372 06 DHCP Reconfigure 374 The DHCP Reconfigure message is used by a DHCP server to inform 375 its client that the server has new configuration information of 376 importance to the client. The client is expected to initiate a 377 new Request/Reply transaction. 379 3.3. Request/Response Processing Model 381 The request/response processing for DHCPv6 is transaction based 382 and uses a best-effort set of messages to guarantee a completed 383 transaction. 385 Transactions are usually started by a client with a DHCP Request, 386 which may be issued after the client knows the server's address. 387 The response (DHCP Reply) is from the server (possibly via a DHCP 388 Relay). At this point in the flow all data has been transmitted 389 and, hopefully, received. To provide a method of recovery if either 390 the client or server do not receive the messages to complete the 391 transaction, the client is required to retransmit any DHCP Request 392 message until it elicits the corresponding DHCP Reply or Replies, 393 or until it can be reasonably certain that the desired DHCP Server 394 is unavailable. The timeout and retransmission guidelines and 395 configuration variables are discussed in Section 8. 397 All DHCP Agents MUST join the DHCPv6 Server/Relay-Agent multicast 398 group at the well-known multicast address FF02:0:0:0:0:0:1:0. All 399 DHCP Servers MUST, in addition, join the DHCPv6 Server multicast 400 group at the well-known multicast address FF02:0:0:0:0:0:1:tbd. 401 All DHCP Relays MUST, on other hand, join in addition the 402 DHCPv6 Relay multicast group at the well-known multicast address 403 FF02:0:0:0:0:0:1:tbd. 405 DHCP uses the UDP [9] protocol to communicate between clients and 406 servers. UDP is not reliable, but DHCP must provide some reliability 407 between clients and servers. If a response is not received after 408 transmission of a DHCP message, the message MUST be retransmitted 409 according to the rules specified in Section 8. 411 A client MUST transmit all messages over UDP using port 547 as the 412 destination port. A client MUST receive all messages from UDP port 413 546. 415 A DHCP Agent MUST transmit all messages to clients over UDP using 416 port 546 as the destination port. A DHCP Agent MUST receive all 417 messages over UDP using port 547. 419 4. DHCP Message Formats and Field Definitions 421 All fields in DHCP messages MUST be initialized to binary zeroes by 422 both the client and server unless otherwise noted. DHCP message 423 types not defined here (msg-types 0 and 7-255) are reserved. 425 4.1. DHCP Solicit Message Format 427 A DHCP client or relay transmits a DHCP Solicit message to obtain one 428 or more DHCP server addresses. 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | msg-type |C|L|A|P| RESERVED | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | link-local address (if present) | 436 | (16 octets) | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | relay agent address (if present) | 439 | (16 octets) | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 msg-type 1 444 C If set, the client requests that all servers receiving 445 the message deallocate the resources associated with 446 the client. 448 L If set, the link-local address is present 450 A If set, the relay's address is present 452 P If set, the client is willing to accept previously 453 cached server addresses from relays 455 RESERVED 0 457 If a DHCP client does not know any DHCP Agent address, or wants 458 to locate a new server to receive configuration parameters, the 459 client SHOULD use, as the destination IP address, the DHCPv6 460 Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0. If the 461 'P' bit is not set, any DHCP Relay receiving the solicitation MUST 462 forward it to the All-DHCP-Servers multicast address, to instruct 463 DHCP Servers to send their advertisements to the prospective client. 464 In that case, the relay MUST copy the client's link-local address 465 into the message, set the 'L' bit, copy the address of its interface 466 from which the client's solicitation was received into the agent's 467 address field, and set the 'A' bit. 469 4.2. DHCP Advertise Message Format 471 A DHCP agent sends a DHCP Advertise message to inform a prospective 472 client about the IP address of a DHCP Agent to which a DHCP Request 473 message may be sent. When the client and server are on different 474 links, the server sends the advertisement back through the DHCP Relay 475 whence the solicitation came. Relays MAY cache DHCP server addresses 476 gleaned from DHCP advertisements with nonzero lifetimes, in order to 477 satisfy possible future client solicitations. 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | msg-type |S|L| rsvd | server-count | lifetime | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | agent address | 485 | (16 octets) | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | link-local address (if present) | 488 | (16 octets) | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | server addresses | 491 | (16 octets each) | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | extensions (variable number and length) ... 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 msg-type 2 498 S If set, the agent address is also a server address. 500 L If set, the link-local address is present 502 rsvd 0 504 server-count 505 The number of addresses listed in the server 506 addresses field. 508 lifetime Lifetime for the server advertisement, in units of 509 4096 seconds. If the destination address of the 510 DHCP Advertisement is a link-local address, then the 511 Lifetime MUST be 0. A value of 0 means that this 512 field is not used. 514 agent address 515 The IP address of a DHCP Agent interface on the same 516 link as the client. 518 server addresses 519 The IP address(es) of the DHCP server(s) 521 extensions See [7]. 523 Suppose that a DHCP server on the same link as a client issues the 524 DHCP Advertise in response to a DHCP Solicit message sent to the 525 All-DHCP-Agents multicast address. Then the agent address will be 526 the IP address of one of the server's interfaces, the 'S' bit will be 527 set, the agent address will be an address of the server, and there 528 may be zero server addresses sent in the DHCP Advertise message. It 529 is an error for server-count to be zero if the 'S' bit is not set. 531 If the DHCP Server is sending the advertisement in response to a 532 solicitation with the client's link-local address present, the server 533 MUST copy the link-local address into the advertisement. 535 The source IP address of the IP header of any DHCP Advertise message 536 must have sufficient scope to be reachable by the DHCP Server. In 537 particular, the source address of any DHCP Advertise message sent 538 by a DHCP relay MUST NOT be a link-local address. In situations 539 where there are no routers sending Router Advertisements, then a DHCP 540 Server MUST be configured on the same link as prospective clients. 542 4.3. DHCP Request Message Format 544 In order to request parameters from a DHCP server, a client sends a 545 DHCP Request message, and MAY append the appropriate extensions [7]. 546 If the client does not know any DHCP server address, it must first 547 obtain a server address by multicasting a DHCP Solicit message (see 548 Section 4.1). If the client does not have a valid IP address of 549 sufficient scope for the DHCP server to communicate with the client, 550 the client MUST use the unicast IP address of a local DHCP relay 551 as the destination IP address. Otherwise, the client MAY omit the 552 server address in the DHCP Request message; in this case, the client 553 MUST send the DHCP Request message directly to the server, using the 554 server address as the IP destination address in the IP header. 556 0 1 2 3 557 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | msg-type |S|C| reserved | transaction-ID | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | (if present) | 562 | server address (16 octets) | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | agent address | 565 | (16 octets) | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | link-local address | 568 | (16 octets) | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | extensions (variable number and length) .... 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 msg-type 3 575 S If set, the server address is present 577 C If set, the client requests the server to clear all 578 existing resources and bindings currently associated 579 with the client, deallocating as needed. 581 reserved 0 583 transaction-ID 584 A monotonically increasing number which the client asks 585 the server to copy into its DHCP Reply, so that the 586 client can match Replies with pending Requests. 588 server address 589 If present, the IP address of the DHCP server which 590 should receive the client's DHCP Request message. 592 agent address 593 The IP address of a relay or server interface, copied 594 from a DHCP Advertisement message. 596 link-local address 597 The IP link-local address of the client interface from 598 which the client issued the DHCP Request message 600 extensions See [7]. 602 4.4. DHCP Reply Message Format 604 The server sends one or more DHCP Reply message in response to every 605 DHCP Request received. If the request comes with the 'S' bit set, 606 the client could not directly send the Request to the server and had 607 to use a neighboring relay agent. In that case, the server sends 608 back the DHCP Reply with the 'L' bit set, and the DHCP Reply is 609 addressed to the agent address found in the DHCP Request message. If 610 the 'L' bit is set, then the client's link-local address will also be 611 present. 613 0 1 2 3 614 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | msg-type |L| error code | transaction-ID | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | (if present) | 619 | link-local address (16 octets) | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | extensions (variable number and length) .... 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 msg-type 4 626 L If set, the link-local address is present 628 error code 629 One of the following values: 631 0 Success 632 16 Failure, reason unspecified 633 17 Authentication failed or nonexistent 634 18 Poorly formed request 635 19 Resources unavailable 636 20 Client record unavailable 637 21 Invalid source address in Release 638 22 Unable to honor required extension parameters 639 24 Bad Hair Day 640 32 Insufficient Funds 641 64 Server unreachable (ICMP error) 643 transaction-ID 644 Copied from the transaction-ID which the DHCP server 645 received in the DHCP Request, to help the client match 646 this reply with an outstanding Request. 648 link-local address 649 If present, the IP address of the client interface 650 which issued the corresponding DHCP Request message. 652 extensions 653 See [7]. 655 If the 'L' bit is set, and thus the link-local address is present in 656 the Reply message, the Reply is sent by the server to the relay's 657 address which was specified as the agent address in the DHCP Request 658 message, and the relay uses the link-local address to deliver the 659 Reply message to the client. Error code 22 MUST be sent only in the 660 case that the Server could otherwise honor the requested resource, 661 if the client had not made the parameter values (included in the 662 relevant Extension requesting the resource) required for the server 663 to obey. If the length in the UDP header preceding the DHCP message 664 does not match that which is expected in the DHCP Request, error code 665 18 MUST be sent. 667 4.5. DHCP Release Message Format 669 The DHCP Release message is sent without the assistance of any DHCP 670 relay. When a client sends a Release message, it is assumed to 671 have a valid IP address with sufficient scope to allow access to 672 the target server. Only the parameters which are specified in the 673 extensions are released. The DHCP server acknowledges the Release 674 message by sending a DHCP Reply (Section 4.4, 6.3). 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | msg-type |D| msg-flags | transaction-ID | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | agent address | 682 | (16 octets) | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | link-local address | 685 | (16 octets) | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | extensions (variable number and length) .... 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 msg-type 5 692 D If the 'D' ("Direct") flag is set, the client instructs 693 the server to send the DHCP Reply directly back to the 694 client, instead of using the given agent address and 695 link-local address to relay the Reply message. 697 msg-flags 0 699 transaction-ID 700 A monotonically increasing number which the client asks 701 the server to use in its DHCP Reply, to help the client 702 match Replies with outstanding Releases. 704 agent address 705 The IP address of the agent interface to which the 706 client issued the DHCP Request message 708 link-local address 709 The IP link-local address of the client interface from 710 which the the client issued the DHCP Request message 712 extensions 713 See [7] 715 Suppose that the client knows that the address it uses as the source 716 IP address in its IP header will still be valid after the server 717 performs the operations requested in the extensions to the DHCP 718 Release message. In that case, and only then, the client SHOULD then 719 specify the 'D' flag. When the 'D' flag is set, the server MUST send 720 the DHCP Reply back to the client's address as shown in the source 721 address of the IP header of the Release message. Otherwise, when 722 the 'D' bit is not set, the server MUST use the agent address and 723 link-local address in its DHCP Reply message to forward the Reply 724 message back to the releasing client. 726 4.6. DHCP Reconfigure Message Format 728 The DHCP Reconfigure message is sent without the assistance of any 729 DHCP relay. When a server sends a Reconfigure message, the client 730 to which it is sent is assumed to have a valid IP address with 731 sufficient scope to be accessible by the server. Only the parameters 732 which are specified in the extensions to the Reconfigure message need 733 be requested again by the client. 735 The client SHOULD listen at UDP port 546 to receive possible 736 DHCP Reconfigure messages, except in cases where the client knows 737 that no Reconfigure message will ever be issued. In some cases, 738 the IP address at which the client listens will be a multicast 739 address sent to the client by the DHCP server in an extension to an 740 earlier DHCP Reply message. If the client does not listen for DHCP 741 Reconfigure messages, it is possible that the client will not receive 742 notification that its DHCP server has deallocated the client's 743 IP address and/or other resources allocated to the client. See 744 discussion in 6.5. 746 0 1 2 3 747 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 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | msg-type | msg-flags | reserved | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | extensions (variable number and length) .... 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 msg-type 6 756 msg-flags 0 758 reserved 0 760 extensions See [7] 762 5. DHCP Client Considerations 764 A DHCP client MUST silently discard any DHCP Solicit, DHCP Request, 765 or DHCP Release message it receives. 767 A DHCP client MAY retain its configured parameters and resources 768 across client system reboots and DHCP client program restarts. 769 However, in these circumstances a DHCP client MUST also formulate a 770 DHCP Request message to verify that its configured parameters and 771 resources are still valid. This Request message MUST have the 'C' 772 bit set, to clean up stale client binding information at the server 773 which may no longer be in use by the client; stale information is 774 that which the client does not include in extensions to such request 775 messages. 777 5.1. Sending DHCP Solicit Messages 779 If a node wishes to become a new DHCP client, it must first 780 locate a DHCP Server. The client does this by multicasting a DHCP 781 Solicit message to the All-DHCP-Agents address multicast address 782 FF02:0:0:0:0:0:1:0, setting the Hop Limit == 1. If there are no 783 DHCP servers on the same link as the node, then a DHCP Relay must be 784 present for further handling of the solicitation. If the node is 785 willing to accept cached server addresses from the DHCP Relay instead 786 of requesting the Relay to multicast its solicitation over all site 787 networks, then the node MAY set the 'P' bit in its solicitation. 789 By setting the 'C' bit in the solicitation, a DHCP client requests 790 that all the DHCP Servers that receive the solicitation should clean 791 up their stale client records that match its link-local address. 793 If a client sends a DHCP Solicit message after it reboots, the 794 solicitation MUST be delayed after reception of the first Router 795 Advertisement [6] message, by at least some random amount of time 796 between zero and MAX_SOLICIT_DELAY seconds. This delay is intended 797 to help stagger requests to DHCP Servers (and avoid link-layer 798 collisions) after a power outage causes many nodes to reboot all at 799 once. Each subsequent DHCP Solicit message that is issued before 800 receiving an advertisement MUST be delayed by twice the amount by 801 which the previous DHCP Solicit message was delayed. 803 5.2. Receiving DHCP Advertise Messages 805 When a DHCP client receives a DHCP Advertise message, it may 806 formulate a DHCP Request message to receive configuration information 807 and resources from the DHCP servers listed in the advertisement. If 808 the Advertise message has zero server addresses and does not have the 809 'S' bit set, the client MUST silently discard the message. If the 810 server's address is shown as a Multicast address, the advertisement 811 MUST be silently discarded. 813 If the 'S' bit is set, the DHCP Advertise message was transmitted 814 by a DHCP server on the same link as the client. In this case, the 815 client MUST use the agent address as the destination address for any 816 future DHCP message transactions sent to that server. 818 Advertisements may have extensions; this might allow the DHCP client 819 to select the configuration that best meets its needs from among 820 several prospective servers. 822 5.3. Sending DHCP Request Messages 824 A DHCP client obtains configuration information from a DHCP server by 825 sending a DHCP Request message. The client must know the server's 826 address before sending the Request message, and client must have 827 acquired a (possibly different) DHCP agent address. If the client 828 and server are on the same link, the agent address used by the client 829 MUST be the same as the DHCP server's address. A DHCP Request 830 message MUST NOT be sent to any multicast address, since otherwise 831 multiple DHCP agents would possibly allocate resources to the client 832 in response to the same Request, and the client would have no way to 833 know which servers had made the allocations, if any datagrams were 834 lost due to collisions, etc. 836 If the client has no valid IP address of sufficient scope, and the 837 DHCP server is off-link, then the client MUST include the server 838 address in the appropriate field of the DHCP Request message and set 839 the 'S' bit. In this case, the IP destination address of the Request 840 message will be a DHCP relay address. 842 Otherwise, if the client already has a valid IP address and knows 843 the IP address of a candidate IP server, it SHOULD send the Request 844 message directly to the DHCP server without requiring the services of 845 the local DHCP relay. 847 If a client wishes to instruct a DHCP server to deallocate all 848 unknown previous resources, configuration information, and bindings 849 associated with its agent address and link-local address, it sets the 850 'C' bit in the DHCP Request. A client MAY send in such a Request 851 even when it is no longer attached to the link on which the relay 852 address is attached. 854 In any case, after choosing a transaction-ID which is numerically 855 greater than its previous transaction-ID, and filling in the 856 appropriate fields of the DHCP Request message, the client MAY append 857 various DHCP Extensions to the message. These extensions denote 858 specific requests by the client; for example, a client may request 859 a particular IP address, or request that the server send an update 860 containing the client's new IP address to a Domain Name Server. When 861 all desired extensions have been applied, the DHCP client unicasts 862 the DHCP Request to the appropriate DHCP Agent. 864 For each pending DHCP Request message, a client MUST maintain the 865 following information: 867 - The transaction-ID of the request message, 868 - The server address, 869 - The agent address, 870 - The time at which the next retransmission will be attempted, and 871 - All extensions appended to the request message. 873 If a client does not receive all the relevant DHCP Reply messages 874 (Section 5.4) with the same transaction-ID as a pending DHCP Request 875 message within REPLY_MSG_INITIAL_TIMEOUT seconds, or if the received 876 DHCP Request messages contain DHCP Authentication extensions which 877 fail to provide the correct authentication information, the client 878 MUST retransmit the Request with the same transaction-ID and continue 879 to retransmit according to the rules in Section 8. 881 5.4. Receiving DHCP Reply Messages 883 When a client receives a DHCP Reply message, it MUST check whether 884 the transaction-ID in the Reply message matches the transaction-ID 885 of a pending DHCP Request message. If no match is found, the Reply 886 message MUST be silently discarded. If the transaction-ID matches 887 that of a pending Request, and the 'L' bit is set, but the source 888 address in the IP header does not match the pending agent address, 889 the client MUST discard the message, and SHOULD log the event. 890 Likewise, if the transaction-ID matches that of a pending Request, 891 and the 'L' bit is not set, but the source address in the IP header 892 does not match the pending server address, the client MUST discard 893 the message, and SHOULD log the event. 895 If the Reply message is acceptable, the client processes each 896 Extension [7], extracting the relevant configuration information 897 and parameters for its network operation. The Error Code found in 898 the Reply message applies to all extensions found in the Reply. If 899 all expected extensions are not found in the same Reply message, 900 then they are likely to be located in another Reply, possibly 901 with a different Error Code, but with the same transaction-ID. The 902 DHCP Client MUST continue processing DHCP Reply messages until all 903 requested extensions are accounted for. If some requested extensions 904 are not accounted for within DHCP Reply messages sent by the server, 905 the client MUST reissue the entire DHCP Request again, with all 906 extensions, and the same transaction-ID. 908 Some configuration information extracted from the extensions to the 909 DHCP Reply message must remain associated with the DHCP server that 910 sent the message. The particular extensions that require this extra 911 measure of association with the server are indicated in the DHCP 912 Extensions document [7]. These "resource-server" associations are 913 used when sending DHCP Release messages. 915 5.5. Sending DHCP Release Messages 917 If a DHCP client determines that some of its network configuration 918 parameters are no longer needed, it SHOULD enable the DHCP server to 919 release allocated resources which are no longer in use by sending a 920 DHCP Release message to the server. The client consults its list 921 of resource-server associations in order to determine which server 922 should receive the desired Release message. If a client wishes to 923 ask the server to release all information and resources relevant to 924 the client, the client specifies no extensions; this is preferable 925 to sending a DHCP Request message with the 'C' bit set and no 926 extensions. 928 Suppose a client wishes to release resources which were granted to 929 it on another link. In that case, the client must instruct the 930 server to send the DHCP Reply directly back to the client, instead 931 of performing the default processing of sending the DHCP Reply back 932 through the agent-address included in the DHCP Release. This is done 933 by setting the 'D' bit in the DHCP Release message. Note that it is 934 an error (Error Code 21) to include within the DHCP Release message 935 both the 'D' bit and an IP address extension which has the IP address 936 used as the source address of the datagram containing DHCP Release 937 message. 939 5.6. Receiving DHCP Reconfigure Messages 941 If a DHCP client receives a DHCP Reconfigure message, it is a request 942 for the client to initiate a new DHCP Request/Reply transaction with 943 the server which sent the Reconfigure message. The server sending 944 the Reconfigure message MAY be different than the server which sent a 945 DHCP Reply message containing the original configuration information. 947 For each Extension which is present in the Reconfigure message, the 948 client appends a matching Extension to its DHCP Request message 949 which it formulates to send to the DHCP server which is found in 950 the IP source address of the message. The client also selects a 951 transaction-ID numerically greater than its last choice and inserts 952 it into the Request message. From then on, processing is the same as 953 specified above in Section 5.3. 955 Note that a client may be requested by its server to join a multicast 956 group for the purpose of receiving DHCP Reconfigure messages. When a 957 Reconfigure message is delivered to the client by way of the selected 958 multicast address, the client must delay its further response for 959 a random amount of time uniformly distributed within the interval 960 between RECONF_MSG_MIN_RESP and RECONF_MSG_MAX_RESP seconds. This 961 will minimize the likelihood that the server will be bombarded with 962 DHCP Request messages all at the same time. 964 6. DHCP Server Considerations 966 A server maintains a collection of client records, called 967 ``bindings''. Each binding is uniquely identifiable by the ordered 968 pair , since the link-local 969 address is guaranteed to be unique [11] on the link identified 970 by the agent address. An implementation MUST support bindings 971 consisting of at least a client's link-local address, agent address, 972 preferred lifetime and valid lifetime [11] for each client address, 973 and the transaction-ID. A client binding may be used to store any 974 other information, resources, and configuration data which will be 975 associated with the client. A DHCP server MUST retain its clients' 976 bindings across server reboots, and, whenever possible, a DHCP client 977 should be assigned the same configuration parameters despite server 978 system reboots and DHCP server program restarts. A DHCP server MUST 979 support fixed or permanent allocation of configuration parameters to 980 specific clients. 982 Servers on the same link as the client MUST use the source address 983 in the IP header from the client as the destination address in DHCP 984 response messages sent by the server to the client. 986 A server MUST ignore any DHCP Advertise, DHCP Reply, or DHCP 987 Reconfigure message it receives. 989 6.1. Receiving DHCP Solicit Messages 991 If the DHCP Solicit message was received at the All-DHCP-Servers 992 multicast address, the DHCP Server MUST check to make sure that the 993 source address is not a link-local address. In that case, if the 994 source address is a link-local address, the server MUST silently 995 discard the packet. If any solicitation has the 'L' bit set without 996 the 'A' bit also being set, the server MUST discard the packet, and 997 SHOULD log the error, in case the packet was sent by a malfunctioning 998 relay agent. If the UDP length disagrees with the length determined 999 by the format of the DHCP Solicit message, the server MUST drop the 1000 packet and SHOULD log the error. 1002 6.2. Sending DHCP Advertise Messages 1004 Upon receiving and verifying the correctness of a DHCP Solicit 1005 message, a server constructs a DHCP Advertise message and transmits 1006 it on the same link as the solicitation was received from. The 1007 destination address of the advertisement MUST be the source address 1008 of the solicitation. The DHCP server must use an IP address of the 1009 interface on which it received the Solicit message as the source 1010 address field of the IP header of the message. 1012 The DHCP server MAY append extensions to the Advertisement, in order 1013 to offer the soliciting node the best possible information about 1014 the services and resources which the server may be able to make 1015 available. 1017 6.3. DHCP Request and Reply Messages 1019 The DHCP server MUST check to ensure that the client's link-local 1020 address field of the Request message contains an address which could 1021 be a valid link-local address. If not, the message MUST be silently 1022 discarded. Otherwise, it checks for the presence of the 'S' bit. If 1023 the 'S' bit is set, the server MUST check that the server address 1024 matches the destination IP address at which the Request message was 1025 received by the server. If the server address does not match, the 1026 Request message MUST be silently discarded. 1028 If the received agent address and link-local address do not 1029 correspond to any binding known to the server, then the server MAY 1030 create a new binding for the previously unknown client; otherwise, it 1031 SHOULD return a DHCP Reply with an error code of 20. 1033 Before processing the Request, the server must determine whether or 1034 not the Request is a retransmission of an earlier DHCP Request from 1035 the same client. This is done by comparing the transaction-ID to 1036 all those transaction-IDs received from the same client during the 1037 previous XID_TIMEOUT seconds. If the transaction-ID is the same as 1038 one received during that time, the server MUST take the same action 1039 (e.g., retransmit the same DHCP Reply to the client) as it did after 1040 processing the previous DHCP Request with the same transaction-ID. 1042 Otherwise (the transaction-ID has not been recently used), when the 1043 server has identified and allocated all the relevant information, 1044 resources, and configuration data that is associated with the client, 1045 it sends that information to its DHCP client by constructing a 1046 DHCP Reply message and including the client's information in DHCP 1047 Extensions to the Reply message. The DHCP Reply message uses the 1048 same transaction-ID as found in the received DHCP Request message. 1049 Note that the reply message MAY (and often will) contain information 1050 not specifically requested by the client. 1052 If the DHCP Request message has the 'S' bit set in the message 1053 header, then the Request was sent to the server by a DHCP Relay. In 1054 this case, the DHCP server MUST send the corresponding DHCP Reply 1055 message to the agent address found in the Request (see section 7.2). 1057 The DHCP Request may contain extensions, which are interpreted 1058 (by default) as advisory information from the client about its 1059 configuration preferences. For instance, if the IP Address Extension 1060 is present, the DHCP server SHOULD attempt to allocate or extend the 1061 lifetime of the address indicated by the extension. Some extensions 1062 may be marked by the client as required. 1064 The DHCP server may accept some extensions for successful processing 1065 and allocation, while still rejecting others, or the server may 1066 reject various extensions for different reasons (and therefore 1067 different Error Codes). The Error Code found in the Reply message 1068 applies to all extensions found in the Reply. The DHCP server can 1069 send multiple Reply messages in response to the same DHCP Request, 1070 each possibly with a different Error Code, but all with the same 1071 transaction-ID. The DHCP server MUST send enough DHCP Reply messages 1072 to account for all requested extensions. The DHCP server SHOULD 1073 attempt to put all the extensions that were processed with the same 1074 Error Code into the same DHCP Reply, in the order in which they were 1075 received. 1077 When a client DHCP Request is received that has the 'C' bit set, the 1078 server should check to find out whether the extensions listed in the 1079 Request message match those which it has associated with the client's 1080 binding. Any resources which are not indicated by the client are 1081 presumed to be unknown by the client, and thus possible candidates 1082 for reallocation to satisfy requests from other clients. The DHCP 1083 Server is NOT required to deallocate all resources associated with 1084 the client upon reception of a DHCP Request with the 'C' bit set, and 1085 wise implementations will not deallocate any resources until after 1086 the list of extensions to the request have been inspected. 1088 6.4. Receiving DHCP Release Messages 1090 If the server receives a DHCP Release Message, it MUST verify that 1091 the link-local address field of the message contains an address 1092 which could be a valid link-local address (i.e., one with the prefix 1093 FE80:00:00:00/64). If not, the message MUST be silently discarded. 1095 In response to a DHCP Release Message with a valid link-local address 1096 and relay address, the DHCP server formulates a DHCP Reply message 1097 that will be sent back to the releasing client by way of the client's 1098 link-local address. A DHCP Reply message sent in response to a DHCP 1099 Release message MUST be sent to the client's link-local address via 1100 the agent address in the Release message and set the 'L' bit in the 1101 Reply, unless the 'D' bit is set in the Release message. 1103 If the received agent address and link-local address do not 1104 correspond to any binding known to the server, then the server SHOULD 1105 return a DHCP Reply with an error code of 20. 1107 If the agent address and link-local address indicate a binding 1108 known to the server, then the server continues processing the 1109 Release message. If there are any extensions, the server releases 1110 the particular configuration items specified in the extensions. 1112 Otherwise, if there are no extensions, the server releases all 1113 configuration information in the client's binding. 1115 After performing the operations indicated in the DHCP Release message 1116 and its extensions, the DHCP server formulates a DHCP Reply message, 1117 copying the transaction-ID, from the DHCP Release message. For 1118 each Extension in the DHCP Release message successfully processed 1119 by the server, a matching Extension is appended to the DHCP Reply 1120 message. For extensions in the DHCP Release message which cannot be 1121 successfully processed by the server, DHCP Reply messages with the 1122 appropriate error codes MUST be returned by the server. 1124 6.5. Sending DHCP Reconfigure Messages 1126 If a DHCP server needs to change the configuration associated to any 1127 of its clients, it constructs a DHCP Reconfigure message and sends 1128 it to each such client. The Reconfigure MAY be sent to a multicast 1129 address chosen by the server and sent to each of its clients. 1131 7. DHCP Relay Considerations 1133 The DHCP protocol is constructed so that a relay does not have 1134 to maintain any state in order to facilitate DHCP client/server 1135 interactions. 1137 All relays MUST use the IP address of the interface from which the 1138 DHCP request was received as the source address for the IP header of 1139 that DHCP message. 1141 The main purpose of the DHCP Relay is to assist clients and servers 1142 to carry out DHCP protocol transactions. DHCP Solicit messages are 1143 issued by the relay when initiated by prospective DHCP clients. 1144 By default, the relay discovers local DHCP Servers by use of 1145 multicasting DHCP solicitations to the All-DHCP-Servers multicast 1146 address, but relays SHOULD allow this behavior to be configurable. 1147 The relay SHOULD NOT send such a multicast solicitation on the 1148 interface from which it received the solicitation from the client. 1149 The relay MAY update its list of available servers after whenever it 1150 receives an updated advertisement (with a nonzero lifetime) from any 1151 DHCP Servers. 1153 The DHCP Relay SHOULD be able to be configured with additional DHCP 1154 Server IP addresses for its subsequent advertisements in response 1155 to link-local DHCP Solicit messages with the 'P' bit set. Such 1156 configured Server addresses MAY still be updated by way of the 1157 abovementioned multicast solicitations, but on the other hand MAY be 1158 configured with infinite lifetimes. 1160 7.1. DHCP Solicit and DHCP Advertise Message Processing 1162 Upon receiving a DHCP Solicit message from a prospective client, a 1163 relay, by default, forwards the message to all DHCP Servers at a site 1164 according to the following procedure: 1166 - setting the 'L' bit, 1168 - copying the prospective client's link-local address into the 1169 appropriate field of the outgoing solicitation, 1171 - setting the 'A' bit, 1173 - copying the address of its interface from which the solicitation 1174 was received from the client, and finally, 1176 - sending the resulting message to the All-DHCP-Servers multicast 1177 address, FF02:0:0:0:0:0:1:tbd, over all interfaces except that 1178 from which the client's solicitation was received. 1180 When the relay receives a DHCP advertisement with the 'L' and 'A' 1181 bits set, it relays the advertisement to the client at the indicated 1182 link-local address by way of the interface indicated in the agent's 1183 address field. Any datagram with the 'L' bit set and the 'A' bit not 1184 set MUST be silently discarded. 1186 If the relay receives a DHCP solicit message with the 'P' bit 1187 set, the relay MAY construct a DHCP Advertise message and transmit 1188 it to the soliciting client on the same link as the solicitation 1189 was received from. In that case, the destination address of the 1190 advertisement MUST be the source address of the solicitation. When 1191 transmitting such a DHCP Advertise message to a prospective client, 1192 a relay indicates how many server addresses are included in the 1193 advertisement, and includes each address in the DHCP Advertise 1194 message. DHCP Advertise messages constructed by DHCP relays from 1195 cached server addresses MUST NOT include a server address on the same 1196 link as the soliciting client. 1198 If the Relay receives a nonzero lifetime in a DHCP Advertise 1199 message from one of the DHCP Servers responding to the solicitation, 1200 the Relay MAY unicast a new solicitation to that server before 1201 the lifetime expires, even if that occurs before the passing of 1202 RELAY_DISCOVERY_PERIOD seconds. Such a unicast solicitation MUST 1203 have the 'A' bit set, the address of the agent's interface for 1204 which DHCP Server addresses are desired, and finally the 'L' bit 1205 not set (no link-local address present). If the relay receives a 1206 DHCP advertisement with the 'A' bit set, and the 'L' bit not set, 1207 the relay MAY cache the server addresses even though no link-local 1208 address is present. 1210 The Relay MUST strip off all extensions to DHCP Advertise messages 1211 before storing them in its cache of DHCP Server addresses, except 1212 where specifically noted in the specification of particular DHCP 1213 extensions. 1215 7.2. DHCP Request Message Processing 1217 When a relay receives a DHCP Request message, it MUST check that the 1218 message is received from a link-local address, that the link-local 1219 address matches the link-local address field in the Request message 1220 header, and that the agent address field of the message matches an 1221 IP address associated to the interface from which the DHCP Request 1222 message was received. If any of these checks fail, the Relay MUST 1223 silently discard the Request message. 1225 The relay MUST also check whether the 'S' bit is set in the message 1226 header. If not, the datagram is discarded, and and the relay SHOULD 1227 return a DHCP Reply message to the source address of the Request 1228 message with error code 18. 1230 If the received request message is acceptable, the relay then 1231 transmits the DHCP Request message to the DHCP server found in the 1232 Server Address field of the received DHCP Request message. All 1233 of the fields of DHCP Request message header transmitted by the 1234 relay are copied over unchanged from the DHCP Request received from 1235 the client. Only the fields in the IP header will differ from the 1236 datagram received from the client, not the payload. If the Relay 1237 receives an ICMP error, the Relay SHOULD return a DHCP Reply message 1238 to the client address (which can be found in the payload of the ICMP 1239 message [2]), with error code 64. 1241 7.3. DHCP Reply Message Processing 1243 When the relay receives a DHCP Reply, it MUST check whether 1244 the message has the 'L' bit set. It must check whether the 1245 link-local address field contains an IP address that has prefix 1246 FE80:00:00:00/64. If all the checks are satisfied, the relay MUST 1247 send a DHCP Reply message to the link-local address listed in the 1248 received Reply message. Only the fields in the IP header will differ 1249 from the datagram received from the server, not the payload. 1251 8. Retransmission and Configuration Variables 1253 When a DHCP client does not receive a DHCP Reply in response to a 1254 pending DHCP Request, the client MUST retransmit the identical DHCP 1255 Request, with the same transaction-ID, to the same server again until 1256 it can be reasonably sure that the DHCP server is unavailable and an 1257 alternative can be chosen. It is important for the DHCP Server to 1258 be sure that its client has received the configuration information 1259 included with the extensions to the DHCP Reply message. All the 1260 actions specified for DHCP Request in this section hold also for DHCP 1261 Release messages received by the DHCP Server. 1263 Likewise, but less commonly, when a DHCP server does not receive a 1264 DHCP Request message in response to its DHCP Reconfigure message to 1265 the client, the server MUST retransmit the identical DHCP Reconfigure 1266 to the client until it is reasonably certain that the client is not 1267 available for reconfiguration. If no corresponding DHCP Request 1268 is ever received by the server, the server MAY erase or deallocate 1269 information as needed from the client's binding. 1271 These retransmissions occur using the following configuration 1272 variables for a DHCP implementation that MUST be configurable by a 1273 client or server: 1275 REPLY_MSG_INITIAL_TIMEOUT 1277 The time in seconds that a DHCP client waits to receive a 1278 server's DHCP Reply before retransmitting a DHCP Request. 1280 Default: 2 seconds. 1282 REPLY_MSG_MIN_RETRANS 1284 The minimum number of DHCP Request transmissions that a DHCP 1285 client should retransmit, before aborting the request, possibly 1286 retrying the Request with another Server, and logging a DHCP 1287 System Error. 1289 Default: 10 retransmissions. 1291 REPLY_MSG_RETRANS_INTERVAL 1293 The time between successive retransmissions of DHCP Request 1294 messages. 1296 Default: 2 seconds. 1298 RECONF_MSG_INITIAL_TIMEOUT 1300 The time in seconds that a DHCP server waits to receive 1301 a client's DHCP Request before retransmitting its DHCP 1302 Reconfigure. 1304 Default: 2 seconds. 1306 RECONF_MSG_MIN_RETRANS 1308 The minimum number of DHCP Reconfigure messages that a DHCP 1309 server should retransmit, before assuming the the client is 1310 unavailable and that the server can proceed with the needed 1311 reconfiguration of that client's resources, and logging a DHCP 1312 System Error. 1314 Default: 10 retransmissions. 1316 RECONF_MSG_RETRANS_INTERVAL 1318 The least time between successive retransmissions of DHCP 1319 Reconfigure messages. 1321 Default: 2 seconds. 1323 RECONF_MSG_MIN_RESP 1325 The minimum amount of time before a client can respond to a 1326 DHCP Reconfigure message sent to a multicast address. 1328 Default: 2 second. 1330 RECONF_MSG_MAX_RESP 1332 The maximum amount of time before a client MUST respond to a 1333 DHCP Reconfigure message sent to a multicast address. 1335 Default: 10 seconds. 1337 RELAY_DISCOVERY_PERIOD 1339 The period fo time between successive attempts by the DHCP 1340 Relay to discovery available DHCP Servers. 1342 Default: 3600 seconds (1 hour). 1344 MAX_SOLICIT_DELAY 1346 The maximum amount of time a prospective client is required 1347 to wait, after determining from a Router Discovery message 1348 that the client should perform stateful address configuration, 1349 before sending a DHCP Solicit to a DHCP Server. 1351 Default: 5 seconds 1353 MAX_ADV_WAIT 1355 The amount of time a client waits to hear DHCP Advertisements 1356 after issuing a DHCP Solicit to the All-DHCP Agents multicast 1357 address. 1359 Default: 5 seconds 1361 Note that, if a client receives a DHCP message which fails 1362 authentication, it should continue to wait for another message which 1363 might be correctly authenticated just as if the failed message had 1364 never arrived; however, receiving such failed messages SHOULD be 1365 logged. 1367 XID_TIMEOUT 1369 The amount of time a DHCP server has to keep track of 1370 client transaction-IDs in order to make sure that client 1371 retransmissions using the same transaction-ID are idempotent. 1373 Default: 10800 seconds 1375 9. Security Considerations 1377 DHCP clients and servers must often be able to authenticate the 1378 messages they exchange. For instance, a DHCP server may wish to be 1379 certain that a DHCP Request originated from the client identified by 1380 the fields included within the 1381 Request message header. Conversely, it is often essential for a DHCP 1382 client to be certain that the configuration parameters and addresses 1383 it has received were sent to it by an authoritative DHCP server. 1384 Similarly, a DHCP server should only accept a DHCP Release message 1385 which seems to be from one of its clients, if it has some assurance 1386 that the client actually did transmit the Release message. At the 1387 time of this writing, there is no generally accepted mechanism useful 1388 with DHCPv4 that can be extended for use with DHCP. 1390 The IPv6 Authentication Header can provide security for DHCP 1391 messages when both endpoints have a suitable IP address. However, 1392 a client often has only a link-local address, and such an address 1393 is not sufficient for a DHCP server which is off-link. In those 1394 circumstances the DHCP relay must be involved, so that the DHCP 1395 message MUST have the relay's address in the IP destination address 1396 field, even though the client aims to deliver the message to the 1397 DHCP server. The DHCP Client-Server Authentication Extension [7] is 1398 intended to be used in these circumstances. 1400 10. Acknowledgements 1402 Thanks to the DHC Working Group for their time and input into the 1403 specification. A special thanks for the consistent input, ideas, 1404 and review by (in alphabetical order) Brian Carpenter, Ralph Droms, 1405 Thomas Narten, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson, 1406 and Phil Wells. 1408 Thanks to Steve Deering and Bob Hinden, who have consistently 1409 taken the time to discuss the more complex parts of the IPv6 1410 specifications. 1412 The authors MUST also thank their employers for the opportunity and 1413 funding to work on DHCP as individuals within the IETF. 1415 A. Related Work in IPv6 1417 The related work in IPv6 that would best serve an implementor 1418 to study is the IPv6 Specification [3], the IPv6 Addressing 1419 Architecture [4], IPv6 Stateless Address Autoconfiguration [11], IPv6 1420 Neighbor Discovery Processing [6], and Dynamic Updates to DNS [12]. 1421 These specifications enable DHCP to build upon the IPv6 work to 1422 provide both robust stateful autoconfiguration and autoregistration 1423 of DNS Host Names. 1425 The IPv6 Specification provides the base architecture and design of 1426 IPv6. A key point for DHCP implementors to understand is that IPv6 1427 requires that every link in the internet have an MTU of 576 octets or 1428 greater (in IPv4 the requirement is 68 octets). This means that a 1429 UDP datagram of 536 octets will always pass through an internet (less 1430 40 octets for the IPv6 header), as long as there are no IP options 1431 prior to the UDP header in the datagram. But, IPv6 does not support 1432 fragmentation at routers and fragmentation must take place end-to-end 1433 between hosts. If a DHCP implementation needs to send a datagram 1434 greater than 536 octets it can either fragment the UDP datagram 1435 in UDP or use Path MTU Discovery [5] to determine the size of the 1436 datagram that will traverse a network path. It is implementation 1437 dependent how this is accomplished in DHCP. 1439 The IPv6 Addressing Architecture specification [4] defines the 1440 address scope that can be used in an IPv6 implementation, and the 1441 various configuration architecture guidelines for network designers 1442 of the IPv6 address space. Two advantages of IPv6 are that multicast 1443 addressing is required, and nodes can create link-local addresses 1444 during initialization of the nodes environment. This means that a 1445 client immediately can configure an IP address at initialization 1446 for an interface, before communicating in any manner on the link. 1447 The client can then use a well-known multicast address to begin 1448 communications to discover neighbors on the link, or to send a DHCP 1449 Solicit and locate a DHCP server or relay. 1451 IPv6 Stateless Address Autoconfiguration [11] (addrconf) specifies 1452 procedures by which a node may autoconfigure addresses based on 1453 router advertisements [6], and the use of a validation lifetime to 1454 support renumbering of addresses on the Internet. In addition the 1455 protocol interaction by which a node begins stateless or stateful 1456 autoconfiguration is specified. DHCP is one vehicle to perform 1457 stateful autoconfiguration. Compatibility with addrconf is a design 1458 requirement of DHCP (see Section 3.1). 1460 IPv6 Neighbor Discovery [6] is the node discovery protocol in IPv6 1461 (replaces and enhances functions of ARP [8]). To truly understand 1462 IPv6 and addrconf it is strongly recommended that implementors 1463 understand IPv6 Neighbor Discovery. 1465 Dynamic Updates to DNS [12] is a specification that supports the 1466 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 1467 the dynamic updates to DNS to now integrate addresses and name space 1468 to not only support autoconfiguration, but also autoregistration in 1469 IPv6. 1471 B. Change History 1473 B.1. Changes from November 95 to February 96 Drafts 1475 Substituted use of client's link-local address for previous uses of 1476 client's interface token. 1478 Reorganized DHCP messages into Solicit/Advertise, Request/Reply, 1479 Release, and Reconfigure. 1481 Made message-specific formats instead of using the same DHCP header 1482 for each message. 1484 Eliminated retransmission message types. 1486 Server commits after receiving DHCP Request, and optimistically 1487 depends on client retransmissions as negative acknowledgement. 1489 Eliminated total-addrs. 1491 Eliminated all definitions and most fields related to allocating IPv6 1492 addresses (moved to the Extensions specification). 1494 Renamed "gateway address" to be "agent address". 1496 Added "Considerations" sections. 1498 B.2. Changes from February 96 to June 96 Drafts 1500 Added language referring to DHCP Client-Server Authentication 1501 extension. 1503 Moved the 'L' bit in the DHCP Reply Message format to save 32 bits. 1505 Added language for multicast Reconfigure message handling. 1507 Added initial capability for the DHCP Relay to multicast and obtain 1508 DHCP Server addresses. 1510 Added capability for Servers to add Extensions to their 1511 Advertisements. 1513 Added 'C' bit to DHCP Solicit for deallocating resources after client 1514 crash. 1516 Added DHCP Advertisement lifetimes for use by DHCP Relay agents that 1517 need to periodically update their list of DHCP servers. 1519 B.3. Changes from June 96 to August 96 Drafts 1521 Since the working group indicated that DHCP solicitation traffic 1522 was not considered to be a significant factor affecting network 1523 load, it was decided to modify the handling of solicitations so 1524 that DHCP relays, by default, multicast DHCP Solicit message to all 1525 DHCP servers at a site. This entailed a number of changes to the 1526 protocol, namely: 1528 - Adding fields to the DHCP Solicit and DHCP Advertise messages to 1529 contain the DHCP client's link-local addresses. 1531 - Adding the 'L' bit to the DHCP Solicit and DHCP Advertise 1532 messages to indicate whether the link-local address is present 1534 - Adding a 'P' bit to the DHCP Solicit message so that the client 1535 can allow the Relay to use its non-default behavior, which is to 1536 return cached DHCP Server addresses to the client in response to 1537 the client's DHCP Solicit message. 1539 - Specified a new multicast address (the All-DHCP-Servers address) 1540 for use by DHCP Relays when "relaying" client solicitations. 1542 Added a random backoff after reboot so that clients' solicitations 1543 don't immediately swamp DHCP Servers after power outages. 1545 Added new multicast addresses for All DHCP Servers and All DHCP 1546 Relays. 1548 C. Comparison between DHCPv4 and DHCPv6 1550 This appendix is provided for readers who will find it useful to see 1551 a model and architecture comparison between DHCPv4 and DHCPv6. There 1552 are three key reasons for the differences: 1554 o IPv6 inherently supports a new model and architecture for 1555 communications and autoconfiguration of addresses. 1557 o DHCPv6 in its design was able to take advantage of the inherent 1558 benefits of IPv6. 1560 o New features were added to support the evolution and the 1561 existence of mature Internet users in the industry. 1563 IPv6 Architecuture/Model Changes: 1565 o The link-local address permits a node to have an address 1566 immediately when the node boots, which means all clients have a 1567 source IP address at all times to locate a server or relay agent 1568 on the local link. 1570 o The need for bootp compatibility and broadcast flags are removed, 1571 which permitted a great deal of freedom in designing the new 1572 packet formats for the client and server interaction. 1574 o Multicast and the scoping methods in IPv6 permitted the design of 1575 discovery packets that would inherently define their range by the 1576 multicast address for the function required. 1578 o Stateful autoconfiguration must coexist and integrate with 1579 stateless autoconfiguration supporting Duplicate Address 1580 Detection and two lease times to facilitate the dynamic 1581 renumbering of addresses and the management of those addresses. 1583 o Multiple addresses per interface are inherently supported in 1584 IPv6. 1586 o Most DHCPv4 options are unnecessary now because the configuration 1587 parameters are either obtained through IPv6 Neighbor Discovery or 1588 the Service Location protocol. 1590 DHCPv6 Architecture/Model Changes: 1592 o The message type is the first byte in the packet. 1594 o IPv6 Address allocations are now handled in a message extension 1595 as opposed to the main header. 1597 o Client/Server bindings are now mandatory and take advantage of 1598 the client's link-local address to always permit communications 1599 either directly from an on-link server, or from a remote server 1600 through an on-link relay-agent. 1602 o Servers are now discovered by a client solicit and server or 1603 relay-agent advertisement model. 1605 o The client will know if the server is on-link or off-link. 1607 o The client after a solicit will be returned the addresses of 1608 available servers either from an on-link server or from an 1609 on-link relay-agent as agents providing the advertisements. 1611 o The on-link relay-agent will obtain the location of remote server 1612 addresses from system configuration or by the use of a site wide 1613 DHCPv6 Multicast packet. 1615 o The protocol is optimized and removes the use of ACKs and NAKs 1616 once the client and server set-up is complete. 1618 o The server assumes the client receives its responses unless it 1619 receives a retransmission of the same client request. This 1620 permits recovery in the case where the network has faulted. 1622 o DHCPINFORM is inherent in the new packet design; a client can 1623 request configuration parameters other than IPv6 addresses in the 1624 optional extension headers. 1626 o Clients must listen to their UDP port for the new Reconfigure 1627 message type from servers, unless they join the appropriate 1628 multicast group as specified by the DHCP server. 1630 o Dynamic Updates to DNS are supported in the IPv6 Address 1631 extension. 1633 o New extensions have been defined. 1635 New Internet User Features: 1637 o Configuration of Dynamic Updates to DNS to support multiple 1638 implementation policy requirements. 1640 o Configuration of what policy is enforced when addresses are 1641 deprecated for dynamic renumbering can be implemented. 1643 o Configuration of how relay-agents locate remote servers for a 1644 link can be implemented. 1646 o An Authentication extension has been added. 1648 o Configuration of additional addresses for server applications can 1649 be requested by a client in an implementation. 1651 o Configuration of reclaiming infinite leases can be implemented 1652 using the Reconfigure message type. 1654 o Configuration of tightly coupled integration between stateless 1655 and stateful address autoconfiguration can be implemented. 1657 References 1659 [1] S. Bradner and A. Mankin. The Recommendation for the IP Next 1660 Generation Protocol. RFC 1752, January 1995. 1662 [2] A. Conta and S. Deering. Internet Control Message Protocol 1663 (ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885, 1664 December 1995. 1666 [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1667 Specification. RFC 1883, December 1995. 1669 [4] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 1670 RFC 1884, December 1995. 1672 [5] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP 1673 version 6. RFC 1981, August 1996. 1675 [6] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 1676 IP Version 6 (IPv6). draft-ietf-ipngwg-discovery-06.txt -- work 1677 in progress, March 1996. 1679 [7] C. Perkins. Extensions to DHCPv6. draft-ietf-dhc-dhcpv6ext-02.txt 1680 -- work in progress, June 1996. 1682 [8] David C. Plummer. An Ethernet Address Resolution Protocol: 1683 Or Converting Network Protocol Addresses to 48.bit Ethernet 1684 Addresses for Transmission on Ethernet Hardware. RFC 826, 1685 November 1982. 1687 [9] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 1689 [10] J. B. Postel, Editor. Internet Protocol. RFC 791, September 1690 1981. 1692 [11] S. Thomson and T. Narten. IPv6 Stateless Address 1693 Autoconfiguration. draft-ietf-addrconf-ipv6-auto-06.txt 1694 - work in progress, November 1995. 1696 [12] S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the 1697 Domain Name System (DNS). draft-ietf-dnsind-dynDNS-06.txt -- 1698 work in progress, February 1996. 1700 Chair's Address 1702 The working group can be contacted via the current chair: 1704 Ralph Droms 1705 Computer Science Department 1706 323 Dana Engineering 1707 Bucknell University 1708 Lewisburg, PA 17837 1710 Phone: (717) 524-1145 1711 E-mail: droms@bucknell.edu 1713 Author's Address 1715 Questions about this memo can be directed to: 1717 Jim Bound Charles Perkins 1718 Digital Equipment Corporation T. J. Watson Research Center 1719 110 Spitbrook Road, ZKO3-3/U14 IBM Corporation 1720 Nashua, NH 03062 30 Saw Mill River Rd., Rm H3-D34 1721 Hawthorne, NY 10532 1722 Phone: +1-603-881-0400 +1-914-784-7350 1723 Fax: +1-914-784-6205 1724 E-mail: bound@zk3.dec.com perk@watson.ibm.com