idnits 2.17.1 draft-ietf-dhc-dhcpv6-stateful-issues-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: For IAs to which addresses have been assigned, the client includes a corresponding IA option containing an IA Address option for each address assigned to the IA. The client MUST not include addresses in any IA option that the client did not obtain from the server or that are no longer valid (that have a zero valid lifetime). (Using the creation date from RFC3315, updated by this document, for RFC5378 checks: 1995-02-03) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 29, 2015) is 3375 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '17' on line 566 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 7083 (Obsoleted by RFC 8415) == Outdated reference: A later version (-04) exists of draft-dhcwg-dhc-rfc3315bis-03 == Outdated reference: A later version (-11) exists of draft-ietf-mif-mpvd-arch-09 == Outdated reference: A later version (-02) exists of draft-ietf-mif-mpvd-dhcp-support-00 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Troan 3 Internet-Draft B. Volz 4 Updates: 3315,3633 (if approved) Cisco Systems, Inc. 5 Intended status: Standards Track M. Siodelski 6 Expires: August 2, 2015 ISC 7 January 29, 2015 9 Issues and Recommendations with Multiple Stateful DHCPv6 Options 10 draft-ietf-dhc-dhcpv6-stateful-issues-10.txt 12 Abstract 14 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 15 specification defined two stateful options, IA_NA and IA_TA, but did 16 not anticipate the development of additional stateful options. 17 DHCPv6 Prefix Delegation added the IA_PD option, which is stateful. 18 Applications that use IA_NA and IA_PD together have revealed issues 19 that need to be addressed. This document updates RFC 3315 and RFC 20 3633 to address these issues. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 2, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Handling of Multiple IA Option Types . . . . . . . . . . . . 4 60 4.1. Placement of Status Codes in an Advertise Message . . . . 5 61 4.2. Advertise Message Processing by a Client . . . . . . . . 6 62 4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 7 63 4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 8 64 4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 8 65 4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 9 66 4.4.3. Updates to section 18.1.3 of RFC 3315 . . . . . . . . 9 67 4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 11 68 4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 12 69 4.4.6. Updates to Section 18.2.3 of RFC 3315 . . . . . . . . 14 70 4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 16 71 4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 17 72 4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 18 73 4.6. Decline Should Not Necessarily Trigger a Release . . . . 19 74 4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 20 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 80 8.2. Informative References . . . . . . . . . . . . . . . . . 21 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 83 1. Introduction 85 DHCPv6 [RFC3315] was written without the expectation that additional 86 stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation 87 [RFC3633] since added a new stateful option for Prefix Delegation to 88 DHCPv6. Implementation experience of the Customer Edge Router model 89 described in [RFC7084] has shown issues with the DHCPv6 protocol in 90 supporting multiple stateful option types, in particular IA_NA (non- 91 temporary addresses) and IA_PD (delegated prefixes). 93 This document describes a number of problems encountered with 94 coexistence of the IA_NA and IA_PD option types and specifies changes 95 to the DHCPv6 protocol to address these problems. 97 The intention of this work is to clarify and, where needed, modify 98 the DHCPv6 protocol specification to support IA_NA and IA_PD option 99 types within a single DHCPv6 session. 101 Note that while IA_TA (temporary addresses) options may be included 102 with other IA option type requests, these generally are not renewed 103 (there are no T1/T2 times) and have a separate life cycle from IA_NA 104 and IA_PD option types. Therefore, the IA_TA option type is mostly 105 out of scope for this document. 107 The changes described in this document are intended to be 108 incorporated in a new revision of the DHCPv6 protocol specification 109 ([I-D.dhcwg-dhc-rfc3315bis]). 111 2. Conventions 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 3. Terminology 119 In addition to the terminology defined in [RFC3315], [RFC3633], and 120 [RFC7227], the following terminology is used in this document: 122 Identity association (IA): Throughout this document, "IA" is 123 used to refer to the Identity 124 Association containing addresses or 125 prefixes assigned to a client and 126 carried in the IA_NA or IA_PD options 127 respectively. 129 IA option types: This is used to generally mean an 130 IA_NA and/or IA_PD option. 132 Stateful options: Options that require dynamic binding 133 state per client on the server. 135 Top-level options: Top-level options are DHCPv6 options 136 that are not encapsulated within 137 other options, excluding the Relay- 138 Message option. Options encapsulated 139 by Relay-message options, but not by 140 any other option, are still top-level 141 options, whether they appear in a 142 relay agent message or a server 143 message. See [RFC7227]. 145 4. Handling of Multiple IA Option Types 147 The DHCPv6 specification [RFC3315] was written with the assumption 148 that the only stateful options were for assigning addresses. DHCPv6 149 Prefix Delegation [RFC3633] describes how to extend the DHCPv6 150 protocol to handle prefix delegation, but does not clearly specify 151 how the DHCP address assignment and prefix delegation co-exist. 153 If a client requests multiple IA option types, but the server is 154 configured to only offer a subset of them, the client could react in 155 several ways: 157 1. Reset the state machine and continue to send Solicit messages, 159 2. Create separate DHCP sessions for each IA option type and 160 continue to Solicit for the unfulfilled IA options, or 162 3. The client could continue with the single session, and include 163 the unfulfilled IA options in subsequent messages to the server. 165 Resetting the state machine and continuing to send Solicit messages 166 may result in the client never completing DHCP and is generally not 167 considered a good solution. It can also result in a packet storm if 168 the client does not appropriately rate limit its sending of Solicit 169 messages. 171 Creating a separate DHCP session (separate instances of the client 172 state machine) per IA option type, while conceptually simple, causes 173 a number of issues: additional host resources required to create and 174 maintain multiple instances of the state machine in clients, 175 additional DHCP protocol traffic, unnecessary duplication of other 176 configuration options and the potential for conflict, divergence in 177 that each IA option type specification specifies its 'own' version of 178 the DHCP protocol. 180 We have chosen to recommend that clients use the remaining option: a 181 single DHCP session and state machine. The client maintains a single 182 session and state machine. It uses the best configuration it is able 183 to obtain during any configuration exchange. But it continues, in 184 each subsequent configuration exchange, to request all the 185 configuration information it is programmed to try to obtain, 186 including any stateful configuration options for which no results 187 were returned in previous exchanges. 189 4.1. Placement of Status Codes in an Advertise Message 191 In Reply messages IA specific status codes (i.e., NoAddrsAvail, 192 NotOnLink, NoBinding, NoPrefixAvail) are encapsulated in the IA 193 option. In Advertise messages though, the NoAddrsAvail code is 194 returned at in the top level. This makes sense if the client is only 195 interested in the assignment of the addresses and the failure case is 196 fatal. However, if the client sends both IA_NA and IA_PD options in 197 a Solicit message, it is possible that the server offers no addresses 198 but it offers some prefixes, and the client may choose to send a 199 Request message to obtain the offered prefixes. In this case, it is 200 better if the Status Code option for IA specific status codes is 201 encapsulated in the IA option to indicate that the failure occurred 202 for the specific IA. This also makes the NoAddrsAvail and 203 NoPrefixAvail Status Code option placement for Advertise messages 204 identical to Reply messages. 206 In addition, how a server formats the Advertise message when 207 addresses are not available has been a point of some confusion and 208 implementations seem to vary (some strictly follow RFC 3315 while 209 others assumed it was encapsulated in the IA option as for Reply 210 messages). 212 We have chosen the following solution: 214 Clients MUST be prepared to handle each of the following Advertise 215 messages formats when there are no addresses available (even when no 216 other IA option types were in the Solicit): 218 1. Advertise containing the IA_NAs and/or IA_TAs with encapsulated 219 Status Code option of NoAddrsAvail and no top-level Status Code 220 option. 222 2. Advertise containing just a top-level Status Code option of 223 NoAddrsAvail and no IA_NAs/IA_TAs. 225 3. Advertise containing a top-level Status Code option of 226 NoAddrsAvail and IA_NAs and/or IA_TAs with a Status Code option 227 of NoAddrsAvail. 229 Note: Clients MUST be prepared to handle the last two formats listed 230 above to facilitate backward compatibility with the servers which 231 have not been updated to this specification. 233 See Section 4.2 for updated text for Section 17.1.3 of RFC 3315 and 234 Section 11.1 of RFC 3633. 236 Servers MUST return the Status Code option of NoAddrsAvail 237 encapsulated in an IA_NA/IA_TA options and not as a top-level Status 238 Code option of NoAddrsAvail when no addresses will be assigned (1 in 239 the above list). This means that the Advertise response matches the 240 Reply response with respect to the handling of the NoAddrsAvail 241 status. 243 Replace the following paragraph in RFC 3315, section 17.2.2: 245 If the server will not assign any addresses to any IAs in a 246 subsequent Request from the client, the server MUST send an 247 Advertise message to the client that includes only a Status 248 Code option with code NoAddrsAvail and a status message for 249 the user, a Server Identifier option with the server's DUID, 250 and a Client Identifier option with the client's DUID. 252 With: 254 If the server will not assign any addresses to an IA in a 255 subsequent Request from the client, the server MUST include 256 the IA in the Advertise message with no addresses in the IA 257 and a Status Code option encapsulated in the IA containing 258 status code NoAddrsAvail. 260 4.2. Advertise Message Processing by a Client 262 [RFC3315] specifies that a client must ignore an Advertise message if 263 a server will not assign any addresses to a client, and [RFC3633] 264 specifies that a client must ignore an Advertise message if a server 265 returns the NoPrefixAvail status to a requesting router. Thus, a 266 client requesting both IA_NA and IA_PD, with a server that only 267 offers either addresses or delegated prefixes, is not supported by 268 the current protocol specifications. 270 Solution: a client SHOULD accept Advertise messages, even when not 271 all IA option types are being offered. And, in this case, the client 272 SHOULD include the not offered IA option types in its Request. A 273 client SHOULD only ignore an Advertise message when none of the 274 requested IA options include offered addresses or delegated prefixes. 275 Note that ignored messages MUST still be processed for SOL_MAX_RT and 276 INF_MAX_RT options as specified in [RFC7083]. 278 Replace Section 17.1.3 of RFC 3315: (existing errata) 280 The client MUST ignore any Advertise message that includes a Status 281 Code option containing the value NoAddrsAvail, with the exception 282 that the client MAY display the associated status message(s) to the 283 user. 285 With (this includes the changes made by [RFC7083]): 287 The client MUST ignore any Advertise message that contains no 288 addresses (IAADDR options encapsulated in IA_NA or IA_TA options) 289 and no delegated prefixes (IAPREFIX options encapsulated in IA_PD 290 options, see RFC 3633) with the exception that the client: 291 - MUST process an included SOL_MAX_RT option (RFC 7083), 292 - MUST process an included INF_MAX_RT option (RFC 7083), and 293 - MAY display any associated status message(s) to the user. 294 The client ignoring this Advertise message MUST NOT restart the 295 Solicit retransmission timer. 297 And, replace: 299 - The client MAY choose a less-preferred server if that server 300 has a better set of advertised parameters, such as the 301 available addresses advertised in IAs. 303 With: 305 - The client MAY choose a less-preferred server if that server has 306 a better set of advertised parameters, such as the available set 307 of IAs, as well as the set of other configuration options 308 advertised. 310 And, replace the last paragraph of Section 11.1 of RFC 3633 with: 312 The requesting router MUST ignore any Advertise message that 313 contains no addresses (IAADDR options encapsulated in IA_NA or 314 IA_TA options) and no delegated prefixes (IAPREFIX options 315 encapsulated in IA_PD options, see RFC 3633) with the exception 316 that the requesting router: 317 - MUST process an included SOL_MAX_RT option (RFC 7083), 318 - MUST process an included INF_MAX_RT option (RFC 7083), and 319 - MAY display any associated status message(s) to the user. 320 The requesting router ignoring this Advertise message MUST NOT 321 restart the Solicit retransmission timer. 323 4.3. T1/T2 Timers 325 The T1 and T2 times determine when the client will contact the server 326 to extend lifetimes of information received in an IA. How should a 327 client handle the case where multiple IA options have different T1 328 and T2 times? 330 In a multiple IA option type model, the T1/T2 times are protocol 331 timers, that should be independent of the IA options themselves. If 332 we were to redo the DHCP protocol from scratch the T1/T2 times should 333 be carried in a separate DHCP option. 335 Solution: The server MUST set the T1/T2 times in all IA options in a 336 Reply or Advertise message to the same value. To deal with the case 337 where servers have not yet been updated to do that, the client MUST 338 select a T1 and T2 time from all IA options which will guarantee that 339 the client will send Renew/Rebind messages not later than at the T1/ 340 T2 times associated with any of the client's bindings. 342 As an example, if the client receives a Reply with T1_NA of 3600 / 343 T2_NA of 5760 and T1_PD of 0 / T2_PD of 1800, the client SHOULD use 344 the T1_PD of 0 / T2_PD of 1800. The reason for this is that a T1 of 345 0 means that the Renew time is at the client's discretion, but this 346 value cannot be greater than the T2 value (1800). 348 The following paragraph should be added to Sections 18.2.1, 18.2.3, 349 and 18.2.4 of RFC 3315: 351 The T1/T2 times set in each applicable IA option for a Reply MUST 352 be the same values across all IAs. The server MUST determine the 353 T1/T2 times across all of the applicable client's bindings in the 354 Reply. This facilitates the client being able to renew all of the 355 bindings at the same time. 357 Note: This additional paragraph has also been included in the revised 358 text later for Sections 18.2.3 and 18.2.4 of RFC 3315. 360 Changes for client T1/T2 handling are included in Section 4.4.3 and 361 Section 4.4.4. 363 4.4. Renew and Rebind Messages 365 This section presents issues with handling multiple IA option types 366 in the context of creation and processing the Renew and Rebind 367 messages. It also introduces relevant updates to the [RFC3315] and 368 [RFC3633]. 370 4.4.1. Renew Message 372 In multiple IA option type model, the client may include multiple IA 373 options in the Request message, and the server may create bindings 374 only for a subset of the IA options included by the client. For the 375 IA options in the Request message for which the server does not 376 create the bindings, the server sends the IA options in the Reply 377 message with the NoAddrsAvail or NoPrefixAvail status codes. 379 The client may accept the bindings created by the server, but may 380 desire the other bindings to be created once they become available, 381 e.g. when the server configuration is changed. The client which 382 accepted the bindings created by the server will periodically send a 383 Renew message to extend their lifetimes. However, the Renew message, 384 as described in the [RFC3315], does not support the ability for the 385 client to extend the lifetimes of the bindings for some IAs, while 386 requesting bindings for other IAs. 388 Solution: The client, which sends a Renew message to extend the 389 lifetimes of the bindings assigned to the client, should include IA 390 options for these bindings as well as IA options for all other 391 bindings that the client desires but has been unable to obtain. The 392 client and server processing need to be modified. Note that this 393 change makes the server's IA processing of Renew similar to the 394 Request processing. 396 4.4.2. Rebind Message 398 According to the Section 4.4.1, the client includes IA options in a 399 Renew message for the bindings it desires but has been unable to 400 obtain by sending a Request message, apart from the IA options for 401 the existing bindings. 403 At time T2, the client stops sending Renew messages to the server and 404 initiates the Rebind/Reply message exchange with any available 405 server. In this case, it should be possible to continue trying to 406 obtain new bindings using the Rebind message if the client failed to 407 get the response from the server to the Renew message. 409 Solution: The client should continue to include the IA options 410 received from the server and it may include additional IA options to 411 request creation of the additional bindings. 413 4.4.3. Updates to section 18.1.3 of RFC 3315 415 Replace Section 18.1.3 of RFC 3315 with the following text: 417 To extend the valid and preferred lifetimes for the addresses 418 assigned to an IA, the client sends a Renew message to the server 419 from which the addresses were obtained, which includes an IA option 420 for the IA whose address lifetimes are to be extended. The client 421 includes IA Address options within the IA option for the addresses 422 assigned to the IA. The server determines new lifetimes for these 423 addresses according to the administrative configuration of the 424 server. The server may also add new addresses to the IA. The 425 server can remove addresses from the IA by returning IA Address 426 options for such addresses with preferred and valid lifetimes set 427 to zero. 429 The server controls the time at which the client contacts the 430 server to extend the lifetimes on assigned addresses through the T1 431 and T2 parameters assigned to an IA. However, as the client 432 Renews/Rebinds all IAs from the server at the same time, the client 433 MUST select a T1 and T2 time from all IA options which will 434 guarantee that the client will send Renew/Rebind messages not later 435 than at the T1/T2 times associated with any of the client's 436 bindings. 438 At time T1, the client initiates a Renew/Reply message exchange to 439 extend the lifetimes on any addresses in the IA. 441 If T1 or T2 had been set to 0 by the server (for an IA_NA) or there 442 are no T1 or T2 times (for an IA_TA) in a previous Reply, the 443 client may send a Renew or Rebind message, respectively, at the 444 client's discretion. 446 The client sets the "msg-type" field to RENEW. The client 447 generates a transaction ID and inserts this value in the 448 "transaction-id" field. 450 The client places the identifier of the destination server in a 451 Server Identifier option. 453 The client MUST include a Client Identifier option to identify 454 itself to the server. The client adds any appropriate options, 455 including one or more IA options. 457 For IAs to which addresses have been assigned, the client includes 458 a corresponding IA option containing an IA Address option for each 459 address assigned to the IA. The client MUST not include addresses 460 in any IA option that the client did not obtain from the server or 461 that are no longer valid (that have a zero valid lifetime). 463 The client MAY include an IA option for each binding it desires but 464 has been unable to obtain. This IA option MUST NOT contain any 465 addresses. However, it MAY contain the IA Address option with IPv6 466 address field set to 0 to indicate the client's preference for the 467 preferred and valid lifetimes for any newly assigned addresses. 469 The client MUST include an Option Request option (see section 22.7) 470 to indicate the options the client is interested in receiving. The 471 client MAY include options with data values as hints to the server 472 about parameter values the client would like to have returned. 474 The client transmits the message according to section 14, using the 475 following parameters: 477 IRT REN_TIMEOUT 479 MRT REN_MAX_RT 481 MRC 0 483 MRD Remaining time until T2 485 The message exchange is terminated when time T2 is reached (see 486 section 18.1.4), at which time the client begins a Rebind message 487 exchange. 489 4.4.4. Updates to Section 18.1.4 of RFC 3315 491 Replace Section 18.1.4 of RFC 3315 with the following text: 493 At time T2 (which will only be reached if the server to which the 494 Renew message was sent at time T1 has not responded), the client 495 initiates a Rebind/Reply message exchange with any available 496 server. 498 The client constructs the Rebind message as described in 18.1.3 499 with the following differences: 501 - The client sets the "msg-type" field to REBIND. 503 - The client does not include the Server Identifier option in the 504 Rebind message. 506 The client transmits the message according to section 14, using the 507 following parameters: 509 IRT REB_TIMEOUT 511 MRT REB_MAX_RT 513 MRC 0 515 MRD Remaining time until valid lifetimes of all addresses in 516 all IAs have expired 518 If all addresses for an IA have expired the client may choose to 519 include this IA without any addresses (or with only a hint for 520 lifetimes) in subsequent Rebind messages to indicate that the 521 client is interested in assignment of the addresses to this IA. 523 The message exchange is terminated when the valid lifetimes of all 524 addresses across all IAs have expired, at which time the client 525 uses Solicit message to locate a new DHCP server and sends a 526 Request for the expired IAs to the new server. 528 4.4.5. Updates to Section 18.1.8 of RFC 3315 530 Replace Section 18.1.8 of RFC 3315 with the following text: 532 Upon the receipt of a valid Reply message in response to a Solicit 533 (with a Rapid Commit option), Request, Confirm, Renew, Rebind or 534 Information-request message, the client extracts the configuration 535 information contained in the Reply. The client MAY choose to 536 report any status code or message from the status code option in 537 the Reply message. 539 If the client receives a Reply message with a Status Code 540 containing UnspecFail, the server is indicating that it was unable 541 to process the message due to an unspecified failure condition. If 542 the client retransmits the original message to the same server to 543 retry the desired operation, the client MUST limit the rate at 544 which it retransmits the message and limit the duration of the time 545 during which it retransmits the message. 547 When the client receives a Reply message with a Status Code option 548 with the value UseMulticast, the client records the receipt of the 549 message and sends subsequent messages to the server through the 550 interface on which the message was received using multicast. The 551 client resends the original message using multicast. 553 When the client receives a NotOnLink status from the server in 554 response to a Confirm message, the client performs DHCP server 555 solicitation, as described in section 17, and client-initiated 556 configuration as described in section 18. If the client receives 557 any Reply messages that do not indicate a NotOnLink status, the 558 client can use the addresses in the IA and ignore any messages that 559 indicate a NotOnLink status. 561 When the client receives a NotOnLink status from the server in 562 response to a Request, the client can either re-issue the Request 563 without specifying any addresses or restart the DHCP server 564 discovery process (see section 17). 566 The client SHOULD perform duplicate address detection [17] on each 567 of the received addresses in any IAs, on which it has not performed 568 duplicate address detection during processing of any of the 569 previous Reply messages from the server. The client performs the 570 duplicate address detection before using the received addresses for 571 the traffic. If any of the addresses are found to be in use on the 572 link, the client sends a Decline message to the server for those 573 addresses as described in section 18.1.7. 575 If the Reply was received in response to a Solicit (with a Rapid 576 Commit option), Request, Renew or Rebind message, the client 577 updates the information it has recorded about IAs from the IA 578 options contained in the Reply message: 580 - Record T1 and T2 times. 582 - Add any new addresses in the IA option to the IA as recorded by 583 the client. 585 - Update lifetimes for any addresses in the IA option that the 586 client already has recorded in the IA. 588 - Discard any addresses from the IA, as recorded by the client, 589 that have a valid lifetime of 0 in the IA Address option. 591 - Leave unchanged any information about addresses the client has 592 recorded in the IA but that were not included in the IA from the 593 server. 595 Management of the specific configuration information is detailed in 596 the definition of each option in section 22. 598 The client examines the status code in each IA individually. If 599 the client receives a NoAddrsAvail status code, the client has 600 received no usable addresses in the IA. 602 If the client can operate with the addresses obtained from the 603 server the client uses addresses and other information from any IAs 604 that do not contain a Status Code option with the NoAddrsAvail 605 status code. The client MAY include the IAs for which it received 606 the NoAddrsAvail status code, with no addresses, in subsequent 607 Renew and Rebind messages sent to the server, to retry obtaining 608 the addresses for these IAs. 610 If the client cannot operate without the addresses for the IAs for 611 which it received the NoAddrsAvail status code, the client may try 612 another server (perhaps by restarting the DHCP server discovery 613 process). 615 If the client finds no usable addresses in any of the IAs, it may 616 either try another server (perhaps restarting the DHCP server 617 discovery process) or use the Information-request message to obtain 618 other configuration information only. 620 When the client receives a Reply message in response to a Renew or 621 Rebind message, the client: 623 - sends a Request message if any of the IAs in the Reply message 624 contains the NoBinding status code. The client places IA 625 options in this message for only those IAs for which the server 626 returned the NoBinding status code in the Reply message. The 627 client continues to use other bindings for which the server did 628 not return an error 630 - sends a Renew/Rebind if any of the IAs is not in the Reply 631 message, but in this case the client MUST limit the rate at 632 which it sends these messages, to avoid the Renew/Rebind storm 634 - otherwise accepts the information in the IA. 636 When the client receives a valid Reply message in response to a 637 Release message, the client considers the Release event completed, 638 regardless of the Status Code option(s) returned by the server. 640 When the client receives a valid Reply message in response to a 641 Decline message, the client considers the Decline event completed, 642 regardless of the Status Code option(s) returned by the server. 644 4.4.6. Updates to Section 18.2.3 of RFC 3315 646 Replace Section 18.2.3 of RFC 3315 with the following text: 648 When the server receives a Renew message via unicast from a client 649 to which the server has not sent a unicast option, the server 650 discards the Renew message and responds with a Reply message 651 containing a Status Code option with the value UseMulticast, a 652 Server Identifier option containing the server's DUID, the Client 653 Identifier option from the client message, and no other options. 655 For each IA in the Renew message from a client, the server locates 656 the client's binding and verifies that the information in the IA 657 from the client matches the information stored for that client. 659 If the server finds the client entry for the IA the server sends 660 back the IA to the client with new lifetimes and, if applicable, 661 T1/T2 times. If the server is unable to extend the lifetimes of an 662 address in the IA, the server MAY choose not to include the IA 663 Address option for this address. 665 The server may choose to change the list of addresses and the 666 lifetimes of addresses in IAs that are returned to the client. 668 If the server finds that any of the addresses in the IA are not 669 appropriate for the link to which the client is attached, the 670 server returns the address to the client with lifetimes of 0. 672 For each IA for which the server cannot find a client entry, the 673 server has the following choices depending on the server's policy 674 and configuration information: 676 - If the server is configured to create new bindings as a result 677 of processing Renew messages, the server SHOULD create a binding 678 and return the IA with allocated addresses with lifetimes and, 679 if applicable, T1/T2 times and other information requested by 680 the client. The server MAY use values in the IA Address option 681 (if included) as a hint. 683 - If the server is configured to create new bindings as a result 684 of processing Renew messages, but the server will not assign any 685 addresses to an IA, the server returns the IA option containing 686 a Status Code option with the NoAddrsAvail status code and a 687 status message for a user. 689 - If the server does not support creation of new bindings for the 690 client sending a Renew message, or if this behavior is disabled 691 according to the server's policy or configuration information, 692 the server returns the IA option containing a Status code option 693 with the NoBinding status code and a status message for a user. 695 The server constructs a Reply message by setting the "msg-type" 696 field to REPLY, and copying the transaction ID from the Renew 697 message into the transaction-id field. 699 The server MUST include a Server Identifier option containing the 700 server's DUID and the Client Identifier option from the Renew 701 message in the Reply message. 703 The server includes other options containing configuration 704 information to be returned to the client as described in section 705 18.2. 707 The T1/T2 times set in each applicable IA option for a Reply MUST 708 be the same values across all IAs. The server MUST determine the 709 T1/T2 times across all of the applicable client's bindings in the 710 Reply. This facilitates the client being able to renew all of the 711 bindings at the same time. 713 4.4.7. Updates to Section 18.2.4 of RFC 3315 715 Replace Section 18.2.4 of RFC 3315 with the following text: 717 When the server receives a Rebind message that contains an IA 718 option from a client, it locates the client's binding and verifies 719 that the information in the IA from the client matches the 720 information stored for that client. 722 If the server finds the client entry for the IA and the server 723 determines that the addresses in the IA are appropriate for the 724 link to which the client's interface is attached according to the 725 server's explicit configuration information, the server SHOULD 726 send back the IA to the client with new lifetimes and, if 727 applicable, T1/T2 times. If the server is unable to extend the 728 lifetimes of an address in the IA, the server MAY choose not to 729 include the IA Address option for this address. 731 If the server finds the client entry for the IA and any of the 732 addresses are no longer appropriate for the link to which the 733 client's interface is attached according to the server's explicit 734 configuration information, the server returns the address to the 735 client with lifetimes of 0. 737 If the server cannot find a client entry for the IA, the IA 738 contains addresses and the server determines that the addresses in 739 the IA are not appropriate for the link to which the client's 740 interface is attached according to the server's explicit 741 configuration information, the server MAY send a Reply message to 742 the client containing the client's IA, with the lifetimes for the 743 addresses in the IA set to 0. This Reply constitutes an explicit 744 notification to the client that the addresses in the IA are no 745 longer valid. In this situation, if the server does not send a 746 Reply message it silently discards the Rebind message. 748 Otherwise, for each IA for which the server cannot find a client 749 entry, the server has the following choices depending on the 750 server's policy and configuration information: 752 - If the server is configured to create new bindings as a result 753 of processing Rebind messages (also see the note about the 754 Rapid Commit option below), the server SHOULD create a binding 755 and return the IA with allocated addresses with lifetimes and, 756 if applicable, T1/T2 times and other information requested by 757 the client. The server MAY use values in the IA Address option 758 (if included) as a hint. 760 - If the server is configured to create new bindings as a result 761 of processing Rebind messages, but the server will not assign 762 any addresses to an IA, the server returns the IA option 763 containing a Status Code option with the NoAddrsAvail status 764 code and a status message for a user. 766 - If the server does not support creation of new bindings for the 767 client sending a Rebind message, or if this behavior is 768 disabled according to the server's policy or configuration 769 information, the server returns the IA option containing a 770 Status Code option with the NoBinding status code and a status 771 message for a user. 773 When the server creates new bindings for the IA it is possible 774 that other servers also create bindings as a result of receiving 775 the same Rebind message. This is the same issue as in the 776 Discussion under the Rapid Commit option, see section 22.14. 777 Therefore, the server SHOULD only create new bindings during 778 processing of a Rebind message if the server is configured to 779 respond with a Reply message to a Solicit message containing the 780 Rapid Commit option. 782 The server constructs a Reply message by setting the "msg-type" 783 field to REPLY, and copying the transaction ID from the Rebind 784 message into the transaction-id field. 786 The server MUST include a Server Identifier option containing the 787 server's DUID and the Client Identifier option from the Rebind 788 message in the Reply message. 790 The server includes other options containing configuration 791 information to be returned to the client as described in section 792 18.2. 794 The T1/T2 times set in each applicable IA option for a Reply MUST 795 be the same values across all IAs. The server MUST determine the 796 T1/T2 times across all of the applicable client's bindings in the 797 Reply. This facilitates the client being able to renew all of the 798 bindings at the same time. 800 4.4.8. Updates to RFC 3633 802 Replace the following text in Section 12.1 of RFC 3633: 804 Each prefix has valid and preferred lifetimes whose durations are 805 specified in the IA_PD Prefix option for that prefix. The 806 requesting router uses Renew and Rebind messages to request the 807 extension of the lifetimes of a delegated prefix. 809 With: 811 Each prefix has valid and preferred lifetimes whose durations are 812 specified in the IA_PD Prefix option for that prefix. The 813 requesting router uses Renew and Rebind messages to request the 814 extension of the lifetimes of a delegated prefix. 816 The requesting router MAY include IA_PD options without any 817 prefixes, i.e. without IA Prefix option or with IPv6 prefix field 818 of IA Prefix option set to 0, in a Renew or Rebind message to 819 obtain bindings it desires but has been unable to obtain. The 820 requesting router MAY set the prefix-length field of the IA Prefix 821 option as a hint to the server. As in [RFC3315], the requesting 822 router MAY also provide lifetime hints in the IA Prefix option. 824 Replace the following text in Section 12.2 of RFC 3633: 826 The delegating router behaves as follows when it cannot find a 827 binding for the requesting router's IA_PD: 829 With: 831 For the Renew or Rebind, if the IA_PD contains no IA Prefix option 832 or it contains an IA Prefix option with the IPv6 prefix field set 833 to 0, the delegating router SHOULD assign prefixes to the IA_PD 834 according to the delegating router's explicit configuration 835 information. In this case, if the IA_PD contains an IA Prefix 836 option with the IPv6 prefix field set to 0, the delegating router 837 MAY use the value in the prefix-length field of the IA Prefix 838 option as a hint for the length of the prefixes to be assigned. 839 The delegating router MAY also respect lifetime hints provided by 840 the requesting router in the IA Prefix option. 842 The delegating router behaves as follows when it cannot find a 843 binding for the requesting router's IA_PD containing prefixes: 845 4.5. Confirm Message 847 The Confirm message, as described in [RFC3315], is specific to 848 address assignment. It allows a server without a binding to reply to 849 the message, under the assumption that the server only needs 850 knowledge about the prefix(es) on the link, to inform the client that 851 the address is likely valid or not. This message is sent when e.g. 852 the client has moved and needs to validate its addresses. Not all 853 bindings can be validated by servers and the Confirm message provides 854 for this by specifying that a server that is unable to determine the 855 on-link status MUST NOT send a Reply. 857 Note: Confirm has a specific meaning and does not overload Renew/ 858 Rebind. It also is lower processing cost as the server does NOT need 859 to extend lease times or otherwise send back other configuration 860 options. 862 The Confirm message is used by the client to verify that it has not 863 moved to a different link. For IAs with addresses, the mechanism 864 used to verify if a client has moved or not, is by matching the 865 link's on-link prefix(es) (typically a /64) against the prefix-length 866 first bits of the addresses provided by the client in the IA_NA or 867 IA_TA IA-types. As a consequence Confirm can only be used when the 868 client has an IA with address(es) (IA_NA or IA_TA). 870 A client MUST have a binding including an IA with addresses to use 871 the Confirm message. A client with IAs with addresses as well as 872 other IA-types MAY, depending on the IA-type, use the Confirm message 873 to detect if the client has moved to a different link. A client that 874 does not have a binding with an IA with addresses MUST use the Rebind 875 message instead. 877 IA_PD requires verification that the delegating router (server) has 878 the binding for the IAs. In that case a requesting router (client) 879 MUST use the Rebind message in place of the Confirm message and it 880 MUST include all of its bindings, even address IAs. 882 Note that Section 18.1.2 of RFC 3315 states that a client MUST 883 initiate a Confirm when it may have moved to a new link. This is 884 relaxed to a SHOULD as a client may have determined whether it has or 885 has not moved using other techniques, such as described in [RFC6059]. 886 And, as stated above, a client with delegated prefixes, MUST send a 887 Rebind instead of a Confirm. 889 4.6. Decline Should Not Necessarily Trigger a Release 891 Some client implementations have been found to send a Release message 892 for other bindings they may have received after they determine a 893 conflict and have correctly sent a Decline message for the 894 conflicting address(es). 896 It is recommended that a client SHOULD NOT send a Release message for 897 other bindings it may have received just because it sent a Decline 898 message. The client SHOULD retain the non-conflicting bindings. The 899 client SHOULD treat the failure to acquire a binding as a result of 900 the conflict, to be equivalent to not having received the binding, 901 insofar as it behaves when sending Renew and Rebind messages. 903 4.7. Multiple Provisioning Domains 905 This document has assumed that all DHCP servers on a network are in a 906 single provisioning domain and thus should be "equal" in the service 907 that they offer. This was also assumed by [RFC3315] and [RFC3633]. 909 One could envision a network where the DHCP servers are in multiple 910 provisioning domains, and it may be desirable to have the DHCP client 911 obtain different IA types from different provisioning domains. How a 912 client detects the multiple provisioning domains and how it would 913 interact with the multiple servers in these different domains is 914 outside the scope of this document (see [I-D.ietf-mif-mpvd-arch] and 915 [I-D.ietf-mif-mpvd-dhcp-support]). 917 5. IANA Considerations 919 This specification does not require any IANA actions. 921 6. Security Considerations 923 There are no new security considerations pertaining to this document. 925 7. Acknowledgements 927 Thanks to many people that contributed to identify the stateful 928 issues addressed by this document and for reviewing drafts of the 929 document, including Ralph Droms, John Brzozowski, Ted Lemon, Hemant 930 Singh, Wes Beebee, Gaurau Halwasia, Bud Millword, Tim Winters, Rob 931 Shakir, Jinmei Tatuya, Andrew Yourtchenko, Fred Templin, Tomek 932 Mrugalski, Suresh Krishnan, and Ian Farrer. 934 8. References 936 8.1. Normative References 938 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 939 Requirement Levels", BCP 14, RFC 2119, March 1997. 941 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 942 and M. Carney, "Dynamic Host Configuration Protocol for 943 IPv6 (DHCPv6)", RFC 3315, July 2003. 945 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 946 Host Configuration Protocol (DHCP) version 6", RFC 3633, 947 December 2003. 949 [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT 950 and INF_MAX_RT", RFC 7083, November 2013. 952 8.2. Informative References 954 [I-D.dhcwg-dhc-rfc3315bis] 955 Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 956 Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host 957 Configuration Protocol for IPv6 (DHCPv6) bis", draft- 958 dhcwg-dhc-rfc3315bis-03 (work in progress), October 2014. 960 [I-D.ietf-mif-mpvd-arch] 961 Anipko, D., "Multiple Provisioning Domain Architecture", 962 draft-ietf-mif-mpvd-arch-09 (work in progress), January 963 2015. 965 [I-D.ietf-mif-mpvd-dhcp-support] 966 Krishnan, S., Korhonen, J., and S. Bhandari, "Support for 967 multiple provisioning domains in DHCPv6", draft-ietf-mif- 968 mpvd-dhcp-support-00 (work in progress), August 2014. 970 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 971 Detecting Network Attachment in IPv6", RFC 6059, November 972 2010. 974 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 975 Requirements for IPv6 Customer Edge Routers", RFC 7084, 976 November 2013. 978 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 979 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 980 BCP 187, RFC 7227, May 2014. 982 Authors' Addresses 984 Ole Troan 985 Cisco Systems, Inc. 986 Philip Pedersens vei 20 987 N-1324 Lysaker 988 Norway 990 Email: ot@cisco.com 992 Bernie Volz 993 Cisco Systems, Inc. 994 1414 Massachusetts Ave 995 Boxborough, MA 01719 996 USA 998 Email: volz@cisco.com 999 Marcin Siodelski 1000 ISC 1001 950 Charter Street 1002 Redwood City, CA 94063 1003 USA 1005 Email: msiodelski@gmail.com