idnits 2.17.1 draft-dhcwg-dhc-rfc3315bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3633, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC3736, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC3315, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2014) is 3466 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration (DHC) T. Mrugalski, Ed. 3 Internet-Draft M. Siodelski 4 Obsoletes: 3315,3633,3736 (if approved) ISC 5 Intended status: Standards Track B. Volz 6 Expires: April 30, 2015 A. Yourtchenko 7 Cisco 8 M. Richardson 9 SSW 10 S. Jiang 11 Huawei 12 T. Lemon 13 Nominum 14 October 27, 2014 16 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis 17 draft-dhcwg-dhc-rfc3315bis-03 19 Abstract 21 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP 22 servers to pass configuration parameters such as IPv6 network 23 addresses to IPv6 nodes. It offers the capability of automatic 24 allocation of reusable network addresses and additional configuration 25 flexibility. This protocol is a stateful counterpart to "IPv6 26 Stateless Address Autoconfiguration" (RFC 4862), and can be used 27 separately or concurrently with the latter to obtain configuration 28 parameters. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 30, 2015. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 6 77 1.1. Protocols and Addressing . . . . . . . . . . . . . . . . 7 78 1.2. Client-server Exchanges Involving Two Messages . . . . . 7 79 1.3. Client-server Exchanges Involving Four Messages . . . . . 8 80 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 81 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 4.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 10 84 4.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 11 85 5. Operational Models . . . . . . . . . . . . . . . . . . . . . 14 86 5.1. Stateless DHCPv6 . . . . . . . . . . . . . . . . . . . . 14 87 5.2. DHCPv6 for Non-Temporary Address Assignment . . . . . . . 15 88 5.3. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 15 89 5.4. DHCPv6 for Customer Edge Routers . . . . . . . . . . . . 18 90 5.5. DHCPv6 for Temporary Addresses . . . . . . . . . . . . . 18 91 6. DHCP Constants . . . . . . . . . . . . . . . . . . . . . . . 18 92 6.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 18 93 6.2. UDP Ports . . . . . . . . . . . . . . . . . . . . . . . . 19 94 6.3. DHCP Message Types . . . . . . . . . . . . . . . . . . . 19 95 6.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 21 96 6.5. Transmission and Retransmission Parameters . . . . . . . 21 97 6.6. Representation of time values and "Infinity" as a time 98 value . . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 7. Client/Server Message Formats . . . . . . . . . . . . . . . . 22 100 8. Relay Agent/Server Message Formats . . . . . . . . . . . . . 23 101 8.1. Relay-forward Message . . . . . . . . . . . . . . . . . . 24 102 8.2. Relay-reply Message . . . . . . . . . . . . . . . . . . . 25 103 9. Representation and Use of Domain Names . . . . . . . . . . . 25 104 10. DHCP Unique Identifier (DUID) . . . . . . . . . . . . . . . . 25 105 10.1. DUID Contents . . . . . . . . . . . . . . . . . . . . . 26 106 10.2. DUID Based on Link-layer Address Plus Time, DUID-LLT . . 26 107 10.3. DUID Assigned by Vendor Based on Enterprise Number, 108 DUID-EN . . . . . . . . . . . . . . . . . . . . . . . . 28 109 10.4. DUID Based on Link-layer Address, DUID-LL . . . . . . . 29 110 11. Identity Association . . . . . . . . . . . . . . . . . . . . 30 111 11.1. Identity Associations for Address Assignment . . . . . . 30 112 11.2. Identity Associations for Prefix Delegation . . . . . . 30 113 12. Selecting Addresses for Assignment to an IA . . . . . . . . . 31 114 13. Management of Temporary Addresses . . . . . . . . . . . . . . 32 115 14. Transmission of Messages by a Client . . . . . . . . . . . . 33 116 15. Reliability of Client Initiated Message Exchanges . . . . . . 33 117 16. Message Validation . . . . . . . . . . . . . . . . . . . . . 35 118 16.1. Use of Transaction IDs . . . . . . . . . . . . . . . . . 35 119 16.2. Solicit Message . . . . . . . . . . . . . . . . . . . . 35 120 16.3. Advertise Message . . . . . . . . . . . . . . . . . . . 36 121 16.4. Request Message . . . . . . . . . . . . . . . . . . . . 36 122 16.5. Confirm Message . . . . . . . . . . . . . . . . . . . . 36 123 16.6. Renew Message . . . . . . . . . . . . . . . . . . . . . 36 124 16.7. Rebind Message . . . . . . . . . . . . . . . . . . . . . 37 125 16.8. Decline Messages . . . . . . . . . . . . . . . . . . . . 37 126 16.9. Release Message . . . . . . . . . . . . . . . . . . . . 37 127 16.10. Reply Message . . . . . . . . . . . . . . . . . . . . . 37 128 16.11. Reconfigure Message . . . . . . . . . . . . . . . . . . 38 129 16.12. Information-request Message . . . . . . . . . . . . . . 38 130 16.13. Relay-forward Message . . . . . . . . . . . . . . . . . 39 131 16.14. Relay-reply Message . . . . . . . . . . . . . . . . . . 39 132 17. Client Source Address and Interface Selection . . . . . . . . 39 133 17.1. Address Assignment . . . . . . . . . . . . . . . . . . . 39 134 17.2. Prefix Delegation . . . . . . . . . . . . . . . . . . . 39 135 18. DHCP Server Solicitation . . . . . . . . . . . . . . . . . . 40 136 18.1. Client Behavior . . . . . . . . . . . . . . . . . . . . 40 137 18.1.1. Creation of Solicit Messages . . . . . . . . . . . . 40 138 18.1.2. Transmission of Solicit Messages . . . . . . . . . . 41 139 18.1.3. Receipt of Advertise Messages . . . . . . . . . . . 42 140 18.1.4. Receipt of Reply Message . . . . . . . . . . . . . . 43 141 18.2. Server Behavior . . . . . . . . . . . . . . . . . . . . 44 142 18.2.1. Receipt of Solicit Messages . . . . . . . . . . . . 44 143 18.2.2. Creation and Transmission of Advertise Messages . . 44 144 18.2.3. Creation and Transmission of Reply Messages . . . . 45 145 18.3. Client behavior for Prefix Delegation . . . . . . . . . 46 146 18.4. Server Behavior for Prefix Delegation . . . . . . . . . 46 147 19. DHCP Client-Initiated Configuration Exchange . . . . . . . . 47 148 19.1. Client Behavior . . . . . . . . . . . . . . . . . . . . 47 149 19.1.1. Creation and Transmission of Request Messages . . . 48 150 19.1.2. Creation and Transmission of Confirm Messages . . . 49 151 19.1.3. Creation and Transmission of Renew Messages . . . . 50 152 19.1.4. Creation and Transmission of Rebind Messages . . . . 51 153 19.1.5. Creation and Transmission of Information-request 154 Messages . . . . . . . . . . . . . . . . . . . . . . 52 155 19.1.6. Creation and Transmission of Release Messages . . . 53 156 19.1.7. Creation and Transmission of Decline Messages . . . 54 157 19.1.8. Receipt of Reply Messages . . . . . . . . . . . . . 55 158 19.2. Server Behavior . . . . . . . . . . . . . . . . . . . . 57 159 19.2.1. Receipt of Request Messages . . . . . . . . . . . . 58 160 19.2.2. Receipt of Confirm Messages . . . . . . . . . . . . 59 161 19.2.3. Receipt of Renew Messages . . . . . . . . . . . . . 59 162 19.2.4. Receipt of Rebind Messages . . . . . . . . . . . . . 60 163 19.2.5. Receipt of Information-request Messages . . . . . . 61 164 19.2.6. Receipt of Release Messages . . . . . . . . . . . . 61 165 19.2.7. Receipt of Decline Messages . . . . . . . . . . . . 62 166 19.2.8. Transmission of Reply Messages . . . . . . . . . . . 63 167 20. DHCP Server-Initiated Configuration Exchange . . . . . . . . 63 168 20.1. Server Behavior . . . . . . . . . . . . . . . . . . . . 63 169 20.1.1. Creation and Transmission of Reconfigure Messages . 63 170 20.1.2. Time Out and Retransmission of Reconfigure Messages 64 171 20.2. Receipt of Renew or Rebind Messages . . . . . . . . . . 65 172 20.3. Receipt of Information-request Messages . . . . . . . . 65 173 20.4. Client Behavior . . . . . . . . . . . . . . . . . . . . 65 174 20.4.1. Receipt of Reconfigure Messages . . . . . . . . . . 65 175 20.4.2. Creation and Transmission of Renew or Rebind 176 Messages . . . . . . . . . . . . . . . . . . . . . . 66 177 20.4.3. Creation and Transmission of Information-request 178 Messages . . . . . . . . . . . . . . . . . . . . . . 67 179 20.4.4. Time Out and Retransmission of Renew, Rebind or 180 Information-request Messages . . . . . . . . . . . . 67 181 20.4.5. Receipt of Reply Messages . . . . . . . . . . . . . 67 182 20.5. Prefix Delegation reconfiguration . . . . . . . . . . . 67 183 20.5.1. Delegating Router behavior . . . . . . . . . . . . . 67 184 20.5.2. Requesting Router behavior . . . . . . . . . . . . . 68 185 21. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 68 186 21.1. Relaying a Client Message or a Relay-forward Message . . 68 187 21.1.1. Relaying a Message from a Client . . . . . . . . . . 68 188 21.1.2. Relaying a Message from a Relay Agent . . . . . . . 69 189 21.1.3. Relay agent behavior with Prefix Delegation . . . . 69 190 21.2. Relaying a Relay-reply Message . . . . . . . . . . . . . 69 191 21.3. Construction of Relay-reply Messages . . . . . . . . . . 70 192 22. Authentication of DHCP Messages . . . . . . . . . . . . . . . 71 193 22.1. Security of Messages Sent Between Servers and Relay 194 Agents . . . . . . . . . . . . . . . . . . . . . . . . . 71 195 22.2. Summary of DHCP Authentication . . . . . . . . . . . . . 72 196 22.3. Replay Detection . . . . . . . . . . . . . . . . . . . . 73 197 22.4. Delayed Authentication Protocol . . . . . . . . . . . . 73 198 22.4.1. Use of the Authentication Option in the Delayed 199 Authentication Protocol . . . . . . . . . . . . . . 73 200 22.4.2. Message Validation . . . . . . . . . . . . . . . . . 75 201 22.4.3. Key Utilization . . . . . . . . . . . . . . . . . . 75 202 22.4.4. Client Considerations for Delayed Authentication 203 Protocol . . . . . . . . . . . . . . . . . . . . . . 75 204 22.4.4.1. Sending Solicit Messages . . . . . . . . . . . . 76 205 22.4.4.2. Receiving Advertise Messages . . . . . . . . . . 76 206 22.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline 207 or Release Messages . . . . . . . . . . . . . . 77 208 22.4.4.4. Sending Information-request Messages . . . . . . 77 209 22.4.4.5. Receiving Reply Messages . . . . . . . . . . . . 77 210 22.4.4.6. Receiving Reconfigure Messages . . . . . . . . . 77 211 22.4.5. Server Considerations for Delayed Authentication 212 Protocol . . . . . . . . . . . . . . . . . . . . . . 77 213 22.4.5.1. Receiving Solicit Messages and Sending Advertise 214 Messages . . . . . . . . . . . . . . . . . . . . 78 215 22.4.5.2. Receiving Request, Confirm, Renew, Rebind or 216 Release Messages and Sending Reply Messages . . 78 217 22.5. Reconfigure Key Authentication Protocol . . . . . . . . 78 218 22.5.1. Use of the Authentication Option in the Reconfigure 219 Key Authentication Protocol . . . . . . . . . . . . 79 220 22.5.2. Server considerations for Reconfigure Key protocol . 79 221 22.5.3. Client considerations for Reconfigure Key protocol . 80 222 23. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 80 223 23.1. Format of DHCP Options . . . . . . . . . . . . . . . . . 81 224 23.2. Client Identifier Option . . . . . . . . . . . . . . . . 81 225 23.3. Server Identifier Option . . . . . . . . . . . . . . . . 82 226 23.4. Identity Association for Non-temporary Addresses Option 83 227 23.5. Identity Association for Temporary Addresses Option . . 85 228 23.6. IA Address Option . . . . . . . . . . . . . . . . . . . 86 229 23.7. Option Request Option . . . . . . . . . . . . . . . . . 88 230 23.8. Preference Option . . . . . . . . . . . . . . . . . . . 89 231 23.9. Elapsed Time Option . . . . . . . . . . . . . . . . . . 89 232 23.10. Relay Message Option . . . . . . . . . . . . . . . . . . 90 233 23.11. Authentication Option . . . . . . . . . . . . . . . . . 91 234 23.12. Server Unicast Option . . . . . . . . . . . . . . . . . 92 235 23.13. Status Code Option . . . . . . . . . . . . . . . . . . . 93 236 23.14. Rapid Commit Option . . . . . . . . . . . . . . . . . . 94 237 23.15. User Class Option . . . . . . . . . . . . . . . . . . . 95 238 23.16. Vendor Class Option . . . . . . . . . . . . . . . . . . 96 239 23.17. Vendor-specific Information Option . . . . . . . . . . . 98 240 23.18. Interface-Id Option . . . . . . . . . . . . . . . . . . 100 241 23.19. Reconfigure Message Option . . . . . . . . . . . . . . . 101 242 23.20. Reconfigure Accept Option . . . . . . . . . . . . . . . 101 243 23.21. Identity Association for Prefix Delegation Option . . . 102 244 23.22. IA Prefix Option . . . . . . . . . . . . . . . . . . . . 104 245 23.23. SOL_MAX_RT Option . . . . . . . . . . . . . . . . . . . 105 246 23.24. INF_MAX_RT Option . . . . . . . . . . . . . . . . . . . 106 247 24. Security Considerations . . . . . . . . . . . . . . . . . . . 107 248 25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 110 249 25.1. Multicast Addresses . . . . . . . . . . . . . . . . . . 111 250 25.2. DHCP Message Types . . . . . . . . . . . . . . . . . . . 111 251 25.3. DHCP Options . . . . . . . . . . . . . . . . . . . . . . 112 252 25.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 113 253 25.5. DUID . . . . . . . . . . . . . . . . . . . . . . . . . . 113 254 26. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 114 255 27. References . . . . . . . . . . . . . . . . . . . . . . . . . 115 256 27.1. Normative References . . . . . . . . . . . . . . . . . . 115 257 27.2. Informative References . . . . . . . . . . . . . . . . . 117 258 Appendix A. Changes since RFC3315 . . . . . . . . . . . . . . . 118 259 Appendix B. Changes since RFC3633 . . . . . . . . . . . . . . . 120 260 Appendix C. Appearance of Options in Message Types . . . . . . . 120 261 Appendix D. Appearance of Options in the Options Field of DHCP 262 Options . . . . . . . . . . . . . . . . . . . . . . 121 263 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 122 265 1. Introduction and Overview 267 This document describes DHCP for IPv6 (DHCP), a client/server 268 protocol that provides managed configuration of devices. 270 DHCP can provide a device with addresses assigned by a DHCP server 271 and other configuration information, which are carried in options. 272 DHCP can be extended through the definition of new options to carry 273 configuration information not specified in this document. 275 DHCP is the "stateful address autoconfiguration protocol" and the 276 "stateful autoconfiguration protocol" referred to in "IPv6 Stateless 277 Address Autoconfiguration" [RFC4862]. 279 This document also provides a mechanism for automated delegation of 280 IPv6 prefixes using DHCP. Through this mechanism, a delegating 281 router can delegate prefixes to requesting routers. 283 The operational models and relevant configuration information for 284 DHCPv4 [RFC2132][RFC2131] and DHCPv6 are sufficiently different that 285 integration between the two services is not included in this 286 document. [RFC3315] suggested that future work might be to extend 287 DHCPv6 to carry IPv4 address and configuration information. However, 288 the current consensus of the IETF is that DHCPv4 should be used 289 rather than DHCPv6 when conveying IPv4 configuration information to 290 nodes. [RFC7341] describes a transport mechanism to carry DHCPv4 291 messages using the DHCPv6 protocol for the dynamic provisioning of 292 IPv4 address and configuration information across IPv6-only networks. 294 The remainder of this introduction summarizes DHCP, explaining the 295 message exchange mechanisms and example message flows. The message 296 flows in Section 1.2 and Section 1.3 are intended as illustrations of 297 DHCP operation rather than an exhaustive list of all possible client- 298 server interactions. Section 5 provides an overview of common 299 operational models. Section 18, Section 19, and Section 20 explain 300 client and server operation in detail. 302 1.1. Protocols and Addressing 304 Clients and servers exchange DHCP messages using UDP [RFC0768]. The 305 client uses a link-local address or addresses determined through 306 other mechanisms for transmitting and receiving DHCP messages. 308 A DHCP client sends most messages using a reserved, link-scoped 309 multicast destination address so that the client need not be 310 configured with the address or addresses of DHCP servers. 312 To allow a DHCP client to send a message to a DHCP server that is not 313 attached to the same link, a DHCP relay agent on the client's link 314 will relay messages between the client and server. The operation of 315 the relay agent is transparent to the client and the discussion of 316 message exchanges in the remainder of this section will omit the 317 description of message relaying by relay agents. 319 Once the client has determined the address of a server, it may under 320 some circumstances send messages directly to the server using 321 unicast. 323 1.2. Client-server Exchanges Involving Two Messages 325 When a DHCP client does not need to have a DHCP server assign it IP 326 addresses, the client can obtain configuration information such as a 327 list of available DNS servers [RFC3646] or NTP servers [RFC4075] 328 through a single message and reply exchanged with a DHCP server. To 329 obtain configuration information the client first sends an 330 Information-request message to the All_DHCP_Relay_Agents_and_Servers 331 multicast address. Servers respond with a Reply message containing 332 the configuration information for the client. 334 This message exchange assumes that the client requires only 335 configuration information and does not require the assignment of any 336 IPv6 addresses. 338 When a server has IPv6 addresses and other configuration information 339 committed to a client, the client and server may be able to complete 340 the exchange using only two messages, instead of four messages as 341 described in the next section. In this case, the client sends a 342 Solicit message to the All_DHCP_Relay_Agents_and_Servers requesting 343 the assignment of addresses and other configuration information. 344 This message includes an indication that the client is willing to 345 accept an immediate Reply message from the server. The server that 346 is willing to commit the assignment of addresses to the client 347 immediately responds with a Reply message. The configuration 348 information and the addresses in the Reply message are then 349 immediately available for use by the client. 351 Each address assigned to the client has associated preferred and 352 valid lifetimes specified by the server. To request an extension of 353 the lifetimes assigned to an address, the client sends a Renew 354 message to the server. The server sends a Reply message to the 355 client with the new lifetimes, allowing the client to continue to use 356 the address without interruption. 358 1.3. Client-server Exchanges Involving Four Messages 360 To request the assignment of one or more IPv6 addresses, a client 361 first locates a DHCP server and then requests the assignment of 362 addresses and other configuration information from the server. The 363 client sends a Solicit message to the 364 All_DHCP_Relay_Agents_and_Servers address to find available DHCP 365 servers. Any server that can meet the client's requirements responds 366 with an Advertise message. The client then chooses one of the 367 servers and sends a Request message to the server asking for 368 confirmed assignment of addresses and other configuration 369 information. The server responds with a Reply message that contains 370 the confirmed addresses and configuration. 372 As described in the previous section, the client sends a Renew 373 message to the server to extend the lifetimes associated with its 374 addresses, allowing the client to continue to use those addresses 375 without interruption. 377 2. Requirements 379 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 380 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 381 document, are to be interpreted as described in [RFC2119]. 383 This document also makes use of internal conceptual variables to 384 describe protocol behavior and external variables that an 385 implementation must allow system administrators to change. The 386 specific variable names, how their values change, and how their 387 settings influence protocol behavior are provided to demonstrate 388 protocol behavior. An implementation is not required to have them in 389 the exact form described here, so long as its external behavior is 390 consistent with that described in this document. 392 3. Background 394 The IPv6 Specification provides the base architecture and design of 395 IPv6. Related work in IPv6 that would best serve an implementor to 396 study includes the IPv6 Specification [RFC2460], the IPv6 Addressing 397 Architecture [RFC4291], IPv6 Stateless Address Autoconfiguration 398 [RFC4862], IPv6 Neighbor Discovery Processing [RFC4861], and Dynamic 399 Updates to DNS [RFC2136]. These specifications enable DHCP to build 400 upon the IPv6 work to provide both robust stateful autoconfiguration 401 and autoregistration of DNS Host Names. 403 The IPv6 Addressing Architecture specification [RFC4291] defines the 404 address scope that can be used in an IPv6 implementation, and the 405 various configuration architecture guidelines for network designers 406 of the IPv6 address space. Two advantages of IPv6 are that support 407 for multicast is required and nodes can create link-local addresses 408 during initialization. The availability of these features means that 409 a client can use its link-local address and a well-known multicast 410 address to discover and communicate with DHCP servers or relay agents 411 on its link. 413 IPv6 Stateless Address Autoconfiguration [RFC4862] specifies 414 procedures by which a node may autoconfigure addresses based on 415 router advertisements [RFC4861], and the use of a valid lifetime to 416 support renumbering of addresses on the Internet. In addition, the 417 protocol interaction by which a node begins stateless or stateful 418 autoconfiguration is specified. DHCP is one vehicle to perform 419 stateful autoconfiguration. Compatibility with stateless address 420 autoconfiguration is a design requirement of DHCP. 422 IPv6 Neighbor Discovery [RFC4861] is the node discovery protocol in 423 IPv6 which replaces and enhances functions of ARP [RFC0826]. To 424 understand IPv6 and stateless address autoconfiguration, it is 425 strongly recommended that implementors understand IPv6 Neighbor 426 Discovery. 428 Dynamic Updates to DNS [RFC2136] is a specification that supports the 429 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 430 the dynamic updates to DNS to integrate addresses and name space to 431 not only support autoconfiguration, but also autoregistration in 432 IPv6. 434 4. Terminology 436 This section defines terminology specific to IPv6 and DHCP used in 437 this document. 439 4.1. IPv6 Terminology 441 IPv6 terminology relevant to this specification from the IPv6 442 Protocol [RFC2460], IPv6 Addressing Architecture [RFC4291], and IPv6 443 Stateless Address Autoconfiguration [RFC4862] is included below. 445 address An IP layer identifier for an interface or 446 a set of interfaces. 448 host Any node that is not a router. 450 IP Internet Protocol Version 6 (IPv6). The 451 terms IPv4 and IPv6 are used only in 452 contexts where it is necessary to avoid 453 ambiguity. 455 interface A node's attachment to a link. 457 link A communication facility or medium over 458 which nodes can communicate at the link 459 layer, i.e., the layer immediately below 460 IP. Examples are Ethernet (simple or 461 bridged); Token Ring; PPP links, X.25, 462 Frame Relay, or ATM networks; and Internet 463 (or higher) layer "tunnels", such as 464 tunnels over IPv4 or IPv6 itself. 466 link-layer identifier A link-layer identifier for an interface. 467 Examples include IEEE 802 addresses for 468 Ethernet or Token Ring network interfaces, 469 and E.164 addresses for ISDN links. 471 link-local address An IPv6 address having a link-only scope, 472 indicated by having the prefix (FE80::/10), 473 that can be used to reach neighboring nodes 474 attached to the same link. Every interface 475 has a link-local address. 477 multicast address An identifier for a set of interfaces 478 (typically belonging to different nodes). 480 A packet sent to a multicast address is 481 delivered to all interfaces identified by 482 that address. 484 neighbor A node attached to the same link. 486 node A device that implements IP. 488 packet An IP header plus payload. 490 prefix The initial bits of an address, or a set of 491 IP addresses that share the same initial 492 bits. 494 prefix length The number of bits in a prefix. 496 router A node that forwards IP packets not 497 explicitly addressed to itself. 499 unicast address An identifier for a single interface. A 500 packet sent to a unicast address is 501 delivered to the interface identified by 502 that address. 504 4.2. DHCP Terminology 506 Terminology specific to DHCP can be found below. 508 allocatable resource (or resource). It is an address, a prefix 509 or any other allocatable resource that may 510 be defined in the future. Currently there 511 are three defined allocatable resources: 512 non-temporary addresses, temporary 513 addresses and delegated prefixes. 515 appropriate to the link An address is "appropriate to the link" 516 when the address is consistent with the 517 DHCP server's knowledge of the network 518 topology, prefix assignment and address 519 assignment policies. 521 binding A binding (or, client binding) is a group 522 of server data records containing the 523 information the server has about the 524 addresses in an IA or configuration 525 information explicitly assigned to the 526 client. Configuration information that has 527 been returned to a client through a policy 528 - for example, the information returned to 529 all clients on the same link - does not 530 require a binding. A binding containing 531 information about an IA is indexed by the 532 tuple (where IA-type 533 is the type of address in the IA; for 534 example, temporary). A binding containing 535 configuration information for a client is 536 indexed by . 538 configuration parameter An element of the configuration information 539 set on the server and delivered to the 540 client using DHCP. Such parameters may be 541 used to carry information to be used by a 542 node to configure its network subsystem and 543 enable communication on a link or 544 internetwork, for example. 546 delegating router: The router that acts as a DHCP server, and 547 is responding to the prefix request. 549 DHCP Dynamic Host Configuration Protocol for 550 IPv6. The terms DHCPv4 and DHCPv6 are used 551 only in contexts where it is necessary to 552 avoid ambiguity. 554 DHCP client (or client) A node that initiates requests on a link to 555 obtain configuration parameters from one or 556 more DHCP servers. Depending on the 557 purpose of the client, it may feature the 558 requesting router functionality, if it 559 supports prefix delegation. 561 DHCP domain A set of links managed by DHCP and operated 562 by a single administrative entity. 564 DHCP realm A name used to identify the DHCP 565 administrative domain from which a DHCP 566 authentication key was selected. 568 DHCP relay agent (or relay agent) A node that acts as an 569 intermediary to deliver DHCP messages 570 between clients and servers. In certain 571 configurations there may be more than one 572 relay agent between clients and servers, so 573 a relay agent may send DHCP messages to 574 another relay agent. 576 DHCP server (or server) A node that responds to requests from 577 clients, and may or may not be on the same 578 link as the client(s). Depending on its 579 capabilities, it may also feature the 580 functionality of delegating router, if it 581 supports prefix delegation. 583 DUID A DHCP Unique IDentifier for a DHCP 584 participant; each DHCP client and server 585 has exactly one DUID. See Section 10 for 586 details of the ways in which a DUID may be 587 constructed. 589 IA Identity Association: A collection of 590 allocatable resources assigned to a client. 591 Each IA has an associated IAID. A client 592 may have more than one IA assigned to it; 593 for example, one for each of its 594 interfaces. Each IA holds one type of 595 address; for example, an identity 596 association for temporary addresses (IA_TA) 597 holds temporary addresses (see "identity 598 association for temporary addresses") and 599 identity association for prefix delegation 600 (IA_PD) holds delegated prefixes. 601 Throughout this document, "IA" is used to 602 refer to an identity association without 603 identifying the type of allocatable 604 resources in the IA. At the time of 605 writing this document, there are 3 IA types 606 defined: IA_NA, IA_TA and IA_PD. New IA 607 types may be defined in the future. 609 IAID Identity Association IDentifier: An 610 identifier for an IA, chosen by the client. 611 Each IA has an IAID, which is chosen to be 612 unique among all IAIDs for IAs belonging to 613 that client. 615 IA_NA Identity association for Non-temporary 616 Addresses: An IA that carries assigned 617 addresses that are not temporary addresses 618 (see "identity association for temporary 619 addresses") 621 IA_TA Identity Association for Temporary 622 Addresses: An IA that carries temporary 623 addresses (see [RFC4941]). 625 IA_PD Identity Association for Prefix Delegation: 626 A collection of prefixes assigned to the 627 requesting router. Each IA_PD has an 628 associated IAID. A requesting router may 629 have more than one IA_PD assigned to it; 630 for example, one for each of its 631 interfaces. 633 message A unit of data carried as the payload of a 634 UDP datagram, exchanged among DHCP servers, 635 relay agents and clients. 637 Reconfigure key A key supplied to a client by a server used 638 to provide security for Reconfigure 639 messages. 641 requesting router: The router that acts as a DHCP client and 642 is requesting prefix(es) to be assigned. 644 singleton option: An option that is allowed to appear only 645 once. Most options are singletons. 647 relaying A DHCP relay agent relays DHCP messages 648 between DHCP participants. 650 transaction ID An opaque value used to match responses 651 with replies initiated either by a client 652 or server. 654 5. Operational Models 656 This section describes some of the currently most common DHCPv6 657 operational models. The described models are not mutually exclusive 658 and are sometimes used together. For example, a device may start in 659 stateful mode to obtain an address, and at a later time when an 660 application is started, request additional parameters using stateless 661 mode. 663 5.1. Stateless DHCPv6 665 Stateless DHCPv6 [RFC3736] is used when DHCPv6 is not used for 666 obtaining an allocatable resource, but a node (DHCPv6 client) desires 667 one or more DHCPv6 "other configuration" parameters, such as a list 668 of DNS recursive name servers or DNS domain search lists [RFC3646]. 669 Stateless may be used when a node initially boots or at any time the 670 software on the node requires some missing or expired configuration 671 information that is available via DHCPv6. 673 This is the simplest and most basic operation for DHCPv6 and requires 674 a client (and a server) to support only two messages - Information- 675 request and Reply. Note that DHCPv6 servers and relay agents 676 typically also need to support the Relay-Forw and Relay-Reply 677 messages to accommodate operation when clients and servers are not on 678 the same link. 680 5.2. DHCPv6 for Non-Temporary Address Assignment 682 This model of operation was the original motivation for DHCPv6 and is 683 the "stateful address autoconfiguration protocol" for IPv6 [RFC2462]. 684 It is appropriate for situations where stateless address 685 autoconfiguration is not desired, because of network policy, 686 additional requirements (such as updating the DNS with forward or 687 reverse resource records), or client specific requirements (i.e., 688 some prefixes are only available to some clients) which are not 689 possible using stateless address autoconfiguration. 691 The model of operation for non-temporary address assignment is as 692 follows. The server is provided with IPv6 prefixes from which it may 693 allocate addresses to clients, as well as any related network 694 topology information as to which prefixes are present on which links. 695 A client requests a non-temporary address to be assigned by the 696 server. The server allocates an address or addresses appropriate for 697 the link on which the client is connected. The server returns the 698 allocated address or addresses to the client. 700 Each address has an associated preferred and valid lifetime, which 701 constitutes an agreement about the length of time over which the 702 client is allowed to use the address. A client can request an 703 extension of the lifetimes on an address and is required to terminate 704 the use of an address if the valid lifetime of the address expires. 706 Typically clients request other configuration parameters, such as the 707 domain server addresses and search lists, when requesting addresses. 709 5.3. DHCPv6 for Prefix Delegation 711 The prefix delegation mechanism, originally described in [RFC3633], 712 is another stateful mode of operation and intended for simple 713 delegation of prefixes from a delegating router (DHCPv6 server) to 714 requesting routers (DHCPv6 clients). It is appropriate for 715 situations in which the delegating router does not have knowledge 716 about the topology of the networks to which the requesting router is 717 attached, and the delegating router does not require other 718 information aside from the identity of the requesting router to 719 choose a prefix for delegation. For example, these options would be 720 used by a service provider to assign a prefix to a Customer Premise 721 Equipment (CPE) device acting as a router between the subscriber's 722 internal network and the service provider's core network. 724 The design of this prefix delegation mechanism meets the requirements 725 for prefix delegation in [RFC3769]. 727 The model of operation for prefix delegation is as follows. A 728 delegating router is provided IPv6 prefixes to be delegated to 729 requesting routers. Examples of ways in which the delegating router 730 may be provided these prefixes are given in Section XXXX (was 12.2 in 731 RFC 3633). A requesting router requests prefix(es) from the 732 delegating router, as described in Section XXXX (was 12.1 in RFC 733 3633). The delegating router chooses prefix(es) for delegation, and 734 responds with prefix(es) to the requesting router. The requesting 735 router is then responsible for the delegated prefix(es). For 736 example, the requesting router might assign a subnet from a delegated 737 prefix to one of its interfaces, and begin sending router 738 advertisements for the prefix on that link. 740 Each prefix has an associated valid and preferred lifetime, which 741 constitutes an agreement about the length of time over which the 742 requesting router is allowed to use the prefix. A requesting router 743 can request an extension of the lifetimes on a delegated prefix and 744 is required to terminate the use of a delegated prefix if the valid 745 lifetime of the prefix expires. 747 This prefix delegation mechanism would be appropriate for use by an 748 ISP to delegate a prefix to a subscriber, where the delegated prefix 749 would possibly be subnetted and assigned to the links within the 750 subscriber's network. 752 Figure 1 illustrates a network architecture in which prefix 753 delegation could be used. 755 ______________________ \ 756 / \ \ 757 | ISP core network | \ 758 \__________ ___________/ | 759 | | 760 +-------+-------+ | 761 | Aggregation | | ISP 762 | device | | network 763 | (delegating | | 764 | router) | | 765 +-------+-------+ | 766 | / 767 |DSL to subscriber / 768 |premises / 769 | 770 +------+------+ \ 771 | CPE | \ 772 | (requesting | \ 773 | router) | | 774 +----+---+----+ | 775 | | | Subsciber 776 ---+-------------+-----+ +-----+------ | Network 777 | | | | 778 +----+-----+ +-----+----+ +----+-----+ | 779 |Subscriber| |Subscriber| |Subscriber| / 780 | PC | | PC | | PC | / 781 +----------+ +----------+ +----------+ / 783 Figure 1: Prefix Delegation Newtork 785 In this example, the delegating router is configured with a set of 786 prefixes to be used for assignment to customers at the time of each 787 customer's first connection to the ISP service. The prefix 788 delegation process begins when the requesting router requests 789 configuration information through DHCP. The DHCP messages from the 790 requesting router are received by the delegating router in the 791 aggregation device. When the delegating router receives the request, 792 it selects an available prefix or prefixes for delegation to the 793 requesting router. The delegating router then returns the prefix or 794 prefixes to the requesting router. 796 The requesting router subnets the delegated prefix and assigns the 797 longer prefixes to links in the subscriber's network. In a typical 798 scenario based on the network shown in Figure 1, the requesting 799 router subnets a single delegated /48 prefix into /64 prefixes and 800 assigns one /64 prefix to each of the links in the subscriber 801 network. 803 The prefix delegation options can be used in conjunction with other 804 DHCP options carrying other configuration information to the 805 requesting router. The requesting router may, in turn, provide DHCP 806 service to hosts attached to the internal network. For example, the 807 requesting router may obtain the addresses of DNS and NTP servers 808 from the ISP delegating router, and then pass that configuration 809 information on to the subscriber hosts through a DHCP server in the 810 requesting router. 812 5.4. DHCPv6 for Customer Edge Routers 814 The DHCPv6 requirements and network architecture for Customer Edge 815 Routers are described in [RFC7084]. This model of operation combines 816 address assignment (see Section 5.2) and prefix delegation (see 817 Section 5.3). In general, this model assumes that a single set of 818 transactions between the client and server will assign or extend the 819 client's non-temporary addresses and delegated prefixes. 821 5.5. DHCPv6 for Temporary Addresses 823 Temporary addresses were originally introduced to avoid privacy 824 concerns with stateless address autoconfiguration, which based 825 64-bits of the address on the EUI-64 (see [RFC3041] and [RFC4941]). 826 They were added to DHCPv6 to provide complementary support when 827 stateful address assignment is used. 829 Temporary address assignment works mostly like non-temporary address 830 assignment (see Section 5.2), however these addresses are generally 831 intended to be used for a short period of time and not to have their 832 lifetimes extended, though they can be if required. 834 Whether temporary addresses are useful when DHCPv6 is used for non- 835 temporary address assignment is open to debate as the privacy 836 concerns expressed in [RFC3041] and [RFC4941] are not applicable. 838 6. DHCP Constants 840 This section describes various program and networking constants used 841 by DHCP. 843 6.1. Multicast Addresses 845 DHCP makes use of the following multicast addresses: 847 All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped 848 multicast address used by a client to communicate 849 with neighboring (i.e., on-link) relay agents and 850 servers. All servers and relay agents are members of 851 this multicast group. 853 All_DHCP_Servers (FF05::1:3) A site-scoped multicast address used by 854 a relay agent to communicate with servers, either 855 because the relay agent wants to send messages to all 856 servers or because it does not know the unicast 857 addresses of the servers. Note that in order for a 858 relay agent to use this address, it must have an 859 address of sufficient scope to be reachable by the 860 servers. All servers within the site are members of 861 this multicast group. 863 6.2. UDP Ports 865 Clients listen for DHCP messages on UDP port 546. Servers and relay 866 agents listen for DHCP messages on UDP port 547. 868 6.3. DHCP Message Types 870 DHCP defines the following message types. More detail on these 871 message types can be found in Section 7 and Section 8. Message types 872 not listed here are reserved for future use. The numeric encoding 873 for each message type is shown in parentheses. 875 SOLICIT (1) A client sends a Solicit message to locate servers. 877 ADVERTISE (2) A server sends an Advertise message to indicate that 878 it is available for DHCP service, in response to a 879 Solicit message received from a client. 881 REQUEST (3) A client sends a Request message to request 882 configuration parameters, including IP addresses, 883 from a specific server. 885 CONFIRM (4) A client sends a Confirm message to any available 886 server to determine whether the addresses it was 887 assigned are still appropriate to the link to which 888 the client is connected. 890 RENEW (5) A client sends a Renew message to the server that 891 originally provided the client's addresses and 892 configuration parameters to extend the lifetimes on 893 the addresses assigned to the client and to update 894 other configuration parameters. 896 REBIND (6) A client sends a Rebind message to any available 897 server to extend the lifetimes on the addresses 898 assigned to the client and to update other 899 configuration parameters; this message is sent after 900 a client receives no response to a Renew message. 902 REPLY (7) A server sends a Reply message containing assigned 903 addresses and configuration parameters in response to 904 a Solicit, Request, Renew, Rebind message received 905 from a client. A server sends a Reply message 906 containing configuration parameters in response to an 907 Information-request message. A server sends a Reply 908 message in response to a Confirm message confirming 909 or denying that the addresses assigned to the client 910 are appropriate to the link to which the client is 911 connected. A server sends a Reply message to 912 acknowledge receipt of a Release or Decline message. 914 RELEASE (8) A client sends a Release message to the server that 915 assigned addresses to the client to indicate that the 916 client will no longer use one or more of the assigned 917 addresses. 919 DECLINE (9) A client sends a Decline message to a server to 920 indicate that the client has determined that one or 921 more addresses assigned by the server are already in 922 use on the link to which the client is connected. 924 RECONFIGURE (10) A server sends a Reconfigure message to a client to 925 inform the client that the server has new or updated 926 configuration parameters, and that the client is to 927 initiate a Renew/Reply or Information-request/Reply 928 transaction with the server in order to receive the 929 updated information. 931 INFORMATION-REQUEST (11) A client sends an Information-request 932 message to a server to request configuration 933 parameters without the assignment of any IP addresses 934 to the client. 936 RELAY-FORW (12) A relay agent sends a Relay-forward message to relay 937 messages to servers, either directly or through 938 another relay agent. The received message, either a 939 client message or a Relay-forward message from 940 another relay agent, is encapsulated in an option in 941 the Relay-forward message. 943 RELAY-REPL (13) A server sends a Relay-reply message to a relay agent 944 containing a message that the relay agent delivers to 945 a client. The Relay-reply message may be relayed by 946 other relay agents for delivery to the destination 947 relay agent. 949 The server encapsulates the client message as an 950 option in the Relay-reply message, which the relay 951 agent extracts and relays to the client. 953 6.4. Status Codes 955 DHCPv6 uses status codes to communicate the success or failure of 956 operations requested in messages from clients and servers, and to 957 provide additional information about the specific cause of the 958 failure of a message. The specific status codes are defined in 959 Section 25.4. 961 If the Status Code option does not appear in a message in which the 962 option could appear, the status of the message is assumed to be 963 Success. 965 6.5. Transmission and Retransmission Parameters 967 This section presents a table of values used to describe the message 968 transmission behavior of clients and servers. 970 +-----------------+-----------+-------------------------------------+ 971 | Parameter | Default | Description | 972 +-----------------+-----------+-------------------------------------+ 973 | SOL_MAX_DELAY | 1 sec | Max delay of first Solicit | 974 | SOL_TIMEOUT | 1 sec | Initial Solicit timeout | 975 | SOL_MAX_RT | 3600 secs | Max Solicit timeout value | 976 | REQ_TIMEOUT | 1 sec | Initial Request timeout | 977 | REQ_MAX_RT | 30 secs | Max Request timeout value | 978 | REQ_MAX_RC | 10 | Max Request retry attempts | 979 | CNF_MAX_DELAY | 1 sec | Max delay of first Confirm | 980 | CNF_TIMEOUT | 1 sec | Initial Confirm timeout | 981 | CNF_MAX_RT | 4 secs | Max Confirm timeout | 982 | CNF_MAX_RD | 10 secs | Max Confirm duration | 983 | REN_TIMEOUT | 10 secs | Initial Renew timeout | 984 | REN_MAX_RT | 600 secs | Max Renew timeout value | 985 | REB_TIMEOUT | 10 secs | Initial Rebind timeout | 986 | REB_MAX_RT | 600 secs | Max Rebind timeout value | 987 | INF_MAX_DELAY | 1 sec | Max delay of first Information- | 988 | | | request | 989 | INF_TIMEOUT | 1 sec | Initial Information-request timeout | 990 | INF_MAX_RT | 3600 secs | Max Information-request timeout | 991 | | | value | 992 | REL_TIMEOUT | 1 sec | Initial Release timeout | 993 | REL_MAX_RC | 4 | MAX Release retry attempts | 994 | DEC_TIMEOUT | 1 sec | Initial Decline timeout | 995 | DEC_MAX_RC | 4 | Max Decline retry attempts | 996 | REC_TIMEOUT | 2 secs | Initial Reconfigure timeout | 997 | REC_MAX_RC | 8 | Max Reconfigure attempts | 998 | HOP_COUNT_LIMIT | 32 | Max hop count in a Relay-forward | 999 | | | message | 1000 +-----------------+-----------+-------------------------------------+ 1002 6.6. Representation of time values and "Infinity" as a time value 1004 All time values for lifetimes, T1 and T2 are unsigned integers. The 1005 value 0xffffffff is taken to mean "infinity" when used as a lifetime 1006 (as in [RFC4861]) or a value for T1 or T2. 1008 7. Client/Server Message Formats 1010 All DHCP messages sent between clients and servers share an identical 1011 fixed format header and a variable format area for options. 1013 All values in the message header and in options are in network byte 1014 order. 1016 Options are stored serially in the options field, with no padding 1017 between the options. Options are byte-aligned but are not aligned in 1018 any other way such as on 2 or 4 byte boundaries. 1020 The following diagram illustrates the format of DHCP messages sent 1021 between clients and servers: 1023 0 1 2 3 1024 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 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | msg-type | transaction-id | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | | 1029 . options . 1030 . (variable) . 1031 | | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 Figure 2: Client/Server message format 1036 msg-type Identifies the DHCP message type; the 1037 available message types are listed in 1038 Section 6.3. 1040 transaction-id The transaction ID for this message exchange. 1042 options Options carried in this message; options are 1043 described in Section 23. 1045 8. Relay Agent/Server Message Formats 1047 Relay agents exchange messages with servers to relay messages between 1048 clients and servers that are not connected to the same link. 1050 All values in the message header and in options are in network byte 1051 order. 1053 Options are stored serially in the options field, with no padding 1054 between the options. Options are byte-aligned but are not aligned in 1055 any other way such as on 2 or 4 byte boundaries. 1057 There are two relay agent messages, which share the following format: 1059 0 1 2 3 1060 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 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | msg-type | hop-count | | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1064 | | 1065 | link-address | 1066 | | 1067 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1068 | | | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1070 | | 1071 | peer-address | 1072 | | 1073 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1074 | | | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1076 . . 1077 . options (variable number and length) .... . 1078 | | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 Figure 3: Relay Agent/Server message format 1083 The following sections describe the use of the Relay Agent message 1084 header. 1086 8.1. Relay-forward Message 1088 The following table defines the use of message fields in a Relay- 1089 forward message. 1091 msg-type RELAY-FORW 1093 hop-count Number of relay agents that have relayed this 1094 message. 1096 link-address A global or site-scoped address that will be 1097 used by the server to identify the link on 1098 which the client is located. 1100 peer-address The address of the client or relay agent from 1101 which the message to be relayed was received. 1103 options MUST include a "Relay Message option" (see 1104 Section 23.10); MAY include other options 1105 added by the relay agent. 1107 8.2. Relay-reply Message 1109 The following table defines the use of message fields in a Relay- 1110 reply message. 1112 msg-type RELAY-REPL 1114 hop-count Copied from the Relay-forward message 1116 link-address Copied from the Relay-forward message 1118 peer-address Copied from the Relay-forward message 1120 options MUST include a "Relay Message option"; see 1121 Section 23.10; MAY include other options 1123 9. Representation and Use of Domain Names 1125 So that domain names may be encoded uniformly, a domain name or a 1126 list of domain names is encoded using the technique described in 1127 section 3.1 of [RFC1035]. A domain name, or list of domain names, in 1128 DHCP MUST NOT be stored in compressed form, as described in section 1129 4.1.4 of [RFC1035]. 1131 10. DHCP Unique Identifier (DUID) 1133 Each DHCP client and server has a DUID. DHCP servers use DUIDs to 1134 identify clients for the selection of configuration parameters and in 1135 the association of IAs with clients. DHCP clients use DUIDs to 1136 identify a server in messages where a server needs to be identified. 1137 See Section 23.2 and Section 23.3 for the representation of a DUID in 1138 a DHCP message. 1140 Clients and servers MUST treat DUIDs as opaque values and MUST only 1141 compare DUIDs for equality. Clients and servers MUST NOT in any 1142 other way interpret DUIDs. Clients and servers MUST NOT restrict 1143 DUIDs to the types defined in this document, as additional DUID types 1144 may be defined in the future. 1146 The DUID is carried in an option because it may be variable length 1147 and because it is not required in all DHCP messages. The DUID is 1148 designed to be unique across all DHCP clients and servers, and stable 1149 for any specific client or server - that is, the DUID used by a 1150 client or server SHOULD NOT change over time if at all possible; for 1151 example, a device's DUID should not change as a result of a change in 1152 the device's network hardware. 1154 The motivation for having more than one type of DUID is that the DUID 1155 must be globally unique, and must also be easy to generate. The sort 1156 of globally-unique identifier that is easy to generate for any given 1157 device can differ quite widely. Also, some devices may not contain 1158 any persistent storage. Retaining a generated DUID in such a device 1159 is not possible, so the DUID scheme must accommodate such devices. 1161 10.1. DUID Contents 1163 A DUID consists of a two-octet type code represented in network byte 1164 order, followed by a variable number of octets that make up the 1165 actual identifier. The length of the DUID (not including the type 1166 code) is at least 1 octet and at most 128 octets. The following 1167 types are currently defined: 1169 +------+------------------------------------------------------+ 1170 | Type | Description | 1171 +------+------------------------------------------------------+ 1172 | 1 | Link-layer address plus time | 1173 | 2 | Vendor-assigned unique ID based on Enterprise Number | 1174 | 3 | Link-layer address | 1175 | 4 | Universally Unique IDentifier (UUID) - see [RFC6355] | 1176 +------+------------------------------------------------------+ 1178 Formats for the variable field of the DUID for the first 3 of the 1179 above types are shown below. For the fourth type, refer to 1180 [RFC6355]. 1182 10.2. DUID Based on Link-layer Address Plus Time, DUID-LLT 1184 This type of DUID consists of a two octet type field containing the 1185 value 1, a two octet hardware type code, four octets containing a 1186 time value, followed by link-layer address of any one network 1187 interface that is connected to the DHCP device at the time that the 1188 DUID is generated. The time value is the time that the DUID is 1189 generated represented in seconds since midnight (UTC), January 1, 1190 2000, modulo 2^32. The hardware type MUST be a valid hardware type 1191 assigned by the IANA as described in [RFC0826]. Both the time and 1192 the hardware type are stored in network byte order. The link-layer 1193 address is stored in canonical form, as described in [RFC2464]. 1195 The following diagram illustrates the format of a DUID-LLT: 1197 0 1 2 3 1198 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 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | 1 | hardware type (16 bits) | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | time (32 bits) | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 . . 1205 . link-layer address (variable length) . 1206 . . 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 Figure 4: DUID-LLT format 1211 The choice of network interface can be completely arbitrary, as long 1212 as that interface provides a globally unique link-layer address for 1213 the link type, and the same DUID-LLT SHOULD be used in configuring 1214 all network interfaces connected to the device, regardless of which 1215 interface's link-layer address was used to generate the DUID-LLT. 1217 Clients and servers using this type of DUID MUST store the DUID-LLT 1218 in stable storage, and MUST continue to use this DUID-LLT even if the 1219 network interface used to generate the DUID-LLT is removed. Clients 1220 and servers that do not have any stable storage MUST NOT use this 1221 type of DUID. 1223 Clients and servers that use this DUID SHOULD attempt to configure 1224 the time prior to generating the DUID, if that is possible, and MUST 1225 use some sort of time source (for example, a real-time clock) in 1226 generating the DUID, even if that time source could not be configured 1227 prior to generating the DUID. The use of a time source makes it 1228 unlikely that two identical DUID-LLTs will be generated if the 1229 network interface is removed from the client and another client then 1230 uses the same network interface to generate a DUID-LLT. A collision 1231 between two DUID-LLTs is very unlikely even if the clocks have not 1232 been configured prior to generating the DUID. 1234 This method of DUID generation is recommended for all general purpose 1235 computing devices such as desktop computers and laptop computers, and 1236 also for devices such as printers, routers, and so on, that contain 1237 some form of writable non-volatile storage. 1239 Despite our best efforts, it is possible that this algorithm for 1240 generating a DUID could result in a client identifier collision. A 1241 DHCP client that generates a DUID-LLT using this mechanism MUST 1242 provide an administrative interface that replaces the existing DUID 1243 with a newly-generated DUID-LLT. 1245 10.3. DUID Assigned by Vendor Based on Enterprise Number, DUID-EN 1247 This form of DUID is assigned by the vendor to the device. It 1248 consists of the vendor's registered Private Enterprise Number as 1249 maintained by IANA [IANA-PEN] followed by a unique identifier 1250 assigned by the vendor. The following diagram summarizes the 1251 structure of a DUID-EN: 1253 0 1 2 3 1254 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 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | 2 | enterprise-number | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | enterprise-number (contd) | | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1260 . identifier . 1261 . (variable length) . 1262 . . 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 Figure 5: DUID-EN format 1267 The source of the identifier is left up to the vendor defining it, 1268 but each identifier part of each DUID-EN MUST be unique to the device 1269 that is using it, and MUST be assigned to the device no later than at 1270 the first usage and stored in some form of non-volatile storage. 1271 This typically means being assigned during manufacture process in 1272 case of physical devices or when the image is created or booted for 1273 the first time in case of virtual machines. The generated DUID 1274 SHOULD be recorded in non-erasable storage. The enterprise-number is 1275 the vendor's registered Private Enterprise Number as maintained by 1276 IANA [IANA-PEN]. The enterprise-number is stored as an unsigned 32 1277 bit number. 1279 An example DUID of this type might look like this: 1281 +---+---+---+---+---+---+---+---+ 1282 | 0 | 2 | 0 | 0 | 0 | 9| 12|192| 1283 +---+---+---+---+---+---+---+---+ 1284 |132|211| 3 | 0 | 9 | 18| 1285 +---+---+---+---+---+---+ 1287 Figure 6: DUID-EN example 1289 This example includes the two-octet type of 2, the Enterprise Number 1290 (9), followed by eight octets of identifier data 1291 (0x0CC084D303000912). 1293 10.4. DUID Based on Link-layer Address, DUID-LL 1295 This type of DUID consists of two octets containing the DUID type 3, 1296 a two octet network hardware type code, followed by the link-layer 1297 address of any one network interface that is permanently connected to 1298 the client or server device. For example, a host that has a network 1299 interface implemented in a chip that is unlikely to be removed and 1300 used elsewhere could use a DUID-LL. The hardware type MUST be a 1301 valid hardware type assigned by the IANA, as described in [RFC0826]. 1302 The hardware type is stored in network byte order. The link-layer 1303 address is stored in canonical form, as described in [RFC2464]. The 1304 following diagram illustrates the format of a DUID-LL: 1306 0 1 2 3 1307 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 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | 3 | hardware type (16 bits) | 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 . . 1312 . link-layer address (variable length) . 1313 . . 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 Figure 7: DUID-LL format 1318 The choice of network interface can be completely arbitrary, as long 1319 as that interface provides a unique link-layer address and is 1320 permanently attached to the device on which the DUID-LL is being 1321 generated. The same DUID-LL SHOULD be used in configuring all 1322 network interfaces connected to the device, regardless of which 1323 interface's link-layer address was used to generate the DUID. 1325 DUID-LL is recommended for devices that have a permanently-connected 1326 network interface with a link-layer address, and do not have 1327 nonvolatile, writable stable storage. DUID-LL MUST NOT be used by 1328 DHCP clients or servers that cannot tell whether or not a network 1329 interface is permanently attached to the device on which the DHCP 1330 client is running. 1332 11. Identity Association 1334 An "identity-association" (IA) is a construct through which a server 1335 and a client can identify, group, and manage a set of related IPv6 1336 addresses or delegated prefixes. Each IA consists of an IAID and 1337 associated configuration information. 1339 The IAID uniquely identifies the IA and must be chosen to be unique 1340 among the IAIDs for that IA type on the client. The IAID is chosen 1341 by the client. For any given use of an IA by the client, the IAID 1342 for that IA MUST be consistent across restarts of the DHCP client. 1343 The client may maintain consistency either by storing the IAID in 1344 non-volatile storage or by using an algorithm that will consistently 1345 produce the same IAID as long as the configuration of the client has 1346 not changed. There may be no way for a client to maintain 1347 consistency of the IAIDs if it does not have non-volatile storage and 1348 the client's hardware configuration changes. If the client uses only 1349 one IAID, it can use a well-known value, e.g., zero. 1351 11.1. Identity Associations for Address Assignment 1353 A client must associate at least one distinct IA with each of its 1354 network interfaces for which it is to request the assignment of IPv6 1355 addresses from a DHCP server. The client uses the IAs assigned to an 1356 interface to obtain configuration information from a server for that 1357 interface. Each IA must be associated with exactly one interface. 1359 The configuration information in an IA consists of one or more IPv6 1360 addresses along with the times T1 and T2 for the IA. See 1361 Section 22.4 for the representation of an IA in a DHCP message. 1363 Each address in an IA has a preferred lifetime and a valid lifetime, 1364 as defined in [RFC4862]. The lifetimes are transmitted from the DHCP 1365 server to the client in the IA option. The lifetimes apply to the 1366 use of IPv6 addresses, as described in section 5.5.4 of [RFC4862]. 1368 11.2. Identity Associations for Prefix Delegation 1370 An IA_PD is different from an IA for address assignment, in that it 1371 does not need to be associated with exactly one interface. One IA_PD 1372 can be associated with the requesting router, with a set of 1373 interfaces or with exactly one interface. A requesting router must 1374 create at least one distinct IA_PD. It may associate a distinct 1375 IA_PD with each of its downstream network interfaces and use that 1376 IA_PD to obtain a prefix for that interface from the delegating 1377 router. 1379 The configuration information in an IA_PD consists of one or more 1380 IPv6 prefixes along with the times T1 and T2 for the IA_PD. See 1381 Section 23.21 for the representation of an IA_PD in a DHCP message. 1383 12. Selecting Addresses for Assignment to an IA 1385 A server selects addresses to be assigned to an IA according to the 1386 address assignment policies determined by the server administrator 1387 and the specific information the server determines about the client 1388 from some combination of the following sources: 1390 - The link to which the client is attached. The server determines 1391 the link as follows: 1393 * If the server receives the message directly from the client and 1394 the source address in the IP datagram in which the message was 1395 received is a link-local address, then the client is on the 1396 same link to which the interface over which the message was 1397 received is attached. 1399 * If the server receives the message from a forwarding relay 1400 agent, then the client is on the same link as the one to which 1401 the interface, identified by the link-address field in the 1402 message from the relay agent, is attached. According to 1403 [RFC6221], the server MUST ignore any link-address field whose 1404 value is zero. The link address field referes to the link- 1405 address field of the Relay-Forward message, and the link- 1406 address fields in any Relay-Forward messages that may be nested 1407 within the Relay-Forward message. 1409 * If the server receives the message directly from the client and 1410 the source address in the IP datagram in which the message was 1411 received is not a link-local address, then the client is on the 1412 link identified by the source address in the IP datagram (note 1413 that this situation can occur only if the server has enabled 1414 the use of unicast message delivery by the client and the 1415 client has sent a message for which unicast delivery is 1416 allowed). 1418 - The DUID supplied by the client. 1420 - Other information in options supplied by the client, e.g. IA 1421 Address options that include the client's requests for specific 1422 addresses. 1424 - Other information in options supplied by the relay agent. 1426 Any address assigned by a server that is based on an EUI-64 1427 identifier MUST include an interface identifier with the "u" 1428 (universal/local) and "g" (individual/group) bits of the interface 1429 identifier set appropriately, as indicated in section 2.5.1 of 1430 [RFC4291]. 1432 A server MUST NOT assign an address that is otherwise reserved for 1433 some other purpose. For example, a server MUST NOT assign reserved 1434 anycast addresses, as defined in [RFC2526], from any subnet. 1436 13. Management of Temporary Addresses 1438 A client may request the assignment of temporary addresses (see 1439 [RFC4941] for the definition of temporary addresses). DHCPv6 1440 handling of address assignment is no different for temporary 1441 addresses. 1443 Clients ask for temporary addresses and servers assign them. 1444 Temporary addresses are carried in the Identity Association for 1445 Temporary Addresses (IA_TA) option (see Section 23.5). Each IA_TA 1446 option contains at most one temporary address for each of the 1447 prefixes on the link to which the client is attached. 1449 The lifetime of the assigned temporary address is set in the IA 1450 Address Option (see Section 23.6) with in the IA_TA option. It is 1451 RECOMMENDED to set short lifetimes, typically shorter than 1452 TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME (see Section 5, 1453 [RFC4941]. 1455 The IAID number space for the IA_TA option IAID number space is 1456 separate from the IA_NA option IAID number space. 1458 A DHCPv6 server implementation MAY generate temporary addresses 1459 referring to the algorithm defined in Section 3.2.1, [RFC4941], with 1460 additional condition that the new address is not duplicated with any 1461 assigned addresses. 1463 The server MAY update the DNS for a temporary address, as described 1464 in section 4 of [RFC4941]. 1466 On the clients, by default, temporary addresses are preferred in 1467 source address selection, according to Rule 7, [RFC6724]. However, 1468 this policy is overridable. 1470 One of the most important properties of temporary address is 1471 unlinkability of different actions over time. So, it is NOT 1472 RECOMMENDED for a client to renew expired temporary addresses, though 1473 DHCPv6 provides such possibility (see Section 23.5). 1475 14. Transmission of Messages by a Client 1477 Unless otherwise specified in this document, or in a document that 1478 describes how IPv6 is carried over a specific type of link (for link 1479 types that do not support multicast), a client sends DHCP messages to 1480 the All_DHCP_Relay_Agents_and_Servers. 1482 A client uses multicast to reach all servers or an individual server. 1483 An individual server is indicated by specifying that server's DUID in 1484 a Server Identifier option (see Section 23.3) in the client's message 1485 (all servers will receive this message but only the indicated server 1486 will respond). All servers are indicated by not supplying this 1487 option. 1489 A client may send some messages directly to a server using unicast, 1490 as described in Section 23.12. 1492 15. Reliability of Client Initiated Message Exchanges 1494 DHCP clients are responsible for reliable delivery of messages in the 1495 client-initiated message exchanges described in Section 18 and 1496 Section 19. If a DHCP client fails to receive an expected response 1497 from a server, the client must retransmit its message. This section 1498 describes the retransmission strategy to be used by clients in 1499 client-initiated message exchanges. 1501 Note that the procedure described in this section is slightly 1502 modified when used with the Solicit message. The modified procedure 1503 is described in Section 18.1.2. 1505 The client begins the message exchange by transmitting a message to 1506 the server. The message exchange terminates when either the client 1507 successfully receives the appropriate response or responses from a 1508 server or servers, or when the message exchange is considered to have 1509 failed according to the retransmission mechanism described below. 1511 The client retransmission behavior is controlled and described by the 1512 following variables: 1514 RT Retransmission timeout 1516 IRT Initial retransmission time 1518 MRC Maximum retransmission count 1520 MRT Maximum retransmission time 1522 MRD Maximum retransmission duration 1523 RAND Randomization factor 1525 With each message transmission or retransmission, the client sets RT 1526 according to the rules given below. If RT expires before the message 1527 exchange terminates, the client recomputes RT and retransmits the 1528 message. 1530 Each of the computations of a new RT include a randomization factor 1531 (RAND), which is a random number chosen with a uniform distribution 1532 between -0.1 and +0.1. The randomization factor is included to 1533 minimize synchronization of messages transmitted by DHCP clients. 1535 The algorithm for choosing a random number does not need to be 1536 cryptographically sound. The algorithm SHOULD produce a different 1537 sequence of random numbers from each invocation of the DHCP client. 1539 RT for the first message transmission is based on IRT: 1541 RT = IRT + RAND*IRT 1543 RT for each subsequent message transmission is based on the previous 1544 value of RT: 1546 RT = 2*RTprev + RAND*RTprev 1548 MRT specifies an upper bound on the value of RT (disregarding the 1549 randomization added by the use of RAND). If MRT has a value of 0, 1550 there is no upper limit on the value of RT. Otherwise: 1552 if (RT > MRT) 1553 RT = MRT + RAND*MRT 1555 MRC specifies an upper bound on the number of times a client may 1556 retransmit a message. Unless MRC is zero, the message exchange fails 1557 once the client has transmitted the message MRC times. 1559 MRD specifies an upper bound on the length of time a client may 1560 retransmit a message. Unless MRD is zero, the message exchange fails 1561 once MRD seconds have elapsed since the client first transmitted the 1562 message. 1564 If both MRC and MRD are non-zero, the message exchange fails whenever 1565 either of the conditions specified in the previous two paragraphs are 1566 met. 1568 If both MRC and MRD are zero, the client continues to transmit the 1569 message until it receives a response. 1571 A client is not expected to listen for a response during the entire 1572 period between transmission of Solicit or Information-request 1573 messages. 1575 16. Message Validation 1577 Clients and servers might get messages that contain options not 1578 allowed to appear in the received message. For example, an IA option 1579 is not allowed to appear in an Information-request message. Clients 1580 and servers MAY choose either to extract information from such a 1581 message if the information is of use to the recipient, or to ignore 1582 such message completely and just drop it. 1584 A server MUST discard any Solicit, Confirm, Rebind or Information- 1585 request messages it receives with a unicast destination address. 1587 Message validation based on DHCP authentication is discussed in 1588 Section 22.4.2. 1590 If a server receives a message that contains options it should not 1591 contain (such as an Information-request message with an IA option), 1592 is missing options that it should contain, or is otherwise not valid, 1593 it MAY send a Reply (or Advertise as appropriate) with a Server 1594 Identifier option, a Client Identifier option if one was included in 1595 the message and a Status Code option with status UnSpecFail. 1597 16.1. Use of Transaction IDs 1599 The "transaction-id" field holds a value used by clients and servers 1600 to synchronize server responses to client messages. A client SHOULD 1601 generate a random number that cannot easily be guessed or predicted 1602 to use as the transaction ID for each new message it sends. Note 1603 that if a client generates easily predictable transaction 1604 identifiers, it may become more vulnerable to certain kinds of 1605 attacks from off-path intruders. A client MUST leave the transaction 1606 ID unchanged in retransmissions of a message. 1608 16.2. Solicit Message 1610 Clients MUST discard any received Solicit messages. 1612 Servers MUST discard any Solicit messages that do not include a 1613 Client Identifier option or that do include a Server Identifier 1614 option. 1616 16.3. Advertise Message 1618 Clients MUST discard any received Advertise message that meets any of 1619 the following conditions: 1621 - the message does not include a Server Identifier option. 1623 - the message does not include a Client Identifier option. 1625 - the contents of the Client Identifier option does not match the 1626 client's DUID. 1628 - the "transaction-id" field value does not match the value the 1629 client used in its Solicit message. 1631 Servers and relay agents MUST discard any received Advertise 1632 messages. 1634 16.4. Request Message 1636 Clients MUST discard any received Request messages. 1638 Servers MUST discard any received Request message that meets any of 1639 the following conditions: 1641 - the message does not include a Server Identifier option. 1643 - the contents of the Server Identifier option do not match the 1644 server's DUID. 1646 - the message does not include a Client Identifier option. 1648 16.5. Confirm Message 1650 Clients MUST discard any received Confirm messages. 1652 Servers MUST discard any received Confirm messages that do not 1653 include a Client Identifier option or that do include a Server 1654 Identifier option. 1656 16.6. Renew Message 1658 Clients MUST discard any received Renew messages. 1660 Servers MUST discard any received Renew message that meets any of the 1661 following conditions: 1663 - the message does not include a Server Identifier option. 1665 - the contents of the Server Identifier option does not match the 1666 server's identifier. 1668 - the message does not include a Client Identifier option. 1670 16.7. Rebind Message 1672 Clients MUST discard any received Rebind messages. 1674 Servers MUST discard any received Rebind messages that do not include 1675 a Client Identifier option or that do include a Server Identifier 1676 option. 1678 16.8. Decline Messages 1680 Clients MUST discard any received Decline messages. 1682 Servers MUST discard any received Decline message that meets any of 1683 the following conditions: 1685 - the message does not include a Server Identifier option. 1687 - the contents of the Server Identifier option does not match the 1688 server's identifier. 1690 - the message does not include a Client Identifier option. 1692 16.9. Release Message 1694 Clients MUST discard any received Release messages. 1696 Servers MUST discard any received Release message that meets any of 1697 the following conditions: 1699 - the message does not include a Server Identifier option. 1701 - the contents of the Server Identifier option does not match the 1702 server's identifier. 1704 - the message does not include a Client Identifier option. 1706 16.10. Reply Message 1708 Clients MUST discard any received Reply message that meets any of the 1709 following conditions: 1711 - the message does not include a Server Identifier option. 1713 - the "transaction-id" field in the message does not match the value 1714 used in the original message. 1716 If the client included a Client Identifier option in the original 1717 message, the Reply message MUST include a Client Identifier option 1718 and the contents of the Client Identifier option MUST match the DUID 1719 of the client; OR, if the client did not include a Client Identifier 1720 option in the original message, the Reply message MUST NOT include a 1721 Client Identifier option. 1723 Servers and relay agents MUST discard any received Reply messages. 1725 16.11. Reconfigure Message 1727 Servers and relay agents MUST discard any received Reconfigure 1728 messages. 1730 Clients MUST discard any Reconfigure message that meets any of the 1731 following conditions: 1733 - the message was not unicast to the client. 1735 - the message does not include a Server Identifier option. 1737 - the message does not include a Client Identifier option that 1738 contains the client's DUID. 1740 - the message does not contain a Reconfigure Message option. 1742 - the Reconfigure Message option msg-type is not a valid value. 1744 - the message includes any IA options and the msg-type in the 1745 Reconfigure Message option is INFORMATION-REQUEST. 1747 - the message does not include DHCP authentication: 1749 * the message does not contain an authentication option. 1751 * the message does not pass the authentication validation 1752 performed by the client. 1754 16.12. Information-request Message 1756 Clients MUST discard any received Information-request messages. 1758 Servers MUST discard any received Information-request message that 1759 meets any of the following conditions: 1761 - The message includes a Server Identifier option and the DUID in 1762 the option does not match the server's DUID. 1764 - The message includes an IA option. 1766 16.13. Relay-forward Message 1768 Clients MUST discard any received Relay-forward messages. 1770 16.14. Relay-reply Message 1772 Clients and servers MUST discard any received Relay-reply messages. 1774 17. Client Source Address and Interface Selection 1776 Client's behavior is different depending on the purpose of the 1777 configuration. 1779 17.1. Address Assignment 1781 When a client sends a DHCP message to the 1782 All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message 1783 through the interface for which configuration information is being 1784 requested. However, the client MAY send the message through another 1785 interface if the interface is a logical interface without direct link 1786 attachement or the client is certain that two interfaces are attached 1787 to the same link. 1789 When a client sends a DHCP message directly to a server using unicast 1790 (after receiving the Server Unicast option from that server), the 1791 source address in the header of the IPv6 datagram MUST be an address 1792 assigned to the interface for which the client is interested in 1793 obtaining configuration and which is suitable for use by the server 1794 in responding to the client. 1796 17.2. Prefix Delegation 1798 Delegated prefixes are not associated with a particular interface in 1799 the same way as addresses are for address assignment, and mentioned 1800 above. 1802 When a client (acting as requesting router) sends a DHCP message for 1803 the purpose of prefix delegation, it SHOULD be sent on the interface 1804 associated with the upstream router (ISP network). The upstream 1805 interface is typically determined by configuration. This rule 1806 applies even in the case where a separate IA_PD is used for each 1807 downstream interface. 1809 When a requesting router sends a DHCP message directly to a 1810 delegating router using unicast (after receiving the Server Unicast 1811 option from that delegating router), the source address SHOULD be an 1812 address from the upstream interface and which is suitable for use by 1813 the delegating router in responding to the requesting router. 1815 18. DHCP Server Solicitation 1817 This section describes how a client locates servers that will assign 1818 addresses to IAs belonging to the client. 1820 The client is responsible for creating IAs and requesting that a 1821 server assign IPv6 addresses to the IA. The client first creates an 1822 IA and assigns it an IAID. The client then transmits a Solicit 1823 message containing an IA option describing the IA. Servers that can 1824 assign addresses to the IA respond to the client with an Advertise 1825 message. The client then initiates a configuration exchange as 1826 described in Section 19. 1828 If the client will accept a Reply message with committed address 1829 assignments and other resources in response to the Solicit message, 1830 the client includes a Rapid Commit option (see Section 23.14) in the 1831 Solicit message. 1833 18.1. Client Behavior 1835 A client uses the Solicit message to discover DHCP servers configured 1836 to assign addresses or return other configuration parameters on the 1837 link to which the client is attached. 1839 18.1.1. Creation of Solicit Messages 1841 The client sets the "msg-type" field to SOLICIT. The client 1842 generates a transaction ID and inserts this value in the 1843 "transaction-id" field. 1845 The client MUST include a Client Identifier option to identify itself 1846 to the server. The client includes IA options for any IAs to which 1847 it wants the server to assign addresses. The client MAY include 1848 addresses in the IAs as a hint to the server about addresses for 1849 which the client has a preference. The client MUST NOT include any 1850 other options in the Solicit message, except as specifically allowed 1851 in the definition of individual options. 1853 The client uses IA_NA options to request the assignment of non- 1854 temporary addresses and uses IA_TA options to request the assignment 1855 of temporary addresses. Either IA_NA or IA_TA options, or a 1856 combination of both, can be included in DHCP messages. 1858 The client SHOULD include an Option Request option (see Section 23.7) 1859 to indicate the options the client is interested in receiving. The 1860 client MAY additionally include instances of those options that are 1861 identified in the Option Request option, with data values as hints to 1862 the server about parameter values the client would like to have 1863 returned. 1865 The client includes a Reconfigure Accept option (see Section 23.20) 1866 if the client is willing to accept Reconfigure messages from the 1867 server. 1869 18.1.2. Transmission of Solicit Messages 1871 The first Solicit message from the client on the interface MUST be 1872 delayed by a random amount of time between 0 and SOL_MAX_DELAY. In 1873 the case of a Solicit message transmitted when DHCP is initiated by 1874 IPv6 Neighbor Discovery, the delay gives the amount of time to wait 1875 after IPv6 Neighbor Discovery causes the client to invoke the 1876 stateful address autoconfiguration protocol (see section 5.5.3 of 1877 [RFC4862]). This random delay desynchronizes clients which start at 1878 the same time (for example, after a power outage). 1880 The client transmits the message according to Section 15, using the 1881 following parameters: 1883 IRT SOL_TIMEOUT 1885 MRT SOL_MAX_RT 1887 MRC 0 1889 MRD 0 1891 If the client has included a Rapid Commit option in its Solicit 1892 message, the client terminates the waiting process as soon as a Reply 1893 message with a Rapid Commit option is received. 1895 If the client is waiting for an Advertise message, the mechanism in 1896 Section 15 is modified as follows for use in the transmission of 1897 Solicit messages. The message exchange is not terminated by the 1898 receipt of an Advertise before the first RT has elapsed. Rather, the 1899 client collects Advertise messages until the first RT has elapsed. 1900 Also, the first RT MUST be selected to be strictly greater than IRT 1901 by choosing RAND to be strictly greater than 0. 1903 A client MUST collect Advertise messages for the first RT seconds, 1904 unless it receives an Advertise message with a preference value of 1905 255. The preference value is carried in the Preference option 1906 (Section 23.8). Any Advertise that does not include a Preference 1907 option is considered to have a preference value of 0. If the client 1908 receives an Advertise message that includes a Preference option with 1909 a preference value of 255, the client immediately begins a client- 1910 initiated message exchange (as described in Section 19) by sending a 1911 Request message to the server from which the Advertise message was 1912 received. If the client receives an Advertise message that does not 1913 include a Preference option with a preference value of 255, the 1914 client continues to wait until the first RT elapses. If the first RT 1915 elapses and the client has received an Advertise message, the client 1916 SHOULD continue with a client-initiated message exchange by sending a 1917 Request message. 1919 If the client does not receive any Advertise messages before the 1920 first RT has elapsed, it begins the retransmission mechanism 1921 described in Section 15. The client terminates the retransmission 1922 process as soon as it receives any Advertise message, and the client 1923 acts on the received Advertise message without waiting for any 1924 additional Advertise messages. 1926 A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client 1927 is configured with either MRC or MRD set to a value other than 0, it 1928 MUST stop trying to configure the interface if the message exchange 1929 fails. After the DHCP client stops trying to configure the 1930 interface, it SHOULD restart the reconfiguration process after some 1931 external event, such as user input, system restart, or when the 1932 client is attached to a new link. 1934 18.1.3. Receipt of Advertise Messages 1936 The client MUST process SOL_MAX_RT and INF_MAX_RT options in an 1937 Advertise message, even if the message contains a Status Code option 1938 indicating a failure, and the Advertise message will be discarded by 1939 the client. 1941 The client MUST ignore any IAs in an Advertise message that include a 1942 Status Code option containing the value NoAddrsAvail, with the 1943 exception that the client MAY display the associated status message 1944 to the user. 1946 Upon receipt of one or more valid Advertise messages, the client 1947 selects one or more Advertise messages based upon the following 1948 criteria. 1950 - Those Advertise messages with the highest server preference value 1951 are preferred over all other Advertise messages. 1953 - Within a group of Advertise messages with the same server 1954 preference value, a client MAY select those servers whose 1955 Advertise messages advertise information of interest to the 1956 client. 1958 - The client MAY choose a less-preferred server if that server has a 1959 better set of advertised parameters, such as the available 1960 addresses advertised in IAs. 1962 Once a client has selected Advertise message(s), the client will 1963 typically store information about each server, such as server 1964 preference value, addresses advertised, when the advertisement was 1965 received, and so on. 1967 In practice, this means that the client will maintain independent 1968 per-IA state machines per each selected server. 1970 If the client needs to select an alternate server in the case that a 1971 chosen server does not respond, the client chooses the next server 1972 according to the criteria given above. 1974 18.1.4. Receipt of Reply Message 1976 If the client includes a Rapid Commit option in the Solicit message, 1977 it will expect a Reply message that includes a Rapid Commit option in 1978 response. The client discards any Reply messages it receives that do 1979 not include a Rapid Commit option. If the client receives a valid 1980 Reply message that includes a Rapid Commit option, it processes the 1981 message as described in Section 19.1.8. If it does not receive such 1982 a Reply message and does receive a valid Advertise message, the 1983 client processes the Advertise message as described in 1984 Section 18.1.3. 1986 If the client subsequently receives a valid Reply message that 1987 includes a Rapid Commit option, it either: 1989 - processes the Reply message as described in Section 19.1.8, and 1990 discards any Reply messages received in response to the Request 1991 message, or 1993 - processes any Reply messages received in response to the Request 1994 message and discards the Reply message that includes the Rapid 1995 Commit option. 1997 18.2. Server Behavior 1999 A server sends an Advertise message in response to valid Solicit 2000 messages it receives to announce the availability of the server to 2001 the client. 2003 18.2.1. Receipt of Solicit Messages 2005 The server determines the information about the client and its 2006 location as described in Section 12 and checks its administrative 2007 policy about responding to the client. If the server is not 2008 permitted to respond to the client, the server discards the Solicit 2009 message. For example, if the administrative policy for the server is 2010 that it may only respond to a client that is willing to accept a 2011 Reconfigure message, if the client does not include a Reconfigure 2012 Accept option (see Section 23.20) in the Solicit message, the servers 2013 discard the Solicit message. 2015 If the client has included a Rapid Commit option in the Solicit 2016 message and the server has been configured to respond with committed 2017 address assignments and other resources, the server responds to the 2018 Solicit with a Reply message as described in Section 18.2.3. 2019 Otherwise, the server ignores the Rapid Commit option and processes 2020 the remainder of the message as if no Rapid Commit option were 2021 present. 2023 18.2.2. Creation and Transmission of Advertise Messages 2025 The server sets the "msg-type" field to ADVERTISE and copies the 2026 contents of the transaction-id field from the Solicit message 2027 received from the client to the Advertise message. The server 2028 includes its server identifier in a Server Identifier option and 2029 copies the Client Identifier from the Solicit message into the 2030 Advertise message. 2032 The server MAY add a Preference option to carry the preference value 2033 for the Advertise message. The server implementation SHOULD allow 2034 the setting of a server preference value by the administrator. The 2035 server preference value MUST default to zero unless otherwise 2036 configured by the server administrator. 2038 The server includes a Reconfigure Accept option if the server wants 2039 to require that the client accept Reconfigure messages. 2041 The server includes options the server will return to the client in a 2042 subsequent Reply message. The information in these options may be 2043 used by the client in the selection of a server if the client 2044 receives more than one Advertise message. If the client has included 2045 an Option Request option in the Solicit message, the server includes 2046 options in the Advertise message containing configuration parameters 2047 for all of the options identified in the Option Request option that 2048 the server has been configured to return to the client. The server 2049 MAY return additional options to the client if it has been configured 2050 to do so. The server must be aware of the recommendations on packet 2051 sizes and the use of fragmentation in section 5 of [RFC2460]. 2053 If the Solicit message from the client included one or more IA 2054 options, the server MUST include IA options in the Advertise message 2055 containing any addresses that would be assigned to IAs contained in 2056 the Solicit message from the client. If the client has included 2057 addresses in the IAs in the Solicit message, the server uses those 2058 addresses as hints about the addresses the client would like to 2059 receive. 2061 If the server will not assign any addresses to any IAs in a 2062 subsequent Request from the client, the server MUST send an Advertise 2063 message to the client that includes only a Status Code option with 2064 code NoAddrsAvail and a status message for the user, a Server 2065 Identifier option with the server's DUID, a Client Identifier option 2066 with the client's DUID, and (optionally) SOL_MAX_RT and/or INF_MAX_RT 2067 options. The server SHOULD include other stateful IA options (like 2068 IA_PD) and other configuration options in the Advertise message. 2070 If the Solicit message was received directly by the server, the 2071 server unicasts the Advertise message directly to the client using 2072 the address in the source address field from the IP datagram in which 2073 the Solicit message was received. The Advertise message MUST be 2074 unicast on the link from which the Solicit message was received. 2076 If the Solicit message was received in a Relay-forward message, the 2077 server constructs a Relay-reply message with the Advertise message in 2078 the payload of a "relay-message" option. If the Relay-forward 2079 messages included an Interface-id option, the server copies that 2080 option to the Relay-reply message. The server unicasts the Relay- 2081 reply message directly to the relay agent using the address in the 2082 source address field from the IP datagram in which the Relay-forward 2083 message was received. 2085 18.2.3. Creation and Transmission of Reply Messages 2087 The server MUST commit the assignment of any addresses or other 2088 configuration information message before sending a Reply message to a 2089 client in response to a Solicit message. 2091 DISCUSSION: 2093 When using the Solicit-Reply message exchange, the server commits 2094 the assignment of any addresses before sending the Reply message. 2095 The client can assume it has been assigned the addresses in the 2096 Reply message and does not need to send a Request message for 2097 those addresses. 2099 Typically, servers that are configured to use the Solicit-Reply 2100 message exchange will be deployed so that only one server will 2101 respond to a Solicit message. If more than one server responds, 2102 the client will only use the addresses from one of the servers, 2103 while the addresses from the other servers will be committed to 2104 the client but not used by the client. 2106 The server includes a Rapid Commit option in the Reply message to 2107 indicate that the Reply is in response to a Solicit message. 2109 The server includes a Reconfigure Accept option if the server wants 2110 to require that the client accept Reconfigure messages. 2112 The server produces the Reply message as though it had received a 2113 Request message, as described in Section 19.2.1. The server 2114 transmits the Reply message as described in Section 19.2.8. 2116 18.3. Client behavior for Prefix Delegation 2118 The requesting router creates and transmits a Solicit message as 2119 described in Section 18.1.1 and Section 18.1.2. The client creates 2120 an IA_PD and assigns it an IAID. The client MUST include the IA_PD 2121 option in the Solicit message. 2123 The client processes any received Advertise messages as described in 2124 Section 18.1.3. The client MAY choose to consider the presence of 2125 advertised prefixes in its decision about which delegating router to 2126 respond to. 2128 The client MUST ignore any IA_PDs in an Advertise message that 2129 include a Status Code option containing the value NoPrefixAvail, with 2130 the exception that the client MAY display the associated status 2131 message to the user and SHOULD process SOL_MAX_RT and INF_MAX_RT 2132 options. 2134 18.4. Server Behavior for Prefix Delegation 2136 The server sends an Advertise message to the requesting router in the 2137 same way as described in Section 18.2.2. If the message contains an 2138 IA_PD option and the delegating router is configured to delegate 2139 prefix(es) to the requesting router, the delegating router selects 2140 the prefix(es) to be delegated to the requesting router. The 2141 mechanism through which the delegating router selects prefix(es) for 2142 delegation is not specified in this document. Examples of ways in 2143 which the server might select prefix(es) for a client include: static 2144 assignment based on subscription to an ISP; dynamic assignment from a 2145 pool of available prefixes; selection based on an external authority 2146 such as a RADIUS server using the Framed-IPv6-Prefix option as 2147 described in [RFC3162]. 2149 If the client includes an IA_PD Prefix option in the IA_PD option in 2150 its Solicit message, the server MAY choose to use the information in 2151 that option to select the prefix(es) or prefix size to be delegated 2152 to the client. 2154 The server sends an Advertise message to the requesting router in the 2155 same way as described in Section 18.2.2. The server MUST include an 2156 IA_PD option, identifying any prefix(es) that the server will 2157 delegate to the client. 2159 If the server will not assign any prefixes to an IA_PD in a 2160 subsequent Request from the requesting router, the server MUST send 2161 an Advertise message to the client that includes the IA_PD with no 2162 prefixes in the IA_PD and a Status Code option in the IA_PD 2163 containing status code NoPrefixAvail and a status message for the 2164 user, a Server Identifier option with the server's DUID and a Client 2165 Identifier option with the client's DUID. The server SHOULD include 2166 other stateful IA options (like IA_NA) and other configuration 2167 options in the Advertise message. 2169 19. DHCP Client-Initiated Configuration Exchange 2171 A client initiates a message exchange with a server or servers to 2172 acquire or update configuration information of interest. The client 2173 may initiate the configuration exchange as part of the operating 2174 system configuration process, when requested to do so by the 2175 application layer, when required by Stateless Address 2176 Autoconfiguration or as required to extend the lifetime of an address 2177 (Renew and Rebind messages). 2179 19.1. Client Behavior 2181 A client uses Request, Renew, Rebind, Release and Decline messages 2182 during the normal life cycle of addresses. It uses Confirm to 2183 validate addresses when it may have moved to a new link. It uses 2184 Information-Request messages when it needs configuration information 2185 but no addresses. 2187 If the client has a source address of sufficient scope that can be 2188 used by the server as a return address, and the client has received a 2189 Server Unicast option (Section 23.12) from the server, the client 2190 SHOULD unicast any Request, Renew, Release and Decline messages to 2191 the server. 2193 DISCUSSION: 2195 Use of unicast may avoid delays due to the relaying of messages by 2196 relay agents, as well as avoid overhead and duplicate responses by 2197 servers due to the delivery of client messages to multiple 2198 servers. Requiring the client to relay all DHCP messages through 2199 a relay agent enables the inclusion of relay agent options in all 2200 messages sent by the client. The server should enable the use of 2201 unicast only when relay agent options will not be used. 2203 19.1.1. Creation and Transmission of Request Messages 2205 The client uses a Request message to populate IAs with addresses and 2206 obtain other configuration information. The client includes one or 2207 more IA options in the Request message. The server then returns 2208 addresses and other information about the IAs to the client in IA 2209 options in a Reply message. 2211 The client generates a transaction ID and inserts this value in the 2212 "transaction-id" field. 2214 The client places the identifier of the destination server in a 2215 Server Identifier option. 2217 The client MUST include a Client Identifier option to identify itself 2218 to the server. The client adds any other appropriate options, 2219 including one or more IA options (if the client is requesting that 2220 the server assign it some network addresses). 2222 The client MUST include an Option Request option (see Section 23.7) 2223 to indicate the options the client is interested in receiving. The 2224 client MAY include options with data values as hints to the server 2225 about parameter values the client would like to have returned. 2227 The client includes a Reconfigure Accept option (see Section 23.20) 2228 indicating whether or not the client is willing to accept Reconfigure 2229 messages from the server. 2231 The client transmits the message according to Section 15, using the 2232 following parameters: 2234 IRT REQ_TIMEOUT 2236 MRT REQ_MAX_RT 2237 MRC REQ_MAX_RC 2239 MRD 0 2241 If the message exchange fails, the client takes an action based on 2242 the client's local policy. Examples of actions the client might take 2243 include: 2245 - Select another server from a list of servers known to the client; 2246 for example, servers that responded with an Advertise message. 2248 - Initiate the server discovery process described in Section 18. 2250 - Terminate the configuration process and report failure. 2252 19.1.2. Creation and Transmission of Confirm Messages 2254 Whenever a client may have moved to a new link, the prefixes from the 2255 addresses assigned to the interfaces on that link may no longer be 2256 appropriate for the link to which the client is attached. Examples 2257 of times when a client may have moved to a new link include: 2259 o The client reboots. 2261 o The client is physically connected to a wired connection. 2263 o The client returns from sleep mode. 2265 o The client using a wireless technology changes access points. 2267 In any situation when a client may have moved to a new link, the 2268 client SHOULD initiate a Confirm/Reply message exchange. The client 2269 includes any IAs assigned to the interface that may have moved to a 2270 new link, along with the addresses associated with those IAs, in its 2271 Confirm message. Any responding servers will indicate whether those 2272 addresses are appropriate for the link to which the client is 2273 attached with the status in the Reply message it returns to the 2274 client. 2276 One example when this rule may not be followed is when the client 2277 does not store its leases in stable storage and experiences a reboot. 2278 It may simply not retain any information, so it does not know what to 2279 confirm. In such case client MUST restart server discovery process 2280 as described in Section 18.1.1. 2282 The client sets the "msg-type" field to CONFIRM. The client 2283 generates a transaction ID and inserts this value in the 2284 "transaction-id" field. 2286 The client MUST include a Client Identifier option to identify itself 2287 to the server. The client includes IA options for all of the IAs 2288 assigned to the interface for which the Confirm message is being 2289 sent. The IA options include all of the addresses the client 2290 currently has associated with those IAs. The client SHOULD set the 2291 T1 and T2 fields in any IA_NA options, and the preferred-lifetime and 2292 valid-lifetime fields in the IA Address options to 0, as the server 2293 will ignore these fields. 2295 The first Confirm message from the client on the interface MUST be 2296 delayed by a random amount of time between 0 and CNF_MAX_DELAY. The 2297 client transmits the message according to Section 15, using the 2298 following parameters: 2300 IRT CNF_TIMEOUT 2302 MRT CNF_MAX_RT 2304 MRC 0 2306 MRD CNF_MAX_RD 2308 If the client receives no responses before the message transmission 2309 process terminates, as described in Section 15, the client SHOULD 2310 continue to use any IP addresses, using the last known lifetimes for 2311 those addresses, and SHOULD continue to use any other previously 2312 obtained configuration parameters. 2314 19.1.3. Creation and Transmission of Renew Messages 2316 To extend the valid and preferred lifetimes for the addresses 2317 associated with an IA, the client sends a Renew message to the server 2318 from which the client obtained the addresses in the IA containing an 2319 IA option for the IA. The client includes IA Address options in the 2320 IA option for the addresses associated with the IA. The server 2321 determines new lifetimes for the addresses in the IA according to the 2322 administrative configuration of the server. The server may also add 2323 new addresses to the IA. The server may remove addresses from the IA 2324 by setting the preferred and valid lifetimes of those addresses to 2325 zero. 2327 The server controls the time at which the client contacts the server 2328 to extend the lifetimes on assigned addresses through the T1 and T2 2329 parameters assigned to an IA. 2331 At time T1 for an IA, the client initiates a Renew/Reply message 2332 exchange to extend the lifetimes on any addresses in the IA. The 2333 client includes an IA option with all addresses currently assigned to 2334 the IA in its Renew message. 2336 If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no 2337 T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind 2338 message, respectively, at the client's discretion. 2340 The client sets the "msg-type" field to RENEW. The client generates 2341 a transaction ID and inserts this value in the "transaction-id" 2342 field. 2344 The client places the identifier of the destination server in a 2345 Server Identifier option. 2347 The client MUST include a Client Identifier option to identify itself 2348 to the server. The client adds any appropriate options, including 2349 one or more IA options. The client MUST include the list of 2350 addresses the client currently has associated with the IAs in the 2351 Renew message. 2353 The client MUST include an Option Request option (see Section 23.7) 2354 to indicate the options the client is interested in receiving. The 2355 client MAY include options with data values as hints to the server 2356 about parameter values the client would like to have returned. 2358 The client transmits the message according to Section 15, using the 2359 following parameters: 2361 IRT REN_TIMEOUT 2363 MRT REN_MAX_RT 2365 MRC 0 2367 MRD Remaining time until T2 2369 The message exchange is terminated when time T2 is reached (see 2370 Section 19.1.4), at which time the client begins a Rebind message 2371 exchange. 2373 19.1.4. Creation and Transmission of Rebind Messages 2375 At time T2 for an IA (which will only be reached if the server to 2376 which the Renew message was sent at time T1 has not responded), the 2377 client initiates a Rebind/Reply message exchange with any available 2378 server. The client includes an IA option with all addresses 2379 currently assigned to the IA in its Rebind message. 2381 The client sets the "msg-type" field to REBIND. The client generates 2382 a transaction ID and inserts this value in the "transaction-id" 2383 field. 2385 The client MUST include a Client Identifier option to identify itself 2386 to the server. The client adds any appropriate options, including 2387 one or more IA options. The client MUST include the list of 2388 addresses the client currently has associated with the IAs in the 2389 Rebind message. 2391 The client MUST include an Option Request option (see Section 23.7) 2392 to indicate the options the client is interested in receiving. The 2393 client MAY include options with data values as hints to the server 2394 about parameter values the client would like to have returned. 2396 The client transmits the message according to Section 15, using the 2397 following parameters: 2399 IRT REB_TIMEOUT 2401 MRT REB_MAX_RT 2403 MRC 0 2405 MRD Remaining time until valid lifetimes of all addresses have 2406 expired 2408 The message exchange is terminated when the valid lifetimes of all 2409 the addresses assigned to the IA expire (see Section 11), at which 2410 time the client has several alternative actions to choose from; for 2411 example: 2413 - The client may choose to use a Solicit message to locate a new 2414 DHCP server and send a Request for the expired IA to the new 2415 server. 2417 - The client may have other addresses in other IAs, so the client 2418 may choose to discard the expired IA and use the addresses in the 2419 other IAs. 2421 19.1.5. Creation and Transmission of Information-request Messages 2423 The client uses an Information-request message to obtain 2424 configuration information without having addresses assigned to it. 2426 The client sets the "msg-type" field to INFORMATION-REQUEST. The 2427 client generates a transaction ID and inserts this value in the 2428 "transaction-id" field. 2430 The client SHOULD include a Client Identifier option to identify 2431 itself to the server. If the client does not include a Client 2432 Identifier option, the server will not be able to return any client- 2433 specific options to the client, or the server may choose not to 2434 respond to the message at all. The client MUST include a Client 2435 Identifier option if the Information-Request message will be 2436 authenticated. 2438 The client MUST include an Option Request option (see Section 23.7) 2439 to indicate the options the client is interested in receiving. The 2440 client MAY include options with data values as hints to the server 2441 about parameter values the client would like to have returned. 2443 The first Information-request message from the client on the 2444 interface MUST be delayed by a random amount of time between 0 and 2445 INF_MAX_DELAY. The client transmits the message according to 2446 Section 15, using the following parameters: 2448 IRT INF_TIMEOUT 2450 MRT INF_MAX_RT 2452 MRC 0 2454 MRD 0 2456 19.1.6. Creation and Transmission of Release Messages 2458 To release one or more addresses, a client sends a Release message to 2459 the server. 2461 The client sets the "msg-type" field to RELEASE. The client 2462 generates a transaction ID and places this value in the "transaction- 2463 id" field. 2465 The client places the identifier of the server that allocated the 2466 address(es) in a Server Identifier option. 2468 The client MUST include a Client Identifier option to identify itself 2469 to the server. The client includes options containing the IAs for 2470 the addresses it is releasing in the "options" field. The addresses 2471 to be released MUST be included in the IAs. Any addresses for the 2472 IAs the client wishes to continue to use MUST NOT be added to the 2473 IAs. 2475 The client MUST NOT use any of the addresses it is releasing as the 2476 source address in the Release message or in any subsequently 2477 transmitted message. 2479 Because Release messages may be lost, the client should retransmit 2480 the Release if no Reply is received. However, there are scenarios 2481 where the client may not wish to wait for the normal retransmission 2482 timeout before giving up (e.g., on power down). Implementations 2483 SHOULD retransmit one or more times, but MAY choose to terminate the 2484 retransmission procedure early. 2486 The client transmits the message according to Section 15, using the 2487 following parameters: 2489 IRT REL_TIMEOUT 2491 MRT 0 2493 MRC REL_MAX_RC 2495 MRD 0 2497 The client MUST stop using all of the addresses being released as 2498 soon as the client begins the Release message exchange process. If 2499 addresses are released but the Reply from a DHCP server is lost, the 2500 client will retransmit the Release message, and the server may 2501 respond with a Reply indicating a status of NoBinding. Therefore, 2502 the client does not treat a Reply message with a status of NoBinding 2503 in a Release message exchange as if it indicates an error. 2505 Note that if the client fails to release the addresses, each address 2506 assigned to the IA will be reclaimed by the server when the valid 2507 lifetime of that address expires. 2509 19.1.7. Creation and Transmission of Decline Messages 2511 If a client detects that one or more addresses assigned to it by a 2512 server are already in use by another node, the client sends a Decline 2513 message to the server to inform it that the address is suspect. 2515 The client sets the "msg-type" field to DECLINE. The client 2516 generates a transaction ID and places this value in the "transaction- 2517 id" field. 2519 The client places the identifier of the server that allocated the 2520 address(es) in a Server Identifier option. 2522 The client MUST include a Client Identifier option to identify itself 2523 to the server. The client includes options containing the IAs for 2524 the addresses it is declining in the "options" field. The addresses 2525 to be declined MUST be included in the IAs. Any addresses for the 2526 IAs the client wishes to continue to use should not be in added to 2527 the IAs. 2529 The client MUST NOT use any of the addresses it is declining as the 2530 source address in the Decline message or in any subsequently 2531 transmitted message. 2533 The client transmits the message according to Section 15, using the 2534 following parameters: 2536 IRT DEC_TIMEOUT 2538 MRT 0 2540 MRC DEC_MAX_RC 2542 MRD 0 2544 If addresses are declined but the Reply from a DHCP server is lost, 2545 the client will retransmit the Decline message, and the server may 2546 respond with a Reply indicating a status of NoBinding. Therefore, 2547 the client does not treat a Reply message with a status of NoBinding 2548 in a Decline message exchange as if it indicates an error. 2550 19.1.8. Receipt of Reply Messages 2552 Upon the receipt of a valid Reply message in response to a Solicit 2553 (with a Rapid Commit option), Request, Confirm, Renew, Rebind or 2554 Information-request message, the client extracts the configuration 2555 information contained in the Reply. The client MAY choose to report 2556 any status code or message from the status code option in the Reply 2557 message. 2559 The client SHOULD perform duplicate address detection [RFC4862] on 2560 each of the addresses in any IAs it receives in the Reply message 2561 before using that address for traffic. If any of the addresses are 2562 found to be in use on the link, the client sends a Decline message to 2563 the server as described in Section 19.1.7. 2565 If the Reply was received in response to a Solicit (with a Rapid 2566 Commit option), Request, Renew or Rebind message, the client updates 2567 the information it has recorded about IAs from the IA options 2568 contained in the Reply message: 2570 - Record T1 and T2 times. 2572 - Add any new addresses in the IA option to the IA as recorded by 2573 the client. 2575 - Update lifetimes for any addresses in the IA option that the 2576 client already has recorded in the IA. 2578 - Discard any addresses from the IA, as recorded by the client, that 2579 have a valid lifetime of 0 in the IA Address option. 2581 - Leave unchanged any information about addresses the client has 2582 recorded in the IA but that were not included in the IA from the 2583 server. 2585 Management of the specific configuration information is detailed in 2586 the definition of each option in Section 23. 2588 If the client receives a Reply message with a Status Code containing 2589 UnspecFail, the server is indicating that it was unable to process 2590 the message due to an unspecified failure condition. If the client 2591 retransmits the original message to the same server to retry the 2592 desired operation, the client MUST limit the rate at which it 2593 retransmits the message and limit the duration of the time during 2594 which it retransmits the message. 2596 When the client receives a Reply message with a Status Code option 2597 with the value UseMulticast, the client records the receipt of the 2598 message and sends subsequent messages to the server through the 2599 interface on which the message was received using multicast. The 2600 client resends the original message using multicast. 2602 When the client receives a NotOnLink status from the server in 2603 response to a Confirm message, the client performs DHCP server 2604 solicitation, as described in Section 18, and client-initiated 2605 configuration as described in Section 19. If the client receives any 2606 Reply messages that do not indicate a NotOnLink status, the client 2607 can use the addresses in the IA and ignore any messages that indicate 2608 a NotOnLink status. 2610 When the client receives a NotOnLink status from the server in 2611 response to a Request, the client can either re-issue the Request 2612 without specifying any addresses or restart the DHCP server discovery 2613 process (see Section 18). 2615 The client examines the status code in each IA individually. If the 2616 status code is NoAddrsAvail, the client has received no usable 2617 addresses in the IA and may choose to try obtaining addresses for the 2618 IA from another server. The client uses addresses and other 2619 information from any IAs that do not contain a Status Code option 2620 with the NoAddrsAvail code. If the client receives no addresses in 2621 any of the IAs, it may either try another server (perhaps restarting 2622 the DHCP server discovery process) or use the Information-request 2623 message to obtain other configuration information only. 2625 When the client receives a Reply message in response to a Renew or 2626 Rebind message, the client examines each IA independently. For each 2627 IA in the original Renew or Rebind message, the client: 2629 - sends a Request message if the IA contained a Status Code option 2630 with the NoBinding status (and does not send any additional Renew/ 2631 Rebind messages) 2633 - sends a Renew/Rebind if the IA is not in the Reply message 2635 - otherwise accepts the information in the IA 2637 When the client receives a valid Reply message in response to a 2638 Release message, the client considers the Release event completed, 2639 regardless of the Status Code option(s) returned by the server. 2641 When the client receives a valid Reply message in response to a 2642 Decline message, the client considers the Decline event completed, 2643 regardless of the Status Code option(s) returned by the server. 2645 19.2. Server Behavior 2647 For this discussion, the Server is assumed to have been configured in 2648 an implementation specific manner with configuration of interest to 2649 clients. 2651 In most instances, the server will send a Reply in response to a 2652 client message. This Reply message MUST always contain the Server 2653 Identifier option containing the server's DUID and the Client 2654 Identifier option from the client message if one was present. 2656 In most Reply messages, the server includes options containing 2657 configuration information for the client. The server must be aware 2658 of the recommendations on packet sizes and the use of fragmentation 2659 in section 5 of [RFC2460]. If the client included an Option Request 2660 option in its message, the server includes options in the Reply 2661 message containing configuration parameters for all of the options 2662 identified in the Option Request option that the server has been 2663 configured to return to the client. The server MAY return additional 2664 options to the client if it has been configured to do so. 2666 19.2.1. Receipt of Request Messages 2668 When the server receives a Request message via unicast from a client 2669 to which the server has not sent a unicast option, the server 2670 discards the Request message and responds with a Reply message 2671 containing a Status Code option with the value UseMulticast, a Server 2672 Identifier option containing the server's DUID, the Client Identifier 2673 option from the client message, and no other options. 2675 When the server receives a valid Request message, the server creates 2676 the bindings for that client according to the server's policy and 2677 configuration information and records the IAs and other information 2678 requested by the client. 2680 The server constructs a Reply message by setting the "msg-type" field 2681 to REPLY, and copying the transaction ID from the Request message 2682 into the transaction-id field. 2684 The server MUST include a Server Identifier option containing the 2685 server's DUID and the Client Identifier option from the Request 2686 message in the Reply message. 2688 If the server finds that the prefix on one or more IP addresses in 2689 any IA in the message from the client is not appropriate for the link 2690 to which the client is connected, the server MUST return the IA to 2691 the client with a Status Code option with the value NotOnLink. 2693 If the server cannot assign any addresses to an IA in the message 2694 from the client, the server MUST include the IA in the Reply message 2695 with no addresses in the IA and a Status Code option in the IA 2696 containing status code NoAddrsAvail. 2698 For any IAs to which the server can assign addresses, the server 2699 includes the IA with addresses and other configuration parameters, 2700 and records the IA as a new client binding. 2702 The server includes a Reconfigure Accept option if the server wants 2703 to require that the client accept Reconfigure messages. 2705 The server includes other options containing configuration 2706 information to be returned to the client as described in 2707 Section 19.2. 2709 If the server finds that the client has included an IA in the Request 2710 message for which the server already has a binding that associates 2711 the IA with the client, the client has resent a Request message for 2712 which it did not receive a Reply message. The server either resends 2713 a previously cached Reply message or sends a new Reply message. 2715 19.2.2. Receipt of Confirm Messages 2717 When the server receives a Confirm message, the server determines 2718 whether the addresses in the Confirm message are appropriate for the 2719 link to which the client is attached. If all of the addresses in the 2720 Confirm message pass this test, the server returns a status of 2721 Success. If any of the addresses do not pass this test, the server 2722 returns a status of NotOnLink. If the server is unable to perform 2723 this test (for example, the server does not have information about 2724 prefixes on the link to which the client is connected), or there were 2725 no addresses in any of the IAs sent by the client, the server MUST 2726 NOT send a reply to the client. 2728 The server ignores the T1 and T2 fields in the IA options and the 2729 preferred-lifetime and valid-lifetime fields in the IA Address 2730 options. 2732 The server constructs a Reply message by setting the "msg-type" field 2733 to REPLY, and copying the transaction ID from the Confirm message 2734 into the transaction-id field. 2736 The server MUST include a Server Identifier option containing the 2737 server's DUID and the Client Identifier option from the Confirm 2738 message in the Reply message. The server includes a Status Code 2739 option indicating the status of the Confirm message. 2741 19.2.3. Receipt of Renew Messages 2743 When the server receives a Renew message via unicast from a client to 2744 which the server has not sent a unicast option, the server discards 2745 the Renew message and responds with a Reply message containing a 2746 Status Code option with the value UseMulticast, a Server Identifier 2747 option containing the server's DUID, the Client Identifier option 2748 from the client message, and no other options. 2750 When the server receives a Renew message that contains an IA option 2751 from a client, it locates the client's binding and verifies that the 2752 information in the IA from the client matches the information stored 2753 for that client. 2755 If the server cannot find a client entry for the IA the server 2756 returns the IA containing no addresses with a Status Code option set 2757 to NoBinding in the Reply message. 2759 If the server finds that any of the addresses are not appropriate for 2760 the link to which the client is attached, the server returns the 2761 address to the client with lifetimes of 0. 2763 If the server finds the addresses in the IA for the client then the 2764 server sends back the IA to the client with new lifetimes and T1/T2 2765 times. The server may choose to change the list of addresses and the 2766 lifetimes of addresses in IAs that are returned to the client. 2768 The server constructs a Reply message by setting the "msg-type" field 2769 to REPLY, and copying the transaction ID from the Renew message into 2770 the transaction-id field. 2772 The server MUST include a Server Identifier option containing the 2773 server's DUID and the Client Identifier option from the Renew message 2774 in the Reply message. 2776 The server includes other options containing configuration 2777 information to be returned to the client as described in 2778 Section 19.2. 2780 19.2.4. Receipt of Rebind Messages 2782 When the server receives a Rebind message that contains an IA option 2783 from a client, it locates the client's binding and verifies that the 2784 information in the IA from the client matches the information stored 2785 for that client. 2787 If the server cannot find a client entry for the IA and the server 2788 determines that the addresses in the IA are not appropriate for the 2789 link to which the client's interface is attached according to the 2790 server's explicit configuration information, the server MAY send a 2791 Reply message to the client containing the client's IA, with the 2792 lifetimes for the addresses in the IA set to zero. This Reply 2793 constitutes an explicit notification to the client that the addresses 2794 in the IA are no longer valid. In this situation, if the server does 2795 not send a Reply message it discards the Rebind message. 2797 If the server finds that any of the addresses are no longer 2798 appropriate for the link to which the client is attached, the server 2799 returns the address to the client with lifetimes of 0. 2801 If the server finds the addresses in the IA for the client then the 2802 server SHOULD send back the IA to the client with new lifetimes and 2803 T1/T2 times. 2805 The server constructs a Reply message by setting the "msg-type" field 2806 to REPLY, and copying the transaction ID from the Rebind message into 2807 the transaction-id field. 2809 The server MUST include a Server Identifier option containing the 2810 server's DUID and the Client Identifier option from the Rebind 2811 message in the Reply message. 2813 The server includes other options containing configuration 2814 information to be returned to the client as described in 2815 Section 19.2. 2817 19.2.5. Receipt of Information-request Messages 2819 When the server receives an Information-request message, the client 2820 is requesting configuration information that does not include the 2821 assignment of any addresses. The server determines all configuration 2822 parameters appropriate to the client, based on the server 2823 configuration policies known to the server. 2825 The server constructs a Reply message by setting the "msg-type" field 2826 to REPLY, and copying the transaction ID from the Information-request 2827 message into the transaction-id field. 2829 The server MUST include a Server Identifier option containing the 2830 server's DUID in the Reply message. If the client included a Client 2831 Identification option in the Information-request message, the server 2832 copies that option to the Reply message. 2834 The server includes options containing configuration information to 2835 be returned to the client as described in Section 19.2. 2837 If the Information-request message received from the client did not 2838 include a Client Identifier option, the server SHOULD respond with a 2839 Reply message containing any configuration parameters that are not 2840 determined by the client's identity. If the server chooses not to 2841 respond, the client may continue to retransmit the Information- 2842 request message indefinitely. 2844 19.2.6. Receipt of Release Messages 2846 When the server receives a Release message via unicast from a client 2847 to which the server has not sent a unicast option, the server 2848 discards the Release message and responds with a Reply message 2849 containing a Status Code option with value UseMulticast, a Server 2850 Identifier option containing the server's DUID, the Client Identifier 2851 option from the client message, and no other options. 2853 Upon the receipt of a valid Release message, the server examines the 2854 IAs and the addresses in the IAs for validity. If the IAs in the 2855 message are in a binding for the client, and the addresses in the IAs 2856 have been assigned by the server to those IAs, the server deletes the 2857 addresses from the IAs and makes the addresses available for 2858 assignment to other clients. The server ignores addresses not 2859 assigned to the IA, although it may choose to log an error. 2861 After all the addresses have been processed, the server generates a 2862 Reply message and includes a Status Code option with value Success, a 2863 Server Identifier option with the server's DUID, and a Client 2864 Identifier option with the client's DUID. For each IA in the Release 2865 message for which the server has no binding information, the server 2866 adds an IA option using the IAID from the Release message, and 2867 includes a Status Code option with the value NoBinding in the IA 2868 option. No other options are included in the IA option. 2870 A server may choose to retain a record of assigned addresses and IAs 2871 after the lifetimes on the addresses have expired to allow the server 2872 to reassign the previously assigned addresses to a client. 2874 19.2.7. Receipt of Decline Messages 2876 When the server receives a Decline message via unicast from a client 2877 to which the server has not sent a unicast option, the server 2878 discards the Decline message and responds with a Reply message 2879 containing a Status Code option with the value UseMulticast, a Server 2880 Identifier option containing the server's DUID, the Client Identifier 2881 option from the client message, and no other options. 2883 Upon the receipt of a valid Decline message, the server examines the 2884 IAs and the addresses in the IAs for validity. If the IAs in the 2885 message are in a binding for the client, and the addresses in the IAs 2886 have been assigned by the server to those IAs, the server deletes the 2887 addresses from the IAs. The server ignores addresses not assigned to 2888 the IA (though it may choose to log an error if it finds such an 2889 address). 2891 The client has found any addresses in the Decline messages to be 2892 already in use on its link. Therefore, the server SHOULD mark the 2893 addresses declined by the client so that those addresses are not 2894 assigned to other clients, and MAY choose to make a notification that 2895 addresses were declined. Local policy on the server determines when 2896 the addresses identified in a Decline message may be made available 2897 for assignment. 2899 After all the addresses have been processed, the server generates a 2900 Reply message and includes a Status Code option with the value 2901 Success, a Server Identifier option with the server's DUID, and a 2902 Client Identifier option with the client's DUID. For each IA in the 2903 Decline message for which the server has no binding information, the 2904 server adds an IA option using the IAID from the Decline message and 2905 includes a Status Code option with the value NoBinding in the IA 2906 option. No other options are included in the IA option. 2908 19.2.8. Transmission of Reply Messages 2910 If the original message was received directly by the server, the 2911 server unicasts the Reply message directly to the client using the 2912 address in the source address field from the IP datagram in which the 2913 original message was received. The Reply message MUST be unicast 2914 through the interface on which the original message was received. 2916 If the original message was received in a Relay-forward message, the 2917 server constructs a Relay-reply message with the Reply message in the 2918 payload of a Relay Message option (see Section 23.10). If the Relay- 2919 forward messages included an Interface-id option, the server copies 2920 that option to the Relay-reply message. The server unicasts the 2921 Relay-reply message directly to the relay agent using the address in 2922 the source address field from the IP datagram in which the Relay- 2923 forward message was received. 2925 20. DHCP Server-Initiated Configuration Exchange 2927 A server initiates a configuration exchange to cause DHCP clients to 2928 obtain new addresses and other configuration information. For 2929 example, an administrator may use a server-initiated configuration 2930 exchange when links in the DHCP domain are to be renumbered. Other 2931 examples include changes in the location of directory servers, 2932 addition of new services such as printing, and availability of new 2933 software. 2935 20.1. Server Behavior 2937 A server sends a Reconfigure message to cause a client to initiate 2938 immediately a Renew/Reply or Information-request/Reply message 2939 exchange with the server. 2941 20.1.1. Creation and Transmission of Reconfigure Messages 2943 The server sets the "msg-type" field to RECONFIGURE. The server sets 2944 the transaction-id field to 0. The server includes a Server 2945 Identifier option containing its DUID and a Client Identifier option 2946 containing the client's DUID in the Reconfigure message. 2948 The server MAY include an Option Request option to inform the client 2949 of what information has been changed or new information that has been 2950 added. In particular, the server specifies the IA option in the 2951 Option Request option if the server wants the client to obtain new 2952 address information. If the server identifies the IA option in the 2953 Option Request option, the server MUST include an IA option to 2954 identify each IA that is to be reconfigured on the client. The IA 2955 options included by the server MUST NOT contain any options. 2957 Because of the risk of denial of service attacks against DHCP 2958 clients, the use of a security mechanism is mandated in Reconfigure 2959 messages. The server MUST use DHCP authentication in the Reconfigure 2960 message. 2962 The server MUST include a Reconfigure Message option (defined in 2963 Section 23.19) to select whether the client responds with a Renew 2964 message, a Rebind message, or an Information-Request message. 2966 The server MUST NOT include any other options in the Reconfigure 2967 except as specifically allowed in the definition of individual 2968 options. 2970 A server sends each Reconfigure message to a single DHCP client, 2971 using an IPv6 unicast address of sufficient scope belonging to the 2972 DHCP client. If the server does not have an address to which it can 2973 send the Reconfigure message directly to the client, the server uses 2974 a Relay-reply message (as described in Section 21.3) to send the 2975 Reconfigure message to a relay agent that will relay the message to 2976 the client. The server may obtain the address of the client (and the 2977 appropriate relay agent, if required) through the information the 2978 server has about clients that have been in contact with the server, 2979 or through some external agent. 2981 To reconfigure more than one client, the server unicasts a separate 2982 message to each client. The server may initiate the reconfiguration 2983 of multiple clients concurrently; for example, a server may send a 2984 Reconfigure message to additional clients while previous 2985 reconfiguration message exchanges are still in progress. 2987 The Reconfigure message causes the client to initiate a Renew/Reply, 2988 a Rebind/Reply, or Information-request/Reply message exchange with 2989 the server. The server interprets the receipt of a Renew, a Rebind, 2990 or Information-request message (whichever was specified in the 2991 original Reconfigure message) from the client as satisfying the 2992 Reconfigure message request. 2994 20.1.2. Time Out and Retransmission of Reconfigure Messages 2996 If the server does not receive a Renew, Rebind, or Information- 2997 request message from the client in REC_TIMEOUT milliseconds, the 2998 server retransmits the Reconfigure message, doubles the REC_TIMEOUT 2999 value and waits again. The server continues this process until 3000 REC_MAX_RC unsuccessful attempts have been made, at which point the 3001 server SHOULD abort the reconfigure process for that client. 3003 Default and initial values for REC_TIMEOUT and REC_MAX_RC are 3004 documented in Section 6.5. 3006 20.2. Receipt of Renew or Rebind Messages 3008 In response to a Renew message, the server generates and sends a 3009 Reply message to the client as described in Section 19.2.3 and 3010 Section 19.2.8, including options for configuration parameters. 3012 In response to a Rebind message, the server generates and sends a 3013 Reply message to the client as described in Section 19.2.4 and 3014 Section 19.2.8, including options for configuration parameters. 3016 The server MAY include options containing the IAs and new values for 3017 other configuration parameters in the Reply message, even if those 3018 IAs and parameters were not requested in the Renew or Rebind message 3019 from the client. 3021 20.3. Receipt of Information-request Messages 3023 The server generates and sends a Reply message to the client as 3024 described in Section 19.2.5 and Section 19.2.8, including options for 3025 configuration parameters. 3027 The server MAY include options containing new values for other 3028 configuration parameters in the Reply message, even if those 3029 parameters were not requested in the Information-request message from 3030 the client. 3032 20.4. Client Behavior 3034 A client receives Reconfigure messages sent to the UDP port 546 on 3035 interfaces for which it has acquired configuration information 3036 through DHCP. These messages may be sent at any time. Since the 3037 results of a reconfiguration event may affect application layer 3038 programs, the client SHOULD log these events, and MAY notify these 3039 programs of the change through an implementation-specific interface. 3041 20.4.1. Receipt of Reconfigure Messages 3043 Upon receipt of a valid Reconfigure message, the client responds with 3044 either a Renew message, a Rebind message, or an Information-request 3045 message as indicated by the Reconfigure Message option (as defined in 3046 Section 23.19). The client ignores the transaction-id field in the 3047 received Reconfigure message. While the transaction is in progress, 3048 the client discards any Reconfigure messages it receives. 3050 DISCUSSION: 3052 The Reconfigure message acts as a trigger that signals the client 3053 to complete a successful message exchange. Once the client has 3054 received a Reconfigure, the client proceeds with the message 3055 exchange (retransmitting the Renew or Information-request message 3056 if necessary); the client ignores any additional Reconfigure 3057 messages until the exchange is complete. Subsequent Reconfigure 3058 messages cause the client to initiate a new exchange. 3060 How does this mechanism work in the face of duplicated or 3061 retransmitted Reconfigure messages? Duplicate messages will be 3062 ignored because the client will begin the exchange after the 3063 receipt of the first Reconfigure. Retransmitted messages will 3064 either trigger the exchange (if the first Reconfigure was not 3065 received by the client) or will be ignored. The server can 3066 discontinue retransmission of Reconfigure messages to the client 3067 once the server receives the Renew or Information-request message 3068 from the client. 3070 It might be possible for a duplicate or retransmitted Reconfigure 3071 to be sufficiently delayed (and delivered out of order) to arrive 3072 at the client after the exchange (initiated by the original 3073 Reconfigure) has been completed. In this case, the client would 3074 initiate a redundant exchange. The likelihood of delayed and out 3075 of order delivery is small enough to be ignored. The consequence 3076 of the redundant exchange is inefficiency rather than incorrect 3077 operation. 3079 20.4.2. Creation and Transmission of Renew or Rebind Messages 3081 When responding to a Reconfigure, the client creates and sends the 3082 Renew message in exactly the same manner as outlined in 3083 Section 19.1.3, with the exception that the client copies the Option 3084 Request option and any IA options from the Reconfigure message into 3085 the Renew message. The client MUST include a Server Identifier 3086 option in the Renew message, identifying the server with which the 3087 client most recently communicated. 3089 When responding to a Reconfigure, the client creates and sends the 3090 Rebind message in exactly the same manner as outlined in 3091 Section 19.1.4, with the exception that the client copies the Option 3092 Request option and any IA options from the Reconfigure message into 3093 the Rebind message. 3095 If a client is currently sending Rebind messages, as described in 3096 Section 19.1.3, the client ignores any received Reconfigure messages. 3098 20.4.3. Creation and Transmission of Information-request Messages 3100 When responding to a Reconfigure, the client creates and sends the 3101 Information-request message in exactly the same manner as outlined in 3102 Section 19.1.5, with the exception that the client includes a Server 3103 Identifier option with the identifier from the Reconfigure message to 3104 which the client is responding. 3106 20.4.4. Time Out and Retransmission of Renew, Rebind or Information- 3107 request Messages 3109 The client uses the same variables and retransmission algorithm as it 3110 does with Renew, Rebind, or Information-request messages generated as 3111 part of a client-initiated configuration exchange. See 3112 Section 19.1.3, Section 19.1.4, and Section 19.1.5 for details. If 3113 the client does not receive a response from the server by the end of 3114 the retransmission process, the client ignores and discards the 3115 Reconfigure message. 3117 20.4.5. Receipt of Reply Messages 3119 Upon the receipt of a valid Reply message, the client processes the 3120 options and sets (or resets) configuration parameters appropriately. 3121 The client records and updates the lifetimes for any addresses 3122 specified in IAs in the Reply message. 3124 20.5. Prefix Delegation reconfiguration 3126 This section describes prefix delegation in Reconfigure message 3127 exchanges. 3129 20.5.1. Delegating Router behavior 3131 The delegating router initiates a configuration message exchange with 3132 a requesting router, as described in Section 20, by sending a 3133 Reconfigure message (acting as a DHCP server) to the requesting 3134 router, as described in Section 20.1. The delegating router 3135 specifies the IA_PD option in the Option Request option to cause the 3136 requesting router to include an IA_PD option to obtain new 3137 information about delegated prefix(es). 3139 20.5.2. Requesting Router behavior 3141 The requesting router responds to a Reconfigure message, acting as a 3142 DHCP client, received from a delegating router as described in 3143 Section 20.4 The requesting router MUST include the IA_PD Prefix 3144 option(s) (in an IA_PD option) for prefix(es) that have been 3145 delegated to the requesting router by the delegating router from 3146 which the Reconfigure message was received. 3148 21. Relay Agent Behavior 3150 The relay agent MAY be configured to use a list of destination 3151 addresses, which MAY include unicast addresses, the All_DHCP_Servers 3152 multicast address, or other addresses selected by the network 3153 administrator. If the relay agent has not been explicitly 3154 configured, it MUST use the All_DHCP_Servers multicast address as the 3155 default. 3157 If the relay agent relays messages to the All_DHCP_Servers multicast 3158 address or other multicast addresses, it sets the Hop Limit field to 3159 32. 3161 21.1. Relaying a Client Message or a Relay-forward Message 3163 A relay agent relays both messages from clients and Relay-forward 3164 messages from other relay agents. When a relay agent receives a 3165 valid message to be relayed, it constructs a new Relay-forward 3166 message. The relay agent copies the source address from the header 3167 of the IP datagram in which the message was received to the peer- 3168 address field of the Relay-forward message. The relay agent copies 3169 the received DHCP message (excluding any IP or UDP headers) into a 3170 Relay Message option in the new message. The relay agent adds to the 3171 Relay-forward message any other options it is configured to include. 3173 [RFC6221] defines a Lightweight DHCPv6 Relay Agent (LDRA) that allows 3174 Relay Agent Information to be inserted by an access node that 3175 performs a link- layer bridging (i.e., non-routing) function. 3177 21.1.1. Relaying a Message from a Client 3179 If the relay agent received the message to be relayed from a client, 3180 the relay agent places a global or site-scoped address with a prefix 3181 assigned to the link on which the client should be assigned an 3182 address in the link-address field. This address will be used by the 3183 server to determine the link from which the client should be assigned 3184 an address and other configuration information. The hop-count in the 3185 Relay-forward message is set to 0. 3187 If the relay agent cannot use the address in the link-address field 3188 to identify the interface through which the response to the client 3189 will be relayed, the relay agent MUST include an Interface-id option 3190 (see Section 23.18) in the Relay-forward message. The server will 3191 include the Interface-id option in its Relay-reply message. The 3192 relay agent fills in the link-address field as described in the 3193 previous paragraph regardless of whether the relay agent includes an 3194 Interface-id option in the Relay-forward message. 3196 21.1.2. Relaying a Message from a Relay Agent 3198 If the message received by the relay agent is a Relay-forward message 3199 and the hop-count in the message is greater than or equal to 3200 HOP_COUNT_LIMIT, the relay agent discards the received message. 3202 The relay agent copies the source address from the IP datagram in 3203 which the message was received from the relay agent into the peer- 3204 address field in the Relay-forward message and sets the hop-count 3205 field to the value of the hop-count field in the received message 3206 incremented by 1. 3208 If the source address from the IP datagram header of the received 3209 message is a global or site-scoped address (and the device on which 3210 the relay agent is running belongs to only one site), the relay agent 3211 sets the link-address field to 0; otherwise the relay agent sets the 3212 link-address field to a global or site-scoped address assigned to the 3213 interface on which the message was received, or includes an 3214 Interface-ID option to identify the interface on which the message 3215 was received. 3217 21.1.3. Relay agent behavior with Prefix Delegation 3219 A relay agent forwards messages containing Prefix Delegation options 3220 in the same way as described earlier in this section. 3222 If a delegating router communicates with a requesting router through 3223 a relay agent, the delegating router may need a protocol or other 3224 out-of-band communication to configure routing information for 3225 delegated prefixes on any router through which the requesting router 3226 may forward traffic. 3228 21.2. Relaying a Relay-reply Message 3230 The relay agent processes any options included in the Relay-reply 3231 message in addition to the Relay Message option, and then discards 3232 those options. 3234 The relay agent extracts the message from the Relay Message option 3235 and relays it to the address contained in the peer-address field of 3236 the Relay-reply message. Relay agents MUST NOT modify the message. 3238 If the Relay-reply message includes an Interface-id option, the relay 3239 agent relays the message from the server to the client on the link 3240 identified by the Interface-id option. Otherwise, if the link- 3241 address field is not set to zero, the relay agent relays the message 3242 on the link identified by the link-address field. 3244 21.3. Construction of Relay-reply Messages 3246 A server uses a Relay-reply message to return a response to a client 3247 if the original message from the client was relayed to the server in 3248 a Relay-forward message or to send a Reconfigure message to a client 3249 if the server does not have an address it can use to send the message 3250 directly to the client. 3252 A response to the client MUST be relayed through the same relay 3253 agents as the original client message. The server causes this to 3254 happen by creating a Relay-reply message that includes a Relay 3255 Message option containing the message for the next relay agent in the 3256 return path to the client. The contained Relay-reply message 3257 contains another Relay Message option to be sent to the next relay 3258 agent, and so on. The server must record the contents of the peer- 3259 address fields in the received message so it can construct the 3260 appropriate Relay-reply message carrying the response from the 3261 server. 3263 For example, if client C sent a message that was relayed by relay 3264 agent A to relay agent B and then to the server, the server would 3265 send the following Relay-Reply message to relay agent B: 3267 msg-type: RELAY-REPLY 3268 hop-count: 1 3269 link-address: 0 3270 peer-address: A 3271 Relay Message option, containing: 3272 msg-type: RELAY-REPLY 3273 hop-count: 0 3274 link-address: address from link to which C is attached 3275 peer-address: C 3276 Relay Message option: 3278 Figure 8: Relay-reply Example 3280 When sending a Reconfigure message to a client through a relay agent, 3281 the server creates a Relay-reply message that includes a Relay 3282 Message option containing the Reconfigure message for the next relay 3283 agent in the return path to the client. The server sets the peer- 3284 address field in the Relay-reply message header to the address of the 3285 client, and sets the link-address field as required by the relay 3286 agent to relay the Reconfigure message to the client. The server 3287 obtains the addresses of the client and the relay agent through prior 3288 interaction with the client or through some external mechanism. 3290 22. Authentication of DHCP Messages 3292 Some network administrators may wish to provide authentication of the 3293 source and contents of DHCP messages. For example, clients may be 3294 subject to denial of service attacks through the use of bogus DHCP 3295 servers, or may simply be misconfigured due to unintentionally 3296 instantiated DHCP servers. Network administrators may wish to 3297 constrain the allocation of addresses to authorized hosts to avoid 3298 denial of service attacks in "hostile" environments where the network 3299 medium is not physically secured, such as wireless networks or 3300 college residence halls. 3302 The DHCP authentication mechanism is based on the design of 3303 authentication for DHCPv4 [RFC3118]. 3305 22.1. Security of Messages Sent Between Servers and Relay Agents 3307 Relay agents and servers that exchange messages securely use the 3308 IPsec mechanisms for IPv6 [RFC4301]. If a client message is relayed 3309 through multiple relay agents, each of the relay agents must have 3310 established independent, pairwise trust relationships. That is, if 3311 messages from client C will be relayed by relay agent A to relay 3312 agent B and then to the server, relay agents A and B must be 3313 configured to use IPsec for the messages they exchange, and relay 3314 agent B and the server must be configured to use IPsec for the 3315 messages they exchange. 3317 Relay agents and servers that support secure relay agent to server or 3318 relay agent to relay agent communication use IPsec under the 3319 following conditions: 3321 Selectors Relay agents are manually configured with the 3322 addresses of the relay agent or server to 3323 which DHCP messages are to be forwarded. 3324 Each relay agent and server that will be 3325 using IPsec for securing DHCP messages must 3326 also be configured with a list of the relay 3327 agents to which messages will be returned. 3329 The selectors for the relay agents and 3330 servers will be the pairs of addresses 3331 defining relay agents and servers that 3332 exchange DHCP messages on DHCPv6 UDP port 3333 547. 3335 Mode Relay agents and servers use transport mode 3336 and ESP. The information in DHCP messages is 3337 not generally considered confidential, so 3338 encryption need not be used (i.e., NULL 3339 encryption can be used). 3341 Key management Because the relay agents and servers are used 3342 within an organization, public key schemes 3343 are not necessary. Because the relay agents 3344 and servers must be manually configured, 3345 manually configured key management may 3346 suffice, but does not provide defense against 3347 replayed messages. Accordingly, IKE with 3348 preshared secrets SHOULD be supported. IKE 3349 with public keys MAY be supported. 3351 Security policy DHCP messages between relay agents and 3352 servers should only be accepted from DHCP 3353 peers as identified in the local 3354 configuration. 3356 Authentication Shared keys, indexed to the source IP address 3357 of the received DHCP message, are adequate in 3358 this application. 3360 Availability Appropriate IPsec implementations are likely 3361 to be available for servers and for relay 3362 agents in more featureful devices used in 3363 enterprise and core ISP networks. IPsec is 3364 less likely to be available for relay agents 3365 in low end devices primarily used in the home 3366 or small office markets. 3368 22.2. Summary of DHCP Authentication 3370 Authentication of DHCP messages is accomplished through the use of 3371 the Authentication option (see Section 23.11). The authentication 3372 information carried in the Authentication option can be used to 3373 reliably identify the source of a DHCP message and to confirm that 3374 the contents of the DHCP message have not been tampered with. 3376 The Authentication option provides a framework for multiple 3377 authentication protocols. Two such protocols are defined here. 3378 Other protocols defined in the future will be specified in separate 3379 documents. 3381 Any DHCP message MUST NOT include more than one Authentication 3382 option. 3384 The protocol field in the Authentication option identifies the 3385 specific protocol used to generate the authentication information 3386 carried in the option. The algorithm field identifies a specific 3387 algorithm within the authentication protocol; for example, the 3388 algorithm field specifies the hash algorithm used to generate the 3389 message authentication code (MAC) in the authentication option. The 3390 replay detection method (RDM) field specifies the type of replay 3391 detection used in the replay detection field. 3393 22.3. Replay Detection 3395 The Replay Detection Method (RDM) field determines the type of replay 3396 detection used in the Replay Detection field. 3398 If the RDM field contains 0x00, the replay detection field MUST be 3399 set to the value of a strictly monotonically increasing counter. 3400 Using a counter value, such as the current time of day (for example, 3401 an NTP-format timestamp [RFC5905]), can reduce the danger of replay 3402 attacks. This method MUST be supported by all protocols. 3404 22.4. Delayed Authentication Protocol 3406 If the protocol field is 2, the message is using the "delayed 3407 authentication" mechanism. In delayed authentication, the client 3408 requests authentication in its Solicit message, and the server 3409 replies with an Advertise message that includes authentication 3410 information. This authentication information contains a nonce value 3411 generated by the source as a message authentication code (MAC) to 3412 provide message authentication and entity authentication. 3414 The use of a particular technique based on the HMAC protocol 3415 [RFC2104] using the MD5 hash [RFC1321] is defined here. 3417 22.4.1. Use of the Authentication Option in the Delayed Authentication 3418 Protocol 3420 In a Solicit message, the client fills in the protocol, algorithm and 3421 RDM fields in the Authentication option with the client's 3422 preferences. The client sets the replay detection field to zero and 3423 omits the authentication information field. The client sets the 3424 option-len field to 11. 3426 In all other messages, the protocol and algorithm fields identify the 3427 method used to construct the contents of the authentication 3428 information field. The RDM field identifies the method used to 3429 construct the contents of the replay detection field. 3431 The format of the Authentication information is: 3433 0 1 2 3 3434 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 3435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3436 | DHCP realm | 3437 | (variable length) | 3438 . . 3439 . . 3440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3441 | key ID (32 bits) | 3442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3443 | | 3444 | HMAC-MD5 | 3445 | (128 bits) | 3446 | | 3447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3449 Figure 9: Authentication information format 3451 DHCP realm The DHCP realm that identifies the key used 3452 to generate the HMAC-MD5 value. This is a 3453 domain name encoded as described in 3454 Section 9. 3456 key ID The key identifier that identified the key 3457 used to generate the HMAC-MD5 value. 3459 HMAC-MD5 The message authentication code generated by 3460 applying MD5 to the DHCP message using the 3461 key identified by the DHCP realm, client 3462 DUID, and key ID. 3464 The sender computes the MAC using the HMAC generation algorithm 3465 [RFC2104] and the MD5 hash function [RFC1321]. The entire DHCP 3466 message (setting the MAC field of the authentication option to zero), 3467 including the DHCP message header and the options field, is used as 3468 input to the HMAC-MD5 computation function. 3470 DISCUSSION: 3472 Algorithm 1 specifies the use of HMAC-MD5. Use of a different 3473 technique, such as HMAC-SHA, will be specified as a separate 3474 protocol. 3476 The DHCP realm used to identify authentication keys is chosen to 3477 be unique among administrative domains. Use of the DHCP realm 3478 allows DHCP administrators to avoid conflict in the use of key 3479 identifiers, and allows a host using DHCP to use authenticated 3480 DHCP while roaming among DHCP administrative domains. 3482 22.4.2. Message Validation 3484 Any DHCP message that includes more than one authentication option 3485 MUST be discarded. 3487 To validate an incoming message, the receiver first checks that the 3488 value in the replay detection field is acceptable according to the 3489 replay detection method specified by the RDM field. If no replay is 3490 detected, then the receiver computes the MAC as described in 3491 [RFC2104]. The entire DHCP message (setting the MAC field of the 3492 authentication option to 0) is used as input to the HMAC-MD5 3493 computation function. If the MAC computed by the receiver does not 3494 match the MAC contained in the authentication option, the receiver 3495 MUST discard the DHCP message. 3497 22.4.3. Key Utilization 3499 Each DHCP client has a set of keys. Each key is identified by . Each key also has a lifetime. The key 3501 may not be used past the end of its lifetime. The client's keys are 3502 initially distributed to the client through some out-of-band 3503 mechanism. The lifetime for each key is distributed with the key. 3504 Mechanisms for key distribution and lifetime specification are beyond 3505 the scope of this document. 3507 The client and server use one of the client's keys to authenticate 3508 DHCP messages during a session (until the next Solicit message sent 3509 by the client). 3511 22.4.4. Client Considerations for Delayed Authentication Protocol 3513 The client announces its intention to use DHCP authentication by 3514 including an Authentication option in its Solicit message. The 3515 server selects a key for the client based on the client's DUID. The 3516 client and server use that key to authenticate all DHCP messages 3517 exchanged during the session. 3519 22.4.4.1. Sending Solicit Messages 3521 When the client sends a Solicit message and wishes to use 3522 authentication, it includes an Authentication option with the desired 3523 protocol, algorithm and RDM as described in Section 22.4. The client 3524 does not include any replay detection or authentication information 3525 in the Authentication option. 3527 22.4.4.2. Receiving Advertise Messages 3529 The client validates any Advertise messages containing an 3530 Authentication option specifying the delayed authentication protocol 3531 using the validation test described in Section 22.4.2. 3533 The Client behavior is defined by local policy, as detailed below. 3535 If the client requires that Advertise messages be authenticated, then 3536 it MUST ignore Advertise messages that do not include authentication 3537 information, or for which the client has no matching key, or that do 3538 not pass the validation test. 3540 Local policy MAY also prefer authenticated Advertise messages, in 3541 which case the client SHOULD attempt to validate all Advertise 3542 messages for which the client has a matching key. Messages for which 3543 the client has a key, but which do not pass the validation test MUST 3544 be rejected, even if the client would otherwise accept the same 3545 message without the Authentication option. 3547 In all cases, messages for which the client does not have a matching 3548 key should be treated as if they have no Authentication option. 3550 When the decision to accept unauthenticated message is made, it 3551 should be made with care. Accepting an unauthenticated Advertise 3552 message can make the client vulnerable to spoofing and other attacks. 3553 Policies and actions which were depending upon Authentication MUST 3554 NOT be executed. Local users SHOULD be informed that the client has 3555 accepted an unauthenticated Advertise message. 3557 A client MUST be configurable to discard unauthenticated messages, 3558 and SHOULD be configured by default to discard unauthenticated 3559 messages if the client has been configured with an authentication key 3560 or other authentication information. 3562 A client MAY choose to differentiate between Advertise messages with 3563 no authentication information and Advertise messages that do not pass 3564 the validation test; for example, a client might accept the former 3565 and discard the latter. If a client does accept an unauthenticated 3566 message, the client SHOULD inform any local users and SHOULD log the 3567 event. 3569 22.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline or Release 3570 Messages 3572 If the client authenticated the Advertise message through which the 3573 client selected the server, the client MUST generate authentication 3574 information for subsequent Request, Confirm, Renew, Rebind or Release 3575 messages sent to the server, as described in Section 22.4. When the 3576 client sends a subsequent message, it MUST use the same key used by 3577 the server to generate the authentication information. 3579 22.4.4.4. Sending Information-request Messages 3581 If the server has selected a key for the client in a previous message 3582 exchange (see Section 22.4.5.1), the client MUST use the same key to 3583 generate the authentication information throughout the session. 3585 22.4.4.5. Receiving Reply Messages 3587 If the client authenticated the Advertise it accepted, the client 3588 MUST validate the associated Reply message from the server. The 3589 client MUST ignore and discard the Reply if the message fails to pass 3590 the validation test and MAY log the validation failure. 3592 If the client accepted an Advertise message that did not include 3593 authentication information or did not pass the validation test, the 3594 client MAY accept an unauthenticated Reply message from the server. 3596 22.4.4.6. Receiving Reconfigure Messages 3598 The client MUST discard the Reconfigure if the message fails to pass 3599 the validation test and MAY log the validation failure. 3601 22.4.5. Server Considerations for Delayed Authentication Protocol 3603 After receiving a Solicit message that contains an Authentication 3604 option, the server selects a key for the client, based on the 3605 client's DUID and key selection policies with which the server has 3606 been configured. The server identifies the selected key in the 3607 Advertise message and uses the key to validate subsequent messages 3608 between the client and the server. 3610 22.4.5.1. Receiving Solicit Messages and Sending Advertise Messages 3612 The server selects a key for the client and includes authentication 3613 information in the Advertise message returned to the client as 3614 specified in Section 22.4. The server MUST record the identifier of 3615 the key selected for the client and use that same key for validating 3616 subsequent messages with the client. 3618 22.4.5.2. Receiving Request, Confirm, Renew, Rebind or Release Messages 3619 and Sending Reply Messages 3621 The server uses the key identified in the message and validates the 3622 message as specified in Section 22.4.2. If the message fails to pass 3623 the validation test or the server does not know the key identified by 3624 the 'key ID' field, the server MUST discard the message and MAY 3625 choose to log the validation failure. If the server receives a 3626 client message without an authentication option while the server has 3627 previously sent authentication information in the same session, it 3628 MUST discard the message and MAY choose to log the validation 3629 failure, because the client violates the definition in 3630 Section 22.4.4.3. 3632 If the message passes the validation test, the server responds to the 3633 specific message as described in Section 19.2. The server MUST 3634 include authentication information generated using the key identified 3635 in the received message, as specified in Section 22.4. 3637 22.5. Reconfigure Key Authentication Protocol 3639 The Reconfigure key authentication protocol provides protection 3640 against misconfiguration of a client caused by a Reconfigure message 3641 sent by a malicious DHCP server. In this protocol, a DHCP server 3642 sends a Reconfigure Key to the client in the initial exchange of DHCP 3643 messages. The client records the Reconfigure Key for use in 3644 authenticating subsequent Reconfigure messages from that server. The 3645 server then includes an HMAC computed from the Reconfigure Key in 3646 subsequent Reconfigure messages. 3648 Both the Reconfigure Key sent from the server to the client and the 3649 HMAC in subsequent Reconfigure messages are carried as the 3650 Authentication information in an Authentication option. The format 3651 of the Authentication information is defined in the following 3652 section. 3654 The Reconfigure Key protocol is used (initiated by the server) only 3655 if the client and server are not using any other authentication 3656 protocol and the client and server have negotiated to use Reconfigure 3657 messages. 3659 22.5.1. Use of the Authentication Option in the Reconfigure Key 3660 Authentication Protocol 3662 The following fields are set in an Authentication option for the 3663 Reconfigure Key Authentication Protocol: 3665 protocol 3 3667 algorithm 1 3669 RDM 0 3671 The format of the Authentication information for the Reconfigure Key 3672 Authentication Protocol is: 3674 0 1 2 3 3675 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 3676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3677 | Type | Value (128 bits) | 3678 +-+-+-+-+-+-+-+-+ | 3679 . . 3680 . . 3681 . +-+-+-+-+-+-+-+-+ 3682 | | 3683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3685 Figure 10: RKAP Authentication Information 3687 Type Type of data in Value field carried in this 3688 option: 3690 1 Reconfigure Key value (used in Reply 3691 message). 3693 2 HMAC-MD5 digest of the message (used in 3694 Reconfigure message). 3696 Value Data as defined by field. 3698 22.5.2. Server considerations for Reconfigure Key protocol 3700 The server selects a Reconfigure Key for a client during the Request/ 3701 Reply, Solicit/Reply or Information-request/Reply message exchange. 3702 The server records the Reconfigure Key and transmits that key to the 3703 client in an Authentication option in the Reply message. 3705 The Reconfigure Key is 128 bits long, and MUST be a cryptographically 3706 strong random or pseudo-random number that cannot easily be 3707 predicted. 3709 To provide authentication for a Reconfigure message, the server 3710 selects a replay detection value according to the RDM selected by the 3711 server, and computes an HMAC-MD5 of the Reconfigure message using the 3712 Reconfigure Key for the client. The server computes the HMAC-MD5 3713 over the entire DHCP Reconfigure message, including the 3714 Authentication option; the HMAC-MD5 field in the Authentication 3715 option is set to zero for the HMAC-MD5 computation. The server 3716 includes the HMAC-MD5 in the authentication information field in an 3717 Authentication option included in the Reconfigure message sent to the 3718 client. 3720 22.5.3. Client considerations for Reconfigure Key protocol 3722 The client will receive a Reconfigure Key from the server in the 3723 initial Reply message from the server. The client records the 3724 Reconfigure Key for use in authenticating subsequent Reconfigure 3725 messages. 3727 To authenticate a Reconfigure message, the client computes an HMAC- 3728 MD5 over the DHCP Reconfigure message, using the Reconfigure Key 3729 received from the server. If this computed HMAC-MD5 matches the 3730 value in the Authentication option, the client accepts the 3731 Reconfigure message. 3733 23. DHCP Options 3735 Options are used to carry additional information and parameters in 3736 DHCP messages. Every option shares a common base format, as 3737 described in Section 23.1. All values in options are represented in 3738 network byte order. 3740 This document describes the DHCP options defined as part of the base 3741 DHCP specification. Other options may be defined in the future in 3742 separate documents. See [RFC7227] for guidelines regarding new 3743 options definition. 3745 Unless otherwise noted, each option may appear only in the options 3746 area of a DHCP message and may appear only once. If an option does 3747 appear multiple times, each instance is considered separate and the 3748 data areas of the options MUST NOT be concatenated or otherwise 3749 combined. 3751 Options that are allowed to appear only once are called singleton 3752 options. The only non-singleton options defined in this document are 3753 IA_NA (See Section 23.4), IA_TA (See Section 23.5), and IA_PD (See 3754 Section 23.21) options. Also, IAAddress (See Section 23.6) and 3755 IAPrefix (See Section 23.22 may appear in their respective IA options 3756 more than once. 3758 23.1. Format of DHCP Options 3760 The format of DHCP options is: 3762 0 1 2 3 3763 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 3764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3765 | option-code | option-len | 3766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3767 | option-data | 3768 | (option-len octets) | 3769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3771 Figure 11: Option Format 3773 option-code An unsigned integer identifying the specific 3774 option type carried in this option. 3776 option-len An unsigned integer giving the length of the 3777 option-data field in this option in octets. 3779 option-data The data for the option; the format of this 3780 data depends on the definition of the option. 3782 DHCPv6 options are scoped by using encapsulation. Some options apply 3783 generally to the client, some are specific to an IA, and some are 3784 specific to the addresses within an IA. These latter two cases are 3785 discussed in Section 23.4 and Section 23.6. 3787 23.2. Client Identifier Option 3789 The Client Identifier option is used to carry a DUID (see Section 10) 3790 identifying a client between a client and a server. The format of 3791 the Client Identifier option is: 3793 0 1 2 3 3794 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 3795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3796 | OPTION_CLIENTID | option-len | 3797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3798 . . 3799 . DUID . 3800 . (variable length) . 3801 . . 3802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3804 Figure 12: Client Identifier Option Format 3806 option-code OPTION_CLIENTID (1). 3808 option-len Length of DUID in octets. 3810 DUID The DUID for the client. 3812 23.3. Server Identifier Option 3814 The Server Identifier option is used to carry a DUID (see Section 10) 3815 identifying a server between a client and a server. The format of 3816 the Server Identifier option is: 3818 0 1 2 3 3819 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 3820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3821 | OPTION_SERVERID | option-len | 3822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3823 . . 3824 . DUID . 3825 . (variable length) . 3826 . . 3827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3829 Figure 13: Server Identifier Option Format 3831 option-code OPTION_SERVERID (2). 3833 option-len Length of DUID in octets. 3835 DUID The DUID for the server. 3837 23.4. Identity Association for Non-temporary Addresses Option 3839 The Identity Association for Non-temporary Addresses option (IA_NA 3840 option) is used to carry an IA_NA, the parameters associated with the 3841 IA_NA, and the non-temporary addresses associated with the IA_NA. 3843 Addresses appearing in an IA_NA option are not temporary addresses 3844 (see Section 23.5). 3846 The format of the IA_NA option is: 3848 0 1 2 3 3849 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 3850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3851 | OPTION_IA_NA | option-len | 3852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3853 | IAID (4 octets) | 3854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3855 | T1 | 3856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3857 | T2 | 3858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3859 | | 3860 . IA_NA-options . 3861 . . 3862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3864 Figure 14: Identity Association for Non-temporary Addresses Option 3865 Format 3867 option-code OPTION_IA_NA (3). 3869 option-len 12 + length of IA_NA-options field. 3871 IAID The unique identifier for this IA_NA; the 3872 IAID must be unique among the identifiers for 3873 all of this client's IA_NAs. The number 3874 space for IA_NA IAIDs is separate from the 3875 number space for IA_TA IAIDs. 3877 T1 The time at which the client contacts the 3878 server from which the addresses in the IA_NA 3879 were obtained to extend the lifetimes of the 3880 addresses assigned to the IA_NA; T1 is a time 3881 duration relative to the current time 3882 expressed in units of seconds. 3884 T2 The time at which the client contacts any 3885 available server to extend the lifetimes of 3886 the addresses assigned to the IA_NA; T2 is a 3887 time duration relative to the current time 3888 expressed in units of seconds. 3890 IA_NA-options Options associated with this IA_NA. 3892 The IA_NA-options field encapsulates those options that are specific 3893 to this IA_NA. For example, all of the IA Address Options carrying 3894 the addresses associated with this IA_NA are in the IA_NA-options 3895 field. 3897 An IA_NA option may only appear in the options area of a DHCP 3898 message. A DHCP message may contain multiple IA_NA options. 3900 The status of any operations involving this IA_NA is indicated in a 3901 Status Code option in the IA_NA-options field. 3903 Note that an IA_NA has no explicit "lifetime" or "lease length" of 3904 its own. When the valid lifetimes of all of the addresses in an 3905 IA_NA have expired, the IA_NA can be considered as having expired. 3906 T1 and T2 are included to give servers explicit control over when a 3907 client recontacts the server about a specific IA_NA. 3909 In a message sent by a client to a server, values in the T1 and T2 3910 fields indicate the client's preference for those parameters. The 3911 client sets T1 and T2 to 0 if it has no preference for those values. 3912 In a message sent by a server to a client, the client MUST use the 3913 values in the T1 and T2 fields for the T1 and T2 parameters, unless 3914 those values in those fields are 0. The values in the T1 and T2 3915 fields are the number of seconds until T1 and T2. 3917 The server selects the T1 and T2 times to allow the client to extend 3918 the lifetimes of any addresses in the IA_NA before the lifetimes 3919 expire, even if the server is unavailable for some short period of 3920 time. Recommended values for T1 and T2 are .5 and .8 times the 3921 shortest preferred lifetime of the addresses in the IA that the 3922 server is willing to extend, respectively. If the "shortest" 3923 preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and 3924 T2 values are also 0xffffffff. If the time at which the addresses in 3925 an IA_NA are to be renewed is to be left to the discretion of the 3926 client, the server sets T1 and T2 to 0. 3928 If a server receives an IA_NA with T1 greater than T2, and both T1 3929 and T2 are greater than 0, the server ignores the invalid values of 3930 T1 and T2 and processes the IA_NA as though the client had set T1 and 3931 T2 to 0. 3933 If a client receives an IA_NA with T1 greater than T2, and both T1 3934 and T2 are greater than 0, the client discards the IA_NA option and 3935 processes the remainder of the message as though the server had not 3936 included the invalid IA_NA option. 3938 Care should be taken in setting T1 or T2 to 0xffffffff ("infinity"). 3939 A client will never attempt to extend the lifetimes of any addresses 3940 in an IA with T1 set to 0xffffffff. A client will never attempt to 3941 use a Rebind message to locate a different server to extend the 3942 lifetimes of any addresses in an IA with T2 set to 0xffffffff. 3944 23.5. Identity Association for Temporary Addresses Option 3946 The Identity Association for the Temporary Addresses (IA_TA) option 3947 is used to carry an IA_TA, the parameters associated with the IA_TA 3948 and the addresses associated with the IA_TA. All of the addresses in 3949 this option are used by the client as temporary addresses, as defined 3950 in [RFC4941]. The format of the IA_TA option is: 3952 0 1 2 3 3953 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 3954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3955 | OPTION_IA_TA | option-len | 3956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3957 | IAID (4 octets) | 3958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3959 | | 3960 . IA_TA-options . 3961 . . 3962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3964 Figure 15: Identity Association for Temporary Addresses Option Format 3966 option-code OPTION_IA_TA (4). 3968 option-len 4 + length of IA_TA-options field. 3970 IAID The unique identifier for this IA_TA; the 3971 IAID must be unique among the identifiers for 3972 all of this client's IA_TAs. The number 3973 space for IA_TA IAIDs is separate from the 3974 number space for IA_NA IAIDs. 3976 IA_TA-options Options associated with this IA_TA. 3978 The IA_TA-Options field encapsulates those options that are specific 3979 to this IA_TA. For example, all of the IA Address Options carrying 3980 the addresses associated with this IA_TA are in the IA_TA-options 3981 field. 3983 Each IA_TA carries one "set" of temporary addresses; that is, at most 3984 one address from each prefix assigned to the link to which the client 3985 is attached. 3987 An IA_TA option may only appear in the options area of a DHCP 3988 message. A DHCP message may contain multiple IA_TA options. 3990 The status of any operations involving this IA_TA is indicated in a 3991 Status Code option in the IA_TA-options field. 3993 Note that an IA has no explicit "lifetime" or "lease length" of its 3994 own. When the valid lifetimes of all of the addresses in an IA_TA 3995 have expired, the IA can be considered as having expired. 3997 An IA_TA option does not include values for T1 and T2. A client MAY 3998 request that the lifetimes on temporary addresses be extended by 3999 including the addresses in a IA_TA option sent in a Renew or Rebind 4000 message to a server. For example, a client would request an 4001 extension on the lifetime of a temporary address to allow an 4002 application to continue to use an established TCP connection. 4004 The client obtains new temporary addresses by sending an IA_TA option 4005 with a new IAID to a server. Requesting new temporary addresses from 4006 the server is the equivalent of generating new temporary addresses as 4007 described in [RFC4941]. The server will generate new temporary 4008 addresses and return them to the client. The client should request 4009 new temporary addresses before the lifetimes on the previously 4010 assigned addresses expire. 4012 A server MUST return the same set of temporary address for the same 4013 IA_TA (as identified by the IAID) as long as those addresses are 4014 still valid. After the lifetimes of the addresses in an IA_TA have 4015 expired, the IAID may be reused to identify a new IA_TA with new 4016 temporary addresses. 4018 This option MAY appear in a Confirm message if the lifetimes on the 4019 temporary addresses in the associated IA have not expired. 4021 23.6. IA Address Option 4023 The IA Address option is used to specify IPv6 addresses associated 4024 with an IA_NA or an IA_TA. The IA Address option must be 4025 encapsulated in the Options field of an IA_NA or IA_TA option. The 4026 Options field encapsulates those options that are specific to this 4027 address. 4029 The format of the IA Address option is: 4031 0 1 2 3 4032 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 4033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4034 | OPTION_IAADDR | option-len | 4035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4036 | | 4037 | IPv6 address | 4038 | | 4039 | | 4040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4041 | preferred-lifetime | 4042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4043 | valid-lifetime | 4044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4045 . . 4046 . IAaddr-options . 4047 . . 4048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4050 Figure 16: IA Address Option Format 4052 option-code OPTION_IAADDR (5). 4054 option-len 24 + length of IAaddr-options field. 4056 IPv6 address An IPv6 address. 4058 preferred-lifetime The preferred lifetime for the IPv6 address 4059 in the option, expressed in units of seconds. 4061 valid-lifetime The valid lifetime for the IPv6 address in 4062 the option, expressed in units of seconds. 4064 IAaddr-options Options associated with this address. 4066 In a message sent by a client to a server, values in the preferred 4067 and valid lifetime fields indicate the client's preference for those 4068 parameters. The client may send 0 if it has no preference for the 4069 preferred and valid lifetimes. If a client wishes to express its 4070 lifetimes preferences and does not have the knowledge to populate the 4071 IPv6 address field, it can use unspecified address (::). It is up to 4072 a server to honor or ignore these preferences. 4074 In a message sent by a server to a client, the client MUST use the 4075 values in the preferred and valid lifetime fields for the preferred 4076 and valid lifetimes. The values in the preferred and valid lifetimes 4077 are the number of seconds remaining in each lifetime. 4079 A client discards any addresses for which the preferred lifetime is 4080 greater than the valid lifetime. A server ignores the lifetimes set 4081 by the client if the preferred lifetime is greater than the valid 4082 lifetime and ignores the values for T1 and T2 set by the client if 4083 those values are greater than the preferred lifetime. 4085 Care should be taken in setting the valid lifetime of an address to 4086 0xffffffff ("infinity"), which amounts to a permanent assignment of 4087 an address to a client. 4089 An IA Address option may appear only in an IA_NA option or an IA_TA 4090 option. More than one IA Address Option can appear in an IA_NA 4091 option or an IA_TA option. 4093 The status of any operations involving this IA Address is indicated 4094 in a Status Code option in the IAaddr-options field, as specified in 4095 Section 23.13. 4097 23.7. Option Request Option 4099 The Option Request option is used to identify a list of options in a 4100 message between a client and a server. The format of the Option 4101 Request option is: 4103 0 1 2 3 4104 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 4105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4106 | OPTION_ORO | option-len | 4107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4108 | requested-option-code-1 | requested-option-code-2 | 4109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4110 | ... | 4111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4113 Figure 17: Option Request Option Format 4115 option-code OPTION_ORO (6). 4117 option-len 2 * number of requested options. 4119 requested-option-code-n The option code for an option requested 4120 by the client. 4122 A client MAY include an Option Request option in a Solicit, Request, 4123 Renew, Rebind, Confirm or Information-request message to inform the 4124 server about options the client wants the server to send to the 4125 client. A server MAY include an Option Request option in a 4126 Reconfigure message to indicate which options the client should 4127 request from the server. If there is a need to request encapsulated 4128 options, top-level Option Request option MUST be used for that 4129 purpose. There is no need request IAADDR or IAPREFIX. 4131 23.8. Preference Option 4133 The Preference option is sent by a server to a client to affect the 4134 selection of a server by the client. 4136 The format of the Preference option is: 4138 0 1 2 3 4139 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 4140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4141 | OPTION_PREFERENCE | option-len | 4142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4143 | pref-value | 4144 +-+-+-+-+-+-+-+-+ 4146 Figure 18: Preference Option Format 4148 option-code OPTION_PREFERENCE (7). 4150 option-len 1. 4152 pref-value The preference value for the server in this 4153 message. 4155 A server MAY include a Preference option in an Advertise message to 4156 control the selection of a server by the client. See Section 18.1.3 4157 for the use of the Preference option by the client and the 4158 interpretation of Preference option data value. 4160 23.9. Elapsed Time Option 4161 0 1 2 3 4162 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 4163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4164 | OPTION_ELAPSED_TIME | option-len | 4165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4166 | elapsed-time | 4167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4169 Figure 19: Elapsed Time Option Format 4171 option-code OPTION_ELAPSED_TIME (8). 4173 option-len 2. 4175 elapsed-time The amount of time since the client began its 4176 current DHCP transaction. This time is 4177 expressed in hundredths of a second (10^-2 4178 seconds). 4180 A client MUST include an Elapsed Time option in messages to indicate 4181 how long the client has been trying to complete a DHCP message 4182 exchange. The elapsed time is measured from the time at which the 4183 client sent the first message in the message exchange, and the 4184 elapsed-time field is set to 0 in the first message in the message 4185 exchange. Servers and Relay Agents use the data value in this option 4186 as input to policy controlling how a server responds to a client 4187 message. For example, the elapsed time option allows a secondary 4188 DHCP server to respond to a request when a primary server has not 4189 answered in a reasonable time. The elapsed time value is an 4190 unsigned, 16 bit integer. The client uses the value 0xffff to 4191 represent any elapsed time values greater than the largest time value 4192 that can be represented in the Elapsed Time option. 4194 23.10. Relay Message Option 4196 The Relay Message option carries a DHCP message in a Relay-forward or 4197 Relay-reply message. 4199 The format of the Relay Message option is: 4201 0 1 2 3 4202 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 4203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4204 | OPTION_RELAY_MSG | option-len | 4205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4206 | | 4207 . DHCP-relay-message . 4208 . . 4209 . . 4210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4212 Figure 20: Relay Message Option Format 4214 option-code OPTION_RELAY_MSG (9) 4216 option-len Length of DHCP-relay-message 4218 DHCP-relay-message In a Relay-forward message, the received 4219 message, relayed verbatim to the next relay 4220 agent or server; in a Relay-reply message, 4221 the message to be copied and relayed to the 4222 relay agent or client whose address is in the 4223 peer-address field of the Relay-reply message 4225 23.11. Authentication Option 4227 The Authentication option carries authentication information to 4228 authenticate the identity and contents of DHCP messages. The use of 4229 the Authentication option is described in Section 22. The format of 4230 the Authentication option is: 4232 0 1 2 3 4233 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 4234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4235 | OPTION_AUTH | option-len | 4236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4237 | protocol | algorithm | RDM | | 4238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4239 | | 4240 | replay detection (64 bits) +-+-+-+-+-+-+-+-+ 4241 | | auth-info | 4242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4243 . authentication information . 4244 . (variable length) . 4245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4247 Figure 21: Authentication Option Format 4249 option-code OPTION_AUTH (11) 4251 option-len 11 + length of authentication information 4252 field 4254 protocol The authentication protocol used in this 4255 authentication option 4257 algorithm The algorithm used in the authentication 4258 protocol 4260 RDM The replay detection method used in this 4261 authentication option 4263 Replay detection The replay detection information for the RDM 4265 authentication information The authentication information, as 4266 specified by the protocol and algorithm used 4267 in this authentication option 4269 23.12. Server Unicast Option 4271 The server sends this option to a client to indicate to the client 4272 that it is allowed to unicast messages to the server. The format of 4273 the Server Unicast option is: 4275 0 1 2 3 4276 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 4277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4278 | OPTION_UNICAST | option-len | 4279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4280 | | 4281 | server-address | 4282 | | 4283 | | 4284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4286 Figure 22: Server Unicast Option Format 4288 option-code OPTION_UNICAST (12). 4290 option-len 16. 4292 server-address The IP address to which the client should 4293 send messages delivered using unicast. 4295 The server specifies the IPv6 address to which the client is to send 4296 unicast messages in the server-address field. When a client receives 4297 this option, where permissible and appropriate, the client sends 4298 messages directly to the server using the IPv6 address specified in 4299 the server-address field of the option. 4301 When the server sends a Unicast option to the client, some messages 4302 from the client will not be relayed by Relay Agents, and will not 4303 include Relay Agent options from the Relay Agents. Therefore, a 4304 server should only send a Unicast option to a client when Relay 4305 Agents are not sending Relay Agent options. A DHCP server rejects 4306 any messages sent inappropriately using unicast to ensure that 4307 messages are relayed by Relay Agents when Relay Agent options are in 4308 use. 4310 Details about when the client may send messages to the server using 4311 unicast are in Section 19. 4313 23.13. Status Code Option 4315 This option returns a status indication related to the DHCP message 4316 or option in which it appears. The format of the Status Code option 4317 is: 4319 0 1 2 3 4320 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 4321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4322 | OPTION_STATUS_CODE | option-len | 4323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4324 | status-code | | 4325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4326 . . 4327 . status-message . 4328 . . 4329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4331 Figure 23: Status Code Option Format 4333 option-code OPTION_STATUS_CODE (13). 4335 option-len 2 + length of status-message. 4337 status-code The numeric code for the status encoded in 4338 this option. The status codes are defined in 4339 Section 25.4. 4341 status-message A UTF-8 encoded text string suitable for 4342 display to an end user, which MUST NOT be 4343 null-terminated. 4345 A Status Code option may appear in the options field of a DHCP 4346 message and/or in the options field of another option. If the Status 4347 Code option does not appear in a message in which the option could 4348 appear, the status of the message is assumed to be Success. 4350 23.14. Rapid Commit Option 4352 The Rapid Commit option is used to signal the use of the two message 4353 exchange for address assignment. The format of the Rapid Commit 4354 option is: 4356 0 1 2 3 4357 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 4358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4359 | OPTION_RAPID_COMMIT | 0 | 4360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4362 Figure 24: Rapid Commit Option Format 4364 option-code OPTION_RAPID_COMMIT (14). 4366 option-len 0. 4368 A client MAY include this option in a Solicit message if the client 4369 is prepared to perform the Solicit-Reply message exchange described 4370 in Section 18.1.1. 4372 A server MUST include this option in a Reply message sent in response 4373 to a Solicit message when completing the Solicit-Reply message 4374 exchange. 4376 DISCUSSION: 4378 Each server that responds with a Reply to a Solicit that includes 4379 a Rapid Commit option will commit the assigned addresses in the 4380 Reply message to the client, and will not receive any confirmation 4381 that the client has received the Reply message. Therefore, if 4382 more than one server responds to a Solicit that includes a Rapid 4383 Commit option, some servers will commit addresses that are not 4384 actually used by the client. 4386 The problem of unused addresses can be minimized, for example, by 4387 designing the DHCP service so that only one server responds to the 4388 Solicit or by using relatively short lifetimes for assigned 4389 addresses. 4391 23.15. User Class Option 4393 The User Class option is used by a client to identify the type or 4394 category of user or applications it represents. 4396 The format of the User Class option is: 4398 0 1 2 3 4399 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 4400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4401 | OPTION_USER_CLASS | option-len | 4402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4403 . . 4404 . user-class-data . 4405 . . 4406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4408 Figure 25: User Class Option Format 4410 option-code OPTION_USER_CLASS (15). 4412 option-len Length of user class data field. 4414 user-class-data The user classes carried by the client. 4416 The information contained in the data area of this option is 4417 contained in one or more opaque fields that represent the user class 4418 or classes of which the client is a member. A server selects 4419 configuration information for the client based on the classes 4420 identified in this option. For example, the User Class option can be 4421 used to configure all clients of people in the accounting department 4422 with a different printer than clients of people in the marketing 4423 department. The user class information carried in this option MUST 4424 be configurable on the client. 4426 The data area of the user class option MUST contain one or more 4427 instances of user class data. Each instance of the user class data 4428 is formatted as follows: 4430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4431 | user-class-len | opaque-data | 4432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4434 Figure 26: User Class Data Format 4436 The user-class-len is two octets long and specifies the length of the 4437 opaque user class data in network byte order. 4439 A server interprets the classes identified in this option according 4440 to its configuration to select the appropriate configuration 4441 information for the client. A server may use only those user classes 4442 that it is configured to interpret in selecting configuration 4443 information for a client and ignore any other user classes. In 4444 response to a message containing a User Class option, a server 4445 includes a User Class option containing those classes that were 4446 successfully interpreted by the server, so that the client can be 4447 informed of the classes interpreted by the server. 4449 23.16. Vendor Class Option 4451 This option is used by a client to identify the vendor that 4452 manufactured the hardware on which the client is running. The 4453 information contained in the data area of this option is contained in 4454 one or more opaque fields that identify details of the hardware 4455 configuration. The format of the Vendor Class option is: 4457 0 1 2 3 4458 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 4459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4460 | OPTION_VENDOR_CLASS | option-len | 4461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4462 | enterprise-number | 4463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4464 . . 4465 . vendor-class-data . 4466 . . . . . 4467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4469 Figure 27: Vendor Class Option Format 4471 option-code OPTION_VENDOR_CLASS (16). 4473 option-len 4 + length of vendor class data field. 4475 enterprise-number The vendor's registered Enterprise Number as 4476 registered with IANA [IANA-PEN]. 4478 vendor-class-data The hardware configuration of the host on 4479 which the client is running. 4481 The vendor-class-data is composed of a series of separate items, each 4482 of which describes some characteristic of the client's hardware 4483 configuration. Examples of vendor-class-data instances might include 4484 the version of the operating system the client is running or the 4485 amount of memory installed on the client. 4487 Each instance of the vendor-class-data is formatted as follows: 4489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4490 | vendor-class-len | opaque-data | 4491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4493 Figure 28: Vendor Class Data Format 4495 The vendor-class-len is two octets long and specifies the length of 4496 the opaque vendor class data in network byte order. 4498 Servers and clients MUST NOT include more than one instance of 4499 OPTION_VENDOR_CLASS with the same Enterprise Number. Each instance 4500 of OPTION_VENDOR_CLASS can carry multiple sub-options. 4502 23.17. Vendor-specific Information Option 4504 This option is used by clients and servers to exchange vendor- 4505 specific information. 4507 The format of the Vendor-specific Information option is: 4509 0 1 2 3 4510 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 4511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4512 | OPTION_VENDOR_OPTS | option-len | 4513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4514 | enterprise-number | 4515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4516 . . 4517 . option-data . 4518 . . 4519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4521 Figure 29: Vendor-specific Information Option Format 4523 option-code OPTION_VENDOR_OPTS (17) 4525 option-len 4 + length of option-data field 4527 enterprise-number The vendor's registered Enterprise Number as 4528 registered with IANA [IANA-PEN]. 4530 option-data An opaque object, interpreted by vendor- 4531 specific code on the clients and servers 4533 The definition of the information carried in this option is vendor 4534 specific. The vendor is indicated in the enterprise-number field. 4535 Use of vendor-specific information allows enhanced operation, 4536 utilizing additional features in a vendor's DHCP implementation. A 4537 DHCP client that does not receive requested vendor-specific 4538 information will still configure the host device's IPv6 stack to be 4539 functional. 4541 The encapsulated vendor-specific options field MUST be encoded as a 4542 sequence of code/length/value fields of identical format to the DHCP 4543 options field. The option codes are defined by the vendor identified 4544 in the enterprise-number field and are not managed by IANA. Each of 4545 the encapsulated options is formatted as follows: 4547 0 1 2 3 4548 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 4549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4550 | opt-code | option-len | 4551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4552 . . 4553 . option-data . 4554 . . 4555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4557 Figure 30: Vendor-specific Options Format 4559 opt-code The code for the encapsulated option. 4561 option-len An unsigned integer giving the length of the 4562 option-data field in this encapsulated option 4563 in octets. 4565 option-data The data area for the encapsulated option. 4567 Multiple instances of the Vendor-specific Information option may 4568 appear in a DHCP message. Each instance of the option is interpreted 4569 according to the option codes defined by the vendor identified by the 4570 Enterprise Number in that option. Servers and clients MUST NOT send 4571 more than one instance of Vendor-specific Information option with the 4572 same Enterprise Number. Each instanf of Vendor-specific Information 4573 option MAY contain multiple encapsulated options. 4575 A client that is interested in receiving a Vendor-specific 4576 Information Option: 4578 - MUST specify the Vendor-specific Information Option in an Option 4579 Request Option. 4581 - MAY specify an associated Vendor Class Option. 4583 - MAY specify the Vendor-specific Information Option with any data. 4585 Severs only return the Vendor-specific Information Options if 4586 specified in Option Request Options from clients and: 4588 - MAY use the Enterprise Numbers in the associated Vendor Class 4589 Options to restrict the set of Enterprise Numbers in the Vendor- 4590 specific Information Options returned. 4592 - MAY return all configured Vendor-specific Information Options. 4594 - MAY use other information in the packet or in its configuration to 4595 determine which set of Enterprise Numbers in the Vendor-specific 4596 Information Options to return. 4598 23.18. Interface-Id Option 4600 The relay agent MAY send the Interface-id option to identify the 4601 interface on which the client message was received. If a relay agent 4602 receives a Relay-reply message with an Interface-id option, the relay 4603 agent relays the message to the client through the interface 4604 identified by the option. 4606 The format of the Interface ID option is: 4608 0 1 2 3 4609 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 4610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4611 | OPTION_INTERFACE_ID | option-len | 4612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4613 . . 4614 . interface-id . 4615 . . 4616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4618 Figure 31: Interface-ID Option Format 4620 option-code OPTION_INTERFACE_ID (18). 4622 option-len Length of interface-id field. 4624 interface-id An opaque value of arbitrary length generated 4625 by the relay agent to identify one of the 4626 relay agent's interfaces. 4628 The server MUST copy the Interface-Id option from the Relay-forward 4629 message into the Relay-reply message the server sends to the relay 4630 agent in response to the Relay-forward message. This option MUST NOT 4631 appear in any message except a Relay-forward or Relay-reply message. 4633 Servers MAY use the Interface-ID for parameter assignment policies. 4634 The Interface-ID SHOULD be considered an opaque value, with policies 4635 based on exact match only; that is, the Interface-ID SHOULD NOT be 4636 internally parsed by the server. The Interface-ID value for an 4637 interface SHOULD be stable and remain unchanged, for example, after 4638 the relay agent is restarted; if the Interface-ID changes, a server 4639 will not be able to use it reliably in parameter assignment policies. 4641 23.19. Reconfigure Message Option 4643 A server includes a Reconfigure Message option in a Reconfigure 4644 message to indicate to the client whether the client responds with a 4645 Renew message, a Rebind message, or an Information-request message. 4646 The format of this option is: 4648 0 1 2 3 4649 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 4650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4651 | OPTION_RECONF_MSG | option-len | 4652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4653 | msg-type | 4654 +-+-+-+-+-+-+-+-+ 4656 Figure 32: Reconfigure Message Option Format 4658 option-code OPTION_RECONF_MSG (19). 4660 option-len 1. 4662 msg-type 5 for Renew message, 6 for Rebind, 11 for 4663 Information-request message. 4665 The Reconfigure Message option can only appear in a Reconfigure 4666 message. 4668 23.20. Reconfigure Accept Option 4670 A client uses the Reconfigure Accept option to announce to the server 4671 whether the client is willing to accept Reconfigure messages, and a 4672 server uses this option to tell the client whether or not to accept 4673 Reconfigure messages. The default behavior, in the absence of this 4674 option, means unwillingness to accept Reconfigure messages, or 4675 instruction not to accept Reconfigure messages, for the client and 4676 server messages, respectively. The following figure gives the format 4677 of the Reconfigure Accept option: 4679 0 1 2 3 4680 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 4681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4682 | OPTION_RECONF_ACCEPT | 0 | 4683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4685 Figure 33: Reconfigure Accept Option Format 4687 option-code OPTION_RECONF_ACCEPT (20). 4689 option-len 0. 4691 23.21. Identity Association for Prefix Delegation Option 4693 The IA_PD option is used to carry a prefix delegation identity 4694 association, the parameters associated with the IA_PD and the 4695 prefixes associated with it. 4697 0 1 2 3 4698 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 4699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4700 | OPTION_IA_PD | option-length | 4701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4702 | IAID (4 octets) | 4703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4704 | T1 | 4705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4706 | T2 | 4707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4708 . . 4709 . IA_PD-options . 4710 . . 4711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4713 Figure 34: Identity Association for Prefix Delegation Option Format 4715 option-code OPTION_IA_PD (25). 4717 option-length 12 + length of IA_PD-options field. 4719 IAID The unique identifier for this IA_PD; the 4720 IAID must be unique among the identifiers for 4721 all of this requesting router's IA_PDs. 4723 T1 The time at which the requesting router 4724 should contact the delegating router from 4725 which the prefixes in the IA_PD were obtained 4726 to extend the lifetimes of the prefixes 4727 delegated to the IA_PD; T1 is a time duration 4728 relative to the current time expressed in 4729 units of seconds. 4731 T2 The time at which the requesting router 4732 should contact any available delegating 4733 router to extend the lifetimes of the 4734 prefixes assigned to the IA_PD; T2 is a time 4735 duration relative to the current time 4736 expressed in units of seconds. 4738 IA_PD-options Options associated with this IA_PD. 4740 The IA_PD-options field encapsulates those options that are specific 4741 to this IA_PD. For example, all of the IA_PD Prefix Options carrying 4742 the prefixes associated with this IA_PD are in the IA_PD-options 4743 field. 4745 An IA_PD option may only appear in the options area of a DHCP 4746 message. A DHCP message may contain multiple IA_PD options. 4748 The status of any operations involving this IA_PD is indicated in a 4749 Status Code option in the IA_PD-options field. 4751 Note that an IA_PD has no explicit "lifetime" or "lease length" of 4752 its own. When the valid lifetimes of all of the prefixes in a IA_PD 4753 have expired, the IA_PD can be considered as having expired. T1 and 4754 T2 are included to give delegating routers explicit control over when 4755 a requesting router should contact the delegating router about a 4756 specific IA_PD. 4758 In a message sent by a requesting router to a delegating router, 4759 values in the T1 and T2 fields indicate the requesting router's 4760 preference for those parameters. The requesting router sets T1 and 4761 T2 to zero if it has no preference for those values. In a message 4762 sent by a delegating router to a requesting router, the requesting 4763 router MUST use the values in the T1 and T2 fields for the T1 and T2 4764 parameters. The values in the T1 and T2 fields are the number of 4765 seconds until T1 and T2. 4767 The delegating router selects the T1 and T2 times to allow the 4768 requesting router to extend the lifetimes of any prefixes in the 4769 IA_PD before the lifetimes expire, even if the delegating router is 4770 unavailable for some short period of time. Recommended values for T1 4771 and T2 are .5 and .8 times the shortest preferred lifetime of the 4772 prefixes in the IA_PD that the delegating router is willing to 4773 extend, respectively. If the time at which the prefixes in an IA_PD 4774 are to be renewed is to be left to the discretion of the requesting 4775 router, the delegating router sets T1 and T2 to 0. 4777 If a delegating router receives an IA_PD with T1 greater than T2, and 4778 both T1 and T2 are greater than 0, the delegating router ignores the 4779 invalid values of T1 and T2 and processes the IA_PD as though the 4780 requesting router had set T1 and T2 to 0. 4782 If a requesting router receives an IA_PD with T1 greater than T2, and 4783 both T1 and T2 are greater than 0, the requesting router discards the 4784 IA_PD option and processes the remainder of the message as though the 4785 requesting router had not included the IA_PD option. 4787 23.22. IA Prefix Option 4789 The IA_PD Prefix option is used to specify IPv6 address prefixes 4790 associated with an IA_PD. The IA_PD Prefix option must be 4791 encapsulated in the IA_PD-options field of an IA_PD option. 4793 0 1 2 3 4794 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 4795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4796 | OPTION_IAPREFIX | option-length | 4797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4798 | preferred-lifetime | 4799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4800 | valid-lifetime | 4801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4802 | prefix-length | | 4803 +-+-+-+-+-+-+-+-+ IPv6 prefix | 4804 | (16 octets) | 4805 | | 4806 | | 4807 | | 4808 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4809 | | . 4810 +-+-+-+-+-+-+-+-+ . 4811 . IAprefix-options . 4812 . . 4813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4815 Figure 35: IA Prefix Option Format 4817 option-code OPTION_IAPREFIX (26) 4819 option-length 25 + length of IAprefix-options field. 4821 preferred-lifetime The recommended preferred lifetime for the 4822 IPv6 prefix in the option, expressed in units 4823 of seconds. A value of 0xFFFFFFFF represents 4824 infinity. 4826 valid-lifetime The valid lifetime for the IPv6 prefix in the 4827 option, expressed in units of seconds. A 4828 value of 0xFFFFFFFF represents infinity. 4830 prefix-length Length for this prefix in bits. 4832 IPv6-prefix An IPv6 prefix. 4834 IAprefix-options Options associated with this prefix. 4836 In a message sent by a requesting router to a delegating router, the 4837 values in the fields can be used to indicate the requesting router's 4838 preference for those values. The requesting router may send a value 4839 of zero to indicate no preference. A requesting router may set the 4840 IPv6 prefix field to zero and a given value in the prefix-length 4841 field to indicate a preference for the size of the prefix to be 4842 delegated. 4844 In a message sent by a delegating router the preferred and valid 4845 lifetimes should be set to the values of AdvPreferredLifetime and 4846 AdvValidLifetime as specified in section 6.2.1, "Router Configuration 4847 Variables" of [RFC2461], unless administratively configured. 4849 A requesting router discards any prefixes for which the preferred 4850 lifetime is greater than the valid lifetime. A delegating router 4851 ignores the lifetimes set by the requesting router if the preferred 4852 lifetime is greater than the valid lifetime and ignores the values 4853 for T1 and T2 set by the requesting router if those values are 4854 greater than the preferred lifetime. 4856 The values in the preferred and valid lifetimes are the number of 4857 seconds remaining for each lifetime. 4859 An IA_PD Prefix option may appear only in an IA_PD option. More than 4860 one IA_PD Prefix Option can appear in a single IA_PD option. 4862 The status of any operations involving this IA_PD Prefix option is 4863 indicated in a Status Code option in the IAprefix-options field. 4865 23.23. SOL_MAX_RT Option 4867 A DHCP server sends the SOL_MAX_RT option to a client to override the 4868 default value of SOL_MAX_RT. The value of SOL_MAX_RT in the option 4869 replaces the default value defined in Section 6.5. One use for the 4870 SOL_MAX_RT option is to set a longer value for SOL_MAX_RT, which 4871 reduces the Solicit traffic from a client that has not received a 4872 response to its Solicit messages. 4874 The format of the SOL_MAX_RT option is: 4876 0 1 2 3 4877 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 4878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4879 | option-code | option-len | 4880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4881 | SOL_MAX_RT value | 4882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4884 Figure 36: SOL_MAX_RT Option Format 4886 option-code OPTION_SOL_MAX_RT (82). 4888 option-len 4. 4890 SOL_MAX_RT value Overriding value for SOL_MAX_RT in seconds; 4891 MUST be in range: 60 <= "value" <= 86400 (1 4892 day). 4894 A DHCP client MUST include the SOL_MAX_RT option code in any Option 4895 Request option (see Section 23.7) it sends. 4897 The DHCP server MAY include the SOL_MAX_RT option in any response it 4898 sends to a client that has included the SOL_MAX_RT option code in an 4899 Option Request option. The SOL_MAX_RT option is sent in the main 4900 body of the message to client, not as an encapsulated option in, 4901 e.g., an IA_NA, IA_TA, or IA_PD option. 4903 A DHCP client MUST ignore any SOL_MAX_RT option values that are less 4904 than 60 or more than 86400. 4906 If a DHCP client receives a message containing a SOL_MAX_RT option 4907 that has a valid value for SOL_MAX_RT, the client MUST set its 4908 internal SOL_MAX_RT parameter to the value contained in the 4909 SOL_MAX_RT option. This value of SOL_MAX_RT is then used by the 4910 retransmission mechanism defined in Section 15 and Section 18.1.2. 4912 Updated SOL_MAX_RT value applies only to the network interface on 4913 which the client received SOL_MAX_RT option. 4915 23.24. INF_MAX_RT Option 4917 A DHCP server sends the INF_MAX_RT option to a client to override the 4918 default value of INF_MAX_RT. The value of INF_MAX_RT in the option 4919 replaces the default value defined in Section 6.5. One use for the 4920 INF_MAX_RT option is to set a longer value for INF_MAX_RT, which 4921 reduces the Information-request traffic from a client that has not 4922 received a response to its Information-request messages. 4924 The format of the INF_MAX_RT option is: 4926 0 1 2 3 4927 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 4928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4929 | option-code | option-len | 4930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4931 | INF_MAX_RT value | 4932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4934 Figure 37: INF_MAX_RT Option Format 4936 option-code OPTION_INF_MAX_RT (83). 4938 option-len 4. 4940 SOL_MAX_RT value Overriding value for INF_MAX_RT in seconds; 4941 MUST be in range: 60 <= "value" <= 86400 (1 4942 day). 4944 A DHCP client MUST include the INF_MAX_RT option code in any Option 4945 Request option (see Section 23.7) it sends. 4947 The DHCP server MAY include the INF_MAX_RT option in any response it 4948 sends to a client that has included the INF_MAX_RT option code in an 4949 Option Request option. The INF_MAX_RT option is sent in the main 4950 body of the message to client, not as an encapsulated option in, 4951 e.g., an IA_NA, IA_TA, or IA_PD option. 4953 A DHCP client MUST ignore any INF_MAX_RT option values that are less 4954 than 60 or more than 86400. 4956 If a DHCP client receives a message containing an INF_MAX_RT option 4957 that has a valid value for INF_MAX_RT, the client MUST set its 4958 internal INF_MAX_RT parameter to the value contained in the 4959 INF_MAX_RT option. This value of INF_MAX_RT is then used by the 4960 retransmission mechanism defined in Section 15 and Section 19.1.5. 4962 Updated INF_MAX_RT value applies only to the network interface on 4963 which the client received INF_MAX_RT option. 4965 24. Security Considerations 4967 The threat to DHCP is inherently an insider threat (assuming a 4968 properly configured network where DHCPv6 ports are blocked on the 4969 perimeter gateways of the enterprise). Regardless of the gateway 4970 configuration, however, the potential attacks by insiders and 4971 outsiders are the same. 4973 Use of manually configured preshared keys for IPsec between relay 4974 agents and servers does not defend against replayed DHCP messages. 4975 Replayed messages can represent a DOS attack through exhaustion of 4976 processing resources, but not through mis-configuration or exhaustion 4977 of other resources such as assignable addresses. 4979 One attack specific to a DHCP client is the establishment of a 4980 malicious server with the intent of providing incorrect configuration 4981 information to the client. The motivation for doing so may be to 4982 mount a "man in the middle" attack that causes the client to 4983 communicate with a malicious server instead of a valid server for 4984 some service such as DNS or NTP. The malicious server may also mount 4985 a denial of service attack through misconfiguration of the client 4986 that causes all network communication from the client to fail. 4988 A malicious DHCP server might cause a client to set its SOL_MAX_RT 4989 and INF_MAX_RT parameters to an unreasonably high value with the 4990 SOL_MAX_RT and INF_MAX_RT options, which may cause an undue delay in 4991 a client completing its DHCP protocol transaction in the case no 4992 other valid response is received. Assuming the client also receives 4993 a response from a valid DHCP server, large values for SOL_MAX_RT and 4994 INF_MAX_RT will not have any effect. 4996 There is another threat to DHCP clients from mistakenly or 4997 accidentally configured DHCP servers that answer DHCP client requests 4998 with unintentionally incorrect configuration parameters. 5000 A DHCP client may also be subject to attack through the receipt of a 5001 Reconfigure message from a malicious server that causes the client to 5002 obtain incorrect configuration information from that server. Note 5003 that although a client sends its response (Renew or Information- 5004 request message) through a relay agent and, therefore, that response 5005 will only be received by servers to which DHCP messages are relayed, 5006 a malicious server could send a Reconfigure message to a client, 5007 followed (after an appropriate delay) by a Reply message that would 5008 be accepted by the client. Thus, a malicious server that is not on 5009 the network path between the client and the server may still be able 5010 to mount a Reconfigure attack on a client. The use of transaction 5011 IDs that are cryptographically sound and cannot easily be predicted 5012 will also reduce the probability that such an attack will be 5013 successful. 5015 The threat specific to a DHCP server is an invalid client 5016 masquerading as a valid client. The motivation for this may be for 5017 theft of service, or to circumvent auditing for any number of 5018 nefarious purposes. 5020 The threat common to both the client and the server is the resource 5021 "denial of service" (DoS) attack. These attacks typically involve 5022 the exhaustion of available addresses, or the exhaustion of CPU or 5023 network bandwidth, and are present anytime there is a shared 5024 resource. 5026 In the case where relay agents add additional options to Relay 5027 Forward messages, the messages exchanged between relay agents and 5028 servers may be used to mount a "man in the middle" or denial of 5029 service attack. 5031 This threat model does not consider the privacy of the contents of 5032 DHCP messages to be important. DHCP is not used to exchange 5033 authentication or configuration information that must be kept secret 5034 from other networks nodes. 5036 DHCP authentication provides for authentication of the identity of 5037 DHCP clients and servers, and for the integrity of messages delivered 5038 between DHCP clients and servers. DHCP authentication does not 5039 provide any privacy for the contents of DHCP messages. 5041 The Delayed Authentication protocol described in Section 22.4 uses a 5042 secret key that is shared between a client and a server. The use of 5043 a "DHCP realm" in the shared key allows identification of 5044 administrative domains so that a client can select the appropriate 5045 key or keys when roaming between administrative domains. However, 5046 the Delayed Authentication protocol does not define any mechanism for 5047 sharing of keys, so a client may require separate keys for each 5048 administrative domain it encounters. The use of shared keys may not 5049 scale well and does not provide for repudiation of compromised keys. 5050 This protocol is focused on solving the intradomain problem where the 5051 out-of-band exchange of a shared key is feasible. 5053 Because of the opportunity for attack through the Reconfigure 5054 message, a DHCP client MUST discard any Reconfigure message that does 5055 not include authentication or that does not pass the validation 5056 process for the authentication protocol. 5058 The Reconfigure Key protocol described in Section 22.5 provides 5059 protection against the use of a Reconfigure message by a malicious 5060 DHCP server to mount a denial of service or man-in-the-middle attack 5061 on a client. This protocol can be compromised by an attacker that 5062 can intercept the initial message in which the DHCP server sends the 5063 key to the client. 5065 Communication between a server and a relay agent, and communication 5066 between relay agents, can be secured through the use of IPsec, as 5067 described in Section 22.1. The use of manual configuration and 5068 installation of static keys are acceptable in this instance because 5069 relay agents and the server will belong to the same administrative 5070 domain and the relay agents will require other specific configuration 5071 (for example, configuration of the DHCP server address) as well as 5072 the IPsec configuration. 5074 A rogue delegating router can issue bogus prefixes to a requesting 5075 router. This may cause denial of service due to unreachability. 5077 A malicious requesting router may be able to mount a denial of 5078 service attack by repeated requests for delegated prefixes that 5079 exhaust the delegating router's available prefixes. 5081 To guard against attacks through prefix delegation, requesting 5082 routers and delegating routers SHOULD use DHCP authentication as 5083 described in Section 22. For point to point links, where one trusts 5084 that there is no man in the middle, or one trusts layer two 5085 authentication, DHCP authentication or IPsec may not be necessary. 5086 Because a requesting router and delegating routers must each have at 5087 least one assigned IPv6 address, the routers may be able to use IPsec 5088 for authentication of DHCPv6 messages. The details of using IPsec 5089 for DHCPv6 are under development. 5091 Networks configured with delegated prefixes should be configured to 5092 preclude intentional or inadvertent inappropriate advertisement of 5093 these prefixes. 5095 25. IANA Considerations 5097 This document defines several new name spaces associated with DHCPv6 5098 and DHCPv6 options: 5100 - Message types 5102 - Status codes 5104 - DUID 5106 - Option codes 5108 IANA has established a registry of values for each of these name 5109 spaces, which are described in the remainder of this section. These 5110 name spaces will be managed by the IANA and all will be managed 5111 separately from the name spaces defined for DHCPv4. 5113 New multicast addresses, message types, status codes, and DUID types 5114 are assigned via Standards Action [RFC5226]. 5116 New DHCP option codes are tentatively assigned after the 5117 specification for the associated option, published as an Internet 5118 Draft, has received expert review by a designated expert [RFC5226]. 5119 The final assignment of DHCP option codes is through Standards 5120 Action, as defined in [RFC5226]. 5122 This document also references three name spaces in Section 22 that 5123 are associated with the Authentication Option (Section 23.11). These 5124 name spaces are defined by the authentication mechanism for DHCPv4 in 5125 [RFC3118]. 5127 The authentication name spaces currently registered by IANA will 5128 apply to both DHCPv6 and DHCPv4. In the future, specifications that 5129 define new Protocol, Algorithm and RDM mechanisms will explicitly 5130 define whether the new mechanisms are used with DHCPv4, DHCPv6 or 5131 both. 5133 25.1. Multicast Addresses 5135 Section 6.1 defines the following multicast addresses, which have 5136 been assigned by IANA for use by DHCPv6: 5138 All_DHCP_Relay_Agents_and_Servers address: FF02::1:2 5140 All_DHCP_Servers address: FF05::1:3 5142 25.2. DHCP Message Types 5144 IANA has recorded the following message types (defined in 5145 Section 6.3). IANA will maintain the registry of DHCP message types. 5147 SOLICIT 1 5149 ADVERTISE 2 5151 REQUEST 3 5153 CONFIRM 4 5155 RENEW 5 5157 REBIND 6 5159 REPLY 7 5160 RELEASE 8 5162 DECLINE 9 5164 RECONFIGURE 10 5166 INFORMATION-REQUEST 11 5168 RELAY-FORW 12 5170 RELAY-REPL 13 5172 25.3. DHCP Options 5174 IANA has recorded the following option-codes (as defined in section 5175 Section 23). IANA will maintain the registry of DHCP option codes. 5177 OPTION_CLIENTID 1 5179 OPTION_SERVERID 2 5181 OPTION_IA_NA 3 5183 OPTION_IA_TA 4 5185 OPTION_IAADDR 5 5187 OPTION_ORO 6 5189 OPTION_PREFERENCE 7 5191 OPTION_ELAPSED_TIME 8 5193 OPTION_RELAY_MSG 9 5195 OPTION_AUTH 11 5197 OPTION_UNICAST 12 5199 OPTION_STATUS_CODE 13 5201 OPTION_RAPID_COMMIT 14 5203 OPTION_USER_CLASS 15 5205 OPTION_VENDOR_CLASS 16 5207 OPTION_VENDOR_OPTS 17 5208 OPTION_INTERFACE_ID 18 5210 OPTION_RECONF_MSG 19 5212 OPTION_RECONF_ACCEPT 20 5214 OPTION_IA_PD 25 5216 OPTION_IAPREFIX 26 5218 OPTION_SOL_MAX_RT 82 5220 OPTION_INF_MAX_RT 83 5222 25.4. Status Codes 5224 IANA has recorded the status codes defined in the following table. 5225 IANA will manage the definition of additional status codes in the 5226 future. 5228 +---------------+------+--------------------------------------------+ 5229 | Name | Code | Description | 5230 +---------------+------+--------------------------------------------+ 5231 | Success | 0 | Success. | 5232 | UnspecFail | 1 | Failure, reason unspecified; this status | 5233 | | | code is sent by either a client or a | 5234 | | | server to indicate a failure not | 5235 | | | explicitly specified in this document. | 5236 | NoAddrsAvail | 2 | Server has no addresses available to | 5237 | | | assign to the IA(s). | 5238 | NoBinding | 3 | Client record (binding) unavailable. | 5239 | NotOnLink | 4 | The prefix for the address is not | 5240 | | | appropriate for the link to which the | 5241 | | | client is attached. | 5242 | UseMulticast | 5 | Sent by a server to a client to force the | 5243 | | | client to send messages to the server | 5244 | | | using the | 5245 | | | All_DHCP_Relay_Agents_and_Servers address. | 5246 | NoPrefixAvail | 6 | Delegating router has no prefixes | 5247 | | | available to assign to the IAPD(s). | 5248 +---------------+------+--------------------------------------------+ 5250 25.5. DUID 5252 IANA has recorded the following DUID types (as defined in 5253 Section 10.1). IANA will manage the definition of additional DUID 5254 types in the future. 5256 DUID-LLT 1 5258 DUID-EN 2 5260 DUID-LL 3 5262 26. Acknowledgments 5264 The following people are authors of the original RFC 3315: Ralph 5265 Droms, Jim Bound, Bernie Volz, Ted Lemon, Charles Perkins, and Mike 5266 Carney. The following people are authors of the original RFC 3633: 5267 Ole Troan and Ralph Droms. This document is merely a refinement of 5268 their work and would not be possible without their original work. 5270 A number of additional people have contributed to identifying issues 5271 with RFC 3315 and RFC 3633 and proposed resolutions to these issues 5272 as reflected in this document (in no particular order): Ole Troan, 5273 Robert Marks, Leaf Yeh, Tim Winters, Michelle Cotton, Pablo Armando, 5274 John Brzozowski, Suresh Krishnan, Hideshi Enokihara, Alexandru 5275 Petrescu, Yukiyo Akisada, Tatuya Jinmei, Fred Templin. With special 5276 thanks to Ralph Droms for answering many questions related to the 5277 original RFC 3315 work. 5279 The following acknowledgements are from the original RFC 3315 and RFC 5280 3633: 5282 Thanks to the DHC Working Group and the members of the IETF for their 5283 time and input into the specification. In particular, thanks also 5284 for the consistent input, ideas, and review by (in alphabetical 5285 order) Bernard Aboba, Bill Arbaugh, Thirumalesh Bhat, Steve Bellovin, 5286 A. K. Vijayabhaskar, Brian Carpenter, Matt Crawford, Steve Deering, 5287 Francis Dupont, Dave Forster, Brian Haberman, Richard Hussong, Tatuya 5288 Jinmei, Kim Kinnear, Fredrik Lindholm, Tony Lindstrom, Josh 5289 Littlefield, Gerald Maguire, Jack McCann, Shin Miyakawa, Thomas 5290 Narten, Erik Nordmark, Jarno Rajahalme, Yakov Rekhter, Pekka Savola, 5291 Mark Stapp, Matt Thomas, Sue Thomson, Tatuya Jinmei, Bernie Volz, 5292 Trevor Warwick, Phil Wells and Toshi Yamasaki. 5294 Thanks to Steve Deering and Bob Hinden, who have consistently taken 5295 the time to discuss the more complex parts of the IPv6 5296 specifications. 5298 And, thanks to Steve Deering for pointing out at IETF 51 in London 5299 that the DHCPv6 specification has the highest revision number of any 5300 Internet Draft. 5302 27. References 5304 27.1. Normative References 5306 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 5307 August 1980. 5309 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 5310 converting network protocol addresses to 48.bit Ethernet 5311 address for transmission on Ethernet hardware", STD 37, 5312 RFC 826, November 1982. 5314 [RFC1035] Mockapetris, P., "Domain names - implementation and 5315 specification", STD 13, RFC 1035, November 1987. 5317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5318 Requirement Levels", BCP 14, RFC 2119, March 1997. 5320 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 5321 2131, March 1997. 5323 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 5324 Extensions", RFC 2132, March 1997. 5326 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 5327 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 5328 RFC 2136, April 1997. 5330 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 5331 (IPv6) Specification", RFC 2460, December 1998. 5333 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 5334 Discovery for IP Version 6 (IPv6)", RFC 2461, December 5335 1998. 5337 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 5338 Networks", RFC 2464, December 1998. 5340 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 5341 Addresses", RFC 2526, March 1999. 5343 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 5344 Messages", RFC 3118, June 2001. 5346 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 5347 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 5348 December 2003. 5350 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 5351 Configuration Option for DHCPv6", RFC 4075, May 2005. 5353 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 5354 Architecture", RFC 4291, February 2006. 5356 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 5357 Internet Protocol", RFC 4301, December 2005. 5359 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 5360 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 5361 September 2007. 5363 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 5364 Address Autoconfiguration", RFC 4862, September 2007. 5366 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 5367 Extensions for Stateless Address Autoconfiguration in 5368 IPv6", RFC 4941, September 2007. 5370 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 5371 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 5372 May 2008. 5374 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 5375 Time Protocol Version 4: Protocol and Algorithms 5376 Specification", RFC 5905, June 2010. 5378 [RFC6221] Miles, D., Ooghe, S., Dec, W., Krishnan, S., and A. 5379 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, May 5380 2011. 5382 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 5383 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 5384 2011. 5386 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 5387 "Default Address Selection for Internet Protocol Version 6 5388 (IPv6)", RFC 6724, September 2012. 5390 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 5391 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 5392 BCP 187, RFC 7227, May 2014. 5394 27.2. Informative References 5396 [IANA-PEN] 5397 IANA, "Private Enterprise Numbers registry 5398 http://www.iana.org/assignments/enterprise-numbers", . 5400 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 5401 April 1992. 5403 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 5404 Hashing for Message Authentication", RFC 2104, February 5405 1997. 5407 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 5408 Autoconfiguration", RFC 2462, December 1998. 5410 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 5411 Stateless Address Autoconfiguration in IPv6", RFC 3041, 5412 January 2001. 5414 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 5415 3162, August 2001. 5417 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 5418 and M. Carney, "Dynamic Host Configuration Protocol for 5419 IPv6 (DHCPv6)", RFC 3315, July 2003. 5421 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 5422 Host Configuration Protocol (DHCP) version 6", RFC 3633, 5423 December 2003. 5425 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 5426 (DHCP) Service for IPv6", RFC 3736, April 2004. 5428 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 5429 Delegation", RFC 3769, June 2004. 5431 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 5432 Requirements for IPv6 Customer Edge Routers", RFC 7084, 5433 November 2013. 5435 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 5436 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 5437 7341, August 2014. 5439 Appendix A. Changes since RFC3315 5441 1. Incorporated RFC3315 errata (ids: 294, 1373, 2928, 1815, 3577, 5442 2509, 295). 5444 2. Partially incorporated RFC3315 errata id 2472 (place other IA 5445 options if NoAddrsAvail is sent in Advertise). 5447 3. Clarified section 21.4.1 of RFC3315 by defining length of "key 5448 ID" field and specifying that 'DHCP realm' is Domain Name 5449 encoded as per section 8 of RFC3315. Ticket #43. 5451 4. Added DUID-UUID and reference to RFC6355. Ticket #54. 5453 5. Specified a minimum length for the DUID in section "9.1. DUID 5454 Contents". Ticket #39. 5456 6. Removed the use of term "sub-options" from section "19.1.1. 5457 Creation and Transmission of Reconfigure Messages". Ticket #40. 5459 7. Added text to section 22.6 "IA Address Option" about the usage 5460 of unspecified address to express the client hints for Preferred 5461 and Valid lifetimes. Ticket #45. 5463 8. Updated text in 21.4.2 of RFC3315 ("Message Validation") as 5464 suggested in section 3.1 of draft-ietf-dhc-dhcpv6-clarify-auth- 5465 01. Ticket #87. 5467 9. Merged RFC7083, "Modification to Default Values of SOL_MAX_RT 5468 and INF_MAX_RT", into this document. Ticket #51. 5470 10. Incorporated RFC3315 errata (id 2471), into section 17.1.3. 5471 Ticket #25. 5473 11. Added text that relay agents MUST NOT modify the relayed message 5474 to section 20.1.2. Ticket #57. 5476 12. Modified the text in section 21.4.4.5, Receiving Reply Messages, 5477 to remove special treatment of a Reply validation failure 5478 (client ignores message). Ticket #89. 5480 13. Appendix C updated: Authentication option is no longer allowed 5481 in Relay-forward and Relay-reply messages, ORO is no longer 5482 allowed in Confirm, Release and Decline messages; Preference 5483 option is no longer allowed in Reply messages (only in 5484 Advertise). Ticket #10. 5486 14. Removed "silently" from several instances of "silently ignores" 5487 or "silently" discards. It is up to software vendor if and how 5488 to log such events (debug log message, event log, message pop-up 5489 etc.). Ticket #50. 5491 15. Clarified that: there should be no more that one instance of 5492 Vendor Class option with a given Enterprise Number; that one 5493 instance of Vendor Class can contain multiple encapsulated 5494 options; the same applies to Vendor Specific Information option. 5495 Ticket #22. 5497 16. Clarified relay agent definition. Ticket #12. 5499 17. Changed REL_MAX_RC and DEC_MAX_RC defaults from 5 to 4 and added 5500 retry to parameter description. Ticket #84. 5502 18. Clarify handling process for Vendor-specific Information Option 5503 and Vendor Class Option. Ticket #20. 5505 19. Replace "monotonic" with "strictly monotonic" in Section 21.3. 5506 Ticket #11. 5508 20. Incorporate everything of RFC 6644, except for Security 5509 Considerations Section, which has already covered in a more 5510 abstracted way. Ticket #55 & #56. 5512 21. Clarify the server behavior process when a client violates 5513 Delayed Authentication Protocol, in Section 21.4. Ticket #90. 5515 22. Updated titles of sections 19.4.2. and 19.4.4. to include Rebind 5516 messages. 5518 23. Applied many of the review comments from a review done by Fred 5519 Templin in August 2006. Ticket #14. 5521 24. Reworded the first paragraph of Section 15 to relax the "SHOULD" 5522 requirement to drop the messages which contain the options not 5523 expected in the current message. Ticket #17. 5525 25. Changed WG to DHC, added keywords 5527 26. Loosened requirements for DUID-EN, so that DUID type can be used 5528 for virtual machines. Ticket #16. 5530 27. Clarified that IA may contain other resources than just address. 5531 Ticket #93. 5533 28. Clarified that most options are singletons (i.e. can appear only 5534 once). Ticket #83. 5536 29. Merged sections 1 (Ticket #96), 2 (Ticket #97), 3 (Ticket #98), 5537 4 (Ticket #99), 6 (Ticket #101), 8 (Ticket #103), 9 (Ticket 5538 #104), 10 (Ticket #105), 11 (Ticket #106), 13 (Ticket #108), 14 5539 (Ticket #109), 15 (Ticket #110), 16 (Ticket #111), 17 (Ticket 5540 #112) and 19 (Ticket #113) from RFC3633 (Prefix Delegation). 5542 30. Clarified that encapsulated options must be requested using top 5543 level ORO (ticket #38). 5545 31. Clarified that configuration for interface X should be requested 5546 over interface X (ticket #48). 5548 32. CONFIRM is now an optional message (MUST send Confirm eased to 5549 SHOULD) (ticket #120). 5551 33. Added reference to RFC7227: DHCPv6 Option Guidelines (ticket 5552 #121). 5554 34. Added new section 5 providing an overview of DHCPv6 operational 5555 modes and removed two prefix delegation sections from section 1. 5556 See tickets #53, #100, and #102. 5558 35. Addressed ticket #115 - don't use DHCPv6 for DHCPv4 5559 configuration. 5561 Appendix B. Changes since RFC3633 5563 1. Incorporated RFC3633 errata (ids: 248, 1880, 2468, 2469, 2470, 5564 3736) 5566 2. ... 5568 Appendix C. Appearance of Options in Message Types 5570 The following table indicates with a "*" the options are allowed in 5571 each DHCP message type: 5573 Client Server IA_NA IA_PD Option Pref Elap. Relay Auth. Server 5574 ID ID IA_TA Request Time Msg. Unicast 5575 Solicit * * * * * * 5576 Advert. * * * * * * 5577 Request * * * * * * * 5578 Confirm * * * * 5579 Renew * * * * * * * 5580 Rebind * * * * * * 5581 Decline * * * * * * 5582 Release * * * * * * 5583 Reply * * * * * * 5584 Reconf. * * * * 5585 Inform. * (see note) * * * 5586 R-forw. * 5587 R-repl. * 5589 NOTE: 5591 Only included in Information-request messages that are sent in 5592 response to a Reconfigure (see Section 20.4.3). 5594 Status Rap. User Vendor Vendor Inter. Recon. Recon. SOL_MAX_RT 5595 Code Comm. Class Class Spec. ID Msg. Accept INF_MAX_RT 5596 Solicit * * * * * 5597 Advert. * * * * * * 5598 Request * * * * 5599 Confirm * * * 5600 Renew * * * * 5601 Rebind * * * * 5602 Decline * * * 5603 Release * * * 5604 Reply * * * * * * * 5605 Reconf. * 5606 Inform. * * * * 5607 R-forw. * * * * 5608 R-repl. * * * * 5610 Appendix D. Appearance of Options in the Options Field of DHCP Options 5612 The following table indicates with a "*" where options can appear in 5613 the options field of other options: 5615 Option IA_NA/ IAADDR Relay Relay 5616 Field IA_TA IA_PD IAPREFIX Forw. Reply 5617 Client ID * 5618 Server ID * 5619 IA_NA/IA_TA * 5620 IAADDR * 5621 IA_PD * 5622 IAPREFIX * 5623 ORO * 5624 Preference * 5625 Elapsed Time * 5626 Relay Message * * 5627 Authentic. * 5628 Server Uni. * 5629 Status Code * * * * 5630 Rapid Comm. * 5631 User Class * 5632 Vendor Class * 5633 Vendor Info. * 5634 Interf. ID * * 5635 Reconf. MSG. * 5636 Reconf. Accept * 5638 Note: "Relay Forw" / "Relay Reply" options appear in the options 5639 field of the message but may only appear in these messages. 5641 Authors' Addresses 5643 Tomek Mrugalski (editor) 5644 Internet Systems Consortium, Inc. 5645 950 Charter Street 5646 Redwood City, CA 94063 5647 USA 5649 Email: tomasz.mrugalski@gmail.com 5651 Marcin Siodelski 5652 Internet Systems Consortium, Inc. 5653 950 Charter St. 5654 Redwood City, CA 94063 5655 USA 5657 Email: msiodelski@gmail.com 5658 Bernie Volz 5659 Cisco Systems, Inc. 5660 1414 Massachusetts Ave 5661 Boxborough, MA 01719 5662 USA 5664 Email: volz@cisco.com 5666 Andrew Yourtchenko 5667 Cisco Systems, Inc. 5668 De Kleetlaan, 7 5669 Diegem B-1831 5670 Belgium 5672 Email: ayourtch@cisco.com 5674 Michael C. Richardson 5675 Sandelman Software Works 5676 470 Dawson Avenue 5677 Ottawa, ON K1Z 5V7 5678 CA 5680 Email: mcr+ietf@sandelman.ca 5681 URI: http://www.sandelman.ca/ 5683 Sheng Jiang 5684 Huawei Technologies Co., Ltd 5685 Q14, Huawei Campus, No.156 Beiqing Road 5686 Hai-Dian District, Beijing, 100095 5687 P.R. China 5689 Email: jiangsheng@huawei.com 5691 Ted Lemon 5692 Nominum, Inc. 5693 950 Charter St. 5694 Redwood City, CA 94043 5695 USA 5697 Email: Ted.Lemon@nominum.com