idnits 2.17.1 draft-ietf-dhc-rfc3315bis-00.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC7083, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC3633, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC3736, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC3315, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 23, 2015) is 3319 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5226' is defined on line 5446, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7083 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 7283 (Obsoleted by RFC 8415) == Outdated reference: A later version (-09) exists of draft-ietf-dhc-topo-conf-04 -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration (DHC) T. Mrugalski, Ed. 3 Internet-Draft M. Siodelski 4 Obsoletes: 3315,3633,3736,7083 (if ISC 5 approved) B. Volz 6 Intended status: Standards Track A. Yourtchenko 7 Expires: September 24, 2015 Cisco 8 M. Richardson 9 SSW 10 S. Jiang 11 Huawei 12 T. Lemon 13 Nominum 14 March 23, 2015 16 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis 17 draft-ietf-dhc-rfc3315bis-00 19 Abstract 21 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP 22 servers to pass configuration parameters such as IPv6 network 23 addresses to IPv6 nodes. It offers the capability of automatic 24 allocation of reusable network addresses and additional configuration 25 flexibility. This protocol is a stateful counterpart to "IPv6 26 Stateless Address Autoconfiguration" (RFC 4862), and can be used 27 separately or concurrently with the latter to obtain configuration 28 parameters. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 24, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 6 77 1.1. Protocols and Addressing . . . . . . . . . . . . . . . . 7 78 1.2. Client-server Exchanges Involving Two Messages . . . . . 7 79 1.3. Client-server Exchanges Involving Four Messages . . . . . 8 80 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 81 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 4.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 10 84 4.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 11 85 5. Operational Models . . . . . . . . . . . . . . . . . . . . . 14 86 5.1. Stateless DHCP . . . . . . . . . . . . . . . . . . . . . 14 87 5.2. DHCP for Non-Temporary Address Assignment . . . . . . . . 15 88 5.3. DHCP for Prefix Delegation . . . . . . . . . . . . . . . 15 89 5.4. DHCP for Customer Edge Routers . . . . . . . . . . . . . 18 90 5.5. DHCP for Temporary Addresses . . . . . . . . . . . . . . 18 91 6. DHCP Constants . . . . . . . . . . . . . . . . . . . . . . . 18 92 6.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 18 93 6.2. UDP Ports . . . . . . . . . . . . . . . . . . . . . . . . 19 94 6.3. DHCP Message Types . . . . . . . . . . . . . . . . . . . 19 95 6.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 21 96 6.5. Transmission and Retransmission Parameters . . . . . . . 21 97 6.6. Representation of time values and "Infinity" as a time 98 value . . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 7. Client/Server Message Formats . . . . . . . . . . . . . . . . 22 100 8. Relay Agent/Server Message Formats . . . . . . . . . . . . . 23 101 8.1. Relay-forward Message . . . . . . . . . . . . . . . . . . 24 102 8.2. Relay-reply Message . . . . . . . . . . . . . . . . . . . 25 103 9. Representation and Use of Domain Names . . . . . . . . . . . 25 104 10. DHCP Unique Identifier (DUID) . . . . . . . . . . . . . . . . 25 105 10.1. DUID Contents . . . . . . . . . . . . . . . . . . . . . 26 106 10.2. DUID Based on Link-layer Address Plus Time, DUID-LLT . . 26 107 10.3. DUID Assigned by Vendor Based on Enterprise Number, 108 DUID-EN . . . . . . . . . . . . . . . . . . . . . . . . 28 109 10.4. DUID Based on Link-layer Address, DUID-LL . . . . . . . 29 110 11. Identity Association . . . . . . . . . . . . . . . . . . . . 30 111 11.1. Identity Associations for Address Assignment . . . . . . 30 112 11.2. Identity Associations for Prefix Delegation . . . . . . 30 113 12. Selecting Addresses for Assignment to an IA . . . . . . . . . 31 114 13. Management of Temporary Addresses . . . . . . . . . . . . . . 32 115 14. Transmission of Messages by a Client . . . . . . . . . . . . 33 116 14.1. Rate Limiting . . . . . . . . . . . . . . . . . . . . . 33 117 15. Reliability of Client Initiated Message Exchanges . . . . . . 34 118 16. Message Validation . . . . . . . . . . . . . . . . . . . . . 35 119 16.1. Use of Transaction IDs . . . . . . . . . . . . . . . . . 36 120 16.2. Solicit Message . . . . . . . . . . . . . . . . . . . . 36 121 16.3. Advertise Message . . . . . . . . . . . . . . . . . . . 36 122 16.4. Request Message . . . . . . . . . . . . . . . . . . . . 37 123 16.5. Confirm Message . . . . . . . . . . . . . . . . . . . . 37 124 16.6. Renew Message . . . . . . . . . . . . . . . . . . . . . 37 125 16.7. Rebind Message . . . . . . . . . . . . . . . . . . . . . 37 126 16.8. Decline Messages . . . . . . . . . . . . . . . . . . . . 38 127 16.9. Release Message . . . . . . . . . . . . . . . . . . . . 38 128 16.10. Reply Message . . . . . . . . . . . . . . . . . . . . . 38 129 16.11. Reconfigure Message . . . . . . . . . . . . . . . . . . 39 130 16.12. Information-request Message . . . . . . . . . . . . . . 39 131 16.13. Relay-forward Message . . . . . . . . . . . . . . . . . 39 132 16.14. Relay-reply Message . . . . . . . . . . . . . . . . . . 40 133 17. Client Source Address and Interface Selection . . . . . . . . 40 134 17.1. Address Assignment . . . . . . . . . . . . . . . . . . . 40 135 17.2. Prefix Delegation . . . . . . . . . . . . . . . . . . . 40 136 18. DHCP Server Solicitation . . . . . . . . . . . . . . . . . . 41 137 18.1. Client Behavior . . . . . . . . . . . . . . . . . . . . 41 138 18.1.1. Creation of Solicit Messages . . . . . . . . . . . . 41 139 18.1.2. Transmission of Solicit Messages . . . . . . . . . . 42 140 18.1.3. Receipt of Advertise Messages . . . . . . . . . . . 43 141 18.1.4. Receipt of Reply Message . . . . . . . . . . . . . . 44 142 18.2. Server Behavior . . . . . . . . . . . . . . . . . . . . 45 143 18.2.1. Receipt of Solicit Messages . . . . . . . . . . . . 45 144 18.2.2. Creation and Transmission of Advertise Messages . . 45 145 18.2.3. Creation and Transmission of Reply Messages . . . . 47 146 18.3. Client behavior for Prefix Delegation . . . . . . . . . 47 147 18.4. Server Behavior for Prefix Delegation . . . . . . . . . 48 148 19. DHCP Client-Initiated Configuration Exchange . . . . . . . . 48 149 19.1. Client Behavior . . . . . . . . . . . . . . . . . . . . 49 150 19.1.1. Creation and Transmission of Request Messages . . . 49 151 19.1.2. Creation and Transmission of Confirm Messages . . . 50 152 19.1.3. Creation and Transmission of Renew Messages . . . . 52 153 19.1.4. Creation and Transmission of Rebind Messages . . . . 53 154 19.1.5. Creation and Transmission of Information-request 155 Messages . . . . . . . . . . . . . . . . . . . . . . 54 156 19.1.6. Creation and Transmission of Release Messages . . . 55 157 19.1.7. Creation and Transmission of Decline Messages . . . 56 158 19.1.8. Receipt of Reply Messages . . . . . . . . . . . . . 57 159 19.2. Server Behavior . . . . . . . . . . . . . . . . . . . . 59 160 19.2.1. Receipt of Request Messages . . . . . . . . . . . . 59 161 19.2.2. Receipt of Confirm Messages . . . . . . . . . . . . 60 162 19.2.3. Receipt of Renew Messages . . . . . . . . . . . . . 61 163 19.2.4. Receipt of Rebind Messages . . . . . . . . . . . . . 62 164 19.2.5. Receipt of Information-request Messages . . . . . . 62 165 19.2.6. Receipt of Release Messages . . . . . . . . . . . . 63 166 19.2.7. Receipt of Decline Messages . . . . . . . . . . . . 64 167 19.2.8. Transmission of Reply Messages . . . . . . . . . . . 64 168 19.3. Requesting Router Behavior for Prefix Delegation . . . . 65 169 19.4. Delegating Router Behavior for Prefix Delegation . . . . 66 170 20. DHCP Server-Initiated Configuration Exchange . . . . . . . . 67 171 20.1. Server Behavior . . . . . . . . . . . . . . . . . . . . 68 172 20.1.1. Creation and Transmission of Reconfigure Messages . 68 173 20.1.2. Time Out and Retransmission of Reconfigure Messages 69 174 20.2. Receipt of Renew or Rebind Messages . . . . . . . . . . 69 175 20.3. Receipt of Information-request Messages . . . . . . . . 69 176 20.4. Client Behavior . . . . . . . . . . . . . . . . . . . . 70 177 20.4.1. Receipt of Reconfigure Messages . . . . . . . . . . 70 178 20.4.2. Creation and Transmission of Renew or Rebind 179 Messages . . . . . . . . . . . . . . . . . . . . . . 71 180 20.4.3. Creation and Transmission of Information-request 181 Messages . . . . . . . . . . . . . . . . . . . . . . 71 182 20.4.4. Time Out and Retransmission of Renew, Rebind or 183 Information-request Messages . . . . . . . . . . . . 71 184 20.4.5. Receipt of Reply Messages . . . . . . . . . . . . . 71 185 20.5. Prefix Delegation Reconfiguration . . . . . . . . . . . 72 186 20.5.1. Delegating Router Behavior . . . . . . . . . . . . . 72 187 20.5.2. Requesting Router Behavior . . . . . . . . . . . . . 72 188 21. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 72 189 21.1. Relaying a Client Message or a Relay-forward Message . . 72 190 21.1.1. Relaying a Message from a Client . . . . . . . . . . 73 191 21.1.2. Relaying a Message from a Relay Agent . . . . . . . 73 192 21.1.3. Relay Agent Behavior with Prefix Delegation . . . . 74 193 21.2. Relaying a Relay-reply Message . . . . . . . . . . . . . 74 194 21.3. Construction of Relay-reply Messages . . . . . . . . . . 74 195 22. Authentication of DHCP Messages . . . . . . . . . . . . . . . 75 196 22.1. Security of Messages Sent Between Servers and Relay 197 Agents . . . . . . . . . . . . . . . . . . . . . . . . . 76 198 22.2. Summary of DHCP Authentication . . . . . . . . . . . . . 77 199 22.3. Replay Detection . . . . . . . . . . . . . . . . . . . . 77 200 22.4. Delayed Authentication Protocol . . . . . . . . . . . . 78 201 22.4.1. Use of the Authentication Option in the Delayed 202 Authentication Protocol . . . . . . . . . . . . . . 78 203 22.4.2. Message Validation . . . . . . . . . . . . . . . . . 80 204 22.4.3. Key Utilization . . . . . . . . . . . . . . . . . . 80 205 22.4.4. Client Considerations for Delayed Authentication 206 Protocol . . . . . . . . . . . . . . . . . . . . . . 80 207 22.4.4.1. Sending Solicit Messages . . . . . . . . . . . . 80 208 22.4.4.2. Receiving Advertise Messages . . . . . . . . . . 81 209 22.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline 210 or Release Messages . . . . . . . . . . . . . . 81 211 22.4.4.4. Sending Information-request Messages . . . . . . 82 212 22.4.4.5. Receiving Reply Messages . . . . . . . . . . . . 82 213 22.4.4.6. Receiving Reconfigure Messages . . . . . . . . . 82 214 22.4.5. Server Considerations for Delayed Authentication 215 Protocol . . . . . . . . . . . . . . . . . . . . . . 82 216 22.4.5.1. Receiving Solicit Messages and Sending Advertise 217 Messages . . . . . . . . . . . . . . . . . . . . 82 218 22.4.5.2. Receiving Request, Confirm, Renew, Rebind or 219 Release Messages and Sending Reply Messages . . 83 220 22.5. Reconfigure Key Authentication Protocol . . . . . . . . 83 221 22.5.1. Use of the Authentication Option in the Reconfigure 222 Key Authentication Protocol . . . . . . . . . . . . 83 223 22.5.2. Server considerations for Reconfigure Key protocol . 84 224 22.5.3. Client considerations for Reconfigure Key protocol . 85 225 23. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 85 226 23.1. Format of DHCP Options . . . . . . . . . . . . . . . . . 86 227 23.2. Client Identifier Option . . . . . . . . . . . . . . . . 86 228 23.3. Server Identifier Option . . . . . . . . . . . . . . . . 87 229 23.4. Identity Association for Non-temporary Addresses Option 88 230 23.5. Identity Association for Temporary Addresses Option . . 90 231 23.6. IA Address Option . . . . . . . . . . . . . . . . . . . 92 232 23.7. Option Request Option . . . . . . . . . . . . . . . . . 93 233 23.8. Preference Option . . . . . . . . . . . . . . . . . . . 94 234 23.9. Elapsed Time Option . . . . . . . . . . . . . . . . . . 95 235 23.10. Relay Message Option . . . . . . . . . . . . . . . . . . 95 236 23.11. Authentication Option . . . . . . . . . . . . . . . . . 96 237 23.12. Server Unicast Option . . . . . . . . . . . . . . . . . 97 238 23.13. Status Code Option . . . . . . . . . . . . . . . . . . . 98 239 23.14. Rapid Commit Option . . . . . . . . . . . . . . . . . . 100 240 23.15. User Class Option . . . . . . . . . . . . . . . . . . . 101 241 23.16. Vendor Class Option . . . . . . . . . . . . . . . . . . 102 242 23.17. Vendor-specific Information Option . . . . . . . . . . . 104 243 23.18. Interface-Id Option . . . . . . . . . . . . . . . . . . 106 244 23.19. Reconfigure Message Option . . . . . . . . . . . . . . . 107 245 23.20. Reconfigure Accept Option . . . . . . . . . . . . . . . 107 246 23.21. Identity Association for Prefix Delegation Option . . . 108 247 23.22. IA Prefix Option . . . . . . . . . . . . . . . . . . . . 110 248 23.23. SOL_MAX_RT Option . . . . . . . . . . . . . . . . . . . 111 249 23.24. INF_MAX_RT Option . . . . . . . . . . . . . . . . . . . 112 250 24. Security Considerations . . . . . . . . . . . . . . . . . . . 113 251 25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 116 252 26. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 116 253 27. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 254 27.1. Normative References . . . . . . . . . . . . . . . . . . 117 255 27.2. Informative References . . . . . . . . . . . . . . . . . 119 256 Appendix A. Changes since RFC3315 . . . . . . . . . . . . . . . 120 257 Appendix B. Changes since RFC3633 . . . . . . . . . . . . . . . 123 258 Appendix C. Appearance of Options in Message Types . . . . . . . 123 259 Appendix D. Appearance of Options in the Options Field of DHCP 260 Options . . . . . . . . . . . . . . . . . . . . . . 124 261 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 125 263 1. Introduction and Overview 265 This document describes DHCP for IPv6 (DHCP), a client/server 266 protocol that provides managed configuration of devices. 268 DHCP can provide a device with addresses assigned by a DHCP server 269 and other configuration information, which are carried in options. 270 DHCP can be extended through the definition of new options to carry 271 configuration information not specified in this document. 273 DHCP is the "stateful address autoconfiguration protocol" and the 274 "stateful autoconfiguration protocol" referred to in "IPv6 Stateless 275 Address Autoconfiguration" [RFC4862]. 277 This document also provides a mechanism for automated delegation of 278 IPv6 prefixes using DHCP. Through this mechanism, a delegating 279 router can delegate prefixes to requesting routers. 281 The operational models and relevant configuration information for 282 DHCPv4 [RFC2132][RFC2131] and DHCPv6 are sufficiently different that 283 integration between the two services is not included in this 284 document. [RFC3315] suggested that future work might be to extend 285 DHCPv6 to carry IPv4 address and configuration information. However, 286 the current consensus of the IETF is that DHCPv4 should be used 287 rather than DHCPv6 when conveying IPv4 configuration information to 288 nodes. [RFC7341] describes a transport mechanism to carry DHCPv4 289 messages using the DHCPv6 protocol for the dynamic provisioning of 290 IPv4 address and configuration information across IPv6-only networks. 292 The remainder of this introduction summarizes DHCP, explaining the 293 message exchange mechanisms and example message flows. The message 294 flows in Section 1.2 and Section 1.3 are intended as illustrations of 295 DHCP operation rather than an exhaustive list of all possible client- 296 server interactions. Section 5 provides an overview of common 297 operational models. Section 18, Section 19, and Section 20 explain 298 client and server operation in detail. 300 1.1. Protocols and Addressing 302 Clients and servers exchange DHCP messages using UDP [RFC0768]. The 303 client uses a link-local address or addresses determined through 304 other mechanisms for transmitting and receiving DHCP messages. 306 A DHCP client sends most messages using a reserved, link-scoped 307 multicast destination address so that the client need not be 308 configured with the address or addresses of DHCP servers. 310 To allow a DHCP client to send a message to a DHCP server that is not 311 attached to the same link, a DHCP relay agent on the client's link 312 will relay messages between the client and server. The operation of 313 the relay agent is transparent to the client and the discussion of 314 message exchanges in the remainder of this section will omit the 315 description of message relaying by relay agents. 317 Once the client has determined the address of a server, it may under 318 some circumstances send messages directly to the server using 319 unicast. 321 1.2. Client-server Exchanges Involving Two Messages 323 When a DHCP client does not need to have a DHCP server assign it IP 324 addresses, the client can obtain configuration information such as a 325 list of available DNS servers [RFC3646] or NTP servers [RFC4075] 326 through a single message and reply exchanged with a DHCP server. To 327 obtain configuration information the client first sends an 328 Information-request message to the All_DHCP_Relay_Agents_and_Servers 329 multicast address. Servers respond with a Reply message containing 330 the configuration information for the client. 332 This message exchange assumes that the client requires only 333 configuration information and does not require the assignment of any 334 IPv6 addresses. 336 When a server has IPv6 addresses and other configuration information 337 committed to a client, the client and server may be able to complete 338 the exchange using only two messages, instead of four messages as 339 described in the next section. In this case, the client sends a 340 Solicit message to the All_DHCP_Relay_Agents_and_Servers requesting 341 the assignment of addresses and other configuration information. 342 This message includes an indication that the client is willing to 343 accept an immediate Reply message from the server. The server that 344 is willing to commit the assignment of addresses to the client 345 immediately responds with a Reply message. The configuration 346 information and the addresses in the Reply message are then 347 immediately available for use by the client. 349 Each address assigned to the client has associated preferred and 350 valid lifetimes specified by the server. To request an extension of 351 the lifetimes assigned to an address, the client sends a Renew 352 message to the server. The server sends a Reply message to the 353 client with the new lifetimes, allowing the client to continue to use 354 the address without interruption. 356 1.3. Client-server Exchanges Involving Four Messages 358 To request the assignment of one or more IPv6 addresses, a client 359 first locates a DHCP server and then requests the assignment of 360 addresses and other configuration information from the server. The 361 client sends a Solicit message to the 362 All_DHCP_Relay_Agents_and_Servers address to find available DHCP 363 servers. Any server that can meet the client's requirements responds 364 with an Advertise message. The client then chooses one of the 365 servers and sends a Request message to the server asking for 366 confirmed assignment of addresses and other configuration 367 information. The server responds with a Reply message that contains 368 the confirmed addresses and configuration. 370 As described in the previous section, the client sends a Renew 371 message to the server to extend the lifetimes associated with its 372 addresses, allowing the client to continue to use those addresses 373 without interruption. 375 2. Requirements 377 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 378 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 379 document, are to be interpreted as described in [RFC2119]. 381 This document also makes use of internal conceptual variables to 382 describe protocol behavior and external variables that an 383 implementation must allow system administrators to change. The 384 specific variable names, how their values change, and how their 385 settings influence protocol behavior are provided to demonstrate 386 protocol behavior. An implementation is not required to have them in 387 the exact form described here, so long as its external behavior is 388 consistent with that described in this document. 390 3. Background 392 The IPv6 Specification provides the base architecture and design of 393 IPv6. Related work in IPv6 that would best serve an implementor to 394 study includes the IPv6 Specification [RFC2460], the IPv6 Addressing 395 Architecture [RFC4291], IPv6 Stateless Address Autoconfiguration 396 [RFC4862], IPv6 Neighbor Discovery Processing [RFC4861], and Dynamic 397 Updates to DNS [RFC2136]. These specifications enable DHCP to build 398 upon the IPv6 work to provide both robust stateful autoconfiguration 399 and autoregistration of DNS Host Names. 401 The IPv6 Addressing Architecture specification [RFC4291] defines the 402 address scope that can be used in an IPv6 implementation, and the 403 various configuration architecture guidelines for network designers 404 of the IPv6 address space. Two advantages of IPv6 are that support 405 for multicast is required and nodes can create link-local addresses 406 during initialization. The availability of these features means that 407 a client can use its link-local address and a well-known multicast 408 address to discover and communicate with DHCP servers or relay agents 409 on its link. 411 IPv6 Stateless Address Autoconfiguration [RFC4862] specifies 412 procedures by which a node may autoconfigure addresses based on 413 router advertisements [RFC4861], and the use of a valid lifetime to 414 support renumbering of addresses on the Internet. In addition, the 415 protocol interaction by which a node begins stateless or stateful 416 autoconfiguration is specified. DHCP is one vehicle to perform 417 stateful autoconfiguration. Compatibility with stateless address 418 autoconfiguration is a design requirement of DHCP. 420 IPv6 Neighbor Discovery [RFC4861] is the node discovery protocol in 421 IPv6 which replaces and enhances functions of ARP [RFC0826]. To 422 understand IPv6 and stateless address autoconfiguration, it is 423 strongly recommended that implementors understand IPv6 Neighbor 424 Discovery. 426 Dynamic Updates to DNS [RFC2136] is a specification that supports the 427 dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 428 the dynamic updates to DNS to integrate addresses and name space to 429 not only support autoconfiguration, but also autoregistration in 430 IPv6. 432 4. Terminology 434 This section defines terminology specific to IPv6 and DHCP used in 435 this document. 437 4.1. IPv6 Terminology 439 IPv6 terminology relevant to this specification from the IPv6 440 Protocol [RFC2460], IPv6 Addressing Architecture [RFC4291], and IPv6 441 Stateless Address Autoconfiguration [RFC4862] is included below. 443 address An IP layer identifier for an interface or 444 a set of interfaces. 446 host Any node that is not a router. 448 IP Internet Protocol Version 6 (IPv6). The 449 terms IPv4 and IPv6 are used only in 450 contexts where it is necessary to avoid 451 ambiguity. 453 interface A node's attachment to a link. 455 link A communication facility or medium over 456 which nodes can communicate at the link 457 layer, i.e., the layer immediately below 458 IP. Examples are Ethernet (simple or 459 bridged); Token Ring; PPP links, X.25, 460 Frame Relay, or ATM networks; and Internet 461 (or higher) layer "tunnels", such as 462 tunnels over IPv4 or IPv6 itself. 464 link-layer identifier A link-layer identifier for an interface. 465 Examples include IEEE 802 addresses for 466 Ethernet or Token Ring network interfaces, 467 and E.164 addresses for ISDN links. 469 link-local address An IPv6 address having a link-only scope, 470 indicated by having the prefix (FE80::/10), 471 that can be used to reach neighboring nodes 472 attached to the same link. Every interface 473 has a link-local address. 475 multicast address An identifier for a set of interfaces 476 (typically belonging to different nodes). 477 A packet sent to a multicast address is 478 delivered to all interfaces identified by 479 that address. 481 neighbor A node attached to the same link. 483 node A device that implements IP. 485 packet An IP header plus payload. 487 prefix The initial bits of an address, or a set of 488 IP addresses that share the same initial 489 bits. 491 prefix length The number of bits in a prefix. 493 router A node that forwards IP packets not 494 explicitly addressed to itself. 496 unicast address An identifier for a single interface. A 497 packet sent to a unicast address is 498 delivered to the interface identified by 499 that address. 501 4.2. DHCP Terminology 503 Terminology specific to DHCP can be found below. 505 allocatable resource (or resource). It is an address, a prefix 506 or any other allocatable resource that may 507 be defined in the future. Currently there 508 are three defined allocatable resources: 509 non-temporary addresses, temporary 510 addresses and delegated prefixes. 512 appropriate to the link An address is "appropriate to the link" 513 when the address is consistent with the 514 DHCP server's knowledge of the network 515 topology, prefix assignment and address 516 assignment policies. 518 binding A binding (or, client binding) is a group 519 of server data records containing the 520 information the server has about the 521 addresses in an IA or configuration 522 information explicitly assigned to the 523 client. Configuration information that has 524 been returned to a client through a policy 525 - for example, the information returned to 526 all clients on the same link - does not 527 require a binding. A binding containing 528 information about an IA is indexed by the 529 tuple (where IA-type 530 is the type of address in the IA; for 531 example, temporary). A binding containing 532 configuration information for a client is 533 indexed by . 535 configuration parameter An element of the configuration information 536 set on the server and delivered to the 537 client using DHCP. Such parameters may be 538 used to carry information to be used by a 539 node to configure its network subsystem and 540 enable communication on a link or 541 internetwork, for example. 543 delegating router: The router that acts as a DHCP server, and 544 is responding to the prefix request. 546 DHCP Dynamic Host Configuration Protocol for 547 IPv6. The terms DHCPv4 and DHCPv6 are used 548 only in contexts where it is necessary to 549 avoid ambiguity. 551 DHCP client (or client) A node that initiates requests on a link to 552 obtain configuration parameters from one or 553 more DHCP servers. Depending on the 554 purpose of the client, it may feature the 555 requesting router functionality, if it 556 supports prefix delegation. 558 DHCP domain A set of links managed by DHCP and operated 559 by a single administrative entity. 561 DHCP realm A name used to identify the DHCP 562 administrative domain from which a DHCP 563 authentication key was selected. 565 DHCP relay agent (or relay agent) A node that acts as an 566 intermediary to deliver DHCP messages 567 between clients and servers. In certain 568 configurations there may be more than one 569 relay agent between clients and servers, so 570 a relay agent may send DHCP messages to 571 another relay agent. 573 DHCP server (or server) A node that responds to requests from 574 clients, and may or may not be on the same 575 link as the client(s). Depending on its 576 capabilities, it may also feature the 577 functionality of delegating router, if it 578 supports prefix delegation. 580 DUID A DHCP Unique IDentifier for a DHCP 581 participant; each DHCP client and server 582 has exactly one DUID. See Section 10 for 583 details of the ways in which a DUID may be 584 constructed. 586 IA Identity Association: A collection of 587 allocatable resources assigned to a client. 588 Each IA has an associated IAID. A client 589 may have more than one IA assigned to it; 590 for example, one for each of its 591 interfaces. Each IA holds one type of 592 address; for example, an identity 593 association for temporary addresses (IA_TA) 594 holds temporary addresses (see "identity 595 association for temporary addresses") and 596 identity association for prefix delegation 597 (IA_PD) holds delegated prefixes. 598 Throughout this document, "IA" is used to 599 refer to an identity association without 600 identifying the type of allocatable 601 resources in the IA. At the time of 602 writing this document, there are 3 IA types 603 defined: IA_NA, IA_TA and IA_PD. New IA 604 types may be defined in the future. 606 IAID Identity Association IDentifier: An 607 identifier for an IA, chosen by the client. 608 Each IA has an IAID, which is chosen to be 609 unique among IAIDs for IAs of a specific 610 type, belonging to that client. 612 IA_NA Identity association for Non-temporary 613 Addresses: An IA that carries assigned 614 addresses that are not temporary addresses 615 (see "identity association for temporary 616 addresses") 618 IA_TA Identity Association for Temporary 619 Addresses: An IA that carries temporary 620 addresses (see [RFC4941]). 622 IA_PD Identity Association for Prefix Delegation: 623 A collection of prefixes assigned to the 624 requesting router. Each IA_PD has an 625 associated IAID. A requesting router may 626 have more than one IA_PD assigned to it; 627 for example, one for each of its 628 interfaces. 630 message A unit of data carried as the payload of a 631 UDP datagram, exchanged among DHCP servers, 632 relay agents and clients. 634 Reconfigure key A key supplied to a client by a server used 635 to provide security for Reconfigure 636 messages. 638 requesting router: The router that acts as a DHCP client and 639 is requesting prefix(es) to be assigned. 641 singleton option: An option that is allowed to appear only 642 once. Most options are singletons. 644 relaying A DHCP relay agent relays DHCP messages 645 between DHCP participants. 647 transaction ID An opaque value used to match responses 648 with replies initiated either by a client 649 or server. 651 5. Operational Models 653 This section describes some of the current most common DHCP 654 operational models. The described models are not mutually exclusive 655 and are sometimes used together. For example, a device may start in 656 stateful mode to obtain an address, and at a later time when an 657 application is started, request additional parameters using stateless 658 mode. 660 5.1. Stateless DHCP 662 Stateless DHCP [RFC3736] is used when DHCP is not used for obtaining 663 an allocatable resource, but a node (DHCP client) desires one or more 664 DHCP "other configuration" parameters, such as a list of DNS 665 recursive name servers or DNS domain search lists [RFC3646]. 666 Stateless may be used when a node initially boots or at any time the 667 software on the node requires some missing or expired configuration 668 information that is available via DHCP. 670 This is the simplest and most basic operation for DHCP and requires a 671 client (and a server) to support only two messages - Information- 672 request and Reply. Note that DHCP servers and relay agents typically 673 also need to support the Relay-Forw and Relay-Reply messages to 674 accommodate operation when clients and servers are not on the same 675 link. 677 5.2. DHCP for Non-Temporary Address Assignment 679 This model of operation was the original motivation for DHCP and is 680 the "stateful address autoconfiguration protocol" for IPv6 [RFC2462]. 681 It is appropriate for situations where stateless address 682 autoconfiguration is not desired, because of network policy, 683 additional requirements (such as updating the DNS with forward or 684 reverse resource records), or client specific requirements (i.e., 685 some prefixes are only available to some clients) which are not 686 possible using stateless address autoconfiguration. 688 The model of operation for non-temporary address assignment is as 689 follows. The server is provided with IPv6 prefixes from which it may 690 allocate addresses to clients, as well as any related network 691 topology information as to which prefixes are present on which links. 692 A client requests a non-temporary address to be assigned by the 693 server. The server allocates an address or addresses appropriate for 694 the link on which the client is connected. The server returns the 695 allocated address or addresses to the client. 697 Each address has an associated preferred and valid lifetime, which 698 constitutes an agreement about the length of time over which the 699 client is allowed to use the address. A client can request an 700 extension of the lifetimes on an address and is required to terminate 701 the use of an address if the valid lifetime of the address expires. 703 Typically clients request other configuration parameters, such as the 704 domain server addresses and search lists, when requesting addresses. 706 5.3. DHCP for Prefix Delegation 708 The prefix delegation mechanism, originally described in [RFC3633], 709 is another stateful mode of operation and intended for simple 710 delegation of prefixes from a delegating router (DHCP server) to 711 requesting routers (DHCP clients). It is appropriate for situations 712 in which the delegating router does not have knowledge about the 713 topology of the networks to which the requesting router is attached, 714 and the delegating router does not require other information aside 715 from the identity of the requesting router to choose a prefix for 716 delegation. For example, these options would be used by a service 717 provider to assign a prefix to a Customer Premise Equipment (CPE) 718 device acting as a router between the subscriber's internal network 719 and the service provider's core network. 721 The design of this prefix delegation mechanism meets the requirements 722 for prefix delegation in [RFC3769]. 724 The model of operation for prefix delegation is as follows. A 725 delegating router is provided IPv6 prefixes to be delegated to 726 requesting routers. Examples of ways in which the delegating router 727 may be provided these prefixes is given in Section 19.4. A 728 requesting router requests prefix(es) from the delegating router, as 729 described in Section 19.3. The delegating router chooses prefix(es) 730 for delegation, and responds with prefix(es) to the requesting 731 router. The requesting router is then responsible for the delegated 732 prefix(es). For example, the requesting router might assign a subnet 733 from a delegated prefix to one of its interfaces, and begin sending 734 router advertisements for the prefix on that link. 736 Each prefix has an associated valid and preferred lifetime, which 737 constitutes an agreement about the length of time over which the 738 requesting router is allowed to use the prefix. A requesting router 739 can request an extension of the lifetimes on a delegated prefix and 740 is required to terminate the use of a delegated prefix if the valid 741 lifetime of the prefix expires. 743 This prefix delegation mechanism would be appropriate for use by an 744 ISP to delegate a prefix to a subscriber, where the delegated prefix 745 would possibly be subnetted and assigned to the links within the 746 subscriber's network. 748 Figure 1 illustrates a network architecture in which prefix 749 delegation could be used. 751 ______________________ \ 752 / \ \ 753 | ISP core network | \ 754 \__________ ___________/ | 755 | | 756 +-------+-------+ | 757 | Aggregation | | ISP 758 | device | | network 759 | (delegating | | 760 | router) | | 761 +-------+-------+ | 762 | / 763 |DSL to subscriber / 764 |premises / 765 | 766 +------+------+ \ 767 | CPE | \ 768 | (requesting | \ 769 | router) | | 770 +----+---+----+ | 771 | | | Subsciber 772 ---+-------------+-----+ +-----+------ | Network 773 | | | | 774 +----+-----+ +-----+----+ +----+-----+ | 775 |Subscriber| |Subscriber| |Subscriber| / 776 | PC | | PC | | PC | / 777 +----------+ +----------+ +----------+ / 779 Figure 1: Prefix Delegation Newtork 781 In this example, the delegating router is configured with a set of 782 prefixes to be used for assignment to customers at the time of each 783 customer's first connection to the ISP service. The prefix 784 delegation process begins when the requesting router requests 785 configuration information through DHCP. The DHCP messages from the 786 requesting router are received by the delegating router in the 787 aggregation device. When the delegating router receives the request, 788 it selects an available prefix or prefixes for delegation to the 789 requesting router. The delegating router then returns the prefix or 790 prefixes to the requesting router. 792 The requesting router subnets the delegated prefix and assigns the 793 longer prefixes to links in the subscriber's network. In a typical 794 scenario based on the network shown in Figure 1, the requesting 795 router subnets a single delegated /48 prefix into /64 prefixes and 796 assigns one /64 prefix to each of the links in the subscriber 797 network. 799 The prefix delegation options can be used in conjunction with other 800 DHCP options carrying other configuration information to the 801 requesting router. The requesting router may, in turn, provide DHCP 802 service to hosts attached to the internal network. For example, the 803 requesting router may obtain the addresses of DNS and NTP servers 804 from the ISP delegating router, and then pass that configuration 805 information on to the subscriber hosts through a DHCP server in the 806 requesting router. 808 5.4. DHCP for Customer Edge Routers 810 The DHCP requirements and network architecture for Customer Edge 811 Routers are described in [RFC7084]. This model of operation combines 812 address assignment (see Section 5.2) and prefix delegation (see 813 Section 5.3). In general, this model assumes that a single set of 814 transactions between the client and server will assign or extend the 815 client's non-temporary addresses and delegated prefixes. 817 5.5. DHCP for Temporary Addresses 819 Temporary addresses were originally introduced to avoid privacy 820 concerns with stateless address autoconfiguration, which based 821 64-bits of the address on the EUI-64 (see [RFC3041] and [RFC4941]). 822 They were added to DHCP to provide complementary support when 823 stateful address assignment is used. 825 Temporary address assignment works mostly like non-temporary address 826 assignment (see Section 5.2), however these addresses are generally 827 intended to be used for a short period of time and not to have their 828 lifetimes extended, though they can be if required. 830 6. DHCP Constants 832 This section describes various program and networking constants used 833 by DHCP. 835 6.1. Multicast Addresses 837 DHCP makes use of the following multicast addresses: 839 All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped 840 multicast address used by a client to communicate 841 with neighboring (i.e., on-link) relay agents and 842 servers. All servers and relay agents are members of 843 this multicast group. 845 All_DHCP_Servers (FF05::1:3) A site-scoped multicast address used by 846 a relay agent to communicate with servers, either 847 because the relay agent wants to send messages to all 848 servers or because it does not know the unicast 849 addresses of the servers. Note that in order for a 850 relay agent to use this address, it must have an 851 address of sufficient scope to be reachable by the 852 servers. All servers within the site are members of 853 this multicast group. 855 6.2. UDP Ports 857 Clients listen for DHCP messages on UDP port 546. Servers and relay 858 agents listen for DHCP messages on UDP port 547. 860 6.3. DHCP Message Types 862 DHCP defines the following message types. More detail on these 863 message types can be found in Section 7 and Section 8. Message types 864 not listed here are reserved for future use. The numeric encoding 865 for each message type is shown in parentheses. 867 SOLICIT (1) A client sends a Solicit message to locate servers. 869 ADVERTISE (2) A server sends an Advertise message to indicate that 870 it is available for DHCP service, in response to a 871 Solicit message received from a client. 873 REQUEST (3) A client sends a Request message to request 874 configuration parameters, including IP addresses, 875 from a specific server. 877 CONFIRM (4) A client sends a Confirm message to any available 878 server to determine whether the addresses it was 879 assigned are still appropriate to the link to which 880 the client is connected. 882 RENEW (5) A client sends a Renew message to the server that 883 originally provided the client's addresses and 884 configuration parameters to extend the lifetimes on 885 the addresses assigned to the client and to update 886 other configuration parameters. 888 REBIND (6) A client sends a Rebind message to any available 889 server to extend the lifetimes on the addresses 890 assigned to the client and to update other 891 configuration parameters; this message is sent after 892 a client receives no response to a Renew message. 894 REPLY (7) A server sends a Reply message containing assigned 895 addresses and configuration parameters in response to 896 a Solicit, Request, Renew, Rebind message received 897 from a client. A server sends a Reply message 898 containing configuration parameters in response to an 899 Information-request message. A server sends a Reply 900 message in response to a Confirm message confirming 901 or denying that the addresses assigned to the client 902 are appropriate to the link to which the client is 903 connected. A server sends a Reply message to 904 acknowledge receipt of a Release or Decline message. 906 RELEASE (8) A client sends a Release message to the server that 907 assigned addresses to the client to indicate that the 908 client will no longer use one or more of the assigned 909 addresses. 911 DECLINE (9) A client sends a Decline message to a server to 912 indicate that the client has determined that one or 913 more addresses assigned by the server are already in 914 use on the link to which the client is connected. 916 RECONFIGURE (10) A server sends a Reconfigure message to a client to 917 inform the client that the server has new or updated 918 configuration parameters, and that the client is to 919 initiate a Renew/Reply or Information-request/Reply 920 transaction with the server in order to receive the 921 updated information. 923 INFORMATION-REQUEST (11) A client sends an Information-request 924 message to a server to request configuration 925 parameters without the assignment of any IP addresses 926 to the client. 928 RELAY-FORW (12) A relay agent sends a Relay-forward message to relay 929 messages to servers, either directly or through 930 another relay agent. The received message, either a 931 client message or a Relay-forward message from 932 another relay agent, is encapsulated in an option in 933 the Relay-forward message. 935 RELAY-REPL (13) A server sends a Relay-reply message to a relay agent 936 containing a message that the relay agent delivers to 937 a client. The Relay-reply message may be relayed by 938 other relay agents for delivery to the destination 939 relay agent. 941 The server encapsulates the client message as an 942 option in the Relay-reply message, which the relay 943 agent extracts and relays to the client. 945 6.4. Status Codes 947 DHCPv6 uses status codes to communicate the success or failure of 948 operations requested in messages from clients and servers, and to 949 provide additional information about the specific cause of the 950 failure of a message. The specific status codes are defined in 951 Section 23.12. 953 If the Status Code option does not appear in a message in which the 954 option could appear, the status of the message is assumed to be 955 Success. 957 6.5. Transmission and Retransmission Parameters 959 This section presents a table of values used to describe the message 960 transmission behavior of clients and servers. 962 +-----------------+-----------+-------------------------------------+ 963 | Parameter | Default | Description | 964 +-----------------+-----------+-------------------------------------+ 965 | SOL_MAX_DELAY | 1 sec | Max delay of first Solicit | 966 | SOL_TIMEOUT | 1 sec | Initial Solicit timeout | 967 | SOL_MAX_RT | 3600 secs | Max Solicit timeout value | 968 | REQ_TIMEOUT | 1 sec | Initial Request timeout | 969 | REQ_MAX_RT | 30 secs | Max Request timeout value | 970 | REQ_MAX_RC | 10 | Max Request retry attempts | 971 | CNF_MAX_DELAY | 1 sec | Max delay of first Confirm | 972 | CNF_TIMEOUT | 1 sec | Initial Confirm timeout | 973 | CNF_MAX_RT | 4 secs | Max Confirm timeout | 974 | CNF_MAX_RD | 10 secs | Max Confirm duration | 975 | REN_TIMEOUT | 10 secs | Initial Renew timeout | 976 | REN_MAX_RT | 600 secs | Max Renew timeout value | 977 | REB_TIMEOUT | 10 secs | Initial Rebind timeout | 978 | REB_MAX_RT | 600 secs | Max Rebind timeout value | 979 | INF_MAX_DELAY | 1 sec | Max delay of first Information- | 980 | | | request | 981 | INF_TIMEOUT | 1 sec | Initial Information-request timeout | 982 | INF_MAX_RT | 3600 secs | Max Information-request timeout | 983 | | | value | 984 | REL_TIMEOUT | 1 sec | Initial Release timeout | 985 | REL_MAX_RC | 4 | MAX Release retry attempts | 986 | DEC_TIMEOUT | 1 sec | Initial Decline timeout | 987 | DEC_MAX_RC | 4 | Max Decline retry attempts | 988 | REC_TIMEOUT | 2 secs | Initial Reconfigure timeout | 989 | REC_MAX_RC | 8 | Max Reconfigure attempts | 990 | HOP_COUNT_LIMIT | 32 | Max hop count in a Relay-forward | 991 | | | message | 992 +-----------------+-----------+-------------------------------------+ 994 6.6. Representation of time values and "Infinity" as a time value 996 All time values for lifetimes, T1 and T2 are unsigned integers. The 997 value 0xffffffff is taken to mean "infinity" when used as a lifetime 998 (as in [RFC4861]) or a value for T1 or T2. 1000 7. Client/Server Message Formats 1002 All DHCP messages sent between clients and servers share an identical 1003 fixed format header and a variable format area for options. 1005 All values in the message header and in options are in network byte 1006 order. 1008 Options are stored serially in the options field, with no padding 1009 between the options. Options are byte-aligned but are not aligned in 1010 any other way such as on 2 or 4 byte boundaries. 1012 The following diagram illustrates the format of DHCP messages sent 1013 between clients and servers: 1015 0 1 2 3 1016 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 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | msg-type | transaction-id | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | | 1021 . options . 1022 . (variable) . 1023 | | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 Figure 2: Client/Server message format 1028 msg-type Identifies the DHCP message type; the 1029 available message types are listed in 1030 Section 6.3. 1032 transaction-id The transaction ID for this message exchange. 1034 options Options carried in this message; options are 1035 described in Section 23. 1037 8. Relay Agent/Server Message Formats 1039 Relay agents exchange messages with servers to relay messages between 1040 clients and servers that are not connected to the same link. 1042 All values in the message header and in options are in network byte 1043 order. 1045 Options are stored serially in the options field, with no padding 1046 between the options. Options are byte-aligned but are not aligned in 1047 any other way such as on 2 or 4 byte boundaries. 1049 There are two relay agent messages, which share the following format: 1051 0 1 2 3 1052 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 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | msg-type | hop-count | | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1056 | | 1057 | link-address | 1058 | | 1059 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1060 | | | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1062 | | 1063 | peer-address | 1064 | | 1065 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1066 | | | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1068 . . 1069 . options (variable number and length) .... . 1070 | | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 Figure 3: Relay Agent/Server message format 1075 The following sections describe the use of the Relay Agent message 1076 header. 1078 8.1. Relay-forward Message 1080 The following table defines the use of message fields in a Relay- 1081 forward message. 1083 msg-type RELAY-FORW 1085 hop-count Number of relay agents that have relayed this 1086 message. 1088 link-address An address that will be used by the server to 1089 identify the link on which the client is 1090 located. This is typically global, site- 1091 scoped or ULA [RFC4193], but see discussion 1092 in Section 21.1.1. 1094 peer-address The address of the client or relay agent from 1095 which the message to be relayed was received. 1097 options MUST include a "Relay Message option" (see 1098 Section 23.10); MAY include other options 1099 added by the relay agent. 1101 8.2. Relay-reply Message 1103 The following table defines the use of message fields in a Relay- 1104 reply message. 1106 msg-type RELAY-REPL 1108 hop-count Copied from the Relay-forward message 1110 link-address Copied from the Relay-forward message 1112 peer-address Copied from the Relay-forward message 1114 options MUST include a "Relay Message option"; see 1115 Section 23.10; MAY include other options 1117 9. Representation and Use of Domain Names 1119 So that domain names may be encoded uniformly, a domain name or a 1120 list of domain names is encoded using the technique described in 1121 section 3.1 of [RFC1035]. A domain name, or list of domain names, in 1122 DHCP MUST NOT be stored in compressed form, as described in section 1123 4.1.4 of [RFC1035]. 1125 10. DHCP Unique Identifier (DUID) 1127 Each DHCP client and server has a DUID. DHCP servers use DUIDs to 1128 identify clients for the selection of configuration parameters and in 1129 the association of IAs with clients. DHCP clients use DUIDs to 1130 identify a server in messages where a server needs to be identified. 1131 See Section 23.2 and Section 23.3 for the representation of a DUID in 1132 a DHCP message. 1134 Clients and servers MUST treat DUIDs as opaque values and MUST only 1135 compare DUIDs for equality. Clients and servers MUST NOT in any 1136 other way interpret DUIDs. Clients and servers MUST NOT restrict 1137 DUIDs to the types defined in this document, as additional DUID types 1138 may be defined in the future. 1140 The DUID is carried in an option because it may be variable length 1141 and because it is not required in all DHCP messages. The DUID is 1142 designed to be unique across all DHCP clients and servers, and stable 1143 for any specific client or server - that is, the DUID used by a 1144 client or server SHOULD NOT change over time if at all possible; for 1145 example, a device's DUID should not change as a result of a change in 1146 the device's network hardware. 1148 The motivation for having more than one type of DUID is that the DUID 1149 must be globally unique, and must also be easy to generate. The sort 1150 of globally-unique identifier that is easy to generate for any given 1151 device can differ quite widely. Also, some devices may not contain 1152 any persistent storage. Retaining a generated DUID in such a device 1153 is not possible, so the DUID scheme must accommodate such devices. 1155 10.1. DUID Contents 1157 A DUID consists of a two-octet type code represented in network byte 1158 order, followed by a variable number of octets that make up the 1159 actual identifier. The length of the DUID (not including the type 1160 code) is at least 1 octet and at most 128 octets. The following 1161 types are currently defined: 1163 +------+------------------------------------------------------+ 1164 | Type | Description | 1165 +------+------------------------------------------------------+ 1166 | 1 | Link-layer address plus time | 1167 | 2 | Vendor-assigned unique ID based on Enterprise Number | 1168 | 3 | Link-layer address | 1169 | 4 | Universally Unique IDentifier (UUID) - see [RFC6355] | 1170 +------+------------------------------------------------------+ 1172 Formats for the variable field of the DUID for the first 3 of the 1173 above types are shown below. The fourth type, DUID-UUID [RFC6355], 1174 can be used in situations where there is a UUID stored in a device's 1175 firmware settings. 1177 10.2. DUID Based on Link-layer Address Plus Time, DUID-LLT 1179 This type of DUID consists of a two octet type field containing the 1180 value 1, a two octet hardware type code, four octets containing a 1181 time value, followed by link-layer address of any one network 1182 interface that is connected to the DHCP device at the time that the 1183 DUID is generated. The time value is the time that the DUID is 1184 generated represented in seconds since midnight (UTC), January 1, 1185 2000, modulo 2^32. The hardware type MUST be a valid hardware type 1186 assigned by the IANA as described in [RFC0826]. Both the time and 1187 the hardware type are stored in network byte order. The link-layer 1188 address is stored in canonical form, as described in [RFC2464]. 1190 The following diagram illustrates the format of a DUID-LLT: 1192 0 1 2 3 1193 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 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | 1 | hardware type (16 bits) | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | time (32 bits) | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 . . 1200 . link-layer address (variable length) . 1201 . . 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 Figure 4: DUID-LLT format 1206 The choice of network interface can be completely arbitrary, as long 1207 as that interface provides a globally unique link-layer address for 1208 the link type, and the same DUID-LLT SHOULD be used in configuring 1209 all network interfaces connected to the device, regardless of which 1210 interface's link-layer address was used to generate the DUID-LLT. 1212 Clients and servers using this type of DUID MUST store the DUID-LLT 1213 in stable storage, and MUST continue to use this DUID-LLT even if the 1214 network interface used to generate the DUID-LLT is removed. Clients 1215 and servers that do not have any stable storage MUST NOT use this 1216 type of DUID. 1218 Clients and servers that use this DUID SHOULD attempt to configure 1219 the time prior to generating the DUID, if that is possible, and MUST 1220 use some sort of time source (for example, a real-time clock) in 1221 generating the DUID, even if that time source could not be configured 1222 prior to generating the DUID. The use of a time source makes it 1223 unlikely that two identical DUID-LLTs will be generated if the 1224 network interface is removed from the client and another client then 1225 uses the same network interface to generate a DUID-LLT. A collision 1226 between two DUID-LLTs is very unlikely even if the clocks have not 1227 been configured prior to generating the DUID. 1229 This method of DUID generation is recommended for all general purpose 1230 computing devices such as desktop computers and laptop computers, and 1231 also for devices such as printers, routers, and so on, that contain 1232 some form of writable non-volatile storage. 1234 Despite our best efforts, it is possible that this algorithm for 1235 generating a DUID could result in a client identifier collision. A 1236 DHCP client that generates a DUID-LLT using this mechanism MUST 1237 provide an administrative interface that replaces the existing DUID 1238 with a newly-generated DUID-LLT. 1240 10.3. DUID Assigned by Vendor Based on Enterprise Number, DUID-EN 1242 This form of DUID is assigned by the vendor to the device. It 1243 consists of the vendor's registered Private Enterprise Number as 1244 maintained by IANA [IANA-PEN] followed by a unique identifier 1245 assigned by the vendor. The following diagram summarizes the 1246 structure of a DUID-EN: 1248 0 1 2 3 1249 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 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | 2 | enterprise-number | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | enterprise-number (contd) | | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1255 . identifier . 1256 . (variable length) . 1257 . . 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 Figure 5: DUID-EN format 1262 The source of the identifier is left up to the vendor defining it, 1263 but each identifier part of each DUID-EN MUST be unique to the device 1264 that is using it, and MUST be assigned to the device no later than at 1265 the first usage and stored in some form of non-volatile storage. 1266 This typically means being assigned during manufacture process in 1267 case of physical devices or when the image is created or booted for 1268 the first time in case of virtual machines. The generated DUID 1269 SHOULD be recorded in non-erasable storage. The enterprise-number is 1270 the vendor's registered Private Enterprise Number as maintained by 1271 IANA [IANA-PEN]. The enterprise-number is stored as an unsigned 32 1272 bit number. 1274 An example DUID of this type might look like this: 1276 +---+---+---+---+---+---+---+---+ 1277 | 0 | 2 | 0 | 0 | 0 | 9| 12|192| 1278 +---+---+---+---+---+---+---+---+ 1279 |132|211| 3 | 0 | 9 | 18| 1280 +---+---+---+---+---+---+ 1282 Figure 6: DUID-EN example 1284 This example includes the two-octet type of 2, the Enterprise Number 1285 (9), followed by eight octets of identifier data 1286 (0x0CC084D303000912). 1288 10.4. DUID Based on Link-layer Address, DUID-LL 1290 This type of DUID consists of two octets containing the DUID type 3, 1291 a two octet network hardware type code, followed by the link-layer 1292 address of any one network interface that is permanently connected to 1293 the client or server device. For example, a host that has a network 1294 interface implemented in a chip that is unlikely to be removed and 1295 used elsewhere could use a DUID-LL. The hardware type MUST be a 1296 valid hardware type assigned by the IANA, as described in [RFC0826]. 1297 The hardware type is stored in network byte order. The link-layer 1298 address is stored in canonical form, as described in [RFC2464]. The 1299 following diagram illustrates the format of a DUID-LL: 1301 0 1 2 3 1302 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 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | 3 | hardware type (16 bits) | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 . . 1307 . link-layer address (variable length) . 1308 . . 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 Figure 7: DUID-LL format 1313 The choice of network interface can be completely arbitrary, as long 1314 as that interface provides a unique link-layer address and is 1315 permanently attached to the device on which the DUID-LL is being 1316 generated. The same DUID-LL SHOULD be used in configuring all 1317 network interfaces connected to the device, regardless of which 1318 interface's link-layer address was used to generate the DUID. 1320 DUID-LL is recommended for devices that have a permanently-connected 1321 network interface with a link-layer address, and do not have 1322 nonvolatile, writable stable storage. DUID-LL MUST NOT be used by 1323 DHCP clients or servers that cannot tell whether or not a network 1324 interface is permanently attached to the device on which the DHCP 1325 client is running. 1327 11. Identity Association 1329 An "identity-association" (IA) is a construct through which a server 1330 and a client can identify, group, and manage a set of related IPv6 1331 addresses or delegated prefixes. Each IA consists of an IAID and 1332 associated configuration information. 1334 The IAID uniquely identifies the IA and must be chosen to be unique 1335 among the IAIDs for that IA type on the client. The IAID is chosen 1336 by the client. For any given use of an IA by the client, the IAID 1337 for that IA MUST be consistent across restarts of the DHCP client. 1338 The client may maintain consistency either by storing the IAID in 1339 non-volatile storage or by using an algorithm that will consistently 1340 produce the same IAID as long as the configuration of the client has 1341 not changed. There may be no way for a client to maintain 1342 consistency of the IAIDs if it does not have non-volatile storage and 1343 the client's hardware configuration changes. If the client uses only 1344 one IAID, it can use a well-known value, e.g., zero. 1346 11.1. Identity Associations for Address Assignment 1348 A client must associate at least one distinct IA with each of its 1349 network interfaces for which it is to request the assignment of IPv6 1350 addresses from a DHCP server. The client uses the IAs assigned to an 1351 interface to obtain configuration information from a server for that 1352 interface. Each IA must be associated with exactly one interface. 1354 The configuration information in an IA consists of one or more IPv6 1355 addresses along with the times T1 and T2 for the IA. See 1356 Section 22.4 for the representation of an IA in a DHCP message. 1358 Each address in an IA has a preferred lifetime and a valid lifetime, 1359 as defined in [RFC4862]. The lifetimes are transmitted from the DHCP 1360 server to the client in the IA option. The lifetimes apply to the 1361 use of IPv6 addresses, as described in section 5.5.4 of [RFC4862]. 1363 11.2. Identity Associations for Prefix Delegation 1365 An IA_PD is different from an IA for address assignment, in that it 1366 does not need to be associated with exactly one interface. One IA_PD 1367 can be associated with the requesting router, with a set of 1368 interfaces or with exactly one interface. A requesting router must 1369 create at least one distinct IA_PD. It may associate a distinct 1370 IA_PD with each of its downstream network interfaces and use that 1371 IA_PD to obtain a prefix for that interface from the delegating 1372 router. 1374 The configuration information in an IA_PD consists of one or more 1375 IPv6 prefixes along with the times T1 and T2 for the IA_PD. See 1376 Section 23.21 for the representation of an IA_PD in a DHCP message. 1378 12. Selecting Addresses for Assignment to an IA 1380 A server selects addresses to be assigned to an IA according to the 1381 address assignment policies determined by the server administrator 1382 and the specific information the server determines about the client 1383 from some combination of the following sources: 1385 - The link to which the client is attached. The server determines 1386 the link as follows: 1388 * If the server receives the message directly from the client and 1389 the source address in the IP datagram in which the message was 1390 received is a link-local address, then the client is on the 1391 same link to which the interface over which the message was 1392 received is attached. 1394 * If the server receives the message from a forwarding relay 1395 agent, then the client is on the same link as the one to which 1396 the interface, identified by the link-address field in the 1397 message from the relay agent, is attached. According to 1398 [RFC6221], the server MUST ignore any link-address field whose 1399 value is zero. The link address field referes to the link- 1400 address field of the Relay-Forward message, and the link- 1401 address fields in any Relay-Forward messages that may be nested 1402 within the Relay-Forward message. 1404 * If the server receives the message directly from the client and 1405 the source address in the IP datagram in which the message was 1406 received is not a link-local address, then the client is on the 1407 link identified by the source address in the IP datagram (note 1408 that this situation can occur only if the server has enabled 1409 the use of unicast message delivery by the client and the 1410 client has sent a message for which unicast delivery is 1411 allowed). 1413 - The DUID supplied by the client. 1415 - Other information in options supplied by the client, e.g. IA 1416 Address options that include the client's requests for specific 1417 addresses. 1419 - Other information in options supplied by the relay agent. 1421 Any address assigned by a server that is based on an EUI-64 1422 identifier MUST include an interface identifier with the "u" 1423 (universal/local) and "g" (individual/group) bits of the interface 1424 identifier set appropriately, as indicated in section 2.5.1 of 1425 [RFC4291]. 1427 A server MUST NOT assign an address that is otherwise reserved for 1428 some other purpose. For example, a server MUST NOT assign reserved 1429 anycast addresses, as defined in [RFC2526], from any subnet. 1431 13. Management of Temporary Addresses 1433 A client may request the assignment of temporary addresses (see 1434 [RFC4941] for the definition of temporary addresses). DHCPv6 1435 handling of address assignment is no different for temporary 1436 addresses. 1438 Clients ask for temporary addresses and servers assign them. 1439 Temporary addresses are carried in the Identity Association for 1440 Temporary Addresses (IA_TA) option (see Section 23.5). Each IA_TA 1441 option contains at most one temporary address for each of the 1442 prefixes on the link to which the client is attached. 1444 The lifetime of the assigned temporary address is set in the IA 1445 Address Option (see Section 23.6) with in the IA_TA option. It is 1446 RECOMMENDED to set short lifetimes, typically shorter than 1447 TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME (see Section 5, 1448 [RFC4941]. 1450 The IAID number space for the IA_TA option IAID number space is 1451 separate from the IA_NA option IAID number space. 1453 A DHCPv6 server implementation MAY generate temporary addresses 1454 referring to the algorithm defined in Section 3.2.1, [RFC4941], with 1455 additional condition that the new address is not duplicated with any 1456 assigned addresses. 1458 The server MAY update the DNS for a temporary address, as described 1459 in section 4 of [RFC4941]. 1461 On the clients, by default, temporary addresses are preferred in 1462 source address selection, according to Rule 7, [RFC6724]. However, 1463 this policy is overridable. 1465 One of the most important properties of temporary address is 1466 unlinkability of different actions over time. So, it is NOT 1467 RECOMMENDED for a client to renew expired temporary addresses, though 1468 DHCPv6 provides such possibility (see Section 23.5). 1470 14. Transmission of Messages by a Client 1472 Unless otherwise specified in this document, or in a document that 1473 describes how IPv6 is carried over a specific type of link (for link 1474 types that do not support multicast), a client sends DHCP messages to 1475 the All_DHCP_Relay_Agents_and_Servers. 1477 A client uses multicast to reach all servers or an individual server. 1478 An individual server is indicated by specifying that server's DUID in 1479 a Server Identifier option (see Section 23.3) in the client's message 1480 (all servers will receive this message but only the indicated server 1481 will respond). All servers are indicated by not supplying this 1482 option. 1484 A client may send some messages directly to a server using unicast, 1485 as described in Section 23.12. 1487 14.1. Rate Limiting 1489 In order to avoid prolonged message bursts that may be caused by 1490 possible logic loops, a DHCPv6 client MUST limit the rate of DHCPv6 1491 messages it transmits. One example is that a client obtains an 1492 address, but does not like the response; it reverts back to Solicit 1493 procedure, discovers the same (sole) server, requests an address and 1494 gets the same address as before (the server still has the lease that 1495 was requested just previously). This loops can repeat infinitely if 1496 there is not a quit/stop mechanism. Therefore, a client must not 1497 initiate transmissions too frequently. 1499 A recommended method for implementing the rate limiting function is a 1500 token bucket, limiting the average rate of transmission to a certain 1501 number in a certain time. This method of bounding burstiness also 1502 guarantees that the long-term transmission rate will not exceed. 1504 TRT Transmission Rate Limit 1506 The Transmission Rate Limit parameter (TRT) SHOULD be configurable. 1507 A possible default could be 20 packets in 20 seconds. 1509 For a device that has multiple interfaces, the limit MUST be enforced 1510 on a per interface basis. 1512 Rate limiting of forwarded DHCPv6 messages and server-side messages 1513 are out of scope of this specification. 1515 15. Reliability of Client Initiated Message Exchanges 1517 DHCP clients are responsible for reliable delivery of messages in the 1518 client-initiated message exchanges described in Section 18 and 1519 Section 19. If a DHCP client fails to receive an expected response 1520 from a server, the client must retransmit its message. This section 1521 describes the retransmission strategy to be used by clients in 1522 client-initiated message exchanges. 1524 Note that the procedure described in this section is slightly 1525 modified when used with the Solicit message. The modified procedure 1526 is described in Section 18.1.2. 1528 The client begins the message exchange by transmitting a message to 1529 the server. The message exchange terminates when either the client 1530 successfully receives the appropriate response or responses from a 1531 server or servers, or when the message exchange is considered to have 1532 failed according to the retransmission mechanism described below. 1534 The client retransmission behavior is controlled and described by the 1535 following variables: 1537 RT Retransmission timeout 1539 IRT Initial retransmission time 1541 MRC Maximum retransmission count 1543 MRT Maximum retransmission time 1545 MRD Maximum retransmission duration 1547 RAND Randomization factor 1549 With each message transmission or retransmission, the client sets RT 1550 according to the rules given below. If RT expires before the message 1551 exchange terminates, the client recomputes RT and retransmits the 1552 message. 1554 Each of the computations of a new RT include a randomization factor 1555 (RAND), which is a random number chosen with a uniform distribution 1556 between -0.1 and +0.1. The randomization factor is included to 1557 minimize synchronization of messages transmitted by DHCP clients. 1559 The algorithm for choosing a random number does not need to be 1560 cryptographically sound. The algorithm SHOULD produce a different 1561 sequence of random numbers from each invocation of the DHCP client. 1563 RT for the first message transmission is based on IRT: 1565 RT = IRT + RAND*IRT 1567 RT for each subsequent message transmission is based on the previous 1568 value of RT: 1570 RT = 2*RTprev + RAND*RTprev 1572 MRT specifies an upper bound on the value of RT (disregarding the 1573 randomization added by the use of RAND). If MRT has a value of 0, 1574 there is no upper limit on the value of RT. Otherwise: 1576 if (RT > MRT) 1577 RT = MRT + RAND*MRT 1579 MRC specifies an upper bound on the number of times a client may 1580 retransmit a message. Unless MRC is zero, the message exchange fails 1581 once the client has transmitted the message MRC times. 1583 MRD specifies an upper bound on the length of time a client may 1584 retransmit a message. Unless MRD is zero, the message exchange fails 1585 once MRD seconds have elapsed since the client first transmitted the 1586 message. 1588 If both MRC and MRD are non-zero, the message exchange fails whenever 1589 either of the conditions specified in the previous two paragraphs are 1590 met. 1592 If both MRC and MRD are zero, the client continues to transmit the 1593 message until it receives a response. 1595 A client is not expected to listen for a response during the entire 1596 period between transmission of Solicit or Information-request 1597 messages. 1599 16. Message Validation 1601 Clients and servers might get messages that contain options not 1602 allowed to appear in the received message. For example, an IA option 1603 is not allowed to appear in an Information-request message. Clients 1604 and servers MAY choose either to extract information from such a 1605 message if the information is of use to the recipient, or to ignore 1606 such message completely and just drop it. 1608 A server MUST discard any Solicit, Confirm, Rebind or Information- 1609 request messages it receives with a unicast destination address. 1611 Message validation based on DHCP authentication is discussed in 1612 Section 22.4.2. 1614 If a server receives a message that contains options it should not 1615 contain (such as an Information-request message with an IA option), 1616 is missing options that it should contain, or is otherwise not valid, 1617 it MAY send a Reply (or Advertise as appropriate) with a Server 1618 Identifier option, a Client Identifier option if one was included in 1619 the message and a Status Code option with status UnSpecFail. 1621 A client or server MUST silently discard any received DHCPv6 messages 1622 with an unknown message type. 1624 16.1. Use of Transaction IDs 1626 The "transaction-id" field holds a value used by clients and servers 1627 to synchronize server responses to client messages. A client SHOULD 1628 generate a random number that cannot easily be guessed or predicted 1629 to use as the transaction ID for each new message it sends. Note 1630 that if a client generates easily predictable transaction 1631 identifiers, it may become more vulnerable to certain kinds of 1632 attacks from off-path intruders. A client MUST leave the transaction 1633 ID unchanged in retransmissions of a message. 1635 16.2. Solicit Message 1637 Clients MUST discard any received Solicit messages. 1639 Servers MUST discard any Solicit messages that do not include a 1640 Client Identifier option or that do include a Server Identifier 1641 option. 1643 16.3. Advertise Message 1645 Clients MUST discard any received Advertise message that meets any of 1646 the following conditions: 1648 - the message does not include a Server Identifier option. 1650 - the message does not include a Client Identifier option. 1652 - the contents of the Client Identifier option does not match the 1653 client's DUID. 1655 - the "transaction-id" field value does not match the value the 1656 client used in its Solicit message. 1658 Servers and relay agents MUST discard any received Advertise 1659 messages. 1661 16.4. Request Message 1663 Clients MUST discard any received Request messages. 1665 Servers MUST discard any received Request message that meets any of 1666 the following conditions: 1668 - the message does not include a Server Identifier option. 1670 - the contents of the Server Identifier option do not match the 1671 server's DUID. 1673 - the message does not include a Client Identifier option. 1675 16.5. Confirm Message 1677 Clients MUST discard any received Confirm messages. 1679 Servers MUST discard any received Confirm messages that do not 1680 include a Client Identifier option or that do include a Server 1681 Identifier option. 1683 16.6. Renew Message 1685 Clients MUST discard any received Renew messages. 1687 Servers MUST discard any received Renew message that meets any of the 1688 following conditions: 1690 - the message does not include a Server Identifier option. 1692 - the contents of the Server Identifier option does not match the 1693 server's identifier. 1695 - the message does not include a Client Identifier option. 1697 16.7. Rebind Message 1699 Clients MUST discard any received Rebind messages. 1701 Servers MUST discard any received Rebind messages that do not include 1702 a Client Identifier option or that do include a Server Identifier 1703 option. 1705 16.8. Decline Messages 1707 Clients MUST discard any received Decline messages. 1709 Servers MUST discard any received Decline message that meets any of 1710 the following conditions: 1712 - the message does not include a Server Identifier option. 1714 - the contents of the Server Identifier option does not match the 1715 server's identifier. 1717 - the message does not include a Client Identifier option. 1719 16.9. Release Message 1721 Clients MUST discard any received Release messages. 1723 Servers MUST discard any received Release message that meets any of 1724 the following conditions: 1726 - the message does not include a Server Identifier option. 1728 - the contents of the Server Identifier option does not match the 1729 server's identifier. 1731 - the message does not include a Client Identifier option. 1733 16.10. Reply Message 1735 Clients MUST discard any received Reply message that meets any of the 1736 following conditions: 1738 - the message does not include a Server Identifier option. 1740 - the "transaction-id" field in the message does not match the value 1741 used in the original message. 1743 If the client included a Client Identifier option in the original 1744 message, the Reply message MUST include a Client Identifier option 1745 and the contents of the Client Identifier option MUST match the DUID 1746 of the client; OR, if the client did not include a Client Identifier 1747 option in the original message, the Reply message MUST NOT include a 1748 Client Identifier option. 1750 Servers and relay agents MUST discard any received Reply messages. 1752 16.11. Reconfigure Message 1754 Servers and relay agents MUST discard any received Reconfigure 1755 messages. 1757 Clients MUST discard any Reconfigure message that meets any of the 1758 following conditions: 1760 - the message was not unicast to the client. 1762 - the message does not include a Server Identifier option. 1764 - the message does not include a Client Identifier option that 1765 contains the client's DUID. 1767 - the message does not contain a Reconfigure Message option. 1769 - the Reconfigure Message option msg-type is not a valid value. 1771 - the message includes any IA options and the msg-type in the 1772 Reconfigure Message option is INFORMATION-REQUEST. 1774 - the message does not include DHCP authentication: 1776 * the message does not contain an authentication option. 1778 * the message does not pass the authentication validation 1779 performed by the client. 1781 16.12. Information-request Message 1783 Clients MUST discard any received Information-request messages. 1785 Servers MUST discard any received Information-request message that 1786 meets any of the following conditions: 1788 - The message includes a Server Identifier option and the DUID in 1789 the option does not match the server's DUID. 1791 - The message includes an IA option. 1793 16.13. Relay-forward Message 1795 Clients MUST discard any received Relay-forward messages. 1797 16.14. Relay-reply Message 1799 Clients and servers MUST discard any received Relay-reply messages. 1801 17. Client Source Address and Interface Selection 1803 Client's behavior is different depending on the purpose of the 1804 configuration. 1806 17.1. Address Assignment 1808 When a client sends a DHCP message to the 1809 All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message 1810 through the interface for which configuration information is being 1811 requested. However, the client MAY send the message through another 1812 interface if the interface is a logical interface without direct link 1813 attachement or the client is certain that two interfaces are attached 1814 to the same link. 1816 When a client sends a DHCP message directly to a server using unicast 1817 (after receiving the Server Unicast option from that server), the 1818 source address in the header of the IPv6 datagram MUST be an address 1819 assigned to the interface for which the client is interested in 1820 obtaining configuration and which is suitable for use by the server 1821 in responding to the client. 1823 17.2. Prefix Delegation 1825 Delegated prefixes are not associated with a particular interface in 1826 the same way as addresses are for address assignment, and mentioned 1827 above. 1829 When a client (acting as requesting router) sends a DHCP message for 1830 the purpose of prefix delegation, it SHOULD be sent on the interface 1831 associated with the upstream router (ISP network). The upstream 1832 interface is typically determined by configuration. This rule 1833 applies even in the case where a separate IA_PD is used for each 1834 downstream interface. 1836 When a requesting router sends a DHCP message directly to a 1837 delegating router using unicast (after receiving the Server Unicast 1838 option from that delegating router), the source address SHOULD be an 1839 address from the upstream interface and which is suitable for use by 1840 the delegating router in responding to the requesting router. 1842 18. DHCP Server Solicitation 1844 This section describes how a client locates servers that will assign 1845 addresses and delegated prefixes to IAs belonging to the client. 1847 The client is responsible for creating IAs and requesting that a 1848 server assign IPv6 addresses and delegated prefixes to the IAs. The 1849 client first creates the IAs and assigns IAIDs to them. The client 1850 then transmits a Solicit message containing the IA options describing 1851 the IAs. The client MUST NOT be using any of the addresses or 1852 delegated prefixes for which it tries to obtain the bindings by 1853 sending the Solicit message. In particular, if the client had some 1854 valid bindings and has chosen to start the server solicitation 1855 process to obtain the bindings from a different server, the client 1856 MUST stop using the addresses and delegated prefixes for the bindings 1857 it had obtained from the previous server, and which it is now trying 1858 to obtain from a new server. 1860 Servers that can assign addresses or delegated prefixes to the IAs 1861 respond to the client with an Advertise message. The client then 1862 initiates a configuration exchange as described in Section 19. 1864 If the client will accept a Reply message with committed address 1865 assignments and other resources in response to the Solicit message, 1866 the client includes a Rapid Commit option (see Section 23.14) in the 1867 Solicit message. 1869 18.1. Client Behavior 1871 A client uses the Solicit message to discover DHCP servers configured 1872 to assign addresses or return other configuration parameters on the 1873 link to which the client is attached. 1875 18.1.1. Creation of Solicit Messages 1877 The client sets the "msg-type" field to SOLICIT. The client 1878 generates a transaction ID and inserts this value in the 1879 "transaction-id" field. 1881 The client MUST include a Client Identifier option to identify itself 1882 to the server. The client includes IA options for any IAs to which 1883 it wants the server to assign addresses. The client MAY include 1884 addresses in the IAs as a hint to the server about addresses for 1885 which the client has a preference. The client MUST NOT include any 1886 other options in the Solicit message, except as specifically allowed 1887 in the definition of individual options. 1889 The client uses IA_NA options to request the assignment of non- 1890 temporary addresses and uses IA_TA options to request the assignment 1891 of temporary addresses. Either IA_NA or IA_TA options, or a 1892 combination of both, can be included in DHCP messages. 1894 The client MUST include an Option Request option (see Section 23.7) 1895 to request the SOL_MAX_RT option (see Section 23.23) and any other 1896 options the client is interested in receiving. The client MAY 1897 additionally include instances of those options that are identified 1898 in the Option Request option, with data values as hints to the server 1899 about parameter values the client would like to have returned. 1901 The client includes a Reconfigure Accept option (see Section 23.20) 1902 if the client is willing to accept Reconfigure messages from the 1903 server. 1905 18.1.2. Transmission of Solicit Messages 1907 The first Solicit message from the client on the interface MUST be 1908 delayed by a random amount of time between 0 and SOL_MAX_DELAY. In 1909 the case of a Solicit message transmitted when DHCP is initiated by 1910 IPv6 Neighbor Discovery, the delay gives the amount of time to wait 1911 after IPv6 Neighbor Discovery causes the client to invoke the 1912 stateful address autoconfiguration protocol (see section 5.5.3 of 1913 [RFC4862]). This random delay desynchronizes clients which start at 1914 the same time (for example, after a power outage). 1916 The client transmits the message according to Section 15, using the 1917 following parameters: 1919 IRT SOL_TIMEOUT 1921 MRT SOL_MAX_RT 1923 MRC 0 1925 MRD 0 1927 If the client has included a Rapid Commit option in its Solicit 1928 message, the client terminates the waiting process as soon as a Reply 1929 message with a Rapid Commit option is received. 1931 If the client is waiting for an Advertise message, the mechanism in 1932 Section 15 is modified as follows for use in the transmission of 1933 Solicit messages. The message exchange is not terminated by the 1934 receipt of an Advertise before the first RT has elapsed. Rather, the 1935 client collects Advertise messages until the first RT has elapsed. 1937 Also, the first RT MUST be selected to be strictly greater than IRT 1938 by choosing RAND to be strictly greater than 0. 1940 A client MUST collect Advertise messages for the first RT seconds, 1941 unless it receives an Advertise message with a preference value of 1942 255. The preference value is carried in the Preference option 1943 (Section 23.8). Any Advertise that does not include a Preference 1944 option is considered to have a preference value of 0. If the client 1945 receives an Advertise message that includes a Preference option with 1946 a preference value of 255, the client immediately begins a client- 1947 initiated message exchange (as described in Section 19) by sending a 1948 Request message to the server from which the Advertise message was 1949 received. If the client receives an Advertise message that does not 1950 include a Preference option with a preference value of 255, the 1951 client continues to wait until the first RT elapses. If the first RT 1952 elapses and the client has received an Advertise message, the client 1953 SHOULD continue with a client-initiated message exchange by sending a 1954 Request message. 1956 If the client does not receive any Advertise messages before the 1957 first RT has elapsed, it begins the retransmission mechanism 1958 described in Section 15. The client terminates the retransmission 1959 process as soon as it receives any Advertise message, and the client 1960 acts on the received Advertise message without waiting for any 1961 additional Advertise messages. 1963 A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client 1964 is configured with either MRC or MRD set to a value other than 0, it 1965 MUST stop trying to configure the interface if the message exchange 1966 fails. After the DHCP client stops trying to configure the 1967 interface, it SHOULD restart the reconfiguration process after some 1968 external event, such as user input, system restart, or when the 1969 client is attached to a new link. 1971 18.1.3. Receipt of Advertise Messages 1973 The client MUST process SOL_MAX_RT and INF_MAX_RT options in an 1974 Advertise message, even if the message contains a Status Code option 1975 indicating a failure, and the Advertise message will be discarded by 1976 the client. 1978 The client MUST ignore any IAs in an Advertise message that include a 1979 Status Code option containing the value NoAddrsAvail, with the 1980 exception that the client MAY display the associated status message 1981 to the user. 1983 Upon receipt of one or more valid Advertise messages, the client 1984 selects one or more Advertise messages based upon the following 1985 criteria. 1987 - Those Advertise messages with the highest server preference value 1988 are preferred over all other Advertise messages. 1990 - Within a group of Advertise messages with the same server 1991 preference value, a client MAY select those servers whose 1992 Advertise messages advertise information of interest to the 1993 client. 1995 - The client MAY choose a less-preferred server if that server has a 1996 better set of advertised parameters, such as the available 1997 addresses advertised in IAs. 1999 Once a client has selected Advertise message(s), the client will 2000 typically store information about each server, such as server 2001 preference value, addresses advertised, when the advertisement was 2002 received, and so on. 2004 In practice, this means that the client will maintain independent 2005 per-IA state machines per each selected server. 2007 If the client needs to select an alternate server in the case that a 2008 chosen server does not respond, the client chooses the next server 2009 according to the criteria given above. 2011 18.1.4. Receipt of Reply Message 2013 If the client includes a Rapid Commit option in the Solicit message, 2014 it will expect a Reply message that includes a Rapid Commit option in 2015 response. The client discards any Reply messages it receives that do 2016 not include a Rapid Commit option. If the client receives a valid 2017 Reply message that includes a Rapid Commit option, it processes the 2018 message as described in Section 19.1.8. If it does not receive such 2019 a Reply message and does receive a valid Advertise message, the 2020 client processes the Advertise message as described in 2021 Section 18.1.3. 2023 If the client subsequently receives a valid Reply message that 2024 includes a Rapid Commit option, it either: 2026 - processes the Reply message as described in Section 19.1.8, and 2027 discards any Reply messages received in response to the Request 2028 message, or 2030 - processes any Reply messages received in response to the Request 2031 message and discards the Reply message that includes the Rapid 2032 Commit option. 2034 18.2. Server Behavior 2036 A server sends an Advertise message in response to valid Solicit 2037 messages it receives to announce the availability of the server to 2038 the client. 2040 18.2.1. Receipt of Solicit Messages 2042 The server determines the information about the client and its 2043 location as described in Section 12 and checks its administrative 2044 policy about responding to the client. If the server is not 2045 permitted to respond to the client, the server discards the Solicit 2046 message. For example, if the administrative policy for the server is 2047 that it may only respond to a client that is willing to accept a 2048 Reconfigure message, if the client does not include a Reconfigure 2049 Accept option (see Section 23.20) in the Solicit message, the servers 2050 discard the Solicit message. 2052 If the client has included a Rapid Commit option in the Solicit 2053 message and the server has been configured to respond with committed 2054 address assignments and other resources, the server responds to the 2055 Solicit with a Reply message as described in Section 18.2.3. 2056 Otherwise, the server ignores the Rapid Commit option and processes 2057 the remainder of the message as if no Rapid Commit option were 2058 present. 2060 18.2.2. Creation and Transmission of Advertise Messages 2062 The server sets the "msg-type" field to ADVERTISE and copies the 2063 contents of the transaction-id field from the Solicit message 2064 received from the client to the Advertise message. The server 2065 includes its server identifier in a Server Identifier option and 2066 copies the Client Identifier from the Solicit message into the 2067 Advertise message. 2069 The server MAY add a Preference option to carry the preference value 2070 for the Advertise message. The server implementation SHOULD allow 2071 the setting of a server preference value by the administrator. The 2072 server preference value MUST default to zero unless otherwise 2073 configured by the server administrator. 2075 The server includes a Reconfigure Accept option if the server wants 2076 to require that the client accept Reconfigure messages. 2078 The server includes options the server will return to the client in a 2079 subsequent Reply message. The information in these options may be 2080 used by the client in the selection of a server if the client 2081 receives more than one Advertise message. If the client has included 2082 an Option Request option in the Solicit message, the server includes 2083 options in the Advertise message containing configuration parameters 2084 for all of the options identified in the Option Request option that 2085 the server has been configured to return to the client. The server 2086 MAY return additional options to the client if it has been configured 2087 to do so. The server must be aware of the recommendations on packet 2088 sizes and the use of fragmentation in section 5 of [RFC2460]. 2090 If the Solicit message from the client included one or more IA 2091 options, the server MUST include IA options in the Advertise message 2092 containing any addresses that would be assigned to IAs contained in 2093 the Solicit message from the client. If the client has included 2094 addresses in the IAs in the Solicit message, the server uses those 2095 addresses as hints about the addresses the client would like to 2096 receive. 2098 If the server will not assign any addresses to any IAs in a 2099 subsequent Request from the client, the server MUST send an Advertise 2100 message to the client that includes only a Status Code option with 2101 code NoAddrsAvail and a status message for the user, a Server 2102 Identifier option with the server's DUID, a Client Identifier option 2103 with the client's DUID, and (optionally) SOL_MAX_RT and/or INF_MAX_RT 2104 options. The server SHOULD include other stateful IA options (like 2105 IA_PD) and other configuration options in the Advertise message. 2107 If the Solicit message was received directly by the server, the 2108 server unicasts the Advertise message directly to the client using 2109 the address in the source address field from the IP datagram in which 2110 the Solicit message was received. The Advertise message MUST be 2111 unicast on the link from which the Solicit message was received. 2113 If the Solicit message was received in a Relay-forward message, the 2114 server constructs a Relay-reply message with the Advertise message in 2115 the payload of a "relay-message" option. If the Relay-forward 2116 messages included an Interface-id option, the server copies that 2117 option to the Relay-reply message. The server unicasts the Relay- 2118 reply message directly to the relay agent using the address in the 2119 source address field from the IP datagram in which the Relay-forward 2120 message was received. 2122 18.2.3. Creation and Transmission of Reply Messages 2124 The server MUST commit the assignment of any addresses or other 2125 configuration information message before sending a Reply message to a 2126 client in response to a Solicit message. 2128 DISCUSSION: 2130 When using the Solicit-Reply message exchange, the server commits 2131 the assignment of any addresses before sending the Reply message. 2132 The client can assume it has been assigned the addresses in the 2133 Reply message and does not need to send a Request message for 2134 those addresses. 2136 Typically, servers that are configured to use the Solicit-Reply 2137 message exchange will be deployed so that only one server will 2138 respond to a Solicit message. If more than one server responds, 2139 the client will only use the addresses from one of the servers, 2140 while the addresses from the other servers will be committed to 2141 the client but not used by the client. 2143 The server includes a Rapid Commit option in the Reply message to 2144 indicate that the Reply is in response to a Solicit message. 2146 The server includes a Reconfigure Accept option if the server wants 2147 to require that the client accept Reconfigure messages. 2149 The server produces the Reply message as though it had received a 2150 Request message, as described in Section 19.2.1. The server 2151 transmits the Reply message as described in Section 19.2.8. 2153 18.3. Client behavior for Prefix Delegation 2155 The requesting router creates and transmits a Solicit message as 2156 described in Section 18.1.1 and Section 18.1.2. The client creates 2157 an IA_PD and assigns it an IAID. The client MUST include the IA_PD 2158 option in the Solicit message. 2160 The client processes any received Advertise messages as described in 2161 Section 18.1.3. The client MAY choose to consider the presence of 2162 advertised prefixes in its decision about which delegating router to 2163 respond to. 2165 The client MUST ignore any IA_PDs in an Advertise message that 2166 include a Status Code option containing the value NoPrefixAvail, with 2167 the exception that the client MAY display the associated status 2168 message to the user and SHOULD process SOL_MAX_RT and INF_MAX_RT 2169 options. 2171 18.4. Server Behavior for Prefix Delegation 2173 The server sends an Advertise message to the requesting router in the 2174 same way as described in Section 18.2.2. If the message contains an 2175 IA_PD option and the delegating router is configured to delegate 2176 prefix(es) to the requesting router, the delegating router selects 2177 the prefix(es) to be delegated to the requesting router. The 2178 mechanism through which the delegating router selects prefix(es) for 2179 delegation is not specified in this document. Examples of ways in 2180 which the server might select prefix(es) for a client include: static 2181 assignment based on subscription to an ISP; dynamic assignment from a 2182 pool of available prefixes; selection based on an external authority 2183 such as a RADIUS server using the Framed-IPv6-Prefix option as 2184 described in [RFC3162]. 2186 If the client includes an IA_PD Prefix option in the IA_PD option in 2187 its Solicit message, the server MAY choose to use the information in 2188 that option to select the prefix(es) or prefix size to be delegated 2189 to the client. 2191 The server sends an Advertise message to the requesting router in the 2192 same way as described in Section 18.2.2. The server MUST include an 2193 IA_PD option, identifying any prefix(es) that the server will 2194 delegate to the client. 2196 If the server will not assign any prefixes to an IA_PD in a 2197 subsequent Request from the requesting router, the server MUST send 2198 an Advertise message to the client that includes the IA_PD with no 2199 prefixes in the IA_PD and a Status Code option in the IA_PD 2200 containing status code NoPrefixAvail and a status message for the 2201 user, a Server Identifier option with the server's DUID and a Client 2202 Identifier option with the client's DUID. The server SHOULD include 2203 other stateful IA options (like IA_NA) and other configuration 2204 options in the Advertise message. 2206 19. DHCP Client-Initiated Configuration Exchange 2208 A client initiates a message exchange with a server or servers to 2209 acquire or update configuration information of interest. The client 2210 may initiate the configuration exchange as part of the operating 2211 system configuration process, when requested to do so by the 2212 application layer, when required by Stateless Address 2213 Autoconfiguration or as required to extend the lifetime of 2214 address(es) or/and delegated prefix(es), using Renew and Rebind 2215 messages. 2217 According to a terminology for the prefix delegation, a client 2218 requesting a delegation of a prefix is referred to as a requesting 2219 router and a server delegating the prefix is referred to as a 2220 delegating router. The requesting router and the delegating router 2221 use the IA_PD Prefix option to exchange information about prefix(es) 2222 in much the same way as IA Address options are used for assigned 2223 addresses. Typically, a single DHCP session is used to exchange 2224 information about addresses and prefixes, i.e. IA_NA and IA_PD 2225 options are carried in the same message. 2227 19.1. Client Behavior 2229 A client uses Request, Renew, Rebind, Release and Decline messages 2230 during the normal life cycle of addresses. It uses Confirm to 2231 validate addresses when it may have moved to a new link. It uses 2232 Information-Request messages when it needs configuration information 2233 but no addresses. 2235 If the client has a source address of sufficient scope that can be 2236 used by the server as a return address, and the client has received a 2237 Server Unicast option (Section 23.12) from the server, the client 2238 SHOULD unicast any Request, Renew, Release and Decline messages to 2239 the server. 2241 DISCUSSION: 2243 Use of unicast may avoid delays due to the relaying of messages by 2244 relay agents, as well as avoid overhead and duplicate responses by 2245 servers due to the delivery of client messages to multiple 2246 servers. Requiring the client to relay all DHCP messages through 2247 a relay agent enables the inclusion of relay agent options in all 2248 messages sent by the client. The server should enable the use of 2249 unicast only when relay agent options will not be used. 2251 19.1.1. Creation and Transmission of Request Messages 2253 The client uses a Request message to populate IAs with addresses and 2254 obtain other configuration information. The client includes one or 2255 more IA options in the Request message. The server then returns 2256 addresses and other information about the IAs to the client in IA 2257 options in a Reply message. 2259 The client generates a transaction ID and inserts this value in the 2260 "transaction-id" field. 2262 The client places the identifier of the destination server in a 2263 Server Identifier option. 2265 The client MUST include a Client Identifier option to identify itself 2266 to the server. The client adds any other appropriate options, 2267 including one or more IA options (if the client is requesting that 2268 the server assign it some network addresses). 2270 The client MUST include an Option Request option (see Section 23.7) 2271 to indicate the options the client is interested in receiving. The 2272 client MAY include options with data values as hints to the server 2273 about parameter values the client would like to have returned. 2275 The client includes a Reconfigure Accept option (see Section 23.20) 2276 indicating whether or not the client is willing to accept Reconfigure 2277 messages from the server. 2279 The client transmits the message according to Section 15, using the 2280 following parameters: 2282 IRT REQ_TIMEOUT 2284 MRT REQ_MAX_RT 2286 MRC REQ_MAX_RC 2288 MRD 0 2290 If the message exchange fails, the client takes an action based on 2291 the client's local policy. Examples of actions the client might take 2292 include: 2294 - Select another server from a list of servers known to the client; 2295 for example, servers that responded with an Advertise message. 2297 - Initiate the server discovery process described in Section 18. 2299 - Terminate the configuration process and report failure. 2301 19.1.2. Creation and Transmission of Confirm Messages 2303 Whenever a client may have moved to a new link, the prefixes/ 2304 addresses assigned to the interfaces on that link may no longer be 2305 appropriate for the link to which the client is attached. Examples 2306 of times when a client may have moved to a new link include: 2308 o The client reboots. 2310 o The client is physically connected to a wired connection. 2312 o The client returns from sleep mode. 2314 o The client using a wireless technology changes access points. 2316 In any situation when a client may have moved to a new link, the 2317 client SHOULD initiate a Confirm/Reply message exchange. The client 2318 includes any IAs assigned to the interface that may have moved to a 2319 new link, along with the addresses associated with those IAs, in its 2320 Confirm message. Any responding servers will indicate whether those 2321 addresses are appropriate for the link to which the client is 2322 attached with the status in the Reply message it returns to the 2323 client. 2325 One example when this rule may not be followed is when the client 2326 does not store its leases in stable storage and experiences a reboot. 2327 It may simply not retain any information, so it does not know what to 2328 confirm. In such case client MUST restart server discovery process 2329 as described in Section 18.1.1. 2331 The client sets the "msg-type" field to CONFIRM. The client 2332 generates a transaction ID and inserts this value in the 2333 "transaction-id" field. 2335 The client MUST include a Client Identifier option to identify itself 2336 to the server. The client includes IA options for all of the IAs 2337 assigned to the interface for which the Confirm message is being 2338 sent. The IA options include all of the addresses the client 2339 currently has associated with those IAs. The client SHOULD set the 2340 T1 and T2 fields in any IA_NA options, and the preferred-lifetime and 2341 valid-lifetime fields in the IA Address options to 0, as the server 2342 will ignore these fields. 2344 The first Confirm message from the client on the interface MUST be 2345 delayed by a random amount of time between 0 and CNF_MAX_DELAY. The 2346 client transmits the message according to Section 15, using the 2347 following parameters: 2349 IRT CNF_TIMEOUT 2351 MRT CNF_MAX_RT 2353 MRC 0 2355 MRD CNF_MAX_RD 2357 If the client receives no responses before the message transmission 2358 process terminates, as described in Section 15, the client SHOULD 2359 continue to use any IP addresses, using the last known lifetimes for 2360 those addresses, and SHOULD continue to use any other previously 2361 obtained configuration parameters. 2363 19.1.3. Creation and Transmission of Renew Messages 2365 To extend the valid and preferred lifetimes for the addresses 2366 associated with an IA, the client sends a Renew message to the server 2367 from which the client obtained the addresses in the IA containing an 2368 IA option for the IA. The client includes IA Address options in the 2369 IA option for the addresses associated with the IA. The server 2370 determines new lifetimes for the addresses in the IA according to the 2371 administrative configuration of the server. The server may also add 2372 new addresses to the IA. The server may remove addresses from the IA 2373 by setting the preferred and valid lifetimes of those addresses to 2374 zero. 2376 The server controls the time at which the client contacts the server 2377 to extend the lifetimes on assigned addresses through the T1 and T2 2378 parameters assigned to an IA. 2380 At time T1 for an IA, the client initiates a Renew/Reply message 2381 exchange to extend the lifetimes on any addresses in the IA. The 2382 client includes an IA option with all addresses currently assigned to 2383 the IA in its Renew message. 2385 If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no 2386 T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind 2387 message, respectively, at the client's discretion. 2389 The client sets the "msg-type" field to RENEW. The client generates 2390 a transaction ID and inserts this value in the "transaction-id" 2391 field. 2393 The client places the identifier of the destination server in a 2394 Server Identifier option. 2396 The client MUST include a Client Identifier option to identify itself 2397 to the server. The client adds any appropriate options, including 2398 one or more IA options. The client MUST include the list of 2399 addresses the client currently has associated with the IAs in the 2400 Renew message. 2402 The client MUST include an Option Request option (see Section 23.7) 2403 to indicate the options the client is interested in receiving. The 2404 client MAY include options with data values as hints to the server 2405 about parameter values the client would like to have returned. 2407 The client transmits the message according to Section 15, using the 2408 following parameters: 2410 IRT REN_TIMEOUT 2411 MRT REN_MAX_RT 2413 MRC 0 2415 MRD Remaining time until T2 2417 The message exchange is terminated when time T2 is reached (see 2418 Section 19.1.4), at which time the client begins a Rebind message 2419 exchange. 2421 19.1.4. Creation and Transmission of Rebind Messages 2423 At time T2 for an IA (which will only be reached if the server to 2424 which the Renew message was sent at time T1 has not responded), the 2425 client initiates a Rebind/Reply message exchange with any available 2426 server. The client includes an IA option with all addresses 2427 currently assigned to the IA in its Rebind message. 2429 The client sets the "msg-type" field to REBIND. The client generates 2430 a transaction ID and inserts this value in the "transaction-id" 2431 field. 2433 The client MUST include a Client Identifier option to identify itself 2434 to the server. The client adds any appropriate options, including 2435 one or more IA options. The client MUST include the list of 2436 addresses the client currently has associated with the IAs in the 2437 Rebind message. 2439 The client MUST include an Option Request option (see Section 23.7) 2440 to indicate the options the client is interested in receiving. The 2441 client MAY include options with data values as hints to the server 2442 about parameter values the client would like to have returned. 2444 The client transmits the message according to Section 15, using the 2445 following parameters: 2447 IRT REB_TIMEOUT 2449 MRT REB_MAX_RT 2451 MRC 0 2453 MRD Remaining time until valid lifetimes of all addresses have 2454 expired 2456 The message exchange is terminated when the valid lifetimes of all 2457 the addresses assigned to the IA expire (see Section 11), at which 2458 time the client has several alternative actions to choose from; for 2459 example: 2461 - The client may choose to use a Solicit message to locate a new 2462 DHCP server and send a Request for the expired IA to the new 2463 server. 2465 - The client may have other addresses in other IAs, so the client 2466 may choose to discard the expired IA and use the addresses in the 2467 other IAs. 2469 19.1.5. Creation and Transmission of Information-request Messages 2471 The client uses an Information-request message to obtain 2472 configuration information without having addresses assigned to it. 2474 The client sets the "msg-type" field to INFORMATION-REQUEST. The 2475 client generates a transaction ID and inserts this value in the 2476 "transaction-id" field. 2478 The client SHOULD include a Client Identifier option to identify 2479 itself to the server. If the client does not include a Client 2480 Identifier option, the server will not be able to return any client- 2481 specific options to the client, or the server may choose not to 2482 respond to the message at all. The client MUST include a Client 2483 Identifier option if the Information-Request message will be 2484 authenticated. 2486 The client MUST include an Option Request option (see Section 23.7) 2487 to request the INF_MAX_RT option (see Section 23.24) and any other 2488 options the client is interested in receiving. The client MAY 2489 include options with data values as hints to the server about 2490 parameter values the client would like to have returned. 2492 The first Information-request message from the client on the 2493 interface MUST be delayed by a random amount of time between 0 and 2494 INF_MAX_DELAY. The client transmits the message according to 2495 Section 15, using the following parameters: 2497 IRT INF_TIMEOUT 2499 MRT INF_MAX_RT 2501 MRC 0 2503 MRD 0 2505 19.1.6. Creation and Transmission of Release Messages 2507 To release one or more addresses, a client sends a Release message to 2508 the server. 2510 The client sets the "msg-type" field to RELEASE. The client 2511 generates a transaction ID and places this value in the "transaction- 2512 id" field. 2514 The client places the identifier of the server that allocated the 2515 address(es) in a Server Identifier option. 2517 The client MUST include a Client Identifier option to identify itself 2518 to the server. The client includes options containing the IAs for 2519 the addresses it is releasing in the "options" field. The addresses 2520 to be released MUST be included in the IAs. Any addresses for the 2521 IAs the client wishes to continue to use MUST NOT be added to the 2522 IAs. 2524 The client MUST NOT use any of the addresses it is releasing as the 2525 source address in the Release message or in any subsequently 2526 transmitted message. 2528 Because Release messages may be lost, the client should retransmit 2529 the Release if no Reply is received. However, there are scenarios 2530 where the client may not wish to wait for the normal retransmission 2531 timeout before giving up (e.g., on power down). Implementations 2532 SHOULD retransmit one or more times, but MAY choose to terminate the 2533 retransmission procedure early. 2535 The client transmits the message according to Section 15, using the 2536 following parameters: 2538 IRT REL_TIMEOUT 2540 MRT 0 2542 MRC REL_MAX_RC 2544 MRD 0 2546 The client MUST stop using all of the addresses being released as 2547 soon as the client begins the Release message exchange process. If 2548 addresses are released but the Reply from a DHCP server is lost, the 2549 client will retransmit the Release message, and the server may 2550 respond with a Reply indicating a status of NoBinding. Therefore, 2551 the client does not treat a Reply message with a status of NoBinding 2552 in a Release message exchange as if it indicates an error. 2554 Note that if the client fails to release the addresses, each address 2555 assigned to the IA will be reclaimed by the server when the valid 2556 lifetime of that address expires. 2558 19.1.7. Creation and Transmission of Decline Messages 2560 If a client detects that one or more addresses assigned to it by a 2561 server are already in use by another node, the client sends a Decline 2562 message to the server to inform it that the address is suspect. 2564 The client sets the "msg-type" field to DECLINE. The client 2565 generates a transaction ID and places this value in the "transaction- 2566 id" field. 2568 The client places the identifier of the server that allocated the 2569 address(es) in a Server Identifier option. 2571 The client MUST include a Client Identifier option to identify itself 2572 to the server. The client includes options containing the IAs for 2573 the addresses it is declining in the "options" field. The addresses 2574 to be declined MUST be included in the IAs. Any addresses for the 2575 IAs the client wishes to continue to use should not be in added to 2576 the IAs. 2578 The client MUST NOT use any of the addresses it is declining as the 2579 source address in the Decline message or in any subsequently 2580 transmitted message. 2582 The client transmits the message according to Section 15, using the 2583 following parameters: 2585 IRT DEC_TIMEOUT 2587 MRT 0 2589 MRC DEC_MAX_RC 2591 MRD 0 2593 If addresses are declined but the Reply from a DHCP server is lost, 2594 the client will retransmit the Decline message, and the server may 2595 respond with a Reply indicating a status of NoBinding. Therefore, 2596 the client does not treat a Reply message with a status of NoBinding 2597 in a Decline message exchange as if it indicates an error. 2599 19.1.8. Receipt of Reply Messages 2601 Upon the receipt of a valid Reply message in response to a Solicit 2602 (with a Rapid Commit option), Request, Confirm, Renew, Rebind or 2603 Information-request message, the client extracts the configuration 2604 information contained in the Reply. The client MAY choose to report 2605 any status code or message from the status code option in the Reply 2606 message. 2608 The client SHOULD perform duplicate address detection [RFC4862] on 2609 each of the addresses in any IAs it receives in the Reply message 2610 before using that address for traffic. If any of the addresses are 2611 found to be in use on the link, the client sends a Decline message to 2612 the server as described in Section 19.1.7. 2614 If the Reply was received in response to a Solicit (with a Rapid 2615 Commit option), Request, Renew or Rebind message, the client updates 2616 the information it has recorded about IAs from the IA options 2617 contained in the Reply message: 2619 - Record T1 and T2 times. 2621 - Add any new addresses in the IA option to the IA as recorded by 2622 the client. 2624 - Update lifetimes for any addresses in the IA option that the 2625 client already has recorded in the IA. 2627 - Discard any addresses from the IA, as recorded by the client, that 2628 have a valid lifetime of 0 in the IA Address option. 2630 - Leave unchanged any information about addresses the client has 2631 recorded in the IA but that were not included in the IA from the 2632 server. 2634 Management of the specific configuration information is detailed in 2635 the definition of each option in Section 23. 2637 If the client receives a Reply message with a Status Code containing 2638 UnspecFail, the server is indicating that it was unable to process 2639 the message due to an unspecified failure condition. If the client 2640 retransmits the original message to the same server to retry the 2641 desired operation, the client MUST limit the rate at which it 2642 retransmits the message and limit the duration of the time during 2643 which it retransmits the message (see Section 14.1). 2645 When the client receives a Reply message with a Status Code option 2646 with the value UseMulticast, the client records the receipt of the 2647 message and sends subsequent messages to the server through the 2648 interface on which the message was received using multicast. The 2649 client resends the original message using multicast. 2651 When the client receives a NotOnLink status from the server in 2652 response to a Confirm message, the client performs DHCP server 2653 solicitation, as described in Section 18, and client-initiated 2654 configuration as described in Section 19. If the client receives any 2655 Reply messages that do not indicate a NotOnLink status, the client 2656 can use the addresses in the IA and ignore any messages that indicate 2657 a NotOnLink status. 2659 When the client receives a NotOnLink status from the server in 2660 response to a Solicit (with a Rapid Commit option) or a Request, the 2661 client can either re-issue the Request without specifying any 2662 addresses or restart the DHCP server discovery process (see 2663 Section 18). 2665 The client examines the status code in each IA individually. If the 2666 status code is NoAddrsAvail, the client has received no usable 2667 addresses in the IA and may choose to try obtaining addresses for the 2668 IA from another server. The client uses addresses and other 2669 information from any IAs that do not contain a Status Code option 2670 with the NoAddrsAvail code. If the client receives no addresses in 2671 any of the IAs, it may either try another server (perhaps restarting 2672 the DHCP server discovery process) or use the Information-request 2673 message to obtain other configuration information only. 2675 Whenever a client restarts the DHCP server discovery process or 2676 selects an alternate server, as described in Section 18.1.3, the 2677 client SHOULD stop using all the addresses and delegated prefixes for 2678 which it has the bindings and try to obtain all required adresses and 2679 prefixes from the new server. This facilitates the client using a 2680 single state machine for all bindings. 2682 When the client receives a Reply message in response to a Renew or 2683 Rebind message, the client examines each IA independently. For each 2684 IA in the original Renew or Rebind message, the client: 2686 - sends a Request message if the IA contained a Status Code option 2687 with the NoBinding status (and does not send any additional Renew/ 2688 Rebind messages) 2690 - sends a Renew/Rebind if the IA is not in the Reply message 2692 - otherwise accepts the information in the IA 2693 When the client receives a valid Reply message in response to a 2694 Release message, the client considers the Release event completed, 2695 regardless of the Status Code option(s) returned by the server. 2697 When the client receives a valid Reply message in response to a 2698 Decline message, the client considers the Decline event completed, 2699 regardless of the Status Code option(s) returned by the server. 2701 19.2. Server Behavior 2703 For this discussion, the Server is assumed to have been configured in 2704 an implementation specific manner with configuration of interest to 2705 clients. 2707 In most instances, the server will send a Reply in response to a 2708 client message. This Reply message MUST always contain the Server 2709 Identifier option containing the server's DUID and the Client 2710 Identifier option from the client message if one was present. 2712 In most Reply messages, the server includes options containing 2713 configuration information for the client. The server must be aware 2714 of the recommendations on packet sizes and the use of fragmentation 2715 in section 5 of [RFC2460]. If the client included an Option Request 2716 option in its message, the server includes options in the Reply 2717 message containing configuration parameters for all of the options 2718 identified in the Option Request option that the server has been 2719 configured to return to the client. The server MAY return additional 2720 options to the client if it has been configured to do so. 2722 19.2.1. Receipt of Request Messages 2724 When the server receives a Request message via unicast from a client 2725 to which the server has not sent a unicast option, the server 2726 discards the Request message and responds with a Reply message 2727 containing a Status Code option with the value UseMulticast, a Server 2728 Identifier option containing the server's DUID, the Client Identifier 2729 option from the client message, and no other options. 2731 When the server receives a valid Request message, the server creates 2732 the bindings for that client according to the server's policy and 2733 configuration information and records the IAs and other information 2734 requested by the client. 2736 The server constructs a Reply message by setting the "msg-type" field 2737 to REPLY, and copying the transaction ID from the Request message 2738 into the transaction-id field. 2740 The server MUST include a Server Identifier option containing the 2741 server's DUID and the Client Identifier option from the Request 2742 message in the Reply message. 2744 If the server finds that the prefix on one or more IP addresses in 2745 any IA in the message from the client is not appropriate for the link 2746 to which the client is connected, the server MUST return the IA to 2747 the client with a Status Code option with the value NotOnLink. 2749 If the server cannot assign any addresses to an IA in the message 2750 from the client, the server MUST include the IA in the Reply message 2751 with no addresses in the IA and a Status Code option in the IA 2752 containing status code NoAddrsAvail. 2754 For any IAs to which the server can assign addresses, the server 2755 includes the IA with addresses and other configuration parameters, 2756 and records the IA as a new client binding. 2758 The server includes a Reconfigure Accept option if the server wants 2759 to require that the client accept Reconfigure messages. 2761 The server includes other options containing configuration 2762 information to be returned to the client as described in 2763 Section 19.2. 2765 If the server finds that the client has included an IA in the Request 2766 message for which the server already has a binding that associates 2767 the IA with the client, the client has resent a Request message for 2768 which it did not receive a Reply message. The server either resends 2769 a previously cached Reply message or sends a new Reply message. 2771 19.2.2. Receipt of Confirm Messages 2773 When the server receives a Confirm message, the server determines 2774 whether the addresses in the Confirm message are appropriate for the 2775 link to which the client is attached. If all of the addresses in the 2776 Confirm message pass this test, the server returns a status of 2777 Success. If any of the addresses do not pass this test, the server 2778 returns a status of NotOnLink. If the server is unable to perform 2779 this test (for example, the server does not have information about 2780 prefixes on the link to which the client is connected), or there were 2781 no addresses in any of the IAs sent by the client, the server MUST 2782 NOT send a reply to the client. 2784 The server ignores the T1 and T2 fields in the IA options and the 2785 preferred-lifetime and valid-lifetime fields in the IA Address 2786 options. 2788 The server constructs a Reply message by setting the "msg-type" field 2789 to REPLY, and copying the transaction ID from the Confirm message 2790 into the transaction-id field. 2792 The server MUST include a Server Identifier option containing the 2793 server's DUID and the Client Identifier option from the Confirm 2794 message in the Reply message. The server includes a Status Code 2795 option indicating the status of the Confirm message. 2797 19.2.3. Receipt of Renew Messages 2799 When the server receives a Renew message via unicast from a client to 2800 which the server has not sent a unicast option, the server discards 2801 the Renew message and responds with a Reply message containing a 2802 Status Code option with the value UseMulticast, a Server Identifier 2803 option containing the server's DUID, the Client Identifier option 2804 from the client message, and no other options. 2806 When the server receives a Renew message that contains an IA option 2807 from a client, it locates the client's binding and verifies that the 2808 information in the IA from the client matches the information stored 2809 for that client. 2811 If the server cannot find a client entry for the IA the server 2812 returns the IA containing no addresses with a Status Code option set 2813 to NoBinding in the Reply message. 2815 If the server finds that any of the addresses are not appropriate for 2816 the link to which the client is attached, the server returns the 2817 address to the client with lifetimes of 0. 2819 If the server finds the addresses in the IA for the client then the 2820 server sends back the IA to the client with new lifetimes and T1/T2 2821 times. The server may choose to change the list of addresses and the 2822 lifetimes of addresses in IAs that are returned to the client. 2824 The server constructs a Reply message by setting the "msg-type" field 2825 to REPLY, and copying the transaction ID from the Renew message into 2826 the transaction-id field. 2828 The server MUST include a Server Identifier option containing the 2829 server's DUID and the Client Identifier option from the Renew message 2830 in the Reply message. 2832 The server includes other options containing configuration 2833 information to be returned to the client as described in 2834 Section 19.2. 2836 19.2.4. Receipt of Rebind Messages 2838 When the server receives a Rebind message that contains an IA option 2839 from a client, it locates the client's binding and verifies that the 2840 information in the IA from the client matches the information stored 2841 for that client. 2843 If the server cannot find a client entry for the IA and the server 2844 determines that the addresses in the IA are not appropriate for the 2845 link to which the client's interface is attached according to the 2846 server's explicit configuration information, the server MAY send a 2847 Reply message to the client containing the client's IA, with the 2848 lifetimes for the addresses in the IA set to zero. This Reply 2849 constitutes an explicit notification to the client that the addresses 2850 in the IA are no longer valid. In this situation, if the server does 2851 not send a Reply message it discards the Rebind message. 2853 If the server finds that any of the addresses are no longer 2854 appropriate for the link to which the client is attached, the server 2855 returns the address to the client with lifetimes of 0. 2857 If the server finds the addresses in the IA for the client then the 2858 server SHOULD send back the IA to the client with new lifetimes and 2859 T1/T2 times. 2861 The server constructs a Reply message by setting the "msg-type" field 2862 to REPLY, and copying the transaction ID from the Rebind message into 2863 the transaction-id field. 2865 The server MUST include a Server Identifier option containing the 2866 server's DUID and the Client Identifier option from the Rebind 2867 message in the Reply message. 2869 The server includes other options containing configuration 2870 information to be returned to the client as described in 2871 Section 19.2. 2873 19.2.5. Receipt of Information-request Messages 2875 When the server receives an Information-request message, the client 2876 is requesting configuration information that does not include the 2877 assignment of any addresses. The server determines all configuration 2878 parameters appropriate to the client, based on the server 2879 configuration policies known to the server. 2881 The server constructs a Reply message by setting the "msg-type" field 2882 to REPLY, and copying the transaction ID from the Information-request 2883 message into the transaction-id field. 2885 The server MUST include a Server Identifier option containing the 2886 server's DUID in the Reply message. If the client included a Client 2887 Identification option in the Information-request message, the server 2888 copies that option to the Reply message. 2890 The server includes options containing configuration information to 2891 be returned to the client as described in Section 19.2. 2893 If the Information-request message received from the client did not 2894 include a Client Identifier option, the server SHOULD respond with a 2895 Reply message containing any configuration parameters that are not 2896 determined by the client's identity. If the server chooses not to 2897 respond, the client may continue to retransmit the Information- 2898 request message indefinitely. 2900 19.2.6. Receipt of Release Messages 2902 When the server receives a Release message via unicast from a client 2903 to which the server has not sent a unicast option, the server 2904 discards the Release message and responds with a Reply message 2905 containing a Status Code option with value UseMulticast, a Server 2906 Identifier option containing the server's DUID, the Client Identifier 2907 option from the client message, and no other options. 2909 Upon the receipt of a valid Release message, the server examines the 2910 IAs and the addresses in the IAs for validity. If the IAs in the 2911 message are in a binding for the client, and the addresses in the IAs 2912 have been assigned by the server to those IAs, the server deletes the 2913 addresses from the IAs and makes the addresses available for 2914 assignment to other clients. The server ignores addresses not 2915 assigned to the IA, although it may choose to log an error. 2917 After all the addresses have been processed, the server generates a 2918 Reply message and includes a Status Code option with value Success, a 2919 Server Identifier option with the server's DUID, and a Client 2920 Identifier option with the client's DUID. For each IA in the Release 2921 message for which the server has no binding information, the server 2922 adds an IA option using the IAID from the Release message, and 2923 includes a Status Code option with the value NoBinding in the IA 2924 option. No other options are included in the IA option. 2926 A server may choose to retain a record of assigned addresses and IAs 2927 after the lifetimes on the addresses have expired to allow the server 2928 to reassign the previously assigned addresses to a client. 2930 19.2.7. Receipt of Decline Messages 2932 When the server receives a Decline message via unicast from a client 2933 to which the server has not sent a unicast option, the server 2934 discards the Decline message and responds with a Reply message 2935 containing a Status Code option with the value UseMulticast, a Server 2936 Identifier option containing the server's DUID, the Client Identifier 2937 option from the client message, and no other options. 2939 Upon the receipt of a valid Decline message, the server examines the 2940 IAs and the addresses in the IAs for validity. If the IAs in the 2941 message are in a binding for the client, and the addresses in the IAs 2942 have been assigned by the server to those IAs, the server deletes the 2943 addresses from the IAs. The server ignores addresses not assigned to 2944 the IA (though it may choose to log an error if it finds such an 2945 address). 2947 The client has found any addresses in the Decline messages to be 2948 already in use on its link. Therefore, the server SHOULD mark the 2949 addresses declined by the client so that those addresses are not 2950 assigned to other clients, and MAY choose to make a notification that 2951 addresses were declined. Local policy on the server determines when 2952 the addresses identified in a Decline message may be made available 2953 for assignment. 2955 After all the addresses have been processed, the server generates a 2956 Reply message and includes a Status Code option with the value 2957 Success, a Server Identifier option with the server's DUID, and a 2958 Client Identifier option with the client's DUID. For each IA in the 2959 Decline message for which the server has no binding information, the 2960 server adds an IA option using the IAID from the Decline message and 2961 includes a Status Code option with the value NoBinding in the IA 2962 option. No other options are included in the IA option. 2964 19.2.8. Transmission of Reply Messages 2966 If the original message was received directly by the server, the 2967 server unicasts the Reply message directly to the client using the 2968 address in the source address field from the IP datagram in which the 2969 original message was received. The Reply message MUST be unicast 2970 through the interface on which the original message was received. 2972 If the original message was received in a Relay-forward message, the 2973 server constructs a Relay-reply message with the Reply message in the 2974 payload of a Relay Message option (see Section 23.10). If the Relay- 2975 forward messages included an Interface-id option, the server copies 2976 that option to the Relay-reply message. The server unicasts the 2977 Relay-reply message directly to the relay agent using the address in 2978 the source address field from the IP datagram in which the Relay- 2979 forward message was received. 2981 19.3. Requesting Router Behavior for Prefix Delegation 2983 The requesting router uses a Request message to populate IA_PDs with 2984 prefixes. The requesting router includes one or more IA_PD options 2985 in the Request message. The delegating router then returns the 2986 prefixes for the IA_PDs to the requesting router in IA_PD options in 2987 a Reply message. 2989 The requesting router includes IA_PD options in any Renew, or Rebind 2990 messages sent by the requesting router. The IA_PD option includes 2991 all of the prefixes the requesting router currently has associated 2992 with that IA_PD. 2994 In some circumstances the requesting router may need verification 2995 that the delegating router still has a valid binding for the 2996 requesting router. Examples of times when a requesting router may 2997 ask for such verification include: 2999 o The requesting router reboots. 3001 o The requesting router's upstream link flaps. 3003 o The requesting router is physically disconnected from a wired 3004 connection. 3006 If such verification is needed the requesting router MUST initiate a 3007 Rebind/Reply message exchange as described in section Section 19.1.4, 3008 with the exception that the retransmission parameters should be set 3009 as for the Confirm message, described in Section 19.1.2. The 3010 requesting router includes any IA_PDs, along with prefixes associated 3011 with those IA_PDs in its Rebind message. 3013 Each prefix has valid and preferred lifetimes whose durations are 3014 specified in the IA_PD Prefix option for that prefix. The requesting 3015 router uses Renew and Rebind messages to request the extension of the 3016 lifetimes of a delegated prefix. 3018 The requesting router uses a Release message to return a delegated 3019 prefix to a delegating router. The prefixes to be released MUST be 3020 included in the IA_PDs. 3022 The Confirm and Decline message types are not used with Prefix 3023 Delegation. 3025 Upon the receipt of a valid Reply message, for each IA_PD the 3026 requesting router assigns a subnet from each of the delegated 3027 prefixes to each of the links to which the associated interfaces are 3028 attached. 3030 When the Delegating Router delegates prefixes to a Requesting Router, 3031 the Requesting Router has sole authority for assignment of those 3032 prefixes, and the Delegating Router MUST NOT assign any prefixes from 3033 that delegated prefix to any of its own links. 3035 When a requesting router subnets a delegated prefix, it must assign 3036 additional bits to the prefix to generate unique, longer prefixes. 3037 For example, if the requesting router in Figure 1 were delegated 3038 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and 3039 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber 3040 network. If the requesting router were delegated 3FFE:FFFF:0::/48 3041 and 3FFE:FFFF:5::/48, it might assign 3FFE:FFFF:0:1::/64 and 3042 3FFE:FFFF:5:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and 3043 3FFE:FFFF:5:2::/64 for assignment to the other link. 3045 If the requesting router assigns a delegated prefix to a link to 3046 which the router is attached, and begins to send router 3047 advertisements for the prefix on the link, the requesting router MUST 3048 set the valid lifetime in those advertisements to be no later than 3049 the valid lifetime specified in the IA_PD Prefix option. A 3050 requesting router MAY use the preferred lifetime specified in the 3051 IA_PD Prefix option. 3053 Handling of Status Codes options in received Reply messages is 3054 described in section Section 19.1.8. The NoPrefixAvail Status Code 3055 is handled in the same manner as the NoAddrsAvail Status Code. 3057 19.4. Delegating Router Behavior for Prefix Delegation 3059 When a delegating router receives a Request message from a requesting 3060 router that contains an IA_PD option, and the delegating router is 3061 authorized to delegate prefix(es) to the requesting router, the 3062 delegating router selects the prefix(es) to be delegated to the 3063 requesting router. The mechanism through which the delegating router 3064 selects prefix(es) for delegation is not specified in this document. 3065 Section 18.4 gives examples of ways in which a delegating router 3066 might select the prefix(es) to be delegated to a requesting router. 3068 A delegating router examines the prefix(es) identified in IA_PD 3069 Prefix options (in an IA_PD option) in Renew and Rebind messages and 3070 responds according to the current status of the prefix(es). The 3071 delegating router returns IA_PD Prefix options (within an IA_PD 3072 option) with updated lifetimes for each valid prefix in the message 3073 from the requesting router. If the delegating router finds that any 3074 of the prefixes are not in the requesting router's binding entry, the 3075 delegating router returns the prefix to the requesting router with 3076 lifetimes of 0. 3078 The delegating router behaves as follows when it cannot find a 3079 binding for the requesting router's IA_PD: 3081 Renew message: If the delegating router cannot find a binding 3082 for the requesting router's IA_PD the delegating 3083 router returns the IA_PD containing no prefixes 3084 with a Status Code option set to NoBinding in the 3085 Reply message. 3087 Rebind message: If the delegating router cannot find a binding 3088 for the requesting router's IA_PD and the 3089 delegating router determines that the prefixes in 3090 the IA_PD are not appropriate for the link to 3091 which the requesting router's interface is 3092 attached according to the delegating routers 3093 explicit configuration, the delegating router MAY 3094 send a Reply message to the requesting router 3095 containing the IA_PD with the lifetimes of the 3096 prefixes in the IA_PD set to zero. This Reply 3097 constitutes an explicit notification to the 3098 requesting router that the prefixes in the IA_PD 3099 are no longer valid. If the delegating router is 3100 unable to determine if the prefix is not 3101 appropriate for the link, the Rebind message is 3102 discarded. 3104 A delegating router may mark any prefix(es) in IA_PD Prefix options 3105 in a Release message from a requesting router as "available", 3106 dependent on the mechanism used to acquire the prefix, e.g., in the 3107 case of a dynamic pool. 3109 The delegating router MUST include an IA_PD Prefix option or options 3110 (in an IA_PD option) in Reply messages sent to a requesting router. 3112 20. DHCP Server-Initiated Configuration Exchange 3114 A server initiates a configuration exchange to cause DHCP clients to 3115 obtain new addresses and other configuration information. For 3116 example, an administrator may use a server-initiated configuration 3117 exchange when links in the DHCP domain are to be renumbered. Other 3118 examples include changes in the location of directory servers, 3119 addition of new services such as printing, and availability of new 3120 software. 3122 20.1. Server Behavior 3124 A server sends a Reconfigure message to cause a client to initiate 3125 immediately a Renew/Reply or Information-request/Reply message 3126 exchange with the server. 3128 20.1.1. Creation and Transmission of Reconfigure Messages 3130 The server sets the "msg-type" field to RECONFIGURE. The server sets 3131 the transaction-id field to 0. The server includes a Server 3132 Identifier option containing its DUID and a Client Identifier option 3133 containing the client's DUID in the Reconfigure message. 3135 The server MAY include an Option Request option to inform the client 3136 of what information has been changed or new information that has been 3137 added. In particular, the server specifies the IA option in the 3138 Option Request option if the server wants the client to obtain new 3139 address information. If the server identifies the IA option in the 3140 Option Request option, the server MUST include an IA option to 3141 identify each IA that is to be reconfigured on the client. The IA 3142 options included by the server MUST NOT contain any options. 3144 Because of the risk of denial of service attacks against DHCP 3145 clients, the use of a security mechanism is mandated in Reconfigure 3146 messages. The server MUST use DHCP authentication in the Reconfigure 3147 message. 3149 The server MUST include a Reconfigure Message option (defined in 3150 Section 23.19) to select whether the client responds with a Renew 3151 message, a Rebind message, or an Information-Request message. 3153 The server MUST NOT include any other options in the Reconfigure 3154 except as specifically allowed in the definition of individual 3155 options. 3157 A server sends each Reconfigure message to a single DHCP client, 3158 using an IPv6 unicast address of sufficient scope belonging to the 3159 DHCP client. If the server does not have an address to which it can 3160 send the Reconfigure message directly to the client, the server uses 3161 a Relay-reply message (as described in Section 21.3) to send the 3162 Reconfigure message to a relay agent that will relay the message to 3163 the client. The server may obtain the address of the client (and the 3164 appropriate relay agent, if required) through the information the 3165 server has about clients that have been in contact with the server, 3166 or through some external agent. 3168 To reconfigure more than one client, the server unicasts a separate 3169 message to each client. The server may initiate the reconfiguration 3170 of multiple clients concurrently; for example, a server may send a 3171 Reconfigure message to additional clients while previous 3172 reconfiguration message exchanges are still in progress. 3174 The Reconfigure message causes the client to initiate a Renew/Reply, 3175 a Rebind/Reply, or Information-request/Reply message exchange with 3176 the server. The server interprets the receipt of a Renew, a Rebind, 3177 or Information-request message (whichever was specified in the 3178 original Reconfigure message) from the client as satisfying the 3179 Reconfigure message request. 3181 20.1.2. Time Out and Retransmission of Reconfigure Messages 3183 If the server does not receive a Renew, Rebind, or Information- 3184 request message from the client in REC_TIMEOUT milliseconds, the 3185 server retransmits the Reconfigure message, doubles the REC_TIMEOUT 3186 value and waits again. The server continues this process until 3187 REC_MAX_RC unsuccessful attempts have been made, at which point the 3188 server SHOULD abort the reconfigure process for that client. 3190 Default and initial values for REC_TIMEOUT and REC_MAX_RC are 3191 documented in Section 6.5. 3193 20.2. Receipt of Renew or Rebind Messages 3195 In response to a Renew message, the server generates and sends a 3196 Reply message to the client as described in Section 19.2.3 and 3197 Section 19.2.8, including options for configuration parameters. 3199 In response to a Rebind message, the server generates and sends a 3200 Reply message to the client as described in Section 19.2.4 and 3201 Section 19.2.8, including options for configuration parameters. 3203 The server MAY include options containing the IAs and new values for 3204 other configuration parameters in the Reply message, even if those 3205 IAs and parameters were not requested in the Renew or Rebind message 3206 from the client. 3208 20.3. Receipt of Information-request Messages 3210 The server generates and sends a Reply message to the client as 3211 described in Section 19.2.5 and Section 19.2.8, including options for 3212 configuration parameters. 3214 The server MAY include options containing new values for other 3215 configuration parameters in the Reply message, even if those 3216 parameters were not requested in the Information-request message from 3217 the client. 3219 20.4. Client Behavior 3221 A client receives Reconfigure messages sent to the UDP port 546 on 3222 interfaces for which it has acquired configuration information 3223 through DHCP. These messages may be sent at any time. Since the 3224 results of a reconfiguration event may affect application layer 3225 programs, the client SHOULD log these events, and MAY notify these 3226 programs of the change through an implementation-specific interface. 3228 20.4.1. Receipt of Reconfigure Messages 3230 Upon receipt of a valid Reconfigure message, the client responds with 3231 either a Renew message, a Rebind message, or an Information-request 3232 message as indicated by the Reconfigure Message option (as defined in 3233 Section 23.19). The client ignores the transaction-id field in the 3234 received Reconfigure message. While the transaction is in progress, 3235 the client discards any Reconfigure messages it receives. 3237 DISCUSSION: 3239 The Reconfigure message acts as a trigger that signals the client 3240 to complete a successful message exchange. Once the client has 3241 received a Reconfigure, the client proceeds with the message 3242 exchange (retransmitting the Renew or Information-request message 3243 if necessary); the client ignores any additional Reconfigure 3244 messages until the exchange is complete. Subsequent Reconfigure 3245 messages cause the client to initiate a new exchange. 3247 How does this mechanism work in the face of duplicated or 3248 retransmitted Reconfigure messages? Duplicate messages will be 3249 ignored because the client will begin the exchange after the 3250 receipt of the first Reconfigure. Retransmitted messages will 3251 either trigger the exchange (if the first Reconfigure was not 3252 received by the client) or will be ignored. The server can 3253 discontinue retransmission of Reconfigure messages to the client 3254 once the server receives the Renew or Information-request message 3255 from the client. 3257 It might be possible for a duplicate or retransmitted Reconfigure 3258 to be sufficiently delayed (and delivered out of order) to arrive 3259 at the client after the exchange (initiated by the original 3260 Reconfigure) has been completed. In this case, the client would 3261 initiate a redundant exchange. The likelihood of delayed and out 3262 of order delivery is small enough to be ignored. The consequence 3263 of the redundant exchange is inefficiency rather than incorrect 3264 operation. 3266 20.4.2. Creation and Transmission of Renew or Rebind Messages 3268 When responding to a Reconfigure, the client creates and sends the 3269 Renew message in exactly the same manner as outlined in 3270 Section 19.1.3, with the exception that the client copies the Option 3271 Request option and any IA options from the Reconfigure message into 3272 the Renew message. The client MUST include a Server Identifier 3273 option in the Renew message, identifying the server with which the 3274 client most recently communicated. 3276 When responding to a Reconfigure, the client creates and sends the 3277 Rebind message in exactly the same manner as outlined in 3278 Section 19.1.4, with the exception that the client copies the Option 3279 Request option and any IA options from the Reconfigure message into 3280 the Rebind message. 3282 If a client is currently sending Rebind messages, as described in 3283 Section 19.1.3, the client ignores any received Reconfigure messages. 3285 20.4.3. Creation and Transmission of Information-request Messages 3287 When responding to a Reconfigure, the client creates and sends the 3288 Information-request message in exactly the same manner as outlined in 3289 Section 19.1.5, with the exception that the client includes a Server 3290 Identifier option with the identifier from the Reconfigure message to 3291 which the client is responding. 3293 20.4.4. Time Out and Retransmission of Renew, Rebind or Information- 3294 request Messages 3296 The client uses the same variables and retransmission algorithm as it 3297 does with Renew, Rebind, or Information-request messages generated as 3298 part of a client-initiated configuration exchange. See 3299 Section 19.1.3, Section 19.1.4, and Section 19.1.5 for details. If 3300 the client does not receive a response from the server by the end of 3301 the retransmission process, the client ignores and discards the 3302 Reconfigure message. 3304 20.4.5. Receipt of Reply Messages 3306 Upon the receipt of a valid Reply message, the client processes the 3307 options and sets (or resets) configuration parameters appropriately. 3308 The client records and updates the lifetimes for any addresses 3309 specified in IAs in the Reply message. 3311 20.5. Prefix Delegation Reconfiguration 3313 This section describes prefix delegation in Reconfigure message 3314 exchanges. 3316 20.5.1. Delegating Router Behavior 3318 The delegating router initiates a configuration message exchange with 3319 a requesting router, as described in Section 20, by sending a 3320 Reconfigure message (acting as a DHCP server) to the requesting 3321 router, as described in Section 20.1. The delegating router 3322 specifies the IA_PD option in the Option Request option to cause the 3323 requesting router to include an IA_PD option to obtain new 3324 information about delegated prefix(es). 3326 20.5.2. Requesting Router Behavior 3328 The requesting router responds to a Reconfigure message, acting as a 3329 DHCP client, received from a delegating router as described in 3330 Section 20.4 The requesting router MUST include the IA_PD Prefix 3331 option(s) (in an IA_PD option) for prefix(es) that have been 3332 delegated to the requesting router by the delegating router from 3333 which the Reconfigure message was received. 3335 21. Relay Agent Behavior 3337 The relay agent MAY be configured to use a list of destination 3338 addresses, which MAY include unicast addresses, the All_DHCP_Servers 3339 multicast address, or other addresses selected by the network 3340 administrator. If the relay agent has not been explicitly 3341 configured, it MUST use the All_DHCP_Servers multicast address as the 3342 default. 3344 If the relay agent relays messages to the All_DHCP_Servers multicast 3345 address or other multicast addresses, it sets the Hop Limit field to 3346 32. 3348 If the relay agent receives a message other than Relay-forward and 3349 Relay-reply and the relay agent does not recognize its message type, 3350 it MUST forward them as described in Section 21.1.1. 3352 21.1. Relaying a Client Message or a Relay-forward Message 3354 A relay agent relays both messages from clients and Relay-forward 3355 messages from other relay agents. When a relay agent receives a 3356 valid message (for a definition of a valid message, see Section 4.1 3357 of [RFC7283]) to be relayed, it constructs a new Relay-forward 3358 message. The relay agent copies the source address from the header 3359 of the IP datagram in which the message was received to the peer- 3360 address field of the Relay-forward message. The relay agent copies 3361 the received DHCP message (excluding any IP or UDP headers) into a 3362 Relay Message option in the new message. The relay agent adds to the 3363 Relay-forward message any other options it is configured to include. 3365 [RFC6221] defines a Lightweight DHCPv6 Relay Agent (LDRA) that allows 3366 Relay Agent Information to be inserted by an access node that 3367 performs a link- layer bridging (i.e., non-routing) function. 3369 21.1.1. Relaying a Message from a Client 3371 If the relay agent received the message to be relayed from a client, 3372 the relay agent places a global, ULA [RFC4193] or site-scoped address 3373 with a prefix assigned to the link on which the client should be 3374 assigned an address in the link-address field. (It is possible for 3375 the relay to use link local address instead, but that is not 3376 recommended as it would require additional information to be provided 3377 in the server configuration. See Section 3.2 of 3378 [I-D.ietf-dhc-topo-conf] for detailed discussion.) This address will 3379 be used by the server to determine the link from which the client 3380 should be assigned an address and other configuration information. 3381 The hop-count in the Relay-forward message is set to 0. 3383 If the relay agent cannot use the address in the link-address field 3384 to identify the interface through which the response to the client 3385 will be relayed, the relay agent MUST include an Interface-id option 3386 (see Section 23.18) in the Relay-forward message. The server will 3387 include the Interface-id option in its Relay-reply message. The 3388 relay agent fills in the link-address field as described in the 3389 previous paragraph regardless of whether the relay agent includes an 3390 Interface-id option in the Relay-forward message. 3392 21.1.2. Relaying a Message from a Relay Agent 3394 If the message received by the relay agent is a Relay-forward message 3395 and the hop-count in the message is greater than or equal to 3396 HOP_COUNT_LIMIT, the relay agent discards the received message. 3398 The relay agent copies the source address from the IP datagram in 3399 which the message was received from the relay agent into the peer- 3400 address field in the Relay-forward message and sets the hop-count 3401 field to the value of the hop-count field in the received message 3402 incremented by 1. 3404 If the source address from the IP datagram header of the received 3405 message is a global or site-scoped address (and the device on which 3406 the relay agent is running belongs to only one site), the relay agent 3407 sets the link-address field to 0; otherwise the relay agent sets the 3408 link-address field to a global or site-scoped address assigned to the 3409 interface on which the message was received, or includes an 3410 Interface-ID option to identify the interface on which the message 3411 was received. 3413 21.1.3. Relay Agent Behavior with Prefix Delegation 3415 A relay agent forwards messages containing Prefix Delegation options 3416 in the same way as described earlier in this section. 3418 If a delegating router communicates with a requesting router through 3419 a relay agent, the delegating router may need a protocol or other 3420 out-of-band communication to configure routing information for 3421 delegated prefixes on any router through which the requesting router 3422 may forward traffic. 3424 21.2. Relaying a Relay-reply Message 3426 The relay agent processes any options included in the Relay-reply 3427 message in addition to the Relay Message option, and then discards 3428 those options. 3430 The relay agent extracts the message from the Relay Message option 3431 and relays it to the address contained in the peer-address field of 3432 the Relay-reply message. Relay agents MUST NOT modify the message. 3434 If the Relay-reply message includes an Interface-id option, the relay 3435 agent relays the message from the server to the client on the link 3436 identified by the Interface-id option. Otherwise, if the link- 3437 address field is not set to zero, the relay agent relays the message 3438 on the link identified by the link-address field. 3440 If the relay agent receives a Relay-reply message, it MUST process 3441 the message as defined above, regardless of the type of message 3442 encapsulated in the Relay Message option. 3444 21.3. Construction of Relay-reply Messages 3446 A server uses a Relay-reply message to return a response to a client 3447 if the original message from the client was relayed to the server in 3448 a Relay-forward message or to send a Reconfigure message to a client 3449 if the server does not have an address it can use to send the message 3450 directly to the client. 3452 A response to the client MUST be relayed through the same relay 3453 agents as the original client message. The server causes this to 3454 happen by creating a Relay-reply message that includes a Relay 3455 Message option containing the message for the next relay agent in the 3456 return path to the client. The contained Relay-reply message 3457 contains another Relay Message option to be sent to the next relay 3458 agent, and so on. The server must record the contents of the peer- 3459 address fields in the received message so it can construct the 3460 appropriate Relay-reply message carrying the response from the 3461 server. 3463 For example, if client C sent a message that was relayed by relay 3464 agent A to relay agent B and then to the server, the server would 3465 send the following Relay-Reply message to relay agent B: 3467 msg-type: RELAY-REPLY 3468 hop-count: 1 3469 link-address: 0 3470 peer-address: A 3471 Relay Message option, containing: 3472 msg-type: RELAY-REPLY 3473 hop-count: 0 3474 link-address: address from link to which C is attached 3475 peer-address: C 3476 Relay Message option: 3478 Figure 8: Relay-reply Example 3480 When sending a Reconfigure message to a client through a relay agent, 3481 the server creates a Relay-reply message that includes a Relay 3482 Message option containing the Reconfigure message for the next relay 3483 agent in the return path to the client. The server sets the peer- 3484 address field in the Relay-reply message header to the address of the 3485 client, and sets the link-address field as required by the relay 3486 agent to relay the Reconfigure message to the client. The server 3487 obtains the addresses of the client and the relay agent through prior 3488 interaction with the client or through some external mechanism. 3490 22. Authentication of DHCP Messages 3492 Some network administrators may wish to provide authentication of the 3493 source and contents of DHCP messages. For example, clients may be 3494 subject to denial of service attacks through the use of bogus DHCP 3495 servers, or may simply be misconfigured due to unintentionally 3496 instantiated DHCP servers. Network administrators may wish to 3497 constrain the allocation of addresses to authorized hosts to avoid 3498 denial of service attacks in "hostile" environments where the network 3499 medium is not physically secured, such as wireless networks or 3500 college residence halls. 3502 The DHCP authentication mechanism is based on the design of 3503 authentication for DHCPv4 [RFC3118]. 3505 22.1. Security of Messages Sent Between Servers and Relay Agents 3507 Relay agents and servers that exchange messages securely use the 3508 IPsec mechanisms for IPv6 [RFC4301]. If a client message is relayed 3509 through multiple relay agents, each of the relay agents must have 3510 established independent, pairwise trust relationships. That is, if 3511 messages from client C will be relayed by relay agent A to relay 3512 agent B and then to the server, relay agents A and B must be 3513 configured to use IPsec for the messages they exchange, and relay 3514 agent B and the server must be configured to use IPsec for the 3515 messages they exchange. 3517 Relay agents and servers that support secure relay agent to server or 3518 relay agent to relay agent communication use IPsec under the 3519 following conditions: 3521 Selectors Relay agents are manually configured with the 3522 addresses of the relay agent or server to 3523 which DHCP messages are to be forwarded. 3524 Each relay agent and server that will be 3525 using IPsec for securing DHCP messages must 3526 also be configured with a list of the relay 3527 agents to which messages will be returned. 3528 The selectors for the relay agents and 3529 servers will be the pairs of addresses 3530 defining relay agents and servers that 3531 exchange DHCP messages on DHCPv6 UDP port 3532 547. 3534 Mode Relay agents and servers use transport mode 3535 and ESP. The information in DHCP messages is 3536 not generally considered confidential, so 3537 encryption need not be used (i.e., NULL 3538 encryption can be used). 3540 Key management Because the relay agents and servers are used 3541 within an organization, public key schemes 3542 are not necessary. Because the relay agents 3543 and servers must be manually configured, 3544 manually configured key management may 3545 suffice, but does not provide defense against 3546 replayed messages. Accordingly, IKE with 3547 preshared secrets SHOULD be supported. IKE 3548 with public keys MAY be supported. 3550 Security policy DHCP messages between relay agents and 3551 servers should only be accepted from DHCP 3552 peers as identified in the local 3553 configuration. 3555 Authentication Shared keys, indexed to the source IP address 3556 of the received DHCP message, are adequate in 3557 this application. 3559 Availability Appropriate IPsec implementations are likely 3560 to be available for servers and for relay 3561 agents in more featureful devices used in 3562 enterprise and core ISP networks. IPsec is 3563 less likely to be available for relay agents 3564 in low end devices primarily used in the home 3565 or small office markets. 3567 22.2. Summary of DHCP Authentication 3569 Authentication of DHCP messages is accomplished through the use of 3570 the Authentication option (see Section 23.11). The authentication 3571 information carried in the Authentication option can be used to 3572 reliably identify the source of a DHCP message and to confirm that 3573 the contents of the DHCP message have not been tampered with. 3575 The Authentication option provides a framework for multiple 3576 authentication protocols. Two such protocols are defined here. 3577 Other protocols defined in the future will be specified in separate 3578 documents. 3580 Any DHCP message MUST NOT include more than one Authentication 3581 option. 3583 The protocol field in the Authentication option identifies the 3584 specific protocol used to generate the authentication information 3585 carried in the option. The algorithm field identifies a specific 3586 algorithm within the authentication protocol; for example, the 3587 algorithm field specifies the hash algorithm used to generate the 3588 message authentication code (MAC) in the authentication option. The 3589 replay detection method (RDM) field specifies the type of replay 3590 detection used in the replay detection field. 3592 22.3. Replay Detection 3594 The Replay Detection Method (RDM) field determines the type of replay 3595 detection used in the Replay Detection field. 3597 If the RDM field contains 0x00, the replay detection field MUST be 3598 set to the value of a strictly monotonically increasing counter. 3599 Using a counter value, such as the current time of day (for example, 3600 an NTP-format timestamp [RFC5905]), can reduce the danger of replay 3601 attacks. This method MUST be supported by all protocols. 3603 22.4. Delayed Authentication Protocol 3605 If the protocol field is 2, the message is using the "delayed 3606 authentication" mechanism. In delayed authentication, the client 3607 requests authentication in its Solicit message, and the server 3608 replies with an Advertise message that includes authentication 3609 information. This authentication information contains a nonce value 3610 generated by the source as a message authentication code (MAC) to 3611 provide message authentication and entity authentication. 3613 Note that the delayed authentication protocol cannot work with 3614 2-message exchange model. This protocol uses Solicit/Advertise 3615 exchange as the key and server selection process. So, real DHCPv6 3616 procedures can only be made in the follow-up messages. 3618 The use of a particular technique based on the HMAC protocol 3619 [RFC2104] using the MD5 hash [RFC1321] is defined here. 3621 22.4.1. Use of the Authentication Option in the Delayed Authentication 3622 Protocol 3624 In a Solicit message, the client fills in the protocol, algorithm and 3625 RDM fields in the Authentication option with the client's 3626 preferences. The client sets the replay detection field to zero and 3627 omits the authentication information field. The client sets the 3628 option-len field to 11. 3630 In all other messages, the protocol and algorithm fields identify the 3631 method used to construct the contents of the authentication 3632 information field. The RDM field identifies the method used to 3633 construct the contents of the replay detection field. 3635 The format of the Authentication information is: 3637 0 1 2 3 3638 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 3639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3640 | DHCP realm | 3641 | (variable length) | 3642 . . 3643 . . 3644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3645 | key ID (32 bits) | 3646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3647 | | 3648 | HMAC-MD5 | 3649 | (128 bits) | 3650 | | 3651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3653 Figure 9: Authentication information format 3655 DHCP realm The DHCP realm that identifies the key used 3656 to generate the HMAC-MD5 value. This is a 3657 domain name encoded as described in 3658 Section 9. 3660 key ID The key identifier that identified the key 3661 used to generate the HMAC-MD5 value. 3663 HMAC-MD5 The message authentication code generated by 3664 applying MD5 to the DHCP message using the 3665 key identified by the DHCP realm, client 3666 DUID, and key ID. 3668 The sender computes the MAC using the HMAC generation algorithm 3669 [RFC2104] and the MD5 hash function [RFC1321]. The entire DHCP 3670 message (setting the MAC field of the authentication option to zero), 3671 including the DHCP message header and the options field, is used as 3672 input to the HMAC-MD5 computation function. 3674 DISCUSSION: 3676 Algorithm 1 specifies the use of HMAC-MD5. Use of a different 3677 technique, such as HMAC-SHA, will be specified as a separate 3678 protocol. 3680 The DHCP realm used to identify authentication keys is chosen to 3681 be unique among administrative domains. Use of the DHCP realm 3682 allows DHCP administrators to avoid conflict in the use of key 3683 identifiers, and allows a host using DHCP to use authenticated 3684 DHCP while roaming among DHCP administrative domains. 3686 22.4.2. Message Validation 3688 Any DHCP message that includes more than one authentication option 3689 MUST be discarded. 3691 To validate an incoming message, the receiver first checks that the 3692 value in the replay detection field is acceptable according to the 3693 replay detection method specified by the RDM field. If no replay is 3694 detected, then the receiver computes the MAC as described in 3695 [RFC2104]. The entire DHCP message (setting the MAC field of the 3696 authentication option to 0) is used as input to the HMAC-MD5 3697 computation function. If the MAC computed by the receiver does not 3698 match the MAC contained in the authentication option, the receiver 3699 MUST discard the DHCP message. 3701 22.4.3. Key Utilization 3703 Each DHCP client has a set of keys. Each key is identified by . Each key also has a lifetime. The key 3705 may not be used past the end of its lifetime. The client's keys are 3706 initially distributed to the client through some out-of-band 3707 mechanism. The lifetime for each key is distributed with the key. 3708 Mechanisms for key distribution and lifetime specification are beyond 3709 the scope of this document. 3711 The client and server use one of the client's keys to authenticate 3712 DHCP messages during a session (until the next Solicit message sent 3713 by the client). 3715 22.4.4. Client Considerations for Delayed Authentication Protocol 3717 The client announces its intention to use DHCP authentication by 3718 including an Authentication option in its Solicit message. The 3719 server selects a key for the client based on the client's DUID. The 3720 client and server use that key to authenticate all DHCP messages 3721 exchanged during the session. 3723 22.4.4.1. Sending Solicit Messages 3725 When the client sends a Solicit message and wishes to use 3726 authentication, it includes an Authentication option with the desired 3727 protocol, algorithm and RDM as described in Section 22.4. The client 3728 does not include any replay detection or authentication information 3729 in the Authentication option. 3731 22.4.4.2. Receiving Advertise Messages 3733 The client validates any Advertise messages containing an 3734 Authentication option specifying the delayed authentication protocol 3735 using the validation test described in Section 22.4.2. 3737 The Client behavior is defined by local policy, as detailed below. 3739 If the client requires that Advertise messages be authenticated, then 3740 it MUST ignore Advertise messages that do not include authentication 3741 information, or for which the client has no matching key, or that do 3742 not pass the validation test. 3744 Local policy MAY also prefer authenticated Advertise messages, in 3745 which case the client SHOULD attempt to validate all Advertise 3746 messages for which the client has a matching key. Messages for which 3747 the client has a key, but which do not pass the validation test MUST 3748 be rejected, even if the client would otherwise accept the same 3749 message without the Authentication option. 3751 In all cases, messages for which the client does not have a matching 3752 key should be treated as if they have no Authentication option. 3754 When the decision to accept unauthenticated message is made, it 3755 should be made with care. Accepting an unauthenticated Advertise 3756 message can make the client vulnerable to spoofing and other attacks. 3757 Policies and actions which were depending upon Authentication MUST 3758 NOT be executed. Local users SHOULD be informed that the client has 3759 accepted an unauthenticated Advertise message. 3761 A client MUST be configurable to discard unauthenticated messages, 3762 and SHOULD be configured by default to discard unauthenticated 3763 messages if the client has been configured with an authentication key 3764 or other authentication information. 3766 A client MAY choose to differentiate between Advertise messages with 3767 no authentication information and Advertise messages that do not pass 3768 the validation test; for example, a client might accept the former 3769 and discard the latter. If a client does accept an unauthenticated 3770 message, the client SHOULD inform any local users and SHOULD log the 3771 event. 3773 22.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline or Release 3774 Messages 3776 If the client authenticated the Advertise message through which the 3777 client selected the server, the client MUST generate authentication 3778 information for subsequent Request, Confirm, Renew, Rebind or Release 3779 messages sent to the server, as described in Section 22.4. When the 3780 client sends a subsequent message, it MUST use the same key used by 3781 the server to generate the authentication information. 3783 22.4.4.4. Sending Information-request Messages 3785 If the server has selected a key for the client in a previous message 3786 exchange (see Section 22.4.5.1), the client MUST use the same key to 3787 generate the authentication information throughout the session. 3789 22.4.4.5. Receiving Reply Messages 3791 If the client authenticated the Advertise it accepted, the client 3792 MUST validate the associated Reply message from the server. The 3793 client MUST ignore and discard the Reply if the message fails to pass 3794 the validation test and MAY log the validation failure. 3796 If the client accepted an Advertise message that did not include 3797 authentication information or did not pass the validation test, the 3798 client MAY accept an unauthenticated Reply message from the server. 3800 22.4.4.6. Receiving Reconfigure Messages 3802 The client MUST discard the Reconfigure if the message fails to pass 3803 the validation test and MAY log the validation failure. 3805 22.4.5. Server Considerations for Delayed Authentication Protocol 3807 After receiving a Solicit message that contains an Authentication 3808 option, the server selects a key for the client, based on the 3809 client's DUID and key selection policies with which the server has 3810 been configured. The server identifies the selected key in the 3811 Advertise message and uses the key to validate subsequent messages 3812 between the client and the server. 3814 22.4.5.1. Receiving Solicit Messages and Sending Advertise Messages 3816 The server selects a key for the client and includes authentication 3817 information in the Advertise message returned to the client as 3818 specified in Section 22.4. The server MUST record the identifier of 3819 the key selected for the client and use that same key for validating 3820 subsequent messages with the client. 3822 22.4.5.2. Receiving Request, Confirm, Renew, Rebind or Release Messages 3823 and Sending Reply Messages 3825 The server uses the key identified in the message and validates the 3826 message as specified in Section 22.4.2. If the message fails to pass 3827 the validation test or the server does not know the key identified by 3828 the 'key ID' field, the server MUST discard the message and MAY 3829 choose to log the validation failure. If the server receives a 3830 client message without an authentication option while the server has 3831 previously sent authentication information in the same session, it 3832 MUST discard the message and MAY choose to log the validation 3833 failure, because the client violates the definition in 3834 Section 22.4.4.3. 3836 If the message passes the validation test, the server responds to the 3837 specific message as described in Section 19.2. The server MUST 3838 include authentication information generated using the key identified 3839 in the received message, as specified in Section 22.4. 3841 22.5. Reconfigure Key Authentication Protocol 3843 The Reconfigure key authentication protocol provides protection 3844 against misconfiguration of a client caused by a Reconfigure message 3845 sent by a malicious DHCP server. In this protocol, a DHCP server 3846 sends a Reconfigure Key to the client in the initial exchange of DHCP 3847 messages. The client records the Reconfigure Key for use in 3848 authenticating subsequent Reconfigure messages from that server. The 3849 server then includes an HMAC computed from the Reconfigure Key in 3850 subsequent Reconfigure messages. 3852 Both the Reconfigure Key sent from the server to the client and the 3853 HMAC in subsequent Reconfigure messages are carried as the 3854 Authentication information in an Authentication option. The format 3855 of the Authentication information is defined in the following 3856 section. 3858 The Reconfigure Key protocol is used (initiated by the server) only 3859 if the client and server are not using any other authentication 3860 protocol and the client and server have negotiated to use Reconfigure 3861 messages. 3863 22.5.1. Use of the Authentication Option in the Reconfigure Key 3864 Authentication Protocol 3866 The following fields are set in an Authentication option for the 3867 Reconfigure Key Authentication Protocol: 3869 protocol 3 3870 algorithm 1 3872 RDM 0 3874 The format of the Authentication information for the Reconfigure Key 3875 Authentication Protocol is: 3877 0 1 2 3 3878 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 3879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3880 | Type | Value (128 bits) | 3881 +-+-+-+-+-+-+-+-+ | 3882 . . 3883 . . 3884 . +-+-+-+-+-+-+-+-+ 3885 | | 3886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3888 Figure 10: RKAP Authentication Information 3890 Type Type of data in Value field carried in this 3891 option: 3893 1 Reconfigure Key value (used in Reply 3894 message). 3896 2 HMAC-MD5 digest of the message (used in 3897 Reconfigure message). 3899 Value Data as defined by the Type field. 3901 22.5.2. Server considerations for Reconfigure Key protocol 3903 The server selects a Reconfigure Key for a client during the Request/ 3904 Reply, Solicit/Reply or Information-request/Reply message exchange. 3905 The server records the Reconfigure Key and transmits that key to the 3906 client in an Authentication option in the Reply message. 3908 The Reconfigure Key is 128 bits long, and MUST be a cryptographically 3909 strong random or pseudo-random number that cannot easily be 3910 predicted. 3912 To provide authentication for a Reconfigure message, the server 3913 selects a replay detection value according to the RDM selected by the 3914 server, and computes an HMAC-MD5 of the Reconfigure message using the 3915 Reconfigure Key for the client. The server computes the HMAC-MD5 3916 over the entire DHCP Reconfigure message, including the 3917 Authentication option; the HMAC-MD5 field in the Authentication 3918 option is set to zero for the HMAC-MD5 computation. The server 3919 includes the HMAC-MD5 in the authentication information field in an 3920 Authentication option included in the Reconfigure message sent to the 3921 client. 3923 22.5.3. Client considerations for Reconfigure Key protocol 3925 The client will receive a Reconfigure Key from the server in the 3926 initial Reply message from the server. The client records the 3927 Reconfigure Key for use in authenticating subsequent Reconfigure 3928 messages. 3930 To authenticate a Reconfigure message, the client computes an HMAC- 3931 MD5 over the DHCP Reconfigure message, using the Reconfigure Key 3932 received from the server. If this computed HMAC-MD5 matches the 3933 value in the Authentication option, the client accepts the 3934 Reconfigure message. 3936 23. DHCP Options 3938 Options are used to carry additional information and parameters in 3939 DHCP messages. Every option shares a common base format, as 3940 described in Section 23.1. All values in options are represented in 3941 network byte order. 3943 This document describes the DHCP options defined as part of the base 3944 DHCP specification. Other options may be defined in the future in 3945 separate documents. See [RFC7227] for guidelines regarding new 3946 options definition. 3948 Unless otherwise noted, each option may appear only in the options 3949 area of a DHCP message and may appear only once. If an option does 3950 appear multiple times, each instance is considered separate and the 3951 data areas of the options MUST NOT be concatenated or otherwise 3952 combined. 3954 Options that are allowed to appear only once are called singleton 3955 options. The only non-singleton options defined in this document are 3956 IA_NA (see Section 23.4), IA_TA (see Section 23.5), and IA_PD (see 3957 Section 23.21) options. Also, IAAddress (see Section 23.6) and 3958 IAPrefix (see Section 23.22) may appear in their respective IA 3959 options more than once. 3961 23.1. Format of DHCP Options 3963 The format of DHCP options is: 3965 0 1 2 3 3966 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 3967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3968 | option-code | option-len | 3969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3970 | option-data | 3971 | (option-len octets) | 3972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3974 Figure 11: Option Format 3976 option-code An unsigned integer identifying the specific 3977 option type carried in this option. 3979 option-len An unsigned integer giving the length of the 3980 option-data field in this option in octets. 3982 option-data The data for the option; the format of this 3983 data depends on the definition of the option. 3985 DHCPv6 options are scoped by using encapsulation. Some options apply 3986 generally to the client, some are specific to an IA, and some are 3987 specific to the addresses within an IA. These latter two cases are 3988 discussed in Section 23.4 and Section 23.6. 3990 23.2. Client Identifier Option 3992 The Client Identifier option is used to carry a DUID (see Section 10) 3993 identifying a client between a client and a server. The format of 3994 the Client Identifier option is: 3996 0 1 2 3 3997 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 3998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3999 | OPTION_CLIENTID | option-len | 4000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4001 . . 4002 . DUID . 4003 . (variable length) . 4004 . . 4005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4007 Figure 12: Client Identifier Option Format 4009 option-code OPTION_CLIENTID (1). 4011 option-len Length of DUID in octets. 4013 DUID The DUID for the client. 4015 23.3. Server Identifier Option 4017 The Server Identifier option is used to carry a DUID (see Section 10) 4018 identifying a server between a client and a server. The format of 4019 the Server Identifier option is: 4021 0 1 2 3 4022 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 4023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4024 | OPTION_SERVERID | option-len | 4025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4026 . . 4027 . DUID . 4028 . (variable length) . 4029 . . 4030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4032 Figure 13: Server Identifier Option Format 4034 option-code OPTION_SERVERID (2). 4036 option-len Length of DUID in octets. 4038 DUID The DUID for the server. 4040 23.4. Identity Association for Non-temporary Addresses Option 4042 The Identity Association for Non-temporary Addresses option (IA_NA 4043 option) is used to carry an IA_NA, the parameters associated with the 4044 IA_NA, and the non-temporary addresses associated with the IA_NA. 4046 Addresses appearing in an IA_NA option are not temporary addresses 4047 (see Section 23.5). 4049 The format of the IA_NA option is: 4051 0 1 2 3 4052 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 4053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4054 | OPTION_IA_NA | option-len | 4055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4056 | IAID (4 octets) | 4057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4058 | T1 | 4059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4060 | T2 | 4061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4062 | | 4063 . IA_NA-options . 4064 . . 4065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4067 Figure 14: Identity Association for Non-temporary Addresses Option 4068 Format 4070 option-code OPTION_IA_NA (3). 4072 option-len 12 + length of IA_NA-options field. 4074 IAID The unique identifier for this IA_NA; the 4075 IAID must be unique among the identifiers for 4076 all of this client's IA_NAs. The number 4077 space for IA_NA IAIDs is separate from the 4078 number space for IA_TA IAIDs. 4080 T1 The time at which the client contacts the 4081 server from which the addresses in the IA_NA 4082 were obtained to extend the lifetimes of the 4083 addresses assigned to the IA_NA; T1 is a time 4084 duration relative to the current time 4085 expressed in units of seconds. 4087 T2 The time at which the client contacts any 4088 available server to extend the lifetimes of 4089 the addresses assigned to the IA_NA; T2 is a 4090 time duration relative to the current time 4091 expressed in units of seconds. 4093 IA_NA-options Options associated with this IA_NA. 4095 The IA_NA-options field encapsulates those options that are specific 4096 to this IA_NA. For example, all of the IA Address Options carrying 4097 the addresses associated with this IA_NA are in the IA_NA-options 4098 field. 4100 Each IA_NA carries one "set" of non-temporary addresses; that is, at 4101 most one address from each prefix assigned to the link to which the 4102 client is attached. 4104 An IA_NA option may only appear in the options area of a DHCP 4105 message. A DHCP message may contain multiple IA_NA options. 4107 The status of any operations involving this IA_NA is indicated in a 4108 Status Code option in the IA_NA-options field. 4110 Note that an IA_NA has no explicit "lifetime" or "lease length" of 4111 its own. When the valid lifetimes of all of the addresses in an 4112 IA_NA have expired, the IA_NA can be considered as having expired. 4113 T1 and T2 are included to give servers explicit control over when a 4114 client recontacts the server about a specific IA_NA. 4116 In a message sent by a client to a server, values in the T1 and T2 4117 fields indicate the client's preference for those parameters. The 4118 client sets T1 and T2 to 0 if it has no preference for those values. 4119 In a message sent by a server to a client, the client MUST use the 4120 values in the T1 and T2 fields for the T1 and T2 parameters, unless 4121 those values in those fields are 0. The values in the T1 and T2 4122 fields are the number of seconds until T1 and T2. 4124 The server selects the T1 and T2 times to allow the client to extend 4125 the lifetimes of any addresses in the IA_NA before the lifetimes 4126 expire, even if the server is unavailable for some short period of 4127 time. Recommended values for T1 and T2 are .5 and .8 times the 4128 shortest preferred lifetime of the addresses in the IA that the 4129 server is willing to extend, respectively. If the "shortest" 4130 preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and 4131 T2 values are also 0xffffffff. If the time at which the addresses in 4132 an IA_NA are to be renewed is to be left to the discretion of the 4133 client, the server sets T1 and T2 to 0. 4135 If a server receives an IA_NA with T1 greater than T2, and both T1 4136 and T2 are greater than 0, the server ignores the invalid values of 4137 T1 and T2 and processes the IA_NA as though the client had set T1 and 4138 T2 to 0. 4140 If a client receives an IA_NA with T1 greater than T2, and both T1 4141 and T2 are greater than 0, the client discards the IA_NA option and 4142 processes the remainder of the message as though the server had not 4143 included the invalid IA_NA option. 4145 Care should be taken in setting T1 or T2 to 0xffffffff ("infinity"). 4146 A client will never attempt to extend the lifetimes of any addresses 4147 in an IA with T1 set to 0xffffffff. A client will never attempt to 4148 use a Rebind message to locate a different server to extend the 4149 lifetimes of any addresses in an IA with T2 set to 0xffffffff. 4151 This option MAY appear in a Confirm message if the lifetimes on the 4152 non-temporary addresses in the associated IA have not expired. 4154 23.5. Identity Association for Temporary Addresses Option 4156 The Identity Association for the Temporary Addresses (IA_TA) option 4157 is used to carry an IA_TA, the parameters associated with the IA_TA 4158 and the addresses associated with the IA_TA. All of the addresses in 4159 this option are used by the client as temporary addresses, as defined 4160 in [RFC4941]. The format of the IA_TA option is: 4162 0 1 2 3 4163 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 4164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4165 | OPTION_IA_TA | option-len | 4166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4167 | IAID (4 octets) | 4168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4169 | | 4170 . IA_TA-options . 4171 . . 4172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4174 Figure 15: Identity Association for Temporary Addresses Option Format 4176 option-code OPTION_IA_TA (4). 4178 option-len 4 + length of IA_TA-options field. 4180 IAID The unique identifier for this IA_TA; the 4181 IAID must be unique among the identifiers for 4182 all of this client's IA_TAs. The number 4183 space for IA_TA IAIDs is separate from the 4184 number space for IA_NA IAIDs. 4186 IA_TA-options Options associated with this IA_TA. 4188 The IA_TA-Options field encapsulates those options that are specific 4189 to this IA_TA. For example, all of the IA Address Options carrying 4190 the addresses associated with this IA_TA are in the IA_TA-options 4191 field. 4193 Each IA_TA carries one "set" of temporary addresses. 4195 An IA_TA option may only appear in the options area of a DHCP 4196 message. A DHCP message may contain multiple IA_TA options. 4198 The status of any operations involving this IA_TA is indicated in a 4199 Status Code option in the IA_TA-options field. 4201 Note that an IA has no explicit "lifetime" or "lease length" of its 4202 own. When the valid lifetimes of all of the addresses in an IA_TA 4203 have expired, the IA can be considered as having expired. 4205 An IA_TA option does not include values for T1 and T2. A client MAY 4206 request that the lifetimes on temporary addresses be extended by 4207 including the addresses in a IA_TA option sent in a Renew or Rebind 4208 message to a server. For example, a client would request an 4209 extension on the lifetime of a temporary address to allow an 4210 application to continue to use an established TCP connection. 4212 The client obtains new temporary addresses by sending an IA_TA option 4213 with a new IAID to a server. Requesting new temporary addresses from 4214 the server is the equivalent of generating new temporary addresses as 4215 described in [RFC4941]. The server will generate new temporary 4216 addresses and return them to the client. The client should request 4217 new temporary addresses before the lifetimes on the previously 4218 assigned addresses expire. 4220 A server MUST return the same set of temporary address for the same 4221 IA_TA (as identified by the IAID) as long as those addresses are 4222 still valid. After the lifetimes of the addresses in an IA_TA have 4223 expired, the IAID may be reused to identify a new IA_TA with new 4224 temporary addresses. 4226 This option MAY appear in a Confirm message if the lifetimes on the 4227 temporary addresses in the associated IA have not expired. 4229 23.6. IA Address Option 4231 The IA Address option is used to specify IPv6 addresses associated 4232 with an IA_NA or an IA_TA. The IA Address option must be 4233 encapsulated in the Options field of an IA_NA or IA_TA option. The 4234 Options fields of the IA_NA or IA_TA option encapsulates those 4235 options that are specific to this address. 4237 The format of the IA Address option is: 4239 0 1 2 3 4240 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 4241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4242 | OPTION_IAADDR | option-len | 4243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4244 | | 4245 | IPv6 address | 4246 | | 4247 | | 4248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4249 | preferred-lifetime | 4250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4251 | valid-lifetime | 4252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4253 . . 4254 . IAaddr-options . 4255 . . 4256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4258 Figure 16: IA Address Option Format 4260 option-code OPTION_IAADDR (5). 4262 option-len 24 + length of IAaddr-options field. 4264 IPv6 address An IPv6 address. 4266 preferred-lifetime The preferred lifetime for the IPv6 address 4267 in the option, expressed in units of seconds. 4269 valid-lifetime The valid lifetime for the IPv6 address in 4270 the option, expressed in units of seconds. 4272 IAaddr-options Options associated with this address. 4274 In a message sent by a client to a server, values in the preferred 4275 and valid lifetime fields indicate the client's preference for those 4276 parameters. The client may send 0 if it has no preference for the 4277 preferred and valid lifetimes. If a client wishes to express its 4278 lifetimes preferences and does not have the knowledge to populate the 4279 IPv6 address field, it can use unspecified address (::). It is up to 4280 a server to honor or ignore these preferences. 4282 In a message sent by a server to a client, the client MUST use the 4283 values in the preferred and valid lifetime fields for the preferred 4284 and valid lifetimes. The values in the preferred and valid lifetimes 4285 are the number of seconds remaining in each lifetime. 4287 A client discards any addresses for which the preferred lifetime is 4288 greater than the valid lifetime. A server ignores the lifetimes set 4289 by the client if the preferred lifetime is greater than the valid 4290 lifetime and ignores the values for T1 and T2 set by the client if 4291 those values are greater than the preferred lifetime. 4293 Care should be taken in setting the valid lifetime of an address to 4294 0xffffffff ("infinity"), which amounts to a permanent assignment of 4295 an address to a client. 4297 More than one IA Address Option can appear in an IA_NA option or an 4298 IA_TA option. 4300 The status of any operations involving this IA Address is indicated 4301 in a Status Code option in the IAaddr-options field, as specified in 4302 Section 23.13. 4304 23.7. Option Request Option 4306 The Option Request option is used to identify a list of options in a 4307 message between a client and a server. The format of the Option 4308 Request option is: 4310 0 1 2 3 4311 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4313 | OPTION_ORO | option-len | 4314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4315 | requested-option-code-1 | requested-option-code-2 | 4316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4317 | ... | 4318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4320 Figure 17: Option Request Option Format 4322 option-code OPTION_ORO (6). 4324 option-len 2 * number of requested options. 4326 requested-option-code-n The option code for an option requested 4327 by the client. 4329 A client MAY include an Option Request option in a Solicit, Request, 4330 Renew, Rebind, Confirm or Information-request message to inform the 4331 server about options the client wants the server to send to the 4332 client. A server MAY include an Option Request option in a 4333 Reconfigure message to indicate which options the client should 4334 request from the server. If there is a need to request encapsulated 4335 options, top-level Option Request option MUST be used for that 4336 purpose. There is no need request IAADDR or IAPREFIX. 4338 23.8. Preference Option 4340 The Preference option is sent by a server to a client to affect the 4341 selection of a server by the client. 4343 The format of the Preference option is: 4345 0 1 2 3 4346 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 4347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4348 | OPTION_PREFERENCE | option-len | 4349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4350 | pref-value | 4351 +-+-+-+-+-+-+-+-+ 4353 Figure 18: Preference Option Format 4355 option-code OPTION_PREFERENCE (7). 4357 option-len 1. 4359 pref-value The preference value for the server in this 4360 message. 4362 A server MAY include a Preference option in an Advertise message to 4363 control the selection of a server by the client. See Section 18.1.3 4364 for the use of the Preference option by the client and the 4365 interpretation of Preference option data value. 4367 23.9. Elapsed Time Option 4369 0 1 2 3 4370 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 4371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4372 | OPTION_ELAPSED_TIME | option-len | 4373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4374 | elapsed-time | 4375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4377 Figure 19: Elapsed Time Option Format 4379 option-code OPTION_ELAPSED_TIME (8). 4381 option-len 2. 4383 elapsed-time The amount of time since the client began its 4384 current DHCP transaction. This time is 4385 expressed in hundredths of a second (10^-2 4386 seconds). 4388 A client MUST include an Elapsed Time option in messages to indicate 4389 how long the client has been trying to complete a DHCP message 4390 exchange. The elapsed time is measured from the time at which the 4391 client sent the first message in the message exchange, and the 4392 elapsed-time field is set to 0 in the first message in the message 4393 exchange. Servers and Relay Agents use the data value in this option 4394 as input to policy controlling how a server responds to a client 4395 message. For example, the elapsed time option allows a secondary 4396 DHCP server to respond to a request when a primary server has not 4397 answered in a reasonable time. The elapsed time value is an 4398 unsigned, 16 bit integer. The client uses the value 0xffff to 4399 represent any elapsed time values greater than the largest time value 4400 that can be represented in the Elapsed Time option. 4402 23.10. Relay Message Option 4404 The Relay Message option carries a DHCP message in a Relay-forward or 4405 Relay-reply message. 4407 The format of the Relay Message option is: 4409 0 1 2 3 4410 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 4411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4412 | OPTION_RELAY_MSG | option-len | 4413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4414 | | 4415 . DHCP-relay-message . 4416 . . 4417 . . 4418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4420 Figure 20: Relay Message Option Format 4422 option-code OPTION_RELAY_MSG (9) 4424 option-len Length of DHCP-relay-message 4426 DHCP-relay-message In a Relay-forward message, the received 4427 message, relayed verbatim to the next relay 4428 agent or server; in a Relay-reply message, 4429 the message to be copied and relayed to the 4430 relay agent or client whose address is in the 4431 peer-address field of the Relay-reply message 4433 23.11. Authentication Option 4435 The Authentication option carries authentication information to 4436 authenticate the identity and contents of DHCP messages. The use of 4437 the Authentication option is described in Section 22. The format of 4438 the Authentication 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_AUTH | option-len | 4444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4445 | protocol | algorithm | RDM | | 4446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4447 | | 4448 | replay detection (64 bits) +-+-+-+-+-+-+-+-+ 4449 | | auth-info | 4450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4451 . authentication information . 4452 . (variable length) . 4453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4455 Figure 21: Authentication Option Format 4457 option-code OPTION_AUTH (11). 4459 option-len 11 + length of authentication information 4460 field. 4462 protocol The authentication protocol used in this 4463 authentication option. 4465 algorithm The algorithm used in the authentication 4466 protocol. 4468 RDM The replay detection method used in this 4469 authentication option. 4471 Replay detection The replay detection information for the RDM. 4473 authentication information The authentication information, as 4474 specified by the protocol and algorithm used 4475 in this authentication option. 4477 23.12. Server Unicast Option 4479 The server sends this option to a client to indicate to the client 4480 that it is allowed to unicast messages to the server. The format of 4481 the Server Unicast option is: 4483 0 1 2 3 4484 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 4485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4486 | OPTION_UNICAST | option-len | 4487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4488 | | 4489 | server-address | 4490 | | 4491 | | 4492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4494 Figure 22: Server Unicast Option Format 4496 option-code OPTION_UNICAST (12). 4498 option-len 16. 4500 server-address The IP address to which the client should 4501 send messages delivered using unicast. 4503 The server specifies the IPv6 address to which the client is to send 4504 unicast messages in the server-address field. When a client receives 4505 this option, where permissible and appropriate, the client sends 4506 messages directly to the server using the IPv6 address specified in 4507 the server-address field of the option. 4509 When the server sends a Unicast option to the client, some messages 4510 from the client will not be relayed by Relay Agents, and will not 4511 include Relay Agent options from the Relay Agents. Therefore, a 4512 server should only send a Unicast option to a client when Relay 4513 Agents are not sending Relay Agent options. A DHCP server rejects 4514 any messages sent inappropriately using unicast to ensure that 4515 messages are relayed by Relay Agents when Relay Agent options are in 4516 use. 4518 Details about when the client may send messages to the server using 4519 unicast are in Section 19. 4521 23.13. Status Code Option 4523 This option returns a status indication related to the DHCP message 4524 or option in which it appears. The format of the Status Code option 4525 is: 4527 0 1 2 3 4528 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 4529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4530 | OPTION_STATUS_CODE | option-len | 4531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4532 | status-code | | 4533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4534 . . 4535 . status-message . 4536 . . 4537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4539 Figure 23: Status Code Option Format 4541 option-code OPTION_STATUS_CODE (13). 4543 option-len 2 + length of status-message. 4545 status-code The numeric code for the status encoded in 4546 this option. 4548 status-message A UTF-8 encoded text string suitable for 4549 display to an end user, which MUST NOT be 4550 null-terminated. 4552 A Status Code option may appear in the options field of a DHCP 4553 message and/or in the options field of another option. If the Status 4554 Code option does not appear in a message in which the option could 4555 appear, the status of the message is assumed to be Success. 4557 The status-codes values previously defined by [RFC3315] and [RFC3633] 4558 are: 4560 +---------------+------+--------------------------------------------+ 4561 | Name | Code | Description | 4562 +---------------+------+--------------------------------------------+ 4563 | Success | 0 | Success. | 4564 | UnspecFail | 1 | Failure, reason unspecified; this status | 4565 | | | code is sent by either a client or a | 4566 | | | server to indicate a failure not | 4567 | | | explicitly specified in this document. | 4568 | NoAddrsAvail | 2 | Server has no addresses available to | 4569 | | | assign to the IA(s). | 4570 | NoBinding | 3 | Client record (binding) unavailable. | 4571 | NotOnLink | 4 | The prefix for the address is not | 4572 | | | appropriate for the link to which the | 4573 | | | client is attached. | 4574 | UseMulticast | 5 | Sent by a server to a client to force the | 4575 | | | client to send messages to the server | 4576 | | | using the | 4577 | | | All_DHCP_Relay_Agents_and_Servers address. | 4578 | NoPrefixAvail | 6 | Delegating router has no prefixes | 4579 | | | available to assign to the IAPD(s). | 4580 +---------------+------+--------------------------------------------+ 4582 23.14. Rapid Commit Option 4584 The Rapid Commit option is used to signal the use of the two message 4585 exchange for address assignment. The format of the Rapid Commit 4586 option is: 4588 0 1 2 3 4589 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 4590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4591 | OPTION_RAPID_COMMIT | 0 | 4592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4594 Figure 24: Rapid Commit Option Format 4596 option-code OPTION_RAPID_COMMIT (14). 4598 option-len 0. 4600 A client MAY include this option in a Solicit message if the client 4601 is prepared to perform the Solicit-Reply message exchange described 4602 in Section 18.1.1. 4604 A server MUST include this option in a Reply message sent in response 4605 to a Solicit message when completing the Solicit-Reply message 4606 exchange. 4608 DISCUSSION: 4610 Each server that responds with a Reply to a Solicit that includes 4611 a Rapid Commit option will commit the assigned addresses in the 4612 Reply message to the client, and will not receive any confirmation 4613 that the client has received the Reply message. Therefore, if 4614 more than one server responds to a Solicit that includes a Rapid 4615 Commit option, some servers will commit addresses that are not 4616 actually used by the client. 4618 The problem of unused addresses can be minimized, for example, by 4619 designing the DHCP service so that only one server responds to the 4620 Solicit or by using relatively short lifetimes for assigned 4621 addresses, or the DHCP client initiatively releases unused 4622 addresses using the Release message. 4624 23.15. User Class Option 4626 The User Class option is used by a client to identify the type or 4627 category of user or applications it represents. 4629 The format of the User Class option is: 4631 0 1 2 3 4632 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 4633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4634 | OPTION_USER_CLASS | option-len | 4635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4636 . . 4637 . user-class-data . 4638 . . 4639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4641 Figure 25: User Class Option Format 4643 option-code OPTION_USER_CLASS (15). 4645 option-len Length of user class data field. 4647 user-class-data The user classes carried by the client. 4649 The information contained in the data area of this option is 4650 contained in one or more opaque fields that represent the user class 4651 or classes of which the client is a member. A server selects 4652 configuration information for the client based on the classes 4653 identified in this option. For example, the User Class option can be 4654 used to configure all clients of people in the accounting department 4655 with a different printer than clients of people in the marketing 4656 department. The user class information carried in this option MUST 4657 be configurable on the client. 4659 The data area of the user class option MUST contain one or more 4660 instances of user class data. Each instance of the user class data 4661 is formatted as follows: 4663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4664 | user-class-len | opaque-data | 4665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4667 Figure 26: User Class Data Format 4669 The user-class-len is two octets long and specifies the length of the 4670 opaque user class data in network byte order. 4672 A server interprets the classes identified in this option according 4673 to its configuration to select the appropriate configuration 4674 information for the client. A server may use only those user classes 4675 that it is configured to interpret in selecting configuration 4676 information for a client and ignore any other user classes. In 4677 response to a message containing a User Class option, a server 4678 includes a User Class option containing those classes that were 4679 successfully interpreted by the server, so that the client can be 4680 informed of the classes interpreted by the server. 4682 23.16. Vendor Class Option 4684 This option is used by a client to identify the vendor that 4685 manufactured the hardware on which the client is running. The 4686 information contained in the data area of this option is contained in 4687 one or more opaque fields that identify details of the hardware 4688 configuration. The format of the Vendor Class option is: 4690 0 1 2 3 4691 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 4692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4693 | OPTION_VENDOR_CLASS | option-len | 4694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4695 | enterprise-number | 4696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4697 . . 4698 . vendor-class-data . 4699 . . . . . 4700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4702 Figure 27: Vendor Class Option Format 4704 option-code OPTION_VENDOR_CLASS (16). 4706 option-len 4 + length of vendor class data field. 4708 enterprise-number The vendor's registered Enterprise Number as 4709 registered with IANA [IANA-PEN]. 4711 vendor-class-data The hardware configuration of the host on 4712 which the client is running. 4714 The vendor-class-data is composed of a series of separate items, each 4715 of which describes some characteristic of the client's hardware 4716 configuration. Examples of vendor-class-data instances might include 4717 the version of the operating system the client is running or the 4718 amount of memory installed on the client. 4720 Each instance of the vendor-class-data is formatted as follows: 4722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4723 | vendor-class-len | opaque-data | 4724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 4726 Figure 28: Vendor Class Data Format 4728 The vendor-class-len is two octets long and specifies the length of 4729 the opaque vendor class data in network byte order. 4731 Servers and clients MUST NOT include more than one instance of 4732 OPTION_VENDOR_CLASS with the same Enterprise Number. Each instance 4733 of OPTION_VENDOR_CLASS can carry multiple sub-options. 4735 23.17. Vendor-specific Information Option 4737 This option is used by clients and servers to exchange vendor- 4738 specific information. 4740 The format of the Vendor-specific Information option is: 4742 0 1 2 3 4743 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 4744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4745 | OPTION_VENDOR_OPTS | option-len | 4746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4747 | enterprise-number | 4748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4749 . . 4750 . option-data . 4751 . . 4752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4754 Figure 29: Vendor-specific Information Option Format 4756 option-code OPTION_VENDOR_OPTS (17). 4758 option-len 4 + length of option-data field. 4760 enterprise-number The vendor's registered Enterprise Number as 4761 registered with IANA [IANA-PEN]. 4763 option-data An opaque object, interpreted by vendor- 4764 specific code on the clients and servers. 4766 The definition of the information carried in this option is vendor 4767 specific. The vendor is indicated in the enterprise-number field. 4768 Use of vendor-specific information allows enhanced operation, 4769 utilizing additional features in a vendor's DHCP implementation. A 4770 DHCP client that does not receive requested vendor-specific 4771 information will still configure the host device's IPv6 stack to be 4772 functional. 4774 The encapsulated vendor-specific options field MUST be encoded as a 4775 sequence of code/length/value fields of identical format to the DHCP 4776 options field. The option codes are defined by the vendor identified 4777 in the enterprise-number field and are not managed by IANA. Each of 4778 the encapsulated options is formatted as follows: 4780 0 1 2 3 4781 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 4782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4783 | opt-code | option-len | 4784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4785 . . 4786 . option-data . 4787 . . 4788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4790 Figure 30: Vendor-specific Options Format 4792 opt-code The code for the encapsulated option. 4794 option-len An unsigned integer giving the length of the 4795 option-data field in this encapsulated option 4796 in octets. 4798 option-data The data area for the encapsulated option. 4800 Multiple instances of the Vendor-specific Information option may 4801 appear in a DHCP message. Each instance of the option is interpreted 4802 according to the option codes defined by the vendor identified by the 4803 Enterprise Number in that option. Servers and clients MUST NOT send 4804 more than one instance of Vendor-specific Information option with the 4805 same Enterprise Number. Each instanf of Vendor-specific Information 4806 option MAY contain multiple encapsulated options. 4808 A client that is interested in receiving a Vendor-specific 4809 Information Option: 4811 - MUST specify the Vendor-specific Information Option in an Option 4812 Request Option. 4814 - MAY specify an associated Vendor Class Option. 4816 - MAY specify the Vendor-specific Information Option with any data. 4818 Severs only return the Vendor-specific Information Options if 4819 specified in Option Request Options from clients and: 4821 - MAY use the Enterprise Numbers in the associated Vendor Class 4822 Options to restrict the set of Enterprise Numbers in the Vendor- 4823 specific Information Options returned. 4825 - MAY return all configured Vendor-specific Information Options. 4827 - MAY use other information in the packet or in its configuration to 4828 determine which set of Enterprise Numbers in the Vendor-specific 4829 Information Options to return. 4831 23.18. Interface-Id Option 4833 The relay agent MAY send the Interface-id option to identify the 4834 interface on which the client message was received. If a relay agent 4835 receives a Relay-reply message with an Interface-id option, the relay 4836 agent relays the message to the client through the interface 4837 identified by the option. 4839 The format of the Interface ID option is: 4841 0 1 2 3 4842 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4844 | OPTION_INTERFACE_ID | option-len | 4845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4846 . . 4847 . interface-id . 4848 . . 4849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4851 Figure 31: Interface-ID Option Format 4853 option-code OPTION_INTERFACE_ID (18). 4855 option-len Length of interface-id field. 4857 interface-id An opaque value of arbitrary length generated 4858 by the relay agent to identify one of the 4859 relay agent's interfaces. 4861 The server MUST copy the Interface-Id option from the Relay-forward 4862 message into the Relay-reply message the server sends to the relay 4863 agent in response to the Relay-forward message. This option MUST NOT 4864 appear in any message except a Relay-forward or Relay-reply message. 4866 Servers MAY use the Interface-ID for parameter assignment policies. 4867 The Interface-ID SHOULD be considered an opaque value, with policies 4868 based on exact match only; that is, the Interface-ID SHOULD NOT be 4869 internally parsed by the server. The Interface-ID value for an 4870 interface SHOULD be stable and remain unchanged, for example, after 4871 the relay agent is restarted; if the Interface-ID changes, a server 4872 will not be able to use it reliably in parameter assignment policies. 4874 23.19. Reconfigure Message Option 4876 A server includes a Reconfigure Message option in a Reconfigure 4877 message to indicate to the client whether the client responds with a 4878 Renew message, a Rebind message, or an Information-request message. 4879 The format of this option is: 4881 0 1 2 3 4882 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 4883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4884 | OPTION_RECONF_MSG | option-len | 4885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4886 | msg-type | 4887 +-+-+-+-+-+-+-+-+ 4889 Figure 32: Reconfigure Message Option Format 4891 option-code OPTION_RECONF_MSG (19). 4893 option-len 1. 4895 msg-type 5 for Renew message, 6 for Rebind, 11 for 4896 Information-request message. 4898 The Reconfigure Message option can only appear in a Reconfigure 4899 message. 4901 23.20. Reconfigure Accept Option 4903 A client uses the Reconfigure Accept option to announce to the server 4904 whether the client is willing to accept Reconfigure messages, and a 4905 server uses this option to tell the client whether or not to accept 4906 Reconfigure messages. The default behavior, in the absence of this 4907 option, means unwillingness to accept Reconfigure messages, or 4908 instruction not to accept Reconfigure messages, for the client and 4909 server messages, respectively. The following figure gives the format 4910 of the Reconfigure Accept option: 4912 0 1 2 3 4913 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 4914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4915 | OPTION_RECONF_ACCEPT | 0 | 4916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4918 Figure 33: Reconfigure Accept Option Format 4920 option-code OPTION_RECONF_ACCEPT (20). 4922 option-len 0. 4924 23.21. Identity Association for Prefix Delegation Option 4926 The IA_PD option is used to carry a prefix delegation identity 4927 association, the parameters associated with the IA_PD and the 4928 prefixes associated with it. 4930 0 1 2 3 4931 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 4932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4933 | OPTION_IA_PD | option-length | 4934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4935 | IAID (4 octets) | 4936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4937 | T1 | 4938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4939 | T2 | 4940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4941 . . 4942 . IA_PD-options . 4943 . . 4944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4946 Figure 34: Identity Association for Prefix Delegation Option Format 4948 option-code OPTION_IA_PD (25). 4950 option-length 12 + length of IA_PD-options field. 4952 IAID The unique identifier for this IA_PD; the 4953 IAID must be unique among the identifiers for 4954 all of this requesting router's IA_PDs. 4956 T1 The time at which the requesting router 4957 should contact the delegating router from 4958 which the prefixes in the IA_PD were obtained 4959 to extend the lifetimes of the prefixes 4960 delegated to the IA_PD; T1 is a time duration 4961 relative to the current time expressed in 4962 units of seconds. 4964 T2 The time at which the requesting router 4965 should contact any available delegating 4966 router to extend the lifetimes of the 4967 prefixes assigned to the IA_PD; T2 is a time 4968 duration relative to the current time 4969 expressed in units of seconds. 4971 IA_PD-options Options associated with this IA_PD. 4973 The IA_PD-options field encapsulates those options that are specific 4974 to this IA_PD. For example, all of the IA_PD Prefix Options carrying 4975 the prefixes associated with this IA_PD are in the IA_PD-options 4976 field. 4978 An IA_PD option may only appear in the options area of a DHCP 4979 message. A DHCP message may contain multiple IA_PD options. 4981 The status of any operations involving this IA_PD is indicated in a 4982 Status Code option in the IA_PD-options field. 4984 Note that an IA_PD has no explicit "lifetime" or "lease length" of 4985 its own. When the valid lifetimes of all of the prefixes in a IA_PD 4986 have expired, the IA_PD can be considered as having expired. T1 and 4987 T2 are included to give delegating routers explicit control over when 4988 a requesting router should contact the delegating router about a 4989 specific IA_PD. 4991 In a message sent by a requesting router to a delegating router, 4992 values in the T1 and T2 fields indicate the requesting router's 4993 preference for those parameters. The requesting router sets T1 and 4994 T2 to zero if it has no preference for those values. In a message 4995 sent by a delegating router to a requesting router, the requesting 4996 router MUST use the values in the T1 and T2 fields for the T1 and T2 4997 parameters. The values in the T1 and T2 fields are the number of 4998 seconds until T1 and T2. 5000 The delegating router selects the T1 and T2 times to allow the 5001 requesting router to extend the lifetimes of any prefixes in the 5002 IA_PD before the lifetimes expire, even if the delegating router is 5003 unavailable for some short period of time. Recommended values for T1 5004 and T2 are .5 and .8 times the shortest preferred lifetime of the 5005 prefixes in the IA_PD that the delegating router is willing to 5006 extend, respectively. If the time at which the prefixes in an IA_PD 5007 are to be renewed is to be left to the discretion of the requesting 5008 router, the delegating router sets T1 and T2 to 0. 5010 If a delegating router receives an IA_PD with T1 greater than T2, and 5011 both T1 and T2 are greater than 0, the delegating router ignores the 5012 invalid values of T1 and T2 and processes the IA_PD as though the 5013 requesting router had set T1 and T2 to 0. 5015 If a requesting router receives an IA_PD with T1 greater than T2, and 5016 both T1 and T2 are greater than 0, the requesting router discards the 5017 IA_PD option and processes the remainder of the message as though the 5018 requesting router had not included the IA_PD option. 5020 23.22. IA Prefix Option 5022 The IA_PD Prefix option is used to specify IPv6 address prefixes 5023 associated with an IA_PD. The IA_PD Prefix option must be 5024 encapsulated in the IA_PD-options field of an IA_PD option. 5026 0 1 2 3 5027 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 5028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5029 | OPTION_IAPREFIX | option-length | 5030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5031 | preferred-lifetime | 5032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5033 | valid-lifetime | 5034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5035 | prefix-length | | 5036 +-+-+-+-+-+-+-+-+ IPv6 prefix | 5037 | (16 octets) | 5038 | | 5039 | | 5040 | | 5041 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5042 | | . 5043 +-+-+-+-+-+-+-+-+ . 5044 . IAprefix-options . 5045 . . 5046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5048 Figure 35: IA Prefix Option Format 5050 option-code OPTION_IAPREFIX (26). 5052 option-length 25 + length of IAprefix-options field. 5054 preferred-lifetime The recommended preferred lifetime for the 5055 IPv6 prefix in the option, expressed in units 5056 of seconds. A value of 0xFFFFFFFF represents 5057 infinity. 5059 valid-lifetime The valid lifetime for the IPv6 prefix in the 5060 option, expressed in units of seconds. A 5061 value of 0xFFFFFFFF represents infinity. 5063 prefix-length Length for this prefix in bits. 5065 IPv6-prefix An IPv6 prefix. 5067 IAprefix-options Options associated with this prefix. 5069 In a message sent by a requesting router to a delegating router, the 5070 values in the fields can be used to indicate the requesting router's 5071 preference for those values. The requesting router may send a value 5072 of zero to indicate no preference. A requesting router may set the 5073 IPv6 prefix field to zero and a given value in the prefix-length 5074 field to indicate a preference for the size of the prefix to be 5075 delegated. 5077 In a message sent by a delegating router the preferred and valid 5078 lifetimes should be set to the values of AdvPreferredLifetime and 5079 AdvValidLifetime as specified in section 6.2.1, "Router Configuration 5080 Variables" of [RFC2461], unless administratively configured. 5082 A requesting router discards any prefixes for which the preferred 5083 lifetime is greater than the valid lifetime. A delegating router 5084 ignores the lifetimes set by the requesting router if the preferred 5085 lifetime is greater than the valid lifetime and ignores the values 5086 for T1 and T2 set by the requesting router if those values are 5087 greater than the preferred lifetime. 5089 The values in the preferred and valid lifetimes are the number of 5090 seconds remaining for each lifetime. 5092 An IA_PD Prefix option may appear only in an IA_PD option. More than 5093 one IA_PD Prefix Option can appear in a single IA_PD option. 5095 The status of any operations involving this IA_PD Prefix option is 5096 indicated in a Status Code option in the IAprefix-options field. 5098 23.23. SOL_MAX_RT Option 5100 A DHCP server sends the SOL_MAX_RT option to a client to override the 5101 default value of SOL_MAX_RT. The value of SOL_MAX_RT in the option 5102 replaces the default value defined in Section 6.5. One use for the 5103 SOL_MAX_RT option is to set a longer value for SOL_MAX_RT, which 5104 reduces the Solicit traffic from a client that has not received a 5105 response to its Solicit messages. 5107 The format of the SOL_MAX_RT option is: 5109 0 1 2 3 5110 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 5111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5112 | option-code | option-len | 5113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5114 | SOL_MAX_RT value | 5115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5117 Figure 36: SOL_MAX_RT Option Format 5119 option-code OPTION_SOL_MAX_RT (82). 5121 option-len 4. 5123 SOL_MAX_RT value Overriding value for SOL_MAX_RT in seconds; 5124 MUST be in range: 60 <= "value" <= 86400 (1 5125 day). 5127 A DHCP client MUST include the SOL_MAX_RT option code in any Option 5128 Request option (see Section 23.7) it sends. 5130 The DHCP server MAY include the SOL_MAX_RT option in any response it 5131 sends to a client that has included the SOL_MAX_RT option code in an 5132 Option Request option. The SOL_MAX_RT option is sent in the main 5133 body of the message to client, not as an encapsulated option in, 5134 e.g., an IA_NA, IA_TA, or IA_PD option. 5136 A DHCP client MUST ignore any SOL_MAX_RT option values that are less 5137 than 60 or more than 86400. 5139 If a DHCP client receives a message containing a SOL_MAX_RT option 5140 that has a valid value for SOL_MAX_RT, the client MUST set its 5141 internal SOL_MAX_RT parameter to the value contained in the 5142 SOL_MAX_RT option. This value of SOL_MAX_RT is then used by the 5143 retransmission mechanism defined in Section 15 and Section 18.1.2. 5145 Updated SOL_MAX_RT value applies only to the network interface on 5146 which the client received SOL_MAX_RT option. 5148 23.24. INF_MAX_RT Option 5150 A DHCP server sends the INF_MAX_RT option to a client to override the 5151 default value of INF_MAX_RT. The value of INF_MAX_RT in the option 5152 replaces the default value defined in Section 6.5. One use for the 5153 INF_MAX_RT option is to set a longer value for INF_MAX_RT, which 5154 reduces the Information-request traffic from a client that has not 5155 received a response to its Information-request messages. 5157 The format of the INF_MAX_RT option is: 5159 0 1 2 3 5160 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 5161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5162 | option-code | option-len | 5163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5164 | INF_MAX_RT value | 5165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5167 Figure 37: INF_MAX_RT Option Format 5169 option-code OPTION_INF_MAX_RT (83). 5171 option-len 4. 5173 SOL_MAX_RT value Overriding value for INF_MAX_RT in seconds; 5174 MUST be in range: 60 <= "value" <= 86400 (1 5175 day). 5177 A DHCP client MUST include the INF_MAX_RT option code in any Option 5178 Request option (see Section 23.7) it sends. 5180 The DHCP server MAY include the INF_MAX_RT option in any response it 5181 sends to a client that has included the INF_MAX_RT option code in an 5182 Option Request option. The INF_MAX_RT option is sent in the main 5183 body of the message to client, not as an encapsulated option in, 5184 e.g., an IA_NA, IA_TA, or IA_PD option. 5186 A DHCP client MUST ignore any INF_MAX_RT option values that are less 5187 than 60 or more than 86400. 5189 If a DHCP client receives a message containing an INF_MAX_RT option 5190 that has a valid value for INF_MAX_RT, the client MUST set its 5191 internal INF_MAX_RT parameter to the value contained in the 5192 INF_MAX_RT option. This value of INF_MAX_RT is then used by the 5193 retransmission mechanism defined in Section 15 and Section 19.1.5. 5195 Updated INF_MAX_RT value applies only to the network interface on 5196 which the client received INF_MAX_RT option. 5198 24. Security Considerations 5200 The threat to DHCP is inherently an insider threat (assuming a 5201 properly configured network where DHCPv6 ports are blocked on the 5202 perimeter gateways of the enterprise). Regardless of the gateway 5203 configuration, however, the potential attacks by insiders and 5204 outsiders are the same. 5206 Use of manually configured preshared keys for IPsec between relay 5207 agents and servers does not defend against replayed DHCP messages. 5208 Replayed messages can represent a DOS attack through exhaustion of 5209 processing resources, but not through mis-configuration or exhaustion 5210 of other resources such as assignable addresses. 5212 One attack specific to a DHCP client is the establishment of a 5213 malicious server with the intent of providing incorrect configuration 5214 information to the client. The motivation for doing so may be to 5215 mount a "man in the middle" attack that causes the client to 5216 communicate with a malicious server instead of a valid server for 5217 some service such as DNS or NTP. The malicious server may also mount 5218 a denial of service attack through misconfiguration of the client 5219 that causes all network communication from the client to fail. 5221 A malicious DHCP server might cause a client to set its SOL_MAX_RT 5222 and INF_MAX_RT parameters to an unreasonably high value with the 5223 SOL_MAX_RT and INF_MAX_RT options, which may cause an undue delay in 5224 a client completing its DHCP protocol transaction in the case no 5225 other valid response is received. Assuming the client also receives 5226 a response from a valid DHCP server, large values for SOL_MAX_RT and 5227 INF_MAX_RT will not have any effect. 5229 There is another threat to DHCP clients from mistakenly or 5230 accidentally configured DHCP servers that answer DHCP client requests 5231 with unintentionally incorrect configuration parameters. 5233 A DHCP client may also be subject to attack through the receipt of a 5234 Reconfigure message from a malicious server that causes the client to 5235 obtain incorrect configuration information from that server. Note 5236 that although a client sends its response (Renew or Information- 5237 request message) through a relay agent and, therefore, that response 5238 will only be received by servers to which DHCP messages are relayed, 5239 a malicious server could send a Reconfigure message to a client, 5240 followed (after an appropriate delay) by a Reply message that would 5241 be accepted by the client. Thus, a malicious server that is not on 5242 the network path between the client and the server may still be able 5243 to mount a Reconfigure attack on a client. The use of transaction 5244 IDs that are cryptographically sound and cannot easily be predicted 5245 will also reduce the probability that such an attack will be 5246 successful. 5248 The threat specific to a DHCP server is an invalid client 5249 masquerading as a valid client. The motivation for this may be for 5250 theft of service, or to circumvent auditing for any number of 5251 nefarious purposes. 5253 The threat common to both the client and the server is the resource 5254 "denial of service" (DoS) attack. These attacks typically involve 5255 the exhaustion of available addresses, or the exhaustion of CPU or 5256 network bandwidth, and are present anytime there is a shared 5257 resource. 5259 In the case where relay agents add additional options to Relay 5260 Forward messages, the messages exchanged between relay agents and 5261 servers may be used to mount a "man in the middle" or denial of 5262 service attack. 5264 This threat model does not consider the privacy of the contents of 5265 DHCP messages to be important. DHCP is not used to exchange 5266 authentication or configuration information that must be kept secret 5267 from other networks nodes. 5269 DHCP authentication provides for authentication of the identity of 5270 DHCP clients and servers, and for the integrity of messages delivered 5271 between DHCP clients and servers. DHCP authentication does not 5272 provide any privacy for the contents of DHCP messages. 5274 The Delayed Authentication protocol described in Section 22.4 uses a 5275 secret key that is shared between a client and a server. The use of 5276 a "DHCP realm" in the shared key allows identification of 5277 administrative domains so that a client can select the appropriate 5278 key or keys when roaming between administrative domains. However, 5279 the Delayed Authentication protocol does not define any mechanism for 5280 sharing of keys, so a client may require separate keys for each 5281 administrative domain it encounters. The use of shared keys may not 5282 scale well and does not provide for repudiation of compromised keys. 5283 This protocol is focused on solving the intradomain problem where the 5284 out-of-band exchange of a shared key is feasible. 5286 Because of the opportunity for attack through the Reconfigure 5287 message, a DHCP client MUST discard any Reconfigure message that does 5288 not include authentication or that does not pass the validation 5289 process for the authentication protocol. 5291 The Reconfigure Key protocol described in Section 22.5 provides 5292 protection against the use of a Reconfigure message by a malicious 5293 DHCP server to mount a denial of service or man-in-the-middle attack 5294 on a client. This protocol can be compromised by an attacker that 5295 can intercept the initial message in which the DHCP server sends the 5296 key to the client. 5298 Communication between a server and a relay agent, and communication 5299 between relay agents, can be secured through the use of IPsec, as 5300 described in Section 22.1. The use of manual configuration and 5301 installation of static keys are acceptable in this instance because 5302 relay agents and the server will belong to the same administrative 5303 domain and the relay agents will require other specific configuration 5304 (for example, configuration of the DHCP server address) as well as 5305 the IPsec configuration. 5307 A rogue delegating router can issue bogus prefixes to a requesting 5308 router. This may cause denial of service due to unreachability. 5310 A malicious requesting router may be able to mount a denial of 5311 service attack by repeated requests for delegated prefixes that 5312 exhaust the delegating router's available prefixes. 5314 To guard against attacks through prefix delegation, requesting 5315 routers and delegating routers SHOULD use DHCP authentication as 5316 described in Section 22. For point to point links, where one trusts 5317 that there is no man in the middle, or one trusts layer two 5318 authentication, DHCP authentication or IPsec may not be necessary. 5319 Because a requesting router and delegating routers must each have at 5320 least one assigned IPv6 address, the routers may be able to use IPsec 5321 for authentication of DHCPv6 messages. The details of using IPsec 5322 for DHCPv6 are under development. 5324 Networks configured with delegated prefixes should be configured to 5325 preclude intentional or inadvertent inappropriate advertisement of 5326 these prefixes. 5328 25. IANA Considerations 5330 This document does not define any new DHCPv6 name spaces or 5331 definitions. 5333 IANA is requested to update the http://www.iana.org/assignments/ 5334 dhcpv6-parameters/dhcpv6-parameters.xhtml page to add a reference to 5335 this document for definitions previously created by [RFC3315], 5336 [RFC3633], and [RFC7083]. 5338 26. Acknowledgments 5340 The following people are authors of the original RFC 3315: Ralph 5341 Droms, Jim Bound, Bernie Volz, Ted Lemon, Charles Perkins, and Mike 5342 Carney. The following people are authors of the original RFC 3633: 5343 Ole Troan and Ralph Droms. This document is merely a refinement of 5344 their work and would not be possible without their original work. 5346 A number of additional people have contributed to identifying issues 5347 with RFC 3315 and RFC 3633 and proposed resolutions to these issues 5348 as reflected in this document (in no particular order): Ole Troan, 5349 Robert Marks, Leaf Yeh, Tim Winters, Michelle Cotton, Pablo Armando, 5350 John Brzozowski, Suresh Krishnan, Hideshi Enokihara, Alexandru 5351 Petrescu, Yukiyo Akisada, Tatuya Jinmei, Fred Templin. With special 5352 thanks to Ralph Droms for answering many questions related to the 5353 original RFC 3315 work. 5355 The following acknowledgements are from the original RFC 3315 and RFC 5356 3633: 5358 Thanks to the DHC Working Group and the members of the IETF for their 5359 time and input into the specification. In particular, thanks also 5360 for the consistent input, ideas, and review by (in alphabetical 5361 order) Bernard Aboba, Bill Arbaugh, Thirumalesh Bhat, Steve Bellovin, 5362 A. K. Vijayabhaskar, Brian Carpenter, Matt Crawford, Steve Deering, 5363 Francis Dupont, Dave Forster, Brian Haberman, Richard Hussong, Tatuya 5364 Jinmei, Kim Kinnear, Fredrik Lindholm, Tony Lindstrom, Josh 5365 Littlefield, Gerald Maguire, Jack McCann, Shin Miyakawa, Thomas 5366 Narten, Erik Nordmark, Jarno Rajahalme, Yakov Rekhter, Pekka Savola, 5367 Mark Stapp, Matt Thomas, Sue Thomson, Tatuya Jinmei, Bernie Volz, 5368 Trevor Warwick, Phil Wells and Toshi Yamasaki. 5370 Thanks to Steve Deering and Bob Hinden, who have consistently taken 5371 the time to discuss the more complex parts of the IPv6 5372 specifications. 5374 And, thanks to Steve Deering for pointing out at IETF 51 in London 5375 that the DHCPv6 specification has the highest revision number of any 5376 Internet Draft. 5378 27. References 5380 27.1. Normative References 5382 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 5383 August 1980. 5385 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 5386 converting network protocol addresses to 48.bit Ethernet 5387 address for transmission on Ethernet hardware", STD 37, 5388 RFC 826, November 1982. 5390 [RFC1035] Mockapetris, P., "Domain names - implementation and 5391 specification", STD 13, RFC 1035, November 1987. 5393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5394 Requirement Levels", BCP 14, RFC 2119, March 1997. 5396 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 5397 2131, March 1997. 5399 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 5400 Extensions", RFC 2132, March 1997. 5402 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 5403 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 5404 RFC 2136, April 1997. 5406 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 5407 (IPv6) Specification", RFC 2460, December 1998. 5409 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 5410 Discovery for IP Version 6 (IPv6)", RFC 2461, December 5411 1998. 5413 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 5414 Networks", RFC 2464, December 1998. 5416 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 5417 Addresses", RFC 2526, March 1999. 5419 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 5420 Messages", RFC 3118, June 2001. 5422 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 5423 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 5424 December 2003. 5426 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 5427 Configuration Option for DHCPv6", RFC 4075, May 2005. 5429 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 5430 Architecture", RFC 4291, February 2006. 5432 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 5433 Internet Protocol", RFC 4301, December 2005. 5435 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 5436 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 5437 September 2007. 5439 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 5440 Address Autoconfiguration", RFC 4862, September 2007. 5442 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 5443 Extensions for Stateless Address Autoconfiguration in 5444 IPv6", RFC 4941, September 2007. 5446 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 5447 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 5448 May 2008. 5450 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 5451 Time Protocol Version 4: Protocol and Algorithms 5452 Specification", RFC 5905, June 2010. 5454 [RFC6221] Miles, D., Ooghe, S., Dec, W., Krishnan, S., and A. 5455 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, May 5456 2011. 5458 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 5459 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 5460 2011. 5462 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 5463 "Default Address Selection for Internet Protocol Version 6 5464 (IPv6)", RFC 6724, September 2012. 5466 [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT 5467 and INF_MAX_RT", RFC 7083, November 2013. 5469 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 5470 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 5471 BCP 187, RFC 7227, May 2014. 5473 [RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 5474 Messages", RFC 7283, July 2014. 5476 27.2. Informative References 5478 [I-D.ietf-dhc-topo-conf] 5479 Lemon, T. and T. Mrugalski, "Customizing DHCP 5480 Configuration on the Basis of Network Topology", draft- 5481 ietf-dhc-topo-conf-04 (work in progress), January 2015. 5483 [IANA-PEN] 5484 IANA, "Private Enterprise Numbers registry 5485 http://www.iana.org/assignments/enterprise-numbers", . 5487 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 5488 April 1992. 5490 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 5491 Hashing for Message Authentication", RFC 2104, February 5492 1997. 5494 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 5495 Autoconfiguration", RFC 2462, December 1998. 5497 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 5498 Stateless Address Autoconfiguration in IPv6", RFC 3041, 5499 January 2001. 5501 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 5502 3162, August 2001. 5504 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 5505 and M. Carney, "Dynamic Host Configuration Protocol for 5506 IPv6 (DHCPv6)", RFC 3315, July 2003. 5508 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 5509 Host Configuration Protocol (DHCP) version 6", RFC 3633, 5510 December 2003. 5512 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 5513 (DHCP) Service for IPv6", RFC 3736, April 2004. 5515 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 5516 Delegation", RFC 3769, June 2004. 5518 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 5519 Addresses", RFC 4193, October 2005. 5521 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 5522 Requirements for IPv6 Customer Edge Routers", RFC 7084, 5523 November 2013. 5525 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 5526 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 5527 7341, August 2014. 5529 Appendix A. Changes since RFC3315 5531 1. Incorporated RFC3315 errata (ids: 294, 1373, 2928, 1815, 3577, 5532 2509, 295). 5534 2. Partially incorporated RFC3315 errata id 2472 (place other IA 5535 options if NoAddrsAvail is sent in Advertise). 5537 3. Clarified section 21.4.1 of RFC3315 by defining length of "key 5538 ID" field and specifying that 'DHCP realm' is Domain Name 5539 encoded as per section 8 of RFC3315. Ticket #43. 5541 4. Added DUID-UUID and reference to RFC6355. Ticket #54. 5543 5. Specified a minimum length for the DUID in section "9.1. DUID 5544 Contents". Ticket #39. 5546 6. Removed the use of term "sub-options" from section "19.1.1. 5547 Creation and Transmission of Reconfigure Messages". Ticket #40. 5549 7. Added text to section 22.6 "IA Address Option" about the usage 5550 of unspecified address to express the client hints for Preferred 5551 and Valid lifetimes. Ticket #45. 5553 8. Updated text in 21.4.2 of RFC3315 ("Message Validation") as 5554 suggested in section 3.1 of draft-ietf-dhc-dhcpv6-clarify-auth- 5555 01. Ticket #87. 5557 9. Merged RFC7083, "Modification to Default Values of SOL_MAX_RT 5558 and INF_MAX_RT", into this document. Ticket #51. 5560 10. Incorporated RFC3315 errata (id 2471), into section 17.1.3. 5561 Ticket #25. 5563 11. Added text that relay agents MUST NOT modify the relayed message 5564 to section 20.1.2. Ticket #57. 5566 12. Modified the text in section 21.4.4.5, Receiving Reply Messages, 5567 to remove special treatment of a Reply validation failure 5568 (client ignores message). Ticket #89. 5570 13. Appendix C updated: Authentication option is no longer allowed 5571 in Relay-forward and Relay-reply messages, ORO is no longer 5572 allowed in Confirm, Release and Decline messages; Preference 5573 option is no longer allowed in Reply messages (only in 5574 Advertise). Ticket #10. 5576 14. Removed "silently" from several instances of "silently ignores" 5577 or "silently" discards. It is up to software vendor if and how 5578 to log such events (debug log message, event log, message pop-up 5579 etc.). Ticket #50. 5581 15. Clarified that: there should be no more that one instance of 5582 Vendor Class option with a given Enterprise Number; that one 5583 instance of Vendor Class can contain multiple encapsulated 5584 options; the same applies to Vendor Specific Information option. 5585 Ticket #22. 5587 16. Clarified relay agent definition. Ticket #12. 5589 17. Changed REL_MAX_RC and DEC_MAX_RC defaults from 5 to 4 and added 5590 retry to parameter description. Ticket #84. 5592 18. Clarify handling process for Vendor-specific Information Option 5593 and Vendor Class Option. Ticket #20. 5595 19. Replace "monotonic" with "strictly monotonic" in Section 21.3. 5596 Ticket #11. 5598 20. Incorporate everything of RFC 6644, except for Security 5599 Considerations Section, which has already covered in a more 5600 abstracted way. Ticket #55 & #56. 5602 21. Clarify the server behavior process when a client violates 5603 Delayed Authentication Protocol, in Section 21.4. Ticket #90. 5605 22. Updated titles of sections 19.4.2. and 19.4.4. to include Rebind 5606 messages. 5608 23. Applied many of the review comments from a review done by Fred 5609 Templin in August 2006. Ticket #14. 5611 24. Reworded the first paragraph of Section 15 to relax the "SHOULD" 5612 requirement to drop the messages which contain the options not 5613 expected in the current message. Ticket #17. 5615 25. Changed WG to DHC, added keywords 5617 26. Loosened requirements for DUID-EN, so that DUID type can be used 5618 for virtual machines. Ticket #16. 5620 27. Clarified that IA may contain other resources than just address. 5621 Ticket #93. 5623 28. Clarified that most options are singletons (i.e. can appear only 5624 once). Ticket #83. 5626 29. Merged sections 1 (Ticket #96), 2 (Ticket #97), 3 (Ticket #98), 5627 4 (Ticket #99), 6 (Ticket #101), 8 (Ticket #103), 9 (Ticket 5628 #104), 10 (Ticket #105), 11 (Ticket #106), 13 (Ticket #108), 14 5629 (Ticket #109), 15 (Ticket #110), 16 (Ticket #111), 17 (Ticket 5630 #112) and 19 (Ticket #113) from RFC3633 (Prefix Delegation). 5632 30. Clarified that encapsulated options must be requested using top 5633 level ORO (ticket #38). 5635 31. Clarified that configuration for interface X should be requested 5636 over interface X (ticket #48). 5638 32. CONFIRM is now an optional message (MUST send Confirm eased to 5639 SHOULD) (ticket #120). 5641 33. Added reference to RFC7227: DHCPv6 Option Guidelines (ticket 5642 #121). 5644 34. Added new section 5 providing an overview of DHCPv6 operational 5645 modes and removed two prefix delegation sections from section 1. 5646 See tickets #53, #100, and #102. 5648 35. Addressed ticket #115 - don't use DHCPv6 for DHCPv4 5649 configuration. 5651 36. Revised IANA Considerations based on ticket #117. 5653 37. Updated IAID description in the terminology with the 5654 clarification that the IAID is unique among IAs of a specific 5655 type, rather than globally unique among all IAs (ticket #94). 5657 38. Merged Section 12 from RFC3633 (ticket #107) 5659 39. Clarified behavior for unknown messages (RFC7283), ticket #58. 5661 40. Addressed tickets #123 and #126, and clarified that the client 5662 SHOULD abandon its bindings when restarts the server 5663 solicitation. 5665 41. Clarified link-address field usage, ticket #73. 5667 Appendix B. Changes since RFC3633 5669 1. Incorporated RFC3633 errata (ids: 248, 1880, 2468, 2469, 2470, 5670 3736) 5672 2. ... 5674 Appendix C. Appearance of Options in Message Types 5676 The following table indicates with a "*" the options are allowed in 5677 each DHCP message type: 5679 Client Server IA_NA IA_PD Option Pref Elap. Relay Auth. Server 5680 ID ID IA_TA Request Time Msg. Unicast 5681 Solicit * * * * * * 5682 Advert. * * * * * * 5683 Request * * * * * * * 5684 Confirm * * * * 5685 Renew * * * * * * * 5686 Rebind * * * * * * 5687 Decline * * * * * * 5688 Release * * * * * * 5689 Reply * * * * * * 5690 Reconf. * * * * 5691 Inform. * (see note) * * * 5692 R-forw. * 5693 R-repl. * 5695 NOTE: 5697 Only included in Information-request messages that are sent in 5698 response to a Reconfigure (see Section 20.4.3). 5700 Status Rap. User Vendor Vendor Inter. Recon. Recon. SOL_MAX_RT 5701 Code Comm. Class Class Spec. ID Msg. Accept INF_MAX_RT 5702 Solicit * * * * * 5703 Advert. * * * * * * 5704 Request * * * * 5705 Confirm * * * 5706 Renew * * * * 5707 Rebind * * * * 5708 Decline * * * 5709 Release * * * 5710 Reply * * * * * * * 5711 Reconf. * 5712 Inform. * * * * 5713 R-forw. * * * * 5714 R-repl. * * * * 5716 Appendix D. Appearance of Options in the Options Field of DHCP Options 5718 The following table indicates with a "*" where options can appear in 5719 the options field of other options: 5721 Option IA_NA/ Relay Relay 5722 Field IA_TA IAADDR IA_PD IAPREFIX Forw. Reply 5723 Client ID * 5724 Server ID * 5725 IA_NA/IA_TA * 5726 IAADDR * 5727 IA_PD * 5728 IAPREFIX * 5729 ORO * 5730 Preference * 5731 Elapsed Time * 5732 Relay Message * * 5733 Authentic. * 5734 Server Uni. * 5735 Status Code * * * 5736 Rapid Comm. * 5737 User Class * 5738 Vendor Class * 5739 Vendor Info. * * * 5740 Interf. ID * * 5741 Reconf. MSG. * 5742 Reconf. Accept * 5744 Note: "Relay Forw" / "Relay Reply" options appear in the options 5745 field of the message but may only appear in these messages. 5747 Authors' Addresses 5749 Tomek Mrugalski (editor) 5750 Internet Systems Consortium, Inc. 5751 950 Charter Street 5752 Redwood City, CA 94063 5753 USA 5755 Email: tomasz.mrugalski@gmail.com 5757 Marcin Siodelski 5758 Internet Systems Consortium, Inc. 5759 950 Charter St. 5760 Redwood City, CA 94063 5761 USA 5763 Email: msiodelski@gmail.com 5764 Bernie Volz 5765 Cisco Systems, Inc. 5766 1414 Massachusetts Ave 5767 Boxborough, MA 01719 5768 USA 5770 Email: volz@cisco.com 5772 Andrew Yourtchenko 5773 Cisco Systems, Inc. 5774 De Kleetlaan, 7 5775 Diegem B-1831 5776 Belgium 5778 Email: ayourtch@cisco.com 5780 Michael C. Richardson 5781 Sandelman Software Works 5782 470 Dawson Avenue 5783 Ottawa, ON K1Z 5V7 5784 CA 5786 Email: mcr+ietf@sandelman.ca 5787 URI: http://www.sandelman.ca/ 5789 Sheng Jiang 5790 Huawei Technologies Co., Ltd 5791 Q14, Huawei Campus, No.156 Beiqing Road 5792 Hai-Dian District, Beijing, 100095 5793 P.R. China 5795 Email: jiangsheng@huawei.com 5797 Ted Lemon 5798 Nominum, Inc. 5799 950 Charter St. 5800 Redwood City, CA 94043 5801 USA 5803 Email: Ted.Lemon@nominum.com