idnits 2.17.00 (12 Aug 2021) /tmp/idnits46568/draft-ietf-dhc-rfc3315bis-13.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 abstract seems to indicate that this document obsoletes RFC7283, but the header doesn't have an 'Obsoletes:' line to match this. 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 (April 7, 2018) is 1498 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 7283 (Obsoleted by RFC 8415) -- 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 7083 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 7550 (Obsoleted by RFC 8415) Summary: 1 error (**), 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 3 Internet-Draft M. Siodelski 4 Obsoletes: 3315, 3633, 3736, 4242, 7083, ISC 5 7283, 7550 (if approved) B. Volz 6 Intended status: Standards Track A. Yourtchenko 7 Expires: October 9, 2018 Cisco 8 M. Richardson 9 SSW 10 S. Jiang 11 Huawei 12 T. Lemon 13 Nominum 14 T. Winters 15 UNH-IOL 16 April 7, 2018 18 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis 19 draft-ietf-dhc-rfc3315bis-13 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), incorporates relay agent handling 37 of unknown messages (RFC7283), and clarifies the interactions between 38 modes of operation (RFC7550). As such, this document obsoletes 39 RFC3315, RFC3633, RFC3736, RFC4242, RFC7083, RFC7283, and RFC7550. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on October 9, 2018. 58 Copyright Notice 60 Copyright (c) 2018 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 This document may contain material from IETF Documents or IETF 74 Contributions published or made publicly available before November 75 10, 2008. The person(s) controlling the copyright in some of this 76 material may not have granted the IETF Trust the right to allow 77 modifications of such material outside the IETF Standards Process. 78 Without obtaining an adequate license from the person(s) controlling 79 the copyright in such materials, this document may not be modified 80 outside the IETF Standards Process, and derivative works of it may 81 not be created outside the IETF Standards Process, except to format 82 it for publication as an RFC or to translate it into languages other 83 than English. 85 Table of Contents 87 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 88 1.1. Relation to Previous DHCPv6 standards . . . . . . . . . . 7 89 1.2. Relation to DHCP in IPv4 . . . . . . . . . . . . . . . . 7 90 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 91 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 8 92 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 93 4.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 8 94 4.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 10 95 5. Client-Server Exchanges . . . . . . . . . . . . . . . . . . . 14 96 5.1. Client-server Exchanges Involving Two Messages . . . . . 15 97 5.2. Client-server Exchanges Involving Four Messages . . . . . 16 98 5.3. Server-client Exchanges . . . . . . . . . . . . . . . . . 16 99 6. Operational Models . . . . . . . . . . . . . . . . . . . . . 17 100 6.1. Stateless DHCP . . . . . . . . . . . . . . . . . . . . . 17 101 6.2. DHCP for Non-Temporary Address Assignment . . . . . . . . 17 102 6.3. DHCP for Prefix Delegation . . . . . . . . . . . . . . . 18 103 6.4. DHCP for Customer Edge Routers . . . . . . . . . . . . . 21 104 6.5. DHCP for Temporary Addresses . . . . . . . . . . . . . . 21 105 6.6. Multiple Addresses and Prefixes . . . . . . . . . . . . . 21 106 7. DHCP Constants . . . . . . . . . . . . . . . . . . . . . . . 22 107 7.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 22 108 7.2. UDP Ports . . . . . . . . . . . . . . . . . . . . . . . . 23 109 7.3. DHCP Message Types . . . . . . . . . . . . . . . . . . . 23 110 7.4. DHCP Option Codes . . . . . . . . . . . . . . . . . . . . 24 111 7.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 25 112 7.6. Transmission and Retransmission Parameters . . . . . . . 25 113 7.7. Representation of Time Values and "Infinity" as a Time 114 Value . . . . . . . . . . . . . . . . . . . . . . . . . . 26 115 8. Client/Server Message Formats . . . . . . . . . . . . . . . . 27 116 9. Relay Agent/Server Message Formats . . . . . . . . . . . . . 28 117 9.1. Relay-forward Message . . . . . . . . . . . . . . . . . . 29 118 9.2. Relay-reply Message . . . . . . . . . . . . . . . . . . . 29 119 10. Representation and Use of Domain Names . . . . . . . . . . . 30 120 11. DHCP Unique Identifier (DUID) . . . . . . . . . . . . . . . . 30 121 11.1. DUID Contents . . . . . . . . . . . . . . . . . . . . . 31 122 11.2. DUID Based on Link-layer Address Plus Time, DUID-LLT . . 31 123 11.3. DUID Assigned by Vendor Based on Enterprise Number, 124 DUID-EN . . . . . . . . . . . . . . . . . . . . . . . . 33 125 11.4. DUID Based on Link-layer Address, DUID-LL . . . . . . . 34 126 11.5. DUID Based on Universally Unique IDentifier (UUID), 127 DUID-UUID . . . . . . . . . . . . . . . . . . . . . . . 34 128 12. Identity Association . . . . . . . . . . . . . . . . . . . . 35 129 12.1. Identity Associations for Address Assignment . . . . . . 35 130 12.2. Identity Associations for Prefix Delegation . . . . . . 36 131 13. Assignment to an IA . . . . . . . . . . . . . . . . . . . . . 36 132 13.1. Selecting Addresses for Assignment to an IA_NA . . . . . 36 133 13.2. Assignment of Temporary Addresses . . . . . . . . . . . 38 134 13.3. Assignment of Prefixes for IA_PD . . . . . . . . . . . . 38 135 14. Transmission of Messages by a Client . . . . . . . . . . . . 39 136 14.1. Rate Limiting . . . . . . . . . . . . . . . . . . . . . 39 137 14.2. Client Behavior when T1 and/or T2 are 0 . . . . . . . . 40 138 15. Reliability of Client Initiated Message Exchanges . . . . . . 40 139 16. Message Validation . . . . . . . . . . . . . . . . . . . . . 42 140 16.1. Use of Transaction IDs . . . . . . . . . . . . . . . . . 43 141 16.2. Solicit Message . . . . . . . . . . . . . . . . . . . . 43 142 16.3. Advertise Message . . . . . . . . . . . . . . . . . . . 43 143 16.4. Request Message . . . . . . . . . . . . . . . . . . . . 44 144 16.5. Confirm Message . . . . . . . . . . . . . . . . . . . . 44 145 16.6. Renew Message . . . . . . . . . . . . . . . . . . . . . 44 146 16.7. Rebind Message . . . . . . . . . . . . . . . . . . . . . 45 147 16.8. Decline Messages . . . . . . . . . . . . . . . . . . . . 45 148 16.9. Release Message . . . . . . . . . . . . . . . . . . . . 45 149 16.10. Reply Message . . . . . . . . . . . . . . . . . . . . . 45 150 16.11. Reconfigure Message . . . . . . . . . . . . . . . . . . 46 151 16.12. Information-request Message . . . . . . . . . . . . . . 46 152 16.13. Relay-forward Message . . . . . . . . . . . . . . . . . 47 153 16.14. Relay-reply Message . . . . . . . . . . . . . . . . . . 47 154 17. Client Source Address and Interface Selection . . . . . . . . 47 155 17.1. Address, Interface Selection for Address Assignment . . 47 156 17.2. Address, Interface Selection for Prefix Delegation . . . 47 157 18. DHCP Configuration Exchanges . . . . . . . . . . . . . . . . 48 158 18.1. A Single Exchange for Multiple IA Options . . . . . . . 51 159 18.2. Client Behavior . . . . . . . . . . . . . . . . . . . . 51 160 18.2.1. Creation and Transmission of Solicit Messages . . . 52 161 18.2.2. Creation and Transmission of Request Messages . . . 55 162 18.2.3. Creation and Transmission of Confirm Messages . . . 56 163 18.2.4. Creation and Transmission of Renew Messages . . . . 57 164 18.2.5. Creation and Transmission of Rebind Messages . . . . 59 165 18.2.6. Creation and Transmission of Information-request 166 Messages . . . . . . . . . . . . . . . . . . . . . . 60 167 18.2.7. Creation and Transmission of Release Messages . . . 61 168 18.2.8. Creation and Transmission of Decline Messages . . . 62 169 18.2.9. Receipt of Advertise Messages . . . . . . . . . . . 63 170 18.2.10. Receipt of Reply Messages . . . . . . . . . . . . . 64 171 18.2.10.1. Reply for Solicit (with Rapid Commit), Request, 172 Renew or Rebind . . . . . . . . . . . . . . . . 66 173 18.2.10.2. Reply for Release and Decline . . . . . . . . . 68 174 18.2.10.3. Reply for Confirm . . . . . . . . . . . . . . . 68 175 18.2.10.4. Reply for Information-request . . . . . . . . . 68 176 18.2.11. Receipt of Reconfigure Messages . . . . . . . . . . 69 177 18.2.12. Refreshing Configuration Information . . . . . . . . 69 178 18.3. Server Behavior . . . . . . . . . . . . . . . . . . . . 70 179 18.3.1. Receipt of Solicit Messages . . . . . . . . . . . . 72 180 18.3.2. Receipt of Request Messages . . . . . . . . . . . . 73 181 18.3.3. Receipt of Confirm Messages . . . . . . . . . . . . 75 182 18.3.4. Receipt of Renew Messages . . . . . . . . . . . . . 75 183 18.3.5. Receipt of Rebind Messages . . . . . . . . . . . . . 77 184 18.3.6. Receipt of Information-request Messages . . . . . . 79 185 18.3.7. Receipt of Release Messages . . . . . . . . . . . . 80 186 18.3.8. Receipt of Decline Messages . . . . . . . . . . . . 81 187 18.3.9. Creation of Advertise Messages . . . . . . . . . . . 81 188 18.3.10. Transmission of Advertise and Reply Messages . . . . 83 189 18.3.11. Creation and Transmission of Reconfigure Messages . 83 190 18.4. Reception of Unicast Messages . . . . . . . . . . . . . 84 191 19. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 85 192 19.1. Relaying a Client Message or a Relay-forward Message . . 85 193 19.1.1. Relaying a Message from a Client . . . . . . . . . . 85 194 19.1.2. Relaying a Message from a Relay Agent . . . . . . . 86 195 19.1.3. Relay Agent Behavior with Prefix Delegation . . . . 86 196 19.2. Relaying a Relay-reply Message . . . . . . . . . . . . . 87 197 19.3. Construction of Relay-reply Messages . . . . . . . . . . 87 198 19.4. Interaction between Relay Agents and Servers . . . . . . 88 199 20. Authentication of DHCP Messages . . . . . . . . . . . . . . . 89 200 20.1. Security of Messages Sent Between Servers and Relay 201 Agents . . . . . . . . . . . . . . . . . . . . . . . . . 89 202 20.2. Summary of DHCP Authentication . . . . . . . . . . . . . 89 203 20.3. Replay Detection . . . . . . . . . . . . . . . . . . . . 90 204 20.4. Reconfigure Key Authentication Protocol . . . . . . . . 90 205 20.4.1. Use of the Authentication Option in the Reconfigure 206 Key Authentication Protocol . . . . . . . . . . . . 91 207 20.4.2. Server Considerations for Reconfigure Key 208 Authentication Protocol . . . . . . . . . . . . . . 92 209 20.4.3. Client Considerations for Reconfigure Key 210 Authentication Protocol . . . . . . . . . . . . . . 92 211 21. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 93 212 21.1. Format of DHCP Options . . . . . . . . . . . . . . . . . 93 213 21.2. Client Identifier Option . . . . . . . . . . . . . . . . 94 214 21.3. Server Identifier Option . . . . . . . . . . . . . . . . 94 215 21.4. Identity Association for Non-temporary Addresses Option 95 216 21.5. Identity Association for Temporary Addresses Option . . 97 217 21.6. IA Address Option . . . . . . . . . . . . . . . . . . . 99 218 21.7. Option Request Option . . . . . . . . . . . . . . . . . 101 219 21.8. Preference Option . . . . . . . . . . . . . . . . . . . 102 220 21.9. Elapsed Time Option . . . . . . . . . . . . . . . . . . 103 221 21.10. Relay Message Option . . . . . . . . . . . . . . . . . . 104 222 21.11. Authentication Option . . . . . . . . . . . . . . . . . 104 223 21.12. Server Unicast Option . . . . . . . . . . . . . . . . . 106 224 21.13. Status Code Option . . . . . . . . . . . . . . . . . . . 107 225 21.14. Rapid Commit Option . . . . . . . . . . . . . . . . . . 108 226 21.15. User Class Option . . . . . . . . . . . . . . . . . . . 109 227 21.16. Vendor Class Option . . . . . . . . . . . . . . . . . . 110 228 21.17. Vendor-specific Information Option . . . . . . . . . . . 112 229 21.18. Interface-Id Option . . . . . . . . . . . . . . . . . . 114 230 21.19. Reconfigure Message Option . . . . . . . . . . . . . . . 115 231 21.20. Reconfigure Accept Option . . . . . . . . . . . . . . . 115 232 21.21. Identity Association for Prefix Delegation Option . . . 116 233 21.22. IA Prefix Option . . . . . . . . . . . . . . . . . . . . 118 234 21.23. Information Refresh Time Option . . . . . . . . . . . . 120 235 21.24. SOL_MAX_RT Option . . . . . . . . . . . . . . . . . . . 121 236 21.25. INF_MAX_RT Option . . . . . . . . . . . . . . . . . . . 122 237 22. Security Considerations . . . . . . . . . . . . . . . . . . . 123 238 23. Privacy Considerations . . . . . . . . . . . . . . . . . . . 126 239 24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 127 240 25. Obsoleted Mechanisms . . . . . . . . . . . . . . . . . . . . 131 241 26. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 132 242 27. References . . . . . . . . . . . . . . . . . . . . . . . . . 133 243 27.1. Normative References . . . . . . . . . . . . . . . . . . 133 244 27.2. Informative References . . . . . . . . . . . . . . . . . 134 245 Appendix A. Summary of Changes . . . . . . . . . . . . . . . . . 139 246 Appendix B. Appearance of Options in Message Types . . . . . . . 142 247 Appendix C. Appearance of Options in the Options Field of DHCP 248 Options . . . . . . . . . . . . . . . . . . . . . . 144 249 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 145 251 1. Introduction 253 This document describes DHCP for IPv6 (DHCPv6), a client/server 254 protocol that provides managed configuration of devices. The basic 255 operation of DHCPv6 provides configuration for clients connected to 256 the same link as the server. Relay agent functionality is also 257 defined for enabling communication between clients and servers that 258 are not on the same link. 260 DHCPv6 can provide a device with addresses assigned by a DHCPv6 261 server and other configuration information, which are carried in 262 options. DHCPv6 can be extended through the definition of new 263 options to carry configuration information not specified in this 264 document. 266 DHCPv6 also provides a mechanism for automated delegation of IPv6 267 prefixes using DHCPv6, originally specified in [RFC3633]. Through 268 this mechanism, a delegating router can delegate prefixes to 269 requesting routers. Use of this mechanism is specified as part of 270 [RFC7084] and by [TR-187]. 272 DHCP can also be used just to provide other configuration options 273 (i.e., no addresses or prefixes). That implies that the server does 274 not have to track any state, and thus this mode is called stateless 275 DHCPv6. Mechanisms necessary to support stateless DHCPv6 are much 276 smaller than to support stateful DHCPv6 ([RFC3736] was written to 277 document just those portions of DHCPv6 needed to support DHCPv6 278 stateless operation). 280 The remainder of this introduction summarizes the relationship to the 281 previous DHCPv6 standards in Section 1.1 and clarifies the stance 282 with regards to DHCPv4 in Section 1.2. Section 5 describes the 283 message exchange mechanisms to illustrate DHCP operation rather than 284 provide an exhaustive list of all possible interactions and Section 6 285 provides an overview of common operational models. Section 18 286 explains client and server operation in detail. 288 1.1. Relation to Previous DHCPv6 standards 290 The initial specification of DHCPv6 was defined in [RFC3315] and a 291 number of follow up documents were published over the years: IPv6 292 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 293 6 [RFC3633], Stateless Dynamic Host Configuration Protocol (DHCP) 294 Service for IPv6s [RFC3736], Information Refresh Time Option for 295 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC4242], 296 Modification to Default Values of SOL_MAX_RT and INF_MAX_RT 297 [RFC7083], Handling Unknown DHCPv6 Messages [RFC7283], and Issues and 298 Recommendations with Multiple Stateful DHCPv6 Options [RFC7550]. 299 This document provides a unified, corrected, and cleaned up 300 definition of DHCPv6 that also covers all errata filed against older 301 RFCs (see list in Appendix A). As such, it obsoletes a number of the 302 aforementioned RFCs. And, there are a small number of mechanisms 303 that were obsoleted, listed in Section 25. Also see Appendix A. 305 1.2. Relation to DHCP in IPv4 307 The operational models and relevant configuration information for 308 DHCPv4 ([RFC2131] and [RFC2132]) and DHCPv6 are sufficiently 309 different that integration between the two services is not included 310 in this document. [RFC3315] suggested that future work might be to 311 extend DHCPv6 to carry IPv4 address and configuration information. 312 However, the current consensus of the IETF is that DHCPv4 should be 313 used rather than DHCPv6 when conveying IPv4 configuration information 314 to nodes. For IPv6-only networks, [RFC7341] describes a transport 315 mechanism to carry DHCPv4 messages using the DHCPv6 protocol for the 316 dynamic provisioning of IPv4 address and configuration information. 318 Merging DHCPv4 and DHCPv6 configuration is out of scope of this 319 document. [RFC4477] discusses some issues and possible strategies 320 for running DHCPv4 and DHCPv6 services together. While this document 321 is a bit dated, it provides a good overview of the issues at hand. 323 2. Requirements 325 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 326 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 327 "OPTIONAL" in this document are to be interpreted as described in BCP 328 14 [RFC2119] [RFC8174] when, and only when, they appear in all 329 capitals, as shown here. 331 This document also makes use of internal conceptual variables to 332 describe protocol behavior and external variables that an 333 implementation must allow system administrators to change. The 334 specific variable names, how their values change, and how their 335 settings influence protocol behavior are provided to demonstrate 336 protocol behavior. An implementation is not required to have them in 337 the exact form described here, so long as its external behavior is 338 consistent with that described in this document. 340 3. Background 342 The IPv6 Specification provides the base architecture and design of 343 IPv6. Related work in IPv6 that would best serve an implementer to 344 study includes the IPv6 Specification [RFC8200], the IPv6 Addressing 345 Architecture [RFC4291], IPv6 Stateless Address Autoconfiguration 346 [RFC4862], and IPv6 Neighbor Discovery Processing [RFC4861]. These 347 specifications enable DHCP to build upon the IPv6 work to provide 348 robust stateful autoconfiguration. 350 The IPv6 Addressing Architecture specification [RFC4291] defines the 351 address scope that can be used in an IPv6 implementation, and the 352 various configuration architecture guidelines for network designers 353 of the IPv6 address space. Two advantages of IPv6 are that support 354 for multicast is required and nodes can create link-local addresses 355 during initialization. The availability of these features means that 356 a client can use its link-local address and a well-known multicast 357 address to discover and communicate with DHCP servers or relay agents 358 on its link. 360 IPv6 Stateless Address Autoconfiguration [RFC4862] specifies 361 procedures by which a node may autoconfigure addresses based on 362 router advertisements [RFC4861], and the use of a valid lifetime to 363 support renumbering of addresses on the Internet. Compatibility with 364 stateless address autoconfiguration is a design requirement of DHCP. 366 IPv6 Neighbor Discovery [RFC4861] is the node discovery protocol in 367 IPv6 which replaces and enhances functions of ARP [RFC0826]. To 368 understand IPv6 and stateless address autoconfiguration, it is 369 strongly recommended that implementers understand IPv6 Neighbor 370 Discovery. 372 4. Terminology 374 This section defines terminology specific to IPv6 and DHCP used in 375 this document. 377 4.1. IPv6 Terminology 379 IPv6 terminology relevant to this specification from the IPv6 380 Protocol [RFC8200], IPv6 Addressing Architecture [RFC4291], and IPv6 381 Stateless Address Autoconfiguration [RFC4862] is included below. 383 address An IP layer identifier for an interface or 384 a set of interfaces. 386 host Any node that is not a router. 388 IP Internet Protocol Version 6 (IPv6). The 389 terms IPv4 and IPv6 are used only in 390 contexts where it is necessary to avoid 391 ambiguity. 393 interface A node's attachment to a link. 395 link A communication facility or medium over 396 which nodes can communicate at the link 397 layer, i.e., the layer immediately below 398 IP. Examples are Ethernet (simple or 399 bridged); PPP and PPPoE links; and Internet 400 (or higher) layer "tunnels", such as 401 tunnels over IPv4 or IPv6 itself. 403 link-layer identifier A link-layer identifier for an interface. 404 For example, IEEE 802 addresses for 405 Ethernet or Token Ring network interfaces. 407 link-local address An IPv6 address having a link-only scope, 408 indicated by having the prefix (fe80::/10), 409 that can be used to reach neighboring nodes 410 attached to the same link. Every IPv6 411 interface has a link-local address. 413 multicast address An identifier for a set of interfaces 414 (typically belonging to different nodes). 415 A packet sent to a multicast address is 416 delivered to all interfaces identified by 417 that address. 419 neighbor A node attached to the same link. 421 node A device that implements IP. 423 packet An IP header plus payload. 425 prefix The initial bits of an address, or a set of 426 IP addresses that share the same initial 427 bits. 429 prefix length The number of bits in a prefix. 431 router A node that forwards IP packets not 432 explicitly addressed to itself. 434 unicast address An identifier for a single interface. A 435 packet sent to a unicast address is 436 delivered to the interface identified by 437 that address. 439 4.2. DHCP Terminology 441 Terminology specific to DHCP can be found below. 443 appropriate to the link An address is "appropriate to the link" 444 when the address is consistent with the 445 DHCP server's knowledge of the network 446 topology, prefix assignment and address 447 assignment policies. 449 binding A binding (or, client binding) is a group 450 of server data records containing the 451 information the server has about the 452 addresses or delegated prefixes in an IA or 453 configuration information explicitly 454 assigned to the client. Configuration 455 information that has been returned to a 456 client through a policy, such as the 457 information returned to all clients on the 458 same link, does not require a binding. A 459 binding containing information about an IA 460 is indexed by the tuple (where IA-type is the type of lease 462 in the IA; for example, temporary). A 463 binding containing configuration 464 information for a client is indexed by 465 . See below for definitions of DUID, 466 IA, and IAID. 468 configuration parameter An element of the configuration information 469 set on the server and delivered to the 470 client using DHCP. Such parameters may be 471 used to carry information to be used by a 472 node to configure its network subsystem and 473 enable communication on a link or 474 internetwork, for example. 476 container option An option that encapsulates other options 477 (for example, the IA_NA option, see 478 Section 21.4, may contain IA Address 479 options, see Section 21.6). 481 delegating router The router that acts as a DHCP server, and 482 responds to requests for delegated 483 prefixes. This document primarily uses the 484 term "DHCP server" or "server" when 485 discussing the "delegating router" 486 functionality of prefix delegation (see 487 Section 1). 489 DHCP Dynamic Host Configuration Protocol for 490 IPv6. The terms DHCPv4 and DHCPv6 are used 491 only in contexts where it is necessary to 492 avoid ambiguity. 494 DHCP client (or client) A node that initiates requests on a link to 495 obtain configuration parameters from one or 496 more DHCP servers. The node may act as a 497 requesting router (see below) if it 498 supports prefix delegation. 500 DHCP domain A set of links managed by DHCP and operated 501 by a single administrative entity. 503 DHCP relay agent (or relay agent) A node that acts as an 504 intermediary to deliver DHCP messages 505 between clients and servers. In certain 506 configurations there may be more than one 507 relay agent between clients and servers, so 508 a relay agent may send DHCP messages to 509 another relay agent. 511 DHCP server (or server) A node that responds to requests from 512 clients, and may or may not be on the same 513 link as the client(s). Depending on its 514 capabilities, it may also feature the 515 functionality of delegating router, if it 516 supports prefix delegation. 518 DUID A DHCP Unique IDentifier for a DHCP 519 participant; each DHCP client and server 520 has exactly one DUID. See Section 11 for 521 details of the ways in which a DUID may be 522 constructed. 524 encapsulated option A DHCPv6 option that is usually only 525 contained in another option. For example, 526 the IA Address option is contained in IA_NA 527 or IA_TA options (see Section 21.5). See 528 Section 9 of [RFC7227] for a more complete 529 definition. 531 IA Identity Association: A collection of 532 leases assigned to a client. Each IA has 533 an associated IAID (see below). A client 534 may have more than one IA assigned to it; 535 for example, one for each of its 536 interfaces. Each IA holds one type of 537 lease; for example, an identity association 538 for temporary addresses (IA_TA) holds 539 temporary addresses and identity 540 association for prefix delegation (IA_PD) 541 holds delegated prefixes. Throughout this 542 document, "IA" is used to refer to an 543 identity association without identifying 544 the type of a lease in the IA. At the time 545 of writing this document, there are three 546 IA types defined: IA_NA, IA_TA and IA_PD. 547 New IA types may be defined in the future. 549 IA option(s) At the time of writing this document, one 550 or more IA_NA, IA_TA, and/or IA_PD options. 551 New IA types may be defined in the future. 553 IAID Identity Association IDentifier: An 554 identifier for an IA, chosen by the client. 555 Each IA has an IAID, which is chosen to be 556 unique among IAIDs for IAs of a specific 557 type, belonging to that client. 559 IA_NA Identity association for Non-temporary 560 Addresses: An IA that carries assigned 561 addresses that are not temporary addresses 562 (see "IA_TA"). See Section 21.4 for 563 details on the IA_NA option. 565 IA_TA Identity Association for Temporary 566 Addresses: An IA that carries temporary 567 addresses (see [RFC4941]). See 568 Section 21.5 for details on the IA_TA 569 option. 571 IA_PD Identity Association for Prefix Delegation: 572 An IA that carries delegated prefixes. See 573 Section 21.21 for details on the IA_PD 574 option. 576 lease A contract by which the server grants the 577 use of an address or delegated prefix to 578 the client for a specified period of time. 580 message A unit of data carried as the payload of a 581 UDP datagram, exchanged among DHCP servers, 582 relay agents and clients. 584 Reconfigure key A key supplied to a client by a server used 585 to provide security for Reconfigure 586 messages (see Section 7.3). 588 relaying A DHCP relay agent relays DHCP messages 589 between DHCP participants. 591 requesting router The router that acts as a DHCP client and 592 is requesting prefix(es) to be assigned. 593 This document primarily uses the term "DHCP 594 client" or "client" when discussing the 595 "requesting router" functionality of prefix 596 delegation (see Section 1). 598 retransmission Another attempt to send the same DHCP 599 message by a client or server, as a result 600 of not receiving a valid response to the 601 previously sent messages. The 602 retransmitted message is typically modified 603 prior to sending, as required by the DHCP 604 specifications. In particular, the client 605 updates the value of the Elapsed Time 606 option in the retransmitted message. 608 RKAP The Reconfiguration Key Authentication 609 Protocol, see Section 20.4. 611 singleton option An option that is allowed to appear only 612 once as a top-level option or at any 613 encapsulation level. Most options are 614 singletons. 616 T1 The time interval after which the client is 617 expected to contact the server that did the 618 assignment to extend (renew) the lifetimes 619 of the addresses assigned (via IA_NA 620 option(s)) and/or prefixes delegated (via 621 IA_PD option(s)) to the client. T1 is 622 expressed as an absolute value in messages 623 (in seconds), is conveyed within IA 624 containers (currently the IA_NA and IA_PD 625 options), and is interpreted as a time 626 interval since the packet's reception. The 627 value stored in the T1 field in IA options 628 is referred to as the T1 value. The actual 629 time when the timer expires is referred to 630 as the T1 time. 632 T2 The time interval after which the client is 633 expected to contact any available server to 634 extend (rebind) the lifetimes of the 635 addresses assigned (via IA_NA option(s)) 636 and/or prefixes delegated (via IA_PD 637 option(s)) to the client. T2 is expressed 638 as an absolute value in messages (in 639 seconds), is conveyed within IA containers 640 (currently the IA_NA and IA_PD options), 641 and is interpreted as a time interval since 642 the packet's reception. The value stored 643 in the T2 field in IA options is referred 644 to as the T2 value. The actual time when 645 the timer expires is referred to as the T2 646 time. 648 top-level option An option conveyed in a DHCP message 649 directly, i.e., not encapsulated in any 650 other option, as described in Section 9 of 651 [RFC7227]. 653 transaction ID An opaque value used to match responses 654 with replies initiated either by a client 655 or server. 657 5. Client-Server Exchanges 659 Clients and servers exchange DHCP messages using UDP [RFC0768] BCP 660 145 [RFC8085]. The client uses a link-local address or addresses 661 determined through other mechanisms for transmitting and receiving 662 DHCP messages. 664 A DHCP client sends most messages using a reserved, link-scoped 665 multicast destination address so that the client need not be 666 configured with the address or addresses of DHCP servers. 668 To allow a DHCP client to send a message to a DHCP server that is not 669 attached to the same link, a DHCP relay agent on the client's link 670 will relay messages between the client and server. The operation of 671 the relay agent is transparent to the client and the discussion of 672 message exchanges in the remainder of this section will omit the 673 description of message relaying by relay agents. 675 Once the client has determined the address of a server, it may under 676 some circumstances send messages directly to the server using 677 unicast. 679 5.1. Client-server Exchanges Involving Two Messages 681 When a DHCP client does not need to have a DHCP server assign it IP 682 addresses or delegated prefixes, the client can obtain other 683 configuration information such as a list of available DNS servers 684 [RFC3646] or NTP servers [RFC4075] through a single message and reply 685 exchange with a DHCP server. To obtain other configuration 686 information the client first sends an Information-request message to 687 the All_DHCP_Relay_Agents_and_Servers multicast address. Servers 688 respond with a Reply message containing the other configuration 689 information for the client. 691 A client may also request the server to expedite address assignment 692 and/or prefix delegation by using a two message exchange instead of 693 the normal four message exchange as discussed in the next section. 694 Expedited assignment can be requested by the client, and servers may 695 or may not honor the request (see Section 18.3.1 and Section 21.14 696 for more details and why servers may not honor this request). 697 Clients may request this expedited service in environments where it 698 is likely that there is only one server available on a link and no 699 expectation that a second server would become available, or when 700 completing the configuration process as quickly as possible is a 701 priority. 703 To request the expedited two message exchange, the client sends a 704 Solicit message to the All_DHCP_Relay_Agents_and_Servers multicast 705 address requesting the assignment of addresses and/or delegated 706 prefixes and other configuration information. This message includes 707 an indication (the Rapid Commit option, see Section 21.14) that the 708 client is willing to accept an immediate Reply message from the 709 server. The server that is willing to commit the assignment of 710 addresses and/or delegated prefixes to the client immediately 711 responds with a Reply message. The configuration information and the 712 addresses and/or delegated prefixes in the Reply message are then 713 immediately available for use by the client. 715 Each address or delegated prefix assigned to the client has 716 associated preferred and valid lifetimes specified by the server. To 717 request an extension of the lifetimes assigned to an address or 718 delegated prefix, the client sends a Renew message to the server. 719 The server sends a Reply message to the client with the new 720 lifetimes, allowing the client to continue to use the address or 721 delegated prefix without interruption. If the server is unable to 722 extend the lifetime of an address or delegated prefix, it indicates 723 this by returning the address or delegated prefix with lifetimes of 724 0. At the same time, the server may assign other addresses or 725 delegated prefixes. 727 There are additional two message exchanges between the client and 728 server described later in this document. 730 5.2. Client-server Exchanges Involving Four Messages 732 To request the assignment of one or more addresses and/or delegated 733 prefixes, a client first locates a DHCP server and then requests the 734 assignment of addresses and/or delegated prefixes and other 735 configuration information from the server. The client sends a 736 Solicit message to the All_DHCP_Relay_Agents_and_Servers multicast 737 address to find available DHCP servers. Any server that can meet the 738 client's requirements responds with an Advertise message. The client 739 then chooses one of the servers and sends a Request message to the 740 server asking for confirmed assignment of addresses and/or delegated 741 prefixes and other configuration information. The server responds 742 with a Reply message that contains the confirmed addresses, delegated 743 prefixes, and configuration. 745 As described in the previous section, the client can request an 746 extension of the lifetimes assigned to addresses or delegated 747 prefixes (this is a two message exchange). 749 5.3. Server-client Exchanges 751 A server that has previously communicated with a client and 752 negotiated for the client to listen for Reconfigure messages, may 753 send the client a Reconfigure message to initiate the client to 754 update its configuration by sending an Information-request, Renew, or 755 Rebind message. The client then performs the two message exchange as 756 described earlier. This can be used to expedite configuration 757 changes to a client, such as the need to renumber a network (see 758 [RFC6879]). 760 6. Operational Models 762 This section describes some of the current most common DHCP 763 operational models. The described models are not mutually exclusive 764 and are sometimes used together. For example, a device may start in 765 stateful mode to obtain an address, and at a later time when an 766 application is started, request additional parameters using stateless 767 mode. 769 This document assumes that the DHCP servers and the client, 770 communicating with the servers via a specific interface, belong to a 771 single provisioning domain. 773 DHCP may be extended to support additional stateful services that may 774 interact with one or more of the models described below. Such 775 interaction should be considered and documented as part of any future 776 protocol extension. 778 6.1. Stateless DHCP 780 Stateless DHCP [RFC3736] is used when DHCP is not used for obtaining 781 a lease, but a node (DHCP client) desires one or more DHCP "other 782 configuration" parameters, such as a list of DNS recursive name 783 servers or DNS domain search lists [RFC3646]. Stateless DHCP may be 784 used when a node initially boots or at any time the software on the 785 node requires some missing or expired configuration information that 786 is available via DHCP. 788 This is the simplest and most basic operation for DHCP and requires a 789 client (and a server) to support only two messages - Information- 790 request and Reply. Note that DHCP servers and relay agents typically 791 also need to support the Relay-forward and Relay-reply messages to 792 accommodate operation when clients and servers are not on the same 793 link. 795 6.2. DHCP for Non-Temporary Address Assignment 797 This model of operation was the original motivation for DHCP. It is 798 appropriate for situations where stateless address autoconfiguration 799 alone is insufficient or impractical, e.g., because of network 800 policy, additional requirements such as dynamic updates to the DNS, 801 or client-specific requirements. 803 The model of operation for non-temporary address assignment is as 804 follows. The server is provided with prefixes from which it may 805 allocate addresses to clients, as well as any related network 806 topology information as to which prefixes are present on which links. 807 A client requests a non-temporary address to be assigned by the 808 server. The server allocates an address or addresses appropriate for 809 the link on which the client is connected. The server returns the 810 allocated address or addresses to the client. 812 Each address has an associated preferred and valid lifetime, which 813 constitutes an agreement about the length of time over which the 814 client is allowed to use the address. A client can request an 815 extension of the lifetimes on an address and is required to terminate 816 the use of an address if the valid lifetime of the address expires. 818 Typically clients request other configuration parameters, such as the 819 DNS name server addresses and domain search lists, when requesting 820 addresses. 822 Clients can also request more than one address or set of addresses 823 (see Section 6.6 and Section 12). 825 6.3. DHCP for Prefix Delegation 827 The prefix delegation mechanism, originally described in [RFC3633], 828 is another stateful mode of operation and was originally intended for 829 simple delegation of prefixes from a delegating router (DHCP server) 830 to requesting routers (DHCP clients). It is appropriate for 831 situations in which the delegating router does not have knowledge 832 about the topology of the networks to which the requesting router is 833 attached, and the delegating router does not require other 834 information aside from the identity of the requesting router to 835 choose a prefix for delegation. For example, these options would be 836 used by a service provider to assign a prefix to a Customer Edge 837 Router device acting as a router between the subscriber's internal 838 network and the service provider's core network. 840 The design of this prefix delegation mechanism meets the requirements 841 for prefix delegation in [RFC3769]. 843 While [RFC3633] assumed that the DHCP client is a router (hence the 844 use of "requesting router") and that the DHCP server was a router 845 (hence the use of "delegating router"), DHCP prefix delegation itself 846 does not require that the client forward IP packets not addressed to 847 itself, and thus does not require that the client (or server) be a 848 router as defined in [RFC8200]. Also, in many cases (such as 849 tethering or hosting virtual machines), hosts are already forwarding 850 IP packets and thus operating as routers as defined in [RFC8200]. 851 Therefore, this document mostly replaces "requesting router" with 852 client and "delegating router" with server. 854 The model of operation for prefix delegation is as follows. A server 855 is provisioned with prefixes to be delegated to clients. A client 856 requests prefix(es) from the server, as described in Section 18. The 857 server chooses prefix(es) for delegation, and responds with 858 prefix(es) to the client. The client is then responsible for the 859 delegated prefix(es). For example, the client might assign a subnet 860 from a delegated prefix to one of its interfaces, and begin sending 861 router advertisements for the prefix on that link. 863 Each prefix has an associated valid and preferred lifetime, which 864 constitutes an agreement about the length of time over which the 865 client is allowed to use the prefix. A client can request an 866 extension of the lifetimes on a delegated prefix and is required to 867 terminate the use of a delegated prefix if the valid lifetime of the 868 prefix expires. 870 This prefix delegation mechanism is appropriate for use by an ISP to 871 delegate a prefix to a subscriber, where the delegated prefix would 872 possibly be subnetted and assigned to the links within the 873 subscriber's network. [RFC7084] and [RFC7368] describe in detail 874 such use. 876 Figure 1 illustrates a network architecture in which prefix 877 delegation could be used. 879 ______________________ \ 880 / \ \ 881 | ISP core network | \ 882 \__________ ___________/ | 883 | | 884 +-------+-------+ | 885 | Aggregation | | ISP 886 | device | | network 887 | (delegating | | 888 | router) | | 889 +-------+-------+ | 890 | / 891 |Network link to / 892 |subscriber premises / 893 | 894 +------+------+ \ 895 | CPE | \ 896 | (requesting | \ 897 | router) | | 898 +----+---+----+ | 899 | | | Subscriber 900 ---+-------------+-----+ +-----+------ | Network 901 | | | | 902 +----+-----+ +-----+----+ +----+-----+ | 903 |Subscriber| |Subscriber| |Subscriber| / 904 | PC | | PC | | PC | / 905 +----------+ +----------+ +----------+ / 907 Figure 1: Prefix Delegation Network 909 In this example, the server (delegating router) is configured with a 910 set of prefixes to be used for assignment to customers at the time of 911 each customer's first connection to the ISP service. The prefix 912 delegation process begins when the client (requesting router) 913 requests configuration information through DHCP. The DHCP messages 914 from the client are received by the server in the aggregation device. 915 When the server receives the request, it selects an available prefix 916 or prefixes for delegation to the client. The server then returns 917 the prefix or prefixes to the client. 919 The client subnets the delegated prefix and assigns the longer 920 prefixes to links in the subscriber's network. In a typical scenario 921 based on the network shown in Figure 1, the client subnets a single 922 delegated /48 prefix into /64 prefixes and assigns one /64 prefix to 923 each of the links in the subscriber network. 925 The prefix delegation options can be used in conjunction with other 926 DHCP options carrying other configuration information to the client. 928 The client may, in turn, provide DHCP service to nodes attached to 929 the internal network. For example, the client may obtain the 930 addresses of DNS and NTP servers from the ISP server, and then pass 931 that configuration information on to the subscriber hosts through a 932 DHCP server in the client (requesting router). 934 If the client uses a delegated prefix to configure addresses on 935 interfaces on itself or other nodes behind it, the preferred and 936 valid lifetimes of those addresses MUST be no larger than the 937 remaining preferred and valid lifetimes, respectively, for the 938 delegated prefix at any time. In particular, if the delegated prefix 939 or a prefix derived from it is advertised for stateless address 940 autoconfiguration [RFC4862], the advertised preferred and valid 941 lifetimes MUST NOT exceed the corresponding remaining lifetimes of 942 the delegated prefix. 944 6.4. DHCP for Customer Edge Routers 946 The DHCP requirements and network architecture for Customer Edge 947 Routers are described in [RFC7084]. This model of operation combines 948 address assignment (see Section 6.2) and prefix delegation (see 949 Section 6.3). In general, this model assumes that a single set of 950 transactions between the client and server will assign or extend the 951 client's non-temporary addresses and delegated prefixes. 953 6.5. DHCP for Temporary Addresses 955 Temporary addresses were originally introduced to avoid privacy 956 concerns with stateless address autoconfiguration, which based 957 64-bits of the address on the EUI-64 (see [RFC4941]. They were added 958 to DHCP to provide complementary support when stateful address 959 assignment is used. 961 Temporary address assignment works mostly like non-temporary address 962 assignment (see Section 6.2), however these addresses are generally 963 intended to be used for a short period of time and not to have their 964 lifetimes extended, though they can be if required. 966 6.6. Multiple Addresses and Prefixes 968 The protocol allows a client to receive multiple addresses. During 969 typical operation, a client sends one instance of an IA_NA option and 970 the server assigns at most one address from each prefix assigned to 971 the link the client is attached to. In particular, the server can be 972 configured to serve addresses out of multiple prefixes for a given 973 link. This is useful in cases such as when a network renumbering 974 event is in progress. In a typical deployment the server will grant 975 one address per each IA_NA option (see Section 21.4). 977 A client can explicitly request multiple addresses by sending 978 multiple IA_NA options (and/or IA_TA options, see Section 21.5). A 979 client can send multiple IA_NA (and/or IA_TA) options in its initial 980 transmissions. Alternatively, it can send an extra Request message 981 with additional new IA_NA (and/or IA_TA) options (or include them in 982 a Renew message). 984 The same principle also applies to Prefix Delegation. In principle 985 the protocol allows a client to request new prefixes to be delegated 986 by sending additional IA_PD options (see Section 21.21). However, a 987 typical operator usually prefers to delegate a single, larger prefix. 988 In most deployments it recommended for the client to request a larger 989 prefix in its initial transmissions rather than request additional 990 prefixes later on. 992 The exact behavior of the server (whether to grant additional 993 addresses and prefixes or not) is up to the server policy and is 994 outside of scope of this document. 996 For more information on how the server distinguishes between IA 997 option instances, see Section 12. 999 7. DHCP Constants 1001 This section describes various program and networking constants used 1002 by DHCP. 1004 7.1. Multicast Addresses 1006 DHCP makes use of the following multicast addresses: 1008 All_DHCP_Relay_Agents_and_Servers (ff02::1:2) A link-scoped 1009 multicast address used by a client to communicate 1010 with neighboring (i.e., on-link) relay agents and 1011 servers. All servers and relay agents are members of 1012 this multicast group. 1014 All_DHCP_Servers (ff05::1:3) A site-scoped multicast address used by 1015 a relay agent to communicate with servers, either 1016 because the relay agent wants to send messages to all 1017 servers or because it does not know the unicast 1018 addresses of the servers. Note that in order for a 1019 relay agent to use this address, it must have an 1020 address of sufficient scope to be reachable by the 1021 servers. All servers within the site are members of 1022 this multicast group on the interfaces which are 1023 within the site. 1025 7.2. UDP Ports 1027 Clients listen for DHCP messages on UDP port 546. Servers and relay 1028 agents listen for DHCP messages on UDP port 547. 1030 7.3. DHCP Message Types 1032 DHCP defines the following message types. More detail on these 1033 message types can be found in Section 8 and Section 9. Additional 1034 message types have been defined and may be defined in the future - 1035 see https://www.iana.org/assignments/dhcpv6-parameters. The numeric 1036 encoding for each message type is shown in parentheses. 1038 SOLICIT (1) A client sends a Solicit message to locate servers. 1040 ADVERTISE (2) A server sends an Advertise message to indicate that 1041 it is available for DHCP service, in response to a 1042 Solicit message received from a client. 1044 REQUEST (3) A client sends a Request message to request 1045 configuration parameters, including addresses and/or 1046 delegated prefixes, from a specific server. 1048 CONFIRM (4) A client sends a Confirm message to any available 1049 server to determine whether the addresses it was 1050 assigned are still appropriate to the link to which 1051 the client is connected. 1053 RENEW (5) A client sends a Renew message to the server that 1054 originally provided the client's leases and 1055 configuration parameters to extend the lifetimes on 1056 the leases assigned to the client and to update other 1057 configuration parameters. 1059 REBIND (6) A client sends a Rebind message to any available 1060 server to extend the lifetimes on the leases assigned 1061 to the client and to update other configuration 1062 parameters; this message is sent after a client 1063 receives no response to a Renew message. 1065 REPLY (7) A server sends a Reply message containing assigned 1066 leases and configuration parameters in response to a 1067 Solicit, Request, Renew, or Rebind message received 1068 from a client. A server sends a Reply message 1069 containing configuration parameters in response to an 1070 Information-request message. A server sends a Reply 1071 message in response to a Confirm message confirming 1072 or denying that the addresses assigned to the client 1073 are appropriate to the link to which the client is 1074 connected. A server sends a Reply message to 1075 acknowledge receipt of a Release or Decline message. 1077 RELEASE (8) A client sends a Release message to the server that 1078 assigned leases to the client to indicate that the 1079 client will no longer use one or more of the assigned 1080 leases. 1082 DECLINE (9) A client sends a Decline message to a server to 1083 indicate that the client has determined that one or 1084 more addresses assigned by the server are already in 1085 use on the link to which the client is connected. 1087 RECONFIGURE (10) A server sends a Reconfigure message to a client to 1088 inform the client that the server has new or updated 1089 configuration parameters, and that the client is to 1090 initiate a Renew/Reply or Information-request/Reply 1091 transaction with the server in order to receive the 1092 updated information. 1094 INFORMATION-REQUEST (11) A client sends an Information-request 1095 message to a server to request configuration 1096 parameters without the assignment of any leases to 1097 the client. 1099 RELAY-FORW (12) A relay agent sends a Relay-forward message to relay 1100 messages to servers, either directly or through 1101 another relay agent. The received message, either a 1102 client message or a Relay-forward message from 1103 another relay agent, is encapsulated in an option in 1104 the Relay-forward message. 1106 RELAY-REPL (13) A server sends a Relay-reply message to a relay agent 1107 containing a message that the relay agent delivers to 1108 a client. The Relay-reply message may be relayed by 1109 other relay agents for delivery to the destination 1110 relay agent. 1112 The server encapsulates the client message as an 1113 option in the Relay-reply message, which the relay 1114 agent extracts and relays to the client. 1116 7.4. DHCP Option Codes 1118 DHCP makes extensive use of options in messages and some of these are 1119 defined later in Section 21. Additional options are defined in other 1120 documents or may be defined in the future. 1122 7.5. Status Codes 1124 DHCP uses status codes to communicate the success or failure of 1125 operations requested in messages from clients and servers, and to 1126 provide additional information about the specific cause of the 1127 failure of a message. The specific status codes are defined in 1128 Section 21.13. 1130 If the Status Code option (see Section 21.13) does not appear in a 1131 message in which the option could appear, the status of the message 1132 is assumed to be Success. 1134 7.6. Transmission and Retransmission Parameters 1136 This section presents a table of values used to describe the message 1137 transmission behavior of clients and servers. Some of the values are 1138 adjusted by a randomization factor and backoffs (see Section 15) and 1139 transmissions may also be influenced by rate limiting (see 1140 Section 14.1). 1142 +-----------------+-----------------+-------------------------------+ 1143 | Parameter | Default | Description | 1144 +-----------------+-----------------+-------------------------------+ 1145 | SOL_MAX_DELAY | 1 sec | Max delay of first Solicit | 1146 | SOL_TIMEOUT | 1 sec | Initial Solicit timeout | 1147 | SOL_MAX_RT | 3600 secs | Max Solicit timeout value | 1148 | REQ_TIMEOUT | 1 sec | Initial Request timeout | 1149 | REQ_MAX_RT | 30 secs | Max Request timeout value | 1150 | REQ_MAX_RC | 10 | Max Request retry attempts | 1151 | CNF_MAX_DELAY | 1 sec | Max delay of first Confirm | 1152 | CNF_TIMEOUT | 1 sec | Initial Confirm timeout | 1153 | CNF_MAX_RT | 4 secs | Max Confirm timeout | 1154 | CNF_MAX_RD | 10 secs | Max Confirm duration | 1155 | REN_TIMEOUT | 10 secs | Initial Renew timeout | 1156 | REN_MAX_RT | 600 secs | Max Renew timeout value | 1157 | REB_TIMEOUT | 10 secs | Initial Rebind timeout | 1158 | REB_MAX_RT | 600 secs | Max Rebind timeout value | 1159 | INF_MAX_DELAY | 1 sec | Max delay of first | 1160 | | | Information-request | 1161 | INF_TIMEOUT | 1 sec | Initial Information-request | 1162 | | | timeout | 1163 | INF_MAX_RT | 3600 secs | Max Information-request | 1164 | | | timeout value | 1165 | REL_TIMEOUT | 1 sec | Initial Release timeout | 1166 | REL_MAX_RC | 4 | MAX Release retry attempts | 1167 | DEC_TIMEOUT | 1 sec | Initial Decline timeout | 1168 | DEC_MAX_RC | 4 | Max Decline retry attempts | 1169 | REC_TIMEOUT | 2 secs | Initial Reconfigure timeout | 1170 | REC_MAX_RC | 8 | Max Reconfigure attempts | 1171 | HOP_COUNT_LIMIT | 8 | Max hop count in a Relay- | 1172 | | | forward message | 1173 | IRT_DEFAULT | 86400 secs (24 | Default information refresh | 1174 | | hours) | time | 1175 | IRT_MINIMUM | 600 secs | Min information refresh time | 1176 | MAX_WAIT_TIME | 60 secs | Maximum required time to wait | 1177 | | | for a response | 1178 +-----------------+-----------------+-------------------------------+ 1180 Table 1: Transmission and Retransmission Parameters 1182 7.7. Representation of Time Values and "Infinity" as a Time Value 1184 All time values for lifetimes, T1, and T2 are unsigned 32-bit 1185 integers and are expressed in seconds. The value 0xffffffff is taken 1186 to mean "infinity" when used as a lifetime (as in [RFC4861]) or a 1187 value for T1 or T2. 1189 Setting the valid lifetime of an address or a delegated prefix to 1190 0xffffffff ("infinity") amounts to a permanent address or delegation 1191 of the prefix to a client and should only be used in cases were 1192 permanent assignments are desired. 1194 Care should be taken in setting T1 or T2 to 0xffffffff ("infinity"). 1195 A client will never attempt to extend the lifetimes of any addresses 1196 in an IA with T1 set to 0xffffffff. A client will never attempt to 1197 use a Rebind message to locate a different server to extend the 1198 lifetimes of any addresses in an IA with T2 set to 0xffffffff. 1200 8. Client/Server Message Formats 1202 All DHCP messages sent between clients and servers share an identical 1203 fixed format header and a variable format area for options. 1205 All values in the message header and in options are in network byte 1206 order. 1208 Options are stored serially in the options field, with no padding 1209 between the options. Options are byte-aligned but are not aligned in 1210 any other way such as on 2 or 4 byte boundaries. 1212 The following diagram illustrates the format of DHCP messages sent 1213 between clients and servers: 1215 0 1 2 3 1216 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 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | msg-type | transaction-id | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | | 1221 . options . 1222 . (variable) . 1223 | | 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 Figure 2: Client/Server message format 1228 msg-type Identifies the DHCP message type; the 1229 available message types are listed in 1230 Section 7.3. A one octet long field. 1232 transaction-id The transaction ID for this message exchange. 1233 A three octets long field. 1235 options Options carried in this message; options are 1236 described in Section 21. A variable length 1237 field (4 octets less than the size of the 1238 message). 1240 9. Relay Agent/Server Message Formats 1242 Relay agents exchange messages with other relay agents and servers to 1243 relay messages between clients and servers that are not connected to 1244 the same link. 1246 All values in the message header and in options are in network byte 1247 order. 1249 Options are stored serially in the options field, with no padding 1250 between the options. Options are byte-aligned but are not aligned in 1251 any other way such as on 2 or 4 byte boundaries. 1253 There are two relay agent messages, which share the following format: 1255 0 1 2 3 1256 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 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | msg-type | hop-count | | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1260 | | 1261 | link-address | 1262 | | 1263 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1264 | | | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1266 | | 1267 | peer-address | 1268 | | 1269 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1270 | | | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1272 . . 1273 . options (variable number and length) .... . 1274 | | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 Figure 3: Relay Agent/Server message format 1279 The following sections describe the use of the Relay Agent message 1280 header. 1282 9.1. Relay-forward Message 1284 The following table defines the use of message fields in a Relay- 1285 forward message. 1287 msg-type RELAY-FORW (12). A one octet long field. 1289 hop-count Number of relay agents that have already 1290 relayed this message. A one octet long 1291 field. 1293 link-address An address that may be used by the server to 1294 identify the link on which the client is 1295 located. This is typically a globally unique 1296 address (including unique local address, 1297 [RFC4193]), but see discussion in 1298 Section 19.1.1. A 16 octets long field 1300 peer-address The address of the client or relay agent from 1301 which the message to be relayed was received. 1302 A 16 octets long field. 1304 options MUST include a Relay Message option (see 1305 Section 21.10); MAY include other options, 1306 such as the Interface-Id option (see 1307 Section 21.18), added by the relay agent. A 1308 variable length field (34 octets less than 1309 the size of the message). 1311 See Section 13.1 for an explanation how link-address is used. 1313 9.2. Relay-reply Message 1315 The following table defines the use of message fields in a Relay- 1316 reply message. 1318 msg-type RELAY-REPL (13). A one octet long field. 1320 hop-count Copied from the Relay-forward message. A one 1321 octet long field. 1323 link-address Copied from the Relay-forward message. A 16 1324 octets long field. 1326 peer-address Copied from the Relay-forward message. A 16 1327 octets long field. 1329 options MUST include a Relay Message option (see 1330 Section 21.10); MAY include other options, 1331 such as the Interface-Id option (see 1332 Section 21.18). A variable length field (34 1333 octets less than the size of the message). 1335 10. Representation and Use of Domain Names 1337 So that domain names may be encoded uniformly, a domain name or a 1338 list of domain names is encoded using the technique described in 1339 section 3.1 of [RFC1035]. A domain name, or list of domain names, in 1340 DHCP MUST NOT be stored in compressed form, as described in section 1341 4.1.4 of [RFC1035]. 1343 11. DHCP Unique Identifier (DUID) 1345 Each DHCP client and server has a DUID. DHCP servers use DUIDs to 1346 identify clients for the selection of configuration parameters and in 1347 the association of IAs with clients. DHCP clients use DUIDs to 1348 identify a server in messages where a server needs to be identified. 1349 See Section 21.2 and Section 21.3 for the representation of a DUID in 1350 a DHCP message. 1352 Clients and servers MUST treat DUIDs as opaque values and MUST only 1353 compare DUIDs for equality. Clients and servers SHOULD NOT in any 1354 other way interpret DUIDs. Clients and servers MUST NOT restrict 1355 DUIDs to the types defined in this document, as additional DUID types 1356 may be defined in the future. It should be noted that an attempt to 1357 parse a DUID to obtain a client's link-layer address is unreliable as 1358 there is no guarantee that the client is still using the same link- 1359 layer address as when it generated its DUID. And, such an attempt 1360 will be more and more unreliable as more clients adopt privacy 1361 measures, such as those defined in [RFC7844]. It is recommended to 1362 rely on the mechanism defined in [RFC6939]. 1364 The DUID is carried in an option because it may be variable in length 1365 and because it is not required in all DHCP messages. The DUID is 1366 designed to be unique across all DHCP clients and servers, and stable 1367 for any specific client or server - that is, the DUID used by a 1368 client or server SHOULD NOT change over time if at all possible; for 1369 example, a device's DUID should not change as a result of a change in 1370 the device's network hardware. The stability of the DUID includes 1371 changes to virtual interfaces, such as logical PPP (over Ethernet) 1372 interfaces that may come and go in Customer Premise Equipment 1373 routers. The client may change its DUID as specified in [RFC7844]. 1375 The motivation for having more than one type of DUID is that the DUID 1376 must be globally unique, and must also be easy to generate. The sort 1377 of globally-unique identifier that is easy to generate for any given 1378 device can differ quite widely. Also, some devices may not contain 1379 any persistent storage. Retaining a generated DUID in such a device 1380 is not possible, so the DUID scheme must accommodate such devices. 1382 11.1. DUID Contents 1384 A DUID consists of a two octets type code represented in network byte 1385 order, followed by a variable number of octets that make up the 1386 actual identifier. The length of the DUID (not including the type 1387 code) is at least 1 octet and at most 128 octets. The following 1388 types are currently defined: 1390 +------+------------------------------------------------------+ 1391 | Type | Description | 1392 +------+------------------------------------------------------+ 1393 | 1 | Link-layer address plus time | 1394 | 2 | Vendor-assigned unique ID based on Enterprise Number | 1395 | 3 | Link-layer address | 1396 | 4 | Universally Unique IDentifier (UUID) - see [RFC6355] | 1397 +------+------------------------------------------------------+ 1399 Table 2: DUID Types 1401 Formats for the variable field of the DUID for the first three of the 1402 above types are shown below. The fourth type, DUID-UUID [RFC6355], 1403 can be used in situations where there is a UUID stored in a device's 1404 firmware settings. 1406 11.2. DUID Based on Link-layer Address Plus Time, DUID-LLT 1408 This type of DUID consists of a two octets type field containing the 1409 value 1, a two octets hardware type code, four octets containing a 1410 time value, followed by link-layer address of any one network 1411 interface that is connected to the DHCP device at the time that the 1412 DUID is generated. The time value is the time that the DUID is 1413 generated represented in seconds since midnight (UTC), January 1, 1414 2000, modulo 2^32. The hardware type MUST be a valid hardware type 1415 assigned by IANA, see [IANA-HARDWARE-TYPES]. Both the time and the 1416 hardware type are stored in network byte order. For Ethernet 1417 hardware types, the link-layer address is stored in canonical form, 1418 as described in [RFC2464]. 1420 The following diagram illustrates the format of a DUID-LLT: 1422 0 1 2 3 1423 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 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | DUID-Type (1) | hardware type (16 bits) | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | time (32 bits) | 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 . . 1430 . link-layer address (variable length) . 1431 . . 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 Figure 4: DUID-LLT format 1436 The choice of network interface can be completely arbitrary, as long 1437 as that interface provides a globally unique link-layer address for 1438 the link type, and the same DUID-LLT SHOULD be used in configuring 1439 all network interfaces connected to the device, regardless of which 1440 interface's link-layer address was used to generate the DUID-LLT. 1442 Clients and servers using this type of DUID MUST store the DUID-LLT 1443 in stable storage, and MUST continue to use this DUID-LLT even if the 1444 network interface used to generate the DUID-LLT is removed. Clients 1445 and servers that do not have any stable storage MUST NOT use this 1446 type of DUID. 1448 Clients and servers that use this DUID SHOULD attempt to configure 1449 the time prior to generating the DUID, if that is possible, and MUST 1450 use some sort of time source (for example, a real-time clock) in 1451 generating the DUID, even if that time source could not be configured 1452 prior to generating the DUID. The use of a time source makes it 1453 unlikely that two identical DUID-LLTs will be generated if the 1454 network interface is removed from the client and another client then 1455 uses the same network interface to generate a DUID-LLT. A collision 1456 between two DUID-LLTs is very unlikely even if the clocks have not 1457 been configured prior to generating the DUID. 1459 This method of DUID generation is recommended for all general purpose 1460 computing devices such as desktop computers and laptop computers, and 1461 also for devices such as printers, routers, and so on, that contain 1462 some form of writable non-volatile storage. 1464 It is possible that this algorithm for generating a DUID could result 1465 in a client identifier collision. A DHCP client that generates a 1466 DUID-LLT using this mechanism MUST provide an administrative 1467 interface that replaces the existing DUID with a newly-generated 1468 DUID-LLT. 1470 11.3. DUID Assigned by Vendor Based on Enterprise Number, DUID-EN 1472 This form of DUID is assigned by the vendor to the device. It 1473 consists of the four octet vendor's registered Private Enterprise 1474 Number as maintained by IANA [IANA-PEN] followed by a unique 1475 identifier assigned by the vendor. The following diagram summarizes 1476 the structure of a DUID-EN: 1478 0 1 2 3 1479 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 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 | DUID-Type (2) | enterprise-number | 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 | enterprise-number (contd) | | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1485 . identifier . 1486 . (variable length) . 1487 . . 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 Figure 5: DUID-EN format 1492 The source of the identifier is left up to the vendor defining it, 1493 but each identifier part of each DUID-EN MUST be unique to the device 1494 that is using it, and MUST be assigned to the device no later than at 1495 the first usage and stored in some form of non-volatile storage. 1496 This typically means being assigned during manufacture process in 1497 case of physical devices or when the image is created or booted for 1498 the first time in case of virtual machines. The generated DUID 1499 SHOULD be recorded in non-erasable storage. The enterprise-number is 1500 the vendor's registered Private Enterprise Number as maintained by 1501 IANA [IANA-PEN]. The enterprise-number is stored as an unsigned 32 1502 bit number. 1504 An example DUID of this type might look like this: 1506 +---+---+---+---+---+---+---+---+ 1507 | 0 | 2 | 0 | 0 | 0 | 9| 12|192| 1508 +---+---+---+---+---+---+---+---+ 1509 |132|211| 3 | 0 | 9 | 18| 1510 +---+---+---+---+---+---+ 1512 Figure 6: DUID-EN example 1514 This example includes the two octets type of 2, the Enterprise Number 1515 (9), followed by eight octets of identifier data 1516 (0x0CC084D303000912). 1518 11.4. DUID Based on Link-layer Address, DUID-LL 1520 This type of DUID consists of two octets containing the DUID type 3, 1521 a two octets network hardware type code, followed by the link-layer 1522 address of any one network interface that is permanently connected to 1523 the client or server device. For example, a node that has a network 1524 interface implemented in a chip that is unlikely to be removed and 1525 used elsewhere could use a DUID-LL. The hardware type MUST be a 1526 valid hardware type assigned by IANA, see [IANA-HARDWARE-TYPES]. The 1527 hardware type is stored in network byte order. The link-layer 1528 address is stored in canonical form, as described in [RFC2464]. The 1529 following diagram illustrates the format of a DUID-LL: 1531 0 1 2 3 1532 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 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | DUID-Type (3) | hardware type (16 bits) | 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 . . 1537 . link-layer address (variable length) . 1538 . . 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 Figure 7: DUID-LL format 1543 The choice of network interface can be completely arbitrary, as long 1544 as that interface provides a unique link-layer address and is 1545 permanently attached to the device on which the DUID-LL is being 1546 generated. The same DUID-LL SHOULD be used in configuring all 1547 network interfaces connected to the device, regardless of which 1548 interface's link-layer address was used to generate the DUID. 1550 DUID-LL is recommended for devices that have a permanently-connected 1551 network interface with a link-layer address, and do not have 1552 nonvolatile, writable stable storage. DUID-LL SHOULD NOT be used by 1553 DHCP clients or servers that cannot tell whether or not a network 1554 interface is permanently attached to the device on which the DHCP 1555 client is running. 1557 11.5. DUID Based on Universally Unique IDentifier (UUID), DUID-UUID 1559 This type of DUID consists of 16 octets containing a 128-bit UUID. 1560 [RFC6355] details when to use this type, and how to pick an 1561 appropriate source of the UUID. 1563 0 1 2 3 1564 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 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | DUID-Type (4) | UUID (128 bits) | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1568 | | 1569 | | 1570 | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 | | 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1574 Figure 8: DUID-UUID format 1576 12. Identity Association 1578 An "identity-association" (IA) is a construct through which a server 1579 and a client can identify, group, and manage a set of related IPv6 1580 addresses or delegated prefixes. Each IA consists of an IAID and 1581 associated configuration information. 1583 The IAID uniquely identifies the IA and MUST be chosen to be unique 1584 among the IAIDs for that IA type on the client (i.e., IA_NA with IAID 1585 0 is unique from IA_TA with IAID 0). The IAID is chosen by the 1586 client. For any given use of an IA by the client, the IAID for that 1587 IA MUST be consistent across restarts of the DHCP client. The client 1588 may maintain consistency either by storing the IAID in non-volatile 1589 storage or by using an algorithm that will consistently produce the 1590 same IAID as long as the configuration of the client has not changed. 1591 There may be no way for a client to maintain consistency of the IAIDs 1592 if it does not have non-volatile storage and the client's hardware 1593 configuration changes. If the client uses only one IAID, it can use 1594 a well-known value, e.g., zero. 1596 If the client wishes to obtain a distinctly new address or prefix and 1597 deprecate the existing one, the client sends a Release message to the 1598 server for the IAs using the original IAID. Then the client creates 1599 a new IAID, to be used in future messages to obtain leases for the 1600 new IA. 1602 12.1. Identity Associations for Address Assignment 1604 A client must associate at least one distinct IA with each of its 1605 network interfaces for which it is to request the assignment of IPv6 1606 addresses from a DHCP server. The client uses the IAs assigned to an 1607 interface to obtain configuration information from a server for that 1608 interface. Each such IA must be associated with exactly one 1609 interface. 1611 The configuration information in an IA_NA option consists of one or 1612 more IPv6 addresses along with the T1 and T2 values for the IA. See 1613 Section 21.4 for the representation of an IA_NA in a DHCP message. 1615 The configuration information in an IA_TA option consists of one or 1616 more IPv6 addresses. See Section 21.5 for the representation of an 1617 IA_TA in a DHCP message. 1619 Each address in an IA has a preferred lifetime and a valid lifetime, 1620 as defined in [RFC4862]. The lifetimes are transmitted from the DHCP 1621 server to the client in the IA Address option (see Section 21.6). 1622 The lifetimes apply to the use of addresses, as described in section 1623 5.5.4 of [RFC4862]. 1625 12.2. Identity Associations for Prefix Delegation 1627 An IA_PD is different from an IA for address assignment, in that it 1628 does not need to be associated with exactly one interface. One IA_PD 1629 can be associated with the client, with a set of interfaces or with 1630 exactly one interface. A client configured to request delegated 1631 prefixes must create at least one distinct IA_PD. It may associate a 1632 distinct IA_PD with each of its downstream network interfaces and use 1633 that IA_PD to obtain a prefix for that interface from the server. 1635 The configuration information in an IA_PD option consists of one or 1636 more prefixes along with the T1 and T2 values for the IA_PD. See 1637 Section 21.21 for the representation of an IA_PD in a DHCP message. 1639 Each delegated prefix in an IA has a preferred lifetime and a valid 1640 lifetime, as defined in [RFC4862]. The lifetimes are transmitted 1641 from the DHCP server to the client in the IA Prefix option (see 1642 Section 21.22). The lifetimes apply to the use of delegated 1643 prefixes, as described in section 5.5.4 of [RFC4862]. 1645 13. Assignment to an IA 1647 13.1. Selecting Addresses for Assignment to an IA_NA 1649 A server selects addresses to be assigned to an IA_NA according to 1650 the address assignment policies determined by the server 1651 administrator and the specific information the server determines 1652 about the client from some combination of the following sources: 1654 - The link to which the client is attached. The server determines 1655 the link as follows: 1657 * If the server receives the message directly from the client and 1658 the source address in the IP datagram in which the message was 1659 received is a link-local address, then the client is on the 1660 same link to which the interface over which the message was 1661 received is attached. 1663 * If the server receives the message from a forwarding relay 1664 agent, then the client is on the same link as the one to which 1665 the interface, identified by the link-address field in the 1666 message from the relay agent, is attached. According to 1667 [RFC6221], the server MUST ignore any link-address field whose 1668 value is zero. The link-address in this case may come from any 1669 of the Relay-forward messages encapsulated in the received 1670 Relay-forward, and in general the most encapsulated (closest 1671 Relay-forward to the client) has the most useful value. 1673 * If the server receives the message directly from the client and 1674 the source address in the IP datagram in which the message was 1675 received is not a link-local address, then the client is on the 1676 link identified by the source address in the IP datagram (note 1677 that this situation can occur only if the server has enabled 1678 the use of unicast message delivery by the client and the 1679 client has sent a message for which unicast delivery is 1680 allowed). 1682 - The DUID supplied by the client. 1684 - Other information in options supplied by the client, e.g., IA 1685 Address options (see Section 21.6) that include the client's 1686 requests for specific addresses. 1688 - Other information in options supplied by the relay agent. 1690 By default, DHCP server implementations SHOULD NOT generate 1691 predictable addresses (see Section 4.7 of [RFC7721]). Server 1692 implementers are encouraged to review [RFC4941], [RFC7824], and 1693 [RFC7707] as to possible considerations for how to generate 1694 addresses. 1696 A server MUST NOT assign an address that is otherwise reserved for 1697 some other purpose. For example, a server MUST NOT assign addresses 1698 that use a reserved IPv6 Interface Identifier ([RFC5453], [RFC7136], 1699 [IANA-RESERVED-IID]). 1701 See [RFC7969] for a more detailed discussion on how servers determine 1702 a client's location on the network. 1704 13.2. Assignment of Temporary Addresses 1706 A client may request the assignment of temporary addresses (see 1707 [RFC4941] for the definition of temporary addresses). DHCP handling 1708 of address assignment is no different for temporary addresses. 1710 Clients ask for temporary addresses and servers assign them. 1711 Temporary addresses are carried in the Identity Association for 1712 Temporary Addresses (IA_TA) option (see Section 21.5). Each IA_TA 1713 option typically contains at least one temporary address for each of 1714 the prefixes on the link to which the client is attached. 1716 The lifetime of the assigned temporary address is set in the IA 1717 Address option (see Section 21.6) encapsulated in the IA_TA option. 1718 It is RECOMMENDED to set short lifetimes, typically shorter than 1719 TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME (see Section 5, 1720 [RFC4941]). 1722 A DHCP server implementation MAY generate temporary addresses 1723 referring to the algorithm defined in Section 3.2.1, [RFC4941], with 1724 the additional condition that any new address is not the same as any 1725 assigned address. 1727 The server MAY update the DNS for a temporary address, as described 1728 in section 4 of [RFC4941]. 1730 On the clients, by default, temporary addresses are preferred in 1731 source address selection, according to Rule 7, [RFC6724]. However, 1732 this policy is overridable. 1734 One of the most important properties of a temporary address is to 1735 make it difficult to link the address to different actions over time. 1736 So, it is NOT RECOMMENDED for a client to renew temporary addresses, 1737 though DHCP provides for such a possibility (see Section 21.5). 1739 13.3. Assignment of Prefixes for IA_PD 1741 The mechanism through which the server selects prefix(es) for 1742 delegation is not specified in this document. Examples of ways in 1743 which the server might select prefix(es) for a client include: static 1744 assignment based on subscription to an ISP; dynamic assignment from a 1745 pool of available prefixes; selection based on an external authority 1746 such as a RADIUS server using the Framed-IPv6-Prefix option as 1747 described in [RFC3162]. 1749 14. Transmission of Messages by a Client 1751 Unless otherwise specified in this document, or in a document that 1752 describes how IPv6 is carried over a specific type of link (for link 1753 types that do not support multicast), a client sends DHCP messages to 1754 the All_DHCP_Relay_Agents_and_Servers multicast address. 1756 DHCP servers SHOULD NOT care if the layer-2 address used was 1757 multicast or not, as long as the layer-3 address was correct. 1759 A client uses multicast to reach all servers or an individual server. 1760 An individual server is indicated by specifying that server's DUID in 1761 a Server Identifier option (see Section 21.3) in the client's message 1762 (all servers will receive this message but only the indicated server 1763 will respond). All servers are indicated by not supplying this 1764 option. 1766 A client may send some messages directly to a server using unicast, 1767 as described in Section 21.12. 1769 14.1. Rate Limiting 1771 In order to avoid prolonged message bursts that may be caused by 1772 possible logic loops, a DHCP client MUST limit the rate of DHCP 1773 messages it transmits or retransmits. One example is that a client 1774 obtains an address or delegated prefix, but does not like the 1775 response; so it reverts back to Solicit procedure, discovers the same 1776 (sole) server, requests an address or delegated prefix and gets the 1777 same address or delegated prefix as before (as the server has this 1778 previously requested lease assigned to this client). This loop can 1779 repeat infinitely if there is not a quit/stop mechanism. Therefore, 1780 a client must not initiate transmissions too frequently. 1782 A recommended method for implementing the rate limiting function is a 1783 token bucket, limiting the average rate of transmission to a certain 1784 number in a certain time interval. This method of bounding 1785 burstiness also guarantees that the long-term transmission rate will 1786 not be exceeded. 1788 TRT Transmission Rate Limit 1790 The Transmission Rate Limit parameter (TRT) SHOULD be configurable. 1791 A possible default could be 20 packets in 20 seconds. 1793 For a device that has multiple interfaces, the limit MUST be enforced 1794 on a per interface basis. 1796 Rate limiting of forwarded DHCP messages and server-side messages are 1797 out of scope of this specification. 1799 14.2. Client Behavior when T1 and/or T2 are 0 1801 In certain cases, T1 and/or T2 values may be set to zero. Currently 1802 there are three such cases: 1804 1. a client received an IA_NA option (see Section 21.4) with a 1805 zero value 1807 2. a client received an IA_PD option (see Section 21.21) with a 1808 zero value 1810 3. a client received an IA_TA option (see Section 21.5) (which 1811 does not contain T1 and T2 fields and are not generally 1812 renewed) 1814 This is an indication that the renew and rebind times are left at the 1815 client's discretion. However, they are not completely discretionary. 1817 When T1 and/or T2 values are set to zero, the client MUST choose a 1818 time to avoid packet storms. In particular, it MUST NOT transmit 1819 immediately. If the client received multiple IA options, it SHOULD 1820 pick renew and/or rebind transmission times so all IA options are 1821 handled in one exchange, if possible. The client MUST choose renew 1822 and rebind times to not violate rate limiting restrictions, defined 1823 in Section 14.1. 1825 15. Reliability of Client Initiated Message Exchanges 1827 DHCP clients are responsible for reliable delivery of messages in the 1828 client-initiated message exchanges described in Section 18. If a 1829 DHCP client fails to receive an expected response from a server, the 1830 client must retransmit its message according to the retransmission 1831 strategy described in this section. 1833 Note that the procedure described in this section is slightly 1834 modified when used with the Solicit message. The modified procedure 1835 is described in Section 18.2.1. 1837 The client begins the message exchange by transmitting a message to 1838 the server. The message exchange terminates when either the client 1839 successfully receives the appropriate response or responses from a 1840 server or servers, or when the message exchange is considered to have 1841 failed according to the retransmission mechanism described below. 1843 The client MUST update an "elapsed-time" value within an Elapsed Time 1844 option (see Section 21.9) in the retransmitted message. In some 1845 cases, the client may also need to modify values in IA Address (see 1846 Section 21.6) or IA Prefix options (see Section 21.22) if a valid 1847 lifetime for any of the client's leases expires before 1848 retransmission. Thus, whenever this document refers to a 1849 "retransmission" of a client's message, it refers to both modifying 1850 the original message and sending this new message instance to the 1851 server. 1853 The client retransmission behavior is controlled and described by the 1854 following variables: 1856 RT Retransmission timeout 1858 IRT Initial retransmission time 1860 MRC Maximum retransmission count 1862 MRT Maximum retransmission time 1864 MRD Maximum retransmission duration 1866 RAND Randomization factor 1868 Specific values for each of these parameters relevant to the various 1869 messages are given in the sub-sections of Section 18.2 using values 1870 defined in Table 1 in Section 7.6. The algorithm for RAND is common 1871 across all message transmissions. 1873 With each message transmission or retransmission, the client sets RT 1874 according to the rules given below. If RT expires before the message 1875 exchange terminates, the client recomputes RT and retransmits the 1876 message. 1878 Each of the computations of a new RT include a randomization factor 1879 (RAND), which is a random number chosen with a uniform distribution 1880 between -0.1 and +0.1. The randomization factor is included to 1881 minimize synchronization of messages transmitted by DHCP clients. 1883 The algorithm for choosing a random number does not need to be 1884 cryptographically sound. The algorithm SHOULD produce a different 1885 sequence of random numbers from each invocation of the DHCP client. 1887 RT for the first message transmission is based on IRT: 1889 RT = IRT + RAND*IRT 1891 RT for each subsequent message transmission is based on the previous 1892 value of RT: 1894 RT = 2*RTprev + RAND*RTprev 1896 MRT specifies an upper bound on the value of RT (disregarding the 1897 randomization added by the use of RAND). If MRT has a value of 0, 1898 there is no upper limit on the value of RT. Otherwise: 1900 if (RT > MRT) 1901 RT = MRT + RAND*MRT 1903 MRC specifies an upper bound on the number of times a client may 1904 retransmit a message. Unless MRC is zero, the message exchange fails 1905 once the client has transmitted the message MRC times. 1907 MRD specifies an upper bound on the length of time a client may 1908 retransmit a message. Unless MRD is zero, the message exchange fails 1909 once MRD seconds have elapsed since the client first transmitted the 1910 message. 1912 If both MRC and MRD are non-zero, the message exchange fails whenever 1913 either of the conditions specified in the previous two paragraphs are 1914 met. 1916 If both MRC and MRD are zero, the client continues to transmit the 1917 message until it receives a response. 1919 A client is not expected to listen for a response during the entire 1920 RT period and may turn off listening capabilities after waiting at 1921 least the shorter of RT and MAX_WAIT_TIME due to power consumption 1922 saving or other reasons. Of course, a client MUST listen for a 1923 Reconfigure if it has negotiated for its use with the server. 1925 16. Message Validation 1927 This section describes which options are valid in which kinds of 1928 message types. Should a client or server receive messages which 1929 contain known options which are invalid for the message, this section 1930 explains how to process it. For example, an IA option is not allowed 1931 to appear in an Information-request message. 1933 Clients and servers MAY choose either to extract information from 1934 such a message if the information is of use to the recipient, or to 1935 ignore such message completely and just discard it. 1937 If a server receives a message that it considers invalid, it MAY send 1938 a Reply (or Advertise as appropriate) with a Server Identifier option 1939 (see Section 21.3), a Client Identifier option (see Section 21.2) if 1940 one was included in the message and a Status Code option (see 1941 Section 21.13) with status UnspecFail. 1943 Clients, relay agents and servers MUST NOT discard messages that 1944 contain unknown options (or instances of vendor options with unknown 1945 enterprise-numbers). These should be ignored as if they were not 1946 present. This is critical to provide for later extension of the DHCP 1947 protocol. 1949 A server MUST discard any Solicit, Confirm, Rebind or Information- 1950 request messages it receives with a layer-3 unicast destination 1951 address. 1953 A client or server MUST discard any received DHCP messages with an 1954 unknown message type. 1956 16.1. Use of Transaction IDs 1958 The "transaction-id" field holds a value used by clients and servers 1959 to synchronize server responses to client messages. A client SHOULD 1960 generate a random number that cannot easily be guessed or predicted 1961 to use as the transaction ID for each new message it sends. Note 1962 that if a client generates easily predictable transaction 1963 identifiers, it may become more vulnerable to certain kinds of 1964 attacks from off-path intruders. A client MUST leave the transaction 1965 ID unchanged in retransmissions of a message. 1967 16.2. Solicit Message 1969 Clients MUST discard any received Solicit messages. 1971 Servers MUST discard any Solicit messages that do not include a 1972 Client Identifier option or that do include a Server Identifier 1973 option. 1975 16.3. Advertise Message 1977 Clients MUST discard any received Advertise message that meets any of 1978 the following conditions: 1980 - the message does not include a Server Identifier option (see 1981 Section 21.3). 1983 - the message does not include a Client Identifier option (see 1984 Section 21.2). 1986 - the contents of the Client Identifier option does not match the 1987 client's DUID. 1989 - the "transaction-id" field value does not match the value the 1990 client used in its Solicit message. 1992 Servers and relay agents MUST discard any received Advertise 1993 messages. 1995 16.4. Request Message 1997 Clients MUST discard any received Request messages. 1999 Servers MUST discard any received Request message that meets any of 2000 the following conditions: 2002 - the message does not include a Server Identifier option (see 2003 Section 21.3). 2005 - the contents of the Server Identifier option do not match the 2006 server's DUID. 2008 - the message does not include a Client Identifier option (see 2009 Section 21.2). 2011 16.5. Confirm Message 2013 Clients MUST discard any received Confirm messages. 2015 Servers MUST discard any received Confirm messages that do not 2016 include a Client Identifier option (see Section 21.2) or that do 2017 include a Server Identifier option (see Section 21.3). 2019 16.6. Renew Message 2021 Clients MUST discard any received Renew messages. 2023 Servers MUST discard any received Renew message that meets any of the 2024 following conditions: 2026 - the message does not include a Server Identifier option (see 2027 Section 21.3). 2029 - the contents of the Server Identifier option does not match the 2030 server's identifier. 2032 - the message does not include a Client Identifier option (see 2033 Section 21.2). 2035 16.7. Rebind Message 2037 Clients MUST discard any received Rebind messages. 2039 Servers MUST discard any received Rebind messages that do not include 2040 a Client Identifier option (see Section 21.2) or that do include a 2041 Server Identifier option (see Section 21.3). 2043 16.8. Decline Messages 2045 Clients MUST discard any received Decline messages. 2047 Servers MUST discard any received Decline message that meets any of 2048 the following conditions: 2050 - the message does not include a Server Identifier option (see 2051 Section 21.3). 2053 - the contents of the Server Identifier option does not match the 2054 server's identifier. 2056 - the message does not include a Client Identifier option (see 2057 Section 21.2). 2059 16.9. Release Message 2061 Clients MUST discard any received Release messages. 2063 Servers MUST discard any received Release message that meets any of 2064 the following conditions: 2066 - the message does not include a Server Identifier option (see 2067 Section 21.3). 2069 - the contents of the Server Identifier option does not match the 2070 server's identifier. 2072 - the message does not include a Client Identifier option (see 2073 Section 21.2). 2075 16.10. Reply Message 2077 Clients MUST discard any received Reply message that meets any of the 2078 following conditions: 2080 - the message does not include a Server Identifier option (see 2081 Section 21.3). 2083 - the "transaction-id" field in the message does not match the value 2084 used in the original message. 2086 If the client included a Client Identifier option (see 2087 Section 21.2)in the original message, the Reply message MUST include 2088 a Client Identifier option and the contents of the Client Identifier 2089 option MUST match the DUID of the client; OR, if the client did not 2090 include a Client Identifier option in the original message, the Reply 2091 message MUST NOT include a Client Identifier option. 2093 Servers and relay agents MUST discard any received Reply messages. 2095 16.11. Reconfigure Message 2097 Servers and relay agents MUST discard any received Reconfigure 2098 messages. 2100 Clients MUST discard any Reconfigure message that meets any of the 2101 following conditions: 2103 - the message was not unicast to the client. 2105 - the message does not include a Server Identifier option (see 2106 Section 21.3). 2108 - the message does not include a Client Identifier option (see 2109 Section 21.2) that contains the client's DUID. 2111 - the message does not include a Reconfigure Message option (see 2112 Section 21.19). 2114 - the Reconfigure Message option msg-type is not a valid value. 2116 - the message does not include authentication (such as RKAP, see 2117 Section 20.4) or fails authentication validation. 2119 16.12. Information-request Message 2121 Clients MUST discard any received Information-request messages. 2123 Servers MUST discard any received Information-request message that 2124 meets any of the following conditions: 2126 - The message includes a Server Identifier option (see Section 21.3) 2127 and the DUID in the option does not match the server's DUID. 2129 - The message includes an IA option. 2131 16.13. Relay-forward Message 2133 Clients MUST discard any received Relay-forward messages. 2135 16.14. Relay-reply Message 2137 Clients and servers MUST discard any received Relay-reply messages. 2139 17. Client Source Address and Interface Selection 2141 Client's behavior regarding interface selection is different 2142 depending on the purpose of the configuration. 2144 17.1. Address, Interface Selection for Address Assignment 2146 When a client sends a DHCP message to the 2147 All_DHCP_Relay_Agents_and_Servers multicast address, it SHOULD send 2148 the message through the interface for which configuration information 2149 (including the addresses) is being requested. However, the client 2150 MAY send the message through another interface if the interface which 2151 configuration is being requested for is a logical interface without 2152 direct link attachment or the client is certain that two interfaces 2153 are attached to the same link. 2155 When a client sends a DHCP message directly to a server using unicast 2156 (after receiving the Server Unicast option, see Section 21.12, from 2157 that server), the source address in the header of the IPv6 datagram 2158 MUST be an address assigned to the interface for which the client is 2159 interested in obtaining configuration and which is suitable for use 2160 by the server in responding to the client. 2162 17.2. Address, Interface Selection for Prefix Delegation 2164 Delegated prefixes are not associated with a particular interface in 2165 the same way as addresses are for address assignment, as mentioned in 2166 Section 17.1 above. 2168 When a client sends a DHCP message for the purpose of prefix 2169 delegation, it SHOULD be sent on the interface associated with the 2170 upstream router (typically, connected to an ISP network); see 2171 [RFC7084]. The upstream interface is typically determined by 2172 configuration. This rule applies even in the case where a separate 2173 IA_PD is used for each downstream interface. 2175 When a client sends a DHCP message directly to a server using unicast 2176 (after receiving the Server Unicast option, see Section 21.12, from 2177 that server), the source address SHOULD be an address from the 2178 upstream interface and which is suitable for use by the server in 2179 responding to the client. 2181 18. DHCP Configuration Exchanges 2183 A client initiates a message exchange with a server or servers to 2184 acquire or update configuration information of interest. A client 2185 has many reasons to initiate the configuration exchange. Some of the 2186 more common ones are: 2188 1. as part of the operating system configuration/bootstrap 2189 process, 2191 2. when requested to do so by the application layer (through an 2192 operating system specific API), 2194 3. when Router Advertisement indicates DHCPv6 is available for 2195 address configuration (see Section 4.2 of [RFC4861]), 2197 4. as required to extend the lifetime of address(es) and/or 2198 delegated prefix(es), using Renew and Rebind messages, 2200 5. or when requested to do so by a server - upon the receipt of a 2201 Reconfigure message. 2203 The client is responsible for creating IAs and requesting that a 2204 server assign addresses and/or delegated prefixes to the IAs. The 2205 client first creates the IAs and assigns IAIDs to them. The client 2206 then transmits a Solicit message containing the IA options describing 2207 the IAs. The client MUST NOT be using any of the addresses or 2208 delegated prefixes for which it tries to obtain the bindings by 2209 sending the Solicit message. In particular, if the client had some 2210 valid bindings and has chosen to start the server discovery process 2211 to obtain the same bindings from a different server, the client MUST 2212 stop using the addresses and delegated prefixes for the bindings it 2213 had obtained from the previous server (see Section 18.2.7 for more 2214 details on what stop using means), and which it is now trying to 2215 obtain from a new server. 2217 A DHCP client that does not need to have a DHCP server assign it IP 2218 addresses or delegated prefixes, can obtain configuration information 2219 such as a list of available DNS servers [RFC3646] or NTP servers 2220 [RFC4075] through a single message and reply exchange with a DHCP 2221 server. To obtain configuration information the client first sends 2222 an Information-request message (see Section 18.2.6) to the 2223 All_DHCP_Relay_Agents_and_Servers multicast address. Servers respond 2224 with a Reply message containing the configuration information for the 2225 client (see Section 18.3.6). 2227 To request the assignment of one or more addresses or delegated 2228 prefixes, a client first locates a DHCP server and then requests the 2229 assignment of addresses/prefixes and other configuration information 2230 from the server. The client does this by sending the Solicit message 2231 (see Section 18.2.1) to the All_DHCP_Relay_Agents_and_Servers 2232 multicast address and collecting Advertise messages from the servers 2233 which respond to the client's message and selects a server from which 2234 it wants to obtain configuration information. This process is 2235 referred to as server discovery. When the client has selected the 2236 server it sends a Request message to this server as described in 2237 Section 18.2.2. 2239 A client willing to perform the Solicit/Reply message exchange 2240 described in Section 18.2.1 includes a Rapid Commit option (see 2241 Section 21.14) in its Solicit message. 2243 Servers that can assign addresses or delegated prefixes to the IAs 2244 respond to the client with an Advertise message or Reply message if 2245 the client included a Rapid Commit option and the server is 2246 configured to accept it. 2248 If the server responds with an Advertise message, the client 2249 initiates a configuration exchange as described in Section 18.2.2. 2251 A server may initiate a message exchange with a client by sending a 2252 Reconfigure message to cause the client to send a Renew, Rebind or 2253 Information-request message to refresh its configuration information 2254 as soon as the Reconfigure message is received by the client. 2256 Figure 9 shows a timeline diagram of the messages exchanged between a 2257 client and two servers for the typical lifecycle of one or more 2258 leases. This is a combination of the 4-message exchange (to select a 2259 server and assign the lease(s) to the client) followed by two 2260 2-message exchanges (to extend the lifetime on the lease(s) and 2261 eventually release the lease(s)). 2263 Server Server 2264 (not selected) Client (selected) 2266 v v v 2267 | | | 2268 | Begins initialization | 2269 | | | 2270 start of | _____________/|\_____________ | 2271 4-message |/ Solicit | Solicit \| 2272 exchange | | | 2273 Determines | Determines 2274 configuration | configuration 2275 | | | 2276 |\ | ____________/| 2277 | \________ | /Advertise | 2278 | Advertise\ |/ | 2279 | \ | | 2280 | Collects Advertises | 2281 | \ | | 2282 | Selects configuration | 2283 | | | 2284 | _____________/|\_____________ | 2285 |/ Request | Request \| 2286 | | | 2287 | | Commits configuration 2288 | | | 2289 end of | | _____________/| 2290 4-message | |/ Reply | 2291 exchange | | | 2292 | Initialization complete | 2293 | | | 2294 . . . 2295 . . . 2296 | T1 (Renewal) Timer Expires | 2297 | | | 2298 2-message | _____________/|\_____________ | 2299 exchange |/ Renew | Renew \| 2300 | | | 2301 | | Commits extended lease(s) 2302 | | | 2303 | | _____________/| 2304 | |/ Reply | 2305 . . . 2306 . . . 2307 | | | 2308 | Graceful shutdown | 2309 | | | 2310 2-message | _____________/|\_____________ | 2311 exchange |/ Release | Release \| 2312 | | | 2313 | | Discards lease(s) 2314 | | | 2315 | | _____________/| 2316 | |/ Reply | 2317 | | | 2318 v v v 2320 Figure 9: Timeline diagram of the messages exchanged between a client 2321 and two servers for the typical lifecycle of one or more leases 2323 18.1. A Single Exchange for Multiple IA Options 2325 This document assumes that a client SHOULD use a single transaction 2326 for all of the IA options required on an interface as this simplifies 2327 the client implementation and reduces the potential number of 2328 transactions required (for the background on this design choice, 2329 refer to Section 4 of [RFC7550]). To facilitate a client's use of a 2330 single transaction for all IA options, servers MUST return the same 2331 T1/T2 values for all IA options in a Reply (see Section 18.3.2, 2332 Section 18.3.4, and Section 18.3.5), so that the client will generate 2333 a single transaction when renewing or rebinding its leases. However, 2334 because some servers may not yet conform to this requirement, a 2335 client MUST be prepared to select appropriate T1/T2 times as 2336 described in Section 18.2.4. 2338 18.2. Client Behavior 2340 A client uses the Solicit message to discover DHCP servers configured 2341 to assign leases or return other configuration parameters on the link 2342 to which the client is attached. 2344 A client uses Request, Renew, Rebind, Release and Decline messages 2345 during the normal life cycle of addresses and delegated prefixes. 2346 When a client detects it may have moved to a new link, it uses 2347 Confirm if it only has addresses and Rebind if it has delegated 2348 prefixes (and addresses). It uses Information-request messages when 2349 it needs configuration information but no addresses and no prefixes. 2351 When a client requests multiple IA option types or multiple instances 2352 of the same IA types in a Solicit, Request, Renew, or Rebind, it is 2353 possible that the available server(s) may only be configured to offer 2354 a subset of them. When possible, the client SHOULD use the best 2355 configuration available and continue to request the additional IAs in 2356 subsequent messages. This allows the client to maintain a single 2357 session and state machine. In practice, especially in the case of 2358 handling IA_NA and IA_PD requests [RFC7084], this situation should be 2359 rare or a result of a temporary operational error. Thus, it is more 2360 likely for the client to get all configuration if it continues, in 2361 each subsequent configuration exchange, to request all the 2362 configuration information it is programmed to try to obtain, 2363 including any stateful configuration options for which no results 2364 were returned in previous message exchanges. 2366 Upon receipt of a Reconfigure message from the server, a client 2367 responds with a Renew, Rebind or an Information-request message as 2368 indicated by the Reconfigure Message option (see Section 21.19). The 2369 client SHOULD be suspicious of the Reconfigure message (they may be 2370 faked), and it MUST NOT abandon any resources it might have already 2371 obtained. The client SHOULD treat the Reconfigure message as if the 2372 T1 timer had expired. The client will expect the server to send IAs 2373 and/or other configuration information to the client in a Reply 2374 message. 2376 If the client has a source address of sufficient scope that can be 2377 used by the server as a return address, and the client has received a 2378 Server Unicast option (see Section 21.12) from the server, the client 2379 SHOULD unicast any Request, Renew, Release and Decline messages to 2380 the server. 2382 Use of unicast may avoid delays due to the relaying of messages by 2383 relay agents, as well as avoid overhead on servers due to the 2384 delivery of client messages to multiple servers. However, requiring 2385 the client to relay all DHCP messages through a relay agent enables 2386 the inclusion of relay agent options in all messages sent by the 2387 client. The server should enable the use of unicast only when relay 2388 agent options will not be used. 2390 18.2.1. Creation and Transmission of Solicit Messages 2392 The client sets the "msg-type" field to SOLICIT. The client 2393 generates a transaction ID and inserts this value in the 2394 "transaction-id" field. 2396 The client MUST include a Client Identifier option (see Section 21.2) 2397 to identify itself to the server. The client includes IA options for 2398 any IAs to which it wants the server to assign leases. 2400 The client MUST include an Elapsed Time option (see Section 21.9) to 2401 indicate how long the client has been trying to complete the current 2402 DHCP message exchange. 2404 The client uses IA_NA options (see Section 21.4) to request the 2405 assignment of non-temporary addresses, IA_TA options (see 2406 Section 21.5) to request the assignment of temporary addresses, and 2407 IA_PD options (see Section 21.21) to request prefix delegation. 2408 Either IA_NA, IA_TA or IA_PD options, or a combination of all, can be 2409 included in DHCP messages. In addition, multiple instances of any IA 2410 option type can be included. 2412 The client MAY include addresses in IA Address options (see 2413 Section 21.6) encapsulated within IA_NA and IA_TA options as hints to 2414 the server about the addresses for which the client has a preference. 2416 The client MAY include values in IA Prefix options (see 2417 Section 21.22) encapsulated within IA_PD options as hints for the 2418 delegated prefix and/or prefix length for which the client has a 2419 preference. See Section 18.2.4 for more on prefix length hints. 2421 The client MUST include an Option Request option (see Section 21.7) 2422 to request the SOL_MAX_RT option (see Section 21.24) and any other 2423 options the client is interested in receiving. The client MAY 2424 additionally include instances of those options that are identified 2425 in the Option Request option, with data values as hints to the server 2426 about parameter values the client would like to have returned. 2428 The client includes a Reconfigure Accept option (see Section 21.20) 2429 if the client is willing to accept Reconfigure messages from the 2430 server. 2432 The client MUST NOT include any other options in the Solicit message, 2433 except as specifically allowed in the definition of individual 2434 options. 2436 The first Solicit message from the client on the interface SHOULD be 2437 delayed by a random amount of time between 0 and SOL_MAX_DELAY. This 2438 random delay helps desynchronize clients which start a DHCP session 2439 at the same time, such as after recovery from a power failure or 2440 after a router outage after seeing that DHCP is available in Router 2441 Advertisement messages (see Section 4.2 of [RFC4861]). 2443 The client transmits the message according to Section 15, using the 2444 following parameters: 2446 IRT SOL_TIMEOUT 2448 MRT SOL_MAX_RT 2450 MRC 0 2452 MRD 0 2454 A client that wishes to use the Rapid Commit 2-message exchange 2455 includes a Rapid Commit option (see Section 21.14) in its Solicit 2456 message. The client may receive a number of different replies from 2457 different servers. The client will make note of any valid Advertise 2458 messages that it receives. The client will discard any Reply 2459 messages that do not contain the Rapid Commit option. 2461 Upon receipt of a valid Reply with the Rapid Commit option, the 2462 client processes the message as described in Section 18.2.10 2463 At the end of the first RT period, if no suitable Reply messages are 2464 received, but the client has valid Advertise messages, then the 2465 client processes the Advertise as described in Section 18.2.9. 2467 If the client subsequently receives a valid Reply message that 2468 includes a Rapid Commit option, it either: 2470 - processes the Reply message as described in Section 18.2.10, and 2471 discards any Reply messages received in response to the Request 2472 message, or 2474 - processes any Reply messages received in response to the Request 2475 message and discards the Reply message that includes the Rapid 2476 Commit option. 2478 If the client is waiting for an Advertise message, the mechanism in 2479 Section 15 is modified as follows for use in the transmission of 2480 Solicit messages. The message exchange is not terminated by the 2481 receipt of an Advertise before the first RT has elapsed. Rather, the 2482 client collects valid Advertise messages until the first RT has 2483 elapsed. Also, the first RT MUST be selected to be strictly greater 2484 than IRT by choosing RAND to be strictly greater than 0. 2486 A client MUST collect valid Advertise messages for the first RT 2487 seconds, unless it receives a valid Advertise message with a 2488 preference value of 255. The preference value is carried in the 2489 Preference option (see Section 21.8). Any valid Advertise that does 2490 not include a Preference option is considered to have a preference 2491 value of 0. If the client receives a valid Advertise message that 2492 includes a Preference option with a preference value of 255, the 2493 client immediately begins a client-initiated message exchange (as 2494 described in Section 18.2.2) by sending a Request message to the 2495 server from which the Advertise message was received. If the client 2496 receives a valid Advertise message that does not include a Preference 2497 option with a preference value of 255, the client continues to wait 2498 until the first RT elapses. If the first RT elapses and the client 2499 has received a valid Advertise message, the client SHOULD continue 2500 with a client-initiated message exchange by sending a Request 2501 message. 2503 If the client does not receive any valid Advertise messages before 2504 the first RT has elapsed, it begins the retransmission mechanism 2505 described in Section 15. The client terminates the retransmission 2506 process as soon as it receives any valid Advertise message, and the 2507 client acts on the received Advertise message without waiting for any 2508 additional Advertise messages. 2510 A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client 2511 is configured with either MRC or MRD set to a value other than 0, it 2512 MUST stop trying to configure the interface if the message exchange 2513 fails. After the DHCP client stops trying to configure the 2514 interface, it SHOULD restart the reconfiguration process after some 2515 external event, such as user input, system restart, or when the 2516 client is attached to a new link. 2518 18.2.2. Creation and Transmission of Request Messages 2520 The client uses a Request message to populate IAs with leases and 2521 obtain other configuration information. The client includes one or 2522 more IA options in the Request message. The server then returns 2523 leases and other information about the IAs to the client in IA 2524 options in a Reply message. 2526 The client generates a transaction ID and inserts this value in the 2527 "transaction-id" field. 2529 The client MUST include the identifier of the destination server in a 2530 Server Identifier option (see Section 21.3). 2532 The client MUST include a Client Identifier option (see Section 21.2) 2533 to identify itself to the server. The client adds any other 2534 appropriate options, including one or more IA options. 2536 The client MUST include an Elapsed Time option (see Section 21.9) to 2537 indicate how long the client has been trying to complete the current 2538 DHCP message exchange. 2540 The client MUST include an Option Request option (see Section 21.7) 2541 to request the SOL_MAX_RT option (see Section 21.24) and any other 2542 options the client is interested in receiving. The client MAY 2543 additionally include instances of those options that are identified 2544 in the Option Request option, with data values as hints to the server 2545 about parameter values the client would like to have returned. 2547 The client includes a Reconfigure Accept option (see Section 21.20) 2548 if the client is willing to accept Reconfigure messages from the 2549 server. 2551 The client transmits the message according to Section 15, using the 2552 following parameters: 2554 IRT REQ_TIMEOUT 2556 MRT REQ_MAX_RT 2557 MRC REQ_MAX_RC 2559 MRD 0 2561 If the message exchange fails, the client takes an action based on 2562 the client's local policy. Examples of actions the client might take 2563 include: 2565 - Select another server from a list of servers known to the client; 2566 for example, servers that responded with an Advertise message. 2568 - Initiate the server discovery process described in Section 18. 2570 - Terminate the configuration process and report failure. 2572 18.2.3. Creation and Transmission of Confirm Messages 2574 The client uses a Confirm message when it has only addresses (no 2575 delegated prefixes) assigned by a DHCP server to determine if it is 2576 still connected to the same link when the client detects a change in 2577 network information as described in Section 18.2.12. 2579 The client sets the "msg-type" field to CONFIRM. The client 2580 generates a transaction ID and inserts this value in the 2581 "transaction-id" field. 2583 The client MUST include a Client Identifier option (see Section 21.2) 2584 to identify itself to the server. 2586 The client MUST include an Elapsed Time option (see Section 21.9) to 2587 indicate how long the client has been trying to complete the current 2588 DHCP message exchange. 2590 The client includes IA options for all of the IAs assigned to the 2591 interface for which the Confirm message is being sent. The IA 2592 options include all of the addresses the client currently has 2593 associated with those IAs. The client SHOULD set the T1 and T2 2594 fields in any IA_NA options (see Section 21.4) and the preferred- 2595 lifetime and valid-lifetime fields in the IA Address options (see 2596 Section 21.6) to 0, as the server will ignore these fields. 2598 The first Confirm message from the client on the interface MUST be 2599 delayed by a random amount of time between 0 and CNF_MAX_DELAY. The 2600 client transmits the message according to Section 15, using the 2601 following parameters: 2603 IRT CNF_TIMEOUT 2604 MRT CNF_MAX_RT 2606 MRC 0 2608 MRD CNF_MAX_RD 2610 If the client receives no responses before the message transmission 2611 process terminates, as described in Section 15, the client SHOULD 2612 continue to use any leases, using the last known lifetimes for those 2613 leases, and SHOULD continue to use any other previously obtained 2614 configuration parameters. 2616 18.2.4. Creation and Transmission of Renew Messages 2618 To extend the valid and preferred lifetimes for the leases assigned 2619 to the IAs and obtain new addresses or delegated prefixes for IAs, 2620 the client sends a Renew message to the server from which the leases 2621 were obtained, which includes IA options for the IAs whose lease 2622 lifetimes are to be extended. The client includes IA Address options 2623 (see Section 21.6) within IA_NA (see Section 21.4) and IA_TA (see 2624 Section 21.5) options for the addresses assigned to the IAs. The 2625 client includes IA Prefix options (see Section 21.22) within IA_PD 2626 options (see Section 21.21) for the delegated prefixes assigned to 2627 the IAs. 2629 The server controls the time at which the client should contact the 2630 server to extend the lifetimes on assigned leases through the T1 and 2631 T2 values assigned to an IA. However, as the client SHOULD renew/ 2632 rebind all IAs from the server at the same time, the client MUST 2633 select T1 and T2 times from all IA options that will guarantee the 2634 client initiates transmissions of Renew/Rebind messages not later 2635 than at the T1/T2 times associated with any of the client's bindings 2636 (earliest T1/T2). 2638 At time T1, the client initiates a Renew/Reply message exchange to 2639 extend the lifetimes on any leases in the IA. 2641 A client MUST also initiate a Renew/Reply message exchange before 2642 time T1 if the client's link-local address used in previous 2643 interactions with the server is no longer valid and it is willing to 2644 receive Reconfigure messages. 2646 If T1 or T2 had been set to 0 by the server (for an IA_NA or IA_PD) 2647 or there are no T1 or T2 times (for an IA_TA) in a previous Reply, 2648 the client may send a Renew or Rebind message, respectively, at the 2649 client's discretion. The client MUST follow the rules defined in 2650 Section 14.2. 2652 The client sets the "msg-type" field to RENEW. The client generates 2653 a transaction ID and inserts this value in the "transaction-id" 2654 field. 2656 The client MUST include a Server Identifier option (see Section 21.3) 2657 in the Renew message, identifying the server with which the client 2658 most recently communicated. 2660 The client MUST include a Client Identifier option (see Section 21.2) 2661 to identify itself to the server. The client adds any appropriate 2662 options, including one or more IA options. 2664 The client MUST include an Elapsed Time option (see Section 21.9) to 2665 indicate how long the client has been trying to complete the current 2666 DHCP message exchange. 2668 For IAs to which leases have been assigned, the client includes a 2669 corresponding IA option containing an IA Address option for each 2670 address assigned to the IA and IA Prefix option for each prefix 2671 assigned to the IA. The client MUST NOT include addresses and 2672 prefixes in any IA option that the client did not obtain from the 2673 server or that are no longer valid (that have a valid lifetime of 0). 2675 The client MAY include an IA option for each binding it desires but 2676 has been unable to obtain. In this case, if the client includes the 2677 IA_PD option to request prefix delegation, the client MAY include the 2678 IA Prefix option encapsulated within the IA_PD option, with the 2679 IPv6-prefix field set to 0 and the "prefix-length" field set to the 2680 desired length of the prefix to be delegated. The server MAY use 2681 this value as a hint for the prefix length. The client SHOULD NOT 2682 include IA Prefix option with the IPv6-prefix field set to 0 unless 2683 it is supplying a hint for the prefix length. 2685 The client includes Option Request option (see Section 21.7) to 2686 request the SOL_MAX_RT option (see Section 21.24) and any other 2687 options the client is interested in receiving. The client MAY 2688 include options with data values as hints to the server about 2689 parameter values the client would like to have returned. 2691 The client transmits the message according to Section 15, using the 2692 following parameters: 2694 IRT REN_TIMEOUT 2696 MRT REN_MAX_RT 2698 MRC 0 2699 MRD Remaining time until earliest T2 2701 The message exchange is terminated when earliest time T2 is reached. 2702 If the client is responding to a Reconfigure, the client ignores and 2703 discards the Reconfigure message. In this case, the client continues 2704 to operate as if Reconfigure message was not received, i.e., it uses 2705 T1/T2 times associated with the client's leases to determine when it 2706 should send Renew or Rebind to the server. The client begins a 2707 Rebind message exchange (see Section 18.2.5) when the earliest time 2708 T2 is reached. 2710 18.2.5. Creation and Transmission of Rebind Messages 2712 At time T2 (which will only be reached if the server to which the 2713 Renew message was sent starting at time T1 has not responded), the 2714 client initiates a Rebind/Reply message exchange with any available 2715 server. 2717 A Rebind is also used to verify delegated prefix bindings but with 2718 different retransmission parameters as described in Section 18.2.3. 2720 The client constructs the Rebind message as described in 2721 Section 18.2.4 with the following differences: 2723 - The client sets the "msg-type" field to REBIND. 2725 - The client does not include the Server Identifier option (see 2726 Section 21.2) in the Rebind message. 2728 The client transmits the message according to Section 15, using the 2729 following parameters: 2731 IRT REB_TIMEOUT 2733 MRT REB_MAX_RT 2735 MRC 0 2737 MRD Remaining time until valid lifetimes of all leases in all 2738 IAs have expired 2740 If all leases for an IA have expired, the client may choose to 2741 include this IA in subsequent Rebind messages to indicate that the 2742 client is interested in assignment of the leases to this IA. 2744 The message exchange is terminated when the valid lifetimes of all 2745 leases across all IAs have expired, at which time the client uses the 2746 Solicit message to locate a new DHCP server and sends a Request for 2747 the expired IAs to the new server. If the terminated Rebind exchange 2748 was initiated as a result of receiving a Reconfigure message, the 2749 client ignores and discards the Reconfigure message. 2751 18.2.6. Creation and Transmission of Information-request Messages 2753 The client uses an Information-request message to obtain 2754 configuration information without having addresses and/or delegated 2755 prefixes assigned to it. 2757 The client sets the "msg-type" field to INFORMATION-REQUEST. The 2758 client generates a transaction ID and inserts this value in the 2759 "transaction-id" field. 2761 The client SHOULD include a Client Identifier option (see 2762 Section 21.2) to identify itself to the server (see section 4.3.1 of 2763 [RFC7844] for reasons why a client may not want to include this 2764 option). If the client does not include a Client Identifier option, 2765 the server will not be able to return any client-specific options to 2766 the client, or the server may choose not to respond to the message at 2767 all. 2769 The client MUST include an Elapsed Time option (see Section 21.9) to 2770 indicate how long the client has been trying to complete the current 2771 DHCP message exchange. 2773 The client MUST include an Option Request option (see Section 21.7) 2774 to request the INF_MAX_RT option (see Section 21.25), the Information 2775 Refresh Time option (see Section 21.23), and any other options the 2776 client is interested in receiving. The client MAY include options 2777 with data values as hints to the server about parameter values the 2778 client would like to have returned. 2780 When responding to a Reconfigure, the client includes a Server 2781 Identifier option (see Section 21.3) with the identifier from the 2782 Reconfigure message to which the client is responding. 2784 The first Information-request message from the client on the 2785 interface MUST be delayed by a random amount of time between 0 and 2786 INF_MAX_DELAY. The client transmits the message according to 2787 Section 15, using the following parameters: 2789 IRT INF_TIMEOUT 2791 MRT INF_MAX_RT 2793 MRC 0 2794 MRD 0 2796 18.2.7. Creation and Transmission of Release Messages 2798 To release one or more leases, a client sends a Release message to 2799 the server. 2801 The client sets the "msg-type" field to RELEASE. The client 2802 generates a transaction ID and places this value in the "transaction- 2803 id" field. 2805 The client places the identifier of the server that allocated the 2806 lease(s) in a Server Identifier option (see Section 21.3). 2808 The client MUST include a Client Identifier option (see Section 21.2) 2809 to identify itself to the server. 2811 The client MUST include an Elapsed Time option (see Section 21.9) to 2812 indicate how long the client has been trying to complete the current 2813 DHCP message exchange. 2815 The client includes options containing the IAs for the leases it is 2816 releasing in the "options" field. The leases to be released MUST be 2817 included in the IAs. Any leases for the IAs the client wishes to 2818 continue to use MUST NOT be added to the IAs. 2820 The client MUST stop using all of the leases being released before 2821 the client begins the Release message exchange process. For an 2822 address, this means the address MUST have been removed from the 2823 interface. For a delegated prefix, this means the prefix MUST have 2824 been advertised with a Preferred Lifetime and a Valid Lifetime of 2825 zero in a Router Advertisement message as described in (e) of 2826 Section 5.5.3 of [RFC4862] - also see L-13 in Section 4.3 of 2827 [RFC7084]. 2829 The client MUST NOT use any of the addresses it is releasing as the 2830 source address in the Release message or in any subsequently 2831 transmitted message. 2833 Because Release messages may be lost, the client should retransmit 2834 the Release if no Reply is received. However, there are scenarios 2835 where the client may not wish to wait for the normal retransmission 2836 timeout before giving up (e.g., on power down). Implementations 2837 SHOULD retransmit one or more times, but MAY choose to terminate the 2838 retransmission procedure early. 2840 The client transmits the message according to Section 15, using the 2841 following parameters: 2843 IRT REL_TIMEOUT 2845 MRT 0 2847 MRC REL_MAX_RC 2849 MRD 0 2851 If leases are released but the Reply from a DHCP server is lost, the 2852 client will retransmit the Release message, and the server may 2853 respond with a Reply indicating a status of NoBinding. Therefore, 2854 the client does not treat a Reply message with a status of NoBinding 2855 in a Release message exchange as if it indicates an error. 2857 Note that if the client fails to release the lease, each lease 2858 assigned to the IA will be reclaimed by the server when the valid 2859 lifetime of that lease expires. 2861 18.2.8. Creation and Transmission of Decline Messages 2863 If a client detects that one or more addresses assigned to it by a 2864 server are already in use by another node, the client sends a Decline 2865 message to the server to inform it that the address is suspect. 2867 The Decline message is not used in prefix delegation and thus the 2868 client MUST NOT include IA_PD options (see Section 21.21) in the 2869 Decline message. 2871 The client sets the "msg-type" field to DECLINE. The client 2872 generates a transaction ID and places this value in the "transaction- 2873 id" field. 2875 The client places the identifier of the server that allocated the 2876 address(es) in a Server Identifier option (see Section 21.3). 2878 The client MUST include a Client Identifier option (see Section 21.2) 2879 to identify itself to the server. 2881 The client MUST include an Elapsed Time option (see Section 21.9) to 2882 indicate how long the client has been trying to complete the current 2883 DHCP message exchange. 2885 The client includes options containing the IAs for the addresses it 2886 is declining in the "options" field. The addresses to be declined 2887 MUST be included in the IAs. Any addresses for the IAs the client 2888 wishes to continue to use should not be in added to the IAs. 2890 The client MUST NOT use any of the addresses it is declining as the 2891 source address in the Decline message or in any subsequently 2892 transmitted message. 2894 The client transmits the message according to Section 15, using the 2895 following parameters: 2897 IRT DEC_TIMEOUT 2899 MRT 0 2901 MRC DEC_MAX_RC 2903 MRD 0 2905 If addresses are declined but the Reply from a DHCP server is lost, 2906 the client will retransmit the Decline message, and the server may 2907 respond with a Reply indicating a status of NoBinding. Therefore, 2908 the client does not treat a Reply message with a status of NoBinding 2909 in a Decline message exchange as if it indicates an error. 2911 The client SHOULD NOT send a Release message for other bindings it 2912 may have received just because it sent a Decline message. The client 2913 SHOULD retain the non-conflicting bindings. The client SHOULD treat 2914 the failure to acquire a binding as a result of the conflict, to be 2915 equivalent to not having received the binding, insofar as it behaves 2916 when sending Renew and Rebind messages. 2918 18.2.9. Receipt of Advertise Messages 2920 Upon receipt of one or more valid Advertise messages, the client 2921 selects one or more Advertise messages based upon the following 2922 criteria. 2924 - Those Advertise messages with the highest server preference value 2925 SHOULD be preferred over all other Advertise messages. The client 2926 MAY choose a less-preferred server if that server has a better set 2927 of advertised parameters, such as the available set of IAs, as 2928 well as the set of other configuration options advertised. 2930 - Within a group of Advertise messages with the same server 2931 preference value, a client MAY select those servers whose 2932 Advertise messages advertise information of interest to the 2933 client. 2935 Once a client has selected Advertise message(s), the client will 2936 typically store information about each server, such as server 2937 preference value, addresses advertised, when the advertisement was 2938 received, and so on. 2940 In practice, this means that the client will maintain independent 2941 per-IA state machines per each selected server. 2943 If the client needs to select an alternate server in the case that a 2944 chosen server does not respond, the client chooses the next server 2945 according to the criteria given above. 2947 The client MUST process any SOL_MAX_RT option (see Section 21.24) and 2948 INF_MAX_RT option (see Section 21.25) present in an Advertise 2949 message, even if the message contains a Status Code option (see 2950 Section 21.13) indicating a failure, and the Advertise message will 2951 be discarded by the client. A client SHOULD only update its 2952 SOL_MAX_RT and INF_MAX_RT values if all received Advertise messages 2953 that contained the corresponding option specified the same value, 2954 otherwise it should use the default value (see Section 7.6). 2956 The client MUST ignore any Advertise message that contains no 2957 addresses (IA Address options, see Section 21.6 encapsulated in 2958 IA_NA, see Section 21.4, or IA_TA, see Section 21.5, options) and no 2959 delegated prefixes (IA Prefix options, see Section 21.22, 2960 encapsulated in IA_PD options, see Section 21.21) with the exception 2961 that the client: 2963 - MUST process an included SOL_MAX_RT option and 2965 - MUST process an included INF_MAX_RT option. 2967 A client can display any associated status message(s) to the user or 2968 activity log. 2970 The client ignoring an Advertise message MUST NOT restart the Solicit 2971 retransmission timer. 2973 18.2.10. Receipt of Reply Messages 2975 Upon the receipt of a valid Reply message in response to a Solicit 2976 with a Rapid Commit option (see Section 21.14), Request, Confirm, 2977 Renew, Rebind, or Information-request message, the client extracts 2978 the top-level Status Code option (see Section 21.13) if present. 2980 The client MUST process any SOL_MAX_RT option (see Section 21.24) and 2981 INF_MAX_RT option (see Section 21.25) present in a Reply message, 2982 even if the message contains a Status Code option indicating a 2983 failure. 2985 If the client receives a Reply message with a status code of 2986 UnspecFail, the server is indicating that it was unable to process 2987 the client's message due to an unspecified failure condition. If the 2988 client retransmits the original message to the same server to retry 2989 the desired operation, the client MUST limit the rate at which it 2990 retransmits the message and limit the duration of the time during 2991 which it retransmits the message (see Section 14.1). 2993 If the client receives a Reply message with a status code of 2994 UseMulticast, the client records the receipt of the message and sends 2995 subsequent messages to the server through the interface on which the 2996 message was received using multicast. The client resends the 2997 original message using multicast. 2999 Otherwise (no status code or another status code), the client 3000 processes the Reply as described below based on the original message 3001 for which the Reply was received. 3003 The client MAY choose to report any status code or message from the 3004 Status Code option in the Reply message. 3006 When a client received a configuration option in an earlier Reply, 3007 then sends a Renew, Rebind or Information-request and the requested 3008 option is not present in the Reply, the client SHOULD stop using the 3009 previously received configuration information. In other words, the 3010 client should behave as if it never received this configuration 3011 option and return to the relevant default state. If there is no 3012 viable way to stop using the received configuration information, the 3013 values received/configured from the option MAY persist if there are 3014 no other sources for that data and they have no external impact. For 3015 example, a client that previously received a Client FQDN option (see 3016 [RFC4704]) and used it to set up its hostname is allowed to continue 3017 using it if there is no reasonable way for a node to unset its 3018 hostname and it has no external impact. As a counter example, a 3019 client that previously received an NTP server address from the DHCP 3020 server and does not receive it any more, MUST stop using the 3021 configured NTP server address. The client SHOULD be open to other 3022 sources of the same configuration information. This behavior does 3023 not apply to any IA options, as their processing is described in 3024 detail in the next section. 3026 When a client receives a requested option that has an updated value 3027 from what was previously received, the client SHOULD make use of that 3028 updated value as soon as possible for its configuration information. 3030 18.2.10.1. Reply for Solicit (with Rapid Commit), Request, Renew or 3031 Rebind 3033 If the client receives a NotOnLink status from the server in response 3034 to a Solicit (with a Rapid Commit option, see Section 21.14) or a 3035 Request, the client can either re-issue the message without 3036 specifying any addresses or restart the DHCP server discovery process 3037 (see Section 18). 3039 If the Reply was received in response to a Solicit (with a Rapid 3040 Commit option), Request, Renew, or Rebind message, the client updates 3041 the information it has recorded about IAs from the IA options 3042 contained in the Reply message: 3044 - Calculate T1 and T2 times (based on T1 and T2 values sent in the 3045 packet and the packet reception time), if appropriate for the IA 3046 type. 3048 - Add any new leases in the IA option to the IA as recorded by the 3049 client. 3051 - Update lifetimes for any leases in the IA option that the client 3052 already has recorded in the IA. 3054 - Discard any leases from the IA, as recorded by the client, that 3055 have a valid lifetime of 0 in the IA Address or IA Prefix option. 3057 - Leave unchanged any information about leases the client has 3058 recorded in the IA but that were not included in the IA from the 3059 server. 3061 If the client can operate with the addresses and/or prefixes obtained 3062 from the server: 3064 - The client uses the addresses, delegated prefixes, and other 3065 information from any IAs that do not contain a Status Code option 3066 with the NoAddrsAvail or NoPrefixAvail status code. The client 3067 MAY include the IAs for which it received the NoAddrsAvail or 3068 NoPrefixAvail status code, with no addresses or prefixes, in 3069 subsequent Renew and Rebind messages sent to the server, to retry 3070 obtaining the addresses or prefixes for these IAs. 3072 - The client MUST perform duplicate address detection as per 3073 [RFC4862] Section 5.4, which does list some exceptions, on each of 3074 the received addresses in any IAs, on which it has not performed 3075 duplicate address detection during processing of any of the 3076 previous Reply messages from the server. The client performs the 3077 duplicate address detection before using the received addresses 3078 for any traffic. If any of the addresses are found to be in use 3079 on the link, the client sends a Decline message to the server for 3080 those addresses as described in Section 18.2.8. 3082 - For each assigned address, which does not have any associated 3083 reachability information, in order to avoid the problems described 3084 in [RFC4943], the client MUST NOT assume that any addresses are 3085 reachable on-link as a result of receiving an IA_NA or IA_TA. 3086 Addresses obtained from IA_NA or IA_TA MUST NOT be used to form an 3087 implicit prefix with a length other than 128. 3089 - For each delegated prefix, the client assigns a subnet to each of 3090 the links to which the associated interfaces are attached. 3092 When a client subnets a delegated prefix, it must assign 3093 additional bits to the prefix to generate unique, longer prefixes. 3094 For example, if the client in Figure 1 were delegated 3095 2001:db8:0::/48, it might generate 2001:db8:0:1::/64 and 3096 2001:db8:0:2::/64 for assignment to the two links in the 3097 subscriber network. If the client were delegated 2001:db8:0::/48 3098 and 2001:db8:5::/48, it might assign 2001:db8:0:1::/64 and 3099 2001:db8:5:1::/64 to one of the links, and 2001:db8:0:2::/64 and 3100 2001:db8:5:2::/64 for assignment to the other link. 3102 If the client uses a delegated prefix to configure addresses on 3103 interfaces on itself or other nodes behind it, the preferred and 3104 valid lifetimes of those addresses MUST be no larger than the 3105 remaining preferred and valid lifetimes, respectively, for the 3106 delegated prefix at any time. In particular, if the delegated 3107 prefix or a prefix derived from it is advertised for stateless 3108 address autoconfiguration [RFC4862], the advertised valid and 3109 preferred lifetimes MUST NOT exceed the corresponding remaining 3110 lifetimes of the delegated prefix. 3112 Management of the specific configuration information is detailed in 3113 the definition of each option in Section 21. 3115 If the Reply message contains any IAs, but the client finds no usable 3116 addresses and/or delegated prefixes in any of these IAs, the client 3117 may either try another server (perhaps restarting the DHCP server 3118 discovery process) or use the Information-request message to obtain 3119 other configuration information only. 3121 When the client receives a Reply message in response to a Renew or 3122 Rebind message, the client: 3124 - Sends a Request message to the server that responded if any of the 3125 IAs in the Reply message contains the NoBinding status code. The 3126 client places IA options in this message for all IAs. The client 3127 continues to use other bindings for which the server did not 3128 return an error. 3130 - Sends a Renew/Rebind if any of the IAs are not in the Reply 3131 message, but as this likely indicates the server that responded 3132 does not support that IA type, sending immediately is unlikely to 3133 produce a different result. Therefore, the client MUST rate limit 3134 its transmissions (see Section 14.1) and MAY just wait for the 3135 normal retransmission time (as if the Reply message had not been 3136 received). The client continues to use other bindings for which 3137 the server did return information. 3139 - Otherwise accepts the information in the IA. 3141 Whenever a client restarts the DHCP server discovery process or 3142 selects an alternate server, as described in Section 18.2.9, the 3143 client SHOULD stop using all the addresses and delegated prefixes for 3144 which it has bindings and try to obtain all required leases from the 3145 new server. This facilitates the client using a single state machine 3146 for all bindings. 3148 18.2.10.2. Reply for Release and Decline 3150 When the client receives a valid Reply message in response to a 3151 Release message, the client considers the Release event completed, 3152 regardless of the Status Code option (see Section 21.13) returned by 3153 the server. 3155 When the client receives a valid Reply message in response to a 3156 Decline message, the client considers the Decline event completed, 3157 regardless of the Status Code option(s) returned by the server. 3159 18.2.10.3. Reply for Confirm 3161 If the client receives any Reply messages that indicate a success 3162 status (explicit or implicit), the client can use the addresses in 3163 the IA and ignore any messages that indicate a NotOnLink status. 3164 When the client only receives one or more Replies with the NotOnLink 3165 status in response to a Confirm message, the client performs DHCP 3166 server discovery as described in Section 18. 3168 18.2.10.4. Reply for Information-request 3170 Refer to Section 21.23 for details on how the Information Refresh 3171 Time option (whether or not present in the Reply) should be handled 3172 by the client. 3174 18.2.11. Receipt of Reconfigure Messages 3176 A client receives Reconfigure messages sent to the UDP port 546 on 3177 interfaces for which it has acquired configuration information 3178 through DHCP. These messages may be sent at any time. Since the 3179 results of a reconfiguration event may affect application layer 3180 programs, the client SHOULD log these events, and MAY notify these 3181 programs of the change through an implementation-specific interface. 3183 Upon receipt of a valid Reconfigure message, the client responds with 3184 either a Renew message, a Rebind message, or an Information-request 3185 message as indicated by the Reconfigure Message option (see 3186 Section 21.19). The client ignores the transaction-id field in the 3187 received Reconfigure message. While the transaction is in progress, 3188 the client discards any Reconfigure messages it receives. 3190 The Reconfigure message acts as a trigger that signals the client to 3191 complete a successful message exchange. Once the client has received 3192 a Reconfigure, the client proceeds with the message exchange 3193 (retransmitting the Renew, Rebind, or Information-request message if 3194 necessary); the client MUST ignore any additional Reconfigure 3195 messages until the exchange is complete. 3197 Duplicate messages will be ignored because the client will begin the 3198 exchange after the receipt of the first Reconfigure. Retransmitted 3199 messages will either trigger the exchange (if the first Reconfigure 3200 was not received by the client) or will be ignored. The server MAY 3201 discontinue retransmission of Reconfigure messages to the client once 3202 the server receives the Renew, Rebind or Information-request message 3203 from the client. 3205 It might be possible for a duplicate or retransmitted Reconfigure to 3206 be sufficiently delayed (and delivered out of order) to arrive at the 3207 client after the exchange (initiated by the original Reconfigure) has 3208 been completed. In this case, the client would initiate a redundant 3209 exchange. The likelihood of delayed and out of order delivery is 3210 small enough to be ignored. The consequence of the redundant 3211 exchange is inefficiency rather than incorrect operation. 3213 18.2.12. Refreshing Configuration Information 3215 Whenever a client may have moved to a new link, the prefixes/ 3216 addresses assigned to the interfaces on that link may no longer be 3217 appropriate for the link to which the client is attached. Examples 3218 of times when a client may have moved to a new link include: 3220 o The client reboots (and has stable storage and persisted DHCP 3221 state). 3223 o The client is reconnected to a link on which it has obtained 3224 leases. 3226 o The client returns from sleep mode. 3228 o The client changes access points (such as if using a wireless 3229 technology). 3231 When the client detects that it may have moved to a new link and it 3232 has obtained addresses and no delegated prefixes from a server, the 3233 client SHOULD initiate a Confirm/Reply message exchange. The client 3234 includes any IAs assigned to the interface that may have moved to a 3235 new link, along with the addresses associated with those IAs, in its 3236 Confirm message. Any responding servers will indicate whether those 3237 addresses are appropriate for the link to which the client is 3238 attached with the status in the Reply message it returns to the 3239 client. 3241 If the client has any valid delegated prefixes obtained from the DHCP 3242 server, the client MUST initiate a Rebind/Reply message exchange as 3243 described in Section 18.2.5, with the exception that the 3244 retransmission parameters should be set as for the Confirm message 3245 (see Section 18.2.3). The client includes IA_NAs, IA_TAs, and 3246 IA_PDs, along with the associated leases, in its Rebind message. 3248 If the client has only obtained network information using 3249 Information-request/Reply message exchanges, the client MUST initiate 3250 a Information-request/Reply message exchange as described in 3251 Section 18.2.6. 3253 If not associated with one of the above mentioned conditions, a 3254 client SHOULD initiate a Renew/Reply exchange (as if the T1 time 3255 expired) as described in Section 18.2.4 or an Information-request/ 3256 Reply exchange as described in Section 18.2.6 if the client detects a 3257 significant change regarding the prefixes available on the link (when 3258 new are added or existing are deprecated) as this may indicate a 3259 configuration change. However, a client MUST rate limit such 3260 attempts to avoid flooding a server with requests when there are link 3261 issues (for example, only doing one of these at most every 30 3262 seconds). 3264 18.3. Server Behavior 3266 For this discussion, the Server is assumed to have been configured in 3267 an implementation specific manner with configuration of interest to 3268 clients. 3270 A server sends an Advertise message in response to each valid Solicit 3271 message it receives to announce the availability of the server to the 3272 client. 3274 In most cases, the server will send a Reply in response to a Request, 3275 Confirm, Renew, Rebind, Decline, Release, and Information-request 3276 messages sent by a client. The server will also send a Reply in 3277 response to a Solicit with a Rapid Commit option (see Section 21.14), 3278 when the server is configured to respond with committed lease 3279 assignments. 3281 These Advertise and Reply messages MUST always contain the Server 3282 Identifier option (see Section 21.3) containing the server's DUID and 3283 the Client Identifier option (see Section 21.2) from the client 3284 message if one was present. 3286 In most response messages, the server includes options containing 3287 configuration information for the client. The server must be aware 3288 of the recommendations on packet sizes and the use of fragmentation 3289 in section 5 of [RFC8200]. If the client included an Option Request 3290 option (see Section 21.7) in its message, the server includes options 3291 in the response message containing configuration parameters for all 3292 of the options identified in the Option Request option that the 3293 server has been configured to return to the client. The server MAY 3294 return additional options to the client if it has been configured to 3295 do so. 3297 Any message sent from a client may arrive at the server encapsulated 3298 in one or more Relay-forward messages. The server MUST use the 3299 received message to construct the proper Relay-reply message to allow 3300 the response to the received message to be relayed through the same 3301 relay agents (in reverse order) as the original client message; see 3302 Section 19.3 for more details. The server may also need to record 3303 this information with each client in case it is needed to send a 3304 Reconfigure message at a later time unless the server has been 3305 configured with addresses that can be used to send Reconfigure 3306 messages directly to the client (see Section 18.3.11). Note that 3307 servers that support leasequery [RFC5007] also need to record this 3308 information. 3310 The server MAY initiate a configuration exchange, by sending 3311 Reconfigure messages, to cause DHCP clients to obtain new addresses, 3312 prefixes and other configuration information. For example, an 3313 administrator may use a server-initiated configuration exchange when 3314 links in the DHCP domain are to be renumbered or when other 3315 configuration options are updated, perhaps because servers are moved, 3316 added, or removed. 3318 When a client receives a Reconfigure message from the server, the 3319 client initiates sending a Renew, Rebind or Information-request 3320 message as indicated by msg-type in the Reconfigure Message option 3321 (see Section 21.19). The server sends IAs and/or other configuration 3322 information to the client in a Reply message. The server MAY include 3323 options containing the IAs and new values for other configuration 3324 parameters in the Reply message, even if those IAs and parameters 3325 were not requested in the client's message. 3327 18.3.1. Receipt of Solicit Messages 3329 See Section 18.4 for handling Solicit message received via unicast. 3330 Unicast transmission of Solicit is not allowed, regardless of whether 3331 the Server Unicast option (see Section 21.12) is configured or not. 3333 The server determines the information about the client and its 3334 location as described in Section 13 and checks its administrative 3335 policy about responding to the client. If the server is not 3336 permitted to respond to the client, the server discards the Solicit 3337 message. For example, if the administrative policy for the server is 3338 that it may only respond to a client that is willing to accept a 3339 Reconfigure message, if the client does not include a Reconfigure 3340 Accept option (see Section 21.20) in the Solicit message, the server 3341 discards the Solicit message. 3343 If the server is permitted to respond to the client, the client has 3344 not included a Rapid Commit option (see Section 21.14) in the Solicit 3345 message or the server has not been configured to respond with 3346 committed assignment of leases and other resources, the server sends 3347 an Advertise message to the client as described in Section 18.3.9. 3349 If the client has included a Rapid Commit option in the Solicit 3350 message and the server has been configured to respond with committed 3351 assignments of leases and other resources, the server responds to the 3352 Solicit with a Reply message. The server produces the Reply message 3353 as though it had received a Request message, as described in 3354 Section 18.3.2. The server transmits the Reply message as described 3355 in Section 18.3.10. The server MUST commit the assignment of any 3356 addresses and delegated prefixes or other configuration information 3357 before sending a Reply message to a client. In this case the server 3358 includes a Rapid Commit option in the Reply message to indicate that 3359 the Reply is in response to a Solicit message. 3361 DISCUSSION: 3363 When using the Solicit/Reply message exchange, the server commits 3364 the assignment of any leases before sending the Reply message. 3365 The client can assume it has been assigned the leases in the Reply 3366 message and does not need to send a Request message for those 3367 leases. 3369 Typically, servers that are configured to use the Solicit/Reply 3370 message exchange will be deployed so that only one server will 3371 respond to a Solicit message. If more than one server responds, 3372 the client will only use the leases from one of the servers, while 3373 the leases from the other servers will be committed to the client 3374 but not used by the client. 3376 18.3.2. Receipt of Request Messages 3378 See Section 18.4 for handling Request message received via unicast. 3380 When the server receives a valid Request message, the server creates 3381 the bindings for that client according to the server's policy and 3382 configuration information and records the IAs and other information 3383 requested by the client. 3385 The server constructs a Reply message by setting the "msg-type" field 3386 to REPLY, and copying the transaction ID from the Request message 3387 into the transaction-id field. 3389 The server MUST include a Server Identifier option (see Section 21.3) 3390 containing the server's DUID and the Client Identifier option (see 3391 Section 21.2) from the Request message in the Reply message. 3393 The server examines all IAs in the message from the client. 3395 For each IA_NA option (see Section 21.4) and IA_TA option (see 3396 Section 21.5) in the Request message the server checks if the 3397 prefixes of included addresses are appropriate for the link to which 3398 the client is connected. If any of the prefixes of the included 3399 addresses is not appropriate for the link to which the client is 3400 connected, the server MUST return the IA to the client with a Status 3401 Code option (see Section 21.13) with the value NotOnLink. If the 3402 server does not send the NotOnLink status code but it cannot assign 3403 any IP addresses to an IA, the server MUST return the IA option in 3404 the Reply message with no addresses in the IA and a Status Code 3405 option containing status code NoAddrsAvail in the IA. 3407 For any IA_PD option (see Section 21.21) in the Request message, to 3408 which the server cannot assign any delegated prefixes, the server 3409 MUST return the IA_PD option in the Reply message with no prefixes in 3410 the IA_PD and with a Status Code option containing status code 3411 NoPrefixAvail in the IA_PD. 3413 The server MAY assign different addresses and/or delegated prefixes 3414 to an IA than those included within the IA of the client's Request 3415 message. 3417 For all IAs to which the server can assign addresses or delegated 3418 prefixes, the server includes the IAs with addresses (for IA_NA and 3419 IA_TA), prefixes (for IA_PD) and other configuration parameters, and 3420 records the IA as a new client binding. The server MUST NOT include 3421 any addresses or delegated prefixes in the IA which the server does 3422 not assign to the client. 3424 The T1/T2 times set in each applicable IA option for a Reply MUST be 3425 the same values across all IAs. The server MUST determine the T1/T2 3426 times across all of the applicable client's bindings in the Reply. 3427 This facilitates the client being able to renew all of the bindings 3428 at the same time. 3430 The server SHOULD include a Reconfigure Accept option (see 3431 Section 21.20) if the server policy enables reconfigure mechanism and 3432 the client supports it. Currently sending this option in a Reply is 3433 technically redundant, as the use of the reconfiguration mechanism 3434 requires authentication and currently the only defined one is the 3435 Reconfigure Key Authentication Protocol (see Section 20.4) and the 3436 presence of the reconfigure key signals support for Reconfigure 3437 acceptance. However, there may be better security mechanisms defined 3438 in the future that would cause RKAP to not be used anymore. 3440 The server includes other options containing configuration 3441 information to be returned to the client as described in 3442 Section 18.3. 3444 If the server finds that the client has included an IA in the Request 3445 message for which the server already has a binding that associates 3446 the IA with the client, the server sends a Reply message with 3447 existing bindings, possibly with updated lifetimes. The server may 3448 update the bindings according to its local policies, but the server 3449 SHOULD generate the response again and not simply retransmit 3450 previously sent information, even if the transaction-id matches a 3451 previous transmission. The server MUST NOT cache its responses. 3453 DISCUSSION: 3455 The reason why cached replies are bad is because lifetimes need to be 3456 updated (either decrease the timers by the amount of time elapsed 3457 since the original transmission or keep the lifetime values and 3458 update the lease information in the server's database). Also, if the 3459 message uses any security protection (such as RDM described in 3460 Section 20.3), its value must be updated. Additionally, any digests 3461 must be updated. Given all of the above, caching replies is far more 3462 complex than simply sending the same buffer as before and it is easy 3463 to miss some of those steps. 3465 18.3.3. Receipt of Confirm Messages 3467 See Section 18.4 for handling Confirm message received via unicast. 3468 Unicast transmission of Confirm is not allowed, regardless of whether 3469 the Server Unicast option (see Section 21.12) is configured or not. 3471 When the server receives a Confirm message, the server determines 3472 whether the addresses in the Confirm message are appropriate for the 3473 link to which the client is attached. If all of the addresses in the 3474 Confirm message pass this test, the server returns a status of 3475 Success. If any of the addresses do not pass this test, the server 3476 returns a status of NotOnLink. If the server is unable to perform 3477 this test (for example, the server does not have information about 3478 prefixes on the link to which the client is connected), or there were 3479 no addresses in any of the IAs sent by the client, the server MUST 3480 NOT send a Reply to the client. 3482 The server ignores the T1 and T2 fields in the IA options and the 3483 preferred-lifetime and valid-lifetime fields in the IA Address 3484 options (see Section 21.6). 3486 The server constructs a Reply message by setting the "msg-type" field 3487 to REPLY, and copying the transaction ID from the Confirm message 3488 into the transaction-id field. 3490 The server MUST include a Server Identifier option (see Section 21.3) 3491 containing the server's DUID and the Client Identifier option (see 3492 Section 21.2) from the Confirm message in the Reply message. The 3493 server includes a Status Code option (see Section 21.13) indicating 3494 the status of the Confirm message. 3496 18.3.4. Receipt of Renew Messages 3498 See Section 18.4 for handling Renew message received via unicast. 3500 For each IA in the Renew message from a client, the server locates 3501 the client's binding and verifies that the information in the IA from 3502 the client matches the information stored for that client. 3504 If the server finds the client entry for the IA, the server sends 3505 back the IA to the client with new lifetimes and, if applicable, T1/ 3506 T2 times. If the server is unable to extend the lifetimes of an 3507 address or delegated prefix in the IA, the server MAY choose not to 3508 include the IA Address option (see Section 21.6) for that address or 3509 IA Prefix option (see Section 21.22) for that delegated prefix. If 3510 the server chooses to include the IA Address or IA Prefix option for 3511 such an address or delegated prefix, the server SHOULD set T1 and T2 3512 values to the valid lifetime for the IA option unless the server also 3513 includes other addresses or delegated prefixes which the server is 3514 able to extend for the IA. Setting T1 and T2 to values equal to 3515 valid lifetime informs the client that the leases associated with 3516 said IA will not be extended, so there is no point in trying. Also, 3517 it avoids generating unnecessary traffic as the remaining lifetime 3518 approaches 0. 3520 The server may choose to change the list of addresses or delegated 3521 prefixes and the lifetimes in IAs that are returned to the client. 3523 If the server finds that any of the addresses in the IA are not 3524 appropriate for the link to which the client is attached, the server 3525 returns the address to the client with lifetimes of 0. 3527 If the server finds that any of the delegated prefixes in the IA are 3528 not appropriate for the link to which the client is attached, the 3529 server returns the delegated prefix to the client with lifetimes of 3530 0. 3532 For each IA for which the server cannot find a client entry, the 3533 server has the following choices depending on the server's policy and 3534 configuration information: 3536 - If the server is configured to create new bindings as a result of 3537 processing Renew messages, the server SHOULD create a binding and 3538 return the IA with assigned addresses or delegated prefixes with 3539 lifetimes and, if applicable, T1/T2 times and other information 3540 requested by the client. If the client included the IA Prefix 3541 option within the IA_PD option (see Section 21.21) with zero value 3542 in the "IPv6 prefix" field and non-zero value in the "prefix- 3543 length" field, the server MAY use the "prefix-length" value as a 3544 hint for the length of the prefixes to be assigned (see [RFC8168] 3545 for further details on prefix length hints). 3547 - If the server is configured to create new bindings as a result of 3548 processing Renew messages, but the server will not assign any 3549 leases to an IA, the server returns the IA option containing a 3550 Status Code option (see Section 21.13) with the NoAddrsAvail or 3551 NoPrefixAvail status code and a status message for a user. 3553 - If the server does not support creation of new bindings for the 3554 client sending a Renew message, or if this behavior is disabled 3555 according to the server's policy or configuration information, the 3556 server returns the IA option containing a Status Code option with 3557 the NoBinding status code and a status message for a user. 3559 The server constructs a Reply message by setting the "msg-type" field 3560 to REPLY and copying the transaction ID from the Renew message into 3561 the "transaction-id" field. 3563 The server MUST include a Server Identifier option (see Section 21.3) 3564 containing the server's DUID and the Client Identifier option (see 3565 Section 21.2) from the Renew message in the Reply message. 3567 The server includes other options containing configuration 3568 information to be returned to the client as described in 3569 Section 18.3. 3571 The server MAY include options containing the IAs and values for 3572 other configuration parameters, even if those parameters were not 3573 requested in the Renew message. 3575 The T1/T2 values set in each applicable IA option for a Reply MUST be 3576 the same across all IAs. The server MUST determine the T1/T2 values 3577 across all of the applicable client's bindings in the Reply. This 3578 facilitates the client being able to renew all of the bindings at the 3579 same time. 3581 18.3.5. Receipt of Rebind Messages 3583 See Section 18.4 for handling Rebind message received via unicast. 3584 Unicast transmission of Rebind is not allowed, regardless of whether 3585 the Server Unicast option (see Section 21.12) is configured or not. 3587 When the server receives a Rebind message that contains an IA option 3588 from a client, it locates the client's binding and verifies that the 3589 information in the IA from the client matches the information stored 3590 for that client. 3592 If the server finds the client entry for the IA and the server 3593 determines that the addresses or delegated prefixes in the IA are 3594 appropriate for the link to which the client's interface is attached 3595 according to the server's explicit configuration information, the 3596 server SHOULD send back the IA to the client with new lifetimes and, 3597 if applicable, T1/T2 values. If the server is unable to extend the 3598 lifetimes of an address in the IA, the server MAY choose not to 3599 include the IA Address option (see Section 21.6) for this address. 3600 If the server is unable to extend the lifetimes of a delegated prefix 3601 in the IA, the server MAY choose not to include the IA Prefix option 3602 (see Section 21.22) for this prefix. 3604 If the server finds that the client entry for the IA and any of the 3605 addresses or delegated prefixes are no longer appropriate for the 3606 link to which the client's interface is attached according to the 3607 server's explicit configuration information, the server returns the 3608 address or delegated prefix to the client with lifetimes of 0. 3610 If the server cannot find a client entry for the IA, the server 3611 checks if the IA contains addresses (for IA_NA and IA_TA) or 3612 delegated prefixes (for IA_PD). The server checks if the addresses 3613 and delegated prefixes are appropriate for the link to which the 3614 client's interface is attached according to the server's explicit 3615 configuration information. For any address which is not appropriate 3616 for the link to which the client's interface is attached, the server 3617 MAY include the IA Address option with the lifetimes of 0. For any 3618 delegated prefix which is not appropriate for the link to which the 3619 client's interface is attached, the server MAY include the IA Prefix 3620 option with the lifetimes of 0. The Reply with lifetimes of 0 3621 constitutes an explicit notification to the client that the specific 3622 addresses and delegated prefixes are no longer valid and MUST NOT be 3623 used by the client. If the server chooses to not include any IAs 3624 containing IA Address or IA Prefix options with lifetimes of 0 and 3625 the server does not include any other IAs with leases and/or status 3626 codes, the server does not send a Reply message. In this situation 3627 the server discards the Rebind message. 3629 Otherwise, for each IA for which the server cannot find a client 3630 entry, the server has the following choices depending on the server's 3631 policy and configuration information: 3633 - If the server is configured to create new bindings as a result of 3634 processing Rebind messages (also see the note about the Rapid 3635 Commit option (see Section 21.14) below), the server SHOULD create 3636 a binding and return the IA with allocated leases with lifetimes 3637 and, if applicable, T1/T2 values and other information requested 3638 by the client. The server MUST NOT return any addresses or 3639 delegated prefixes in the IA which the server does not assign to 3640 the client. 3642 - If the server is configured to create new bindings as a result of 3643 processing Rebind messages, but the server will not assign any 3644 leases to an IA, the server returns the IA option containing a 3645 Status Code option (see Section 21.13) with the NoAddrsAvail or 3646 NoPrefixAvail status code and a status message for a user. 3648 - If the server does not support creation of new bindings for the 3649 client sending a Rebind message, or if this behavior is disabled 3650 according to the server's policy or configuration information, the 3651 server returns the IA option containing a Status Code option with 3652 the NoBinding status code and a status message for a user. 3654 When the server creates new bindings for the IA, it is possible that 3655 other servers also create bindings as a result of receiving the same 3656 Rebind message - see the Discussion in Section 21.14. Therefore, the 3657 server SHOULD only create new bindings during processing of a Rebind 3658 message if the server is configured to respond with a Reply message 3659 to a Solicit message containing the Rapid Commit option. 3661 The server constructs a Reply message by setting the "msg-type" field 3662 to REPLY and copying the transaction ID from the Rebind message into 3663 the "transaction-id" field. 3665 The server MUST include a Server Identifier option (see Section 21.3) 3666 containing the server's DUID and the Client Identifier option (see 3667 Section 21.2) from the Rebind message in the Reply message. 3669 The server includes other options containing configuration 3670 information to be returned to the client as described in 3671 Section 18.3. 3673 The server MAY include options containing the IAs and values for 3674 other configuration parameters, even if those IAs and parameters were 3675 not requested in the Rebind message. 3677 The T1 values set in each applicable IA option for a Reply MUST be 3678 the same values across all IAs. The T2 values set in each applicable 3679 IA option for a Reply MUST be the same values across all IAs. The 3680 server MUST determine the T1 values across all of the applicable 3681 client's bindings in the Reply. The server MUST determine the T2 3682 values across all of the applicable client's bindings in the Reply. 3683 This facilitates the client being able to renew all of the bindings 3684 at the same time. 3686 18.3.6. Receipt of Information-request Messages 3688 See Section 18.4 for handling Information-request message received 3689 via unicast. 3691 When the server receives an Information-request message, the client 3692 is requesting configuration information that does not include the 3693 assignment of any leases. The server determines all configuration 3694 parameters appropriate to the client, based on the server 3695 configuration policies known to the server. 3697 The server constructs a Reply message by setting the "msg-type" field 3698 to REPLY, and copying the transaction ID from the Information-request 3699 message into the transaction-id field. 3701 The server MUST include a Server Identifier option (see Section 21.3) 3702 containing the server's DUID in the Reply message. If the client 3703 included a Client Identifier option (see Section 21.2) in the 3704 Information-request message, the server copies that option to the 3705 Reply message. 3707 The server includes options containing configuration information to 3708 be returned to the client as described in Section 18.3. The server 3709 MAY include additional options that were not requested by the client 3710 in the Information-request message. 3712 If the Information-request message received from the client did not 3713 include a Client Identifier option, the server SHOULD respond with a 3714 Reply message containing any configuration parameters that are not 3715 determined by the client's identity. If the server chooses not to 3716 respond, the client may continue to retransmit the Information- 3717 request message indefinitely. 3719 18.3.7. Receipt of Release Messages 3721 See Section 18.4 for handling Release message received via unicast. 3723 The server constructs a Reply message by setting the "msg-type" field 3724 to REPLY, and copying the transaction ID from the Release message 3725 into the transaction-id field. 3727 Upon the receipt of a valid Release message, the server examines the 3728 IAs and the leases in the IAs for validity. If the IAs in the 3729 message are in a binding for the client, and the leases in the IAs 3730 have been assigned by the server to those IAs, the server deletes the 3731 leases from the IAs and makes the leases available for assignment to 3732 other clients. The server ignores leases not assigned to the IA, 3733 although it may choose to log an error. 3735 After all the leases have been processed, the server generates a 3736 Reply message and includes a Status Code option (see Section 21.13) 3737 with value Success, a Server Identifier option (see Section 21.3) 3738 with the server's DUID, and a Client Identifier option (see 3739 Section 21.2) with the client's DUID. For each IA in the Release 3740 message for which the server has no binding information, the server 3741 adds an IA option using the IAID from the Release message, and 3742 includes a Status Code option with the value NoBinding in the IA 3743 option. No other options are included in the IA option. 3745 A server may choose to retain a record of assigned leases and IAs 3746 after the lifetimes on the leases have expired to allow the server to 3747 reassign the previously assigned leases to a client. 3749 18.3.8. Receipt of Decline Messages 3751 See Section 18.4 for handling Decline message received via unicast. 3753 Upon the receipt of a valid Decline message, the server examines the 3754 IAs and the addresses in the IAs for validity. If the IAs in the 3755 message are in a binding for the client, and the addresses in the IAs 3756 have been assigned by the server to those IAs, the server deletes the 3757 addresses from the IAs. The server ignores addresses not assigned to 3758 the IA (though it may choose to log an error if it finds such an 3759 address). 3761 The client has found any addresses in the Decline messages to be 3762 already in use on its link. Therefore, the server SHOULD mark the 3763 addresses declined by the client so that those addresses are not 3764 assigned to other clients, and MAY choose to make a notification that 3765 addresses were declined. Local policy on the server determines when 3766 the addresses identified in a Decline message may be made available 3767 for assignment. 3769 After all the addresses have been processed, the server generates a 3770 Reply message by setting the "msg-type" field to REPLY, and copying 3771 the transaction ID from the Decline message into the transaction-id 3772 field. The client includes a Status Code option (see Section 21.13) 3773 with the value Success, a Server Identifier option (see Section 21.3) 3774 with the server's DUID, and a Client Identifier option (see 3775 Section 21.2) with the client's DUID. For each IA in the Decline 3776 message for which the server has no binding information, the server 3777 adds an IA option using the IAID from the Decline message and 3778 includes a Status Code option with the value NoBinding in the IA 3779 option. No other options are included in the IA option. 3781 18.3.9. Creation of Advertise Messages 3783 The server sets the "msg-type" field to ADVERTISE and copies the 3784 contents of the transaction-id field from the Solicit message 3785 received from the client to the Advertise message. The server 3786 includes its server identifier in a Server Identifier option (see 3787 Section 21.3) and copies the Client Identifier option (see 3788 Section 21.2) from the Solicit message into the Advertise message. 3790 The server MAY add a Preference option (see Section 21.8) to carry 3791 the preference value for the Advertise message. The server 3792 implementation SHOULD allow the setting of a server preference value 3793 by the administrator. The server preference value MUST default to 3794 zero unless otherwise configured by the server administrator. 3796 The server includes a Reconfigure Accept option (see Section 21.20) 3797 if the server wants to indicate it supports Reconfigure mechanism. 3798 This information may be used by the client during the server 3799 selection process. 3801 The server includes the options the server will return to the client 3802 in a subsequent Reply message. The information in these options may 3803 be used by the client in the selection of a server if the client 3804 receives more than one Advertise message. The server MUST include 3805 options in the Advertise message containing configuration parameters 3806 for all of the options identified in the Option Request option (see 3807 Section 21.7) in the Solicit message that the server has been 3808 configured to return to the client. If the Option Request option 3809 includes a container option the server MUST include all the options 3810 that are eligible to be encapsulated in the container. The Option 3811 Request option MAY be used to signal support for a feature even when 3812 that option is encapsulated as in the case of the Prefix Exclude 3813 option [RFC6603]. In this case, special processing is required by 3814 the server. The server MAY return additional options to the client 3815 if it has been configured to do so. 3817 The server MUST include IA options in the Advertise message 3818 containing any addresses and/or delegated prefixes that would be 3819 assigned to IAs contained in the Solicit message from the client. If 3820 the client has included addresses in the IA Address options (see 3821 Section 21.6) in the Solicit message, the server MAY use those 3822 addresses as hints about the addresses that the client would like to 3823 receive. If the client has included IA Prefix options (see 3824 Section 21.22), the server MAY use the prefix contained in the 3825 IPv6-prefix field and/or the prefix length contained in the "prefix- 3826 length" field as a hints about the prefixes the client would like to 3827 receive. If the server is not going to assign an address or 3828 delegated prefix received as a hint in the Solicit message, the 3829 server MUST NOT include this address or delegated prefix in the 3830 Advertise message. 3832 If the server will not assign any addresses to an IA_NA or IA_TA in 3833 subsequent Request from the client, the server MUST include the IA 3834 option in the Advertise message with no addresses in that IA and a 3835 Status Code option (see Section 21.13) encapsulated in the IA option 3836 containing status code NoAddrsAvail. 3838 If the server will not assign any prefixes to an IA_PD in subsequent 3839 Request from the client, the server MUST include the IA_PD option 3840 (see Section 21.21) in the Advertise message with no prefixes in the 3841 IA_PD option and a Status Code option encapsulated in the IA_PD 3842 containing status code NoPrefixAvail. 3844 Transmission of the Advertise message is described in the next 3845 section. 3847 18.3.10. Transmission of Advertise and Reply Messages 3849 If the original message was received directly by the server, the 3850 server unicasts the Advertise or Reply message directly to the client 3851 using the address in the source address field from the IP datagram in 3852 which the original message was received. The Advertise or Reply 3853 message MUST be unicast through the interface on which the original 3854 message was received. 3856 If the original message was received in a Relay-forward message, the 3857 server constructs a Relay-reply message with the Reply message in the 3858 payload of a Relay Message option (see Section 21.10). If the Relay- 3859 forward messages included an Interface-Id option (see Section 21.18), 3860 the server copies that option to the Relay-reply message. The server 3861 unicasts the Relay-reply message directly to the relay agent using 3862 the address in the source address field from the IP datagram in which 3863 the Relay-forward message was received. See Section 19.3 for more 3864 details on the construction of Relay-reply messages. 3866 18.3.11. Creation and Transmission of Reconfigure Messages 3868 The server sets the "msg-type" field to RECONFIGURE. The server sets 3869 the transaction-id field to 0. The server includes a Server 3870 Identifier option (see Section 21.3) containing its DUID and a Client 3871 Identifier option (see Section 21.2) containing the client's DUID in 3872 the Reconfigure message. 3874 Because of the risk of denial of service attacks against DHCP 3875 clients, the use of a security mechanism is mandated in Reconfigure 3876 messages. The server MUST use DHCP authentication in the Reconfigure 3877 message (see Section 20.4). 3879 The server MUST include a Reconfigure Message option (see 3880 Section 21.19) to select whether the client responds with a Renew 3881 message, a Rebind message, or an Information-request message. 3883 The server MUST NOT include any other options in the Reconfigure 3884 except as specifically allowed in the definition of individual 3885 options. 3887 A server sends each Reconfigure message to a single DHCP client, 3888 using an IPv6 unicast address of sufficient scope belonging to the 3889 DHCP client. If the server does not have an address to which it can 3890 send the Reconfigure message directly to the client, the server uses 3891 a Relay-reply message (as described in Section 19.3) to send the 3892 Reconfigure message to a relay agent that will relay the message to 3893 the client. The server may obtain the address of the client (and the 3894 appropriate relay agent, if required) through the information the 3895 server has about clients that have been in contact with the server 3896 (see Section 18.3), or through some external agent. 3898 To reconfigure more than one client, the server unicasts a separate 3899 message to each client. The server may initiate the reconfiguration 3900 of multiple clients concurrently; for example, a server may send a 3901 Reconfigure message to additional clients while previous 3902 reconfiguration message exchanges are still in progress. 3904 The Reconfigure message causes the client to initiate a Renew/Reply, 3905 a Rebind/Reply, or Information-request/Reply message exchange with 3906 the server. The server interprets the receipt of a Renew, a Rebind, 3907 or Information-request message (whichever was specified in the 3908 original Reconfigure message) from the client as satisfying the 3909 Reconfigure message request. 3911 When transmitting the Reconfigure message, the server sets the 3912 retransmission time (RT) to REC_TIMEOUT. If the server does not 3913 receive a Renew, Rebind, or Information-request message from the 3914 client before the RT elapses, the server retransmits the Reconfigure 3915 message, doubles the RT value, and waits again. The server continues 3916 this process until REC_MAX_RC unsuccessful attempts have been made, 3917 at which point the server SHOULD abort the reconfigure process for 3918 that client. 3920 Default and initial values for REC_TIMEOUT and REC_MAX_RC are 3921 documented in Section 7.6. 3923 18.4. Reception of Unicast Messages 3925 Unless otherwise stated in sections dedicated to specific messages 3926 reception (see dedicated sections in Section 18.3), the server is not 3927 supposed to accept unicast traffic when it is not explicitly 3928 configured to do so. For some messages (Solicit, Rebind, and 3929 Confirm) unicast transmission is not allowed, even if Server Unicast 3930 option (see Section 21.12) is configured. For Request, Renew, 3931 Informaton-request, Release, and Decline messages, it is allowed only 3932 if Server Unicast option is configured. 3934 When the server receives a message via unicast from a client to which 3935 the server has not sent a Server Unicast option (or is not currently 3936 configured to send a Server Unicast option to the client), the server 3937 discards that message and responds with an Advertise (when responding 3938 to Solicit) or Reply (when responding to any other messages) message 3939 containing a Status Code option (see Section 21.13) with value 3940 UseMulticast, a Server Identifier option (see Section 21.3) 3941 containing the server's DUID, the Client Identifier option (see 3942 Section 21.2) from the client message (if any), and no other options. 3944 19. Relay Agent Behavior 3946 The relay agent SHOULD be configured to use a list of destination 3947 addresses, which include unicast addresses. The list of destination 3948 addresses MAY include the All_DHCP_Servers multicast address or other 3949 addresses selected by the network administrator. If the relay agent 3950 has not been explicitly configured, it MUST use the All_DHCP_Servers 3951 multicast address as the default. 3953 If the relay agent relays messages to the All_DHCP_Servers multicast 3954 address or other multicast addresses, it sets the Hop Limit field to 3955 8. 3957 If the relay agent receives a message other than Relay-forward and 3958 Relay-reply and the relay agent does not recognize its message type, 3959 it MUST forward them as described in Section 19.1.1. 3961 19.1. Relaying a Client Message or a Relay-forward Message 3963 A relay agent relays both messages from clients and Relay-forward 3964 messages from other relay agents. When a relay agent receives a 3965 Relay-forward message, a recognized message type for which it is not 3966 the intended target, or an unrecognized message type ([RFC7283]), it 3967 constructs a new Relay-forward message. The relay agent copies the 3968 source address from the header of the IP datagram in which the 3969 message was received into the peer-address field of the Relay-forward 3970 message. The relay agent copies the received DHCP message (excluding 3971 any IP or UDP headers) into a Relay Message option (see 3972 Section 21.10) in the new message. The relay agent adds to the 3973 Relay-forward message any other options it is configured to include. 3975 [RFC6221] defines a Lightweight DHCPv6 Relay Agent (LDRA) that allows 3976 relay agent information to be inserted by an access node that 3977 performs a link-layer bridging (i.e., non-routing) function. 3979 19.1.1. Relaying a Message from a Client 3981 If the relay agent received the message to be relayed from a client, 3982 the relay agent places a global address (including unique local 3983 address, [RFC4193]) with a prefix assigned to the link on which the 3984 client should be assigned leases into the link-address field. If 3985 such an address is not available, the relay agent may set the link- 3986 address field to a link-local address from the interface the original 3987 message was received on. That is not recommended as it may require 3988 additional information to be provided in the server configuration. 3989 See Section 3.2 of [RFC7969] for a detailed discussion. 3991 This address will be used by the server to determine the link from 3992 which the client should be assigned leases and other configuration 3993 information. 3995 The hop-count in the Relay-forward message is set to 0. 3997 If the relay agent cannot use the address in the link-address field 3998 to identify the interface through which the response to the client 3999 will be relayed, the relay agent MUST include an Interface-Id option 4000 (see Section 21.18) in the Relay-forward message. The server will 4001 include the Interface-Id option in its Relay-reply message. The 4002 relay agent sets the link-address field as described in the earlier 4003 paragraphs regardless of whether the relay agent includes an 4004 Interface-Id option in the Relay-forward message. 4006 19.1.2. Relaying a Message from a Relay Agent 4008 If the message received by the relay agent is a Relay-forward message 4009 and the hop-count in the message is greater than or equal to 4010 HOP_COUNT_LIMIT, the relay agent discards the received message. 4012 The relay agent copies the source address from the IP datagram in 4013 which the message was received from the relay agent into the peer- 4014 address field in the Relay-forward message and sets the hop-count 4015 field to the value of the hop-count field in the received message 4016 incremented by 1. 4018 If the source address from the IP datagram header of the received 4019 message is a global address (including unique local address, 4020 [RFC4193]), the relay agent sets the link-address field to 0; 4021 otherwise the relay agent sets the link-address field to a global 4022 address (including unique local address) assigned to the interface on 4023 which the message was received, or includes an Interface-Id option 4024 (see Section 21.18) to identify the interface on which the message 4025 was received. 4027 19.1.3. Relay Agent Behavior with Prefix Delegation 4029 A relay agent forwards messages containing Prefix Delegation options 4030 in the same way as described earlier in this section. 4032 If a server communicates with a client through a relay agent about 4033 delegated prefixes, the server may need a protocol or other out-of- 4034 band communication to configure routing information for delegated 4035 prefixes on any router through which the client may forward traffic. 4037 19.2. Relaying a Relay-reply Message 4039 The relay agent processes any options included in the Relay-reply 4040 message in addition to the Relay Message option (see Section 21.10). 4042 The relay agent extracts the message from the Relay Message option 4043 and relays it to the address contained in the peer-address field of 4044 the Relay-reply message. Relay agents MUST NOT modify the message. 4046 If the Relay-reply message includes an Interface-Id option (see 4047 Section 21.18), the relay agent relays the message from the server to 4048 the client on the link identified by the Interface-Id option. 4049 Otherwise, if the link-address field is not set to zero, the relay 4050 agent relays the message on the link identified by the link-address 4051 field. 4053 If the relay agent receives a Relay-reply message, it MUST process 4054 the message as defined above, regardless of the type of message 4055 encapsulated in the Relay Message option. 4057 19.3. Construction of Relay-reply Messages 4059 A server uses a Relay-reply message to return a response to a client 4060 if the original message from the client was relayed to the server in 4061 a Relay-forward message or to send a Reconfigure message to a client 4062 if the server does not have an address it can use to send the message 4063 directly to the client. 4065 A response to the client MUST be relayed through the same relay 4066 agents as the original client message. The server causes this to 4067 happen by creating a Relay-reply message that includes a Relay 4068 Message option (see Section 21.10) containing the message for the 4069 next relay agent in the return path to the client. The contained 4070 Relay-reply message contains another Relay Message option to be sent 4071 to the next relay agent, and so on. The server must record the 4072 contents of the peer-address fields in the received message so it can 4073 construct the appropriate Relay-reply message carrying the response 4074 from the server. 4076 For example, if client C sent a message that was relayed by relay 4077 agent A to relay agent B and then to the server, the server would 4078 send the following Relay-reply message to relay agent B: 4080 msg-type: RELAY-REPLY 4081 hop-count: 1 4082 link-address: 0 4083 peer-address: A 4084 Relay Message option, containing: 4085 msg-type: RELAY-REPLY 4086 hop-count: 0 4087 link-address: address from link to which C is attached 4088 peer-address: C 4089 Relay Message option: 4091 Figure 10: Relay-reply Example 4093 When sending a Reconfigure message to a client through a relay agent, 4094 the server creates a Relay-reply message that includes a Relay 4095 Message option containing the Reconfigure message for the next relay 4096 agent in the return path to the client. The server sets the peer- 4097 address field in the Relay-reply message header to the address of the 4098 client, and sets the link-address field as required by the relay 4099 agent to relay the Reconfigure message to the client. The server 4100 obtains the addresses of the client and the relay agent through prior 4101 interaction with the client or through some external mechanism. 4103 19.4. Interaction between Relay Agents and Servers 4105 Each time a packet is relayed by a relay agent towards a server, a 4106 new encapsulation level is added around the packet. Each relay is 4107 allowed to insert additional options on the encapsulation level it 4108 added, but MUST NOT change anything in the packet being encapsulated. 4109 If there are multiple relays between a client and a server, multiple 4110 encapsulations are used. Although it makes packet processing 4111 slightly more complex, it has a big advantage of having clear 4112 indication which relay inserted which option. The response packet is 4113 expected to travel through the same relays, but in reverse order. 4114 Each time a response packet is relayed back towards a client, one 4115 encapsulation level is removed. 4117 In certain cases relays can add one or more options. These options 4118 can be added for several reasons. First, relays can provide 4119 additional information about the client. That source of information 4120 is usually more trusted by a server administrator as it comes from 4121 the network infrastructure rather then the client and cannot be 4122 easily spoofed. These options can be used by the server to determine 4123 its allocation policy. 4125 Second, a relay may need some information to send a response back to 4126 the client. Relay agents are expected to be stateless (not retain 4127 any state after a packet has been processed). A relay agent may 4128 include the Interface-Id option (see Section 21.18), which will be 4129 echoed back in the response. It can include other options and ask 4130 the server to echo one or more of the options back in the response. 4131 These options can then be used by the relay agent to send the 4132 response back to the client or for other needs. The client will 4133 never see these options. See [RFC4994] for details. 4135 Third, sometimes a relay is the best device to provide values for 4136 certain options. A relay can insert an option into the packet being 4137 forwarded to the server and ask the server to pass that option back 4138 to the client. The client will receive that option. It should be 4139 noted that the server is the ultimate authority here and depending on 4140 its configuration, it may send the option back to the client or not. 4141 See [RFC6422] for details. 4143 Servers may need to retain the relay information after the packet 4144 processing is completed for various reasons. One is a bulk 4145 leasequery mechanism that may ask for all addresses and/or prefixes 4146 that were assigned via a specific relay. A second is for the 4147 reconfigure mechanism. The server may chose to not send the 4148 Reconfigure message directly to the client, but rather send it via 4149 relays. This particular behavior is considered an implementation 4150 detail and is out of scope for this document. 4152 20. Authentication of DHCP Messages 4154 Within this document, two security mechanisms are introduced for the 4155 authentication of DHCP messages: authentication (and encryption) of 4156 messages sent between servers and relay agents using IPsec, and 4157 protection against misconfiguration of a client caused by a 4158 Reconfigure message sent by a malicious DHCP server. 4160 The delayed authentication protocol, defined in [RFC3315], has been 4161 obsoleted by this document (see Section 25). 4163 20.1. Security of Messages Sent Between Servers and Relay Agents 4165 Relay agents and servers that exchange messages can use IPsec as 4166 detailed in [RFC8213]. 4168 20.2. Summary of DHCP Authentication 4170 Authentication of DHCP messages is accomplished through the use of 4171 the Authentication option (see Section 21.11). The authentication 4172 information carried in the Authentication option can be used to 4173 reliably identify the source of a DHCP message and to confirm that 4174 the contents of the DHCP message have not been tampered with. 4176 The Authentication option provides a framework for multiple 4177 authentication protocols. One such protocol, the Reconfigure key 4178 authentication protocol, is defined in Section 20.4. Other protocols 4179 defined in the future will be specified in separate documents. 4181 Any DHCP message MUST NOT include more than one Authentication 4182 option. 4184 The protocol field in the Authentication option identifies the 4185 specific protocol used to generate the authentication information 4186 carried in the option. The algorithm field identifies a specific 4187 algorithm within the authentication protocol; for example, the 4188 algorithm field specifies the hash algorithm used to generate the 4189 message authentication code (MAC) in the authentication option. The 4190 replay detection method (RDM) field specifies the type of replay 4191 detection used in the replay detection field. 4193 20.3. Replay Detection 4195 The Replay Detection Method (RDM) field of the Authentication option 4196 (see Section 21.11) determines the type of replay detection used in 4197 the Replay Detection field. 4199 If the RDM field contains 0x00, the replay detection field MUST be 4200 set to the value of a strictly monotonically increasing 64-bit 4201 unsigned integer (modulo 2^64). Using this technique can reduce the 4202 danger of replay attacks. This method MUST be supported by all 4203 Authentication option protocols. One choice might be to use the 4204 64-bit NTP Timestamp format [RFC5905]). 4206 A client that receives a message with the RDM field set to 0x00 MUST 4207 compare its replay detection field with the previous value sent by 4208 that same server (based on the Server Identifier option, see 4209 Section 21.3). If this is the first time a client processes an 4210 Authentication option sent by a server, the client MUST record the 4211 replay detection value, but otherwise skip the replay detection 4212 check. 4214 Servers that support the reconfigure mechanism MUST ensure the replay 4215 detection value is retained between restarts. Failing to do so may 4216 cause clients to refuse Reconfigure messages sent by the server, 4217 effectively rendering the reconfigure mechanism useless. 4219 20.4. Reconfigure Key Authentication Protocol 4221 The Reconfigure key authentication protocol provides protection 4222 against misconfiguration of a client caused by a Reconfigure message 4223 sent by a malicious DHCP server. In this protocol, a DHCP server 4224 sends a Reconfigure Key to the client in the initial exchange of DHCP 4225 messages. The client records the Reconfigure Key for use in 4226 authenticating subsequent Reconfigure messages from that server. The 4227 server then includes an HMAC computed from the Reconfigure Key in 4228 subsequent Reconfigure messages. 4230 Both the Reconfigure Key sent from the server to the client and the 4231 HMAC in subsequent Reconfigure messages are carried as the 4232 Authentication information in an Authentication option (see 4233 Section 21.11. The format of the Authentication information is 4234 defined in the following section. 4236 The Reconfigure Key protocol is used (initiated by the server) only 4237 if the client and server have negotiated to use Reconfigure messages. 4239 20.4.1. Use of the Authentication Option in the Reconfigure Key 4240 Authentication Protocol 4242 The following fields are set in an Authentication option (see 4243 Section 21.11 for the Reconfigure Key Authentication Protocol: 4245 protocol 3 4247 algorithm 1 4249 RDM 0 4251 The format of the authentication information for the Reconfigure Key 4252 Authentication Protocol is: 4254 0 1 2 3 4255 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 4256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4257 | Type | Value (128 bits) | 4258 +-+-+-+-+-+-+-+-+ | 4259 . . 4260 . . 4261 . +-+-+-+-+-+-+-+-+ 4262 | | 4263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4265 Figure 11: RKAP Authentication Information 4267 Type Type of data in the Value field carried in this 4268 option: 4270 1 Reconfigure Key value (used in Reply 4271 message). 4273 2 HMAC-MD5 digest of the message (used in 4274 Reconfigure message). 4276 A one octet long field. 4278 Value Data as defined by the Type field. A 16 octets 4279 long field. 4281 20.4.2. Server Considerations for Reconfigure Key Authentication 4282 Protocol 4284 The server selects a Reconfigure Key for a client during the Request/ 4285 Reply, Solicit/Reply or Information-request/Reply message exchange. 4286 The server records the Reconfigure Key and transmits that key to the 4287 client in an Authentication option (see Section 21.11) in the Reply 4288 message. 4290 The Reconfigure Key is 128 bits long, and MUST be a cryptographically 4291 strong random or pseudo-random number that cannot easily be 4292 predicted. 4294 To provide authentication for a Reconfigure message, the server 4295 selects a replay detection value according to the RDM selected by the 4296 server, and computes an HMAC-MD5 of the Reconfigure message using the 4297 Reconfigure Key for the client. The server computes the HMAC-MD5 4298 over the entire DHCP Reconfigure message, including the 4299 Authentication option; the HMAC-MD5 field in the Authentication 4300 option is set to zero for the HMAC-MD5 computation. The server 4301 includes the HMAC-MD5 in the authentication information field in an 4302 Authentication option included in the Reconfigure message sent to the 4303 client. 4305 20.4.3. Client Considerations for Reconfigure Key Authentication 4306 Protocol 4308 The client will receive a Reconfigure Key from the server in an 4309 Authentication option (see Section 21.11) in the initial Reply 4310 message from the server. The client records the Reconfigure Key for 4311 use in authenticating subsequent Reconfigure messages. 4313 To authenticate a Reconfigure message, the client computes an HMAC- 4314 MD5 over the Reconfigure message, with zeroes substituted for the 4315 HMAC-MD5 field, using the Reconfigure Key received from the server. 4316 If this computed HMAC-MD5 matches the value in the Authentication 4317 option, the client accepts the Reconfigure message. 4319 21. DHCP Options 4321 Options are used to carry additional information and parameters in 4322 DHCP messages. Every option shares a common base format, as 4323 described in Section 21.1. All values in options are represented in 4324 network byte order. 4326 This document describes the DHCP options defined as part of the base 4327 DHCP specification. Other options may be defined in the future in 4328 separate documents. See [RFC7227] for guidelines regarding new 4329 options definition. See Section 24 for additional information about 4330 a registry maintained by IANA. 4332 Unless otherwise noted, each option may appear only in the options 4333 area of a DHCP message and may appear only once. If an option does 4334 appear multiple times, each instance is considered separate and the 4335 data areas of the options MUST NOT be concatenated or otherwise 4336 combined. 4338 Options that are allowed to appear only once are called singleton 4339 options. The only non-singleton options defined in this document are 4340 IA_NA (see Section 21.4), IA_TA (see Section 21.5), Vendor Class (see 4341 Section 21.16), Vendor-specific Information (see Section 21.17), and 4342 IA_PD (see Section 21.21) options. Also, IA Address (see 4343 Section 21.6) and IA Prefix (see Section 21.22) may appear in their 4344 respective IA options more than once. 4346 21.1. Format of DHCP Options 4348 The format of DHCP options is: 4350 0 1 2 3 4351 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 4352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4353 | option-code | option-len | 4354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4355 | option-data | 4356 | (option-len octets) | 4357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4359 Figure 12: Option Format 4361 option-code An unsigned integer identifying the specific 4362 option type carried in this option. A two 4363 octets long field. 4365 option-len An unsigned integer giving the length of the 4366 option-data field in this option in octets. 4367 A two octets long field. 4369 option-data The data for the option; the format of this 4370 data depends on the definition of the option. 4371 A variable length field (the length, in 4372 octets, is specified by option-len). 4374 DHCP options are scoped by using encapsulation. Some options apply 4375 generally to the client, some are specific to an IA, and some are 4376 specific to the addresses within an IA. These latter two cases are 4377 discussed in Section 21.4 and Section 21.6. 4379 21.2. Client Identifier Option 4381 The Client Identifier option is used to carry a DUID (see Section 11) 4382 identifying a client between a client and a server. The format of 4383 the Client Identifier option is: 4385 0 1 2 3 4386 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 4387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4388 | OPTION_CLIENTID | option-len | 4389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4390 . . 4391 . DUID . 4392 . (variable length) . 4393 . . 4394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4396 Figure 13: Client Identifier Option Format 4398 option-code OPTION_CLIENTID (1). 4400 option-len Length of DUID in octets. 4402 DUID The DUID for the client. 4404 21.3. Server Identifier Option 4406 The Server Identifier option is used to carry a DUID (see Section 11) 4407 identifying a server between a client and a server. The format of 4408 the Server Identifier option is: 4410 0 1 2 3 4411 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 4412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4413 | OPTION_SERVERID | option-len | 4414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4415 . . 4416 . DUID . 4417 . (variable length) . 4418 . . 4419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4421 Figure 14: Server Identifier Option Format 4423 option-code OPTION_SERVERID (2). 4425 option-len Length of DUID in octets. 4427 DUID The DUID for the server. 4429 21.4. Identity Association for Non-temporary Addresses Option 4431 The Identity Association for Non-temporary Addresses option (IA_NA 4432 option) is used to carry an IA_NA, the parameters associated with the 4433 IA_NA, and the non-temporary addresses associated with the IA_NA. 4435 Addresses appearing in an IA_NA option are not temporary addresses 4436 (see Section 21.5). 4438 The format of the IA_NA option is: 4440 0 1 2 3 4441 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 4442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4443 | OPTION_IA_NA | option-len | 4444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4445 | IAID (4 octets) | 4446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4447 | T1 | 4448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4449 | T2 | 4450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4451 | | 4452 . IA_NA-options . 4453 . . 4454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4456 Figure 15: Identity Association for Non-temporary Addresses Option 4457 Format 4459 option-code OPTION_IA_NA (3). 4461 option-len 12 + length of IA_NA-options field. 4463 IAID The unique identifier for this IA_NA; the 4464 IAID must be unique among the identifiers for 4465 all of this client's IA_NAs. The number 4466 space for IA_NA IAIDs is separate from the 4467 number space for other IA option types (i.e., 4468 IA_TA and IA_PD). A four octets long field 4469 containing an unsigned integer. 4471 T1 The time interval after which the client 4472 should contact the server from which the 4473 addresses in the IA_NA were obtained to 4474 extend the lifetimes of the addresses 4475 assigned to the IA_NA; T1 is a time duration 4476 relative to the current time expressed in 4477 units of seconds. A four octets long field 4478 containing an unsigned integer. 4480 T2 The time interval after which the client 4481 should contact any available server to extend 4482 the lifetimes of the addresses assigned to 4483 the IA_NA; T2 is a time duration relative to 4484 the current time expressed in units of 4485 seconds. A four octets long field containing 4486 an unsigned integer. 4488 IA_NA-options Options associated with this IA_NA. A 4489 variable length field (12 octets less than 4490 the value in the option-len field). 4492 The IA_NA-options field encapsulates those options that are specific 4493 to this IA_NA. For example, all of the IA Address options (see 4494 Section 21.6) carrying the addresses associated with this IA_NA are 4495 in the IA_NA-options field. 4497 Each IA_NA carries one "set" of non-temporary addresses; it is up to 4498 the server policy to determine how many addresses are assigned, but 4499 typically at most one address is assigned from each prefix assigned 4500 to the link to which the client is attached to. 4502 An IA_NA option may only appear in the options area of a DHCP 4503 message. A DHCP message may contain multiple IA_NA options (though 4504 each must have a unique IAID). 4506 The status of any operations involving this IA_NA is indicated in a 4507 Status Code option (see Section 21.13) in the IA_NA-options field. 4509 Note that an IA_NA has no explicit "lifetime" or "lease length" of 4510 its own. When the valid lifetimes of all of the addresses in an 4511 IA_NA have expired, the IA_NA can be considered as having expired. 4512 T1 and T2 are included to give servers explicit control over when a 4513 client recontacts the server about a specific IA_NA. 4515 In a message sent by a client to a server, the T1 and T2 fields 4516 SHOULD be set to 0. The server MUST ignore any values in these 4517 fields in messages received from a client. 4519 In a message sent by a server to a client, the client MUST use the 4520 values in the T1 and T2 fields for the T1 and T2 times, unless those 4521 values in those fields are 0. The values in the T1 and T2 fields are 4522 the number of seconds until T1 and T2 and are calculated since 4523 reception of the message. 4525 As per Section 7.7, the value 0xffffffff is taken to mean "infinity" 4526 and should be used carefully. 4528 The server selects the T1 and T2 values to allow the client to extend 4529 the lifetimes of any addresses in the IA_NA before the lifetimes 4530 expire, even if the server is unavailable for some short period of 4531 time. Recommended values for T1 and T2 are .5 and .8 times the 4532 shortest preferred lifetime of the addresses in the IA that the 4533 server is willing to extend, respectively. If the "shortest" 4534 preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and 4535 T2 values are also 0xffffffff. If the time at which the addresses in 4536 an IA_NA are to be renewed is to be left to the discretion of the 4537 client, the server sets T1 and T2 values to 0. The client MUST 4538 follow the rules defined in Section 14.2. 4540 If a client receives an IA_NA with T1 greater than T2, and both T1 4541 and T2 are greater than 0, the client discards the IA_NA option and 4542 processes the remainder of the message as though the server had not 4543 included the invalid IA_NA option. 4545 21.5. Identity Association for Temporary Addresses Option 4547 The Identity Association for the Temporary Addresses (IA_TA) option 4548 is used to carry an IA_TA, the parameters associated with the IA_TA 4549 and the addresses associated with the IA_TA. All of the addresses in 4550 this option are used by the client as temporary addresses, as defined 4551 in [RFC4941]. The format of the IA_TA option is: 4553 0 1 2 3 4554 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 4555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4556 | OPTION_IA_TA | option-len | 4557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4558 | IAID (4 octets) | 4559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4560 | | 4561 . IA_TA-options . 4562 . . 4563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4565 Figure 16: Identity Association for Temporary Addresses Option Format 4567 option-code OPTION_IA_TA (4). 4569 option-len 4 + length of IA_TA-options field. 4571 IAID The unique identifier for this IA_TA; the 4572 IAID must be unique among the identifiers for 4573 all of this client's IA_TAs. The number 4574 space for IA_TA IAIDs is separate from the 4575 number space for other IA option types (i.e., 4576 IA_NA and IA_PD). A four octets long field 4577 containing an unsigned integer. 4579 IA_TA-options Options associated with this IA_TA. A 4580 variable length field (4 octets less than the 4581 value in the option-len field). 4583 The IA_TA-Options field encapsulates those options that are specific 4584 to this IA_TA. For example, all of the IA Address options (see 4585 Section 21.6) carrying the addresses associated with this IA_TA are 4586 in the IA_TA-options field. 4588 Each IA_TA carries one "set" of temporary addresses. It is up to the 4589 server policy to determine how many addresses are assigned. 4591 An IA_TA option may only appear in the options area of a DHCP 4592 message. A DHCP message may contain multiple IA_TA options (though 4593 each must have a unique IAID). 4595 The status of any operations involving this IA_TA is indicated in a 4596 Status Code option (see Section 21.13) in the IA_TA-options field. 4598 Note that an IA has no explicit "lifetime" or "lease length" of its 4599 own. When the valid lifetimes of all of the addresses in an IA_TA 4600 have expired, the IA can be considered as having expired. 4602 An IA_TA option does not include values for T1 and T2. A client MAY 4603 request that the valid lifetime on temporary addresses be extended by 4604 including the addresses in a IA_TA option sent in a Renew or Rebind 4605 message to a server. For example, a client would request an 4606 extension on the valid lifetime of a temporary address to allow an 4607 application to continue to use an established TCP connection. 4608 Extending only the valid, but not the preferred lifetime means the 4609 address will end up in deprecated state eventually. Existing 4610 connections could continue, but no new ones would be created using 4611 that address. 4613 The client obtains new temporary addresses by sending an IA_TA option 4614 with a new IAID to a server. Requesting new temporary addresses from 4615 the server is the equivalent of generating new temporary addresses as 4616 described in [RFC4941]. The server will generate new temporary 4617 addresses and return them to the client. The client should request 4618 new temporary addresses before the lifetimes on the previously 4619 assigned addresses expire. 4621 A server MUST return the same set of temporary address for the same 4622 IA_TA (as identified by the IAID) as long as those addresses are 4623 still valid. After the lifetimes of the addresses in an IA_TA have 4624 expired, the IAID may be reused to identify a new IA_TA with new 4625 temporary addresses. 4627 21.6. IA Address Option 4629 The IA Address option is used to specify an address associated with 4630 an IA_NA or an IA_TA. The IA Address option must be encapsulated in 4631 the Options field of an IA_NA (see Section 21.4) or IA_TA (see 4632 Section 21.5) option. The IAaddr-options fields encapsulates those 4633 options that are specific to this address. 4635 The format of the IA Address option is: 4637 0 1 2 3 4638 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 4639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4640 | OPTION_IAADDR | option-len | 4641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4642 | | 4643 | IPv6-address | 4644 | | 4645 | | 4646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4647 | preferred-lifetime | 4648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4649 | valid-lifetime | 4650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4651 . . 4652 . IAaddr-options . 4653 . . 4654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4656 Figure 17: IA Address Option Format 4658 option-code OPTION_IAADDR (5). 4660 option-len 24 + length of IAaddr-options field. 4662 IPv6-address An IPv6 address. A client MUST NOT form an 4663 implicit prefix with a length other than 128 4664 for this address. And, a client MUST NOT 4665 assume any length of prefix that matches this 4666 address is on-link (see [RFC7421]). A 16 4667 octets long field. 4669 preferred-lifetime The preferred lifetime for the address in the 4670 option, expressed in units of seconds. A 4671 four octets long field containing an unsigned 4672 integer. 4674 valid-lifetime The valid lifetime for the address in the 4675 option, expressed in units of seconds. A 4676 four octets long field containing an unsigned 4677 integer. 4679 IAaddr-options Options associated with this address. A 4680 variable length field (24 octets less than 4681 the value in the option-len field). 4683 In a message sent by a client to a server, the preferred and valid 4684 lifetime fields SHOULD be set to 0. The server MUST ignore any 4685 received values. 4687 The client SHOULD NOT send the IA Address option with an unspecified 4688 address (::). 4690 In a message sent by a server to a client, the client MUST use the 4691 values in the preferred and valid lifetime fields for the preferred 4692 and valid lifetimes. The values in the preferred and valid lifetimes 4693 are the number of seconds remaining in each lifetime. 4695 The client MUST discard any addresses for which the preferred 4696 lifetime is greater than the valid lifetime. 4698 As per Section 7.7, the valid lifetime of an address 0xffffffff is 4699 taken to mean "infinity" and should be used carefully. 4701 More than one IA Address option can appear in an IA_NA option or an 4702 IA_TA option. 4704 The status of any operations involving this IA Address is indicated 4705 in a Status Code option in the IAaddr-options field, as specified in 4706 Section 21.13. 4708 21.7. Option Request Option 4710 The Option Request option is used to identify a list of options in a 4711 message between a client and a server. The format of the Option 4712 Request option is: 4714 0 1 2 3 4715 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 4716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4717 | OPTION_ORO | option-len | 4718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4719 | requested-option-code-1 | requested-option-code-2 | 4720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4721 | ... | 4722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4724 Figure 18: Option Request Option Format 4726 option-code OPTION_ORO (6). 4728 option-len 2 * number of requested options. 4730 requested-option-code-n The option-code for an option requested 4731 by the client. Each option-code is a two 4732 octets long field containing an unsigned 4733 integer. 4735 A client MUST include an Option Request option in a Solicit, Request, 4736 Renew, Rebind, or Information-request message to inform the server 4737 about options the client wants the server to send to the client. For 4738 certain message types, some option codes MUST be included in the 4739 Option Request option, see Table 4 for details. 4741 The Option Request option MUST NOT include the following options: 4742 Client Identifier (see Section 21.2), Server Identifier (see 4743 Section 21.3), IA_NA (see Section 21.4), IA_TA (see Section 21.5), 4744 IA_PD (see Section 21.21), IA Address (see Section 21.6), IA Prefix 4745 (see Section 21.22), Option Request, Elapsed Time (see 4746 Section 21.23), Preference (see Section 21.8), Relay Message (see 4747 Section 21.9), Authentication (see Section 21.11), Server Unicast 4748 (see Section 21.12), Status Code (see Section 21.13), Rapid Commit 4749 (see Section 21.14), User Class (see Section 21.15), Vendor Class 4750 (see Section 21.16), Interface-Id (see Section 21.17), Reconfigure 4751 Message (see Section 21.19), and Reconfigure Accept (see 4752 Section 21.20). Other top-level options MUST appear in the Option 4753 Request option or they will not be sent by the server. Only top- 4754 level options MAY appear in the Option Request option. Options 4755 encapsulated in a container option SHOULD NOT appear in an Option 4756 Request option; see [RFC7598] for an example of container options. 4757 However, options MAY be defined which specify exceptions to this 4758 restriction on including encapsulated options in an Option Request 4759 option. For example, the Option Request option MAY be used to signal 4760 support for a feature even when that option is encapsulated, as in 4761 the case of the Prefix Exclude option [RFC6603]. See Table 4. 4763 21.8. Preference Option 4765 The Preference option is sent by a server to a client to affect the 4766 selection of a server by the client. 4768 The format of the Preference option is: 4770 0 1 2 3 4771 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 4772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4773 | OPTION_PREFERENCE | option-len | 4774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4775 | pref-value | 4776 +-+-+-+-+-+-+-+-+ 4778 Figure 19: Preference Option Format 4780 option-code OPTION_PREFERENCE (7). 4782 option-len 1. 4784 pref-value The preference value for the server in this 4785 message. A one-octet unsigned integer. 4787 A server MAY include a Preference option in an Advertise message to 4788 control the selection of a server by the client. See Section 18.2.9 4789 for the use of the Preference option by the client and the 4790 interpretation of Preference option data value. 4792 21.9. Elapsed Time Option 4794 0 1 2 3 4795 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 4796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4797 | OPTION_ELAPSED_TIME | option-len | 4798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4799 | elapsed-time | 4800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4802 Figure 20: Elapsed Time Option Format 4804 option-code OPTION_ELAPSED_TIME (8). 4806 option-len 2. 4808 elapsed-time The amount of time since the client began its 4809 current DHCP transaction. This time is 4810 expressed in hundredths of a second (10^-2 4811 seconds). A two octets long field containing 4812 an unsigned integer. 4814 A client MUST include an Elapsed Time option in messages to indicate 4815 how long the client has been trying to complete a DHCP message 4816 exchange. The elapsed time is measured from the time at which the 4817 client sent the first message in the message exchange, and the 4818 elapsed-time field is set to 0 in the first message in the message 4819 exchange. Servers and Relay Agents use the data value in this option 4820 as input to policy controlling how a server responds to a client 4821 message. For example, the Elapsed Time option allows a secondary 4822 DHCP server to respond to a request when a primary server has not 4823 answered in a reasonable time. The elapsed time value is an 4824 unsigned, 16 bit integer. The client uses the value 0xffff to 4825 represent any elapsed time values greater than the largest time value 4826 that can be represented in the Elapsed Time option. 4828 21.10. Relay Message Option 4830 The Relay Message option carries a DHCP message in a Relay-forward or 4831 Relay-reply message. 4833 The format of the Relay Message option is: 4835 0 1 2 3 4836 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 4837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4838 | OPTION_RELAY_MSG | option-len | 4839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4840 | | 4841 . DHCP-relay-message . 4842 . . 4843 . . 4844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4846 Figure 21: Relay Message Option Format 4848 option-code OPTION_RELAY_MSG (9). 4850 option-len Length of DHCP-relay-message. 4852 DHCP-relay-message In a Relay-forward message, the received 4853 message, relayed verbatim to the next relay 4854 agent or server; in a Relay-reply message, 4855 the message to be copied and relayed to the 4856 relay agent or client whose address is in the 4857 peer-address field of the Relay-reply 4858 message. The length, in octets, is specified 4859 by option-len. 4861 21.11. Authentication Option 4863 The Authentication option carries authentication information to 4864 authenticate the identity and contents of DHCP messages. The use of 4865 the Authentication option is described in Section 20. The delayed 4866 authentication protocol, defined in [RFC3315], has been obsoleted by 4867 this document, due to lack of usage. The format of the 4868 Authentication option is: 4870 0 1 2 3 4871 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 4872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4873 | OPTION_AUTH | option-len | 4874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4875 | protocol | algorithm | RDM | | 4876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4877 | | 4878 | replay detection (64 bits) +-+-+-+-+-+-+-+-+ 4879 | | | 4880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4881 . authentication information . 4882 . (variable length) . 4883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4885 Figure 22: Authentication Option Format 4887 option-code OPTION_AUTH (11). 4889 option-len 11 + length of authentication information 4890 field. 4892 protocol The authentication protocol used in this 4893 authentication option. A one-octet unsigned 4894 integer. 4896 algorithm The algorithm used in the authentication 4897 protocol. A one-octet unsigned integer. 4899 RDM The replay detection method used in this 4900 Authentication option. A one-octet unsigned 4901 integer. 4903 Replay detection The replay detection information for the RDM. 4904 A 64-bit (8 octets) long field 4906 authentication information The authentication information, as 4907 specified by the protocol and algorithm used 4908 in this Authentication option. A variable 4909 length field (11 octets less than the value 4910 in option-len). 4912 IANA maintains a registry for the protocol, algorithm, and RDM values 4913 at https://www.iana.org/assignments/auth-namespaces. 4915 21.12. Server Unicast Option 4917 The server sends this option to a client to indicate to the client 4918 that it is allowed to unicast messages to the server. The format of 4919 the Server Unicast option is: 4921 0 1 2 3 4922 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 4923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4924 | OPTION_UNICAST | option-len | 4925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4926 | | 4927 | server-address | 4928 | | 4929 | | 4930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4932 Figure 23: Server Unicast Option Format 4934 option-code OPTION_UNICAST (12). 4936 option-len 16. 4938 server-address The 128-bit address to which the client 4939 should send messages delivered using unicast. 4941 The server specifies the address to which the client is to send 4942 unicast messages in the server-address field. When a client receives 4943 this option, where permissible and appropriate, the client sends 4944 messages directly to the server using the address specified in the 4945 server-address field of the option. 4947 When the server sends a Unicast option to the client, some messages 4948 from the client will not be relayed by relay agents, and will not 4949 include relay agent options from the relay agents. Therefore, a 4950 server should only send a Unicast option to a client when relay 4951 agents are not sending relay agent options. A DHCP server rejects 4952 any messages sent inappropriately using unicast to ensure that 4953 messages are relayed by relay agents when relay agent options are in 4954 use. 4956 Details about when the client may send messages to the server using 4957 unicast are in Section 18. 4959 21.13. Status Code Option 4961 This option returns a status indication related to the DHCP message 4962 or option in which it appears. The format of the Status Code option 4963 is: 4965 0 1 2 3 4966 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 4967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4968 | OPTION_STATUS_CODE | option-len | 4969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4970 | status-code | | 4971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4972 . . 4973 . status-message . 4974 . . 4975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4977 Figure 24: Status Code Option Format 4979 option-code OPTION_STATUS_CODE (13). 4981 option-len 2 + length of status-message. 4983 status-code The numeric code for the status encoded in 4984 this option. A two octets long field 4985 containing an unsigned integer. 4987 status-message A UTF-8 encoded text string suitable for 4988 display to an end user, which MUST NOT be 4989 null-terminated. A variable length field (2 4990 octets less than the value in option-len). 4992 A Status Code option may appear in the options field of a DHCP 4993 message and/or in the options field of another option. If the Status 4994 Code option does not appear in a message in which the option could 4995 appear, the status of the message is assumed to be Success. 4997 The status-code values previously defined by [RFC3315] and [RFC3633] 4998 are: 5000 +---------------+------+--------------------------------------------+ 5001 | Name | Code | Description | 5002 +---------------+------+--------------------------------------------+ 5003 | Success | 0 | Success. | 5004 | UnspecFail | 1 | Failure, reason unspecified; this status | 5005 | | | code is sent by either a client or a | 5006 | | | server to indicate a failure not | 5007 | | | explicitly specified in this document. | 5008 | NoAddrsAvail | 2 | Server has no addresses available to | 5009 | | | assign to the IA(s). | 5010 | NoBinding | 3 | Client record (binding) unavailable. | 5011 | NotOnLink | 4 | The prefix for the address is not | 5012 | | | appropriate for the link to which the | 5013 | | | client is attached. | 5014 | UseMulticast | 5 | Sent by a server to a client to force the | 5015 | | | client to send messages to the server | 5016 | | | using the | 5017 | | | All_DHCP_Relay_Agents_and_Servers | 5018 | | | multicast address. | 5019 | NoPrefixAvail | 6 | Server has no prefixes available to assign | 5020 | | | to the IA_PD(s). | 5021 +---------------+------+--------------------------------------------+ 5023 Table 3: Status Code Definitions 5025 See Section 24 for additional information about the registry 5026 maintained by IANA with the complete list of status codes. 5028 21.14. Rapid Commit Option 5030 The Rapid Commit option is used to signal the use of the two message 5031 exchange for address assignment. The format of the Rapid Commit 5032 option is: 5034 0 1 2 3 5035 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 5036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5037 | OPTION_RAPID_COMMIT | 0 | 5038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5040 Figure 25: Rapid Commit Option Format 5042 option-code OPTION_RAPID_COMMIT (14). 5044 option-len 0. 5046 A client MAY include this option in a Solicit message if the client 5047 is prepared to perform the Solicit/Reply message exchange described 5048 in Section 18.2.1. 5050 A server MUST include this option in a Reply message sent in response 5051 to a Solicit message when completing the Solicit/Reply message 5052 exchange. 5054 DISCUSSION: 5056 Each server that responds with a Reply to a Solicit that includes 5057 a Rapid Commit option will commit the leases in the Reply message 5058 to the client, and will not receive any confirmation that the 5059 client has received the Reply message. Therefore, if more than 5060 one server responds to a Solicit that includes a Rapid Commit 5061 option, some servers will commit leases that are not actually used 5062 by the client, which could result in bad information in the DNS 5063 server if the DHCP server updates DNS [RFC4704] or in response to 5064 leasequery requests [RFC5007]. 5066 The problem of unused leases can be minimized by designing the 5067 DHCP service so that only one server responds to the Solicit or by 5068 using relatively short lifetimes for newly assigned leases. 5070 21.15. User Class Option 5072 The User Class option is used by a client to identify the type or 5073 category of user or applications it represents. 5075 The format of the User Class option is: 5077 0 1 2 3 5078 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 5079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5080 | OPTION_USER_CLASS | option-len | 5081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5082 . . 5083 . user-class-data . 5084 . . 5085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5087 Figure 26: User Class Option Format 5089 option-code OPTION_USER_CLASS (15). 5091 option-len Length of user class data field. 5093 user-class-data The user classes carried by the client. The 5094 length, in octets, is specified by option- 5095 len. 5097 The information contained in the data area of this option is 5098 contained in one or more opaque fields that represent the user class 5099 or classes of which the client is a member. A server selects 5100 configuration information for the client based on the classes 5101 identified in this option. For example, the User Class option can be 5102 used to configure all clients of people in the accounting department 5103 with a different printer than clients of people in the marketing 5104 department. The user class information carried in this option MUST 5105 be configurable on the client. 5107 The data area of the User Class option MUST contain one or more 5108 instances of user class data. Each instance of the user class data 5109 is formatted as follows: 5111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 5112 | user-class-len | opaque-data | 5113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 5115 Figure 27: User Class Data Format 5117 The user-class-len is two octets long and specifies the length of the 5118 opaque user class data in network byte order. 5120 A server interprets the classes identified in this option according 5121 to its configuration to select the appropriate configuration 5122 information for the client. A server may use only those user classes 5123 that it is configured to interpret in selecting configuration 5124 information for a client and ignore any other user classes. In 5125 response to a message containing a User Class option, a server 5126 includes a User Class option containing those classes that were 5127 successfully interpreted by the server, so that the client can be 5128 informed of the classes interpreted by the server. 5130 21.16. Vendor Class Option 5132 This option is used by a client to identify the vendor that 5133 manufactured the hardware on which the client is running. The 5134 information contained in the data area of this option is contained in 5135 one or more opaque fields that identify details of the hardware 5136 configuration. The format of the Vendor Class option is: 5138 0 1 2 3 5139 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 5140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5141 | OPTION_VENDOR_CLASS | option-len | 5142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5143 | enterprise-number | 5144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5145 . . 5146 . vendor-class-data . 5147 . . . . . 5148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5150 Figure 28: Vendor Class Option Format 5152 option-code OPTION_VENDOR_CLASS (16). 5154 option-len 4 + length of vendor class data field. 5156 enterprise-number The vendor's registered Enterprise Number as 5157 registered with IANA [IANA-PEN]. A four 5158 octets long field containing an unsigned 5159 integer. 5161 vendor-class-data The hardware configuration of the node on 5162 which the client is running. A variable 5163 length field (4 octets less than the value in 5164 option-len). 5166 The vendor-class-data is composed of a series of separate items, each 5167 of which describes some characteristic of the client's hardware 5168 configuration. Examples of vendor-class-data instances might include 5169 the version of the operating system the client is running or the 5170 amount of memory installed on the client. 5172 Each instance of the vendor-class-data is formatted as follows: 5174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 5175 | vendor-class-len | opaque-data | 5176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 5178 Figure 29: Vendor Class Data Format 5180 The vendor-class-len is two octets long and specifies the length of 5181 the opaque vendor class data in network byte order. 5183 Servers and clients MUST NOT include more than one instance of 5184 OPTION_VENDOR_CLASS with the same Enterprise Number. Each instance 5185 of OPTION_VENDOR_CLASS can carry multiple vendor-class-data 5186 instances. 5188 21.17. Vendor-specific Information Option 5190 This option is used by clients and servers to exchange vendor- 5191 specific information. 5193 The format of the Vendor-specific Information option is: 5195 0 1 2 3 5196 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 5197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5198 | OPTION_VENDOR_OPTS | option-len | 5199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5200 | enterprise-number | 5201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5202 . . 5203 . vendor-option-data . 5204 . . 5205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5207 Figure 30: Vendor-specific Information Option Format 5209 option-code OPTION_VENDOR_OPTS (17). 5211 option-len 4 + length of option-data field. 5213 enterprise-number The vendor's registered Enterprise Number as 5214 registered with IANA [IANA-PEN]. A four 5215 octets long field containing an unsigned 5216 integer. 5218 vendor-option-data Vendor options, interpreted by vendor- 5219 specific code on the clients and servers. A 5220 variable length field (4 octets less than the 5221 value in option-len). 5223 The definition of the information carried in this option is vendor 5224 specific. The vendor is indicated in the enterprise-number field. 5225 Use of vendor-specific information allows enhanced operation, 5226 utilizing additional features in a vendor's DHCP implementation. A 5227 DHCP client that does not receive requested vendor-specific 5228 information will still configure the node device's IPv6 stack to be 5229 functional. 5231 The vendor-option-data field MUST be encoded as a sequence of 5232 code/length/value fields of identical format to the DHCP options 5233 field. The sub-option codes are defined by the vendor identified in 5234 the enterprise-number field, and are not managed by IANA. Each of 5235 the sub-options is formatted as follows: 5237 0 1 2 3 5238 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 5239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5240 | sub-opt-code | sub-option-len | 5241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5242 . . 5243 . sub-option-data . 5244 . . 5245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5247 Figure 31: Vendor-specific Options Format 5249 sub-opt-code The code for the sub-option. A two octets 5250 long field. 5252 sub-option-len An unsigned integer giving the length of the 5253 sub-option-data field in this sub-option in 5254 octets. A two octets long field. 5256 sub-option-data The data area for the sub-option. The 5257 length, in octets, is specified by sub- 5258 option-len. 5260 Multiple instances of the Vendor-specific Information option may 5261 appear in a DHCP message. Each instance of the option is interpreted 5262 according to the option codes defined by the vendor identified by the 5263 Enterprise Number in that option. Servers and clients MUST NOT send 5264 more than one instance of Vendor-specific Information option with the 5265 same Enterprise Number. Each instance of Vendor-specific Information 5266 option MAY contain multiple sub-options. 5268 A client that is interested in receiving a Vendor-specific 5269 Information option: 5271 - MUST specify the Vendor-specific Information option in an Option 5272 Request option. 5274 - MAY specify an associated Vendor Class option (see Section 21.16). 5276 - MAY specify the Vendor-specific Information option with 5277 appropriate data. 5279 Servers only return the Vendor-specific Information options if 5280 specified in Option Request options from clients and: 5282 - MAY use the Enterprise Numbers in the associated Vendor Class 5283 options to restrict the set of Enterprise Numbers in the Vendor- 5284 specific Information options returned. 5286 - MAY return all configured Vendor-specific Information options. 5288 - MAY use other information in the packet or in its configuration to 5289 determine which set of Enterprise Numbers in the Vendor-specific 5290 Information options to return. 5292 21.18. Interface-Id Option 5294 The relay agent MAY send the Interface-Id option to identify the 5295 interface on which the client message was received. If a relay agent 5296 receives a Relay-reply message with an Interface-Id option, the relay 5297 agent relays the message to the client through the interface 5298 identified by the option. 5300 The format of the Interface-Id option is: 5302 0 1 2 3 5303 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 5304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5305 | OPTION_INTERFACE_ID | option-len | 5306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5307 . . 5308 . interface-id . 5309 . . 5310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5312 Figure 32: Interface-ID Option Format 5314 option-code OPTION_INTERFACE_ID (18). 5316 option-len Length of interface-id field. 5318 interface-id An opaque value of arbitrary length generated 5319 by the relay agent to identify one of the 5320 relay agent's interfaces. The length, in 5321 octets, is specified by option-len. 5323 The server MUST copy the Interface-Id option from the Relay-forward 5324 message into the Relay-reply message the server sends to the relay 5325 agent in response to the Relay-forward message. This option MUST NOT 5326 appear in any message except a Relay-forward or Relay-reply message. 5328 Servers MAY use the interface-id for parameter assignment policies. 5329 The interface-id SHOULD be considered an opaque value, with policies 5330 based on exact match only; that is, the interface-id SHOULD NOT be 5331 internally parsed by the server. The interface-id value for an 5332 interface SHOULD be stable and remain unchanged, for example, after 5333 the relay agent is restarted; if the interface-id changes, a server 5334 will not be able to use it reliably in parameter assignment policies. 5336 21.19. Reconfigure Message Option 5338 A server includes a Reconfigure Message option in a Reconfigure 5339 message to indicate to the client whether the client responds with a 5340 Renew message, a Rebind message, or an Information-request message. 5341 The format of this option is: 5343 0 1 2 3 5344 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 5345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5346 | OPTION_RECONF_MSG | option-len | 5347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5348 | msg-type | 5349 +-+-+-+-+-+-+-+-+ 5351 Figure 33: Reconfigure Message Option Format 5353 option-code OPTION_RECONF_MSG (19). 5355 option-len 1. 5357 msg-type 5 for Renew message, 6 for Rebind, 11 for 5358 Information-request message. A one-octet 5359 unsigned integer. 5361 The Reconfigure Message option can only appear in a Reconfigure 5362 message. 5364 21.20. Reconfigure Accept Option 5366 A client uses the Reconfigure Accept option to announce to the server 5367 whether the client is willing to accept Reconfigure messages, and a 5368 server uses this option to tell the client whether or not to accept 5369 Reconfigure messages. The default behavior, in the absence of this 5370 option, means unwillingness to accept Reconfigure messages, or 5371 instruction not to accept Reconfigure messages, for the client and 5372 server messages, respectively. The following figure gives the format 5373 of the Reconfigure Accept option: 5375 0 1 2 3 5376 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 5377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5378 | OPTION_RECONF_ACCEPT | 0 | 5379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5381 Figure 34: Reconfigure Accept Option Format 5383 option-code OPTION_RECONF_ACCEPT (20). 5385 option-len 0. 5387 21.21. Identity Association for Prefix Delegation Option 5389 The IA_PD option is used to carry a prefix delegation identity 5390 association, the parameters associated with the IA_PD and the 5391 prefixes associated with it. The format of this option is: 5393 0 1 2 3 5394 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 5395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5396 | OPTION_IA_PD | option-length | 5397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5398 | IAID (4 octets) | 5399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5400 | T1 | 5401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5402 | T2 | 5403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5404 . . 5405 . IA_PD-options . 5406 . . 5407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5409 Figure 35: Identity Association for Prefix Delegation Option Format 5411 option-code OPTION_IA_PD (25). 5413 option-length 12 + length of IA_PD-options field. 5415 IAID The unique identifier for this IA_PD; the 5416 IAID must be unique among the identifiers for 5417 all of this client's IA_PDs. The number 5418 space for IA_PD IAIDs is separate from the 5419 number space for other IA option types (i.e., 5420 IA_NA and IA_TA). A four octets long field 5421 containing an unsigned integer. 5423 T1 The time interval after which the client 5424 should contact the server from which the 5425 prefixes in the IA_PD were obtained to extend 5426 the lifetimes of the prefixes delegated to 5427 the IA_PD; T1 is a time duration relative to 5428 the message reception time expressed in units 5429 of seconds. A four octets long field 5430 containing an unsigned integer. 5432 T2 The time interval after which the client 5433 should contact any available server to extend 5434 the lifetimes of the prefixes assigned to the 5435 IA_PD; T2 is a time duration relative to the 5436 message reception time expressed in units of 5437 seconds. A four octets long field containing 5438 an unsigned integer. 5440 IA_PD-options Options associated with this IA_PD. A 5441 variable length field (12 octets less than 5442 the value in the option-len field). 5444 The IA_PD-options field encapsulates those options that are specific 5445 to this IA_PD. For example, all of the IA Prefix options (see 5446 Section 21.22) carrying the prefixes associated with this IA_PD are 5447 in the IA_PD-options field. 5449 An IA_PD option may only appear in the options area of a DHCP 5450 message. A DHCP message may contain multiple IA_PD options (though 5451 each must have a unique IAID). 5453 The status of any operations involving this IA_PD is indicated in a 5454 Status Code option (see Section 21.13) in the IA_PD-options field. 5456 Note that an IA_PD has no explicit "lifetime" or "lease length" of 5457 its own. When the valid lifetimes of all of the prefixes in a IA_PD 5458 have expired, the IA_PD can be considered as having expired. T1 and 5459 T2 fields are included to give the server explicit control over when 5460 a client should contact the server about a specific IA_PD. 5462 In a message sent by a client to a server, the T1 and T2 fields 5463 SHOULD be set to 0. The server MUST ignore any values in these 5464 fields in messages received from a client. 5466 In a message sent by a server to a client, the client MUST use the 5467 values in the T1 and T2 fields for the T1 and T2 timers, unless those 5468 values in those fields are 0. The values in the T1 and T2 fields are 5469 the number of seconds until T1 and T2. 5471 The server selects the T1 and T2 times to allow the client to extend 5472 the lifetimes of any prefixes in the IA_PD before the lifetimes 5473 expire, even if the server is unavailable for some short period of 5474 time. Recommended values for T1 and T2 are .5 and .8 times the 5475 shortest preferred lifetime of the prefixes in the IA_PD that the 5476 server is willing to extend, respectively. If the time at which the 5477 prefixes in an IA_PD are to be renewed is to be left to the 5478 discretion of the client, the server sets T1 and T2 to 0. The client 5479 MUST follow the rules defined in Section 14.2. 5481 If a client receives an IA_PD with T1 greater than T2, and both T1 5482 and T2 are greater than 0, the client discards the IA_PD option and 5483 processes the remainder of the message as though the server had not 5484 included the IA_PD option. 5486 21.22. IA Prefix Option 5488 The IA Prefix option is used to specify a prefix associated with an 5489 IA_PD. The IA Prefix option must be encapsulated in the IA_PD- 5490 options field of an IA_PD option (see Section 21.21). 5492 0 1 2 3 5493 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 5494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5495 | OPTION_IAPREFIX | option-length | 5496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5497 | preferred-lifetime | 5498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5499 | valid-lifetime | 5500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5501 | prefix-length | | 5502 +-+-+-+-+-+-+-+-+ IPv6-prefix | 5503 | (16 octets) | 5504 | | 5505 | | 5506 | | 5507 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5508 | | . 5509 +-+-+-+-+-+-+-+-+ . 5510 . IAprefix-options . 5511 . . 5512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5514 Figure 36: IA Prefix Option Format 5516 option-code OPTION_IAPREFIX (26). 5518 option-length 25 + length of IAprefix-options field. 5520 preferred-lifetime The preferred lifetime for the prefix in the 5521 option, expressed in units of seconds. A 5522 value of 0xFFFFFFFF represents "infinity" 5523 (see Section 7.7. A four octets long field 5524 containing an unsigned integer. 5526 valid-lifetime The valid lifetime for the prefix in the 5527 option, expressed in units of seconds. A 5528 value of 0xFFFFFFFF represents "infinity". A 5529 four octets long field containing an unsigned 5530 integer. 5532 prefix-length Length for this prefix in bits. A one-octet 5533 unsigned integer. 5535 IPv6-prefix An IPv6 prefix. A 16 octets long field. 5537 IAprefix-options Options associated with this prefix. A 5538 variable length field (25 octets less than 5539 the value in the option-len field). 5541 In a message sent by a client to a server, the preferred and valid 5542 lifetime fields SHOULD be set to 0. The server MUST ignore any 5543 received values in these lifetime fields. 5545 The client SHOULD NOT send an IA Prefix option with 0 in the prefix- 5546 length field (and an unspecified value (::) in the IPv6-prefix 5547 field). A client MAY send a non-zero value in the prefix-length 5548 field and the unspecified value (::) in the IPv6-prefix field to 5549 indicate a preference for the size of the prefix to be delegated. 5550 See [RFC8168] for further details on prefix length hints. 5552 The client MUST discard any prefixes for which the preferred lifetime 5553 is greater than the valid lifetime. 5555 The values in the preferred and valid lifetimes are the number of 5556 seconds remaining for each lifetime. See Section 18.2.10.1 for more 5557 details on how these values are used for delegated prefixes. 5559 As per Section 7.7, the preferred and valid lifetime values of 5560 0xffffffff is taken to mean "infinity" and should be used carefully. 5562 An IA Prefix option may appear only in an IA_PD option. More than 5563 one IA Prefix option can appear in a single IA_PD option. 5565 The status of any operations involving this IA Prefix option is 5566 indicated in a Status Code option (see Section 21.3) in the IAprefix- 5567 options field. 5569 21.23. Information Refresh Time Option 5571 This option is requested by clients and returned by servers to 5572 specify an upper bound for how long a client should wait before 5573 refreshing information retrieved from a DHCP server. It is only used 5574 in Reply messages in response to Information-request messages. In 5575 other messages there will usually be other information that indicates 5576 when the client should contact the server, e.g., T1/T2 times and 5577 lifetimes. This option is useful when the configuration parameters 5578 change or during renumbering event as clients running in the 5579 stateless mode will be able to update their configuration. 5581 The format of the Information Refresh Time option is: 5583 0 1 2 3 5584 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 5585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5586 |OPTION_INFORMATION_REFRESH_TIME| option-len | 5587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5588 | information-refresh-time | 5589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5591 Figure 37: Information Refresh Time Option Format 5593 option-code OPTION_INFORMATION_REFRESH_TIME (32). 5595 option-len 4. 5597 information-refresh-time Time duration relative to the current 5598 time, expressed in units of seconds. A four 5599 octets long field containing an unsigned 5600 integer. 5602 A DHCP client MUST request this option in the Option Request option 5603 (see Section 21.7) when sending Information-request messages. A 5604 client MUST NOT request this option in the Option Request option in 5605 any other messages. 5607 A server sending a Reply to an Information-request message SHOULD 5608 include this option if it is requested in the Option Request option 5609 of the Information-request. The option value MUST NOT be smaller 5610 than IRT_MINIMUM. This option MUST only appear in the top-level 5611 option area of Reply messages. 5613 If the Reply to an Information-request message does not contain this 5614 option, the client MUST behave as if the option with value 5615 IRT_DEFAULT was provided. 5617 A client MUST use the refresh time IRT_MINIMUM if it receives the 5618 option with a value less than IRT_MINIMUM. 5620 As per Section 7.7, the value 0xffffffff is taken to mean "infinity" 5621 and implies that the client should not refresh its configuration data 5622 without some other trigger (such as detecting movement to a new 5623 link). 5625 If a client contacts the server to obtain new data or refresh some 5626 existing data before the refresh time expires, then it SHOULD also 5627 refresh all data covered by this option. 5629 When the client detects that the refresh time has expired, it SHOULD 5630 try to update its configuration data by sending an Information- 5631 Request as specified in Section 18.2.6, except that the client MUST 5632 delay sending the first Information-request by a random amount of 5633 time between 0 and INF_MAX_DELAY. 5635 A client MAY have a maximum value for the refresh time, where that 5636 value is used whenever the client receives this option with a value 5637 higher than the maximum. This also means that the maximum value is 5638 used when the received value is "infinity". A maximum value might 5639 make the client less vulnerable to attacks based on forged DHCP 5640 messages. Without a maximum value, a client may be made to use wrong 5641 information for a possibly infinite period of time. There may 5642 however be reasons for having a very long refresh time, so it may be 5643 useful for this maximum value to be configurable. 5645 21.24. SOL_MAX_RT Option 5647 A DHCP server sends the SOL_MAX_RT option to a client to override the 5648 default value of SOL_MAX_RT. The value of SOL_MAX_RT in the option 5649 replaces the default value defined in Section 7.6. One use for the 5650 SOL_MAX_RT option is to set a longer value for SOL_MAX_RT, which 5651 reduces the Solicit traffic from a client that has not received a 5652 response to its Solicit messages. 5654 The format of the SOL_MAX_RT option is: 5656 0 1 2 3 5657 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 5658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5659 | option-code | option-len | 5660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5661 | SOL_MAX_RT value | 5662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5664 Figure 38: SOL_MAX_RT Option Format 5666 option-code OPTION_SOL_MAX_RT (82). 5668 option-len 4. 5670 SOL_MAX_RT value Overriding value for SOL_MAX_RT in seconds; 5671 MUST be in range: 60 <= "value" <= 86400 (1 5672 day). A four octets long field containing an 5673 unsigned integer. 5675 A DHCP client MUST include the SOL_MAX_RT option code in any Option 5676 Request option (see Section 21.7) it sends in a Solicit message. 5678 The DHCP server MAY include the SOL_MAX_RT option in any response it 5679 sends to a client that has included the SOL_MAX_RT option code in an 5680 Option Request option. The SOL_MAX_RT option is sent as a top-level 5681 option in the message to the client. 5683 A DHCP client MUST ignore any SOL_MAX_RT option values that are less 5684 than 60 or more than 86400. 5686 If a DHCP client receives a message containing a SOL_MAX_RT option 5687 that has a valid value for SOL_MAX_RT, the client MUST set its 5688 internal SOL_MAX_RT parameter to the value contained in the 5689 SOL_MAX_RT option. This value of SOL_MAX_RT is then used by the 5690 retransmission mechanism defined in Section 15 and Section 18.2.1. 5692 The purpose of this mechanism is to give network administrator a way 5693 to avoid large DHCP traffic if all DHCP servers become unavailable. 5694 Therefore this value is expected to be retained for as long as 5695 practically possible. 5697 Updated SOL_MAX_RT value applies only to the network interface on 5698 which the client received SOL_MAX_RT option. 5700 21.25. INF_MAX_RT Option 5702 A DHCP server sends the INF_MAX_RT option to a client to override the 5703 default value of INF_MAX_RT. The value of INF_MAX_RT in the option 5704 replaces the default value defined in Section 7.6. One use for the 5705 INF_MAX_RT option is to set a longer value for INF_MAX_RT, which 5706 reduces the Information-request traffic from a client that has not 5707 received a response to its Information-request messages. 5709 The format of the INF_MAX_RT option is: 5711 0 1 2 3 5712 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 5713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5714 | option-code | option-len | 5715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5716 | INF_MAX_RT value | 5717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5719 Figure 39: INF_MAX_RT Option Format 5721 option-code OPTION_INF_MAX_RT (83). 5723 option-len 4. 5725 INF_MAX_RT value Overriding value for INF_MAX_RT in seconds; 5726 MUST be in range: 60 <= "value" <= 86400 (1 5727 day). A four octets long field containing an 5728 unsigned integer. 5730 A DHCP client MUST include the INF_MAX_RT option code in any Option 5731 Request option (see Section 21.7) it sends in an Information-request 5732 message. 5734 The DHCP server MAY include the INF_MAX_RT option in any response it 5735 sends to a client that has included the INF_MAX_RT option code in an 5736 Option Request option. The INF_MAX_RT option is a top-level option 5737 in the message to the client. 5739 A DHCP client MUST ignore any INF_MAX_RT option values that are less 5740 than 60 or more than 86400. 5742 If a DHCP client receives a message containing an INF_MAX_RT option 5743 that has a valid value for INF_MAX_RT, the client MUST set its 5744 internal INF_MAX_RT parameter to the value contained in the 5745 INF_MAX_RT option. This value of INF_MAX_RT is then used by the 5746 retransmission mechanism defined in Section 15 and Section 18.2.6. 5748 Updated INF_MAX_RT value applies only to the network interface on 5749 which the client received INF_MAX_RT option. 5751 22. Security Considerations 5753 This section discusses security considerations that are not related 5754 to privacy. For dedicated privacy discussion, see Section 23. 5756 The threat to DHCP is inherently an insider threat (assuming a 5757 properly configured network where DHCP ports are blocked on the 5758 perimeter gateways of the enterprise). Regardless of the gateway 5759 configuration, however, the potential attacks by insiders and 5760 outsiders are the same. 5762 DHCP lacks end-to-end encryption between clients and servers, thus 5763 hijacking, tampering, and eavesdropping attacks are all possible as a 5764 result. Some network environments (discussed below) can be secured 5765 through various means to minimize these attacks. 5767 One attack specific to a DHCP client is the establishment of a 5768 malicious server with the intent of providing incorrect configuration 5769 information to the client. The motivation for doing so may be to 5770 mount a "man in the middle" attack that causes the client to 5771 communicate with a malicious server instead of a valid server for 5772 some service such as DNS or NTP. The malicious server may also mount 5773 a denial of service attack through misconfiguration of the client 5774 that causes all network communication from the client to fail. 5776 A malicious DHCP server might cause a client to set its SOL_MAX_RT 5777 and INF_MAX_RT parameters to an unreasonably high value with the 5778 SOL_MAX_RT (see Section 21.24) and INF_MAX_RT (see Section 21.25) 5779 options, which may cause an undue delay in a client completing its 5780 DHCP protocol transaction in the case no other valid response is 5781 received. Assuming the client also receives a response from a valid 5782 DHCP server, large values for SOL_MAX_RT and INF_MAX_RT will not have 5783 any effect. 5785 A malicious server can also send a Server Unicast option (see 5786 Section 21.12) to a client in an Advertise message, thus potentially 5787 causing the client to bypass relays and communicate only with the 5788 malicious server for subsequent Request and Renew messages. 5790 There is another threat to DHCP clients from mistakenly or 5791 accidentally configured DHCP servers that answer DHCP client requests 5792 with unintentionally incorrect configuration parameters. 5794 A DHCP client may also be subject to attack through the receipt of a 5795 Reconfigure message from a malicious server that causes the client to 5796 obtain incorrect configuration information from that server. Note 5797 that although a client sends its response (Renew, Rebind, or 5798 Information-request message) through a relay agent and, therefore, 5799 that response will only be received by servers to which DHCP messages 5800 are relayed, a malicious server could send a Reconfigure message to a 5801 client, followed (after an appropriate delay) by a Reply message that 5802 would be accepted by the client. Thus, a malicious server that is 5803 not on the network path between the client and the server may still 5804 be able to mount a Reconfigure attack on a client. The use of 5805 transaction IDs that are cryptographically sound and cannot easily be 5806 predicted will also reduce the probability that such an attack will 5807 be successful. 5809 Because of the opportunity for attack through the Reconfigure 5810 message, a DHCP client MUST discard any Reconfigure message that does 5811 not include authentication or that does not pass the validation 5812 process for the authentication protocol. 5814 The Reconfigure Key protocol described in Section 20.4 provides 5815 protection against the use of a Reconfigure message by a malicious 5816 DHCP server to mount a denial of service or man-in-the-middle attack 5817 on a client. This protocol can be compromised by an attacker that 5818 can intercept the initial message in which the DHCP server sends the 5819 key "in plain text" to the client. 5821 Many of these rogue server attacks can be mitigated by making use of 5822 the mechanism described in [RFC7610] and [RFC7513]. 5824 The threat specific to a DHCP server is an invalid client 5825 masquerading as a valid client. The motivation for this may be for 5826 theft of service, or to circumvent auditing for any number of 5827 nefarious purposes. 5829 The threat common to both the client and the server is the resource 5830 "denial of service" (DoS) attack. These attacks typically involve 5831 the exhaustion of available assigned address or delegatable prefixes, 5832 or the exhaustion of CPU or network bandwidth, and are present 5833 anytime there is a shared resource. Some forms of these exhaustion 5834 attacks can be partially mitigated by appropriate server policy, 5835 e.g., limiting the maximum number of leases any one client can get. 5837 The messages exchanged between relay agents and servers may be used 5838 to mount a "man in the middle" or denial of service attack. 5839 Communication between a server and a relay agent, and communication 5840 between relay agents, can be authenticated and encrypted through the 5841 use of IPsec, as described in [RFC8213]. 5843 However, the use of manually configured pre-shared keys for IPsec 5844 between relay agents and servers does not defend against replayed 5845 DHCP messages. Replayed messages can represent a DOS attack through 5846 exhaustion of processing resources, but not through mis-configuration 5847 or exhaustion of other resources such as assignable address and 5848 delegatable prefixes. 5850 Various network environments also offer levels of security if 5851 deployed as described below. 5853 - In enterprise and factory networks, use of [IEEE-802.1x] 5854 authentication can prevent unknown or untrusted clients from 5855 connecting to the network. However, this does not necessarily 5856 assure that the connected client will be a good DHCP or network 5857 actor. 5859 - For wired networks where clients typically are connected to a 5860 switch port, snooping DHCP multicast (or unicast traffic) becomes 5861 difficult as the switches limit the traffic delivered to a port. 5862 The client's DHCP multicast packets (with destination address 5863 fe02::1:2) are only forwarded to the DHCP server's (or relay's) 5864 switch port - not all ports. And the server's (or relay's) 5865 unicast replies are only delivered to the target client's port - 5866 not all ports. 5868 - In public networks (such as a WiFi network in a coffee shop or 5869 airport), it is possible for others within radio range to snoop 5870 DHCP and other traffic. But in these environments, there is very 5871 little if anything that can be learned from the DHCP traffic 5872 itself (either from client to server, or server to client) if the 5873 privacy considerations (see Section 23) are followed. For devices 5874 that do not follow the privacy considerations, there is also 5875 little that can be learned that would not be available from 5876 subsequent communications anyway (such as the device's mac- 5877 address). Or, that cannot be inferred by the bad actor initiating 5878 a DHCP request itself (since all clients will typically receive 5879 similar configuration details). As mentioned above, one threat is 5880 that the RKAP key for a client can be learned (if the initial 5881 Solicit / Advertise / Request / Reply exchange is monitored) and 5882 trigger a premature reconfiguration - but this is relatively easy 5883 to prevent by disallowing direct client-to-client communication on 5884 these networks or using [RFC7610] and [RFC7513]. 5886 23. Privacy Considerations 5888 This section focuses on the server considerations. For extended 5889 discussion about privacy considerations for the client, see 5890 [RFC7824]. In particular, Section 3 of that document discusses 5891 various identifiers that could be misused to track the client. 5892 Section 4 discusses existing mechanisms that may have an impact on 5893 client's privacy. Finally, Section 5 discusses potential attack 5894 vectors. For recommendations how to address or mitigate those 5895 issues, see [RFC7844]. 5897 This specification does not define any allocation strategies. 5898 Implementers are expected to develop their own algorithm for the 5899 server to choose a resource out of the available pool. Several 5900 possible allocation strategies are mentioned in Section 4.3 of 5902 [RFC7824]. Please keep in mind that this list is not exhaustive and 5903 there are certainly other possible strategies. Readers are also 5904 encouraged to read [RFC7707], in particular Section 4.1.2 that 5905 discusses the problems with certain allocation strategies. 5907 24. IANA Considerations 5909 This document does not define any new DHCP name spaces or 5910 definitions. 5912 The publication of this document does not change the assignment rules 5913 for new values for message types, option codes, DUID types or status 5914 codes. 5916 The list of assigned values used in DHCPv6 is available at 5917 https://www.iana.org/assignments/dhcpv6-parameters 5919 IANA is requested to update the https://www.iana.org/assignments/ 5920 dhcpv6-parameters page to add a reference to this document for 5921 definitions previously created by [RFC3315], [RFC3633], [RFC4242] and 5922 [RFC7083]. 5924 IANA is requested to add two columns to the DHCPv6 Option table at 5925 https://www.iana.org/assignments/dhcpv6-parameters to indicate which 5926 options are allowed to appear in a client's Option Request option 5927 (see Section 21.7) and which options are singleton options (only 5928 allowed to appear once as a top-level or encapsulated option - see 5929 Section 16 of [RFC7227]). Table 4 provides the data for the options 5930 assigned by IANA at the time of writing. 5932 +-------+-------------------------+---------------------+-----------+ 5933 | Optio | Option Name (OPTION | Client ORO (1) | Singleton | 5934 | n | prefix removed) | | Option | 5935 +-------+-------------------------+---------------------+-----------+ 5936 | 1 | CLIENTID | No | Yes | 5937 | 2 | SERVERID | No | Yes | 5938 | 3 | IA_NA | No | No | 5939 | 4 | IA_TA | No | No | 5940 | 5 | IAADDR | No | No | 5941 | 6 | ORO | No | Yes | 5942 | 7 | PREFERENCE | No | Yes | 5943 | 8 | ELAPSED_TIME | No | Yes | 5944 | 9 | RELAY_MSG | No | Yes | 5945 | 11 | AUTH | No | Yes | 5946 | 12 | UNICAST | No | Yes | 5947 | 13 | STATUS_CODE | No | Yes | 5948 | 14 | RAPID_COMMIT | No | Yes | 5949 | 15 | USER_CLASS | No | Yes | 5950 | 16 | VENDOR_CLASS | No | No (2) | 5951 | 17 | VENDOR_OPTS | Optional | No (2) | 5952 | 18 | INTERFACE_ID | No | Yes | 5953 | 19 | RECONF_MSG | No | Yes | 5954 | 20 | RECONF_ACCEPT | No | Yes | 5955 | 21 | SIP_SERVER_D | Yes | Yes | 5956 | 22 | SIP_SERVER_A | Yes | Yes | 5957 | 23 | DNS_SERVERS | Yes | Yes | 5958 | 24 | DOMAIN_LIST | Yes | Yes | 5959 | 25 | IA_PD | No | No | 5960 | 26 | IAPREFIX | No | No | 5961 | 27 | NIS_SERVERS | Yes | Yes | 5962 | 28 | NISP_SERVERS | Yes | Yes | 5963 | 29 | NIS_DOMAIN_NAME | Yes | Yes | 5964 | 30 | NISP_DOMAIN_NAME | Yes | Yes | 5965 | 31 | SNTP_SERVERS | Yes | Yes | 5966 | 32 | INFORMATION_REFRESH_TIM | Required for | Yes | 5967 | | E | Information-request | | 5968 | 33 | BCMCS_SERVER_D | Yes | Yes | 5969 | 34 | BCMCS_SERVER_A | Yes | Yes | 5970 | 36 | GEOCONF_CIVIC | Yes | Yes | 5971 | 37 | REMOTE_ID | No | Yes | 5972 | 38 | SUBSCRIBER_ID | No | Yes | 5973 | 39 | CLIENT_FQDN | Yes | Yes | 5974 | 40 | PANA_AGENT | Yes | Yes | 5975 | 41 | NEW_POSIX_TIMEZONE | Yes | Yes | 5976 | 42 | NEW_TZDB_TIMEZONE | Yes | Yes | 5977 | 43 | ERO | No | Yes | 5978 | 44 | LQ_QUERY | No | Yes | 5979 | 45 | CLIENT_DATA | No | Yes | 5980 | 46 | CLT_TIME | No | Yes | 5981 | 47 | LQ_RELAY_DATA | No | Yes | 5982 | 48 | LQ_CLIENT_LINK | No | Yes | 5983 | 49 | MIP6_HNIDF | Yes | Yes | 5984 | 50 | MIP6_VDINF | Yes | Yes | 5985 | 51 | V6_LOST | Yes | Yes | 5986 | 52 | CAPWAP_AC_V6 | Yes | Yes | 5987 | 53 | RELAY_ID | No | Yes | 5988 | 54 | IPv6_Address-MoS | Yes | Yes | 5989 | 55 | IPv6_FQDN-MoS | Yes | Yes | 5990 | 56 | NTP_SERVER | Yes | Yes | 5991 | 57 | V6_ACCESS_DOMAIN | Yes | Yes | 5992 | 58 | SIP_UA_CS_LIST | Yes | Yes | 5993 | 59 | OPT_BOOTFILE_URL | Yes | Yes | 5994 | 60 | OPT_BOOTFILE_PARAM | Yes | Yes | 5995 | 61 | CLIENT_ARCH_TYPE | No | Yes | 5996 | 62 | NII | Yes | Yes | 5997 | 63 | GEOLOCATION | Yes | Yes | 5998 | 64 | AFTR_NAME | Yes | Yes | 5999 | 65 | ERP_LOCAL_DOMAIN_NAME | Yes | Yes | 6000 | 66 | RSOO | No | Yes | 6001 | 67 | PD_EXCLUDE | Yes | Yes | 6002 | 68 | VSS | No | Yes | 6003 | 69 | MIP6_IDINF | Yes | Yes | 6004 | 70 | MIP6_UDINF | Yes | Yes | 6005 | 71 | MIP6_HNP | Yes | Yes | 6006 | 72 | MIP6_HAA | Yes | Yes | 6007 | 73 | MIP6_HAF | Yes | Yes | 6008 | 74 | RDNSS_SELECTION | Yes | No | 6009 | 75 | KRB_PRINCIPAL_NAME | Yes | Yes | 6010 | 76 | KRB_REALM_NAME | Yes | Yes | 6011 | 77 | KRB_DEFAULT_REALM_NAME | Yes | Yes | 6012 | 78 | KRB_KDC | Yes | Yes | 6013 | 79 | CLIENT_LINKLAYER_ADDR | No | Yes | 6014 | 80 | LINK_ADDRESS | No | Yes | 6015 | 81 | RADIUS | No | Yes | 6016 | 82 | SOL_MAX_RT | Required for | Yes | 6017 | | | Solicit | | 6018 | 83 | INF_MAX_RT | Required for | Yes | 6019 | | | Information-request | | 6020 | 84 | ADDRSEL | Yes | Yes | 6021 | 85 | ADDRSEL_TABLE | Yes | Yes | 6022 | 86 | V6_PCP_SERVER | Yes | No | 6023 | 87 | DHCPV4_MSG | No | Yes | 6024 | 88 | DHCP4_O_DHCP6_SERVER | Yes | Yes | 6025 | 89 | S46_RULE | No | No (3) | 6026 | 90 | S46_BR | No | No | 6027 | 91 | S46_DMR | No | Yes | 6028 | 92 | S46_V4V6BIND | No | Yes | 6029 | 93 | S46_PORTPARAMS | No | Yes | 6030 | 94 | S46_CONT_MAPE | Yes | No | 6031 | 95 | S46_CONT_MAPT | Yes | Yes | 6032 | 96 | S46_CONT_LW | Yes | Yes | 6033 | 97 | 4RD | Yes | Yes | 6034 | 98 | 4RD_MAP_RULE | Yes | Yes | 6035 | 99 | 4RD_NON_MAP_RULE | Yes | Yes | 6036 | 100 | LQ_BASE_TIME | No | Yes | 6037 | 101 | LQ_START_TIME | No | Yes | 6038 | 102 | LQ_END_TIME | No | Yes | 6039 | 103 | DHCP Captive-Portal | Yes | Yes | 6040 | 104 | MPL_PARAMETERS | Yes | Yes | 6041 | 105 | ANI_ATT | No | Yes | 6042 | 106 | ANI_NETWORK_NAME | No | Yes | 6043 | 107 | ANI_AP_NAME | No | Yes | 6044 | 108 | ANI_AP_BSSID | No | Yes | 6045 | 109 | ANI_OPERATOR_ID | No | Yes | 6046 | 110 | ANI_OPERATOR_REALM | No | Yes | 6047 | 111 | S46_PRIORITY | Yes | Yes | 6048 | 112 | MUD_URL_V6 (TEMPORARY) | No | Yes | 6049 | 113 | V6_PREFIX64 | Yes | No | 6050 | 114 | F_BINDING_STATUS | No | Yes | 6051 | 115 | F_CONNECT_FLAGS | No | Yes | 6052 | 116 | F_DNS_REMOVAL_INFO | No | Yes | 6053 | 117 | F_DNS_HOST_NAME | No | Yes | 6054 | 118 | F_DNS_ZONE_NAME | No | Yes | 6055 | 119 | F_DNS_FLAGS | No | Yes | 6056 | 120 | F_EXPIRATION_TIME | No | Yes | 6057 | 121 | F_MAX_UNACKED_BNDUPD | No | Yes | 6058 | 122 | F_MCLT | No | Yes | 6059 | 123 | F_PARTNER_LIFETIME | No | Yes | 6060 | 124 | F_PARTNER_LIFETIME_SENT | No | Yes | 6061 | 125 | F_PARTNER_DOWN_TIME | No | Yes | 6062 | 126 | F_PARTNER_RAW_CLT_TIME | No | Yes | 6063 | 127 | F_PROTOCOL_VERSION | No | Yes | 6064 | 128 | F_KEEPALIVE_TIME | No | Yes | 6065 | 129 | F_RECONFIGURE_DATA | No | Yes | 6066 | 130 | F_RELATIONSHIP_NAME | No | Yes | 6067 | 131 | F_SERVER_FLAGS | No | Yes | 6068 | 132 | F_SERVER_STATE | No | Yes | 6069 | 133 | F_START_TIME_OF_STATE | No | Yes | 6070 | 134 | F_STATE_EXPIRATION_TIME | No | Yes | 6071 | 135 | RELAY_PORT | No | Yes | 6072 | 143 | IPv6_ADDRESS-ANDSF | Yes | Yes | 6073 +-------+-------------------------+---------------------+-----------+ 6075 Table 4: Updated Options Table 6077 Notes for Table 4: 6079 (1) For the "Client ORO" column: a "Yes" for an option means that 6080 the client includes this option code in the Option Request 6081 option (see Section 21.7) if it desires that configuration 6082 information; a "No" means that the option MUST NOT be included 6083 (and servers SHOULD silently ignore that option code if it 6084 appears in a client's Option Request option). 6086 (2) For each enterprise-number, there MUST only be a single 6087 instance. 6089 (3) See [RFC7598] for details. 6091 IANA is requested to correct the range of possible Status Codes in 6092 the Status Codes table at https://www.iana.org/assignments/ 6093 dhcpv6-parameters by replacing 23-255 (as Unassigned) with 23-65535 6094 (the codes are 16-bit unsigned integers). 6096 IANA is requested to update the All_DHCP_Relay_Agents_and_Servers 6097 (ff02::1:2) and All_DHCP_Servers (ff05::1:3) table entries in the 6098 IPv6 multicast address space registry at 6099 https://www.iana.org/assignments/ipv6-multicast-addresses to 6100 reference this document instead of [RFC3315]. 6102 IANA is requested to add an "Obsolete" annotation into the "DHCPv6 6103 Delayed Authentication" entry in the "Authentication Suboption (value 6104 8) - Protocol identifier values" registry at 6105 https://www.iana.org/assignments/bootp-dhcp-parameters, and to add an 6106 "Obsolete" annotation into the "Delayed Authentication" entity in the 6107 "Protocol Name Space Values" registry at 6108 https://www.iana.org/assignments/auth-namespaces. IANA is also 6109 requested to update these pages to reference this document instead of 6110 [RFC3315]. 6112 IANA is requested to add a reference to this document for the RDM 6113 value of 0 to the "RDM Name Space Values" registry at 6114 https://www.iana.org/assignments/auth-namespaces. 6116 IANA is requested to update the "Service Name and Transport Protocol 6117 Port Number Registry" at https://www.iana.org/assignments/service- 6118 names-port-numbers as follows: 6120 546/udp - Add a reference to this document. 6122 547/udp - Add a reference to this document. 6124 547/tcp - Add a reference to [RFC5460]. 6126 647/tcp - Add a reference to [RFC8156]. 6128 25. Obsoleted Mechanisms 6130 This specification is mostly a corrected and cleaned up version of 6131 the original specification, [RFC3315], along with numerous additions 6132 from later RFCs. However, there are a small number of mechanisms 6133 that were not widely deployed, were underspecified or had other 6134 operational issues. Those mechanisms are now considered deprecated. 6135 Legacy implementations MAY support them, but implementations 6136 conformant to this document MUST NOT rely on them. 6138 The following mechanisms are now obsolete: 6140 Delayed Authentication. This mechanism was underspecified and had 6141 significant operational burden. As a result, after 10 years its 6142 adoption was extremely limited at best. 6144 Lifetime hints sent by a client. Clients used to be allowed to send 6145 lifetime values as hints. This mechanism was not widely implemented 6146 and there were known misimplementations that sent the remaining 6147 lifetimes rather than total desired lifetimes. That in turn was 6148 sometimes misunderstood by servers as a request for ever decreasing 6149 lease lifetimes, which caused issues when values started approaching 6150 zero. Clients now SHOULD set lifetimes to 0 in IA Address and IA 6151 Prefix options, and servers MUST ignore any requested lifetime value. 6153 T1/T2 hints sent by a client. These had similar issues to the 6154 lifetime hints. Clients now SHOULD set the T1/T2 values to 0 in 6155 IA_NA and IA_PD options, and servers MUST ignore any client supplied 6156 T1/T2 values. 6158 26. Acknowledgments 6160 This document is merely a refinement of earlier work by the authors 6161 of RFC3315 (Ralph Droms, Jim Bound, Bernie Volz, Ted Lemon, Charles 6162 Perkins, and Mike Carney), RFC3633 (Ole Troan and Ralph Droms), 6163 RFC3736 (Ralph Droms), RFC4242 (Stig Venaas, Tim Chown, and Bernie 6164 Volz), RFC7083 (Ralph Droms), and RFC7550 (Ole Troan, Bernie Volz, 6165 and Marcin Siodelski) and would not be possible without their 6166 original work. 6168 A number of additional people have contributed to identifying issues 6169 with RFC3315 and RFC3633 and proposed resolutions to these issues as 6170 reflected in this document (in no particular order): Ole Troan, 6171 Robert Marks, Leaf Yeh, Michelle Cotton, Pablo Armando, John 6172 Brzozowski, Suresh Krishnan, Hideshi Enokihara, Alexandru Petrescu, 6173 Yukiyo Akisada, Tatuya Jinmei, Fred Templin and Christian Huitema. 6175 We also thank the following, not otherwise acknowledged and in no 6176 particular order, for their review comments: Jeremy Reed, Francis 6177 Dupont, Tatuya Jinmei, Lorenzo Colitti, Tianxiang Li, Ian Farrer, 6178 Yogendra Pal, Kim Kinnear, Shawn Routhier, Tim Chown, Michayla 6179 Newcombe, Alissa Cooper, Allison Mankin, Adam Roach, Kyle Rose, Elwyn 6180 Davies, Eric Rescorla, Ben Campbell, Warren Kumari, and Kathleen 6181 Moriarty. 6183 And, special thanks to Ralph Droms for answering many questions 6184 related to the original RFC3315 and RFC3633 work and for shepherding 6185 this document through the IETF process. 6187 27. References 6189 27.1. Normative References 6191 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 6192 DOI 10.17487/RFC0768, August 1980, 6193 . 6195 [RFC1035] Mockapetris, P., "Domain names - implementation and 6196 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 6197 November 1987, . 6199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6200 Requirement Levels", BCP 14, RFC 2119, 6201 DOI 10.17487/RFC2119, March 1997, 6202 . 6204 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 6205 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 6206 2006, . 6208 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 6209 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 6210 DOI 10.17487/RFC4861, September 2007, 6211 . 6213 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 6214 Address Autoconfiguration", RFC 4862, 6215 DOI 10.17487/RFC4862, September 2007, 6216 . 6218 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 6219 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 6220 DOI 10.17487/RFC6221, May 2011, 6221 . 6223 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 6224 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 6225 DOI 10.17487/RFC6355, August 2011, 6226 . 6228 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 6229 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 6230 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 6231 . 6233 [RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 6234 Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014, 6235 . 6237 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 6238 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 6239 March 2017, . 6241 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 6242 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 6243 May 2017, . 6245 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 6246 (IPv6) Specification", STD 86, RFC 8200, 6247 DOI 10.17487/RFC8200, July 2017, 6248 . 6250 [RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged 6251 between Servers and Relay Agents", RFC 8213, 6252 DOI 10.17487/RFC8213, August 2017, 6253 . 6255 27.2. Informative References 6257 [IANA-HARDWARE-TYPES] 6258 IANA, "Hardware Types 6259 https://www.iana.org/assignments/arp-parameters". 6261 [IANA-PEN] 6262 IANA, "Private Enterprise Numbers registry 6263 https://www.iana.org/assignments/enterprise-numbers". 6265 [IANA-RESERVED-IID] 6266 IANA, "Reserved IPv6 Interface Identifiers 6267 https://www.iana.org/assignments/ipv6-interface-ids". 6269 [IEEE-802.1x] 6270 IEEE, "802.1X-2010 - IEEE Standard for Local and 6271 metropolitan area networks--Port-Based Network Access 6272 Control", February 2010, 6273 . 6276 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 6277 Converting Network Protocol Addresses to 48.bit Ethernet 6278 Address for Transmission on Ethernet Hardware", STD 37, 6279 RFC 826, DOI 10.17487/RFC0826, November 1982, 6280 . 6282 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 6283 RFC 2131, DOI 10.17487/RFC2131, March 1997, 6284 . 6286 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 6287 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 6288 . 6290 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 6291 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 6292 . 6294 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 6295 RFC 3162, DOI 10.17487/RFC3162, August 2001, 6296 . 6298 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 6299 C., and M. Carney, "Dynamic Host Configuration Protocol 6300 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 6301 2003, . 6303 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 6304 Host Configuration Protocol (DHCP) version 6", RFC 3633, 6305 DOI 10.17487/RFC3633, December 2003, 6306 . 6308 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 6309 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 6310 DOI 10.17487/RFC3646, December 2003, 6311 . 6313 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 6314 (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, 6315 April 2004, . 6317 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 6318 Delegation", RFC 3769, DOI 10.17487/RFC3769, June 2004, 6319 . 6321 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 6322 Configuration Option for DHCPv6", RFC 4075, 6323 DOI 10.17487/RFC4075, May 2005, 6324 . 6326 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 6327 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 6328 . 6330 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 6331 Time Option for Dynamic Host Configuration Protocol for 6332 IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November 6333 2005, . 6335 [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host 6336 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 6337 Issues", RFC 4477, DOI 10.17487/RFC4477, May 2006, 6338 . 6340 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 6341 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 6342 Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, 6343 . 6345 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 6346 Extensions for Stateless Address Autoconfiguration in 6347 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 6348 . 6350 [RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor 6351 Discovery On-Link Assumption Considered Harmful", 6352 RFC 4943, DOI 10.17487/RFC4943, September 2007, 6353 . 6355 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 6356 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 6357 DOI 10.17487/RFC4994, September 2007, 6358 . 6360 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 6361 "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, 6362 September 2007, . 6364 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 6365 RFC 5453, DOI 10.17487/RFC5453, February 2009, 6366 . 6368 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 6369 DOI 10.17487/RFC5460, February 2009, 6370 . 6372 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 6373 "Network Time Protocol Version 4: Protocol and Algorithms 6374 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 6375 . 6377 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 6378 RFC 6422, DOI 10.17487/RFC6422, December 2011, 6379 . 6381 [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. 6382 Troan, "Prefix Exclude Option for DHCPv6-based Prefix 6383 Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, 6384 . 6386 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 6387 "Default Address Selection for Internet Protocol Version 6 6388 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 6389 . 6391 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 6392 Network Renumbering Scenarios, Considerations, and 6393 Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, 6394 . 6396 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 6397 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 6398 May 2013, . 6400 [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT 6401 and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 6402 2013, . 6404 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 6405 Requirements for IPv6 Customer Edge Routers", RFC 7084, 6406 DOI 10.17487/RFC7084, November 2013, 6407 . 6409 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 6410 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 6411 February 2014, . 6413 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 6414 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 6415 RFC 7341, DOI 10.17487/RFC7341, August 2014, 6416 . 6418 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 6419 Weil, "IPv6 Home Networking Architecture Principles", 6420 RFC 7368, DOI 10.17487/RFC7368, October 2014, 6421 . 6423 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 6424 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 6425 Boundary in IPv6 Addressing", RFC 7421, 6426 DOI 10.17487/RFC7421, January 2015, 6427 . 6429 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 6430 Validation Improvement (SAVI) Solution for DHCP", 6431 RFC 7513, DOI 10.17487/RFC7513, May 2015, 6432 . 6434 [RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and 6435 Recommendations with Multiple Stateful DHCPv6 Options", 6436 RFC 7550, DOI 10.17487/RFC7550, May 2015, 6437 . 6439 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 6440 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 6441 Configuration of Softwire Address and Port-Mapped 6442 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 6443 . 6445 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 6446 Protecting against Rogue DHCPv6 Servers", BCP 199, 6447 RFC 7610, DOI 10.17487/RFC7610, August 2015, 6448 . 6450 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 6451 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 6452 . 6454 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 6455 Considerations for IPv6 Address Generation Mechanisms", 6456 RFC 7721, DOI 10.17487/RFC7721, March 2016, 6457 . 6459 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 6460 Considerations for DHCPv6", RFC 7824, 6461 DOI 10.17487/RFC7824, May 2016, 6462 . 6464 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 6465 Profiles for DHCP Clients", RFC 7844, 6466 DOI 10.17487/RFC7844, May 2016, 6467 . 6469 [RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP 6470 Configuration on the Basis of Network Topology", RFC 7969, 6471 DOI 10.17487/RFC7969, October 2016, 6472 . 6474 [RFC8156] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Protocol", 6475 RFC 8156, DOI 10.17487/RFC8156, June 2017, 6476 . 6478 [RFC8168] Li, T., Liu, C., and Y. Cui, "DHCPv6 Prefix-Length Hint 6479 Issues", RFC 8168, DOI 10.17487/RFC8168, May 2017, 6480 . 6482 [TR-187] Broadband Forum, "TR-187 - IPv6 for PPP Broadband Access", 6483 February 2013, . 6486 Appendix A. Summary of Changes 6488 This appendix provides a summary of the significant changes made to 6489 this updated DHCPv6 specification. 6491 1. The Introduction Section 1 was reorganized and updated. In 6492 particular, the client/server message exchanges were moved into 6493 a new (and expanded) section on their own (see Section 5). And, 6494 new sections were added to discuss the relation to previous 6495 DHCPv6 documents and also to DHCPv4. 6497 2. The Requirements Section 2 and Background Section 3 had very 6498 minor edits. 6500 3. The Terminology Section 4 had minor edits. 6502 4. The DHCP Terminology Section 4.2 was expanded to incorporate 6503 definitions from RFC3633, add T1/T2 definitions, add a few new 6504 definitions useful in a document that combined address and 6505 prefix delegation assignments, and improve some existing 6506 definitions. 6508 5. The Client-Server Exchanges Section 5 was added from material 6509 previously in the Introduction Section 1 of RFC3315 and was 6510 expanded. 6512 6. The Operational Models Section 6 is new and provides information 6513 on the kinds of DHCP clients and how they operate. 6515 7. The DHCP Constants Section 7 was primarily updated to add 6516 constants from RFC4242 and RFC7083. Note that the 6517 HOP_COUNT_LIMIT was reduced from 32 to 8. 6519 8. The Client/Server Message Formats Section 8, Relay Agent/Server 6520 Message Formats Section 9, and Representation and Use of Domain 6521 Names Section 10 had only very minor changes. 6523 9. The DHCP Unique Identifier (DUID) Section 11 now discourages, 6524 rather than disallows, a server to parse the DUID, now includes 6525 some information on the DUID-UUID (RFC6355), and has other minor 6526 edits. 6528 10. The Identity Association Section 12 was expanded to better 6529 explain the concept and also included prefix delegation. 6531 11. The Assignment to an IA Section 13 incorporates material from 6532 two sections (11 and 12) of RFC3315 and also includes a section 6533 on prefix delegation. 6535 12. The Transmission of Messages by a Client Section 14 was expanded 6536 to include rate limiting by clients and how clients should 6537 handle T1 or T2 values of 0. 6539 13. The Reliability of Client Initiated Message Exchanges Section 15 6540 was expanded to clarify that the Elapsed Time option must be 6541 updated in retransmitted messages and that a client is not 6542 required to listen for DHCP traffic for the entire 6543 retransmission period. 6545 14. The Message Validation Section 16 had minor edits. 6547 15. The Client Source Address and Interface Selection Section 17 was 6548 expanded to include prefix delegation. 6550 16. The DHCP Configuration Exchanges Section 18 consolidates what 6551 used to be in the RFC3315 DHCP Server Solicitation Section 17, 6552 DHCP Client-Initiated Configuration Exchange Section 18, and 6553 DHCP Server-Initiated Configuration Exchange Section 19. This 6554 material was reorganized and enhanced, and incorporates prefix 6555 delegation from RFC3633 and other changes from RFC4242, RFC7083, 6556 and RFC7550. A few changes of note: 6558 1. The Option Request option is no longer optional for some 6559 messages (Solicit and Information-request) as RFC7083 6560 requires clients to request SOL_MAX_RT or INF_MAX_RT 6561 options. 6563 2. The Reconfigure message should no longer contain IA_NA/ 6564 IA_PD, ORO, or other options to indicate to the client what 6565 was reconfigured. The client should request everything it 6566 needs in the response to the Reconfigure. 6568 3. The lifetime and T1/T2 hints should not be sent by a client 6569 (it should send 0 values in these fields) and any non-zero 6570 values should be ignored by the server. 6572 4. Clarified that a server may return different addresses in 6573 the Reply than requested by a client in the Request message. 6574 Also clarified that a server must not include addresses that 6575 it will not assign. 6577 Also, a Refreshing Configuration Information Section 18.2.12 was 6578 added indicating use cases for when a client should try to 6579 refresh network information. 6581 17. The Relay Agent Behavior Section 19 incorporates [RFC7283] and 6582 had minor edits. A new section, Interaction between Relay 6583 Agents and Servers Section 19.4, was added. 6585 18. The Authentication of DHCP Messages Section 20 had significant 6586 changes: IPsec materials were mostly removed and replaced with a 6587 reference to [RFC8213], and the Delay Authentication Protocol 6588 was removed (see Section 25). Note that the Reconfigure Key 6589 Authentication Protocol is retained. 6591 19. The DHCP Options Section 21 was expanded to incorporate the 6592 prefix delegation options from RFC3633, the Information Refresh 6593 Time option from RFC4242, and the SOL_MAX_RT and INF_MAX_RT 6594 options from RFC7083. In addition, some additional edits were 6595 made to clarify option handling, such as which options should 6596 not be in an Option Request option. 6598 20. The Security Considerations Section 22 were updated to expand 6599 the discussion of security threats and incorporate material from 6600 the incorporated documents, primarily RFC3633. 6602 21. The new Privacy Considerations Section 23 was added to consider 6603 privacy issues. 6605 22. The IANA Considerations Section 24 was rewritten to reflect the 6606 changes requested for this document as other documents have 6607 already made the message, option, DUID, and status code 6608 assignments and this document does not add any new assignments. 6610 23. The new Obsoleted Mechanisms Section 25 documents what this 6611 specification obsoletes. 6613 24. The Appearance of Options in Message Types Appendix B and 6614 Appearance of Options in the Options Field of DHCP Appendix C 6615 were updated to reflect the incorporated options from RFC3633, 6616 RFC4242, and RFC7083. 6618 25. Where appropriate, informational references have been added to 6619 provide further background and guidance throughout the document 6620 (as can be noted by the vast increase in references). 6622 26. Changes were made to incorporate the following errata for 6623 [RFC3315]: Erratum IDs 294, 295, 1373, 1815, 2471, 2472, 2509, 6624 2928, 3577; [RFC3633]: Erratum IDs 248, 1880, 2468, 2469, 2470, 6625 3736; and [RFC3736]: Erratum ID 3796. 6627 27. General changes to other IPv6 specifications, such as removing 6628 the use of site-local unicast addresses and adding unique local 6629 addresses, were made to the document. Note that in a few 6630 places, older obsoleted RFCs (such as RFC2462 related to M and O 6631 bit handling) are still referenced as the material cited was not 6632 added in the replacement RFC. 6634 28. It should be noted that this document does not refer to all 6635 DHCPv6 functionality and specifications. Readers of this 6636 specification should visit https://www.iana.org/assignments/ 6637 dhcpv6-parameters and https://datatracker.ietf.org/wg/dhc/ to 6638 learn of the RFCs that define DHCPv6 messages, options, status- 6639 codes, and more. 6641 Appendix B. Appearance of Options in Message Types 6643 The following tables indicates with a "*" the options are allowed in 6644 each DHCP message type. 6646 These tables are informational and should they conflict with text 6647 earlier in this document, that text should be considered 6648 authoritative. 6650 Client Server IA_NA/ Elap. Relay Server 6651 ID ID IA_TA IA_PD ORO Pref Time Msg. Auth. Unicast 6652 Solicit * * * * * 6653 Advert. * * * * * 6654 Request * * * * * * 6655 Confirm * * * 6656 Renew * * * * * * 6657 Rebind * * * * * 6658 Decline * * * * * 6659 Release * * * * * 6660 Reply * * * * * * 6661 Reconf. * * * 6662 Inform. * (see note) * * 6663 R-forw. * 6664 R-repl. * 6666 NOTE: Server ID option (see Section 21.3) is only included in 6667 Information-request messages that are sent in response to a 6668 Reconfigure (see Section 18.2.6). 6670 Info 6671 Status Rap. User Vendor Vendor Inter. Recon. Recon. Refresh 6672 Code Comm. Class Class Spec. ID Msg. Accept Time 6673 Solicit * * * * * 6674 Advert. * * * * * 6675 Request * * * * 6676 Confirm * * * 6677 Renew * * * * 6678 Rebind * * * * 6679 Decline * * * 6680 Release * * * 6681 Reply * * * * * * * 6682 Reconf. * 6683 Inform. * * * * 6684 R-forw. * * 6685 R-repl. * * 6686 SOL_MAX_RT INF_MAX_RT 6687 Solicit 6688 Advert. * 6689 Request 6690 Confirm 6691 Renew 6692 Rebind 6693 Decline 6694 Release 6695 Reply * * 6696 Reconf. 6697 Inform. 6698 R-forw. 6699 R-repl. 6701 Appendix C. Appearance of Options in the Options Field of DHCP Options 6703 The following table indicates with a "*" where options defined in 6704 this document can appear as top-level options or encapsulated in 6705 other options defined in this document. Other RFC's may define 6706 additional situations where options defined in this document are 6707 encapsulated in other options. 6709 This table is informational and should it conflict with text earlier 6710 in this document, that text should be considered authoritative. 6712 Top- IA_NA/ RELAY- RELAY- 6713 Level IA_TA IAADDR IA_PD IAPREFIX FORW REPLY 6714 Client ID * 6715 Server ID * 6716 IA_NA/IA_TA * 6717 IAADDR * 6718 IA_PD * 6719 IAPREFIX * 6720 ORO * 6721 Preference * 6722 Elapsed Time * 6723 Relay Message * * 6724 Authentic. * 6725 Server Uni. * 6726 Status Code * * * 6727 Rapid Comm. * 6728 User Class * 6729 Vendor Class * 6730 Vendor Info. * * * 6731 Interf. ID * * 6732 Reconf. MSG. * 6733 Reconf. Accept * 6734 Info Refresh Time * 6735 SOL_MAX_RT * 6736 INF_MAX_RT * 6738 Notes: Options asterisked in the "Top-Level" column appear in the 6739 options field of client messages (see Section 8). Options asterisked 6740 in the "RELAY-FORW" / "RELAY-REPLY" column appear in the options 6741 field of the Relay-forward and Relay-reply messages (see Section 9). 6743 Authors' Addresses 6745 Tomek Mrugalski 6746 Internet Systems Consortium, Inc. 6747 950 Charter Street 6748 Redwood City, CA 94063 6749 USA 6751 Email: tomasz.mrugalski@gmail.com 6752 Marcin Siodelski 6753 Internet Systems Consortium, Inc. 6754 950 Charter Street 6755 Redwood City, CA 94063 6756 USA 6758 Email: msiodelski@gmail.com 6760 Bernie Volz 6761 Cisco Systems, Inc. 6762 1414 Massachusetts Ave 6763 Boxborough, MA 01719 6764 USA 6766 Email: volz@cisco.com 6768 Andrew Yourtchenko 6769 Cisco Systems, Inc. 6770 De Kleetlaan, 7 6771 Diegem B-1831 6772 Belgium 6774 Email: ayourtch@cisco.com 6776 Michael C. Richardson 6777 Sandelman Software Works 6778 470 Dawson Avenue 6779 Ottawa, ON K1Z 5V7 6780 CA 6782 Email: mcr+ietf@sandelman.ca 6783 URI: http://www.sandelman.ca/ 6785 Sheng Jiang 6786 Huawei Technologies Co., Ltd 6787 Q14, Huawei Campus, No.156 Beiqing Road 6788 Hai-Dian District, Beijing, 100095 6789 P.R. China 6791 Email: jiangsheng@huawei.com 6792 Ted Lemon 6793 Nominum, Inc. 6794 800 Bridge St. 6795 Redwood City, CA 94043 6796 USA 6798 Email: Ted.Lemon@nominum.com 6800 Timothy Winters 6801 University of New Hampshire, Interoperability Lab (UNH-IOL) 6802 Durham, NH 6803 USA 6805 Email: twinters@iol.unh.edu