idnits 2.17.1 draft-ietf-dhc-rfc3315bis-09.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 (June 28, 2017) is 2493 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 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 (==), 9 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: December 30, 2017 Cisco 8 M. Richardson 9 SSW 10 S. Jiang 11 Huawei 12 T. Lemon 13 Nominum 14 T. Winters 15 UNH-IOL 16 June 28, 2017 18 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis 19 draft-ietf-dhc-rfc3315bis-09 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 December 30, 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 . . . . . . . . . . . . . 20 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 . . . . . . . . . . . 28 120 11. DHCP Unique Identifier (DUID) . . . . . . . . . . . . . . . . 28 121 11.1. DUID Contents . . . . . . . . . . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . . . . . . . . . . 31 125 11.4. DUID Based on Link-layer Address, DUID-LL . . . . . . . 32 126 11.5. DUID Based on Universally Unique IDentifier (UUID), 127 DUID-UUID . . . . . . . . . . . . . . . . . . . . . . . 33 128 12. Identity Association . . . . . . . . . . . . . . . . . . . . 33 129 12.1. Identity Associations for Address Assignment . . . . . . 34 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 . . . . . . . . . . . 36 134 13.3. Assignment of Prefixes for IA_PD . . . . . . . . . . . . 36 135 14. Transmission of Messages by a Client . . . . . . . . . . . . 37 136 14.1. Rate Limiting . . . . . . . . . . . . . . . . . . . . . 37 137 14.2. Client Behavior when T1 and/or T2 are 0 . . . . . . . . 38 138 15. Reliability of Client Initiated Message Exchanges . . . . . . 38 139 16. Message Validation . . . . . . . . . . . . . . . . . . . . . 40 140 16.1. Use of Transaction IDs . . . . . . . . . . . . . . . . . 41 141 16.2. Solicit Message . . . . . . . . . . . . . . . . . . . . 41 142 16.3. Advertise Message . . . . . . . . . . . . . . . . . . . 41 143 16.4. Request Message . . . . . . . . . . . . . . . . . . . . 42 144 16.5. Confirm Message . . . . . . . . . . . . . . . . . . . . 42 145 16.6. Renew Message . . . . . . . . . . . . . . . . . . . . . 42 146 16.7. Rebind Message . . . . . . . . . . . . . . . . . . . . . 42 147 16.8. Decline Messages . . . . . . . . . . . . . . . . . . . . 43 148 16.9. Release Message . . . . . . . . . . . . . . . . . . . . 43 149 16.10. Reply Message . . . . . . . . . . . . . . . . . . . . . 43 150 16.11. Reconfigure Message . . . . . . . . . . . . . . . . . . 44 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 . . 45 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 . . . 52 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 . . . . . . . . . . . . . . . . . . . . . . 57 167 18.2.7. Creation and Transmission of Release Messages . . . 58 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 . . . . . . . . . . . . 77 187 18.3.9. Creation of Advertise Messages . . . . . . . . . . . 78 188 18.3.10. Transmission of Advertise and Reply Messages . . . . 79 189 18.3.11. Creation and Transmission of Reconfigure Messages . 80 190 18.4. Reception of Unicast Messages . . . . . . . . . . . . . 81 191 19. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 81 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 . . . . . . . . . . . . . 83 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 . . . . . . . . . . . . . . . . . . . . 85 203 20.4. Reconfigure Key Authentication Protocol . . . . . . . . 86 204 20.4.1. Use of the Authentication Option in the Reconfigure 205 Key Authentication Protocol . . . . . . . . . . . . 86 206 20.4.2. Server Considerations for Reconfigure Key 207 Authentication Protocol . . . . . . . . . . . . . . 87 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 . . . . . . . . . . . . . . . . 89 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 . . . . . . . . . . . . . . . . . . 99 221 21.11. Authentication Option . . . . . . . . . . . . . . . . . 100 222 21.12. Server Unicast Option . . . . . . . . . . . . . . . . . 101 223 21.13. Status Code Option . . . . . . . . . . . . . . . . . . . 102 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 . . . . . . . . . . . . 115 234 21.24. SOL_MAX_RT Option . . . . . . . . . . . . . . . . . . . 117 235 21.25. INF_MAX_RT Option . . . . . . . . . . . . . . . . . . . 118 236 22. Security Considerations . . . . . . . . . . . . . . . . . . . 119 237 23. Privacy Considerations . . . . . . . . . . . . . . . . . . . 121 238 24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 121 239 25. Obsoleted Mechanisms . . . . . . . . . . . . . . . . . . . . 126 240 26. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 126 241 27. References . . . . . . . . . . . . . . . . . . . . . . . . . 127 242 27.1. Normative References . . . . . . . . . . . . . . . . . . 127 243 27.2. Informative References . . . . . . . . . . . . . . . . . 128 244 Appendix A. Summary of Changes . . . . . . . . . . . . . . . . . 133 245 Appendix B. Appearance of Options in Message Types . . . . . . . 136 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 [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 update its configuration by sending an Information-request, Renew, or 707 Rebind message. The client then performs the earlier described two 708 message exchange. This can be used to expedite configuration changes 709 to a client, such as the need to renumber a network (see [RFC6879]). 711 6. Operational Models 713 This section describes some of the current most common DHCP 714 operational models. The described models are not mutually exclusive 715 and are sometimes used together. For example, a device may start in 716 stateful mode to obtain an address, and at a later time when an 717 application is started, request additional parameters using stateless 718 mode. 720 This document assumes that the DHCP servers and the client, 721 communicating with the servers via specific interface, belong to a 722 single provisioning domain. 724 6.1. Stateless DHCP 726 Stateless DHCP [RFC3736] is used when DHCP is not used for obtaining 727 a lease, but a node (DHCP client) desires one or more DHCP "other 728 configuration" parameters, such as a list of DNS recursive name 729 servers or DNS domain search lists [RFC3646]. Stateless may be used 730 when a node initially boots or at any time the software on the node 731 requires some missing or expired configuration information that is 732 available via DHCP. 734 This is the simplest and most basic operation for DHCP and requires a 735 client (and a server) to support only two messages - Information- 736 request and Reply. Note that DHCP servers and relay agents typically 737 also need to support the Relay-forward and Relay-reply messages to 738 accommodate operation when clients and servers are not on the same 739 link. 741 6.2. DHCP for Non-Temporary Address Assignment 743 This model of operation was the original motivation for DHCP. It is 744 appropriate for situations where stateless address autoconfiguration 745 alone is insufficient or impractical, e.g., because of network 746 policy, additional requirements such as dynamic updates to the DNS, 747 or client-specific requirements. 749 The model of operation for non-temporary address assignment is as 750 follows. The server is provided with prefixes from which it may 751 allocate addresses to clients, as well as any related network 752 topology information as to which prefixes are present on which links. 753 A client requests a non-temporary address to be assigned by the 754 server. The server allocates an address or addresses appropriate for 755 the link on which the client is connected. The server returns the 756 allocated address or addresses to the client. 758 Each address has an associated preferred and valid lifetime, which 759 constitutes an agreement about the length of time over which the 760 client is allowed to use the address. A client can request an 761 extension of the lifetimes on an address and is required to terminate 762 the use of an address if the valid lifetime of the address expires. 764 Typically clients request other configuration parameters, such as the 765 DNS name server addresses and domain search lists, when requesting 766 addresses. 768 Clients can also request more than one address or set of addresses 769 (see Section 6.6 and Section 12). 771 6.3. DHCP for Prefix Delegation 773 The prefix delegation mechanism, originally described in [RFC3633], 774 is another stateful mode of operation and was originally intended for 775 simple delegation of prefixes from a delegating router (DHCP server) 776 to requesting routers (DHCP clients). It is appropriate for 777 situations in which the delegating router does not have knowledge 778 about the topology of the networks to which the requesting router is 779 attached, and the delegating router does not require other 780 information aside from the identity of the requesting router to 781 choose a prefix for delegation. For example, these options would be 782 used by a service provider to assign a prefix to a Customer Edge 783 Router device acting as a router between the subscriber's internal 784 network and the service provider's core network. 786 The design of this prefix delegation mechanism meets the requirements 787 for prefix delegation in [RFC3769]. 789 While [RFC3633] assumed that the DHCP client is a router (hence use 790 of "requesting router") and that the DHCP server was a router (hence 791 use of "delegating router"), DHCP prefix delegation itself does not 792 require that the client forward IP packets not addressed to itself, 793 and thus does not require that the client (or server) be a router as 794 defined in [RFC2460]. Also, in many cases (such as tethering or 795 hosting virtual machines), hosts are already forwarding IP packets 796 and thus operating as routers as defined in [RFC2460]. Therefore, 797 this document mostly replaces "requesting router" with client and 798 "delegating router" with server. 800 The model of operation for prefix delegation is as follows. A server 801 is provided prefixes to be delegated to clients. A client requests 802 prefix(es) from the server, as described in Section 18. The server 803 chooses prefix(es) for delegation, and responds with prefix(es) to 804 the client. The client is then responsible for the delegated 805 prefix(es). For example, the client might assign a subnet from a 806 delegated prefix to one of its interfaces, and begin sending router 807 advertisements for the prefix on that link. 809 Each prefix has an associated valid and preferred lifetime, which 810 constitutes an agreement about the length of time over which the 811 client is allowed to use the prefix. A client can request an 812 extension of the lifetimes on a delegated prefix and is required to 813 terminate the use of a delegated prefix if the valid lifetime of the 814 prefix expires. 816 This prefix delegation mechanism is appropriate for use by an ISP to 817 delegate a prefix to a subscriber, where the delegated prefix would 818 possibly be subnetted and assigned to the links within the 819 subscriber's network. [RFC7084] and [RFC7368] describe in detail 820 such use. 822 Figure 1 illustrates a network architecture in which prefix 823 delegation could be used. 825 ______________________ \ 826 / \ \ 827 | ISP core network | \ 828 \__________ ___________/ | 829 | | 830 +-------+-------+ | 831 | Aggregation | | ISP 832 | device | | network 833 | (delegating | | 834 | router) | | 835 +-------+-------+ | 836 | / 837 |Network link to / 838 |subscriber premises / 839 | 840 +------+------+ \ 841 | CPE | \ 842 | (requesting | \ 843 | router) | | 844 +----+---+----+ | 845 | | | Subscriber 846 ---+-------------+-----+ +-----+------ | Network 847 | | | | 848 +----+-----+ +-----+----+ +----+-----+ | 849 |Subscriber| |Subscriber| |Subscriber| / 850 | PC | | PC | | PC | / 851 +----------+ +----------+ +----------+ / 853 Figure 1: Prefix Delegation Network 855 In this example, the server (delegating router) is configured with a 856 set of prefixes to be used for assignment to customers at the time of 857 each customer's first connection to the ISP service. The prefix 858 delegation process begins when the client (requesting router) 859 requests configuration information through DHCP. The DHCP messages 860 from the client are received by the server in the aggregation device. 861 When the server receives the request, it selects an available prefix 862 or prefixes for delegation to the client. The server then returns 863 the prefix or prefixes to the client. 865 The client subnets the delegated prefix and assigns the longer 866 prefixes to links in the subscriber's network. In a typical scenario 867 based on the network shown in Figure 1, the client subnets a single 868 delegated /48 prefix into /64 prefixes and assigns one /64 prefix to 869 each of the links in the subscriber network. 871 The prefix delegation options can be used in conjunction with other 872 DHCP options carrying other configuration information to the client. 873 The client may, in turn, provide DHCP service to nodes attached to 874 the internal network. For example, the client may obtain the 875 addresses of DNS and NTP servers from the ISP server, and then pass 876 that configuration information on to the subscriber hosts through a 877 DHCP server in the client (requesting router). 879 If the client uses a delegated prefix to configure addresses on 880 interfaces on itself or other nodes behind it, the preferred and 881 valid lifetimes of those addresses MUST be no larger than the 882 remaining preferred and valid lifetimes, respectively, for the 883 delegated prefix at any time. In particular, if the delegated prefix 884 or a prefix derived from it is advertised for stateless address 885 autoconfiguration [RFC4862], the advertised preferred and valid 886 lifetimes MUST NOT exceed the corresponding remaining lifetimes of 887 the delegated prefix. 889 6.4. DHCP for Customer Edge Routers 891 The DHCP requirements and network architecture for Customer Edge 892 Routers are described in [RFC7084]. This model of operation combines 893 address assignment (see Section 6.2) and prefix delegation (see 894 Section 6.3). In general, this model assumes that a single set of 895 transactions between the client and server will assign or extend the 896 client's non-temporary addresses and delegated prefixes. 898 6.5. DHCP for Temporary Addresses 900 Temporary addresses were originally introduced to avoid privacy 901 concerns with stateless address autoconfiguration, which based 902 64-bits of the address on the EUI-64 (see [RFC3041] and [RFC4941]). 903 They were added to DHCP to provide complementary support when 904 stateful address assignment is used. 906 Temporary address assignment works mostly like non-temporary address 907 assignment (see Section 6.2), however these addresses are generally 908 intended to be used for a short period of time and not to have their 909 lifetimes extended, though they can be if required. 911 6.6. Multiple Addresses and Prefixes 913 The protocol allows a client to receive multiple addresses. During 914 typical operation, a client sends one instance of an IA_NA option and 915 the server assigns at most one address from each prefix assigned to 916 the link the client is attached to. In particular, the server can be 917 configured to serve addresses out of multiple prefixes for a given 918 link. This is useful in cases such as when a network renumbering 919 event is in progress. In a typical deployment the server will grant 920 one address per each IA_NA option. 922 A client can explicitly request multiple addresses by sending 923 multiple IA_NA (and/or IA_TA) options. A client can send multiple 924 IA_NA (and/or IA_TA) options in its initial transmissions. 925 Alternatively, it can send an extra Request message with additional 926 new IA_NA (and/or IA_TA) options (or include them in a Renew 927 message). 929 The same principle also applies to Prefix Delegation. In principle 930 the protocol allows a client to request new prefixes to be delegated 931 by sending additional IA_PD options. However, a typical operator 932 usually prefers to delegate a single, larger prefix. In most 933 deployments it recommended for the client to request larger prefix in 934 its initial transmissions rather than request additional prefixes 935 later on. 937 The exact behavior of the server (whether to grant additional 938 addresses and prefixes or not) is up to the server policy and is 939 outside of scope of this document. 941 For more information on how the server distinguishes between IA 942 option instances, see Section 12. 944 7. DHCP Constants 946 This section describes various program and networking constants used 947 by DHCP. 949 7.1. Multicast Addresses 951 DHCP makes use of the following multicast addresses: 953 All_DHCP_Relay_Agents_and_Servers (ff02::1:2) A link-scoped 954 multicast address used by a client to communicate 955 with neighboring (i.e., on-link) relay agents and 956 servers. All servers and relay agents are members of 957 this multicast group. 959 All_DHCP_Servers (ff05::1:3) A site-scoped multicast address used by 960 a relay agent to communicate with servers, either 961 because the relay agent wants to send messages to all 962 servers or because it does not know the unicast 963 addresses of the servers. Note that in order for a 964 relay agent to use this address, it must have an 965 address of sufficient scope to be reachable by the 966 servers. All servers within the site are members of 967 this multicast group on the interfaces which are 968 within the site. 970 7.2. UDP Ports 972 Clients listen for DHCP messages on UDP port 546. Servers and relay 973 agents listen for DHCP messages on UDP port 547. 975 7.3. DHCP Message Types 977 DHCP defines the following message types. More detail on these 978 message types can be found in Section 8 and Section 9. Additional 979 message types have been defined and may be defined in the future - 980 see https://www.iana.org/assignments/dhcpv6-parameters/ 981 dhcpv6-parameters.xhtml. The numeric encoding for each message type 982 is shown in parentheses. 984 SOLICIT (1) A client sends a Solicit message to locate servers. 986 ADVERTISE (2) A server sends an Advertise message to indicate that 987 it is available for DHCP service, in response to a 988 Solicit message received from a client. 990 REQUEST (3) A client sends a Request message to request 991 configuration parameters, including addresses and/or 992 delegated prefixes, from a specific server. 994 CONFIRM (4) A client sends a Confirm message to any available 995 server to determine whether the addresses it was 996 assigned are still appropriate to the link to which 997 the client is connected. 999 RENEW (5) A client sends a Renew message to the server that 1000 originally provided the client's leases and 1001 configuration parameters to extend the lifetimes on 1002 the leases assigned to the client and to update other 1003 configuration parameters. 1005 REBIND (6) A client sends a Rebind message to any available 1006 server to extend the lifetimes on the leases assigned 1007 to the client and to update other configuration 1008 parameters; this message is sent after a client 1009 receives no response to a Renew message. 1011 REPLY (7) A server sends a Reply message containing assigned 1012 leases and configuration parameters in response to a 1013 Solicit, Request, Renew, Rebind message received from 1014 a client. A server sends a Reply message containing 1015 configuration parameters in response to an 1016 Information-request message. A server sends a Reply 1017 message in response to a Confirm message confirming 1018 or denying that the addresses assigned to the client 1019 are appropriate to the link to which the client is 1020 connected. A server sends a Reply message to 1021 acknowledge receipt of a Release or Decline message. 1023 RELEASE (8) A client sends a Release message to the server that 1024 assigned leases to the client to indicate that the 1025 client will no longer use one or more of the assigned 1026 leases. 1028 DECLINE (9) A client sends a Decline message to a server to 1029 indicate that the client has determined that one or 1030 more addresses assigned by the server are already in 1031 use on the link to which the client is connected. 1033 RECONFIGURE (10) A server sends a Reconfigure message to a client to 1034 inform the client that the server has new or updated 1035 configuration parameters, and that the client is to 1036 initiate a Renew/Reply or Information-request/Reply 1037 transaction with the server in order to receive the 1038 updated information. 1040 INFORMATION-REQUEST (11) A client sends an Information-request 1041 message to a server to request configuration 1042 parameters without the assignment of any leases to 1043 the client. 1045 RELAY-FORW (12) A relay agent sends a Relay-forward message to relay 1046 messages to servers, either directly or through 1047 another relay agent. The received message, either a 1048 client message or a Relay-forward message from 1049 another relay agent, is encapsulated in an option in 1050 the Relay-forward message. 1052 RELAY-REPL (13) A server sends a Relay-reply message to a relay agent 1053 containing a message that the relay agent delivers to 1054 a client. The Relay-reply message may be relayed by 1055 other relay agents for delivery to the destination 1056 relay agent. 1058 The server encapsulates the client message as an 1059 option in the Relay-reply message, which the relay 1060 agent extracts and relays to the client. 1062 7.4. DHCP Option Codes 1064 DHCP makes extensive use of options in messages and some of these are 1065 defined later in Section 21. Additional options are defined in other 1066 documents or may be defined in the future. 1068 7.5. Status Codes 1070 DHCP uses status codes to communicate the success or failure of 1071 operations requested in messages from clients and servers, and to 1072 provide additional information about the specific cause of the 1073 failure of a message. The specific status codes are defined in 1074 Section 21.13. 1076 If the Status Code option does not appear in a message in which the 1077 option could appear, the status of the message is assumed to be 1078 Success. 1080 7.6. Transmission and Retransmission Parameters 1082 This section presents a table of values used to describe the message 1083 transmission behavior of clients and servers. 1085 +-----------------+------------------+------------------------------+ 1086 | Parameter | Default | Description | 1087 +-----------------+------------------+------------------------------+ 1088 | SOL_MAX_DELAY | 1 sec | Max delay of first Solicit | 1089 | SOL_TIMEOUT | 1 sec | Initial Solicit timeout | 1090 | SOL_MAX_RT | 3600 secs | Max Solicit timeout value | 1091 | REQ_TIMEOUT | 1 sec | Initial Request timeout | 1092 | REQ_MAX_RT | 30 secs | Max Request timeout value | 1093 | REQ_MAX_RC | 10 | Max Request retry attempts | 1094 | CNF_MAX_DELAY | 1 sec | Max delay of first Confirm | 1095 | CNF_TIMEOUT | 1 sec | Initial Confirm timeout | 1096 | CNF_MAX_RT | 4 secs | Max Confirm timeout | 1097 | CNF_MAX_RD | 10 secs | Max Confirm duration | 1098 | REN_TIMEOUT | 10 secs | Initial Renew timeout | 1099 | REN_MAX_RT | 600 secs | Max Renew timeout value | 1100 | REB_TIMEOUT | 10 secs | Initial Rebind timeout | 1101 | REB_MAX_RT | 600 secs | Max Rebind timeout value | 1102 | INF_MAX_DELAY | 1 sec | Max delay of first | 1103 | | | Information-request | 1104 | INF_TIMEOUT | 1 sec | Initial Information-request | 1105 | | | timeout | 1106 | INF_MAX_RT | 3600 secs | Max Information-request | 1107 | | | timeout value | 1108 | REL_TIMEOUT | 1 sec | Initial Release timeout | 1109 | REL_MAX_RC | 4 | MAX Release retry attempts | 1110 | DEC_TIMEOUT | 1 sec | Initial Decline timeout | 1111 | DEC_MAX_RC | 4 | Max Decline retry attempts | 1112 | REC_TIMEOUT | 2 secs | Initial Reconfigure timeout | 1113 | REC_MAX_RC | 8 | Max Reconfigure attempts | 1114 | HOP_COUNT_LIMIT | 32 | Max hop count in a Relay- | 1115 | | | forward message | 1116 | IRT_DEFAULT | 86400 secs (24 | Default information refresh | 1117 | | hours) | time | 1118 | IRT_MINIMUM | 600 secs | Min information refresh time | 1119 +-----------------+------------------+------------------------------+ 1121 7.7. Representation of Time Values and "Infinity" as a Time Value 1123 All time values for lifetimes, T1 and T2 are unsigned 32-bit 1124 integers. The value 0xffffffff is taken to mean "infinity" when used 1125 as a lifetime (as in [RFC4861]) or a value for T1 or T2. 1127 Setting the valid lifetime of an address or a delegated prefix to 1128 0xffffffff ("infinity") amounts to a permanent address or delegation 1129 of the prefix to a client and should only be used in cases were 1130 permanent assignments are desired. 1132 Care should be taken in setting T1 or T2 to 0xffffffff ("infinity"). 1133 A client will never attempt to extend the lifetimes of any addresses 1134 in an IA with T1 set to 0xffffffff. A client will never attempt to 1135 use a Rebind message to locate a different server to extend the 1136 lifetimes of any addresses in an IA with T2 set to 0xffffffff. 1138 8. Client/Server Message Formats 1140 All DHCP messages sent between clients and servers share an identical 1141 fixed format header and a variable format area for options. 1143 All values in the message header and in options are in network byte 1144 order. 1146 Options are stored serially in the options field, with no padding 1147 between the options. Options are byte-aligned but are not aligned in 1148 any other way such as on 2 or 4 byte boundaries. 1150 The following diagram illustrates the format of DHCP messages sent 1151 between clients and servers: 1153 0 1 2 3 1154 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 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | msg-type | transaction-id | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | | 1159 . options . 1160 . (variable) . 1161 | | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 Figure 2: Client/Server message format 1166 msg-type Identifies the DHCP message type; the 1167 available message types are listed in 1168 Section 7.3. A one octet long field. 1170 transaction-id The transaction ID for this message exchange. 1171 A three octets long field. 1173 options Options carried in this message; options are 1174 described in Section 21. A variable length 1175 field (4 octets less than the size of the 1176 message). 1178 9. Relay Agent/Server Message Formats 1180 Relay agents exchange messages with other relay agents and servers to 1181 relay messages between clients and servers that are not connected to 1182 the same link. 1184 All values in the message header and in options are in network byte 1185 order. 1187 Options are stored serially in the options field, with no padding 1188 between the options. Options are byte-aligned but are not aligned in 1189 any other way such as on 2 or 4 byte boundaries. 1191 There are two relay agent messages, which share the following format: 1193 0 1 2 3 1194 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 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | msg-type | hop-count | | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1198 | | 1199 | link-address | 1200 | | 1201 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1202 | | | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1204 | | 1205 | peer-address | 1206 | | 1207 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1208 | | | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1210 . . 1211 . options (variable number and length) .... . 1212 | | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 Figure 3: Relay Agent/Server message format 1217 The following sections describe the use of the Relay Agent message 1218 header. 1220 9.1. Relay-forward Message 1222 The following table defines the use of message fields in a Relay- 1223 forward message. 1225 msg-type RELAY-FORW (12). A one octet long field. 1227 hop-count Number of relay agents that have already 1228 relayed this message. A one octet long 1229 field. 1231 link-address An address that may be used by the server to 1232 identify the link on which the client is 1233 located. This is typically a globally unique 1234 address (including unique local address, 1235 [RFC4193]), but see discussion in 1236 Section 19.1.1. A 16 octets long field 1238 peer-address The address of the client or relay agent from 1239 which the message to be relayed was received. 1240 A 16 octets long field. 1242 options MUST include a "Relay Message option" (see 1243 Section 21.10); MAY include other options 1244 added by the relay agent. A variable length 1245 field (34 octets less than the size of the 1246 message). 1248 See Section 13.1 for an explanation how link-address is used. 1250 9.2. Relay-reply Message 1252 The following table defines the use of message fields in a Relay- 1253 reply message. 1255 msg-type RELAY-REPL (13). A one octet long field. 1257 hop-count Copied from the Relay-forward message. A one 1258 octet long field. 1260 link-address Copied from the Relay-forward message. A 16 1261 octets long field. 1263 peer-address Copied from the Relay-forward message. A 16 1264 octets long field. 1266 options MUST include a "Relay Message option"; see 1267 Section 21.10; MAY include other options. A 1268 variable length field (34 octets less than 1269 the size of the message). 1271 10. Representation and Use of Domain Names 1273 So that domain names may be encoded uniformly, a domain name or a 1274 list of domain names is encoded using the technique described in 1275 section 3.1 of [RFC1035]. A domain name, or list of domain names, in 1276 DHCP MUST NOT be stored in compressed form, as described in section 1277 4.1.4 of [RFC1035]. 1279 11. DHCP Unique Identifier (DUID) 1281 Each DHCP client and server has a DUID. DHCP servers use DUIDs to 1282 identify clients for the selection of configuration parameters and in 1283 the association of IAs with clients. DHCP clients use DUIDs to 1284 identify a server in messages where a server needs to be identified. 1285 See Section 21.2 and Section 21.3 for the representation of a DUID in 1286 a DHCP message. 1288 Clients and servers MUST treat DUIDs as opaque values and MUST only 1289 compare DUIDs for equality. Clients and servers SHOULD NOT in any 1290 other way interpret DUIDs. Clients and servers MUST NOT restrict 1291 DUIDs to the types defined in this document, as additional DUID types 1292 may be defined in the future. It should be noted that an attempt to 1293 parse a DUID to obtain a client's link-layer address is unreliable as 1294 there is no guarantee that the client is still using the same link- 1295 layer address as when it generated its DUID. And, such an attempt 1296 will be more and more unreliable as more clients adopt privacy 1297 measures, such as those defined in [RFC7844]. It is recommended to 1298 rely on the mechanism defined in [RFC6939]. 1300 The DUID is carried in an option because it may be variable in length 1301 and because it is not required in all DHCP messages. The DUID is 1302 designed to be unique across all DHCP clients and servers, and stable 1303 for any specific client or server - that is, the DUID used by a 1304 client or server SHOULD NOT change over time if at all possible; for 1305 example, a device's DUID should not change as a result of a change in 1306 the device's network hardware. The stability of the DUID includes 1307 changes to virtual interfaces, such as logical PPP (over Ethernet) 1308 interfaces that may come and go in Customer Premise Equipment 1309 routers. The client may change its DUID as specified in [RFC7844]. 1311 The motivation for having more than one type of DUID is that the DUID 1312 must be globally unique, and must also be easy to generate. The sort 1313 of globally-unique identifier that is easy to generate for any given 1314 device can differ quite widely. Also, some devices may not contain 1315 any persistent storage. Retaining a generated DUID in such a device 1316 is not possible, so the DUID scheme must accommodate such devices. 1318 11.1. DUID Contents 1320 A DUID consists of a two octets type code represented in network byte 1321 order, followed by a variable number of octets that make up the 1322 actual identifier. The length of the DUID (not including the type 1323 code) is at least 1 octet and at most 128 octets. The following 1324 types are currently defined: 1326 +------+------------------------------------------------------+ 1327 | Type | Description | 1328 +------+------------------------------------------------------+ 1329 | 1 | Link-layer address plus time | 1330 | 2 | Vendor-assigned unique ID based on Enterprise Number | 1331 | 3 | Link-layer address | 1332 | 4 | Universally Unique IDentifier (UUID) - see [RFC6355] | 1333 +------+------------------------------------------------------+ 1335 Formats for the variable field of the DUID for the first three of the 1336 above types are shown below. The fourth type, DUID-UUID [RFC6355], 1337 can be used in situations where there is a UUID stored in a device's 1338 firmware settings. 1340 11.2. DUID Based on Link-layer Address Plus Time, DUID-LLT 1342 This type of DUID consists of a two octets type field containing the 1343 value 1, a two octets hardware type code, four octets containing a 1344 time value, followed by link-layer address of any one network 1345 interface that is connected to the DHCP device at the time that the 1346 DUID is generated. The time value is the time that the DUID is 1347 generated represented in seconds since midnight (UTC), January 1, 1348 2000, modulo 2^32. The hardware type MUST be a valid hardware type 1349 assigned by the IANA as described in [RFC0826]. Both the time and 1350 the hardware type are stored in network byte order. The link-layer 1351 address is stored in canonical form, as described in [RFC2464]. 1353 The following diagram illustrates the format of a DUID-LLT: 1355 0 1 2 3 1356 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 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | DUID-Type (1) | hardware type (16 bits) | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | time (32 bits) | 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 . . 1363 . link-layer address (variable length) . 1364 . . 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 Figure 4: DUID-LLT format 1369 The choice of network interface can be completely arbitrary, as long 1370 as that interface provides a globally unique link-layer address for 1371 the link type, and the same DUID-LLT SHOULD be used in configuring 1372 all network interfaces connected to the device, regardless of which 1373 interface's link-layer address was used to generate the DUID-LLT. 1375 Clients and servers using this type of DUID MUST store the DUID-LLT 1376 in stable storage, and MUST continue to use this DUID-LLT even if the 1377 network interface used to generate the DUID-LLT is removed. Clients 1378 and servers that do not have any stable storage MUST NOT use this 1379 type of DUID. 1381 Clients and servers that use this DUID SHOULD attempt to configure 1382 the time prior to generating the DUID, if that is possible, and MUST 1383 use some sort of time source (for example, a real-time clock) in 1384 generating the DUID, even if that time source could not be configured 1385 prior to generating the DUID. The use of a time source makes it 1386 unlikely that two identical DUID-LLTs will be generated if the 1387 network interface is removed from the client and another client then 1388 uses the same network interface to generate a DUID-LLT. A collision 1389 between two DUID-LLTs is very unlikely even if the clocks have not 1390 been configured prior to generating the DUID. 1392 This method of DUID generation is recommended for all general purpose 1393 computing devices such as desktop computers and laptop computers, and 1394 also for devices such as printers, routers, and so on, that contain 1395 some form of writable non-volatile storage. 1397 It is possible that this algorithm for generating a DUID could result 1398 in a client identifier collision. A DHCP client that generates a 1399 DUID-LLT using this mechanism MUST provide an administrative 1400 interface that replaces the existing DUID with a newly-generated 1401 DUID-LLT. 1403 11.3. DUID Assigned by Vendor Based on Enterprise Number, DUID-EN 1405 This form of DUID is assigned by the vendor to the device. It 1406 consists of the four octet vendor's registered Private Enterprise 1407 Number as maintained by IANA [IANA-PEN] followed by a unique 1408 identifier assigned by the vendor. The following diagram summarizes 1409 the structure of a DUID-EN: 1411 0 1 2 3 1412 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 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 | DUID-Type (2) | enterprise-number | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | enterprise-number (contd) | | 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1418 . identifier . 1419 . (variable length) . 1420 . . 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 Figure 5: DUID-EN format 1425 The source of the identifier is left up to the vendor defining it, 1426 but each identifier part of each DUID-EN MUST be unique to the device 1427 that is using it, and MUST be assigned to the device no later than at 1428 the first usage and stored in some form of non-volatile storage. 1429 This typically means being assigned during manufacture process in 1430 case of physical devices or when the image is created or booted for 1431 the first time in case of virtual machines. The generated DUID 1432 SHOULD be recorded in non-erasable storage. The enterprise-number is 1433 the vendor's registered Private Enterprise Number as maintained by 1434 IANA [IANA-PEN]. The enterprise-number is stored as an unsigned 32 1435 bit number. 1437 An example DUID of this type might look like this: 1439 +---+---+---+---+---+---+---+---+ 1440 | 0 | 2 | 0 | 0 | 0 | 9| 12|192| 1441 +---+---+---+---+---+---+---+---+ 1442 |132|211| 3 | 0 | 9 | 18| 1443 +---+---+---+---+---+---+ 1445 Figure 6: DUID-EN example 1447 This example includes the two octets type of 2, the Enterprise Number 1448 (9), followed by eight octets of identifier data 1449 (0x0CC084D303000912). 1451 11.4. DUID Based on Link-layer Address, DUID-LL 1453 This type of DUID consists of two octets containing the DUID type 3, 1454 a two octets network hardware type code, followed by the link-layer 1455 address of any one network interface that is permanently connected to 1456 the client or server device. For example, a node that has a network 1457 interface implemented in a chip that is unlikely to be removed and 1458 used elsewhere could use a DUID-LL. The hardware type MUST be a 1459 valid hardware type assigned by the IANA, as described in [RFC0826]. 1460 The hardware type is stored in network byte order. The link-layer 1461 address is stored in canonical form, as described in [RFC2464]. The 1462 following diagram illustrates the format of a DUID-LL: 1464 0 1 2 3 1465 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 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | DUID-Type (3) | hardware type (16 bits) | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 . . 1470 . link-layer address (variable length) . 1471 . . 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 Figure 7: DUID-LL format 1476 The choice of network interface can be completely arbitrary, as long 1477 as that interface provides a unique link-layer address and is 1478 permanently attached to the device on which the DUID-LL is being 1479 generated. The same DUID-LL SHOULD be used in configuring all 1480 network interfaces connected to the device, regardless of which 1481 interface's link-layer address was used to generate the DUID. 1483 DUID-LL is recommended for devices that have a permanently-connected 1484 network interface with a link-layer address, and do not have 1485 nonvolatile, writable stable storage. DUID-LL SHOULD NOT be used by 1486 DHCP clients or servers that cannot tell whether or not a network 1487 interface is permanently attached to the device on which the DHCP 1488 client is running. 1490 11.5. DUID Based on Universally Unique IDentifier (UUID), DUID-UUID 1492 This type of DUID consists of 16 octets containing a 128-bit UUID. 1493 [RFC6355] details when to use this type, and how to pick an 1494 appropriate source of the UUID. 1496 0 1 2 3 1497 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 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | DUID-Type (4) | UUID (128 bits) | 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1501 | | 1502 | | 1503 | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 | | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1507 Figure 8: DUID-UUID format 1509 12. Identity Association 1511 An "identity-association" (IA) is a construct through which a server 1512 and a client can identify, group, and manage a set of related IPv6 1513 addresses or delegated prefixes. Each IA consists of an IAID and 1514 associated configuration information. 1516 The IAID uniquely identifies the IA and MUST be chosen to be unique 1517 among the IAIDs for that IA type on the client (i.e., IA_NA with IAID 1518 0 is unique from IA_TA with IAID 0). The IAID is chosen by the 1519 client. For any given use of an IA by the client, the IAID for that 1520 IA MUST be consistent across restarts of the DHCP client. The client 1521 may maintain consistency either by storing the IAID in non-volatile 1522 storage or by using an algorithm that will consistently produce the 1523 same IAID as long as the configuration of the client has not changed. 1524 There may be no way for a client to maintain consistency of the IAIDs 1525 if it does not have non-volatile storage and the client's hardware 1526 configuration changes. If the client uses only one IAID, it can use 1527 a well-known value, e.g., zero. 1529 If the client wishes to obtain a distinctly new address or prefix and 1530 deprecate the existing one, the client sends a Release message to the 1531 server for the IAs using the original IAID. Then the client creates 1532 a new IAID, to be used in future messages to obtain leases for the 1533 new IA. 1535 12.1. Identity Associations for Address Assignment 1537 A client must associate at least one distinct IA with each of its 1538 network interfaces for which it is to request the assignment of IPv6 1539 addresses from a DHCP server. The client uses the IAs assigned to an 1540 interface to obtain configuration information from a server for that 1541 interface. Each IA must be associated with exactly one interface. 1543 The configuration information in an IA_NA consists of one or more 1544 IPv6 addresses along with the T1 and T2 times for the IA. See 1545 Section 21.4 for the representation of an IA_NA in a DHCP message. 1547 The configuration information in an IA_TA consists of one or more 1548 IPv6 addresses. See Section 21.5 for the representation of an IA_TA 1549 in a DHCP message. 1551 Each address in an IA has a preferred lifetime and a valid lifetime, 1552 as defined in [RFC4862]. The lifetimes are transmitted from the DHCP 1553 server to the client in the IA Address option. The lifetimes apply 1554 to the use of addresses, as described in section 5.5.4 of [RFC4862]. 1556 12.2. Identity Associations for Prefix Delegation 1558 An IA_PD is different from an IA for address assignment, in that it 1559 does not need to be associated with exactly one interface. One IA_PD 1560 can be associated with the client, with a set of interfaces or with 1561 exactly one interface. A client must create at least one distinct 1562 IA_PD. It may associate a distinct IA_PD with each of its downstream 1563 network interfaces and use that IA_PD to obtain a prefix for that 1564 interface from the server. 1566 The configuration information in an IA_PD consists of one or more 1567 prefixes along with the T1 and T2 times for the IA_PD. See 1568 Section 21.21 for the representation of an IA_PD in a DHCP message. 1570 Each delegated prefix in an IA has a preferred lifetime and a valid 1571 lifetime, as defined in [RFC4862]. The lifetimes are transmitted 1572 from the DHCP server to the client in the IA Prefix option. The 1573 lifetimes apply to the use of delegated prefixes, as described in 1574 section 5.5.4 of [RFC4862]. 1576 13. Assignment to an IA 1578 13.1. Selecting Addresses for Assignment to an IA_NA 1580 A server selects addresses to be assigned to an IA_NA according to 1581 the address assignment policies determined by the server 1582 administrator and the specific information the server determines 1583 about the client from some combination of the following sources: 1585 - The link to which the client is attached. The server determines 1586 the link as follows: 1588 * If the server receives the message directly from the client and 1589 the source address in the IP datagram in which the message was 1590 received is a link-local address, then the client is on the 1591 same link to which the interface over which the message was 1592 received is attached. 1594 * If the server receives the message from a forwarding relay 1595 agent, then the client is on the same link as the one to which 1596 the interface, identified by the link-address field in the 1597 message from the relay agent, is attached. According to 1598 [RFC6221], the server MUST ignore any link-address field whose 1599 value is zero. The link-address in this case may come from any 1600 of the Relay-forward messages encapsulated in the received 1601 Relay-forward, and in general the most encapsulated (closest 1602 Relay-forward to the client) has the most useful value. 1604 * If the server receives the message directly from the client and 1605 the source address in the IP datagram in which the message was 1606 received is not a link-local address, then the client is on the 1607 link identified by the source address in the IP datagram (note 1608 that this situation can occur only if the server has enabled 1609 the use of unicast message delivery by the client and the 1610 client has sent a message for which unicast delivery is 1611 allowed). 1613 - The DUID supplied by the client. 1615 - Other information in options supplied by the client, e.g., IA 1616 Address options that include the client's requests for specific 1617 addresses. 1619 - Other information in options supplied by the relay agent. 1621 By default, DHCP server implementations SHOULD NOT generate 1622 predictable addresses [RFC7721]. Server implementers are encouraged 1623 to review [RFC4941], [RFC7824], and [RFC7707] as to possible 1624 considerations for how to generate addresses. 1626 A server MUST NOT assign an address that is otherwise reserved for 1627 some other purpose. For example, a server MUST NOT assign addresses 1628 that use a reserved IPv6 Interface Identifier ([RFC5453], [RFC7136], 1629 [IANA-RESERVED-IID]). 1631 See [RFC7969] for a more detailed discussion on how servers determine 1632 a client's location on the network. 1634 13.2. Assignment of Temporary Addresses 1636 A client may request the assignment of temporary addresses (see 1637 [RFC4941] for the definition of temporary addresses). DHCP handling 1638 of address assignment is no different for temporary addresses. 1640 Clients ask for temporary addresses and servers assign them. 1641 Temporary addresses are carried in the Identity Association for 1642 Temporary Addresses (IA_TA) option (see Section 21.5). Each IA_TA 1643 option contains at lease one temporary address for each of the 1644 prefixes on the link to which the client is attached. 1646 The lifetime of the assigned temporary address is set in the IA 1647 Address option (see Section 21.6) encapsulated in the IA_TA option. 1648 It is RECOMMENDED to set short lifetimes, typically shorter than 1649 TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME (see Section 5, 1650 [RFC4941]). 1652 A DHCP server implementation MAY generate temporary addresses 1653 referring to the algorithm defined in Section 3.2.1, [RFC4941], with 1654 the additional condition that any new address is not the same as any 1655 assigned address. 1657 The server MAY update the DNS for a temporary address, as described 1658 in section 4 of [RFC4941]. 1660 On the clients, by default, temporary addresses are preferred in 1661 source address selection, according to Rule 7, [RFC6724]. However, 1662 this policy is overridable. 1664 One of the most important properties of a temporary address is to 1665 make it difficult to link the address to different actions over time. 1666 So, it is NOT RECOMMENDED for a client to renew temporary addresses, 1667 though DHCP provides for such a possibility (see Section 21.5). 1669 13.3. Assignment of Prefixes for IA_PD 1671 The mechanism through which the server selects prefix(es) for 1672 delegation is not specified in this document. Examples of ways in 1673 which the server might select prefix(es) for a client include: static 1674 assignment based on subscription to an ISP; dynamic assignment from a 1675 pool of available prefixes; selection based on an external authority 1676 such as a RADIUS server using the Framed-IPv6-Prefix option as 1677 described in [RFC3162]. 1679 14. Transmission of Messages by a Client 1681 Unless otherwise specified in this document, or in a document that 1682 describes how IPv6 is carried over a specific type of link (for link 1683 types that do not support multicast), a client sends DHCP messages to 1684 the All_DHCP_Relay_Agents_and_Servers multicast address. 1686 DHCP servers SHOULD NOT care if the layer-2 address used was 1687 multicast or not, as long as the layer-3 address was correct. 1689 A client uses multicast to reach all servers or an individual server. 1690 An individual server is indicated by specifying that server's DUID in 1691 a Server Identifier option (see Section 21.3) in the client's message 1692 (all servers will receive this message but only the indicated server 1693 will respond). All servers are indicated by not supplying this 1694 option. 1696 A client may send some messages directly to a server using unicast, 1697 as described in Section 21.12. 1699 14.1. Rate Limiting 1701 In order to avoid prolonged message bursts that may be caused by 1702 possible logic loops, a DHCP client MUST limit the rate of DHCP 1703 messages it transmits. One example is that a client obtains an 1704 address or delegated prefix, but does not like the response; so it 1705 reverts back to Solicit procedure, discovers the same (sole) server, 1706 requests an address or delegated prefix and gets the same address or 1707 delegated prefix as before (as the server has this previously 1708 requested lease assigned to this client). This loop can repeat 1709 infinitely if there is not a quit/stop mechanism. Therefore, a 1710 client must not initiate transmissions too frequently. 1712 A recommended method for implementing the rate limiting function is a 1713 token bucket, limiting the average rate of transmission to a certain 1714 number in a certain time interval. This method of bounding 1715 burstiness also guarantees that the long-term transmission rate will 1716 not be exceeded. 1718 TRT Transmission Rate Limit 1720 The Transmission Rate Limit parameter (TRT) SHOULD be configurable. 1721 A possible default could be 20 packets in 20 seconds. 1723 For a device that has multiple interfaces, the limit MUST be enforced 1724 on a per interface basis. 1726 Rate limiting of forwarded DHCP messages and server-side messages are 1727 out of scope of this specification. 1729 14.2. Client Behavior when T1 and/or T2 are 0 1731 In certain cases, T1 and/or T2 time may be set to zero. Currently 1732 there are three such cases: 1734 1. a client received an IA_NA option with a zero value 1736 2. a client received an IA_PD option with a zero value 1738 3. a client received an IA_TA option (which does not contain T1 1739 and T2 fields and are not generally renewed) 1741 This is an indication that the renew and rebind times are left at the 1742 client's discretion. However, they are not completely discretionary. 1744 When T1 and/or T2 times are set to zero, the client MUST choose a 1745 time to avoid packet storms. In particular, it MUST NOT transmit 1746 immediately. If the client received multiple IA containers, it 1747 SHOULD pick renew and/or rebind transmission times so all IA 1748 containers are handled in one exchange, if possible. The client MUST 1749 choose renew and rebind times to not violate rate limiting 1750 restrictions, defined in Section 14.1. 1752 15. Reliability of Client Initiated Message Exchanges 1754 DHCP clients are responsible for reliable delivery of messages in the 1755 client-initiated message exchanges described in Section 18. If a 1756 DHCP client fails to receive an expected response from a server, the 1757 client must retransmit its message according to the retransmission 1758 strategy described in this section. 1760 Note that the procedure described in this section is slightly 1761 modified when used with the Solicit message. The modified procedure 1762 is described in Section 18.2.1. 1764 The client begins the message exchange by transmitting a message to 1765 the server. The message exchange terminates when either the client 1766 successfully receives the appropriate response or responses from a 1767 server or servers, or when the message exchange is considered to have 1768 failed according to the retransmission mechanism described below. 1770 The client MUST update an "elapsed-time" value within an Elapsed Time 1771 option (see Section 21.9) in the retransmitted message. In some 1772 cases, the client may also need to modify values in the IA Address or 1773 IA Prefix options if a valid lifetime for any of the client's leases 1774 expires before retransmission. Thus, whenever this document refers 1775 to a "retransmission" of a client's message, it refers to both 1776 modifying the original message and sending this new message instance 1777 to the server. 1779 The client retransmission behavior is controlled and described by the 1780 following variables: 1782 RT Retransmission timeout 1784 IRT Initial retransmission time 1786 MRC Maximum retransmission count 1788 MRT Maximum retransmission time 1790 MRD Maximum retransmission duration 1792 RAND Randomization factor 1794 With each message transmission or retransmission, the client sets RT 1795 according to the rules given below. If RT expires before the message 1796 exchange terminates, the client recomputes RT and retransmits the 1797 message. 1799 Each of the computations of a new RT include a randomization factor 1800 (RAND), which is a random number chosen with a uniform distribution 1801 between -0.1 and +0.1. The randomization factor is included to 1802 minimize synchronization of messages transmitted by DHCP clients. 1804 The algorithm for choosing a random number does not need to be 1805 cryptographically sound. The algorithm SHOULD produce a different 1806 sequence of random numbers from each invocation of the DHCP client. 1808 RT for the first message transmission is based on IRT: 1810 RT = IRT + RAND*IRT 1812 RT for each subsequent message transmission is based on the previous 1813 value of RT: 1815 RT = 2*RTprev + RAND*RTprev 1817 MRT specifies an upper bound on the value of RT (disregarding the 1818 randomization added by the use of RAND). If MRT has a value of 0, 1819 there is no upper limit on the value of RT. Otherwise: 1821 if (RT > MRT) 1822 RT = MRT + RAND*MRT 1824 MRC specifies an upper bound on the number of times a client may 1825 retransmit a message. Unless MRC is zero, the message exchange fails 1826 once the client has transmitted the message MRC times. 1828 MRD specifies an upper bound on the length of time a client may 1829 retransmit a message. Unless MRD is zero, the message exchange fails 1830 once MRD seconds have elapsed since the client first transmitted the 1831 message. 1833 If both MRC and MRD are non-zero, the message exchange fails whenever 1834 either of the conditions specified in the previous two paragraphs are 1835 met. 1837 If both MRC and MRD are zero, the client continues to transmit the 1838 message until it receives a response. 1840 A client is not expected to listen for a response during the entire 1841 RT period and may turn off listening capabilities after a certain 1842 time due to power consumption saving or other reasons. Of course, a 1843 client MUST listen for a Reconfigure if it has negotiated for its use 1844 with the server. 1846 16. Message Validation 1848 This section describes which options are valid in which kinds of 1849 message types. Should a client or server receive messages which 1850 contain known options which are invalid for the message, this section 1851 explains how to process it. For example, an IA option is not allowed 1852 to appear in an Information-request message. 1854 Clients and servers MAY choose either to extract information from 1855 such a message if the information is of use to the recipient, or to 1856 ignore such message completely and just discard it. 1858 If a server receives a message that it considers invalid, it MAY send 1859 a Reply (or Advertise as appropriate) with a Server Identifier 1860 option, a Client Identifier option if one was included in the message 1861 and a Status Code option with status UnspecFail. 1863 Clients, relay agents and servers MUST NOT discard messages that 1864 contain unknown options (or instances of vendor options with unknown 1865 enterprise-numbers). These should be ignored as if they were not 1866 present. This is critical to provide for later extension of the DHCP 1867 protocol. 1869 A server MUST discard any Solicit, Confirm, Rebind or Information- 1870 request messages it receives with a layer-3 unicast destination 1871 address. 1873 A client or server MUST discard any received DHCP messages with an 1874 unknown message type. 1876 16.1. Use of Transaction IDs 1878 The "transaction-id" field holds a value used by clients and servers 1879 to synchronize server responses to client messages. A client SHOULD 1880 generate a random number that cannot easily be guessed or predicted 1881 to use as the transaction ID for each new message it sends. Note 1882 that if a client generates easily predictable transaction 1883 identifiers, it may become more vulnerable to certain kinds of 1884 attacks from off-path intruders. A client MUST leave the transaction 1885 ID unchanged in retransmissions of a message. 1887 16.2. Solicit Message 1889 Clients MUST discard any received Solicit messages. 1891 Servers MUST discard any Solicit messages that do not include a 1892 Client Identifier option or that do include a Server Identifier 1893 option. 1895 16.3. Advertise Message 1897 Clients MUST discard any received Advertise message that meets any of 1898 the following conditions: 1900 - the message does not include a Server Identifier option. 1902 - the message does not include a Client Identifier option. 1904 - the contents of the Client Identifier option does not match the 1905 client's DUID. 1907 - the "transaction-id" field value does not match the value the 1908 client used in its Solicit message. 1910 Servers and relay agents MUST discard any received Advertise 1911 messages. 1913 16.4. Request Message 1915 Clients MUST discard any received Request messages. 1917 Servers MUST discard any received Request message that meets any of 1918 the following conditions: 1920 - the message does not include a Server Identifier option. 1922 - the contents of the Server Identifier option do not match the 1923 server's DUID. 1925 - the message does not include a Client Identifier option. 1927 16.5. Confirm Message 1929 Clients MUST discard any received Confirm messages. 1931 Servers MUST discard any received Confirm messages that do not 1932 include a Client Identifier option or that do include a Server 1933 Identifier option. 1935 16.6. Renew Message 1937 Clients MUST discard any received Renew messages. 1939 Servers MUST discard any received Renew message that meets any of the 1940 following conditions: 1942 - the message does not include a Server Identifier option. 1944 - the contents of the Server Identifier option does not match the 1945 server's identifier. 1947 - the message does not include a Client Identifier option. 1949 16.7. Rebind Message 1951 Clients MUST discard any received Rebind messages. 1953 Servers MUST discard any received Rebind messages that do not include 1954 a Client Identifier option or that do include a Server Identifier 1955 option. 1957 16.8. Decline Messages 1959 Clients MUST discard any received Decline messages. 1961 Servers MUST discard any received Decline message that meets any of 1962 the following conditions: 1964 - the message does not include a Server Identifier option. 1966 - the contents of the Server Identifier option does not match the 1967 server's identifier. 1969 - the message does not include a Client Identifier option. 1971 16.9. Release Message 1973 Clients MUST discard any received Release messages. 1975 Servers MUST discard any received Release message that meets any of 1976 the following conditions: 1978 - the message does not include a Server Identifier option. 1980 - the contents of the Server Identifier option does not match the 1981 server's identifier. 1983 - the message does not include a Client Identifier option. 1985 16.10. Reply Message 1987 Clients MUST discard any received Reply message that meets any of the 1988 following conditions: 1990 - the message does not include a Server Identifier option. 1992 - the "transaction-id" field in the message does not match the value 1993 used in the original message. 1995 If the client included a Client Identifier option in the original 1996 message, the Reply message MUST include a Client Identifier option 1997 and the contents of the Client Identifier option MUST match the DUID 1998 of the client; OR, if the client did not include a Client Identifier 1999 option in the original message, the Reply message MUST NOT include a 2000 Client Identifier option. 2002 Servers and relay agents MUST discard any received Reply messages. 2004 16.11. Reconfigure Message 2006 Servers and relay agents MUST discard any received Reconfigure 2007 messages. 2009 Clients MUST discard any Reconfigure message that meets any of the 2010 following conditions: 2012 - the message was not unicast to the client. 2014 - the message does not include a Server Identifier option. 2016 - the message does not include a Client Identifier option that 2017 contains the client's DUID. 2019 - the message does not include a Reconfigure Message option. 2021 - the Reconfigure Message option msg-type is not a valid value. 2023 - the message does not include authentication (such as RKAP, see 2024 Section 20.4) or fails authentication validation. 2026 16.12. Information-request Message 2028 Clients MUST discard any received Information-request messages. 2030 Servers MUST discard any received Information-request message that 2031 meets any of the following conditions: 2033 - The message includes a Server Identifier option and the DUID in 2034 the option does not match the server's DUID. 2036 - The message includes an IA option. 2038 16.13. Relay-forward Message 2040 Clients MUST discard any received Relay-forward messages. 2042 16.14. Relay-reply Message 2044 Clients and servers MUST discard any received Relay-reply messages. 2046 17. Client Source Address and Interface Selection 2048 Client's behavior regarding interface selection is different 2049 depending on the purpose of the configuration. 2051 17.1. Address, Interface Selection for Address Assignment 2053 When a client sends a DHCP message to the 2054 All_DHCP_Relay_Agents_and_Servers multicast address, it SHOULD send 2055 the message through the interface for which configuration information 2056 (including the addresses) is being requested. However, the client 2057 MAY send the message through another interface if the interface which 2058 configuration is being requested for is a logical interface without 2059 direct link attachment or the client is certain that two interfaces 2060 are attached to the same link. 2062 When a client sends a DHCP message directly to a server using unicast 2063 (after receiving the Server Unicast option from that server), the 2064 source address in the header of the IPv6 datagram MUST be an address 2065 assigned to the interface for which the client is interested in 2066 obtaining configuration and which is suitable for use by the server 2067 in responding to the client. 2069 17.2. Address, Interface Selection for Prefix Delegation 2071 Delegated prefixes are not associated with a particular interface in 2072 the same way as addresses are for address assignment, as mentioned in 2073 Section 17.1 above. 2075 When a client sends a DHCP message for the purpose of prefix 2076 delegation, it SHOULD be sent on the interface associated with the 2077 upstream router (ISP network). The upstream interface is typically 2078 determined by configuration. This rule applies even in the case 2079 where a separate IA_PD is used for each downstream interface. 2081 When a client sends a DHCP message directly to a server using unicast 2082 (after receiving the Server Unicast option from that server), the 2083 source address SHOULD be an address from the upstream interface and 2084 which is suitable for use by the server in responding to the client. 2086 18. DHCP Configuration Exchanges 2088 A client initiates a message exchange with a server or servers to 2089 acquire or update configuration information of interest. A client 2090 has many reasons to initiate the configuration exchange. Some of the 2091 more common ones are: 2093 1. as part of the operating system configuration/bootstrap 2094 process, 2096 2. when requested to do so by the application layer (through an 2097 operating system specific API), 2099 3. when Router Advertisement indicates DHCPv6 is available for 2100 address configuration (see [RFC4861] Section 4.2), 2102 4. as required to extend the lifetime of address(es) and/or 2103 delegated prefix(es), using Renew and Rebind messages, 2105 5. or when requested to do so by a server - upon the receipt of a 2106 Reconfigure message. 2108 The client is responsible for creating IAs and requesting that a 2109 server assign addresses and/or delegated prefixes to the IAs. The 2110 client first creates the IAs and assigns IAIDs to them. The client 2111 then transmits a Solicit message containing the IA options describing 2112 the IAs. The client MUST NOT be using any of the addresses or 2113 delegated prefixes for which it tries to obtain the bindings by 2114 sending the Solicit message. In particular, if the client had some 2115 valid bindings and has chosen to start the server discovery process 2116 to obtain the same bindings from a different server, the client MUST 2117 stop using the addresses and delegated prefixes for the bindings it 2118 had obtained from the previous server (see Section 18.2.7 for more 2119 details on what stop using means), and which it is now trying to 2120 obtain from a new server. 2122 A DHCP client that does not need to have a DHCP server assign it IP 2123 addresses or delegated prefixes, can obtain configuration information 2124 such as a list of available DNS servers [RFC3646] or NTP servers 2125 [RFC4075] through a single message and reply exchange with a DHCP 2126 server. To obtain configuration information the client first sends 2127 an Information-request message (see Section 18.2.6) to the 2128 All_DHCP_Relay_Agents_and_Servers multicast address. Servers respond 2129 with a Reply message containing the configuration information for the 2130 client (see Section 18.3.6). 2132 To request the assignment of one or more addresses or delegated 2133 prefixes, a client first locates a DHCP server and then requests the 2134 assignment of addresses/prefixes and other configuration information 2135 from the server. The client does this by sending the Solicit message 2136 (see Section 18.2.1) to the All_DHCP_Relay_Agents_and_Servers 2137 multicast address and collecting Advertise messages from the servers 2138 which respond to the client's message and selects a server from which 2139 it wants to obtain configuration information. This process is 2140 referred to as server discovery. When the client has selected the 2141 server it sends a Request message to this server as described in 2142 Section 18.2.2. 2144 A client willing to perform the Solicit/Reply message exchange 2145 described in Section 18.2.1 includes a Rapid Commit option (see 2146 Section 21.14) in its Solicit message. 2148 Servers that can assign addresses or delegated prefixes to the IAs 2149 respond to the client with an Advertise message or Reply message if 2150 the client included a Rapid Commit option and the server is 2151 configured to accept it. 2153 If the server responds with an Advertise message, the client 2154 initiates a configuration exchange as described in Section 18.2.2. 2156 A server may initiate a message exchange with a client by sending a 2157 Reconfigure message to cause the client to send a Renew, Rebind or 2158 Information-request message to refresh its configuration information 2159 as soon as the Reconfigure message is received by the client. 2161 Figure 9 shows a timeline diagram of the messages exchanged between a 2162 client and two servers for the typical lifecycle of one or more 2163 leases. This is a combination of the 4-message exchange (to select a 2164 server and assign the lease(s) to the client) followed by two 2165 2-message exchanges (to extend the lifetime on the lease(s) and 2166 eventually release the lease(s)). 2168 Server Server 2169 (not selected) Client (selected) 2171 v v v 2172 | | | 2173 | Begins initialization | 2174 | | | 2175 start of | _____________/|\_____________ | 2176 4-message |/ Solicit | Solicit \| 2177 exchange | | | 2178 Determines | Determines 2179 configuration | configuration 2180 | | | 2181 |\ | ____________/| 2182 | \________ | /Advertise | 2183 | Advertise\ |/ | 2184 | \ | | 2185 | Collects Advertises | 2186 | \ | | 2187 | Selects configuration | 2188 | | | 2189 | _____________/|\_____________ | 2190 |/ Request | Request \| 2191 | | | 2192 | | Commits configuration 2193 | | | 2194 end of | | _____________/| 2195 4-message | |/ Reply | 2196 exchange | | | 2197 | Initialization complete | 2198 | | | 2199 . . . 2200 . . . 2201 | T1 (Renewal) Timer Expires | 2202 | | | 2203 2-message | _____________/|\_____________ | 2204 exchange |/ Renew | Renew \| 2205 | | | 2206 | | Commits extended lease(s) 2207 | | | 2208 | | _____________/| 2209 | |/ Reply | 2210 . . . 2211 . . . 2212 | | | 2213 | Graceful shutdown | 2214 | | | 2215 2-message | _____________/|\_____________ | 2216 exchange |/ Release | Release \| 2217 | | | 2218 | | Discards lease(s) 2219 | | | 2220 | | _____________/| 2221 | |/ Reply | 2222 | | | 2223 v v v 2225 Figure 9: Timeline diagram of the messages exchanged between a client 2226 and two servers for the typical lifecycle of one or more leases 2228 18.1. A Single Exchange for Multiple IA Options 2230 The client and server use the IA_PD option to exchange information 2231 about prefix(es) in much the same way as IA_NA and IA_TA options are 2232 used for assigned addresses. Typically, a single DHCP session is 2233 used to exchange information about addresses and prefixes, i.e., 2234 IA_NA and IA_PD options are carried in the same message. 2236 Clients SHOULD use a single transaction for all of its IA options. 2237 Servers SHOULD assign the same T1/T2 values to all IA options 2238 configured for a client, so the client will generate a single 2239 transaction when renewing its leases. For a rationale of this 2240 approach, see Section 4.2 of [RFC7550]. 2242 18.2. Client Behavior 2244 A client uses the Solicit message to discover DHCP servers configured 2245 to assign leases or return other configuration parameters on the link 2246 to which the client is attached. 2248 A client uses Request, Renew, Rebind, Release and Decline messages 2249 during the normal life cycle of addresses and delegated prefixes. 2250 When a client detects it may have moved to a new link, it uses 2251 Confirm if it only has addresses and Rebind if it has delegated 2252 prefixes (and addresses). It uses Information-request messages when 2253 it needs configuration information but no addresses and no prefixes. 2255 When a client requests multiple IA option types or multiple instances 2256 of the same IA types in a Solicit, Request, Renew, or Rebind, it is 2257 possible that the available server(s) may only be configured to offer 2258 a subset of them. When possible, the client SHOULD use the best 2259 configuration available and continue to request the additional IAs in 2260 subsequent messages [RFC7550]. This allows the client to maintain a 2261 single session and state machine. In practice, especially in the 2262 case of handling IA_NA and IA_PD requests [RFC7084], this situation 2263 should be rare or a result of a temporary operational error. Thus, 2264 it is more likely for the client to get all configuration if it 2265 continues, in each subsequent configuration exchange, to request all 2266 the configuration information it is programmed to try to obtain, 2267 including any stateful configuration options for which no results 2268 were returned in previous message exchanges. 2270 Upon receipt of a Reconfigure message from the server, a client 2271 responds with a Renew, Rebind or an Information-request message as 2272 indicated by the Reconfigure Message option. The client SHOULD be 2273 suspicious of the Reconfigure message (they may be faked), and it 2274 MUST NOT abandon any resources it might have already obtained. The 2275 client SHOULD treat the Reconfigure message as if the T1 timer had 2276 expired. The client will expect the server to send IAs and/or other 2277 configuration information to the client in a Reply message. 2279 If the client has a source address of sufficient scope that can be 2280 used by the server as a return address, and the client has received a 2281 Server Unicast option Section 21.12 from the server, the client 2282 SHOULD unicast any Request, Renew, Release and Decline messages to 2283 the server. 2285 Use of unicast may avoid delays due to the relaying of messages by 2286 relay agents, as well as avoid overhead on servers due to the 2287 delivery of client messages to multiple servers. However, requiring 2288 the client to relay all DHCP messages through a relay agent enables 2289 the inclusion of relay agent options in all messages sent by the 2290 client. The server should enable the use of unicast only when relay 2291 agent options will not be used. 2293 18.2.1. Creation and Transmission of Solicit Messages 2295 The client sets the "msg-type" field to SOLICIT. The client 2296 generates a transaction ID and inserts this value in the 2297 "transaction-id" field. 2299 The client MUST include a Client Identifier option to identify itself 2300 to the server. The client includes IA options for any IAs to which 2301 it wants the server to assign leases. 2303 The client MUST include an Elapsed Time option (see Section 21.9) to 2304 indicate how long the client has been trying to complete the current 2305 DHCP message exchange. 2307 The client uses IA_NA options to request the assignment of non- 2308 temporary addresses, IA_TA options to request the assignment of 2309 temporary addresses, and IA_PD options to request prefix delegation. 2310 Either IA_NA, IA_TA or IA_PD options, or a combination of all, can be 2311 included in DHCP messages. In addition, multiple instances of any IA 2312 option type can be included. 2314 The client MAY include addresses in IA Address options encapsulated 2315 within IA_NA and IA_TA options as hints to the server about the 2316 addresses for which the client has a preference. 2318 The client MAY include values in IA Prefix options encapsulated 2319 within IA_PD options as hints for the delegated prefix and/or prefix 2320 length for which the client has a preference. See Section 18.2.4 for 2321 more on prefix length hints. 2323 The client MUST include an Option Request option (see Section 21.7) 2324 to request the SOL_MAX_RT option (see Section 21.24) and any other 2325 options the client is interested in receiving. The client MAY 2326 additionally include instances of those options that are identified 2327 in the Option Request option, with data values as hints to the server 2328 about parameter values the client would like to have returned. 2330 The client includes a Reconfigure Accept option (see Section 21.20) 2331 if the client is willing to accept Reconfigure messages from the 2332 server. 2334 The client MUST NOT include any other options in the Solicit message, 2335 except as specifically allowed in the definition of individual 2336 options. 2338 The first Solicit message from the client on the interface SHOULD be 2339 delayed by a random amount of time between 0 and SOL_MAX_DELAY. This 2340 mechanism is essential for devices that are not battery powered, as 2341 they may suffer from power failure. After recovering from a power 2342 outage, many devices may start their transmission at the same time. 2343 This is much less of a concern for battery powered devices. This 2344 random delay also helps descynronize clients which start DHCP session 2345 by seeing it available in Router Advertisement messages (see 2346 [RFC4861] Section 4.2). 2348 The client transmits the message according to Section 15, using the 2349 following parameters: 2351 IRT SOL_TIMEOUT 2353 MRT SOL_MAX_RT 2355 MRC 0 2357 MRD 0 2359 A client that wishes to use the Rapid Commit 2-message exchange 2360 includes a Rapid Commit option in its Solicit message. The client 2361 may receive a number of different replies from different servers. 2362 The client will make note of any valid Advertise messages that it 2363 receives. The client will discard any Reply messages that do not 2364 contain the Rapid Commit option. 2366 Upon receipt of a valid Reply with the Rapid Commit option, the 2367 client processes the message as described in Section 18.2.10 2369 At the end of the first RT period, if no suitable Reply messages are 2370 received, but the client has valid Advertise messages, then the 2371 client processes the Advertise as described in Section 18.2.9. 2373 If the client subsequently receives a valid Reply message that 2374 includes a Rapid Commit option, it either: 2376 - processes the Reply message as described in Section 18.2.10, and 2377 discards any Reply messages received in response to the Request 2378 message, or 2380 - processes any Reply messages received in response to the Request 2381 message and discards the Reply message that includes the Rapid 2382 Commit option. 2384 If the client is waiting for an Advertise message, the mechanism in 2385 Section 15 is modified as follows for use in the transmission of 2386 Solicit messages. The message exchange is not terminated by the 2387 receipt of an Advertise before the first RT has elapsed. Rather, the 2388 client collects valid Advertise messages until the first RT has 2389 elapsed. Also, the first RT MUST be selected to be strictly greater 2390 than IRT by choosing RAND to be strictly greater than 0. 2392 A client MUST collect valid Advertise messages for the first RT 2393 seconds, unless it receives a valid Advertise message with a 2394 preference value of 255. The preference value is carried in the 2395 Preference option (see Section 21.8). Any valid Advertise that does 2396 not include a Preference option is considered to have a preference 2397 value of 0. If the client receives a valid Advertise message that 2398 includes a Preference option with a preference value of 255, the 2399 client immediately begins a client-initiated message exchange (as 2400 described in Section 18.2.2) by sending a Request message to the 2401 server from which the Advertise message was received. If the client 2402 receives a valid Advertise message that does not include a Preference 2403 option with a preference value of 255, the client continues to wait 2404 until the first RT elapses. If the first RT elapses and the client 2405 has received a valid Advertise message, the client SHOULD continue 2406 with a client-initiated message exchange by sending a Request 2407 message. 2409 If the client does not receive any valid Advertise messages before 2410 the first RT has elapsed, it begins the retransmission mechanism 2411 described in Section 15. The client terminates the retransmission 2412 process as soon as it receives any valid Advertise message, and the 2413 client acts on the received Advertise message without waiting for any 2414 additional Advertise messages. 2416 A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client 2417 is configured with either MRC or MRD set to a value other than 0, it 2418 MUST stop trying to configure the interface if the message exchange 2419 fails. After the DHCP client stops trying to configure the 2420 interface, it SHOULD restart the reconfiguration process after some 2421 external event, such as user input, system restart, or when the 2422 client is attached to a new link. 2424 18.2.2. Creation and Transmission of Request Messages 2426 The client uses a Request message to populate IAs with leases and 2427 obtain other configuration information. The client includes one or 2428 more IA options in the Request message. The server then returns 2429 leases and other information about the IAs to the client in IA 2430 options in a Reply message. 2432 The client generates a transaction ID and inserts this value in the 2433 "transaction-id" field. 2435 The client MUST include the identifier of the destination server in a 2436 Server Identifier option. 2438 The client MUST include a Client Identifier option to identify itself 2439 to the server. The client adds any other appropriate options, 2440 including one or more IA options. 2442 The client MUST include an Elapsed Time option (see Section 21.9) to 2443 indicate how long the client has been trying to complete the current 2444 DHCP message exchange. 2446 The client MUST include an Option Request option (see Section 21.7) 2447 to request the SOL_MAX_RT option (see Section 21.24) and any other 2448 options the client is interested in receiving. The client MAY 2449 additionally include instances of those options that are identified 2450 in the Option Request option, with data values as hints to the server 2451 about parameter values the client would like to have returned. 2453 The client includes a Reconfigure Accept option (see Section 21.20) 2454 if the client is willing to accept Reconfigure messages from the 2455 server. 2457 The client transmits the message according to Section 15, using the 2458 following parameters: 2460 IRT REQ_TIMEOUT 2462 MRT REQ_MAX_RT 2464 MRC REQ_MAX_RC 2466 MRD 0 2468 If the message exchange fails, the client takes an action based on 2469 the client's local policy. Examples of actions the client might take 2470 include: 2472 - Select another server from a list of servers known to the client; 2473 for example, servers that responded with an Advertise message. 2475 - Initiate the server discovery process described in Section 18. 2477 - Terminate the configuration process and report failure. 2479 18.2.3. Creation and Transmission of Confirm Messages 2481 The client uses a Confirm message when is has only addresses (no 2482 delegated prefixes) assigned by a DHCP server to determine if it is 2483 still connected to the same link when the client detects a change in 2484 network information as described in Section 18.2.12. 2486 The client sets the "msg-type" field to CONFIRM. The client 2487 generates a transaction ID and inserts this value in the 2488 "transaction-id" field. 2490 The client MUST include a Client Identifier option to identify itself 2491 to the server. 2493 The client MUST include an Elapsed Time option (see Section 21.9) to 2494 indicate how long the client has been trying to complete the current 2495 DHCP message exchange. 2497 The client includes IA options for all of the IAs assigned to the 2498 interface for which the Confirm message is being sent. The IA 2499 options include all of the addresses the client currently has 2500 associated with those IAs. The client SHOULD set the T1 and T2 2501 fields in any IA_NA options and the preferred-lifetime and valid- 2502 lifetime fields in the IA Address options to 0, as the server will 2503 ignore these fields. 2505 The first Confirm message from the client on the interface MUST be 2506 delayed by a random amount of time between 0 and CNF_MAX_DELAY. The 2507 client transmits the message according to Section 15, using the 2508 following parameters: 2510 IRT CNF_TIMEOUT 2512 MRT CNF_MAX_RT 2514 MRC 0 2516 MRD CNF_MAX_RD 2518 If the client receives no responses before the message transmission 2519 process terminates, as described in Section 15, the client SHOULD 2520 continue to use any leases, using the last known lifetimes for those 2521 leases, and SHOULD continue to use any other previously obtained 2522 configuration parameters. 2524 18.2.4. Creation and Transmission of Renew Messages 2526 To extend the valid and preferred lifetimes for the leases assigned 2527 to the IAs and obtain new addresses or delegated prefixes for IAs, 2528 the client sends a Renew message to the server from which the leases 2529 were obtained, which includes IA options for the IAs whose lease 2530 lifetimes are to be extended. The client includes IA Address options 2531 within IA_NA and IA_TA options for the addresses assigned to the IAs. 2532 The client includes IA Prefix options within IA_PD options for the 2533 delegated prefixes assigned to the IAs. 2535 The server controls the time at which the client should contact the 2536 server to extend the lifetimes on assigned leases through the T1 and 2537 T2 parameters assigned to an IA. However, as the client Renews/ 2538 Rebinds all IAs from the server at the same time, the client MUST 2539 select a T1 and T2 time from all IA options, which will guarantee 2540 that the client will send Renew/Rebind messages not later than at the 2541 T1/T2 times associated with any of the client's bindings (earliest 2542 T1/T2). 2544 At time T1, the client initiates a Renew/Reply message exchange to 2545 extend the lifetimes on any leases in the IA. 2547 A client MUST also initiate a Renew/Reply message exchange before 2548 time T1 if the client's link-local address used in previous 2549 interactions with the server is no longer valid and it is willing to 2550 receive Reconfigure messages. 2552 If T1 or T2 had been set to 0 by the server (for an IA_NA or IA_PD) 2553 or there are no T1 or T2 times (for an IA_TA) in a previous Reply, 2554 the client may send a Renew or Rebind message, respectively, at the 2555 client's discretion. The client MUST follow the rules defined in 2556 Section 14.2. 2558 The client sets the "msg-type" field to RENEW. The client generates 2559 a transaction ID and inserts this value in the "transaction-id" 2560 field. 2562 The client MUST include a Server Identifier option in the Renew 2563 message, identifying the server with which the client most recently 2564 communicated. 2566 The client MUST include a Client Identifier option to identify itself 2567 to the server. The client adds any appropriate options, including 2568 one or more IA options. 2570 The client MUST include an Elapsed Time option (see Section 21.9) to 2571 indicate how long the client has been trying to complete the current 2572 DHCP message exchange. 2574 For IAs to which leases have been assigned, the client includes a 2575 corresponding IA option containing an IA Address option for each 2576 address assigned to the IA and IA Prefix option for each prefix 2577 assigned to the IA. The client MUST NOT include addresses and 2578 prefixes in any IA option that the client did not obtain from the 2579 server or that are no longer valid (that have a valid lifetime of 0). 2581 The client MAY include an IA option for each binding it desires but 2582 has been unable to obtain. In this case, if the client includes the 2583 IA_PD option to request prefix delegation, the client MAY include the 2584 IA Prefix option encapsulated within the IA_PD option, with the 2585 IPv6-prefix field set to 0 and the "prefix-length" field set to the 2586 desired length of the prefix to be delegated. The server MAY use 2587 this value as a hint for the prefix length. The client SHOULD NOT 2588 include IA Prefix option with the IPv6-prefix field set to 0 unless 2589 it is supplying a hint for the prefix length. 2591 The client includes Option Request option (see Section 21.7) to 2592 request the SOL_MAX_RT option (see Section 21.24) and any other 2593 options the client is interested in receiving. The client MAY 2594 include options with data values as hints to the server about 2595 parameter values the client would like to have returned. 2597 The client transmits the message according to Section 15, using the 2598 following parameters: 2600 IRT REN_TIMEOUT 2602 MRT REN_MAX_RT 2604 MRC 0 2606 MRD Remaining time until earliest T2 2608 The message exchange is terminated when earliest time T2 is reached. 2609 If the client is responding to a Reconfigure, the client ignores and 2610 discards the Reconfigure message. In this case, the client continues 2611 to operate as if Reconfigure message was not received, i.e., it uses 2612 T1/T2 times associated with the client's leases to determine when it 2613 should send Renew or Rebind to the server. server. The client begins 2614 a Rebind message exchange (see Section 18.2.5) when the earliest time 2615 T2 is reached. 2617 18.2.5. Creation and Transmission of Rebind Messages 2619 At time T2 (which will only be reached if the server to which the 2620 Renew message was sent starting at time T1 has not responded), the 2621 client initiates a Rebind/Reply message exchange with any available 2622 server. 2624 A Rebind is also used to verify delegated prefix bindings but with 2625 different retransmission parameters as described in Section 18.2.3. 2627 The client constructs the Rebind message as described in 2628 Section 18.2.4 with the following differences: 2630 - The client sets the "msg-type" field to REBIND. 2632 - The client does not include the Server Identifier option in the 2633 Rebind message. 2635 The client transmits the message according to Section 15, using the 2636 following parameters: 2638 IRT REB_TIMEOUT 2640 MRT REB_MAX_RT 2642 MRC 0 2644 MRD Remaining time until valid lifetimes of all leases in all 2645 IAs have expired 2647 If all leases for an IA have expired, the client may choose to 2648 include this IA in subsequent Rebind messages to indicate that the 2649 client is interested in assignment of the leases to this IA. 2651 The message exchange is terminated when the valid lifetimes of all 2652 leases across all IAs have expired, at which time the client uses the 2653 Solicit message to locate a new DHCP server and sends a Request for 2654 the expired IAs to the new server. If the terminated Rebind exchange 2655 was initiated as a result of receiving a Reconfigure message, the 2656 client ignores and discards the Reconfigure message. 2658 18.2.6. Creation and Transmission of Information-request Messages 2660 The client uses an Information-request message to obtain 2661 configuration information without having addresses and/or delegated 2662 prefixes assigned to it. 2664 The client sets the "msg-type" field to INFORMATION-REQUEST. The 2665 client generates a transaction ID and inserts this value in the 2666 "transaction-id" field. 2668 The client SHOULD include a Client Identifier option to identify 2669 itself to the server (see section 4.3.1 of [RFC7844] for reasons why 2670 a client may not want to include this option). If the client does 2671 not include a Client Identifier option, the server will not be able 2672 to return any client-specific options to the client, or the server 2673 may choose not to respond to the message at all. 2675 The client MUST include an Elapsed Time option (see Section 21.9) to 2676 indicate how long the client has been trying to complete the current 2677 DHCP message exchange. 2679 The client MUST include an Option Request option (see Section 21.7) 2680 to request the INF_MAX_RT option (see Section 21.25), the Information 2681 Refresh Time option (see Section 21.23), and any other options the 2682 client is interested in receiving. The client MAY include options 2683 with data values as hints to the server about parameter values the 2684 client would like to have returned. 2686 When responding to a Reconfigure, the client includes a Server 2687 Identifier option with the identifier from the Reconfigure message to 2688 which the client is responding. 2690 The first Information-request message from the client on the 2691 interface MUST be delayed by a random amount of time between 0 and 2692 INF_MAX_DELAY. The client transmits the message according to 2693 Section 15, using the following parameters: 2695 IRT INF_TIMEOUT 2697 MRT INF_MAX_RT 2699 MRC 0 2701 MRD 0 2703 18.2.7. Creation and Transmission of Release Messages 2705 To release one or more leases, a client sends a Release message to 2706 the server. 2708 The client sets the "msg-type" field to RELEASE. The client 2709 generates a transaction ID and places this value in the "transaction- 2710 id" field. 2712 The client places the identifier of the server that allocated the 2713 lease(s) in a Server Identifier option. 2715 The client MUST include a Client Identifier option to identify itself 2716 to the server. 2718 The client MUST include an Elapsed Time option (see Section 21.9) to 2719 indicate how long the client has been trying to complete the current 2720 DHCP message exchange. 2722 The client includes options containing the IAs for the leases it is 2723 releasing in the "options" field. The leases to be released MUST be 2724 included in the IAs. Any leases for the IAs the client wishes to 2725 continue to use MUST NOT be added to the IAs. 2727 The client MUST stop using all of the leases being released before 2728 the client begins the Release message exchange process. For an 2729 address, this means the address MUST have been removed from the 2730 interface. For a delegated prefix, this means the prefix MUST have 2731 been advertised with a Preferred Lifetime and a Valid Lifetime of 2732 zero in a Router Advertisement message as described in (e) of 2733 Section 5.5.3 of [RFC4862] - also see L-13 in Section 4.3 of 2734 [RFC7084]. 2736 The client MUST NOT use any of the addresses it is releasing as the 2737 source address in the Release message or in any subsequently 2738 transmitted message. 2740 Because Release messages may be lost, the client should retransmit 2741 the Release if no Reply is received. However, there are scenarios 2742 where the client may not wish to wait for the normal retransmission 2743 timeout before giving up (e.g., on power down). Implementations 2744 SHOULD retransmit one or more times, but MAY choose to terminate the 2745 retransmission procedure early. 2747 The client transmits the message according to Section 15, using the 2748 following parameters: 2750 IRT REL_TIMEOUT 2752 MRT 0 2754 MRC REL_MAX_RC 2756 MRD 0 2758 If leases are released but the Reply from a DHCP server is lost, the 2759 client will retransmit the Release message, and the server may 2760 respond with a Reply indicating a status of NoBinding. Therefore, 2761 the client does not treat a Reply message with a status of NoBinding 2762 in a Release message exchange as if it indicates an error. 2764 Note that if the client fails to release the lease, each lease 2765 assigned to the IA will be reclaimed by the server when the valid 2766 lifetime of that lease expires. 2768 18.2.8. Creation and Transmission of Decline Messages 2770 If a client detects that one or more addresses assigned to it by a 2771 server are already in use by another node, the client sends a Decline 2772 message to the server to inform it that the address is suspect. 2774 The Decline message is not used in prefix delegation and thus the 2775 client MUST NOT include IA_PD options in the Decline message. 2777 The client sets the "msg-type" field to DECLINE. The client 2778 generates a transaction ID and places this value in the "transaction- 2779 id" field. 2781 The client places the identifier of the server that allocated the 2782 address(es) in a Server Identifier option. 2784 The client MUST include a Client Identifier option to identify itself 2785 to the server. 2787 The client MUST include an Elapsed Time option (see Section 21.9) to 2788 indicate how long the client has been trying to complete the current 2789 DHCP message exchange. 2791 The client includes options containing the IAs for the addresses it 2792 is declining in the "options" field. The addresses to be declined 2793 MUST be included in the IAs. Any addresses for the IAs the client 2794 wishes to continue to use should not be in added to the IAs. 2796 The client MUST NOT use any of the addresses it is declining as the 2797 source address in the Decline message or in any subsequently 2798 transmitted message. 2800 The client transmits the message according to Section 15, using the 2801 following parameters: 2803 IRT DEC_TIMEOUT 2805 MRT 0 2807 MRC DEC_MAX_RC 2808 MRD 0 2810 If addresses are declined but the Reply from a DHCP server is lost, 2811 the client will retransmit the Decline message, and the server may 2812 respond with a Reply indicating a status of NoBinding. Therefore, 2813 the client does not treat a Reply message with a status of NoBinding 2814 in a Decline message exchange as if it indicates an error. 2816 The client SHOULD NOT send a Release message for other bindings it 2817 may have received just because it sent a Decline message. The client 2818 SHOULD retain the non-conflicting bindings. The client SHOULD treat 2819 the failure to acquire a binding as a result of the conflict, to be 2820 equivalent to not having received the binding, insofar as it behaves 2821 when sending Renew and Rebind messages. 2823 18.2.9. Receipt of Advertise Messages 2825 Upon receipt of one or more valid Advertise messages, the client 2826 selects one or more Advertise messages based upon the following 2827 criteria. 2829 - Those Advertise messages with the highest server preference value 2830 are preferred over all other Advertise messages. 2832 - Within a group of Advertise messages with the same server 2833 preference value, a client MAY select those servers whose 2834 Advertise messages advertise information of interest to the 2835 client. 2837 - The client MAY choose a less-preferred server if that server has a 2838 better set of advertised parameters, such as the available set of 2839 IAs, as well as the set of other configuration options advertised. 2841 Once a client has selected Advertise message(s), the client will 2842 typically store information about each server, such as server 2843 preference value, addresses advertised, when the advertisement was 2844 received, and so on. 2846 In practice, this means that the client will maintain independent 2847 per-IA state machines per each selected server. 2849 If the client needs to select an alternate server in the case that a 2850 chosen server does not respond, the client chooses the next server 2851 according to the criteria given above. 2853 The client MUST process SOL_MAX_RT and INF_MAX_RT options in an 2854 Advertise message, even if the message contains a Status Code option 2855 indicating a failure, and the Advertise message will be discarded by 2856 the client. A client SHOULD only update its SOL_MAX_RT and 2857 INF_MAX_RT values if all received Advertise messages that contained 2858 the corresponding option specified the same value, otherwise it 2859 should use the default value (see Section 7.6). 2861 The client MUST ignore any Advertise message that contains no 2862 addresses (IA Address options encapsulated in IA_NA or IA_TA options) 2863 and no delegated prefixes (IA Prefix options encapsulated in IA_PD 2864 options) with the exception that the client: 2866 - MUST process an included SOL_MAX_RT option and 2868 - MUST process an included INF_MAX_RT option. 2870 A client can display any associated status message(s) to the user or 2871 activity log. 2873 The client ignoring an Advertise message MUST NOT restart the Solicit 2874 retransmission timer. 2876 18.2.10. Receipt of Reply Messages 2878 Upon the receipt of a valid Reply message in response to a Solicit 2879 (with a Rapid Commit option), Request, Confirm, Renew, Rebind, or 2880 Information-request message, the client extracts the top-level Status 2881 Code option if present. 2883 The client MUST process SOL_MAX_RT and INF_MAX_RT options in a Reply 2884 message, even if the message contains a Status Code option indicating 2885 a failure. 2887 If the client receives a Reply message with a status code of 2888 UnspecFail, the server is indicating that it was unable to process 2889 the client's message due to an unspecified failure condition. If the 2890 client retransmits the original message to the same server to retry 2891 the desired operation, the client MUST limit the rate at which it 2892 retransmits the message and limit the duration of the time during 2893 which it retransmits the message (see Section 14.1). 2895 If the client receives a Reply message with a status code of 2896 UseMulticast, the client records the receipt of the message and sends 2897 subsequent messages to the server through the interface on which the 2898 message was received using multicast. The client resends the 2899 original message using multicast. 2901 Otherwise (no status code or another status code), the client 2902 processes the Reply as described below based on the original message 2903 for which the Reply was received. 2905 The client MAY choose to report any status code or message from the 2906 Status Code option in the Reply message. 2908 When a client received a configuration option in an earlier Reply, 2909 then sends a Renew, Rebind or Information-request and the requested 2910 option is not present in the Reply, the client SHOULD stop using the 2911 previously received configuration information. In other words, the 2912 client should behave as if it never received this configuration 2913 option and return to the relevant default state. If there is no 2914 viable way to stop using the received configuration information, the 2915 values received/configured from the option MAY persist if there are 2916 no other sources for that data and they have no external impact. For 2917 example, a client that previously received a Client FQDN option and 2918 used it to set up its hostname is allowed to continue using it if 2919 there is no reasonable way for a node to unset its hostname and it 2920 has no external impact. As a counter example, a client that 2921 previously received an NTP server address from the DHCP server and 2922 does not receive it any more, MUST stop using the configured NTP 2923 server address. The client SHOULD be open to other sources of the 2924 same configuration information. This behavior does not apply to any 2925 IA containers, as their processing is described in detail in the next 2926 section. 2928 When a client receives a requested option that has an updated value 2929 from what was previously received, the client SHOULD make use of that 2930 updated value as soon as possible for its configuration information. 2932 18.2.10.1. Reply for Solicit (with Rapid Commit), Request, Renew or 2933 Rebind 2935 If the client receives a NotOnLink status from the server in response 2936 to a Solicit (with a Rapid Commit option) or a Request, the client 2937 can either re-issue the message without specifying any addresses or 2938 restart the DHCP server discovery process (see Section 18). 2940 If the Reply was received in response to a Solicit (with a Rapid 2941 Commit option), Request, Renew, or Rebind message, the client updates 2942 the information it has recorded about IAs from the IA options 2943 contained in the Reply message: 2945 - Record T1 and T2 times, if appropriate for the IA type. 2947 - Add any new leases in the IA option to the IA as recorded by the 2948 client. 2950 - Update lifetimes for any leases in the IA option that the client 2951 already has recorded in the IA. 2953 - Discard any leases from the IA, as recorded by the client, that 2954 have a valid lifetime of 0 in the IA Address or IA Prefix option. 2956 - Leave unchanged any information about leases the client has 2957 recorded in the IA but that were not included in the IA from the 2958 server. 2960 If the client can operate with the addresses and/or prefixes obtained 2961 from the server: 2963 - The client uses the addresses, delegated prefixes, and other 2964 information from any IAs that do not contain a Status Code option 2965 with the NoAddrsAvail or NoPrefixAvail status code. The client 2966 MAY include the IAs for which it received the NoAddrsAvail or 2967 NoPrefixAvail status code, with no addresses or prefixes, in 2968 subsequent Renew and Rebind messages sent to the server, to retry 2969 obtaining the addresses or prefixes for these IAs. 2971 - The client MUST perform duplicate address detection as per 2972 [RFC4862] Section 5.4, which does list some exceptions, on each of 2973 the received addresses in any IAs, on which it has not performed 2974 duplicate address detection during processing of any of the 2975 previous Reply messages from the server. The client performs the 2976 duplicate address detection before using the received addresses 2977 for any traffic. If any of the addresses are found to be in use 2978 on the link, the client sends a Decline message to the server for 2979 those addresses as described in Section 18.2.8. 2981 - For each assigned address, which does not have any associated 2982 reachability information, in order to avoid the problems described 2983 in [RFC4943], the client MUST NOT assume that any addresses are 2984 reachable on-link as a result of receiving an IA_NA or IA_TA. 2985 Addresses obtained from IA_NA or IA_TA MUST NOT be used to form an 2986 implicit prefix with a length other than 128. 2988 - For each delegated prefix, the client assigns a subnet to each of 2989 the links to which the associated interfaces are attached, with 2990 the following exception: the client MUST NOT advertise any 2991 delegated prefixes or subnets from the delegated prefix(es) to the 2992 link through which it received the DHCP message from the server 2993 (see [RFC6603] for exceptions). 2995 When a client subnets a delegated prefix, it must assign 2996 additional bits to the prefix to generate unique, longer prefixes. 2997 For example, if the client in Figure 1 were delegated 2998 2001:db8:0::/48, it might generate 2001:db8:0:1::/64 and 2999 2001:db8:0:2::/64 for assignment to the two links in the 3000 subscriber network. If the client were delegated 2001:db8:0::/48 3001 and 2001:db8:5::/48, it might assign 2001:db8:0:1::/64 and 3002 2001:db8:5:1::/64 to one of the links, and 2001:db8:0:2::/64 and 3003 2001:db8:5:2::/64 for assignment to the other link. 3005 If the client uses a delegated prefix to configure addresses on 3006 interfaces on itself or other nodes behind it, the preferred and 3007 valid lifetimes of those addresses MUST be no larger than the 3008 remaining preferred and valid lifetimes, respectively, for the 3009 delegated prefix at any time. In particular, if the delegated 3010 prefix or a prefix derived from it is advertised for stateless 3011 address autoconfiguration [RFC4862], the advertised valid and 3012 preferred lifetimes MUST NOT exceed the corresponding remaining 3013 lifetimes of the delegated prefix. 3015 Management of the specific configuration information is detailed in 3016 the definition of each option in Section 21. 3018 If the Reply message contains any IAs, but the client finds no usable 3019 addresses and/or delegated prefixes in any of these IAs, the client 3020 may either try another server (perhaps restarting the DHCP server 3021 discovery process) or use the Information-request message to obtain 3022 other configuration information only. 3024 When the client receives a Reply message in response to a Renew or 3025 Rebind message, the client: 3027 - Sends a Request message if any of the IAs in the Reply message 3028 contains the NoBinding status code to the server that responded. 3029 The client places IA options in this message for all IAs. The 3030 client continues to use other bindings for which the server did 3031 not return an error. 3033 - Sends a Renew/Rebind if any of the IAs are not in the Reply 3034 message, but in this case the client MUST limit the rate at which 3035 it sends these messages, to avoid the Renew/Rebind storm. 3037 - Otherwise accepts the information in the IA. 3039 Whenever a client restarts the DHCP server discovery process or 3040 selects an alternate server, as described in Section 18.2.9, the 3041 client SHOULD stop using all the addresses and delegated prefixes for 3042 which it has bindings and try to obtain all required leases from the 3043 new server. This facilitates the client using a single state machine 3044 for all bindings. 3046 18.2.10.2. Reply for Release and Decline 3048 When the client receives a valid Reply message in response to a 3049 Release message, the client considers the Release event completed, 3050 regardless of the Status Code option(s) returned by the server. 3052 When the client receives a valid Reply message in response to a 3053 Decline message, the client considers the Decline event completed, 3054 regardless of the Status Code option(s) returned by the server. 3056 18.2.10.3. Reply for Confirm 3058 If the client receives any Reply messages that indicate a success 3059 status (explicit or implicit), the client can use the addresses in 3060 the IA and ignore any messages that indicate a NotOnLink status. 3061 When the client only receives one or more Replies with the NotOnLink 3062 status in response to a Confirm message, the client performs DHCP 3063 server discovery as described in Section 18. 3065 18.2.10.4. Reply for Information-request 3067 Refer to Section 21.23 for details on how the Information Refresh 3068 Time option (whether or not present in the Reply) should be handled 3069 by the client. 3071 18.2.11. Receipt of Reconfigure Messages 3073 A client receives Reconfigure messages sent to the UDP port 546 on 3074 interfaces for which it has acquired configuration information 3075 through DHCP. These messages may be sent at any time. Since the 3076 results of a reconfiguration event may affect application layer 3077 programs, the client SHOULD log these events, and MAY notify these 3078 programs of the change through an implementation-specific interface. 3080 Upon receipt of a valid Reconfigure message, the client responds with 3081 either a Renew message, a Rebind message, or an Information-request 3082 message as indicated by the Reconfigure Message option (as defined in 3083 Section 21.19). The client ignores the transaction-id field in the 3084 received Reconfigure message. While the transaction is in progress, 3085 the client discards any Reconfigure messages it receives. 3087 The Reconfigure message acts as a trigger that signals the client to 3088 complete a successful message exchange. Once the client has received 3089 a Reconfigure, the client proceeds with the message exchange 3090 (retransmitting the Renew, Rebind, or Information-request message if 3091 necessary); the client MUST ignore any additional Reconfigure 3092 messages until the exchange is complete. 3094 Duplicate messages will be ignored because the client will begin the 3095 exchange after the receipt of the first Reconfigure. Retransmitted 3096 messages will either trigger the exchange (if the first Reconfigure 3097 was not received by the client) or will be ignored. The server MAY 3098 discontinue retransmission of Reconfigure messages to the client once 3099 the server receives the Renew, Rebind or Information-request message 3100 from the client. 3102 It might be possible for a duplicate or retransmitted Reconfigure to 3103 be sufficiently delayed (and delivered out of order) to arrive at the 3104 client after the exchange (initiated by the original Reconfigure) has 3105 been completed. In this case, the client would initiate a redundant 3106 exchange. The likelihood of delayed and out of order delivery is 3107 small enough to be ignored. The consequence of the redundant 3108 exchange is inefficiency rather than incorrect operation. 3110 18.2.12. Refreshing Configuration Information 3112 Whenever a client may have moved to a new link, the prefixes/ 3113 addresses assigned to the interfaces on that link may no longer be 3114 appropriate for the link to which the client is attached. Examples 3115 of times when a client may have moved to a new link include: 3117 o The client reboots (and has stable storage and persisted DHCP 3118 state). 3120 o The client is reconnected to a link on which it has obtained 3121 leases. 3123 o The client returns from sleep mode. 3125 o The client changes access points (such as if using a wireless 3126 technology). 3128 When the client detects one of the above conditions and it has 3129 obtained addresses and no delegated prefixes from a server, the 3130 client SHOULD initiate a Confirm/Reply message exchange. The client 3131 includes any IAs assigned to the interface that may have moved to a 3132 new link, along with the addresses associated with those IAs, in its 3133 Confirm message. Any responding servers will indicate whether those 3134 addresses are appropriate for the link to which the client is 3135 attached with the status in the Reply message it returns to the 3136 client. 3138 If the client has any valid delegated prefixes obtained from the DHCP 3139 server, the client MUST initiate a Rebind/Reply message exchange as 3140 described in Section 18.2.5, with the exception that the 3141 retransmission parameters should be set as for the Confirm message 3142 (see Section 18.2.3). The client includes IA_NAs, IA_TAs, and 3143 IA_PDs, along with the associated leases, in its Rebind message. 3145 If the client has only obtained network information using Information 3146 Request/Reply message exchanges, the client MUST initiate a 3147 Information-Request/Reply message exchange as described in 3148 Section 18.2.6. 3150 If not associated with one of the above mentioned conditions, a 3151 client MAY initiate a Renew/Reply exchange (as if the T1 time 3152 expired) as described in Section 18.2.4 or an Information-Request/ 3153 Reply exchange as described in Section 18.2.6 if the client detects a 3154 significant change regarding the prefixes available on the link (when 3155 new are added or existing are deprecated) as this may indicate a 3156 configuration change. However, a client MUST rate limit such 3157 attempts to avoid flooding a server with requests when there are link 3158 issues (for example, only doing one of these at most every 30 3159 seconds). 3161 18.3. Server Behavior 3163 For this discussion, the Server is assumed to have been configured in 3164 an implementation specific manner with configuration of interest to 3165 clients. 3167 A server sends an Advertise message in response to each valid Solicit 3168 message it receives to announce the availability of the server to the 3169 client. 3171 In most cases, the server will send a Reply in response to a Request, 3172 Confirm, Renew, Rebind, Decline, Release, and Information-request 3173 messages sent by a client. The server will also send a Reply in 3174 response to a Solicit with a Rapid Commit option, when the server is 3175 configured to respond with committed lease assignments. 3177 These Advertise and Reply messages MUST always contain the Server 3178 Identifier option containing the server's DUID and the Client 3179 Identifier option from the client message if one was present. 3181 In most response messages, the server includes options containing 3182 configuration information for the client. The server must be aware 3183 of the recommendations on packet sizes and the use of fragmentation 3184 in section 5 of [RFC2460]. If the client included an Option Request 3185 option in its message, the server includes options in the response 3186 message containing configuration parameters for all of the options 3187 identified in the Option Request option that the server has been 3188 configured to return to the client. The server MAY return additional 3189 options to the client if it has been configured to do so. 3191 The server MAY initiate a configuration exchange, by sending 3192 Reconfigure messages, to cause DHCP clients to obtain new addresses, 3193 prefixes and other configuration information. For example, an 3194 administrator may use a server-initiated configuration exchange when 3195 links in the DHCP domain are to be renumbered or when other 3196 configuration options are updated, perhaps because servers are moved, 3197 added, or removed. 3199 When a client receives a Reconfigure message from the server, the 3200 client initiates sending a Renew, Rebind or Information-request 3201 message as indicated by msg-type in the Reconfigure Message option 3202 (as defined in Section 21.19). The server sends IAs and/or other 3203 configuration information to the client in a Reply message. The 3204 server MAY include options containing the IAs and new values for 3205 other configuration parameters in the Reply message, even if those 3206 IAs and parameters were not requested in the client's message. 3208 18.3.1. Receipt of Solicit Messages 3210 See Section 18.4 for handling Solicit message received via unicast. 3211 Unicast transmission of Solicit is not allowed, regardless if Server 3212 Unicast option is configured or not. 3214 The server determines the information about the client and its 3215 location as described in Section 13 and checks its administrative 3216 policy about responding to the client. If the server is not 3217 permitted to respond to the client, the server discards the Solicit 3218 message. For example, if the administrative policy for the server is 3219 that it may only respond to a client that is willing to accept a 3220 Reconfigure message, if the client does not include a Reconfigure 3221 Accept option (see Section 21.20) in the Solicit message, the server 3222 discards the Solicit message. 3224 If the server is permitted to respond to the client, the client has 3225 not included a Rapid Commit option in the Solicit message or the 3226 server has not been configured to respond with committed assignment 3227 of leases and other resources, the server sends an Advertise message 3228 to the client as described in Section 18.3.9. 3230 If the client has included a Rapid Commit option in the Solicit 3231 message and the server has been configured to respond with committed 3232 assignments of leases and other resources, the server responds to the 3233 Solicit with a Reply message. The server produces the Reply message 3234 as though it had received a Request message, as described in 3235 Section 18.3.2. The server transmits the Reply message as described 3236 in Section 18.3.10. The server MUST commit the assignment of any 3237 addresses and delegated prefixes or other configuration information 3238 before sending a Reply message to a client. In this case the server 3239 includes a Rapid Commit option in the Reply message to indicate that 3240 the Reply is in response to a Solicit message. 3242 DISCUSSION: 3244 When using the Solicit/Reply message exchange, the server commits 3245 the assignment of any leases before sending the Reply message. 3246 The client can assume it has been assigned the leases in the Reply 3247 message and does not need to send a Request message for those 3248 leases. 3250 Typically, servers that are configured to use the Solicit/Reply 3251 message exchange will be deployed so that only one server will 3252 respond to a Solicit message. If more than one server responds, 3253 the client will only use the leases from one of the servers, while 3254 the leases from the other servers will be committed to the client 3255 but not used by the client. 3257 18.3.2. Receipt of Request Messages 3259 See Section 18.4 for handling Request message received via unicast. 3261 When the server receives a valid Request message, the server creates 3262 the bindings for that client according to the server's policy and 3263 configuration information and records the IAs and other information 3264 requested by the client. 3266 The server constructs a Reply message by setting the "msg-type" field 3267 to REPLY, and copying the transaction ID from the Request message 3268 into the transaction-id field. 3270 The server MUST include a Server Identifier option containing the 3271 server's DUID and the Client Identifier option from the Request 3272 message in the Reply message. 3274 The server examines all IAs in the message from the client. 3276 For each IA_NA and IA_TA in the Request message the server checks if 3277 the prefixes of included addresses are appropriate for the link to 3278 which the client is connected. If any of the prefixes of the 3279 included addresses is not appropriate for the link to which the 3280 client is connected, the server MUST return the IA to the client with 3281 a Status Code option with the value NotOnLink. If the server does 3282 not send the NotOnLink status code but it cannot assign any IP 3283 addresses to an IA, the server MUST return the IA option in the Reply 3284 message with no addresses in the IA and a Status Code option 3285 containing status code NoAddrsAvail in the IA. 3287 For any IA_PD in the Request message, to which the server cannot 3288 assign any delegated prefixes, the server MUST return the IA_PD 3289 option in the Reply message with no prefixes in the IA_PD and with a 3290 Status Code option containing status code NoPrefixAvail in the IA_PD. 3292 The server MAY assign different addresses and/or delegated prefixes 3293 to an IA than those included within the IA of the client's Request 3294 message. 3296 For all IAs to which the server can assign addresses or delegated 3297 prefixes, the server includes the IAs with addresses (for IA_NA and 3298 IA_TA), prefixes (for IA_PD) and other configuration parameters, and 3299 records the IA as a new client binding. The server MUST NOT include 3300 any addresses or delegated prefixes in the IA which the server does 3301 not assign to the client. 3303 The T1/T2 times set in each applicable IA option for a Reply MUST be 3304 the same values across all IAs. The server MUST determine the T1/T2 3305 times across all of the applicable client's bindings in the Reply. 3306 This facilitates the client being able to renew all of the bindings 3307 at the same time. 3309 The server SHOULD include a Reconfigure Accept option if the server 3310 policy enables reconfigure mechanism and the client supports it. 3311 Currently sending this option in Reply is technically redundant, as 3312 the use of the reconfiguration mechanism requires authentication and 3313 currently the only defined one is the Reconfigure Key Authentication 3314 Protocol (see Section 20.4) and the presence of the reconfigure key 3315 signals support for Reconfigure acceptance. However, there may be 3316 better security mechanisms defined in the future that would cause 3317 RKAP to not be used anymore. One of such mechanisms being worked on 3318 is mentioned in Section 22. 3320 The server includes other options containing configuration 3321 information to be returned to the client as described in 3322 Section 18.3. 3324 If the server finds that the client has included an IA in the Request 3325 message for which the server already has a binding that associates 3326 the IA with the client, the server sends a Reply message with 3327 existing bindings, possibly with updated lifetimes. The server may 3328 update the bindings according to its local policies, but the server 3329 SHOULD generate the response again and not simply retransmit 3330 previously sent information, even if the transaction-id matches a 3331 previous transmission. The server MUST NOT cache its responses. 3333 18.3.3. Receipt of Confirm Messages 3335 See Section 18.4 for handling Confirm message received via unicast. 3336 Unicast transmission of Confirm is not allowed, regardless if Server 3337 Unicast option is configured or not. 3339 When the server receives a Confirm message, the server determines 3340 whether the addresses in the Confirm message are appropriate for the 3341 link to which the client is attached. If all of the addresses in the 3342 Confirm message pass this test, the server returns a status of 3343 Success. If any of the addresses do not pass this test, the server 3344 returns a status of NotOnLink. If the server is unable to perform 3345 this test (for example, the server does not have information about 3346 prefixes on the link to which the client is connected), or there were 3347 no addresses in any of the IAs sent by the client, the server MUST 3348 NOT send a Reply to the client. 3350 The server ignores the T1 and T2 fields in the IA options and the 3351 preferred-lifetime and valid-lifetime fields in the IA Address 3352 options. 3354 The server constructs a Reply message by setting the "msg-type" field 3355 to REPLY, and copying the transaction ID from the Confirm message 3356 into the transaction-id field. 3358 The server MUST include a Server Identifier option containing the 3359 server's DUID and the Client Identifier option from the Confirm 3360 message in the Reply message. The server includes a Status Code 3361 option indicating the status of the Confirm message. 3363 18.3.4. Receipt of Renew Messages 3365 See Section 18.4 for handling Renew message received via unicast. 3367 For each IA in the Renew message from a client, the server locates 3368 the client's binding and verifies that the information in the IA from 3369 the client matches the information stored for that client. 3371 If the server finds the client entry for the IA, the server sends 3372 back the IA to the client with new lifetimes and, if applicable, T1/ 3373 T2 times. If the server is unable to extend the lifetimes of an 3374 address or delegated prefix in the IA, the server MAY choose not to 3375 include the IA Address or IA Prefix option for this address or 3376 delegated prefix. If the server chooses to include the IA Address or 3377 IA Prefix option for such an address or delegated prefix, the server 3378 SHOULD set T1 and T2 to the valid lifetime for the IA option unless 3379 the server also includes other addresses or delegated prefixes which 3380 the server is able to extend for the IA. Setting T1 and T2 to values 3381 equal to valid lifetime informs the client that the leases associated 3382 with said IA will not be extended, so there is no point in trying. 3383 Also, it avoids generating unnecessary traffic as the remaining 3384 lifetime approaches 0. 3386 The server may choose to change the list of addresses or delegated 3387 prefixes and the lifetimes in IAs that are returned to the client. 3389 If the server finds that any of the addresses in the IA are not 3390 appropriate for the link to which the client is attached, the server 3391 returns the address to the client with lifetimes of 0. 3393 If the server finds that any of the delegated prefixes in the IA are 3394 not appropriate for the link to which the client is attached, the 3395 server returns the delegated prefix to the client with lifetimes of 3396 0. 3398 For each IA for which the server cannot find a client entry, the 3399 server has the following choices depending on the server's policy and 3400 configuration information: 3402 - If the server is configured to create new bindings as a result of 3403 processing Renew messages, the server SHOULD create a binding and 3404 return the IA with assigned addresses or delegated prefixes with 3405 lifetimes and, if applicable, T1/T2 times and other information 3406 requested by the client. If the client included the IA Prefix 3407 option within the IA_PD option with zero value in the "IPv6 3408 prefix" field and non-zero value in the "prefix-length" field, the 3409 server MAY use the "prefix-length" value as a hint for the length 3410 of the prefixes to be assigned (see [RFC8168] for further details 3411 on prefix length hints). 3413 - If the server is configured to create new bindings as a result of 3414 processing Renew messages, but the server will not assign any 3415 leases to an IA, the server returns the IA option containing a 3416 Status Code option with the NoAddrsAvail or NoPrefixAvail status 3417 code and a status message for a user. 3419 - If the server does not support creation of new bindings for the 3420 client sending a Renew message, or if this behavior is disabled 3421 according to the server's policy or configuration information, the 3422 server returns the IA option containing a Status Code option with 3423 the NoBinding status code and a status message for a user. 3425 The server constructs a Reply message by setting the "msg-type" field 3426 to REPLY and copying the transaction ID from the Renew message into 3427 the "transaction-id" field. 3429 The server MUST include a Server Identifier option containing the 3430 server's DUID and the Client Identifier option from the Renew message 3431 in the Reply message. 3433 The server includes other options containing configuration 3434 information to be returned to the client as described in 3435 Section 18.3. 3437 The server MAY include options containing the IAs and values for 3438 other configuration parameters, even if those parameters were not 3439 requested in the Renew message. 3441 The T1/T2 times set in each applicable IA option for a Reply MUST be 3442 the same values across all IAs. The server MUST determine the T1/T2 3443 times across all of the applicable client's bindings in the Reply. 3444 This facilitates the client being able to renew all of the bindings 3445 at the same time. 3447 18.3.5. Receipt of Rebind Messages 3449 See Section 18.4 for handling Rebind message received via unicast. 3450 Unicast transmission of Rebind is not allowed, regardless if Server 3451 Unicast option is configured or not. 3453 When the server receives a Rebind message that contains an IA option 3454 from a client, it locates the client's binding and verifies that the 3455 information in the IA from the client matches the information stored 3456 for that client. 3458 If the server finds the client entry for the IA and the server 3459 determines that the addresses or delegated prefixes in the IA are 3460 appropriate for the link to which the client's interface is attached 3461 according to the server's explicit configuration information, the 3462 server SHOULD send back the IA to the client with new lifetimes and, 3463 if applicable, T1/T2 times. If the server is unable to extend the 3464 lifetimes of an address in the IA, the server MAY choose not to 3465 include the IA Address option for this address. If the server is 3466 unable to extend the lifetimes of a delegated prefix in the IA, the 3467 server MAY choose not to include the IA Prefix option for this 3468 prefix. 3470 If the server finds that the client entry for the IA and any of the 3471 addresses or delegated prefixes are no longer appropriate for the 3472 link to which the client's interface is attached according to the 3473 server's explicit configuration information, the server returns the 3474 address or delegated prefix to the client with lifetimes of 0. 3476 If the server cannot find a client entry for the IA, the server 3477 checks if the IA contains addresses (for IA_NA and IA_TA) or 3478 delegated prefixes (for IA_PD). The server checks if the addresses 3479 and delegated prefixes are appropriate for the link to which the 3480 client's interface is attached according to the server's explicit 3481 configuration information. For any address which is not appropriate 3482 for the link to which the client's interface is attached, the server 3483 MAY include the IA Address option with the lifetimes of 0. For any 3484 delegated prefix which is not appropriate for the link to which the 3485 client's interface is attached, the server MAY include the IA Prefix 3486 option with the lifetimes of 0. The Reply with lifetimes of 0 3487 constitutes an explicit notification to the client that the specific 3488 addresses and delegated prefixes are no longer valid and MUST NOT be 3489 used by the client. If the server chooses to not include any IAs 3490 containing IA Address or IA Prefix options with lifetimes of 0 and 3491 the server does not include any other IAs with leases and/or status 3492 codes, the server does not send a Reply message. In this situation 3493 the server discards the Rebind message. 3495 Otherwise, for each IA for which the server cannot find a client 3496 entry, the server has the following choices depending on the server's 3497 policy and configuration information: 3499 - If the server is configured to create new bindings as a result of 3500 processing Rebind messages (also see the note about the Rapid 3501 Commit option below), the server SHOULD create a binding and 3502 return the IA with allocated leases with lifetimes and, if 3503 applicable, T1/T2 times and other information requested by the 3504 client. The server MUST NOT return any addresses or delegated 3505 prefixes in the IA which the server does not assign to the client. 3507 - If the server is configured to create new bindings as a result of 3508 processing Rebind messages, but the server will not assign any 3509 leases to an IA, the server returns the IA option containing a 3510 Status Code option with the NoAddrsAvail or NoPrefixAvail status 3511 code and a status message for a user. 3513 - If the server does not support creation of new bindings for the 3514 client sending a Rebind message, or if this behavior is disabled 3515 according to the server's policy or configuration information, the 3516 server returns the IA option containing a Status Code option with 3517 the NoBinding status code and a status message for a user. 3519 When the server creates new bindings for the IA, it is possible that 3520 other servers also create bindings as a result of receiving the same 3521 Rebind message - see the Discussion in Section 21.14. Therefore, the 3522 server SHOULD only create new bindings during processing of a Rebind 3523 message if the server is configured to respond with a Reply message 3524 to a Solicit message containing the Rapid Commit option. 3526 The server constructs a Reply message by setting the "msg-type" field 3527 to REPLY and copying the transaction ID from the Rebind message into 3528 the "transaction-id" field. 3530 The server MUST include a Server Identifier option containing the 3531 server's DUID and the Client Identifier option from the Rebind 3532 message in the Reply message. 3534 The server includes other options containing configuration 3535 information to be returned to the client as described in 3536 Section 18.3. 3538 The server MAY include options containing the IAs and values for 3539 other configuration parameters, even if those IAs and parameters were 3540 not requested in the Rebind message. 3542 The T1/T2 times set in each applicable IA option for a Reply MUST be 3543 the same values across all IAs. The server MUST determine the T1/T2 3544 times across all of the applicable client's bindings in the Reply. 3545 This facilitates the client being able to renew all of the bindings 3546 at the same time. 3548 18.3.6. Receipt of Information-request Messages 3550 See Section 18.4 for handling Information-request message received 3551 via unicast. 3553 When the server receives an Information-request message, the client 3554 is requesting configuration information that does not include the 3555 assignment of any leases. The server determines all configuration 3556 parameters appropriate to the client, based on the server 3557 configuration policies known to the server. 3559 The server constructs a Reply message by setting the "msg-type" field 3560 to REPLY, and copying the transaction ID from the Information-request 3561 message into the transaction-id field. 3563 The server MUST include a Server Identifier option containing the 3564 server's DUID in the Reply message. If the client included a Client 3565 Identification option in the Information-request message, the server 3566 copies that option to the Reply message. 3568 The server includes options containing configuration information to 3569 be returned to the client as described in Section 18.3. The server 3570 MAY include additional options that were not requested by the client 3571 in the Information-request message. 3573 If the Information-request message received from the client did not 3574 include a Client Identifier option, the server SHOULD respond with a 3575 Reply message containing any configuration parameters that are not 3576 determined by the client's identity. If the server chooses not to 3577 respond, the client may continue to retransmit the Information- 3578 request message indefinitely. 3580 18.3.7. Receipt of Release Messages 3582 See Section 18.4 for handling Release message received via unicast. 3584 The server constructs a Reply message by setting the "msg-type" field 3585 to REPLY, and copying the transaction ID from the Release message 3586 into the transaction-id field. 3588 Upon the receipt of a valid Release message, the server examines the 3589 IAs and the leases in the IAs for validity. If the IAs in the 3590 message are in a binding for the client, and the leases in the IAs 3591 have been assigned by the server to those IAs, the server deletes the 3592 leases from the IAs and makes the leases available for assignment to 3593 other clients. The server ignores leases not assigned to the IA, 3594 although it may choose to log an error. 3596 After all the leases have been processed, the server generates a 3597 Reply message and includes a Status Code option with value Success, a 3598 Server Identifier option with the server's DUID, and a Client 3599 Identifier option with the client's DUID. For each IA in the Release 3600 message for which the server has no binding information, the server 3601 adds an IA option using the IAID from the Release message, and 3602 includes a Status Code option with the value NoBinding in the IA 3603 option. No other options are included in the IA option. 3605 A server may choose to retain a record of assigned leases and IAs 3606 after the lifetimes on the leases have expired to allow the server to 3607 reassign the previously assigned leases to a client. 3609 18.3.8. Receipt of Decline Messages 3611 See Section 18.4 for handling Decline message received via unicast. 3613 Upon the receipt of a valid Decline message, the server examines the 3614 IAs and the addresses in the IAs for validity. If the IAs in the 3615 message are in a binding for the client, and the addresses in the IAs 3616 have been assigned by the server to those IAs, the server deletes the 3617 addresses from the IAs. The server ignores addresses not assigned to 3618 the IA (though it may choose to log an error if it finds such an 3619 address). 3621 The client has found any addresses in the Decline messages to be 3622 already in use on its link. Therefore, the server SHOULD mark the 3623 addresses declined by the client so that those addresses are not 3624 assigned to other clients, and MAY choose to make a notification that 3625 addresses were declined. Local policy on the server determines when 3626 the addresses identified in a Decline message may be made available 3627 for assignment. 3629 After all the addresses have been processed, the server generates a 3630 Reply message by setting the "msg-type" field to REPLY, and copying 3631 the transaction ID from the Decline message into the transaction-id 3632 field. The client includes a Status Code option with the value 3633 Success, a Server Identifier option with the server's DUID, and a 3634 Client Identifier option with the client's DUID. For each IA in the 3635 Decline message for which the server has no binding information, the 3636 server adds an IA option using the IAID from the Decline message and 3637 includes a Status Code option with the value NoBinding in the IA 3638 option. No other options are included in the IA option. 3640 18.3.9. Creation of Advertise Messages 3642 The server sets the "msg-type" field to ADVERTISE and copies the 3643 contents of the transaction-id field from the Solicit message 3644 received from the client to the Advertise message. The server 3645 includes its server identifier in a Server Identifier option and 3646 copies the Client Identifier option from the Solicit message into the 3647 Advertise message. 3649 The server MAY add a Preference option to carry the preference value 3650 for the Advertise message. The server implementation SHOULD allow 3651 the setting of a server preference value by the administrator. The 3652 server preference value MUST default to zero unless otherwise 3653 configured by the server administrator. 3655 The server includes a Reconfigure Accept option if the server wants 3656 to indicate it supports Reconfigure mechanism. This information may 3657 be used by the client during the server selection process. 3659 The server includes the options the server will return to the client 3660 in a subsequent Reply message. The information in these options may 3661 be used by the client in the selection of a server if the client 3662 receives more than one Advertise message. The server MUST include 3663 options in the Advertise message containing configuration parameters 3664 for all of the options identified in the Option Request option in the 3665 Solicit message that the server has been configured to return to the 3666 client. If the Option Request option includes a container option the 3667 server MUST include all the options that are eligible to be 3668 encapsulated in the container. The Option Request option MAY be used 3669 to signal support for a feature even when that option is encapsulated 3670 as in the case of the Prefix Exclude option [RFC6603]. In this case, 3671 special processing is required by the server. The server MAY return 3672 additional options to the client if it has been configured to do so. 3674 The server MUST include IA options in the Advertise message 3675 containing any addresses and/or delegated prefixes that would be 3676 assigned to IAs contained in the Solicit message from the client. If 3677 the client has included addresses in the IA in the Solicit message, 3678 the server MAY use those addresses as hints about the addresses that 3679 the client would like to receive. If the client has included IA 3680 Prefix option in the IA_PD, the server MAY use the prefix contained 3681 in the IPv6-prefix field and/or the prefix length contained in the 3682 "prefix-length" field as a hints about the prefixes the client would 3683 like to receive. If the server is not going to assign an address or 3684 delegated prefix received as a hint in the Solicit message, the 3685 server MUST NOT include this address or delegated prefix in the 3686 Advertise message. 3688 If the server will not assign any addresses to an IA (IA_NA or IA_TA) 3689 in subsequent Request from the client, the server MUST include the IA 3690 in the Advertise message with no addresses in the IA and a Status 3691 Code option encapsulated in the IA containing status code 3692 NoAddrsAvail. 3694 If the server will not assign any prefixes to an IA_PD in subsequent 3695 Request from the client, the server MUST include the IA_PD in the 3696 Advertise message with no prefixes in the IA and a Status Code option 3697 encapsulated in the IA_PD containing status code NoPrefixAvail. 3699 Transmission of the Advertise message is described in the next 3700 section. 3702 18.3.10. Transmission of Advertise and Reply Messages 3704 If the original message was received directly by the server, the 3705 server unicasts the Advertise or Reply message directly to the client 3706 using the address in the source address field from the IP datagram in 3707 which the original message was received. The Advertise or Reply 3708 message MUST be unicast through the interface on which the original 3709 message was received. 3711 If the original message was received in a Relay-forward message, the 3712 server constructs a Relay-reply message with the Reply message in the 3713 payload of a Relay Message option (see Section 21.10). If the Relay- 3714 forward messages included an Interface-id option, the server copies 3715 that option to the Relay-reply message. The server unicasts the 3716 Relay-reply message directly to the relay agent using the address in 3717 the source address field from the IP datagram in which the Relay- 3718 forward message was received. See Section 19.3 for more details on 3719 the construction of Relay-reply messages. 3721 18.3.11. Creation and Transmission of Reconfigure Messages 3723 The server sets the "msg-type" field to RECONFIGURE. The server sets 3724 the transaction-id field to 0. The server includes a Server 3725 Identifier option containing its DUID and a Client Identifier option 3726 containing the client's DUID in the Reconfigure message. 3728 Because of the risk of denial of service attacks against DHCP 3729 clients, the use of a security mechanism is mandated in Reconfigure 3730 messages. The server MUST use DHCP authentication in the Reconfigure 3731 message. 3733 The server MUST include a Reconfigure Message option (defined in 3734 Section 21.19) to select whether the client responds with a Renew 3735 message, a Rebind message, or an Information-request message. 3737 The server MUST NOT include any other options in the Reconfigure 3738 except as specifically allowed in the definition of individual 3739 options. 3741 A server sends each Reconfigure message to a single DHCP client, 3742 using an IPv6 unicast address of sufficient scope belonging to the 3743 DHCP client. If the server does not have an address to which it can 3744 send the Reconfigure message directly to the client, the server uses 3745 a Relay-reply message (as described in Section 19.3) to send the 3746 Reconfigure message to a relay agent that will relay the message to 3747 the client. The server may obtain the address of the client (and the 3748 appropriate relay agent, if required) through the information the 3749 server has about clients that have been in contact with the server, 3750 or through some external agent. 3752 To reconfigure more than one client, the server unicasts a separate 3753 message to each client. The server may initiate the reconfiguration 3754 of multiple clients concurrently; for example, a server may send a 3755 Reconfigure message to additional clients while previous 3756 reconfiguration message exchanges are still in progress. 3758 The Reconfigure message causes the client to initiate a Renew/Reply, 3759 a Rebind/Reply, or Information-request/Reply message exchange with 3760 the server. The server interprets the receipt of a Renew, a Rebind, 3761 or Information-request message (whichever was specified in the 3762 original Reconfigure message) from the client as satisfying the 3763 Reconfigure message request. 3765 If the server does not receive a Renew, Rebind, or Information- 3766 request message from the client in REC_TIMEOUT milliseconds, the 3767 server retransmits the Reconfigure message, doubles the REC_TIMEOUT 3768 value and waits again. The server continues this process until 3769 REC_MAX_RC unsuccessful attempts have been made, at which point the 3770 server SHOULD abort the reconfigure process for that client. 3772 Default and initial values for REC_TIMEOUT and REC_MAX_RC are 3773 documented in Section 7.6. 3775 18.4. Reception of Unicast Messages 3777 Unless otherwise stated in sections dedicated to specific messages 3778 reception (see dedicated sections in Section 18.3), the server is not 3779 supposed to accept unicast traffic when it is not explicitly 3780 configured to do so. For some messages (Solicit, Rebind, and 3781 Confirm) unicast transmission is not allowed, even if Server Unicast 3782 option is configured. For Request, Renew, Informaton-request, 3783 Release, and Decline messages, it is allowed only if Server Unicast 3784 option is configured. 3786 When the server receives a message via unicast from a client to which 3787 the server has not sent a Server Unicast option (or is not currently 3788 configured to send a Server Unicast option to the client), the server 3789 discards that message and responds with an Advertise (when responding 3790 to Solicit) or Reply (when responding to any other messages) message 3791 containing a Status Code option with value UseMulticast, a Server 3792 Identifier option containing the server's DUID, the Client Identifier 3793 option from the client message (if any), and no other options. 3795 19. Relay Agent Behavior 3797 The relay agent SHOULD be configured to use a list of destination 3798 addresses, which include unicast addresses. The list of destination 3799 addresses MAY include the All_DHCP_Servers multicast address or other 3800 addresses selected by the network administrator. If the relay agent 3801 has not been explicitly configured, it MUST use the All_DHCP_Servers 3802 multicast address as the default. 3804 If the relay agent relays messages to the All_DHCP_Servers multicast 3805 address or other multicast addresses, it sets the Hop Limit field to 3806 32. 3808 If the relay agent receives a message other than Relay-forward and 3809 Relay-reply and the relay agent does not recognize its message type, 3810 it MUST forward them as described in Section 19.1.1. 3812 19.1. Relaying a Client Message or a Relay-forward Message 3814 A relay agent relays both messages from clients and Relay-forward 3815 messages from other relay agents. When a relay agent receives a 3816 valid message (for a definition of a valid message, see Section 4.1 3817 of [RFC7283]) to be relayed, it constructs a new Relay-forward 3818 message. The relay agent copies the source address from the header 3819 of the IP datagram in which the message was received into the peer- 3820 address field of the Relay-forward message. The relay agent copies 3821 the received DHCP message (excluding any IP or UDP headers) into a 3822 Relay Message option in the new message. The relay agent adds to the 3823 Relay-forward message any other options it is configured to include. 3825 [RFC6221] defines a Lightweight DHCPv6 Relay Agent (LDRA) that allows 3826 Relay Agent Information to be inserted by an access node that 3827 performs a link-layer bridging (i.e., non-routing) function. 3829 19.1.1. Relaying a Message from a Client 3831 If the relay agent received the message to be relayed from a client, 3832 the relay agent places a global address (including unique local 3833 address, [RFC4193]) with a prefix assigned to the link on which the 3834 client should be assigned leases into the link-address field. If 3835 such an address is not available, the relay agent may set the link- 3836 address field to a link-local address from the interface the original 3837 message was received on. That is not recommended as it may require 3838 additional information to be provided in the server configuration. 3839 See Section 3.2 of [RFC7969] for a detailed discussion. 3841 This address will be used by the server to determine the link from 3842 which the client should be assigned leases and other configuration 3843 information. 3845 The hop-count in the Relay-forward message is set to 0. 3847 If the relay agent cannot use the address in the link-address field 3848 to identify the interface through which the response to the client 3849 will be relayed, the relay agent MUST include an Interface-id option 3850 (see Section 21.18) in the Relay-forward message. The server will 3851 include the Interface-id option in its Relay-reply message. The 3852 relay agent sets the link-address field as described in the earlier 3853 paragraphs regardless of whether the relay agent includes an 3854 Interface-id option in the Relay-forward message. 3856 19.1.2. Relaying a Message from a Relay Agent 3858 If the message received by the relay agent is a Relay-forward message 3859 and the hop-count in the message is greater than or equal to 3860 HOP_COUNT_LIMIT, the relay agent discards the received message. 3862 The relay agent copies the source address from the IP datagram in 3863 which the message was received from the relay agent into the peer- 3864 address field in the Relay-forward message and sets the hop-count 3865 field to the value of the hop-count field in the received message 3866 incremented by 1. 3868 If the source address from the IP datagram header of the received 3869 message is a global address (including unique local address, 3870 [RFC4193]), the relay agent sets the link-address field to 0; 3871 otherwise the relay agent sets the link-address field to a global 3872 address (including unique local address) assigned to the interface on 3873 which the message was received, or includes an Interface-ID option to 3874 identify the interface on which the message was received. 3876 19.1.3. Relay Agent Behavior with Prefix Delegation 3878 A relay agent forwards messages containing Prefix Delegation options 3879 in the same way as described earlier in this section. 3881 If a server communicates with a client through a relay agent about 3882 delegated prefixes, the server may need a protocol or other out-of- 3883 band communication to configure routing information for delegated 3884 prefixes on any router through which the client may forward traffic. 3886 19.2. Relaying a Relay-reply Message 3888 The relay agent processes any options included in the Relay-reply 3889 message in addition to the Relay Message option. 3891 The relay agent extracts the message from the Relay Message option 3892 and relays it to the address contained in the peer-address field of 3893 the Relay-reply message. Relay agents MUST NOT modify the message. 3895 If the Relay-reply message includes an Interface-id option, the relay 3896 agent relays the message from the server to the client on the link 3897 identified by the Interface-id option. Otherwise, if the link- 3898 address field is not set to zero, the relay agent relays the message 3899 on the link identified by the link-address field. 3901 If the relay agent receives a Relay-reply message, it MUST process 3902 the message as defined above, regardless of the type of message 3903 encapsulated in the Relay Message option. 3905 19.3. Construction of Relay-reply Messages 3907 A server uses a Relay-reply message to return a response to a client 3908 if the original message from the client was relayed to the server in 3909 a Relay-forward message or to send a Reconfigure message to a client 3910 if the server does not have an address it can use to send the message 3911 directly to the client. 3913 A response to the client MUST be relayed through the same relay 3914 agents as the original client message. The server causes this to 3915 happen by creating a Relay-reply message that includes a Relay 3916 Message option containing the message for the next relay agent in the 3917 return path to the client. The contained Relay-reply message 3918 contains another Relay Message option to be sent to the next relay 3919 agent, and so on. The server must record the contents of the peer- 3920 address fields in the received message so it can construct the 3921 appropriate Relay-reply message carrying the response from the 3922 server. 3924 For example, if client C sent a message that was relayed by relay 3925 agent A to relay agent B and then to the server, the server would 3926 send the following Relay-reply message to relay agent B: 3928 msg-type: RELAY-REPLY 3929 hop-count: 1 3930 link-address: 0 3931 peer-address: A 3932 Relay Message option, containing: 3933 msg-type: RELAY-REPLY 3934 hop-count: 0 3935 link-address: address from link to which C is attached 3936 peer-address: C 3937 Relay Message option: 3939 Figure 10: Relay-reply Example 3941 When sending a Reconfigure message to a client through a relay agent, 3942 the server creates a Relay-reply message that includes a Relay 3943 Message option containing the Reconfigure message for the next relay 3944 agent in the return path to the client. The server sets the peer- 3945 address field in the Relay-reply message header to the address of the 3946 client, and sets the link-address field as required by the relay 3947 agent to relay the Reconfigure message to the client. The server 3948 obtains the addresses of the client and the relay agent through prior 3949 interaction with the client or through some external mechanism. 3951 20. Authentication of DHCP Messages 3953 Within this document, two security mechanisms are introduced for the 3954 authentication of DHCP messages: authentication (and encryption) of 3955 messages sent between servers and relay agents using IPsec, and 3956 protection against misconfiguration of a client caused by a 3957 Reconfigure message sent by a malicious DHCP server. 3959 The delayed authentication protocol, defined in [RFC3315], has been 3960 obsoleted by this document (see Section 25). 3962 20.1. Security of Messages Sent Between Servers and Relay Agents 3964 Relay agents and servers that exchange messages can use IPsec as 3965 detailed in [I-D.ietf-dhc-relay-server-security]. 3967 20.2. Summary of DHCP Authentication 3969 Authentication of DHCP messages is accomplished through the use of 3970 the Authentication option (see Section 21.11). The authentication 3971 information carried in the Authentication option can be used to 3972 reliably identify the source of a DHCP message and to confirm that 3973 the contents of the DHCP message have not been tampered with. 3975 The Authentication option provides a framework for multiple 3976 authentication protocols. One such protocol, the Reconfigure key 3977 authentication protocol, is defined in Section 20.4. Other protocols 3978 defined in the future will be specified in separate documents. 3980 Any DHCP message MUST NOT include more than one Authentication 3981 option. 3983 The protocol field in the Authentication option identifies the 3984 specific protocol used to generate the authentication information 3985 carried in the option. The algorithm field identifies a specific 3986 algorithm within the authentication protocol; for example, the 3987 algorithm field specifies the hash algorithm used to generate the 3988 message authentication code (MAC) in the authentication option. The 3989 replay detection method (RDM) field specifies the type of replay 3990 detection used in the replay detection field. 3992 20.3. Replay Detection 3994 The Replay Detection Method (RDM) field determines the type of replay 3995 detection used in the Replay Detection field. 3997 If the RDM field contains 0x00, the replay detection field MUST be 3998 set to the value of a strictly monotonically increasing counter. 4000 Using a counter value, such as the current time of day (for example, 4001 an NTP-format timestamp [RFC5905]), can reduce the danger of replay 4002 attacks. This method MUST be supported by all protocols. 4004 20.4. Reconfigure Key Authentication Protocol 4006 The Reconfigure key authentication protocol provides protection 4007 against misconfiguration of a client caused by a Reconfigure message 4008 sent by a malicious DHCP server. In this protocol, a DHCP server 4009 sends a Reconfigure Key to the client in the initial exchange of DHCP 4010 messages. The client records the Reconfigure Key for use in 4011 authenticating subsequent Reconfigure messages from that server. The 4012 server then includes an HMAC computed from the Reconfigure Key in 4013 subsequent Reconfigure messages. 4015 Both the Reconfigure Key sent from the server to the client and the 4016 HMAC in subsequent Reconfigure messages are carried as the 4017 Authentication information in an Authentication option. The format 4018 of the Authentication information is defined in the following 4019 section. 4021 The Reconfigure Key protocol is used (initiated by the server) only 4022 if the client and server have negotiated to use Reconfigure messages. 4024 20.4.1. Use of the Authentication Option in the Reconfigure Key 4025 Authentication Protocol 4027 The following fields are set in an Authentication option for the 4028 Reconfigure Key Authentication Protocol: 4030 protocol 3 4032 algorithm 1 4034 RDM 0 4036 The format of the authentication information for the Reconfigure Key 4037 Authentication Protocol is: 4039 0 1 2 3 4040 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 4041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4042 | Type | Value (128 bits) | 4043 +-+-+-+-+-+-+-+-+ | 4044 . . 4045 . . 4046 . +-+-+-+-+-+-+-+-+ 4047 | | 4048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4050 Figure 11: RKAP Authentication Information 4052 Type Type of data in the Value field carried in this 4053 option: 4055 1 Reconfigure Key value (used in Reply 4056 message). 4058 2 HMAC-MD5 digest of the message (used in 4059 Reconfigure message). 4061 A one octet long field. 4063 Value Data as defined by the Type field. A 16 octets 4064 long field. 4066 20.4.2. Server Considerations for Reconfigure Key Authentication 4067 Protocol 4069 The server selects a Reconfigure Key for a client during the Request/ 4070 Reply, Solicit/Reply or Information-request/Reply message exchange. 4071 The server records the Reconfigure Key and transmits that key to the 4072 client in an Authentication option in the Reply message. 4074 The Reconfigure Key is 128 bits long, and MUST be a cryptographically 4075 strong random or pseudo-random number that cannot easily be 4076 predicted. 4078 To provide authentication for a Reconfigure message, the server 4079 selects a replay detection value according to the RDM selected by the 4080 server, and computes an HMAC-MD5 of the Reconfigure message using the 4081 Reconfigure Key for the client. The server computes the HMAC-MD5 4082 over the entire DHCP Reconfigure message, including the 4083 Authentication option; the HMAC-MD5 field in the Authentication 4084 option is set to zero for the HMAC-MD5 computation. The server 4085 includes the HMAC-MD5 in the authentication information field in an 4086 Authentication option included in the Reconfigure message sent to the 4087 client. 4089 20.4.3. Client Considerations for Reconfigure Key Authentication 4090 Protocol 4092 The client will receive a Reconfigure Key from the server in an 4093 Authentication option in the initial Reply message from the server. 4094 The client records the Reconfigure Key for use in authenticating 4095 subsequent Reconfigure messages. 4097 To authenticate a Reconfigure message, the client computes an HMAC- 4098 MD5 over the DHCP Reconfigure message, using the Reconfigure Key 4099 received from the server. If this computed HMAC-MD5 matches the 4100 value in the Authentication option, the client accepts the 4101 Reconfigure message. 4103 21. DHCP Options 4105 Options are used to carry additional information and parameters in 4106 DHCP messages. Every option shares a common base format, as 4107 described in Section 21.1. All values in options are represented in 4108 network byte order. 4110 This document describes the DHCP options defined as part of the base 4111 DHCP specification. Other options may be defined in the future in 4112 separate documents. See [RFC7227] for guidelines regarding new 4113 options definition. See Section 24 for additional information about 4114 a registry maintained by IANA. 4116 Unless otherwise noted, each option may appear only in the options 4117 area of a DHCP message and may appear only once. If an option does 4118 appear multiple times, each instance is considered separate and the 4119 data areas of the options MUST NOT be concatenated or otherwise 4120 combined. 4122 Options that are allowed to appear only once are called singleton 4123 options. The only non-singleton options defined in this document are 4124 IA_NA (see Section 21.4), IA_TA (see Section 21.5), Vendor Class (see 4125 Section 21.16), Vendor-specific Information (see Section 21.17), and 4126 IA_PD (see Section 21.21) options. Also, IA Address (see 4127 Section 21.6) and IA Prefix (see Section 21.22) may appear in their 4128 respective IA options more than once. 4130 21.1. Format of DHCP Options 4132 The format of DHCP options is: 4134 0 1 2 3 4135 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 4136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4137 | option-code | option-len | 4138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4139 | option-data | 4140 | (option-len octets) | 4141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4143 Figure 12: Option Format 4145 option-code An unsigned integer identifying the specific 4146 option type carried in this option. A two 4147 octets long field. 4149 option-len An unsigned integer giving the length of the 4150 option-data field in this option in octets. 4151 A two octets long field. 4153 option-data The data for the option; the format of this 4154 data depends on the definition of the option. 4155 A variable length field (the length, in 4156 octets, is specified by option-len). 4158 DHCP options are scoped by using encapsulation. Some options apply 4159 generally to the client, some are specific to an IA, and some are 4160 specific to the addresses within an IA. These latter two cases are 4161 discussed in Section 21.4 and Section 21.6. 4163 21.2. Client Identifier Option 4165 The Client Identifier option is used to carry a DUID (see Section 11) 4166 identifying a client between a client and a server. The format of 4167 the Client Identifier option is: 4169 0 1 2 3 4170 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 4171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4172 | OPTION_CLIENTID | option-len | 4173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4174 . . 4175 . DUID . 4176 . (variable length) . 4177 . . 4178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4180 Figure 13: Client Identifier Option Format 4182 option-code OPTION_CLIENTID (1). 4184 option-len Length of DUID in octets. 4186 DUID The DUID for the client. 4188 21.3. Server Identifier Option 4190 The Server Identifier option is used to carry a DUID (see Section 11) 4191 identifying a server between a client and a server. The format of 4192 the Server Identifier option is: 4194 0 1 2 3 4195 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 4196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4197 | OPTION_SERVERID | option-len | 4198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4199 . . 4200 . DUID . 4201 . (variable length) . 4202 . . 4203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4205 Figure 14: Server Identifier Option Format 4207 option-code OPTION_SERVERID (2). 4209 option-len Length of DUID in octets. 4211 DUID The DUID for the server. 4213 21.4. Identity Association for Non-temporary Addresses Option 4215 The Identity Association for Non-temporary Addresses option (IA_NA 4216 option) is used to carry an IA_NA, the parameters associated with the 4217 IA_NA, and the non-temporary addresses associated with the IA_NA. 4219 Addresses appearing in an IA_NA option are not temporary addresses 4220 (see Section 21.5). 4222 The format of the IA_NA option is: 4224 0 1 2 3 4225 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 4226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4227 | OPTION_IA_NA | option-len | 4228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4229 | IAID (4 octets) | 4230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4231 | T1 | 4232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4233 | T2 | 4234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4235 | | 4236 . IA_NA-options . 4237 . . 4238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4240 Figure 15: Identity Association for Non-temporary Addresses Option 4241 Format 4243 option-code OPTION_IA_NA (3). 4245 option-len 12 + length of IA_NA-options field. 4247 IAID The unique identifier for this IA_NA; the 4248 IAID must be unique among the identifiers for 4249 all of this client's IA_NAs. The number 4250 space for IA_NA IAIDs is separate from the 4251 number space for other IA option types (i.e., 4252 IA_TA and IA_PD). A four octets long field. 4254 T1 The time at which the client should contact 4255 the server from which the addresses in the 4256 IA_NA were obtained to extend the lifetimes 4257 of the addresses assigned to the IA_NA; T1 is 4258 a time duration relative to the current time 4259 expressed in units of seconds. A four octets 4260 long field. 4262 T2 The time at which the client should contact 4263 any available server to extend the lifetimes 4264 of the addresses assigned to the IA_NA; T2 is 4265 a time duration relative to the current time 4266 expressed in units of seconds. A four octets 4267 long field. 4269 IA_NA-options Options associated with this IA_NA. A 4270 variable length field (12 octets less than 4271 the value in the option-len field). 4273 The IA_NA-options field encapsulates those options that are specific 4274 to this IA_NA. For example, all of the IA Address options carrying 4275 the addresses associated with this IA_NA are in the IA_NA-options 4276 field. 4278 Each IA_NA carries one "set" of non-temporary addresses; it is up to 4279 the server policy to determine how many addresses are assigned, but 4280 typically at most one address is assigned from each prefix assigned 4281 to the link to which the client is attached to. 4283 An IA_NA option may only appear in the options area of a DHCP 4284 message. A DHCP message may contain multiple IA_NA options (though 4285 each must have a unique IAID). 4287 The status of any operations involving this IA_NA is indicated in a 4288 Status Code option in the IA_NA-options field. 4290 Note that an IA_NA has no explicit "lifetime" or "lease length" of 4291 its own. When the valid lifetimes of all of the addresses in an 4292 IA_NA have expired, the IA_NA can be considered as having expired. 4293 T1 and T2 are included to give servers explicit control over when a 4294 client recontacts the server about a specific IA_NA. 4296 In a message sent by a client to a server, the T1 and T2 fields 4297 SHOULD be set to 0. The server MUST ignore any values in these 4298 fields in messages received from a client. 4300 In a message sent by a server to a client, the client MUST use the 4301 values in the T1 and T2 fields for the T1 and T2 parameters, unless 4302 those values in those fields are 0. The values in the T1 and T2 4303 fields are the number of seconds until T1 and T2. 4305 The server selects the T1 and T2 times to allow the client to extend 4306 the lifetimes of any addresses in the IA_NA before the lifetimes 4307 expire, even if the server is unavailable for some short period of 4308 time. Recommended values for T1 and T2 are .5 and .8 times the 4309 shortest preferred lifetime of the addresses in the IA that the 4310 server is willing to extend, respectively. If the "shortest" 4311 preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and 4312 T2 values are also 0xffffffff. If the time at which the addresses in 4313 an IA_NA are to be renewed is to be left to the discretion of the 4314 client, the server sets T1 and T2 to 0. The client MUST follow the 4315 rules defined in Section 14.2. 4317 If a client receives an IA_NA with T1 greater than T2, and both T1 4318 and T2 are greater than 0, the client discards the IA_NA option and 4319 processes the remainder of the message as though the server had not 4320 included the invalid IA_NA option. 4322 As per Section 7.7, the value 0xffffffff is taken to ("infinity") and 4323 should be used carefully. 4325 21.5. Identity Association for Temporary Addresses Option 4327 The Identity Association for the Temporary Addresses (IA_TA) option 4328 is used to carry an IA_TA, the parameters associated with the IA_TA 4329 and the addresses associated with the IA_TA. All of the addresses in 4330 this option are used by the client as temporary addresses, as defined 4331 in [RFC4941]. The format of the IA_TA option is: 4333 0 1 2 3 4334 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 4335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4336 | OPTION_IA_TA | option-len | 4337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4338 | IAID (4 octets) | 4339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4340 | | 4341 . IA_TA-options . 4342 . . 4343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4345 Figure 16: Identity Association for Temporary Addresses Option Format 4347 option-code OPTION_IA_TA (4). 4349 option-len 4 + length of IA_TA-options field. 4351 IAID The unique identifier for this IA_TA; the 4352 IAID must be unique among the identifiers for 4353 all of this client's IA_TAs. The number 4354 space for IA_TA IAIDs is separate from the 4355 number space for other IA option types (i.e., 4356 IA_NA and IA_PD). A four octets long field. 4358 IA_TA-options Options associated with this IA_TA. A 4359 variable length field (4 octets less than the 4360 value in the option-len field). 4362 The IA_TA-Options field encapsulates those options that are specific 4363 to this IA_TA. For example, all of the IA Address options carrying 4364 the addresses associated with this IA_TA are in the IA_TA-options 4365 field. 4367 Each IA_TA carries one "set" of temporary addresses. It is up to the 4368 server policy to determine how many addresses are assigned. 4370 An IA_TA option may only appear in the options area of a DHCP 4371 message. A DHCP message may contain multiple IA_TA options (though 4372 each must have a unique IAID). 4374 The status of any operations involving this IA_TA is indicated in a 4375 Status Code option in the IA_TA-options field. 4377 Note that an IA has no explicit "lifetime" or "lease length" of its 4378 own. When the valid lifetimes of all of the addresses in an IA_TA 4379 have expired, the IA can be considered as having expired. 4381 An IA_TA option does not include values for T1 and T2. A client MAY 4382 request that the valid lifetime on temporary addresses be extended by 4383 including the addresses in a IA_TA option sent in a Renew or Rebind 4384 message to a server. For example, a client would request an 4385 extension on the valid lifetime of a temporary address to allow an 4386 application to continue to use an established TCP connection. 4387 Extending only the valid, but not the preferred lifetime means the 4388 address will end up in deprecated state eventually. Existing 4389 connections could continue, but no new ones would be created using 4390 that address. 4392 The client obtains new temporary addresses by sending an IA_TA option 4393 with a new IAID to a server. Requesting new temporary addresses from 4394 the server is the equivalent of generating new temporary addresses as 4395 described in [RFC4941]. The server will generate new temporary 4396 addresses and return them to the client. The client should request 4397 new temporary addresses before the lifetimes on the previously 4398 assigned addresses expire. 4400 A server MUST return the same set of temporary address for the same 4401 IA_TA (as identified by the IAID) as long as those addresses are 4402 still valid. After the lifetimes of the addresses in an IA_TA have 4403 expired, the IAID may be reused to identify a new IA_TA with new 4404 temporary addresses. 4406 21.6. IA Address Option 4408 The IA Address option is used to specify an address associated with 4409 an IA_NA or an IA_TA. The IA Address option must be encapsulated in 4410 the Options field of an IA_NA or IA_TA option. The IAaddr-options 4411 fields encapsulates those options that are specific to this address. 4413 The format of the IA Address option is: 4415 0 1 2 3 4416 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 4417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4418 | OPTION_IAADDR | option-len | 4419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4420 | | 4421 | IPv6-address | 4422 | | 4423 | | 4424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4425 | preferred-lifetime | 4426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4427 | valid-lifetime | 4428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4429 . . 4430 . IAaddr-options . 4431 . . 4432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4434 Figure 17: IA Address Option Format 4436 option-code OPTION_IAADDR (5). 4438 option-len 24 + length of IAaddr-options field. 4440 IPv6-address An IPv6 address. A client MUST NOT form an 4441 implicit prefix with a length other than 128 4442 for this address. And, a client MUST NOT 4443 assume any length of prefix that matches this 4444 address is on-link (see [RFC7421]). A 16 4445 octets long field. 4447 preferred-lifetime The preferred lifetime for the address in the 4448 option, expressed in units of seconds. A 4449 four octets long field. 4451 valid-lifetime The valid lifetime for the address in the 4452 option, expressed in units of seconds. A 4453 four octets long field. 4455 IAaddr-options Options associated with this address. A 4456 variable length field (24 octets less than 4457 the value in the option-len field). 4459 In a message sent by a client to a server, the preferred and valid 4460 lifetime fields SHOULD be set to 0. The server MUST ignore any 4461 received values. 4463 The client SHOULD NOT send the IA Address option with an unspecified 4464 address (::). 4466 In a message sent by a server to a client, the client MUST use the 4467 values in the preferred and valid lifetime fields for the preferred 4468 and valid lifetimes. The values in the preferred and valid lifetimes 4469 are the number of seconds remaining in each lifetime. 4471 The client MUST discard any addresses for which the preferred 4472 lifetime is greater than the valid lifetime. 4474 As per Section 7.7, the valid lifetime of an address 0xffffffff is 4475 taken to mean "infinity" and should be used carefully. 4477 More than one IA Address option can appear in an IA_NA option or an 4478 IA_TA option. 4480 The status of any operations involving this IA Address is indicated 4481 in a Status Code option in the IAaddr-options field, as specified in 4482 Section 21.13. 4484 21.7. Option Request Option 4486 The Option Request option is used to identify a list of options in a 4487 message between a client and a server. The format of the Option 4488 Request option is: 4490 0 1 2 3 4491 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 4492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4493 | OPTION_ORO | option-len | 4494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4495 | requested-option-code-1 | requested-option-code-2 | 4496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4497 | ... | 4498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4500 Figure 18: Option Request Option Format 4502 option-code OPTION_ORO (6). 4504 option-len 2 * number of requested options. 4506 requested-option-code-n The option code for an option requested 4507 by the client. The length, in octets, is 4508 specified by option-len. 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. For 4513 certain message types, some option codes MUST be included in the 4514 Option Request option, see Table 1 for details. 4516 The Option Request option MUST NOT include the following options: 4517 Server Identifier, Client Identifier, IA_NA, IA_PD, IA_TA, IA 4518 Address, IA Prefix, Option Request, Elapsed Time, Preference, Relay 4519 Message, Authentication, Server Unicast, Rapid Commit, User Class, 4520 Vendor Class, Interface-Id, Reconfigure Message, and Reconfigure 4521 Accept. Other top-level options MUST appear in the Option Request 4522 option or they will not be sent by the server. Only top-level 4523 options MAY appear in the Option Request option. Options 4524 encapsulated in a container option SHOULD NOT appear in an Option 4525 Request option; see [RFC7598] for an example of container options. 4526 However, options MAY be defined which specify exceptions to this 4527 restriction on including encapsulated options in an Option Request 4528 option. For example, the Option Request option MAY be used to signal 4529 support for a feature even when that option is encapsulated, as in 4530 the case of the Prefix Exclude option [RFC6603]. See Table 1. 4532 21.8. Preference Option 4534 The Preference option is sent by a server to a client to affect the 4535 selection of a server by the client. 4537 The format of the Preference option is: 4539 0 1 2 3 4540 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 4541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4542 | OPTION_PREFERENCE | option-len | 4543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4544 | pref-value | 4545 +-+-+-+-+-+-+-+-+ 4547 Figure 19: Preference Option Format 4549 option-code OPTION_PREFERENCE (7). 4551 option-len 1. 4553 pref-value The preference value for the server in this 4554 message. A one octet long field. 4556 A server MAY include a Preference option in an Advertise message to 4557 control the selection of a server by the client. See Section 18.2.9 4558 for the use of the Preference option by the client and the 4559 interpretation of Preference option data value. 4561 21.9. Elapsed Time Option 4563 0 1 2 3 4564 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 4565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4566 | OPTION_ELAPSED_TIME | option-len | 4567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4568 | elapsed-time | 4569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4571 Figure 20: Elapsed Time Option Format 4573 option-code OPTION_ELAPSED_TIME (8). 4575 option-len 2. 4577 elapsed-time The amount of time since the client began its 4578 current DHCP transaction. This time is 4579 expressed in hundredths of a second (10^-2 4580 seconds). A two octets long field. 4582 A client MUST include an Elapsed Time option in messages to indicate 4583 how long the client has been trying to complete a DHCP message 4584 exchange. The elapsed time is measured from the time at which the 4585 client sent the first message in the message exchange, and the 4586 elapsed-time field is set to 0 in the first message in the message 4587 exchange. Servers and Relay Agents use the data value in this option 4588 as input to policy controlling how a server responds to a client 4589 message. For example, the elapsed time option allows a secondary 4590 DHCP server to respond to a request when a primary server has not 4591 answered in a reasonable time. The elapsed time value is an 4592 unsigned, 16 bit integer. The client uses the value 0xffff to 4593 represent any elapsed time values greater than the largest time value 4594 that can be represented in the Elapsed Time option. 4596 21.10. Relay Message Option 4598 The Relay Message option carries a DHCP message in a Relay-forward or 4599 Relay-reply message. 4601 The format of the Relay Message option is: 4603 0 1 2 3 4604 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 4605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4606 | OPTION_RELAY_MSG | option-len | 4607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4608 | | 4609 . DHCP-relay-message . 4610 . . 4611 . . 4612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4614 Figure 21: Relay Message Option Format 4616 option-code OPTION_RELAY_MSG (9). 4618 option-len Length of DHCP-relay-message. 4620 DHCP-relay-message In a Relay-forward message, the received 4621 message, relayed verbatim to the next relay 4622 agent or server; in a Relay-reply message, 4623 the message to be copied and relayed to the 4624 relay agent or client whose address is in the 4625 peer-address field of the Relay-reply 4626 message. The length, in octets, is specified 4627 by option-len. 4629 21.11. Authentication Option 4631 The Authentication option carries authentication information to 4632 authenticate the identity and contents of DHCP messages. The use of 4633 the Authentication option is described in Section 20. The delayed 4634 authentication protocol, defined in [RFC3315], has been obsoleted by 4635 this document, due to lack of usage. The format of the 4636 Authentication option is: 4638 0 1 2 3 4639 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 4640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4641 | OPTION_AUTH | option-len | 4642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4643 | protocol | algorithm | RDM | | 4644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4645 | | 4646 | replay detection (64 bits) +-+-+-+-+-+-+-+-+ 4647 | | | 4648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4649 . authentication information . 4650 . (variable length) . 4651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4653 Figure 22: Authentication Option Format 4655 option-code OPTION_AUTH (11). 4657 option-len 11 + length of authentication information 4658 field. 4660 protocol The authentication protocol used in this 4661 authentication option. A one octet long 4662 field. 4664 algorithm The algorithm used in the authentication 4665 protocol. A one octet long field. 4667 RDM The replay detection method used in this 4668 authentication option. A one octet long 4669 field. 4671 Replay detection The replay detection information for the RDM. 4672 A 64-bit (8 octets) long field 4674 authentication information The authentication information, as 4675 specified by the protocol and algorithm used 4676 in this authentication option. A variable 4677 length field (11 octets less than the value 4678 in option-len). 4680 21.12. Server Unicast Option 4682 The server sends this option to a client to indicate to the client 4683 that it is allowed to unicast messages to the server. The format of 4684 the Server Unicast option is: 4686 0 1 2 3 4687 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 4688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4689 | OPTION_UNICAST | option-len | 4690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4691 | | 4692 | server-address | 4693 | | 4694 | | 4695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4697 Figure 23: Server Unicast Option Format 4699 option-code OPTION_UNICAST (12). 4701 option-len 16. 4703 server-address The 128-bit address to which the client 4704 should send messages delivered using unicast. 4706 The server specifies the address to which the client is to send 4707 unicast messages in the server-address field. When a client receives 4708 this option, where permissible and appropriate, the client sends 4709 messages directly to the server using the address specified in the 4710 server-address field of the option. 4712 When the server sends a Unicast option to the client, some messages 4713 from the client will not be relayed by Relay Agents, and will not 4714 include Relay Agent options from the Relay Agents. Therefore, a 4715 server should only send a Unicast option to a client when Relay 4716 Agents are not sending Relay Agent options. A DHCP server rejects 4717 any messages sent inappropriately using unicast to ensure that 4718 messages are relayed by Relay Agents when Relay Agent options are in 4719 use. 4721 Details about when the client may send messages to the server using 4722 unicast are in Section 18. 4724 21.13. Status Code Option 4726 This option returns a status indication related to the DHCP message 4727 or option in which it appears. The format of the Status Code option 4728 is: 4730 0 1 2 3 4731 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 4732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4733 | OPTION_STATUS_CODE | option-len | 4734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4735 | status-code | | 4736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4737 . . 4738 . status-message . 4739 . . 4740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4742 Figure 24: Status Code Option Format 4744 option-code OPTION_STATUS_CODE (13). 4746 option-len 2 + length of status-message. 4748 status-code The numeric code for the status encoded in 4749 this option. A two octets long field. 4751 status-message A UTF-8 encoded text string suitable for 4752 display to an end user, which MUST NOT be 4753 null-terminated. A variable length field (2 4754 octets less than the value in option-len). 4756 A Status Code option may appear in the options field of a DHCP 4757 message and/or in the options field of another option. If the Status 4758 Code option does not appear in a message in which the option could 4759 appear, the status of the message is assumed to be Success. 4761 The status-code values previously defined by [RFC3315] and [RFC3633] 4762 are: 4764 +---------------+------+--------------------------------------------+ 4765 | Name | Code | Description | 4766 +---------------+------+--------------------------------------------+ 4767 | Success | 0 | Success. | 4768 | UnspecFail | 1 | Failure, reason unspecified; this status | 4769 | | | code is sent by either a client or a | 4770 | | | server to indicate a failure not | 4771 | | | explicitly specified in this document. | 4772 | NoAddrsAvail | 2 | Server has no addresses available to | 4773 | | | assign to the IA(s). | 4774 | NoBinding | 3 | Client record (binding) unavailable. | 4775 | NotOnLink | 4 | The prefix for the address is not | 4776 | | | appropriate for the link to which the | 4777 | | | client is attached. | 4778 | UseMulticast | 5 | Sent by a server to a client to force the | 4779 | | | client to send messages to the server | 4780 | | | using the | 4781 | | | All_DHCP_Relay_Agents_and_Servers | 4782 | | | multicast address. | 4783 | NoPrefixAvail | 6 | Server has no prefixes available to assign | 4784 | | | to the IA_PD(s). | 4785 +---------------+------+--------------------------------------------+ 4787 See Section 24 for additional information about the registry 4788 maintained by IANA with the complete list of status codes. 4790 21.14. Rapid Commit Option 4792 The Rapid Commit option is used to signal the use of the two message 4793 exchange for address assignment. The format of the Rapid Commit 4794 option is: 4796 0 1 2 3 4797 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 4798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4799 | OPTION_RAPID_COMMIT | 0 | 4800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4802 Figure 25: Rapid Commit Option Format 4804 option-code OPTION_RAPID_COMMIT (14). 4806 option-len 0. 4808 A client MAY include this option in a Solicit message if the client 4809 is prepared to perform the Solicit/Reply message exchange described 4810 in Section 18.2.1. 4812 A server MUST include this option in a Reply message sent in response 4813 to a Solicit message when completing the Solicit/Reply message 4814 exchange. 4816 DISCUSSION: 4818 Each server that responds with a Reply to a Solicit that includes 4819 a Rapid Commit option will commit the leases in the Reply message 4820 to the client, and will not receive any confirmation that the 4821 client has received the Reply message. Therefore, if more than 4822 one server responds to a Solicit that includes a Rapid Commit 4823 option, some servers will commit leases that are not actually used 4824 by the client, which could result in bad information in the DNS 4825 server if the DHCP server updates DNS [RFC4704] or in response to 4826 leasequery requests [RFC5007]. 4828 The problem of unused leases can be minimized by designing the 4829 DHCP service so that only one server responds to the Solicit, by 4830 using relatively short lifetimes for newly assigned leases, or by 4831 having DHCP clients release unused leases using the Release 4832 message. 4834 21.15. User Class Option 4836 The User Class option is used by a client to identify the type or 4837 category of user or applications it represents. 4839 The format of the User Class option is: 4841 0 1 2 3 4842 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 4843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4844 | OPTION_USER_CLASS | option-len | 4845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4846 . . 4847 . user-class-data . 4848 . . 4849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4851 Figure 26: User Class Option Format 4853 option-code OPTION_USER_CLASS (15). 4855 option-len Length of user class data field. 4857 user-class-data The user classes carried by the client. The 4858 length, in octets, is specified by option- 4859 len. 4861 The information contained in the data area of this option is 4862 contained in one or more opaque fields that represent the user class 4863 or classes of which the client is a member. A server selects 4864 configuration information for the client based on the classes 4865 identified in this option. For example, the User Class option can be 4866 used to configure all clients of people in the accounting department 4867 with a different printer than clients of people in the marketing 4868 department. The user class information carried in this option MUST 4869 be configurable on the client. 4871 The data area of the user class option MUST contain one or more 4872 instances of user class data. Each instance of the user class data 4873 is formatted as follows: 4875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4876 | user-class-len | opaque-data | 4877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4879 Figure 27: User Class Data Format 4881 The user-class-len is two octets long and specifies the length of the 4882 opaque user class data in network byte order. 4884 A server interprets the classes identified in this option according 4885 to its configuration to select the appropriate configuration 4886 information for the client. A server may use only those user classes 4887 that it is configured to interpret in selecting configuration 4888 information for a client and ignore any other user classes. In 4889 response to a message containing a User Class option, a server 4890 includes a User Class option containing those classes that were 4891 successfully interpreted by the server, so that the client can be 4892 informed of the classes interpreted by the server. 4894 21.16. Vendor Class Option 4896 This option is used by a client to identify the vendor that 4897 manufactured the hardware on which the client is running. The 4898 information contained in the data area of this option is contained in 4899 one or more opaque fields that identify details of the hardware 4900 configuration. The format of the Vendor Class option is: 4902 0 1 2 3 4903 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 4904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4905 | OPTION_VENDOR_CLASS | option-len | 4906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4907 | enterprise-number | 4908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4909 . . 4910 . vendor-class-data . 4911 . . . . . 4912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4914 Figure 28: Vendor Class Option Format 4916 option-code OPTION_VENDOR_CLASS (16). 4918 option-len 4 + length of vendor class data field. 4920 enterprise-number The vendor's registered Enterprise Number as 4921 registered with IANA [IANA-PEN]. A four 4922 octets long field. 4924 vendor-class-data The hardware configuration of the node on 4925 which the client is running. A variable 4926 length field (4 octets less than the value in 4927 option-len). 4929 The vendor-class-data is composed of a series of separate items, each 4930 of which describes some characteristic of the client's hardware 4931 configuration. Examples of vendor-class-data instances might include 4932 the version of the operating system the client is running or the 4933 amount of memory installed on the client. 4935 Each instance of the vendor-class-data is formatted as follows: 4937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4938 | vendor-class-len | opaque-data | 4939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4941 Figure 29: Vendor Class Data Format 4943 The vendor-class-len is two octets long and specifies the length of 4944 the opaque vendor class data in network byte order. 4946 Servers and clients MUST NOT include more than one instance of 4947 OPTION_VENDOR_CLASS with the same Enterprise Number. Each instance 4948 of OPTION_VENDOR_CLASS can carry multiple vendor-class-data 4949 instances. 4951 21.17. Vendor-specific Information Option 4953 This option is used by clients and servers to exchange vendor- 4954 specific information. 4956 The format of the Vendor-specific Information option is: 4958 0 1 2 3 4959 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 4960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4961 | OPTION_VENDOR_OPTS | option-len | 4962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4963 | enterprise-number | 4964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4965 . . 4966 . vendor-option-data . 4967 . . 4968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4970 Figure 30: Vendor-specific Information Option Format 4972 option-code OPTION_VENDOR_OPTS (17). 4974 option-len 4 + length of option-data field. 4976 enterprise-number The vendor's registered Enterprise Number as 4977 registered with IANA [IANA-PEN]. A four 4978 octets long field. 4980 vendor-option-data Vendor options, interpreted by vendor- 4981 specific code on the clients and servers. A 4982 variable length field (4 octets less than the 4983 value in option-len). 4985 The definition of the information carried in this option is vendor 4986 specific. The vendor is indicated in the enterprise-number field. 4987 Use of vendor-specific information allows enhanced operation, 4988 utilizing additional features in a vendor's DHCP implementation. A 4989 DHCP client that does not receive requested vendor-specific 4990 information will still configure the node device's IPv6 stack to be 4991 functional. 4993 The vendor-option-data field MUST be encoded as a sequence of 4994 code/length/value fields of identical format to the DHCP options 4995 field. The sub-option codes are defined by the vendor identified in 4996 the enterprise-number field, and are not managed by IANA. Each of 4997 the sub-options is formatted as follows: 4999 0 1 2 3 5000 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 5001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5002 | sub-opt-code | sub-option-len | 5003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5004 . . 5005 . sub-option-data . 5006 . . 5007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5009 Figure 31: Vendor-specific Options Format 5011 sub-opt-code The code for the sub-option. A two octets 5012 long field. 5014 sub-option-len An unsigned integer giving the length of the 5015 sub-option-data field in this sub-option in 5016 octets. A two octets long field. 5018 sub-option-data The data area for the sub-option. The 5019 length, in octets, is specified by sub- 5020 option-len. 5022 Multiple instances of the Vendor-specific Information option may 5023 appear in a DHCP message. Each instance of the option is interpreted 5024 according to the option codes defined by the vendor identified by the 5025 Enterprise Number in that option. Servers and clients MUST NOT send 5026 more than one instance of Vendor-specific Information option with the 5027 same Enterprise Number. Each instance of Vendor-specific Information 5028 option MAY contain multiple sub-options. 5030 A client that is interested in receiving a Vendor-specific 5031 Information option: 5033 - MUST specify the Vendor-specific Information option in an Option 5034 Request option. 5036 - MAY specify an associated Vendor Class option. 5038 - MAY specify the Vendor-specific Information option with 5039 appropriate data. 5041 Servers only return the Vendor-specific Information options if 5042 specified in Option Request options from clients and: 5044 - MAY use the Enterprise Numbers in the associated Vendor Class 5045 options to restrict the set of Enterprise Numbers in the Vendor- 5046 specific Information options returned. 5048 - MAY return all configured Vendor-specific Information options. 5050 - MAY use other information in the packet or in its configuration to 5051 determine which set of Enterprise Numbers in the Vendor-specific 5052 Information options to return. 5054 21.18. Interface-Id Option 5056 The relay agent MAY send the Interface-id option to identify the 5057 interface on which the client message was received. If a relay agent 5058 receives a Relay-reply message with an Interface-id option, the relay 5059 agent relays the message to the client through the interface 5060 identified by the option. 5062 The format of the Interface ID option is: 5064 0 1 2 3 5065 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 5066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5067 | OPTION_INTERFACE_ID | option-len | 5068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5069 . . 5070 . interface-id . 5071 . . 5072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5074 Figure 32: Interface-ID Option Format 5076 option-code OPTION_INTERFACE_ID (18). 5078 option-len Length of interface-id field. 5080 interface-id An opaque value of arbitrary length generated 5081 by the relay agent to identify one of the 5082 relay agent's interfaces. The length, in 5083 octets, is specified by option-len. 5085 The server MUST copy the Interface-Id option from the Relay-forward 5086 message into the Relay-reply message the server sends to the relay 5087 agent in response to the Relay-forward message. This option MUST NOT 5088 appear in any message except a Relay-forward or Relay-reply message. 5090 Servers MAY use the Interface-ID for parameter assignment policies. 5091 The Interface-ID SHOULD be considered an opaque value, with policies 5092 based on exact match only; that is, the Interface-ID SHOULD NOT be 5093 internally parsed by the server. The Interface-ID value for an 5094 interface SHOULD be stable and remain unchanged, for example, after 5095 the relay agent is restarted; if the Interface-ID changes, a server 5096 will not be able to use it reliably in parameter assignment policies. 5098 21.19. Reconfigure Message Option 5100 A server includes a Reconfigure Message option in a Reconfigure 5101 message to indicate to the client whether the client responds with a 5102 Renew message, a Rebind message, or an Information-request message. 5103 The format of this option is: 5105 0 1 2 3 5106 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 5107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5108 | OPTION_RECONF_MSG | option-len | 5109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5110 | msg-type | 5111 +-+-+-+-+-+-+-+-+ 5113 Figure 33: Reconfigure Message Option Format 5115 option-code OPTION_RECONF_MSG (19). 5117 option-len 1. 5119 msg-type 5 for Renew message, 6 for Rebind, 11 for 5120 Information-request message. A one octet 5121 long field. 5123 The Reconfigure Message option can only appear in a Reconfigure 5124 message. 5126 21.20. Reconfigure Accept Option 5128 A client uses the Reconfigure Accept option to announce to the server 5129 whether the client is willing to accept Reconfigure messages, and a 5130 server uses this option to tell the client whether or not to accept 5131 Reconfigure messages. The default behavior, in the absence of this 5132 option, means unwillingness to accept Reconfigure messages, or 5133 instruction not to accept Reconfigure messages, for the client and 5134 server messages, respectively. The following figure gives the format 5135 of the Reconfigure Accept option: 5137 0 1 2 3 5138 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 5139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5140 | OPTION_RECONF_ACCEPT | 0 | 5141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5143 Figure 34: Reconfigure Accept Option Format 5145 option-code OPTION_RECONF_ACCEPT (20). 5147 option-len 0. 5149 21.21. Identity Association for Prefix Delegation Option 5151 The IA_PD option is used to carry a prefix delegation identity 5152 association, the parameters associated with the IA_PD and the 5153 prefixes associated with it. The format of this option is: 5155 0 1 2 3 5156 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 5157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5158 | OPTION_IA_PD | option-length | 5159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5160 | IAID (4 octets) | 5161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5162 | T1 | 5163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5164 | T2 | 5165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5166 . . 5167 . IA_PD-options . 5168 . . 5169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5171 Figure 35: Identity Association for Prefix Delegation Option Format 5173 option-code OPTION_IA_PD (25). 5175 option-length 12 + length of IA_PD-options field. 5177 IAID The unique identifier for this IA_PD; the 5178 IAID must be unique among the identifiers for 5179 all of this client's IA_PDs. The number 5180 space for IA_PD IAIDs is separate from the 5181 number space for other IA option types (i.e., 5182 IA_NA and IA_TA). A four octets long field. 5184 T1 The time at which the client should contact 5185 the server from which the prefixes in the 5186 IA_PD were obtained to extend the lifetimes 5187 of the prefixes delegated to the IA_PD; T1 is 5188 a time duration relative to the current time 5189 expressed in units of seconds. A four octets 5190 long field. 5192 T2 The time at which the client should contact 5193 any available server to extend the lifetimes 5194 of the prefixes assigned to the IA_PD; T2 is 5195 a time duration relative to the current time 5196 expressed in units of seconds. A four octets 5197 long field. 5199 IA_PD-options Options associated with this IA_PD. A 5200 variable length field (12 octets less than 5201 the value in the option-len field). 5203 The IA_PD-options field encapsulates those options that are specific 5204 to this IA_PD. For example, all of the IA Prefix options carrying 5205 the prefixes associated with this IA_PD are in the IA_PD-options 5206 field. 5208 An IA_PD option may only appear in the options area of a DHCP 5209 message. A DHCP message may contain multiple IA_PD options (though 5210 each must have a unique IAID). 5212 The status of any operations involving this IA_PD is indicated in a 5213 Status Code option in the IA_PD-options field. 5215 Note that an IA_PD has no explicit "lifetime" or "lease length" of 5216 its own. When the valid lifetimes of all of the prefixes in a IA_PD 5217 have expired, the IA_PD can be considered as having expired. T1 and 5218 T2 are included to give the server explicit control over when a 5219 client should contact the server about a specific IA_PD. 5221 In a message sent by a client to a server, the T1 and T2 fields 5222 SHOULD be set to 0. The server MUST ignore any values in these 5223 fields in messages received from a client. 5225 In a message sent by a server to a client, the client MUST use the 5226 values in the T1 and T2 fields for the T1 and T2 parameters, unless 5227 those values in those fields are 0. The values in the T1 and T2 5228 fields are the number of seconds until T1 and T2. 5230 The server selects the T1 and T2 times to allow the client to extend 5231 the lifetimes of any prefixes in the IA_PD before the lifetimes 5232 expire, even if the server is unavailable for some short period of 5233 time. Recommended values for T1 and T2 are .5 and .8 times the 5234 shortest preferred lifetime of the prefixes in the IA_PD that the 5235 server is willing to extend, respectively. If the time at which the 5236 prefixes in an IA_PD are to be renewed is to be left to the 5237 discretion of the client, the server sets T1 and T2 to 0. The client 5238 MUST follow the rules defined in Section 14.2. 5240 If a client receives an IA_PD with T1 greater than T2, and both T1 5241 and T2 are greater than 0, the client discards the IA_PD option and 5242 processes the remainder of the message as though the client had not 5243 included the IA_PD option. 5245 21.22. IA Prefix Option 5247 The IA Prefix option is used to specify a prefix associated with an 5248 IA_PD. The IA Prefix option must be encapsulated in the IA_PD- 5249 options field of an IA_PD option. 5251 0 1 2 3 5252 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 5253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5254 | OPTION_IAPREFIX | option-length | 5255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5256 | preferred-lifetime | 5257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5258 | valid-lifetime | 5259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5260 | prefix-length | | 5261 +-+-+-+-+-+-+-+-+ IPv6-prefix | 5262 | (16 octets) | 5263 | | 5264 | | 5265 | | 5266 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5267 | | . 5268 +-+-+-+-+-+-+-+-+ . 5269 . IAprefix-options . 5270 . . 5271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5273 Figure 36: IA Prefix Option Format 5275 option-code OPTION_IAPREFIX (26). 5277 option-length 25 + length of IAprefix-options field. 5279 preferred-lifetime The preferred lifetime for the prefix in the 5280 option, expressed in units of seconds. A 5281 value of 0xFFFFFFFF represents infinity. A 5282 four octets long field. 5284 valid-lifetime The valid lifetime for the prefix in the 5285 option, expressed in units of seconds. A 5286 value of 0xFFFFFFFF represents infinity. A 5287 four octets long field. 5289 prefix-length Length for this prefix in bits. A one octet 5290 long field. 5292 IPv6-prefix An IPv6 prefix. A 16 octets long field. 5294 IAprefix-options Options associated with this prefix. A 5295 variable length field (25 octets less than 5296 the value in the option-len field). 5298 In a message sent by a client to a server, the preferred and valid 5299 lifetime fields SHOULD be set to 0. The server MUST ignore any 5300 received values in these lifetime fields. 5302 A client may set the IPv6-prefix field to zero and a given value in 5303 the prefix-length field to indicate a preference for the size of the 5304 prefix to be delegated. 5306 The client MUST discard any prefixes for which the preferred lifetime 5307 is greater than the valid lifetime. 5309 The values in the preferred and valid lifetimes are the number of 5310 seconds remaining for each lifetime. See Section 18.2.10.1 for more 5311 details on how these values are used for delegated prefixes. 5313 As per Section 7.7, the preferred and valid lifetime values of 5314 0xffffffff is taken to mean "infinity" and should be used carefully. 5316 An IA Prefix option may appear only in an IA_PD option. More than 5317 one IA Prefix option can appear in a single IA_PD option. 5319 The status of any operations involving this IA Prefix option is 5320 indicated in a Status Code option in the IAprefix-options field. 5322 21.23. Information Refresh Time Option 5324 This option is requested by clients and returned by servers to 5325 specify an upper bound for how long a client should wait before 5326 refreshing information retrieved from a DHCP server. It is only used 5327 in Reply messages in response to Information-request messages. In 5328 other messages there will usually be other information that indicates 5329 when the client should contact the server, e.g., T1/T2 times and 5330 lifetimes. This option is useful when the configuration parameters 5331 change or during renumbering event as clients running in the 5332 stateless mode will be able to update their configuration. 5334 The format of the Information Refresh Time option is: 5336 0 1 2 3 5337 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 5338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5339 |OPTION_INFORMATION_REFRESH_TIME| option-len | 5340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5341 | information-refresh-time | 5342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5344 Figure 37: Information Refresh Time Option Format 5346 option-code OPTION_INFORMATION_REFRESH_TIME (32). 5348 option-len 4. 5350 information-refresh-time Time duration relative to the current 5351 time, expressed in units of seconds. A four 5352 octets long field. 5354 A DHCP client MUST request this option in the Option Request option 5355 (see Section 21.7) when sending Information-request messages. A 5356 client MUST NOT request this option in the ORO in any other messages. 5358 A server sending a Reply to an Information-Request message SHOULD 5359 include this option if it is requested in the ORO of the Information- 5360 Request. The option value MUST NOT be smaller than IRT_MINIMUM. 5361 This option MUST only appear in the top-level option area of Reply 5362 messages. 5364 If the Reply to an Information-request message does not contain this 5365 option, the client MUST behave as if the option with value 5366 IRT_DEFAULT was provided. 5368 A client MUST use the refresh time IRT_MINIMUM if it receives the 5369 option with a value less than IRT_MINIMUM. 5371 As per Section 7.7, the value 0xffffffff is taken to mean "infinity" 5372 and implies that the client should not refresh its configuration data 5373 without some other trigger (such as detecting movement to a new 5374 link). 5376 If a client contacts the server to obtain new data or refresh some 5377 existing data before the refresh time expires, then it SHOULD also 5378 refresh all data covered by this option. 5380 When the client detects that the refresh time has expired, it SHOULD 5381 try to update its configuration data by sending an Information- 5382 Request as specified in Section 18.2.6, except that the client MUST 5383 delay sending the first Information-request by a random amount of 5384 time between 0 and INF_MAX_DELAY. 5386 A client MAY have a maximum value for the refresh time, where that 5387 value is used whenever the client receives this option with a value 5388 higher than the maximum. This also means that the maximum value is 5389 used when the received value is "infinity". A maximum value might 5390 make the client less vulnerable to attacks based on forged DHCP 5391 messages. Without a maximum value, a client may be made to use wrong 5392 information for a possibly infinite period of time. There may 5393 however be reasons for having a very long refresh time, so it may be 5394 useful for this maximum value to be configurable. 5396 21.24. SOL_MAX_RT Option 5398 A DHCP server sends the SOL_MAX_RT option to a client to override the 5399 default value of SOL_MAX_RT. The value of SOL_MAX_RT in the option 5400 replaces the default value defined in Section 7.6. One use for the 5401 SOL_MAX_RT option is to set a longer value for SOL_MAX_RT, which 5402 reduces the Solicit traffic from a client that has not received a 5403 response to its Solicit messages. 5405 The format of the SOL_MAX_RT option is: 5407 0 1 2 3 5408 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 5409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5410 | option-code | option-len | 5411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5412 | SOL_MAX_RT value | 5413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5415 Figure 38: SOL_MAX_RT Option Format 5417 option-code OPTION_SOL_MAX_RT (82). 5419 option-len 4. 5421 SOL_MAX_RT value Overriding value for SOL_MAX_RT in seconds; 5422 MUST be in range: 60 <= "value" <= 86400 (1 5423 day). A four octets long field. 5425 A DHCP client MUST include the SOL_MAX_RT option code in any Option 5426 Request option (see Section 21.7) it sends in a Solicit message. 5428 The DHCP server MAY include the SOL_MAX_RT option in any response it 5429 sends to a client that has included the SOL_MAX_RT option code in an 5430 Option Request option. The SOL_MAX_RT option is sent as a top-level 5431 option in the message to the client, not as an encapsulated option 5432 in, e.g., an IA_NA, IA_TA, or IA_PD option. 5434 A DHCP client MUST ignore any SOL_MAX_RT option values that are less 5435 than 60 or more than 86400. 5437 If a DHCP client receives a message containing a SOL_MAX_RT option 5438 that has a valid value for SOL_MAX_RT, the client MUST set its 5439 internal SOL_MAX_RT parameter to the value contained in the 5440 SOL_MAX_RT option. This value of SOL_MAX_RT is then used by the 5441 retransmission mechanism defined in Section 15 and Section 18.2.1. 5443 The purpose of this mechanism is to give network administrator a way 5444 to avoid large DHCP traffic if all DHCP servers become unavailable. 5445 Therefore this value is expected to be retained for as long as 5446 practically possible. 5448 Updated SOL_MAX_RT value applies only to the network interface on 5449 which the client received SOL_MAX_RT option. 5451 21.25. INF_MAX_RT Option 5453 A DHCP server sends the INF_MAX_RT option to a client to override the 5454 default value of INF_MAX_RT. The value of INF_MAX_RT in the option 5455 replaces the default value defined in Section 7.6. One use for the 5456 INF_MAX_RT option is to set a longer value for INF_MAX_RT, which 5457 reduces the Information-request traffic from a client that has not 5458 received a response to its Information-request messages. 5460 The format of the INF_MAX_RT option is: 5462 0 1 2 3 5463 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 5464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5465 | option-code | option-len | 5466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5467 | INF_MAX_RT value | 5468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5470 Figure 39: INF_MAX_RT Option Format 5472 option-code OPTION_INF_MAX_RT (83). 5474 option-len 4. 5476 INF_MAX_RT value Overriding value for INF_MAX_RT in seconds; 5477 MUST be in range: 60 <= "value" <= 86400 (1 5478 day). A four octets long field. 5480 A DHCP client MUST include the INF_MAX_RT option code in any Option 5481 Request option (see Section 21.7) it sends in an Information-Request 5482 message. 5484 The DHCP server MAY include the INF_MAX_RT option in any response it 5485 sends to a client that has included the INF_MAX_RT option code in an 5486 Option Request option. The INF_MAX_RT option is a top-level option 5487 in the message to the client. 5489 A DHCP client MUST ignore any INF_MAX_RT option values that are less 5490 than 60 or more than 86400. 5492 If a DHCP client receives a message containing an INF_MAX_RT option 5493 that has a valid value for INF_MAX_RT, the client MUST set its 5494 internal INF_MAX_RT parameter to the value contained in the 5495 INF_MAX_RT option. This value of INF_MAX_RT is then used by the 5496 retransmission mechanism defined in Section 15 and Section 18.2.6. 5498 Updated INF_MAX_RT value applies only to the network interface on 5499 which the client received INF_MAX_RT option. 5501 22. Security Considerations 5503 This section discusses security considerations that are not related 5504 to privacy. For dedicated privacy discussion, see Section 23. The 5505 work in progress [I-D.ietf-dhc-sedhcpv6] document provides additional 5506 analysis of the security issues and specifies a secure client and 5507 server communication mechanism. 5509 The threat to DHCP is inherently an insider threat (assuming a 5510 properly configured network where DHCP ports are blocked on the 5511 perimeter gateways of the enterprise). Regardless of the gateway 5512 configuration, however, the potential attacks by insiders and 5513 outsiders are the same. 5515 One attack specific to a DHCP client is the establishment of a 5516 malicious server with the intent of providing incorrect configuration 5517 information to the client. The motivation for doing so may be to 5518 mount a "man in the middle" attack that causes the client to 5519 communicate with a malicious server instead of a valid server for 5520 some service such as DNS or NTP. The malicious server may also mount 5521 a denial of service attack through misconfiguration of the client 5522 that causes all network communication from the client to fail. 5524 A malicious DHCP server might cause a client to set its SOL_MAX_RT 5525 and INF_MAX_RT parameters to an unreasonably high value with the 5526 SOL_MAX_RT and INF_MAX_RT options, which may cause an undue delay in 5527 a client completing its DHCP protocol transaction in the case no 5528 other valid response is received. Assuming the client also receives 5529 a response from a valid DHCP server, large values for SOL_MAX_RT and 5530 INF_MAX_RT will not have any effect. 5532 There is another threat to DHCP clients from mistakenly or 5533 accidentally configured DHCP servers that answer DHCP client requests 5534 with unintentionally incorrect configuration parameters. 5536 A DHCP client may also be subject to attack through the receipt of a 5537 Reconfigure message from a malicious server that causes the client to 5538 obtain incorrect configuration information from that server. Note 5539 that although a client sends its response (Renew, Rebind, or 5540 Information-request message) through a relay agent and, therefore, 5541 that response will only be received by servers to which DHCP messages 5542 are relayed, a malicious server could send a Reconfigure message to a 5543 client, followed (after an appropriate delay) by a Reply message that 5544 would be accepted by the client. Thus, a malicious server that is 5545 not on the network path between the client and the server may still 5546 be able to mount a Reconfigure attack on a client. The use of 5547 transaction IDs that are cryptographically sound and cannot easily be 5548 predicted will also reduce the probability that such an attack will 5549 be successful. 5551 Because of the opportunity for attack through the Reconfigure 5552 message, a DHCP client MUST discard any Reconfigure message that does 5553 not include authentication or that does not pass the validation 5554 process for the authentication protocol. 5556 The Reconfigure Key protocol described in Section 20.4 provides 5557 protection against the use of a Reconfigure message by a malicious 5558 DHCP server to mount a denial of service or man-in-the-middle attack 5559 on a client. This protocol can be compromised by an attacker that 5560 can intercept the initial message in which the DHCP server sends the 5561 key "in plain text" to the client. 5563 Many of these rogue server attacks can be mitigated by making use of 5564 the mechanism described in [RFC7610]. 5566 The threat specific to a DHCP server is an invalid client 5567 masquerading as a valid client. The motivation for this may be for 5568 theft of service, or to circumvent auditing for any number of 5569 nefarious purposes. 5571 The threat common to both the client and the server is the resource 5572 "denial of service" (DoS) attack. These attacks typically involve 5573 the exhaustion of available assigned address or delegatable prefixes, 5574 or the exhaustion of CPU or network bandwidth, and are present 5575 anytime there is a shared resource. Some forms of these exhaustion 5576 attacks can be partially mitigated by appropriate server policy, 5577 e.g., limiting the maximum number of leases any one client can get. 5579 The messages exchanged between relay agents and servers may be used 5580 to mount a "man in the middle" or denial of service attack. 5581 Communication between a server and a relay agent, and communication 5582 between relay agents, can be authenticated and encrypted through the 5583 use of IPsec, as described in [I-D.ietf-dhc-relay-server-security]. 5585 However, the use of manually configured pre-shared keys for IPsec 5586 between relay agents and servers does not defend against replayed 5587 DHCP messages. Replayed messages can represent a DOS attack through 5588 exhaustion of processing resources, but not through mis-configuration 5589 or exhaustion of other resources such as assignable address and 5590 delegatable prefixes. 5592 Networks configured with delegated prefixes should be configured to 5593 preclude intentional or inadvertent inappropriate advertisement of 5594 these prefixes. 5596 23. Privacy Considerations 5598 This section focuses on the server considerations. For extended 5599 discussion about privacy considerations for the client, see 5600 [RFC7824]. In particular, Section 3 of that document discusses 5601 various identifiers that could be misused to track the client. 5602 Section 4 discusses existing mechanisms that may have an impact on 5603 client's privacy. Finally, Section 5 discusses potential attack 5604 vectors. For recommendations how to address or mitigate those 5605 issues, see [RFC7844]. 5607 This specification does not define any allocation strategies. 5608 Implementers are expected to develop their own algorithm for the 5609 server to choose a resource out of the available pool. Several 5610 possible allocation strategies are mentioned in Section 4.3 of 5611 [RFC7824]. Please keep in mind that this list is not exhaustive and 5612 there are certainly other possible strategies. Readers are also 5613 encouraged to read [RFC7707], in particular Section 4.1.2 that 5614 discusses the problems with certain allocation strategies. 5616 24. IANA Considerations 5618 This document does not define any new DHCP name spaces or 5619 definitions. 5621 The publication of this document does not change the assignment rules 5622 for new values for message types, option codes, DUID types or status 5623 codes. 5625 The list of assigned values used in DHCPv6 is available at 5626 http://www.iana.org/assignments/dhcpv6-parameters/ 5627 dhcpv6-parameters.xml 5629 IANA is requested to update the http://www.iana.org/assignments/ 5630 dhcpv6-parameters/dhcpv6-parameters.xhtml page to add a reference to 5631 this document for definitions previously created by [RFC3315], 5632 [RFC3633], [RFC4242] and [RFC7083]. 5634 IANA is requested to add two columns to the DHCPv6 Option table at 5635 http://www.iana.org/assignments/dhcpv6-parameters/ 5636 dhcpv6-parameters.xhtml to indicate which options are allowed to 5637 appear in a client's ORO option (see Section 21.7) and which options 5638 are singleton options (only allowed to appear once as a top-level or 5639 encapsulated option - see Section 16 of [RFC7227]). Table 1 provides 5640 the data for the options assigned by IANA at the time of writing. 5642 +-------+-------------------------+---------------------+-----------+ 5643 | Optio | Option Name (OPTION | Client ORO (1) | Singleton | 5644 | n | prefix removed) | | Option | 5645 +-------+-------------------------+---------------------+-----------+ 5646 | 1 | CLIENTID | No | Yes | 5647 | 2 | SERVERID | No | Yes | 5648 | 3 | IA_NA | No | No | 5649 | 4 | IA_TA | No | No | 5650 | 5 | IAADDR | No | No | 5651 | 6 | ORO | No | Yes | 5652 | 7 | PREFERENCE | No | Yes | 5653 | 8 | ELAPSED_TIME | No | Yes | 5654 | 9 | RELAY_MSG | No | Yes | 5655 | 11 | AUTH | No | Yes | 5656 | 12 | UNICAST | Yes | Yes | 5657 | 13 | STATUS_CODE | No | Yes | 5658 | 14 | RAPID_COMMIT | No | Yes | 5659 | 15 | USER_CLASS | No | Yes | 5660 | 16 | VENDOR_CLASS | No | No (2) | 5661 | 17 | VENDOR_OPTS | Optional | No (2) | 5662 | 18 | INTERFACE_ID | No | Yes | 5663 | 19 | RECONF_MSG | No | Yes | 5664 | 20 | RECONF_ACCEPT | No | Yes | 5665 | 21 | SIP_SERVER_D | Yes | Yes | 5666 | 22 | SIP_SERVER_A | Yes | Yes | 5667 | 23 | DNS_SERVERS | Yes | Yes | 5668 | 24 | DOMAIN_LIST | Yes | Yes | 5669 | 25 | IA_PD | No | No | 5670 | 26 | IAPREFIX | No | No | 5671 | 27 | NIS_SERVERS | Yes | Yes | 5672 | 28 | NISP_SERVERS | Yes | Yes | 5673 | 29 | NIS_DOMAIN_NAME | Yes | Yes | 5674 | 30 | NISP_DOMAIN_NAME | Yes | Yes | 5675 | 31 | SNTP_SERVERS | Yes | Yes | 5676 | 32 | INFORMATION_REFRESH_TIM | Required for | Yes | 5677 | | E | Information-request | | 5678 | 33 | BCMCS_SERVER_D | Yes | Yes | 5679 | 34 | BCMCS_SERVER_A | Yes | Yes | 5680 | 36 | GEOCONF_CIVIC | Yes | Yes | 5681 | 37 | REMOTE_ID | No | Yes | 5682 | 38 | SUBSCRIBER_ID | No | Yes | 5683 | 39 | CLIENT_FQDN | Yes | Yes | 5684 | 40 | PANA_AGENT | Yes | Yes | 5685 | 41 | NEW_POSIX_TIMEZONE | Yes | Yes | 5686 | 42 | NEW_TZDB_TIMEZONE | Yes | Yes | 5687 | 43 | ERO | No | Yes | 5688 | 44 | LQ_QUERY | No | Yes | 5689 | 45 | CLIENT_DATA | No | Yes | 5690 | 46 | CLT_TIME | No | Yes | 5691 | 47 | LQ_RELAY_DATA | No | Yes | 5692 | 48 | LQ_CLIENT_LINK | No | Yes | 5693 | 49 | MIP6_HNIDF | Yes | Yes | 5694 | 50 | MIP6_VDINF | Yes | Yes | 5695 | 51 | V6_LOST | Yes | Yes | 5696 | 52 | CAPWAP_AC_V6 | Yes | Yes | 5697 | 53 | RELAY_ID | No | Yes | 5698 | 54 | OPTION-IPv6_Address-MoS | Yes | Yes | 5699 | 55 | OPTION-IPv6_FQDN-MoS | Yes | Yes | 5700 | 56 | NTP_SERVER | Yes | Yes | 5701 | 57 | V6_ACCESS_DOMAIN | Yes | Yes | 5702 | 58 | SIP_UA_CS_LIST | Yes | Yes | 5703 | 59 | OPT_BOOTFILE_URL | Yes | Yes | 5704 | 60 | OPT_BOOTFILE_PARAM | Yes | Yes | 5705 | 61 | CLIENT_ARCH_TYPE | No | Yes | 5706 | 62 | NII | Yes | Yes | 5707 | 63 | GEOLOCATION | Yes | Yes | 5708 | 64 | AFTR_NAME | Yes | Yes | 5709 | 65 | ERP_LOCAL_DOMAIN_NAME | Yes | Yes | 5710 | 66 | RSOO | No | Yes | 5711 | 67 | PD_EXCLUDE | Yes | Yes | 5712 | 68 | VSS | No | Yes | 5713 | 69 | MIP6_IDINF | Yes | Yes | 5714 | 70 | MIP6_UDINF | Yes | Yes | 5715 | 71 | MIP6_HNP | Yes | Yes | 5716 | 72 | MIP6_HAA | Yes | Yes | 5717 | 73 | MIP6_HAF | Yes | Yes | 5718 | 74 | RDNSS_SELECTION | Yes | No | 5719 | 75 | KRB_PRINCIPAL_NAME | Yes | Yes | 5720 | 76 | KRB_REALM_NAME | Yes | Yes | 5721 | 77 | KRB_DEFAULT_REALM_NAME | Yes | Yes | 5722 | 78 | KRB_KDC | Yes | Yes | 5723 | 79 | CLIENT_LINKLAYER_ADDR | No | Yes | 5724 | 80 | LINK_ADDRESS | No | Yes | 5725 | 81 | RADIUS | No | Yes | 5726 | 82 | SOL_MAX_RT | Required for | Yes | 5727 | | | Solicit | | 5728 | 83 | INF_MAX_RT | Required for | Yes | 5729 | | | Information-request | | 5730 | 84 | ADDRSEL | Yes | Yes | 5731 | 85 | ADDRSEL_TABLE | Yes | Yes | 5732 | 86 | V6_PCP_SERVER | Yes | No | 5733 | 87 | DHCPV4_MSG | No | Yes | 5734 | 88 | DHCP4_O_DHCP6_SERVER | Yes | Yes | 5735 | 89 | S46_RULE | No | No (3) | 5736 | 90 | S46_BR | No | No | 5737 | 91 | S46_DMR | No | Yes | 5738 | 92 | S46_V4V6BIND | No | Yes | 5739 | 93 | S46_PORTPARAMS | No | Yes | 5740 | 94 | S46_CONT_MAPE | Yes | No | 5741 | 95 | S46_CONT_MAPT | Yes | Yes | 5742 | 96 | S46_CONT_LW | Yes | Yes | 5743 | 97 | 4RD | Yes | Yes | 5744 | 98 | 4RD_MAP_RULE | Yes | Yes | 5745 | 99 | 4RD_NON_MAP_RULE | Yes | Yes | 5746 | 100 | LQ_BASE_TIME | No | Yes | 5747 | 101 | LQ_START_TIME | No | Yes | 5748 | 102 | LQ_END_TIME | No | Yes | 5749 | 103 | DHCP Captive-Portal | Yes | Yes | 5750 | 104 | MPL_PARAMETERS | Yes | Yes | 5751 | 105 | ANI_ATT | No | Yes | 5752 | 106 | ANI_NETWORK_NAME | No | Yes | 5753 | 107 | ANI_AP_NAME | No | Yes | 5754 | 108 | ANI_AP_BSSID | No | Yes | 5755 | 109 | ANI_OPERATOR_ID | No | Yes | 5756 | 110 | ANI_OPERATOR_REALM | No | Yes | 5757 | 111 | S46_PRIORITY | Yes | Yes | 5758 | 112 | MUD_URL_V6 (TEMPORARY) | No | Yes | 5759 | 113 | V6_PREFIX64 | Yes | No | 5760 | 114 | F_BINDING_STATUS | No | (4) | 5761 | 115 | F_CONNECT_FLAGS | No | (4) | 5762 | 116 | F_DNS_REMOVAL_INFO | No | (4) | 5763 | 117 | F_DNS_HOST_NAME | No | (4) | 5764 | 118 | F_DNS_ZONE_NAME | No | (4) | 5765 | 119 | F_DNS_FLAGS | No | (4) | 5766 | 120 | F_EXPIRATION_TIME | No | (4) | 5767 | 121 | F_MAX_UNACKED_BNDUPD | No | (4) | 5768 | 122 | F_MCLT | No | (4) | 5769 | 123 | F_PARTNER_LIFETIME | No | (4) | 5770 | 124 | F_PARTNER_LIFETIME_SENT | No | (4) | 5771 | 125 | F_PARTNER_DOWN_TIME | No | (4) | 5772 | 126 | F_PARTNER_RAW_CLT_TIME | No | (4) | 5773 | 127 | F_PROTOCOL_VERSION | No | (4) | 5774 | 128 | F_KEEPALIVE_TIME | No | (4) | 5775 | 129 | F_RECONFIGURE_DATA | No | (4) | 5776 | 130 | F_RELATIONSHIP_NAME | No | (4) | 5777 | 131 | F_SERVER_FLAGS | No | (4) | 5778 | 132 | F_SERVER_STATE | No | (4) | 5779 | 133 | F_START_TIME_OF_STATE | No | (4) | 5780 | 134 | F_STATE_EXPIRATION_TIME | No | (4) | 5781 | 143 | IPv6_ADDRESS-ANDSF | Yes | Yes | 5782 +-------+-------------------------+---------------------+-----------+ 5784 Table 1: Updated Options Table 5786 Notes for Table 1: 5788 (1) For the "Client ORO" column: a "Yes" for an option means that 5789 the client includes this option code if it desires that 5790 configuration information; a "No" means that the option MUST 5791 NOT be included (and servers SHOULD silently ignore that option 5792 code if it appears in ORO). 5794 (2) For each enterprise-number, there MUST only be a single 5795 instance. 5797 (3) See [RFC7598] for details. 5799 (4) See RFC8156 for details. 5801 IANA is requested to update the All_DHCP_Relay_Agents_and_Servers 5802 (ff02::1:2) and All_DHCP_Servers (ff05::1:3) table entries in the 5803 IPv6 multicast address space registry at 5804 http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6- 5805 multicast-addresses.xhtml to reference this document instead of 5806 [RFC3315]. 5808 IANA is requested to update the http://www.iana.org/assignments/ 5809 bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#authentication- 5810 protocol-id page to add an "Obsolete" annotation into the "DHCPv6 5811 Delayed Authentication" entity in the "Authentication Suboption 5812 (value 8) - Protocol identifier values" registry, and 5813 https://www.iana.org/assignments/auth-namespaces/auth- 5814 namespaces.xhtml page to add an "Obsolete" annotation into the 5815 "Delayed Authentication" entity in the "Protocol Name Space Values" 5816 registry. IANA is also requested to update these pages to reference 5817 this document instead of [RFC3315]. 5819 25. Obsoleted Mechanisms 5821 This specification is mostly a corrected and cleaned up version of 5822 the original specification, [RFC3315], along with numerous additions 5823 from later RFCs. However, there are a small number of mechanisms 5824 that were not widely deployed, were underspecified or had other 5825 operational issues. Those mechanisms are now considered deprecated. 5826 Legacy implementations MAY support them, but implementations 5827 conformant to this document MUST NOT rely on them. 5829 The following mechanisms are now obsolete: 5831 Delayed Authentication. This mechanism was underspecified and had 5832 significant operational burden. As a result, after 10 years its 5833 adoption was extremely limited at best. 5835 Lifetime hints sent by a client. Clients used to be allowed to send 5836 lifetime values as hints. This mechanism was not widely implemented 5837 and there were known misimplementations that sent the remaining 5838 lifetimes rather than total desired lifetimes. That in turn was 5839 sometimes misunderstood by servers as a request for ever decreasing 5840 lease lifetimes, which caused issues when values started approaching 5841 zero. Clients now SHOULD set lifetimes to 0 in IA Address and IA 5842 Prefix options, and servers MUST ignore any requested lifetime value. 5844 T1/T2 hints sent by a client. These had similar issues to the 5845 lifetime hints. Clients now SHOULD set the T1/T2 values to 0 in 5846 IA_NA and IA_PD options, and servers MUST ignore any client supplied 5847 T1/T2 values. 5849 26. Acknowledgments 5851 This document is merely a refinement of earlier work by the authors 5852 of RFC3315 (Ralph Droms, Jim Bound, Bernie Volz, Ted Lemon, Charles 5853 Perkins, and Mike Carney), RFC3633 (Ole Troan and Ralph Droms), 5854 RFC3736 (Ralph Droms), RFC4242 (Stig Venaas, Tim Chown, and Bernie 5855 Volz), RFC7083 (Ralph Droms), and RFC7550 (Ole Troan, Bernie Volz, 5856 and Marcin Siodelski) and would not be possible without their 5857 original work. 5859 A number of additional people have contributed to identifying issues 5860 with RFC3315 and RFC3633 and proposed resolutions to these issues as 5861 reflected in this document (in no particular order): Ole Troan, 5862 Robert Marks, Leaf Yeh, Michelle Cotton, Pablo Armando, John 5863 Brzozowski, Suresh Krishnan, Hideshi Enokihara, Alexandru Petrescu, 5864 Yukiyo Akisada, Tatuya Jinmei, Fred Templin and Christian Huitema. 5866 We also thank the following, not otherwise acknowledged and in no 5867 particular order, for their review comments: Jeremy Reed, Francis 5868 Dupont, Tatuya Jinmei, Lorenzo Colitti, Tianxiang Li, Ian Farrer, 5869 Yogendra Pal, Kim Kinnear, Shawn Routhier, Tim Chown, and Michayla 5870 Newcombe. 5872 And, special thanks to Ralph Droms for answering many questions 5873 related to the original RFC3315 and RFC3633 work and for being the 5874 document shepherd. 5876 27. References 5878 27.1. Normative References 5880 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 5881 DOI 10.17487/RFC0768, August 1980, 5882 . 5884 [RFC1035] Mockapetris, P., "Domain names - implementation and 5885 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 5886 November 1987, . 5888 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5889 Requirement Levels", BCP 14, RFC 2119, 5890 DOI 10.17487/RFC2119, March 1997, 5891 . 5893 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 5894 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 5895 December 1998, . 5897 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 5898 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 5899 2006, . 5901 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 5902 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 5903 DOI 10.17487/RFC4861, September 2007, 5904 . 5906 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 5907 Address Autoconfiguration", RFC 4862, 5908 DOI 10.17487/RFC4862, September 2007, 5909 . 5911 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 5912 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 5913 DOI 10.17487/RFC6221, May 2011, 5914 . 5916 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 5917 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 5918 DOI 10.17487/RFC6355, August 2011, 5919 . 5921 [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT 5922 and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 5923 2013, . 5925 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 5926 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 5927 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 5928 . 5930 [RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 5931 Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014, 5932 . 5934 27.2. Informative References 5936 [I-D.ietf-dhc-relay-server-security] 5937 Volz, B. and Y. Pal, "Security of Messages Exchanged 5938 Between Servers and Relay Agents", draft-ietf-dhc-relay- 5939 server-security-05 (work in progress), April 2017. 5941 [I-D.ietf-dhc-sedhcpv6] 5942 Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. 5943 Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work 5944 in progress), February 2017. 5946 [IANA-PEN] 5947 IANA, "Private Enterprise Numbers registry 5948 http://www.iana.org/assignments/enterprise-numbers". 5950 [IANA-RESERVED-IID] 5951 IANA, "Reserved IPv6 Interface Identifiers 5952 http://www.iana.org/assignments/ipv6-interface-ids/ 5953 ipv6-interface-ids.xml". 5955 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 5956 Converting Network Protocol Addresses to 48.bit Ethernet 5957 Address for Transmission on Ethernet Hardware", STD 37, 5958 RFC 826, DOI 10.17487/RFC0826, November 1982, 5959 . 5961 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 5962 RFC 2131, DOI 10.17487/RFC2131, March 1997, 5963 . 5965 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 5966 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 5967 . 5969 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 5970 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 5971 . 5973 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 5974 Stateless Address Autoconfiguration in IPv6", RFC 3041, 5975 DOI 10.17487/RFC3041, January 2001, 5976 . 5978 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 5979 RFC 3162, DOI 10.17487/RFC3162, August 2001, 5980 . 5982 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 5983 C., and M. Carney, "Dynamic Host Configuration Protocol 5984 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 5985 2003, . 5987 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 5988 Host Configuration Protocol (DHCP) version 6", RFC 3633, 5989 DOI 10.17487/RFC3633, December 2003, 5990 . 5992 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 5993 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 5994 DOI 10.17487/RFC3646, December 2003, 5995 . 5997 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 5998 (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, 5999 April 2004, . 6001 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 6002 Delegation", RFC 3769, DOI 10.17487/RFC3769, June 2004, 6003 . 6005 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 6006 Configuration Option for DHCPv6", RFC 4075, 6007 DOI 10.17487/RFC4075, May 2005, 6008 . 6010 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 6011 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 6012 . 6014 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 6015 Time Option for Dynamic Host Configuration Protocol for 6016 IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November 6017 2005, . 6019 [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host 6020 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 6021 Issues", RFC 4477, DOI 10.17487/RFC4477, May 2006, 6022 . 6024 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 6025 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 6026 Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, 6027 . 6029 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 6030 Extensions for Stateless Address Autoconfiguration in 6031 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 6032 . 6034 [RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor 6035 Discovery On-Link Assumption Considered Harmful", 6036 RFC 4943, DOI 10.17487/RFC4943, September 2007, 6037 . 6039 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 6040 "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, 6041 September 2007, . 6043 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 6044 RFC 5453, DOI 10.17487/RFC5453, February 2009, 6045 . 6047 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 6048 "Network Time Protocol Version 4: Protocol and Algorithms 6049 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 6050 . 6052 [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. 6053 Troan, "Prefix Exclude Option for DHCPv6-based Prefix 6054 Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, 6055 . 6057 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 6058 "Default Address Selection for Internet Protocol Version 6 6059 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 6060 . 6062 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 6063 Network Renumbering Scenarios, Considerations, and 6064 Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, 6065 . 6067 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 6068 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 6069 May 2013, . 6071 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 6072 Requirements for IPv6 Customer Edge Routers", RFC 7084, 6073 DOI 10.17487/RFC7084, November 2013, 6074 . 6076 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 6077 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 6078 February 2014, . 6080 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 6081 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 6082 RFC 7341, DOI 10.17487/RFC7341, August 2014, 6083 . 6085 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 6086 Weil, "IPv6 Home Networking Architecture Principles", 6087 RFC 7368, DOI 10.17487/RFC7368, October 2014, 6088 . 6090 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 6091 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 6092 Boundary in IPv6 Addressing", RFC 7421, 6093 DOI 10.17487/RFC7421, January 2015, 6094 . 6096 [RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and 6097 Recommendations with Multiple Stateful DHCPv6 Options", 6098 RFC 7550, DOI 10.17487/RFC7550, May 2015, 6099 . 6101 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 6102 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 6103 Configuration of Softwire Address and Port-Mapped 6104 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 6105 . 6107 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 6108 Protecting against Rogue DHCPv6 Servers", BCP 199, 6109 RFC 7610, DOI 10.17487/RFC7610, August 2015, 6110 . 6112 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 6113 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 6114 . 6116 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 6117 Considerations for IPv6 Address Generation Mechanisms", 6118 RFC 7721, DOI 10.17487/RFC7721, March 2016, 6119 . 6121 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 6122 Considerations for DHCPv6", RFC 7824, 6123 DOI 10.17487/RFC7824, May 2016, 6124 . 6126 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 6127 Profiles for DHCP Clients", RFC 7844, 6128 DOI 10.17487/RFC7844, May 2016, 6129 . 6131 [RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP 6132 Configuration on the Basis of Network Topology", RFC 7969, 6133 DOI 10.17487/RFC7969, October 2016, 6134 . 6136 [RFC8168] Li, T., Liu, C., and Y. Cui, "DHCPv6 Prefix-Length Hint 6137 Issues", RFC 8168, DOI 10.17487/RFC8168, May 2017, 6138 . 6140 [TR-187] Broadband Forum, "TR-187 - IPv6 for PPP Broadband Access", 6141 February 2013, . 6144 Appendix A. Summary of Changes 6146 This appendix provides a summary of the significant changes made to 6147 this updated DHCPv6 specification. 6149 1. The Introduction Section 1 was reorganized and updated. In 6150 particular, the client/server message exchanges were moved into 6151 a new (and expanded) section on their own (see Section 5). And, 6152 new sections were added to discuss the relation to previous 6153 DHCPv6 documents and also to DHCPv4. 6155 2. The Requirements Section 2 and Background Section 3 had very 6156 minor edits. 6158 3. The Terminology Section 4 had minor edits. 6160 4. The DHCP Terminology Section 4.2 was expanded to incorporate 6161 definitions from RFC3633, add T1/T2 definitions, add a few new 6162 definitions useful in a document that combined address and 6163 prefix delegation assignments, and improve some existing 6164 definitions. 6166 5. The Client-Server Exchanges Section 5 was added from material 6167 previously in the Introduction Section 1 of RFC3315 and was 6168 expanded. 6170 6. The Operational Models Section 6 is new and provides information 6171 on the kinds of DHCP clients and how they operate. 6173 7. The DHCP Constants Section 7 was primarily updated to add 6174 constants from RFC4242 and RFC7083. 6176 8. The Client/Server Message Formats Section 8, Relay Agent/Server 6177 Message Formats Section 9, and Representation and Use of Domain 6178 Names Section 10 had only very minor changes. 6180 9. The DHCP Unique Identifier (DUID) Section 11 now discourages, 6181 rather than disallows, a server to parse the DUID, now includes 6182 some information on the DUID-UUID (RFC6355), and has other minor 6183 edits. 6185 10. The Identity Association Section 12 was expanded to better 6186 explain the concept and also included prefix delegation. 6188 11. The Assignment to an IA Section 13 incorporates material from 6189 two sections (11 and 12) of RFC3315 and also includes a section 6190 on prefix delegation. 6192 12. The Transmission of Messages by a Client Section 14 was expanded 6193 to include rate limiting by clients and how clients should 6194 handle T1 or T2 values of 0. 6196 13. The Reliability of Client Initiated Message Exchanges Section 15 6197 was expanded to clarify that the Elapsed Time option must be 6198 updated in retransmitted messages and that a client is not 6199 required to listen for DHCP traffic for the entire 6200 retransmission period. 6202 14. The Message Validation Section 16 had minor edits. 6204 15. The Client Source Address and Interface Selection Section 17 was 6205 expanded to include prefix delegation. 6207 16. The DHCP Configuration Exchanges Section 18 consolidates what 6208 used to be in the RFC3315 DHCP Server Solicitation Section 17, 6209 DHCP Client-Initiated Configuration Exchange Section 18, and 6210 DHCP Server-Initiated Configuration Exchange Section 19. This 6211 material was reorganized and enhanced, and incorporates prefix 6212 delegation from RFC3633 and other changes from RFC4242, RFC7083, 6213 and RFC7550. A few changes of note: 6215 1. The Option Request option is no longer optional for some 6216 messages (Solicit and Information-request) as RFC7083 6217 requires clients to request SOL_MAX_RT or INF_MAX_RT 6218 options. 6220 2. The Reconfigure message should no longer contain IA_NA/ 6221 IA_PD, ORO, or other options to indicate to the client what 6222 was reconfigured. The client should request everything it 6223 needs in the response to the Reconfigure. 6225 3. Lifetime and T1/T2 hints should not be sent by a client (it 6226 should send 0 values in these fields) and any non-zero 6227 values should be ignored by the server. 6229 4. Clarified that a server may return different addresses in 6230 the Reply than requested by a client in the Request message. 6231 Also clarified that a server must not include addresses that 6232 it will not assign. 6234 Also, a Refreshing Configuration Information Section 18.2.12 was 6235 added indicating use cases for when a client should try to 6236 refresh network information. 6238 17. The Relay Agent Behavior Section 19 had minor edits. 6240 18. The Authentication of DHCP Messages Section 20 had significant 6241 changes: IPsec materials were mostly removed and replaced with a 6242 reference to [I-D.ietf-dhc-relay-server-security], and the Delay 6243 Authentication Protocol was removed (see Section 25). Note that 6244 the Reconfigure Key Authentication Protocol is retained. 6246 19. The DHCP Options Section 21 was expanded to incorporate the 6247 prefix delegation options from RFC3633, the Information Refresh 6248 Time option from RFC4242, and the SOL_MAX_RT and INF_MAX_RT 6249 options from RFC7083. In addition, some additional edits were 6250 made to clarify option handling, such as which options should 6251 not be in an Option Request option. 6253 20. The Security Considerations Section 22 were updated to expand 6254 the discussion of security threats and incorporate material from 6255 the incorporated documents, primarily RFC3633. 6257 21. The new Privacy Considerations Section 23 was added to consider 6258 privacy issues. 6260 22. The IANA Considerations Section 24 was rewritten to reflect the 6261 changes requested for this document as other documents have 6262 already made the message, option, DUID, and status code 6263 assignments and this document does not add any new assignments. 6265 23. The new Obsoleted Mechanisms Section 25 documents what this 6266 specification obsoletes. 6268 24. The Appearance of Options in Message Types Appendix B and 6269 Appearance of Options in the Options Field of DHCP Appendix C 6270 were updated to reflect the incorporated options from RFC3633, 6271 RFC4242, and RFC7083. 6273 25. Where appropriate, informational references have been added to 6274 provide further background and guidance throughout the document 6275 (as can be noted by the vast increase in references). 6277 26. General changes to other IPv6 specifications, such as removing 6278 the use of site-local unicast addresses and adding unique local 6279 addresses, were made to the document. Note that in a few 6280 places, older obsoleted RFCs (such as RFC2462 related to M and O 6281 bit handling) are still referenced as the material cited was not 6282 added in the replacement RFC. 6284 27. It should be noted that this document does not refer to all 6285 DHCPv6 functionality and specifications. Readers of this 6286 specification should visit http://www.iana.org/assignments/ 6287 dhcpv6-parameters/dhcpv6-parameters.xml and 6288 https://datatracker.ietf.org/wg/dhc/ to learn of the RFCs that 6289 define DHCPv6 messages, options, status-codes, and more. 6291 Appendix B. Appearance of Options in Message Types 6293 The following tables indicates with a "*" the options are allowed in 6294 each DHCP message type. 6296 These tables are informational and should they conflict with text 6297 earlier in this document, that text should be considered 6298 authoritative. 6300 Client Server IA_NA/ Elap. Relay Server 6301 ID ID IA_TA IA_PD ORO Pref Time Msg. Auth. Unicast 6302 Solicit * * * * * 6303 Advert. * * * * * 6304 Request * * * * * * 6305 Confirm * * * 6306 Renew * * * * * * 6307 Rebind * * * * * 6308 Decline * * * * * 6309 Release * * * * * 6310 Reply * * * * * * 6311 Reconf. * * * 6312 Inform. * (see note) * * 6313 R-forw. * 6314 R-repl. * 6316 NOTE: Server ID option is only included in Information-request 6317 messages that are sent in response to a Reconfigure (see 6318 Section 18.2.6). 6320 Info 6321 Status Rap. User Vendor Vendor Inter. Recon. Recon. Refresh 6322 Code Comm. Class Class Spec. ID Msg. Accept Time 6323 Solicit * * * * * 6324 Advert. * * * * * 6325 Request * * * * 6326 Confirm * * * 6327 Renew * * * * 6328 Rebind * * * * 6329 Decline * * * 6330 Release * * * 6331 Reply * * * * * * * 6332 Reconf. * 6333 Inform. * * * * 6334 R-forw. * * 6335 R-repl. * * 6336 SOL_MAX_RT INF_MAX_RT 6337 Solicit 6338 Advert. * 6339 Request 6340 Confirm 6341 Renew 6342 Rebind 6343 Decline 6344 Release 6345 Reply * * 6346 Reconf. 6347 Inform. 6348 R-forw. 6349 R-repl. 6351 Appendix C. Appearance of Options in the Options Field of DHCP Options 6353 The following table indicates with a "*" where options defined in 6354 this document can appear as top-level options or encapsulated in 6355 other options defined in this document. Other RFC's may define 6356 additional situations where options defined in this document are 6357 encapsulated in other options. 6359 This table is informational and should it conflict with text earlier 6360 in this document, that text should be considered authoritative. 6362 Top- IA_NA/ Relay- Relay- 6363 Level IA_TA IAADDR IA_PD IAPREFIX Forw Reply 6364 Client ID * 6365 Server ID * 6366 IA_NA/IA_TA * 6367 IAADDR * 6368 IA_PD * 6369 IAPREFIX * 6370 ORO * 6371 Preference * 6372 Elapsed Time * 6373 Relay Message * * 6374 Authentic. * 6375 Server Uni. * 6376 Status Code * * * 6377 Rapid Comm. * 6378 User Class * 6379 Vendor Class * 6380 Vendor Info. * * * 6381 Interf. ID * * 6382 Reconf. MSG. * 6383 Reconf. Accept * 6384 Info Refresh Time * 6385 SOL_MAX_RT * 6386 INF_MAX_RT * 6388 Notes: Options asterisked in the "Top-Level" column appear in the 6389 options field of client messages (see Section 8). Options asterisked 6390 in the "Relay-Forw" / "Relay-Reply" column appear in the options 6391 field of the Relay-forward and Relay-reply messages (see Section 9). 6393 Authors' Addresses 6395 Tomek Mrugalski (editor) 6396 Internet Systems Consortium, Inc. 6397 950 Charter Street 6398 Redwood City, CA 94063 6399 USA 6401 Email: tomasz.mrugalski@gmail.com 6402 Marcin Siodelski 6403 Internet Systems Consortium, Inc. 6404 950 Charter Street 6405 Redwood City, CA 94063 6406 USA 6408 Email: msiodelski@gmail.com 6410 Bernie Volz 6411 Cisco Systems, Inc. 6412 1414 Massachusetts Ave 6413 Boxborough, MA 01719 6414 USA 6416 Email: volz@cisco.com 6418 Andrew Yourtchenko 6419 Cisco Systems, Inc. 6420 De Kleetlaan, 7 6421 Diegem B-1831 6422 Belgium 6424 Email: ayourtch@cisco.com 6426 Michael C. Richardson 6427 Sandelman Software Works 6428 470 Dawson Avenue 6429 Ottawa, ON K1Z 5V7 6430 CA 6432 Email: mcr+ietf@sandelman.ca 6433 URI: http://www.sandelman.ca/ 6435 Sheng Jiang 6436 Huawei Technologies Co., Ltd 6437 Q14, Huawei Campus, No.156 Beiqing Road 6438 Hai-Dian District, Beijing, 100095 6439 P.R. China 6441 Email: jiangsheng@huawei.com 6442 Ted Lemon 6443 Nominum, Inc. 6444 800 Bridge St. 6445 Redwood City, CA 94043 6446 USA 6448 Email: Ted.Lemon@nominum.com 6450 Timothy Winters 6451 University of New Hampshire, Interoperability Lab (UNH-IOL) 6452 Durham, NH 6453 USA 6455 Email: twinters@iol.unh.edu