idnits 2.17.1 draft-ietf-dhc-dhcpv6-stateful-issues-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3633, but the abstract doesn't seem to directly say this. It does mention RFC3633 though, so this could be OK. 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 (January 1, 2014) is 3765 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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 January 1, 2014 6 Expires: July 5, 2014 8 Issues with multiple stateful DHCPv6 options 9 draft-ietf-dhc-dhcpv6-stateful-issues-05.txt 11 Abstract 13 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written 14 with the expectation that additional stateful DHCPv6 options would be 15 developed. IPv6 Prefix Options for Dynamic Host Configuration 16 Protocol (DHCP) version 6 shoe-horned the new options for Prefix 17 Delegation into DHCPv6. Implementation experience of the CPE model 18 described in RFC6204 has shown multiple issues with the DHCPv6 19 protocol in supporting multiple stateful options. This document 20 updates RFC3315 and indirectly RFC3633. 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 July 5, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Handling of multiple IA options types . . . . . . . . . . . . 3 60 4.1. Advertise Message . . . . . . . . . . . . . . . . . . . . 4 61 4.2. Placement of Status Codes . . . . . . . . . . . . . . . . 5 62 4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 5 63 4.4. Renew Message . . . . . . . . . . . . . . . . . . . . . . 6 64 4.5. Rebind Message . . . . . . . . . . . . . . . . . . . . . 7 65 4.6. Confirm Message . . . . . . . . . . . . . . . . . . . . . 8 66 4.7. Release Message . . . . . . . . . . . . . . . . . . . . . 9 67 4.8. Multiple Provisioning Domains . . . . . . . . . . . . . . 9 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 8.2. Informative References . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 DHCPv6 [RFC3315] was not written with the expectation that additional 79 stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation 80 [RFC3633] shoe-horned the new options for Prefix Delegation into 81 DHCPv6. Implementation experience of the CPE model described in 82 [RFC6204] has shown multiple issues with the DHCPv6 protocol in 83 supporting multiple stateful options. 85 This document describes a number of problems encountered with 86 multiple IA option types into DHCP and recommended changes to the 87 DHCPv6 protocol specifications. 89 The intention of this work is to modify the DHCP protocol 90 specification to support multiple IA option types within a single 91 DHCP session. This problem can also be solved by implementing a 92 separate DHCP session (separate client state machine) per IA option 93 type. This latter approach has a number of issues: additional DHCP 94 protocol traffic, 'collisions' between stateless options also 95 included with the IA options, divergence in that each IA option type 96 specification specifies its 'own' version of the DHCP protocol. 98 The changes described in this document will be incorporated in a new 99 revision of the DHCPv6 protocol specification [RFC3315]. 101 2. Conventions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 3. Terminology 109 Stateful options Options that require dynamic binding 110 state per client on the server. 112 Identity association (IA): A collection of stateful options assigned 113 to a client. Each IA has an associated 114 IAID. A client may have more than one IA 115 assigned to it; for example, one for each 116 of its interfaces. Each IA holds one 117 type of IA option; for example, an 118 identity association for temporary 119 addresses (IA_TA) holds temporary 120 addresses (see "identity association for 121 temporary addresses"). Throughout this 122 document, "IA" is used to refer to an 123 identity association without identifying 124 the type of stateful option in the IA. 126 4. Handling of multiple IA options types 128 DHCPv6 was written with the assumption that the only stateful options 129 were for assigning addresses. DHCPv6 PD describes how to extend the 130 DHCPv6 protocol to handle prefix delegation, but [RFC3633] did not 131 consider how DHCP address assignment and prefix delegation could co- 132 exist. 134 If a client requests multiple IA option types, but the server is 135 configured to only offer a subset of them, the client could react in 136 several ways. Reset the state machine and continue to send Solicit 137 messages, create separate DHCP sessions for each IA option type and 138 continue to Solicit for the unfulfilled IA options, or it could 139 continue with the single session, and include the unfulfilled IA 140 options on subsequent messages to the server. 142 Proposed solution: the client should keep a single session with the 143 server and include the missing options on subsequent messages 144 (Request, Renew, and Rebind) to the server. 146 4.1. Advertise Message 148 [RFC3315] specifies that a client must ignore an Advertise message if 149 a server will not assign any addresses to a client. A client 150 requesting both IA_NA and IA_PD, with a server that only offers one 151 of them, is not supported in the current protocol specification. 153 Proposed solution: a client SHOULD accept Advertise messages, even 154 when not all IA option types are being offered. A client SHOULD 155 ignore an Advertise message when no bindings at all are being 156 offered. The client SHOULD include the not offered IA option types 157 in its Request. 159 Replace Section 17.1.3 of [RFC3315]: (existing errata) 161 The client MUST ignore any Advertise message that includes a Status 162 Code option containing the value NoAddrsAvail, with the exception 163 that the client MAY display the associated status message(s) to the 164 user. 166 With: 168 The client MUST ignore any Advertise message that contains no 169 bindings (if only IA_NA and/or IA_TA options were requested, 170 this is a message that includes a Status Code option containing the 171 value NoAddrsAvail), with the exception that the client MAY display 172 the associated status message(s) to the user. 174 And, replace: 176 - The client MAY choose a less-preferred server if that server 177 has a better set of advertised parameters, such as the 178 available addresses advertised in IAs. 180 With: 182 - The client MAY choose a less-preferred server if that server 183 has a better set of advertised parameters, such as the 184 available options advertised in IAs. 186 It is important to note that the receipt of a Advertisement without 187 any bindings does not imply that the client should restart the 188 Solicit retransmissions timers. Doing so would lead to a Solicit/ 189 Advertisement storm. 191 4.2. Placement of Status Codes 193 In Reply messages IA specific status codes (i.e., NoAddrsAvail, 194 NotOnlink, NoBinding, NoPrefixAvail) are encapsulated in the IA 195 option. In Advertisement messages the Status Code option with the 196 NoAddrsAvail code is in the "global" scope. That makes sense when 197 the failure case is fatal. With the introduction of multiple IA 198 option types, there might be a case where a server is not willing to 199 offer addresses, but might be willing to offer other stateful option 200 types. 202 While a Status Code option is implicitly bound to a specific type of 203 IA, e.g. NoPrefixAvail is only applicable to IA_PD and NoAddrsAvail 204 is only applicable to IA_NA/IA_TA, it may be problematic to make this 205 assumption for all status codes. Ideally the Status Code option 206 should be encapsulated in the IA option for all DHCP messages. This 207 makes Advertisement messages equal to Reply messages. 209 Proposed solution: No change. For backwards compatibility, the 210 NoAddrsAvail Status Code option when no addresses are available will 211 be kept in the global scope for Advertise messages. Other IA option 212 types MUST encapsulate the Status Code option within the IA option. 214 To clarify further: when a client requests both IA_NA and IA_PD, and 215 the server can offer IA_PD but not IA_NA, the server sends an 216 Advertise response containing no IA_NA option, a status code option 217 of NoAddrsAvail, and one or more IA_PD options containing IAPREFIX 218 options. 220 4.3. T1/T2 Timers 222 The T1 and T2 timers determine when the client will contact the 223 server to extend lifetimes of information received in an IA. How 224 should a client handle the case where multiple IA options have 225 different T1 and T2 timers? 227 In a multiple IA option types model, the T1/T2 timers are protocol 228 timers, that should be independent of the IA options themselves. If 229 we were to redo the DHCP protocol from scratch the T1/T2 timers 230 should be carried in a separate DHCP option. 232 Proposed solution: The server SHOULD set the T1/T2 timers in all IA 233 options in Reply and Advertise messages to the same value. To deal 234 with the case where servers have not yet been updated to do that, 235 clients MUST use the shortest (explicit or implicit) T1/T2 timer 236 (larger than 0) in any IA options in the Reply. Longer T1/T2 timers 237 are ignored. 239 4.4. Renew Message 241 The Renew message, as described in [RFC3315], allows a client to only 242 renew bindings assigned via a Request message. 244 In a multiple IA option type model, the Renew does not support the 245 ability for the client to renew one IA option type while requesting 246 bindings for other IA option types that were not available when the 247 client sent the Request. 249 Proposed solution: The client should continue with the IA options 250 received, while continuing to include the other IA options in 251 subsequent messages to the server. The client and server processing 252 need to be modified. Note that this change makes the server's IA 253 processing of Renew and Rebind similar to the Request processing. 255 Replace Section 18.1.3 of [RFC3315]: 257 At time T1 for an IA, the client initiates a Renew/Reply message 258 exchange to extend the lifetimes on any addresses in the IA. The 259 client includes an IA option with all addresses currently assigned 260 to the IA in its Renew message. 262 With: 264 At time T1 for an IA, the client initiates a Renew/Reply message 265 exchange to extend the lifetimes on any addresses in the IA. The 266 client includes an IA option with all addresses currently assigned 267 to the IA in its Renew message. The client also includes an IA 268 option for each binding it desires but has been unable to obtain. 270 Replace Section 18.2.3 of [RFC3315]: 272 If the server cannot find a client entry for the IA the server 273 returns the IA containing no addresses with a Status Code option 274 set to NoBinding in the Reply message. 276 With: 278 If the server cannot find a client entry for the IA the server 279 creates the bindings for that client according to the server's 280 policy and configuration information and records the IAs and 281 other information requested by the client. 283 Note that clients that communicate with servers that do not support 284 this updated Renew processing will receive the NoBinding status for 285 the IA which had no bindings. The client MUST continue to process 286 the other IAs in the Reply. The client MAY attempt a Solicit/ 287 Advertise/Request/Reply sequence periodically to obtain bindings for 288 these IAs. However, it MUST limit the frequency at which is does 289 this to no more often than the renewal frequency. 291 4.5. Rebind Message 293 The Rebind message, as described in [RFC3315] does not explicitly 294 specify what a server should do when an IA option which contains no 295 addresses is present. 297 Replace Section 18.1.4 of [RFC3315]: 299 At time T2 for an IA (which will only be reached if the server to 300 which the Renew message was sent at time T1 has not responded), the 301 client initiates a Rebind/Reply message exchange with any available 302 server. The client includes an IA option with all addresses 303 currently assigned to the IA in its Rebind message. 305 With: 307 At time T2 for an IA (which will only be reached if the server to 308 which the Renew message was sent at time T1 has not responded), the 309 client initiates a Rebind/Reply message exchange with any available 310 server. The client includes an IA option with all addresses 311 currently assigned to the IA in its Rebind message. The client 312 also includes an IA option for each binding it desires but has been 313 unable to obtain. 315 Replace Section 18.2.4 of [RFC3315] with the following text to 316 clarify how the server should handle all of the possible conditions: 318 When the server receives a Rebind message that contains an IA 319 option from a client, it locates the client's binding and verifies 320 that the information in the IA from the client matches the 321 information stored for that client. 323 If the server finds the addresses in the IA for the client and the 324 server determines that the addresses in the IA are appropriate for 325 the link to which the client's interface is attached according to 326 the server's explicit configuration information, the server SHOULD 327 send back the IA to the client with new lifetimes and T1/T2 times. 329 If the server cannot find a client entry for the IA and the server 330 determines that the addresses in the IA are not appropriate for the 331 link to which the client's interface is attached according to the 332 server's explicit configuration information, the server MAY send a 333 Reply message to the client containing the client's IA, with the 334 lifetimes for the addresses in the IA set to zero. This Reply 335 constitutes an explicit notification to the client that the 336 addresses in the IA are no longer valid. In this situation, if the 337 server does not send a Reply message it silently discards the 338 Rebind message. 340 If the server cannot find a client entry for the IA and the server 341 determines that the addresses in the IA are appropriate for the 342 link to which the client's interface is attached according to the 343 server's explicit configuration information, and the addresses are 344 not in use, the server MAY assign the addresses to the client and 345 send a Reply message to the client with new lifetimes and T1/T2 346 times for the bindings. If the server cannot assign the addresses 347 to the client, the server returns the IA containing no addresses 348 with a Status Code option set to NoBinding in the Reply message. 350 Note: A server SHOULD NOT provide additional bindings to the client 351 as the client could accept a Reply from a different server (this is 352 the same issue as in the Discussion under the Rapid Commit option, 353 see section 22.14). 355 The server constructs a Reply message by setting the "msg-type" 356 field to REPLY, and copying the transaction ID from the Rebind 357 message into the transaction-id field. 359 The server MUST include a Server Identifier option containing the 360 server's DUID and the Client Identifier option from the Rebind 361 message in the Reply message. 363 The server includes other options containing configuration 364 information to be returned to the client as described in section 365 18.2. 367 4.6. Confirm Message 369 The Confirm message, as described in [RFC3315], is specific to 370 address assignment. It allows a server without a binding reply to 371 the message, under the assumption that the server only needs 372 knowledge about the prefix(es) on the link, to inform the client that 373 the address is likely valid or not. This message is sent when e.g. 374 the client has moved and needs to validate its addresses. Not all 375 bindings can be validated by servers and the Confirm message provides 376 for this by specifying that a server that is unable to determine the 377 on-link status MUST NOT send a Reply. 379 Note: Confirm has a specific meaning and does not overload Renew/ 380 Rebind. It also is lower processing cost as the server does NOT need 381 to extend lease times or otherwise send back other configuration 382 options. 384 Proposed solution: Allow and specify the Confirm message for other IA 385 option types. The server performs the same test as for addresses on 386 the delegated prefixes (see [RFC3315], section 18.2.2). 388 Replace Section 12.1 of [RFC3633]: 390 If such verification is needed the requesting router MUST initiate 391 a Rebind/Reply message exchange as described in section 18.1.4, 392 "Creation and Transmission of Rebind Messages" of RFC 3315, with 393 the exception that the retransmission parameters should be set as 394 for the Confirm message, described in section 18.1.2, "Creation 395 and Transmission of Confirm Messages" of RFC 3315. The requesting 396 router includes any IA_PDs, along with prefixes associated with 397 those IA_PDs in its Rebind message. 399 ... 401 The Confirm and Decline message types are not used with Prefix 402 Delegation. 404 With: 406 If such verification is needed the requesting router MUST initiate 407 a Confirm message exchange as described in section 18.1.2, 408 "Creation and Transmission of Confirm Messages" of RFC 3315. The 409 requesting router includes any IA_PDs, along with prefixes 410 associated with those IA_PDs in its Confirm message. 412 ... 414 The Decline message type is not used with Prefix Delegation. 416 4.7. Release Message 418 A client can release any individual lease at any time. A client can 419 get "back" a lease by using a Renew message. It MAY do this at any 420 time, though must avoid creating a Renew storm. E.g. wait until T1. 422 4.8. Multiple Provisioning Domains 424 This document has assumed that all DHCP servers on a network are in a 425 single provisioning domain and thus should be "equal" in the service 426 that they offer. This was also assumed by [RFC3315] and [RFC3633]. 428 One could envision a network where the DHCP servers are in multiple 429 provisioning domains, and it may be desirable to have the DHCP client 430 obtain different IA types from different provisioning domains. How a 431 client detects the multiple provisioning domains and how it would 432 interact with the multiple servers in these different domains is 433 outside the scope of this document. 435 5. IANA Considerations 437 This specification does not require any IANA actions. 439 6. Security Considerations 441 There are no new security considerations pertaining to this document. 443 7. Acknowledgements 445 8. References 447 8.1. Normative References 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, March 1997. 452 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 453 and M. Carney, "Dynamic Host Configuration Protocol for 454 IPv6 (DHCPv6)", RFC 3315, July 2003. 456 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 457 Host Configuration Protocol (DHCP) version 6", RFC 3633, 458 December 2003. 460 8.2. Informative References 462 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 463 Troan, "Basic Requirements for IPv6 Customer Edge 464 Routers", RFC 6204, April 2011. 466 Authors' Addresses 468 Ole Troan 469 Cisco Systems, Inc. 470 Philip Pedersens vei 20 471 N-1324 Lysaker 472 Norway 474 Email: ot@cisco.com 475 Bernie Volz 476 Cisco Systems, Inc. 477 1414 Massachusetts Ave 478 Boxborough, MA 01719 479 USA 481 Email: volz@cisco.com