idnits 2.17.1 draft-ietf-dhc-dhcpv6-04.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 148: '... MUST This word, or...' RFC 2119 keyword, line 152: '... MUST NOT This phrase m...' RFC 2119 keyword, line 155: '... SHOULD This word, or...' RFC 2119 keyword, line 163: '... MAY This word, or...' RFC 2119 keyword, line 166: '...nclude this option MUST be prepared to...' (78 more instances...) -- The draft header indicates that this document obsoletes draft-ietf-dhc-dhcpv6-03.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- -- No information found for rfcdraft-ietf-dhc-dhcpv6-03.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 February 1996) is 10300 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-03.txt IBM Research 5 12 February 1996 7 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 8 draft-ietf-dhc-dhcpv6-04.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 options, to IPv6 hosts. 38 It offers the capability of automatic allocation of reusable network 39 addresses and additional configuration options. This protocol should 40 be considered a stateful counterpart to the IPv6 Stateless Address 41 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 . . . . . . . . . . . . . . . . . . . 4 56 3. Protocol Design Model 5 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 8 62 4.1. UDP Ports used for DHCPv6 messages . . . . . . . . . . . 8 63 4.2. DHCP Solicit Message Format . . . . . . . . . . . . . . . 8 64 4.3. DHCP Advertise Message Format . . . . . . . . . . . . . . 9 65 4.4. DHCP Request Message Format . . . . . . . . . . . . . . . 10 66 4.5. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12 67 4.6. DHCP Release Message Format . . . . . . . . . . . . . . . 13 68 4.7. DHCP Reconfigure Message Format . . . . . . . . . . . . . 14 70 5. DHCP Client Considerations 15 71 5.1. DHCP Solicit Message Processing . . . . . . . . . . . . . 15 72 5.2. DHCP Advertise Message Processing . . . . . . . . . . . . 15 73 5.3. DHCP Request Message Processing . . . . . . . . . . . . . 16 74 5.4. DHCP Reply Message Processing . . . . . . . . . . . . . . 17 75 5.5. DHCP Release Message Processing . . . . . . . . . . . . . 18 76 5.6. DHCP Reconfigure Message Processing . . . . . . . . . . . 18 78 6. DHCP Server Considerations 19 79 6.1. DHCP Solicit and Advertise Message Processing . . . . . . 19 80 6.2. DHCP Request and Reply Message Processing . . . . . . . . 19 81 6.3. DHCP Release Message Processing . . . . . . . . . . . . . 20 82 6.4. DHCP Reconfigure Message Processing . . . . . . . . . . . 21 84 7. DHCP Relay Considerations 22 85 7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 22 86 7.2. DHCP Request Message Processing . . . . . . . . . . . . . 23 87 7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 23 88 7.4. Retransmission and Configuation Variables . . . . . . . . 23 90 8. Security Considerations 25 92 9. Acknowledgements 25 94 A. Related Work in IPv6 26 96 B. Change History 27 97 B.1. Changes from November 95 to February 96 Drafts . . . . . 27 99 Chair's Address 29 101 Author's Address 29 102 1. Introduction 104 The Dynamic Host Configuration Protocol (DHCP) provides configuration 105 parameters to Internet hosts. DHCP consists of a protocol for 106 delivering host-specific configuration parameters from a DHCP server 107 to a host, and a mechanism for allocation of network addresses and 108 other related parameters to IPv6 hosts. 110 DHCP is built on a client-server model, where designated DHCP 111 server hosts allocate network addresses and automatically deliver 112 configuration parameters to dynamically configured hosts. Throughout 113 the remainder of this document, the term "server" refers to a host 114 providing initialization parameters through DHCP, and the term 115 "client" refers to a host requesting initialization parameters from 116 a DHCP server. DHCPv6 servers maintain state for their clients, 117 in contrast to IPv6 Stateless Address Autoconfiguration [9], 118 where IPv6 hosts should get the same results if they repeat the 119 autoconfiguration procedure multiple times. 121 DHCPv6 uses Request and Reply messages to support a client/server 122 processing model whereby both client and server are assured that 123 requested configuration parameters have been received and accepted by 124 the client. DHCPv6 supports optional configuration parameters and 125 processing for hosts through its companion document Extensions for 126 the Dynamic Host Configuration Protocol for IPv6 [5]. 128 The IPv6 Addressing Architecture [3] and IPv6 Stateless Address 129 Autoconfiguration specifications provide new features not available 130 in IP version 4 (IPv4) [8], which are used to simplify and generalize 131 the operation of DHCPv6 clients. 133 Section 2 provides definitions for terminology used throughout this 134 document. Section 3 provides a overview of the protocol design model 135 that guides the design choices in the specification; section 3.2 136 briefly describes the protocol messages and their semantics. 137 Section 4 provides the message formats and field definitions used for 138 each message. Sections 5, 6, and 7 specify how clients, servers, 139 and relays interact. Appendix A summarizes related work in IPv6 that 140 will provide helpful context; it is not part of this specification, 141 but included for informational purposes. 143 1.1. Specification Language 145 In this document, several words are used to signify the requirements 146 of the specification. These words are often capitalized. 148 MUST This word, or the adjective "required", means 149 that the definition is an absolute requirement 150 of the specification. 152 MUST NOT This phrase means that the definition is an 153 absolute prohibition of the specification. 155 SHOULD This word, or the adjective "recommended", 156 means that there may exist valid reasons in 157 particular circumstances to ignore this item, 158 but the full implications must be understood 159 and carefully weighed before choosing a 160 different course. Unexpected results may 161 result otherwise. 163 MAY This word, or the adjective "optional", means 164 that this item is one of an allowed set of 165 alternatives. An implementation which does 166 not include this option MUST be prepared to 167 interoperate with another implementation which 168 does include the option. 170 silently discard The implementation discards the datagram 171 without further processing, and without 172 indicating an error to the sender. The 173 implementation SHOULD provide the capability of 174 logging the error, including the contents of 175 the discarded datagram, and SHOULD record the 176 event in a statistics counter. 178 2. Terminology and Definitions 180 Relevant terminology from the IPv6 Protocol [2], IPv6 Addressing 181 Architecture, and IPv6 Stateless Address Autoconfiguration will be 182 provided, and then the DHCPv6 terminology. 184 2.1. IPv6 Terminology 186 IP 188 Internet Protocol Version 6 (IPv6). The terms IPv4 and IPv6 189 are used only in contexts where necessary to avoid ambiguity. 191 node 193 A device that implements IPv6. 195 router 197 A node that forwards IPv6 datagrams not explicitly addressed to 198 itself. 200 host 202 Any node that is not a router. 204 link 206 A communication facility or medium over which nodes can 207 communicate at the link layer, i.e., the layer immediately 208 below IPv6. Examples are Ethernet (simple or bridged); PPP 209 links, X.25, Frame Relay, or ATM networks; and internet (or 210 higher) layer "tunnels", such as tunnels over IPv4 or IPv6 211 itself. 213 link-layer identifier 215 a link-layer identifier for an interface. Examples include 216 IEEE 802 addresses for Ethernet links, and E.164 addresses for 217 ISDN links. 219 link-local address 221 An address having link-only scope that can be used to reach 222 neighboring nodes attached to the same link. All interfaces 223 have a link-local address. 225 neighbors 227 Nodes attached to the same link. 229 interface 231 A node's attachment to the link. 233 address 235 An IP layer identifier for an interface or a set of interfaces. 237 message 239 The data exchanged between DHCP agents and clients; in this 240 specification, messages are delivered via IPv6 and UDP. 242 datagram 244 An IP header plus payload. 246 unicast address 248 An identifier for a single interface. A datagram sent to a 249 unicast address is delivered to the interface identified by 250 that address. 252 multicast address 254 An identifier for a set of interfaces (typically belonging to 255 different nodes). A datagram sent to a multicast address is 256 delivered to all interfaces identified by that address. 258 2.2. DHCPv6 Terminology 260 configuration parameter 262 Any parameter that can be used by a node to configure its 263 network environment and enable communication on a link or 264 internetwork. 266 client 268 A host that initiates requests on a link to obtain 269 configuration parameters. 271 server 273 A server is a node that responds to requests from clients on a 274 link to provide: addresses, dynamic updates to DNS, or other 275 configuration parameters. 277 relay 279 A node that may advertise DHCP server addresses, or may act as 280 an intermediary to deliver DHCP messages between clients and 281 servers. 283 DHCP Agent 285 Either a DHCPv6 server or a DHCPv6 relay. 287 agent address 289 The address of a neighboring DHCP relay or DHCP server on the 290 same link as the DHCP client. 292 msg-type 294 The msg-type defines the DHCPv6 protocol type for a message. 296 transaction-ID 298 The transaction-ID is a monotonically increasing integer 299 identifier specified by the client and is used by the client to 300 match a DHCP Reply to a pending DHCP Request. 302 server address 304 The server address specifies the address for the server 305 responding to a client. 307 binding 309 A binding in DHCPv6 contains the data which a DHCPv6 server 310 MUST maintain for each of its clients. An implementation 311 MUST support bindings consisting of at least a client's 312 link-local address, agent address, preferred lifetime and valid 313 lifetime [9] for each client address, and the transaction-ID. 315 3. Protocol Design Model 317 This section is provided for implementors to understand the DHCPv6 318 protocol design model from an architectural perspective. The goals, 319 conceptual models and implementation examples presented in this 320 section do not specify requirements of the DHCPv6 protocol. 322 3.1. Design Goals 324 The following list gives general design goals for this DHCPv6 325 specification. 327 - DHCPv6 should be a mechanism rather than a policy. DHCPv6 must 328 allow local system administrators control over configuration 329 parameters where desired; e.g., local system administrators 330 should be able to enforce local policies concerning allocation 331 and access to local resources where desired. 333 - DHCPv6 MUST NOT introduce any requirement for manual 334 configuration of DHCPv6 client hosts, except possibly for 335 manually configured keys. Each host should be able to discover 336 appropriate local configuration parameters without user 337 intervention, and incorporate those parameters into its own 338 configuration. 340 - DHCPv6 MUST NOT require a server on each link. To allow for 341 scale and economy, DHCPv6 must work across relay agents. 343 - A DHCPv6 client must be prepared to receive multiple responses to 344 solicitations for DHCP servers. Some installations may include 345 multiple, overlapping DHCPv6 servers to enhance reliability 346 and/or to increase performance. 348 - DHCPv6 must coexist with statically configured, non-participating 349 hosts and with existing network protocol implementations. 351 - DHCPv6 MUST be compatible with IPv6 Stateless Address 352 Autoconfiguration. 354 - DHCPv6 must support the requirements of automated renumbering of 355 IPv6 addresses [1]. 357 - DHCPv6 servers should be able to support Dynamic Updates to 358 DNS [10]. 360 - A DHCPv6 server to server protocol is NOT part of this DHCPv6 361 specification. 363 - It is NOT a design goal of DHCPv6 to specify how a server 364 configuration parameter database is maintained or determined. 365 Methods for configuring DHCP servers are outside the scope of 366 this document. 368 3.2. DHCPv6 Messages 370 Each DHCPv6 message contains a type, which defines whether the 371 message originated from a DHCPv6 server or client. 373 The message types are as follows: 375 01 DHCP Solicit 377 The DHCP Solicit message is a DHCPv6 multicast (or in special 378 circumstances unicast) message from a client to one or more 379 neighboring DHCPv6 Agents. 381 02 DHCP Advertise 383 The DHCP Advertise is an IPv6 unicast message from a DHCP Agent 384 in response to a client DHCP Solicit. 386 03 DHCP Request 388 The DHCP Request is an IPv6 unicast message from a client to 389 a server, when the client knows the IPv6 unicast address of a 390 server, to request configuration parameters on a network. 392 04 DHCP Reply 394 The DHCP Reply is an IPv6 unicast message sent by a server to 395 respond to a client's DHCP Request. Extensions [5] to the DHCP 396 Reply describe the resources that the DHCP Server has committed 397 and allocated to the client, and may contain other information 398 for use by the client. 400 05 DHCP Release 402 The DHCP Release message is used by a DHCPv6 client to inform 403 the server that the client is releasing a particular address, 404 or set of addresses or resources, even though the addresses or 405 resources may still be marked valid in the server's binding for 406 the client. 408 06 DHCP Reconfigure 410 The DHCP Reconfigure message is used by a DHCPv6 server 411 to inform the client that the server has new configuration 412 information of importance to the client. The client is 413 expected to initiate a new Request/Reply transaction. 415 3.3. Request/Response Processing Model 417 Processing details for the DHCP messages listed above are specified 418 in Sections 5, 6, and 7. 420 The request/response processing for DHCPv6 is transaction based 421 and uses a best-effort set of messages to guarantee a completed 422 transaction. The timeout and retransmission guidelines and 423 configuration variables are discussed in Section 7.4. 425 The request/response set is always started by a client with a DHCP 426 Request, which may be issued after the client knows the server's 427 address. The response message is from the server and is the DHCP 428 Reply. At this point in the flow all data has been received. To 429 provide a method of recovery if either the client or server do not 430 receive the messages to complete the transaction, the client is 431 required to retransmit any DHCP Request message until it elicits a 432 DHCP Reply, or until it can be reasonably certain that the desired 433 DHCP Server is unavailable. 435 4. DHCPv6 Message Formats and Field Definitions 437 All fields in DHCPv6 messages MUST be initialized to binary zeroes by 438 both the client and server unless otherwise noted. DHCPv6 message 439 types not defined here (msg-types 0 and 7-255) are reserved. 441 All DHCP Agents MUST join the DHCPv6 Server/Relay-Agent multicast 442 group at the well-known multicast address FF02:0:0:0:0:0:1:0. 444 Servers on the same link as the client MUST use the source address 445 in the IPv6 header from the client as the destination address in the 446 server's response datagrams. 448 4.1. UDP Ports used for DHCPv6 messages 450 DHCPv6 uses the UDP [7] protocol to communicate between clients 451 and servers. UDP is not reliable, but DHCPv6 must provide some 452 reliability between clients and servers. If a response is not 453 received after transmission of a DHCP message, the message MUST be 454 retransmitted according to the rules specified in 7.4. 456 A Client MUST transmit all messages over UDP using UDP port 547 as 457 the destination port. A client MUST receive all messages from UDP 458 port 546. 460 A DHCP Agent MUST transmit all messages over UDP using UDP port 546 461 as the destination port. A DHCP Agent MUST receive all messages over 462 UDP using UDP port 547. 464 4.2. DHCP Solicit Message Format 466 A DHCPv6 client transmits a DHCP Solicit message to obtain the 467 address of a neighboring DHCP Agent, and to obtain one or more 468 addresses for DHCP servers which the DHCP Agent is configured to 469 advertise. If a DHCPv6 client does not know any DHCP Agent address, 470 or wants to locate a new server to receive configuration parameters, 471 the client SHOULD use, as the destination IP address, the DHCPv6 472 Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0. 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | msg-type | msg-flags | RESERVED | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | extensions (variable number and length) ... 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 msg-type 1 484 msg-flags 0 486 RESERVED 0 488 extensions No extensions are defined at this time. 490 4.3. DHCP Advertise Message Format 492 A DHCPv6 agent sends a DHCP Advertise message to inform a prospective 493 client about the IPv6 address of a DHCP Agent to which a DHCP Request 494 message may be sent. 496 A DHCPv6 agent MAY periodically transmit DHCP Advertise messages to 497 the All-DHCPv6 Clients multicast address, no more often than once per 498 second, and with TTL == 1. 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | msg-type |S| msg-flags | server-count | reserved | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | agent address | 506 | (16 octets) | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | server addresses | 509 | (16 octets each) | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | extensions (variable number and length) ... 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 msg-type 2 516 S If set, the agent address is also a server 517 address. 519 msg-flags 0 521 server-count The number of addresses listed in the server 522 addresses field. 524 RESERVED 0 526 agent address The IPv6 address of a neighboring DHCP Agent 527 interface 529 server addresses The IPv6 address(es) of the DHCPv6 server(s) 530 which the DHCP Agent has been configured to 531 advertise. 533 extensions See [5]. 535 Note that if a neighboring DHCPv6 server issues the DHCP Advertise, 536 then the agent address will be the IPv6 address of one of the 537 server's interfaces, the 'S' bit will be set, the agent address will 538 be an address of the server, and there may be zero server addresses 539 sent in the DHCP Advertise message. It is an error for server-count 540 to be zero if the 'S' bit is not set. 542 4.4. DHCP Request Message Format 544 In order to request parameters from a DHCP server, a client sends a 545 DHCP Request message and appends the extensions which are appropriate 546 for obtaining the needed parameters [5]. If the client does not know 547 any DHCPv6 server address, it must first obtain a server address by 548 multicasting a DHCP Solicit message (see Section 4.2). If the client 549 does not have a valid IPv6 address which is reachable by the DHCPv6 550 server, the client MUST use the unicast IP address of a local DHCPv6 551 relay as the destination IP address. Otherwise, the client MAY omit 552 the server address in the DHCP Request message; in this case, the 553 client MUST send the DHCP Request message directly to the server just 554 as it would any other datagram destined for the server, using the 555 server address as the IPv6 destination address in the IPv6 header. 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | msg-type |S|C| reserved | transaction-ID | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | (if present) | 563 | server address (16 octets) | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | agent address | 566 | (16 octets) | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | link-local address | 569 | (16 octets) | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | extensions (variable number and length) .... 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 msg-type 3 576 S If set, the server address is present 578 C If set, the client requests the server to 579 clear all existing resources and bindings 580 currently associated with the client, 581 deallocating as needed. 583 reserved 0 585 transaction-ID A monotonically increasing number which the 586 client asks the server to copy into its DHCP 587 Reply, so that the client can match Replies 588 with pending Requests. 590 server address If present, the IPv6 address of the DHCPv6 591 server which should receive the client's DHCP 592 Request message. 594 agent address The IPv6 address of the relay or server 595 interface from which the client received the 596 DHCP Advertise message 598 link-local address The IPv6 link-local address of the client 599 interface from which the the client issued 600 the DHCP Request message 602 extensions See [5]. 604 4.5. DHCP Reply Message Format 606 The server sends a DHCP Reply message in response to every DHCP 607 Request received. If the request comes with the 'S' bit set, the 608 client could not directly send the Request to the server and had to 609 use a neighboring relay agent. In that case, the server sends back 610 the DHCP Reply with the 'L' bit set, and the DHCP Reply is addressed 611 to the agent address found in the DHCP Request message. If the 612 'L' bit is set, then the client's link-local address will also be 613 present. 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | msg-type | error code | transaction-ID | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 |L| RESERVED | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | (if present) | 623 | link-local address (16 octets) | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | extensions (variable number and length) .... 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 msg-type 3 630 error code One of the following values: 632 0 Success 633 1 Failure, reason unspecified 634 2 Authentication failed or nonexistent 635 3 Poorly formed request 636 4 Resources unavailable 637 5 Client record unavailable 638 16 Wrong phase of moon 639 32 Dogbert didn't like it 640 64 Server unreachable (ICMP error) 642 transaction-ID Copied from the transaction-ID which the 643 DHCPv6 server received in the DHCP Request. 644 to help the client match this reply with an 645 outstanding Request. 647 L If set, the link-local address is present 648 RESERVED 0 650 link-local address If present, the IPv6 address of the client 651 interface which issued the corresponding DHCP 652 Request message. 654 extensions See [5]. 656 If the 'L' bit is set, and thus the link-local address is present in 657 the Reply message, the Reply is sent by the server to the relay's 658 address which was specified as the agent address in the DHCP Request 659 message, and the relay uses the link-local address to deliver the 660 Reply message to the client. 662 4.6. DHCP Release Message Format 664 The DHCP Release message is sent without the assistance of any DHCPv6 665 relay. When a client sends a Release message, it is assumed to 666 have a valid IPv6 address with sufficient scope to allow access to 667 the target server. Only the parameters which are specified in the 668 extensions are released. The DHCP server acknowledges the Release 669 message by sending a DHCP Reply (Section 6.2). 671 0 1 2 3 672 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 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | msg-type |D| msg-flags | transaction-ID | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | agent address | 677 | (16 octets) | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | link-local address | 680 | (16 octets) | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | extensions (variable number and length) .... 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 msg-type 5 687 D If the 'D' ("Direct") flag is set, the client 688 instructs the server to send the DHCP Reply 689 directly back to the client, instead of 690 using the given agent address and link-local 691 address to relay the Reply message. 693 msg-flags 0 694 transaction-ID A monotonically increasing number which the 695 client asks the server to use in its DHCP 696 Reply, to help the client match Replies with 697 outstanding Releases. 699 agent address The IPv6 address of the agent interface to 700 which the client issued the DHCP Request 701 message 703 link-local address The IPv6 link-local address of the client 704 interface from which the the client issued 705 the DHCP Request message 707 extensions See [5] 709 If the client knows that the address it uses as the source IP address 710 in its IPv6 header will still be valid after the server performs the 711 operations requested in the extensions to the DHCP Release message, 712 the client can then specify the 'D' flag. When the 'D' flag is set, 713 the server MUST send the DHCP Reply back to the client's address 714 as shown in the source address of the IPv6 header of the Release 715 message. Otherwise, when the 'D' bit is not set, the server MUST use 716 the agent address and link-local address in its DHCP Reply message to 717 forward the Reply message back to the releasing client. 719 4.7. DHCP Reconfigure Message Format 721 The DHCP Reconfigure message is sent without the assistance of any 722 DHCPv6 relay. When a server sends a Reconfigure message, the client 723 to which it is sent is assumed to have a valid IPv6 address with 724 sufficient scope to be accessible by the server. Only the parameters 725 which are specified in the extensions to the Reconfigure message need 726 be requested again by the client. 728 The client SHOULD listen at UDP port 546 to receive possible DHCP 729 Reconfigure messages. If the client does not listen for DHCP 730 Reconfigure messages, it is possible that the client will not receive 731 notification that its DHCP server has deallocated the client's IPv6 732 address and/or other resources allocated to the client. 734 See discussion in 6.3. 736 0 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | msg-type | msg-flags | reserved | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | extensions (variable number and length) .... 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 msg-type 6 746 msg-flags 0 748 reserved 0 750 extensions See [5] 752 5. DHCP Client Considerations 754 A DHCPv6 client MUST silently discard any DHCP Solicit, DHCP Request, 755 or DHCP Release message it receives. 757 A DHCPv6 client should retain its configured parameters and resources 758 across client system reboots and DHCPv6 client program restarts. 759 However, in these circumstances a DHCPv6 client SHOULD also formulate 760 a DHCP Request message to verify that its configured parameters and 761 resources are still valid. This Request message MUST have the 'C' 762 bit set, to clear client binding information at the server, of which 763 the client may no longer have any record. 765 5.1. DHCP Solicit Message Processing 767 If a node wishes to become a new DHCPv6 client, it must first locate 768 a neighboring DHCP Agent. The client does this by multcasting 769 a DHCP Solicit message to the well-known multicast address 770 FF02:0:0:0:0:0:1:0, setting the TTL == 1. 772 5.2. DHCP Advertise Message Processing 774 When a DHCPv6 client receives a DHCP Advertise message, it may 775 formulate a DHCP Request message to receive configuration information 776 and resources from the DHCP servers listed in the advertisement. If 777 the Advertise message has zero server addresses and does not have the 778 'S' bit set, the client MUST silently discard the message. 780 If the 'S' bit is set, the DHCP Advertise message was transmitted 781 by a DHCPv6 server. In this case, the Advertise message may 782 have Extensions; this might allow the DHCPv6 client to select 783 the configuration that best meets its needs from among several 784 prospective servers. Also in this case, the client MUST use the 785 agent address as the address of its server for future DHCPv6 message 786 transactions. 788 5.3. DHCP Request Message Processing 790 A DHCPv6 client obtains configuration information from a DHCPv6 791 server by sending a DHCP Request message. The client must know the 792 server's address before sending the Request message. In addition, 793 the client must have acquired a valid DHCP agent address. If the 794 client and server are on the same link, the agent address used by the 795 client MUST be the same as the DHCP server's address. 797 If the client has no valid IPv6 address and the DHCP server is 798 off-link, then the client MUST include the server address in the 799 appropriate field of the DHCP Request message and set the 'S' bit. 800 In this case, the IPv6 destination address of the Request message 801 MUST be the agent address. 803 Otherwise, if the client already has a valid IPv6 address and knows 804 the IPv6 address of a candidate IPv6 server, it MUST send the Request 805 message directly to the DHCPv6 server without requiring the services 806 of the local DHCPv6 relay. 808 If a client wishes to instruct a DHCP server to deallocate all 809 previous resources, configuration information, and bindings 810 associated with its agent address and link-local address, it sets the 811 'C' bit in the DHCP Request. A client MAY send in such a Request 812 even when it is no longer attached to the link on which the relay 813 address is attached. 815 A client MAY maintain information about which relay address and 816 server address it has been using for use after a reboot. When 817 the client has a pending DHCP Request and reboots before the 818 corresponding DHCP Reply is received, the client MUST issue its next 819 DHCP Request after rebooting with the 'C' bit set. 821 In any case, after choosing a transaction-ID which is numerically 822 greater than its previous transaction-ID, and filling in the 823 appropriate fields of the DHCP Request message, the client MAY append 824 various DHCPv6 Extensions to the message. These Extensions denote 825 specific requests by the client; for example, a client may request 826 a particular IP address, or request that the server send an update 827 containing the client's new IP address to a Domain Name Server. When 828 all Extensions have been applied, the DHCPv6 client unicasts the DHCP 829 Request to the appropriate DHCP Agent. 831 For each pending DHCP Request message, a client MUST maintain the 832 following information: 834 - The transaction-ID of the Request message, 836 - The server address, 838 - The agent address, 840 - The time at which the next retransmission will be attempted, and 842 - All Extensions appended to the reply message. 844 If a client does not receive a DHCP Reply message with the 845 same transaction-ID as a pending DHCP Request message within 846 REPLY_MSG_INITIAL_TIMEOUT seconds, it MUST retransmit the Request 847 with the same transaction-ID and continue to retransmit according to 848 the rules in Section 7.4. 850 Note that if a client crashes while its DHCP Request is still 851 pending, no state is maintained, and the client MUST reissue a DHCP 852 Request after it restarts. 854 5.4. DHCP Reply Message Processing 856 When a client receives a DHCP Reply message, it MUST check whether 857 the transaction-ID in the Reply message matches the transaction-ID 858 of a pending DHCP Request message. If no match is found, the Reply 859 message MUST be silently discarded, and an error SHOULD be logged. 860 If the transaction-ID matches that of a pending Request, and the 'L' 861 bit is set, but the source address in the IPv6 header does not match 862 the pending agent address, the client MUST discard the message, and 863 SHOULD log the event. Likewise, if the transaction-ID matches that 864 of a pending Request, and the 'L' bit is not set, but the source 865 address in the IPv6 header does not match the pending server address, 866 the client MUST discard the message, and SHOULD log the event. 868 If the Reply message is acceptable, the client processes each 869 Extension [5], extracting the relevant configuration information and 870 parameters for its network operation. 872 Some configuration information extracted from the Extensions to the 873 DHCP Reply message must remain associated with the DHCP server that 874 sent the message. The particular extensions that require this extra 875 measure of association with the server are indicated in the DHCPv6 876 Extensions document [5]. These associations may be useful with DHCP 877 Release messages. 879 5.5. DHCP Release Message Processing 881 If a DHCPv6 client determines that some of its network configuration 882 parameters are no longer valid, it may enable the DHCPv6 server to 883 release allocated resources which are no longer in use by sending a 884 DHCP Release message to the server. The client must consult its list 885 of resource-server associations in order to determine which server 886 should receive the desired Release message. If a client wishes to 887 ask the server to release all information and resources relevent to 888 the client, the client specifies no Extensions. 890 A client wishes to release resources which were granted to it at 891 another link-local address. In that case, the client must instruct 892 the server to send the DHCP Reply directly back to the client, 893 instead of performing the default processing of sending the DHCP 894 Reply back through the agent-address included in the DHCP Release. 895 This is done by setting the 'D' bit in the DHCP Release message. 897 5.6. DHCP Reconfigure Message Processing 899 DISCUSSION: On the one hand, clients REALLY SHOULD listen for 900 Reconfigure messages. On the other hand, some 901 implementors claim that requiring a client to 902 always listen at a port is asking too much. This 903 issue needs further discussion. 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 6. DHCP Server Considerations 922 A server MUST ignore any DHCP Advertise, DHCP Reply, or DHCP 923 Reconfigure message it receives. 925 A server uses the combination to 926 index into its records of client bindings. A DHCPv6 server should 927 retain its client's bindings across server reboots, and, whenever 928 possible, a DHCPv6 client should be assigned the same configuration 929 parameters despite server host system reboots and DHCPv6 server 930 program restarts. A DHCPv6 server MUST support fixed or permanent 931 allocation of configuration parameters to specific hosts. 933 6.1. DHCP Solicit and Advertise Message Processing 935 Upon receiving a DHCP Solicit message from a client, a server 936 constructs a DHCP Advertise message and transmits it to the 937 soliciting client on the same link as the solicitation was received 938 from. The destination address of the advertisement MUST be the 939 source address of the solicitation. The DHCP server must use a IPv6 940 address of the interface on which it received the client's DHCP 941 Solicit message as the source address field of the IPv6 header of the 942 message. 944 6.2. DHCP Request and Reply Message Processing 946 The DHCPv6 server MUST check to ensure that a valid link-local 947 address is present in the client's link-local address field of the 948 Request message. If not, the message MUST be silently discarded. 949 Otherwise, it checks for the presence of the 'S' bit. If the 'S' bit 950 is set, the server MUST check that the server address matches the 951 destination IPv6 address at which the Request message was received 952 by the server. If the server address does not match, the Request 953 message MUST be silently discarded. 955 If the message is accepted, the server extracts the client's 956 link-local address and the agent address, and uses the information to 957 locate or create an appropriate client record (called a binding) used 958 to store all the relevant information, resources, and configuration 959 data which will be associated with the client. Each client record is 960 uniquely identifiable by the ordered pair , since the link-local address is guaranteed to be unique [9] 962 on the link identified by the agent address. If the received agent 963 address and link-local address do not correspond to any binding known 964 to the server, then the server MAY create a new binding for the 965 previously unknown client; otherwise, it SHOULD return a DHCP Reply 966 with a error code of 5. 968 Before processing the Request, the server must determine whether or 969 not the Request is a retransmission of an earlier DHCP Request from 970 the same client. This is done by comparing the transaction-ID to 971 all those transaction-IDs received from the same client during the 972 previous TRANSACTION_ID_TIMEOUT seconds. If the transaction-ID is 973 the same as one received during that time, the server MUST take the 974 same action (e.g., retransmit the same DHCP Reply to the client) 975 as it did after processing the previous DHCP Request with the same 976 transaction-ID. 978 Otherwise (the transaction-ID has not been recently used), when the 979 server has identified and allocated all the relevant information, 980 resources, and configuration data that is associated with the client, 981 it sends that information to its DHCPv6 client by constructing a 982 DHCP Reply message and including the client's information in DHCPv6 983 Extensions to the Reply message. The DHCP Reply message uses the 984 same transaction-ID as found in the received DHCP Request message. 986 If the DHCP Request message has the 'S' bit set in the message 987 header, the DHCPv6 server MUST send the corresponding DHCP Reply 988 message to the agent address found in the Request. 990 The DHCP Request may contain Extensions, which are interpreted 991 as advisory (or mandatory) information from the client about its 992 configuration preferences. For instance, if the IP Address Extension 993 is present, the DHCPv6 server SHOULD attempt to allocate or extend 994 the lifetime of the address indicated by the Extension. 996 6.3. DHCP Release Message Processing 998 If the server receives a DHCP Release Message, it MUST verify that a 999 valid link-local address is present in the link-local address field 1000 of the message. If not, the message MUST be silently discarded. 1002 In response to a DHCP Release Message with a valid link-local 1003 address, the DHCPv6 server formulates a DHCP Reply message that 1004 will be sent back to the releasing client by way of the client's 1005 link-local address. A DHCP Reply message sent in response to a DHCP 1006 Release message MUST be sent to the client's link-local address via 1007 the agent address in the Release message and set the 'L' bit in the 1008 Reply, (unless the 'D' bit is set in the Release message). 1010 If the received agent address and link-local address do not 1011 correspond to any binding known to the server, then the server SHOULD 1012 return a DHCP Reply with a error code of 5. 1014 Otherwise, if the agent address and link-local address indicate a 1015 binding known to the server, then the server continues processing 1016 for the Release message. If there are any Extensions, the server 1017 releases the particular configuration items specified in the 1018 extensions. Otherwise, if there are no extensions, the server 1019 releases all configuration information in the client's binding. 1021 After performing the operations indicated in the DHCP Release 1022 message and its Extensions, the DHCPv6 server formulates a DHCP 1023 Reply message, copying the transaction-ID, from the DHCP Release 1024 message. For each Extension in the DHCP Release message successfully 1025 processed by the server, a matching Extension is appended to the DHCP 1026 Reply message. Extensions in the DHCP Release message which cannot 1027 be successfully processed by the server MUST NOT correspond to any 1028 Extension appended to the Reply by the server. 1030 6.4. DHCP Reconfigure Message Processing 1032 If a DHCPv6 server needs to change the configuration associated 1033 to any of its clients, it constructs a DHCP Reconfigure message 1034 and sends it to each such client. The Reconfigure message MUST 1035 contain the particular Extensions which inform the client about which 1036 configuration information needs to be changed. 1038 DISCUSSION: Perhaps a DHCPv6 server should be allowed to 1039 multicast a DHCP Reconfigure message to its 1040 clients. There are issues to be resolved here. 1041 There is concern about encouraging servers to send 1042 such messages to any DHCP-wide multicast address. 1044 Perhaps a new extension should be defined so that 1045 the server can ask (some of) its clients to join a 1046 specific multicast group. Then the server could 1047 efficiently multicast Reconfigure messages to 1048 whatever group it wants. 1050 This would have the additional advantage that 1051 clients could receive Reconfigure messages without 1052 listening to any specific UDP port. 1054 If multiple clients can receive the same 1055 Reconfigure message, some algorithm must be 1056 specified so that the clients stagger their 1057 responses (i.e., their DHCP Requests) so that 1058 the server isn't deluged all at once with some 1059 arbitrarily large number of client Requests. 1061 7. DHCP Relay Considerations 1063 The DHCPv6 protocol is constructed so that a relay does not have 1064 to maintain any state in order to facilitate DHCPv6 client/server 1065 interactions. 1067 All relays MUST use the IPv6 address of the interface from which the 1068 DHCPv6 message is transmitted as the source address for the IP header 1069 of that DHCPv6 message. 1071 7.1. DHCP Solicit and DHCP Advertise Message Processing 1073 Upon receiving a DHCP Solicit message from a client, a relay 1074 constructs a DHCP Advertise message and transmits it to the 1075 soliciting client on the same link as the solicitation was received 1076 from. The destination address of the advertisement MUST be the 1077 source address of the solicitation. 1079 DISCUSSION: If the Solicit is delivered to a server and 1080 the server is allowed to send the corresponding 1081 Advertise back to a client, the server could then 1082 include some prospective information to "entice" a 1083 client to use its services. For instance, a server 1084 could include proposed lifetime information, and a 1085 client could pick the server with the best "terms". 1086 Presumably, this forwarding behavior should be a 1087 matter of relay configuration instead of client 1088 request. I'll assume that for now and try to make 1089 the protocol reflect the ability of DHCP Advertise 1090 messages to contain Extensions and come from DHCP 1091 servers off-link. That may take a little more 1092 doing which isn't in the protocol right now, be 1093 patient. 1095 When transmitting a DHCP Advertise message, a relay indicates how 1096 many server addresses which it was configured to advertise, and 1097 includes each address in the DHCP Advertise message. The DHCP 1098 Advertise message must use a routeable IPv6 address in the source 1099 address of the IPv6 header of the message. In particular, the source 1100 address of any DHCP Advertise message sent by a DHCPv6 relay MUST NOT 1101 be a link-local address. 1103 7.2. DHCP Request Message Processing 1105 When a relay receives a DHCP Request message, it MUST check that the 1106 message is received from a link-local address, that the link-local 1107 address matches the link-local address field in the Request message 1108 header, and that the agent address field of the message matches an 1109 IPv6 address associated to the interface from which the DHCP Request 1110 message was received. The relay MUST also check whether the 'S' 1111 bit is set in the message header. If any of these checks fail, the 1112 message is not acceptable and MUST be silently discarded. 1114 If the received request message is acceptable, the relay then 1115 transmits the DHCP Request message to the DHCPv6 server found in the 1116 Server Address field of the received DHCP Request message. All of 1117 the fields of DHCP Request message header transmitted by the relay 1118 are copied over unchanged from the DHCP Request received from the 1119 client. Only the fields in the IPv6 header will differ from the 1120 datagram received from the client, not the payload. 1122 7.3. DHCP Reply Message Processing 1124 When the relay receives a DHCP Reply, it MUST check whether the 1125 message has the 'L' bit set. It must check whether the link-local 1126 address field contains an IPv6 address that has prefix FE80::00 . 1127 If all the checks are satisfied, the relay MUST send a DHCP Reply 1128 message to the link-local address listed in the received Reply 1129 message. Only the fields in the IPv6 header will differ from the 1130 datagram received from the server, not the payload. 1132 7.4. Retransmission and Configuation Variables 1134 When a DHCPv6 client does not receive a DHCP Reply in response to a 1135 pending DHCP Request, the client MUST retransmit the identical DHCP 1136 Request to the same server again until it can be reasonably sure that 1137 the DHCPv6 server is unavailable and an alternative can be chosen. 1138 It is important for the DHCP Server to be sure that its client has 1139 received the configuration information included with the Extensions 1140 to the DHCP Reply message. 1142 Likewise, but less commonly, when a DHCP server does not receive a 1143 DHCP Request message in response to its DHCP Reconfigure message to 1144 the client, the server MUST retransmit the identical DHCP Reconfigure 1145 to the client until it is reasonably certain that the client is not 1146 available for reconfiguration. If no corresponding DHCP Request 1147 is ever received by the server, the server MAY erase or deallocate 1148 information as needed from the client's binding. 1150 These retransmissions occur using the following configuration 1151 variables for a DHCPv6 implementation that MUST be configurable by a 1152 client or server are as follows: 1154 REPLY_MSG_INITIAL_TIMEOUT 1156 The time in seconds that a DHCPv6 client waits to receive a 1157 server's DHCP Reply before retransmitting a DHCP Request. 1159 Default: 2 seconds. 1161 REPLY_MSG_MIN_RETRANS 1163 The minimum number of DHCP Request transmissions that a DHCPv6 1164 client should retransmit, before aborting the request, possibly 1165 retrying the Request with another Server, and logging DHCPv6 1166 System Error. 1168 Default: 10 retransmissions. 1170 RECONF_MSG_INITIAL_TIMEOUT 1172 The time in seconds that a DHCPv6 server waits to receive 1173 a client's DHCP Request before retransmitting its DHCP 1174 Reconfigure. 1176 Default: 2 seconds. 1178 RECONF_MSG_MIN_RETRANS 1180 The minimum number of DHCP Reconfigure messages that a DHCPv6 1181 server should retransmit, before assuming the the client is 1182 unavailable and that the server can proceed with the needed 1183 reconfiguration of that client's resources, and logging DHCPv6 1184 System Error. 1186 Default: 10 retransmissions. 1188 The following parameter specifies how long a DHCPv6 server has to 1189 keep track of client transaction-IDs in order to make sure that 1190 client retransmissions using the same transaction-ID are idempotent. 1192 TRANSACTION_IT_TIMEOUT 1194 Default: 10800 seconds 1196 8. Security Considerations 1198 It may often be very important for DHCP clients and servers to be 1199 able to authenticate the messages they exchange. For instance, a 1200 DHCP server may wish to be certain that a DHCP Request originated 1201 from the client identified by the 1202 fields included within the Request message header. Conversely, 1203 it is often essential for a DHCP client to be certain that the 1204 configuration parameters and addresses it has received were sent to 1205 it by an authoritative DHCP server. Similarly, a DHCP server should 1206 only accept a DHCP Release message which seems to be from one of 1207 its clients, if it has some assurance that the client actually did 1208 transmit the Release message. At the time of this writing, there 1209 is no generally accepted mechanism useful with DHCPv4 that can be 1210 extended for use with DHCPv6. 1212 There has been some discussion about the advisability and 1213 desirability of using IPv6 Authentication to allow DHCPv6 clients 1214 and servers to authenticate messages which they exchange. However, 1215 in many circumstances a client has only a link-local address, and a 1216 link-local address cannot be forwarded to a server which is off-link. 1217 Thus, the DHCP relay _has_to be involved, for instance, with the DHCP 1218 Request when the client has only a link-local address, and therefore 1219 the DHCP Request (in this circumstance) MUST have the relay's address 1220 in the IPv6 destination address field. 1222 That means that the authentication (in this circumstance) CANNOT be 1223 end-to-end. That means that IPsec cannot apply. Thus, in order to 1224 authenticate DHCP Request messages in many circumstances will require 1225 a more specialized technique for message authentication, as specified 1226 in the DHCPv6 Extensions companion document [5]. 1228 One possibility is to allow relays to encapsulate the DHCP Request 1229 before delivery to the server. Then the client could apply 1230 end-to-end authentication (such as afforded by IPSec) which would 1231 nevertheless remain untouched by the relay. The relay could, if 1232 desired, apply its own authentication header to the encapsulated 1233 datagrams. 1235 9. Acknowledgements 1237 Thanks to the DHC Working Group for their time and input into the 1238 specification. A special thanks for the consistent input, ideas, 1239 and review by (in alphabetical order) Brian Carpenter, Ralph Droms, 1240 Thomas Narten, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson, 1241 and Phil Wells. 1243 Thanks to Steve Deering and Bob Hinden, who have consistently 1244 taken the time to discuss the more complex parts of the IPv6 1245 specifications. 1247 The authors MUST also thank their employers for the opportunity and 1248 funding to work on DHCPv6 and IPv6 in general as an individual in the 1249 IETF. 1251 A. Related Work in IPv6 1253 The related work in IPv6 that would best serve an implementor 1254 to study is the IPv6 Specification [2], the IPv6 Addressing 1255 Architecture [3], IPv6 Stateless Address Autoconfiguration [9], IPv6 1256 Neighbor Discovery Processing [4], and Dynamic Updates to DNS [10]. 1257 These specifications afford DHCPv6 to build upon the IPv6 work to 1258 provide both robust stateful autoconfiguration and autoregistration 1259 of DNS Host Names. 1261 The IPv6 Specification provides the base architecture and design of 1262 IPv6. A key point for DHCPv6 implementors to understand is that IPv6 1263 requires that every link in the internet have an MTU of 576 octets or 1264 greater (in IPv4 the requirement is 68 octets). This means that a 1265 UDP datagram of 536 octets will always pass through an internet (less 1266 40 octets for the IPv6 header), as long as there are no IP options 1267 prior to the UDP header in the datagram. But, IPv6 does not support 1268 fragmentation at routers and fragmentation must take place end-to-end 1269 between hosts. If a DHCPv6 implementation needs to send a datagram 1270 greater than 536 octets it can either fragment the UDP datagram 1271 in UDP or use Path MTU Discovery [2] to determine the size of the 1272 datagram that will traverse a network path. It is implementation 1273 defined how this is accomplished in DHCPv6. 1275 The IPv6 Addressing Architecture Specification provides the address 1276 scope that can be used in an IPv6 implementation, and the various 1277 configuration architecture guidelines for network designers of 1278 the IPv6 address space. Two advantages of IPv6 is that multicast 1279 addressing is well defined and nodes can create link-local addresses 1280 during initialization of the nodes environment. This means that a 1281 host immediately can configure an IPv6 address at initialization 1282 for an interface, before communicating in any manner on the link. 1283 The host can then use a well-known multicast address to begin 1284 communications to discover neighbors on the link, or as was discussed 1285 in the specification to locate a DHCPv6 server or relay. 1287 The IPv6 Stateless Address Autoconfiguration Specification [9] 1288 defines how a host can autoconfigure addresses based on neighbor 1289 discovery router advertisements, and the use of a validation lifetime 1290 to support renumbering of addresses on the Internet. In addition the 1291 addrconf specification defines the protocol interaction for a host to 1292 begin stateless or stateful autoconfiguration. DHCPv6 is one vehicle 1293 to perform stateful autoconfiguration. Compatibility with addrconf 1294 is a design goal of DHCPv6. 1296 IPv6 Neighbor Discovery (ND) [4] is the node discovery protocol in 1297 IPv6 (replaces and enhances functions of IPv4 ARP Model [6]). To 1298 truly understand IPv6 and addrconf it is strongly recommended that 1299 implementors understand IPv6 ND. 1301 Dynamic Updates to DNS [10] is a specification that supports the 1302 dynamic update of DNS records for both IPv4 and IPv6. DHCPv6 can use 1303 the dynamic updates to DNS to now integrate addresses and name space 1304 to not only support autoconfiguration, but also autoregistration in 1305 IPv6. 1307 B. Change History 1309 B.1. Changes from November 95 to February 96 Drafts 1311 Substituted use of client's link-local address for previous uses of 1312 client's interface token. 1314 Reorganized DHCP messages into Solicit/Advertise, Request/Reply, 1315 Release, and Reconfigure. 1317 Made message-specific formats instead of using the same DHCP header 1318 for each message. 1320 Eliminated retransmission message types. 1322 Server commits after receiving DHCP Request, and optimistically 1323 depends on client retransmissions as negative acknowledgement. 1325 Eliminated total-addrs. 1327 Eliminated all definitions and most fields related to allocating IPv6 1328 addresses (moved to the Extensions specification). 1330 Renamed "gateway address" to be "agent address". 1332 References 1334 [1] S. Bradner and A. Mankin. The Recommendation for the IP Next 1335 Generation Protocol. RFC 1752, January 1995. 1337 [2] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1338 Specification. RFC 1883, December 1995. 1340 [3] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 1341 RFC 1883, December 1995. 1343 [4] T. Narten, E. Nordmark, and W. Simpson. IPv6 Neighbor 1344 Discovery. draft-ietf-ipngwg-discovery-03.txt -- work in 1345 progress, November 1995. 1347 [5] C. Perkins. Extensions to DHCPv6. draft-ietf-dhc-dhcpv6ext-00.txt 1348 -- work in progress, November 1995. 1350 [6] David C. Plummer. An Ethernet Address Resolution Protocol: 1351 Or Converting Network Protocol Addresses to 48.bit Ethernet 1352 Addresses for Transmission on Ethernet Hardware. RFC 826, 1353 November 1982. 1355 [7] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 1357 [8] J. B. Postel, editor. Internet Protocol. RFC 791, September 1358 1981. 1360 [9] S. Thomson and T. Narten. IPv6 Stateless Address 1361 Autoconfiguration. draft-ietf-addrconf-ipv6-auto-06.txt 1362 - work in progress, November 1995. 1364 [10] S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the 1365 Domain Name System (DNS). draft-ietf-dnsind-dynDNS-06.txt -- 1366 work in progress, February 1996. 1368 Chair's Address 1370 The working group can be contacted via the current chair: 1372 Ralph Droms 1373 Computer Science Department 1374 323 Dana Engineering 1375 Bucknell University 1376 Lewisburg, PA 17837 1378 Phone: (717) 524-1145 1379 E-mail: droms@bucknell.edu 1381 Author's Address 1383 Questions about this memo can be directed to: 1385 Jim Bound Charles Perkins 1386 Digital Equipment Corporation T. J. Watson Research Center 1387 110 Spitbrook Road, ZKO3-3/U14 IBM Corporation 1388 Nashua, NH 03062 30 Saw Mill River Rd., Rm J1-A25 1389 Hawthorne, NY 10532 1390 Phone: +1-603-881-0400 +1-914-784-7350 1391 Fax: +1-914-784-6205 1392 E-mail: bound@zk3.dec.com perk@watson.ibm.com