idnits 2.17.1 draft-ietf-dhc-dhcpv6-stateful-issues-11.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 the creation date from RFC3315, updated by this document, for RFC5378 checks: 1995-02-03) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (February 12, 2015) is 3332 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 606 ** 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-10 == Outdated reference: A later version (-02) exists of draft-ietf-mif-mpvd-dhcp-support-00 Summary: 3 errors (**), 0 flaws (~~), 4 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 16, 2015 ISC 7 February 12, 2015 9 Issues and Recommendations with Multiple Stateful DHCPv6 Options 10 draft-ietf-dhc-dhcpv6-stateful-issues-11.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 16, 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 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 4. Handling of Multiple IA Option Types . . . . . . . . . . . . 4 72 4.1. Placement of Status Codes in an Advertise Message . . . . 5 73 4.2. Advertise Message Processing by a Client . . . . . . . . 7 74 4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 8 75 4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 9 76 4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 9 77 4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 10 78 4.4.3. Updates to section 18.1.3 of RFC 3315 . . . . . . . . 10 79 4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 12 80 4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 13 81 4.4.6. Updates to Section 18.2.3 of RFC 3315 . . . . . . . . 15 82 4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 16 83 4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 18 84 4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 19 85 4.6. Decline Should Not Necessarily Trigger a Release . . . . 20 86 4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 20 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 92 8.2. Informative References . . . . . . . . . . . . . . . . . 21 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 95 1. Introduction 97 DHCPv6 [RFC3315] was written without the expectation that additional 98 stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation 99 [RFC3633] since added a new stateful option for Prefix Delegation to 100 DHCPv6. Implementation experience of the Customer Edge Router (CER) 101 model described in [RFC7084] has shown issues with the DHCPv6 102 protocol in supporting multiple stateful option types, in particular 103 IA_NA (non-temporary addresses) and IA_PD (delegated prefixes). 105 This document describes a number of problems encountered with 106 coexistence of the IA_NA and IA_PD option types and specifies changes 107 to the DHCPv6 protocol to address these problems. 109 The intention of this work is to clarify and, where needed, modify 110 the DHCPv6 protocol specification to support IA_NA and IA_PD option 111 types within a single DHCPv6 session. 113 Note that while IA_TA (temporary addresses) options may be included 114 with other IA option type requests, these generally are not renewed 115 (there are no T1/T2 times) and have a separate life cycle from IA_NA 116 and IA_PD option types. Therefore, the IA_TA option type is mostly 117 out of scope for this document. 119 The changes described in this document are intended to be 120 incorporated in a new revision of the DHCPv6 protocol specification 121 ([I-D.dhcwg-dhc-rfc3315bis]). 123 2. Conventions 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 3. Terminology 131 In addition to the terminology defined in [RFC3315], [RFC3633], and 132 [RFC7227], the following terminology is used in this document: 134 Identity association (IA): Throughout this document, "IA" is 135 used to refer to the Identity 136 Association containing addresses or 137 prefixes assigned to a client and 138 carried in the IA_NA or IA_PD options 139 respectively. 141 IA option types: This is used to generally mean an 142 IA_NA and/or IA_PD option. 144 Stateful options: Options that require dynamic binding 145 state per client on the server. 147 Top-level options: Top-level options are DHCPv6 options 148 that are not encapsulated within 149 other options, excluding the Relay- 150 Message option. Options encapsulated 151 by Relay-message options, but not by 152 any other option, are still top-level 153 options, whether they appear in a 154 relay agent message or a server 155 message. See [RFC7227]. 157 4. Handling of Multiple IA Option Types 159 The DHCPv6 specification [RFC3315] was written with the assumption 160 that the only stateful options were for assigning addresses. DHCPv6 161 Prefix Delegation [RFC3633] describes how to extend the DHCPv6 162 protocol to handle prefix delegation, but does not clearly specify 163 how the DHCP address assignment and prefix delegation co-exist. 165 If a client requests multiple IA option types, but the server is 166 configured to only offer a subset of them, the client could react in 167 several ways: 169 1. Reset the state machine and continue to send Solicit messages, 171 2. Create separate DHCP sessions for each IA option type and 172 continue to Solicit for the unfulfilled IA options, or 174 3. The client could continue with the single session, and include 175 the unfulfilled IA options in subsequent messages to the server. 177 Resetting the state machine and continuing to send Solicit messages 178 may result in the client never completing DHCP and is generally not 179 considered a good solution. It can also result in a packet storm if 180 the client does not appropriately rate limit its sending of Solicit 181 messages or there are many clients on the network. Client 182 implementors that follow this approach, are strongly advised to 183 implement the updates to RFC-3315 specified in [RFC7083]. 185 Creating a separate DHCP session (separate instances of the client 186 state machine) per IA option type, while conceptually simple, causes 187 a number of issues: additional host resources required to create and 188 maintain multiple instances of the state machine in clients, 189 additional DHCP protocol traffic, unnecessary duplication of other 190 configuration options and the potential for conflict, divergence in 191 that each IA option type specification specifies its 'own' version of 192 the DHCP protocol. 194 The single session and state machine allows the client to use the 195 best configuration it is able to obtain from a single DHCP server 196 during the configuration exchange. Note, however, that the server 197 may not be configured to deliver the entire configuration requested 198 by the client. In that case the client could continue to operate 199 only using the configuration received, even if other servers can 200 provide the missing configuration. In practice, especially in the 201 case of handling IA_NA and IA_PD, this situation should be rare or a 202 temporary operational error. So, it is more likely for the client to 203 get all configuration if it continues, in each subsequent 204 configuration exchange, to request all the configuration information 205 it is programmed to try to obtain, including any stateful 206 configuration options for which no results were returned in previous 207 exchanges. 209 One major issue of this last approach is that it is difficult to 210 allow it with the current DHCPv6 specifications; in some cases they 211 are not clear enough, and in other cases existing restrictions can 212 make it impossible. This document introduces some clarifications and 213 small modifications to the current specifications to address these 214 concerns. 216 While all approaches have their own pros and cons, we recommend and 217 focus on approach 3 for this document because it is deemed to work 218 best for common cases of the mixed use of IA_NA and IA_PD. But this 219 document does not exclude other approaches. Also, in some corner 220 cases it may not be feasible to maintain a single DHCPv6 session for 221 both IA_NA and IA_PD. These corner cases are beyond the scope of 222 this document and may depend on the network in which the client (CER) 223 is designed to operate and on the functions the client is required to 224 perform. 226 The sections which follow update RFC 3315 and RFC 3633 to accommodate 227 the recommendation, though many of the changes are also applicable 228 even if other approaches are used. 230 4.1. Placement of Status Codes in an Advertise Message 232 In Reply messages IA specific status codes (i.e., NoAddrsAvail, 233 NotOnLink, NoBinding, NoPrefixAvail) are encapsulated in the IA 234 option. In Advertise messages though, the NoAddrsAvail code is 235 returned at in the top level. This makes sense if the client is only 236 interested in the assignment of the addresses and the failure case is 237 fatal. However, if the client sends both IA_NA and IA_PD options in 238 a Solicit message, it is possible that the server offers no addresses 239 but it offers some prefixes, and the client may choose to send a 240 Request message to obtain the offered prefixes. In this case, it is 241 better if the Status Code option for IA specific status codes is 242 encapsulated in the IA option to indicate that the failure occurred 243 for the specific IA. This also makes the NoAddrsAvail and 244 NoPrefixAvail Status Code option placement for Advertise messages 245 identical to Reply messages. 247 In addition, how a server formats the Advertise message when 248 addresses are not available has been a point of some confusion and 249 implementations seem to vary (some strictly follow RFC 3315 while 250 others assumed it was encapsulated in the IA option as for Reply 251 messages). 253 We have chosen the following solution: 255 Clients MUST be prepared to handle each of the following Advertise 256 messages formats when there are no addresses available (even when no 257 other IA option types were in the Solicit): 259 1. Advertise containing the IA_NAs and/or IA_TAs with encapsulated 260 Status Code option of NoAddrsAvail and no top-level Status Code 261 option. 263 2. Advertise containing just a top-level Status Code option of 264 NoAddrsAvail and no IA_NAs/IA_TAs. 266 3. Advertise containing a top-level Status Code option of 267 NoAddrsAvail and IA_NAs and/or IA_TAs with a Status Code option 268 of NoAddrsAvail. 270 Note: Clients MUST be prepared to handle the last two formats listed 271 above to facilitate backward compatibility with the servers which 272 have not been updated to this specification. 274 See Section 4.2 for updated text for Section 17.1.3 of RFC 3315 and 275 Section 11.1 of RFC 3633. 277 Servers MUST return the Status Code option of NoAddrsAvail 278 encapsulated in an IA_NA/IA_TA options and not as a top-level Status 279 Code option of NoAddrsAvail when no addresses will be assigned (1 in 280 the above list). This means that the Advertise response matches the 281 Reply response with respect to the handling of the NoAddrsAvail 282 status. 284 Replace the following paragraph in RFC 3315, section 17.2.2: 286 If the server will not assign any addresses to any IAs in a 287 subsequent Request from the client, the server MUST send an 288 Advertise message to the client that includes only a Status 289 Code option with code NoAddrsAvail and a status message for 290 the user, a Server Identifier option with the server's DUID, 291 and a Client Identifier option with the client's DUID. 293 With: 295 If the server will not assign any addresses to an IA in a 296 subsequent Request from the client, the server MUST include 297 the IA in the Advertise message with no addresses in the IA 298 and a Status Code option encapsulated in the IA containing 299 status code NoAddrsAvail. 301 4.2. Advertise Message Processing by a Client 303 [RFC3315] specifies that a client must ignore an Advertise message if 304 a server will not assign any addresses to a client, and [RFC3633] 305 specifies that a client must ignore an Advertise message if a server 306 returns the NoPrefixAvail status to a requesting router. Thus, a 307 client requesting both IA_NA and IA_PD, with a server that only 308 offers either addresses or delegated prefixes, is not supported by 309 the current protocol specifications. 311 Solution: a client SHOULD accept Advertise messages, even when not 312 all IA option types are being offered. And, in this case, the client 313 SHOULD include the not offered IA option types in its Request. A 314 client SHOULD only ignore an Advertise message when none of the 315 requested IA options include offered addresses or delegated prefixes. 316 Note that ignored messages MUST still be processed for SOL_MAX_RT and 317 INF_MAX_RT options as specified in [RFC7083]. 319 Replace Section 17.1.3 of RFC 3315: (existing errata) 321 The client MUST ignore any Advertise message that includes a Status 322 Code option containing the value NoAddrsAvail, with the exception 323 that the client MAY display the associated status message(s) to the 324 user. 326 With (this includes the changes made by [RFC7083]): 328 The client MUST ignore any Advertise message that contains no 329 addresses (IAADDR options encapsulated in IA_NA or IA_TA options) 330 and no delegated prefixes (IAPREFIX options encapsulated in IA_PD 331 options, see RFC 3633) with the exception that the client: 332 - MUST process an included SOL_MAX_RT option (RFC 7083), 333 - MUST process an included INF_MAX_RT option (RFC 7083), and 334 - MAY display any associated status message(s) to the user. 335 The client ignoring this Advertise message MUST NOT restart the 336 Solicit retransmission timer. 338 And, replace: 340 - The client MAY choose a less-preferred server if that server 341 has a better set of advertised parameters, such as the 342 available addresses advertised in IAs. 344 With: 346 - The client MAY choose a less-preferred server if that server has 347 a better set of advertised parameters, such as the available set 348 of IAs, as well as the set of other configuration options 349 advertised. 351 And, replace the last paragraph of Section 11.1 of RFC 3633 with: 353 The requesting router MUST ignore any Advertise message that 354 contains no addresses (IAADDR options encapsulated in IA_NA or 355 IA_TA options) and no delegated prefixes (IAPREFIX options 356 encapsulated in IA_PD options, see RFC 3633) with the exception 357 that the requesting router: 358 - MUST process an included SOL_MAX_RT option (RFC 7083), 359 - MUST process an included INF_MAX_RT option (RFC 7083), and 360 - MAY display any associated status message(s) to the user. 361 The requesting router ignoring this Advertise message MUST NOT 362 restart the Solicit retransmission timer. 364 4.3. T1/T2 Timers 366 The T1 and T2 times determine when the client will contact the server 367 to extend lifetimes of information received in an IA. How should a 368 client handle the case where multiple IA options have different T1 369 and T2 times? 371 In a multiple IA option type model, the T1/T2 times are protocol 372 timers, that should be independent of the IA options themselves. If 373 we were to redo the DHCP protocol from scratch the T1/T2 times should 374 be carried in a separate DHCP option. 376 Solution: The server MUST set the T1/T2 times in all IA options in a 377 Reply or Advertise message to the same value. To deal with the case 378 where servers have not yet been updated to do that, the client MUST 379 select a T1 and T2 time from all IA options which will guarantee that 380 the client will send Renew/Rebind messages not later than at the T1/ 381 T2 times associated with any of the client's bindings. 383 As an example, if the client receives a Reply with T1_NA of 3600 / 384 T2_NA of 5760 and T1_PD of 0 / T2_PD of 1800, the client SHOULD use 385 the T1_PD of 0 / T2_PD of 1800. The reason for this is that a T1 of 386 0 means that the Renew time is at the client's discretion, but this 387 value cannot be greater than the T2 value (1800). 389 The following paragraph should be added to Sections 18.2.1, 18.2.3, 390 and 18.2.4 of RFC 3315: 392 The T1/T2 times set in each applicable IA option for a Reply MUST 393 be the same values across all IAs. The server MUST determine the 394 T1/T2 times across all of the applicable client's bindings in the 395 Reply. This facilitates the client being able to renew all of the 396 bindings at the same time. 398 Note: This additional paragraph has also been included in the revised 399 text later for Sections 18.2.3 and 18.2.4 of RFC 3315. 401 Changes for client T1/T2 handling are included in Section 4.4.3 and 402 Section 4.4.4. 404 4.4. Renew and Rebind Messages 406 This section presents issues with handling multiple IA option types 407 in the context of creation and processing the Renew and Rebind 408 messages. It also introduces relevant updates to the [RFC3315] and 409 [RFC3633]. 411 4.4.1. Renew Message 413 In multiple IA option type model, the client may include multiple IA 414 options in the Request message, and the server may create bindings 415 only for a subset of the IA options included by the client. For the 416 IA options in the Request message for which the server does not 417 create the bindings, the server sends the IA options in the Reply 418 message with the NoAddrsAvail or NoPrefixAvail status codes. 420 The client may accept the bindings created by the server, but may 421 desire the other bindings to be created once they become available, 422 e.g. when the server configuration is changed. The client which 423 accepted the bindings created by the server will periodically send a 424 Renew message to extend their lifetimes. However, the Renew message, 425 as described in the [RFC3315], does not support the ability for the 426 client to extend the lifetimes of the bindings for some IAs, while 427 requesting bindings for other IAs. 429 Solution: The client, which sends a Renew message to extend the 430 lifetimes of the bindings assigned to the client, should include IA 431 options for these bindings as well as IA options for all other 432 bindings that the client desires but has been unable to obtain. The 433 client and server processing need to be modified. Note that this 434 change makes the server's IA processing of Renew similar to the 435 Request processing. 437 4.4.2. Rebind Message 439 According to the Section 4.4.1, the client includes IA options in a 440 Renew message for the bindings it desires but has been unable to 441 obtain by sending a Request message, apart from the IA options for 442 the existing bindings. 444 At time T2, the client stops sending Renew messages to the server and 445 initiates the Rebind/Reply message exchange with any available 446 server. In this case, it should be possible to continue trying to 447 obtain new bindings using the Rebind message if the client failed to 448 get the response from the server to the Renew message. 450 Solution: The client should continue to include the IA options 451 received from the server and it may include additional IA options to 452 request creation of the additional bindings. 454 4.4.3. Updates to section 18.1.3 of RFC 3315 456 Replace Section 18.1.3 of RFC 3315 with the following text: 458 To extend the valid and preferred lifetimes for the addresses 459 assigned to an IA, the client sends a Renew message to the server 460 from which the addresses were obtained, which includes an IA option 461 for the IA whose address lifetimes are to be extended. The client 462 includes IA Address options within the IA option for the addresses 463 assigned to the IA. The server determines new lifetimes for these 464 addresses according to the administrative configuration of the 465 server. The server may also add new addresses to the IA. The 466 server can remove addresses from the IA by returning IA Address 467 options for such addresses with preferred and valid lifetimes set 468 to zero. 470 The server controls the time at which the client contacts the 471 server to extend the lifetimes on assigned addresses through the T1 472 and T2 parameters assigned to an IA. However, as the client 473 Renews/Rebinds all IAs from the server at the same time, the client 474 MUST select a T1 and T2 time from all IA options which will 475 guarantee that the client will send Renew/Rebind messages not later 476 than at the T1/T2 times associated with any of the client's 477 bindings. 479 At time T1, the client initiates a Renew/Reply message exchange to 480 extend the lifetimes on any addresses in the IA. 482 If T1 or T2 had been set to 0 by the server (for an IA_NA) or there 483 are no T1 or T2 times (for an IA_TA) in a previous Reply, the 484 client may send a Renew or Rebind message, respectively, at the 485 client's discretion. 487 The client sets the "msg-type" field to RENEW. The client 488 generates a transaction ID and inserts this value in the 489 "transaction-id" field. 491 The client places the identifier of the destination server in a 492 Server Identifier option. 494 The client MUST include a Client Identifier option to identify 495 itself to the server. The client adds any appropriate options, 496 including one or more IA options. 498 For IAs to which addresses have been assigned, the client includes 499 a corresponding IA option containing an IA Address option for each 500 address assigned to the IA. The client MUST NOT include addresses 501 in any IA option that the client did not obtain from the server or 502 that are no longer valid (that have a zero valid lifetime). 504 The client MAY include an IA option for each binding it desires but 505 has been unable to obtain. This IA option MUST NOT contain any 506 addresses. However, it MAY contain the IA Address option with IPv6 507 address field set to 0 to indicate the client's preference for the 508 preferred and valid lifetimes for any newly assigned addresses. 510 The client MUST include an Option Request option (see section 22.7) 511 to indicate the options the client is interested in receiving. The 512 client MAY include options with data values as hints to the server 513 about parameter values the client would like to have returned. 515 The client transmits the message according to section 14, using the 516 following parameters: 518 IRT REN_TIMEOUT 519 MRT REN_MAX_RT 521 MRC 0 523 MRD Remaining time until T2 525 The message exchange is terminated when time T2 is reached (see 526 section 18.1.4), at which time the client begins a Rebind message 527 exchange. 529 4.4.4. Updates to Section 18.1.4 of RFC 3315 531 Replace Section 18.1.4 of RFC 3315 with the following text: 533 At time T2 (which will only be reached if the server to which the 534 Renew message was sent at time T1 has not responded), the client 535 initiates a Rebind/Reply message exchange with any available 536 server. 538 The client constructs the Rebind message as described in 18.1.3 539 with the following differences: 541 - The client sets the "msg-type" field to REBIND. 543 - The client does not include the Server Identifier option in the 544 Rebind message. 546 The client transmits the message according to section 14, using the 547 following parameters: 549 IRT REB_TIMEOUT 551 MRT REB_MAX_RT 553 MRC 0 555 MRD Remaining time until valid lifetimes of all addresses in 556 all IAs have expired 558 If all addresses for an IA have expired the client may choose to 559 include this IA without any addresses (or with only a hint for 560 lifetimes) in subsequent Rebind messages to indicate that the 561 client is interested in assignment of the addresses to this IA. 563 The message exchange is terminated when the valid lifetimes of all 564 addresses across all IAs have expired, at which time the client 565 uses Solicit message to locate a new DHCP server and sends a 566 Request for the expired IAs to the new server. 568 4.4.5. Updates to Section 18.1.8 of RFC 3315 570 Replace Section 18.1.8 of RFC 3315 with the following text: 572 Upon the receipt of a valid Reply message in response to a Solicit 573 (with a Rapid Commit option), Request, Confirm, Renew, Rebind or 574 Information-request message, the client extracts the configuration 575 information contained in the Reply. The client MAY choose to 576 report any status code or message from the status code option in 577 the Reply message. 579 If the client receives a Reply message with a Status Code 580 containing UnspecFail, the server is indicating that it was unable 581 to process the message due to an unspecified failure condition. If 582 the client retransmits the original message to the same server to 583 retry the desired operation, the client MUST limit the rate at 584 which it retransmits the message and limit the duration of the time 585 during which it retransmits the message. 587 When the client receives a Reply message with a Status Code option 588 with the value UseMulticast, the client records the receipt of the 589 message and sends subsequent messages to the server through the 590 interface on which the message was received using multicast. The 591 client resends the original message using multicast. 593 When the client receives a NotOnLink status from the server in 594 response to a Confirm message, the client performs DHCP server 595 solicitation, as described in section 17, and client-initiated 596 configuration as described in section 18. If the client receives 597 any Reply messages that do not indicate a NotOnLink status, the 598 client can use the addresses in the IA and ignore any messages that 599 indicate a NotOnLink status. 601 When the client receives a NotOnLink status from the server in 602 response to a Request, the client can either re-issue the Request 603 without specifying any addresses or restart the DHCP server 604 discovery process (see section 17). 606 The client SHOULD perform duplicate address detection [17] on each 607 of the received addresses in any IAs, on which it has not performed 608 duplicate address detection during processing of any of the 609 previous Reply messages from the server. The client performs the 610 duplicate address detection before using the received addresses for 611 the traffic. If any of the addresses are found to be in use on the 612 link, the client sends a Decline message to the server for those 613 addresses as described in section 18.1.7. 615 If the Reply was received in response to a Solicit (with a Rapid 616 Commit option), Request, Renew or Rebind message, the client 617 updates the information it has recorded about IAs from the IA 618 options contained in the Reply message: 620 - Record T1 and T2 times. 622 - Add any new addresses in the IA option to the IA as recorded by 623 the client. 625 - Update lifetimes for any addresses in the IA option that the 626 client already has recorded in the IA. 628 - Discard any addresses from the IA, as recorded by the client, 629 that have a valid lifetime of 0 in the IA Address option. 631 - Leave unchanged any information about addresses the client has 632 recorded in the IA but that were not included in the IA from the 633 server. 635 Management of the specific configuration information is detailed in 636 the definition of each option in section 22. 638 The client examines the status code in each IA individually. If 639 the client receives a NoAddrsAvail status code, the client has 640 received no usable addresses in the IA. 642 If the client can operate with the addresses obtained from the 643 server the client uses addresses and other information from any IAs 644 that do not contain a Status Code option with the NoAddrsAvail 645 status code. The client MAY include the IAs for which it received 646 the NoAddrsAvail status code, with no addresses, in subsequent 647 Renew and Rebind messages sent to the server, to retry obtaining 648 the addresses for these IAs. 650 If the client cannot operate without the addresses for the IAs for 651 which it received the NoAddrsAvail status code, the client may try 652 another server (perhaps by restarting the DHCP server discovery 653 process). 655 If the client finds no usable addresses in any of the IAs, it may 656 either try another server (perhaps restarting the DHCP server 657 discovery process) or use the Information-request message to obtain 658 other configuration information only. 660 When the client receives a Reply message in response to a Renew or 661 Rebind message, the client: 663 - sends a Request message if any of the IAs in the Reply message 664 contains the NoBinding status code. The client places IA 665 options in this message for only those IAs for which the server 666 returned the NoBinding status code in the Reply message. The 667 client continues to use other bindings for which the server did 668 not return an error 670 - sends a Renew/Rebind if any of the IAs is not in the Reply 671 message, but in this case the client MUST limit the rate at 672 which it sends these messages, to avoid the Renew/Rebind storm 674 - otherwise accepts the information in the IA. 676 When the client receives a valid Reply message in response to a 677 Release message, the client considers the Release event completed, 678 regardless of the Status Code option(s) returned by the server. 680 When the client receives a valid Reply message in response to a 681 Decline message, the client considers the Decline event completed, 682 regardless of the Status Code option(s) returned by the server. 684 4.4.6. Updates to Section 18.2.3 of RFC 3315 686 Replace Section 18.2.3 of RFC 3315 with the following text: 688 When the server receives a Renew message via unicast from a client 689 to which the server has not sent a unicast option, the server 690 discards the Renew message and responds with a Reply message 691 containing a Status Code option with the value UseMulticast, a 692 Server Identifier option containing the server's DUID, the Client 693 Identifier option from the client message, and no other options. 695 For each IA in the Renew message from a client, the server locates 696 the client's binding and verifies that the information in the IA 697 from the client matches the information stored for that client. 699 If the server finds the client entry for the IA the server sends 700 back the IA to the client with new lifetimes and, if applicable, 701 T1/T2 times. If the server is unable to extend the lifetimes of an 702 address in the IA, the server MAY choose not to include the IA 703 Address option for this address. 705 The server may choose to change the list of addresses and the 706 lifetimes of addresses in IAs that are returned to the client. 708 If the server finds that any of the addresses in the IA are not 709 appropriate for the link to which the client is attached, the 710 server returns the address to the client with lifetimes of 0. 712 For each IA for which the server cannot find a client entry, the 713 server has the following choices depending on the server's policy 714 and configuration information: 716 - If the server is configured to create new bindings as a result 717 of processing Renew messages, the server SHOULD create a binding 718 and return the IA with allocated addresses with lifetimes and, 719 if applicable, T1/T2 times and other information requested by 720 the client. The server MAY use values in the IA Address option 721 (if included) as a hint. 723 - If the server is configured to create new bindings as a result 724 of processing Renew messages, but the server will not assign any 725 addresses to an IA, the server returns the IA option containing 726 a Status Code option with the NoAddrsAvail status code and a 727 status message for a user. 729 - If the server does not support creation of new bindings for the 730 client sending a Renew message, or if this behavior is disabled 731 according to the server's policy or configuration information, 732 the server returns the IA option containing a Status code option 733 with the NoBinding status code and a status message for a user. 735 The server constructs a Reply message by setting the "msg-type" 736 field to REPLY, and copying the transaction ID from the Renew 737 message into the transaction-id field. 739 The server MUST include a Server Identifier option containing the 740 server's DUID and the Client Identifier option from the Renew 741 message in the Reply message. 743 The server includes other options containing configuration 744 information to be returned to the client as described in section 745 18.2. 747 The T1/T2 times set in each applicable IA option for a Reply MUST 748 be the same values across all IAs. The server MUST determine the 749 T1/T2 times across all of the applicable client's bindings in the 750 Reply. This facilitates the client being able to renew all of the 751 bindings at the same time. 753 4.4.7. Updates to Section 18.2.4 of RFC 3315 755 Replace Section 18.2.4 of RFC 3315 with the following text: 757 When the server receives a Rebind message that contains an IA 758 option from a client, it locates the client's binding and verifies 759 that the information in the IA from the client matches the 760 information stored for that client. 762 If the server finds the client entry for the IA and the server 763 determines that the addresses in the IA are appropriate for the 764 link to which the client's interface is attached according to the 765 server's explicit configuration information, the server SHOULD 766 send back the IA to the client with new lifetimes and, if 767 applicable, T1/T2 times. If the server is unable to extend the 768 lifetimes of an address in the IA, the server MAY choose not to 769 include the IA Address option for this address. 771 If the server finds the client entry for the IA and any of the 772 addresses are no longer appropriate for the link to which the 773 client's interface is attached according to the server's explicit 774 configuration information, the server returns the address to the 775 client with lifetimes of 0. 777 If the server cannot find a client entry for the IA, the IA 778 contains addresses and the server determines that the addresses in 779 the IA are not appropriate for the link to which the client's 780 interface is attached according to the server's explicit 781 configuration information, the server MAY send a Reply message to 782 the client containing the client's IA, with the lifetimes for the 783 addresses in the IA set to 0. This Reply constitutes an explicit 784 notification to the client that the addresses in the IA are no 785 longer valid. In this situation, if the server does not send a 786 Reply message it silently discards the Rebind message. 788 Otherwise, for each IA for which the server cannot find a client 789 entry, the server has the following choices depending on the 790 server's policy and configuration information: 792 - If the server is configured to create new bindings as a result 793 of processing Rebind messages (also see the note about the 794 Rapid Commit option below), the server SHOULD create a binding 795 and return the IA with allocated addresses with lifetimes and, 796 if applicable, T1/T2 times and other information requested by 797 the client. The server MAY use values in the IA Address option 798 (if included) as a hint. 800 - If the server is configured to create new bindings as a result 801 of processing Rebind messages, but the server will not assign 802 any addresses to an IA, the server returns the IA option 803 containing a Status Code option with the NoAddrsAvail status 804 code and a status message for a user. 806 - If the server does not support creation of new bindings for the 807 client sending a Rebind message, or if this behavior is 808 disabled according to the server's policy or configuration 809 information, the server returns the IA option containing a 810 Status Code option with the NoBinding status code and a status 811 message for a user. 813 When the server creates new bindings for the IA it is possible 814 that other servers also create bindings as a result of receiving 815 the same Rebind message. This is the same issue as in the 816 Discussion under the Rapid Commit option, see section 22.14. 817 Therefore, the server SHOULD only create new bindings during 818 processing of a Rebind message if the server is configured to 819 respond with a Reply message to a Solicit message containing the 820 Rapid Commit option. 822 The server constructs a Reply message by setting the "msg-type" 823 field to REPLY, and copying the transaction ID from the Rebind 824 message into the transaction-id field. 826 The server MUST include a Server Identifier option containing the 827 server's DUID and the Client Identifier option from the Rebind 828 message in the Reply message. 830 The server includes other options containing configuration 831 information to be returned to the client as described in section 832 18.2. 834 The T1/T2 times set in each applicable IA option for a Reply MUST 835 be the same values across all IAs. The server MUST determine the 836 T1/T2 times across all of the applicable client's bindings in the 837 Reply. This facilitates the client being able to renew all of the 838 bindings at the same time. 840 4.4.8. Updates to RFC 3633 842 Replace the following text in Section 12.1 of RFC 3633: 844 Each prefix has valid and preferred lifetimes whose durations are 845 specified in the IA_PD Prefix option for that prefix. The 846 requesting router uses Renew and Rebind messages to request the 847 extension of the lifetimes of a delegated prefix. 849 With: 851 Each prefix has valid and preferred lifetimes whose durations are 852 specified in the IA_PD Prefix option for that prefix. The 853 requesting router uses Renew and Rebind messages to request the 854 extension of the lifetimes of a delegated prefix. 856 The requesting router MAY include IA_PD options without any 857 prefixes, i.e. without IA Prefix option or with IPv6 prefix field 858 of IA Prefix option set to 0, in a Renew or Rebind message to 859 obtain bindings it desires but has been unable to obtain. The 860 requesting router MAY set the prefix-length field of the IA Prefix 861 option as a hint to the server. As in [RFC3315], the requesting 862 router MAY also provide lifetime hints in the IA Prefix option. 864 Replace the following text in Section 12.2 of RFC 3633: 866 The delegating router behaves as follows when it cannot find a 867 binding for the requesting router's IA_PD: 869 With: 871 For the Renew or Rebind, if the IA_PD contains no IA Prefix option 872 or it contains an IA Prefix option with the IPv6 prefix field set 873 to 0, the delegating router SHOULD assign prefixes to the IA_PD 874 according to the delegating router's explicit configuration 875 information. In this case, if the IA_PD contains an IA Prefix 876 option with the IPv6 prefix field set to 0, the delegating router 877 MAY use the value in the prefix-length field of the IA Prefix 878 option as a hint for the length of the prefixes to be assigned. 879 The delegating router MAY also respect lifetime hints provided by 880 the requesting router in the IA Prefix option. 882 The delegating router behaves as follows when it cannot find a 883 binding for the requesting router's IA_PD containing prefixes: 885 4.5. Confirm Message 887 The Confirm message, as described in [RFC3315], is specific to 888 address assignment. It allows a server without a binding to reply to 889 the message, under the assumption that the server only needs 890 knowledge about the prefix(es) on the link, to inform the client that 891 the address is likely valid or not. This message is sent when e.g. 892 the client has moved and needs to validate its addresses. Not all 893 bindings can be validated by servers and the Confirm message provides 894 for this by specifying that a server that is unable to determine the 895 on-link status MUST NOT send a Reply. 897 Note: Confirm has a specific meaning and does not overload Renew/ 898 Rebind. It also is lower processing cost as the server does NOT need 899 to extend lease times or otherwise send back other configuration 900 options. 902 The Confirm message is used by the client to verify that it has not 903 moved to a different link. For IAs with addresses, the mechanism 904 used to verify if a client has moved or not, is by matching the 905 link's on-link prefix(es) (typically a /64) against the prefix-length 906 first bits of the addresses provided by the client in the IA_NA or 907 IA_TA IA-types. As a consequence Confirm can only be used when the 908 client has an IA with address(es) (IA_NA or IA_TA). 910 A client MUST have a binding including an IA with addresses to use 911 the Confirm message. A client with IAs with addresses as well as 912 other IA-types MAY, depending on the IA-type, use the Confirm message 913 to detect if the client has moved to a different link. A client that 914 does not have a binding with an IA with addresses MUST use the Rebind 915 message instead. 917 IA_PD requires verification that the delegating router (server) has 918 the binding for the IAs. In that case a requesting router (client) 919 MUST use the Rebind message in place of the Confirm message and it 920 MUST include all of its bindings, even address IAs. 922 Note that Section 18.1.2 of RFC 3315 states that a client MUST 923 initiate a Confirm when it may have moved to a new link. This is 924 relaxed to a SHOULD as a client may have determined whether it has or 925 has not moved using other techniques, such as described in [RFC6059]. 926 And, as stated above, a client with delegated prefixes, MUST send a 927 Rebind instead of a Confirm. 929 4.6. Decline Should Not Necessarily Trigger a Release 931 Some client implementations have been found to send a Release message 932 for other bindings they may have received after they determine a 933 conflict and have correctly sent a Decline message for the 934 conflicting address(es). 936 It is recommended that a client SHOULD NOT send a Release message for 937 other bindings it may have received just because it sent a Decline 938 message. The client SHOULD retain the non-conflicting bindings. The 939 client SHOULD treat the failure to acquire a binding as a result of 940 the conflict, to be equivalent to not having received the binding, 941 insofar as it behaves when sending Renew and Rebind messages. 943 4.7. Multiple Provisioning Domains 945 This document has assumed that all DHCP servers on a network are in a 946 single provisioning domain and thus should be "equal" in the service 947 that they offer. This was also assumed by [RFC3315] and [RFC3633]. 949 One could envision a network where the DHCP servers are in multiple 950 provisioning domains, and it may be desirable to have the DHCP client 951 obtain different IA types from different provisioning domains. How a 952 client detects the multiple provisioning domains and how it would 953 interact with the multiple servers in these different domains is 954 outside the scope of this document (see [I-D.ietf-mif-mpvd-arch] and 955 [I-D.ietf-mif-mpvd-dhcp-support]). 957 5. IANA Considerations 959 This specification does not require any IANA actions. 961 6. Security Considerations 963 There are no new security considerations pertaining to this document. 965 7. Acknowledgements 967 Thanks to many people that contributed to identify the stateful 968 issues addressed by this document and for reviewing drafts of the 969 document, including Ralph Droms, John Brzozowski, Ted Lemon, Hemant 970 Singh, Wes Beebee, Gaurau Halwasia, Bud Millword, Tim Winters, Rob 971 Shakir, Jinmei Tatuya, Andrew Yourtchenko, Fred Templin, Tomek 972 Mrugalski, Suresh Krishnan, and Ian Farrer. 974 8. References 976 8.1. Normative References 978 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 979 Requirement Levels", BCP 14, RFC 2119, March 1997. 981 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 982 and M. Carney, "Dynamic Host Configuration Protocol for 983 IPv6 (DHCPv6)", RFC 3315, July 2003. 985 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 986 Host Configuration Protocol (DHCP) version 6", RFC 3633, 987 December 2003. 989 [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT 990 and INF_MAX_RT", RFC 7083, November 2013. 992 8.2. Informative References 994 [I-D.dhcwg-dhc-rfc3315bis] 995 Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 996 Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host 997 Configuration Protocol for IPv6 (DHCPv6) bis", draft- 998 dhcwg-dhc-rfc3315bis-03 (work in progress), October 2014. 1000 [I-D.ietf-mif-mpvd-arch] 1001 Anipko, D., "Multiple Provisioning Domain Architecture", 1002 draft-ietf-mif-mpvd-arch-10 (work in progress), February 1003 2015. 1005 [I-D.ietf-mif-mpvd-dhcp-support] 1006 Krishnan, S., Korhonen, J., and S. Bhandari, "Support for 1007 multiple provisioning domains in DHCPv6", draft-ietf-mif- 1008 mpvd-dhcp-support-00 (work in progress), August 2014. 1010 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 1011 Detecting Network Attachment in IPv6", RFC 6059, November 1012 2010. 1014 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1015 Requirements for IPv6 Customer Edge Routers", RFC 7084, 1016 November 2013. 1018 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 1019 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 1020 BCP 187, RFC 7227, May 2014. 1022 Authors' Addresses 1024 Ole Troan 1025 Cisco Systems, Inc. 1026 Philip Pedersens vei 20 1027 N-1324 Lysaker 1028 Norway 1030 Email: ot@cisco.com 1032 Bernie Volz 1033 Cisco Systems, Inc. 1034 1414 Massachusetts Ave 1035 Boxborough, MA 01719 1036 USA 1038 Email: volz@cisco.com 1039 Marcin Siodelski 1040 ISC 1041 950 Charter Street 1042 Redwood City, CA 94063 1043 USA 1045 Email: msiodelski@gmail.com