idnits 2.17.1 draft-ietf-dhc-dhcpv6-stateful-issues-04.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 abstract seems to contain references ([RFC6204]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC3633, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3315, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (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 (May 13, 2013) is 4000 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: 3 errors (**), 0 flaws (~~), 1 warning (==), 5 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 May 13, 2013 6 Expires: November 14, 2013 8 Issues with multiple stateful DHCPv6 options 9 draft-ietf-dhc-dhcpv6-stateful-issues-04.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. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 14, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Handling of multiple IA options types . . . . . . . . . . . . 3 59 4.1. Advertisement message . . . . . . . . . . . . . . . . . . 4 60 4.2. Placement of Status codes . . . . . . . . . . . . . . . . 5 61 4.3. T1/T2 timers . . . . . . . . . . . . . . . . . . . . . . 5 62 4.4. Renew and Rebind messages . . . . . . . . . . . . . . . . 6 63 4.5. Confirm message . . . . . . . . . . . . . . . . . . . . . 7 64 4.6. Release messages . . . . . . . . . . . . . . . . . . . . 8 65 4.7. Multiple provisioning domains . . . . . . . . . . . . . . 9 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 8.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 DHCPv6 [RFC3315] was not written with the expectation that additional 77 stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation 78 [RFC3633] shoe-horned the new options for Prefix Delegation into 79 DHCPv6. Implementation experience of the CPE model described in 80 [RFC6204] has shown multiple issues with the DHCPv6 protocol in 81 supporting multiple stateful options. 83 This document describes a number of problems encountered with 84 multiple IA option types into DHCP and recommended changes to the 85 DHCPv6 protocol specifications. 87 The intention of this work is to modify the DHCP protocol 88 specification to support multiple IA option types within a single 89 DHCP session. This problem can also be solved by implementing a 90 separate DHCP session (separate client state machine) per IA option 91 type. This latter approach has a number of issues: additional DHCP 92 protocol traffic, 'collisions' between stateless options also 93 included with the IA options, divergence in that each IA option type 94 specification specifies its 'own' version of the DHCP protocol. 96 The changes described in this document will be incorporated in a new 97 revision of the DHCPv6 protocol specification [RFC3315]. 99 2. Conventions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 3. Terminology 107 Stateful options Options that require dynamic binding 108 state per client on the server. 110 Identity association (IA): A collection of stateful options assigned 111 to a client. Each IA has an associated 112 IAID. A client may have more than one IA 113 assigned to it; for example, one for each 114 of its interfaces. Each IA holds one 115 type of IA option; for example, an 116 identity association for temporary 117 addresses (IA_TA) holds temporary 118 addresses (see "identity association for 119 temporary addresses"). Throughout this 120 document, "IA" is used to refer to an 121 identity association without identifying 122 the type of stateful option in the IA. 124 4. Handling of multiple IA options types 126 DHCPv6 was written with the assumption that the only stateful options 127 were for assigning addresses. DHCPv6 PD describes how to extend the 128 DHCPv6 protocol to handle prefix delegation, but [RFC3633] did not 129 consider how DHCP address assignment and prefix delegation could co- 130 exist. 132 If a client requests multiple IA option types, but the server is 133 configured to only offer a subset of them, the client could react in 134 several ways. Reset the state machine and continue to send Solicit 135 messages, create separate DHCP sessions for each IA option type and 136 continue to Solicit for the missing options, or it could continue 137 with the single session, and include the missing options on 138 subsequent messages to the server. 140 Proposed solution: the client should keep a single session with the 141 server and include the missing options on subsequent messages 142 (Request, Renew, and Rebind) to the server. 144 4.1. Advertisement message 146 [RFC3315] specifies that a client must ignore an Advertise message if 147 a server will not assign any addresses to a client. A client 148 requesting both IA_NA and IA_PD, with a server that only offers one 149 of them, is not supported in the current protocol specification. 151 Proposed solution: a client SHOULD accept Advertise messages, even 152 when not all IA option types are being offered. A client SHOULD 153 ignore an Advertise message when no bindings at all are being 154 offered. The client SHOULD include the not offered IA option types 155 in its Request. 157 Replace Section 17.1.3 of [RFC3315]: (existing errata) 159 The client MUST ignore any Advertise message that includes a Status 160 Code option containing the value NoAddrsAvail, with the exception 161 that the client MAY display the associated status message(s) to the 162 user. 164 With: 166 The client MUST ignore any Advertise message that contains no 167 bindings (if only IA_NA and/or IA_TA options were requested, 168 this is a message that includes a Status Code option containing the 169 value NoAddrsAvail), with the exception that the client MAY display 170 the associated status message(s) to the user. 172 And, replace: 174 - The client MAY choose a less-preferred server if that server 175 has a better set of advertised parameters, such as the 176 available addresses advertised in IAs. 178 With: 180 - The client MAY choose a less-preferred server if that server 181 has a better set of advertised parameters, such as the 182 available options advertised in IAs. 184 It is important to note that the receipt of a Advertisement without 185 any bindings does not imply that the client should restart the 186 Solicit retransmissions timers. Doing so would lead to a Solicit/ 187 Advertisement storm. 189 4.2. Placement of Status codes 191 In Reply messages IA specific status codes (i.e., NoAddrsAvail, 192 NotOnlink, NoBinding, NoPrefixAvail) are encapsulated in the IA 193 option. In Advertisement messages the Status Code option with the 194 NoAddrsAvail code is in the "global" scope. That makes sense when 195 the failure case is fatal. With the introduction of multiple IA 196 option types, there might be a case where a server is not willing to 197 offer addresses, but might be willing to offer other stateful option 198 types. 200 While a Status Code option is implicitly bound to a specific type of 201 IA, e.g. NoPrefixAvail is only applicable to IA_PD and NoAddrsAvail 202 is only applicable to IA_NA/IA_TA, it may be problematic to make this 203 assumption for all status codes. Ideally the Status Code option 204 should be encapsulated in the IA option for all DHCP messages. This 205 makes Advertisement messages equal to Reply messages. 207 Proposed solution: No change. For backwards compatibility, the 208 NoAddrsAvail Status Code option when no addresses are available will 209 be kept in the global scope for Advertise messages. Other IA option 210 types MUST encapsulate the Status Code option within the IA option. 212 To clarify further: when a client requests both IA_NA and IA_PD, and 213 the server can offer IA_PD but not IA_NA, the server sends an 214 Advertise response containing no IA_NA option, a status code option 215 of NoAddrsAvail, and one or more IA_PD options containing IAPREFIX 216 options. 218 4.3. T1/T2 timers 220 The T1 and T2 timers determine when the client will contact the 221 server to extend lifetimes of information received in an IA. How 222 should a client handle the case where multiple IA options have 223 different T1 and T2 timers? 225 In a multiple IA option types model, the T1/T2 timers are protocol 226 timers, that should be independent of the IA options themselves. If 227 we were to redo the DHCP protocol from scratch the T1/T2 timers 228 should be carried in a separate DHCP option. 230 Proposed solution: The server SHOULD set the T1/T2 timers in all IA 231 options in Reply and Advertise messages to the same value. To deal 232 with the case where servers have not yet been updated to do that, 233 clients MUST use the shortest (explicit or implicit) T1/T2 timer 234 (larger than 0) in any IA options in the Reply. Longer T1/T2 timers 235 are ignored. 237 4.4. Renew and Rebind messages 239 The Renew message, as described in [RFC3315], allows a client to only 240 renew bindings assigned via a Request message. The Rebind message, 241 as described in [RFC3315] does not explicitly specify what a server 242 should do when an IA option which contains no addresses is present. 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 Replace Section 18.1.4 of [RFC3315]: 293 At time T2 for an IA (which will only be reached if the server to 294 which the Renew message was sent at time T1 has not responded), the 295 client initiates a Rebind/Reply message exchange with any available 296 server. The client includes an IA option with all addresses 297 currently assigned to the IA in its Rebind message. 299 With: 301 At time T2 for an IA (which will only be reached if the server to 302 which the Renew message was sent at time T1 has not responded), the 303 client initiates a Rebind/Reply message exchange with any available 304 server. The client includes an IA option with all addresses 305 currently assigned to the IA in its Rebind message. The client 306 also includes an IA option for each binding it desires but has been 307 unable to obtain. 309 4.5. Confirm message 311 The Confirm message, as described in [RFC3315], is specific to 312 address assignment. It allows a server without a binding reply to 313 the message, under the assumption that the server only needs 314 knowledge about the prefix(es) on the link, to inform the client that 315 the address is likely valid or not. This message is sent when e.g. 316 the client has moved and needs to validate its addresses. Not all 317 bindings can be validated by servers and the Confirm message provides 318 for this by specifying that a server that is unable to determine the 319 on-link status MUST NOT send a Reply. 321 Note: Confirm has a specific meaning and does not overload Renew/ 322 Rebind. It also is lower processing cost as the server does NOT need 323 to extend lease times or otherwise send back other configuration 324 options. 326 Proposed solution: Allow and specify the Confirm message for other IA 327 option types. The server performs the same test as for addresses on 328 the delegated prefixes (see [RFC3315], section 18.2.2). 330 Replace Section 12.1 of [RFC3633]: 332 If such verification is needed the requesting router MUST initiate 333 a Rebind/Reply message exchange as described in section 18.1.4, 334 "Creation and Transmission of Rebind Messages" of RFC 3315, with 335 the exception that the retransmission parameters should be set as 336 for the Confirm message, described in section 18.1.2, "Creation 337 and Transmission of Confirm Messages" of RFC 3315. The requesting 338 router includes any IA_PDs, along with prefixes associated with 339 those IA_PDs in its Rebind message. 341 ... 343 The Confirm and Decline message types are not used with Prefix 344 Delegation. 346 With: 348 If such verification is needed the requesting router MUST initiate 349 a Confirm message exchange as described in section 18.1.2, 350 "Creation and Transmission of Confirm Messages" of RFC 3315. The 351 requesting router includes any IA_PDs, along with prefixes 352 associated with those IA_PDs in its Confirm message. 354 ... 356 The Decline message type is not used with Prefix Delegation. 358 4.6. Release messages 360 A client can release any individual lease at any time. A client can 361 get "back" a lease by using a Renew message. It MAY do this at any 362 time, though must avoid creating a Renew storm. E.g. wait until T1. 364 4.7. Multiple provisioning domains 366 This document has assumed that all DHCP servers on a network are in a 367 single provisioning domain and thus should be "equal" in the service 368 that they offer. This was also assumed by [RFC3315] and [RFC3633]. 370 One could envision a network where the DHCP servers are in multiple 371 provisioning domains, and it may be desirable to have the DHCP client 372 obtain different IA types from different provisioning domains. How a 373 client detects the multiple provisioning domains and how it would 374 interact with the multiple servers in these different domains is 375 outside the scope of this document and an area for future work. 377 5. IANA Considerations 379 This specification does not require any IANA actions. 381 6. Security Considerations 383 There are no new security considerations pertaining to this document. 385 7. Acknowledgements 387 8. References 389 8.1. Normative References 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", BCP 14, RFC 2119, March 1997. 394 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 395 and M. Carney, "Dynamic Host Configuration Protocol for 396 IPv6 (DHCPv6)", RFC 3315, July 2003. 398 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 399 Host Configuration Protocol (DHCP) version 6", RFC 3633, 400 December 2003. 402 8.2. Informative References 404 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 405 Troan, "Basic Requirements for IPv6 Customer Edge 406 Routers", RFC 6204, April 2011. 408 Authors' Addresses 409 Ole Troan 410 Cisco Systems, Inc. 411 Philip Pedersens vei 20 412 N-1324 Lysaker 413 Norway 415 Email: ot@cisco.com 417 Bernie Volz 418 Cisco Systems, Inc. 419 1414 Massachusetts Ave 420 Boxborough, MA 01719 421 USA 423 Email: volz@cisco.com