idnits 2.17.1 draft-ietf-dhc-rfc3315bis-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (June 27, 2016) is 2832 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 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 7083 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 7283 (Obsoleted by RFC 8415) == Outdated reference: A later version (-06) exists of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-02 == Outdated reference: A later version (-09) exists of draft-ietf-dhc-topo-conf-08 -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- 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) -- Obsolete informational reference (is this intentional?): RFC 4242 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 7550 (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 4 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,7083,7550 (if ISC 5 approved) B. Volz 6 Intended status: Standards Track A. Yourtchenko 7 Expires: December 29, 2016 Cisco 8 M. Richardson 9 SSW 10 S. Jiang 11 Huawei 12 T. Lemon 13 Nominum 14 T. Winters 15 UNH-IOL 16 June 27, 2016 18 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis 19 draft-ietf-dhc-rfc3315bis-05 21 Abstract 23 This document describes the Dynamic Host Configuration Protocol for 24 IPv6 (DHCPv6): an extensible mechanism for configuring hosts with 25 network configuration parameters, IP addresses, and prefixes. 26 Parameters can be provided statelessly, or in combination with 27 stateful assignment of one or more IPv6 addresses and/or IPv6 28 prefixes. DHCPv6 can operate either in place of or in addition to 29 stateless address autoconfiguration (SLAAC). 31 This document updates the text from RFC 3315, the original DHCPv6 32 specification, and incorporates the stateless DHCPv6 extensions (RFC 33 3736) and prefix delegation (RFC 3633), clarifying the interactions 34 between these modes of operation (RFC 7550) and providing a mechanism 35 for throttling DHCPv6 clients when DHCPv6 service is not available 36 (RFC 7083). As such, this document obsoletes RFC3315, RFC3633, 37 RFC3736, RFC7083, RFC7550. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on December 29, 2016. 56 Copyright Notice 58 Copyright (c) 2016 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 This document may contain material from IETF Documents or IETF 72 Contributions published or made publicly available before November 73 10, 2008. The person(s) controlling the copyright in some of this 74 material may not have granted the IETF Trust the right to allow 75 modifications of such material outside the IETF Standards Process. 76 Without obtaining an adequate license from the person(s) controlling 77 the copyright in such materials, this document may not be modified 78 outside the IETF Standards Process, and derivative works of it may 79 not be created outside the IETF Standards Process, except to format 80 it for publication as an RFC or to translate it into languages other 81 than English. 83 Table of Contents 85 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 6 86 1.1. Relation to previous DHCPv6 standards . . . . . . . . . . 6 87 1.2. Relation to DHCP in IPv4 . . . . . . . . . . . . . . . . 7 88 1.3. Protocols and Addressing . . . . . . . . . . . . . . . . 7 89 1.4. Client-server Exchanges Involving Two Messages . . . . . 7 90 1.5. Client-server Exchanges Involving Four Messages . . . . . 8 91 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 92 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 9 93 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 94 4.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 10 95 4.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 11 96 5. Operational Models . . . . . . . . . . . . . . . . . . . . . 15 97 5.1. Stateless DHCP . . . . . . . . . . . . . . . . . . . . . 15 98 5.2. DHCP for Non-Temporary Address Assignment . . . . . . . . 15 99 5.3. DHCP for Prefix Delegation . . . . . . . . . . . . . . . 16 100 5.4. DHCP for Customer Edge Routers . . . . . . . . . . . . . 17 101 5.5. DHCP for Temporary Addresses . . . . . . . . . . . . . . 19 102 6. DHCP Constants . . . . . . . . . . . . . . . . . . . . . . . 19 103 6.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 19 104 6.2. UDP Ports . . . . . . . . . . . . . . . . . . . . . . . . 20 105 6.3. DHCP Message Types . . . . . . . . . . . . . . . . . . . 20 106 6.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 22 107 6.5. Transmission and Retransmission Parameters . . . . . . . 22 108 6.6. Representation of time values and "Infinity" as a time 109 value . . . . . . . . . . . . . . . . . . . . . . . . . . 23 110 7. Client/Server Message Formats . . . . . . . . . . . . . . . . 23 111 8. Relay Agent/Server Message Formats . . . . . . . . . . . . . 24 112 8.1. Relay-forward Message . . . . . . . . . . . . . . . . . . 25 113 8.2. Relay-reply Message . . . . . . . . . . . . . . . . . . . 26 114 9. Representation and Use of Domain Names . . . . . . . . . . . 26 115 10. DHCP Unique Identifier (DUID) . . . . . . . . . . . . . . . . 26 116 10.1. DUID Contents . . . . . . . . . . . . . . . . . . . . . 27 117 10.2. DUID Based on Link-layer Address Plus Time, DUID-LLT . . 27 118 10.3. DUID Assigned by Vendor Based on Enterprise Number, 119 DUID-EN . . . . . . . . . . . . . . . . . . . . . . . . 29 120 10.4. DUID Based on Link-layer Address, DUID-LL . . . . . . . 30 121 11. Identity Association . . . . . . . . . . . . . . . . . . . . 31 122 11.1. Identity Associations for Address Assignment . . . . . . 31 123 11.2. Identity Associations for Prefix Delegation . . . . . . 32 124 12. Assignment to an IA . . . . . . . . . . . . . . . . . . . . . 32 125 12.1. Selecting Addresses for Assignment to an IA_NA . . . . . 32 126 12.2. Assignment of Prefixes for IA_PD . . . . . . . . . . . . 33 127 12.3. Assignment of Temporary Addresses . . . . . . . . . . . 33 128 13. Transmission of Messages by a Client . . . . . . . . . . . . 34 129 13.1. Rate Limiting . . . . . . . . . . . . . . . . . . . . . 34 130 13.2. Choosing transmission time when T1 / T2 is 0 . . . . . . 35 131 14. Reliability of Client Initiated Message Exchanges . . . . . . 35 132 15. Message Validation . . . . . . . . . . . . . . . . . . . . . 37 133 15.1. Use of Transaction IDs . . . . . . . . . . . . . . . . . 38 134 15.2. Solicit Message . . . . . . . . . . . . . . . . . . . . 38 135 15.3. Advertise Message . . . . . . . . . . . . . . . . . . . 38 136 15.4. Request Message . . . . . . . . . . . . . . . . . . . . 39 137 15.5. Confirm Message . . . . . . . . . . . . . . . . . . . . 39 138 15.6. Renew Message . . . . . . . . . . . . . . . . . . . . . 39 139 15.7. Rebind Message . . . . . . . . . . . . . . . . . . . . . 39 140 15.8. Decline Messages . . . . . . . . . . . . . . . . . . . . 40 141 15.9. Release Message . . . . . . . . . . . . . . . . . . . . 40 142 15.10. Reply Message . . . . . . . . . . . . . . . . . . . . . 40 143 15.11. Reconfigure Message . . . . . . . . . . . . . . . . . . 41 144 15.12. Information-request Message . . . . . . . . . . . . . . 41 145 15.13. Relay-forward Message . . . . . . . . . . . . . . . . . 41 146 15.14. Relay-reply Message . . . . . . . . . . . . . . . . . . 42 147 16. Client Source Address and Interface Selection . . . . . . . . 42 148 16.1. Address Assignment . . . . . . . . . . . . . . . . . . . 42 149 16.2. Prefix Delegation . . . . . . . . . . . . . . . . . . . 42 150 17. DHCP Configuration Exchanges . . . . . . . . . . . . . . . . 43 151 17.1. Client Behavior . . . . . . . . . . . . . . . . . . . . 44 152 17.1.1. Creation and Transmission of Solicit Messages . . . 45 153 17.1.2. Creation and Transmission of Request Messages . . . 48 154 17.1.3. Creation and Transmission of Confirm Messages . . . 49 155 17.1.4. Creation and Transmission of Renew Messages . . . . 51 156 17.1.5. Creation and Transmission of Rebind Messages . . . . 53 157 17.1.6. Creation and Transmission of Information-request 158 Messages . . . . . . . . . . . . . . . . . . . . . . 54 159 17.1.7. Creation and Transmission of Release Messages . . . 55 160 17.1.8. Creation and Transmission of Decline Messages . . . 56 161 17.1.9. Receipt of Advertise Messages . . . . . . . . . . . 57 162 17.1.10. Receipt of Reply Messages . . . . . . . . . . . . . 58 163 17.1.10.1. Reply for Solicit (with Rapid Commit), Request, 164 Renew or Rebind . . . . . . . . . . . . . . . . 59 165 17.1.10.2. Reply for Release and Decline . . . . . . . . . 62 166 17.1.10.3. Reply for Confirm . . . . . . . . . . . . . . . 62 167 17.1.11. Receipt of Reconfigure Messages . . . . . . . . . . 62 168 17.1.12. Bindings Verification by Requesting Router . . . . . 63 169 17.2. Server Behavior . . . . . . . . . . . . . . . . . . . . 63 170 17.2.1. Receipt of Solicit Messages . . . . . . . . . . . . 64 171 17.2.2. Receipt of Request Messages . . . . . . . . . . . . 65 172 17.2.3. Receipt of Confirm Messages . . . . . . . . . . . . 67 173 17.2.4. Receipt of Renew Messages . . . . . . . . . . . . . 68 174 17.2.5. Receipt of Rebind Messages . . . . . . . . . . . . . 69 175 17.2.6. Receipt of Information-request Messages . . . . . . 71 176 17.2.7. Receipt of Release Messages . . . . . . . . . . . . 72 177 17.2.8. Receipt of Decline Messages . . . . . . . . . . . . 73 178 17.2.9. Creation and Transmission of Advertise Messages . . 74 179 17.2.10. Transmission of Reply Messages . . . . . . . . . . . 75 180 17.2.11. Creation and Transmission of Reconfigure Messages . 76 181 18. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 77 182 18.1. Relaying a Client Message or a Relay-forward Message . . 77 183 18.1.1. Relaying a Message from a Client . . . . . . . . . . 78 184 18.1.2. Relaying a Message from a Relay Agent . . . . . . . 78 185 18.1.3. Relay Agent Behavior with Prefix Delegation . . . . 79 186 18.2. Relaying a Relay-reply Message . . . . . . . . . . . . . 79 187 18.3. Construction of Relay-reply Messages . . . . . . . . . . 79 188 19. Authentication of DHCP Messages . . . . . . . . . . . . . . . 80 189 19.1. Security of Messages Sent Between Servers and Relay 190 Agents . . . . . . . . . . . . . . . . . . . . . . . . . 80 191 19.2. Summary of DHCP Authentication . . . . . . . . . . . . . 82 192 19.3. Replay Detection . . . . . . . . . . . . . . . . . . . . 82 193 19.4. Reconfigure Key Authentication Protocol . . . . . . . . 83 194 19.4.1. Use of the Authentication Option in the Reconfigure 195 Key Authentication Protocol . . . . . . . . . . . . 83 196 19.4.2. Server considerations for Reconfigure Key protocol . 84 197 19.4.3. Client considerations for Reconfigure Key protocol . 85 198 20. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 85 199 20.1. Format of DHCP Options . . . . . . . . . . . . . . . . . 85 200 20.2. Client Identifier Option . . . . . . . . . . . . . . . . 86 201 20.3. Server Identifier Option . . . . . . . . . . . . . . . . 87 202 20.4. Identity Association for Non-temporary Addresses Option 87 203 20.5. Identity Association for Temporary Addresses Option . . 90 204 20.6. IA Address Option . . . . . . . . . . . . . . . . . . . 91 205 20.7. Option Request Option . . . . . . . . . . . . . . . . . 93 206 20.8. Preference Option . . . . . . . . . . . . . . . . . . . 94 207 20.9. Elapsed Time Option . . . . . . . . . . . . . . . . . . 95 208 20.10. Relay Message Option . . . . . . . . . . . . . . . . . . 95 209 20.11. Authentication Option . . . . . . . . . . . . . . . . . 96 210 20.12. Server Unicast Option . . . . . . . . . . . . . . . . . 97 211 20.13. Status Code Option . . . . . . . . . . . . . . . . . . . 98 212 20.14. Rapid Commit Option . . . . . . . . . . . . . . . . . . 100 213 20.15. User Class Option . . . . . . . . . . . . . . . . . . . 101 214 20.16. Vendor Class Option . . . . . . . . . . . . . . . . . . 102 215 20.17. Vendor-specific Information Option . . . . . . . . . . . 104 216 20.18. Interface-Id Option . . . . . . . . . . . . . . . . . . 106 217 20.19. Reconfigure Message Option . . . . . . . . . . . . . . . 107 218 20.20. Reconfigure Accept Option . . . . . . . . . . . . . . . 107 219 20.21. Identity Association for Prefix Delegation Option . . . 108 220 20.22. IA Prefix Option . . . . . . . . . . . . . . . . . . . . 110 221 20.23. SOL_MAX_RT Option . . . . . . . . . . . . . . . . . . . 112 222 20.24. INF_MAX_RT Option . . . . . . . . . . . . . . . . . . . 113 223 20.25. Information Refresh Time Option . . . . . . . . . . . . 114 224 21. Security Considerations . . . . . . . . . . . . . . . . . . . 115 225 22. Privacy Considerations . . . . . . . . . . . . . . . . . . . 117 226 23. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 118 227 24. Obsoleted mechanisms . . . . . . . . . . . . . . . . . . . . 118 228 25. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 119 229 26. References . . . . . . . . . . . . . . . . . . . . . . . . . 120 230 26.1. Normative References . . . . . . . . . . . . . . . . . . 120 231 26.2. Informative References . . . . . . . . . . . . . . . . . 122 232 Appendix A. Changes since RFC3315 . . . . . . . . . . . . . . . 125 233 Appendix B. Changes since RFC3633 . . . . . . . . . . . . . . . 130 234 Appendix C. Appearance of Options in Message Types . . . . . . . 131 235 Appendix D. Appearance of Options in the Options Field of DHCP 236 Options . . . . . . . . . . . . . . . . . . . . . . 131 237 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 132 239 1. Introduction and Overview 241 This document describes DHCP for IPv6 (DHCPv6), a client/server 242 protocol that provides managed configuration of devices. Relay agent 243 functionality is also defined for enabling communication between 244 clients and servers that are not on the same link. 246 DHCPv6 can provide a device with addresses assigned by a DHCPv6 247 server and other configuration information, which are carried in 248 options. DHCPv6 can be extended through the definition of new 249 options to carry configuration information not specified in this 250 document. 252 DHCPv6 is the "stateful address autoconfiguration protocol" and the 253 "stateful autoconfiguration protocol" referred to in "IPv6 Stateless 254 Address Autoconfiguration" [RFC4862]. 256 This document also provides a mechanism for automated delegation of 257 IPv6 prefixes using DHCPv6. Through this mechanism, a delegating 258 router can delegate prefixes to requesting routers. Use of this 259 mechanism is specified as part of the [RFC7084] and by [TR-187]. 261 DHCPv6 can also provide only other configuration options (i.e., no 262 addresses or prefixes). That implies that the server doesn't have to 263 track any state, and thus the mode is called stateless DHCPv6. 264 Mechanisms necessary to support stateless DHCPv6 are much smaller 265 than to support stateful DHCPv6. 267 The remainder of this introduction summarizes relation to the 268 previous DHCPv6 standards Section 1.1, clarifies the stance with 269 regards to DHCPv4 Section 1.2. More detailed description of the 270 message exchange mechanisms and example message flows in Section 1.4 271 and Section 1.5 are intended as illustrations of DHCP operation 272 rather than an exhaustive list of all possible client-server 273 interactions. Section 5 provides an overview of common operational 274 models. Section 17 explains client and server operation in detail. 276 1.1. Relation to previous DHCPv6 standards 278 The initial specification of DHCPv6 was defined in [RFC3315] and a 279 number of follow up extensions published over the years. Several 280 notable extensions were published: prefix delegation [RFC3633], 281 stateless [RFC3736], update to SOL_MAX_RT and INF_MAX_RT option 282 values [RFC7083] and harmonization between addresses and prefixes 283 support [RFC7550]. Understanding a protocol which definition is 284 spread between large number of documents may be cumbersome. 285 Furthermore, a significant operational experience has been gained 286 over the years and certain small elements of the protocol have been 287 reworked. This document provides a unified, corrected and cleaned up 288 definition of the DHCPv6 that also covers all erratas filled against 289 older RFCs. As such, it obsoletes a number of aforementioned RFCs. 290 There is a small number of mechanisms that were obsoleted. They are 291 listed in Section 24. 293 1.2. Relation to DHCP in IPv4 295 The operational models and relevant configuration information for 296 DHCPv4 [RFC2132][RFC2131] and DHCPv6 are sufficiently different that 297 integration between the two services is not included in this 298 document. [RFC3315] suggested that future work might be to extend 299 DHCPv6 to carry IPv4 address and configuration information. However, 300 the current consensus of the IETF is that DHCPv4 should be used 301 rather than DHCPv6 when conveying IPv4 configuration information to 302 nodes. [RFC7341] describes a transport mechanism to carry DHCPv4 303 messages using the DHCPv6 protocol for the dynamic provisioning of 304 IPv4 address and configuration information across IPv6-only networks. 306 1.3. Protocols and Addressing 308 Clients and servers exchange DHCP messages using UDP [RFC0768]. The 309 client uses a link-local address or addresses determined through 310 other mechanisms for transmitting and receiving DHCP messages. 312 A DHCP client sends most messages using a reserved, link-scoped 313 multicast destination address so that the client need not be 314 configured with the address or addresses of DHCP servers. 316 To allow a DHCP client to send a message to a DHCP server that is not 317 attached to the same link, a DHCP relay agent on the client's link 318 will relay messages between the client and server. The operation of 319 the relay agent is transparent to the client and the discussion of 320 message exchanges in the remainder of this section will omit the 321 description of message relaying by relay agents. 323 Once the client has determined the address of a server, it may under 324 some circumstances send messages directly to the server using 325 unicast. 327 1.4. Client-server Exchanges Involving Two Messages 329 When a DHCP client does not need to have a DHCP server assign it IP 330 addresses or delegated prefixes, the client can obtain configuration 331 information such as a list of available DNS servers [RFC3646] or NTP 332 servers [RFC4075] through a single message and reply exchange with a 333 DHCP server. To obtain configuration information the client first 334 sends an Information-request message to the 335 All_DHCP_Relay_Agents_and_Servers multicast address. Servers respond 336 with a Reply message containing the configuration information for the 337 client. 339 This message exchange assumes that the client requires only 340 configuration information and does not require the assignment of any 341 IPv6 addresses or delegated prefixes. 343 When a server has IPv6 addresses and/or delegated prefixes and other 344 configuration information committed to a client, the client and 345 server may be able to complete the exchange using only two messages, 346 instead of four messages as described in the next section. In this 347 case, the client sends a Solicit message to the 348 All_DHCP_Relay_Agents_and_Servers requesting the assignment of 349 addresses and/or delegated prefixes and other configuration 350 information. This message includes an indication that the client is 351 willing to accept an immediate Reply message from the server. The 352 server that is willing to commit the assignment of addresses and/or 353 delegated prefixes to the client immediately responds with a Reply 354 message. The configuration information and the addresses and/or 355 delegated prefixes in the Reply message are then immediately 356 available for use by the client. 358 Each address or delegated prefix assigned to the client has 359 associated preferred and valid lifetimes specified by the server. To 360 request an extension of the lifetimes assigned to an address or 361 delegated prefix, the client sends a Renew message to the server. 362 The server sends a Reply message to the client with the new 363 lifetimes, allowing the client to continue to use the address or 364 delegated prefix without interruption. 366 1.5. Client-server Exchanges Involving Four Messages 368 To request the assignment of one or more IPv6 addresses and/or 369 delegated prefixes, a client first locates a DHCP server and then 370 requests the assignment of addresses and/or delegated prefixes and 371 other configuration information from the server. The client sends a 372 Solicit message to the All_DHCP_Relay_Agents_and_Servers address to 373 find available DHCP servers. Any server that can meet the client's 374 requirements responds with an Advertise message. The client then 375 chooses one of the servers and sends a Request message to the server 376 asking for confirmed assignment of addresses and/or delegated 377 prefixes and other configuration information. The server responds 378 with a Reply message that contains the confirmed addresses, delegated 379 prefixes, and configuration. 381 As described in the previous section, the client sends a Renew 382 message to the server to extend the lifetimes associated with its 383 addresses and/or delegated prefixes, allowing the client to continue 384 to use those addresses and/or delegated prefixes without 385 interruption. 387 2. Requirements 389 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 390 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 391 "OPTIONAL" in this document are to be interpreted as described in 392 [RFC2119]. 394 This document also makes use of internal conceptual variables to 395 describe protocol behavior and external variables that an 396 implementation must allow system administrators to change. The 397 specific variable names, how their values change, and how their 398 settings influence protocol behavior are provided to demonstrate 399 protocol behavior. An implementation is not required to have them in 400 the exact form described here, so long as its external behavior is 401 consistent with that described in this document. 403 3. Background 405 The IPv6 Specification provides the base architecture and design of 406 IPv6. Related work in IPv6 that would best serve an implementer to 407 study includes the IPv6 Specification [RFC2460], the IPv6 Addressing 408 Architecture [RFC4291], IPv6 Stateless Address Autoconfiguration 409 [RFC4862], IPv6 Neighbor Discovery Processing [RFC4861], and Dynamic 410 Updates to DNS [RFC2136]. These specifications enable DHCP to build 411 upon the IPv6 work to provide both robust stateful autoconfiguration 412 and autoregistration of DNS Host Names. 414 The IPv6 Addressing Architecture specification [RFC4291] defines the 415 address scope that can be used in an IPv6 implementation, and the 416 various configuration architecture guidelines for network designers 417 of the IPv6 address space. Two advantages of IPv6 are that support 418 for multicast is required and nodes can create link-local addresses 419 during initialization. The availability of these features means that 420 a client can use its link-local address and a well-known multicast 421 address to discover and communicate with DHCP servers or relay agents 422 on its link. 424 IPv6 Stateless Address Autoconfiguration [RFC4862] specifies 425 procedures by which a node may autoconfigure addresses based on 426 router advertisements [RFC4861], and the use of a valid lifetime to 427 support renumbering of addresses on the Internet. In addition, the 428 protocol interaction by which a node begins stateless or stateful 429 autoconfiguration is specified. DHCP is one vehicle to perform 430 stateful autoconfiguration. Compatibility with stateless address 431 autoconfiguration is a design requirement of DHCP. 433 IPv6 Neighbor Discovery [RFC4861] is the node discovery protocol in 434 IPv6 which replaces and enhances functions of ARP [RFC0826]. To 435 understand IPv6 and stateless address autoconfiguration, it is 436 strongly recommended that implementers understand IPv6 Neighbor 437 Discovery. 439 Dynamic Updates to DNS [RFC2136] is a specification that supports the 440 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 441 the dynamic updates to DNS to integrate addresses and name space to 442 not only support autoconfiguration, but also autoregistration in 443 IPv6. 445 4. Terminology 447 This section defines terminology specific to IPv6 and DHCP used in 448 this document. 450 4.1. IPv6 Terminology 452 IPv6 terminology relevant to this specification from the IPv6 453 Protocol [RFC2460], IPv6 Addressing Architecture [RFC4291], and IPv6 454 Stateless Address Autoconfiguration [RFC4862] is included below. 456 address An IP layer identifier for an interface or 457 a set of interfaces. 459 host Any node that is not a router. 461 IP Internet Protocol Version 6 (IPv6). The 462 terms IPv4 and IPv6 are used only in 463 contexts where it is necessary to avoid 464 ambiguity. 466 interface A node's attachment to a link. 468 link A communication facility or medium over 469 which nodes can communicate at the link 470 layer, i.e., the layer immediately below 471 IP. Examples are Ethernet (simple or 472 bridged); Token Ring; PPP and PPPoE links, 473 X.25, Frame Relay, or ATM networks; and 474 Internet (or higher) layer "tunnels", such 475 as tunnels over IPv4 or IPv6 itself. 477 link-layer identifier A link-layer identifier for an interface. 478 Examples include IEEE 802 addresses for 479 Ethernet or Token Ring network interfaces, 480 and E.164 addresses for ISDN links. 482 link-local address An IPv6 address having a link-only scope, 483 indicated by having the prefix (FE80::/10), 484 that can be used to reach neighboring nodes 485 attached to the same link. Every interface 486 has a link-local address. 488 multicast address An identifier for a set of interfaces 489 (typically belonging to different nodes). 490 A packet sent to a multicast address is 491 delivered to all interfaces identified by 492 that address. 494 neighbor A node attached to the same link. 496 node A device that implements IP. 498 packet An IP header plus payload. 500 prefix The initial bits of an address, or a set of 501 IP addresses that share the same initial 502 bits. 504 prefix length The number of bits in a prefix. 506 router A node that forwards IP packets not 507 explicitly addressed to itself. 509 unicast address An identifier for a single interface. A 510 packet sent to a unicast address is 511 delivered to the interface identified by 512 that address. 514 4.2. DHCP Terminology 516 Terminology specific to DHCP can be found below. 518 appropriate to the link An address is "appropriate to the link" 519 when the address is consistent with the 520 DHCP server's knowledge of the network 521 topology, prefix assignment and address 522 assignment policies. 524 binding A binding (or, client binding) is a group 525 of server data records containing the 526 information the server has about the 527 addresses in an IA or configuration 528 information explicitly assigned to the 529 client. Configuration information that has 530 been returned to a client through a policy 531 - for example, the information returned to 532 all clients on the same link - does not 533 require a binding. A binding containing 534 information about an IA is indexed by the 535 tuple (where IA-type 536 is the type of address in the IA; for 537 example, temporary). A binding containing 538 configuration information for a client is 539 indexed by . 541 configuration parameter An element of the configuration information 542 set on the server and delivered to the 543 client using DHCP. Such parameters may be 544 used to carry information to be used by a 545 node to configure its network subsystem and 546 enable communication on a link or 547 internetwork, for example. 549 delegating router The router that acts as a DHCP server, and 550 is responding to the prefix request. 552 DHCP Dynamic Host Configuration Protocol for 553 IPv6. The terms DHCPv4 and DHCPv6 are used 554 only in contexts where it is necessary to 555 avoid ambiguity. 557 DHCP client (or client) A node that initiates requests on a link to 558 obtain configuration parameters from one or 559 more DHCP servers. Depending on the 560 purpose of the client, it may feature the 561 requesting router functionality, if it 562 supports prefix delegation. 564 DHCP domain A set of links managed by DHCP and operated 565 by a single administrative entity. 567 DHCP realm A name used to identify the DHCP 568 administrative domain from which a DHCP 569 authentication key was selected. 571 DHCP relay agent (or relay agent) A node that acts as an 572 intermediary to deliver DHCP messages 573 between clients and servers. In certain 574 configurations there may be more than one 575 relay agent between clients and servers, so 576 a relay agent may send DHCP messages to 577 another relay agent. 579 DHCP server (or server) A node that responds to requests from 580 clients, and may or may not be on the same 581 link as the client(s). Depending on its 582 capabilities, it may also feature the 583 functionality of delegating router, if it 584 supports prefix delegation. 586 DUID A DHCP Unique IDentifier for a DHCP 587 participant; each DHCP client and server 588 has exactly one DUID. See Section 10 for 589 details of the ways in which a DUID may be 590 constructed. 592 IA Identity Association: A collection of 593 leases assigned to a client. Each IA has 594 an associated IAID. A client may have more 595 than one IA assigned to it; for example, 596 one for each of its interfaces. Each IA 597 holds one type of address; for example, an 598 identity association for temporary 599 addresses (IA_TA) holds temporary addresses 600 (see "identity association for temporary 601 addresses") and identity association for 602 prefix delegation (IA_PD) holds delegated 603 prefixes. Throughout this document, "IA" 604 is used to refer to an identity association 605 without identifying the type of a lease in 606 the IA. At the time of writing this 607 document, there are 3 IA types defined: 608 IA_NA, IA_TA and IA_PD. New IA types may 609 be defined in the future. 611 IAID Identity Association IDentifier: An 612 identifier for an IA, chosen by the client. 613 Each IA has an IAID, which is chosen to be 614 unique among IAIDs for IAs of a specific 615 type, belonging to that client. 617 IA_NA Identity association for Non-temporary 618 Addresses: An IA that carries assigned 619 addresses that are not temporary addresses 620 (see "identity association for temporary 621 addresses") 623 IA_TA Identity Association for Temporary 624 Addresses: An IA that carries temporary 625 addresses (see [RFC4941]). 627 IA_PD Identity Association for Prefix Delegation: 628 A collection of prefixes assigned to the 629 requesting router. Each IA_PD has an 630 associated IAID. A requesting router may 631 have more than one IA_PD assigned to it; 632 for example, one for each of its 633 interfaces. 635 lease It is an address assigned by the DHCP 636 server to the client or a delegated prefix 637 assigned by the delegating router to the 638 requesting router. Leases are carried in 639 the IA Address or IA Prefix options within 640 the IA_NA/IA_TA and IA_PD options 641 respectively. 643 message A unit of data carried as the payload of a 644 UDP datagram, exchanged among DHCP servers, 645 relay agents and clients. 647 Reconfigure key A key supplied to a client by a server used 648 to provide security for Reconfigure 649 messages. 651 requesting router The router that acts as a DHCP client and 652 is requesting prefix(es) to be assigned. 654 singleton option An option that is allowed to appear only 655 once. Most options are singletons. 657 relaying A DHCP relay agent relays DHCP messages 658 between DHCP participants. 660 retransmission Another attempt to send the same DHCP 661 message by a client or server, as a result 662 of not receiving a valid response to the 663 previously sent messages. The 664 retransmitted message is typically modified 665 prior to sending, as required by the DHCP 666 specifications. In particular, the client 667 updates the value of the Elapsed Time 668 option in the retransmitted message. 670 top-level option An option conveyed in a DHCP message 671 directly, i.e. not encapsulated in any 672 other option, as described in Section 9 of 673 [RFC7227]. 675 transaction ID An opaque value used to match responses 676 with replies initiated either by a client 677 or server. 679 5. Operational Models 681 This section describes some of the current most common DHCP 682 operational models. The described models are not mutually exclusive 683 and are sometimes used together. For example, a device may start in 684 stateful mode to obtain an address, and at a later time when an 685 application is started, request additional parameters using stateless 686 mode. 688 This document assumes that the DHCP servers and the client, 689 communicating with the servers via specific interface, belong to a 690 single provisioning domain. 692 5.1. Stateless DHCP 694 Stateless DHCP [RFC3736] is used when DHCP is not used for obtaining 695 a lease, but a node (DHCP client) desires one or more DHCP "other 696 configuration" parameters, such as a list of DNS recursive name 697 servers or DNS domain search lists [RFC3646]. Stateless may be used 698 when a node initially boots or at any time the software on the node 699 requires some missing or expired configuration information that is 700 available via DHCP. 702 This is the simplest and most basic operation for DHCP and requires a 703 client (and a server) to support only two messages - Information- 704 request and Reply. Note that DHCP servers and relay agents typically 705 also need to support the Relay-Forw and Relay-Reply messages to 706 accommodate operation when clients and servers are not on the same 707 link. 709 5.2. DHCP for Non-Temporary Address Assignment 711 This model of operation was the original motivation for DHCP and is 712 the "stateful address autoconfiguration protocol" for IPv6 [RFC2462]. 713 It is appropriate for situations where stateless address 714 autoconfiguration is not desired, because of network policy, 715 additional requirements (such as updating the DNS with forward or 716 reverse resource records), or client specific requirements (i.e., 717 some prefixes are only available to some clients) which are not 718 possible using stateless address autoconfiguration. 720 The model of operation for non-temporary address assignment is as 721 follows. The server is provided with IPv6 prefixes from which it may 722 allocate addresses to clients, as well as any related network 723 topology information as to which prefixes are present on which links. 724 A client requests a non-temporary address to be assigned by the 725 server. The server allocates an address or addresses appropriate for 726 the link on which the client is connected. The server returns the 727 allocated address or addresses to the client. 729 Each address has an associated preferred and valid lifetime, which 730 constitutes an agreement about the length of time over which the 731 client is allowed to use the address. A client can request an 732 extension of the lifetimes on an address and is required to terminate 733 the use of an address if the valid lifetime of the address expires. 735 Typically clients request other configuration parameters, such as the 736 domain server addresses and search lists, when requesting addresses. 738 5.3. DHCP for Prefix Delegation 740 The prefix delegation mechanism, originally described in [RFC3633], 741 is another stateful mode of operation and intended for simple 742 delegation of prefixes from a delegating router (DHCP server) to 743 requesting routers (DHCP clients). It is appropriate for situations 744 in which the delegating router does not have knowledge about the 745 topology of the networks to which the requesting router is attached, 746 and the delegating router does not require other information aside 747 from the identity of the requesting router to choose a prefix for 748 delegation. For example, these options would be used by a service 749 provider to assign a prefix to a Customer Edge Router device acting 750 as a router between the subscriber's internal network and the service 751 provider's core network. 753 The design of this prefix delegation mechanism meets the requirements 754 for prefix delegation in [RFC3769]. 756 The model of operation for prefix delegation is as follows. A 757 delegating router is provided IPv6 prefixes to be delegated to 758 requesting routers. A requesting router requests prefix(es) from the 759 delegating router, as described in Section 17. The delegating router 760 chooses prefix(es) for delegation, and responds with prefix(es) to 761 the requesting router. The requesting router is then responsible for 762 the delegated prefix(es). For example, the requesting router might 763 assign a subnet from a delegated prefix to one of its interfaces, and 764 begin sending router advertisements for the prefix on that link. 766 Each prefix has an associated valid and preferred lifetime, which 767 constitutes an agreement about the length of time over which the 768 requesting router is allowed to use the prefix. A requesting router 769 can request an extension of the lifetimes on a delegated prefix and 770 is required to terminate the use of a delegated prefix if the valid 771 lifetime of the prefix expires. 773 This prefix delegation mechanism is appropriate for use by an ISP to 774 delegate a prefix to a subscriber, where the delegated prefix would 775 possibly be subnetted and assigned to the links within the 776 subscriber's network. [RFC7084] and [RFC7368] describe in detail 777 such use. 779 Figure 1 illustrates a network architecture in which prefix 780 delegation could be used. 782 5.4. DHCP for Customer Edge Routers 784 The DHCP requirements and network architecture for Customer Edge 785 Routers are described in [RFC7084]. This model of operation combines 786 address assignment (see Section 5.2) and prefix delegation (see 787 Section 5.3). In general, this model assumes that a single set of 788 transactions between the client and server will assign or extend the 789 client's non-temporary addresses and delegated prefixes. 791 ______________________ \ 792 / \ \ 793 | ISP core network | \ 794 \__________ ___________/ | 795 | | 796 +-------+-------+ | 797 | Aggregation | | ISP 798 | device | | network 799 | (delegating | | 800 | router) | | 801 +-------+-------+ | 802 | / 803 |DSL to subscriber / 804 |premises / 805 | 806 +------+------+ \ 807 | CPE | \ 808 | (requesting | \ 809 | router) | | 810 +----+---+----+ | 811 | | | Subscriber 812 ---+-------------+-----+ +-----+------ | Network 813 | | | | 814 +----+-----+ +-----+----+ +----+-----+ | 815 |Subscriber| |Subscriber| |Subscriber| / 816 | PC | | PC | | PC | / 817 +----------+ +----------+ +----------+ / 819 Figure 1: Prefix Delegation Network 821 In this example, the delegating router is configured with a set of 822 prefixes to be used for assignment to customers at the time of each 823 customer's first connection to the ISP service. The prefix 824 delegation process begins when the requesting router requests 825 configuration information through DHCP. The DHCP messages from the 826 requesting router are received by the delegating router in the 827 aggregation device. When the delegating router receives the request, 828 it selects an available prefix or prefixes for delegation to the 829 requesting router. The delegating router then returns the prefix or 830 prefixes to the requesting router. 832 The requesting router subnets the delegated prefix and assigns the 833 longer prefixes to links in the subscriber's network. In a typical 834 scenario based on the network shown in Figure 1, the requesting 835 router subnets a single delegated /48 prefix into /64 prefixes and 836 assigns one /64 prefix to each of the links in the subscriber 837 network. 839 The prefix delegation options can be used in conjunction with other 840 DHCP options carrying other configuration information to the 841 requesting router. The requesting router may, in turn, provide DHCP 842 service to hosts attached to the internal network. For example, the 843 requesting router may obtain the addresses of DNS and NTP servers 844 from the ISP delegating router, and then pass that configuration 845 information on to the subscriber hosts through a DHCP server in the 846 requesting router. 848 If the requesting router assigns a delegated prefix to a link to 849 which the router is attached, and begins to send router 850 advertisements for the prefix on the link, the requesting router MUST 851 set the valid lifetime in those advertisements to be no later than 852 the valid lifetime specified in the IA_PD Prefix option. A 853 requesting router MAY use the preferred lifetime specified in the 854 IA_PD Prefix option. 856 5.5. DHCP for Temporary Addresses 858 Temporary addresses were originally introduced to avoid privacy 859 concerns with stateless address autoconfiguration, which based 860 64-bits of the address on the EUI-64 (see [RFC3041] and [RFC4941]). 861 They were added to DHCP to provide complementary support when 862 stateful address assignment is used. 864 Temporary address assignment works mostly like non-temporary address 865 assignment (see Section 5.2), however these addresses are generally 866 intended to be used for a short period of time and not to have their 867 lifetimes extended, though they can be if required. 869 6. DHCP Constants 871 This section describes various program and networking constants used 872 by DHCP. 874 6.1. Multicast Addresses 876 DHCP makes use of the following multicast addresses: 878 All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped 879 multicast address used by a client to communicate 880 with neighboring (i.e., on-link) relay agents and 881 servers. All servers and relay agents are members of 882 this multicast group. 884 All_DHCP_Servers (FF05::1:3) A site-scoped multicast address used by 885 a relay agent to communicate with servers, either 886 because the relay agent wants to send messages to all 887 servers or because it does not know the unicast 888 addresses of the servers. Note that in order for a 889 relay agent to use this address, it must have an 890 address of sufficient scope to be reachable by the 891 servers. All servers within the site are members of 892 this multicast group on the interfaces which are 893 within the site. 895 6.2. UDP Ports 897 Clients listen for DHCP messages on UDP port 546. Servers and relay 898 agents listen for DHCP messages on UDP port 547. 900 6.3. DHCP Message Types 902 DHCP defines the following message types. More detail on these 903 message types can be found in Section 7 and Section 8. Additional 904 message types are defined in [RFC5007], [RFC5460], [RFC6977], 905 [RFC7341], [RFC7563]. Additional message types may be defined in the 906 future. The numeric encoding for each message type is shown in 907 parentheses. 909 SOLICIT (1) A client sends a Solicit message to locate servers. 911 ADVERTISE (2) A server sends an Advertise message to indicate that 912 it is available for DHCP service, in response to a 913 Solicit message received from a client. 915 REQUEST (3) A client sends a Request message to request 916 configuration parameters, including IP addresses, 917 from a specific server. 919 CONFIRM (4) A client sends a Confirm message to any available 920 server to determine whether the addresses it was 921 assigned are still appropriate to the link to which 922 the client is connected. 924 RENEW (5) A client sends a Renew message to the server that 925 originally provided the client's addresses and 926 configuration parameters to extend the lifetimes on 927 the addresses assigned to the client and to update 928 other configuration parameters. 930 REBIND (6) A client sends a Rebind message to any available 931 server to extend the lifetimes on the addresses 932 assigned to the client and to update other 933 configuration parameters; this message is sent after 934 a client receives no response to a Renew message. 936 REPLY (7) A server sends a Reply message containing assigned 937 addresses and configuration parameters in response to 938 a Solicit, Request, Renew, Rebind message received 939 from a client. A server sends a Reply message 940 containing configuration parameters in response to an 941 Information-request message. A server sends a Reply 942 message in response to a Confirm message confirming 943 or denying that the addresses assigned to the client 944 are appropriate to the link to which the client is 945 connected. A server sends a Reply message to 946 acknowledge receipt of a Release or Decline message. 948 RELEASE (8) A client sends a Release message to the server that 949 assigned addresses to the client to indicate that the 950 client will no longer use one or more of the assigned 951 addresses. 953 DECLINE (9) A client sends a Decline message to a server to 954 indicate that the client has determined that one or 955 more addresses assigned by the server are already in 956 use on the link to which the client is connected. 958 RECONFIGURE (10) A server sends a Reconfigure message to a client to 959 inform the client that the server has new or updated 960 configuration parameters, and that the client is to 961 initiate a Renew/Reply or Information-request/Reply 962 transaction with the server in order to receive the 963 updated information. 965 INFORMATION-REQUEST (11) A client sends an Information-request 966 message to a server to request configuration 967 parameters without the assignment of any IP addresses 968 to the client. 970 RELAY-FORW (12) A relay agent sends a Relay-forward message to relay 971 messages to servers, either directly or through 972 another relay agent. The received message, either a 973 client message or a Relay-forward message from 974 another relay agent, is encapsulated in an option in 975 the Relay-forward message. 977 RELAY-REPL (13) A server sends a Relay-reply message to a relay agent 978 containing a message that the relay agent delivers to 979 a client. The Relay-reply message may be relayed by 980 other relay agents for delivery to the destination 981 relay agent. 983 The server encapsulates the client message as an 984 option in the Relay-reply message, which the relay 985 agent extracts and relays to the client. 987 6.4. Status Codes 989 DHCP uses status codes to communicate the success or failure of 990 operations requested in messages from clients and servers, and to 991 provide additional information about the specific cause of the 992 failure of a message. The specific status codes are defined in 993 Section 20.12. 995 If the Status Code option does not appear in a message in which the 996 option could appear, the status of the message is assumed to be 997 Success. 999 6.5. Transmission and Retransmission Parameters 1001 This section presents a table of values used to describe the message 1002 transmission behavior of clients and servers. 1004 +-----------------+-----------+-------------------------------------+ 1005 | Parameter | Default | Description | 1006 +-----------------+-----------+-------------------------------------+ 1007 | SOL_MAX_DELAY | 1 sec | Max delay of first Solicit | 1008 | SOL_TIMEOUT | 1 sec | Initial Solicit timeout | 1009 | SOL_MAX_RT | 3600 secs | Max Solicit timeout value | 1010 | REQ_TIMEOUT | 1 sec | Initial Request timeout | 1011 | REQ_MAX_RT | 30 secs | Max Request timeout value | 1012 | REQ_MAX_RC | 10 | Max Request retry attempts | 1013 | CNF_MAX_DELAY | 1 sec | Max delay of first Confirm | 1014 | CNF_TIMEOUT | 1 sec | Initial Confirm timeout | 1015 | CNF_MAX_RT | 4 secs | Max Confirm timeout | 1016 | CNF_MAX_RD | 10 secs | Max Confirm duration | 1017 | REN_TIMEOUT | 10 secs | Initial Renew timeout | 1018 | REN_MAX_RT | 600 secs | Max Renew timeout value | 1019 | REB_TIMEOUT | 10 secs | Initial Rebind timeout | 1020 | REB_MAX_RT | 600 secs | Max Rebind timeout value | 1021 | INF_MAX_DELAY | 1 sec | Max delay of first Information- | 1022 | | | request | 1023 | INF_TIMEOUT | 1 sec | Initial Information-request timeout | 1024 | INF_MAX_RT | 3600 secs | Max Information-request timeout | 1025 | | | value | 1026 | REL_TIMEOUT | 1 sec | Initial Release timeout | 1027 | REL_MAX_RC | 4 | MAX Release retry attempts | 1028 | DEC_TIMEOUT | 1 sec | Initial Decline timeout | 1029 | DEC_MAX_RC | 4 | Max Decline retry attempts | 1030 | REC_TIMEOUT | 2 secs | Initial Reconfigure timeout | 1031 | REC_MAX_RC | 8 | Max Reconfigure attempts | 1032 | HOP_COUNT_LIMIT | 32 | Max hop count in a Relay-forward | 1033 | | | message | 1034 +-----------------+-----------+-------------------------------------+ 1036 6.6. Representation of time values and "Infinity" as a time value 1038 All time values for lifetimes, T1 and T2 are unsigned integers. The 1039 value 0xffffffff is taken to mean "infinity" when used as a lifetime 1040 (as in [RFC4861]) or a value for T1 or T2. 1042 7. Client/Server Message Formats 1044 All DHCP messages sent between clients and servers share an identical 1045 fixed format header and a variable format area for options. 1047 All values in the message header and in options are in network byte 1048 order. 1050 Options are stored serially in the options field, with no padding 1051 between the options. Options are byte-aligned but are not aligned in 1052 any other way such as on 2 or 4 byte boundaries. 1054 The following diagram illustrates the format of DHCP messages sent 1055 between clients and servers: 1057 0 1 2 3 1058 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 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | msg-type | transaction-id | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | | 1063 . options . 1064 . (variable) . 1065 | | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 Figure 2: Client/Server message format 1070 msg-type Identifies the DHCP message type; the 1071 available message types are listed in 1072 Section 6.3. 1074 transaction-id The transaction ID for this message exchange. 1076 options Options carried in this message; options are 1077 described in Section 20. 1079 8. Relay Agent/Server Message Formats 1081 Relay agents exchange messages with servers to relay messages between 1082 clients and servers that are not connected to the same link. 1084 All values in the message header and in options are in network byte 1085 order. 1087 Options are stored serially in the options field, with no padding 1088 between the options. Options are byte-aligned but are not aligned in 1089 any other way such as on 2 or 4 byte boundaries. 1091 There are two relay agent messages, which share the following format: 1093 0 1 2 3 1094 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 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | msg-type | hop-count | | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1098 | | 1099 | link-address | 1100 | | 1101 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1102 | | | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1104 | | 1105 | peer-address | 1106 | | 1107 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1108 | | | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1110 . . 1111 . options (variable number and length) .... . 1112 | | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 Figure 3: Relay Agent/Server message format 1117 The following sections describe the use of the Relay Agent message 1118 header. 1120 8.1. Relay-forward Message 1122 The following table defines the use of message fields in a Relay- 1123 forward message. 1125 msg-type RELAY-FORW 1127 hop-count Number of relay agents that have relayed this 1128 message. 1130 link-address An address that will be used by the server to 1131 identify the link on which the client is 1132 located. This is typically global, site- 1133 scoped or ULA [RFC4193], but see discussion 1134 in Section 18.1.1. 1136 peer-address The address of the client or relay agent from 1137 which the message to be relayed was received. 1139 options MUST include a "Relay Message option" (see 1140 Section 20.10); MAY include other options 1141 added by the relay agent. 1143 8.2. Relay-reply Message 1145 The following table defines the use of message fields in a Relay- 1146 reply message. 1148 msg-type RELAY-REPL 1150 hop-count Copied from the Relay-forward message 1152 link-address Copied from the Relay-forward message 1154 peer-address Copied from the Relay-forward message 1156 options MUST include a "Relay Message option"; see 1157 Section 20.10; MAY include other options 1159 9. Representation and Use of Domain Names 1161 So that domain names may be encoded uniformly, a domain name or a 1162 list of domain names is encoded using the technique described in 1163 section 3.1 of [RFC1035]. A domain name, or list of domain names, in 1164 DHCP MUST NOT be stored in compressed form, as described in section 1165 4.1.4 of [RFC1035]. 1167 10. DHCP Unique Identifier (DUID) 1169 Each DHCP client and server has a DUID. DHCP servers use DUIDs to 1170 identify clients for the selection of configuration parameters and in 1171 the association of IAs with clients. DHCP clients use DUIDs to 1172 identify a server in messages where a server needs to be identified. 1173 See Section 20.2 and Section 20.3 for the representation of a DUID in 1174 a DHCP message. 1176 Clients and servers MUST treat DUIDs as opaque values and MUST only 1177 compare DUIDs for equality. Clients and servers MUST NOT in any 1178 other way interpret DUIDs. Clients and servers MUST NOT restrict 1179 DUIDs to the types defined in this document, as additional DUID types 1180 may be defined in the future. 1182 The DUID is carried in an option because it may be variable length 1183 and because it is not required in all DHCP messages. The DUID is 1184 designed to be unique across all DHCP clients and servers, and stable 1185 for any specific client or server - that is, the DUID used by a 1186 client or server SHOULD NOT change over time if at all possible; for 1187 example, a device's DUID should not change as a result of a change in 1188 the device's network hardware. The stability of the DUID includes 1189 changes to virtual interfaces, such as logical PPP (over Ethernet) 1190 interfaces that may come and go in Customer Premise Equipment 1191 routers. 1193 The motivation for having more than one type of DUID is that the DUID 1194 must be globally unique, and must also be easy to generate. The sort 1195 of globally-unique identifier that is easy to generate for any given 1196 device can differ quite widely. Also, some devices may not contain 1197 any persistent storage. Retaining a generated DUID in such a device 1198 is not possible, so the DUID scheme must accommodate such devices. 1200 10.1. DUID Contents 1202 A DUID consists of a two-octet type code represented in network byte 1203 order, followed by a variable number of octets that make up the 1204 actual identifier. The length of the DUID (not including the type 1205 code) is at least 1 octet and at most 128 octets. The following 1206 types are currently defined: 1208 +------+------------------------------------------------------+ 1209 | Type | Description | 1210 +------+------------------------------------------------------+ 1211 | 1 | Link-layer address plus time | 1212 | 2 | Vendor-assigned unique ID based on Enterprise Number | 1213 | 3 | Link-layer address | 1214 | 4 | Universally Unique IDentifier (UUID) - see [RFC6355] | 1215 +------+------------------------------------------------------+ 1217 Formats for the variable field of the DUID for the first 3 of the 1218 above types are shown below. The fourth type, DUID-UUID [RFC6355], 1219 can be used in situations where there is a UUID stored in a device's 1220 firmware settings. 1222 10.2. DUID Based on Link-layer Address Plus Time, DUID-LLT 1224 This type of DUID consists of a two octet type field containing the 1225 value 1, a two octet hardware type code, four octets containing a 1226 time value, followed by link-layer address of any one network 1227 interface that is connected to the DHCP device at the time that the 1228 DUID is generated. The time value is the time that the DUID is 1229 generated represented in seconds since midnight (UTC), January 1, 1230 2000, modulo 2^32. The hardware type MUST be a valid hardware type 1231 assigned by the IANA as described in [RFC0826]. Both the time and 1232 the hardware type are stored in network byte order. The link-layer 1233 address is stored in canonical form, as described in [RFC2464]. 1235 The following diagram illustrates the format of a DUID-LLT: 1237 0 1 2 3 1238 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 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | 1 | hardware type (16 bits) | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | time (32 bits) | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 . . 1245 . link-layer address (variable length) . 1246 . . 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 Figure 4: DUID-LLT format 1251 The choice of network interface can be completely arbitrary, as long 1252 as that interface provides a globally unique link-layer address for 1253 the link type, and the same DUID-LLT SHOULD be used in configuring 1254 all network interfaces connected to the device, regardless of which 1255 interface's link-layer address was used to generate the DUID-LLT. 1257 Clients and servers using this type of DUID MUST store the DUID-LLT 1258 in stable storage, and MUST continue to use this DUID-LLT even if the 1259 network interface used to generate the DUID-LLT is removed. Clients 1260 and servers that do not have any stable storage MUST NOT use this 1261 type of DUID. 1263 Clients and servers that use this DUID SHOULD attempt to configure 1264 the time prior to generating the DUID, if that is possible, and MUST 1265 use some sort of time source (for example, a real-time clock) in 1266 generating the DUID, even if that time source could not be configured 1267 prior to generating the DUID. The use of a time source makes it 1268 unlikely that two identical DUID-LLTs will be generated if the 1269 network interface is removed from the client and another client then 1270 uses the same network interface to generate a DUID-LLT. A collision 1271 between two DUID-LLTs is very unlikely even if the clocks have not 1272 been configured prior to generating the DUID. 1274 This method of DUID generation is recommended for all general purpose 1275 computing devices such as desktop computers and laptop computers, and 1276 also for devices such as printers, routers, and so on, that contain 1277 some form of writable non-volatile storage. 1279 Despite our best efforts, it is possible that this algorithm for 1280 generating a DUID could result in a client identifier collision. A 1281 DHCP client that generates a DUID-LLT using this mechanism MUST 1282 provide an administrative interface that replaces the existing DUID 1283 with a newly-generated DUID-LLT. 1285 10.3. DUID Assigned by Vendor Based on Enterprise Number, DUID-EN 1287 This form of DUID is assigned by the vendor to the device. It 1288 consists of the vendor's registered Private Enterprise Number as 1289 maintained by IANA [IANA-PEN] followed by a unique identifier 1290 assigned by the vendor. The following diagram summarizes the 1291 structure of a DUID-EN: 1293 0 1 2 3 1294 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 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | 2 | enterprise-number | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 | enterprise-number (contd) | | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1300 . identifier . 1301 . (variable length) . 1302 . . 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 Figure 5: DUID-EN format 1307 The source of the identifier is left up to the vendor defining it, 1308 but each identifier part of each DUID-EN MUST be unique to the device 1309 that is using it, and MUST be assigned to the device no later than at 1310 the first usage and stored in some form of non-volatile storage. 1311 This typically means being assigned during manufacture process in 1312 case of physical devices or when the image is created or booted for 1313 the first time in case of virtual machines. The generated DUID 1314 SHOULD be recorded in non-erasable storage. The enterprise-number is 1315 the vendor's registered Private Enterprise Number as maintained by 1316 IANA [IANA-PEN]. The enterprise-number is stored as an unsigned 32 1317 bit number. 1319 An example DUID of this type might look like this: 1321 +---+---+---+---+---+---+---+---+ 1322 | 0 | 2 | 0 | 0 | 0 | 9| 12|192| 1323 +---+---+---+---+---+---+---+---+ 1324 |132|211| 3 | 0 | 9 | 18| 1325 +---+---+---+---+---+---+ 1327 Figure 6: DUID-EN example 1329 This example includes the two-octet type of 2, the Enterprise Number 1330 (9), followed by eight octets of identifier data 1331 (0x0CC084D303000912). 1333 10.4. DUID Based on Link-layer Address, DUID-LL 1335 This type of DUID consists of two octets containing the DUID type 3, 1336 a two octet network hardware type code, followed by the link-layer 1337 address of any one network interface that is permanently connected to 1338 the client or server device. For example, a host that has a network 1339 interface implemented in a chip that is unlikely to be removed and 1340 used elsewhere could use a DUID-LL. The hardware type MUST be a 1341 valid hardware type assigned by the IANA, as described in [RFC0826]. 1342 The hardware type is stored in network byte order. The link-layer 1343 address is stored in canonical form, as described in [RFC2464]. The 1344 following diagram illustrates the format of a DUID-LL: 1346 0 1 2 3 1347 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 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | 3 | hardware type (16 bits) | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 . . 1352 . link-layer address (variable length) . 1353 . . 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 Figure 7: DUID-LL format 1358 The choice of network interface can be completely arbitrary, as long 1359 as that interface provides a unique link-layer address and is 1360 permanently attached to the device on which the DUID-LL is being 1361 generated. The same DUID-LL SHOULD be used in configuring all 1362 network interfaces connected to the device, regardless of which 1363 interface's link-layer address was used to generate the DUID. 1365 DUID-LL is recommended for devices that have a permanently-connected 1366 network interface with a link-layer address, and do not have 1367 nonvolatile, writable stable storage. DUID-LL MUST NOT be used by 1368 DHCP clients or servers that cannot tell whether or not a network 1369 interface is permanently attached to the device on which the DHCP 1370 client is running. 1372 11. Identity Association 1374 An "identity-association" (IA) is a construct through which a server 1375 and a client can identify, group, and manage a set of related IPv6 1376 addresses or delegated prefixes. Each IA consists of an IAID and 1377 associated configuration information. 1379 The IAID uniquely identifies the IA and must be chosen to be unique 1380 among the IAIDs for that IA type on the client. The IAID is chosen 1381 by the client. For any given use of an IA by the client, the IAID 1382 for that IA MUST be consistent across restarts of the DHCP client. 1383 The client may maintain consistency either by storing the IAID in 1384 non-volatile storage or by using an algorithm that will consistently 1385 produce the same IAID as long as the configuration of the client has 1386 not changed. There may be no way for a client to maintain 1387 consistency of the IAIDs if it does not have non-volatile storage and 1388 the client's hardware configuration changes. If the client uses only 1389 one IAID, it can use a well-known value, e.g., zero. 1391 If the client wishes to obtain a distinctly new address or prefix and 1392 deprecate the existing one, the client sends a Release message to the 1393 server for the IAs using the original IAID. Then the client creates 1394 a new IAID, to be used in future Request messages to obtain new IAs. 1396 11.1. Identity Associations for Address Assignment 1398 A client must associate at least one distinct IA with each of its 1399 network interfaces for which it is to request the assignment of IPv6 1400 addresses from a DHCP server. The client uses the IAs assigned to an 1401 interface to obtain configuration information from a server for that 1402 interface. Each IA must be associated with exactly one interface. 1404 The configuration information in an IA consists of one or more IPv6 1405 addresses along with the times T1 and T2 for the IA. See 1406 Section 20.4 for the representation of an IA in a DHCP message. 1408 Each address in an IA has a preferred lifetime and a valid lifetime, 1409 as defined in [RFC4862]. The lifetimes are transmitted from the DHCP 1410 server to the client in the IA option. The lifetimes apply to the 1411 use of IPv6 addresses, as described in section 5.5.4 of [RFC4862]. 1413 11.2. Identity Associations for Prefix Delegation 1415 An IA_PD is different from an IA for address assignment, in that it 1416 does not need to be associated with exactly one interface. One IA_PD 1417 can be associated with the requesting router, with a set of 1418 interfaces or with exactly one interface. A requesting router must 1419 create at least one distinct IA_PD. It may associate a distinct 1420 IA_PD with each of its downstream network interfaces and use that 1421 IA_PD to obtain a prefix for that interface from the delegating 1422 router. 1424 The configuration information in an IA_PD consists of one or more 1425 IPv6 prefixes along with the times T1 and T2 for the IA_PD. See 1426 Section 20.21 for the representation of an IA_PD in a DHCP message. 1428 12. Assignment to an IA 1430 12.1. Selecting Addresses for Assignment to an IA_NA 1432 A server selects addresses to be assigned to an IA_NA according to 1433 the address assignment policies determined by the server 1434 administrator and the specific information the server determines 1435 about the client from some combination of the following sources: 1437 - The link to which the client is attached. The server determines 1438 the link as follows: 1440 * If the server receives the message directly from the client and 1441 the source address in the IP datagram in which the message was 1442 received is a link-local address, then the client is on the 1443 same link to which the interface over which the message was 1444 received is attached. 1446 * If the server receives the message from a forwarding relay 1447 agent, then the client is on the same link as the one to which 1448 the interface, identified by the link-address field in the 1449 message from the relay agent, is attached. According to 1450 [RFC6221], the server MUST ignore any link-address field whose 1451 value is zero. The link address field refers to the link- 1452 address field of the Relay-Forward message, and the link- 1453 address fields in any Relay-Forward messages that may be nested 1454 within the Relay-Forward message. 1456 * If the server receives the message directly from the client and 1457 the source address in the IP datagram in which the message was 1458 received is not a link-local address, then the client is on the 1459 link identified by the source address in the IP datagram (note 1460 that this situation can occur only if the server has enabled 1461 the use of unicast message delivery by the client and the 1462 client has sent a message for which unicast delivery is 1463 allowed). 1465 - The DUID supplied by the client. 1467 - Other information in options supplied by the client, e.g. IA 1468 Address options that include the client's requests for specific 1469 addresses. 1471 - Other information in options supplied by the relay agent. 1473 Any address assigned by a server that is based on an EUI-64 1474 identifier MUST include an interface identifier with the "u" 1475 (universal/local) and "g" (individual/group) bits of the interface 1476 identifier set appropriately, as indicated in section 2.5.1 of 1477 [RFC4291]. 1479 A server MUST NOT assign an address that is otherwise reserved for 1480 some other purpose. For example, a server MUST NOT assign reserved 1481 anycast addresses, as defined in [RFC2526], from any subnet. 1483 12.2. Assignment of Prefixes for IA_PD 1485 The mechanism through which the delegating router selects prefix(es) 1486 for delegation is not specified in this document. Examples of ways 1487 in which the server might select prefix(es) for a client include: 1488 static assignment based on subscription to an ISP; dynamic assignment 1489 from a pool of available prefixes; selection based on an external 1490 authority such as a RADIUS server using the Framed-IPv6-Prefix option 1491 as described in [RFC3162]. 1493 12.3. Assignment of Temporary Addresses 1495 A client may request the assignment of temporary addresses (see 1496 [RFC4941] for the definition of temporary addresses). DHCP handling 1497 of address assignment is no different for temporary addresses. 1499 Clients ask for temporary addresses and servers assign them. 1500 Temporary addresses are carried in the Identity Association for 1501 Temporary Addresses (IA_TA) option (see Section 20.5). Each IA_TA 1502 option contains at most one temporary address for each of the 1503 prefixes on the link to which the client is attached. 1505 The lifetime of the assigned temporary address is set in the IA 1506 Address Option (see Section 20.6) with in the IA_TA option. It is 1507 RECOMMENDED to set short lifetimes, typically shorter than 1508 TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME (see Section 5, 1509 [RFC4941]. 1511 The IAID number space for the IA_TA option IAID number space is 1512 separate from the IA_NA option IAID number space. 1514 A DHCP server implementation MAY generate temporary addresses 1515 referring to the algorithm defined in Section 3.2.1, [RFC4941], with 1516 additional condition that the new address is not duplicated with any 1517 assigned addresses. 1519 The server MAY update the DNS for a temporary address, as described 1520 in section 4 of [RFC4941]. 1522 On the clients, by default, temporary addresses are preferred in 1523 source address selection, according to Rule 7, [RFC6724]. However, 1524 this policy is overridable. 1526 One of the most important properties of temporary address is 1527 unlinkability of different actions over time. So, it is NOT 1528 RECOMMENDED for a client to renew expired temporary addresses, though 1529 DHCP provides such possibility (see Section 20.5). 1531 13. Transmission of Messages by a Client 1533 Unless otherwise specified in this document, or in a document that 1534 describes how IPv6 is carried over a specific type of link (for link 1535 types that do not support multicast), a client sends DHCP messages to 1536 the All_DHCP_Relay_Agents_and_Servers. 1538 A client uses multicast to reach all servers or an individual server. 1539 An individual server is indicated by specifying that server's DUID in 1540 a Server Identifier option (see Section 20.3) in the client's message 1541 (all servers will receive this message but only the indicated server 1542 will respond). All servers are indicated by not supplying this 1543 option. 1545 A client may send some messages directly to a server using unicast, 1546 as described in Section 20.12. 1548 13.1. Rate Limiting 1550 In order to avoid prolonged message bursts that may be caused by 1551 possible logic loops, a DHCP client MUST limit the rate of DHCP 1552 messages it transmits. One example is that a client obtains an 1553 address, but does not like the response; it reverts back to Solicit 1554 procedure, discovers the same (sole) server, requests an address and 1555 gets the same address as before (the server still has the lease that 1556 was requested just previously). This loops can repeat infinitely if 1557 there is not a quit/stop mechanism. Therefore, a client must not 1558 initiate transmissions too frequently. 1560 A recommended method for implementing the rate limiting function is a 1561 token bucket, limiting the average rate of transmission to a certain 1562 number in a certain time. This method of bounding burstiness also 1563 guarantees that the long-term transmission rate will not exceed. 1565 TRT Transmission Rate Limit 1567 The Transmission Rate Limit parameter (TRT) SHOULD be configurable. 1568 A possible default could be 20 packets in 20 seconds. 1570 For a device that has multiple interfaces, the limit MUST be enforced 1571 on a per interface basis. 1573 Rate limiting of forwarded DHCP messages and server-side messages are 1574 out of scope of this specification. 1576 13.2. Choosing transmission time when T1 / T2 is 0 1578 In certain cases, T1 and/or T2 time may be set to zero. Currently 1579 there are three such cases: 1. a client received an IA_NA option with 1580 a zero value; 2. a client received an IA_PD option with a zero value; 1581 3. a client received an IA_TA option (which does not contain T1 and 1582 T2 fields and are not generally renewed). Additional cases may 1583 appear in the future. This is an indication that the transmission 1584 times are left at the client's discretion. They are not completely 1585 discretionary, though. 1587 When T1 and/or T2 times are set to zero, the client MUST choose a 1588 time to avoid packet storms. In particular, it MUST NOT transmit 1589 immediately. If the client received multiple IA containers, it 1590 SHOULD pick renew and/or rebind transmission times so all IA 1591 containers are handled in one exchange, if possible. Client MUST 1592 choose the transmission times to not violate rate limiting 1593 restrictions, defined in Section 13.1. 1595 14. Reliability of Client Initiated Message Exchanges 1597 DHCP clients are responsible for reliable delivery of messages in the 1598 client-initiated message exchanges described in Section 17. If a 1599 DHCP client fails to receive an expected response from a server, the 1600 client must retransmit its message. This section describes the 1601 retransmission strategy to be used by clients in client-initiated 1602 message exchanges. 1604 Note that the procedure described in this section is slightly 1605 modified when used with the Solicit message. The modified procedure 1606 is described in Section 17.1.1. 1608 The client begins the message exchange by transmitting a message to 1609 the server. The message exchange terminates when either the client 1610 successfully receives the appropriate response or responses from a 1611 server or servers, or when the message exchange is considered to have 1612 failed according to the retransmission mechanism described below. 1614 The client MUST update an "elapsed-time" value within an Elapsed Time 1615 option (see Section 20.9) in the retransmitted message. In some 1616 cases, the client may also need to modify values in the IA Address or 1617 IA Prefix options, if a valid lifetime for any of the client's leases 1618 expires before retransmission. Thus, whenever this document refers 1619 to a "retransmission" of a client's message, it refers to both 1620 modifying the original message and sending this new message instance 1621 to the server. The retransmitting client MUST NOT resend the 1622 original message to the server, i.e. the client MUST update all 1623 options in the retransmitted message, for which such update is 1624 required by the protocol (e.g. Elapsed Time option). 1626 The client retransmission behavior is controlled and described by the 1627 following variables: 1629 RT Retransmission timeout 1631 IRT Initial retransmission time 1633 MRC Maximum retransmission count 1635 MRT Maximum retransmission time 1637 MRD Maximum retransmission duration 1639 RAND Randomization factor 1641 With each message transmission or retransmission, the client sets RT 1642 according to the rules given below. If RT expires before the message 1643 exchange terminates, the client recomputes RT and retransmits the 1644 message. 1646 Each of the computations of a new RT include a randomization factor 1647 (RAND), which is a random number chosen with a uniform distribution 1648 between -0.1 and +0.1. The randomization factor is included to 1649 minimize synchronization of messages transmitted by DHCP clients. 1651 The algorithm for choosing a random number does not need to be 1652 cryptographically sound. The algorithm SHOULD produce a different 1653 sequence of random numbers from each invocation of the DHCP client. 1655 RT for the first message transmission is based on IRT: 1657 RT = IRT + RAND*IRT 1659 RT for each subsequent message transmission is based on the previous 1660 value of RT: 1662 RT = 2*RTprev + RAND*RTprev 1664 MRT specifies an upper bound on the value of RT (disregarding the 1665 randomization added by the use of RAND). If MRT has a value of 0, 1666 there is no upper limit on the value of RT. Otherwise: 1668 if (RT > MRT) 1669 RT = MRT + RAND*MRT 1671 MRC specifies an upper bound on the number of times a client may 1672 retransmit a message. Unless MRC is zero, the message exchange fails 1673 once the client has transmitted the message MRC times. 1675 MRD specifies an upper bound on the length of time a client may 1676 retransmit a message. Unless MRD is zero, the message exchange fails 1677 once MRD seconds have elapsed since the client first transmitted the 1678 message. 1680 If both MRC and MRD are non-zero, the message exchange fails whenever 1681 either of the conditions specified in the previous two paragraphs are 1682 met. 1684 If both MRC and MRD are zero, the client continues to transmit the 1685 message until it receives a response. 1687 A client is not expected to listen for a response during the entire 1688 period between transmission of Solicit or Information-request 1689 messages. 1691 15. Message Validation 1693 Clients and servers might get messages that contain options not 1694 allowed to appear in the received message. For example, an IA option 1695 is not allowed to appear in an Information-request message. Clients 1696 and servers MAY choose either to extract information from such a 1697 message if the information is of use to the recipient, or to ignore 1698 such message completely and just drop it. 1700 If a server receives a message that contains options it should not 1701 contain (such as an Information-request message with an IA option), 1702 is missing options that it should contain, or is otherwise not valid, 1703 it MAY send a Reply (or Advertise as appropriate) with a Server 1704 Identifier option, a Client Identifier option if one was included in 1705 the message and a Status Code option with status UnSpecFail. 1707 Clients, relay agents and servers MUST NOT discard messages that 1708 contain unknown options (or instances of vendor options with unknown 1709 enterprise-numbers). These should be ignored as if they weren't 1710 present. 1712 A server MUST discard any Solicit, Confirm, Rebind or Information- 1713 request messages it receives with a unicast destination address. 1715 A client or server MUST silently discard any received DHCP messages 1716 with an unknown message type. 1718 15.1. Use of Transaction IDs 1720 The "transaction-id" field holds a value used by clients and servers 1721 to synchronize server responses to client messages. A client SHOULD 1722 generate a random number that cannot easily be guessed or predicted 1723 to use as the transaction ID for each new message it sends. Note 1724 that if a client generates easily predictable transaction 1725 identifiers, it may become more vulnerable to certain kinds of 1726 attacks from off-path intruders. A client MUST leave the transaction 1727 ID unchanged in retransmissions of a message. 1729 15.2. Solicit Message 1731 Clients MUST discard any received Solicit messages. 1733 Servers MUST discard any Solicit messages that do not include a 1734 Client Identifier option or that do include a Server Identifier 1735 option. 1737 15.3. Advertise Message 1739 Clients MUST discard any received Advertise message that meets any of 1740 the following conditions: 1742 - the message does not include a Server Identifier option. 1744 - the message does not include a Client Identifier option. 1746 - the contents of the Client Identifier option does not match the 1747 client's DUID. 1749 - the "transaction-id" field value does not match the value the 1750 client used in its Solicit message. 1752 Servers and relay agents MUST discard any received Advertise 1753 messages. 1755 15.4. Request Message 1757 Clients MUST discard any received Request messages. 1759 Servers MUST discard any received Request message that meets any of 1760 the following conditions: 1762 - the message does not include a Server Identifier option. 1764 - the contents of the Server Identifier option do not match the 1765 server's DUID. 1767 - the message does not include a Client Identifier option. 1769 15.5. Confirm Message 1771 Clients MUST discard any received Confirm messages. 1773 Servers MUST discard any received Confirm messages that do not 1774 include a Client Identifier option or that do include a Server 1775 Identifier option. 1777 15.6. Renew Message 1779 Clients MUST discard any received Renew messages. 1781 Servers MUST discard any received Renew message that meets any of the 1782 following conditions: 1784 - the message does not include a Server Identifier option. 1786 - the contents of the Server Identifier option does not match the 1787 server's identifier. 1789 - the message does not include a Client Identifier option. 1791 15.7. Rebind Message 1793 Clients MUST discard any received Rebind messages. 1795 Servers MUST discard any received Rebind messages that do not include 1796 a Client Identifier option or that do include a Server Identifier 1797 option. 1799 15.8. Decline Messages 1801 Clients MUST discard any received Decline messages. 1803 Servers MUST discard any received Decline message that meets any of 1804 the following conditions: 1806 - the message does not include a Server Identifier option. 1808 - the contents of the Server Identifier option does not match the 1809 server's identifier. 1811 - the message does not include a Client Identifier option. 1813 15.9. Release Message 1815 Clients MUST discard any received Release messages. 1817 Servers MUST discard any received Release message that meets any of 1818 the following conditions: 1820 - the message does not include a Server Identifier option. 1822 - the contents of the Server Identifier option does not match the 1823 server's identifier. 1825 - the message does not include a Client Identifier option. 1827 15.10. Reply Message 1829 Clients MUST discard any received Reply message that meets any of the 1830 following conditions: 1832 - the message does not include a Server Identifier option. 1834 - the "transaction-id" field in the message does not match the value 1835 used in the original message. 1837 If the client included a Client Identifier option in the original 1838 message, the Reply message MUST include a Client Identifier option 1839 and the contents of the Client Identifier option MUST match the DUID 1840 of the client; OR, if the client did not include a Client Identifier 1841 option in the original message, the Reply message MUST NOT include a 1842 Client Identifier option. 1844 Servers and relay agents MUST discard any received Reply messages. 1846 15.11. Reconfigure Message 1848 Servers and relay agents MUST discard any received Reconfigure 1849 messages. 1851 Clients MUST discard any Reconfigure message that meets any of the 1852 following conditions: 1854 - the message was not unicast to the client. 1856 - the message does not include a Server Identifier option. 1858 - the message does not include a Client Identifier option that 1859 contains the client's DUID. 1861 - the message does not contain a Reconfigure Message option. 1863 - the Reconfigure Message option msg-type is not a valid value. 1865 - the message includes any IA options and the msg-type in the 1866 Reconfigure Message option is INFORMATION-REQUEST. 1868 - the message does not include DHCP authentication: 1870 * the message does not contain an authentication option. 1872 * the message does not pass the authentication validation 1873 performed by the client. 1875 15.12. Information-request Message 1877 Clients MUST discard any received Information-request messages. 1879 Servers MUST discard any received Information-request message that 1880 meets any of the following conditions: 1882 - The message includes a Server Identifier option and the DUID in 1883 the option does not match the server's DUID. 1885 - The message includes an IA option. 1887 15.13. Relay-forward Message 1889 Clients MUST discard any received Relay-forward messages. 1891 15.14. Relay-reply Message 1893 Clients and servers MUST discard any received Relay-reply messages. 1895 16. Client Source Address and Interface Selection 1897 Client's behavior is different depending on the purpose of the 1898 configuration. 1900 16.1. Address Assignment 1902 When a client sends a DHCP message to the 1903 All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message 1904 through the interface for which configuration information is being 1905 requested. However, the client MAY send the message through another 1906 interface if the interface is a logical interface without direct link 1907 attachment or the client is certain that two interfaces are attached 1908 to the same link. 1910 When a client sends a DHCP message directly to a server using unicast 1911 (after receiving the Server Unicast option from that server), the 1912 source address in the header of the IPv6 datagram MUST be an address 1913 assigned to the interface for which the client is interested in 1914 obtaining configuration and which is suitable for use by the server 1915 in responding to the client. 1917 16.2. Prefix Delegation 1919 Delegated prefixes are not associated with a particular interface in 1920 the same way as addresses are for address assignment, and mentioned 1921 above. 1923 When a client (acting as requesting router) sends a DHCP message for 1924 the purpose of prefix delegation, it SHOULD be sent on the interface 1925 associated with the upstream router (ISP network). The upstream 1926 interface is typically determined by configuration. This rule 1927 applies even in the case where a separate IA_PD is used for each 1928 downstream interface. 1930 When a requesting router sends a DHCP message directly to a 1931 delegating router using unicast (after receiving the Server Unicast 1932 option from that delegating router), the source address SHOULD be an 1933 address from the upstream interface and which is suitable for use by 1934 the delegating router in responding to the requesting router. 1936 17. DHCP Configuration Exchanges 1938 A client initiates a message exchange with a server or servers to 1939 acquire or update configuration information of interest. 1941 A DHCP client that does not need to have a DHCP server assign it IP 1942 addresses or delegated prefixes, can obtain configuration information 1943 such as a list of available DNS servers [RFC3646] or NTP servers 1944 [RFC4075] through a single message and reply exchange with a DHCP 1945 server. To obtain configuration information the client first sends 1946 an Information-request message (see Section 17.1.6) to the 1947 All_DHCP_Relay_Agents_and_Servers multicast address. Servers respond 1948 with a Reply message containing the configuration information for the 1949 client (see Section 17.2.6). 1951 To request the assignment of one or more IPv6 addresses or delegated 1952 prefixes, a client first locates a DHCP server and then requests the 1953 assignment of addresses and other configuration information from the 1954 server. The client does it by sending the Solicit message (see 1955 Section 17.1.1) to the All_DHCP_Relay_Agents_and_Servers multicast 1956 address and collecting Advertise messages from the servers which 1957 respond to the client's message and selects a server from which it 1958 wants to obtain configuration information. This process is referred 1959 to as server discovery or server solicitation. When the client has 1960 selected the server it sends a Request message to this server as 1961 described in the Section 17.1.2. 1963 A client willing to perform the Solicit-Reply message exchange 1964 described in Section 17.1.1 includes a Rapid Commit option (see 1965 Section 20.14) in its Solicit message. 1967 The client has many reasons to initiate the configuration exchange: 1969 1. as part of the operating system configuration/bootstrap 1970 process, 1972 2. when requested to do so by the application layer (through an 1973 operating system specific API), 1975 3. when required by Stateless Address Autoconfiguration (as 1976 defined in [RFC2462]) 1978 4. or as required to extend the lifetime of address(es) and/or 1979 delegated prefix(es), using Renew and Rebind messages. 1981 A server may initiate a message exchange with a client by sending a 1982 Reconfigure message to cause the client to send a Renew, Rebind or 1983 Information-request message to refresh its configuration information 1984 as soon as the Reconfigure message is received by the client. 1986 The client is responsible for creating IAs and requesting that a 1987 server assign IPv6 addresses and/or delegated prefixes to the IAs. 1988 The client first creates the IAs and assigns IAIDs to them. The 1989 client then transmits a Solicit message containing the IA options 1990 describing the IAs. The client MUST NOT be using any of the 1991 addresses or delegated prefixes for which it tries to obtain the 1992 bindings by sending the Solicit message. In particular, if the 1993 client had some valid bindings and has chosen to start the server 1994 solicitation process to obtain the bindings from a different server, 1995 the client MUST stop using the addresses and delegated prefixes for 1996 the bindings it had obtained from the previous server, and which it 1997 is now trying to obtain from a new server. 1999 If the client will accept a Reply message with committed leases 2000 assignments and other resources in response to the Solicit message, 2001 the client includes a Rapid Commit option (see Section 20.14) in the 2002 Solicit message. 2004 Servers that can assign addresses or delegated prefixes to the IAs 2005 respond to the client with an Advertise message or Reply message if 2006 the client included a Rapid Commit option and the server is 2007 configured to accept it. 2009 If the server responds with an Advertise message, the client 2010 initiates a configuration exchange as described in Section 17.1.2. 2012 Requesting router and delegating router use the IA_PD Prefix option 2013 to exchange information about prefix(es) in much the same way as IA 2014 Address options are used for assigned addresses. Typically, a single 2015 DHCP session is used to exchange information about addresses and 2016 prefixes, i.e. IA_NA and IA_PD options are carried in the same 2017 message. 2019 17.1. Client Behavior 2021 A client uses the Solicit message to discover DHCP servers configured 2022 to assign leases or return other configuration parameters on the link 2023 to which the client is attached. 2025 A client uses Request, Renew, Rebind, Release and Decline messages 2026 during the normal life cycle of addresses and delegated prefixes. 2027 When a client detects it may have moved to a new link, it uses 2028 Confirm if it only has addresses and Rebind if it has delegated 2029 prefixes (and addresses). It uses Information-request messages when 2030 it needs configuration information but no addresses and no prefixes. 2032 When a client requests multiple IA option types in a Solicit, 2033 Request, Renew, or Rebind, it is possible that the available 2034 server(s) may only be configured to offer a subset of them. When 2035 possible, the client SHOULD use the best configuration available and 2036 continue to request the additional IAs in subsequent messages 2037 ([RFC7550]). This allows the client to maintain a single session and 2038 state machine. In practice, especially in the case of handling IA_NA 2039 and IA_PD requests ([RFC7084]), this situation should be rare or a 2040 temporary operational error. Thus, it is more likely for the client 2041 to get all configuration if it continues, in each subsequent 2042 configuration exchange, to request all the configuration information 2043 it is programmed to try to obtain, including any stateful 2044 configuration options for which no results were returned in previous 2045 message exchanges. 2047 Upon receipt of a Reconfigure message from the server, a client 2048 responds with a Renew, Rebind or an Information-request message as 2049 indicated by the Reconfigure Message option. The server sends IAs 2050 and/or other configuration information to the client in a Reply 2051 message. 2053 If the client has a source address of sufficient scope that can be 2054 used by the server as a return address, and the client has received a 2055 Server Unicast option (Section 20.12) from the server, the client 2056 SHOULD unicast any Request, Renew, Release and Decline messages to 2057 the server. 2059 DISCUSSION: 2061 Use of unicast may avoid delays due to the relaying of messages by 2062 relay agents, as well as avoid overhead and duplicate responses by 2063 servers due to the delivery of client messages to multiple 2064 servers. However, requiring the client to relay all DHCP messages 2065 through a relay agent enables the inclusion of relay agent options 2066 in all messages sent by the client. The server should enable the 2067 use of unicast only when relay agent options will not be used. 2069 17.1.1. Creation and Transmission of Solicit Messages 2071 The client sets the "msg-type" field to SOLICIT. The client 2072 generates a transaction ID and inserts this value in the 2073 "transaction-id" field. 2075 The client MUST include a Client Identifier option to identify itself 2076 to the server. The client includes IA options for any IAs to which 2077 it wants the server to assign leases. 2079 The client MUST include an Elapsed Time option (see Section 20.9) to 2080 indicate how long the client has been trying to complete the current 2081 DHCP message exchange. 2083 The client MAY include addresses in the IA_NA and IA_TA options as 2084 hints to the server about the addresses for which the client has a 2085 preference. 2087 The client MAY include values in the IA Prefix option encapsulated 2088 within IA_PD option as hints for the delegated prefix and/or prefix 2089 length for which the client has a preference. 2091 The client MUST NOT include any other options in the Solicit message, 2092 except as specifically allowed in the definition of individual 2093 options. 2095 The client uses IA_NA options to request the assignment of non- 2096 temporary addresses, IA_TA options to request the assignment of 2097 temporary addresses and IA_PD options to request prefix delegation. 2098 Either IA_NA, IA_TA or IA_PD options, or a combination of all, can be 2099 included in DHCP messages. In addition, multiple instances of any IA 2100 option type can be included. 2102 The client MUST include an Option Request option (see Section 20.7) 2103 to request the SOL_MAX_RT option (see Section 20.23) and any other 2104 options the client is interested in receiving. The client MAY 2105 additionally include instances of those options that are identified 2106 in the Option Request option, with data values as hints to the server 2107 about parameter values the client would like to have returned. 2109 The client includes a Reconfigure Accept option (see Section 20.20) 2110 if the client is willing to accept Reconfigure messages from the 2111 server. 2113 The first Solicit message from the client on the interface MUST be 2114 delayed by a random amount of time between 0 and SOL_MAX_DELAY. In 2115 the case of a Solicit message transmitted when DHCP is initiated by 2116 IPv6 Neighbor Discovery, the delay gives the amount of time to wait 2117 after IPv6 Neighbor Discovery causes the client to invoke the 2118 stateful address autoconfiguration protocol (see section 5.5.3 of 2119 [RFC4862]). This random delay desynchronizes clients which start at 2120 the same time (for example, after a power outage). 2122 The client transmits the message according to Section 14, using the 2123 following parameters: 2125 IRT SOL_TIMEOUT 2126 MRT SOL_MAX_RT 2128 MRC 0 2130 MRD 0 2132 A client that wishes to use the Rapid Commit 2-message exchange 2133 includes a Rapid Commit option in its Solicit message. The client 2134 may receive a number of different replies from different servers. 2135 The client will make note of any Advertise messages that it receives. 2136 The client will discard any Reply messages that do not contain the 2137 Rapid Commit option. 2139 Upon receipt of a valid Reply with the Rapid Commit option, the 2140 client processes the message as described in Section 17.1.10 2142 At the end of the first RT period, if no suitable Reply messages are 2143 received, but the client has valid Advertise messages, then the 2144 client processes the Advertise as described in Section 17.1.9. 2146 If the client subsequently receives a valid Reply message that 2147 includes a Rapid Commit option, it either: 2149 - processes the Reply message as described in Section 17.1.10, and 2150 discards any Reply messages received in response to the Request 2151 message, or 2153 - processes any Reply messages received in response to the Request 2154 message and discards the Reply message that includes the Rapid 2155 Commit option. 2157 If the client is waiting for an Advertise message, the mechanism in 2158 Section 14 is modified as follows for use in the transmission of 2159 Solicit messages. The message exchange is not terminated by the 2160 receipt of an Advertise before the first RT has elapsed. Rather, the 2161 client collects Advertise messages until the first RT has elapsed. 2162 Also, the first RT MUST be selected to be strictly greater than IRT 2163 by choosing RAND to be strictly greater than 0. 2165 A client MUST collect Advertise messages for the first RT seconds, 2166 unless it receives an Advertise message with a preference value of 2167 255. The preference value is carried in the Preference option 2168 (Section 20.8). Any Advertise that does not include a Preference 2169 option is considered to have a preference value of 0. If the client 2170 receives an Advertise message that includes a Preference option with 2171 a preference value of 255, the client immediately begins a client- 2172 initiated message exchange (as described in Section 17.1.2) by 2173 sending a Request message to the server from which the Advertise 2174 message was received. If the client receives an Advertise message 2175 that does not include a Preference option with a preference value of 2176 255, the client continues to wait until the first RT elapses. If the 2177 first RT elapses and the client has received an Advertise message, 2178 the client SHOULD continue with a client-initiated message exchange 2179 by sending a Request message. 2181 If the client does not receive any Advertise messages before the 2182 first RT has elapsed, it begins the retransmission mechanism 2183 described in Section 14. The client terminates the retransmission 2184 process as soon as it receives any Advertise message, and the client 2185 acts on the received Advertise message without waiting for any 2186 additional Advertise messages. 2188 A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client 2189 is configured with either MRC or MRD set to a value other than 0, it 2190 MUST stop trying to configure the interface if the message exchange 2191 fails. After the DHCP client stops trying to configure the 2192 interface, it SHOULD restart the reconfiguration process after some 2193 external event, such as user input, system restart, or when the 2194 client is attached to a new link. 2196 17.1.2. Creation and Transmission of Request Messages 2198 The client uses a Request message to populate IAs with leases and 2199 obtain other configuration information. The client includes one or 2200 more IA options in the Request message. The server then returns 2201 leases and other information about the IAs to the client in IA 2202 options in a Reply message. 2204 The client generates a transaction ID and inserts this value in the 2205 "transaction-id" field. 2207 The client places the identifier of the destination server in a 2208 Server Identifier option. 2210 The client MUST include a Client Identifier option to identify itself 2211 to the server. The client adds any other appropriate options, 2212 including one or more IA options. 2214 The client MUST include an Elapsed Time option (see Section 20.9) to 2215 indicate how long the client has been trying to complete the current 2216 DHCP message exchange. 2218 The client MUST include an Option Request option (see Section 20.7) 2219 to request the SOL_MAX_RT option (see Section 20.23) and any other 2220 options the client is interested in receiving. The client MAY 2221 additionally include instances of those options that are identified 2222 in the Option Request option, with data values as hints to the server 2223 about parameter values the client would like to have returned. 2225 The client includes a Reconfigure Accept option (see Section 20.20) 2226 indicating whether or not the client is willing to accept Reconfigure 2227 messages from the server. 2229 The client transmits the message according to Section 14, using the 2230 following parameters: 2232 IRT REQ_TIMEOUT 2234 MRT REQ_MAX_RT 2236 MRC REQ_MAX_RC 2238 MRD 0 2240 If the message exchange fails, the client takes an action based on 2241 the client's local policy. Examples of actions the client might take 2242 include: 2244 - Select another server from a list of servers known to the client; 2245 for example, servers that responded with an Advertise message. 2247 - Initiate the server discovery process described in Section 17. 2249 - Terminate the configuration process and report failure. 2251 17.1.3. Creation and Transmission of Confirm Messages 2253 Whenever a client may have moved to a new link, the prefixes/ 2254 addresses assigned to the interfaces on that link may no longer be 2255 appropriate for the link to which the client is attached. Examples 2256 of times when a client may have moved to a new link include: 2258 o The client reboots (and has no stable storage or persisted DHCP 2259 state). 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 and the 2268 client does not have any delegated prefixes obtained from the DHCP 2269 server from which it has obtained the addresses, the client SHOULD 2270 initiate a Confirm/Reply message exchange. The client includes any 2271 IAs assigned to the interface that may have moved to a new link, 2272 along with the addresses associated with those IAs, in its Confirm 2273 message. Any responding servers will indicate whether those 2274 addresses are appropriate for the link to which the client is 2275 attached with the status in the Reply message it returns to the 2276 client. 2278 If the client has any valid delegated prefixes obtained from the DHCP 2279 server from which it has obtained the addresses, the client initiates 2280 Rebind/Reply exchange as described in Section 17.1.12 instead of 2281 sending the Confirm message. 2283 The client sets the "msg-type" field to CONFIRM. The client 2284 generates a transaction ID and inserts this value in the 2285 "transaction-id" field. 2287 The client MUST include a Client Identifier option to identify itself 2288 to the server. 2290 The client MUST include an Elapsed Time option (see Section 20.9) to 2291 indicate how long the client has been trying to complete the current 2292 DHCP message exchange. 2294 The client includes IA options for all of the IAs assigned to the 2295 interface for which the Confirm message is being sent. The IA 2296 options include all of the addresses the client currently has 2297 associated with those IAs. The client SHOULD set the T1 and T2 2298 fields in any IA_NA options and the preferred-lifetime and valid- 2299 lifetime fields in the IA Address options to 0, as the server will 2300 ignore these fields. 2302 The first Confirm message from the client on the interface MUST be 2303 delayed by a random amount of time between 0 and CNF_MAX_DELAY. The 2304 client transmits the message according to Section 14, using the 2305 following parameters: 2307 IRT CNF_TIMEOUT 2309 MRT CNF_MAX_RT 2311 MRC 0 2313 MRD CNF_MAX_RD 2315 If the client receives no responses before the message transmission 2316 process terminates, as described in Section 14, the client SHOULD 2317 continue to use any IP addresses, using the last known lifetimes for 2318 those addresses, and SHOULD continue to use any other previously 2319 obtained configuration parameters. 2321 17.1.4. Creation and Transmission of Renew Messages 2323 To extend the valid and preferred lifetimes for the leases assigned 2324 to the IAs and obtain new addresses or delegated prefixes for IAs, 2325 the client sends a Renew message to the server from which the leases 2326 were obtained, which includes IA options for the IAs whose lease 2327 lifetimes are to be extended. The client includes IA Address options 2328 within IA_NA and IA_TA options for the addresses assigned to the IAs. 2329 The client includes IA Prefix options within IA_PD options for the 2330 delegated prefixes assigned to the IAs. The server determines new 2331 lifetimes for the leases according to the administrative 2332 configuration of the server. The server may also add leases to the 2333 IAs. The server can remove leases from the IAs by returning IA 2334 Address options (for IA_NA and IA_TA) and IA Prefix options (for 2335 IA_PD) with preferred and valid lifetimes set to 0. 2337 The server controls the time at which the client contacts the server 2338 to extend the lifetimes on assigned leases through the T1 and T2 2339 parameters assigned to an IA. However, as the client Renews/Rebinds 2340 all IAs from the server at the same time, the client MUST select a T1 2341 and T2 time from all IA options, which will guarantee that the client 2342 will send Renew/Rebind messages not later than at the T1/T2 times 2343 associated with any of the client's bindings (earliest T1/T2). 2345 At time T1, the client initiates a Renew/Reply message exchange to 2346 extend the lifetimes on any leases in the IA. 2348 If T1 or T2 had been set to 0 by the server (for an IA_NA or IA_PD) 2349 or there are no T1 or T2 times (for an IA_TA) in a previous Reply, 2350 the client may send a Renew or Rebind message, respectively, at the 2351 client's discretion. The client MUST follow the rules defined in 2352 Section 13.2. 2354 If the client is sending a Renew message in response to a Reconfigure 2355 message from the server, the client copies IA options from the 2356 Reconfigure message into the Renew message. 2358 The client sets the "msg-type" field to RENEW. The client generates 2359 a transaction ID and inserts this value in the "transaction-id" 2360 field. 2362 The client MUST include a Server Identifier option in the Renew 2363 message, identifying the server with which the client most recently 2364 communicated. 2366 The client MUST include a Client Identifier option to identify itself 2367 to the server. The client adds any appropriate options, including 2368 one or more IA options. 2370 The client MUST include an Elapsed Time option (see Section 20.9) to 2371 indicate how long the client has been trying to complete the current 2372 DHCP message exchange. 2374 For IAs to which leases have been assigned, the client includes a 2375 corresponding IA option containing an IA Address option for each 2376 address assigned to the IA and IA Prefix option for each prefix 2377 assigned to the IA. The client MUST NOT include addresses and 2378 prefixes in any IA option that the client did not obtain from the 2379 server or that are no longer valid (that have a valid lifetime of 0). 2381 The client MAY include an IA option for each binding it desires but 2382 has been unable to obtain. In this case, if the client includes the 2383 IA_PD option to request prefix delegation, the client MAY include the 2384 IA Prefix option encapsulated within the IA_PD option, with the IPv6 2385 prefix field set to 0 and the "prefix-length" field set to the 2386 desired length of the prefix to be delegated. The server MAY use 2387 this value as a hint for the prefix length. The client SHOULD NOT 2388 include IA Prefix option with the IPv6 prefix field set to 0 unless 2389 it is supplying a hint for the prefix length. 2391 When the client is responding to a Reconfigure, the client copies the 2392 Option Request option from the Reconfigure message into the Renew 2393 message. Otherwise, the client includes Option Request option (see 2394 Section 20.7) to request the SOL_MAX_RT option (see Section 20.23) 2395 and any other options the client is interested in receiving. The 2396 client MAY include options with data values as hints to the server 2397 about parameter values the client would like to have returned. 2399 The client transmits the message according to Section 14, using the 2400 following parameters: 2402 IRT REN_TIMEOUT 2404 MRT REN_MAX_RT 2406 MRC 0 2408 MRD Remaining time until earliest T2 2410 The message exchange is terminated when earliest time T2 is reached. 2411 If the client is responding to a Reconfigure, the client ignores and 2412 discards the Reconfigure message. In this case, the client continues 2413 to operate as if Reconfigure message was not received, i.e. it uses 2414 T1/T2 times associated with the client's leases to determine when it 2415 should send Renew or Rebind to the server. If the terminated Renew 2416 exchange was not initiated as a result of receiving a Reconfigure 2417 message, the client begins a Rebind message exchange (see 2418 Section 17.1.5) when the earliest time T2 is reached. 2420 17.1.5. Creation and Transmission of Rebind Messages 2422 At time T2 (which will only be reached if the server to which the 2423 Renew message was sent starting at time T1 has not responded), the 2424 client initiates a Rebind/Reply message exchange with any available 2425 server. 2427 The client constructs the Rebind message as described in 2428 Section 17.1.4 with the following differences: 2430 - The client sets the "msg-type" field to REBIND. 2432 - The client does not include the Server Identifier option in the 2433 Rebind message. 2435 The client transmits the message according to Section 14, using the 2436 following parameters: 2438 IRT REB_TIMEOUT 2440 MRT REB_MAX_RT 2442 MRC 0 2444 MRD Remaining time until valid lifetimes of all leases in all 2445 IAs have expired 2447 If all leases for an IA have expired, the client may choose to 2448 include this IA in subsequent Rebind messages to indicate that the 2449 client is interested in assignment of the leases to this IA. 2451 The message exchange is terminated when the valid lifetimes of all 2452 leases across all IAs have expired, at which time the client uses the 2453 Solicit message to locate a new DHCP server and sends a Request for 2454 the expired IAs to the new server. If the terminated Rebind exchange 2455 was initiated as a result of receiving a Reconfigure message, the 2456 client ignores and discards the Reconfigure message. 2458 17.1.6. Creation and Transmission of Information-request Messages 2460 The client uses an Information-request message to obtain 2461 configuration information without having addresses and/or delegated 2462 prefixes assigned to it. 2464 The client sets the "msg-type" field to INFORMATION-REQUEST. The 2465 client generates a transaction ID and inserts this value in the 2466 "transaction-id" field. 2468 The client SHOULD include a Client Identifier option to identify 2469 itself to the server. If the client does not include a Client 2470 Identifier option, the server will not be able to return any client- 2471 specific options to the client, or the server may choose not to 2472 respond to the message at all. 2474 The client MUST include an Elapsed Time option (see Section 20.9) to 2475 indicate how long the client has been trying to complete the current 2476 DHCP message exchange. 2478 The client MUST include an Option Request option (see Section 20.7) 2479 to request the INF_MAX_RT option (see Section 20.24), the Information 2480 Refresh Time option [RFC4242], and any other options the client is 2481 interested in receiving. The client MAY include options with data 2482 values as hints to the server about parameter values the client would 2483 like to have returned. 2485 When responding to a Reconfigure, the client includes a Server 2486 Identifier option with the identifier from the Reconfigure message to 2487 which the client is responding. 2489 The first Information-request message from the client on the 2490 interface MUST be delayed by a random amount of time between 0 and 2491 INF_MAX_DELAY. The client transmits the message according to 2492 Section 14, using the following parameters: 2494 IRT INF_TIMEOUT 2496 MRT INF_MAX_RT 2498 MRC 0 2500 MRD 0 2502 17.1.7. Creation and Transmission of Release Messages 2504 To release one or more leases, a client sends a Release message to 2505 the server. 2507 The client sets the "msg-type" field to RELEASE. The client 2508 generates a transaction ID and places this value in the "transaction- 2509 id" field. 2511 The client places the identifier of the server that allocated the 2512 lease(s) in a Server Identifier option. 2514 The client MUST include a Client Identifier option to identify itself 2515 to the server. 2517 The client MUST include an Elapsed Time option (see Section 20.9) to 2518 indicate how long the client has been trying to complete the current 2519 DHCP message exchange. 2521 The client includes options containing the IAs for the leases it is 2522 releasing in the "options" field. The leases to be released MUST be 2523 included in the IAs. Any leases for the IAs the client wishes to 2524 continue to use MUST NOT be added to the IAs. 2526 The client MUST NOT use any of the addresses it is releasing as the 2527 source address in the Release message or in any subsequently 2528 transmitted message. 2530 Because Release messages may be lost, the client should retransmit 2531 the Release if no Reply is received. However, there are scenarios 2532 where the client may not wish to wait for the normal retransmission 2533 timeout before giving up (e.g., on power down). Implementations 2534 SHOULD retransmit one or more times, but MAY choose to terminate the 2535 retransmission procedure early. 2537 The client transmits the message according to Section 14, using the 2538 following parameters: 2540 IRT REL_TIMEOUT 2542 MRT 0 2544 MRC REL_MAX_RC 2546 MRD 0 2548 The client MUST stop using all of the leases being released before 2549 the client begins the Release message exchange process. For an 2550 address, this means the address MUST have been removed from the 2551 interface. For a delegated prefix, this means the prefix MUST have 2552 been advertised with a Preferred Lifetime and a Valid Lifetime of 2553 zero in a Router Advertisement message as described in Section 5.5.3, 2554 (e) of [RFC4862] - also see L-13 in Section 4.3 of [RFC7084]. 2556 If leases are released but the Reply from a DHCP server is lost, the 2557 client will retransmit the Release message, and the server may 2558 respond with a Reply indicating a status of NoBinding. Therefore, 2559 the client does not treat a Reply message with a status of NoBinding 2560 in a Release message exchange as if it indicates an error. 2562 Note that if the client fails to release the lease, each lease 2563 assigned to the IA will be reclaimed by the server when the valid 2564 lifetime of that lease expires. 2566 17.1.8. Creation and Transmission of Decline Messages 2568 If a client detects that one or more addresses assigned to it by a 2569 server are already in use by another node, the client sends a Decline 2570 message to the server to inform it that the address is suspect. 2572 The Decline message is not used in prefix delegation and thus the 2573 client MUST NOT include IA_PD options in the Decline message. 2575 The client sets the "msg-type" field to DECLINE. The client 2576 generates a transaction ID and places this value in the "transaction- 2577 id" field. 2579 The client places the identifier of the server that allocated the 2580 address(es) in a Server Identifier option. 2582 The client MUST include a Client Identifier option to identify itself 2583 to the server. 2585 The client MUST include an Elapsed Time option (see Section 20.9) to 2586 indicate how long the client has been trying to complete the current 2587 DHCP message exchange. 2589 The client includes options containing the IAs for the addresses it 2590 is declining in the "options" field. The addresses to be declined 2591 MUST be included in the IAs. Any addresses for the IAs the client 2592 wishes to continue to use should not be in added to the IAs. 2594 The client MUST NOT use any of the addresses it is declining as the 2595 source address in the Decline message or in any subsequently 2596 transmitted message. 2598 The client transmits the message according to Section 14, using the 2599 following parameters: 2601 IRT DEC_TIMEOUT 2603 MRT 0 2605 MRC DEC_MAX_RC 2607 MRD 0 2609 If addresses are declined but the Reply from a DHCP server is lost, 2610 the client will retransmit the Decline message, and the server may 2611 respond with a Reply indicating a status of NoBinding. Therefore, 2612 the client does not treat a Reply message with a status of NoBinding 2613 in a Decline message exchange as if it indicates an error. 2615 The client SHOULD NOT send a Release message for other bindings it 2616 may have received just because it sent a Decline message. The client 2617 SHOULD retain the non-conflicting bindings. The client SHOULD treat 2618 the failure to acquire a binding as a result of the conflict, to be 2619 equivalent to not having received the binding, insofar as it behaves 2620 when sending Renew and Rebind messages. 2622 17.1.9. Receipt of Advertise Messages 2624 The client MUST process SOL_MAX_RT and INF_MAX_RT options in an 2625 Advertise message, even if the message contains a Status Code option 2626 indicating a failure, and the Advertise message will be discarded by 2627 the client. 2629 The client MUST ignore any Advertise message that contains no 2630 addresses (IAADDR options encapsulated in IA_NA or IA_TA options) and 2631 no delegated prefixes (IAPREFIX options encapsulated in IA_PD 2632 options) with the exception that the client: 2634 - MUST process an included SOL_MAX_RT option and 2636 - MUST process an included INF_MAX_RT option. 2638 A client can display any associated status message(s) to the user or 2639 activity log. 2641 The client ignoring this Advertise message MUST NOT restart the 2642 Solicit retransmission timer. 2644 Upon receipt of one or more valid Advertise messages, the client 2645 selects one or more Advertise messages based upon the following 2646 criteria. 2648 - Those Advertise messages with the highest server preference value 2649 are preferred over all other Advertise messages. 2651 - Within a group of Advertise messages with the same server 2652 preference value, a client MAY select those servers whose 2653 Advertise messages advertise information of interest to the 2654 client. 2656 - The client MAY choose a less-preferred server if that server has a 2657 better set of advertised parameters, such as the available set of 2658 IAs, as well as the set of other configuration options advertised. 2660 Once a client has selected Advertise message(s), the client will 2661 typically store information about each server, such as server 2662 preference value, addresses advertised, when the advertisement was 2663 received, and so on. 2665 In practice, this means that the client will maintain independent 2666 per-IA state machines per each selected server. 2668 If the client needs to select an alternate server in the case that a 2669 chosen server does not respond, the client chooses the next server 2670 according to the criteria given above. 2672 17.1.10. Receipt of Reply Messages 2674 Upon the receipt of a valid Reply message in response to a Solicit 2675 (with a Rapid Commit option), Request, Confirm, Renew, Rebind, or 2676 Information-request message, the client extracts the top-level Status 2677 Code option if present. 2679 If the client receives a Reply message with a status code of 2680 UnspecFail, the server is indicating that it was unable to process 2681 the client's message due to an unspecified failure condition. If the 2682 client retransmits the original message to the same server to retry 2683 the desired operation, the client MUST limit the rate at which it 2684 retransmits the message and limit the duration of the time during 2685 which it retransmits the message (see Section 13.1). 2687 If the client receives a Reply message with a status code of 2688 UseMulticast, the client records the receipt of the message and sends 2689 subsequent messages to the server through the interface on which the 2690 message was received using multicast. The client resends the 2691 original message using multicast. 2693 Otherwise (no status code or another status code), the client 2694 processes the Reply as described below based on the original message 2695 for which the Reply was received. 2697 The client MAY choose to report any status code or message from the 2698 Status Code option in the Reply message. 2700 17.1.10.1. Reply for Solicit (with Rapid Commit), Request, Renew or 2701 Rebind 2703 If the client receives a NotOnLink status from the server in response 2704 to a Solicit (with a Rapid Commit option) or a Request, the client 2705 can either re-issue the message without specifying any addresses or 2706 restart the DHCP server discovery process (see Section 17). 2708 If the Reply was received in response to a Solicit (with a Rapid 2709 Commit option), Request, Renew, or Rebind message, the client updates 2710 the information it has recorded about IAs from the IA options 2711 contained in the Reply message: 2713 - Record T1 and T2 times, if appropriate for the IA type. 2715 - Add any new leases in the IA option to the IA as recorded by the 2716 client. 2718 - Update lifetimes for any leases in the IA option that the client 2719 already has recorded in the IA. 2721 - Discard any leases from the IA, as recorded by the client, that 2722 have a valid lifetime of 0 in the IA Address or IA Prefix option. 2724 - Leave unchanged any information about leases the client has 2725 recorded in the IA but that were not included in the IA from the 2726 server. 2728 If the client can operate with the addresses and/or prefixes obtained 2729 from the server: 2731 - The client uses the addresses, delegated prefixes, and other 2732 information from any IAs that do not contain a Status Code option 2733 with the NoAddrsAvail or NoPrefixAvail status code. The client 2734 MAY include the IAs for which it received the NoAddrsAvail or 2735 NoPrefixAvail status code, with no addresses or prefixes, in 2736 subsequent Renew and Rebind messages sent to the server, to retry 2737 obtaining the addresses or prefixes for these IAs. 2739 - The client MUST perform duplicate address detection as per 2740 [RFC4862] Section 5.4, which does list some exceptions, on each of 2741 the received addresses in any IAs, on which it has not performed 2742 duplicate address detection during processing of any of the 2743 previous Reply messages from the server. The client performs the 2744 duplicate address detection before using the received addresses 2745 for the traffic. If any of the addresses are found to be in use 2746 on the link, the client sends a Decline message to the server for 2747 those addresses as described in Section 17.1.8. 2749 - For each IAADDR, which does not have any associated reachability 2750 information, in order avoid the problems described in [RFC4943], 2751 hosts MUST NOT assume that any addresses are reachable on-link as 2752 a result of receiving an IA_NA or IA_TA. Addresses obtained from 2753 IA_NA or IA_TA MUST NOT be used to form an implicit prefix with a 2754 length other than 128. 2756 - For each IA_PD the requesting router assigns a subnet from each of 2757 the delegated prefixes to each of the links to which the 2758 associated interfaces are attached, with the following exception: 2759 the requesting router MUST NOT assign any delegated prefixes or 2760 subnets from the delegated prefix(es) to the link through which it 2761 received the DHCP message from the delegating router (see 2762 [RFC6603] for exceptions). 2764 When a requesting router subnets a delegated prefix, it must 2765 assign additional bits to the prefix to generate unique, longer 2766 prefixes. For example, if the requesting router in Figure 1 were 2767 delegated 2001:db8:0::/48, it might generate 2001:db8:0:1::/64 and 2768 2001:db8:0:2::/64 for assignment to the two links in the 2769 subscriber network. If the requesting router were delegated 2770 2001:db8:0::/48 and 2001:db8:5::/48, it might assign 2771 2001:db8:0:1::/64 and 2001:db8:5:1::/64 to one of the links, and 2772 2001:db8:0:2::/64 and 2001:db8:5:2::/64 for assignment to the 2773 other link. 2775 If the requesting router assigns a delegated prefix to a link to 2776 which the router is attached, and begins to send router 2777 advertisements for the prefix on the link, the requesting router 2778 MUST set the valid lifetime in those advertisements to be no later 2779 than the valid lifetime specified in the IA_PD Prefix option. A 2780 requesting router MAY use the preferred lifetime specified in the 2781 IA_PD Prefix option. 2783 Management of the specific configuration information is detailed in 2784 the definition of each option in Section 20. 2786 When a client had received a configuration option in earlier Reply, 2787 then sent Renew, Rebind or Information-Request and that requested 2788 option does not appear in in the Reply any more, it MUST stop using 2789 the received configuration information. In other words, client 2790 should behave as if it never received this option at all and return 2791 to whatever default state regarding that configuration information 2792 was. If there is no viable way to stop using the information, the 2793 values received/configured from the option MAY persist if there are 2794 no other sources for that data and they have no external impact. For 2795 example, a client that previously received Client FQDN option and 2796 used it to set up its hostname is allowed to continue using it if 2797 there is no reasonable way for a host to unset its hostname and it 2798 has no external impact. As a counter example, a client that used to 2799 receive an NTP server address from the DHCP server and does not 2800 receive it any more, MUST stop using the configured NTP server IPv6 2801 address. The client SHOULD be open to other sources of the same 2802 configuration information. This behavior does not apply to any IA 2803 containers, as their processing is described in detail in other parts 2804 of this document. 2806 If the Reply message contains any IAs, but the client finds no usable 2807 addresses and/or delegated prefixes in any of these IAs, the client 2808 may either try another server (perhaps restarting the DHCP server 2809 discovery process) or use the Information-request message to obtain 2810 other configuration information only. 2812 When the client receives a Reply message in response to a Renew or 2813 Rebind message, the client: 2815 - Sends a Request message if any of the IAs in the Reply message 2816 contains the NoBinding status code. The client places IA options 2817 in this message for only those IAs for which the server returned 2818 the NoBinding status code in the Reply message. The client 2819 continues to use other bindings for which the server did not 2820 return an error. 2822 - Sends a Renew/Rebind if any of the IAs are not in the Reply 2823 message, but in this case the client MUST limit the rate at which 2824 it sends these messages, to avoid the Renew/Rebind storm. 2826 - Otherwise accepts the information in the IA. 2828 Whenever a client restarts the DHCP server discovery process or 2829 selects an alternate server, as described in Section 17.1.9, the 2830 client SHOULD stop using all the addresses and delegated prefixes for 2831 which it has bindings and try to obtain all required leases from the 2832 new server. This facilitates the client using a single state machine 2833 for all bindings. 2835 17.1.10.2. Reply for Release and Decline 2837 When the client receives a valid Reply message in response to a 2838 Release message, the client considers the Release event completed, 2839 regardless of the Status Code option(s) returned by the server. 2841 When the client receives a valid Reply message in response to a 2842 Decline message, the client considers the Decline event completed, 2843 regardless of the Status Code option(s) returned by the server. 2845 17.1.10.3. Reply for Confirm 2847 When the client receives a NotOnLink status from the server in 2848 response to a Confirm message, the client performs DHCP server 2849 solicitation, as described in Section 17, and client-initiated 2850 configuration, as described in Section 17. If the client receives 2851 any Reply messages that indicate a success status (explicit or 2852 implicit), the client can use the addresses in the IA and ignore any 2853 messages that indicate a NotOnLink status. 2855 17.1.11. Receipt of Reconfigure Messages 2857 A client receives Reconfigure messages sent to the UDP port 546 on 2858 interfaces for which it has acquired configuration information 2859 through DHCP. These messages may be sent at any time. Since the 2860 results of a reconfiguration event may affect application layer 2861 programs, the client SHOULD log these events, and MAY notify these 2862 programs of the change through an implementation-specific interface. 2864 Upon receipt of a valid Reconfigure message, the client responds with 2865 either a Renew message, a Rebind message, or an Information-request 2866 message as indicated by the Reconfigure Message option (as defined in 2867 Section 20.19). The client ignores the transaction-id field in the 2868 received Reconfigure message. While the transaction is in progress, 2869 the client discards any Reconfigure messages it receives. 2871 DISCUSSION: 2873 The Reconfigure message acts as a trigger that signals the client 2874 to complete a successful message exchange. Once the client has 2875 received a Reconfigure, the client proceeds with the message 2876 exchange (retransmitting the Renew or Information-request message 2877 if necessary); the client ignores any additional Reconfigure 2878 messages until the exchange is complete. Subsequent Reconfigure 2879 messages cause the client to initiate a new exchange. 2881 How does this mechanism work in the face of duplicated or 2882 retransmitted Reconfigure messages? Duplicate messages will be 2883 ignored because the client will begin the exchange after the 2884 receipt of the first Reconfigure. Retransmitted messages will 2885 either trigger the exchange (if the first Reconfigure was not 2886 received by the client) or will be ignored. The server can 2887 discontinue retransmission of Reconfigure messages to the client 2888 once the server receives the Renew, Rebind or Information-request 2889 message from the client. 2891 It might be possible for a duplicate or retransmitted Reconfigure 2892 to be sufficiently delayed (and delivered out of order) to arrive 2893 at the client after the exchange (initiated by the original 2894 Reconfigure) has been completed. In this case, the client would 2895 initiate a redundant exchange. The likelihood of delayed and out 2896 of order delivery is small enough to be ignored. The consequence 2897 of the redundant exchange is inefficiency rather than incorrect 2898 operation. 2900 17.1.12. Bindings Verification by Requesting Router 2902 In some circumstances the requesting router may need verification 2903 that the delegating router still has a valid binding for the 2904 requesting router. Examples of times when a requesting router may 2905 ask for such verification include: 2907 o The requesting router reboots. 2909 o The requesting router's upstream link flaps. 2911 o The requesting router is physically disconnected from a wired 2912 connection. 2914 If such verification is needed the requesting router MUST initiate a 2915 Rebind/Reply message exchange as described in Section 17.1.5, with 2916 the exception that the retransmission parameters should be set as for 2917 the Confirm message, described in Section 17.1.3. The requesting 2918 router includes any IA_PDs, along with prefixes associated with those 2919 IA_PDs in its Rebind message. 2921 17.2. Server Behavior 2923 For this discussion, the Server is assumed to have been configured in 2924 an implementation specific manner with configuration of interest to 2925 clients. 2927 A server sends Advertise message in response to valid Solicit 2928 messages it receives to announce the availability of the server to 2929 the client. 2931 In most instances, the server will send a Reply in response to a 2932 Request, Confirm, Renew, Rebind, Decline and Information-request 2933 messages sent by a client. The server will also send a Reply in 2934 response to a Solicit with a Rapid Commit option, when the server is 2935 configured to respond with committed lease assignments. 2937 This Reply message MUST always contain the Server Identifier option 2938 containing the server's DUID and the Client Identifier option from 2939 the client message if one was present. 2941 In most reply messages, the server includes options containing 2942 configuration information for the client. The server must be aware 2943 of the recommendations on packet sizes and the use of fragmentation 2944 in section 5 of [RFC2460]. If the client included an Option Request 2945 option in its message, the server includes options in the reply 2946 message containing configuration parameters for all of the options 2947 identified in the Option Request option that the server has been 2948 configured to return to the client. The server MAY return additional 2949 options to the client if it has been configured to do so. 2951 The server MAY initiate a configuration exchange, by sending 2952 Reconfigure messages, to cause DHCP clients to obtain new addresses, 2953 prefixes and other configuration information. For example, an 2954 administrator may use a server-initiated configuration exchange when 2955 links in the DHCP domain are to be renumbered. Other examples 2956 include changes in the location of directory servers, addition of new 2957 services such as printing, and availability of new software. 2959 When a client receives a Reconfigure message from the server, the 2960 client sends Renew, Rebind or Information-request message as 2961 indicated by the as indicated by the Reconfigure Message option (as 2962 defined in Section 20.19). The server sends IAs and/or other 2963 configuration information to the client in a Reply message. The 2964 server MAY include options containing the IAs and new values for 2965 other configuration parameters in the Reply message, even if those 2966 IAs and parameters were not requested in the client's message. 2968 17.2.1. Receipt of Solicit Messages 2970 The server determines the information about the client and its 2971 location as described in Section 12 and checks its administrative 2972 policy about responding to the client. If the server is not 2973 permitted to respond to the client, the server discards the Solicit 2974 message. For example, if the administrative policy for the server is 2975 that it may only respond to a client that is willing to accept a 2976 Reconfigure message, if the client does not include a Reconfigure 2977 Accept option (see Section 20.20) in the Solicit message, the servers 2978 discard the Solicit message. 2980 If the server is permitted to respond to the client, the client has 2981 not included a Rapid Commit option in the Solicit message or the 2982 server has not been configured to respond with committed assignment 2983 of leases and other resources, the server sends an Advertise message 2984 to the client as described in Section 17.2.9. 2986 If the client has included a Rapid Commit option in the Solicit 2987 message and the server has been configured to respond with committed 2988 assignments of leases and other resources, the server responds to the 2989 Solicit with a Reply message. The server MUST commit the assignment 2990 of any addresses and delegated prefixes or other configuration 2991 information before sending a Reply message to a client. In this case 2992 the server includes a Rapid Commit option in the Reply message to 2993 indicate that the Reply is in response to a Solicit message. 2995 DISCUSSION: 2997 When using the Solicit-Reply message exchange, the server commits 2998 the assignment of any leases before sending the Reply message. 2999 The client can assume it has been assigned the leases in the Reply 3000 message and does not need to send a Request message for those 3001 addresses. 3003 Typically, servers that are configured to use the Solicit-Reply 3004 message exchange will be deployed so that only one server will 3005 respond to a Solicit message. If more than one server responds, 3006 the client will only use the leases from one of the servers, while 3007 the leases from the other servers will be committed to the client 3008 but not used by the client. 3010 The server includes a Reconfigure Accept option if the server is 3011 configured to use reconfigure mechanism (see Section 17.2.11). 3012 Sending this option back to the client may useful using server 3013 selection process. 3015 The server produces the Reply message as though it had received a 3016 Request message, as described in Section 17.2.2. The server 3017 transmits the Reply message as described in Section 17.2.10. 3019 17.2.2. Receipt of Request Messages 3021 When the server receives a Request message via unicast from a client 3022 to which the server has not sent a unicast option (or is not 3023 currently configured to send a unicast option to the client), the 3024 server discards the Request message and responds with a Reply message 3025 containing a Status Code option with the value UseMulticast, a Server 3026 Identifier option containing the server's DUID, the Client Identifier 3027 option from the client message, and no other options. 3029 When the server receives a valid Request message, the server creates 3030 the bindings for that client according to the server's policy and 3031 configuration information and records the IAs and other information 3032 requested by the client. 3034 The server constructs a Reply message by setting the "msg-type" field 3035 to REPLY, and copying the transaction ID from the Request message 3036 into the transaction-id field. 3038 The server MUST include a Server Identifier option containing the 3039 server's DUID and the Client Identifier option from the Request 3040 message in the Reply message. 3042 The server examines all IAs in the message from the client. 3044 For each IA_NA and IA_TA in the Request message the server checks if 3045 the prefixes on included IP addresses are appropriate for the link to 3046 which the client is connected. If any of the prefixes on the 3047 included IP addresses is not appropriate for the link to which the 3048 client is connected, the server MUST return the IA to the client with 3049 a Status Code option with the value NotOnLink. If the server does 3050 not send the NotOnLink status code but it cannot assign any IP 3051 addresses to an IA, the server MUST return the IA in the Reply 3052 message with no addresses in the IA and a Status Code option 3053 containing status code NoAddrsAvail. 3055 For any IA_PD in the Request message, to which the server cannot 3056 assign any delegated prefixes, the server MUST return the IA_PD 3057 option in the Reply message with the Status Code option containing 3058 status code NoPrefixAvail. 3060 The server MAY assign different addresses and/or delegated prefixes 3061 to an IA than included in the IA within the Request message sent by 3062 the client. 3064 For all IAs to which the server can assign addresses or delegated 3065 prefixes, the server includes the IAs with addresses (for IA_NA and 3066 IA_TA), prefixes (for IA_PD) and other configuration parameters, and 3067 records the IA as a new client binding. The server MUST NOT include 3068 any addresses or delegated prefixes in the IA which the server does 3069 not assign to the client. 3071 The T1/T2 times set in each applicable IA option for a Reply MUST be 3072 the same values across all IAs. The server MUST determine the T1/T2 3073 times across all of the applicable client's bindings in the Reply. 3074 This facilitates the client being able to renew all of the bindings 3075 at the same time. 3077 The server MAY include a Reconfigure Accept option. New server 3078 implementations are discouraged from sending Reconfigure Accept 3079 option, as it does not convey any additional information. If the 3080 reconfigure mechanism is supported, the server is supposed to send 3081 Authentication option with Reconfigure Key (see Section 19.4 for 3082 details). However, it is still allowed to send Reconfigure Accept 3083 option to maintain backward compatibility with servers that implement 3084 [RFC3315]. 3086 The server includes other options containing configuration 3087 information to be returned to the client as described in 3088 Section 17.2. 3090 If the server finds that the client has included an IA in the Request 3091 message for which the server already has a binding that associates 3092 the IA with the client, the server sends a new Reply message with 3093 existing bindings, possibly with updated lifetimes. The server may 3094 update the bindings according to its local policies, but the server 3095 SHOULD generate the response again and not simply retransmit 3096 previously sent information, even if the transaction-id matches 3097 previous transmission. The server MUST NOT cache its responses. 3099 17.2.3. Receipt of Confirm Messages 3101 When the server receives a Confirm message, the server determines 3102 whether the addresses in the Confirm message are appropriate for the 3103 link to which the client is attached. If all of the addresses in the 3104 Confirm message pass this test, the server returns a status of 3105 Success. If any of the addresses do not pass this test, the server 3106 returns a status of NotOnLink. If the server is unable to perform 3107 this test (for example, the server does not have information about 3108 prefixes on the link to which the client is connected), or there were 3109 no addresses in any of the IAs sent by the client, the server MUST 3110 NOT send a Reply to the client. 3112 The server ignores the T1 and T2 fields in the IA options and the 3113 preferred-lifetime and valid-lifetime fields in the IA Address 3114 options. 3116 The server constructs a Reply message by setting the "msg-type" field 3117 to REPLY, and copying the transaction ID from the Confirm message 3118 into the transaction-id field. 3120 The server MUST include a Server Identifier option containing the 3121 server's DUID and the Client Identifier option from the Confirm 3122 message in the Reply message. The server includes a Status Code 3123 option indicating the status of the Confirm message. 3125 17.2.4. Receipt of Renew Messages 3127 When the server receives a Renew message via unicast from a client to 3128 which the server has not sent a unicast option (or is not currently 3129 configured to send a unicast option to the client), the server 3130 discards the Renew message and responds with a Reply message 3131 containing a Status Code option with the value UseMulticast, a Server 3132 Identifier option containing the server's DUID, the Client Identifier 3133 option from the client message, and no other options. 3135 For each IA in the Renew message from a client, the server locates 3136 the client's binding and verifies that the information in the IA from 3137 the client matches the information stored for that client. 3139 If the server finds the client entry for the IA, the server sends 3140 back the IA to the client with new lifetimes and, if applicable, T1/ 3141 T2 times. If the server is unable to extend the lifetimes of an 3142 address or delegated prefix in the IA, the server MAY choose not to 3143 include the IA Address or IA Prefix option for this address or 3144 delegated prefix. If the server chooses to include the IA Address or 3145 IA Prefix option for such an address or delegated prefix, the server 3146 SHOULD set T1 and T2 to the valid lifetime for the IA option unless 3147 the server also includes other addresses or delegated prefix which 3148 the server is able to extend. 3150 The server may choose to change the list of addresses or delegated 3151 prefixes and the lifetimes in IAs that are returned to the client. 3153 If the server finds that any of the addresses in the IA are not 3154 appropriate for the link to which the client is attached, the server 3155 returns the address to the client with lifetimes of 0. 3157 If the server finds that any of the delegated prefixes in the IA are 3158 not appropriate for the link to which the client is attached, the 3159 server returns the delegated prefix to the client with lifetimes of 3160 0. 3162 For each IA for which the server cannot find a client entry, the 3163 server has the following choices depending on the server's policy and 3164 configuration information: 3166 - If the server is configured to create new bindings as a result of 3167 processing Renew messages, the server SHOULD create a binding and 3168 return the IA with assigned addresses or delegated prefixes with 3169 lifetimes and, if applicable, T1/T2 times and other information 3170 requested by the client. If the client included the IA Prefix 3171 option within the IA_PD option with zero value in the "IPv6 3172 prefix" field and non-zero value in the "prefix-length" field, the 3173 server MAY use the "prefix-length" value as a hint for the length 3174 of the prefixes to be assigned (see 3175 [I-D.ietf-dhc-dhcpv6-prefix-length-hint-issue] for further details 3176 on prefix length hints). 3178 - If the server is configured to create new bindings as a result of 3179 processing Renew messages, but the server will not assign any 3180 leases to an IA, the server returns the IA option containing a 3181 Status Code option with the NoAddrsAvail or NoPrefixAvail status 3182 code and a status message for a user. 3184 - If the server does not support creation of new bindings for the 3185 client sending a Renew message, or if this behavior is disabled 3186 according to the server's policy or configuration information, the 3187 server returns the IA option containing a Status Code option with 3188 the NoBinding status code and a status message for a user. 3190 The server constructs a Reply message by setting the "msg-type" field 3191 to REPLY and copying the transaction ID from the Renew message into 3192 the "transaction-id" field. 3194 The server MUST include a Server Identifier option containing the 3195 server's DUID and the Client Identifier option from the Renew message 3196 in the Reply message. 3198 The server includes other options containing configuration 3199 information to be returned to the client as described in 3200 Section 17.2. 3202 The server MAY include options containing the IAs and values for 3203 other configuration parameters, even if those parameters were not 3204 requested in the Renew message. 3206 The T1/T2 times set in each applicable IA option for a Reply MUST be 3207 the same values across all IAs. The server MUST determine the T1/T2 3208 times across all of the applicable client's bindings in the Reply. 3209 This facilitates the client being able to renew all of the bindings 3210 at the same time. 3212 17.2.5. Receipt of Rebind Messages 3214 When the server receives a Rebind message that contains an IA option 3215 from a client, it locates the client's binding and verifies that the 3216 information in the IA from the client matches the information stored 3217 for that client. 3219 If the server finds the client entry for the IA and the server 3220 determines that the addresses or delegated prefixes in the IA are 3221 appropriate for the link to which the client's interface is attached 3222 according to the server's explicit configuration information, the 3223 server SHOULD send back the IA to the client with new lifetimes and, 3224 if applicable, T1/T2 times. If the server is unable to extend the 3225 lifetimes of an address in the IA, the server MAY choose not to 3226 include the IA Address option for this address. If the server is 3227 unable to extend the lifetimes of a delegated prefix in the IA, the 3228 server MAY choose not to include the IA Prefix option for this 3229 prefix. 3231 If the server finds that the client entry for the IA and any of the 3232 addresses or delegated prefixes are no longer appropriate for the 3233 link to which the client's interface is attached according to the 3234 server's explicit configuration information, the server returns the 3235 address or delegated prefix to the client with lifetimes of 0. 3237 If the server cannot find a client entry for the IA, the server 3238 checks if the IA contains addresses (for IA_NA and IA_TA) or 3239 delegated prefixes (for IA_PD). The server checks if the addresses 3240 and delegated prefixes are appropriate for the link to which the 3241 client's interface is attached according to the server's explicit 3242 configuration information. For any address which is not appropriate 3243 for the link to which the client's interface is attached, the server 3244 MAY include the IA Address option with the lifetimes of 0. For any 3245 delegated prefix which is not appropriate for the link to which the 3246 client's interface is attached, the server MAY include the IA Prefix 3247 option with the lifetimes of 0. The Reply with lifetimes of 0 3248 constitutes an explicit notification to the client that the specific 3249 addresses and delegated prefixes are no longer valid and MUST NOT be 3250 used by the client. If the server chooses to not include any IAs 3251 containing IA Address or IA Prefix options with lifetimes of 0 and 3252 the server does not include any other IAs with leases and/or status 3253 codes, the server does not send a Reply message. In this situation 3254 the server silently discards the Rebind message. 3256 Otherwise, for each IA for which the server cannot find a client 3257 entry, the server has the following choices depending on the server's 3258 policy and configuration information: 3260 - If the server is configured to create new bindings as a result of 3261 processing Rebind messages (also see the note about the Rapid 3262 Commit option below), the server SHOULD create a binding and 3263 return the IA with allocated leases with lifetimes and, if 3264 applicable, T1/T2 times and other information requested by the 3265 client. The server MUST NOT return any addresses or delegated 3266 prefixes in the IA which the server does not assign to the client. 3268 - If the server is configured to create new bindings as a result of 3269 processing Rebind messages, but the server will not assign any 3270 leases to an IA, the server returns the IA option containing a 3271 Status Code option with the NoAddrsAvail or NoPrefixAvail status 3272 code and a status message for a user. 3274 - If the server does not support creation of new bindings for the 3275 client sending a Rebind message, or if this behavior is disabled 3276 according to the server's policy or configuration information, the 3277 server returns the IA option containing a Status Code option with 3278 the NoBinding status code and a status message for a user. 3280 When the server creates new bindings for the IA, it is possible that 3281 other servers also create bindings as a result of receiving the same 3282 Rebind message. This is the same issue as in the Discussion under 3283 "Rapid Commit Option"; see Section 20.14. Therefore, the server 3284 SHOULD only create new bindings during processing of a Rebind message 3285 if the server is configured to respond with a Reply message to a 3286 Solicit message containing the Rapid Commit option. 3288 The server constructs a Reply message by setting the "msg-type" field 3289 to REPLY and copying the transaction ID from the Rebind message into 3290 the "transaction-id" field. 3292 The server MUST include a Server Identifier option containing the 3293 server's DUID and the Client Identifier option from the Rebind 3294 message in the Reply message. 3296 The server includes other options containing configuration 3297 information to be returned to the client as described in 3298 Section 17.2. 3300 The server MAY include options containing the IAs and values for 3301 other configuration parameters, even if those IAs and parameters were 3302 not requested in the Rebind message. 3304 The T1/T2 times set in each applicable IA option for a Reply MUST be 3305 the same values across all IAs. The server MUST determine the T1/T2 3306 times across all of the applicable client's bindings in the Reply. 3307 This facilitates the client being able to renew all of the bindings 3308 at the same time. 3310 17.2.6. Receipt of Information-request Messages 3312 When the server receives an Information-request message, the client 3313 is requesting configuration information that does not include the 3314 assignment of any leases. The server determines all configuration 3315 parameters appropriate to the client, based on the server 3316 configuration policies known to the server. 3318 The server constructs a Reply message by setting the "msg-type" field 3319 to REPLY, and copying the transaction ID from the Information-request 3320 message into the transaction-id field. 3322 The server MUST include a Server Identifier option containing the 3323 server's DUID in the Reply message. If the client included a Client 3324 Identification option in the Information-request message, the server 3325 copies that option to the Reply message. 3327 The server includes options containing configuration information to 3328 be returned to the client as described in Section 17.2. The server 3329 MAY include additional options that were not requested by the client 3330 in the Information-request message. 3332 If the Information-request message received from the client did not 3333 include a Client Identifier option, the server SHOULD respond with a 3334 Reply message containing any configuration parameters that are not 3335 determined by the client's identity. If the server chooses not to 3336 respond, the client may continue to retransmit the Information- 3337 request message indefinitely. 3339 17.2.7. Receipt of Release Messages 3341 The server constructs a Reply message by setting the "msg-type" field 3342 to REPLY, and copying the transaction ID from the Release message 3343 into the transaction-id field. 3345 When the server receives a Release message via unicast from a client 3346 to which the server has not sent a unicast option (or is not 3347 currently configured to send a unicast option to the client), the 3348 server discards the Release message and responds with a Reply message 3349 containing a Status Code option with value UseMulticast, a Server 3350 Identifier option containing the server's DUID, the Client Identifier 3351 option from the client message, and no other options. 3353 Upon the receipt of a valid Release message, the server examines the 3354 IAs and the leases in the IAs for validity. If the IAs in the 3355 message are in a binding for the client, and the leases in the IAs 3356 have been assigned by the server to those IAs, the server deletes the 3357 leases from the IAs and makes the leases available for assignment to 3358 other clients. The server ignores leases not assigned to the IA, 3359 although it may choose to log an error. 3361 After all the leases have been processed, the server generates a 3362 Reply message and includes a Status Code option with value Success, a 3363 Server Identifier option with the server's DUID, and a Client 3364 Identifier option with the client's DUID. For each IA in the Release 3365 message for which the server has no binding information, the server 3366 adds an IA option using the IAID from the Release message, and 3367 includes a Status Code option with the value NoBinding in the IA 3368 option. No other options are included in the IA option. 3370 A server may choose to retain a record of assigned leases and IAs 3371 after the lifetimes on the leases have expired to allow the server to 3372 reassign the previously assigned leases to a client. 3374 17.2.8. Receipt of Decline Messages 3376 When the server receives a Decline message via unicast from a client 3377 to which the server has not sent a unicast option (or is not 3378 currently configured to send a unicast option to the client), the 3379 server discards the Decline message and responds with a Reply message 3380 containing a Status Code option with the value UseMulticast, a Server 3381 Identifier option containing the server's DUID, the Client Identifier 3382 option from the client message, and no other options. 3384 Upon the receipt of a valid Decline message, the server examines the 3385 IAs and the addresses in the IAs for validity. If the IAs in the 3386 message are in a binding for the client, and the addresses in the IAs 3387 have been assigned by the server to those IAs, the server deletes the 3388 addresses from the IAs. The server ignores addresses not assigned to 3389 the IA (though it may choose to log an error if it finds such an 3390 address). 3392 The client has found any addresses in the Decline messages to be 3393 already in use on its link. Therefore, the server SHOULD mark the 3394 addresses declined by the client so that those addresses are not 3395 assigned to other clients, and MAY choose to make a notification that 3396 addresses were declined. Local policy on the server determines when 3397 the addresses identified in a Decline message may be made available 3398 for assignment. 3400 After all the addresses have been processed, the server generates a 3401 Reply message by setting the "msg-type" field to REPLY, and copying 3402 the transaction ID from the Decline message into the transaction-id 3403 field. The client includes a Status Code option with the value 3404 Success, a Server Identifier option with the server's DUID, and a 3405 Client Identifier option with the client's DUID. For each IA in the 3406 Decline message for which the server has no binding information, the 3407 server adds an IA option using the IAID from the Decline message and 3408 includes a Status Code option with the value NoBinding in the IA 3409 option. No other options are included in the IA option. 3411 17.2.9. Creation and Transmission of Advertise Messages 3413 The server sets the "msg-type" field to ADVERTISE and copies the 3414 contents of the transaction-id field from the Solicit message 3415 received from the client to the Advertise message. The server 3416 includes its server identifier in a Server Identifier option and 3417 copies the Client Identifier option from the Solicit message into the 3418 Advertise message. 3420 The server MAY add a Preference option to carry the preference value 3421 for the Advertise message. The server implementation SHOULD allow 3422 the setting of a server preference value by the administrator. The 3423 server preference value MUST default to zero unless otherwise 3424 configured by the server administrator. 3426 The server includes a Reconfigure Accept option if the server wants 3427 to indicate it supports Reconfigure mechanism. This information may 3428 be used by the client during server selection process. 3430 The server includes options the server will return to the client in a 3431 subsequent Reply message. The information in these options may be 3432 used by the client in the selection of a server if the client 3433 receives more than one Advertise message. The server MUST include 3434 options in the Advertise message containing configuration parameters 3435 for all of the options identified in the Option Request option in the 3436 Solicit message that the server has been configured to return to the 3437 client. If the Option Request option includes a container option the 3438 server MUST include all the options that are eligible to be 3439 encapsulated in the container. The Option Request option MAY be used 3440 to signal support for a feature even when that option is encapsulated 3441 as in the case of the Prefix Excluded option [RFC6603]. In this 3442 case, special processing is required by the server. The server MAY 3443 return additional options to the client if it has been configured to 3444 do so. The server must be aware of the recommendations on packet 3445 sizes and the use of fragmentation in section 5 of [RFC2460]. 3447 If the Solicit message from the client included one or more IA 3448 options, the server MUST include IA options in the Advertise message 3449 containing any addresses and/or delegated prefixes that would be 3450 assigned to IAs contained in the Solicit message from the client. If 3451 the client has included addresses in the IA in the Solicit message, 3452 the server MAY use those addresses as hints about the addresses that 3453 the client would like to receive. If the client has included IA 3454 Prefix option in the IA_PD, the server MAY use the prefix contained 3455 in the IPv6 prefix field and/or the prefix length contained in the 3456 "prefix-length" field as a hints about the prefixes the client would 3457 like to receive. If the server is not going to assign an address or 3458 delegated prefix received as a hint in the Solicit message, the 3459 server MUST NOT include this address or delegated prefix in the 3460 Advertise message 3462 If the server will not assign any addresses to an IA (IA_NA or IA_IA) 3463 in subsequent Request from the client, the server MUST include the IA 3464 in the Advertise message with no addresses in the IA and a Status 3465 Code option encapsulated in the IA containing status code 3466 NoAddrsAvail. 3468 If the server will not assign any prefixes to an IA_PD in subsequent 3469 Request from the client, the server MUST include the IA_PD in the 3470 Advertise message with no prefixes in the IA and a Status Code option 3471 encapsulated in the IA_PD containing status code NoPrefixAvail. 3473 If the Solicit message was received directly by the server, the 3474 server unicasts the Advertise message directly to the client using 3475 the address in the source address field from the IP datagram in which 3476 the Solicit message was received. The Advertise message MUST be 3477 unicast on the link from which the Solicit message was received. 3479 If the Solicit message was received in a Relay-forward message, the 3480 server constructs a Relay-reply message with the Advertise message in 3481 the payload of a "relay-message" option. If the Relay-forward 3482 messages included an Interface-id option, the server copies that 3483 option to the Relay-reply message. The server unicasts the Relay- 3484 reply message directly to the relay agent using the address in the 3485 source address field from the IP datagram in which the Relay-forward 3486 message was received. 3488 17.2.10. Transmission of Reply Messages 3490 If the original message was received directly by the server, the 3491 server unicasts the Reply message directly to the client using the 3492 address in the source address field from the IP datagram in which the 3493 original message was received. The Reply message MUST be unicast 3494 through the interface on which the original message was received. 3496 If the original message was received in a Relay-forward message, the 3497 server constructs a Relay-reply message with the Reply message in the 3498 payload of a Relay Message option (see Section 20.10). If the Relay- 3499 forward messages included an Interface-id option, the server copies 3500 that option to the Relay-reply message. The server unicasts the 3501 Relay-reply message directly to the relay agent using the address in 3502 the source address field from the IP datagram in which the Relay- 3503 forward message was received. 3505 17.2.11. Creation and Transmission of Reconfigure Messages 3507 The server sets the "msg-type" field to RECONFIGURE. The server sets 3508 the transaction-id field to 0. The server includes a Server 3509 Identifier option containing its DUID and a Client Identifier option 3510 containing the client's DUID in the Reconfigure message. 3512 The server MAY include an Option Request option to inform the client 3513 of what information has been changed or new information that has been 3514 added. In particular, the server specifies the IA option in the 3515 Option Request option if the server wants the client to obtain new 3516 address information. If the server identifies the IA option in the 3517 Option Request option, the server MUST include an IA option to 3518 identify each IA that is to be reconfigured on the client. The IA 3519 options included by the server MUST NOT contain any options. 3521 Because of the risk of denial of service attacks against DHCP 3522 clients, the use of a security mechanism is mandated in Reconfigure 3523 messages. The server MUST use DHCP authentication in the Reconfigure 3524 message. 3526 The server MUST include a Reconfigure Message option (defined in 3527 Section 20.19) to select whether the client responds with a Renew 3528 message, a Rebind message, or an Information-request message. 3530 The server MUST NOT include any other options in the Reconfigure 3531 except as specifically allowed in the definition of individual 3532 options. 3534 A server sends each Reconfigure message to a single DHCP client, 3535 using an IPv6 unicast address of sufficient scope belonging to the 3536 DHCP client. If the server does not have an address to which it can 3537 send the Reconfigure message directly to the client, the server uses 3538 a Relay-reply message (as described in Section 18.3) to send the 3539 Reconfigure message to a relay agent that will relay the message to 3540 the client. The server may obtain the address of the client (and the 3541 appropriate relay agent, if required) through the information the 3542 server has about clients that have been in contact with the server, 3543 or through some external agent. 3545 To reconfigure more than one client, the server unicasts a separate 3546 message to each client. The server may initiate the reconfiguration 3547 of multiple clients concurrently; for example, a server may send a 3548 Reconfigure message to additional clients while previous 3549 reconfiguration message exchanges are still in progress. 3551 The Reconfigure message causes the client to initiate a Renew/Reply, 3552 a Rebind/Reply, or Information-request/Reply message exchange with 3553 the server. The server interprets the receipt of a Renew, a Rebind, 3554 or Information-request message (whichever was specified in the 3555 original Reconfigure message) from the client as satisfying the 3556 Reconfigure message request. 3558 If the server does not receive a Renew, Rebind, or Information- 3559 request message from the client in REC_TIMEOUT milliseconds, the 3560 server retransmits the Reconfigure message, doubles the REC_TIMEOUT 3561 value and waits again. The server continues this process until 3562 REC_MAX_RC unsuccessful attempts have been made, at which point the 3563 server SHOULD abort the reconfigure process for that client. 3565 Default and initial values for REC_TIMEOUT and REC_MAX_RC are 3566 documented in Section 6.5. 3568 18. Relay Agent Behavior 3570 The relay agent MAY be configured to use a list of destination 3571 addresses, which MAY include unicast addresses, the All_DHCP_Servers 3572 multicast address, or other addresses selected by the network 3573 administrator. If the relay agent has not been explicitly 3574 configured, it MUST use the All_DHCP_Servers multicast address as the 3575 default. 3577 If the relay agent relays messages to the All_DHCP_Servers multicast 3578 address or other multicast addresses, it sets the Hop Limit field to 3579 32. 3581 If the relay agent receives a message other than Relay-forward and 3582 Relay-reply and the relay agent does not recognize its message type, 3583 it MUST forward them as described in Section 18.1.1. 3585 18.1. Relaying a Client Message or a Relay-forward Message 3587 A relay agent relays both messages from clients and Relay-forward 3588 messages from other relay agents. When a relay agent receives a 3589 valid message (for a definition of a valid message, see Section 4.1 3590 of [RFC7283]) to be relayed, it constructs a new Relay-forward 3591 message. The relay agent copies the source address from the header 3592 of the IP datagram in which the message was received to the peer- 3593 address field of the Relay-forward message. The relay agent copies 3594 the received DHCP message (excluding any IP or UDP headers) into a 3595 Relay Message option in the new message. The relay agent adds to the 3596 Relay-forward message any other options it is configured to include. 3598 [RFC6221] defines a Lightweight DHCPv6 Relay Agent (LDRA) that allows 3599 Relay Agent Information to be inserted by an access node that 3600 performs a link- layer bridging (i.e., non-routing) function. 3602 18.1.1. Relaying a Message from a Client 3604 If the relay agent received the message to be relayed from a client, 3605 the relay agent places a global, ULA [RFC4193] or site-scoped address 3606 with a prefix assigned to the link on which the client should be 3607 assigned an address in the link-address field. If not addresses of 3608 other scopes are available the relay agent may fill in the link- 3609 address field with a link-local address from the interface the 3610 original message was received on. That is not recommended as it 3611 requires additional information to be provided in the server 3612 configuration. See Section 3.2 of [I-D.ietf-dhc-topo-conf] for 3613 detailed discussion. 3615 This address will be used by the server to determine the link from 3616 which the client should be assigned an address and other 3617 configuration information. The hop-count in the Relay-forward 3618 message is set to 0. 3620 If the relay agent cannot use the address in the link-address field 3621 to identify the interface through which the response to the client 3622 will be relayed, the relay agent MUST include an Interface-id option 3623 (see Section 20.18) in the Relay-forward message. The server will 3624 include the Interface-id option in its Relay-reply message. The 3625 relay agent fills in the link-address field as described in the 3626 previous paragraph regardless of whether the relay agent includes an 3627 Interface-id option in the Relay-forward message. 3629 18.1.2. Relaying a Message from a Relay Agent 3631 If the message received by the relay agent is a Relay-forward message 3632 and the hop-count in the message is greater than or equal to 3633 HOP_COUNT_LIMIT, the relay agent discards the received message. 3635 The relay agent copies the source address from the IP datagram in 3636 which the message was received from the relay agent into the peer- 3637 address field in the Relay-forward message and sets the hop-count 3638 field to the value of the hop-count field in the received message 3639 incremented by 1. 3641 If the source address from the IP datagram header of the received 3642 message is a global or site-scoped address (and the device on which 3643 the relay agent is running belongs to only one site), the relay agent 3644 sets the link-address field to 0; otherwise the relay agent sets the 3645 link-address field to a global or site-scoped address assigned to the 3646 interface on which the message was received, or includes an 3647 Interface-ID option to identify the interface on which the message 3648 was received. 3650 18.1.3. Relay Agent Behavior with Prefix Delegation 3652 A relay agent forwards messages containing Prefix Delegation options 3653 in the same way as described earlier in this section. 3655 If a delegating router communicates with a requesting router through 3656 a relay agent, the delegating router may need a protocol or other 3657 out-of-band communication to configure routing information for 3658 delegated prefixes on any router through which the requesting router 3659 may forward traffic. 3661 18.2. Relaying a Relay-reply Message 3663 The relay agent processes any options included in the Relay-reply 3664 message in addition to the Relay Message option, and then discards 3665 those options. 3667 The relay agent extracts the message from the Relay Message option 3668 and relays it to the address contained in the peer-address field of 3669 the Relay-reply message. Relay agents MUST NOT modify the message. 3671 If the Relay-reply message includes an Interface-id option, the relay 3672 agent relays the message from the server to the client on the link 3673 identified by the Interface-id option. Otherwise, if the link- 3674 address field is not set to zero, the relay agent relays the message 3675 on the link identified by the link-address field. 3677 If the relay agent receives a Relay-reply message, it MUST process 3678 the message as defined above, regardless of the type of message 3679 encapsulated in the Relay Message option. 3681 18.3. Construction of Relay-reply Messages 3683 A server uses a Relay-reply message to return a response to a client 3684 if the original message from the client was relayed to the server in 3685 a Relay-forward message or to send a Reconfigure message to a client 3686 if the server does not have an address it can use to send the message 3687 directly to the client. 3689 A response to the client MUST be relayed through the same relay 3690 agents as the original client message. The server causes this to 3691 happen by creating a Relay-reply message that includes a Relay 3692 Message option containing the message for the next relay agent in the 3693 return path to the client. The contained Relay-reply message 3694 contains another Relay Message option to be sent to the next relay 3695 agent, and so on. The server must record the contents of the peer- 3696 address fields in the received message so it can construct the 3697 appropriate Relay-reply message carrying the response from the 3698 server. 3700 For example, if client C sent a message that was relayed by relay 3701 agent A to relay agent B and then to the server, the server would 3702 send the following Relay-reply message to relay agent B: 3704 msg-type: RELAY-REPLY 3705 hop-count: 1 3706 link-address: 0 3707 peer-address: A 3708 Relay Message option, containing: 3709 msg-type: RELAY-REPLY 3710 hop-count: 0 3711 link-address: address from link to which C is attached 3712 peer-address: C 3713 Relay Message option: 3715 Figure 8: Relay-reply Example 3717 When sending a Reconfigure message to a client through a relay agent, 3718 the server creates a Relay-reply message that includes a Relay 3719 Message option containing the Reconfigure message for the next relay 3720 agent in the return path to the client. The server sets the peer- 3721 address field in the Relay-reply message header to the address of the 3722 client, and sets the link-address field as required by the relay 3723 agent to relay the Reconfigure message to the client. The server 3724 obtains the addresses of the client and the relay agent through prior 3725 interaction with the client or through some external mechanism. 3727 19. Authentication of DHCP Messages 3729 Within this document, two security mechanisms are introduced for the 3730 authentication of DHCP messages: security of messages sent between 3731 servers and relay agents using IPsec, and protection against 3732 misconfiguration of a client caused by a Reconfigure message sent by 3733 a malicious DHCP server. The delayed authentication protocol, 3734 defined in [RFC3315], has been obsoleted by this document, due to 3735 lack of usage. 3737 19.1. Security of Messages Sent Between Servers and Relay Agents 3739 Relay agents and servers that exchange messages securely use the 3740 IPsec mechanisms for IPv6 [RFC4301]. If a client message is relayed 3741 through multiple relay agents, each of the relay agents must have 3742 established independent, pairwise trust relationships. That is, if 3743 messages from client C will be relayed by relay agent A to relay 3744 agent B and then to the server, relay agents A and B must be 3745 configured to use IPsec for the messages they exchange, and relay 3746 agent B and the server must be configured to use IPsec for the 3747 messages they exchange. 3749 Relay agents and servers that support secure relay agent to server or 3750 relay agent to relay agent communication use IPsec under the 3751 following conditions: 3753 Selectors Relay agents are manually configured with the 3754 addresses of the relay agent or server to 3755 which DHCP messages are to be forwarded. 3756 Each relay agent and server that will be 3757 using IPsec for securing DHCP messages must 3758 also be configured with a list of the relay 3759 agents to which messages will be returned. 3760 The selectors for the relay agents and 3761 servers will be the pairs of addresses 3762 defining relay agents and servers that 3763 exchange DHCP messages on UDP port 547. 3765 Mode Relay agents and servers use transport mode 3766 and ESP. The information in DHCP messages is 3767 not generally considered confidential, so 3768 encryption need not be used (i.e., NULL 3769 encryption can be used). 3771 Key management Because the relay agents and servers are used 3772 within an organization, public key schemes 3773 are not necessary. Because the relay agents 3774 and servers must be manually configured, 3775 manually configured key management may 3776 suffice, but does not provide defense against 3777 replayed messages. Accordingly, IKE with 3778 preshared secrets SHOULD be supported. IKE 3779 with public keys MAY be supported. 3781 Security policy DHCP messages between relay agents and 3782 servers should only be accepted from DHCP 3783 peers as identified in the local 3784 configuration. 3786 Authentication Shared keys, indexed to the source IP address 3787 of the received DHCP message, are adequate in 3788 this application. 3790 Availability Appropriate IPsec implementations are likely 3791 to be available for servers and for relay 3792 agents in more featureful devices used in 3793 enterprise and core ISP networks. IPsec is 3794 less likely to be available for relay agents 3795 in low end devices primarily used in the home 3796 or small office markets. 3798 19.2. Summary of DHCP Authentication 3800 Authentication of DHCP messages is accomplished through the use of 3801 the Authentication option (see Section 20.11). The authentication 3802 information carried in the Authentication option can be used to 3803 reliably identify the source of a DHCP message and to confirm that 3804 the contents of the DHCP message have not been tampered with. 3806 The Authentication option provides a framework for multiple 3807 authentication protocols. One such protocol, the Reconfigure key 3808 authentication protocol , is defined in Section 19.4. Other 3809 protocols defined in the future will be specified in separate 3810 documents. 3812 Any DHCP message MUST NOT include more than one Authentication 3813 option. 3815 The protocol field in the Authentication option identifies the 3816 specific protocol used to generate the authentication information 3817 carried in the option. The algorithm field identifies a specific 3818 algorithm within the authentication protocol; for example, the 3819 algorithm field specifies the hash algorithm used to generate the 3820 message authentication code (MAC) in the authentication option. The 3821 replay detection method (RDM) field specifies the type of replay 3822 detection used in the replay detection field. 3824 [RFC3315] has defined the delayed authentication protocol. But it is 3825 obsoleted by this document, due to lack of usage. 3827 19.3. Replay Detection 3829 The Replay Detection Method (RDM) field determines the type of replay 3830 detection used in the Replay Detection field. 3832 If the RDM field contains 0x00, the replay detection field MUST be 3833 set to the value of a strictly monotonically increasing counter. 3834 Using a counter value, such as the current time of day (for example, 3835 an NTP-format timestamp [RFC5905]), can reduce the danger of replay 3836 attacks. This method MUST be supported by all protocols. 3838 19.4. Reconfigure Key Authentication Protocol 3840 The Reconfigure key authentication protocol provides protection 3841 against misconfiguration of a client caused by a Reconfigure message 3842 sent by a malicious DHCP server. In this protocol, a DHCP server 3843 sends a Reconfigure Key to the client in the initial exchange of DHCP 3844 messages. The client records the Reconfigure Key for use in 3845 authenticating subsequent Reconfigure messages from that server. The 3846 server then includes an HMAC computed from the Reconfigure Key in 3847 subsequent Reconfigure messages. 3849 Both the Reconfigure Key sent from the server to the client and the 3850 HMAC in subsequent Reconfigure messages are carried as the 3851 Authentication information in an Authentication option. The format 3852 of the Authentication information is defined in the following 3853 section. 3855 The Reconfigure Key protocol is used (initiated by the server) only 3856 if the client and server are not using any other authentication 3857 protocol and the client and server have negotiated to use Reconfigure 3858 messages. 3860 19.4.1. Use of the Authentication Option in the Reconfigure Key 3861 Authentication Protocol 3863 The following fields are set in an Authentication option for the 3864 Reconfigure Key Authentication Protocol: 3866 protocol 3 3868 algorithm 1 3870 RDM 0 3872 The format of the Authentication information for the Reconfigure Key 3873 Authentication Protocol is: 3875 0 1 2 3 3876 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 3877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3878 | Type | Value (128 bits) | 3879 +-+-+-+-+-+-+-+-+ | 3880 . . 3881 . . 3882 . +-+-+-+-+-+-+-+-+ 3883 | | 3884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3886 Figure 9: RKAP Authentication Information 3888 Type Type of data in Value field carried in this 3889 option: 3891 1 Reconfigure Key value (used in Reply 3892 message). 3894 2 HMAC-MD5 digest of the message (used in 3895 Reconfigure message). 3897 Value Data as defined by the Type field. 3899 19.4.2. Server considerations for Reconfigure Key protocol 3901 The server selects a Reconfigure Key for a client during the Request/ 3902 Reply, Solicit/Reply or Information-request/Reply message exchange. 3903 The server records the Reconfigure Key and transmits that key to the 3904 client in an Authentication option in the Reply message. 3906 The Reconfigure Key is 128 bits long, and MUST be a cryptographically 3907 strong random or pseudo-random number that cannot easily be 3908 predicted. 3910 To provide authentication for a Reconfigure message, the server 3911 selects a replay detection value according to the RDM selected by the 3912 server, and computes an HMAC-MD5 of the Reconfigure message using the 3913 Reconfigure Key for the client. The server computes the HMAC-MD5 3914 over the entire DHCP Reconfigure message, including the 3915 Authentication option; the HMAC-MD5 field in the Authentication 3916 option is set to zero for the HMAC-MD5 computation. The server 3917 includes the HMAC-MD5 in the authentication information field in an 3918 Authentication option included in the Reconfigure message sent to the 3919 client. 3921 19.4.3. Client considerations for Reconfigure Key protocol 3923 The client will receive a Reconfigure Key from the server in the 3924 initial Reply message from the server. The client records the 3925 Reconfigure Key for use in authenticating subsequent Reconfigure 3926 messages. 3928 To authenticate a Reconfigure message, the client computes an HMAC- 3929 MD5 over the DHCP Reconfigure message, using the Reconfigure Key 3930 received from the server. If this computed HMAC-MD5 matches the 3931 value in the Authentication option, the client accepts the 3932 Reconfigure message. 3934 20. DHCP Options 3936 Options are used to carry additional information and parameters in 3937 DHCP messages. Every option shares a common base format, as 3938 described in Section 20.1. All values in options are represented in 3939 network byte order. 3941 This document describes the DHCP options defined as part of the base 3942 DHCP specification. Other options may be defined in the future in 3943 separate documents. See [RFC7227] for guidelines regarding new 3944 options definition. See Section 23 for additional information about 3945 a registry maintained by IANA. 3947 Unless otherwise noted, each option may appear only in the options 3948 area of a DHCP message and may appear only once. If an option does 3949 appear multiple times, each instance is considered separate and the 3950 data areas of the options MUST NOT be concatenated or otherwise 3951 combined. 3953 Options that are allowed to appear only once are called singleton 3954 options. The only non-singleton options defined in this document are 3955 IA_NA (see Section 20.4), IA_TA (see Section 20.5), and IA_PD (see 3956 Section 20.21) options. Also, IAAddress (see Section 20.6) and 3957 IAPrefix (see Section 20.22) may appear in their respective IA 3958 options more than once. 3960 20.1. Format of DHCP Options 3962 The format of DHCP options is: 3964 0 1 2 3 3965 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 3966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3967 | option-code | option-len | 3968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3969 | option-data | 3970 | (option-len octets) | 3971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3973 Figure 10: Option Format 3975 option-code An unsigned integer identifying the specific 3976 option type carried in this option. 3978 option-len An unsigned integer giving the length of the 3979 option-data field in this option in octets. 3981 option-data The data for the option; the format of this 3982 data depends on the definition of the option. 3984 DHCP options are scoped by using encapsulation. Some options apply 3985 generally to the client, some are specific to an IA, and some are 3986 specific to the addresses within an IA. These latter two cases are 3987 discussed in Section 20.4 and Section 20.6. 3989 20.2. Client Identifier Option 3991 The Client Identifier option is used to carry a DUID (see Section 10) 3992 identifying a client between a client and a server. The format of 3993 the Client Identifier option is: 3995 0 1 2 3 3996 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 3997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3998 | OPTION_CLIENTID | option-len | 3999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4000 . . 4001 . DUID . 4002 . (variable length) . 4003 . . 4004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4006 Figure 11: Client Identifier Option Format 4008 option-code OPTION_CLIENTID (1). 4010 option-len Length of DUID in octets. 4012 DUID The DUID for the client. 4014 20.3. Server Identifier Option 4016 The Server Identifier option is used to carry a DUID (see Section 10) 4017 identifying a server between a client and a server. The format of 4018 the Server Identifier option is: 4020 0 1 2 3 4021 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 4022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4023 | OPTION_SERVERID | option-len | 4024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4025 . . 4026 . DUID . 4027 . (variable length) . 4028 . . 4029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4031 Figure 12: Server Identifier Option Format 4033 option-code OPTION_SERVERID (2). 4035 option-len Length of DUID in octets. 4037 DUID The DUID for the server. 4039 20.4. Identity Association for Non-temporary Addresses Option 4041 The Identity Association for Non-temporary Addresses option (IA_NA 4042 option) is used to carry an IA_NA, the parameters associated with the 4043 IA_NA, and the non-temporary addresses associated with the IA_NA. 4045 Addresses appearing in an IA_NA option are not temporary addresses 4046 (see Section 20.5). 4048 The format of the IA_NA option is: 4050 0 1 2 3 4051 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 4052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4053 | OPTION_IA_NA | option-len | 4054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4055 | IAID (4 octets) | 4056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4057 | T1 | 4058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4059 | T2 | 4060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4061 | | 4062 . IA_NA-options . 4063 . . 4064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4066 Figure 13: Identity Association for Non-temporary Addresses Option 4067 Format 4069 option-code OPTION_IA_NA (3). 4071 option-len 12 + length of IA_NA-options field. 4073 IAID The unique identifier for this IA_NA; the 4074 IAID must be unique among the identifiers for 4075 all of this client's IA_NAs. The number 4076 space for IA_NA IAIDs is separate from the 4077 number space for IA_TA IAIDs. 4079 T1 The time at which the client contacts the 4080 server from which the addresses in the IA_NA 4081 were obtained to extend the lifetimes of the 4082 addresses assigned to the IA_NA; T1 is a time 4083 duration relative to the current time 4084 expressed in units of seconds. 4086 T2 The time at which the client contacts any 4087 available server to extend the lifetimes of 4088 the addresses assigned to the IA_NA; T2 is a 4089 time duration relative to the current time 4090 expressed in units of seconds. 4092 IA_NA-options Options associated with this IA_NA. 4094 The IA_NA-options field encapsulates those options that are specific 4095 to this IA_NA. For example, all of the IA Address Options carrying 4096 the addresses associated with this IA_NA are in the IA_NA-options 4097 field. 4099 Each IA_NA carries one "set" of non-temporary addresses; that is, at 4100 most one address from each prefix assigned to the link to which the 4101 client is attached. 4103 An IA_NA option may only appear in the options area of a DHCP 4104 message. A DHCP message may contain multiple IA_NA options. 4106 The status of any operations involving this IA_NA is indicated in a 4107 Status Code option in the IA_NA-options field. 4109 Note that an IA_NA has no explicit "lifetime" or "lease length" of 4110 its own. When the valid lifetimes of all of the addresses in an 4111 IA_NA have expired, the IA_NA can be considered as having expired. 4112 T1 and T2 are included to give servers explicit control over when a 4113 client recontacts the server about a specific IA_NA. 4115 In a message sent by a client to a server, the T1 and T2 fields 4116 SHOULD be set to 0. The server MUST ignore any values in these 4117 fields in messages received from a client. 4119 In a message sent by a server to a client, the client MUST use the 4120 values in the T1 and T2 fields for the T1 and T2 parameters, unless 4121 those values in those fields are 0. The values in the T1 and T2 4122 fields are the number of seconds until T1 and T2. 4124 The server selects the T1 and T2 times to allow the client to extend 4125 the lifetimes of any addresses in the IA_NA before the lifetimes 4126 expire, even if the server is unavailable for some short period of 4127 time. Recommended values for T1 and T2 are .5 and .8 times the 4128 shortest preferred lifetime of the addresses in the IA that the 4129 server is willing to extend, respectively. If the "shortest" 4130 preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and 4131 T2 values are also 0xffffffff. If the time at which the addresses in 4132 an IA_NA are to be renewed is to be left to the discretion of the 4133 client, the server sets T1 and T2 to 0. The client MUST follow the 4134 rules defined in Section 13.2. 4136 If a server receives an IA_NA with T1 greater than T2, and both T1 4137 and T2 are greater than 0, the server ignores the invalid values of 4138 T1 and T2 and processes the IA_NA as though the client had set T1 and 4139 T2 to 0. 4141 If a client receives an IA_NA with T1 greater than T2, and both T1 4142 and T2 are greater than 0, the client discards the IA_NA option and 4143 processes the remainder of the message as though the server had not 4144 included the invalid IA_NA option. 4146 Care should be taken in setting T1 or T2 to 0xffffffff ("infinity"). 4147 A client will never attempt to extend the lifetimes of any addresses 4148 in an IA with T1 set to 0xffffffff. A client will never attempt to 4149 use a Rebind message to locate a different server to extend the 4150 lifetimes of any addresses in an IA with T2 set to 0xffffffff. 4152 This option MAY appear in a Confirm message if the lifetimes on the 4153 non-temporary addresses in the associated IA have not expired. 4155 20.5. Identity Association for Temporary Addresses Option 4157 The Identity Association for the Temporary Addresses (IA_TA) option 4158 is used to carry an IA_TA, the parameters associated with the IA_TA 4159 and the addresses associated with the IA_TA. All of the addresses in 4160 this option are used by the client as temporary addresses, as defined 4161 in [RFC4941]. The format of the IA_TA option is: 4163 0 1 2 3 4164 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 4165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4166 | OPTION_IA_TA | option-len | 4167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4168 | IAID (4 octets) | 4169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4170 | | 4171 . IA_TA-options . 4172 . . 4173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4175 Figure 14: Identity Association for Temporary Addresses Option Format 4177 option-code OPTION_IA_TA (4). 4179 option-len 4 + length of IA_TA-options field. 4181 IAID The unique identifier for this IA_TA; the 4182 IAID must be unique among the identifiers for 4183 all of this client's IA_TAs. The number 4184 space for IA_TA IAIDs is separate from the 4185 number space for IA_NA IAIDs. 4187 IA_TA-options Options associated with this IA_TA. 4189 The IA_TA-Options field encapsulates those options that are specific 4190 to this IA_TA. For example, all of the IA Address Options carrying 4191 the addresses associated with this IA_TA are in the IA_TA-options 4192 field. 4194 Each IA_TA carries one "set" of temporary addresses. 4196 An IA_TA option may only appear in the options area of a DHCP 4197 message. A DHCP message may contain multiple IA_TA options. 4199 The status of any operations involving this IA_TA is indicated in a 4200 Status Code option in the IA_TA-options field. 4202 Note that an IA has no explicit "lifetime" or "lease length" of its 4203 own. When the valid lifetimes of all of the addresses in an IA_TA 4204 have expired, the IA can be considered as having expired. 4206 An IA_TA option does not include values for T1 and T2. A client MAY 4207 request that the lifetimes on temporary addresses be extended by 4208 including the addresses in a IA_TA option sent in a Renew or Rebind 4209 message to a server. For example, a client would request an 4210 extension on the lifetime of a temporary address to allow an 4211 application to continue to use an established TCP connection. 4213 The client obtains new temporary addresses by sending an IA_TA option 4214 with a new IAID to a server. Requesting new temporary addresses from 4215 the server is the equivalent of generating new temporary addresses as 4216 described in [RFC4941]. The server will generate new temporary 4217 addresses and return them to the client. The client should request 4218 new temporary addresses before the lifetimes on the previously 4219 assigned addresses expire. 4221 A server MUST return the same set of temporary address for the same 4222 IA_TA (as identified by the IAID) as long as those addresses are 4223 still valid. After the lifetimes of the addresses in an IA_TA have 4224 expired, the IAID may be reused to identify a new IA_TA with new 4225 temporary addresses. 4227 This option MAY appear in a Confirm message if the lifetimes on the 4228 temporary addresses in the associated IA have not expired. 4230 20.6. IA Address Option 4232 The IA Address option is used to specify IPv6 addresses associated 4233 with an IA_NA or an IA_TA. The IA Address option must be 4234 encapsulated in the Options field of an IA_NA or IA_TA option. The 4235 Options fields of the IA_NA or IA_TA option encapsulates those 4236 options that are specific to this address. 4238 The format of the IA Address option is: 4240 0 1 2 3 4241 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 4242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4243 | OPTION_IAADDR | option-len | 4244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4245 | | 4246 | IPv6 address | 4247 | | 4248 | | 4249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4250 | preferred-lifetime | 4251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4252 | valid-lifetime | 4253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4254 . . 4255 . IAaddr-options . 4256 . . 4257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4259 Figure 15: IA Address Option Format 4261 option-code OPTION_IAADDR (5). 4263 option-len 24 + length of IAaddr-options field. 4265 IPv6 address An IPv6 address. 4267 preferred-lifetime The preferred lifetime for the IPv6 address 4268 in the option, expressed in units of seconds. 4270 valid-lifetime The valid lifetime for the IPv6 address in 4271 the option, expressed in units of seconds. 4273 IAaddr-options Options associated with this address. 4275 In a message sent by a client to a server, the preferred and valid 4276 lifetime fields SHOULD be set to 0. The server MUST ignore any 4277 received values. 4279 The client SHOULD NOT send the IA Address option with unspecified 4280 address (::). 4282 In a message sent by a server to a client, the client MUST use the 4283 values in the preferred and valid lifetime fields for the preferred 4284 and valid lifetimes. The values in the preferred and valid lifetimes 4285 are the number of seconds remaining in each lifetime. 4287 A client discards any addresses for which the preferred lifetime is 4288 greater than the valid lifetime. A server ignores the lifetimes set 4289 by the client if the preferred lifetime is greater than the valid 4290 lifetime and ignores the values for T1 and T2 set by the client if 4291 those values are greater than the preferred lifetime. 4293 Care should be taken in setting the valid lifetime of an address to 4294 0xffffffff ("infinity"), which amounts to a permanent assignment of 4295 an address to a client. 4297 More than one IA Address Option can appear in an IA_NA option or an 4298 IA_TA option. 4300 The status of any operations involving this IA Address is indicated 4301 in a Status Code option in the IAaddr-options field, as specified in 4302 Section 20.13. 4304 20.7. Option Request Option 4306 The Option Request option is used to identify a list of options in a 4307 message between a client and a server. The format of the Option 4308 Request option is: 4310 0 1 2 3 4311 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 4312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4313 | OPTION_ORO | option-len | 4314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4315 | requested-option-code-1 | requested-option-code-2 | 4316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4317 | ... | 4318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4320 Figure 16: Option Request Option Format 4322 option-code OPTION_ORO (6). 4324 option-len 2 * number of requested options. 4326 requested-option-code-n The option code for an option requested 4327 by the client. 4329 A client MAY include an Option Request option in a Solicit, Request, 4330 Renew, Rebind, Confirm or Information-request message to inform the 4331 server about options the client wants the server to send to the 4332 client. A server MAY include an Option Request option in a 4333 Reconfigure message to indicate which options the client should 4334 request from the server. 4336 The Option Request option MUST NOT include the following options: 4337 Server Identifier, Client Identifier, IA_NA, IA_PD, IA_TA, Option 4338 Request, Elapsed Time, Preference, Relay Message, Authentication, 4339 Server Unicast, Rapid Commit, User Class, Interface-Id, Reconfigure 4340 Message, and Reconfigure Accept. Other top-level Options MUST appear 4341 in the Option Request option or the will not be sent by the server. 4342 Only container options MUST appear in the Option Request, options 4343 encapsulated in the container MUST NOT by in the Option Request, see 4344 [RFC7598] as an example of container options. The exception to this 4345 is the Option Request option MAY be used to signal support for a 4346 feature even when that option is encapsulated as in the case of the 4347 Prefix Excluded option [RFC6603]. 4349 20.8. Preference Option 4351 The Preference option is sent by a server to a client to affect the 4352 selection of a server by the client. 4354 The format of the Preference 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_PREFERENCE | option-len | 4360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4361 | pref-value | 4362 +-+-+-+-+-+-+-+-+ 4364 Figure 17: Preference Option Format 4366 option-code OPTION_PREFERENCE (7). 4368 option-len 1. 4370 pref-value The preference value for the server in this 4371 message. 4373 A server MAY include a Preference option in an Advertise message to 4374 control the selection of a server by the client. See Section 17.1.9 4375 for the use of the Preference option by the client and the 4376 interpretation of Preference option data value. 4378 20.9. Elapsed Time Option 4380 0 1 2 3 4381 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 4382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4383 | OPTION_ELAPSED_TIME | option-len | 4384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4385 | elapsed-time | 4386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4388 Figure 18: Elapsed Time Option Format 4390 option-code OPTION_ELAPSED_TIME (8). 4392 option-len 2. 4394 elapsed-time The amount of time since the client began its 4395 current DHCP transaction. This time is 4396 expressed in hundredths of a second (10^-2 4397 seconds). 4399 A client MUST include an Elapsed Time option in messages to indicate 4400 how long the client has been trying to complete a DHCP message 4401 exchange. The elapsed time is measured from the time at which the 4402 client sent the first message in the message exchange, and the 4403 elapsed-time field is set to 0 in the first message in the message 4404 exchange. Servers and Relay Agents use the data value in this option 4405 as input to policy controlling how a server responds to a client 4406 message. For example, the elapsed time option allows a secondary 4407 DHCP server to respond to a request when a primary server has not 4408 answered in a reasonable time. The elapsed time value is an 4409 unsigned, 16 bit integer. The client uses the value 0xffff to 4410 represent any elapsed time values greater than the largest time value 4411 that can be represented in the Elapsed Time option. 4413 20.10. Relay Message Option 4415 The Relay Message option carries a DHCP message in a Relay-forward or 4416 Relay-reply message. 4418 The format of the Relay Message option is: 4420 0 1 2 3 4421 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 4422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4423 | OPTION_RELAY_MSG | option-len | 4424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4425 | | 4426 . DHCP-relay-message . 4427 . . 4428 . . 4429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4431 Figure 19: Relay Message Option Format 4433 option-code OPTION_RELAY_MSG (9) 4435 option-len Length of DHCP-relay-message 4437 DHCP-relay-message In a Relay-forward message, the received 4438 message, relayed verbatim to the next relay 4439 agent or server; in a Relay-reply message, 4440 the message to be copied and relayed to the 4441 relay agent or client whose address is in the 4442 peer-address field of the Relay-reply message 4444 20.11. Authentication Option 4446 The Authentication option carries authentication information to 4447 authenticate the identity and contents of DHCP messages. The use of 4448 the Authentication option is described in Section 19. The delayed 4449 authentication protocol, defined in [RFC3315], has been obsoleted by 4450 this document, due to lack of usage. The format of the 4451 Authentication option is: 4453 0 1 2 3 4454 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 4455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4456 | OPTION_AUTH | option-len | 4457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4458 | protocol | algorithm | RDM | | 4459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4460 | | 4461 | replay detection (64 bits) +-+-+-+-+-+-+-+-+ 4462 | | auth-info | 4463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4464 . authentication information . 4465 . (variable length) . 4466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4468 Figure 20: Authentication Option Format 4470 option-code OPTION_AUTH (11). 4472 option-len 11 + length of authentication information 4473 field. 4475 protocol The authentication protocol used in this 4476 authentication option. 4478 algorithm The algorithm used in the authentication 4479 protocol. 4481 RDM The replay detection method used in this 4482 authentication option. 4484 Replay detection The replay detection information for the RDM. 4486 authentication information The authentication information, as 4487 specified by the protocol and algorithm used 4488 in this authentication option. 4490 20.12. Server Unicast Option 4492 The server sends this option to a client to indicate to the client 4493 that it is allowed to unicast messages to the server. The format of 4494 the Server Unicast option is: 4496 0 1 2 3 4497 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 4498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4499 | OPTION_UNICAST | option-len | 4500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4501 | | 4502 | server-address | 4503 | | 4504 | | 4505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4507 Figure 21: Server Unicast Option Format 4509 option-code OPTION_UNICAST (12). 4511 option-len 16. 4513 server-address The IP address to which the client should 4514 send messages delivered using unicast. 4516 The server specifies the IPv6 address to which the client is to send 4517 unicast messages in the server-address field. When a client receives 4518 this option, where permissible and appropriate, the client sends 4519 messages directly to the server using the IPv6 address specified in 4520 the server-address field of the option. 4522 When the server sends a Unicast option to the client, some messages 4523 from the client will not be relayed by Relay Agents, and will not 4524 include Relay Agent options from the Relay Agents. Therefore, a 4525 server should only send a Unicast option to a client when Relay 4526 Agents are not sending Relay Agent options. A DHCP server rejects 4527 any messages sent inappropriately using unicast to ensure that 4528 messages are relayed by Relay Agents when Relay Agent options are in 4529 use. 4531 Details about when the client may send messages to the server using 4532 unicast are in Section 17. 4534 20.13. Status Code Option 4536 This option returns a status indication related to the DHCP message 4537 or option in which it appears. The format of the Status Code option 4538 is: 4540 0 1 2 3 4541 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 4542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4543 | OPTION_STATUS_CODE | option-len | 4544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4545 | status-code | | 4546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4547 . . 4548 . status-message . 4549 . . 4550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4552 Figure 22: Status Code Option Format 4554 option-code OPTION_STATUS_CODE (13). 4556 option-len 2 + length of status-message. 4558 status-code The numeric code for the status encoded in 4559 this option. 4561 status-message A UTF-8 encoded text string suitable for 4562 display to an end user, which MUST NOT be 4563 null-terminated. 4565 A Status Code option may appear in the options field of a DHCP 4566 message and/or in the options field of another option. If the Status 4567 Code option does not appear in a message in which the option could 4568 appear, the status of the message is assumed to be Success. 4570 The status-codes values previously defined by [RFC3315] and [RFC3633] 4571 are: 4573 +---------------+------+--------------------------------------------+ 4574 | Name | Code | Description | 4575 +---------------+------+--------------------------------------------+ 4576 | Success | 0 | Success. | 4577 | UnspecFail | 1 | Failure, reason unspecified; this status | 4578 | | | code is sent by either a client or a | 4579 | | | server to indicate a failure not | 4580 | | | explicitly specified in this document. | 4581 | NoAddrsAvail | 2 | Server has no addresses available to | 4582 | | | assign to the IA(s). | 4583 | NoBinding | 3 | Client record (binding) unavailable. | 4584 | NotOnLink | 4 | The prefix for the address is not | 4585 | | | appropriate for the link to which the | 4586 | | | client is attached. | 4587 | UseMulticast | 5 | Sent by a server to a client to force the | 4588 | | | client to send messages to the server | 4589 | | | using the | 4590 | | | All_DHCP_Relay_Agents_and_Servers address. | 4591 | NoPrefixAvail | 6 | Delegating router has no prefixes | 4592 | | | available to assign to the IAPD(s). | 4593 +---------------+------+--------------------------------------------+ 4595 20.14. Rapid Commit Option 4597 The Rapid Commit option is used to signal the use of the two message 4598 exchange for address assignment. The format of the Rapid Commit 4599 option is: 4601 0 1 2 3 4602 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 4603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4604 | OPTION_RAPID_COMMIT | 0 | 4605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4607 Figure 23: Rapid Commit Option Format 4609 option-code OPTION_RAPID_COMMIT (14). 4611 option-len 0. 4613 A client MAY include this option in a Solicit message if the client 4614 is prepared to perform the Solicit-Reply message exchange described 4615 in Section 17.1.1. 4617 A server MUST include this option in a Reply message sent in response 4618 to a Solicit message when completing the Solicit-Reply message 4619 exchange. 4621 DISCUSSION: 4623 Each server that responds with a Reply to a Solicit that includes 4624 a Rapid Commit option will commit the assigned addresses in the 4625 Reply message to the client, and will not receive any confirmation 4626 that the client has received the Reply message. Therefore, if 4627 more than one server responds to a Solicit that includes a Rapid 4628 Commit option, some servers will commit addresses that are not 4629 actually used by the client. 4631 The problem of unused addresses can be minimized, for example, by 4632 designing the DHCP service so that only one server responds to the 4633 Solicit or by using relatively short lifetimes for assigned 4634 addresses, or the DHCP client initiatively releases unused 4635 addresses using the Release message. 4637 20.15. User Class Option 4639 The User Class option is used by a client to identify the type or 4640 category of user or applications it represents. 4642 The format of the User Class option is: 4644 0 1 2 3 4645 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 4646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4647 | OPTION_USER_CLASS | option-len | 4648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4649 . . 4650 . user-class-data . 4651 . . 4652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4654 Figure 24: User Class Option Format 4656 option-code OPTION_USER_CLASS (15). 4658 option-len Length of user class data field. 4660 user-class-data The user classes carried by the client. 4662 The information contained in the data area of this option is 4663 contained in one or more opaque fields that represent the user class 4664 or classes of which the client is a member. A server selects 4665 configuration information for the client based on the classes 4666 identified in this option. For example, the User Class option can be 4667 used to configure all clients of people in the accounting department 4668 with a different printer than clients of people in the marketing 4669 department. The user class information carried in this option MUST 4670 be configurable on the client. 4672 The data area of the user class option MUST contain one or more 4673 instances of user class data. Each instance of the user class data 4674 is formatted as follows: 4676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4677 | user-class-len | opaque-data | 4678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4680 Figure 25: User Class Data Format 4682 The user-class-len is two octets long and specifies the length of the 4683 opaque user class data in network byte order. 4685 A server interprets the classes identified in this option according 4686 to its configuration to select the appropriate configuration 4687 information for the client. A server may use only those user classes 4688 that it is configured to interpret in selecting configuration 4689 information for a client and ignore any other user classes. In 4690 response to a message containing a User Class option, a server 4691 includes a User Class option containing those classes that were 4692 successfully interpreted by the server, so that the client can be 4693 informed of the classes interpreted by the server. 4695 20.16. Vendor Class Option 4697 This option is used by a client to identify the vendor that 4698 manufactured the hardware on which the client is running. The 4699 information contained in the data area of this option is contained in 4700 one or more opaque fields that identify details of the hardware 4701 configuration. The format of the Vendor Class option is: 4703 0 1 2 3 4704 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 4705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4706 | OPTION_VENDOR_CLASS | option-len | 4707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4708 | enterprise-number | 4709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4710 . . 4711 . vendor-class-data . 4712 . . . . . 4713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4715 Figure 26: Vendor Class Option Format 4717 option-code OPTION_VENDOR_CLASS (16). 4719 option-len 4 + length of vendor class data field. 4721 enterprise-number The vendor's registered Enterprise Number as 4722 registered with IANA [IANA-PEN]. 4724 vendor-class-data The hardware configuration of the host on 4725 which the client is running. 4727 The vendor-class-data is composed of a series of separate items, each 4728 of which describes some characteristic of the client's hardware 4729 configuration. Examples of vendor-class-data instances might include 4730 the version of the operating system the client is running or the 4731 amount of memory installed on the client. 4733 Each instance of the vendor-class-data is formatted as follows: 4735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4736 | vendor-class-len | opaque-data | 4737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4739 Figure 27: Vendor Class Data Format 4741 The vendor-class-len is two octets long and specifies the length of 4742 the opaque vendor class data in network byte order. 4744 Servers and clients MUST NOT include more than one instance of 4745 OPTION_VENDOR_CLASS with the same Enterprise Number. Each instance 4746 of OPTION_VENDOR_CLASS can carry multiple sub-options. 4748 20.17. Vendor-specific Information Option 4750 This option is used by clients and servers to exchange vendor- 4751 specific information. 4753 The format of the Vendor-specific Information option is: 4755 0 1 2 3 4756 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 4757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4758 | OPTION_VENDOR_OPTS | option-len | 4759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4760 | enterprise-number | 4761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4762 . . 4763 . option-data . 4764 . . 4765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4767 Figure 28: Vendor-specific Information Option Format 4769 option-code OPTION_VENDOR_OPTS (17). 4771 option-len 4 + length of option-data field. 4773 enterprise-number The vendor's registered Enterprise Number as 4774 registered with IANA [IANA-PEN]. 4776 option-data An opaque object, interpreted by vendor- 4777 specific code on the clients and servers. 4779 The definition of the information carried in this option is vendor 4780 specific. The vendor is indicated in the enterprise-number field. 4781 Use of vendor-specific information allows enhanced operation, 4782 utilizing additional features in a vendor's DHCP implementation. A 4783 DHCP client that does not receive requested vendor-specific 4784 information will still configure the host device's IPv6 stack to be 4785 functional. 4787 The encapsulated vendor-specific options field MUST be encoded as a 4788 sequence of code/length/value fields of identical format to the DHCP 4789 options field. The option codes are defined by the vendor identified 4790 in the enterprise-number field and are not managed by IANA. Each of 4791 the encapsulated options is formatted as follows: 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 | opt-code | option-len | 4797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4798 . . 4799 . option-data . 4800 . . 4801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4803 Figure 29: Vendor-specific Options Format 4805 opt-code The code for the encapsulated option. 4807 option-len An unsigned integer giving the length of the 4808 option-data field in this encapsulated option 4809 in octets. 4811 option-data The data area for the encapsulated option. 4813 Multiple instances of the Vendor-specific Information option may 4814 appear in a DHCP message. Each instance of the option is interpreted 4815 according to the option codes defined by the vendor identified by the 4816 Enterprise Number in that option. Servers and clients MUST NOT send 4817 more than one instance of Vendor-specific Information option with the 4818 same Enterprise Number. Each instance of Vendor-specific Information 4819 option MAY contain multiple encapsulated options. 4821 A client that is interested in receiving a Vendor-specific 4822 Information Option: 4824 - MUST specify the Vendor-specific Information Option in an Option 4825 Request Option. 4827 - MAY specify an associated Vendor Class Option. 4829 - MAY specify the Vendor-specific Information Option with any data. 4831 Severs only return the Vendor-specific Information Options if 4832 specified in Option Request Options from clients and: 4834 - MAY use the Enterprise Numbers in the associated Vendor Class 4835 Options to restrict the set of Enterprise Numbers in the Vendor- 4836 specific Information Options returned. 4838 - MAY return all configured Vendor-specific Information Options. 4840 - MAY use other information in the packet or in its configuration to 4841 determine which set of Enterprise Numbers in the Vendor-specific 4842 Information Options to return. 4844 20.18. Interface-Id Option 4846 The relay agent MAY send the Interface-id option to identify the 4847 interface on which the client message was received. If a relay agent 4848 receives a Relay-reply message with an Interface-id option, the relay 4849 agent relays the message to the client through the interface 4850 identified by the option. 4852 The format of the Interface ID option is: 4854 0 1 2 3 4855 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 4856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4857 | OPTION_INTERFACE_ID | option-len | 4858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4859 . . 4860 . interface-id . 4861 . . 4862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4864 Figure 30: Interface-ID Option Format 4866 option-code OPTION_INTERFACE_ID (18). 4868 option-len Length of interface-id field. 4870 interface-id An opaque value of arbitrary length generated 4871 by the relay agent to identify one of the 4872 relay agent's interfaces. 4874 The server MUST copy the Interface-Id option from the Relay-forward 4875 message into the Relay-reply message the server sends to the relay 4876 agent in response to the Relay-forward message. This option MUST NOT 4877 appear in any message except a Relay-forward or Relay-reply message. 4879 Servers MAY use the Interface-ID for parameter assignment policies. 4880 The Interface-ID SHOULD be considered an opaque value, with policies 4881 based on exact match only; that is, the Interface-ID SHOULD NOT be 4882 internally parsed by the server. The Interface-ID value for an 4883 interface SHOULD be stable and remain unchanged, for example, after 4884 the relay agent is restarted; if the Interface-ID changes, a server 4885 will not be able to use it reliably in parameter assignment policies. 4887 20.19. Reconfigure Message Option 4889 A server includes a Reconfigure Message option in a Reconfigure 4890 message to indicate to the client whether the client responds with a 4891 Renew message, a Rebind message, or an Information-request message. 4892 The format of this option is: 4894 0 1 2 3 4895 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 4896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4897 | OPTION_RECONF_MSG | option-len | 4898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4899 | msg-type | 4900 +-+-+-+-+-+-+-+-+ 4902 Figure 31: Reconfigure Message Option Format 4904 option-code OPTION_RECONF_MSG (19). 4906 option-len 1. 4908 msg-type 5 for Renew message, 6 for Rebind, 11 for 4909 Information-request message. 4911 The Reconfigure Message option can only appear in a Reconfigure 4912 message. 4914 20.20. Reconfigure Accept Option 4916 A client uses the Reconfigure Accept option to announce to the server 4917 whether the client is willing to accept Reconfigure messages, and a 4918 server uses this option to tell the client whether or not to accept 4919 Reconfigure messages. The default behavior, in the absence of this 4920 option, means unwillingness to accept Reconfigure messages, or 4921 instruction not to accept Reconfigure messages, for the client and 4922 server messages, respectively. The following figure gives the format 4923 of the Reconfigure Accept option: 4925 0 1 2 3 4926 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 4927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4928 | OPTION_RECONF_ACCEPT | 0 | 4929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4931 Figure 32: Reconfigure Accept Option Format 4933 option-code OPTION_RECONF_ACCEPT (20). 4935 option-len 0. 4937 20.21. Identity Association for Prefix Delegation Option 4939 The IA_PD option is used to carry a prefix delegation identity 4940 association, the parameters associated with the IA_PD and the 4941 prefixes associated with it. 4943 0 1 2 3 4944 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 4945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4946 | OPTION_IA_PD | option-length | 4947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4948 | IAID (4 octets) | 4949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4950 | T1 | 4951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4952 | T2 | 4953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4954 . . 4955 . IA_PD-options . 4956 . . 4957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4959 Figure 33: Identity Association for Prefix Delegation Option Format 4961 option-code OPTION_IA_PD (25). 4963 option-length 12 + length of IA_PD-options field. 4965 IAID The unique identifier for this IA_PD; the 4966 IAID must be unique among the identifiers for 4967 all of this requesting router's IA_PDs. 4969 T1 The time at which the requesting router 4970 should contact the delegating router from 4971 which the prefixes in the IA_PD were obtained 4972 to extend the lifetimes of the prefixes 4973 delegated to the IA_PD; T1 is a time duration 4974 relative to the current time expressed in 4975 units of seconds. 4977 T2 The time at which the requesting router 4978 should contact any available delegating 4979 router to extend the lifetimes of the 4980 prefixes assigned to the IA_PD; T2 is a time 4981 duration relative to the current time 4982 expressed in units of seconds. 4984 IA_PD-options Options associated with this IA_PD. 4986 The IA_PD-options field encapsulates those options that are specific 4987 to this IA_PD. For example, all of the IA_PD Prefix Options carrying 4988 the prefixes associated with this IA_PD are in the IA_PD-options 4989 field. 4991 An IA_PD option may only appear in the options area of a DHCP 4992 message. A DHCP message may contain multiple IA_PD options. 4994 The status of any operations involving this IA_PD is indicated in a 4995 Status Code option in the IA_PD-options field. 4997 Note that an IA_PD has no explicit "lifetime" or "lease length" of 4998 its own. When the valid lifetimes of all of the prefixes in a IA_PD 4999 have expired, the IA_PD can be considered as having expired. T1 and 5000 T2 are included to give delegating routers explicit control over when 5001 a requesting router should contact the delegating router about a 5002 specific IA_PD. 5004 In a message sent by a requesting router to a delegating router, the 5005 T1 and T2 fields SHOULD be set to 0. The delegating router MUST 5006 ignore any values in these fields in messages received from a 5007 requesting router. 5009 In a message sent by a delegating router to a requesting router, the 5010 delegating router MUST use the values in the T1 and T2 fields for the 5011 T1 and T2 parameters, unless those values in those fields are 0. The 5012 values in the T1 and T2 fields are the number of seconds until T1 and 5013 T2. 5015 The delegating router selects the T1 and T2 times to allow the 5016 requesting router to extend the lifetimes of any prefixes in the 5017 IA_PD before the lifetimes expire, even if the delegating router is 5018 unavailable for some short period of time. Recommended values for T1 5019 and T2 are .5 and .8 times the shortest preferred lifetime of the 5020 prefixes in the IA_PD that the delegating router is willing to 5021 extend, respectively. If the time at which the prefixes in an IA_PD 5022 are to be renewed is to be left to the discretion of the requesting 5023 router, the delegating router sets T1 and T2 to 0. The requesting 5024 router MUST follow the rules defined in Section 13.2. 5026 If a delegating router receives an IA_PD with T1 greater than T2, and 5027 both T1 and T2 are greater than 0, the delegating router ignores the 5028 invalid values of T1 and T2 and processes the IA_PD as though the 5029 requesting router had set T1 and T2 to 0. 5031 If a requesting router receives an IA_PD with T1 greater than T2, and 5032 both T1 and T2 are greater than 0, the requesting router discards the 5033 IA_PD option and processes the remainder of the message as though the 5034 requesting router had not included the IA_PD option. 5036 20.22. IA Prefix Option 5038 The IA_PD Prefix option is used to specify IPv6 address prefixes 5039 associated with an IA_PD. The IA_PD Prefix option must be 5040 encapsulated in the IA_PD-options field of an IA_PD option. 5042 0 1 2 3 5043 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 5044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5045 | OPTION_IAPREFIX | option-length | 5046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5047 | preferred-lifetime | 5048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5049 | valid-lifetime | 5050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5051 | prefix-length | | 5052 +-+-+-+-+-+-+-+-+ IPv6 prefix | 5053 | (16 octets) | 5054 | | 5055 | | 5056 | | 5057 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5058 | | . 5059 +-+-+-+-+-+-+-+-+ . 5060 . IAprefix-options . 5061 . . 5062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5064 Figure 34: IA Prefix Option Format 5066 option-code OPTION_IAPREFIX (26). 5068 option-length 25 + length of IAprefix-options field. 5070 preferred-lifetime The recommended preferred lifetime for the 5071 IPv6 prefix in the option, expressed in units 5072 of seconds. A value of 0xFFFFFFFF represents 5073 infinity. 5075 valid-lifetime The valid lifetime for the IPv6 prefix in the 5076 option, expressed in units of seconds. A 5077 value of 0xFFFFFFFF represents infinity. 5079 prefix-length Length for this prefix in bits. 5081 IPv6-prefix An IPv6 prefix. 5083 IAprefix-options Options associated with this prefix. 5085 In a message sent by a requesting router to a delegating router, the 5086 preferred and valid lifetime fields SHOULD be set to 0. The server 5087 MUST ignore any received values in these lifetime fields. 5089 A requesting router may set the IPv6 prefix field to zero and a given 5090 value in the prefix-length field to indicate a preference for the 5091 size of the prefix to be delegated. 5093 In a message sent by a delegating router the preferred and valid 5094 lifetimes should be set to the values of AdvPreferredLifetime and 5095 AdvValidLifetime as specified in section 6.2.1, "Router Configuration 5096 Variables" of [RFC2461], unless administratively configured. 5098 A requesting router discards any prefixes for which the preferred 5099 lifetime is greater than the valid lifetime. A delegating router 5100 ignores the lifetimes set by the requesting router if the preferred 5101 lifetime is greater than the valid lifetime and ignores the values 5102 for T1 and T2 set by the requesting router if those values are 5103 greater than the preferred lifetime. 5105 The values in the preferred and valid lifetimes are the number of 5106 seconds remaining for each lifetime. 5108 An IA_PD Prefix option may appear only in an IA_PD option. More than 5109 one IA_PD Prefix Option can appear in a single IA_PD option. 5111 The status of any operations involving this IA_PD Prefix option is 5112 indicated in a Status Code option in the IAprefix-options field. 5114 20.23. SOL_MAX_RT Option 5116 A DHCP server sends the SOL_MAX_RT option to a client to override the 5117 default value of SOL_MAX_RT. The value of SOL_MAX_RT in the option 5118 replaces the default value defined in Section 6.5. One use for the 5119 SOL_MAX_RT option is to set a longer value for SOL_MAX_RT, which 5120 reduces the Solicit traffic from a client that has not received a 5121 response to its Solicit messages. 5123 The format of the SOL_MAX_RT option is: 5125 0 1 2 3 5126 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 5127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5128 | option-code | option-len | 5129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5130 | SOL_MAX_RT value | 5131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5133 Figure 35: SOL_MAX_RT Option Format 5135 option-code OPTION_SOL_MAX_RT (82). 5137 option-len 4. 5139 SOL_MAX_RT value Overriding value for SOL_MAX_RT in seconds; 5140 MUST be in range: 60 <= "value" <= 86400 (1 5141 day). 5143 A DHCP client MUST include the SOL_MAX_RT option code in any Option 5144 Request option (see Section 20.7) it sends. 5146 The DHCP server MAY include the SOL_MAX_RT option in any response it 5147 sends to a client that has included the SOL_MAX_RT option code in an 5148 Option Request option. The SOL_MAX_RT option is sent in the main 5149 body of the message to client, not as an encapsulated option in, 5150 e.g., an IA_NA, IA_TA, or IA_PD option. 5152 A DHCP client MUST ignore any SOL_MAX_RT option values that are less 5153 than 60 or more than 86400. 5155 If a DHCP client receives a message containing a SOL_MAX_RT option 5156 that has a valid value for SOL_MAX_RT, the client MUST set its 5157 internal SOL_MAX_RT parameter to the value contained in the 5158 SOL_MAX_RT option. This value of SOL_MAX_RT is then used by the 5159 retransmission mechanism defined in Section 14 and Section 17.1.1. 5161 Updated SOL_MAX_RT value applies only to the network interface on 5162 which the client received SOL_MAX_RT option. 5164 20.24. INF_MAX_RT Option 5166 A DHCP server sends the INF_MAX_RT option to a client to override the 5167 default value of INF_MAX_RT. The value of INF_MAX_RT in the option 5168 replaces the default value defined in Section 6.5. One use for the 5169 INF_MAX_RT option is to set a longer value for INF_MAX_RT, which 5170 reduces the Information-request traffic from a client that has not 5171 received a response to its Information-request messages. 5173 The format of the INF_MAX_RT option is: 5175 0 1 2 3 5176 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 5177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5178 | option-code | option-len | 5179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5180 | INF_MAX_RT value | 5181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5183 Figure 36: INF_MAX_RT Option Format 5185 option-code OPTION_INF_MAX_RT (83). 5187 option-len 4. 5189 SOL_MAX_RT value Overriding value for INF_MAX_RT in seconds; 5190 MUST be in range: 60 <= "value" <= 86400 (1 5191 day). 5193 A DHCP client MUST include the INF_MAX_RT option code in any Option 5194 Request option (see Section 20.7) it sends. 5196 The DHCP server MAY include the INF_MAX_RT option in any response it 5197 sends to a client that has included the INF_MAX_RT option code in an 5198 Option Request option. The INF_MAX_RT option is sent in the main 5199 body of the message to client, not as an encapsulated option in, 5200 e.g., an IA_NA, IA_TA, or IA_PD option. 5202 A DHCP client MUST ignore any INF_MAX_RT option values that are less 5203 than 60 or more than 86400. 5205 If a DHCP client receives a message containing an INF_MAX_RT option 5206 that has a valid value for INF_MAX_RT, the client MUST set its 5207 internal INF_MAX_RT parameter to the value contained in the 5208 INF_MAX_RT option. This value of INF_MAX_RT is then used by the 5209 retransmission mechanism defined in Section 14 and Section 17.1.6. 5211 Updated INF_MAX_RT value applies only to the network interface on 5212 which the client received INF_MAX_RT option. 5214 20.25. Information Refresh Time Option 5216 A client running in stateless mode requests this option. The server 5217 includes this option in its response to specify an upper bound for 5218 how long a client should wait before refreshing the information. 5219 Clients that support stateless mode MUST support this option. This 5220 option is listed here for completeteness. For complete reference, 5221 see [RFC4242]. 5223 21. Security Considerations 5225 This section discusses security considerations that are not related 5226 to privacy. For dedicated privacy discussion, see Section 22. 5228 The threat to DHCP is inherently an insider threat (assuming a 5229 properly configured network where DHCP ports are blocked on the 5230 perimeter gateways of the enterprise). Regardless of the gateway 5231 configuration, however, the potential attacks by insiders and 5232 outsiders are the same. 5234 Use of manually configured preshared keys for IPsec between relay 5235 agents and servers does not defend against replayed DHCP messages. 5236 Replayed messages can represent a DOS attack through exhaustion of 5237 processing resources, but not through mis-configuration or exhaustion 5238 of other resources such as assignable addresses. 5240 One attack specific to a DHCP client is the establishment of a 5241 malicious server with the intent of providing incorrect configuration 5242 information to the client. The motivation for doing so may be to 5243 mount a "man in the middle" attack that causes the client to 5244 communicate with a malicious server instead of a valid server for 5245 some service such as DNS or NTP. The malicious server may also mount 5246 a denial of service attack through misconfiguration of the client 5247 that causes all network communication from the client to fail. 5249 A malicious DHCP server might cause a client to set its SOL_MAX_RT 5250 and INF_MAX_RT parameters to an unreasonably high value with the 5251 SOL_MAX_RT and INF_MAX_RT options, which may cause an undue delay in 5252 a client completing its DHCP protocol transaction in the case no 5253 other valid response is received. Assuming the client also receives 5254 a response from a valid DHCP server, large values for SOL_MAX_RT and 5255 INF_MAX_RT will not have any effect. 5257 There is another threat to DHCP clients from mistakenly or 5258 accidentally configured DHCP servers that answer DHCP client requests 5259 with unintentionally incorrect configuration parameters. 5261 A DHCP client may also be subject to attack through the receipt of a 5262 Reconfigure message from a malicious server that causes the client to 5263 obtain incorrect configuration information from that server. Note 5264 that although a client sends its response (Renew or Information- 5265 request message) through a relay agent and, therefore, that response 5266 will only be received by servers to which DHCP messages are relayed, 5267 a malicious server could send a Reconfigure message to a client, 5268 followed (after an appropriate delay) by a Reply message that would 5269 be accepted by the client. Thus, a malicious server that is not on 5270 the network path between the client and the server may still be able 5271 to mount a Reconfigure attack on a client. The use of transaction 5272 IDs that are cryptographically sound and cannot easily be predicted 5273 will also reduce the probability that such an attack will be 5274 successful. 5276 Many of these rogue server attacks can be mitigated by making use of 5277 the mechanism described in [RFC7610]. 5279 The threat specific to a DHCP server is an invalid client 5280 masquerading as a valid client. The motivation for this may be for 5281 theft of service, or to circumvent auditing for any number of 5282 nefarious purposes. 5284 The threat common to both the client and the server is the resource 5285 "denial of service" (DoS) attack. These attacks typically involve 5286 the exhaustion of available addresses, or the exhaustion of CPU or 5287 network bandwidth, and are present anytime there is a shared 5288 resource. 5290 In the case where relay agents add additional options to Relay 5291 Forward messages, the messages exchanged between relay agents and 5292 servers may be used to mount a "man in the middle" or denial of 5293 service attack. 5295 This threat model does not consider the privacy of the contents of 5296 DHCP messages to be important. DHCP is not used to exchange 5297 authentication or configuration information that must be kept secret 5298 from other networks nodes. 5300 Because of the opportunity for attack through the Reconfigure 5301 message, a DHCP client MUST discard any Reconfigure message that does 5302 not include authentication or that does not pass the validation 5303 process for the authentication protocol. 5305 The Reconfigure Key protocol described in Section 19.4 provides 5306 protection against the use of a Reconfigure message by a malicious 5307 DHCP server to mount a denial of service or man-in-the-middle attack 5308 on a client. This protocol can be compromised by an attacker that 5309 can intercept the initial message in which the DHCP server sends the 5310 key to the client. 5312 Communication between a server and a relay agent, and communication 5313 between relay agents, can be secured through the use of IPsec, as 5314 described in Section 19.1. The use of manual configuration and 5315 installation of static keys are acceptable in this instance because 5316 relay agents and the server will belong to the same administrative 5317 domain and the relay agents will require other specific configuration 5318 (for example, configuration of the DHCP server address) as well as 5319 the IPsec configuration. 5321 A rogue delegating router can issue bogus prefixes to a requesting 5322 router. This may cause denial of service due to unreachability. 5324 A malicious requesting router may be able to mount a denial of 5325 service attack by repeated requests for delegated prefixes that 5326 exhaust the delegating router's available prefixes. 5328 Because a requesting router and delegating routers must each have at 5329 least one assigned IPv6 address, the routers may be able to use IPsec 5330 for authentication of DHCP messages. The details of using IPsec for 5331 DHCP are under development. For point to point links, where one 5332 trusts that there is no man in the middle, or one trusts layer two 5333 authentication, IPsec may not be necessary. 5335 Networks configured with delegated prefixes should be configured to 5336 preclude intentional or inadvertent inappropriate advertisement of 5337 these prefixes. 5339 22. Privacy Considerations 5341 This section focuses on the server considerations. For extended 5342 discussion about privacy considerations for the client, see 5343 [RFC7824]. It particular, Section 3 of said document discuss various 5344 identifiers that could be misused to track the client. Section 4 5345 discusses existing mechanisms that may have an impact on client's 5346 privacy. Finally, Section 5 discusses potential attack vectors. For 5347 recommendations how to address or mitigate those issues, see 5348 [RFC7844]. 5350 This specification does not define any allocation strategies. 5351 Implementers are expected to develop their own algorithm for the 5352 server to choose a resource out of the available pool. Several 5353 possible allocation strategies are mentioned in Section 4.3 of 5354 [RFC7824]. Please keep in mind that this list is not exhaustive and 5355 there are certainly possible other strategies. Here are some 5356 observations for the implementer to consider. 5358 Assigning addresses using some kind of sequential algorithm 5359 (prefix::1, prefix::2, prefix::3,...) is fast, but greatly facilitate 5360 scanning of the network. Also, it makes any attacks that require 5361 guessing the next address much easier to conduct. 5363 Deriving the IID (Interface Identifier) part of the addresses from 5364 the link layer address of the client exposes information about the 5365 client hardware and enables tracking the client across multiple 5366 subnets. Also, since the address will likely be used to access 5367 remote services, this tracking can be conducted remotely. 5369 23. IANA Considerations 5371 This document does not define any new DHCP name spaces or 5372 definitions. 5374 IANA is requested to update the http://www.iana.org/assignments/ 5375 dhcpv6-parameters/dhcpv6-parameters.xhtml page to add a reference to 5376 this document for definitions previously created by [RFC3315], 5377 [RFC3633], and [RFC7083]. 5379 IANA is requested to add a column to the DHCPv6 Option table at 5380 http://www.iana.org/assignments/dhcpv6-parameters/ 5381 dhcpv6-parameters.xhtml to indicate which Options are allowed to 5382 appear in the ORO option. See Section 20.7. 5384 IANA is requested to update the http://www.iana.org/assignments/ 5385 bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#authentication- 5386 protocol-id page to add an "Obsolete" annotation into the "DHCPv6 5387 Delayed Authentication" entity in the "Authentication Suboption 5388 (value 8) - Protocol identifier values" registry, and 5389 https://www.iana.org/assignments/auth-namespaces/auth- 5390 namespaces.xhtml page to add an "Obsolete" annotation into the 5391 "Delayed Authentication" entity in the "Protocol Name Space Values" 5392 registry. 5394 The publication of this document does not change the assignment rules 5395 for new values for message types, option codes, DUID types or status 5396 codes. 5398 The list of assigned values used in DHCPv6 is available at 5399 http://www.iana.org/assignments/dhcpv6-parameters/ 5400 dhcpv6-parameters.xml 5402 Note to IANA: is this the right, long term link? I noticed there are 5403 two similar ones ending with .xhtml and .xml. Please update the link 5404 above if necessary. 5406 24. Obsoleted mechanisms 5408 This specification is mostly a corrected and cleaned up version of 5409 the original specification, [RFC3315], along with numerous additions 5410 from later RFCs. However, there is a small number of mechanisms that 5411 didn't get much traction, were not widely deployed, underspecified or 5412 had other operational issues. Those mechanisms are now considered 5413 deprecated. Legacy implementations MAY support them, but 5414 implementations conformant to this document MUST NOT rely on them. 5416 The following mechanism are now obsolete: 5418 Delayed Authentication. This mechanism was underspecified and had 5419 significant operational burden. As a result, after 10 years its 5420 adoption was extremely limited at best. 5422 Lifetime hints sent by a client. Client used to be allowed to send 5423 lifetime values as hints. This mechanism was not widely implemented 5424 and there were known misimplementations that sent remaining lifetimes 5425 rather than total lifetimes. That in turn was sometimes 5426 misunderstood by the servers as a request for ever decreasing lease 5427 lifetimes, which caused issues when values started approaching zero. 5429 25. Acknowledgments 5431 The following people are authors of the original RFC 3315: Ralph 5432 Droms, Jim Bound, Bernie Volz, Ted Lemon, Charles Perkins, and Mike 5433 Carney. The following people are authors of the original RFC 3633: 5434 Ole Troan and Ralph Droms. This document is merely a refinement of 5435 their work and would not be possible without their original work. 5437 A number of additional people have contributed to identifying issues 5438 with RFC 3315 and RFC 3633 and proposed resolutions to these issues 5439 as reflected in this document (in no particular order): Ole Troan, 5440 Robert Marks, Leaf Yeh, Tim Winters, Michelle Cotton, Pablo Armando, 5441 John Brzozowski, Suresh Krishnan, Hideshi Enokihara, Alexandru 5442 Petrescu, Yukiyo Akisada, Tatuya Jinmei, Fred Templin and Christian 5443 Huitema. With special thanks to Ralph Droms for answering many 5444 questions related to the original RFC 3315 work. 5446 The following acknowledgements are from the original RFC 3315 and RFC 5447 3633: 5449 Thanks to the DHC Working Group and the members of the IETF for their 5450 time and input into the specification. In particular, thanks also 5451 for the consistent input, ideas, and review by (in alphabetical 5452 order) Bernard Aboba, Bill Arbaugh, Thirumalesh Bhat, Steve Bellovin, 5453 A. K. Vijayabhaskar, Brian Carpenter, Matt Crawford, Steve Deering, 5454 Francis Dupont, Dave Forster, Brian Haberman, Richard Hussong, Tatuya 5455 Jinmei, Kim Kinnear, Fredrik Lindholm, Tony Lindstrom, Josh 5456 Littlefield, Gerald Maguire, Jack McCann, Shin Miyakawa, Thomas 5457 Narten, Erik Nordmark, Jarno Rajahalme, Yakov Rekhter, Pekka Savola, 5458 Mark Stapp, Matt Thomas, Sue Thomson, Tatuya Jinmei, Bernie Volz, 5459 Trevor Warwick, Phil Wells and Toshi Yamasaki. 5461 Thanks to Steve Deering and Bob Hinden, who have consistently taken 5462 the time to discuss the more complex parts of the IPv6 5463 specifications. 5465 And, thanks to Steve Deering for pointing out at IETF 51 in London 5466 that the DHCPv6 specification has the highest revision number of any 5467 Internet Draft. 5469 26. References 5471 26.1. Normative References 5473 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 5474 DOI 10.17487/RFC0768, August 1980, 5475 . 5477 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 5478 Converting Network Protocol Addresses to 48.bit Ethernet 5479 Address for Transmission on Ethernet Hardware", STD 37, 5480 RFC 826, DOI 10.17487/RFC0826, November 1982, 5481 . 5483 [RFC1035] Mockapetris, P., "Domain names - implementation and 5484 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 5485 November 1987, . 5487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5488 Requirement Levels", BCP 14, RFC 2119, 5489 DOI 10.17487/RFC2119, March 1997, 5490 . 5492 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 5493 RFC 2131, DOI 10.17487/RFC2131, March 1997, 5494 . 5496 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 5497 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 5498 . 5500 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 5501 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 5502 RFC 2136, DOI 10.17487/RFC2136, April 1997, 5503 . 5505 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 5506 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 5507 December 1998, . 5509 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 5510 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 5511 . 5513 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 5514 Addresses", RFC 2526, DOI 10.17487/RFC2526, March 1999, 5515 . 5517 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 5518 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 5519 DOI 10.17487/RFC3646, December 2003, 5520 . 5522 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 5523 Configuration Option for DHCPv6", RFC 4075, 5524 DOI 10.17487/RFC4075, May 2005, 5525 . 5527 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 5528 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 5529 2006, . 5531 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 5532 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 5533 December 2005, . 5535 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 5536 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 5537 DOI 10.17487/RFC4861, September 2007, 5538 . 5540 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 5541 Address Autoconfiguration", RFC 4862, 5542 DOI 10.17487/RFC4862, September 2007, 5543 . 5545 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 5546 Extensions for Stateless Address Autoconfiguration in 5547 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 5548 . 5550 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 5551 "Network Time Protocol Version 4: Protocol and Algorithms 5552 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 5553 . 5555 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 5556 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 5557 DOI 10.17487/RFC6221, May 2011, 5558 . 5560 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 5561 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 5562 DOI 10.17487/RFC6355, August 2011, 5563 . 5565 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 5566 "Default Address Selection for Internet Protocol Version 6 5567 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 5568 . 5570 [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT 5571 and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 5572 2013, . 5574 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 5575 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 5576 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 5577 . 5579 [RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 5580 Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014, 5581 . 5583 26.2. Informative References 5585 [I-D.ietf-dhc-dhcpv6-prefix-length-hint-issue] 5586 Cui, Y., Li, T., and C. Liu, "DHCPv6 Prefix Length Hint 5587 Issues", draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-02 5588 (work in progress), June 2016. 5590 [I-D.ietf-dhc-topo-conf] 5591 Lemon, T. and T. Mrugalski, "Customizing DHCP 5592 Configuration on the Basis of Network Topology", draft- 5593 ietf-dhc-topo-conf-08 (work in progress), May 2016. 5595 [IANA-PEN] 5596 IANA, "Private Enterprise Numbers registry 5597 http://www.iana.org/assignments/enterprise-numbers". 5599 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 5600 Discovery for IP Version 6 (IPv6)", RFC 2461, 5601 DOI 10.17487/RFC2461, December 1998, 5602 . 5604 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 5605 Autoconfiguration", RFC 2462, DOI 10.17487/RFC2462, 5606 December 1998, . 5608 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 5609 Stateless Address Autoconfiguration in IPv6", RFC 3041, 5610 DOI 10.17487/RFC3041, January 2001, 5611 . 5613 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 5614 RFC 3162, DOI 10.17487/RFC3162, August 2001, 5615 . 5617 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 5618 C., and M. Carney, "Dynamic Host Configuration Protocol 5619 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 5620 2003, . 5622 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 5623 Host Configuration Protocol (DHCP) version 6", RFC 3633, 5624 DOI 10.17487/RFC3633, December 2003, 5625 . 5627 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 5628 (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, 5629 April 2004, . 5631 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 5632 Delegation", RFC 3769, DOI 10.17487/RFC3769, June 2004, 5633 . 5635 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 5636 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 5637 . 5639 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 5640 Time Option for Dynamic Host Configuration Protocol for 5641 IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November 5642 2005, . 5644 [RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor 5645 Discovery On-Link Assumption Considered Harmful", 5646 RFC 4943, DOI 10.17487/RFC4943, September 2007, 5647 . 5649 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 5650 "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, 5651 September 2007, . 5653 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 5654 DOI 10.17487/RFC5460, February 2009, 5655 . 5657 [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. 5658 Troan, "Prefix Exclude Option for DHCPv6-based Prefix 5659 Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, 5660 . 5662 [RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6 5663 Reconfiguration from Relay Agents", RFC 6977, 5664 DOI 10.17487/RFC6977, July 2013, 5665 . 5667 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 5668 Requirements for IPv6 Customer Edge Routers", RFC 7084, 5669 DOI 10.17487/RFC7084, November 2013, 5670 . 5672 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 5673 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 5674 RFC 7341, DOI 10.17487/RFC7341, August 2014, 5675 . 5677 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 5678 Weil, "IPv6 Home Networking Architecture Principles", 5679 RFC 7368, DOI 10.17487/RFC7368, October 2014, 5680 . 5682 [RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and 5683 Recommendations with Multiple Stateful DHCPv6 Options", 5684 RFC 7550, DOI 10.17487/RFC7550, May 2015, 5685 . 5687 [RFC7563] Pazhyannur, R., Speicher, S., Gundavelli, S., Korhonen, 5688 J., and J. Kaippallimalil, "Extensions to the Proxy Mobile 5689 IPv6 (PMIPv6) Access Network Identifier Option", RFC 7563, 5690 DOI 10.17487/RFC7563, June 2015, 5691 . 5693 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 5694 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 5695 Configuration of Softwire Address and Port-Mapped 5696 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 5697 . 5699 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 5700 Protecting against Rogue DHCPv6 Servers", BCP 199, 5701 RFC 7610, DOI 10.17487/RFC7610, August 2015, 5702 . 5704 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 5705 Considerations for DHCPv6", RFC 7824, 5706 DOI 10.17487/RFC7824, May 2016, 5707 . 5709 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 5710 Profiles for DHCP Clients", RFC 7844, 5711 DOI 10.17487/RFC7844, May 2016, 5712 . 5714 [TR-187] Broadband Forum, "TR-187 - IPv6 for PPP Broadband Access", 5715 February 2013, . 5718 Appendix A. Changes since RFC3315 5720 Note: This appendix should be removed by the RFC-Editor when 5721 preparing the document for publication. 5723 1. Incorporated RFC3315 errata (ids: 294, 1373, 2928, 1815, 3577, 5724 2509, 295). 5726 2. Partially incorporated RFC3315 errata id 2472 (place other IA 5727 options if NoAddrsAvail is sent in Advertise). 5729 3. Clarified section 21.4.1 of RFC3315 by defining length of "key 5730 ID" field and specifying that 'DHCP realm' is Domain Name 5731 encoded as per section 8 of RFC3315. Ticket #43. 5733 4. Added DUID-UUID and reference to RFC6355. Ticket #54. 5735 5. Specified a minimum length for the DUID in section "9.1. DUID 5736 Contents". Ticket #39. 5738 6. Removed the use of term "sub-options" from section "19.1.1. 5739 Creation and Transmission of Reconfigure Messages". Ticket #40. 5741 7. Added text to section 22.6 "IA Address Option" about the usage 5742 of unspecified address to express the client hints for Preferred 5743 and Valid lifetimes. Ticket #45. 5745 8. Updated text in 21.4.2 of RFC3315 ("Message Validation") as 5746 suggested in section 3.1 of draft-ietf-dhc-dhcpv6-clarify-auth- 5747 01. Ticket #87. 5749 9. Merged RFC7083, "Modification to Default Values of SOL_MAX_RT 5750 and INF_MAX_RT", into this document. Ticket #51. 5752 10. Incorporated RFC3315 errata (id 2471), into section 17.1.3. 5753 Ticket #25. 5755 11. Added text that relay agents MUST NOT modify the relayed message 5756 to section 20.1.2. Ticket #57. 5758 12. Modified the text in section 21.4.4.5, Receiving Reply Messages, 5759 to remove special treatment of a Reply validation failure 5760 (client ignores message). Ticket #89. 5762 13. Appendix C updated: Authentication option is no longer allowed 5763 in Relay-forward and Relay-reply messages, ORO is no longer 5764 allowed in Confirm, Release and Decline messages; Preference 5765 option is no longer allowed in Reply messages (only in 5766 Advertise). Ticket #10. 5768 14. Removed "silently" from several instances of "silently ignores" 5769 or "silently" discards. It is up to software vendor if and how 5770 to log such events (debug log message, event log, message pop-up 5771 etc.). Ticket #50. 5773 15. Clarified that: there should be no more than one instance of 5774 Vendor Class option with a given Enterprise Number; that one 5775 instance of Vendor Class can contain multiple encapsulated 5776 options; the same applies to Vendor Specific Information option. 5777 Ticket #22. 5779 16. Clarified relay agent definition. Ticket #12. 5781 17. Changed REL_MAX_RC and DEC_MAX_RC defaults from 5 to 4 and added 5782 retry to parameter description. Ticket #84. 5784 18. Clarify handling process for Vendor-specific Information Option 5785 and Vendor Class Option. Ticket #20. 5787 19. Replace "monotonic" with "strictly monotonic" in Section 21.3. 5788 Ticket #11. 5790 20. Incorporate everything of RFC 6644, except for Security 5791 Considerations Section, which has already covered in a more 5792 abstracted way. Tickets #55 & #56. 5794 21. Clarify the server behavior process when a client violates 5795 Delayed Authentication Protocol, in Section 21.4. Ticket #90. 5797 22. Updated titles of sections 19.4.2. and 19.4.4. to include Rebind 5798 messages. 5800 23. Applied many of the review comments from a review done by Fred 5801 Templin in August 2006. Ticket #14. 5803 24. Reworded the first paragraph of Section 15 to relax the "SHOULD" 5804 requirement to drop the messages which contain the options not 5805 expected in the current message. Ticket #17. 5807 25. Changed WG to DHC on the first page header, added keywords. 5809 26. Loosened requirements for DUID-EN, so that DUID type can be used 5810 for virtual machines. Ticket #16. 5812 27. Clarified that IA may contain other resources than just address. 5813 Ticket #93. 5815 28. Clarified that most options are singletons (i.e. can appear only 5816 once). Ticket #83. 5818 29. Merged sections 1 (Ticket #96), 2 (Ticket #97), 3 (Ticket #98), 5819 4 (Ticket #99), 6 (Ticket #101), 8 (Ticket #103), 9 (Ticket 5820 #104), 10 (Ticket #105), 11 (Ticket #106), 13 (Ticket #108), 14 5821 (Ticket #109), 15 (Ticket #110), 16 (Ticket #111), 17 (Ticket 5822 #112) and 19 (Ticket #113) from RFC3633 (Prefix Delegation). 5824 30. Clarified that encapsulated options must be requested using top- 5825 level ORO (ticket #38). 5827 31. Clarified that configuration for interface X should be requested 5828 over interface X (ticket #48). 5830 32. CONFIRM is now an optional message (MUST send Confirm eased to 5831 SHOULD) (ticket #120). 5833 33. Added reference to RFC7227: DHCPv6 Option Guidelines (ticket 5834 #121). 5836 34. Added new section 5 providing an overview of DHCPv6 operational 5837 modes and removed two prefix delegation sections from section 1. 5838 See tickets #53, #100, and #102. 5840 35. Addressed ticket #115 - don't use DHCPv6 for DHCPv4 5841 configuration. 5843 36. Revised IANA Considerations based on ticket #117. 5845 37. Updated IAID description in the terminology with the 5846 clarification that the IAID is unique among IAs of a specific 5847 type, rather than globally unique among all IAs (ticket #94). 5849 38. Merged Section 12 from RFC3633 (ticket #107). 5851 39. Clarified behavior for unknown messages (RFC7283), ticket #58. 5853 40. Addressed tickets #123 and #126, and clarified that the client 5854 SHOULD abandon its bindings when restarts the server 5855 solicitation. 5857 41. Clarified link-address field usage, ticket #73. 5859 42. Clarified that retransmitting at client's discretion (t1,t2=0) 5860 does not mean immediate transmission (ticket #71). 5862 43. Merged section 4.4. of RFC7550 (stateful-issues). This includes 5863 new Renew and Rebind processing by the server, i.e. a client may 5864 request allocation of new addresses/prefixes during Renew and 5865 Rebind. This addresses tickets #62 and #63. 5867 44. Merged section 4.1 and 4.2 of RFC7550 (stateful-issues). This 5868 addresses tickets #59 and #60. 5870 45. Added normative reference to RFC7550 and to obsoleted list. 5871 Also added terse text of Abstract and section 1.0 to indicate 5872 what this document is about. 5874 46. Merged section 4.6 of RFC7550 (stateful-issues). This addresses 5875 ticket #85. 5877 47. Clarified that the document assumes single provisioning domain. 5878 This resolves ticket #66. 5880 48. Removed the Delayed Auth Protocol. This resolves ticket #86. 5882 49. Added text the text suggesting to not send all-zero address/ 5883 prefix unless the client wishes to hint the lifetimes and/or 5884 prefix lengths. This resolves ticket #82. 5886 50. Cleaned up Confirm text regarding rebooting client an stable 5887 storage. 5889 51. Updated server processing section to clarify that server unicast 5890 check can be based on current configuration of unicast setting 5891 so server is not required to remember what it sent. This 5892 resolves ticket #130. 5894 52. Removed references to lifetime hints from the client; only 5895 IAPREFIX prefix-length hints are now allowed. Servers will 5896 ignore any lifetime hints; clients should set lifetime to 0. 5897 This resolves ticket #148. Also, removed T1/T2 hints from 5898 clients to servers - while not explicitly discussed, seems to 5899 make sense? And, fixed some of the message processing text to 5900 include PD, not just addresses (though I think Marcin will 5901 eventually replace much of this text? Plus a few other minor 5902 edits. 5904 53. Clarified that the server may return different addresses in the 5905 Reply than requested by the client in the Request message. Also 5906 clarified that the server must not include addresses that it 5907 will not assign. This resolves ticket #69. 5909 54. Introduction updated, including relation to previous RFCs 5910 (ticket #136). 5912 55. Added section with deprecated mechanisms (ticket #149). 5914 56. Combined text for prefix delegation and address assignment in 5915 sections 18 and 19. Also, introduced a term "lease" replacing 5916 "allocable resources". This resolves ticket #146. 5918 57. Reorganized text about Reply processing on the client side 5919 (ticket #140). 5921 58. Revised the "Creation and Transmission of Release Messages" 5922 section to clarify what a client must do before initiating a 5923 Release (ticket #151). 5925 59. Privacy considerations added (ticket #145). 5927 60. Abstract updated. Ticket #133. 5929 61. Removed references to the text that server was allowed to cache 5930 its replies. Ticket #80. 5932 62. Merged sections 17, 18 and 19 into a single section describing 5933 client and server behaviors. Ticket #142. 5935 63. Added text about single session for multiple IA option types. 5936 Ticket #160. 5938 64. Moved additional text from RFC3633 section 12.1. Ticket #102. 5940 65. Addressed minor addition to text as per ticket 131 and also 5941 ticket #61. 5943 66. Clarified MUST perform DAD, excepting exceptions listed in 5944 RFC4862 Section 5.4. Ticket #153. 5946 67. Removed the requirement for the server to send Reconfigure 5947 Accept in Reply messages, also clarified why it's useful in 5948 Advertise. Ticket #154. 5950 68. Explicitly require Elapsed Time option to be placed in messages 5951 sent by a client. Ticket #159. 5953 69. Update section 14 - explained that Elapsed Time option (and 5954 possibly other options) must be updated prior to resending the 5955 message. Also included "retransmission" in the DHCP 5956 terminology. Ticket #157. 5958 70. Added text explaining that the client should stop using an 5959 option if it's not being sent by the server. Ticket #150. 5961 71. Added reference to RFC4242 (Information Refresh Time Option). 5962 Ticket #161. 5964 72. Updated ORO Option to list Options that MUST NOT be included. 5965 Also added to that IANA Consider should keep track of which 5966 options are allowed in ORO. Ticket #81. 5968 73. Updated Creation and Transmission of Advertise message so that 5969 the only options in the ORO will be included in the Advertise 5970 unless configured otherwise. Ticket #81. 5972 74. Information Refresh Time Option is now mandatory for clients 5973 that support stateless mode. Added reference to RFC4242. 5974 Ticket #161. 5976 Appendix B. Changes since RFC3633 5978 Note: This appendix should be removed by the RFC-Editor when 5979 preparing the document for publication. 5981 1. Incorporated RFC3633 errata (ids: 248, 1880, 2468, 2469, 2470, 5982 3736) 5984 Appendix C. Appearance of Options in Message Types 5986 The following table indicates with a "*" the options are allowed in 5987 each DHCP message type: 5989 Client Server IA_NA/ Elap. Relay Auth. Server 5990 ID ID IA_TA IA_PD ORO Pref Time Msg. Unicast 5991 Solicit * * * * * * 5992 Advert. * * * * * * 5993 Request * * * * * * * 5994 Confirm * * * * 5995 Renew * * * * * * * 5996 Rebind * * * * * * 5997 Decline * * * * * * 5998 Release * * * * * * 5999 Reply * * * * * * 6000 Reconf. * * * * 6001 Inform. * (see note) * * * 6002 R-forw. * 6003 R-repl. * 6005 NOTE: 6007 Only included in Information-request messages that are sent in 6008 response to a Reconfigure (see Section 17.1.6). 6010 Status Rap. User Vendor Vendor Inter. Recon. Recon. SOL_MAX_RT 6011 Code Comm. Class Class Spec. ID Msg. Accept INF_MAX_RT 6012 Solicit * * * * * 6013 Advert. * * * * * * 6014 Request * * * * 6015 Confirm * * * 6016 Renew * * * * 6017 Rebind * * * * 6018 Decline * * * 6019 Release * * * 6020 Reply * * * * * * * 6021 Reconf. * 6022 Inform. * * * * 6023 R-forw. * * * * 6024 R-repl. * * * * 6026 Appendix D. Appearance of Options in the Options Field of DHCP Options 6028 The following table indicates with a "*" where options can appear in 6029 the options field of other options: 6031 Option IA_NA/ Relay Relay 6032 Field IA_TA IAADDR IA_PD IAPREFIX Forw. Reply 6033 Client ID * 6034 Server ID * 6035 IA_NA/IA_TA * 6036 IAADDR * 6037 IA_PD * 6038 IAPREFIX * 6039 ORO * 6040 Preference * 6041 Elapsed Time * 6042 Relay Message * * 6043 Authentic. * 6044 Server Uni. * 6045 Status Code * * * 6046 Rapid Comm. * 6047 User Class * 6048 Vendor Class * 6049 Vendor Info. * * * 6050 Interf. ID * * 6051 Reconf. MSG. * 6052 Reconf. Accept * 6053 SOL_MAX_RT * 6054 INF_MAX_RT * 6056 Note: "Relay Forw" / "Relay Reply" options appear in the options 6057 field of the message but may only appear in these messages. 6059 Authors' Addresses 6061 Tomek Mrugalski (editor) 6062 Internet Systems Consortium, Inc. 6063 950 Charter Street 6064 Redwood City, CA 94063 6065 USA 6067 Email: tomasz.mrugalski@gmail.com 6069 Marcin Siodelski 6070 Internet Systems Consortium, Inc. 6071 950 Charter St. 6072 Redwood City, CA 94063 6073 USA 6075 Email: msiodelski@gmail.com 6076 Bernie Volz 6077 Cisco Systems, Inc. 6078 1414 Massachusetts Ave 6079 Boxborough, MA 01719 6080 USA 6082 Email: volz@cisco.com 6084 Andrew Yourtchenko 6085 Cisco Systems, Inc. 6086 De Kleetlaan, 7 6087 Diegem B-1831 6088 Belgium 6090 Email: ayourtch@cisco.com 6092 Michael C. Richardson 6093 Sandelman Software Works 6094 470 Dawson Avenue 6095 Ottawa, ON K1Z 5V7 6096 CA 6098 Email: mcr+ietf@sandelman.ca 6099 URI: http://www.sandelman.ca/ 6101 Sheng Jiang 6102 Huawei Technologies Co., Ltd 6103 Q14, Huawei Campus, No.156 Beiqing Road 6104 Hai-Dian District, Beijing, 100095 6105 P.R. China 6107 Email: jiangsheng@huawei.com 6109 Ted Lemon 6110 Nominum, Inc. 6111 800 Bridge St. 6112 Redwood City, CA 94043 6113 USA 6115 Email: Ted.Lemon@nominum.com 6116 Timothy Winters 6117 University of New Hampshire, Interoperability Lab (UNH-IOL) 6118 Durham, NH 6119 USA 6121 Email: twinters@iol.unh.edu