idnits 2.17.1 draft-troan-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC3315], [RFC6204], [RFC3633]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 28, 2012) is 4405 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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: 5 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: Informational cisco 5 Expires: September 29, 2012 March 28, 2012 7 Issues with multiple stateful DHCPv6 options 8 draft-troan-dhc-dhcpv6-stateful-issues-00.txt 10 Abstract 12 [RFC3315] was not written with the expectation that other stateful 13 DHCPv6 options would be developed. [RFC3633] shoe-horned the new 14 options for Prefix Delegation options for DHCPv6 into DHCPv6. 15 Implementation experience of the CPE model described in [RFC6204] has 16 shown multiple issues with the DHCPv6 protocol in supporting multiple 17 stateful options. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 29, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Handling of multiple IA_* options . . . . . . . . . . . . . . . 3 56 3.1. Advertisement message . . . . . . . . . . . . . . . . . . . 3 57 3.2. Placement of Status codes . . . . . . . . . . . . . . . . . 4 58 3.3. T1/T2 timers . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.4. Confirm message . . . . . . . . . . . . . . . . . . . . . . 5 60 3.5. Release / Decline messages . . . . . . . . . . . . . . . . 6 61 3.6. Unanswered options . . . . . . . . . . . . . . . . . . . . 6 62 3.7. Multiple provisioning domains . . . . . . . . . . . . . . . 6 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 [RFC3315] was not written with the expectation that other stateful 74 DHCPv6 options would be developed. [RFC3633] shoe-horned the new 75 options for Prefix Delegation options for DHCPv6 into DHCPv6. 76 Implementation experience of the CPE model described in [RFC6204] has 77 shown multiple issues with the DHCPv6 protocol in supporting multiple 78 stateful options. 80 This document describes a number of problems encountered when 81 introducing multiple IA_ options into DHCP. The document also 82 suggest solutions with suggested edits to the protocol specification. 84 The intention of this work is to modify the DHCP protocol 85 specification to support multiple IA_ options within a single DHCP 86 session. This problem can also be solved by implementing a separate 87 DHCP session (separate client state machine) per IA_ option. This 88 latter approach has a number of issues. Addition DHCP protocol 89 traffic, 'collisions' between stateless options also included with 90 the IA_ options, divergence in that each IA_ option specification 91 basically specifies its own version of the DHCP protocol... 93 2. Conventions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 3. Handling of multiple IA_* options 101 DHCPv6 was written with the assumption that the only stateful options 102 where for assigning addresses. DHCPv6 PD describes how to extend the 103 DHCPv6 protocol to handle prefix delegation, but RFC3633 did not 104 consider how DHCP address assignment and prefix delegation could co- 105 exist. 107 3.1. Advertisement message 109 RFC3315 specifies that a client must ignore an Advertise message if a 110 server will not assign any addresses to a client. A client 111 requesting both IA_NA and IA_PD, with a server that only offers one 112 of them, is not supported in the current protocol specification. 114 Proposed solution: a client should accept Advertise messages, even 115 when not all IA_ options are being offered. A client should ignore 116 an Advertise message when no IA_ options at all are being offered. 118 Replace Section 17.1.3: (existing errata) 120 The client MUST ignore any Advertise message that includes a Status 121 Code option containing the value NoAddrsAvail, with the exception 122 that the client MAY display the associated status message to the 123 user. 125 With: 127 The client MUST ignore any IAs in an Advertise message that 128 includes a Status Code option containing the value NoAddrsAvail, 129 with the exception that the client MAY display the associated 130 status message to the user. An Advertise message without any IA 131 options MUST be ignored. 133 It is important to note that the receipt of a Advertisement without 134 any IA options, does not imply that the client should restart the 135 Solicit retransmissions timers. Doing so would lead to a Solicit/ 136 Advertisement storm. 138 3.2. Placement of Status codes 140 In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, 141 NoBinding) are encapsulated in the IA option. In Advertisement 142 messages the Status code option with the NoAddrsAvail code is in the 143 "global" scope. That makes sense when the failure case is fatal. 144 With the introduction of multiple IA options, there might be a case 145 where a server is not willing to offer addresses, but might be 146 willing to offer other options. 148 While a Status Code option is implicitly bound to a specific type of 149 IA. E.g. NoPrefixAvail is only applicable to IA_PD, and 150 NoAddrsAvail is only applicable to IA_NA/IA_TA, it may be problematic 151 to make this assumption for all status codes. If so the Status Code 152 must be embedded in the IA_ option for all DHCP messages. This makes 153 Advertisement messages equal to Reply messages. 155 Proposed solution: Embedding the Status code option in the specific 156 IA. For backwards compatibility, the IA_NA status code can be kept 157 in the global scope. 159 Replace Section 17.2.2: (existing errata) 160 If the server will not assign any addresses to any IAs in a 161 subsequent Request from the client, the server MUST send an 162 Advertise message to the client that includes only a Status Code 163 option with code NoAddrsAvail and a status message for the user, a 164 Server Identifier option with the server's DUID, and a Client 165 Identifier option with the client's DUID. 167 With: 169 If the server will not assign any addresses to an IA in a 170 subsequent Request from the client, the server MUST send an 171 Advertise message to the client that includes the IA containing a 172 Status Code option with status code NoAddrsAvail and a status 173 message for the user, a Server Identifier option with the server's 174 DUID, and a Client Identifier option with the client's DUID. The 175 server SHOULD include other stateful IA options (like IA_PD) and 176 other configuration options in the Advertise message. 178 3.3. T1/T2 timers 180 The T1 and T2 timers determine when the client will contact the 181 server to extend lifetimes of information received in an IA. How 182 should a client handle the case where multiple IA_ options have 183 different T1 and T2 timers? 185 In a multiple IA_ options model, the T1/T2 timers are protocol 186 timers, that should be independent of the IA_ options themselves. If 187 we were to redo the DHCP protocol from scratch the T1/T2 timers 188 should be carried in a separate DHCP option. 190 Proposed solution: The server should set the T1/T2 timers in all IA_* 191 to the same value. To deal with the case where servers have not yet 192 been updated to do that, clients must use the shortest T1/T2 timer 193 (larger than 0) in any IA_ option. Longer T1/T2 timers are ignored. 195 3.4. Confirm message 197 The Confirm message is specific to address assignment. It lets a 198 server without a binding to reply to the message, under the 199 assumption that the server has knowledge of the prefix on the link, 200 while not having the binding, can inform the client that the address 201 is likely valid. This message is sent when e.g. the client has moved 202 and needs to validate its addresses. Not all IA_ options can be 203 validated by servers without the binding. 205 Note: Confirm has a specific meaning and doesn't overload Renew/ 206 Rebind. It also is lower processing cost as the server does NOT need 207 to extend lease times or otherwise send back options. 209 Proposed solution: Allow and specify the Confirm message for other IA 210 options. It is encouraged to use Renew instead of Confirm. 212 3.5. Release / Decline messages 214 A client can release any individual lease at any time. A client can 215 get "back" a lease by using a Renew message. It MAY do this at any 216 time, though must avoid creating a Renew storm. E.g. wait until T1. 218 3.6. Unanswered options 220 If a client requests multiple IA_ options, but the server is willing 221 to only offer a subset of them, the client could react in several 222 ways. Reset the state machine and continue to send Solicit messages, 223 create separate DHCP sessions for each IA and continue to Solicit for 224 the missing options, or it could continue with the single session, 225 and include the missing options on subsequent messages to the server. 227 Proposed solution: the client should keep a single session with the 228 server. The client should continue with the IA_ options received, 229 while continuing to request the other IA options in subsequent 230 messages to the server. That means continue to include the empty 231 unanswered IAs in subsequent Renew and Rebind messages. 233 For the IAs that the server has no binding for, it must reply using 234 the same behaviour as for a Request message. That is with a 235 "NoAddrsAvail" status. (As opposed to the currently specified 236 NoBinding). This behaviour will not require the server to remember 237 the IAs that it is not willing to server. I.e. the change is to 238 allow the client to include IAs (bindings) in Renew/Rebind messages 239 which it has not received (yet). 241 3.7. Multiple provisioning domains 243 Out of scope for this set of proposed changes to RFC3315/RFC3633. 245 4. IANA Considerations 247 This specification does not require any IANA actions. 249 5. Security Considerations 251 There are no new security considerations pertaining to this document. 253 6. Acknowledgements 255 7. References 257 7.1. Normative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 263 and M. Carney, "Dynamic Host Configuration Protocol for 264 IPv6 (DHCPv6)", RFC 3315, July 2003. 266 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 267 Host Configuration Protocol (DHCP) version 6", RFC 3633, 268 December 2003. 270 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 271 Troan, "Basic Requirements for IPv6 Customer Edge 272 Routers", RFC 6204, April 2011. 274 7.2. Informative References 276 Authors' Addresses 278 Ole Troan 279 cisco 280 Oslo, 281 Norway 283 Email: ot@cisco.com 285 Bernie Volz 286 cisco 287 Out in the Woods somewhere, 288 US of A 290 Email: volz@cisco.com