idnits 2.17.1 draft-ietf-dhc-dhcpv6-stateful-issues-07.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 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 (October 2, 2014) is 3493 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 529 ** 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-02 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 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: April 5, 2015 ISC 7 October 2, 2014 9 Issues and Recommendations with Multiple Stateful DHCPv6 Options 10 draft-ietf-dhc-dhcpv6-stateful-issues-07.txt 12 Abstract 14 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written 15 with the expectation that additional stateful DHCPv6 options would be 16 developed. IPv6 Prefix Options for Dynamic Host Configuration 17 Protocol (DHCP) version 6 shoe-horned the new options for Prefix 18 Delegation into DHCPv6. Implementation experience of the CPE model 19 described in RFC 7084 has shown multiple issues with the DHCPv6 20 protocol in supporting multiple stateful options. This document 21 updates RFC 3315 and RFC 3633. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 5, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Handling of Multiple IA Options Types . . . . . . . . . . . . 4 61 4.1. Placement of Status Codes . . . . . . . . . . . . . . . . 5 62 4.2. Advertise Message . . . . . . . . . . . . . . . . . . . . 6 63 4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 7 64 4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 8 65 4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 8 66 4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 8 67 4.4.3. Updates to section 18.1.3 of RFC 3315 . . . . . . . . 9 68 4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 10 69 4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 11 70 4.4.6. Updates to Section 18.2.3 of RFC 3315 . . . . . . . . 14 71 4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 15 72 4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 17 73 4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 18 74 4.6. Decline Should Not Necessarily Trigger a Release . . . . 19 75 4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 19 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 81 8.2. Informative References . . . . . . . . . . . . . . . . . 20 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 84 1. Introduction 86 DHCPv6 [RFC3315] was not written with the expectation that additional 87 stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation 88 [RFC3633] shoe-horned the new options for Prefix Delegation into 89 DHCPv6. Implementation experience of the CPE model described in 90 [RFC7084] has shown issues with the DHCPv6 protocol in supporting 91 multiple stateful option types, in particular IA_NA (non-temporary 92 addresses) and IA_PD (delegated prefixes). 94 This document describes a number of problems encountered with 95 coexistence of the IA_NA and IA_PD option types and changes to the 96 DHCPv6 protocol specifications to address these problems. 98 The intention of this work is to clarify and, where needed, modify 99 the DHCP protocol specification to support multiple IA option types 100 within a single DHCP session. However, as it is not possible to know 101 what future IA option types might be used for, this work is primarily 102 to clarify DHCP operation when IA_NA and IA_PD options are being 103 requested as per [RFC7084]. And, to provide a framework to support 104 new IA option types, assuming they are similar enough. Future 105 documents that define new IA option types will need to specify 106 whether they fit into this framework or define the DHCP operation for 107 the new and existing IA option types, as appropriate. 109 There are two general solutions to the problem of supporting multiple 110 IA option types. One is by using a separate DHCP session (separate 111 instances of the client state machine) per IA option type. While 112 conceptually simple, this approach has a number of issues: multiple 113 instances of the state machine in clients, additional DHCP protocol 114 traffic, 'collisions' between other configuration options, divergence 115 in that each IA option type specification specifies its 'own' version 116 of the DHCP protocol. The other is by using a single DHCP session 117 and state machine, which is the approach taken by this document (see 118 Section 4). 120 Note that while IA_TA (temporary addresses) options may be included 121 with other IA option type requests, these generally are not renewed 122 (there are no T1/T2 times) and have a separate life cycle from IA_NA 123 and IA_PD option types. DHCPv6 assigned temporary addresses also 124 have limited value when DHCPv6 is used for non-temporary address 125 assignment, as the privacy issues identified for IPv6 stateless 126 address assignment ([RFC4941]) do not apply to DHCPv6 assignments. 128 The changes described in this document are intended to be 129 incorporated in a new revision of the DHCPv6 protocol specification 130 ([I-D.dhcwg-dhc-rfc3315bis]). 132 2. Conventions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 3. Terminology 140 In addition to the terminology defined in [RFC3315], [RFC3633], and 141 [RFC7227], the following terminology is used in this document: 143 Resource (allocable resource): A value (or a collection of values) 144 dynamically assigned to the client by 145 the server and being carried in the 146 stateful options. Examples of 147 resources are an IPv6 address or an 148 IPv6 prefix. Information about the 149 resources is transported in stateful 150 options such as IA_NA, for addresses, 151 and IA_PD, for prefix delegations. 152 In the future, other types of 153 resources and stateful options may be 154 defined. 156 Identity association (IA): A collection of resources assigned to 157 a client. Each IA has an associated 158 IAID. A client may have more than 159 one IA assigned to it; for example, 160 one for each of its interfaces. Each 161 IA holds one type of IA option; for 162 example, an identity association for 163 non-temporary addresses (IA_NA) holds 164 non-temporary addresses. Throughout 165 this document, "IA" is used to refer 166 to an identity association without 167 identifying the type of resources in 168 the IA. 170 IA option types: This is used to generally mean an 171 IA_NA and/or IA_PD and may also 172 include IA_TA, as well as future IA 173 options. 175 Stateful options: Options that require dynamic binding 176 state per client on the server. 178 4. Handling of Multiple IA Options Types 180 DHCPv6 was written with the assumption that the only stateful options 181 were for assigning addresses. DHCPv6 PD describes how to extend the 182 DHCPv6 protocol to handle prefix delegation, but [RFC3633] did not 183 consider how DHCP address assignment and prefix delegation could co- 184 exist. 186 If a client requests multiple IA option types, but the server is 187 configured to only offer a subset of them, the client could react in 188 several ways. Reset the state machine and continue to send Solicit 189 messages, create separate DHCP sessions for each IA option type and 190 continue to Solicit for the unfulfilled IA options, or it could 191 continue with the single session, and include the unfulfilled IA 192 options in subsequent messages to the server. 194 Proposed solution: the client should keep a single session with the 195 server and include the missing options in subsequent messages 196 (Request, Renew, and Rebind) to the server. 198 4.1. Placement of Status Codes 200 In Reply messages IA specific status codes (i.e., NoAddrsAvail, 201 NotOnlink, NoBinding, NoPrefixAvail) are encapsulated in the IA 202 option. In Advertise messages the Status Code option with the 203 NoAddrsAvail code is in the top-level. That makes sense when the 204 failure case is fatal. However, with the introduction of other 205 stateful option types, there may be cases where a server is not 206 willing to offer addresses, but is willing to offer other resources, 207 e.g. delegated prefixes. 209 Ideally the Status Code option for IA specific status codes should be 210 encapsulated in the IA option for all DHCP messages. This also makes 211 the NoAddrsAvail and NoPrefixAvail Status Code option placement for 212 Advertise messages identical to Reply messages. 214 In addition, how a server formats the Advertise message when 215 addresses are not available has been a point of some confusion and 216 implementations seem to vary (some strictly follow RFC 3315 while 217 others assumed it was encapsulated in the IA option as for Reply 218 messages). 220 Therefore, the proposed solution is: 222 Clients MUST be prepared to handle each of the following Advertise 223 messages formats when there are no addresses available (even when no 224 other IA option types were in the Solicit): 226 1. Advertise containing just a top-level Status Code option (of 227 NoAddrsAvail) and no IA_NAs/IA_TAs. 229 2. Advertise containing the IA_NAs and/or IA_TAs with encapsulated 230 Status Code option (of NoAddrsAvail) and no top-level Status Code 231 option. 233 3. Advertise containing a top-level Status Code option (of 234 NoAddrsAvail) and IA_NAs and/or IA_TAs with a Status Code option 235 (of NoAddrsAvail). 237 Servers MUST return the Status Code option (of NoAddrsAvail) 238 encapsulated in an IA_NA/IA_TA options and not as a top-level Status 239 Code option (of NoAddrsAvail) when no addresses will be assigned (2 240 in the above list). This means that the Advertise response matches 241 the Reply response with respect to the handling of the NoAddrsAvail 242 status. 244 Replace the following paragraph in RFC 3315, section 17.2.2: 246 If the server will not assign any addresses to any IAs in a 247 subsequent Request from the client, the server MUST send an 248 Advertise message to the client that includes only a Status 249 Code option with code NoAddrsAvail and a status message for 250 the user, a Server Identifier option with the server's DUID, 251 and a Client Identifier option with the client's DUID. 253 With: 255 If the server will not assign any addresses to an IA in a 256 subsequent Request from the client, the server MUST include 257 the IA in the Advertise message with no addresses in the IA 258 and a Status Code option encapsulated in the IA containing 259 status code NoAddrsAvail. 261 4.2. Advertise Message 263 [RFC3315] specifies that a client must ignore an Advertise message if 264 a server will not assign any addresses to a client. A client 265 requesting both IA_NA and IA_PD, with a server that only offers one 266 of them, is not supported in the current protocol specification. 268 Proposed solution: a client SHOULD accept Advertise messages, even 269 when not all IA option types are being offered. And, in this case, 270 the client SHOULD include the not offered IA option types in its 271 Request. A client SHOULD only ignore an Advertise message when all 272 IA options include no offered addresses or delegated prefixes. Note 273 that ignored messages MUST still be processed for SOL_MAX_RT and 274 INF_MAX_RT options as specified in [RFC7083]. 276 Replace Section 17.1.3 of RFC 3315: (existing errata) 278 The client MUST ignore any Advertise message that includes a Status 279 Code option containing the value NoAddrsAvail, with the exception 280 that the client MAY display the associated status message(s) to the 281 user. 283 With (this includes the changes made by [RFC7083]): 285 The client MUST ignore any Advertise message that contains no 286 addresses (IAADDR options encapsulated in IA_NA or IA_TA options) 287 and no delegated prefixes (IAPREFIX options encapsulated in IA_PD 288 options, see RFC 3633) with the exception that the client 289 MUST process an included SOL_MAX_RT option (RFC 7083), MUST 290 process an included INF_MAX_RT option (RFC 7083), and MAY 291 display any associated status message(s) to the user. 293 And, replace: 295 - The client MAY choose a less-preferred server if that server 296 has a better set of advertised parameters, such as the 297 available addresses advertised in IAs. 299 With: 301 - The client MAY choose a less-preferred server if that server 302 has a better set of advertised parameters, such as the 303 available options advertised in IAs. 305 It is important to note that the receipt of an Advertise message 306 without any addresses and delegated prefixes does not imply that the 307 client should restart the Solicit retransmissions timers. Doing so 308 would lead to a Solicit/Advertise storm. 310 4.3. T1/T2 Timers 312 The T1 and T2 times determine when the client will contact the server 313 to extend lifetimes of information received in an IA. How should a 314 client handle the case where multiple IA options have different T1 315 and T2 times? 317 In a multiple IA option type model, the T1/T2 times are protocol 318 timers, that should be independent of the IA options themselves. If 319 we were to redo the DHCP protocol from scratch the T1/T2 times should 320 be carried in a separate DHCP option. 322 Proposed solution: The server MUST set the T1/T2 times in all IA 323 options in a Reply or Advertise message to the same value. To deal 324 with the case where servers have not yet been updated to do that, 325 clients MUST use the shortest (explicit or implicit) T1/T2 times 326 (larger than 0), from the same IA option, in the Reply. T1/T2 times 327 from other IAs are ignored. 329 The following paragraph should be added to Section 18.2.1, 18.2.3, 330 and 18.2.4 of RFC 3315: 332 The T1/T2 times set in each applicable IA option for a Reply MUST 333 be the same values across all IAs. The server MUST determine the 334 T1/T2 times across all of the applicable client's bindings in the 335 Reply. This facilitates the client being able to renew all of the 336 bindings at the same time. 338 4.4. Renew and Rebind Messages 340 This section presents issues with handling multiple IA option types 341 in the context of creation and processing the Renew and Rebind 342 messages. It also proposes relevant updates to the [RFC3315] and 343 [RFC3633]. 345 4.4.1. Renew Message 347 The Renew message, as described in [RFC3315], allows a client to only 348 renew bindings assigned via a Request message. 350 In a multiple IA option type model, the Renew does not support the 351 ability for the client to renew one IA option type while requesting 352 bindings for other IA option types that were not available when the 353 client sent the Request. 355 Proposed solution: The client should continue with the IA options 356 received, while continuing to include the other IA options in 357 subsequent messages to the server. The client and server processing 358 need to be modified. Note that this change makes the server's IA 359 processing of Renew similar to the Request processing. 361 4.4.2. Rebind Message 363 In Section 4.4.1 it has been proposed that the client includes IA 364 options in a Renew message for the bindings it desires but has been 365 unable to obtain by sending a Request message, apart from the IA 366 options for the existing bindings. 368 At time T2, the client stops sending Renew messages to the server and 369 initiates the Rebind/Reply message exchange with any available 370 server. In this case, it should be possible to continue trying to 371 obtain new bindings using the Rebind message if the client failed to 372 get the response from the server to the Renew message. 374 The Rebind message, as described in [RFC3315] does not explicitly 375 specify what a server should do when an IA option which contains no 376 addresses is present. 378 Proposed solution: The client should continue with the IA options 379 received and it MAY include additional IA options to request creation 380 of additional bindings. 382 4.4.3. Updates to section 18.1.3 of RFC 3315 384 Replace Section 18.1.3 of RFC 3315 with the following text: 386 To extend the valid and preferred lifetimes for the addresses 387 associated with an IA, the client sends a Renew message to the 388 server from which the client obtained the addresses in the IA 389 containing an IA option for the IA. The client includes IA Address 390 options in the IA option for the addresses associated with the IA. 391 The server determines new lifetimes for the addresses in the IA 392 according to the administrative configuration of the server. The 393 server may also add new addresses to the IA. The server may remove 394 addresses from the IA by setting the preferred and valid lifetimes 395 of those addresses to zero. 397 The server controls the time at which the client contacts the 398 server to extend the lifetimes on assigned addresses through the T1 399 and T2 parameters assigned to an IA. 401 At time T1 for an IA, the client initiates a Renew/Reply message 402 exchange to extend the lifetimes on any addresses in the IA. 404 If T1 or T2 had been set to 0 by the server (for an IA_NA) or there 405 are no T1 or T2 times (for an IA_TA) in a previous Reply, the 406 client may send a Renew or Rebind message, respectively, at the 407 client's discretion. 409 The client sets the "msg-type" field to RENEW. The client 410 generates a transaction ID and inserts this value in the 411 "transaction-id" field. 413 The client places the identifier of the destination server in a 414 Server Identifier option. 416 The client MUST include a Client Identifier option to identify 417 itself to the server. The client adds any appropriate options, 418 including one or more IA options. 420 The client includes an IA option with all addresses currently 421 assigned to the IA in its Renew message. The client also includes 422 IA options for all other bindings for which the client desires to 423 extend the lifetimes of addresses. The client MUST only include 424 addresses in the IA that the client obtained from the server and 425 are still valid (have non-zero lifetime). 427 The client MAY include an IA option for each binding it desires but 428 has been unable to obtain. This IA option MUST NOT contain any 429 addresses. However, it MAY contain the IA Address option with IPv6 430 address field set to 0 to indicate the client's preference for the 431 preferred and valid lifetimes for any newly assigned addresses. 433 The client MUST include an Option Request option (see section 22.7) 434 to indicate the options the client is interested in receiving. The 435 client MAY include options with data values as hints to the server 436 about parameter values the client would like to have returned. 438 The client transmits the message according to section 14, using the 439 following parameters: 441 IRT REN_TIMEOUT 443 MRT REN_MAX_RT 445 MRC 0 447 MRD Remaining time until T2 449 The message exchange is terminated when time T2 is reached (see 450 section 18.1.4), at which time the client begins a Rebind message 451 exchange. 453 4.4.4. Updates to Section 18.1.4 of RFC 3315 455 Replace Section 18.1.4 of RFC 3315 with the following text: 457 At time T2 for an IA (which will only be reached if the server to 458 which the Renew message was sent at time T1 has not responded), the 459 client initiates a Rebind/Reply message exchange with any available 460 server. 462 The client constructs the Rebind message as described in 18.1.3 463 with the following differences: 465 - The client sets the "msg-type" field to REBIND. 467 - The client does not include the Server Identifier option in the 468 Rebind message. 470 The client transmits the message according to section 14, using the 471 following parameters: 473 IRT REB_TIMEOUT 474 MRT REB_MAX_RT 476 MRC 0 478 MRD Remaining time until valid lifetimes of all addresses in 479 all IAs have expired 481 If all addresses for an IA have expired the client may choose to 482 include this IA without any addresses (or with only a hint for 483 lifetimes) in subsequent Rebind messages to indicate that the 484 client is interested in assignment of the addresses to this IA. 486 The message exchange is terminated when the valid lifetimes of all 487 addresses across all IAs have expired, at which time the client may 488 use a Solicit message to locate a new DHCP server and send a 489 Request for the expired IAs to the new server. 491 4.4.5. Updates to Section 18.1.8 of RFC 3315 493 Replace Section 18.1.8 of RFC 3315 with the following text: 495 Upon the receipt of a valid Reply message in response to a Solicit 496 (with a Rapid Commit option), Request, Confirm, Renew, Rebind or 497 Information-request message, the client extracts the configuration 498 information contained in the Reply. The client MAY choose to 499 report any status code or message from the status code option in 500 the Reply message. 502 If the client receives a Reply message with a Status Code 503 containing UnspecFail, the server is indicating that it was unable 504 to process the message due to an unspecified failure condition. If 505 the client retransmits the original message to the same server to 506 retry the desired operation, the client MUST limit the rate at 507 which it retransmits the message and limit the duration of the time 508 during which it retransmits the message. 510 When the client receives a Reply message with a Status Code option 511 with the value UseMulticast, the client records the receipt of the 512 message and sends subsequent messages to the server through the 513 interface on which the message was received using multicast. The 514 client resends the original message using multicast. 516 When the client receives a NotOnLink status from the server in 517 response to a Confirm message, the client performs DHCP server 518 solicitation, as described in section 17, and client-initiated 519 configuration as described in section 18. If the client receives 520 any Reply messages that do not indicate a NotOnLink status, the 521 client can use the addresses in the IA and ignore any messages that 522 indicate a NotOnLink status. 524 When the client receives a NotOnLink status from the server in 525 response to a Request, the client can either re-issue the Request 526 without specifying any addresses or restart the DHCP server 527 discovery process (see section 17). 529 The client SHOULD perform duplicate address detection [17] on each 530 of the received addresses in any IAs, on which it has not performed 531 duplicate address detection during processing of any of the 532 previous Reply messages from the server. The client performs the 533 duplicate address detection before using the received addresses for 534 the traffic. If any of the addresses are found to be in use on the 535 link, the client sends a Decline message to the server for those 536 addresses as described in section 18.1.7. 538 If the Reply was received in response to a Solicit (with a Rapid 539 Commit option), Request, Renew or Rebind message, the client 540 updates the information it has recorded about IAs from the IA 541 options contained in the Reply message: 543 - Record T1 and T2 times. The client MUST use the shortest 544 (explicit or implicit) T1 and T2 times (larger than 0) from the 545 same IA option across all of the IA options to facilitate 546 initiating the renewal process for all bindings simultaneously. 547 T1/T2 times from other IAs are ignored. 549 - Add any new addresses in the IA option to the IA as recorded by 550 the client. 552 - Update lifetimes for any addresses in the IA option that the 553 client already has recorded in the IA. 555 - Discard any addresses from the IA, as recorded by the client, 556 that have a valid lifetime of 0 in the IA Address option. 558 - Leave unchanged any information about addresses the client has 559 recorded in the IA but that were not included in the IA from the 560 server. 562 Management of the specific configuration information is detailed in 563 the definition of each option in section 22. 565 The client examines the status code in each IA individually. If 566 the client receives a NoAddrsAvail, the client has received no 567 usable addresses in the IA. 569 If the client finds no usable addresses in any IA, the client MAY 570 use the Information-request message to obtain other configuration 571 information only. 573 The client uses addresses and other information from any IAs that 574 do not contain a Status Code option with the NoAddrsAvail code. 575 For each IA for which the client receives NoAddrsAvail status code 576 the client has the following choices: 578 - The client includes the IA with no addresses in subsequent Renew 579 and Rebind messages sent to the server, to request creation of 580 the binding for the IA. 582 - Tries another server (perhaps restarting the DHCP server 583 discovery process). 585 When the client receives a Reply message in response to a Renew or 586 Rebind message, for each IA in the original Renew or Rebind 587 message, the client: 589 - Sends a Request message if the IA sent in the Renew or Rebind 590 contained addresses that the client is currently using and the 591 server responded with a NoBinding status code. 593 - Tries to obtain the IA from another server (by restarting the 594 DHCP discovery process) if the client attempted to obtain a new 595 binding in the Renew or Rebind message by sending an IA without 596 any addresses and the server responded with NoBinding status 597 code. 599 - Follows the retransmission procedure for Renew/Rebind messages 600 as described in section 14 if the IA is not in the Reply 601 message. 603 - Otherwise accepts the information in the IA. 605 When the client receives a valid Reply message in response to a 606 Release message, the client considers the Release event completed, 607 regardless of the Status Code option(s) returned by the server. 609 When the client receives a valid Reply message in response to a 610 Decline message, the client considers the Decline event completed, 611 regardless of the Status Code option(s) returned by the server. 613 4.4.6. Updates to Section 18.2.3 of RFC 3315 615 Replace Section 18.2.3 of RFC 3315 with the following text: 617 When the server receives a Renew message via unicast from a client 618 to which the server has not sent a unicast option, the server 619 discards the Renew message and responds with a Reply message 620 containing a Status Code option with the value UseMulticast, a 621 Server Identifier option containing the server's DUID, the Client 622 Identifier option from the client message, and no other options. 624 For each IA in the Renew message from a client, the server locates 625 the client's binding and verifies that the information in the IA 626 from the client matches the information stored for that client. 628 If the server finds the addresses in the IA for the client then the 629 server sends back the IA to the client with new lifetimes and, if 630 applicable, T1/T2 times. If the server is unable to extend the 631 lifetimes of an address in the IA, the server MAY choose not to 632 include the IA Address option for this address. 634 The server may choose to change the list of addresses and the 635 lifetimes of addresses in IAs that are returned to the client. 637 If the server finds that any of the addresses in the IA are not 638 appropriate for the link to which the client is attached, the 639 server returns the address to the client with lifetimes of 0. 641 For each IA for which the server cannot find a client entry, the 642 server has the following choices depending on the server's policy 643 and configuration information: 645 - If the server is configured to create new bindings as a result 646 of processing Renew messages, the server SHOULD create a binding 647 and return the IA with allocated addresses with lifetimes and, 648 if applicable, T1/T2 times and other information requested by 649 the client. The server MAY use values in the IA Address option 650 (if included) as a hint. 652 - If the server is configured to create new bindings as a result 653 of processing Renew messages, but the server will not assign any 654 addresses to an IA, the server returns the IA option containing 655 a Status Code option with the NoAddrsAvail status code and a 656 status message for a user. 658 - If the server does not support creation of new bindings for the 659 client sending a Renew message, or if this behavior is disabled 660 according to the server's policy or configuration information, 661 the server returns the IA option containing a Status code option 662 with the NoBinding status code and a status message for a user. 664 The server constructs a Reply message by setting the "msg-type" 665 field to REPLY, and copying the transaction ID from the Renew 666 message into the transaction-id field. 668 The server MUST include a Server Identifier option containing the 669 server's DUID and the Client Identifier option from the Renew 670 message in the Reply message. 672 The server includes other options containing configuration 673 information to be returned to the client as described in section 674 18.2. 676 The T1/T2 times set in each applicable IA option for a Reply MUST 677 be the same values across all IAs. The server MUST determine the 678 T1/T2 times across all of the applicable client's bindings in the 679 Reply. This facilitates the client being able to renew all of the 680 bindings at the same time. 682 4.4.7. Updates to Section 18.2.4 of RFC 3315 684 Replace Section 18.2.4 of RFC 3315 with the following text: 686 When the server receives a Rebind message that contains an IA 687 option from a client, it locates the client's binding and verifies 688 that the information in the IA from the client matches the 689 information stored for that client. 691 If the server finds the addresses in the IA for the client and the 692 server determines that the addresses in the IA are appropriate for 693 the link to which the client's interface is attached according to 694 the server's explicit configuration information, the server SHOULD 695 send back the IA to the client with new lifetimes and, if 696 applicable, T1/T2 times. If the server is unable to extend the 697 lifetimes of an address in the IA, the server MAY choose not to 698 include the IA Address option for this address. 700 If the server finds the client entry for the IA and any of the 701 addresses are no longer appropriate for the link to which the 702 client's interface is attached according to the server's explicit 703 configuration information, the server returns the addresses to the 704 client with lifetimes of 0. 706 If the server cannot find a client entry for the IA, the IA 707 contains addresses and the server determines that the addresses in 708 the IA are not appropriate for the link to which the client's 709 interface is attached according to the server's explicit 710 configuration information, the server MAY send a Reply message to 711 the client containing the client's IA, with the lifetimes for the 712 addresses in the IA set to 0. This Reply constitutes an explicit 713 notification to the client that the addresses in the IA are no 714 longer valid. In this situation, if the server does not send a 715 Reply message it silently discards the Rebind message. 717 Otherwise, for each IA for which the server cannot find a client 718 entry, the server has the following choices depending on the 719 server's policy and configuration information: 721 - If the server is configured to create new bindings as a result 722 of processing Rebind messages (also see the note about the 723 Rapid Commit option below), the server SHOULD create a binding 724 and return the IA with allocated addresses with lifetimes and, 725 if applicable, T1/T2 times and other information requested by 726 the client. The server MAY use values in the IA Address option 727 (if included) as a hint. 729 - If the server is configured to create new bindings as a result 730 of processing Rebind messages, but the server will not assign 731 any addresses to an IA, the server returns the IA option 732 containing a Status Code option with the NoAddrsAvail status 733 code and a status message for a user. 735 - If the server does not support creation of new bindings for the 736 client sending a Rebind message, or if this behavior is 737 disabled according to the server's policy or configuration 738 information, the server returns the IA option containing a 739 Status Code option with the NoBinding status code and a status 740 message for a user. 742 When the server creates new bindings for the IA it is possible 743 that other servers also create bindings as a result of receiving 744 the same Rebind message. This is the same issue as in the 745 Discussion under the Rapid Commit option, see section 22.14. 746 Therefore, the server SHOULD only create new bindings during 747 processing of a Rebind message if the server is configured to 748 respond with a Reply message to a Solicit message containing the 749 Rapid Commit option. 751 The server constructs a Reply message by setting the "msg-type" 752 field to REPLY, and copying the transaction ID from the Rebind 753 message into the transaction-id field. 755 The server MUST include a Server Identifier option containing the 756 server's DUID and the Client Identifier option from the Rebind 757 message in the Reply message. 759 The server includes other options containing configuration 760 information to be returned to the client as described in section 761 18.2. 763 The T1/T2 times set in each applicable IA option for a Reply MUST 764 be the same values across all IAs. The server MUST determine the 765 T1/T2 times across all of the applicable client's bindings in the 766 Reply. This facilitates the client being able to renew all of the 767 bindings at the same time. 769 4.4.8. Updates to RFC 3633 771 Replace Section 12.1: 773 Each prefix has valid and preferred lifetimes whose durations are 774 specified in the IA_PD Prefix option for that prefix. The 775 requesting router uses Renew and Rebind messages to request the 776 extension of the lifetimes of a delegated prefix. 778 With: 780 Each prefix has valid and preferred lifetimes whose durations are 781 specified in the IA_PD Prefix option for that prefix. The 782 requesting router uses Renew and Rebind messages to request the 783 extension of the lifetimes of a delegated prefix. 785 The requesting router MAY include IA_PD options without any 786 prefixes, i.e. without IA Prefix option or with IPv6 prefix field 787 of IA Prefix option set to 0, in a Renew or Rebind message to 788 obtain bindings it desires but has been unable to obtain. The 789 requesting router MAY set the prefix-length field of the IA Prefix 790 option as a hint to the server. 792 Replace Section 12.2: 794 The delegating router behaves as follows when it cannot find a 795 binding for the requesting router's IA_PD: 797 With: 799 For the Renew or Rebind, if the IA_PD contains no prefixes, i.e. 800 contains no IA Prefix option or the IPv6 prefix field in the IA 801 Prefix option is set to 0, the delegating router MAY assign 802 prefixes to the IA_PD according to the delegating router's 803 explicit configuration information. In this case, when the server 804 assigns new prefixes to the IA_PD, the server MAY use the value in 805 the prefix-length field of the IA Prefix option as a hint for the 806 length of the prefixes being assigned. 808 The delegating router behaves as follows when it cannot find a 809 binding for the requesting router's IA_PD containing prefixes: 811 4.5. Confirm Message 813 The Confirm message, as described in [RFC3315], is specific to 814 address assignment. It allows a server without a binding to reply to 815 the message, under the assumption that the server only needs 816 knowledge about the prefix(es) on the link, to inform the client that 817 the address is likely valid or not. This message is sent when e.g. 818 the client has moved and needs to validate its addresses. Not all 819 bindings can be validated by servers and the Confirm message provides 820 for this by specifying that a server that is unable to determine the 821 on-link status MUST NOT send a Reply. 823 Note: Confirm has a specific meaning and does not overload Renew/ 824 Rebind. It also is lower processing cost as the server does NOT need 825 to extend lease times or otherwise send back other configuration 826 options. 828 The Confirm message is used by the client to verify that it has not 829 moved to a different link. For IAs with addresses, the mechanism 830 used to verify if a client has moved or not, is by matching the 831 link's on-link prefix(es) (typically a /64) against the prefix-length 832 first bits of the addresses provided by the client in the IA_NA or 833 IA_TA IA-types. As a consequence Confirm can only be used when the 834 client has an IA with address(es) (IA_NA or IA_TA). 836 A client MUST have a binding including an IA with addresses to use 837 the Confirm message. A client with IAs with addresses as well as 838 other IA-types MAY, depending on the IA-type, use the Confirm message 839 to detect if the client has moved to a different link. A client that 840 does not have a binding with an IA with addresses MUST use the Rebind 841 message instead. 843 IA_PD requires verification that the server has the binding for the 844 IAs. In that case a client MUST use the Rebind message in place of 845 the Confirm message and it MUST include all of its bindings, even 846 address IAs. 848 Note that Section 18.1.2 of RFC 3315 states that a client MUST 849 initiate a Confirm when it may have moved to a new link. This is 850 relaxed to a SHOULD as a client may have determined whether it has or 851 has not moved using other techniques, such as described in [RFC6059]. 852 And, as stated above, a client with delegated prefixes, MUST send a 853 Rebind instead of a Confirm. 855 4.6. Decline Should Not Necessarily Trigger a Release 857 Some client implementations have been found to send a Release message 858 for other bindings they may have received after they determine a 859 conflict and have correctly sent a Decline message for the 860 conflicting address(es). 862 It is recommended that a client SHOULD NOT send a Release message for 863 other bindings it may have received just because it sent a Decline 864 message. The client should retain the non-conflicting bindings. 866 4.7. Multiple Provisioning Domains 868 This document has assumed that all DHCP servers on a network are in a 869 single provisioning domain and thus should be "equal" in the service 870 that they offer. This was also assumed by [RFC3315] and [RFC3633]. 872 One could envision a network where the DHCP servers are in multiple 873 provisioning domains, and it may be desirable to have the DHCP client 874 obtain different IA types from different provisioning domains. How a 875 client detects the multiple provisioning domains and how it would 876 interact with the multiple servers in these different domains is 877 outside the scope of this document. 879 5. IANA Considerations 881 This specification does not require any IANA actions. 883 6. Security Considerations 885 There are no new security considerations pertaining to this document. 887 7. Acknowledgements 889 Thanks to many people that contributed to identify the issues in this 890 document, including Ralph Droms, John, Brzozowski, Ted Lemon, Hemant 891 Singh, Wes Beebee, Gaurau Halwasia, Bud Millword, Tim Winters, and 892 Rob Shakir. 894 8. References 895 8.1. Normative References 897 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 898 Requirement Levels", BCP 14, RFC 2119, March 1997. 900 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 901 and M. Carney, "Dynamic Host Configuration Protocol for 902 IPv6 (DHCPv6)", RFC 3315, July 2003. 904 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 905 Host Configuration Protocol (DHCP) version 6", RFC 3633, 906 December 2003. 908 [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT 909 and INF_MAX_RT", RFC 7083, November 2013. 911 8.2. Informative References 913 [I-D.dhcwg-dhc-rfc3315bis] 914 Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 915 Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host 916 Configuration Protocol for IPv6 (DHCPv6) bis", draft- 917 dhcwg-dhc-rfc3315bis-02 (work in progress), July 2014. 919 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 920 Extensions for Stateless Address Autoconfiguration in 921 IPv6", RFC 4941, September 2007. 923 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 924 Detecting Network Attachment in IPv6", RFC 6059, November 925 2010. 927 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 928 Requirements for IPv6 Customer Edge Routers", RFC 7084, 929 November 2013. 931 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 932 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 933 BCP 187, RFC 7227, May 2014. 935 Authors' Addresses 936 Ole Troan 937 Cisco Systems, Inc. 938 Philip Pedersens vei 20 939 N-1324 Lysaker 940 Norway 942 Email: ot@cisco.com 944 Bernie Volz 945 Cisco Systems, Inc. 946 1414 Massachusetts Ave 947 Boxborough, MA 01719 948 USA 950 Email: volz@cisco.com 952 Marcin Siodelski 953 ISC 954 950 Charter Street 955 Redwood City, CA 94063 956 USA 958 Email: msiodelski@gmail.com