idnits 2.17.1 draft-ietf-dhc-dhcpv6-stateful-issues-01.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 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 (October 6, 2012) is 4219 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 (==), 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 October 6, 2012 6 Expires: April 9, 2013 8 Issues with multiple stateful DHCPv6 options 9 draft-ietf-dhc-dhcpv6-stateful-issues-01.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 has shown multiple issues with the DHCPv6 protocol in 19 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 April 9, 2013. 38 Copyright Notice 40 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Handling of multiple IA options types . . . . . . . . . . . . 4 59 4.1. Advertisement message . . . . . . . . . . . . . . . . . . 4 60 4.2. Placement of Status codes . . . . . . . . . . . . . . . . 5 61 4.3. T1/T2 timers . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.4. Renew and Rebind messages . . . . . . . . . . . . . . . . 6 63 4.5. Confirm message . . . . . . . . . . . . . . . . . . . . . 8 64 4.6. Release messages . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 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 (NoAddrsAvail, NotOnlink, 192 NoBinding) are encapsulated in the IA option. In Advertisement 193 messages the Status Code option with the NoAddrsAvail code is in the 194 "global" scope. That makes sense when the failure case is fatal. 195 With the introduction of multiple IA option types, there might be a 196 case where a server is not willing to offer addresses, but might be 197 willing to offer other stateful option types. 199 While a Status Code option is implicitly bound to a specific type of 200 IA, e.g. NoPrefixAvail is only applicable to IA_PD and NoAddrsAvail 201 is only applicable to IA_NA/IA_TA, it may be problematic to make this 202 assumption for all status codes. Ideally the Status Code option 203 should be encapsulated in the IA option for all DHCP messages. This 204 makes Advertisement messages equal to Reply messages. 206 Proposed solution: No change. For backwards compatibility, the 207 NoAddrsAvail Status Code option when no addresses are available will 208 be kept in the global scope for Advertise messages. Other IA option 209 types MUST encapsulate the Status Code option within the IA option. 211 4.3. T1/T2 timers 213 The T1 and T2 timers determine when the client will contact the 214 server to extend lifetimes of information received in an IA. How 215 should a client handle the case where multiple IA options have 216 different T1 and T2 timers? 218 In a multiple IA option types model, the T1/T2 timers are protocol 219 timers, that should be independent of the IA options themselves. If 220 we were to redo the DHCP protocol from scratch the T1/T2 timers 221 should be carried in a separate DHCP option. 223 Proposed solution: The server SHOULD set the T1/T2 timers in all IA 224 options in Reply and Advertise messages to the same value. To deal 225 with the case where servers have not yet been updated to do that, 226 clients MUST use the shortest (explicit or implicit) T1/T2 timer 227 (larger than 0) in any IA options in the Reply. Longer T1/T2 timers 228 are ignored. 230 4.4. Renew and Rebind messages 232 The Renew message, as described in [RFC3315], allows a client to only 233 renew bindings assigned via a Request message. The Rebind message, 234 as described in [RFC3315] does not explicitly specify what a server 235 should do when an IA option which contains no addresses is present. 237 In a multiple IA option type model, the Renew does not support the 238 ability for the client to renew one IA option type while requesting 239 bindings for other IA option types that were not available when the 240 client sent the Request. 242 Proposed solution: The client should continue with the IA options 243 received, while continuing to include the other IA options in 244 subsequent messages to the server. The client and server processing 245 need to be modified. Note that this change makes the server's IA 246 processing of Renew and Rebind similar to the Request processing. 248 Replace Section 18.1.3 of [RFC3315]: 250 At time T1 for an IA, the client initiates a Renew/Reply message 251 exchange to extend the lifetimes on any addresses in the IA. The 252 client includes an IA option with all addresses currently assigned 253 to the IA in its Renew message. 255 With: 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. The client also includes an IA 261 option for each binding it desires but has been unable to obtain. 263 Replace Section 18.2.3 of [RFC3315]: 265 If the server cannot find a client entry for the IA the server 266 returns the IA containing no addresses with a Status Code option 267 set to NoBinding in the Reply message. 269 With: 271 If the server cannot find a client entry for the IA the server 272 creates the bindings for that client according to the server's 273 policy and configuration information and records the IAs and 274 other information requested by the client. 276 Note that clients that communicate with servers that do not support 277 this updated Renew processing will receive the NoBinding status for 278 the IA which had no bindings. The client MUST continue to process 279 the other IAs in the Reply. The client MAY attempt a Solicit/ 280 Advertise/Request/Reply sequence periodically to obtain bindings for 281 these IAs. However, it MUST limit the frequency at which is does 282 this to no more often than the renewal frequency. 284 Replace Section 18.1.4 of [RFC3315]: 286 At time T2 for an IA (which will only be reached if the server to 287 which the Renew message was sent at time T1 has not responded), the 288 client initiates a Rebind/Reply message exchange with any available 289 server. The client includes an IA option with all addresses 290 currently assigned to the IA in its Rebind message. 292 With: 294 At time T2 for an IA (which will only be reached if the server to 295 which the Renew message was sent at time T1 has not responded), the 296 client initiates a Rebind/Reply message exchange with any available 297 server. The client includes an IA option with all addresses 298 currently assigned to the IA in its Rebind message. The client 299 also includes an IA option for each binding it desires but has been 300 unable to obtain. 302 4.5. Confirm message 304 The Confirm message, as described in [RFC3315], is specific to 305 address assignment. It lets a server without a binding to reply to 306 the message, under the assumption that the server only needs 307 knowledge about the prefix(es) on the link, to inform the client that 308 the address is likely valid or not. This message is sent when e.g. 309 the client has moved and needs to validate its addresses. Not all 310 bindings can be validated by servers and the Confirm message provides 311 for this by specifying that a server that is unable to determine the 312 on-link status MUST NOT send a Reply. 314 Note: Confirm has a specific meaning and does not overload Renew/ 315 Rebind. It also is lower processing cost as the server does NOT need 316 to extend lease times or otherwise send back other configuration 317 options. 319 Proposed solution: Allow and specify the Confirm message for other IA 320 option types. The server performs the same test as for addresses on 321 the delegated prefixes (see [RFC3315], section 18.2.2). 323 Replace Section 12.1 of [RFC3633]: 325 If such verification is needed the requesting router MUST initiate 326 a Rebind/Reply message exchange as described in section 18.1.4, 327 "Creation and Transmission of Rebind Messages" of RFC 3315, with 328 the exception that the retransmission parameters should be set as 329 for the Confirm message, described in section 18.1.2, "Creation 330 and Transmission of Confirm Messages" of RFC 3315. The requesting 331 router includes any IA_PDs, along with prefixes associated with 332 those IA_PDs in its Rebind message. 334 ... 336 The Confirm and Decline message types are not used with Prefix 337 Delegation. 339 With: 341 If such verification is needed the requesting router MUST initiate 342 a Confirm message exchange as described in section 18.1.2, 343 "Creation and Transmission of Confirm Messages" of RFC 3315. The 344 requesting router includes any IA_PDs, along with prefixes 345 associated with those IA_PDs in its Confirm message. 347 ... 349 The Decline message type is not used with Prefix Delegation. 351 4.6. Release messages 353 A client can release any individual lease at any time. A client can 354 get "back" a lease by using a Renew message. It MAY do this at any 355 time, though must avoid creating a Renew storm. E.g. wait until T1. 357 4.7. Multiple provisioning domains 359 This document has assumed that all DHCP servers on a network are in a 360 single provisioning domain and thus should be "equal" in the service 361 that they offer. This was also assumed by [RFC3315] and [RFC3633]. 363 One could envision a network where the DHCP servers are in multiple 364 provisioning domains, and it may be desirable to have the DHCP client 365 obtain different IA types from different provisioning domains. How a 366 client detects the multiple provisioning domains and how it would 367 interact with the multiple servers in these different domains is 368 outside the scope of this document and an area for future work. 370 5. IANA Considerations 372 This specification does not require any IANA actions. 374 6. Security Considerations 376 There are no new security considerations pertaining to this document. 378 7. Acknowledgements 380 8. References 382 8.1. Normative References 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, March 1997. 387 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 388 and M. Carney, "Dynamic Host Configuration Protocol for 389 IPv6 (DHCPv6)", RFC 3315, July 2003. 391 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 392 Host Configuration Protocol (DHCP) version 6", RFC 3633, 393 December 2003. 395 8.2. Informative References 397 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 398 Troan, "Basic Requirements for IPv6 Customer Edge 399 Routers", RFC 6204, April 2011. 401 Authors' Addresses 403 Ole Troan 404 Cisco Systems, Inc. 405 Philip Pedersens vei 20 406 N-1324 Lysaker, 407 Norway 409 Email: ot@cisco.com 411 Bernie Volz 412 Cisco Systems, Inc. 413 1414 Massachusetts Ave 414 Boxborough, MA 01719, 415 USA 417 Email: volz@cisco.com