idnits 2.17.1 draft-ietf-dhc-dhcpv6-05.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-25) 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 152: '... MUST This word, or the ...' RFC 2119 keyword, line 156: '... MUST NOT This phrase means ...' RFC 2119 keyword, line 159: '... SHOULD This word, or the ...' RFC 2119 keyword, line 166: '... MAY This word, or the ...' RFC 2119 keyword, line 169: '... MUST be prepared to i...' (92 more instances...) -- The draft header indicates that this document obsoletes draft-ietf-dhc-dhcpv6-04.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- -- No information found for rfcdraft-ietf-dhc-dhcpv6-04.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 (12 June 1996) is 10179 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 1883 (ref. '2') (Obsoleted by RFC 2460) -- Duplicate reference: RFC1883, mentioned in '3', was also mentioned in '2'. ** Obsolete normative reference: RFC 1883 (ref. '3') (Obsoleted by RFC 2460) == Outdated reference: A later version (-06) exists of draft-ietf-ipngwg-discovery-03 -- No information found for draft-ietf-dhc-dhcpv6ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' == 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: 12 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force J. Bound 2 INTERNET DRAFT Digital Equipment Corp. 3 DHC Working Group C. Perkins 4 Obsoletes: draft-ietf-dhc-dhcpv6-04.txt IBM Research 5 12 June 1996 7 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 8 draft-ietf-dhc-dhcpv6-05.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 (DHCP) provides a framework 37 for passing configuration information, via extensions, to IPv6 hosts. 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 50 1.1. Specification Language . . . . . . . . . . . . . . . . . 1 52 2. Terminology and Definitions 2 53 2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2 54 2.2. DHCPv6 Terminology . . . . . . . . . . . . . . . . . . . 3 56 3. Protocol Design Model 4 57 3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 5 58 3.2. DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 6 59 3.3. Request/Response Processing Model . . . . . . . . . . . . 7 61 4. DHCPv6 Message Formats and Field Definitions 7 62 4.1. UDP Ports used for DHCPv6 messages . . . . . . . . . . . 7 63 4.2. DHCP Solicit Message Format . . . . . . . . . . . . . . . 8 64 4.3. DHCP Advertise Message Format . . . . . . . . . . . . . . 8 65 4.4. DHCP Request Message Format . . . . . . . . . . . . . . . 10 66 4.5. DHCP Reply Message Format . . . . . . . . . . . . . . . . 11 67 4.6. DHCP Release Message Format . . . . . . . . . . . . . . . 12 68 4.7. DHCP Reconfigure Message Format . . . . . . . . . . . . . 14 70 5. DHCP Client Considerations 15 71 5.1. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 15 72 5.2. Receiving DHCP Advertise Messages . . . . . . . . . . . . 15 73 5.3. Sending DHCP Request Messages . . . . . . . . . . . . . . 16 74 5.4. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 17 75 5.5. Sending DHCP Release Messages . . . . . . . . . . . . . . 18 76 5.6. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 18 78 6. DHCP Server Considerations 19 79 6.1. Receiving DHCP Solicit Messages . . . . . . . . . . . . . 19 80 6.2. Sending DHCP Advertise Messages . . . . . . . . . . . . . 19 81 6.3. DHCP Request and Reply Messages . . . . . . . . . . . . . 20 82 6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 21 83 6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . . 22 85 7. DHCP Relay Considerations 22 86 7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 23 87 7.2. DHCP Request Message Processing . . . . . . . . . . . . . 23 88 7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 24 89 7.4. Retransmission and Configuration Variables . . . . . . . 24 91 8. Security Considerations 26 93 9. Acknowledgements 27 95 A. Related Work in IPv6 27 97 B. Change History 29 98 B.1. Changes from November 95 to February 96 Drafts . . . . . 29 99 B.2. Changes from February 96 to June 96 Drafts . . . . . . . 29 101 C. Comparison between DHCPv4 and DHCPv6 29 103 Chair's Address 34 105 Author's Address 34 106 1. Introduction 108 The Dynamic Host Configuration Protocol (DHCP) provides configuration 109 parameters to Internet hosts. DHCP consists of a protocol for 110 delivering host-specific configuration parameters from a DHCP server 111 to a host, and a mechanism for allocation of network addresses and 112 other related parameters to IPv6 hosts. 114 DHCP is built on a client-server model, where designated DHCP 115 server hosts allocate network addresses and automatically deliver 116 configuration parameters to dynamically configured hosts. Throughout 117 the remainder of this document, the term "server" refers to a host 118 providing initialization parameters through DHCP, and the term 119 "client" refers to a host requesting initialization parameters from 120 a DHCP server. DHCPv6 servers maintain state for their clients, 121 in contrast to IPv6 Stateless Address Autoconfiguration [9], 122 where IPv6 hosts should get the same results if they repeat the 123 autoconfiguration procedure multiple times. 125 DHCPv6 uses Request and Reply messages to support a client/server 126 processing model whereby both client and server are assured that 127 requested configuration parameters have been received and accepted by 128 the client. DHCPv6 supports optional configuration parameters and 129 processing for hosts through its companion document Extensions for 130 the Dynamic Host Configuration Protocol for IPv6 [5]. 132 The IPv6 Addressing Architecture [3] and IPv6 Stateless Address 133 Autoconfiguration specifications provide new features not available 134 in IP version 4 (IPv4) [8], which are used to simplify and generalize 135 the operation of DHCPv6 clients. 137 Section 2 provides definitions for terminology used throughout this 138 document. Section 3 provides a overview of the protocol design model 139 that guides the design choices in the specification; section 3.2 140 briefly describes the protocol messages and their semantics. 141 Section 4 provides the message formats and field definitions used for 142 each message. Sections 5, 6, and 7 specify how clients, servers, 143 and relays interact. Appendix A summarizes related work in IPv6 that 144 will provide helpful context; it is not part of this specification, 145 but included for informational purposes. 147 1.1. Specification Language 149 In this document, several words are used to signify the requirements 150 of the specification. These words are often capitalized. 152 MUST This word, or the adjective "required", means that 153 the definition is an absolute requirement of the 154 specification. 156 MUST NOT This phrase means that the definition is an absolute 157 prohibition of the specification. 159 SHOULD This word, or the adjective "recommended", means 160 that there may exist valid reasons in particular 161 circumstances to ignore this item, but the full 162 implications must be understood and carefully 163 weighed before choosing a different course. 164 Unexpected results may result otherwise. 166 MAY This word, or the adjective "optional", means that 167 this item is one of an allowed set of alternatives. 168 An implementation which does not include this option 169 MUST be prepared to interoperate with another 170 implementation which does include the option. 172 silently discard 173 The implementation discards the datagram without 174 further processing, and without indicating an error 175 to the sender. The implementation SHOULD provide 176 the capability of logging the error, including the 177 contents of the discarded datagram, and SHOULD 178 record the event in a statistics counter. 180 2. Terminology and Definitions 182 Relevant terminology from the IPv6 Protocol [2], IPv6 Addressing 183 Architecture, and IPv6 Stateless Address Autoconfiguration will be 184 provided, and then the DHCPv6 terminology. 186 2.1. IPv6 Terminology 188 IP Internet Protocol Version 6 (IPv6). The terms IPv4 and 189 IPv6 are used only in contexts where necessary to avoid 190 ambiguity. 192 node A device that implements IPv6. 194 router A node that forwards IPv6 datagrams not explicitly 195 addressed to itself. 197 host Any node that is not a router. 199 link A communication facility or medium over which nodes 200 can communicate at the link layer, i.e., the layer 201 immediately below IPv6. Examples are Ethernet (simple 202 or bridged); PPP links, X.25, Frame Relay, or ATM 203 networks; and internet (or higher) layer "tunnels", 204 such as tunnels over IPv4 or IPv6 itself. 206 link-layer identifier 207 a link-layer identifier for an interface. Examples 208 include IEEE 802 addresses for Ethernet links, and 209 E.164 addresses for ISDN links. 211 link-local address 212 An address having link-only scope that can be used to 213 reach neighboring nodes attached to the same link. All 214 interfaces have a link-local address. 216 neighbors 217 Nodes attached to the same link. 219 interface 220 A node's attachment to the link. 222 address An IP layer identifier for an interface or a set of 223 interfaces. 225 message The data exchanged between DHCP agents and clients; in 226 this specification, messages are delivered via IPv6 and 227 UDP. 229 datagram An IP header plus payload. 231 unicast address 232 An identifier for a single interface. A datagram sent 233 to a unicast address is delivered to the interface 234 identified by that address. 236 multicast address 237 An identifier for a set of interfaces (typically 238 belonging to different nodes). A datagram sent to 239 a multicast address is delivered to all interfaces 240 identified by that address. 242 2.2. DHCPv6 Terminology 244 configuration parameter 245 Any parameter that can be used by a node to configure 246 its network environment and enable communication on a 247 link or internetwork. 249 client A host that initiates requests on a link to obtain 250 configuration parameters. 252 server A server is a node that responds to requests from 253 clients on a link to provide: addresses, dynamic 254 updates to DNS, or other configuration parameters. 256 relay A node that may advertise DHCP server addresses, or may 257 act as an intermediary to deliver DHCP messages between 258 clients and servers. 260 DHCP Agent 261 Either a DHCPv6 server or a DHCPv6 relay. 263 agent address 264 The address of a neighboring DHCP relay or DHCP server 265 on the same link as the DHCP client. 267 msg-type The msg-type defines the DHCPv6 protocol type for a 268 message. 270 transaction-ID 271 The transaction-ID is a monotonically increasing 272 integer identifier specified by the client and is used 273 by the client to match a DHCP Reply to a pending DHCP 274 Request. 276 server address 277 The server address specifies the address for the server 278 responding to a client. 280 binding A binding in DHCPv6 contains the data which a DHCPv6 281 server MUST maintain for each of its clients. An 282 implementation MUST support bindings consisting of at 283 least a client's link-local address, agent address, 284 preferred lifetime and valid lifetime [9] for each 285 client address, and the transaction-ID. 287 3. Protocol Design Model 289 This section is provided for implementors to understand the DHCPv6 290 protocol design model from an architectural perspective. The goals, 291 conceptual models and implementation examples presented in this 292 section do not specify requirements of the DHCPv6 protocol. 294 3.1. Design Goals 296 The following list gives general design goals for this DHCPv6 297 specification. 299 - DHCPv6 should be a mechanism rather than a policy. DHCPv6 must 300 allow local system administrators control over configuration 301 parameters where desired; e.g., local system administrators 302 should be able to enforce local policies concerning allocation 303 and access to local resources where desired. 305 - DHCPv6 MUST NOT introduce any requirement for manual 306 configuration of DHCPv6 client hosts, except possibly for 307 manually configured keys. Each host should be able to discover 308 appropriate local configuration parameters without user 309 intervention, and incorporate those parameters into its own 310 configuration. 312 - DHCPv6 MUST NOT require a server on each link. To allow for 313 scale and economy, DHCPv6 must work across relay agents. 315 - A DHCPv6 client must be prepared to receive multiple responses to 316 solicitations for DHCP servers. Some installations may include 317 multiple, overlapping DHCPv6 servers to enhance reliability 318 and/or to increase performance. 320 - DHCPv6 must coexist with statically configured, non-participating 321 hosts and with existing network protocol implementations. 323 - DHCPv6 MUST be compatible with IPv6 Stateless Address 324 Autoconfiguration. 326 - DHCPv6 must support the requirements of automated renumbering of 327 IPv6 addresses [1]. 329 - DHCPv6 servers should be able to support Dynamic Updates to 330 DNS [10]. 332 - DHCPv6 servers MUST be able to handle multiple IPv6 addresses for 333 each client. 335 - A DHCPv6 server to server protocol is NOT part of this DHCPv6 336 specification. 338 - It is NOT a design goal of DHCPv6 to specify how a server 339 configuration parameter database is maintained or determined. 340 Methods for configuring DHCP servers are outside the scope of 341 this document. 343 3.2. DHCPv6 Messages 345 Each DHCPv6 message contains a type, which defines their function 346 within the protocol. The message types are as follows: 348 01 DHCP Solicit 350 The DHCP Solicit message is a DHCPv6 multicast (or in special 351 circumstances unicast) message from a client to one or more 352 neighboring DHCPv6 Agents. 354 02 DHCP Advertise 356 The DHCP Advertise is an IPv6 unicast message from a DHCP Agent 357 in response to a client DHCP Solicit message. 359 03 DHCP Request 361 The DHCP Request is an IPv6 unicast message from a client to 362 a server, when the client knows the IPv6 unicast address of a 363 server, to request configuration parameters on a network. 365 04 DHCP Reply 367 The DHCP Reply is an IPv6 unicast message sent by a server to 368 respond to a client's DHCP Request. Extensions [5] to the DHCP 369 Reply describe the resources that the DHCP Server has committed 370 and allocated to the client, and may contain other information 371 for use by the client. 373 05 DHCP Release 375 The DHCP Release message is used by a DHCPv6 client to inform 376 the server that the client is releasing a particular address, 377 or set of addresses or resources, so that the server may 378 subsequently mark the addresses or resources as invalid in the 379 server's binding for the client. 381 06 DHCP Reconfigure 383 The DHCP Reconfigure message is used by a DHCPv6 server 384 to inform the client that the server has new configuration 385 information of importance to the client. The client is 386 expected to initiate a new Request/Reply transaction. 388 3.3. Request/Response Processing Model 390 Processing details for the DHCP messages listed above are specified 391 in Sections 5, 6, and 7. 393 The request/response processing for DHCPv6 is transaction based 394 and uses a best-effort set of messages to guarantee a completed 395 transaction. The timeout and retransmission guidelines and 396 configuration variables are discussed in Section 7.4. 398 The request/response set is always started by a client with a DHCP 399 Request, which may be issued after the client knows the server's 400 address. The response message or messages (the DHCP Reply) are is 401 from the server (possibly via a DHCP Relay). At this point in the 402 flow all data has been transmitted and, hopefully, received. To 403 provide a method of recovery if either the client or server do not 404 receive the messages to complete the transaction, the client is 405 required to retransmit any DHCP Request message until it elicits a 406 DHCP Reply, or until it can be reasonably certain that the desired 407 DHCP Server is unavailable. 409 4. DHCPv6 Message Formats and Field Definitions 411 All fields in DHCPv6 messages MUST be initialized to binary zeroes by 412 both the client and server unless otherwise noted. DHCPv6 message 413 types not defined here (msg-types 0 and 7-255) are reserved. 415 All DHCP Agents MUST join the DHCPv6 Server/Relay-Agent multicast 416 group at the well-known multicast address FF02:0:0:0:0:0:1:0. All 417 DHCP Servers MUST join the DHCPv6 Server multicast group at the 418 well-known multicast address FF02:0:0:0:0:0:tbd. 420 Servers on the same link as the client MUST use the source address 421 in the IPv6 header from the client as the destination address in the 422 server's response message. 424 4.1. UDP Ports used for DHCPv6 messages 426 DHCPv6 uses the UDP [7] protocol to communicate between clients 427 and servers. UDP is not reliable, but DHCPv6 must provide some 428 reliability between clients and servers. If a response is not 429 received after transmission of a DHCP message, the message MUST be 430 retransmitted according to the rules specified in 7.4. 432 A Client MUST transmit all messages over UDP using UDP port 547 as 433 the destination port. A client MUST receive all messages from UDP 434 port 546. 436 A DHCP Agent MUST transmit all messages over UDP using UDP port 546 437 as the destination port. A DHCP Agent MUST receive all messages over 438 UDP using UDP port 547. 440 4.2. DHCP Solicit Message Format 442 A DHCPv6 client transmits a DHCP Solicit message to obtain the 443 address of a neighboring DHCP Agent, and to obtain one or more 444 addresses for DHCP servers which the DHCP Agent is configured to 445 advertise. If a DHCPv6 client does not know any DHCP Agent address, 446 or wants to locate a new server to receive configuration parameters, 447 the client SHOULD use, as the destination IP address, the DHCPv6 448 Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0. 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | msg-type | msg-flags | RESERVED | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 msg-type 1 458 msg-flags 0 460 RESERVED 0 462 4.3. DHCP Advertise Message Format 464 A DHCPv6 agent sends a DHCP Advertise message to inform a prospective 465 client about the IPv6 address of a DHCP Agent to which a DHCP Request 466 message may be sent. 468 A DHCPv6 agent MAY periodically transmit DHCP Advertise messages to 469 the All-DHCPv6 Clients multicast address, no more often than once per 470 second, and with TTL == 1. 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | msg-type |S| rsvd | server-count | reserved | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | agent address | 478 | (16 octets) | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | server addresses | 481 | (16 octets each) | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | extensions (variable number and length) ... 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 msg-type 2 488 S If set, the agent address is also a server address. 490 T If set, the advertisement contains a time interval 491 which is the lifetime of the advertisement. 493 rsvd 0 495 server-count 496 The number of addresses listed in the server 497 addresses field. 499 reserved 0 501 agent address 502 The IPv6 address of a neighboring DHCP Agent 503 interface 505 server addresses 506 The IPv6 address(es) of the DHCPv6 server(s) which 507 the DHCP Agent has been configured to advertise. 509 extensions See [5]. 511 Note that if a neighboring DHCPv6 server issues the DHCP Advertise, 512 then the agent address will be the IPv6 address of one of the 513 server's interfaces, the 'S' bit will be set, the agent address will 514 be an address of the server, and there may be zero server addresses 515 sent in the DHCP Advertise message. It is an error for server-count 516 to be zero if the 'S' bit is not set. 518 4.4. DHCP Request Message Format 520 In order to request parameters from a DHCP server, a client sends a 521 DHCP Request message and appends the appropriate extensions [5]. If 522 the client does not know any DHCPv6 server address, it must first 523 obtain a server address by multicasting a DHCP Solicit message (see 524 Section 4.2). If the client does not have a valid IPv6 address 525 which is reachable by the DHCPv6 server, the client MUST use the 526 unicast IP address of a local DHCPv6 relay as the destination IP 527 address. Otherwise, the client MAY omit the server address in the 528 DHCP Request message; in this case, the client MUST send the DHCP 529 Request message directly to the server, using the server address as 530 the IPv6 destination address in the IPv6 header. 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | msg-type |S|C| reserved | transaction-ID | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | (if present) | 538 | server address (16 octets) | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | agent address | 541 | (16 octets) | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | link-local address | 544 | (16 octets) | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | extensions (variable number and length) .... 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 msg-type 3 551 S If set, the server address is present 553 C If set, the client requests the server to clear all 554 existing resources and bindings currently associated 555 with the client, deallocating as needed. 557 reserved 0 559 transaction-ID 560 A monotonically increasing number which the client asks 561 the server to copy into its DHCP Reply, so that the 562 client can match Replies with pending Requests. 564 server address 565 If present, the IPv6 address of the DHCPv6 server which 566 should receive the client's DHCP Request message. 568 agent address 569 The IPv6 address of the relay or server interface from 570 which the client received the DHCP Advertise message 572 link-local address 573 The IPv6 link-local address of the client interface 574 from which the the client issued the DHCP Request 575 message 577 extensions See [5]. 579 4.5. DHCP Reply Message Format 581 The server sends at least one DHCP Reply message in response to 582 every DHCP Request received. If the request comes with the 'S' bit 583 set, the client could not directly send the Request to the server 584 and had to use a neighboring relay agent. In that case, the server 585 sends back the DHCP Reply with the 'L' bit set, and the DHCP Reply is 586 addressed to the agent address found in the DHCP Request message. If 587 the 'L' bit is set, then the client's link-local address will also be 588 present. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | msg-type |L| error code | transaction-ID | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | (if present) | 596 | link-local address (16 octets) | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | extensions (variable number and length) .... 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 msg-type 3 603 L If set, the link-local address is present 604 error code 605 One of the following values: 607 0 Success 608 16 Failure, reason unspecified 609 17 Authentication failed or nonexistent 610 18 Poorly formed request 611 19 Resources unavailable 612 20 Client record unavailable 613 21 Invalid source address in Release 614 22 Unable to honor mandatory request 615 24 Bad Hair Day 616 32 Insufficient Funds 617 64 Server unreachable (ICMP error) 619 transaction-ID 620 Copied from the transaction-ID which the DHCPv6 server 621 received in the DHCP Request. to help the client match 622 this reply with an outstanding Request. 624 link-local address 625 If present, the IPv6 address of the client interface 626 which issued the corresponding DHCP Request message. 628 extensions 629 See [5]. 631 If the 'L' bit is set, and thus the link-local address is present in 632 the Reply message, the Reply is sent by the server to the relay's 633 address which was specified as the agent address in the DHCP Request 634 message, and the relay uses the link-local address to deliver the 635 Reply message to the client. Error Code 22 MUST be sent only in the 636 case that the Server could otherwise honor the requested resource, 637 if the client had not made the parameter values (included in the 638 relevant Extension requesting the resource) mandatory for the server 639 to obey. 641 4.6. DHCP Release Message Format 643 The DHCP Release message is sent without the assistance of any DHCPv6 644 relay. When a client sends a Release message, it is assumed to 645 have a valid IPv6 address with sufficient scope to allow access to 646 the target server. Only the parameters which are specified in the 647 extensions are released. The DHCP server acknowledges the Release 648 message by sending a DHCP Reply (Section 6.3). 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | msg-type |D| msg-flags | transaction-ID | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | agent address | 656 | (16 octets) | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | link-local address | 659 | (16 octets) | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | extensions (variable number and length) .... 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 msg-type 5 666 D If the 'D' ("Direct") flag is set, the client instructs 667 the server to send the DHCP Reply directly back to the 668 client, instead of using the given agent address and 669 link-local address to relay the Reply message. 671 msg-flags 0 673 transaction-ID 674 A monotonically increasing number which the client asks 675 the server to use in its DHCP Reply, to help the client 676 match Replies with outstanding Releases. 678 agent address 679 The IPv6 address of the agent interface to which the 680 client issued the DHCP Request message 682 link-local address 683 The IPv6 link-local address of the client interface 684 from which the the client issued the DHCP Request 685 message 687 extensions See [5] 689 Suppose that the client knows that the address it uses as the source 690 IP address in its IPv6 header will still be valid after the server 691 performs the operations requested in the extensions to the DHCP 692 Release message. In that case, and only then, the client SHOULD then 693 specify the 'D' flag. When the 'D' flag is set, the server MUST send 694 the DHCP Reply back to the client's address as shown in the source 695 address of the IPv6 header of the Release message. Otherwise, when 696 the 'D' bit is not set, the server MUST use the agent address and 697 link-local address in its DHCP Reply message to forward the Reply 698 message back to the releasing client. 700 4.7. DHCP Reconfigure Message Format 702 The DHCP Reconfigure message is sent without the assistance of any 703 DHCPv6 relay. When a server sends a Reconfigure message, the client 704 to which it is sent is assumed to have a valid IPv6 address with 705 sufficient scope to be accessible by the server. Only the parameters 706 which are specified in the extensions to the Reconfigure message need 707 be requested again by the client. 709 The client SHOULD listen at UDP port 546 to receive possible DHCP 710 Reconfigure messages, except in cases where the client knows that 711 no Reconfigure message will ever be issued. If the client does not 712 listen for DHCP Reconfigure messages, it is possible that the client 713 will not receive notification that its DHCP server has deallocated 714 the client's IPv6 address and/or other resources allocated to the 715 client. 717 See discussion in 6.5. 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | msg-type |C| msg-flags | reserved | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | extensions (variable number and length) .... 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 msg-type 6 729 msg-type If set, the DHCPv6 client requests that all servers 730 receiving the message deallocate the resources 731 associated with the client. 733 msg-flags 0 735 reserved 0 737 extensions See [5] 739 5. DHCP Client Considerations 741 A DHCPv6 client MUST silently discard any DHCP Solicit, DHCP Request, 742 or DHCP Release message it receives. 744 A DHCPv6 client should retain its configured parameters and resources 745 across client system reboots and DHCPv6 client program restarts. 746 However, in these circumstances a DHCPv6 client SHOULD also formulate 747 a DHCP Request message to verify that its configured parameters and 748 resources are still valid. This Request message MUST have the 'C' 749 bit set, to clear client binding information at the server, of which 750 the client may no longer have any record. 752 5.1. Sending DHCP Solicit Messages 754 If a node wishes to become a new DHCPv6 client, it must first locate 755 a neighboring DHCP Agent. The client does this by multcasting 756 a DHCP Solicit message to the well-known multicast address 757 FF02:0:0:0:0:0:1:0 (All DHCP Agents Address), setting the TTL == 1. 759 By setting the 'C' bit in the Solicitation, a DHCPv6 client requests 760 that all the DHCP Servers that receive the solicitation should 761 deallocate their client records that match its link-local address. 763 5.2. Receiving DHCP Advertise Messages 765 When a DHCPv6 client receives a DHCP Advertise message, it may 766 formulate a DHCP Request message to receive configuration information 767 and resources from the DHCP servers listed in the advertisement. If 768 the Advertise message has zero server addresses and does not have the 769 'S' bit set, the client MUST silently discard the message. If the 770 server's address is shown as a Multicast address, the advertisement 771 MUST be silently discarded. 773 If the 'S' bit is set, the DHCP Advertise message was transmitted by 774 a DHCPv6 server on the same link as the client. In this case, the 775 client MUST use the agent address as the address of its server for 776 future DHCPv6 message transactions. Also in this case, the Advertise 777 message may have Extensions; this might allow the DHCPv6 client to 778 select the configuration that best meets its needs from among several 779 prospective servers. 781 5.3. Sending DHCP Request Messages 783 A DHCPv6 client obtains configuration information from a DHCPv6 784 server by sending a DHCP Request message. The client must know the 785 server's address before sending the Request message. In addition, 786 the client must have acquired a valid DHCP agent address. If the 787 client and server are on the same link, the agent address used by the 788 client MUST be the same as the DHCP server's address. A DHCP Request 789 message MUST NOT be sent to any multicast address, since otherwise 790 multiple DHCP agents would possibly allocate resources to the client 791 in response to the same Request, and the client would have no way to 792 know which servers had made the allocations. 794 If the client has no valid IPv6 address and the DHCP server is 795 off-link, then the client MUST include the server address in the 796 appropriate field of the DHCP Request message and set the 'S' bit. 797 In this case, the IPv6 destination address of the Request message 798 MUST be the agent address. 800 Otherwise, if the client already has a valid IPv6 address and knows 801 the IPv6 address of a candidate IPv6 server, it MUST send the Request 802 message directly to the DHCPv6 server without requiring the services 803 of the local DHCPv6 relay. 805 If a client wishes to instruct a DHCP server to deallocate all 806 previous resources, configuration information, and bindings 807 associated with its agent address and link-local address, it sets the 808 'C' bit in the DHCP Request. A client MAY send in such a Request 809 even when it is no longer attached to the link on which the relay 810 address is attached. 812 A client MAY maintain information about which relay address and 813 server address it has been using for use after a reboot. Even so, 814 after a reboot the client MUST issue its next DHCP Request with the 815 'C' bit set. 817 In any case, after choosing a transaction-ID which is numerically 818 greater than its previous transaction-ID, and filling in the 819 appropriate fields of the DHCP Request message, the client MAY append 820 various DHCPv6 Extensions to the message. These Extensions denote 821 specific requests by the client; for example, a client may request 822 a particular IP address, or request that the server send an update 823 containing the client's new IP address to a Domain Name Server. When 824 all Extensions have been applied, the DHCPv6 client unicasts the DHCP 825 Request to the appropriate DHCP Agent. 827 For each pending DHCP Request message, a client MUST maintain the 828 following information: 830 - The transaction-ID of the Request message, 832 - The server address, 834 - The agent address, 836 - The time at which the next retransmission will be attempted, and 838 - All Extensions appended to the request message. 840 If a client does not receive all the relevant DHCP Reply messages 841 with the same transaction-ID as a pending DHCP Request message within 842 REPLY_MSG_INITIAL_TIMEOUT seconds, it MUST retransmit the Request 843 with the same transaction-ID and continue to retransmit according to 844 the rules in Section 7.4. 846 5.4. Receiving DHCP Reply Messages 848 When a client receives a DHCP Reply message, it MUST check whether 849 the transaction-ID in the Reply message matches the transaction-ID 850 of a pending DHCP Request message. If no match is found, the Reply 851 message MUST be silently discarded, and an error SHOULD be logged. 852 If the transaction-ID matches that of a pending Request, and the 'L' 853 bit is set, but the source address in the IPv6 header does not match 854 the pending agent address, the client MUST discard the message, and 855 SHOULD log the event. Likewise, if the transaction-ID matches that 856 of a pending Request, and the 'L' bit is not set, but the source 857 address in the IPv6 header does not match the pending server address, 858 the client MUST discard the message, and SHOULD log the event. 860 If the Reply message is acceptable, the client processes each 861 Extension [5], extracting the relevant configuration information 862 and parameters for its network operation. The Error Code found in 863 the Reply message applies to all extensions found in the Reply. If 864 all expected extensions are not found in the same Reply message, 865 then they are likely to be located in another Reply, possibly 866 with a different Error Code, but with the same Transaction ID. The 867 DHCPv6 Client MUST continue processing DHCP Reply messages until all 868 requested extensions are accounted for. If some requested extensions 869 are not accounted for within DHCP Reply messages sent by the server, 870 the client MUST reissue the entire DHCPv6 Request again, with all 871 extensions, and the same Transaction ID. 873 Some configuration information extracted from the Extensions to the 874 DHCP Reply message must remain associated with the DHCP server that 875 sent the message. The particular extensions that require this extra 876 measure of association with the server are indicated in the DHCPv6 877 Extensions document [5]. These associations may be useful with DHCP 878 Release messages. 880 5.5. Sending DHCP Release Messages 882 If a DHCPv6 client determines that some of its network configuration 883 parameters are no longer needed, it may enable the DHCPv6 server to 884 release allocated resources which are no longer in use by sending 885 a DHCP Release message to the server. The client must consult its 886 list of resource-server associations in order to determine which 887 server should receive the desired Release message. If a client 888 wishes to ask the server to release all information and resources 889 relevent to the client, the client specifies no Extensions; this is 890 preferable to sending a DHCP Request message with the 'C' bit set and 891 no extensions. 893 Suppoase client wishes to release resources which were granted to 894 it at another link-local address. In that case, the client must 895 instruct the server to send the DHCP Reply directly back to the 896 client, instead of performing the default processing of sending 897 the DHCP Reply back through the agent-address included in the DHCP 898 Release. This is done by setting the 'D' bit in the DHCP Release 899 message. Note that it is an error to include within the DHCP Release 900 message an IPv6 address extension which has the IPv6 address used as 901 the source address of the datagram containing DHCP Release message. 903 5.6. Receiving DHCP Reconfigure Messages 905 If a DHCPv6 client receives a DHCP Reconfigure message, it is 906 a request for the client to initiate a new DHCP Request/Reply 907 transaction with the server which sent the Reconfigure message. 908 The server sending the Reconfigure message MAY be different than 909 the server which sent a DHCP Reply message containing the original 910 configuration information. 912 For each Extension which is present in the Reconfigure message, the 913 client appends a matching Extension to its DHCP Request message 914 which it formulates to send to the DHCPv6 server which is found in 915 the IP source address of the message. The client also selects a 916 transaction-ID numerically greater than its last choice and inserts 917 it into the Request message. From then on, processing is the same as 918 specified above in Section 5.3. 920 Note that a client may be requested by its server to join a multicast 921 group for the purpose of receiving DHCP Reconfigure messages. When a 922 Reconfigure message is delivered to the client by way of the selected 923 multicast address, the client must delay its further response for 924 a random amount of time uniformly distributed within the interval 925 between RECONF_MSG_MIN_RESP and RECONF_MSG_MAX_RESP seconds. This 926 will minimize the likelihood that the server will be bombarded with 927 DHCP Request messages all at the same time. 929 6. DHCP Server Considerations 931 A server MUST ignore any DHCP Advertise, DHCP Reply, or DHCP 932 Reconfigure message it receives. 934 A server uses the combination to 935 index into its client records. A client record (called a "client 936 binding", or sometimes just a "binding") is used to store all the 937 relevant information, resources, and configuration data which will 938 be associated with the client. Each client binding is uniquely 939 identifiable by the ordered pair , 940 since the link-local address is guaranteed to be unique [9] on 941 the link identified by the agent address. A DHCPv6 server should 942 retain its clients' bindings across server reboots, and, whenever 943 possible, a DHCPv6 client should be assigned the same configuration 944 parameters despite server host system reboots and DHCPv6 server 945 program restarts. A DHCPv6 server MUST support fixed or permanent 946 allocation of configuration parameters to specific clients. 948 6.1. Receiving DHCP Solicit Messages 950 If the DHCP Solicit message was received at the All-DHCP-Servers 951 multicast address, the DHCP Server MUST check to make sure that the 952 source address is not a link-local address. If the source address is 953 a link-local address, the server MUST silently discard the packet. 955 6.2. Sending DHCP Advertise Messages 957 Upon receiving and verifying the correctness of a DHCP Solicit 958 message, a server constructs a DHCP Advertise message and transmits 959 it on the same link as the solicitation was received from. The 960 destination address of the advertisement MUST be the source address 961 of the solicitation. The DHCP server must use a IPv6 address of the 962 interface on which it received the Solicit message as the source 963 address field of the IPv6 header of the message. 965 The DHCP server MAY append extensions to the Advertisement, in order 966 to offer the soliciting node the best possible information about 967 the services and resources which the server may be able to make 968 available, should the solicitor choose to subsequently send a DHCP 969 Request to the server. 971 6.3. DHCP Request and Reply Messages 973 The DHCPv6 server MUST check to ensure that a valid link-local 974 address is present in the client's link-local address field of the 975 Request message. If not, the message MUST be silently discarded. 976 Otherwise, it checks for the presence of the 'S' bit. If the 'S' bit 977 is set, the server MUST check that the server address matches the 978 destination IPv6 address at which the Request message was received 979 by the server. If the server address does not match, the Request 980 message MUST be silently discarded. 982 If the received agent address and link-local address do not 983 correspond to any binding known to the server, then the server MAY 984 create a new binding for the previously unknown client; otherwise, it 985 SHOULD return a DHCP Reply with a error code of 5. 987 Before processing the Request, the server must determine whether 988 or not the Request is a retransmission of an earlier DHCP Request 989 from the same client. This is done by comparing the transaction-ID 990 to all those transaction-IDs received from the same client during 991 the previous XID_ID_TIMEOUT seconds. If the transaction-ID is the 992 same as one received during that time, the server MUST take the 993 same action (e.g., retransmit the same DHCP Reply to the client) 994 as it did after processing the previous DHCP Request with the same 995 transaction-ID. 997 Otherwise (the transaction-ID has not been recently used), when the 998 server has identified and allocated all the relevant information, 999 resources, and configuration data that is associated with the client, 1000 it sends that information to its DHCPv6 client by constructing a 1001 DHCP Reply message and including the client's information in DHCPv6 1002 Extensions to the Reply message. The DHCP Reply message uses the 1003 same transaction-ID as found in the received DHCP Request message. 1005 If the DHCP Request message has the 'S' bit set in the message 1006 header, then the Request was sent to the server by a DHCP Relay. In 1007 this case, the DHCPv6 server MUST send the corresponding DHCP Reply 1008 message to the agent address found in the Request (see section 7.2). 1010 The DHCP Request may contain Extensions, which are interpreted 1011 (by default) as advisory information from the client about its 1012 configuration preferences. For instance, if the IP Address Extension 1013 is present, the DHCPv6 server SHOULD attempt to allocate or extend 1014 the lifetime of the address indicated by the Extension. Some 1015 Extensions may be marked by the client as Required. 1017 the DHCP server may accept some extensions for successful processing 1018 and allocation, while still rejecting others, or the server may 1019 reject various extensions for different reasons (and therefore 1020 different Error Codes). The Error Code found in the Reply message 1021 applies to all extensions found in the Reply. The DHCP server can 1022 send multiple Reply messages in response to the same DHCP Request, 1023 each possibly with a different Error Code, but all with the same 1024 Transaction ID. The DHCPv6 server MUST send enough DHCP Reply 1025 messages to account for all requested extensions. The DHCPv6 server 1026 SHOULD attempt to put all the Extensions that were processed with the 1027 same Error Code into the same DHCP Reply, in the order in which they 1028 were received. 1030 6.4. Receiving DHCP Release Messages 1032 If the server receives a DHCP Release Message, it MUST verify that a 1033 valid link-local address is present in the link-local address field 1034 of the message. If not, the message MUST be silently discarded. 1036 In response to a DHCP Release Message with a valid link-local 1037 address, the DHCPv6 server formulates a DHCP Reply message that 1038 will be sent back to the releasing client by way of the client's 1039 link-local address. A DHCP Reply message sent in response to a DHCP 1040 Release message MUST be sent to the client's link-local address via 1041 the agent address in the Release message and set the 'L' bit in the 1042 Reply, (unless the 'D' bit is set in the Release message). 1044 If the received agent address and link-local address do not 1045 correspond to any binding known to the server, then the server SHOULD 1046 return a DHCP Reply with a error code of 5. 1048 Otherwise, if the agent address and link-local address indicate a 1049 binding known to the server, then the server continues processing 1050 for the Release message. If there are any Extensions, the server 1051 releases the particular configuration items specified in the 1052 extensions. Otherwise, if there are no extensions, the server 1053 releases all configuration information in the client's binding. 1055 After performing the operations indicated in the DHCP Release 1056 message and its Extensions, the DHCPv6 server formulates a DHCP 1057 Reply message, copying the transaction-ID, from the DHCP Release 1058 message. For each Extension in the DHCP Release message successfully 1059 processed by the server, a matching Extension is appended to the DHCP 1060 Reply message. Extensions in the DHCP Release message which cannot 1061 be successfully processed by the server MUST NOT correspond to any 1062 Extension appended to the Reply by the server. 1064 6.5. Sending DHCP Reconfigure Messages 1066 If a DHCPv6 server needs to change the configuration associated 1067 to any of its clients, it constructs a DHCP Reconfigure message 1068 and sends it to each such client. The Reconfigure message MUST 1069 contain the particular Extensions which inform the client about which 1070 configuration information needs to be changed. The Reconfigure MAY 1071 be sent to a multicast address chosen by the server and sent to each 1072 of its clients. 1074 7. DHCP Relay Considerations 1076 The DHCPv6 protocol is constructed so that a relay does not have 1077 to maintain any state in order to facilitate DHCPv6 client/server 1078 interactions. 1080 All relays MUST use the IPv6 address of the interface from which the 1081 DHCPv6 message is transmitted as the source address for the IP header 1082 of that DHCPv6 message. 1084 The main purpose of the DHCP Relay is to assist clients and servers 1085 to carry out DHCPv6 protocol transactions. This, naturally, requires 1086 that the relay be able to discover the addresses of those DHCP 1087 Servers whose services can be advertised to propective clients. In 1088 addition, this discovery has to be able to happen without specific 1089 configuration within the DHCP Relay. By default, the relay discovers 1090 local DHCP Servers by use of multicasting DHCP solicitations to 1091 the All-DHCP-Servers multicast address, but this behavior is fully 1092 configurable. This solicitation occurs every RELAY_DISCOVERY_PERIOD 1093 seconds, and the relay updates its list of available servers after 1094 each solicitation, after waiting MAX_ADV_WAIT seconds to receive the 1095 updated advertisements from the DHCP Servers. 1097 The DHCP Relay MUST be able to be configured with additional DHCP 1098 Server address information for its subsequent advertisements to 1099 link-local DHCP solicitations. Such configured Server addresses 1100 are NOT subject to updates by way of the abovementioned multicast 1101 solicitions. 1103 DISCUSSION: TODO: Make the DHCP Server able to include a 1104 "advertisement lifetime" in the DHCP Advertisement 1105 returned to the DHCP Relay multicast. TODO: Make 1106 the DHCP Server able to specify that each Client 1107 Solicitation is "passed through" the relay so that 1108 the DHCP Server can append specific Extensions 1109 to the Advertisement which is then returned to 1110 that client by way of the link-local DHCP Relay. 1111 This will be done soon, pending the outcome of 1112 discussion within the DHC Working Group. 1114 7.1. DHCP Solicit and DHCP Advertise Message Processing 1116 Upon receiving a DHCP Solicit message from a client, a relay 1117 constructs a DHCP Advertise message and transmits it to the 1118 soliciting client on the same link as the solicitation was received 1119 from. The destination address of the advertisement MUST be the 1120 source address of the solicitation. 1122 DISCUSSION: If the Solicit is delivered to a server and 1123 the server is allowed to send the corresponding 1124 Advertise back to a client, the server could then 1125 include some prospective information to "entice" a 1126 client to use its services. For instance, a server 1127 could include proposed lifetime information, and a 1128 client could pick the server with the best "terms". 1129 Presumably, this forwarding behavior should be a 1130 matter of relay configuration instead of client 1131 request. I'll assume that for now and try to make 1132 the protocol reflect the ability of DHCP Advertise 1133 messages to contain Extensions and come from DHCP 1134 servers off-link. That may take a little more 1135 doing which isn't in the protocol right now, be 1136 patient. 1138 DISCUSSION: What about the 'C' bit in Advertisements? 1140 When transmitting a DHCP Advertise message, a relay indicates how 1141 many server addresses are included in the advertisement, and includes 1142 each address in the DHCP Advertise message. The DHCP Advertise 1143 message must use a routeable IPv6 address in the source address of 1144 the IPv6 header of the message. In particular, the source address 1145 of any DHCP Advertise message sent by a DHCPv6 relay MUST NOT be a 1146 link-local address. 1148 7.2. DHCP Request Message Processing 1150 When a relay receives a DHCP Request message, it MUST check that the 1151 message is received from a link-local address, that the link-local 1152 address matches the link-local address field in the Request message 1153 header, and that the agent address field of the message matches an 1154 IPv6 address associated to the interface from which the DHCP Request 1155 message was received. The relay MUST also check whether the 'S' 1156 bit is set in the message header. If any of these checks fail, the 1157 message is not acceptable and MUST be silently discarded. 1159 If the received request message is acceptable, the relay then 1160 transmits the DHCP Request message to the DHCPv6 server found in the 1161 Server Address field of the received DHCP Request message. All of 1162 the fields of DHCP Request message header transmitted by the relay 1163 are copied over unchanged from the DHCP Request received from the 1164 client. Only the fields in the IPv6 header will differ from the 1165 datagram received from the client, not the payload. 1167 DISCUSSION: Would an error return be better? 1169 DISCUSSION: How about ICMP Unreachable when the Request fails? 1171 7.3. DHCP Reply Message Processing 1173 When the relay receives a DHCP Reply, it MUST check whether the 1174 message has the 'L' bit set. It must check whether the link-local 1175 address field contains an IPv6 address that has prefix FE80::00 . 1176 If all the checks are satisfied, the relay MUST send a DHCP Reply 1177 message to the link-local address listed in the received Reply 1178 message. Only the fields in the IPv6 header will differ from the 1179 datagram received from the server, not the payload. 1181 7.4. Retransmission and Configuration Variables 1183 When a DHCPv6 client does not receive a DHCP Reply in response to a 1184 pending DHCP Request, the client MUST retransmit the identical DHCP 1185 Request to the same server again until it can be reasonably sure that 1186 the DHCPv6 server is unavailable and an alternative can be chosen. 1187 It is important for the DHCP Server to be sure that its client has 1188 received the configuration information included with the Extensions 1189 to the DHCP Reply message. 1191 Likewise, but less commonly, when a DHCP server does not receive a 1192 DHCP Request message in response to its DHCP Reconfigure message to 1193 the client, the server MUST retransmit the identical DHCP Reconfigure 1194 to the client until it is reasonably certain that the client is not 1195 available for reconfiguration. If no corresponding DHCP Request 1196 is ever received by the server, the server MAY erase or deallocate 1197 information as needed from the client's binding. 1199 These retransmissions occur using the following configuration 1200 variables for a DHCPv6 implementation that MUST be configurable by a 1201 client or server are as follows: 1203 REPLY_MSG_INITIAL_TIMEOUT 1205 The time in seconds that a DHCPv6 client waits to receive a 1206 server's DHCP Reply before retransmitting a DHCP Request. 1208 Default: 2 seconds. 1210 REPLY_MSG_MIN_RETRANS 1212 The minimum number of DHCP Request transmissions that a DHCPv6 1213 client should retransmit, before aborting the request, possibly 1214 retrying the Request with another Server, and logging a DHCPv6 1215 System Error. 1217 Default: 10 retransmissions. 1219 REPLY_MSG_RETRANS_INTERVAL 1221 The time between successive retransmissions of DHCP Request 1222 messages. 1224 Default: 2 seconds. 1226 RECONF_MSG_INITIAL_TIMEOUT 1228 The time in seconds that a DHCPv6 server waits to receive 1229 a client's DHCP Request before retransmitting its DHCP 1230 Reconfigure. 1232 Default: 2 seconds. 1234 RECONF_MSG_MIN_RETRANS 1236 The minimum number of DHCP Reconfigure messages that a DHCPv6 1237 server should retransmit, before assuming the the client is 1238 unavailable and that the server can proceed with the needed 1239 reconfiguration of that client's resources, and logging a 1240 DHCPv6 System Error. 1242 Default: 10 retransmissions. 1244 RECONF_MSG_RETRANS_INTERVAL 1246 The time between successive retransmissions of DHCP Reconfigure 1247 messages. 1249 Default: 2 seconds. 1251 RECONF_MSG_MIN_RESP 1253 The minimum amount of time before a client can respond to a 1254 DHCP Reconfigure message sent to a multicast address. 1256 Default: 1 second. 1258 RECONF_MSG_MAX_RESP 1260 The maximum amount of time before a client MUST respond to a 1261 DHCP Reconfigure message sent to a multicast address. 1263 Default: 8 second. 1265 RELAY_DISCOVERY_PERIOD 1267 The period fo time between successive attempts by the DHCP 1268 Relay to discovery available DHCP Servers. 1270 Default: 3600 seconds (1 hour). 1272 MAX_ADV_WAIT 1274 The amount of time the relay waits to hear DHCP Advertisements 1275 from DHCP Servers after the relay issues its periodic 1276 solicitation to the All-DHCP Servers multicast address. 1278 The following parameter specifies how long a DHCPv6 server has to 1279 keep track of client transaction-IDs in order to make sure that 1280 client retransmissions using the same transaction-ID are idempotent. 1282 XID_IT_TIMEOUT 1284 Default: 10800 seconds 1286 8. Security Considerations 1288 DHCP clients and servers must often be able to authenticate the 1289 messages they exchange. For instance, a DHCP server may wish to be 1290 certain that a DHCP Request originated from the client identified by 1291 the fields included within the 1292 Request message header. Conversely, it is often essential for a DHCP 1293 client to be certain that the configuration parameters and addresses 1294 it has received were sent to it by an authoritative DHCP server. 1295 Similarly, a DHCP server should only accept a DHCP Release message 1296 which seems to be from one of its clients, if it has some assurance 1297 that the client actually did transmit the Release message. At the 1298 time of this writing, there is no generally accepted mechanism useful 1299 with DHCPv4 that can be extended for use with DHCPv6. 1301 The IPv6 Authentication Header can provide security for DHCPv6 1302 messages when both endpoints have a suitable IPv6 address. However, 1303 a client often has only a link-local address, and such an address 1304 is not sufficient for a DHCPv6 server which is off-link. In those 1305 circumstances the DHCP relay must be involved, so that the DHCP 1306 message MUST have the relay's address in the IPv6 destination address 1307 field, even though the client aims to deliver the message to the 1308 DHCPv5 server. The DHCPv6 Client-Server Authentication Extension is 1309 intended to be used in these circumstances. 1311 9. Acknowledgements 1313 Thanks to the DHC Working Group for their time and input into the 1314 specification. A special thanks for the consistent input, ideas, 1315 and review by (in alphabetical order) Brian Carpenter, Ralph Droms, 1316 Thomas Narten, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson, 1317 and Phil Wells. 1319 Thanks to Steve Deering and Bob Hinden, who have consistently 1320 taken the time to discuss the more complex parts of the IPv6 1321 specifications. 1323 The authors MUST also thank their employers for the opportunity and 1324 funding to work on DHCPv6 and IPv6 in general as an individual in the 1325 IETF. 1327 A. Related Work in IPv6 1329 The related work in IPv6 that would best serve an implementor 1330 to study is the IPv6 Specification [2], the IPv6 Addressing 1331 Architecture [3], IPv6 Stateless Address Autoconfiguration [9], IPv6 1332 Neighbor Discovery Processing [4], and Dynamic Updates to DNS [10]. 1333 These specifications afford DHCPv6 to build upon the IPv6 work to 1334 provide both robust stateful autoconfiguration and autoregistration 1335 of DNS Host Names. 1337 The IPv6 Specification provides the base architecture and design of 1338 IPv6. A key point for DHCPv6 implementors to understand is that IPv6 1339 requires that every link in the internet have an MTU of 576 octets or 1340 greater (in IPv4 the requirement is 68 octets). This means that a 1341 UDP datagram of 536 octets will always pass through an internet (less 1342 40 octets for the IPv6 header), as long as there are no IP options 1343 prior to the UDP header in the datagram. But, IPv6 does not support 1344 fragmentation at routers and fragmentation must take place end-to-end 1345 between hosts. If a DHCPv6 implementation needs to send a datagram 1346 greater than 536 octets it can either fragment the UDP datagram 1347 in UDP or use Path MTU Discovery [2] to determine the size of the 1348 datagram that will traverse a network path. It is implementation 1349 defined how this is accomplished in DHCPv6. 1351 The IPv6 Addressing Architecture Specification provides the address 1352 scope that can be used in an IPv6 implementation, and the various 1353 configuration architecture guidelines for network designers of the 1354 IPv6 address space. Two advantages of IPv6 are that multicast 1355 addressing is well defined, and nodes can create link-local addresses 1356 during initialization of the nodes environment. This means that a 1357 host immediately can configure an IPv6 address at initialization 1358 for an interface, before communicating in any manner on the link. 1359 The host can then use a well-known multicast address to begin 1360 communications to discover neighbors on the link, or to send a DHCP 1361 Solicit and locate a DHCPv6 server or relay. 1363 IPv6 Stateless Address Autoconfiguration [9] specifies procedures by 1364 which a host may autoconfigure addresses based on neighbor discovery 1365 router advertisements, and the use of a validation lifetime to 1366 support renumbering of addresses on the Internet. In addition the 1367 protocol interaction by which a host begins stateless or stateful 1368 autoconfiguration is specified. DHCPv6 is one vehicle to perform 1369 stateful autoconfiguration. Compatibility with addrconf is a design 1370 goal of DHCPv6. 1372 IPv6 Neighbor Discovery [4] is the node discovery protocol in 1373 IPv6 (replaces and enhances functions of IPv4 ARP Model [6]). To 1374 truly understand IPv6 and addrconf it is strongly recommended that 1375 implementors understand IPv6 Neighbor Discovery. 1377 Dynamic Updates to DNS [10] is a specification that supports the 1378 dynamic update of DNS records for both IPv4 and IPv6. DHCPv6 can use 1379 the dynamic updates to DNS to now integrate addresses and name space 1380 to not only support autoconfiguration, but also autoregistration in 1381 IPv6. 1383 B. Change History 1385 B.1. Changes from November 95 to February 96 Drafts 1387 Substituted use of client's link-local address for previous uses of 1388 client's interface token. 1390 Reorganized DHCP messages into Solicit/Advertise, Request/Reply, 1391 Release, and Reconfigure. 1393 Made message-specific formats instead of using the same DHCP header 1394 for each message. 1396 Eliminated retransmission message types. 1398 Server commits after receiving DHCP Request, and optimistically 1399 depends on client retransmissions as negative acknowledgement. 1401 Eliminated total-addrs. 1403 Eliminated all definitions and most fields related to allocating IPv6 1404 addresses (moved to the Extensions specification). 1406 Renamed "gateway address" to be "agent address". 1408 Added "Considerations" sections. 1410 B.2. Changes from February 96 to June 96 Drafts 1412 Added language referring to DHCP Client-Server Authentication 1413 extension. 1415 Moved the 'L' bit in the DHCP Reply Message format to save 32 bits. 1417 Added language for multicast Reconfigure message handling. 1419 In the process of adding capability for the DHCP Relay to multicast 1420 and obtain DHCP Server addresses. 1422 C. Comparison between DHCPv4 and DHCPv6 1424 This appendix is provided for readers who will find it useful to see 1425 a model and architecture comparison between DHCPv4 and DHCPv6. The 1426 differences are because of three key reasons: 1428 o IPv6 inherently supports a new model and architecture for 1429 communications and autoconfiguration of addresses. 1431 o DHCPv6 in its design was able to take advantage of the inherent 1432 benefits of IPv6. 1434 o New features were added to support the evolution and the 1435 existence of mature Internet users in the industry. 1437 IPv6 Architecuture/Model Changes: 1439 o The link-local address permits a node to have an address 1440 immediately when the node boots, which means all clients have a 1441 source IP address at all times to locate a server or relay agent 1442 on the local link. 1444 o The need for bootp compatibility and broadcast flags are removed, 1445 which permitted a great deal of freedom in designing the new 1446 packet formats for the client and server interaction. 1448 o Multicast and the scoping methods in IPv6 permitted the design of 1449 discovery packets that would inherently define their range by the 1450 multicast address for the function required. 1452 o Stateful autoconfiguration must coexist and integrate with 1453 stateless autoconfiguration supporting Duplicate Address 1454 Detection and two lease times to facilitate the dynamic 1455 renumbering of addresses and the management of those addresses. 1457 o Multiple addresses per interface are inherently supported in 1458 IPv6. 1460 o Most DHCPv4 options are unnecessary now because the configuration 1461 parameters are either obtained thru IPv6 Neighbor Discovery or 1462 the Service Location protocol. 1464 DHCPv6 Architecture/Model Changes: 1466 o Message types are the first bytes in the packet. 1468 o IPv6 Address allocations are now handled in a message extension 1469 as opposed to the main header. 1471 o Client/Server bindings are now mandatory and take advantage of 1472 the client's link-local address to always permit communications 1473 either directly from an on-link server, or from a remote server 1474 through an on-link relay-agent. 1476 o Servers are now discovered by a client solicit and server or 1477 relay-agent advertisement model. 1479 o The client will know if the server is on-link or off-link. 1481 o The client after a solicit will be returned the addresses of 1482 available servers either from an on-link server or from an 1483 on-link relay-agent as agents providing the advertisements. 1485 o The on-link relay-agent will obtain the location of remote server 1486 addresses from system configuration or by the use of a site wide 1487 DHCPv6 Multicast packet. 1489 o The protocol is optimized and removes the use of ACKs and NAKs 1490 once the client and server set-up is complete. 1492 o The server uses client retransmits to indicate that the client 1493 may have become invalid, which permits recovery in the case where 1494 the network has faulted. 1496 o DHCPINFORM is inherent in the new packet design; a client can 1497 request configuration parameters other than IPv6 addresses in the 1498 optional extension headers. 1500 o Clients must listen to their UDP port for the new Reconfigure 1501 message type from servers, unless they join the appropriate 1502 multicast group as specified by the DHCP server. 1504 o Dynamic Updates to DNS are supported in the IPv6 Address 1505 extension. 1507 o New extensions have been defined. 1509 New Internet User Features: 1511 o Configuration of Dynamic Updates to DNS to support multiple 1512 implementation policy requirements. 1514 o Configuration of what policy is enforced when addresses are 1515 deprecated for dynamic renumbering can be implemented. 1517 o Configuration of how relay-agents locate remote servers for a 1518 link can be implemented. 1520 o An Authentication extension has been added. 1522 o Configuration of IPv6 Mobile Binding Updates and Anycast 1523 Addresses can be facilitated and implemented to support 1524 Multihomed nodes. 1526 o Configuration of additional addresses for server applications can 1527 be requested by a client in an implementation. 1529 o Configuration of reclaiming infinite leases can be implemented 1530 using the Reconfigure message type. 1532 o Configuration of tightly coupled integration between stateless 1533 and stateful address autoconfiguration can be implemented. 1535 References 1537 [1] S. Bradner and A. Mankin. The Recommendation for the IP Next 1538 Generation Protocol. RFC 1752, January 1995. 1540 [2] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1541 Specification. RFC 1883, December 1995. 1543 [3] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 1544 RFC 1883, December 1995. 1546 [4] T. Narten, E. Nordmark, and W. Simpson. IPv6 Neighbor 1547 Discovery. draft-ietf-ipngwg-discovery-03.txt -- work in 1548 progress, November 1995. 1550 [5] C. Perkins. Extensions to DHCPv6. draft-ietf-dhc-dhcpv6ext-02.txt 1551 -- work in progress, June 1996. 1553 [6] David C. Plummer. An Ethernet Address Resolution Protocol: 1554 Or Converting Network Protocol Addresses to 48.bit Ethernet 1555 Addresses for Transmission on Ethernet Hardware. RFC 826, 1556 November 1982. 1558 [7] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 1560 [8] J. B. Postel, Editor. Internet Protocol. RFC 791, September 1561 1981. 1563 [9] S. Thomson and T. Narten. IPv6 Stateless Address 1564 Autoconfiguration. draft-ietf-addrconf-ipv6-auto-06.txt 1565 - work in progress, November 1995. 1567 [10] S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the 1568 Domain Name System (DNS). draft-ietf-dnsind-dynDNS-06.txt -- 1569 work in progress, February 1996. 1571 Chair's Address 1573 The working group can be contacted via the current chair: 1575 Ralph Droms 1576 Computer Science Department 1577 323 Dana Engineering 1578 Bucknell University 1579 Lewisburg, PA 17837 1581 Phone: (717) 524-1145 1582 E-mail: droms@bucknell.edu 1584 Author's Address 1586 Questions about this memo can be directed to: 1588 Jim Bound Charles Perkins 1589 Digital Equipment Corporation T. J. Watson Research Center 1590 110 Spitbrook Road, ZKO3-3/U14 IBM Corporation 1591 Nashua, NH 03062 30 Saw Mill River Rd., Rm H3-D34 1592 Hawthorne, NY 10532 1593 Phone: +1-603-881-0400 +1-914-784-7350 1594 Fax: +1-914-784-6205 1595 E-mail: bound@zk3.dec.com perk@watson.ibm.com