idnits 2.17.1 draft-ietf-dhc-rfc3315bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC7550, but the abstract doesn't seem to directly say this. It does mention RFC7550 though, so this could be OK. 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 (May 8, 2017) is 2544 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 7083 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 7283 (Obsoleted by RFC 8415) -- 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 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 7550 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 2 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,4242,7083,7550 ISC 5 (if approved) B. Volz 6 Intended status: Standards Track A. Yourtchenko 7 Expires: November 9, 2017 Cisco 8 M. Richardson 9 SSW 10 S. Jiang 11 Huawei 12 T. Lemon 13 Nominum 14 T. Winters 15 UNH-IOL 16 May 8, 2017 18 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis 19 draft-ietf-dhc-rfc3315bis-08 21 Abstract 23 This document describes the Dynamic Host Configuration Protocol for 24 IPv6 (DHCPv6): an extensible mechanism for configuring nodes 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 RFC3315, the original DHCPv6 32 specification, and incorporates prefix delegation (RFC3633), 33 stateless DHCPv6 (RFC3736), an option to specify an upper bound for 34 how long a client should wait before refreshing information 35 (RFC4242), a mechanism for throttling DHCPv6 clients when DHCPv6 36 service is not available (RFC7083), and clarifies the interactions 37 between modes of operation (RFC7550). As such, this document 38 obsoletes RFC3315, RFC3633, RFC3736, RFC4242, RFC7083, and RFC7550. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on November 9, 2017. 57 Copyright Notice 59 Copyright (c) 2017 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 This document may contain material from IETF Documents or IETF 73 Contributions published or made publicly available before November 74 10, 2008. The person(s) controlling the copyright in some of this 75 material may not have granted the IETF Trust the right to allow 76 modifications of such material outside the IETF Standards Process. 77 Without obtaining an adequate license from the person(s) controlling 78 the copyright in such materials, this document may not be modified 79 outside the IETF Standards Process, and derivative works of it may 80 not be created outside the IETF Standards Process, except to format 81 it for publication as an RFC or to translate it into languages other 82 than English. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 87 1.1. Relation to Previous DHCPv6 standards . . . . . . . . . . 6 88 1.2. Relation to DHCP in IPv4 . . . . . . . . . . . . . . . . 7 89 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 90 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 8 91 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 92 4.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 8 93 4.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 10 94 5. Client-Server Exchanges . . . . . . . . . . . . . . . . . . . 13 95 5.1. Client-server Exchanges Involving Two Messages . . . . . 14 96 5.2. Client-server Exchanges Involving Four Messages . . . . . 15 97 5.3. Server-client Exchanges . . . . . . . . . . . . . . . . . 15 99 6. Operational Models . . . . . . . . . . . . . . . . . . . . . 15 100 6.1. Stateless DHCP . . . . . . . . . . . . . . . . . . . . . 16 101 6.2. DHCP for Non-Temporary Address Assignment . . . . . . . . 16 102 6.3. DHCP for Prefix Delegation . . . . . . . . . . . . . . . 17 103 6.4. DHCP for Customer Edge Routers . . . . . . . . . . . . . 19 104 6.5. DHCP for Temporary Addresses . . . . . . . . . . . . . . 19 105 6.6. Multiple Addresses and Prefixes . . . . . . . . . . . . . 19 106 7. DHCP Constants . . . . . . . . . . . . . . . . . . . . . . . 20 107 7.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 20 108 7.2. UDP Ports . . . . . . . . . . . . . . . . . . . . . . . . 21 109 7.3. DHCP Message Types . . . . . . . . . . . . . . . . . . . 21 110 7.4. DHCP Option Codes . . . . . . . . . . . . . . . . . . . . 23 111 7.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 23 112 7.6. Transmission and Retransmission Parameters . . . . . . . 23 113 7.7. Representation of Time Values and "Infinity" as a Time 114 Value . . . . . . . . . . . . . . . . . . . . . . . . . . 24 115 8. Client/Server Message Formats . . . . . . . . . . . . . . . . 25 116 9. Relay Agent/Server Message Formats . . . . . . . . . . . . . 26 117 9.1. Relay-forward Message . . . . . . . . . . . . . . . . . . 27 118 9.2. Relay-reply Message . . . . . . . . . . . . . . . . . . . 27 119 10. Representation and Use of Domain Names . . . . . . . . . . . 27 120 11. DHCP Unique Identifier (DUID) . . . . . . . . . . . . . . . . 28 121 11.1. DUID Contents . . . . . . . . . . . . . . . . . . . . . 28 122 11.2. DUID Based on Link-layer Address Plus Time, DUID-LLT . . 29 123 11.3. DUID Assigned by Vendor Based on Enterprise Number, 124 DUID-EN . . . . . . . . . . . . . . . . . . . . . . . . 30 125 11.4. DUID Based on Link-layer Address, DUID-LL . . . . . . . 31 126 11.5. DUID Based on Universally Unique IDentifier (UUID), 127 DUID-UUID . . . . . . . . . . . . . . . . . . . . . . . 32 128 12. Identity Association . . . . . . . . . . . . . . . . . . . . 33 129 12.1. Identity Associations for Address Assignment . . . . . . 33 130 12.2. Identity Associations for Prefix Delegation . . . . . . 34 131 13. Assignment to an IA . . . . . . . . . . . . . . . . . . . . . 34 132 13.1. Selecting Addresses for Assignment to an IA_NA . . . . . 34 133 13.2. Assignment of Temporary Addresses . . . . . . . . . . . 35 134 13.3. Assignment of Prefixes for IA_PD . . . . . . . . . . . . 36 135 14. Transmission of Messages by a Client . . . . . . . . . . . . 36 136 14.1. Rate Limiting . . . . . . . . . . . . . . . . . . . . . 37 137 14.2. Client Behavior when T1 and/or T2 are 0 . . . . . . . . 37 138 15. Reliability of Client Initiated Message Exchanges . . . . . . 38 139 16. Message Validation . . . . . . . . . . . . . . . . . . . . . 40 140 16.1. Use of Transaction IDs . . . . . . . . . . . . . . . . . 40 141 16.2. Solicit Message . . . . . . . . . . . . . . . . . . . . 41 142 16.3. Advertise Message . . . . . . . . . . . . . . . . . . . 41 143 16.4. Request Message . . . . . . . . . . . . . . . . . . . . 41 144 16.5. Confirm Message . . . . . . . . . . . . . . . . . . . . 42 145 16.6. Renew Message . . . . . . . . . . . . . . . . . . . . . 42 146 16.7. Rebind Message . . . . . . . . . . . . . . . . . . . . . 42 147 16.8. Decline Messages . . . . . . . . . . . . . . . . . . . . 42 148 16.9. Release Message . . . . . . . . . . . . . . . . . . . . 43 149 16.10. Reply Message . . . . . . . . . . . . . . . . . . . . . 43 150 16.11. Reconfigure Message . . . . . . . . . . . . . . . . . . 43 151 16.12. Information-request Message . . . . . . . . . . . . . . 44 152 16.13. Relay-forward Message . . . . . . . . . . . . . . . . . 44 153 16.14. Relay-reply Message . . . . . . . . . . . . . . . . . . 44 154 17. Client Source Address and Interface Selection . . . . . . . . 44 155 17.1. Address, Interface Selection for Address Assignment . . 44 156 17.2. Address, Interface Selection for Prefix Delegation . . . 45 157 18. DHCP Configuration Exchanges . . . . . . . . . . . . . . . . 45 158 18.1. A Single Exchange for Multiple IA Options . . . . . . . 48 159 18.2. Client Behavior . . . . . . . . . . . . . . . . . . . . 49 160 18.2.1. Creation and Transmission of Solicit Messages . . . 50 161 18.2.2. Creation and Transmission of Request Messages . . . 53 162 18.2.3. Creation and Transmission of Confirm Messages . . . 54 163 18.2.4. Creation and Transmission of Renew Messages . . . . 55 164 18.2.5. Creation and Transmission of Rebind Messages . . . . 57 165 18.2.6. Creation and Transmission of Information-request 166 Messages . . . . . . . . . . . . . . . . . . . . . . 58 167 18.2.7. Creation and Transmission of Release Messages . . . 59 168 18.2.8. Creation and Transmission of Decline Messages . . . 60 169 18.2.9. Receipt of Advertise Messages . . . . . . . . . . . 61 170 18.2.10. Receipt of Reply Messages . . . . . . . . . . . . . 62 171 18.2.10.1. Reply for Solicit (with Rapid Commit), Request, 172 Renew or Rebind . . . . . . . . . . . . . . . . 63 173 18.2.10.2. Reply for Release and Decline . . . . . . . . . 66 174 18.2.10.3. Reply for Confirm . . . . . . . . . . . . . . . 66 175 18.2.10.4. Reply for Information-request . . . . . . . . . 66 176 18.2.11. Receipt of Reconfigure Messages . . . . . . . . . . 66 177 18.2.12. Refreshing Configuration Information . . . . . . . . 67 178 18.3. Server Behavior . . . . . . . . . . . . . . . . . . . . 68 179 18.3.1. Receipt of Solicit Messages . . . . . . . . . . . . 69 180 18.3.2. Receipt of Request Messages . . . . . . . . . . . . 70 181 18.3.3. Receipt of Confirm Messages . . . . . . . . . . . . 72 182 18.3.4. Receipt of Renew Messages . . . . . . . . . . . . . 72 183 18.3.5. Receipt of Rebind Messages . . . . . . . . . . . . . 74 184 18.3.6. Receipt of Information-request Messages . . . . . . 76 185 18.3.7. Receipt of Release Messages . . . . . . . . . . . . 77 186 18.3.8. Receipt of Decline Messages . . . . . . . . . . . . 78 187 18.3.9. Creation and Transmission of Advertise Messages . . 78 188 18.3.10. Transmission of Reply Messages . . . . . . . . . . . 80 189 18.3.11. Creation and Transmission of Reconfigure Messages . 80 190 18.4. Reception of Unicast Messages . . . . . . . . . . . . . 81 191 19. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 82 192 19.1. Relaying a Client Message or a Relay-forward Message . . 82 193 19.1.1. Relaying a Message from a Client . . . . . . . . . . 82 194 19.1.2. Relaying a Message from a Relay Agent . . . . . . . 83 195 19.1.3. Relay Agent Behavior with Prefix Delegation . . . . 83 196 19.2. Relaying a Relay-reply Message . . . . . . . . . . . . . 84 197 19.3. Construction of Relay-reply Messages . . . . . . . . . . 84 198 20. Authentication of DHCP Messages . . . . . . . . . . . . . . . 85 199 20.1. Security of Messages Sent Between Servers and Relay 200 Agents . . . . . . . . . . . . . . . . . . . . . . . . . 85 201 20.2. Summary of DHCP Authentication . . . . . . . . . . . . . 85 202 20.3. Replay Detection . . . . . . . . . . . . . . . . . . . . 86 203 20.4. Reconfigure Key Authentication Protocol . . . . . . . . 86 204 20.4.1. Use of the Authentication Option in the Reconfigure 205 Key Authentication Protocol . . . . . . . . . . . . 87 206 20.4.2. Server Considerations for Reconfigure Key 207 Authentication Protocol . . . . . . . . . . . . . . 88 208 20.4.3. Client Considerations for Reconfigure Key 209 Authentication Protocol . . . . . . . . . . . . . . 88 210 21. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 88 211 21.1. Format of DHCP Options . . . . . . . . . . . . . . . . . 89 212 21.2. Client Identifier Option . . . . . . . . . . . . . . . . 90 213 21.3. Server Identifier Option . . . . . . . . . . . . . . . . 90 214 21.4. Identity Association for Non-temporary Addresses Option 91 215 21.5. Identity Association for Temporary Addresses Option . . 93 216 21.6. IA Address Option . . . . . . . . . . . . . . . . . . . 95 217 21.7. Option Request Option . . . . . . . . . . . . . . . . . 96 218 21.8. Preference Option . . . . . . . . . . . . . . . . . . . 97 219 21.9. Elapsed Time Option . . . . . . . . . . . . . . . . . . 98 220 21.10. Relay Message Option . . . . . . . . . . . . . . . . . . 98 221 21.11. Authentication Option . . . . . . . . . . . . . . . . . 99 222 21.12. Server Unicast Option . . . . . . . . . . . . . . . . . 100 223 21.13. Status Code Option . . . . . . . . . . . . . . . . . . . 101 224 21.14. Rapid Commit Option . . . . . . . . . . . . . . . . . . 103 225 21.15. User Class Option . . . . . . . . . . . . . . . . . . . 104 226 21.16. Vendor Class Option . . . . . . . . . . . . . . . . . . 105 227 21.17. Vendor-specific Information Option . . . . . . . . . . . 107 228 21.18. Interface-Id Option . . . . . . . . . . . . . . . . . . 109 229 21.19. Reconfigure Message Option . . . . . . . . . . . . . . . 110 230 21.20. Reconfigure Accept Option . . . . . . . . . . . . . . . 110 231 21.21. Identity Association for Prefix Delegation Option . . . 111 232 21.22. IA Prefix Option . . . . . . . . . . . . . . . . . . . . 113 233 21.23. Information Refresh Time Option . . . . . . . . . . . . 114 234 21.24. SOL_MAX_RT Option . . . . . . . . . . . . . . . . . . . 116 235 21.25. INF_MAX_RT Option . . . . . . . . . . . . . . . . . . . 117 236 22. Security Considerations . . . . . . . . . . . . . . . . . . . 118 237 23. Privacy Considerations . . . . . . . . . . . . . . . . . . . 120 238 24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 121 239 25. Obsoleted Mechanisms . . . . . . . . . . . . . . . . . . . . 125 240 26. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 126 241 27. References . . . . . . . . . . . . . . . . . . . . . . . . . 126 242 27.1. Normative References . . . . . . . . . . . . . . . . . . 126 243 27.2. Informative References . . . . . . . . . . . . . . . . . 127 244 Appendix A. Summary of Changes . . . . . . . . . . . . . . . . . 132 245 Appendix B. Appearance of Options in Message Types . . . . . . . 135 246 Appendix C. Appearance of Options in the Options Field of DHCP 247 Options . . . . . . . . . . . . . . . . . . . . . . 137 248 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 138 250 1. Introduction 252 This document describes DHCP for IPv6 (DHCPv6), a client/server 253 protocol that provides managed configuration of devices. Relay agent 254 functionality is also defined for enabling communication between 255 clients and servers that are not on the same link. 257 DHCPv6 can provide a device with addresses assigned by a DHCPv6 258 server and other configuration information, which are carried in 259 options. DHCPv6 can be extended through the definition of new 260 options to carry configuration information not specified in this 261 document. 263 DHCPv6 also provides a mechanism for automated delegation of IPv6 264 prefixes using DHCPv6, originally specified in [RFC3633]. Through 265 this mechanism, a delegating router can delegate prefixes to 266 requesting routers. Use of this mechanism is specified as part of 267 the [RFC7084] and by [TR-187]. 269 DHCPv6 can also provide only other configuration options (i.e., no 270 addresses or prefixes). That implies that the server does not have 271 to track any state, and thus this mode is called stateless DHCPv6. 272 Mechanisms necessary to support stateless DHCPv6 are much smaller 273 than to support stateful DHCPv6. 275 The remainder of this introduction summarizes the relationship to the 276 previous DHCPv6 standards in Section 1.1 and clarifies the stance 277 with regards to DHCPv4 in Section 1.2. Section 5 describes the 278 message exchange mechanisms to illustrate DHCP operation rather than 279 provide an exhaustive list of all possible interactions and Section 6 280 provides an overview of common operational models. Section 18 281 explains client and server operation in detail. 283 1.1. Relation to Previous DHCPv6 standards 285 The initial specification of DHCPv6 was defined in [RFC3315] and a 286 number of follow up documents were published over the years: IPv6 287 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 288 6 [RFC3633], Stateless Dynamic Host Configuration Protocol (DHCP) 289 Service for IPv6s [RFC3736], Information Refresh Time Option for 290 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC4242], 291 Modification to Default Values of SOL_MAX_RT and INF_MAX_RT 292 [RFC7083], and Issues and Recommendations with Multiple Stateful 293 DHCPv6 Options [RFC7550]. This document provides a unified, 294 corrected, and cleaned up definition of DHCPv6 that also covers all 295 errata filled against older RFCs. As such, it obsoletes a number of 296 aforementioned RFCs. And, there are a small number of mechanisms 297 that were obsoleted, listed in Section 25. Also see Appendix A. 299 1.2. Relation to DHCP in IPv4 301 The operational models and relevant configuration information for 302 DHCPv4 ([RFC2131] and [RFC2132]) and DHCPv6 are sufficiently 303 different that integration between the two services is not included 304 in this document. [RFC3315] suggested that future work might be to 305 extend DHCPv6 to carry IPv4 address and configuration information. 306 However, the current consensus of the IETF is that DHCPv4 should be 307 used rather than DHCPv6 when conveying IPv4 configuration information 308 to nodes. For IPv6-only networks, [RFC7341] describes a transport 309 mechanism to carry DHCPv4 messages using the DHCPv6 protocol for the 310 dynamic provisioning of IPv4 address and configuration information. 312 Merging DHCPv4 and DHCPv6 configuration is out of scope of this 313 document. [RFC4477] discusses some issues and possible strategies 314 for running DHCPv4 and DHCPv6 services together. While this document 315 is a bit dated, it provides a good overview of the issues at hand. 317 2. Requirements 319 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 320 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 321 "OPTIONAL" in this document are to be interpreted as described in 322 [RFC2119] when they appear in ALL CAPS. When these words are not in 323 ALL CAPS (such as "should" or "Should"), they have their usual 324 English meanings, and are not to be interpreted as [RFC2119] key 325 words. 327 This document also makes use of internal conceptual variables to 328 describe protocol behavior and external variables that an 329 implementation must allow system administrators to change. The 330 specific variable names, how their values change, and how their 331 settings influence protocol behavior are provided to demonstrate 332 protocol behavior. An implementation is not required to have them in 333 the exact form described here, so long as its external behavior is 334 consistent with that described in this document. 336 3. Background 338 The IPv6 Specification provides the base architecture and design of 339 IPv6. Related work in IPv6 that would best serve an implementer to 340 study includes the IPv6 Specification [RFC2460], the IPv6 Addressing 341 Architecture [RFC4291], IPv6 Stateless Address Autoconfiguration 342 [RFC4862], and IPv6 Neighbor Discovery Processing [RFC4861]. These 343 specifications enable DHCP to build upon the IPv6 work to provide 344 robust stateful autoconfiguration. 346 The IPv6 Addressing Architecture specification [RFC4291] defines the 347 address scope that can be used in an IPv6 implementation, and the 348 various configuration architecture guidelines for network designers 349 of the IPv6 address space. Two advantages of IPv6 are that support 350 for multicast is required and nodes can create link-local addresses 351 during initialization. The availability of these features means that 352 a client can use its link-local address and a well-known multicast 353 address to discover and communicate with DHCP servers or relay agents 354 on its link. 356 IPv6 Stateless Address Autoconfiguration [RFC4862] specifies 357 procedures by which a node may autoconfigure addresses based on 358 router advertisements [RFC4861], and the use of a valid lifetime to 359 support renumbering of addresses on the Internet. Compatibility with 360 stateless address autoconfiguration is a design requirement of DHCP. 362 IPv6 Neighbor Discovery [RFC4861] is the node discovery protocol in 363 IPv6 which replaces and enhances functions of ARP [RFC0826]. To 364 understand IPv6 and stateless address autoconfiguration, it is 365 strongly recommended that implementers understand IPv6 Neighbor 366 Discovery. 368 4. Terminology 370 This section defines terminology specific to IPv6 and DHCP used in 371 this document. 373 4.1. IPv6 Terminology 375 IPv6 terminology relevant to this specification from the IPv6 376 Protocol [RFC2460], IPv6 Addressing Architecture [RFC4291], and IPv6 377 Stateless Address Autoconfiguration [RFC4862] is included below. 379 address An IP layer identifier for an interface or 380 a set of interfaces. 382 host Any node that is not a router. 384 IP Internet Protocol Version 6 (IPv6). The 385 terms IPv4 and IPv6 are used only in 386 contexts where it is necessary to avoid 387 ambiguity. 389 interface A node's attachment to a link. 391 link A communication facility or medium over 392 which nodes can communicate at the link 393 layer, i.e., the layer immediately below 394 IP. Examples are Ethernet (simple or 395 bridged); PPP and PPPoE links; and Internet 396 (or higher) layer "tunnels", such as 397 tunnels over IPv4 or IPv6 itself. 399 link-layer identifier A link-layer identifier for an interface. 400 Examples include IEEE 802 addresses for 401 Ethernet or Token Ring network interfaces, 402 and E.164 addresses for ISDN links. 404 link-local address An IPv6 address having a link-only scope, 405 indicated by having the prefix (fe80::/10), 406 that can be used to reach neighboring nodes 407 attached to the same link. Every interface 408 has a link-local address. 410 multicast address An identifier for a set of interfaces 411 (typically belonging to different nodes). 412 A packet sent to a multicast address is 413 delivered to all interfaces identified by 414 that address. 416 neighbor A node attached to the same link. 418 node A device that implements IP. 420 packet An IP header plus payload. 422 prefix The initial bits of an address, or a set of 423 IP addresses that share the same initial 424 bits. 426 prefix length The number of bits in a prefix. 428 router A node that forwards IP packets not 429 explicitly addressed to itself. 431 unicast address An identifier for a single interface. A 432 packet sent to a unicast address is 433 delivered to the interface identified by 434 that address. 436 4.2. DHCP Terminology 438 Terminology specific to DHCP can be found below. 440 appropriate to the link An address is "appropriate to the link" 441 when the address is consistent with the 442 DHCP server's knowledge of the network 443 topology, prefix assignment and address 444 assignment policies. 446 binding A binding (or, client binding) is a group 447 of server data records containing the 448 information the server has about the 449 addresses or delegated prefixes in an IA or 450 configuration information explicitly 451 assigned to the client. Configuration 452 information that has been returned to a 453 client through a policy, such as the 454 information returned to all clients on the 455 same link, does not require a binding. A 456 binding containing information about an IA 457 is indexed by the tuple (where IA-type is the type of lease 459 in the IA; for example, temporary). A 460 binding containing configuration 461 information for a client is indexed by 462 . 464 configuration parameter An element of the configuration information 465 set on the server and delivered to the 466 client using DHCP. Such parameters may be 467 used to carry information to be used by a 468 node to configure its network subsystem and 469 enable communication on a link or 470 internetwork, for example. 472 container option An option that encapsulates other options 473 (for example, the IA_NA may contain IAADDR 474 options). 476 delegating router The router that acts as a DHCP server, and 477 responds to requests for delegated 478 prefixes. This document primarily uses the 479 term "DHCP server" or "server" when 480 discussing the "delegating router" 481 functionality of prefix delegation (see 482 Section 1. 484 DHCP Dynamic Host Configuration Protocol for 485 IPv6. The terms DHCPv4 and DHCPv6 are used 486 only in contexts where it is necessary to 487 avoid ambiguity. 489 DHCP client (or client) A node that initiates requests on a link to 490 obtain configuration parameters from one or 491 more DHCP servers. Depending on the 492 purpose of the client, it may feature the 493 requesting router functionality, if it 494 supports prefix delegation. 496 DHCP domain A set of links managed by DHCP and operated 497 by a single administrative entity. 499 DHCP relay agent (or relay agent) A node that acts as an 500 intermediary to deliver DHCP messages 501 between clients and servers. In certain 502 configurations there may be more than one 503 relay agent between clients and servers, so 504 a relay agent may send DHCP messages to 505 another relay agent. 507 DHCP server (or server) A node that responds to requests from 508 clients, and may or may not be on the same 509 link as the client(s). Depending on its 510 capabilities, it may also feature the 511 functionality of delegating router, if it 512 supports prefix delegation. 514 DUID A DHCP Unique IDentifier for a DHCP 515 participant; each DHCP client and server 516 has exactly one DUID. See Section 11 for 517 details of the ways in which a DUID may be 518 constructed. 520 IA Identity Association: A collection of 521 leases assigned to a client. Each IA has 522 an associated IAID. A client may have more 523 than one IA assigned to it; for example, 524 one for each of its interfaces. Each IA 525 holds one type of lease; for example, an 526 identity association for temporary 527 addresses (IA_TA) holds temporary addresses 528 (see "identity association for temporary 529 addresses") and identity association for 530 prefix delegation (IA_PD) holds delegated 531 prefixes. Throughout this document, "IA" 532 is used to refer to an identity association 533 without identifying the type of a lease in 534 the IA. At the time of writing this 535 document, there are three IA types defined: 536 IA_NA, IA_TA and IA_PD. New IA types may 537 be defined in the future. 539 IAID Identity Association IDentifier: An 540 identifier for an IA, chosen by the client. 541 Each IA has an IAID, which is chosen to be 542 unique among IAIDs for IAs of a specific 543 type, belonging to that client. 545 IA_NA Identity association for Non-temporary 546 Addresses: An IA that carries assigned 547 addresses that are not temporary addresses 548 (see "IA_TA"). 550 IA_TA Identity Association for Temporary 551 Addresses: An IA that carries temporary 552 addresses (see [RFC4941]). 554 IA_PD Identity Association for Prefix Delegation: 555 An IA that carries delegated prefixes. 557 lease A contract by which the server grants the 558 use of an address or delegated prefix to 559 the client for a specified period of time. 561 message A unit of data carried as the payload of a 562 UDP datagram, exchanged among DHCP servers, 563 relay agents and clients. 565 Reconfigure key A key supplied to a client by a server used 566 to provide security for Reconfigure 567 messages (see Section 7.3). 569 relaying A DHCP relay agent relays DHCP messages 570 between DHCP participants. 572 requesting router The router that acts as a DHCP client and 573 is requesting prefix(es) to be assigned. 574 This document primarily uses the term "DHCP 575 client" or "client" when discussing the 576 "requesting router" functionality of prefix 577 delegation (see Section 1. 579 retransmission Another attempt to send the same DHCP 580 message by a client or server, as a result 581 of not receiving a valid response to the 582 previously sent messages. The 583 retransmitted message is typically modified 584 prior to sending, as required by the DHCP 585 specifications. In particular, the client 586 updates the value of the Elapsed Time 587 option in the retransmitted message. 589 RKAP The Reconfiguration Key Authentication 590 Protocol, see Section 20.4. 592 singleton option An option that is allowed to appear only 593 once as a the top-level option or at any 594 encapsulation level. Most options are 595 singletons. 597 T1 The time at which the client contacts the 598 server from which the addresses in the 599 IA_NA or prefixes in the IA_PD were 600 obtained to extend the lifetimes of the 601 addresses assigned to the IA_NA or prefixes 602 delegated to the IA_PD. 604 T2 The time at which the client contacts any 605 available server to extend the lifetimes of 606 the addresses assigned to the IA_NA or 607 prefixes delegated to the IA_PD. 609 top-level option An option conveyed in a DHCP message 610 directly, i.e., not encapsulated in any 611 other option, as described in Section 9 of 612 [RFC7227]. 614 transaction ID An opaque value used to match responses 615 with replies initiated either by a client 616 or server. 618 5. Client-Server Exchanges 620 Clients and servers exchange DHCP messages using UDP [RFC0768]. The 621 client uses a link-local address or addresses determined through 622 other mechanisms for transmitting and receiving DHCP messages. 624 A DHCP client sends most messages using a reserved, link-scoped 625 multicast destination address so that the client need not be 626 configured with the address or addresses of DHCP servers. 628 To allow a DHCP client to send a message to a DHCP server that is not 629 attached to the same link, a DHCP relay agent on the client's link 630 will relay messages between the client and server. The operation of 631 the relay agent is transparent to the client and the discussion of 632 message exchanges in the remainder of this section will omit the 633 description of message relaying by relay agents. 635 Once the client has determined the address of a server, it may under 636 some circumstances send messages directly to the server using 637 unicast. 639 5.1. Client-server Exchanges Involving Two Messages 641 When a DHCP client does not need to have a DHCP server assign it IP 642 addresses or delegated prefixes, the client can obtain other 643 configuration information such as a list of available DNS servers 644 [RFC3646] or NTP servers [RFC4075] through a single message and reply 645 exchange with a DHCP server. To obtain other configuration 646 information the client first sends an Information-request message to 647 the All_DHCP_Relay_Agents_and_Servers multicast address. Servers 648 respond with a Reply message containing the other configuration 649 information for the client. 651 When a server has addresses and/or delegated prefixes and other 652 configuration information committed to a client, the client and 653 server may be able to complete the exchange using only two messages, 654 instead of four messages as described in the next section. In this 655 case, the client sends a Solicit message to the 656 All_DHCP_Relay_Agents_and_Servers multicast address requesting the 657 assignment of addresses and/or delegated prefixes and other 658 configuration information. This message includes an indication (the 659 Rapid Commit option) that the client is willing to accept an 660 immediate Reply message from the server. The server that is willing 661 to commit the assignment of addresses and/or delegated prefixes to 662 the client immediately responds with a Reply message. The 663 configuration information and the addresses and/or delegated prefixes 664 in the Reply message are then immediately available for use by the 665 client. 667 Each address or delegated prefix assigned to the client has 668 associated preferred and valid lifetimes specified by the server. To 669 request an extension of the lifetimes assigned to an address or 670 delegated prefix, the client sends a Renew message to the server. 671 The server sends a Reply message to the client with the new 672 lifetimes, allowing the client to continue to use the address or 673 delegated prefix without interruption. If the server is unable to 674 extend the lifetime of an address or delegated prefix, it indicates 675 this by returning the address or delegated prefix with lifetimes of 676 0. At the same time, the server may assign other addresses or 677 delegated prefixes. 679 There are additional two message exchanges between the client and 680 server described later in this document. 682 5.2. Client-server Exchanges Involving Four Messages 684 To request the assignment of one or more addresses and/or delegated 685 prefixes, a client first locates a DHCP server and then requests the 686 assignment of addresses and/or delegated prefixes and other 687 configuration information from the server. The client sends a 688 Solicit message to the All_DHCP_Relay_Agents_and_Servers multicast 689 address to find available DHCP servers. Any server that can meet the 690 client's requirements responds with an Advertise message. The client 691 then chooses one of the servers and sends a Request message to the 692 server asking for confirmed assignment of addresses and/or delegated 693 prefixes and other configuration information. The server responds 694 with a Reply message that contains the confirmed addresses, delegated 695 prefixes, and configuration. 697 As described in the previous section, the client can also request an 698 extension of the lifetimes assigned to addresses or delegated 699 prefixes (this is a two message exchange). 701 5.3. Server-client Exchanges 703 A server that has previously communicated with a client and 704 negotiated for the client to listen for Reconfigure messages, may 705 send the client a Reconfigure message to initiate the client to 706 updates its configuration by sending an Information-request, Renew, 707 or Rebind message. The client then performs the earlier described 708 two message exchange. This can be used to expedite configuration 709 changes to a client, such as the need to renumber a network (see 710 [RFC6879]). 712 6. Operational Models 714 This section describes some of the current most common DHCP 715 operational models. The described models are not mutually exclusive 716 and are sometimes used together. For example, a device may start in 717 stateful mode to obtain an address, and at a later time when an 718 application is started, request additional parameters using stateless 719 mode. 721 This document assumes that the DHCP servers and the client, 722 communicating with the servers via specific interface, belong to a 723 single provisioning domain. 725 6.1. Stateless DHCP 727 Stateless DHCP [RFC3736] is used when DHCP is not used for obtaining 728 a lease, but a node (DHCP client) desires one or more DHCP "other 729 configuration" parameters, such as a list of DNS recursive name 730 servers or DNS domain search lists [RFC3646]. Stateless may be used 731 when a node initially boots or at any time the software on the node 732 requires some missing or expired configuration information that is 733 available via DHCP. 735 This is the simplest and most basic operation for DHCP and requires a 736 client (and a server) to support only two messages - Information- 737 request and Reply. Note that DHCP servers and relay agents typically 738 also need to support the Relay-forward and Relay-reply messages to 739 accommodate operation when clients and servers are not on the same 740 link. 742 6.2. DHCP for Non-Temporary Address Assignment 744 This model of operation was the original motivation for DHCP and is 745 the "stateful address autoconfiguration protocol" for IPv6 which is 746 discussed in [RFC2462]. It is appropriate for situations where 747 stateless address autoconfiguration alone is insufficient or 748 impractical, e.g., because of network policy, additional requirements 749 such as dynamic updates to the DNS, or client-specific requirements. 751 The model of operation for non-temporary address assignment is as 752 follows. The server is provided with prefixes from which it may 753 allocate addresses to clients, as well as any related network 754 topology information as to which prefixes are present on which links. 755 A client requests a non-temporary address to be assigned by the 756 server. The server allocates an address or addresses appropriate for 757 the link on which the client is connected. The server returns the 758 allocated address or addresses to the client. 760 Each address has an associated preferred and valid lifetime, which 761 constitutes an agreement about the length of time over which the 762 client is allowed to use the address. A client can request an 763 extension of the lifetimes on an address and is required to terminate 764 the use of an address if the valid lifetime of the address expires. 766 Typically clients request other configuration parameters, such as the 767 DNS name server addresses and domain search lists, when requesting 768 addresses. 770 Clients can also request more than one address or set of addresses 771 (see Section 6.6 and Section 12). 773 6.3. DHCP for Prefix Delegation 775 The prefix delegation mechanism, originally described in [RFC3633], 776 is another stateful mode of operation and was originally intended for 777 simple delegation of prefixes from a delegating router (DHCP server) 778 to requesting routers (DHCP clients). It is appropriate for 779 situations in which the delegating router does not have knowledge 780 about the topology of the networks to which the requesting router is 781 attached, and the delegating router does not require other 782 information aside from the identity of the requesting router to 783 choose a prefix for delegation. For example, these options would be 784 used by a service provider to assign a prefix to a Customer Edge 785 Router device acting as a router between the subscriber's internal 786 network and the service provider's core network. 788 The design of this prefix delegation mechanism meets the requirements 789 for prefix delegation in [RFC3769]. 791 While [RFC3633] assumed that the DHCP client is a router (hence use 792 of "requesting router") and that the DHCP server was a router (hence 793 use of "delegating router"), DHCP prefix delegation itself does not 794 require that the client forward IP packets not addressed to itself, 795 and thus does not require that the client (or server) be a router as 796 defined in [RFC2460]. Also, in many cases (such as tethering or 797 hosting virtual machines), hosts are already forwarding IP packets 798 and thus operating as routers as defined in [RFC2460]. Therefore, 799 this document mostly replaces "requesting router" with client and 800 "delegating router" with server. 802 The model of operation for prefix delegation is as follows. A server 803 is provided prefixes to be delegated to clients. A client requests 804 prefix(es) from the server, as described in Section 18. The server 805 chooses prefix(es) for delegation, and responds with prefix(es) to 806 the client. The client is then responsible for the delegated 807 prefix(es). For example, the client might assign a subnet from a 808 delegated prefix to one of its interfaces, and begin sending router 809 advertisements for the prefix on that link. 811 Each prefix has an associated valid and preferred lifetime, which 812 constitutes an agreement about the length of time over which the 813 client is allowed to use the prefix. A client can request an 814 extension of the lifetimes on a delegated prefix and is required to 815 terminate the use of a delegated prefix if the valid lifetime of the 816 prefix expires. 818 This prefix delegation mechanism is appropriate for use by an ISP to 819 delegate a prefix to a subscriber, where the delegated prefix would 820 possibly be subnetted and assigned to the links within the 821 subscriber's network. [RFC7084] and [RFC7368] describe in detail 822 such use. 824 Figure 1 illustrates a network architecture in which prefix 825 delegation could be used. 827 ______________________ \ 828 / \ \ 829 | ISP core network | \ 830 \__________ ___________/ | 831 | | 832 +-------+-------+ | 833 | Aggregation | | ISP 834 | device | | network 835 | (delegating | | 836 | router) | | 837 +-------+-------+ | 838 | / 839 |Network link to / 840 |subscriber premises / 841 | 842 +------+------+ \ 843 | CPE | \ 844 | (requesting | \ 845 | router) | | 846 +----+---+----+ | 847 | | | Subscriber 848 ---+-------------+-----+ +-----+------ | Network 849 | | | | 850 +----+-----+ +-----+----+ +----+-----+ | 851 |Subscriber| |Subscriber| |Subscriber| / 852 | PC | | PC | | PC | / 853 +----------+ +----------+ +----------+ / 855 Figure 1: Prefix Delegation Network 857 In this example, the server (delegating router) is configured with a 858 set of prefixes to be used for assignment to customers at the time of 859 each customer's first connection to the ISP service. The prefix 860 delegation process begins when the client (requesting router) 861 requests configuration information through DHCP. The DHCP messages 862 from the client are received by the server in the aggregation device. 863 When the server receives the request, it selects an available prefix 864 or prefixes for delegation to the client. The server then returns 865 the prefix or prefixes to the client. 867 The client subnets the delegated prefix and assigns the longer 868 prefixes to links in the subscriber's network. In a typical scenario 869 based on the network shown in Figure 1, the client subnets a single 870 delegated /48 prefix into /64 prefixes and assigns one /64 prefix to 871 each of the links in the subscriber network. 873 The prefix delegation options can be used in conjunction with other 874 DHCP options carrying other configuration information to the client. 875 The client may, in turn, provide DHCP service to nodes attached to 876 the internal network. For example, the client may obtain the 877 addresses of DNS and NTP servers from the ISP server, and then pass 878 that configuration information on to the subscriber hosts through a 879 DHCP server in the client (requesting router). 881 If the client assigns a delegated prefix to a link to which the 882 router is attached, and begins to send router advertisements for the 883 prefix on the link, the client MUST set the valid lifetime in those 884 advertisements to be no later than the valid lifetime specified in 885 the IA_PD option. A client MAY use the preferred lifetime specified 886 in the IA_PD option. 888 6.4. DHCP for Customer Edge Routers 890 The DHCP requirements and network architecture for Customer Edge 891 Routers are described in [RFC7084]. This model of operation combines 892 address assignment (see Section 6.2) and prefix delegation (see 893 Section 6.3). In general, this model assumes that a single set of 894 transactions between the client and server will assign or extend the 895 client's non-temporary addresses and delegated prefixes. 897 6.5. DHCP for Temporary Addresses 899 Temporary addresses were originally introduced to avoid privacy 900 concerns with stateless address autoconfiguration, which based 901 64-bits of the address on the EUI-64 (see [RFC3041] and [RFC4941]). 902 They were added to DHCP to provide complementary support when 903 stateful address assignment is used. 905 Temporary address assignment works mostly like non-temporary address 906 assignment (see Section 6.2), however these addresses are generally 907 intended to be used for a short period of time and not to have their 908 lifetimes extended, though they can be if required. 910 6.6. Multiple Addresses and Prefixes 912 The protocol allows a client to receive multiple addresses. During 913 typical operation, a client sends one instance of an IA_NA option and 914 the server assigns at most one address from each prefix assigned to 915 the link the client is attached to. In particular, the server can be 916 configured to serve addresses out of multiple prefixes for a given 917 link. This is useful in cases such as when a network renumbering 918 event is in progress. In a typical deployment the server will grant 919 one address per each IA_NA option. 921 A client can explicitly request multiple addresses by sending 922 multiple IA_NA (and/or IA_TA) options. A client can send multiple 923 IA_NA (and/or IA_TA) options in its initial transmissions. 924 Alternatively, it can send an extra Request message with additional 925 new IA_NA (and/or IA_TA) options (or include them in a Renew 926 message). 928 The same principle also applies to Prefix Delegation. In principle 929 the protocol allows a client to request new prefixes to be delegated 930 by sending additional IA_PD options. However, a typical operator 931 usually prefers to delegate a single, larger prefix. In most 932 deployments it recommended for the client to request larger prefix in 933 its initial transmissions rather than request additional prefixes 934 later on. 936 The exact behavior of the server (whether to grant additional 937 addresses and prefixes or not) is up to the server policy and is 938 outside of scope of this document. 940 For more information on how the server distinguishes between IA 941 option instances, see Section 12. 943 7. DHCP Constants 945 This section describes various program and networking constants used 946 by DHCP. 948 7.1. Multicast Addresses 950 DHCP makes use of the following multicast addresses: 952 All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped 953 multicast address used by a client to communicate 954 with neighboring (i.e., on-link) relay agents and 955 servers. All servers and relay agents are members of 956 this multicast group. 958 All_DHCP_Servers (FF05::1:3) A site-scoped multicast address used by 959 a relay agent to communicate with servers, either 960 because the relay agent wants to send messages to all 961 servers or because it does not know the unicast 962 addresses of the servers. Note that in order for a 963 relay agent to use this address, it must have an 964 address of sufficient scope to be reachable by the 965 servers. All servers within the site are members of 966 this multicast group on the interfaces which are 967 within the site. 969 7.2. UDP Ports 971 Clients listen for DHCP messages on UDP port 546. Servers and relay 972 agents listen for DHCP messages on UDP port 547. 974 7.3. DHCP Message Types 976 DHCP defines the following message types. More detail on these 977 message types can be found in Section 8 and Section 9. Additional 978 message types have been defined and may be defined in the future - 979 see https://www.iana.org/assignments/dhcpv6-parameters/ 980 dhcpv6-parameters.xhtml. The numeric encoding for each message type 981 is shown in parentheses. 983 SOLICIT (1) A client sends a Solicit message to locate servers. 985 ADVERTISE (2) A server sends an Advertise message to indicate that 986 it is available for DHCP service, in response to a 987 Solicit message received from a client. 989 REQUEST (3) A client sends a Request message to request 990 configuration parameters, including addresses and/or 991 delegated prefixes, from a specific server. 993 CONFIRM (4) A client sends a Confirm message to any available 994 server to determine whether the addresses it was 995 assigned are still appropriate to the link to which 996 the client is connected. 998 RENEW (5) A client sends a Renew message to the server that 999 originally provided the client's leases and 1000 configuration parameters to extend the lifetimes on 1001 the leases assigned to the client and to update other 1002 configuration parameters. 1004 REBIND (6) A client sends a Rebind message to any available 1005 server to extend the lifetimes on the leases assigned 1006 to the client and to update other configuration 1007 parameters; this message is sent after a client 1008 receives no response to a Renew message. 1010 REPLY (7) A server sends a Reply message containing assigned 1011 leases and configuration parameters in response to a 1012 Solicit, Request, Renew, Rebind message received from 1013 a client. A server sends a Reply message containing 1014 configuration parameters in response to an 1015 Information-request message. A server sends a Reply 1016 message in response to a Confirm message confirming 1017 or denying that the addresses assigned to the client 1018 are appropriate to the link to which the client is 1019 connected. A server sends a Reply message to 1020 acknowledge receipt of a Release or Decline message. 1022 RELEASE (8) A client sends a Release message to the server that 1023 assigned leases to the client to indicate that the 1024 client will no longer use one or more of the assigned 1025 leases. 1027 DECLINE (9) A client sends a Decline message to a server to 1028 indicate that the client has determined that one or 1029 more addresses assigned by the server are already in 1030 use on the link to which the client is connected. 1032 RECONFIGURE (10) A server sends a Reconfigure message to a client to 1033 inform the client that the server has new or updated 1034 configuration parameters, and that the client is to 1035 initiate a Renew/Reply or Information-request/Reply 1036 transaction with the server in order to receive the 1037 updated information. 1039 INFORMATION-REQUEST (11) A client sends an Information-request 1040 message to a server to request configuration 1041 parameters without the assignment of any leases to 1042 the client. 1044 RELAY-FORW (12) A relay agent sends a Relay-forward message to relay 1045 messages to servers, either directly or through 1046 another relay agent. The received message, either a 1047 client message or a Relay-forward message from 1048 another relay agent, is encapsulated in an option in 1049 the Relay-forward message. 1051 RELAY-REPL (13) A server sends a Relay-reply message to a relay agent 1052 containing a message that the relay agent delivers to 1053 a client. The Relay-reply message may be relayed by 1054 other relay agents for delivery to the destination 1055 relay agent. 1057 The server encapsulates the client message as an 1058 option in the Relay-reply message, which the relay 1059 agent extracts and relays to the client. 1061 7.4. DHCP Option Codes 1063 DHCP makes extensive use of options in messages and some of these are 1064 defined later in Section 21. Additional options are defined in other 1065 documents or may be defined in the future. 1067 7.5. Status Codes 1069 DHCP uses status codes to communicate the success or failure of 1070 operations requested in messages from clients and servers, and to 1071 provide additional information about the specific cause of the 1072 failure of a message. The specific status codes are defined in 1073 Section 21.13. 1075 If the Status Code option does not appear in a message in which the 1076 option could appear, the status of the message is assumed to be 1077 Success. 1079 7.6. Transmission and Retransmission Parameters 1081 This section presents a table of values used to describe the message 1082 transmission behavior of clients and servers. 1084 +-----------------+------------------+------------------------------+ 1085 | Parameter | Default | Description | 1086 +-----------------+------------------+------------------------------+ 1087 | SOL_MAX_DELAY | 1 sec | Max delay of first Solicit | 1088 | SOL_TIMEOUT | 1 sec | Initial Solicit timeout | 1089 | SOL_MAX_RT | 3600 secs | Max Solicit timeout value | 1090 | REQ_TIMEOUT | 1 sec | Initial Request timeout | 1091 | REQ_MAX_RT | 30 secs | Max Request timeout value | 1092 | REQ_MAX_RC | 10 | Max Request retry attempts | 1093 | CNF_MAX_DELAY | 1 sec | Max delay of first Confirm | 1094 | CNF_TIMEOUT | 1 sec | Initial Confirm timeout | 1095 | CNF_MAX_RT | 4 secs | Max Confirm timeout | 1096 | CNF_MAX_RD | 10 secs | Max Confirm duration | 1097 | REN_TIMEOUT | 10 secs | Initial Renew timeout | 1098 | REN_MAX_RT | 600 secs | Max Renew timeout value | 1099 | REB_TIMEOUT | 10 secs | Initial Rebind timeout | 1100 | REB_MAX_RT | 600 secs | Max Rebind timeout value | 1101 | INF_MAX_DELAY | 1 sec | Max delay of first | 1102 | | | Information-request | 1103 | INF_TIMEOUT | 1 sec | Initial Information-request | 1104 | | | timeout | 1105 | INF_MAX_RT | 3600 secs | Max Information-request | 1106 | | | timeout value | 1107 | REL_TIMEOUT | 1 sec | Initial Release timeout | 1108 | REL_MAX_RC | 4 | MAX Release retry attempts | 1109 | DEC_TIMEOUT | 1 sec | Initial Decline timeout | 1110 | DEC_MAX_RC | 4 | Max Decline retry attempts | 1111 | REC_TIMEOUT | 2 secs | Initial Reconfigure timeout | 1112 | REC_MAX_RC | 8 | Max Reconfigure attempts | 1113 | HOP_COUNT_LIMIT | 32 | Max hop count in a Relay- | 1114 | | | forward message | 1115 | IRT_DEFAULT | 86400 secs (24 | Default information refresh | 1116 | | hours) | time | 1117 | IRT_MINIMUM | 600 secs | Min information refresh time | 1118 +-----------------+------------------+------------------------------+ 1120 7.7. Representation of Time Values and "Infinity" as a Time Value 1122 All time values for lifetimes, T1 and T2 are unsigned 32-bit 1123 integers. The value 0xffffffff is taken to mean "infinity" when used 1124 as a lifetime (as in [RFC4861]) or a value for T1 or T2. 1126 Setting the valid lifetime of an address or a delegated prefix to 1127 0xffffffff ("infinity") amounts to a permanent address or delegation 1128 of the prefix to a client and should only be used in cases were 1129 permanent addresses are desired. 1131 Care should be taken in setting T1 or T2 to 0xffffffff ("infinity"). 1132 A client will never attempt to extend the lifetimes of any addresses 1133 in an IA with T1 set to 0xffffffff. A client will never attempt to 1134 use a Rebind message to locate a different server to extend the 1135 lifetimes of any addresses in an IA with T2 set to 0xffffffff. 1137 8. Client/Server Message Formats 1139 All DHCP messages sent between clients and servers share an identical 1140 fixed format header and a variable format area for options. 1142 All values in the message header and in options are in network byte 1143 order. 1145 Options are stored serially in the options field, with no padding 1146 between the options. Options are byte-aligned but are not aligned in 1147 any other way such as on 2 or 4 byte boundaries. 1149 The following diagram illustrates the format of DHCP messages sent 1150 between clients and servers: 1152 0 1 2 3 1153 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 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | msg-type | transaction-id | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | | 1158 . options . 1159 . (variable) . 1160 | | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 Figure 2: Client/Server message format 1165 msg-type Identifies the DHCP message type; the 1166 available message types are listed in 1167 Section 7.3. 1169 transaction-id The transaction ID for this message exchange. 1171 options Options carried in this message; options are 1172 described in Section 21. 1174 9. Relay Agent/Server Message Formats 1176 Relay agents exchange messages with other relay agents and servers to 1177 relay messages between clients and servers that are not connected to 1178 the same link. 1180 All values in the message header and in options are in network byte 1181 order. 1183 Options are stored serially in the options field, with no padding 1184 between the options. Options are byte-aligned but are not aligned in 1185 any other way such as on 2 or 4 byte boundaries. 1187 There are two relay agent messages, which share the following format: 1189 0 1 2 3 1190 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 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | msg-type | hop-count | | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1194 | | 1195 | link-address | 1196 | | 1197 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1198 | | | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1200 | | 1201 | peer-address | 1202 | | 1203 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1204 | | | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1206 . . 1207 . options (variable number and length) .... . 1208 | | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 Figure 3: Relay Agent/Server message format 1213 The following sections describe the use of the Relay Agent message 1214 header. 1216 9.1. Relay-forward Message 1218 The following table defines the use of message fields in a Relay- 1219 forward message. 1221 msg-type RELAY-FORW 1223 hop-count Number of relay agents that have already 1224 relayed this message. 1226 link-address An address that may be used by the server to 1227 identify the link on which the client is 1228 located. This is typically a globally unique 1229 address or unique local address (ULA) 1230 [RFC4193], but see discussion in 1231 Section 19.1.1. 1233 peer-address The address of the client or relay agent from 1234 which the message to be relayed was received. 1236 options MUST include a "Relay Message option" (see 1237 Section 21.10); MAY include other options 1238 added by the relay agent. 1240 See Section 13.1 for an explanation how link-address is used. 1242 9.2. Relay-reply Message 1244 The following table defines the use of message fields in a Relay- 1245 reply message. 1247 msg-type RELAY-REPL 1249 hop-count Copied from the Relay-forward message 1251 link-address Copied from the Relay-forward message 1253 peer-address Copied from the Relay-forward message 1255 options MUST include a "Relay Message option"; see 1256 Section 21.10; MAY include other options 1258 10. Representation and Use of Domain Names 1260 So that domain names may be encoded uniformly, a domain name or a 1261 list of domain names is encoded using the technique described in 1262 section 3.1 of [RFC1035]. A domain name, or list of domain names, in 1263 DHCP MUST NOT be stored in compressed form, as described in section 1264 4.1.4 of [RFC1035]. 1266 11. DHCP Unique Identifier (DUID) 1268 Each DHCP client and server has a DUID. DHCP servers use DUIDs to 1269 identify clients for the selection of configuration parameters and in 1270 the association of IAs with clients. DHCP clients use DUIDs to 1271 identify a server in messages where a server needs to be identified. 1272 See Section 21.2 and Section 21.3 for the representation of a DUID in 1273 a DHCP message. 1275 Clients and servers MUST treat DUIDs as opaque values and MUST only 1276 compare DUIDs for equality. Clients and servers SHOULD NOT in any 1277 other way interpret DUIDs. Clients and servers MUST NOT restrict 1278 DUIDs to the types defined in this document, as additional DUID types 1279 may be defined in the future. It should be noted that an attempt to 1280 parse a DUID to obtain a client's link-layer address is unreliable as 1281 there is no guarantee that the client is still using the same link- 1282 layer address as when it generated its DUID. And, such an attempt 1283 will be more and more unreliable as more clients adopt privacy 1284 measures, such are those defined in [RFC7844]. It is recommended to 1285 rely on the mechanism defined in [RFC6939]. 1287 The DUID is carried in an option because it may be variable length 1288 and because it is not required in all DHCP messages. The DUID is 1289 designed to be unique across all DHCP clients and servers, and stable 1290 for any specific client or server - that is, the DUID used by a 1291 client or server SHOULD NOT change over time if at all possible; for 1292 example, a device's DUID should not change as a result of a change in 1293 the device's network hardware. The stability of the DUID includes 1294 changes to virtual interfaces, such as logical PPP (over Ethernet) 1295 interfaces that may come and go in Customer Premise Equipment 1296 routers. The client may change its DUID as specific in [RFC7844]. 1298 The motivation for having more than one type of DUID is that the DUID 1299 must be globally unique, and must also be easy to generate. The sort 1300 of globally-unique identifier that is easy to generate for any given 1301 device can differ quite widely. Also, some devices may not contain 1302 any persistent storage. Retaining a generated DUID in such a device 1303 is not possible, so the DUID scheme must accommodate such devices. 1305 11.1. DUID Contents 1307 A DUID consists of a two-octet type code represented in network byte 1308 order, followed by a variable number of octets that make up the 1309 actual identifier. The length of the DUID (not including the type 1310 code) is at least 1 octet and at most 128 octets. The following 1311 types are currently defined: 1313 +------+------------------------------------------------------+ 1314 | Type | Description | 1315 +------+------------------------------------------------------+ 1316 | 1 | Link-layer address plus time | 1317 | 2 | Vendor-assigned unique ID based on Enterprise Number | 1318 | 3 | Link-layer address | 1319 | 4 | Universally Unique IDentifier (UUID) - see [RFC6355] | 1320 +------+------------------------------------------------------+ 1322 Formats for the variable field of the DUID for the first three of the 1323 above types are shown below. The fourth type, DUID-UUID [RFC6355], 1324 can be used in situations where there is a UUID stored in a device's 1325 firmware settings. 1327 11.2. DUID Based on Link-layer Address Plus Time, DUID-LLT 1329 This type of DUID consists of a two octet type field containing the 1330 value 1, a two octet hardware type code, four octets containing a 1331 time value, followed by link-layer address of any one network 1332 interface that is connected to the DHCP device at the time that the 1333 DUID is generated. The time value is the time that the DUID is 1334 generated represented in seconds since midnight (UTC), January 1, 1335 2000, modulo 2^32. The hardware type MUST be a valid hardware type 1336 assigned by the IANA as described in [RFC0826]. Both the time and 1337 the hardware type are stored in network byte order. The link-layer 1338 address is stored in canonical form, as described in [RFC2464]. 1340 The following diagram illustrates the format of a DUID-LLT: 1342 0 1 2 3 1343 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 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | 1 | hardware type (16 bits) | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 | time (32 bits) | 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 . . 1350 . link-layer address (variable length) . 1351 . . 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 Figure 4: DUID-LLT format 1356 The choice of network interface can be completely arbitrary, as long 1357 as that interface provides a globally unique link-layer address for 1358 the link type, and the same DUID-LLT SHOULD be used in configuring 1359 all network interfaces connected to the device, regardless of which 1360 interface's link-layer address was used to generate the DUID-LLT. 1362 Clients and servers using this type of DUID MUST store the DUID-LLT 1363 in stable storage, and MUST continue to use this DUID-LLT even if the 1364 network interface used to generate the DUID-LLT is removed. Clients 1365 and servers that do not have any stable storage MUST NOT use this 1366 type of DUID. 1368 Clients and servers that use this DUID SHOULD attempt to configure 1369 the time prior to generating the DUID, if that is possible, and MUST 1370 use some sort of time source (for example, a real-time clock) in 1371 generating the DUID, even if that time source could not be configured 1372 prior to generating the DUID. The use of a time source makes it 1373 unlikely that two identical DUID-LLTs will be generated if the 1374 network interface is removed from the client and another client then 1375 uses the same network interface to generate a DUID-LLT. A collision 1376 between two DUID-LLTs is very unlikely even if the clocks have not 1377 been configured prior to generating the DUID. 1379 This method of DUID generation is recommended for all general purpose 1380 computing devices such as desktop computers and laptop computers, and 1381 also for devices such as printers, routers, and so on, that contain 1382 some form of writable non-volatile storage. 1384 It is possible that this algorithm for generating a DUID could result 1385 in a client identifier collision. A DHCP client that generates a 1386 DUID-LLT using this mechanism MUST provide an administrative 1387 interface that replaces the existing DUID with a newly-generated 1388 DUID-LLT. 1390 11.3. DUID Assigned by Vendor Based on Enterprise Number, DUID-EN 1392 This form of DUID is assigned by the vendor to the device. It 1393 consists of the vendor's registered Private Enterprise Number as 1394 maintained by IANA [IANA-PEN] followed by a unique identifier 1395 assigned by the vendor. The following diagram summarizes the 1396 structure of a DUID-EN: 1398 0 1 2 3 1399 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 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 | 2 | enterprise-number | 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 | enterprise-number (contd) | | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1405 . identifier . 1406 . (variable length) . 1407 . . 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 Figure 5: DUID-EN format 1412 The source of the identifier is left up to the vendor defining it, 1413 but each identifier part of each DUID-EN MUST be unique to the device 1414 that is using it, and MUST be assigned to the device no later than at 1415 the first usage and stored in some form of non-volatile storage. 1416 This typically means being assigned during manufacture process in 1417 case of physical devices or when the image is created or booted for 1418 the first time in case of virtual machines. The generated DUID 1419 SHOULD be recorded in non-erasable storage. The enterprise-number is 1420 the vendor's registered Private Enterprise Number as maintained by 1421 IANA [IANA-PEN]. The enterprise-number is stored as an unsigned 32 1422 bit number. 1424 An example DUID of this type might look like this: 1426 +---+---+---+---+---+---+---+---+ 1427 | 0 | 2 | 0 | 0 | 0 | 9| 12|192| 1428 +---+---+---+---+---+---+---+---+ 1429 |132|211| 3 | 0 | 9 | 18| 1430 +---+---+---+---+---+---+ 1432 Figure 6: DUID-EN example 1434 This example includes the two-octet type of 2, the Enterprise Number 1435 (9), followed by eight octets of identifier data 1436 (0x0CC084D303000912). 1438 11.4. DUID Based on Link-layer Address, DUID-LL 1440 This type of DUID consists of two octets containing the DUID type 3, 1441 a two octet network hardware type code, followed by the link-layer 1442 address of any one network interface that is permanently connected to 1443 the client or server device. For example, a node that has a network 1444 interface implemented in a chip that is unlikely to be removed and 1445 used elsewhere could use a DUID-LL. The hardware type MUST be a 1446 valid hardware type assigned by the IANA, as described in [RFC0826]. 1447 The hardware type is stored in network byte order. The link-layer 1448 address is stored in canonical form, as described in [RFC2464]. The 1449 following diagram illustrates the format of a DUID-LL: 1451 0 1 2 3 1452 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 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 | 3 | hardware type (16 bits) | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 . . 1457 . link-layer address (variable length) . 1458 . . 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 Figure 7: DUID-LL format 1463 The choice of network interface can be completely arbitrary, as long 1464 as that interface provides a unique link-layer address and is 1465 permanently attached to the device on which the DUID-LL is being 1466 generated. The same DUID-LL SHOULD be used in configuring all 1467 network interfaces connected to the device, regardless of which 1468 interface's link-layer address was used to generate the DUID. 1470 DUID-LL is recommended for devices that have a permanently-connected 1471 network interface with a link-layer address, and do not have 1472 nonvolatile, writable stable storage. DUID-LL SHOULD NOT be used by 1473 DHCP clients or servers that cannot tell whether or not a network 1474 interface is permanently attached to the device on which the DHCP 1475 client is running. 1477 11.5. DUID Based on Universally Unique IDentifier (UUID), DUID-UUID 1479 This type of DUID consists of sixteen octets containing a 128-bit 1480 UUID. [RFC6355] details when to use this type, and how to pick an 1481 appropriate source of the UUID. 1483 0 1 2 3 1484 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 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 | DUID-Type (4) | UUID (128 bits) | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1488 | | 1489 | | 1490 | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1494 Figure 8: DUID-UUID format 1496 12. Identity Association 1498 An "identity-association" (IA) is a construct through which a server 1499 and a client can identify, group, and manage a set of related IPv6 1500 addresses or delegated prefixes. Each IA consists of an IAID and 1501 associated configuration information. 1503 The IAID uniquely identifies the IA and MUST be chosen to be unique 1504 among the IAIDs for that IA type on the client (i.e., IA_NA with IAID 1505 0 is unique from IA_TA with IAID 0). The IAID is chosen by the 1506 client. For any given use of an IA by the client, the IAID for that 1507 IA MUST be consistent across restarts of the DHCP client. The client 1508 may maintain consistency either by storing the IAID in non-volatile 1509 storage or by using an algorithm that will consistently produce the 1510 same IAID as long as the configuration of the client has not changed. 1511 There may be no way for a client to maintain consistency of the IAIDs 1512 if it does not have non-volatile storage and the client's hardware 1513 configuration changes. If the client uses only one IAID, it can use 1514 a well-known value, e.g., zero. 1516 If the client wishes to obtain a distinctly new address or prefix and 1517 deprecate the existing one, the client sends a Release message to the 1518 server for the IAs using the original IAID. Then the client creates 1519 a new IAID, to be used in future messages to obtain leases for the 1520 new IA. 1522 12.1. Identity Associations for Address Assignment 1524 A client must associate at least one distinct IA with each of its 1525 network interfaces for which it is to request the assignment of IPv6 1526 addresses from a DHCP server. The client uses the IAs assigned to an 1527 interface to obtain configuration information from a server for that 1528 interface. Each IA must be associated with exactly one interface. 1530 The configuration information in an IA_NA consists of one or more 1531 IPv6 addresses along with the T1 and T2 times for the IA. See 1532 Section 21.4 for the representation of an IA_NA in a DHCP message. 1534 The configuration information in an IA_TA consists of one or more 1535 IPv6 addresses. See Section 21.5 for the representation of an IA_TA 1536 in a DHCP message. 1538 Each address in an IA has a preferred lifetime and a valid lifetime, 1539 as defined in [RFC4862]. The lifetimes are transmitted from the DHCP 1540 server to the client in the IA Address option. The lifetimes apply 1541 to the use of addresses, as described in section 5.5.4 of [RFC4862]. 1543 12.2. Identity Associations for Prefix Delegation 1545 An IA_PD is different from an IA for address assignment, in that it 1546 does not need to be associated with exactly one interface. One IA_PD 1547 can be associated with the client, with a set of interfaces or with 1548 exactly one interface. A client must create at least one distinct 1549 IA_PD. It may associate a distinct IA_PD with each of its downstream 1550 network interfaces and use that IA_PD to obtain a prefix for that 1551 interface from the server. 1553 The configuration information in an IA_PD consists of one or more 1554 prefixes along with the T1 and T2 times for the IA_PD. See 1555 Section 21.21 for the representation of an IA_PD in a DHCP message. 1557 Each delegated prefix in an IA has a preferred lifetime and a valid 1558 lifetime, as defined in [RFC4862]. The lifetimes are transmitted 1559 from the DHCP server to the client in the IA Prefix option. The 1560 lifetimes apply to the use of delegated prefixes, as described in 1561 section 5.5.4 of [RFC4862]. 1563 13. Assignment to an IA 1565 13.1. Selecting Addresses for Assignment to an IA_NA 1567 A server selects addresses to be assigned to an IA_NA according to 1568 the address assignment policies determined by the server 1569 administrator and the specific information the server determines 1570 about the client from some combination of the following sources: 1572 - The link to which the client is attached. The server determines 1573 the link as follows: 1575 * If the server receives the message directly from the client and 1576 the source address in the IP datagram in which the message was 1577 received is a link-local address, then the client is on the 1578 same link to which the interface over which the message was 1579 received is attached. 1581 * If the server receives the message from a forwarding relay 1582 agent, then the client is on the same link as the one to which 1583 the interface, identified by the link-address field in the 1584 message from the relay agent, is attached. According to 1585 [RFC6221], the server MUST ignore any link-address field whose 1586 value is zero. The link-address in this case may come from any 1587 of the Relay-forward messages encapsulated in the received 1588 Relay-forward, and in general the most encapsulated (closest 1589 Relay-forward to the client) has the most useful value. 1591 * If the server receives the message directly from the client and 1592 the source address in the IP datagram in which the message was 1593 received is not a link-local address, then the client is on the 1594 link identified by the source address in the IP datagram (note 1595 that this situation can occur only if the server has enabled 1596 the use of unicast message delivery by the client and the 1597 client has sent a message for which unicast delivery is 1598 allowed). 1600 - The DUID supplied by the client. 1602 - Other information in options supplied by the client, e.g., IA 1603 Address options that include the client's requests for specific 1604 addresses. 1606 - Other information in options supplied by the relay agent. 1608 By default, DHCP server implementations SHOULD NOT generate 1609 predictable addresses ([RFC7721]). Server implementers are 1610 encouraged to review [RFC4941], [RFC7824], and [RFC7707] as to 1611 possible considerations for how to generate addresses. 1613 A server MUST NOT assign an address that is otherwise reserved for 1614 some other purpose. For example, a server MUST NOT assign addresses 1615 that use a reserved IPv6 Interface Identifier ([RFC5453], [RFC7136], 1616 [IANA-RESERVED-IID]). 1618 See [RFC7969] for a more detailed discussion on how servers determine 1619 a client's location on the network. 1621 13.2. Assignment of Temporary Addresses 1623 A client may request the assignment of temporary addresses (see 1624 [RFC4941] for the definition of temporary addresses). DHCP handling 1625 of address assignment is no different for temporary addresses. 1627 Clients ask for temporary addresses and servers assign them. 1628 Temporary addresses are carried in the Identity Association for 1629 Temporary Addresses (IA_TA) option (see Section 21.5). Each IA_TA 1630 option contains at lease one temporary address for each of the 1631 prefixes on the link to which the client is attached. 1633 The lifetime of the assigned temporary address is set in the IA 1634 Address option (see Section 21.6) encapsulated in the IA_TA option. 1635 It is RECOMMENDED to set short lifetimes, typically shorter than 1636 TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME (see Section 5, 1637 [RFC4941]). 1639 A DHCP server implementation MAY generate temporary addresses 1640 referring to the algorithm defined in Section 3.2.1, [RFC4941], with 1641 additional condition that the new address is not duplicated with any 1642 assigned addresses. 1644 The server MAY update the DNS for a temporary address, as described 1645 in section 4 of [RFC4941]. 1647 On the clients, by default, temporary addresses are preferred in 1648 source address selection, according to Rule 7, [RFC6724]. However, 1649 this policy is overridable. 1651 One of the most important properties of temporary address is 1652 unlinkability of different actions over time. So, it is NOT 1653 RECOMMENDED for a client to renew expired temporary addresses, though 1654 DHCP provides such possibility (see Section 21.5). 1656 13.3. Assignment of Prefixes for IA_PD 1658 The mechanism through which the server selects prefix(es) for 1659 delegation is not specified in this document. Examples of ways in 1660 which the server might select prefix(es) for a client include: static 1661 assignment based on subscription to an ISP; dynamic assignment from a 1662 pool of available prefixes; selection based on an external authority 1663 such as a RADIUS server using the Framed-IPv6-Prefix option as 1664 described in [RFC3162]. 1666 14. Transmission of Messages by a Client 1668 Unless otherwise specified in this document, or in a document that 1669 describes how IPv6 is carried over a specific type of link (for link 1670 types that do not support multicast), a client sends DHCP messages to 1671 the All_DHCP_Relay_Agents_and_Servers multicast address. 1673 DHCP servers SHOULD NOT care if the layer-2 address used was 1674 multicast or not, as long as the layer-3 address was correct. 1676 A client uses multicast to reach all servers or an individual server. 1677 An individual server is indicated by specifying that server's DUID in 1678 a Server Identifier option (see Section 21.3) in the client's message 1679 (all servers will receive this message but only the indicated server 1680 will respond). All servers are indicated by not supplying this 1681 option. 1683 A client may send some messages directly to a server using unicast, 1684 as described in Section 21.12. 1686 14.1. Rate Limiting 1688 In order to avoid prolonged message bursts that may be caused by 1689 possible logic loops, a DHCP client MUST limit the rate of DHCP 1690 messages it transmits. One example is that a client obtains an 1691 address or delegated prefix, but does not like the response; so it 1692 reverts back to Solicit procedure, discovers the same (sole) server, 1693 requests an address or delegated prefix and gets the same address or 1694 delegated prefix as before (as the server has this previously 1695 requested lease assigned to this client). This loop can repeat 1696 infinitely if there is not a quit/stop mechanism. Therefore, a 1697 client must not initiate transmissions too frequently. 1699 A recommended method for implementing the rate limiting function is a 1700 token bucket, limiting the average rate of transmission to a certain 1701 number in a certain time interval. This method of bounding 1702 burstiness also guarantees that the long-term transmission rate will 1703 not be exceeded. 1705 TRT Transmission Rate Limit 1707 The Transmission Rate Limit parameter (TRT) SHOULD be configurable. 1708 A possible default could be 20 packets in 20 seconds. 1710 For a device that has multiple interfaces, the limit MUST be enforced 1711 on a per interface basis. 1713 Rate limiting of forwarded DHCP messages and server-side messages are 1714 out of scope of this specification. 1716 14.2. Client Behavior when T1 and/or T2 are 0 1718 In certain cases, T1 and/or T2 time may be set to zero. Currently 1719 there are three such cases: 1721 1. a client received an IA_NA option with a zero value, 1723 2. a client received an IA_PD option with a zero value, and 1724 3. a client received an IA_TA option (which does not contain T1 1725 and T2 fields and are not generally renewed). 1727 This is an indication that the renew and rebind times are left at the 1728 client's discretion. However, they are not completely discretionary. 1730 When T1 and/or T2 times are set to zero, the client MUST choose a 1731 time to avoid packet storms. In particular, it MUST NOT transmit 1732 immediately. If the client received multiple IA containers, it 1733 SHOULD pick renew and/or rebind transmission times so all IA 1734 containers are handled in one exchange, if possible. The client MUST 1735 choose renew and rebind times to not violate rate limiting 1736 restrictions, defined in Section 14.1. 1738 15. Reliability of Client Initiated Message Exchanges 1740 DHCP clients are responsible for reliable delivery of messages in the 1741 client-initiated message exchanges described in Section 18. If a 1742 DHCP client fails to receive an expected response from a server, the 1743 client must retransmit its message according to the retransmission 1744 strategy described in this section. 1746 Note that the procedure described in this section is slightly 1747 modified when used with the Solicit message. The modified procedure 1748 is described in Section 18.2.1. 1750 The client begins the message exchange by transmitting a message to 1751 the server. The message exchange terminates when either the client 1752 successfully receives the appropriate response or responses from a 1753 server or servers, or when the message exchange is considered to have 1754 failed according to the retransmission mechanism described below. 1756 The client MUST update an "elapsed-time" value within an Elapsed Time 1757 option (see Section 21.9) in the retransmitted message. In some 1758 cases, the client may also need to modify values in the IA Address or 1759 IA Prefix options if a valid lifetime for any of the client's leases 1760 expires before retransmission. Thus, whenever this document refers 1761 to a "retransmission" of a client's message, it refers to both 1762 modifying the original message and sending this new message instance 1763 to the server. 1765 The client retransmission behavior is controlled and described by the 1766 following variables: 1768 RT Retransmission timeout 1770 IRT Initial retransmission time 1771 MRC Maximum retransmission count 1773 MRT Maximum retransmission time 1775 MRD Maximum retransmission duration 1777 RAND Randomization factor 1779 With each message transmission or retransmission, the client sets RT 1780 according to the rules given below. If RT expires before the message 1781 exchange terminates, the client recomputes RT and retransmits the 1782 message. 1784 Each of the computations of a new RT include a randomization factor 1785 (RAND), which is a random number chosen with a uniform distribution 1786 between -0.1 and +0.1. The randomization factor is included to 1787 minimize synchronization of messages transmitted by DHCP clients. 1789 The algorithm for choosing a random number does not need to be 1790 cryptographically sound. The algorithm SHOULD produce a different 1791 sequence of random numbers from each invocation of the DHCP client. 1793 RT for the first message transmission is based on IRT: 1795 RT = IRT + RAND*IRT 1797 RT for each subsequent message transmission is based on the previous 1798 value of RT: 1800 RT = 2*RTprev + RAND*RTprev 1802 MRT specifies an upper bound on the value of RT (disregarding the 1803 randomization added by the use of RAND). If MRT has a value of 0, 1804 there is no upper limit on the value of RT. Otherwise: 1806 if (RT > MRT) 1807 RT = MRT + RAND*MRT 1809 MRC specifies an upper bound on the number of times a client may 1810 retransmit a message. Unless MRC is zero, the message exchange fails 1811 once the client has transmitted the message MRC times. 1813 MRD specifies an upper bound on the length of time a client may 1814 retransmit a message. Unless MRD is zero, the message exchange fails 1815 once MRD seconds have elapsed since the client first transmitted the 1816 message. 1818 If both MRC and MRD are non-zero, the message exchange fails whenever 1819 either of the conditions specified in the previous two paragraphs are 1820 met. 1822 If both MRC and MRD are zero, the client continues to transmit the 1823 message until it receives a response. 1825 A client is not expected to listen for a response during the entire 1826 RT period and may turn off listening capabilities after a certain 1827 time due to power consumption saving or other reasons. Of course, a 1828 client MUST listen for a Reconfigure if it has negotiated for its use 1829 with the server. 1831 16. Message Validation 1833 This section describes which options are valid in which kinds of 1834 message types. Should a client or server receive messages which 1835 contain known options which are invalid for the message, this section 1836 explains how to process it. For example, an IA option is not allowed 1837 to appear in an Information-request message. 1839 Clients and servers MAY choose either to extract information from 1840 such a message if the information is of use to the recipient, or to 1841 ignore such message completely and just discard it. 1843 If a server receives a message that it considers invalid, it MAY send 1844 a Reply (or Advertise as appropriate) with a Server Identifier 1845 option, a Client Identifier option if one was included in the message 1846 and a Status Code option with status UnspecFail. 1848 Clients, relay agents and servers MUST NOT discard messages that 1849 contain unknown options (or instances of vendor options with unknown 1850 enterprise-numbers). These should be ignored as if they were not 1851 present. This is critical to provide for later extension of the DHCP 1852 protocol. 1854 A server MUST discard any Solicit, Confirm, Rebind or Information- 1855 request messages it receives with a layer-3 unicast destination 1856 address. 1858 A client or server MUST discard any received DHCP messages with an 1859 unknown message type. 1861 16.1. Use of Transaction IDs 1863 The "transaction-id" field holds a value used by clients and servers 1864 to synchronize server responses to client messages. A client SHOULD 1865 generate a random number that cannot easily be guessed or predicted 1866 to use as the transaction ID for each new message it sends. Note 1867 that if a client generates easily predictable transaction 1868 identifiers, it may become more vulnerable to certain kinds of 1869 attacks from off-path intruders. A client MUST leave the transaction 1870 ID unchanged in retransmissions of a message. 1872 16.2. Solicit Message 1874 Clients MUST discard any received Solicit messages. 1876 Servers MUST discard any Solicit messages that do not include a 1877 Client Identifier option or that do include a Server Identifier 1878 option. 1880 16.3. Advertise Message 1882 Clients MUST discard any received Advertise message that meets any of 1883 the following conditions: 1885 - the message does not include a Server Identifier option. 1887 - the message does not include a Client Identifier option. 1889 - the contents of the Client Identifier option does not match the 1890 client's DUID. 1892 - the "transaction-id" field value does not match the value the 1893 client used in its Solicit message. 1895 Servers and relay agents MUST discard any received Advertise 1896 messages. 1898 16.4. Request Message 1900 Clients MUST discard any received Request messages. 1902 Servers MUST discard any received Request message that meets any of 1903 the following conditions: 1905 - the message does not include a Server Identifier option. 1907 - the contents of the Server Identifier option do not match the 1908 server's DUID. 1910 - the message does not include a Client Identifier option. 1912 16.5. Confirm Message 1914 Clients MUST discard any received Confirm messages. 1916 Servers MUST discard any received Confirm messages that do not 1917 include a Client Identifier option or that do include a Server 1918 Identifier option. 1920 16.6. Renew Message 1922 Clients MUST discard any received Renew messages. 1924 Servers MUST discard any received Renew message that meets any of the 1925 following conditions: 1927 - the message does not include a Server Identifier option. 1929 - the contents of the Server Identifier option does not match the 1930 server's identifier. 1932 - the message does not include a Client Identifier option. 1934 16.7. Rebind Message 1936 Clients MUST discard any received Rebind messages. 1938 Servers MUST discard any received Rebind messages that do not include 1939 a Client Identifier option or that do include a Server Identifier 1940 option. 1942 16.8. Decline Messages 1944 Clients MUST discard any received Decline messages. 1946 Servers MUST discard any received Decline message that meets any of 1947 the following conditions: 1949 - the message does not include a Server Identifier option. 1951 - the contents of the Server Identifier option does not match the 1952 server's identifier. 1954 - the message does not include a Client Identifier option. 1956 16.9. Release Message 1958 Clients MUST discard any received Release messages. 1960 Servers MUST discard any received Release message that meets any of 1961 the following conditions: 1963 - the message does not include a Server Identifier option. 1965 - the contents of the Server Identifier option does not match the 1966 server's identifier. 1968 - the message does not include a Client Identifier option. 1970 16.10. Reply Message 1972 Clients MUST discard any received Reply message that meets any of the 1973 following conditions: 1975 - the message does not include a Server Identifier option. 1977 - the "transaction-id" field in the message does not match the value 1978 used in the original message. 1980 If the client included a Client Identifier option in the original 1981 message, the Reply message MUST include a Client Identifier option 1982 and the contents of the Client Identifier option MUST match the DUID 1983 of the client; OR, if the client did not include a Client Identifier 1984 option in the original message, the Reply message MUST NOT include a 1985 Client Identifier option. 1987 Servers and relay agents MUST discard any received Reply messages. 1989 16.11. Reconfigure Message 1991 Servers and relay agents MUST discard any received Reconfigure 1992 messages. 1994 Clients MUST discard any Reconfigure message that meets any of the 1995 following conditions: 1997 - the message was not unicast to the client. 1999 - the message does not include a Server Identifier option. 2001 - the message does not include a Client Identifier option that 2002 contains the client's DUID. 2004 - the message does not include a Reconfigure Message option. 2006 - the Reconfigure Message option msg-type is not a valid value. 2008 - the message does not include DHCP authentication: 2010 * the message does not include an Authentication option. 2012 * the message does not pass the authentication validation 2013 performed by the client. 2015 16.12. Information-request Message 2017 Clients MUST discard any received Information-request messages. 2019 Servers MUST discard any received Information-request message that 2020 meets any of the following conditions: 2022 - The message includes a Server Identifier option and the DUID in 2023 the option does not match the server's DUID. 2025 - The message includes an IA option. 2027 16.13. Relay-forward Message 2029 Clients MUST discard any received Relay-forward messages. 2031 16.14. Relay-reply Message 2033 Clients and servers MUST discard any received Relay-reply messages. 2035 17. Client Source Address and Interface Selection 2037 Client's behavior is different depending on the purpose of the 2038 configuration. 2040 17.1. Address, Interface Selection for Address Assignment 2042 When a client sends a DHCP message to the 2043 All_DHCP_Relay_Agents_and_Servers multicast address, it SHOULD send 2044 the message through the interface for which configuration information 2045 (including the addresses) is being requested. However, the client 2046 MAY send the message through another interface if the interface which 2047 configuration is being requested for is a logical interface without 2048 direct link attachment or the client is certain that two interfaces 2049 are attached to the same link. 2051 When a client sends a DHCP message directly to a server using unicast 2052 (after receiving the Server Unicast option from that server), the 2053 source address in the header of the IPv6 datagram MUST be an address 2054 assigned to the interface for which the client is interested in 2055 obtaining configuration and which is suitable for use by the server 2056 in responding to the client. 2058 17.2. Address, Interface Selection for Prefix Delegation 2060 Delegated prefixes are not associated with a particular interface in 2061 the same way as addresses are for address assignment, as mentioned in 2062 Section 17.1 above. 2064 When a client sends a DHCP message for the purpose of prefix 2065 delegation, it SHOULD be sent on the interface associated with the 2066 upstream router (ISP network). The upstream interface is typically 2067 determined by configuration. This rule applies even in the case 2068 where a separate IA_PD is used for each downstream interface. 2070 When a client sends a DHCP message directly to a server using unicast 2071 (after receiving the Server Unicast option from that server), the 2072 source address SHOULD be an address from the upstream interface and 2073 which is suitable for use by the server in responding to the client. 2075 18. DHCP Configuration Exchanges 2077 A client initiates a message exchange with a server or servers to 2078 acquire or update configuration information of interest. A client 2079 has many reasons to initiate the configuration exchange: 2081 1. as part of the operating system configuration/bootstrap 2082 process, 2084 2. when requested to do so by the application layer (through an 2085 operating system specific API), 2087 3. when required by Stateless Address Autoconfiguration (as 2088 defined in [RFC2462] Section 5.2), 2090 4. as required to extend the lifetime of address(es) and/or 2091 delegated prefix(es), using Renew and Rebind messages, 2093 4. or when requested to do so by server - upon the receipt of a 2094 Reconfigure message. 2096 A DHCP client that does not need to have a DHCP server assign it IP 2097 addresses or delegated prefixes, can obtain configuration information 2098 such as a list of available DNS servers [RFC3646] or NTP servers 2100 [RFC4075] through a single message and reply exchange with a DHCP 2101 server. To obtain configuration information the client first sends 2102 an Information-request message (see Section 18.2.6) to the 2103 All_DHCP_Relay_Agents_and_Servers multicast address. Servers respond 2104 with a Reply message containing the configuration information for the 2105 client (see Section 18.3.6). 2107 To request the assignment of one or more addresses or delegated 2108 prefixes, a client first locates a DHCP server and then requests the 2109 assignment of addresses/prefixes and other configuration information 2110 from the server. The client does this by sending the Solicit message 2111 (see Section 18.2.1) to the All_DHCP_Relay_Agents_and_Servers 2112 multicast address and collecting Advertise messages from the servers 2113 which respond to the client's message and selects a server from which 2114 it wants to obtain configuration information. This process is 2115 referred to as server discovery. When the client has selected the 2116 server it sends a Request message to this server as described in the 2117 Section 18.2.2. 2119 A client willing to perform the Solicit/Reply message exchange 2120 described in Section 18.2.1 includes a Rapid Commit option (see 2121 Section 21.14) in its Solicit message. 2123 The client has many reasons to initiate the configuration exchange: 2125 1. as part of the operating system configuration/bootstrap 2126 process, 2128 2. when requested to do so by the application layer (through an 2129 operating system specific API), 2131 3. when required by Stateless Address Autoconfiguration (as 2132 defined in [RFC2462]) 2134 4. or as required to extend the lifetime of address(es) and/or 2135 delegated prefix(es), using Renew and Rebind messages. 2137 A server may initiate a message exchange with a client by sending a 2138 Reconfigure message to cause the client to send a Renew, Rebind or 2139 Information-request message to refresh its configuration information 2140 as soon as the Reconfigure message is received by the client. 2142 The client is responsible for creating IAs and requesting that a 2143 server assign addresses and/or delegated prefixes to the IAs. The 2144 client first creates the IAs and assigns IAIDs to them. The client 2145 then transmits a Solicit message containing the IA options describing 2146 the IAs. The client MUST NOT be using any of the addresses or 2147 delegated prefixes for which it tries to obtain the bindings by 2148 sending the Solicit message. In particular, if the client had some 2149 valid bindings and has chosen to start the server discovery process 2150 to obtain the same bindings from a different server, the client MUST 2151 stop using the addresses and delegated prefixes for the bindings it 2152 had obtained from the previous server (see Section 18.2.7 for more 2153 details on what stop using means), and which it is now trying to 2154 obtain from a new server. 2156 Servers that can assign addresses or delegated prefixes to the IAs 2157 respond to the client with an Advertise message or Reply message if 2158 the client included a Rapid Commit option and the server is 2159 configured to accept it. 2161 If the server responds with an Advertise message, the client 2162 initiates a configuration exchange as described in Section 18.2.2. 2164 A server may initiate a message exchange with a client by sending a 2165 Reconfigure message to cause the client to send a Renew, Rebind or 2166 Information-request message to refresh its configuration information 2167 as soon as the Reconfigure message is received by the client. 2169 Figure 9 shows a timeline diagram of the messages exchanged between a 2170 client and two servers for the typical lifecycle of one or more 2171 leases. This is a combination of the 4-message exchange (to select a 2172 server and assign the lease(s) to the client) followed by two 2173 2-message exchanges (to extend the lifetime on the lease(s) and 2174 eventually release the lease(s)). 2176 Server Server 2177 (not selected) Client (selected) 2179 v v v 2180 | | | 2181 | Begins initialization | 2182 | | | 2183 start of | _____________/|\_____________ | 2184 4-message |/ Solicit | Solicit \| 2185 exchange | | | 2186 Determines | Determines 2187 configuration | configuration 2188 | | | 2189 |\ | ____________/| 2190 | \________ | /Advertise | 2191 | Advertise\ |/ | 2192 | \ | | 2193 | Collects Advertises | 2194 | \ | | 2195 | Selects configuration | 2196 | | | 2197 | _____________/|\_____________ | 2198 |/ Request | Request \| 2199 | | | 2200 | | Commits configuration 2201 | | | 2202 end of | | _____________/| 2203 4-message | |/ Reply | 2204 exchange | | | 2205 | Initialization complete | 2206 | | | 2207 . . . 2208 . . . 2209 | T1 (Renewal) Timer Expires | 2210 | | | 2211 2-message | _____________/|\_____________ | 2212 exchange |/ Renew | Renew \| 2213 | | | 2214 | | Commits extended lease(s) 2215 | | | 2216 | | _____________/| 2217 | |/ Reply | 2218 . . . 2219 . . . 2220 | | | 2221 | Graceful shutdown | 2222 | | | 2223 2-message | _____________/|\_____________ | 2224 exchange |/ Release | Release \| 2225 | | | 2226 | | Discards lease(s) 2227 | | | 2228 | | _____________/| 2229 | |/ Reply | 2230 | | | 2231 v v v 2233 Figure 9: Timeline diagram of the messages exchanged between a client 2234 and two servers for the typical lifecycle of one or more leases 2236 18.1. A Single Exchange for Multiple IA Options 2238 The client and server use the IA_PD option to exchange information 2239 about prefix(es) in much the same way as IA_NA and IA_TA options are 2240 used for assigned addresses. Typically, a single DHCP session is 2241 used to exchange information about addresses and prefixes, i.e., 2242 IA_NA and IA_PD options are carried in the same message. 2244 Clients SHOULD use a single transaction for all of its IA options. 2245 Servers SHOULD assign the same T1/T2 values to all IA options 2246 configured for a client, so the client will generate a single 2247 transaction when renewing its leases. For a rationale of this 2248 approach, see Section 4.2 of [RFC7550]. 2250 18.2. Client Behavior 2252 A client uses the Solicit message to discover DHCP servers configured 2253 to assign leases or return other configuration parameters on the link 2254 to which the client is attached. 2256 A client uses Request, Renew, Rebind, Release and Decline messages 2257 during the normal life cycle of addresses and delegated prefixes. 2258 When a client detects it may have moved to a new link, it uses 2259 Confirm if it only has addresses and Rebind if it has delegated 2260 prefixes (and addresses). It uses Information-request messages when 2261 it needs configuration information but no addresses and no prefixes. 2263 When a client requests multiple IA option types or multiple instances 2264 of the same IA types in a Solicit, Request, Renew, or Rebind, it is 2265 possible that the available server(s) may only be configured to offer 2266 a subset of them. When possible, the client SHOULD use the best 2267 configuration available and continue to request the additional IAs in 2268 subsequent messages ([RFC7550]). This allows the client to maintain 2269 a single session and state machine. In practice, especially in the 2270 case of handling IA_NA and IA_PD requests ([RFC7084]), this situation 2271 should be rare or a result of a temporary operational error. Thus, 2272 it is more likely for the client to get all configuration if it 2273 continues, in each subsequent configuration exchange, to request all 2274 the configuration information it is programmed to try to obtain, 2275 including any stateful configuration options for which no results 2276 were returned in previous message exchanges. 2278 Upon receipt of a Reconfigure message from the server, a client 2279 responds with a Renew, Rebind or an Information-request message as 2280 indicated by the Reconfigure Message option. The client SHOULD be 2281 suspicious of the Reconfigure message (they may be faked), and it 2282 MUST NOT abandon any resources it might have already obtained. The 2283 client SHOULD treat the Reconfigure message as if the T1 timer had 2284 expired. The client will expect the server to send IAs and/or other 2285 configuration information to the client in a Reply message. 2287 If the client has a source address of sufficient scope that can be 2288 used by the server as a return address, and the client has received a 2289 Server Unicast option (Section 21.12) from the server, the client 2290 SHOULD unicast any Request, Renew, Release and Decline messages to 2291 the server. 2293 Use of unicast may avoid delays due to the relaying of messages by 2294 relay agents, as well as avoid overhead and duplicate responses by 2295 servers due to the delivery of client messages to multiple servers. 2296 However, requiring the client to relay all DHCP messages through a 2297 relay agent enables the inclusion of relay agent options in all 2298 messages sent by the client. The server should enable the use of 2299 unicast only when relay agent options will not be used. 2301 18.2.1. Creation and Transmission of Solicit Messages 2303 The client sets the "msg-type" field to SOLICIT. The client 2304 generates a transaction ID and inserts this value in the 2305 "transaction-id" field. 2307 The client MUST include a Client Identifier option to identify itself 2308 to the server. The client includes IA options for any IAs to which 2309 it wants the server to assign leases. 2311 The client MUST include an Elapsed Time option (see Section 21.9) to 2312 indicate how long the client has been trying to complete the current 2313 DHCP message exchange. 2315 The client uses IA_NA options to request the assignment of non- 2316 temporary addresses, IA_TA options to request the assignment of 2317 temporary addresses, and IA_PD options to request prefix delegation. 2318 Either IA_NA, IA_TA or IA_PD options, or a combination of all, can be 2319 included in DHCP messages. In addition, multiple instances of any IA 2320 option type can be included. 2322 The client MAY include addresses in IA Address options encapsulated 2323 within IA_NA and IA_TA options as hints to the server about the 2324 addresses for which the client has a preference. 2326 The client MAY include values in IA Prefix options encapsulated 2327 within IA_PD options as hints for the delegated prefix and/or prefix 2328 length for which the client has a preference. See Section 18.2.4 for 2329 more on prefix length hints. 2331 The client MUST include an Option Request option (see Section 21.7) 2332 to request the SOL_MAX_RT option (see Section 21.24) and any other 2333 options the client is interested in receiving. The client MAY 2334 additionally include instances of those options that are identified 2335 in the Option Request option, with data values as hints to the server 2336 about parameter values the client would like to have returned. 2338 The client includes a Reconfigure Accept option (see Section 21.20) 2339 if the client is willing to accept Reconfigure messages from the 2340 server. 2342 The client MUST NOT include any other options in the Solicit message, 2343 except as specifically allowed in the definition of individual 2344 options. 2346 The first Solicit message from the client on the interface SHOULD be 2347 delayed by a random amount of time between 0 and SOL_MAX_DELAY. This 2348 mechanism is essential for devices that are not battery powered, as 2349 they may suffer from power failure. After recovering from a power 2350 outage, many devices may start their transmission at the same time. 2351 This is much less of a concern for battery powered devices. 2353 In the case of a Solicit message transmitted when DHCP is initiated, 2354 the delay gives the amount of time to wait after IPv6 Neighbor 2355 Discovery causes the client to invoke the stateful address 2356 autoconfiguration protocol (see section 5.5.3 of [RFC2462]). This 2357 random delay desynchronizes clients which start at the same time (for 2358 example, after a power outage). 2360 The client transmits the message according to Section 15, using the 2361 following parameters: 2363 IRT SOL_TIMEOUT 2365 MRT SOL_MAX_RT 2367 MRC 0 2369 MRD 0 2371 A client that wishes to use the Rapid Commit 2-message exchange 2372 includes a Rapid Commit option in its Solicit message. The client 2373 may receive a number of different replies from different servers. 2374 The client will make note of any valid Advertise messages that it 2375 receives. The client will discard any Reply messages that do not 2376 contain the Rapid Commit option. 2378 Upon receipt of a valid Reply with the Rapid Commit option, the 2379 client processes the message as described in Section 18.2.10 2381 At the end of the first RT period, if no suitable Reply messages are 2382 received, but the client has valid Advertise messages, then the 2383 client processes the Advertise as described in Section 18.2.9. 2385 If the client subsequently receives a valid Reply message that 2386 includes a Rapid Commit option, it either: 2388 - processes the Reply message as described in Section 18.2.10, and 2389 discards any Reply messages received in response to the Request 2390 message, or 2392 - processes any Reply messages received in response to the Request 2393 message and discards the Reply message that includes the Rapid 2394 Commit option. 2396 If the client is waiting for an Advertise message, the mechanism in 2397 Section 15 is modified as follows for use in the transmission of 2398 Solicit messages. The message exchange is not terminated by the 2399 receipt of an Advertise before the first RT has elapsed. Rather, the 2400 client collects valid Advertise messages until the first RT has 2401 elapsed. Also, the first RT MUST be selected to be strictly greater 2402 than IRT by choosing RAND to be strictly greater than 0. 2404 A client MUST collect valid Advertise messages for the first RT 2405 seconds, unless it receives a valid Advertise message with a 2406 preference value of 255. The preference value is carried in the 2407 Preference option (Section 21.8). Any valid Advertise that does not 2408 include a Preference option is considered to have a preference value 2409 of 0. If the client receives a valid Advertise message that includes 2410 a Preference option with a preference value of 255, the client 2411 immediately begins a client-initiated message exchange (as described 2412 in Section 18.2.2) by sending a Request message to the server from 2413 which the Advertise message was received. If the client receives a 2414 valid Advertise message that does not include a Preference option 2415 with a preference value of 255, the client continues to wait until 2416 the first RT elapses. If the first RT elapses and the client has 2417 received a valid Advertise message, the client SHOULD continue with a 2418 client-initiated message exchange by sending a Request message. 2420 If the client does not receive any valid Advertise messages before 2421 the first RT has elapsed, it begins the retransmission mechanism 2422 described in Section 15. The client terminates the retransmission 2423 process as soon as it receives any valid Advertise message, and the 2424 client acts on the received Advertise message without waiting for any 2425 additional Advertise messages. 2427 A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client 2428 is configured with either MRC or MRD set to a value other than 0, it 2429 MUST stop trying to configure the interface if the message exchange 2430 fails. After the DHCP client stops trying to configure the 2431 interface, it SHOULD restart the reconfiguration process after some 2432 external event, such as user input, system restart, or when the 2433 client is attached to a new link. 2435 18.2.2. Creation and Transmission of Request Messages 2437 The client uses a Request message to populate IAs with leases and 2438 obtain other configuration information. The client includes one or 2439 more IA options in the Request message. The server then returns 2440 leases and other information about the IAs to the client in IA 2441 options in a Reply message. 2443 The client generates a transaction ID and inserts this value in the 2444 "transaction-id" field. 2446 The client MUST include the identifier of the destination server in a 2447 Server Identifier option. 2449 The client MUST include a Client Identifier option to identify itself 2450 to the server. The client adds any other appropriate options, 2451 including one or more IA options. 2453 The client MUST include an Elapsed Time option (see Section 21.9) to 2454 indicate how long the client has been trying to complete the current 2455 DHCP message exchange. 2457 The client MUST include an Option Request option (see Section 21.7) 2458 to request the SOL_MAX_RT option (see Section 21.24) and any other 2459 options the client is interested in receiving. The client MAY 2460 additionally include instances of those options that are identified 2461 in the Option Request option, with data values as hints to the server 2462 about parameter values the client would like to have returned. 2464 The client includes a Reconfigure Accept option (see Section 21.20) 2465 if the client is willing to accept Reconfigure messages from the 2466 server. 2468 The client transmits the message according to Section 15, using the 2469 following parameters: 2471 IRT REQ_TIMEOUT 2473 MRT REQ_MAX_RT 2475 MRC REQ_MAX_RC 2477 MRD 0 2479 If the message exchange fails, the client takes an action based on 2480 the client's local policy. Examples of actions the client might take 2481 include: 2483 - Select another server from a list of servers known to the client; 2484 for example, servers that responded with an Advertise message. 2486 - Initiate the server discovery process described in Section 18. 2488 - Terminate the configuration process and report failure. 2490 18.2.3. Creation and Transmission of Confirm Messages 2492 The client uses a Confirm message when is has only addresses (no 2493 delegated prefixes) assigned by a DHCP server to determine if it is 2494 still connected to the same link when the client detects a change in 2495 network information as described in Section 18.2.12. 2497 The client sets the "msg-type" field to CONFIRM. The client 2498 generates a transaction ID and inserts this value in the 2499 "transaction-id" field. 2501 The client MUST include a Client Identifier option to identify itself 2502 to the server. 2504 The client MUST include an Elapsed Time option (see Section 21.9) to 2505 indicate how long the client has been trying to complete the current 2506 DHCP message exchange. 2508 The client includes IA options for all of the IAs assigned to the 2509 interface for which the Confirm message is being sent. The IA 2510 options include all of the addresses the client currently has 2511 associated with those IAs. The client SHOULD set the T1 and T2 2512 fields in any IA_NA options and the preferred-lifetime and valid- 2513 lifetime fields in the IA Address options to 0, as the server will 2514 ignore these fields. 2516 The first Confirm message from the client on the interface MUST be 2517 delayed by a random amount of time between 0 and CNF_MAX_DELAY. The 2518 client transmits the message according to Section 15, using the 2519 following parameters: 2521 IRT CNF_TIMEOUT 2523 MRT CNF_MAX_RT 2525 MRC 0 2527 MRD CNF_MAX_RD 2529 If the client receives no responses before the message transmission 2530 process terminates, as described in Section 15, the client SHOULD 2531 continue to use any leases, using the last known lifetimes for those 2532 leases, and SHOULD continue to use any other previously obtained 2533 configuration parameters. 2535 18.2.4. Creation and Transmission of Renew Messages 2537 To extend the valid and preferred lifetimes for the leases assigned 2538 to the IAs and obtain new addresses or delegated prefixes for IAs, 2539 the client sends a Renew message to the server from which the leases 2540 were obtained, which includes IA options for the IAs whose lease 2541 lifetimes are to be extended. The client includes IA Address options 2542 within IA_NA and IA_TA options for the addresses assigned to the IAs. 2543 The client includes IA Prefix options within IA_PD options for the 2544 delegated prefixes assigned to the IAs. 2546 The server controls the time at which the client should contact the 2547 server to extend the lifetimes on assigned leases through the T1 and 2548 T2 parameters assigned to an IA. However, as the client Renews/ 2549 Rebinds all IAs from the server at the same time, the client MUST 2550 select a T1 and T2 time from all IA options, which will guarantee 2551 that the client will send Renew/Rebind messages not later than at the 2552 T1/T2 times associated with any of the client's bindings (earliest 2553 T1/T2). 2555 At time T1, the client initiates a Renew/Reply message exchange to 2556 extend the lifetimes on any leases in the IA. 2558 A client MUST also initiate a Renew/Reply message exchange before 2559 time T1 if the client's link-local address used in previous 2560 interactions with the server is no longer valid and it is willing to 2561 receive Reconfigure messages. 2563 If T1 or T2 had been set to 0 by the server (for an IA_NA or IA_PD) 2564 or there are no T1 or T2 times (for an IA_TA) in a previous Reply, 2565 the client may send a Renew or Rebind message, respectively, at the 2566 client's discretion. The client MUST follow the rules defined in 2567 Section 14.2. 2569 The client sets the "msg-type" field to RENEW. The client generates 2570 a transaction ID and inserts this value in the "transaction-id" 2571 field. 2573 The client MUST include a Server Identifier option in the Renew 2574 message, identifying the server with which the client most recently 2575 communicated. 2577 The client MUST include a Client Identifier option to identify itself 2578 to the server. The client adds any appropriate options, including 2579 one or more IA options. 2581 The client MUST include an Elapsed Time option (see Section 21.9) to 2582 indicate how long the client has been trying to complete the current 2583 DHCP message exchange. 2585 For IAs to which leases have been assigned, the client includes a 2586 corresponding IA option containing an IA Address option for each 2587 address assigned to the IA and IA Prefix option for each prefix 2588 assigned to the IA. The client MUST NOT include addresses and 2589 prefixes in any IA option that the client did not obtain from the 2590 server or that are no longer valid (that have a valid lifetime of 0). 2592 The client MAY include an IA option for each binding it desires but 2593 has been unable to obtain. In this case, if the client includes the 2594 IA_PD option to request prefix delegation, the client MAY include the 2595 IA Prefix option encapsulated within the IA_PD option, with the 2596 IPv6-prefix field set to 0 and the "prefix-length" field set to the 2597 desired length of the prefix to be delegated. The server MAY use 2598 this value as a hint for the prefix length. The client SHOULD NOT 2599 include IA Prefix option with the IPv6-prefix field set to 0 unless 2600 it is supplying a hint for the prefix length. 2602 The client includes Option Request option (see Section 21.7) to 2603 request the SOL_MAX_RT option (see Section 21.24) and any other 2604 options the client is interested in receiving. The client MAY 2605 include options with data values as hints to the server about 2606 parameter values the client would like to have returned. 2608 The client transmits the message according to Section 15, using the 2609 following parameters: 2611 IRT REN_TIMEOUT 2613 MRT REN_MAX_RT 2615 MRC 0 2617 MRD Remaining time until earliest T2 2619 The message exchange is terminated when earliest time T2 is reached. 2620 If the client is responding to a Reconfigure, the client ignores and 2621 discards the Reconfigure message. In this case, the client continues 2622 to operate as if Reconfigure message was not received, i.e., it uses 2623 T1/T2 times associated with the client's leases to determine when it 2624 should send Renew or Rebind to the server. If the terminated Renew 2625 exchange was not initiated as a result of receiving a Reconfigure 2626 message, the client begins a Rebind message exchange (see 2627 Section 18.2.5) when the earliest time T2 is reached. 2629 18.2.5. Creation and Transmission of Rebind Messages 2631 At time T2 (which will only be reached if the server to which the 2632 Renew message was sent starting at time T1 has not responded), the 2633 client initiates a Rebind/Reply message exchange with any available 2634 server. 2636 A Rebind is also used to verify delegated prefix bindings but with 2637 different retransmission parameters as described in Section 18.2.3. 2639 The client constructs the Rebind message as described in 2640 Section 18.2.4 with the following differences: 2642 - The client sets the "msg-type" field to REBIND. 2644 - The client does not include the Server Identifier option in the 2645 Rebind message. 2647 The client transmits the message according to Section 15, using the 2648 following parameters: 2650 IRT REB_TIMEOUT 2652 MRT REB_MAX_RT 2654 MRC 0 2656 MRD Remaining time until valid lifetimes of all leases in all 2657 IAs have expired 2659 If all leases for an IA have expired, the client may choose to 2660 include this IA in subsequent Rebind messages to indicate that the 2661 client is interested in assignment of the leases to this IA. 2663 The message exchange is terminated when the valid lifetimes of all 2664 leases across all IAs have expired, at which time the client uses the 2665 Solicit message to locate a new DHCP server and sends a Request for 2666 the expired IAs to the new server. If the terminated Rebind exchange 2667 was initiated as a result of receiving a Reconfigure message, the 2668 client ignores and discards the Reconfigure message. 2670 18.2.6. Creation and Transmission of Information-request Messages 2672 The client uses an Information-request message to obtain 2673 configuration information without having addresses and/or delegated 2674 prefixes assigned to it. 2676 The client sets the "msg-type" field to INFORMATION-REQUEST. The 2677 client generates a transaction ID and inserts this value in the 2678 "transaction-id" field. 2680 The client SHOULD include a Client Identifier option to identify 2681 itself to the server (see section 4.3.1 of [RFC7844] for reasons why 2682 a client may not want to include this option). If the client does 2683 not include a Client Identifier option, the server will not be able 2684 to return any client-specific options to the client, or the server 2685 may choose not to respond to the message at all. 2687 The client MUST include an Elapsed Time option (see Section 21.9) to 2688 indicate how long the client has been trying to complete the current 2689 DHCP message exchange. 2691 The client MUST include an Option Request option (see Section 21.7) 2692 to request the INF_MAX_RT option (see Section 21.25), the Information 2693 Refresh Time option (see Section 21.23), and any other options the 2694 client is interested in receiving. The client MAY include options 2695 with data values as hints to the server about parameter values the 2696 client would like to have returned. 2698 When responding to a Reconfigure, the client includes a Server 2699 Identifier option with the identifier from the Reconfigure message to 2700 which the client is responding. 2702 The first Information-request message from the client on the 2703 interface MUST be delayed by a random amount of time between 0 and 2704 INF_MAX_DELAY. The client transmits the message according to 2705 Section 15, using the following parameters: 2707 IRT INF_TIMEOUT 2709 MRT INF_MAX_RT 2711 MRC 0 2713 MRD 0 2715 18.2.7. Creation and Transmission of Release Messages 2717 To release one or more leases, a client sends a Release message to 2718 the server. 2720 The client sets the "msg-type" field to RELEASE. The client 2721 generates a transaction ID and places this value in the "transaction- 2722 id" field. 2724 The client places the identifier of the server that allocated the 2725 lease(s) in a Server Identifier option. 2727 The client MUST include a Client Identifier option to identify itself 2728 to the server. 2730 The client MUST include an Elapsed Time option (see Section 21.9) to 2731 indicate how long the client has been trying to complete the current 2732 DHCP message exchange. 2734 The client includes options containing the IAs for the leases it is 2735 releasing in the "options" field. The leases to be released MUST be 2736 included in the IAs. Any leases for the IAs the client wishes to 2737 continue to use MUST NOT be added to the IAs. 2739 The client MUST stop using all of the leases being released before 2740 the client begins the Release message exchange process. For an 2741 address, this means the address MUST have been removed from the 2742 interface. For a delegated prefix, this means the prefix MUST have 2743 been advertised with a Preferred Lifetime and a Valid Lifetime of 2744 zero in a Router Advertisement message as described in Section 5.5.3, 2745 (e) of [RFC4862] - also see L-13 in Section 4.3 of [RFC7084]. 2747 The client MUST NOT use any of the addresses it is releasing as the 2748 source address in the Release message or in any subsequently 2749 transmitted message. 2751 Because Release messages may be lost, the client should retransmit 2752 the Release if no Reply is received. However, there are scenarios 2753 where the client may not wish to wait for the normal retransmission 2754 timeout before giving up (e.g., on power down). Implementations 2755 SHOULD retransmit one or more times, but MAY choose to terminate the 2756 retransmission procedure early. 2758 The client transmits the message according to Section 15, using the 2759 following parameters: 2761 IRT REL_TIMEOUT 2762 MRT 0 2764 MRC REL_MAX_RC 2766 MRD 0 2768 If leases are released but the Reply from a DHCP server is lost, the 2769 client will retransmit the Release message, and the server may 2770 respond with a Reply indicating a status of NoBinding. Therefore, 2771 the client does not treat a Reply message with a status of NoBinding 2772 in a Release message exchange as if it indicates an error. 2774 Note that if the client fails to release the lease, each lease 2775 assigned to the IA will be reclaimed by the server when the valid 2776 lifetime of that lease expires. 2778 18.2.8. Creation and Transmission of Decline Messages 2780 If a client detects that one or more addresses assigned to it by a 2781 server are already in use by another node, the client sends a Decline 2782 message to the server to inform it that the address is suspect. 2784 The Decline message is not used in prefix delegation and thus the 2785 client MUST NOT include IA_PD options in the Decline message. 2787 The client sets the "msg-type" field to DECLINE. The client 2788 generates a transaction ID and places this value in the "transaction- 2789 id" field. 2791 The client places the identifier of the server that allocated the 2792 address(es) in a Server Identifier option. 2794 The client MUST include a Client Identifier option to identify itself 2795 to the server. 2797 The client MUST include an Elapsed Time option (see Section 21.9) to 2798 indicate how long the client has been trying to complete the current 2799 DHCP message exchange. 2801 The client includes options containing the IAs for the addresses it 2802 is declining in the "options" field. The addresses to be declined 2803 MUST be included in the IAs. Any addresses for the IAs the client 2804 wishes to continue to use should not be in added to the IAs. 2806 The client MUST NOT use any of the addresses it is declining as the 2807 source address in the Decline message or in any subsequently 2808 transmitted message. 2810 The client transmits the message according to Section 15, using the 2811 following parameters: 2813 IRT DEC_TIMEOUT 2815 MRT 0 2817 MRC DEC_MAX_RC 2819 MRD 0 2821 If addresses are declined but the Reply from a DHCP server is lost, 2822 the client will retransmit the Decline message, and the server may 2823 respond with a Reply indicating a status of NoBinding. Therefore, 2824 the client does not treat a Reply message with a status of NoBinding 2825 in a Decline message exchange as if it indicates an error. 2827 The client SHOULD NOT send a Release message for other bindings it 2828 may have received just because it sent a Decline message. The client 2829 SHOULD retain the non-conflicting bindings. The client SHOULD treat 2830 the failure to acquire a binding as a result of the conflict, to be 2831 equivalent to not having received the binding, insofar as it behaves 2832 when sending Renew and Rebind messages. 2834 18.2.9. Receipt of Advertise Messages 2836 Upon receipt of one or more valid Advertise messages, the client 2837 selects one or more Advertise messages based upon the following 2838 criteria. 2840 - Those Advertise messages with the highest server preference value 2841 are preferred over all other Advertise messages. 2843 - Within a group of Advertise messages with the same server 2844 preference value, a client MAY select those servers whose 2845 Advertise messages advertise information of interest to the 2846 client. 2848 - The client MAY choose a less-preferred server if that server has a 2849 better set of advertised parameters, such as the available set of 2850 IAs, as well as the set of other configuration options advertised. 2852 Once a client has selected Advertise message(s), the client will 2853 typically store information about each server, such as server 2854 preference value, addresses advertised, when the advertisement was 2855 received, and so on. 2857 In practice, this means that the client will maintain independent 2858 per-IA state machines per each selected server. 2860 If the client needs to select an alternate server in the case that a 2861 chosen server does not respond, the client chooses the next server 2862 according to the criteria given above. 2864 The client MUST process SOL_MAX_RT and INF_MAX_RT options in an 2865 Advertise message, even if the message contains a Status Code option 2866 indicating a failure, and the Advertise message will be discarded by 2867 the client. A client SHOULD only update its SOL_MAX_RT and 2868 INF_MAX_RT values if all received Advertise messages that contained 2869 the corresponding option specified the same value, otherwise it 2870 should use the default value (see Section 7.6). 2872 The client MUST ignore any Advertise message that contains no 2873 addresses (IA Address options encapsulated in IA_NA or IA_TA options) 2874 and no delegated prefixes (IA Prefix options encapsulated in IA_PD 2875 options) with the exception that the client: 2877 - MUST process an included SOL_MAX_RT option and 2879 - MUST process an included INF_MAX_RT option. 2881 A client can display any associated status message(s) to the user or 2882 activity log. 2884 The client ignoring this Advertise message MUST NOT restart the 2885 Solicit retransmission timer. 2887 18.2.10. Receipt of Reply Messages 2889 Upon the receipt of a valid Reply message in response to a Solicit 2890 (with a Rapid Commit option), Request, Confirm, Renew, Rebind, or 2891 Information-request message, the client extracts the top-level Status 2892 Code option if present. 2894 The client MUST process SOL_MAX_RT and INF_MAX_RT options in an Reply 2895 message, even if the message contains a Status Code option indicating 2896 a failure. 2898 If the client receives a Reply message with a status code of 2899 UnspecFail, the server is indicating that it was unable to process 2900 the client's message due to an unspecified failure condition. If the 2901 client retransmits the original message to the same server to retry 2902 the desired operation, the client MUST limit the rate at which it 2903 retransmits the message and limit the duration of the time during 2904 which it retransmits the message (see Section 14.1). 2906 If the client receives a Reply message with a status code of 2907 UseMulticast, the client records the receipt of the message and sends 2908 subsequent messages to the server through the interface on which the 2909 message was received using multicast. The client resends the 2910 original message using multicast. 2912 Otherwise (no status code or another status code), the client 2913 processes the Reply as described below based on the original message 2914 for which the Reply was received. 2916 The client MAY choose to report any status code or message from the 2917 Status Code option in the Reply message. 2919 When a client received a configuration option in an earlier Reply, 2920 then sends a Renew, Rebind or Information-request and the requested 2921 option is not present in the Reply, the client SHOULD stop using the 2922 previously received configuration information. In other words, the 2923 client should behave as if it never received this configuration 2924 option and return to the relevant default state. If there is no 2925 viable way to stop using the received configuration information, the 2926 values received/configured from the option MAY persist if there are 2927 no other sources for that data and they have no external impact. For 2928 example, a client that previously received a Client FQDN option and 2929 used it to set up its hostname is allowed to continue using it if 2930 there is no reasonable way for a node to unset its hostname and it 2931 has no external impact. As a counter example, a client that 2932 previously received an NTP server address from the DHCP server and 2933 does not receive it any more, MUST stop using the configured NTP 2934 server address. The client SHOULD be open to other sources of the 2935 same configuration information. This behavior does not apply to any 2936 IA containers, as their processing is described in detail in other 2937 parts of this document. 2939 When a client receives a requested option that has an updated value 2940 from what was previously received, the client SHOULD make use of that 2941 updated value as soon as possible for its configuration information. 2943 18.2.10.1. Reply for Solicit (with Rapid Commit), Request, Renew or 2944 Rebind 2946 If the client receives a NotOnLink status from the server in response 2947 to a Solicit (with a Rapid Commit option) or a Request, the client 2948 can either re-issue the message without specifying any addresses or 2949 restart the DHCP server discovery process (see Section 18). 2951 If the Reply was received in response to a Solicit (with a Rapid 2952 Commit option), Request, Renew, or Rebind message, the client updates 2953 the information it has recorded about IAs from the IA options 2954 contained in the Reply message: 2956 - Record T1 and T2 times, if appropriate for the IA type. 2958 - Add any new leases in the IA option to the IA as recorded by the 2959 client. 2961 - Update lifetimes for any leases in the IA option that the client 2962 already has recorded in the IA. 2964 - Discard any leases from the IA, as recorded by the client, that 2965 have a valid lifetime of 0 in the IA Address or IA Prefix option. 2967 - Leave unchanged any information about leases the client has 2968 recorded in the IA but that were not included in the IA from the 2969 server. 2971 If the client can operate with the addresses and/or prefixes obtained 2972 from the server: 2974 - The client uses the addresses, delegated prefixes, and other 2975 information from any IAs that do not contain a Status Code option 2976 with the NoAddrsAvail or NoPrefixAvail status code. The client 2977 MAY include the IAs for which it received the NoAddrsAvail or 2978 NoPrefixAvail status code, with no addresses or prefixes, in 2979 subsequent Renew and Rebind messages sent to the server, to retry 2980 obtaining the addresses or prefixes for these IAs. 2982 - The client MUST perform duplicate address detection as per 2983 [RFC4862] Section 5.4, which does list some exceptions, on each of 2984 the received addresses in any IAs, on which it has not performed 2985 duplicate address detection during processing of any of the 2986 previous Reply messages from the server. The client performs the 2987 duplicate address detection before using the received addresses 2988 for any traffic. If any of the addresses are found to be in use 2989 on the link, the client sends a Decline message to the server for 2990 those addresses as described in Section 18.2.8. 2992 - For each assigned address, which does not have any associated 2993 reachability information, in order to avoid the problems described 2994 in [RFC4943], the client MUST NOT assume that any addresses are 2995 reachable on-link as a result of receiving an IA_NA or IA_TA. 2996 Addresses obtained from IA_NA or IA_TA MUST NOT be used to form an 2997 implicit prefix with a length other than 128. 2999 - For each delegated prefix, the client assigns a subnet to each of 3000 the links to which the associated interfaces are attached, with 3001 the following exception: the client MUST NOT advertise any 3002 delegated prefixes or subnets from the delegated prefix(es) to the 3003 link through which it received the DHCP message from the server 3004 (see [RFC6603] for exceptions). 3006 When a client subnets a delegated prefix, it must assign 3007 additional bits to the prefix to generate unique, longer prefixes. 3008 For example, if the client in Figure 1 were delegated 3009 2001:db8:0::/48, it might generate 2001:db8:0:1::/64 and 3010 2001:db8:0:2::/64 for assignment to the two links in the 3011 subscriber network. If the client were delegated 2001:db8:0::/48 3012 and 2001:db8:5::/48, it might assign 2001:db8:0:1::/64 and 3013 2001:db8:5:1::/64 to one of the links, and 2001:db8:0:2::/64 and 3014 2001:db8:5:2::/64 for assignment to the other link. 3016 If the client assigns a delegated prefix to a link to which the 3017 router is attached, and begins to send router advertisements for 3018 the prefix on the link, the client MUST set the valid lifetime in 3019 those advertisements to be no later than the valid lifetime 3020 specified in the IA_PD option. A client MAY use the preferred 3021 lifetime specified in the IA_PD option. 3023 Management of the specific configuration information is detailed in 3024 the definition of each option in Section 21. 3026 If the Reply message contains any IAs, but the client finds no usable 3027 addresses and/or delegated prefixes in any of these IAs, the client 3028 may either try another server (perhaps restarting the DHCP server 3029 discovery process) or use the Information-request message to obtain 3030 other configuration information only. 3032 When the client receives a Reply message in response to a Renew or 3033 Rebind message, the client: 3035 - Sends a Request message if any of the IAs in the Reply message 3036 contains the NoBinding status code to the server that responded. 3037 The client places IA options in this message for all IAs. The 3038 client continues to use other bindings for which the server did 3039 not return an error. 3041 - Sends a Renew/Rebind if any of the IAs are not in the Reply 3042 message, but in this case the client MUST limit the rate at which 3043 it sends these messages, to avoid the Renew/Rebind storm. 3045 - Otherwise accepts the information in the IA. 3047 Whenever a client restarts the DHCP server discovery process or 3048 selects an alternate server, as described in Section 18.2.9, the 3049 client SHOULD stop using all the addresses and delegated prefixes for 3050 which it has bindings and try to obtain all required leases from the 3051 new server. This facilitates the client using a single state machine 3052 for all bindings. 3054 18.2.10.2. Reply for Release and Decline 3056 When the client receives a valid Reply message in response to a 3057 Release message, the client considers the Release event completed, 3058 regardless of the Status Code option(s) returned by the server. 3060 When the client receives a valid Reply message in response to a 3061 Decline message, the client considers the Decline event completed, 3062 regardless of the Status Code option(s) returned by the server. 3064 18.2.10.3. Reply for Confirm 3066 If the client receives any Reply messages that indicate a success 3067 status (explicit or implicit), the client can use the addresses in 3068 the IA and ignore any messages that indicate a NotOnLink status. 3069 When the client only receives one or more Replies with the NotOnLink 3070 status in response to a Confirm message, the client performs DHCP 3071 server discovery as described in Section 18. 3073 18.2.10.4. Reply for Information-request 3075 Refer to Section 21.23 for details on how the Information Refresh 3076 Time option (whether or not present in the Reply) should be handled 3077 by the client. 3079 18.2.11. Receipt of Reconfigure Messages 3081 A client receives Reconfigure messages sent to the UDP port 546 on 3082 interfaces for which it has acquired configuration information 3083 through DHCP. These messages may be sent at any time. Since the 3084 results of a reconfiguration event may affect application layer 3085 programs, the client SHOULD log these events, and MAY notify these 3086 programs of the change through an implementation-specific interface. 3088 Upon receipt of a valid Reconfigure message, the client responds with 3089 either a Renew message, a Rebind message, or an Information-request 3090 message as indicated by the Reconfigure Message option (as defined in 3091 Section 21.19). The client ignores the transaction-id field in the 3092 received Reconfigure message. While the transaction is in progress, 3093 the client discards any Reconfigure messages it receives. 3095 The Reconfigure message acts as a trigger that signals the client to 3096 complete a successful message exchange. Once the client has received 3097 a Reconfigure, the client proceeds with the message exchange 3098 (retransmitting the Renew, Rebind, or Information-request message if 3099 necessary); the client MUST ignore any additional Reconfigure 3100 messages until the exchange is complete. Subsequent Reconfigure 3101 messages cause the client to initiate a new exchange. 3103 Duplicate messages will be ignored because the client will begin the 3104 exchange after the receipt of the first Reconfigure. Retransmitted 3105 messages will either trigger the exchange (if the first Reconfigure 3106 was not received by the client) or will be ignored. The server MAY 3107 discontinue retransmission of Reconfigure messages to the client once 3108 the server receives the Renew, Rebind or Information-request message 3109 from the client. 3111 It might be possible for a duplicate or retransmitted Reconfigure to 3112 be sufficiently delayed (and delivered out of order) to arrive at the 3113 client after the exchange (initiated by the original Reconfigure) has 3114 been completed. In this case, the client would initiate a redundant 3115 exchange. The likelihood of delayed and out of order delivery is 3116 small enough to be ignored. The consequence of the redundant 3117 exchange is inefficiency rather than incorrect operation. 3119 18.2.12. Refreshing Configuration Information 3121 Whenever a client may have moved to a new link, the prefixes/ 3122 addresses assigned to the interfaces on that link may no longer be 3123 appropriate for the link to which the client is attached. Examples 3124 of times when a client may have moved to a new link include: 3126 o The client reboots (and has stable storage and persisted DHCP 3127 state). 3129 o The client is reconnected to a link on which it has obtained 3130 leases. 3132 o The client returns from sleep mode. 3134 o The client changes access points (such as if using a wireless 3135 technology). 3137 When the client detects one of the above conditions and it has 3138 obtained addresses and no delegated prefixes from a server, the 3139 client SHOULD initiate a Confirm/Reply message exchange. The client 3140 includes any IAs assigned to the interface that may have moved to a 3141 new link, along with the addresses associated with those IAs, in its 3142 Confirm message. Any responding servers will indicate whether those 3143 addresses are appropriate for the link to which the client is 3144 attached with the status in the Reply message it returns to the 3145 client. 3147 If the client has any valid delegated prefixes obtained from the DHCP 3148 server, the client MUST initiate a Rebind/Reply message exchange as 3149 described in Section 18.2.5, with the exception that the 3150 retransmission parameters should be set as for the Confirm message as 3151 described below. The client includes IA_NAs, IA_TAs, and IA_PDs, 3152 along with the associated leases, in its Rebind message. 3154 If the client has obtained network information from Information 3155 Request, the client MUST initiate a Information-Request/Reply message 3156 exchange as described in Section 18.2.6. 3158 If not associated with one of the above mentioned conditions, a 3159 client MAY initiate a Renew/Reply exchange (as if the T1 time 3160 expired) as described in Section 18.2.4 or an Information-Request/ 3161 Reply exchange as described in Section 18.2.6 if the client detects a 3162 significant change regarding the prefixes available on the link (when 3163 new are added or existing are deprecated) as is may incidate a 3164 configuration change. However, a client MUST rate limit such 3165 attempts to avoid flooding a server with requests when there are link 3166 issues (for example, only doing one of these at most every 30 3167 seconds). 3169 18.3. Server Behavior 3171 For this discussion, the Server is assumed to have been configured in 3172 an implementation specific manner with configuration of interest to 3173 clients. 3175 A server sends an Advertise message in response to each valid Solicit 3176 message it receives to announce the availability of the server to the 3177 client. 3179 In most cases, the server will send a Reply in response to a Request, 3180 Confirm, Renew, Rebind, Decline, Release, and Information-request 3181 messages sent by a client. The server will also send a Reply in 3182 response to a Solicit with a Rapid Commit option, when the server is 3183 configured to respond with committed lease assignments. 3185 This Reply message MUST always contain the Server Identifier option 3186 containing the server's DUID and the Client Identifier option from 3187 the client message if one was present. 3189 In most response messages, the server includes options containing 3190 configuration information for the client. The server must be aware 3191 of the recommendations on packet sizes and the use of fragmentation 3192 in section 5 of [RFC2460]. If the client included an Option Request 3193 option in its message, the server includes options in the reply 3194 message containing configuration parameters for all of the options 3195 identified in the Option Request option that the server has been 3196 configured to return to the client. The server MAY return additional 3197 options to the client if it has been configured to do so. 3199 The server MAY initiate a configuration exchange, by sending 3200 Reconfigure messages, to cause DHCP clients to obtain new addresses, 3201 prefixes and other configuration information. For example, an 3202 administrator may use a server-initiated configuration exchange when 3203 links in the DHCP domain are to be renumbered. Other examples 3204 include changes in the location of directory servers, addition of new 3205 services such as printing, and availability of new software. 3207 When a client receives a Reconfigure message from the server, the 3208 client initiates sending a Renew, Rebind or Information-request 3209 message as indicated by msg-type in the Reconfigure Message option 3210 (as defined in Section 21.19). The server sends IAs and/or other 3211 configuration information to the client in a Reply message. The 3212 server MAY include options containing the IAs and new values for 3213 other configuration parameters in the Reply message, even if those 3214 IAs and parameters were not requested in the client's message. 3216 18.3.1. Receipt of Solicit Messages 3218 See Section 18.4 for handling Solicit message received via unicast. 3219 Unicast transmission of Solicit is not allowed, regardless if Server 3220 Unicast option is configured or not. 3222 The server determines the information about the client and its 3223 location as described in Section 13 and checks its administrative 3224 policy about responding to the client. If the server is not 3225 permitted to respond to the client, the server discards the Solicit 3226 message. For example, if the administrative policy for the server is 3227 that it may only respond to a client that is willing to accept a 3228 Reconfigure message, if the client does not include a Reconfigure 3229 Accept option (see Section 21.20) in the Solicit message, the server 3230 discards the Solicit message. 3232 If the server is permitted to respond to the client, the client has 3233 not included a Rapid Commit option in the Solicit message or the 3234 server has not been configured to respond with committed assignment 3235 of leases and other resources, the server sends an Advertise message 3236 to the client as described in Section 18.3.9. 3238 If the client has included a Rapid Commit option in the Solicit 3239 message and the server has been configured to respond with committed 3240 assignments of leases and other resources, the server responds to the 3241 Solicit with a Reply message. The server produces the Reply message 3242 as though it had received a Request message, as described in 3243 Section 18.3.2. The server transmits the Reply message as described 3244 in Section 18.3.10. The server MUST commit the assignment of any 3245 addresses and delegated prefixes or other configuration information 3246 before sending a Reply message to a client. In this case the server 3247 includes a Rapid Commit option in the Reply message to indicate that 3248 the Reply is in response to a Solicit message. 3250 DISCUSSION: 3252 When using the Solicit/Reply message exchange, the server commits 3253 the assignment of any leases before sending the Reply message. 3254 The client can assume it has been assigned the leases in the Reply 3255 message and does not need to send a Request message for those 3256 leases. 3258 Typically, servers that are configured to use the Solicit/Reply 3259 message exchange will be deployed so that only one server will 3260 respond to a Solicit message. If more than one server responds, 3261 the client will only use the leases from one of the servers, while 3262 the leases from the other servers will be committed to the client 3263 but not used by the client. 3265 18.3.2. Receipt of Request Messages 3267 See Section 18.4 for handling Request message received via unicast. 3269 When the server receives a valid Request message, the server creates 3270 the bindings for that client according to the server's policy and 3271 configuration information and records the IAs and other information 3272 requested by the client. 3274 The server constructs a Reply message by setting the "msg-type" field 3275 to REPLY, and copying the transaction ID from the Request message 3276 into the transaction-id field. 3278 The server MUST include a Server Identifier option containing the 3279 server's DUID and the Client Identifier option from the Request 3280 message in the Reply message. 3282 The server examines all IAs in the message from the client. 3284 For each IA_NA and IA_TA in the Request message the server checks if 3285 the prefixes of included addresses are appropriate for the link to 3286 which the client is connected. If any of the prefixes of the 3287 included addresses is not appropriate for the link to which the 3288 client is connected, the server MUST return the IA to the client with 3289 a Status Code option with the value NotOnLink. If the server does 3290 not send the NotOnLink status code but it cannot assign any IP 3291 addresses to an IA, the server MUST return the IA option in the Reply 3292 message with no addresses in the IA and a Status Code option 3293 containing status code NoAddrsAvail in the IA. 3295 For any IA_PD in the Request message, to which the server cannot 3296 assign any delegated prefixes, the server MUST return the IA_PD 3297 option in the Reply message with no prefixes in the IA_PD and with a 3298 Status Code option containing status code NoPrefixAvail in the IA_PD. 3300 The server MAY assign different addresses and/or delegated prefixes 3301 to an IA than those included within the IA of the client's Request 3302 message. 3304 For all IAs to which the server can assign addresses or delegated 3305 prefixes, the server includes the IAs with addresses (for IA_NA and 3306 IA_TA), prefixes (for IA_PD) and other configuration parameters, and 3307 records the IA as a new client binding. The server MUST NOT include 3308 any addresses or delegated prefixes in the IA which the server does 3309 not assign to the client. 3311 The T1/T2 times set in each applicable IA option for a Reply MUST be 3312 the same values across all IAs. The server MUST determine the T1/T2 3313 times across all of the applicable client's bindings in the Reply. 3314 This facilitates the client being able to renew all of the bindings 3315 at the same time. 3317 The server SHOULD include a Reconfigure Accept option if the server 3318 policy enables reconfigure mechanism and the client supports it. 3319 Currently sending this option in Reply is technically redundant, as 3320 the use of the reconfiguration mechanism requires an authentication 3321 and currently the only defined one is Reconfigure Key Authentication 3322 Protocol (see Section 20.4 for details) and the presence or 3323 reconfigure key signals support for Reconfigure acceptance. However, 3324 there may be better security mechanisms defined in the future that 3325 would cause RKAP to not be used anymore. One of such mechanisms 3326 currently worked on in mentioned in Section 22. 3328 The server includes other options containing configuration 3329 information to be returned to the client as described in 3330 Section 18.3. 3332 If the server finds that the client has included an IA in the Request 3333 message for which the server already has a binding that associates 3334 the IA with the client, the server sends a Reply message with 3335 existing bindings, possibly with updated lifetimes. The server may 3336 update the bindings according to its local policies, but the server 3337 SHOULD generate the response again and not simply retransmit 3338 previously sent information, even if the transaction-id matches a 3339 previous transmission. The server MUST NOT cache its responses. 3341 18.3.3. Receipt of Confirm Messages 3343 See Section 18.4 for handling Confirm message received via unicast. 3344 Unicast transmission of Confirm is not allowed, regardless if Server 3345 Unicast option is configured or not. 3347 When the server receives a Confirm message, the server determines 3348 whether the addresses in the Confirm message are appropriate for the 3349 link to which the client is attached. If all of the addresses in the 3350 Confirm message pass this test, the server returns a status of 3351 Success. If any of the addresses do not pass this test, the server 3352 returns a status of NotOnLink. If the server is unable to perform 3353 this test (for example, the server does not have information about 3354 prefixes on the link to which the client is connected), or there were 3355 no addresses in any of the IAs sent by the client, the server MUST 3356 NOT send a Reply to the client. 3358 The server ignores the T1 and T2 fields in the IA options and the 3359 preferred-lifetime and valid-lifetime fields in the IA Address 3360 options. 3362 The server constructs a Reply message by setting the "msg-type" field 3363 to REPLY, and copying the transaction ID from the Confirm message 3364 into the transaction-id field. 3366 The server MUST include a Server Identifier option containing the 3367 server's DUID and the Client Identifier option from the Confirm 3368 message in the Reply message. The server includes a Status Code 3369 option indicating the status of the Confirm message. 3371 18.3.4. Receipt of Renew Messages 3373 See Section 18.4 for handling Renew message received via unicast. 3375 For each IA in the Renew message from a client, the server locates 3376 the client's binding and verifies that the information in the IA from 3377 the client matches the information stored for that client. 3379 If the server finds the client entry for the IA, the server sends 3380 back the IA to the client with new lifetimes and, if applicable, T1/ 3381 T2 times. If the server is unable to extend the lifetimes of an 3382 address or delegated prefix in the IA, the server MAY choose not to 3383 include the IA Address or IA Prefix option for this address or 3384 delegated prefix. If the server chooses to include the IA Address or 3385 IA Prefix option for such an address or delegated prefix, the server 3386 SHOULD set T1 and T2 to the valid lifetime for the IA option unless 3387 the server also includes other addresses or delegated prefixes which 3388 the server is able to extend for the IA. Setting T1 and T2 to values 3389 equal to valid lifetime informs the client that the leases associated 3390 with said IA will not be extended, so there is no point in trying. 3391 Also, it avoids generating unnecessary traffic as the remaining 3392 lifetime approaches 0. 3394 The server may choose to change the list of addresses or delegated 3395 prefixes and the lifetimes in IAs that are returned to the client. 3397 If the server finds that any of the addresses in the IA are not 3398 appropriate for the link to which the client is attached, the server 3399 returns the address to the client with lifetimes of 0. 3401 If the server finds that any of the delegated prefixes in the IA are 3402 not appropriate for the link to which the client is attached, the 3403 server returns the delegated prefix to the client with lifetimes of 3404 0. 3406 For each IA for which the server cannot find a client entry, the 3407 server has the following choices depending on the server's policy and 3408 configuration information: 3410 - If the server is configured to create new bindings as a result of 3411 processing Renew messages, the server SHOULD create a binding and 3412 return the IA with assigned addresses or delegated prefixes with 3413 lifetimes and, if applicable, T1/T2 times and other information 3414 requested by the client. If the client included the IA Prefix 3415 option within the IA_PD option with zero value in the "IPv6 3416 prefix" field and non-zero value in the "prefix-length" field, the 3417 server MAY use the "prefix-length" value as a hint for the length 3418 of the prefixes to be assigned (see 3419 [I-D.ietf-dhc-dhcpv6-prefix-length-hint-issue] for further details 3420 on prefix length hints). 3422 - If the server is configured to create new bindings as a result of 3423 processing Renew messages, but the server will not assign any 3424 leases to an IA, the server returns the IA option containing a 3425 Status Code option with the NoAddrsAvail or NoPrefixAvail status 3426 code and a status message for a user. 3428 - If the server does not support creation of new bindings for the 3429 client sending a Renew message, or if this behavior is disabled 3430 according to the server's policy or configuration information, the 3431 server returns the IA option containing a Status Code option with 3432 the NoBinding status code and a status message for a user. 3434 The server constructs a Reply message by setting the "msg-type" field 3435 to REPLY and copying the transaction ID from the Renew message into 3436 the "transaction-id" field. 3438 The server MUST include a Server Identifier option containing the 3439 server's DUID and the Client Identifier option from the Renew message 3440 in the Reply message. 3442 The server includes other options containing configuration 3443 information to be returned to the client as described in 3444 Section 18.3. 3446 The server MAY include options containing the IAs and values for 3447 other configuration parameters, even if those parameters were not 3448 requested in the Renew message. 3450 The T1/T2 times set in each applicable IA option for a Reply MUST be 3451 the same values across all IAs. The server MUST determine the T1/T2 3452 times across all of the applicable client's bindings in the Reply. 3453 This facilitates the client being able to renew all of the bindings 3454 at the same time. 3456 18.3.5. Receipt of Rebind Messages 3458 See Section 18.4 for handling Rebind message received via unicast. 3459 Unicast transmission of Rebind is not allowed, regardless if Server 3460 Unicast option is configured or not. 3462 When the server receives a Rebind message that contains an IA option 3463 from a client, it locates the client's binding and verifies that the 3464 information in the IA from the client matches the information stored 3465 for that client. 3467 If the server finds the client entry for the IA and the server 3468 determines that the addresses or delegated prefixes in the IA are 3469 appropriate for the link to which the client's interface is attached 3470 according to the server's explicit configuration information, the 3471 server SHOULD send back the IA to the client with new lifetimes and, 3472 if applicable, T1/T2 times. If the server is unable to extend the 3473 lifetimes of an address in the IA, the server MAY choose not to 3474 include the IA Address option for this address. If the server is 3475 unable to extend the lifetimes of a delegated prefix in the IA, the 3476 server MAY choose not to include the IA Prefix option for this 3477 prefix. 3479 If the server finds that the client entry for the IA and any of the 3480 addresses or delegated prefixes are no longer appropriate for the 3481 link to which the client's interface is attached according to the 3482 server's explicit configuration information, the server returns the 3483 address or delegated prefix to the client with lifetimes of 0. 3485 If the server cannot find a client entry for the IA, the server 3486 checks if the IA contains addresses (for IA_NA and IA_TA) or 3487 delegated prefixes (for IA_PD). The server checks if the addresses 3488 and delegated prefixes are appropriate for the link to which the 3489 client's interface is attached according to the server's explicit 3490 configuration information. For any address which is not appropriate 3491 for the link to which the client's interface is attached, the server 3492 MAY include the IA Address option with the lifetimes of 0. For any 3493 delegated prefix which is not appropriate for the link to which the 3494 client's interface is attached, the server MAY include the IA Prefix 3495 option with the lifetimes of 0. The Reply with lifetimes of 0 3496 constitutes an explicit notification to the client that the specific 3497 addresses and delegated prefixes are no longer valid and MUST NOT be 3498 used by the client. If the server chooses to not include any IAs 3499 containing IA Address or IA Prefix options with lifetimes of 0 and 3500 the server does not include any other IAs with leases and/or status 3501 codes, the server does not send a Reply message. In this situation 3502 the server discards the Rebind message. 3504 Otherwise, for each IA for which the server cannot find a client 3505 entry, the server has the following choices depending on the server's 3506 policy and configuration information: 3508 - If the server is configured to create new bindings as a result of 3509 processing Rebind messages (also see the note about the Rapid 3510 Commit option below), the server SHOULD create a binding and 3511 return the IA with allocated leases with lifetimes and, if 3512 applicable, T1/T2 times and other information requested by the 3513 client. The server MUST NOT return any addresses or delegated 3514 prefixes in the IA which the server does not assign to the client. 3516 - If the server is configured to create new bindings as a result of 3517 processing Rebind messages, but the server will not assign any 3518 leases to an IA, the server returns the IA option containing a 3519 Status Code option with the NoAddrsAvail or NoPrefixAvail status 3520 code and a status message for a user. 3522 - If the server does not support creation of new bindings for the 3523 client sending a Rebind message, or if this behavior is disabled 3524 according to the server's policy or configuration information, the 3525 server returns the IA option containing a Status Code option with 3526 the NoBinding status code and a status message for a user. 3528 When the server creates new bindings for the IA, it is possible that 3529 other servers also create bindings as a result of receiving the same 3530 Rebind message. This is the same issue as in the Discussion under 3531 "Rapid Commit Option"; see Section 21.14. Therefore, the server 3532 SHOULD only create new bindings during processing of a Rebind message 3533 if the server is configured to respond with a Reply message to a 3534 Solicit message containing the Rapid Commit option. 3536 The server constructs a Reply message by setting the "msg-type" field 3537 to REPLY and copying the transaction ID from the Rebind message into 3538 the "transaction-id" field. 3540 The server MUST include a Server Identifier option containing the 3541 server's DUID and the Client Identifier option from the Rebind 3542 message in the Reply message. 3544 The server includes other options containing configuration 3545 information to be returned to the client as described in 3546 Section 18.3. 3548 The server MAY include options containing the IAs and values for 3549 other configuration parameters, even if those IAs and parameters were 3550 not requested in the Rebind message. 3552 The T1/T2 times set in each applicable IA option for a Reply MUST be 3553 the same values across all IAs. The server MUST determine the T1/T2 3554 times across all of the applicable client's bindings in the Reply. 3555 This facilitates the client being able to renew all of the bindings 3556 at the same time. 3558 18.3.6. Receipt of Information-request Messages 3560 See Section 18.4 for handling Information-request message received 3561 via unicast. 3563 When the server receives an Information-request message, the client 3564 is requesting configuration information that does not include the 3565 assignment of any leases. The server determines all configuration 3566 parameters appropriate to the client, based on the server 3567 configuration policies known to the server. 3569 The server constructs a Reply message by setting the "msg-type" field 3570 to REPLY, and copying the transaction ID from the Information-request 3571 message into the transaction-id field. 3573 The server MUST include a Server Identifier option containing the 3574 server's DUID in the Reply message. If the client included a Client 3575 Identification option in the Information-request message, the server 3576 copies that option to the Reply message. 3578 The server includes options containing configuration information to 3579 be returned to the client as described in Section 18.3. The server 3580 MAY include additional options that were not requested by the client 3581 in the Information-request message. 3583 If the Information-request message received from the client did not 3584 include a Client Identifier option, the server SHOULD respond with a 3585 Reply message containing any configuration parameters that are not 3586 determined by the client's identity. If the server chooses not to 3587 respond, the client may continue to retransmit the Information- 3588 request message indefinitely. 3590 18.3.7. Receipt of Release Messages 3592 See Section 18.4 for handling Release message received via unicast. 3594 The server constructs a Reply message by setting the "msg-type" field 3595 to REPLY, and copying the transaction ID from the Release message 3596 into the transaction-id field. 3598 Upon the receipt of a valid Release message, the server examines the 3599 IAs and the leases in the IAs for validity. If the IAs in the 3600 message are in a binding for the client, and the leases in the IAs 3601 have been assigned by the server to those IAs, the server deletes the 3602 leases from the IAs and makes the leases available for assignment to 3603 other clients. The server ignores leases not assigned to the IA, 3604 although it may choose to log an error. 3606 After all the leases have been processed, the server generates a 3607 Reply message and includes a Status Code option with value Success, a 3608 Server Identifier option with the server's DUID, and a Client 3609 Identifier option with the client's DUID. For each IA in the Release 3610 message for which the server has no binding information, the server 3611 adds an IA option using the IAID from the Release message, and 3612 includes a Status Code option with the value NoBinding in the IA 3613 option. No other options are included in the IA option. 3615 A server may choose to retain a record of assigned leases and IAs 3616 after the lifetimes on the leases have expired to allow the server to 3617 reassign the previously assigned leases to a client. 3619 18.3.8. Receipt of Decline Messages 3621 See Section 18.4 for handling Decline message received via unicast. 3623 Upon the receipt of a valid Decline message, the server examines the 3624 IAs and the addresses in the IAs for validity. If the IAs in the 3625 message are in a binding for the client, and the addresses in the IAs 3626 have been assigned by the server to those IAs, the server deletes the 3627 addresses from the IAs. The server ignores addresses not assigned to 3628 the IA (though it may choose to log an error if it finds such an 3629 address). 3631 The client has found any addresses in the Decline messages to be 3632 already in use on its link. Therefore, the server SHOULD mark the 3633 addresses declined by the client so that those addresses are not 3634 assigned to other clients, and MAY choose to make a notification that 3635 addresses were declined. Local policy on the server determines when 3636 the addresses identified in a Decline message may be made available 3637 for assignment. 3639 After all the addresses have been processed, the server generates a 3640 Reply message by setting the "msg-type" field to REPLY, and copying 3641 the transaction ID from the Decline message into the transaction-id 3642 field. The client includes a Status Code option with the value 3643 Success, a Server Identifier option with the server's DUID, and a 3644 Client Identifier option with the client's DUID. For each IA in the 3645 Decline message for which the server has no binding information, the 3646 server adds an IA option using the IAID from the Decline message and 3647 includes a Status Code option with the value NoBinding in the IA 3648 option. No other options are included in the IA option. 3650 18.3.9. Creation and Transmission of Advertise Messages 3652 The server sets the "msg-type" field to ADVERTISE and copies the 3653 contents of the transaction-id field from the Solicit message 3654 received from the client to the Advertise message. The server 3655 includes its server identifier in a Server Identifier option and 3656 copies the Client Identifier option from the Solicit message into the 3657 Advertise message. 3659 The server MAY add a Preference option to carry the preference value 3660 for the Advertise message. The server implementation SHOULD allow 3661 the setting of a server preference value by the administrator. The 3662 server preference value MUST default to zero unless otherwise 3663 configured by the server administrator. 3665 The server includes a Reconfigure Accept option if the server wants 3666 to indicate it supports Reconfigure mechanism. This information may 3667 be used by the client during the server selection process. 3669 The server includes the options the server will return to the client 3670 in a subsequent Reply message. The information in these options may 3671 be used by the client in the selection of a server if the client 3672 receives more than one Advertise message. The server MUST include 3673 options in the Advertise message containing configuration parameters 3674 for all of the options identified in the Option Request option in the 3675 Solicit message that the server has been configured to return to the 3676 client. If the Option Request option includes a container option the 3677 server MUST include all the options that are eligible to be 3678 encapsulated in the container. The Option Request option MAY be used 3679 to signal support for a feature even when that option is encapsulated 3680 as in the case of the Prefix Exclude option [RFC6603]. In this case, 3681 special processing is required by the server. The server MAY return 3682 additional options to the client if it has been configured to do so. 3683 The server must be aware of the recommendations on packet sizes and 3684 the use of fragmentation in section 5 of [RFC2460]. 3686 The server MUST include IA options in the Advertise message 3687 containing any addresses and/or delegated prefixes that would be 3688 assigned to IAs contained in the Solicit message from the client. If 3689 the client has included addresses in the IA in the Solicit message, 3690 the server MAY use those addresses as hints about the addresses that 3691 the client would like to receive. If the client has included IA 3692 Prefix option in the IA_PD, the server MAY use the prefix contained 3693 in the IPv6-prefix field and/or the prefix length contained in the 3694 "prefix-length" field as a hints about the prefixes the client would 3695 like to receive. If the server is not going to assign an address or 3696 delegated prefix received as a hint in the Solicit message, the 3697 server MUST NOT include this address or delegated prefix in the 3698 Advertise message. 3700 If the server will not assign any addresses to an IA (IA_NA or IA_TA) 3701 in subsequent Request from the client, the server MUST include the IA 3702 in the Advertise message with no addresses in the IA and a Status 3703 Code option encapsulated in the IA containing status code 3704 NoAddrsAvail. 3706 If the server will not assign any prefixes to an IA_PD in subsequent 3707 Request from the client, the server MUST include the IA_PD in the 3708 Advertise message with no prefixes in the IA and a Status Code option 3709 encapsulated in the IA_PD containing status code NoPrefixAvail. 3711 If the Solicit message was received directly by the server, the 3712 server unicasts the Advertise message directly to the client using 3713 the address in the source address field from the IP datagram in which 3714 the Solicit message was received. The Advertise message MUST be 3715 unicast on the link from which the Solicit message was received. 3717 If the Solicit message was received in a Relay-forward message, the 3718 server constructs a Relay-reply message with the Advertise message in 3719 the payload of a "relay-message" option. If the Relay-forward 3720 messages included an Interface-id option, the server copies that 3721 option to the Relay-reply message. The server unicasts the Relay- 3722 reply message directly to the relay agent using the address in the 3723 source address field from the IP datagram in which the Relay-forward 3724 message was received. 3726 18.3.10. Transmission of Reply Messages 3728 If the original message was received directly by the server, the 3729 server unicasts the Reply message directly to the client using the 3730 address in the source address field from the IP datagram in which the 3731 original message was received. The Reply message MUST be unicast 3732 through the interface on which the original message was received. 3734 If the original message was received in a Relay-forward message, the 3735 server constructs a Relay-reply message with the Reply message in the 3736 payload of a Relay Message option (see Section 21.10). If the Relay- 3737 forward messages included an Interface-id option, the server copies 3738 that option to the Relay-reply message. The server unicasts the 3739 Relay-reply message directly to the relay agent using the address in 3740 the source address field from the IP datagram in which the Relay- 3741 forward message was received. 3743 18.3.11. Creation and Transmission of Reconfigure Messages 3745 The server sets the "msg-type" field to RECONFIGURE. The server sets 3746 the transaction-id field to 0. The server includes a Server 3747 Identifier option containing its DUID and a Client Identifier option 3748 containing the client's DUID in the Reconfigure message. 3750 Because of the risk of denial of service attacks against DHCP 3751 clients, the use of a security mechanism is mandated in Reconfigure 3752 messages. The server MUST use DHCP authentication in the Reconfigure 3753 message. 3755 The server MUST include a Reconfigure Message option (defined in 3756 Section 21.19) to select whether the client responds with a Renew 3757 message, a Rebind message, or an Information-request message. 3759 The server MUST NOT include any other options in the Reconfigure 3760 except as specifically allowed in the definition of individual 3761 options. 3763 A server sends each Reconfigure message to a single DHCP client, 3764 using an IPv6 unicast address of sufficient scope belonging to the 3765 DHCP client. If the server does not have an address to which it can 3766 send the Reconfigure message directly to the client, the server uses 3767 a Relay-reply message (as described in Section 19.3) to send the 3768 Reconfigure message to a relay agent that will relay the message to 3769 the client. The server may obtain the address of the client (and the 3770 appropriate relay agent, if required) through the information the 3771 server has about clients that have been in contact with the server, 3772 or through some external agent. 3774 To reconfigure more than one client, the server unicasts a separate 3775 message to each client. The server may initiate the reconfiguration 3776 of multiple clients concurrently; for example, a server may send a 3777 Reconfigure message to additional clients while previous 3778 reconfiguration message exchanges are still in progress. 3780 The Reconfigure message causes the client to initiate a Renew/Reply, 3781 a Rebind/Reply, or Information-request/Reply message exchange with 3782 the server. The server interprets the receipt of a Renew, a Rebind, 3783 or Information-request message (whichever was specified in the 3784 original Reconfigure message) from the client as satisfying the 3785 Reconfigure message request. 3787 If the server does not receive a Renew, Rebind, or Information- 3788 request message from the client in REC_TIMEOUT milliseconds, the 3789 server retransmits the Reconfigure message, doubles the REC_TIMEOUT 3790 value and waits again. The server continues this process until 3791 REC_MAX_RC unsuccessful attempts have been made, at which point the 3792 server SHOULD abort the reconfigure process for that client. 3794 Default and initial values for REC_TIMEOUT and REC_MAX_RC are 3795 documented in Section 7.6. 3797 18.4. Reception of Unicast Messages 3799 Unless otherwise stated in sections dedicated to specific messages 3800 reception (see dedicated sections in Section 18.3), the server is not 3801 supposed to accept unicast traffic when it is not explicitly 3802 configured to do so. For some messages (Solicit, Rebind, and 3803 Confirm) unicast transmission is not allowed, even if Server Unicast 3804 option is configured. For Request, Renew, Informaton-request, 3805 Release, and Decline messages, it is allowed only if Server Unicast 3806 option is configured. 3808 When the server receives a message via unicast from a client to which 3809 the server has not sent a Server Unicast option (or is not currently 3810 configured to send a Server Unicast option to the client), the server 3811 discards that message and responds with an Advertise (when responding 3812 to Solicit) or Reply (when responding to any other messages) message 3813 containing a Status Code option with value UseMulticast, a Server 3814 Identifier option containing the server's DUID, the Client Identifier 3815 option from the client message, and no other options. 3817 19. Relay Agent Behavior 3819 The relay agent SHOULD be configured to use a list of destination 3820 addresses, which include unicast addresses. The list of destination 3821 addresses MAY include the All_DHCP_Servers multicast address or other 3822 addresses selected by the network administrator. If the relay agent 3823 has not been explicitly configured, it MUST use the All_DHCP_Servers 3824 multicast address as the default. 3826 If the relay agent relays messages to the All_DHCP_Servers multicast 3827 address or other multicast addresses, it sets the Hop Limit field to 3828 32. 3830 If the relay agent receives a message other than Relay-forward and 3831 Relay-reply and the relay agent does not recognize its message type, 3832 it MUST forward them as described in Section 19.1.1. 3834 19.1. Relaying a Client Message or a Relay-forward Message 3836 A relay agent relays both messages from clients and Relay-forward 3837 messages from other relay agents. When a relay agent receives a 3838 valid message (for a definition of a valid message, see Section 4.1 3839 of [RFC7283]) to be relayed, it constructs a new Relay-forward 3840 message. The relay agent copies the source address from the header 3841 of the IP datagram in which the message was received into the peer- 3842 address field of the Relay-forward message. The relay agent copies 3843 the received DHCP message (excluding any IP or UDP headers) into a 3844 Relay Message option in the new message. The relay agent adds to the 3845 Relay-forward message any other options it is configured to include. 3847 [RFC6221] defines a Lightweight DHCPv6 Relay Agent (LDRA) that allows 3848 Relay Agent Information to be inserted by an access node that 3849 performs a link-layer bridging (i.e., non-routing) function. 3851 19.1.1. Relaying a Message from a Client 3853 If the relay agent received the message to be relayed from a client, 3854 the relay agent places a global or unique local [RFC4193] address 3855 with a prefix assigned to the link on which the client should be 3856 assigned leases into the link-address field. If such an address is 3857 not available, the relay agent may set the link-address field to a 3858 link-local address from the interface the original message was 3859 received on. That is not recommended as it may require additional 3860 information to be provided in the server configuration. See 3861 Section 3.2 of [RFC7969] for a detailed discussion. 3863 This address will be used by the server to determine the link from 3864 which the client should be assigned leases and other configuration 3865 information. The hop-count in the Relay-forward message is set to 0. 3867 If the relay agent cannot use the address in the link-address field 3868 to identify the interface through which the response to the client 3869 will be relayed, the relay agent MUST include an Interface-id option 3870 (see Section 21.18) in the Relay-forward message. The server will 3871 include the Interface-id option in its Relay-reply message. The 3872 relay agent sets the link-address field as described in the earlier 3873 paragraphs regardless of whether the relay agent includes an 3874 Interface-id option in the Relay-forward message. 3876 19.1.2. Relaying a Message from a Relay Agent 3878 If the message received by the relay agent is a Relay-forward message 3879 and the hop-count in the message is greater than or equal to 3880 HOP_COUNT_LIMIT, the relay agent discards the received message. 3882 The relay agent copies the source address from the IP datagram in 3883 which the message was received from the relay agent into the peer- 3884 address field in the Relay-forward message and sets the hop-count 3885 field to the value of the hop-count field in the received message 3886 incremented by 1. 3888 If the source address from the IP datagram header of the received 3889 message is a global or unique local address, the relay agent sets the 3890 link-address field to 0; otherwise the relay agent sets the link- 3891 address field to a global or unique local address assigned to the 3892 interface on which the message was received, or includes an 3893 Interface-ID option to identify the interface on which the message 3894 was received. 3896 19.1.3. Relay Agent Behavior with Prefix Delegation 3898 A relay agent forwards messages containing Prefix Delegation options 3899 in the same way as described earlier in this section. 3901 If a server communicates with a client through a relay agent about 3902 delegated prefixes, the server may need a protocol or other out-of- 3903 band communication to configure routing information for delegated 3904 prefixes on any router through which the client may forward traffic. 3906 19.2. Relaying a Relay-reply Message 3908 The relay agent processes any options included in the Relay-reply 3909 message in addition to the Relay Message option. 3911 The relay agent extracts the message from the Relay Message option 3912 and relays it to the address contained in the peer-address field of 3913 the Relay-reply message. Relay agents MUST NOT modify the message. 3915 If the Relay-reply message includes an Interface-id option, the relay 3916 agent relays the message from the server to the client on the link 3917 identified by the Interface-id option. Otherwise, if the link- 3918 address field is not set to zero, the relay agent relays the message 3919 on the link identified by the link-address field. 3921 If the relay agent receives a Relay-reply message, it MUST process 3922 the message as defined above, regardless of the type of message 3923 encapsulated in the Relay Message option. 3925 19.3. Construction of Relay-reply Messages 3927 A server uses a Relay-reply message to return a response to a client 3928 if the original message from the client was relayed to the server in 3929 a Relay-forward message or to send a Reconfigure message to a client 3930 if the server does not have an address it can use to send the message 3931 directly to the client. 3933 A response to the client MUST be relayed through the same relay 3934 agents as the original client message. The server causes this to 3935 happen by creating a Relay-reply message that includes a Relay 3936 Message option containing the message for the next relay agent in the 3937 return path to the client. The contained Relay-reply message 3938 contains another Relay Message option to be sent to the next relay 3939 agent, and so on. The server must record the contents of the peer- 3940 address fields in the received message so it can construct the 3941 appropriate Relay-reply message carrying the response from the 3942 server. 3944 For example, if client C sent a message that was relayed by relay 3945 agent A to relay agent B and then to the server, the server would 3946 send the following Relay-reply message to relay agent B: 3948 msg-type: RELAY-REPLY 3949 hop-count: 1 3950 link-address: 0 3951 peer-address: A 3952 Relay Message option, containing: 3953 msg-type: RELAY-REPLY 3954 hop-count: 0 3955 link-address: address from link to which C is attached 3956 peer-address: C 3957 Relay Message option: 3959 Figure 10: Relay-reply Example 3961 When sending a Reconfigure message to a client through a relay agent, 3962 the server creates a Relay-reply message that includes a Relay 3963 Message option containing the Reconfigure message for the next relay 3964 agent in the return path to the client. The server sets the peer- 3965 address field in the Relay-reply message header to the address of the 3966 client, and sets the link-address field as required by the relay 3967 agent to relay the Reconfigure message to the client. The server 3968 obtains the addresses of the client and the relay agent through prior 3969 interaction with the client or through some external mechanism. 3971 20. Authentication of DHCP Messages 3973 Within this document, two security mechanisms are introduced for the 3974 authentication of DHCP messages: authentication (and encryption) of 3975 messages sent between servers and relay agents using IPsec, and 3976 protection against misconfiguration of a client caused by a 3977 Reconfigure message sent by a malicious DHCP server. 3979 The delayed authentication protocol, defined in [RFC3315], has been 3980 obsoleted by this document (see Section 25). 3982 20.1. Security of Messages Sent Between Servers and Relay Agents 3984 Relay agents and servers that exchange messages can use IPsec as 3985 detailed in [I-D.ietf-dhc-relay-server-security]. 3987 20.2. Summary of DHCP Authentication 3989 Authentication of DHCP messages is accomplished through the use of 3990 the Authentication option (see Section 21.11). The authentication 3991 information carried in the Authentication option can be used to 3992 reliably identify the source of a DHCP message and to confirm that 3993 the contents of the DHCP message have not been tampered with. 3995 The Authentication option provides a framework for multiple 3996 authentication protocols. One such protocol, the Reconfigure key 3997 authentication protocol, is defined in Section 20.4. Other protocols 3998 defined in the future will be specified in separate documents. 4000 Any DHCP message MUST NOT include more than one Authentication 4001 option. 4003 The protocol field in the Authentication option identifies the 4004 specific protocol used to generate the authentication information 4005 carried in the option. The algorithm field identifies a specific 4006 algorithm within the authentication protocol; for example, the 4007 algorithm field specifies the hash algorithm used to generate the 4008 message authentication code (MAC) in the authentication option. The 4009 replay detection method (RDM) field specifies the type of replay 4010 detection used in the replay detection field. 4012 20.3. Replay Detection 4014 The Replay Detection Method (RDM) field determines the type of replay 4015 detection used in the Replay Detection field. 4017 If the RDM field contains 0x00, the replay detection field MUST be 4018 set to the value of a strictly monotonically increasing counter. 4019 Using a counter value, such as the current time of day (for example, 4020 an NTP-format timestamp [RFC5905]), can reduce the danger of replay 4021 attacks. This method MUST be supported by all protocols. 4023 20.4. Reconfigure Key Authentication Protocol 4025 The Reconfigure key authentication protocol provides protection 4026 against misconfiguration of a client caused by a Reconfigure message 4027 sent by a malicious DHCP server. In this protocol, a DHCP server 4028 sends a Reconfigure Key to the client in the initial exchange of DHCP 4029 messages. The client records the Reconfigure Key for use in 4030 authenticating subsequent Reconfigure messages from that server. The 4031 server then includes an HMAC computed from the Reconfigure Key in 4032 subsequent Reconfigure messages. 4034 Both the Reconfigure Key sent from the server to the client and the 4035 HMAC in subsequent Reconfigure messages are carried as the 4036 Authentication information in an Authentication option. The format 4037 of the Authentication information is defined in the following 4038 section. 4040 The Reconfigure Key protocol is used (initiated by the server) only 4041 if the client and server are not using any other authentication 4042 protocol and the client and server have negotiated to use Reconfigure 4043 messages. 4045 20.4.1. Use of the Authentication Option in the Reconfigure Key 4046 Authentication Protocol 4048 The following fields are set in an Authentication option for the 4049 Reconfigure Key Authentication Protocol: 4051 protocol 3 4053 algorithm 1 4055 RDM 0 4057 The format of the Authentication information for the Reconfigure Key 4058 Authentication Protocol is: 4060 0 1 2 3 4061 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 4062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4063 | Type | Value (128 bits) | 4064 +-+-+-+-+-+-+-+-+ | 4065 . . 4066 . . 4067 . +-+-+-+-+-+-+-+-+ 4068 | | 4069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4071 Figure 11: RKAP Authentication Information 4073 Type Type of data in Value field carried in this 4074 option: 4076 1 Reconfigure Key value (used in Reply 4077 message). 4079 2 HMAC-MD5 digest of the message (used in 4080 Reconfigure message). 4082 Value Data as defined by the Type field. 4084 20.4.2. Server Considerations for Reconfigure Key Authentication 4085 Protocol 4087 The server selects a Reconfigure Key for a client during the Request/ 4088 Reply, Solicit/Reply or Information-request/Reply message exchange. 4089 The server records the Reconfigure Key and transmits that key to the 4090 client in an Authentication option in the Reply message. 4092 The Reconfigure Key is 128 bits long, and MUST be a cryptographically 4093 strong random or pseudo-random number that cannot easily be 4094 predicted. 4096 To provide authentication for a Reconfigure message, the server 4097 selects a replay detection value according to the RDM selected by the 4098 server, and computes an HMAC-MD5 of the Reconfigure message using the 4099 Reconfigure Key for the client. The server computes the HMAC-MD5 4100 over the entire DHCP Reconfigure message, including the 4101 Authentication option; the HMAC-MD5 field in the Authentication 4102 option is set to zero for the HMAC-MD5 computation. The server 4103 includes the HMAC-MD5 in the authentication information field in an 4104 Authentication option included in the Reconfigure message sent to the 4105 client. 4107 20.4.3. Client Considerations for Reconfigure Key Authentication 4108 Protocol 4110 The client will receive a Reconfigure Key from the server in the 4111 initial Reply message from the server. The client records the 4112 Reconfigure Key for use in authenticating subsequent Reconfigure 4113 messages. 4115 To authenticate a Reconfigure message, the client computes an HMAC- 4116 MD5 over the DHCP Reconfigure message, using the Reconfigure Key 4117 received from the server. If this computed HMAC-MD5 matches the 4118 value in the Authentication option, the client accepts the 4119 Reconfigure message. 4121 21. DHCP Options 4123 Options are used to carry additional information and parameters in 4124 DHCP messages. Every option shares a common base format, as 4125 described in Section 21.1. All values in options are represented in 4126 network byte order. 4128 This document describes the DHCP options defined as part of the base 4129 DHCP specification. Other options may be defined in the future in 4130 separate documents. See [RFC7227] for guidelines regarding new 4131 options definition. See Section 24 for additional information about 4132 a registry maintained by IANA. 4134 Unless otherwise noted, each option may appear only in the options 4135 area of a DHCP message and may appear only once. If an option does 4136 appear multiple times, each instance is considered separate and the 4137 data areas of the options MUST NOT be concatenated or otherwise 4138 combined. 4140 Options that are allowed to appear only once are called singleton 4141 options. The only non-singleton options defined in this document are 4142 IA_NA (see Section 21.4), IA_TA (see Section 21.5), Vendor Class (see 4143 Section 21.16, Vendor-specific Information (see Section 21.17), and 4144 IA_PD (see Section 21.21) options. Also, IA Address (see 4145 Section 21.6) and IA Prefix (see Section 21.22) may appear in their 4146 respective IA options more than once. 4148 21.1. Format of DHCP Options 4150 The format of DHCP options is: 4152 0 1 2 3 4153 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 4154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4155 | option-code | option-len | 4156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4157 | option-data | 4158 | (option-len octets) | 4159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4161 Figure 12: Option Format 4163 option-code An unsigned integer identifying the specific 4164 option type carried in this option. 4166 option-len An unsigned integer giving the length of the 4167 option-data field in this option in octets. 4169 option-data The data for the option; the format of this 4170 data depends on the definition of the option. 4172 DHCP options are scoped by using encapsulation. Some options apply 4173 generally to the client, some are specific to an IA, and some are 4174 specific to the addresses within an IA. These latter two cases are 4175 discussed in Section 21.4 and Section 21.6. 4177 21.2. Client Identifier Option 4179 The Client Identifier option is used to carry a DUID (see Section 11) 4180 identifying a client between a client and a server. The format of 4181 the Client Identifier option is: 4183 0 1 2 3 4184 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 4185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4186 | OPTION_CLIENTID | option-len | 4187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4188 . . 4189 . DUID . 4190 . (variable length) . 4191 . . 4192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4194 Figure 13: Client Identifier Option Format 4196 option-code OPTION_CLIENTID (1). 4198 option-len Length of DUID in octets. 4200 DUID The DUID for the client. 4202 21.3. Server Identifier Option 4204 The Server Identifier option is used to carry a DUID (see Section 11) 4205 identifying a server between a client and a server. The format of 4206 the Server Identifier option is: 4208 0 1 2 3 4209 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 4210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4211 | OPTION_SERVERID | option-len | 4212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4213 . . 4214 . DUID . 4215 . (variable length) . 4216 . . 4217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4219 Figure 14: Server Identifier Option Format 4221 option-code OPTION_SERVERID (2). 4223 option-len Length of DUID in octets. 4225 DUID The DUID for the server. 4227 21.4. Identity Association for Non-temporary Addresses Option 4229 The Identity Association for Non-temporary Addresses option (IA_NA 4230 option) is used to carry an IA_NA, the parameters associated with the 4231 IA_NA, and the non-temporary addresses associated with the IA_NA. 4233 Addresses appearing in an IA_NA option are not temporary addresses 4234 (see Section 21.5). 4236 The format of the IA_NA option is: 4238 0 1 2 3 4239 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 4240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4241 | OPTION_IA_NA | option-len | 4242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4243 | IAID (4 octets) | 4244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4245 | T1 | 4246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4247 | T2 | 4248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4249 | | 4250 . IA_NA-options . 4251 . . 4252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4254 Figure 15: Identity Association for Non-temporary Addresses Option 4255 Format 4257 option-code OPTION_IA_NA (3). 4259 option-len 12 + length of IA_NA-options field. 4261 IAID The unique identifier for this IA_NA; the 4262 IAID must be unique among the identifiers for 4263 all of this client's IA_NAs. The number 4264 space for IA_NA IAIDs is separate from the 4265 number space for other IA option types (i.e., 4266 IA_TA and IA_PD). 4268 T1 The time at which the client should contact 4269 the server from which the addresses in the 4270 IA_NA were obtained to extend the lifetimes 4271 of the addresses assigned to the IA_NA; T1 is 4272 a time duration relative to the current time 4273 expressed in units of seconds. 4275 T2 The time at which the client should contact 4276 any available server to extend the lifetimes 4277 of the addresses assigned to the IA_NA; T2 is 4278 a time duration relative to the current time 4279 expressed in units of seconds. 4281 IA_NA-options Options associated with this IA_NA. 4283 The IA_NA-options field encapsulates those options that are specific 4284 to this IA_NA. For example, all of the IA Address options carrying 4285 the addresses associated with this IA_NA are in the IA_NA-options 4286 field. 4288 Each IA_NA carries one "set" of non-temporary addresses; "it is up to 4289 the server policy to determine how many addresses are assigned, but 4290 typically at most one address from each prefix assigned to the link 4291 the client is attached to. 4293 An IA_NA option may only appear in the options area of a DHCP 4294 message. A DHCP message may contain multiple IA_NA options. 4296 The status of any operations involving this IA_NA is indicated in a 4297 Status Code option in the IA_NA-options field. 4299 Note that an IA_NA has no explicit "lifetime" or "lease length" of 4300 its own. When the valid lifetimes of all of the addresses in an 4301 IA_NA have expired, the IA_NA can be considered as having expired. 4302 T1 and T2 are included to give servers explicit control over when a 4303 client recontacts the server about a specific IA_NA. 4305 In a message sent by a client to a server, the T1 and T2 fields 4306 SHOULD be set to 0. The server MUST ignore any values in these 4307 fields in messages received from a client. 4309 In a message sent by a server to a client, the client MUST use the 4310 values in the T1 and T2 fields for the T1 and T2 parameters, unless 4311 those values in those fields are 0. The values in the T1 and T2 4312 fields are the number of seconds until T1 and T2. 4314 The server selects the T1 and T2 times to allow the client to extend 4315 the lifetimes of any addresses in the IA_NA before the lifetimes 4316 expire, even if the server is unavailable for some short period of 4317 time. Recommended values for T1 and T2 are .5 and .8 times the 4318 shortest preferred lifetime of the addresses in the IA that the 4319 server is willing to extend, respectively. If the "shortest" 4320 preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and 4321 T2 values are also 0xffffffff. If the time at which the addresses in 4322 an IA_NA are to be renewed is to be left to the discretion of the 4323 client, the server sets T1 and T2 to 0. The client MUST follow the 4324 rules defined in Section 14.2. 4326 If a client receives an IA_NA with T1 greater than T2, and both T1 4327 and T2 are greater than 0, the client discards the IA_NA option and 4328 processes the remainder of the message as though the server had not 4329 included the invalid IA_NA option. 4331 As per Section 7.7, the value 0xffffffff is taken to ("infinity") and 4332 should be used carefully. 4334 21.5. Identity Association for Temporary Addresses Option 4336 The Identity Association for the Temporary Addresses (IA_TA) option 4337 is used to carry an IA_TA, the parameters associated with the IA_TA 4338 and the addresses associated with the IA_TA. All of the addresses in 4339 this option are used by the client as temporary addresses, as defined 4340 in [RFC4941]. The format of the IA_TA option is: 4342 0 1 2 3 4343 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 4344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4345 | OPTION_IA_TA | option-len | 4346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4347 | IAID (4 octets) | 4348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4349 | | 4350 . IA_TA-options . 4351 . . 4352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4354 Figure 16: Identity Association for Temporary Addresses Option Format 4356 option-code OPTION_IA_TA (4). 4358 option-len 4 + length of IA_TA-options field. 4360 IAID The unique identifier for this IA_TA; the 4361 IAID must be unique among the identifiers for 4362 all of this client's IA_TAs. The number 4363 space for IA_TA IAIDs is separate from the 4364 number space for other IA option types (i.e., 4365 IA_NA and IA_PD). 4367 IA_TA-options Options associated with this IA_TA. 4369 The IA_TA-Options field encapsulates those options that are specific 4370 to this IA_TA. For example, all of the IA Address options carrying 4371 the addresses associated with this IA_TA are in the IA_TA-options 4372 field. 4374 Each IA_TA carries one "set" of temporary addresses. It is up to the 4375 server policy to determine how many addresses are assigned. 4377 An IA_TA option may only appear in the options area of a DHCP 4378 message. A DHCP message may contain multiple IA_TA options. 4380 The status of any operations involving this IA_TA is indicated in a 4381 Status Code option in the IA_TA-options field. 4383 Note that an IA has no explicit "lifetime" or "lease length" of its 4384 own. When the valid lifetimes of all of the addresses in an IA_TA 4385 have expired, the IA can be considered as having expired. 4387 An IA_TA option does not include values for T1 and T2. A client MAY 4388 request that valid lifetime on temporary addresses be extended by 4389 including the addresses in a IA_TA option sent in a Renew or Rebind 4390 message to a server. For example, a client would request an 4391 extension on the valid lifetime of a temporary address to allow an 4392 application to continue to use an established TCP connection. 4393 Extending only valid, but not preferred lifetime means the address 4394 will end up in deprecated state eventually. Existing connections 4395 could continue, but no new ones would be created using that address. 4397 The client obtains new temporary addresses by sending an IA_TA option 4398 with a new IAID to a server. Requesting new temporary addresses from 4399 the server is the equivalent of generating new temporary addresses as 4400 described in [RFC4941]. The server will generate new temporary 4401 addresses and return them to the client. The client should request 4402 new temporary addresses before the lifetimes on the previously 4403 assigned addresses expire. 4405 A server MUST return the same set of temporary address for the same 4406 IA_TA (as identified by the IAID) as long as those addresses are 4407 still valid. After the lifetimes of the addresses in an IA_TA have 4408 expired, the IAID may be reused to identify a new IA_TA with new 4409 temporary addresses. 4411 21.6. IA Address Option 4413 The IA Address option is used to specify an address associated with 4414 an IA_NA or an IA_TA. The IA Address option must be encapsulated in 4415 the Options field of an IA_NA or IA_TA option. The Options fields of 4416 the IA_NA or IA_TA option encapsulates those options that are 4417 specific to this address. 4419 The format of the IA Address option is: 4421 0 1 2 3 4422 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 4423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4424 | OPTION_IAADDR | option-len | 4425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4426 | | 4427 | IPv6-address | 4428 | | 4429 | | 4430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4431 | preferred-lifetime | 4432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4433 | valid-lifetime | 4434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4435 . . 4436 . IAaddr-options . 4437 . . 4438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4440 Figure 17: IA Address Option Format 4442 option-code OPTION_IAADDR (5). 4444 option-len 24 + length of IAaddr-options field. 4446 IPv6-address An IPv6 address. A client MUST NOT form an 4447 implicit prefix with a length other than 128 4448 for this address. And, a client MUST NOT 4449 assume any length of prefix that matches this 4450 address is on-link (see [RFC7421]). 4452 preferred-lifetime The preferred lifetime for the address in the 4453 option, expressed in units of seconds. 4455 valid-lifetime The valid lifetime for the address in the 4456 option, expressed in units of seconds. 4458 IAaddr-options Options associated with this address. 4460 In a message sent by a client to a server, the preferred and valid 4461 lifetime fields SHOULD be set to 0. The server MUST ignore any 4462 received values. 4464 The client SHOULD NOT send the IA Address option with unspecified 4465 address (::). 4467 In a message sent by a server to a client, the client MUST use the 4468 values in the preferred and valid lifetime fields for the preferred 4469 and valid lifetimes. The values in the preferred and valid lifetimes 4470 are the number of seconds remaining in each lifetime. 4472 A client discards any addresses for which the preferred lifetime is 4473 greater than the valid lifetime. 4475 As per Section 7.7, the valid lifetime of an address 0xffffffff is 4476 taken to mean "infinity" and should be used carefully. 4478 More than one IA Address option can appear in an IA_NA option or an 4479 IA_TA option. 4481 The status of any operations involving this IA Address is indicated 4482 in a Status Code option in the IAaddr-options field, as specified in 4483 Section 21.13. 4485 21.7. Option Request Option 4487 The Option Request option is used to identify a list of options in a 4488 message between a client and a server. The format of the Option 4489 Request option is: 4491 0 1 2 3 4492 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 4493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4494 | OPTION_ORO | option-len | 4495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4496 | requested-option-code-1 | requested-option-code-2 | 4497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4498 | ... | 4499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4501 Figure 18: Option Request Option Format 4503 option-code OPTION_ORO (6). 4505 option-len 2 * number of requested options. 4507 requested-option-code-n The option code for an option requested 4508 by the client. 4510 A client MUST include an Option Request option in a Solicit, Request, 4511 Renew, Rebind, or Information-request message to inform the server 4512 about options the client wants the server to send to the client. 4514 The Option Request option MUST NOT include the following options: 4515 Server Identifier, Client Identifier, IA_NA, IA_PD, IA_TA, IA 4516 Address, IA Prefix, Option Request, Elapsed Time, Preference, Relay 4517 Message, Authentication, Server Unicast, Rapid Commit, User Class, 4518 Vendor Class, Interface-Id, Reconfigure Message, and Reconfigure 4519 Accept. Other top-level options MUST appear in the Option Request 4520 option or they will not be sent by the server. Only container 4521 options MUST appear in the Option Request, options encapsulated in 4522 the container MUST NOT be in the Option Request, see [RFC7598] as an 4523 example of container options. The exception to this is the Option 4524 Request option MAY be used to signal support for a feature even when 4525 that option is encapsulated as in the case of the Prefix Exclude 4526 option [RFC6603]. See Table 1. 4528 21.8. Preference Option 4530 The Preference option is sent by a server to a client to affect the 4531 selection of a server by the client. 4533 The format of the Preference option is: 4535 0 1 2 3 4536 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 4537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4538 | OPTION_PREFERENCE | option-len | 4539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4540 | pref-value | 4541 +-+-+-+-+-+-+-+-+ 4543 Figure 19: Preference Option Format 4545 option-code OPTION_PREFERENCE (7). 4547 option-len 1. 4549 pref-value The preference value for the server in this 4550 message. 4552 A server MAY include a Preference option in an Advertise message to 4553 control the selection of a server by the client. See Section 18.2.9 4554 for the use of the Preference option by the client and the 4555 interpretation of Preference option data value. 4557 21.9. Elapsed Time Option 4559 0 1 2 3 4560 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 4561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4562 | OPTION_ELAPSED_TIME | option-len | 4563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4564 | elapsed-time | 4565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4567 Figure 20: Elapsed Time Option Format 4569 option-code OPTION_ELAPSED_TIME (8). 4571 option-len 2. 4573 elapsed-time The amount of time since the client began its 4574 current DHCP transaction. This time is 4575 expressed in hundredths of a second (10^-2 4576 seconds). 4578 A client MUST include an Elapsed Time option in messages to indicate 4579 how long the client has been trying to complete a DHCP message 4580 exchange. The elapsed time is measured from the time at which the 4581 client sent the first message in the message exchange, and the 4582 elapsed-time field is set to 0 in the first message in the message 4583 exchange. Servers and Relay Agents use the data value in this option 4584 as input to policy controlling how a server responds to a client 4585 message. For example, the elapsed time option allows a secondary 4586 DHCP server to respond to a request when a primary server has not 4587 answered in a reasonable time. The elapsed time value is an 4588 unsigned, 16 bit integer. The client uses the value 0xffff to 4589 represent any elapsed time values greater than the largest time value 4590 that can be represented in the Elapsed Time option. 4592 21.10. Relay Message Option 4594 The Relay Message option carries a DHCP message in a Relay-forward or 4595 Relay-reply message. 4597 The format of the Relay Message option is: 4599 0 1 2 3 4600 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 4601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4602 | OPTION_RELAY_MSG | option-len | 4603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4604 | | 4605 . DHCP-relay-message . 4606 . . 4607 . . 4608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4610 Figure 21: Relay Message Option Format 4612 option-code OPTION_RELAY_MSG (9) 4614 option-len Length of DHCP-relay-message 4616 DHCP-relay-message In a Relay-forward message, the received 4617 message, relayed verbatim to the next relay 4618 agent or server; in a Relay-reply message, 4619 the message to be copied and relayed to the 4620 relay agent or client whose address is in the 4621 peer-address field of the Relay-reply message 4623 21.11. Authentication Option 4625 The Authentication option carries authentication information to 4626 authenticate the identity and contents of DHCP messages. The use of 4627 the Authentication option is described in Section 20. The delayed 4628 authentication protocol, defined in [RFC3315], has been obsoleted by 4629 this document, due to lack of usage. The format of the 4630 Authentication option is: 4632 0 1 2 3 4633 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 4634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4635 | OPTION_AUTH | option-len | 4636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4637 | protocol | algorithm | RDM | | 4638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4639 | | 4640 | replay detection (64 bits) +-+-+-+-+-+-+-+-+ 4641 | | auth-info | 4642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4643 . authentication information . 4644 . (variable length) . 4645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4647 Figure 22: Authentication Option Format 4649 option-code OPTION_AUTH (11). 4651 option-len 11 + length of authentication information 4652 field. 4654 protocol The authentication protocol used in this 4655 authentication option. 4657 algorithm The algorithm used in the authentication 4658 protocol. 4660 RDM The replay detection method used in this 4661 authentication option. 4663 Replay detection The replay detection information for the RDM. 4665 authentication information The authentication information, as 4666 specified by the protocol and algorithm used 4667 in this authentication option. 4669 21.12. Server Unicast Option 4671 The server sends this option to a client to indicate to the client 4672 that it is allowed to unicast messages to the server. The format of 4673 the Server Unicast option is: 4675 0 1 2 3 4676 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 4677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4678 | OPTION_UNICAST | option-len | 4679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4680 | | 4681 | server-address | 4682 | | 4683 | | 4684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4686 Figure 23: Server Unicast Option Format 4688 option-code OPTION_UNICAST (12). 4690 option-len 16. 4692 server-address The address to which the client should send 4693 messages delivered using unicast. 4695 The server specifies the address to which the client is to send 4696 unicast messages in the server-address field. When a client receives 4697 this option, where permissible and appropriate, the client sends 4698 messages directly to the server using the address specified in the 4699 server-address field of the option. 4701 When the server sends a Unicast option to the client, some messages 4702 from the client will not be relayed by Relay Agents, and will not 4703 include Relay Agent options from the Relay Agents. Therefore, a 4704 server should only send a Unicast option to a client when Relay 4705 Agents are not sending Relay Agent options. A DHCP server rejects 4706 any messages sent inappropriately using unicast to ensure that 4707 messages are relayed by Relay Agents when Relay Agent options are in 4708 use. 4710 Details about when the client may send messages to the server using 4711 unicast are in Section 18. 4713 21.13. Status Code Option 4715 This option returns a status indication related to the DHCP message 4716 or option in which it appears. The format of the Status Code option 4717 is: 4719 0 1 2 3 4720 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 4721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4722 | OPTION_STATUS_CODE | option-len | 4723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4724 | status-code | | 4725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4726 . . 4727 . status-message . 4728 . . 4729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4731 Figure 24: Status Code Option Format 4733 option-code OPTION_STATUS_CODE (13). 4735 option-len 2 + length of status-message. 4737 status-code The numeric code for the status encoded in 4738 this option. 4740 status-message A UTF-8 encoded text string suitable for 4741 display to an end user, which MUST NOT be 4742 null-terminated. 4744 A Status Code option may appear in the options field of a DHCP 4745 message and/or in the options field of another option. If the Status 4746 Code option does not appear in a message in which the option could 4747 appear, the status of the message is assumed to be Success. 4749 The status-code values previously defined by [RFC3315] and [RFC3633] 4750 are: 4752 +---------------+------+--------------------------------------------+ 4753 | Name | Code | Description | 4754 +---------------+------+--------------------------------------------+ 4755 | Success | 0 | Success. | 4756 | UnspecFail | 1 | Failure, reason unspecified; this status | 4757 | | | code is sent by either a client or a | 4758 | | | server to indicate a failure not | 4759 | | | explicitly specified in this document. | 4760 | NoAddrsAvail | 2 | Server has no addresses available to | 4761 | | | assign to the IA(s). | 4762 | NoBinding | 3 | Client record (binding) unavailable. | 4763 | NotOnLink | 4 | The prefix for the address is not | 4764 | | | appropriate for the link to which the | 4765 | | | client is attached. | 4766 | UseMulticast | 5 | Sent by a server to a client to force the | 4767 | | | client to send messages to the server | 4768 | | | using the | 4769 | | | All_DHCP_Relay_Agents_and_Servers | 4770 | | | multicast address. | 4771 | NoPrefixAvail | 6 | Server has no prefixes available to assign | 4772 | | | to the IA_PD(s). | 4773 +---------------+------+--------------------------------------------+ 4775 See Section 24 for additional information about the registry 4776 maintained by IANA with the complete list of status codes. 4778 21.14. Rapid Commit Option 4780 The Rapid Commit option is used to signal the use of the two message 4781 exchange for address assignment. The format of the Rapid Commit 4782 option is: 4784 0 1 2 3 4785 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 4786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4787 | OPTION_RAPID_COMMIT | 0 | 4788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4790 Figure 25: Rapid Commit Option Format 4792 option-code OPTION_RAPID_COMMIT (14). 4794 option-len 0. 4796 A client MAY include this option in a Solicit message if the client 4797 is prepared to perform the Solicit/Reply message exchange described 4798 in Section 18.2.1. 4800 A server MUST include this option in a Reply message sent in response 4801 to a Solicit message when completing the Solicit/Reply message 4802 exchange. 4804 DISCUSSION: 4806 Each server that responds with a Reply to a Solicit that includes 4807 a Rapid Commit option will commit the leases in the Reply message 4808 to the client, and will not receive any confirmation that the 4809 client has received the Reply message. Therefore, if more than 4810 one server responds to a Solicit that includes a Rapid Commit 4811 option, some servers will commit leases that are not actually used 4812 by the client, which could result in bad information in the DNS 4813 server if the DHCP server updates DNS ([RFC4704]) or in response 4814 to leasequery requests ([RFC5007]). 4816 The problem of unused leases can be minimized, for example, by 4817 designing the DHCP service so that only one server responds to the 4818 Solicit or by using relatively short lifetimes for newly assigned 4819 leases, or the DHCP client initiatively releases unused leases by 4820 using the Release message. 4822 21.15. User Class Option 4824 The User Class option is used by a client to identify the type or 4825 category of user or applications it represents. 4827 The format of the User Class option is: 4829 0 1 2 3 4830 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 4831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4832 | OPTION_USER_CLASS | option-len | 4833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4834 . . 4835 . user-class-data . 4836 . . 4837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4839 Figure 26: User Class Option Format 4841 option-code OPTION_USER_CLASS (15). 4843 option-len Length of user class data field. 4845 user-class-data The user classes carried by the client. 4847 The information contained in the data area of this option is 4848 contained in one or more opaque fields that represent the user class 4849 or classes of which the client is a member. A server selects 4850 configuration information for the client based on the classes 4851 identified in this option. For example, the User Class option can be 4852 used to configure all clients of people in the accounting department 4853 with a different printer than clients of people in the marketing 4854 department. The user class information carried in this option MUST 4855 be configurable on the client. 4857 The data area of the user class option MUST contain one or more 4858 instances of user class data. Each instance of the user class data 4859 is formatted as follows: 4861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4862 | user-class-len | opaque-data | 4863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4865 Figure 27: User Class Data Format 4867 The user-class-len is two octets long and specifies the length of the 4868 opaque user class data in network byte order. 4870 A server interprets the classes identified in this option according 4871 to its configuration to select the appropriate configuration 4872 information for the client. A server may use only those user classes 4873 that it is configured to interpret in selecting configuration 4874 information for a client and ignore any other user classes. In 4875 response to a message containing a User Class option, a server 4876 includes a User Class option containing those classes that were 4877 successfully interpreted by the server, so that the client can be 4878 informed of the classes interpreted by the server. 4880 21.16. Vendor Class Option 4882 This option is used by a client to identify the vendor that 4883 manufactured the hardware on which the client is running. The 4884 information contained in the data area of this option is contained in 4885 one or more opaque fields that identify details of the hardware 4886 configuration. The format of the Vendor Class option is: 4888 0 1 2 3 4889 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 4890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4891 | OPTION_VENDOR_CLASS | option-len | 4892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4893 | enterprise-number | 4894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4895 . . 4896 . vendor-class-data . 4897 . . . . . 4898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4900 Figure 28: Vendor Class Option Format 4902 option-code OPTION_VENDOR_CLASS (16). 4904 option-len 4 + length of vendor class data field. 4906 enterprise-number The vendor's registered Enterprise Number as 4907 registered with IANA [IANA-PEN]. 4909 vendor-class-data The hardware configuration of the node on 4910 which the client is running. 4912 The vendor-class-data is composed of a series of separate items, each 4913 of which describes some characteristic of the client's hardware 4914 configuration. Examples of vendor-class-data instances might include 4915 the version of the operating system the client is running or the 4916 amount of memory installed on the client. 4918 Each instance of the vendor-class-data is formatted as follows: 4920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4921 | vendor-class-len | opaque-data | 4922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4924 Figure 29: Vendor Class Data Format 4926 The vendor-class-len is two octets long and specifies the length of 4927 the opaque vendor class data in network byte order. 4929 Servers and clients MUST NOT include more than one instance of 4930 OPTION_VENDOR_CLASS with the same Enterprise Number. Each instance 4931 of OPTION_VENDOR_CLASS can carry multiple sub-options. 4933 21.17. Vendor-specific Information Option 4935 This option is used by clients and servers to exchange vendor- 4936 specific information. 4938 The format of the Vendor-specific Information option is: 4940 0 1 2 3 4941 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 4942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4943 | OPTION_VENDOR_OPTS | option-len | 4944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4945 | enterprise-number | 4946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4947 . . 4948 . option-data . 4949 . . 4950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4952 Figure 30: Vendor-specific Information Option Format 4954 option-code OPTION_VENDOR_OPTS (17). 4956 option-len 4 + length of option-data field. 4958 enterprise-number The vendor's registered Enterprise Number as 4959 registered with IANA [IANA-PEN]. 4961 option-data An opaque object, interpreted by vendor- 4962 specific code on the clients and servers. 4964 The definition of the information carried in this option is vendor 4965 specific. The vendor is indicated in the enterprise-number field. 4966 Use of vendor-specific information allows enhanced operation, 4967 utilizing additional features in a vendor's DHCP implementation. A 4968 DHCP client that does not receive requested vendor-specific 4969 information will still configure the node device's IPv6 stack to be 4970 functional. 4972 The encapsulated vendor-specific options field MUST be encoded as a 4973 sequence of code/length/value fields of identical format to the DHCP 4974 options field. The option codes are defined by the vendor identified 4975 in the enterprise-number field and are not managed by IANA. Each of 4976 the encapsulated options is formatted as follows: 4978 0 1 2 3 4979 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 4980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4981 | opt-code | option-len | 4982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4983 . . 4984 . option-data . 4985 . . 4986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4988 Figure 31: Vendor-specific Options Format 4990 opt-code The code for the encapsulated option. 4992 option-len An unsigned integer giving the length of the 4993 option-data field in this encapsulated option 4994 in octets. 4996 option-data The data area for the encapsulated option. 4998 Multiple instances of the Vendor-specific Information option may 4999 appear in a DHCP message. Each instance of the option is interpreted 5000 according to the option codes defined by the vendor identified by the 5001 Enterprise Number in that option. Servers and clients MUST NOT send 5002 more than one instance of Vendor-specific Information option with the 5003 same Enterprise Number. Each instance of Vendor-specific Information 5004 option MAY contain multiple encapsulated options. 5006 A client that is interested in receiving a Vendor-specific 5007 Information option: 5009 - MUST specify the Vendor-specific Information option in an Option 5010 Request option. 5012 - MAY specify an associated Vendor Class option. 5014 - MAY specify the Vendor-specific Information option with 5015 appropriate data. 5017 Servers only return the Vendor-specific Information options if 5018 specified in Option Request options from clients and: 5020 - MAY use the Enterprise Numbers in the associated Vendor Class 5021 options to restrict the set of Enterprise Numbers in the Vendor- 5022 specific Information options returned. 5024 - MAY return all configured Vendor-specific Information options. 5026 - MAY use other information in the packet or in its configuration to 5027 determine which set of Enterprise Numbers in the Vendor-specific 5028 Information options to return. 5030 21.18. Interface-Id Option 5032 The relay agent MAY send the Interface-id option to identify the 5033 interface on which the client message was received. If a relay agent 5034 receives a Relay-reply message with an Interface-id option, the relay 5035 agent relays the message to the client through the interface 5036 identified by the option. 5038 The format of the Interface ID option is: 5040 0 1 2 3 5041 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 5042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5043 | OPTION_INTERFACE_ID | option-len | 5044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5045 . . 5046 . interface-id . 5047 . . 5048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5050 Figure 32: Interface-ID Option Format 5052 option-code OPTION_INTERFACE_ID (18). 5054 option-len Length of interface-id field. 5056 interface-id An opaque value of arbitrary length generated 5057 by the relay agent to identify one of the 5058 relay agent's interfaces. 5060 The server MUST copy the Interface-Id option from the Relay-forward 5061 message into the Relay-reply message the server sends to the relay 5062 agent in response to the Relay-forward message. This option MUST NOT 5063 appear in any message except a Relay-forward or Relay-reply message. 5065 Servers MAY use the Interface-ID for parameter assignment policies. 5066 The Interface-ID SHOULD be considered an opaque value, with policies 5067 based on exact match only; that is, the Interface-ID SHOULD NOT be 5068 internally parsed by the server. The Interface-ID value for an 5069 interface SHOULD be stable and remain unchanged, for example, after 5070 the relay agent is restarted; if the Interface-ID changes, a server 5071 will not be able to use it reliably in parameter assignment policies. 5073 21.19. Reconfigure Message Option 5075 A server includes a Reconfigure Message option in a Reconfigure 5076 message to indicate to the client whether the client responds with a 5077 Renew message, a Rebind message, or an Information-request message. 5078 The format of this option is: 5080 0 1 2 3 5081 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 5082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5083 | OPTION_RECONF_MSG | option-len | 5084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5085 | msg-type | 5086 +-+-+-+-+-+-+-+-+ 5088 Figure 33: Reconfigure Message Option Format 5090 option-code OPTION_RECONF_MSG (19). 5092 option-len 1. 5094 msg-type 5 for Renew message, 6 for Rebind, 11 for 5095 Information-request message. 5097 The Reconfigure Message option can only appear in a Reconfigure 5098 message. 5100 21.20. Reconfigure Accept Option 5102 A client uses the Reconfigure Accept option to announce to the server 5103 whether the client is willing to accept Reconfigure messages, and a 5104 server uses this option to tell the client whether or not to accept 5105 Reconfigure messages. The default behavior, in the absence of this 5106 option, means unwillingness to accept Reconfigure messages, or 5107 instruction not to accept Reconfigure messages, for the client and 5108 server messages, respectively. The following figure gives the format 5109 of the Reconfigure Accept option: 5111 0 1 2 3 5112 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 5113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5114 | OPTION_RECONF_ACCEPT | 0 | 5115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5117 Figure 34: Reconfigure Accept Option Format 5119 option-code OPTION_RECONF_ACCEPT (20). 5121 option-len 0. 5123 21.21. Identity Association for Prefix Delegation Option 5125 The IA_PD option is used to carry a prefix delegation identity 5126 association, the parameters associated with the IA_PD and the 5127 prefixes associated with it. 5129 0 1 2 3 5130 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 5131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5132 | OPTION_IA_PD | option-length | 5133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5134 | IAID (4 octets) | 5135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5136 | T1 | 5137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5138 | T2 | 5139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5140 . . 5141 . IA_PD-options . 5142 . . 5143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5145 Figure 35: Identity Association for Prefix Delegation Option Format 5147 option-code OPTION_IA_PD (25). 5149 option-length 12 + length of IA_PD-options field. 5151 IAID The unique identifier for this IA_PD; the 5152 IAID must be unique among the identifiers for 5153 all of this client's IA_PDs. The number 5154 space for IA_PD IAIDs is separate from the 5155 number space for other IA option types (i.e., 5156 IA_NA and IA_TA). 5158 T1 The time at which the client should contact 5159 the server from which the prefixes in the 5160 IA_PD were obtained to extend the lifetimes 5161 of the prefixes delegated to the IA_PD; T1 is 5162 a time duration relative to the current time 5163 expressed in units of seconds. 5165 T2 The time at which the client should contact 5166 any available server to extend the lifetimes 5167 of the prefixes assigned to the IA_PD; T2 is 5168 a time duration relative to the current time 5169 expressed in units of seconds. 5171 IA_PD-options Options associated with this IA_PD. 5173 The IA_PD-options field encapsulates those options that are specific 5174 to this IA_PD. For example, all of the IA Prefix options carrying 5175 the prefixes associated with this IA_PD are in the IA_PD-options 5176 field. 5178 An IA_PD option may only appear in the options area of a DHCP 5179 message. A DHCP message may contain multiple IA_PD options. 5181 The status of any operations involving this IA_PD is indicated in a 5182 Status Code option in the IA_PD-options field. 5184 Note that an IA_PD has no explicit "lifetime" or "lease length" of 5185 its own. When the valid lifetimes of all of the prefixes in a IA_PD 5186 have expired, the IA_PD can be considered as having expired. T1 and 5187 T2 are included to give the server explicit control over when a 5188 client should contact the server about a specific IA_PD. 5190 In a message sent by a client to a server, the T1 and T2 fields 5191 SHOULD be set to 0. The server MUST ignore any values in these 5192 fields in messages received from a client. 5194 In a message sent by a server to a client, the server MUST use the 5195 values in the T1 and T2 fields for the T1 and T2 parameters, unless 5196 those values in those fields are 0. The values in the T1 and T2 5197 fields are the number of seconds until T1 and T2. 5199 The server selects the T1 and T2 times to allow the client to extend 5200 the lifetimes of any prefixes in the IA_PD before the lifetimes 5201 expire, even if the server is unavailable for some short period of 5202 time. Recommended values for T1 and T2 are .5 and .8 times the 5203 shortest preferred lifetime of the prefixes in the IA_PD that the 5204 server is willing to extend, respectively. If the time at which the 5205 prefixes in an IA_PD are to be renewed is to be left to the 5206 discretion of the client, the server sets T1 and T2 to 0. The client 5207 MUST follow the rules defined in Section 14.2. 5209 If a client receives an IA_PD with T1 greater than T2, and both T1 5210 and T2 are greater than 0, the client discards the IA_PD option and 5211 processes the remainder of the message as though the client had not 5212 included the IA_PD option. 5214 21.22. IA Prefix Option 5216 The IA Prefix option is used to specify a prefix associated with an 5217 IA_PD. The IA Prefix option must be encapsulated in the IA_PD- 5218 options field of an IA_PD option. 5220 0 1 2 3 5221 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 5222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5223 | OPTION_IAPREFIX | option-length | 5224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5225 | preferred-lifetime | 5226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5227 | valid-lifetime | 5228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5229 | prefix-length | | 5230 +-+-+-+-+-+-+-+-+ IPv6-prefix | 5231 | (16 octets) | 5232 | | 5233 | | 5234 | | 5235 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5236 | | . 5237 +-+-+-+-+-+-+-+-+ . 5238 . IAprefix-options . 5239 . . 5240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5242 Figure 36: IA Prefix Option Format 5244 option-code OPTION_IAPREFIX (26). 5246 option-length 25 + length of IAprefix-options field. 5248 preferred-lifetime The recommended preferred lifetime for the 5249 prefix in the option, expressed in units of 5250 seconds. A value of 0xFFFFFFFF represents 5251 infinity. 5253 valid-lifetime The valid lifetime for the prefix in the 5254 option, expressed in units of seconds. A 5255 value of 0xFFFFFFFF represents infinity. 5257 prefix-length Length for this prefix in bits. 5259 IPv6-prefix An IPv6 prefix. 5261 IAprefix-options Options associated with this prefix. 5263 In a message sent by a client to a server, the preferred and valid 5264 lifetime fields SHOULD be set to 0. The server MUST ignore any 5265 received values in these lifetime fields. 5267 A client may set the IPv6-prefix field to zero and a given value in 5268 the prefix-length field to indicate a preference for the size of the 5269 prefix to be delegated. 5271 A client discards any prefixes for which the preferred lifetime is 5272 greater than the valid lifetime. 5274 The values in the preferred and valid lifetimes are the number of 5275 seconds remaining for each lifetime. 5277 As per Section 7.7, the preferred and valid lifetime values of 5278 0xffffffff is taken to mean "infinity" and should be used carefully. 5280 An IA Prefix option may appear only in an IA_PD option. More than 5281 one IA Prefix option can appear in a single IA_PD option. 5283 The status of any operations involving this IA Prefix option is 5284 indicated in a Status Code option in the IAprefix-options field. 5286 21.23. Information Refresh Time Option 5288 This option is requested by clients and returned by servers to 5289 specify an upper bound for how long a client should wait before 5290 refreshing information retrieved from a DHCP server. It is only used 5291 in Reply messages in response to Information-request messages. In 5292 other messages there will usually be other information that indicates 5293 when the client should contact the server, e.g., T1/T2 times and 5294 lifetimes. This option is useful when the configuration parameters 5295 change or during renumbering event as clients running in the 5296 stateless mode will be able to update their configuration. 5298 The format of the Information Refresh Time option is: 5300 0 1 2 3 5301 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 5302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5303 |OPTION_INFORMATION_REFRESH_TIME| option-len | 5304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5305 | information-refresh-time | 5306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5308 Figure 37: Information Refresh Time Option Format 5310 option-code OPTION_INFORMATION_REFRESH_TIME (32). 5312 option-len 4. 5314 information-refresh-time Time duration relative to the current 5315 time, expressed in units of seconds. 5317 A DHCP client MUST request this option in the Option Request option 5318 (see Section 21.7) when sending Information-request messages. A 5319 client MUST NOT request this option in the ORO in any other messages. 5321 A server sending a Reply to an Information-Request message SHOULD 5322 include this option if it is requested in the ORO of the Information- 5323 Request. The option value MUST NOT be smaller than IRT_MINIMUM. 5324 This option MUST only appear in the top-level option area of Reply 5325 messages. 5327 If the Reply to an Information-request message does not contain this 5328 option, the client MUST behave as if the option with value 5329 IRT_DEFAULT was provided. 5331 A client MUST use the refresh time IRT_MINIMUM if it receives the 5332 option with a value less than IRT_MINIMUM. 5334 As per Section 7.7, the value 0xffffffff is taken to mean "infinity" 5335 and implies that the client should not refresh its configuration data 5336 without some other trigger (such as detecting movement to a new 5337 link). 5339 If a client contacts the server to obtain new data or refresh some 5340 existing data before the refresh time expires, then it SHOULD also 5341 refresh all data covered by this option. 5343 When the client detects that the refresh time has expired, it SHOULD 5344 try to update its configuration data by sending an Information- 5345 Request as specified in Section 18.2.6, except that the client MUST 5346 delay sending the first Information-request by a random amount of 5347 time between 0 and INF_MAX_DELAY. 5349 A client MAY have a maximum value for the refresh time, where that 5350 value is used whenever the client receives this option with a value 5351 higher than the maximum. This also means that the maximum value is 5352 used when the received value is "infinity". A maximum value might 5353 make the client less vulnerable to attacks based on forged DHCP 5354 messages. Without a maximum value, a client may be made to use wrong 5355 information for a possibly infinite period of time. There may 5356 however be reasons for having a very long refresh time, so it may be 5357 useful for this maximum value to be configurable. 5359 21.24. SOL_MAX_RT Option 5361 A DHCP server sends the SOL_MAX_RT option to a client to override the 5362 default value of SOL_MAX_RT. The value of SOL_MAX_RT in the option 5363 replaces the default value defined in Section 7.6. One use for the 5364 SOL_MAX_RT option is to set a longer value for SOL_MAX_RT, which 5365 reduces the Solicit traffic from a client that has not received a 5366 response to its Solicit messages. 5368 The format of the SOL_MAX_RT option is: 5370 0 1 2 3 5371 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 5372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5373 | option-code | option-len | 5374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5375 | SOL_MAX_RT value | 5376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5378 Figure 38: SOL_MAX_RT Option Format 5380 option-code OPTION_SOL_MAX_RT (82). 5382 option-len 4. 5384 SOL_MAX_RT value Overriding value for SOL_MAX_RT in seconds; 5385 MUST be in range: 60 <= "value" <= 86400 (1 5386 day). 5388 A DHCP client MUST include the SOL_MAX_RT option code in any Option 5389 Request option (see Section 21.7) it sends. 5391 The DHCP server MAY include the SOL_MAX_RT option in any response it 5392 sends to a client that has included the SOL_MAX_RT option code in an 5393 Option Request option. The SOL_MAX_RT option is sent in the main 5394 body of the message to client, not as an encapsulated option in, 5395 e.g., an IA_NA, IA_TA, or IA_PD option. 5397 A DHCP client MUST ignore any SOL_MAX_RT option values that are less 5398 than 60 or more than 86400. 5400 If a DHCP client receives a message containing a SOL_MAX_RT option 5401 that has a valid value for SOL_MAX_RT, the client MUST set its 5402 internal SOL_MAX_RT parameter to the value contained in the 5403 SOL_MAX_RT option. This value of SOL_MAX_RT is then used by the 5404 retransmission mechanism defined in Section 15 and Section 18.2.1. 5406 The purpose of this mechanism is to give network administrator a way 5407 to avoid large DHCP traffic if all DHCP servers become unavailable. 5408 Therefore this value is expected to be retained for as long as 5409 practically possible. 5411 Updated SOL_MAX_RT value applies only to the network interface on 5412 which the client received SOL_MAX_RT option. 5414 The requirement for the client to request SOL_MAX_RT serves two 5415 purposes. First, it distinguishes between legacy and modern clients. 5416 Second, it allows modern clients to take advantage of the 5417 configurable SOL_MAX_RT values, even if the server is a legacy one. 5419 21.25. INF_MAX_RT Option 5421 A DHCP server sends the INF_MAX_RT option to a client to override the 5422 default value of INF_MAX_RT. The value of INF_MAX_RT in the option 5423 replaces the default value defined in Section 7.6. One use for the 5424 INF_MAX_RT option is to set a longer value for INF_MAX_RT, which 5425 reduces the Information-request traffic from a client that has not 5426 received a response to its Information-request messages. 5428 The format of the INF_MAX_RT option is: 5430 0 1 2 3 5431 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 5432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5433 | option-code | option-len | 5434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5435 | INF_MAX_RT value | 5436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5438 Figure 39: INF_MAX_RT Option Format 5440 option-code OPTION_INF_MAX_RT (83). 5442 option-len 4. 5444 SOL_MAX_RT value Overriding value for INF_MAX_RT in seconds; 5445 MUST be in range: 60 <= "value" <= 86400 (1 5446 day). 5448 A DHCP client MUST include the INF_MAX_RT option code in any Option 5449 Request option (see Section 21.7) it sends. 5451 The DHCP server MAY include the INF_MAX_RT option in any response it 5452 sends to a client that has included the INF_MAX_RT option code in an 5453 Option Request option. The INF_MAX_RT option is sent in the main 5454 body of the message to client, not as an encapsulated option in, 5455 e.g., an IA_NA, IA_TA, or IA_PD option. 5457 A DHCP client MUST ignore any INF_MAX_RT option values that are less 5458 than 60 or more than 86400. 5460 If a DHCP client receives a message containing an INF_MAX_RT option 5461 that has a valid value for INF_MAX_RT, the client MUST set its 5462 internal INF_MAX_RT parameter to the value contained in the 5463 INF_MAX_RT option. This value of INF_MAX_RT is then used by the 5464 retransmission mechanism defined in Section 15 and Section 18.2.6. 5466 Updated INF_MAX_RT value applies only to the network interface on 5467 which the client received INF_MAX_RT option. 5469 22. Security Considerations 5471 This section discusses security considerations that are not related 5472 to privacy. For dedicated privacy discussion, see Section 23. The 5473 work in progress [I-D.ietf-dhc-sedhcpv6] document provides additional 5474 analysis of the security issues and specifies a secure client and 5475 server communication mechanism. 5477 The threat to DHCP is inherently an insider threat (assuming a 5478 properly configured network where DHCP ports are blocked on the 5479 perimeter gateways of the enterprise). Regardless of the gateway 5480 configuration, however, the potential attacks by insiders and 5481 outsiders are the same. 5483 One attack specific to a DHCP client is the establishment of a 5484 malicious server with the intent of providing incorrect configuration 5485 information to the client. The motivation for doing so may be to 5486 mount a "man in the middle" attack that causes the client to 5487 communicate with a malicious server instead of a valid server for 5488 some service such as DNS or NTP. The malicious server may also mount 5489 a denial of service attack through misconfiguration of the client 5490 that causes all network communication from the client to fail. 5492 A malicious DHCP server might cause a client to set its SOL_MAX_RT 5493 and INF_MAX_RT parameters to an unreasonably high value with the 5494 SOL_MAX_RT and INF_MAX_RT options, which may cause an undue delay in 5495 a client completing its DHCP protocol transaction in the case no 5496 other valid response is received. Assuming the client also receives 5497 a response from a valid DHCP server, large values for SOL_MAX_RT and 5498 INF_MAX_RT will not have any effect. 5500 There is another threat to DHCP clients from mistakenly or 5501 accidentally configured DHCP servers that answer DHCP client requests 5502 with unintentionally incorrect configuration parameters. 5504 A DHCP client may also be subject to attack through the receipt of a 5505 Reconfigure message from a malicious server that causes the client to 5506 obtain incorrect configuration information from that server. Note 5507 that although a client sends its response (Renew, Rebind, or 5508 Information-request message) through a relay agent and, therefore, 5509 that response will only be received by servers to which DHCP messages 5510 are relayed, a malicious server could send a Reconfigure message to a 5511 client, followed (after an appropriate delay) by a Reply message that 5512 would be accepted by the client. Thus, a malicious server that is 5513 not on the network path between the client and the server may still 5514 be able to mount a Reconfigure attack on a client. The use of 5515 transaction IDs that are cryptographically sound and cannot easily be 5516 predicted will also reduce the probability that such an attack will 5517 be successful. 5519 Because of the opportunity for attack through the Reconfigure 5520 message, a DHCP client MUST discard any Reconfigure message that does 5521 not include authentication or that does not pass the validation 5522 process for the authentication protocol. 5524 The Reconfigure Key protocol described in Section 20.4 provides 5525 protection against the use of a Reconfigure message by a malicious 5526 DHCP server to mount a denial of service or man-in-the-middle attack 5527 on a client. This protocol can be compromised by an attacker that 5528 can intercept the initial message in which the DHCP server sends the 5529 key "in plain text" to the client. 5531 Many of these rogue server attacks can be mitigated by making use of 5532 the mechanism described in [RFC7610]. 5534 The threat specific to a DHCP server is an invalid client 5535 masquerading as a valid client. The motivation for this may be for 5536 theft of service, or to circumvent auditing for any number of 5537 nefarious purposes. 5539 The threat common to both the client and the server is the resource 5540 "denial of service" (DoS) attack. These attacks typically involve 5541 the exhaustion of available assigned address or delegatable prefixes, 5542 or the exhaustion of CPU or network bandwidth, and are present 5543 anytime there is a shared resource. Some forms of these exhaustion 5544 attacks can be partially mitigated by appropriate server policy, 5545 e.g., limiting the maximum number of leases any one client can get. 5547 The messages exchanged between relay agents and servers may be used 5548 to mount a "man in the middle" or denial of service attack. 5549 Communication between a server and a relay agent, and communication 5550 between relay agents, can be authenticated and encrypted through the 5551 use of IPsec, as described in [I-D.ietf-dhc-relay-server-security]. 5553 However, the use of manually configured pre-shared keys for IPsec 5554 between relay agents and servers does not defend against replayed 5555 DHCP messages. Replayed messages can represent a DOS attack through 5556 exhaustion of processing resources, but not through mis-configuration 5557 or exhaustion of other resources such as assignable address and 5558 delegatable prefixes. 5560 Networks configured with delegated prefixes should be configured to 5561 preclude intentional or inadvertent inappropriate advertisement of 5562 these prefixes. 5564 23. Privacy Considerations 5566 This section focuses on the server considerations. For extended 5567 discussion about privacy considerations for the client, see 5568 [RFC7824]. In particular, Section 3 of said document discusses 5569 various identifiers that could be misused to track the client. 5570 Section 4 discusses existing mechanisms that may have an impact on 5571 client's privacy. Finally, Section 5 discusses potential attack 5572 vectors. For recommendations how to address or mitigate those 5573 issues, see [RFC7844]. 5575 This specification does not define any allocation strategies. 5576 Implementers are expected to develop their own algorithm for the 5577 server to choose a resource out of the available pool. Several 5578 possible allocation strategies are mentioned in Section 4.3 of 5579 [RFC7824]. Please keep in mind that this list is not exhaustive and 5580 there are certainly other possible strategies. Readers are also 5581 encouraged to read [RFC7707], in particular Section 4.1.2 that 5582 discusses the problems with certain allocation strategies. 5584 24. IANA Considerations 5586 This document does not define any new DHCP name spaces or 5587 definitions. 5589 The publication of this document does not change the assignment rules 5590 for new values for message types, option codes, DUID types or status 5591 codes. 5593 The list of assigned values used in DHCPv6 is available at 5594 http://www.iana.org/assignments/dhcpv6-parameters/ 5595 dhcpv6-parameters.xml 5597 IANA is requested to update the http://www.iana.org/assignments/ 5598 dhcpv6-parameters/dhcpv6-parameters.xhtml page to add a reference to 5599 this document for definitions previously created by [RFC3315], 5600 [RFC3633], [RFC4242] and [RFC7083]. 5602 IANA is requested to add a column to the DHCPv6 Option table at 5603 http://www.iana.org/assignments/dhcpv6-parameters/ 5604 dhcpv6-parameters.xhtml to indicate which options are allowed to 5605 appear in the ORO option. See Section 20.7. 5607 IANA is requested to add two columns to the DHCPv6 Option table at 5608 http://www.iana.org/assignments/dhcpv6-parameters/ 5609 dhcpv6-parameters.xhtml to indicate which options are allowed to 5610 appear in a client's ORO option (see Section 21.7) and which options 5611 are singleton options (only allowed to appear once as a top-level or 5612 encapsulated option - see Section 16 of [RFC7227]). Table 1 provides 5613 the data for the options assigned by IANA at the time of writing. 5615 +-------+-------------------------+---------------------+-----------+ 5616 | Optio | Option Name (OPTION | Client ORO (1) | Singleton | 5617 | n | prefix removed) | | Option | 5618 +-------+-------------------------+---------------------+-----------+ 5619 | 1 | CLIENTID | No | Yes | 5620 | 2 | SERVERID | No | Yes | 5621 | 3 | IA_NA | No | No | 5622 | 4 | IA_TA | No | No | 5623 | 5 | IAADDR | No | No | 5624 | 6 | ORO | No | Yes | 5625 | 7 | PREFERENCE | No | Yes | 5626 | 8 | ELAPSED_TIME | No | Yes | 5627 | 9 | RELAY_MSG | No | Yes | 5628 | 11 | AUTH | No | Yes | 5629 | 12 | UNICAST | Yes | Yes | 5630 | 13 | STATUS_CODE | No | Yes | 5631 | 14 | RAPID_COMMIT | No | Yes | 5632 | 15 | USER_CLASS | No | Yes | 5633 | 16 | VENDOR_CLASS | No | No (2) | 5634 | 17 | VENDOR_OPTS | Optional | No (2) | 5635 | 18 | INTERFACE_ID | No | Yes | 5636 | 19 | RECONF_MSG | No | Yes | 5637 | 20 | RECONF_ACCEPT | No | Yes | 5638 | 21 | SIP_SERVER_D | Yes | Yes | 5639 | 22 | SIP_SERVER_A | Yes | Yes | 5640 | 23 | DNS_SERVERS | Yes | Yes | 5641 | 24 | DOMAIN_LIST | Yes | Yes | 5642 | 25 | IA_PD | No | No | 5643 | 26 | IAPREFIX | No | No | 5644 | 27 | NIS_SERVERS | Yes | Yes | 5645 | 28 | NISP_SERVERS | Yes | Yes | 5646 | 29 | NIS_DOMAIN_NAME | Yes | Yes | 5647 | 30 | NISP_DOMAIN_NAME | Yes | Yes | 5648 | 31 | SNTP_SERVERS | Yes | Yes | 5649 | 32 | INFORMATION_REFRESH_TIM | Required for | Yes | 5650 | | E | Information-request | | 5651 | 33 | BCMCS_SERVER_D | Yes | Yes | 5652 | 34 | BCMCS_SERVER_A | Yes | Yes | 5653 | 36 | GEOCONF_CIVIC | Yes | Yes | 5654 | 37 | REMOTE_ID | No | Yes | 5655 | 38 | SUBSCRIBER_ID | No | Yes | 5656 | 39 | CLIENT_FQDN | Yes | Yes | 5657 | 40 | PANA_AGENT | Yes | Yes | 5658 | 41 | NEW_POSIX_TIMEZONE | Yes | Yes | 5659 | 42 | NEW_TZDB_TIMEZONE | Yes | Yes | 5660 | 43 | ERO | No | Yes | 5661 | 44 | LQ_QUERY | No | Yes | 5662 | 45 | CLIENT_DATA | No | Yes | 5663 | 46 | CLT_TIME | No | Yes | 5664 | 47 | LQ_RELAY_DATA | No | Yes | 5665 | 48 | LQ_CLIENT_LINK | No | Yes | 5666 | 49 | MIP6_HNIDF | Yes | Yes | 5667 | 50 | MIP6_VDINF | Yes | Yes | 5668 | 51 | V6_LOST | Yes | Yes | 5669 | 52 | CAPWAP_AC_V6 | Yes | Yes | 5670 | 53 | RELAY_ID | No | Yes | 5671 | 54 | OPTION-IPv6_Address-MoS | Yes | Yes | 5672 | 55 | OPTION-IPv6_FQDN-MoS | Yes | Yes | 5673 | 56 | NTP_SERVER | Yes | Yes | 5674 | 57 | V6_ACCESS_DOMAIN | Yes | Yes | 5675 | 58 | SIP_UA_CS_LIST | Yes | Yes | 5676 | 59 | OPT_BOOTFILE_URL | Yes | Yes | 5677 | 60 | OPT_BOOTFILE_PARAM | Yes | Yes | 5678 | 61 | CLIENT_ARCH_TYPE | No | Yes | 5679 | 62 | NII | Yes | Yes | 5680 | 63 | GEOLOCATION | Yes | Yes | 5681 | 64 | AFTR_NAME | Yes | Yes | 5682 | 65 | ERP_LOCAL_DOMAIN_NAME | Yes | Yes | 5683 | 66 | RSOO | No | Yes | 5684 | 67 | PD_EXCLUDE | Yes | Yes | 5685 | 68 | VSS | No | Yes | 5686 | 69 | MIP6_IDINF | Yes | Yes | 5687 | 70 | MIP6_UDINF | Yes | Yes | 5688 | 71 | MIP6_HNP | Yes | Yes | 5689 | 72 | MIP6_HAA | Yes | Yes | 5690 | 73 | MIP6_HAF | Yes | Yes | 5691 | 74 | RDNSS_SELECTION | Yes | No | 5692 | 75 | KRB_PRINCIPAL_NAME | Yes | Yes | 5693 | 76 | KRB_REALM_NAME | Yes | Yes | 5694 | 77 | KRB_DEFAULT_REALM_NAME | Yes | Yes | 5695 | 78 | KRB_KDC | Yes | Yes | 5696 | 79 | CLIENT_LINKLAYER_ADDR | No | Yes | 5697 | 80 | LINK_ADDRESS | No | Yes | 5698 | 81 | RADIUS | No | Yes | 5699 | 82 | SOL_MAX_RT | Required for | Yes | 5700 | | | Solicit | | 5701 | 83 | INF_MAX_RT | Required for | Yes | 5702 | | | Information-request | | 5703 | 84 | ADDRSEL | Yes | Yes | 5704 | 85 | ADDRSEL_TABLE | Yes | Yes | 5705 | 86 | V6_PCP_SERVER | Yes | No | 5706 | 87 | DHCPV4_MSG | No | Yes | 5707 | 88 | DHCP4_O_DHCP6_SERVER | Yes | Yes | 5708 | 89 | S46_RULE | No | No (3) | 5709 | 90 | S46_BR | No | No | 5710 | 91 | S46_DMR | No | Yes | 5711 | 92 | S46_V4V6BIND | No | Yes | 5712 | 93 | S46_PORTPARAMS | No | Yes | 5713 | 94 | S46_CONT_MAPE | Yes | No | 5714 | 95 | S46_CONT_MAPT | Yes | Yes | 5715 | 96 | S46_CONT_LW | Yes | Yes | 5716 | 97 | 4RD | Yes | Yes | 5717 | 98 | 4RD_MAP_RULE | Yes | Yes | 5718 | 99 | 4RD_NON_MAP_RULE | Yes | Yes | 5719 | 100 | LQ_BASE_TIME | No | Yes | 5720 | 101 | LQ_START_TIME | No | Yes | 5721 | 102 | LQ_END_TIME | No | Yes | 5722 | 103 | DHCP Captive-Portal | Yes | Yes | 5723 | 104 | MPL_PARAMETERS | Yes | Yes | 5724 | 105 | ANI_ATT | No | Yes | 5725 | 106 | ANI_NETWORK_NAME | No | Yes | 5726 | 107 | ANI_AP_NAME | No | Yes | 5727 | 108 | ANI_AP_BSSID | No | Yes | 5728 | 109 | ANI_OPERATOR_ID | No | Yes | 5729 | 110 | ANI_OPERATOR_REALM | No | Yes | 5730 | 111 | S46_PRIORITY | Yes | Yes | 5731 | 112 | MUD_URL_V6 (TEMPORARY) | No | Yes | 5732 | 113 | V6_PREFIX64 | Yes | No | 5733 | 114 | F_BINDING_STATUS | No | (4) | 5734 | 115 | F_CONNECT_FLAGS | No | (4) | 5735 | 116 | F_DNS_REMOVAL_INFO | No | (4) | 5736 | 117 | F_DNS_HOST_NAME | No | (4) | 5737 | 118 | F_DNS_ZONE_NAME | No | (4) | 5738 | 119 | F_DNS_FLAGS | No | (4) | 5739 | 120 | F_EXPIRATION_TIME | No | (4) | 5740 | 121 | F_MAX_UNACKED_BNDUPD | No | (4) | 5741 | 122 | F_MCLT | No | (4) | 5742 | 123 | F_PARTNER_LIFETIME | No | (4) | 5743 | 124 | F_PARTNER_LIFETIME_SENT | No | (4) | 5744 | 125 | F_PARTNER_DOWN_TIME | No | (4) | 5745 | 126 | F_PARTNER_RAW_CLT_TIME | No | (4) | 5746 | 127 | F_PROTOCOL_VERSION | No | (4) | 5747 | 128 | F_KEEPALIVE_TIME | No | (4) | 5748 | 129 | F_RECONFIGURE_DATA | No | (4) | 5749 | 130 | F_RELATIONSHIP_NAME | No | (4) | 5750 | 131 | F_SERVER_FLAGS | No | (4) | 5751 | 132 | F_SERVER_STATE | No | (4) | 5752 | 133 | F_START_TIME_OF_STATE | No | (4) | 5753 | 134 | F_STATE_EXPIRATION_TIME | No | (4) | 5754 | 143 | IPv6_ADDRESS-ANDSF | Yes | Yes | 5755 +-------+-------------------------+---------------------+-----------+ 5757 Table 1: Updated Options Table 5759 Notes for Table 1: 5761 (1) For the "Client ORO" column: a "Yes" for an option means that 5762 the client includes this option code if it desires that 5763 configuration information; a "No" means that the option MUST 5764 NOT be included (and servers SHOULD silently ignore that option 5765 code if it appears in ORO). 5767 (2) For each enterprise-number, there MUST only be a single 5768 instance. 5770 (3) See [RFC7598] for details. 5772 (4) See RFC8156 for details. 5774 IANA is requested to update the All_DHCP_Relay_Agents_and_Servers 5775 (FF02::1:2) and All_DHCP_Servers (FF05::1:3) table entries in the 5776 IPv6 multicast address space registry at 5777 http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6- 5778 multicast-addresses.xhtml to reference this document instead of 5779 [RFC3315]. 5781 IANA is requested to update the http://www.iana.org/assignments/ 5782 bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#authentication- 5783 protocol-id page to add an "Obsolete" annotation into the "DHCPv6 5784 Delayed Authentication" entity in the "Authentication Suboption 5785 (value 8) - Protocol identifier values" registry, and 5786 https://www.iana.org/assignments/auth-namespaces/auth- 5787 namespaces.xhtml page to add an "Obsolete" annotation into the 5788 "Delayed Authentication" entity in the "Protocol Name Space Values" 5789 registry. IANA is also requested to update these pages to reference 5790 this document instead of [RFC3315]. 5792 25. Obsoleted Mechanisms 5794 This specification is mostly a corrected and cleaned up version of 5795 the original specification, [RFC3315], along with numerous additions 5796 from later RFCs. However, there are a small number of mechanisms 5797 that were not widely deployed, were underspecified or had other 5798 operational issues. Those mechanisms are now considered deprecated. 5799 Legacy implementations MAY support them, but implementations 5800 conformant to this document MUST NOT rely on them. 5802 The following mechanisms are now obsolete: 5804 Delayed Authentication. This mechanism was underspecified and had 5805 significant operational burden. As a result, after 10 years its 5806 adoption was extremely limited at best. 5808 Lifetime hints sent by a client. Clients used to be allowed to send 5809 lifetime values as hints. This mechanism was not widely implemented 5810 and there were known misimplementations that sent the remaining 5811 lifetimes rather than total desired lifetimes. That in turn was 5812 sometimes misunderstood by servers as a request for ever decreasing 5813 lease lifetimes, which caused issues when values started approaching 5814 zero. Clients now SHOULD set lifetimes to 0 in IA Address and IA 5815 Prefix options, and servers MUST ignore any requested lifetime value. 5817 T1/T2 hints sent by a client. These had similar issues to the 5818 lifetime hints. Clients now SHOULD set the T1/T2 values to 0 in 5819 IA_NA and IA_PD options, and servers MUST ignore any client supplied 5820 T1/T2 values. 5822 26. Acknowledgments 5824 This document is merely a refinement of earlier work by the authors 5825 of RFC3315 (Ralph Droms, Jim Bound, Bernie Volz, Ted Lemon, Charles 5826 Perkins, and Mike Carney) RFC3633 (Ole Troan and Ralph Droms), 5827 RFC3736 (Ralph Droms), RFC4242 (Stig Venaas, Tim Chown, and Bernie 5828 Volz), RFC7083 (Ralph Droms), and RFC7550 (Ole Troan, Bernie Volz, 5829 and Marcin Siodelski) and would not be possible without their 5830 original work. 5832 A number of additional people have contributed to identifying issues 5833 with RFC3315 and RFC3633 and proposed resolutions to these issues as 5834 reflected in this document (in no particular order): Ole Troan, 5835 Robert Marks, Leaf Yeh, Michelle Cotton, Pablo Armando, John 5836 Brzozowski, Suresh Krishnan, Hideshi Enokihara, Alexandru Petrescu, 5837 Yukiyo Akisada, Tatuya Jinmei, Fred Templin and Christian Huitema. 5839 We also thank the following, not otherwise acknowledged and in no 5840 particular order, for their review comments: Jeremy Reed, Francis 5841 Dupont, Tatuya Jinmei, Lorenzo Colitti, Tianxiang Li, Ian Farrer, 5842 Yogendra Pal, Kim Kinnear, Shawn Routhier, Tim Chown, and Michayla 5843 Newcombe. 5845 And, special thanks to Ralph Droms for answering many questions 5846 related to the original RFC3315 and RFC3633 work and for being the 5847 document shepherd. 5849 27. References 5851 27.1. Normative References 5853 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 5854 DOI 10.17487/RFC0768, August 1980, 5855 . 5857 [RFC1035] Mockapetris, P., "Domain names - implementation and 5858 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 5859 November 1987, . 5861 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5862 Requirement Levels", BCP 14, RFC 2119, 5863 DOI 10.17487/RFC2119, March 1997, 5864 . 5866 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 5867 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 5868 December 1998, . 5870 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 5871 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 5872 2006, . 5874 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 5875 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 5876 DOI 10.17487/RFC4861, September 2007, 5877 . 5879 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 5880 Address Autoconfiguration", RFC 4862, 5881 DOI 10.17487/RFC4862, September 2007, 5882 . 5884 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 5885 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 5886 DOI 10.17487/RFC6221, May 2011, 5887 . 5889 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 5890 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 5891 DOI 10.17487/RFC6355, August 2011, 5892 . 5894 [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT 5895 and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 5896 2013, . 5898 [RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 5899 Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014, 5900 . 5902 27.2. Informative References 5904 [I-D.ietf-dhc-dhcpv6-prefix-length-hint-issue] 5905 Li, T., Liu, C., and Y. Cui, "DHCPv6 Prefix Length Hint 5906 Issues", draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06 5907 (work in progress), March 2017. 5909 [I-D.ietf-dhc-relay-server-security] 5910 Volz, B. and Y. Pal, "Security of Messages Exchanged 5911 Between Servers and Relay Agents", draft-ietf-dhc-relay- 5912 server-security-05 (work in progress), April 2017. 5914 [I-D.ietf-dhc-sedhcpv6] 5915 Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. 5916 Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work 5917 in progress), February 2017. 5919 [IANA-PEN] 5920 IANA, "Private Enterprise Numbers registry 5921 http://www.iana.org/assignments/enterprise-numbers". 5923 [IANA-RESERVED-IID] 5924 IANA, "Reserved IPv6 Interface Identifiers 5925 http://www.iana.org/assignments/ipv6-interface-ids/ 5926 ipv6-interface-ids.xml". 5928 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 5929 Converting Network Protocol Addresses to 48.bit Ethernet 5930 Address for Transmission on Ethernet Hardware", STD 37, 5931 RFC 826, DOI 10.17487/RFC0826, November 1982, 5932 . 5934 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 5935 RFC 2131, DOI 10.17487/RFC2131, March 1997, 5936 . 5938 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 5939 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 5940 . 5942 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 5943 Autoconfiguration", RFC 2462, DOI 10.17487/RFC2462, 5944 December 1998, . 5946 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 5947 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 5948 . 5950 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 5951 Stateless Address Autoconfiguration in IPv6", RFC 3041, 5952 DOI 10.17487/RFC3041, January 2001, 5953 . 5955 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 5956 RFC 3162, DOI 10.17487/RFC3162, August 2001, 5957 . 5959 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 5960 C., and M. Carney, "Dynamic Host Configuration Protocol 5961 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 5962 2003, . 5964 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 5965 Host Configuration Protocol (DHCP) version 6", RFC 3633, 5966 DOI 10.17487/RFC3633, December 2003, 5967 . 5969 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 5970 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 5971 DOI 10.17487/RFC3646, December 2003, 5972 . 5974 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 5975 (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, 5976 April 2004, . 5978 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 5979 Delegation", RFC 3769, DOI 10.17487/RFC3769, June 2004, 5980 . 5982 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 5983 Configuration Option for DHCPv6", RFC 4075, 5984 DOI 10.17487/RFC4075, May 2005, 5985 . 5987 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 5988 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 5989 . 5991 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 5992 Time Option for Dynamic Host Configuration Protocol for 5993 IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November 5994 2005, . 5996 [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host 5997 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 5998 Issues", RFC 4477, DOI 10.17487/RFC4477, May 2006, 5999 . 6001 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 6002 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 6003 Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, 6004 . 6006 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 6007 Extensions for Stateless Address Autoconfiguration in 6008 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 6009 . 6011 [RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor 6012 Discovery On-Link Assumption Considered Harmful", 6013 RFC 4943, DOI 10.17487/RFC4943, September 2007, 6014 . 6016 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 6017 "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, 6018 September 2007, . 6020 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 6021 RFC 5453, DOI 10.17487/RFC5453, February 2009, 6022 . 6024 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 6025 "Network Time Protocol Version 4: Protocol and Algorithms 6026 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 6027 . 6029 [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. 6030 Troan, "Prefix Exclude Option for DHCPv6-based Prefix 6031 Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, 6032 . 6034 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 6035 "Default Address Selection for Internet Protocol Version 6 6036 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 6037 . 6039 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 6040 Network Renumbering Scenarios, Considerations, and 6041 Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, 6042 . 6044 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 6045 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 6046 May 2013, . 6048 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 6049 Requirements for IPv6 Customer Edge Routers", RFC 7084, 6050 DOI 10.17487/RFC7084, November 2013, 6051 . 6053 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 6054 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 6055 February 2014, . 6057 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 6058 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 6059 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 6060 . 6062 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 6063 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 6064 RFC 7341, DOI 10.17487/RFC7341, August 2014, 6065 . 6067 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 6068 Weil, "IPv6 Home Networking Architecture Principles", 6069 RFC 7368, DOI 10.17487/RFC7368, October 2014, 6070 . 6072 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 6073 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 6074 Boundary in IPv6 Addressing", RFC 7421, 6075 DOI 10.17487/RFC7421, January 2015, 6076 . 6078 [RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and 6079 Recommendations with Multiple Stateful DHCPv6 Options", 6080 RFC 7550, DOI 10.17487/RFC7550, May 2015, 6081 . 6083 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 6084 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 6085 Configuration of Softwire Address and Port-Mapped 6086 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 6087 . 6089 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 6090 Protecting against Rogue DHCPv6 Servers", BCP 199, 6091 RFC 7610, DOI 10.17487/RFC7610, August 2015, 6092 . 6094 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 6095 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 6096 . 6098 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 6099 Considerations for IPv6 Address Generation Mechanisms", 6100 RFC 7721, DOI 10.17487/RFC7721, March 2016, 6101 . 6103 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 6104 Considerations for DHCPv6", RFC 7824, 6105 DOI 10.17487/RFC7824, May 2016, 6106 . 6108 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 6109 Profiles for DHCP Clients", RFC 7844, 6110 DOI 10.17487/RFC7844, May 2016, 6111 . 6113 [RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP 6114 Configuration on the Basis of Network Topology", RFC 7969, 6115 DOI 10.17487/RFC7969, October 2016, 6116 . 6118 [TR-187] Broadband Forum, "TR-187 - IPv6 for PPP Broadband Access", 6119 February 2013, . 6122 Appendix A. Summary of Changes 6124 This appendix provides a summary of the significant changes made to 6125 this updated DHCPv6 specification. 6127 1. The Introduction Section 1 was reorganized and updated. In 6128 particular, the client/server message exchanges were moved into 6129 a new (and expanded) section on their own (see Section 5). And, 6130 new sections were added to discuss the relation to previous 6131 DHCPv6 documents and also to DHCPv4. 6133 2. The Requirements Section 2 and Background Section 3 had very 6134 minor edits. 6136 3. The Terminology Section 4 had minor edits. 6138 4. The DHCP Terminology Section 4.2 was expanded to incorporate 6139 definitions from RFC3633, add T1/T2 definitions, add a few new 6140 definitions useful in a document that combined address and 6141 prefix delegation assignments, and improve some existing 6142 definitions. 6144 5. The Client-Server Exchanges Section 5 was added from material 6145 previously in the Introduction Section 1 of RFC3315 and was 6146 expanded. 6148 6. The Operational Models Section 6 is new and provides information 6149 on the kinds of DHCP clients and how they operate. 6151 7. The DHCP Constants Section 7 was primarily updated to add 6152 constants from RFC4242 and RFC7083. 6154 8. The Client/Server Message Formats Section 8, Relay Agent/Server 6155 Message Formats Section 9, and Representation and Use of Domain 6156 Names Section 10 had only very minor changes. 6158 9. The DHCP Unique Identifier (DUID) Section 11 now discourages, 6159 rather than disallows, a server to parse the DUID, now includes 6160 some information on the DUID-UUID (RFC6355), and has other minor 6161 edits. 6163 10. The Identity Association Section 12 was expanded to better 6164 explain the concept and also included prefix delegation. 6166 11. The Assignment to an IA Section 13 incorporates material from 6167 two sections (11 and 12) of RFC3315 and also includes a section 6168 on prefix delegation. 6170 12. The Transmission of Messages by a Client Section 14 was expanded 6171 to include rate limiting by clients and how clients should 6172 handle T1 or T2 values of 0. 6174 13. The Reliability of Client Initiated Message Exchanges Section 15 6175 was expanded to clarify that the Elapsed Time option must be 6176 updated in retransmitted messages and that a client is not 6177 required to listen for DHCP traffic for the entire 6178 retransmission period. 6180 14. The Message Validation Section 16 had minor edits. 6182 15. The Client Source Address and Interface Selection Section 17 was 6183 expanded to include prefix delegation. 6185 16. The DHCP Configuration Exchanges Section 18 consolidates what 6186 used to be in the RFC3315 DHCP Server Solicitation Section 17, 6187 DHCP Client-Initiated Configuration Exchange Section 18, and 6188 DHCP Server-Initiated Configuration Exchange Section 19. This 6189 material was reorganized and enhanced, and incorporates prefix 6190 delegation from RFC3633 and other changes from RFC4242, RFC7083, 6191 and RFC7550. A few changes of note: 6193 1. The Option Request option is no longer optional for some 6194 messages (Solicit and Information-request) as RFC7083 6195 requires clients to request SOL_MAX_RT or INF_MAX_RT 6196 options. 6198 2. The Reconfigure message should no longer contain IA_NA/ 6199 IA_PD, ORO, or other options to indicate to the client what 6200 was reconfigured. The client should request everything it 6201 needs in the response to the Reconfigure. 6203 3. Lifetime and T1/T2 hints should not be sent by a client (it 6204 should send 0 values in these fields) and any non-zero 6205 values should be ignored by the server. 6207 4. Clarified that a server may return different addresses in 6208 the Reply than requested by a client in the Request message. 6209 Also clarified that a server must not include addresses that 6210 it will not assign. 6212 Also, a Refreshing Configuration Information Section 18.2.12 was 6213 added indicating use cases for when a client should try to 6214 refresh network information. 6216 17. The Relay Agent Behavior Section 19 had minor edits. 6218 18. The Authentication of DHCP Messages Section 20 had significant 6219 changes: IPsec materials were mostly removed and replaced with a 6220 reference to [I-D.ietf-dhc-relay-server-security], and the Delay 6221 Authentication Protocol was removed (see Section 25). Note that 6222 the Reconfigure Key Authentication Protocol is retained. 6224 19. The DHCP Options Section 21 was expanded to incorporate the 6225 prefix delegation options from RFC3633, the Information Refresh 6226 Time option from RFC4242, and the SOL_MAX_RT and INF_MAX_RT 6227 options from RFC7083. In addition, some additional edits were 6228 made to clarify option handling, such as which options should 6229 not be in an Option Request option. 6231 20. The Security Considerations Section 22 were updated to expand 6232 the discussion of security threats and incorporate material from 6233 the incorporated documents, primarily RFC3633. 6235 21. The new Privacy Considerations Section 23 was added to consider 6236 privacy issues. 6238 22. The IANA Considerations Section 24 was rewritten to reflect the 6239 changes requested for this document as other documents have 6240 already made the message, option, DUID, and status code 6241 assignments and this document does not add any new assignments. 6243 23. The new Obsoleted Mechanisms Section 25 documents what this 6244 specification obsoletes. 6246 24. The Appearance of Options in Message Types Appendix B and 6247 Appearance of Options in the Options Field of DHCP Appendix C 6248 were updated to reflect the incorporated options from RFC3633, 6249 RFC4242, and RFC7083. 6251 25. Where appropriate, informational references have been added to 6252 provide further background and guidance throughout the document 6253 (as can be noted by the vast increase in references). 6255 26. General changes to other IPv6 specifications, such as removing 6256 the use of site-local unicast addresses and adding unique local 6257 addresses, were made to the document. Note that in a few 6258 places, older obsoleted RFCs (such as RFC2462 related to M and O 6259 bit handling) are still referenced as the material cited was not 6260 added in the replacement RFC. 6262 27. It should be noted that this document does not refer to all 6263 DHCPv6 functionality and specifications. Readers of this 6264 specification should visit http://www.iana.org/assignments/ 6265 dhcpv6-parameters/dhcpv6-parameters.xml and 6266 https://datatracker.ietf.org/wg/dhc/ to learn of the RFCs that 6267 define DHCPv6 messages, options, status-codes, and more. 6269 Appendix B. Appearance of Options in Message Types 6271 The following table indicates with a "*" the options are allowed in 6272 each DHCP message type: 6274 Client Server IA_NA/ Elap. Relay Server 6275 ID ID IA_TA IA_PD ORO Pref Time Msg. Auth. Unicast 6276 Solicit * * * * * 6277 Advert. * * * * * 6278 Request * * * * * * 6279 Confirm * * * 6280 Renew * * * * * * 6281 Rebind * * * * * 6282 Decline * * * * * 6283 Release * * * * * 6284 Reply * * * * * * 6285 Reconf. * * 6286 Inform. * (see note) * * * 6287 R-forw. * 6288 R-repl. * 6290 NOTE: Only included in Information-request messages that are sent in 6291 response to a Reconfigure (see Section 18.2.6). 6293 Info 6294 Status Rap. User Vendor Vendor Inter. Recon. Recon. Refresh 6295 Code Comm. Class Class Spec. ID Msg. Accept Time 6296 Solicit * * * * * 6297 Advert. * * * * * 6298 Request * * * * 6299 Confirm * * * 6300 Renew * * * * 6301 Rebind * * * * 6302 Decline * * * 6303 Release * * * 6304 Reply * * * * * * * 6305 Reconf. * 6306 Inform. * * * * * 6307 R-forw. * * * * 6308 R-repl. * * * * 6309 SOL_MAX_RT INF_MAX_RT 6310 Solicit * 6311 Advert. * 6312 Request 6313 Confirm 6314 Renew 6315 Rebind 6316 Decline 6317 Release 6318 Reply * * 6319 Reconf. 6320 Inform. 6321 R-forw. 6322 R-repl. 6324 Appendix C. Appearance of Options in the Options Field of DHCP Options 6326 The following table indicates with a "*" where options can appear in 6327 the options field of other options: 6329 Option IA_NA/ Relay- Relay- 6330 Field IA_TA IAADDR IA_PD IAPREFIX Forw Reply 6331 Client ID * 6332 Server ID * 6333 IA_NA/IA_TA * 6334 IAADDR * 6335 IA_PD * 6336 IAPREFIX * 6337 ORO * 6338 Preference * 6339 Elapsed Time * 6340 Relay Message * * 6341 Authentic. * 6342 Server Uni. * 6343 Status Code * * * 6344 Rapid Comm. * 6345 User Class * 6346 Vendor Class * 6347 Vendor Info. * * * 6348 Interf. ID * * 6349 Reconf. MSG. * 6350 Reconf. Accept * 6351 Info Refresh Time * 6352 SOL_MAX_RT * 6353 INF_MAX_RT * 6355 Note: "Relay-Forw" / "Relay-Reply" options appear in the options 6356 field of the Relay-forward and Relay-reply messages. 6358 Authors' Addresses 6360 Tomek Mrugalski (editor) 6361 Internet Systems Consortium, Inc. 6362 950 Charter Street 6363 Redwood City, CA 94063 6364 USA 6366 Email: tomasz.mrugalski@gmail.com 6368 Marcin Siodelski 6369 Internet Systems Consortium, Inc. 6370 950 Charter St. 6371 Redwood City, CA 94063 6372 USA 6374 Email: msiodelski@gmail.com 6376 Bernie Volz 6377 Cisco Systems, Inc. 6378 1414 Massachusetts Ave 6379 Boxborough, MA 01719 6380 USA 6382 Email: volz@cisco.com 6384 Andrew Yourtchenko 6385 Cisco Systems, Inc. 6386 De Kleetlaan, 7 6387 Diegem B-1831 6388 Belgium 6390 Email: ayourtch@cisco.com 6392 Michael C. Richardson 6393 Sandelman Software Works 6394 470 Dawson Avenue 6395 Ottawa, ON K1Z 5V7 6396 CA 6398 Email: mcr+ietf@sandelman.ca 6399 URI: http://www.sandelman.ca/ 6400 Sheng Jiang 6401 Huawei Technologies Co., Ltd 6402 Q14, Huawei Campus, No.156 Beiqing Road 6403 Hai-Dian District, Beijing, 100095 6404 P.R. China 6406 Email: jiangsheng@huawei.com 6408 Ted Lemon 6409 Nominum, Inc. 6410 800 Bridge St. 6411 Redwood City, CA 94043 6412 USA 6414 Email: Ted.Lemon@nominum.com 6416 Timothy Winters 6417 University of New Hampshire, Interoperability Lab (UNH-IOL) 6418 Durham, NH 6419 USA 6421 Email: twinters@iol.unh.edu