idnits 2.17.1 draft-ietf-dhc-dhcpv6-stateful-issues-00.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 -- The document date (May 7, 2012) is 4371 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 normative reference: RFC 6204 (Obsoleted by RFC 7084) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: November 8, 2012 May 7, 2012 7 Issues with multiple stateful DHCPv6 options 8 draft-ietf-dhc-dhcpv6-stateful-issues-00.txt 10 Abstract 12 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written 13 with the expectation that additional stateful DHCPv6 options would be 14 developed. IPv6 Prefix Options for Dynamic Host Configuration 15 Protocol (DHCP) version 6 shoe-horned the new options for Prefix 16 Delegation into DHCPv6. Implementation experience of the CPE model 17 described in has shown multiple issues with the DHCPv6 protocol in 18 supporting multiple stateful options. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 8, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Handling of multiple IA options types . . . . . . . . . . . . . 4 58 4.1. Advertisement message . . . . . . . . . . . . . . . . . . . 4 59 4.2. Placement of Status codes . . . . . . . . . . . . . . . . . 5 60 4.3. T1/T2 timers . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.4. Confirm message . . . . . . . . . . . . . . . . . . . . . . 6 62 4.5. Release messages . . . . . . . . . . . . . . . . . . . . . 6 63 4.6. Unanswered options . . . . . . . . . . . . . . . . . . . . 6 64 4.7. Multiple provisioning domains . . . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 68 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 DHCPv6 [RFC3315] was not written with the expectation that additional 74 stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation 75 [RFC3633] shoe-horned the new options for Prefix Delegation into 76 DHCPv6. Implementation experience of the CPE model described in 77 [RFC6204] has shown multiple issues with the DHCPv6 protocol in 78 supporting multiple stateful options. 80 This document describes a number of problems encountered with 81 multiple IA option types into DHCP and recommended changes to the 82 DHCPv6 protocol specifications. 84 The intention of this work is to modify the DHCP protocol 85 specification to support multiple IA option types within a single 86 DHCP session. This problem can also be solved by implementing a 87 separate DHCP session (separate client state machine) per IA option 88 type. This latter approach has a number of issues: additional DHCP 89 protocol traffic, 'collisions' between stateless options also 90 included with the IA options, divergence in that each IA option type 91 specification specifies its 'own' version of the DHCP protocol. 93 The changes described in this document will be incorporated in a new 94 revision of the DHCPv6 protocol specification [RFC3315]. 96 2. Conventions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 3. Terminology 104 Stateful options Options that require dynamic binding 105 state per client on the server. 107 Identity association (IA): A collection of stateful options assigned 108 to a client. Each IA has an associated 109 IAID. A client may have more than one IA 110 assigned to it; for example, one for each 111 of its interfaces. Each IA holds one 112 type of IA option; for example, an 113 identity association for temporary 114 addresses (IA_TA) holds temporary 115 addresses (see "identity association for 116 temporary addresses"). Throughout this 117 document, "IA" is used to refer to an 118 identity association without identifying 119 the type of stateful option in the IA. 121 4. Handling of multiple IA options types 123 DHCPv6 was written with the assumption that the only stateful options 124 where for assigning addresses. DHCPv6 PD describes how to extend the 125 DHCPv6 protocol to handle prefix delegation, but RFC3633 did not 126 consider how DHCP address assignment and prefix delegation could co- 127 exist. 129 4.1. Advertisement message 131 RFC3315 specifies that a client must ignore an Advertise message if a 132 server will not assign any addresses to a client. A client 133 requesting both IA_NA and IA_PD, with a server that only offers one 134 of them, is not supported in the current protocol specification. 136 Proposed solution: a client should accept Advertise messages, even 137 when not all IA option types are being offered. A client should 138 ignore an Advertise message when no bindings at all are being 139 offered. 141 Replace Section 17.1.3: (existing errata) 143 The client MUST ignore any Advertise message that includes a Status 144 Code option containing the value NoAddrsAvail, with the exception 145 that the client MAY display the associated status message(s) to the 146 user. 148 With: 150 The client MUST ignore any Advertise message that contains no 151 bindings (if only IA_NA and/or IA_TA options were requested, 152 this is a message that includes a Status Code option containing the 153 value NoAddrsAvail), with the exception that the client MAY display 154 the associated status message(s) to the user. 156 And, replace: 158 - The client MAY choose a less-preferred server if that server 159 has a better set of advertised parameters, such as the 160 available addresses advertised in IAs. 162 With: 164 - The client MAY choose a less-preferred server if that server 165 has a better set of advertised parameters, such as the 166 available options advertised in IAs. 168 It is important to note that the receipt of a Advertisement without 169 any bindings does not imply that the client should restart the 170 Solicit retransmissions timers. Doing so would lead to a Solicit/ 171 Advertisement storm. 173 4.2. Placement of Status codes 175 In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, 176 NoBinding) are encapsulated in the IA option. In Advertisement 177 messages the Status Code option with the NoAddrsAvail code is in the 178 "global" scope. That makes sense when the failure case is fatal. 179 With the introduction of multiple IA option types, there might be a 180 case where a server is not willing to offer addresses, but might be 181 willing to offer other stateful option types. 183 While a Status Code option is implicitly bound to a specific type of 184 IA, e.g. NoPrefixAvail is only applicable to IA_PD and NoAddrsAvail 185 is only applicable to IA_NA/IA_TA, it may be problematic to make this 186 assumption for all status codes. Ideally the Status Code option 187 should be encapsulated in the IA option for all DHCP messages. This 188 makes Advertisement messages equal to Reply messages. 190 Proposed solution: No change. For backwards compatibility, the 191 NoAddrsAvail Status Code option when no addresses are available will 192 be kept in the global scope for Advertise messages. Other IA option 193 types MUST encapsulate the Status Code option within the IA option. 195 4.3. T1/T2 timers 197 The T1 and T2 timers determine when the client will contact the 198 server to extend lifetimes of information received in an IA. How 199 should a client handle the case where multiple IA options have 200 different T1 and T2 timers? 202 In a multiple IA option types model, the T1/T2 timers are protocol 203 timers, that should be independent of the IA options themselves. If 204 we were to redo the DHCP protocol from scratch the T1/T2 timers 205 should be carried in a separate DHCP option. 207 Proposed solution: The server SHOULD set the T1/T2 timers in all IA 208 options in Reply and Advertise messages to the same value. To deal 209 with the case where servers have not yet been updated to do that, 210 clients MUST use the shortest (explicit or implicit) T1/T2 timer 211 (larger than 0) in any IA options in the Reply. Longer T1/T2 timers 212 are ignored. 214 4.4. Confirm message 216 The Confirm message, as described in [RFC3315], is specific to 217 address assignment. It lets a server without a binding to reply to 218 the message, under the assumption that the server only needs 219 knowledge about the prefix(es) on the link, to inform the client that 220 the address is likely valid or not. This message is sent when e.g. 221 the client has moved and needs to validate its addresses. Not all 222 bindings can be validated by servers and the Confirm message provides 223 for this by specifying that a server that is unable to determine the 224 on-link status MUST NOT send a Reply. 226 Note: Confirm has a specific meaning and does not overload Renew/ 227 Rebind. It also is lower processing cost as the server does NOT need 228 to extend lease times or otherwise send back other configuration 229 options. 231 Proposed solution: Allow and specify the Confirm message for other IA 232 option types. A server SHOULD respond to a Confirm message only if 233 it has definitive knowledge, based on the network configuration and 234 not the specific client's bindings, that the client is still on-link 235 or not on-link. 237 4.5. Release messages 239 A client can release any individual lease at any time. A client can 240 get "back" a lease by using a Renew message. It MAY do this at any 241 time, though must avoid creating a Renew storm. E.g. wait until T1. 243 4.6. Unanswered options 245 If a client requests multiple IA option types, but the server is 246 willing to only offer a subset of them, the client could react in 247 several ways. Reset the state machine and continue to send Solicit 248 messages, create separate DHCP sessions for each IA option type and 249 continue to Solicit for the missing options, or it could continue 250 with the single session, and include the missing options on 251 subsequent messages to the server. 253 Proposed solution: the client should keep a single session with the 254 server. The client should continue with the IA options received, 255 while continuing to request the other IA options in subsequent 256 messages to the server. That means to continue to include the empty 257 unanswered IAs in subsequent Renew and Rebind messages. 259 For the IAs that the server will not offer a binding, it must reply 260 using the same behaviour as for a Request message. That is not with 261 the currently specified NoBinding status). This behaviour will not 262 require the server to remember the IAs that it is not willing to 263 serve. I.e. the change is to allow the client to include IAs in 264 Renew/Rebind messages for which it has not received bindings (yet). 266 A client can only use the Renew (or Rebind) to request new IA options 267 if it already has one or more bindings. A client MUST NOT use Renew 268 (or Rebind) if it has no valid bindings it is renewing. 270 Replace Section 18.2.3: 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 set 274 to NoBinding in the Reply message. 276 With: 278 If the server cannot find a client entry for the IA but has one or 279 more bindings for the client, the server SHOULD treat this like a 280 Request message for the IA. If the server has no other bindings for 281 the client, the server SHOULD return the IA containing no bindings 282 with a Status Code option set to NoBinding in the Reply message. 284 4.7. Multiple provisioning domains 286 This document has assumed that all DHCP servers on a network are in a 287 single provisioning domain and thus should be "equal" in the service 288 that they offer. 290 One could envision a network where the DHCP servers are in multiple 291 provisioning domains, and it may be desireable to have the DHCP 292 client obtain different IA types from different provisioning domains. 293 How a client detects the multiple provisioning domains and how it 294 would interact with the multiple servers in these different domains 295 is outside the scope of this document and an area for future work. 297 5. IANA Considerations 299 This specification does not require any IANA actions. 301 6. Security Considerations 303 There are no new security considerations pertaining to this document. 305 7. Acknowledgements 307 8. Normative References 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, March 1997. 312 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 313 and M. Carney, "Dynamic Host Configuration Protocol for 314 IPv6 (DHCPv6)", RFC 3315, July 2003. 316 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 317 Host Configuration Protocol (DHCP) version 6", RFC 3633, 318 December 2003. 320 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 321 Troan, "Basic Requirements for IPv6 Customer Edge 322 Routers", RFC 6204, April 2011. 324 Authors' Addresses 326 Ole Troan 327 Cisco Systems, Inc. 328 Philip Pedersens vei 20 329 N-1324 Lysaker, 330 Norway 332 Email: ot@cisco.com 334 Bernie Volz 335 Cisco Systems, Inc. 336 1414 Massachusetts Ave 337 Boxborough, MA 01719, 338 USA 340 Email: volz@cisco.com