idnits 2.17.1 draft-ietf-dhc-dhcpv4-forcerenew-extensions-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 : ---------------------------------------------------------------------------- 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 (December 4, 2016) is 2698 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) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Luyuan Fang 3 Intended Status: Standards Track eBay 4 Expires: June 7, 2017 Deepak Bansal 5 Microsoft 6 Fabio Chiussi 7 Luiginius 9 December 4, 2016 11 Forcerenew Reconfiguration Extensions for DHCPv4 12 draft-ietf-dhc-dhcpv4-forcerenew-extensions-01 14 Abstract 16 This document extends the definition of the DHCPFORCERENEW message 17 for parameter reconfiguration in DHCPv4. This extension makes the 18 DHCPFORCERENEW message more suitable to reconfigure configuration 19 parameters other than IP addresses, and aligns the behavior of the 20 reconfiguration procedure in DHCPv4 to the corresponding behavior in 21 DHCPv6. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Extended DHCPFORCERENEW Message for DHCPv4 . . . . . . . . . . 4 64 2.1 DHCPFORCERENEW Procedure . . . . . . . . . . . . . . . . . . 4 65 2.2 DHCPFORCEINFORENEW: Extended DHCPFORCERENEW Message . . . . 5 66 2.3 DHCPFORCEINFORENEW Client Decline . . . . . . . . . . . . . 5 67 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 72 6.2 Informative References . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 Network and cloud operators increasingly use DHCP to distribute not 78 just IP addresses, but also a variety of other configuration 79 parameters to the clients. The DHCP servers may need to reconfigure 80 such other configuration parameters in the clients in isolation, 81 i.e., without reconfiguring IP addresses. In the case of 82 reconfiguration of only configuration parameters other than IP 83 addresses, it is especially important that service interruptions be 84 avoided. Towards this goal, it is desirable for a DHCP client, when 85 receiving a reconfiguration request from the DHCP server, to be made 86 aware of whether such a request includes reconfiguration of IP 87 addresses or only pertains to other configuration parameters, and 88 have the client adapt its behavior to each situation. Currently, this 89 is achieved in DHCPv6, but not in DHCPv4. This draft proposes an 90 extension of the FORCERENEW message in DHCPv4 to provide this 91 additional desired client behavior. 93 For historical reasons, the procedure for server-initiated 94 reconfiguration of configuration parameters uses a different 95 mechanism and produces a different behavior in DHCPv4 and in DHCPv6. 96 This is especially noticeable in the case of reconfiguration of 97 parameters other than IP addresses. 99 In DHCPv6 [RFC3315] [I-D. draft-ietf-dhc-rfc3315bis], the DHCP server 100 sends a Reconfigure message to a client to inform the client that the 101 server has new or updated configuration parameters. The Reconfigure 102 message allows the client to distinguish whether the reconfiguration 103 pertains to the IP addresses, in which case the client initiates a 104 Renew/Reply, or it pertains to other parameters, in which case the 105 client initiates an Information-request/Reply. In addition, the 106 DHCPv6 reconfiguration procedure includes a way for the client to 107 decline the reconfiguration attempt. 109 In DHCPv4 [RFC2131], the server-initiated reconfiguration procedure 110 relies on the use of the DHCPFORCERENEW message [RFC3203] and is less 111 granular than its IPv6 counterpart, which can result in service 112 interruptions that could be otherwise avoided when the 113 reconfiguration only involves parameters other than IP addresses. 115 This is the consequence of two differences with respect to the 116 reconfiguration procedure in DHCPv6. 118 1. The DHCPFORCERENEW message does not contain any indication for the 119 client to distinguish a reconfiguration of IP addresses from a 120 reconfiguration of some other configuration information. As a 121 result, the client always initiates a Renew/Reply transaction with 122 the server, which typically lead to service interruptions. 124 2. In DHCPv4, there is no easy way for the client to decline a 125 server-initiated reconfiguration request. The ability for a client 126 to decline server-initiated reconfiguration may turn useful in the 127 case of configuration information reconfiguration. 129 It should be noted that [RFC7341] specifies DHCPv4 over DHCPv6, thus 130 making it possible to use the DHCPv6 reconfigure function to 131 reconfigure parameters in DHCPv4. However, [RFC7341] is only 132 applicable to a IPv6 core network. Thus, achieving similar 133 reconfiguration behavior as DHCPv6 on a IPv4 network requires an 134 extension to the DHCPFORCERENEW message. 136 In this document, we extend the DHCPFORCERENEW message used in DHCPv4 137 by introducing a new Message Type DHCPFORCEINFORENEW to distinguish 138 reconfiguration of IP addresses from reconfiguration of other 139 information. In the latter case, we use the usual option mechanism to 140 distribute new or updated parameters to the client. 142 We also introduce a way for the client to decline the reconfiguration 143 request. 145 Any server-initiated reconfiguration requires authentication. The 146 extended DHCPFORCERENEW message must be used with the security 147 mechanisms described in [RFC6704], which aligns DHCPv4 authentication 148 with DHCPv6 authentication described in [I-D. draft-ietf-dhc- 149 rfc3315bis]. 151 The extended DHCPFORCENEW message described in this document aligns 152 the behavior of server-initiated reconfiguration in DHCPv4 with the 153 corresponding behavior in DHCPv6. 155 1.1. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [RFC2119]. 161 In this document, we use the terminology defined in [RFC3203] and in 162 [I-D. draft-ietf-dhc-rfc3315bis]. 164 2. Extended DHCPFORCERENEW Message for DHCPv4 166 2.1 DHCPFORCERENEW Procedure 168 This is the DHCPFORCERENEW procedure defined in [RFC3203]. 170 The DHCP server sends a unicast DHCPFORCERENEW message to the client. 171 Upon receipt of the unicast DHCPFORCERENEW message, the client enters 172 a Renew/Reply transaction with the server to try to renew its lease 173 according to normal DHCP procedures. If the server wants to assign a 174 new IP address to the client, it replies to the DHCPREQUEST with a 175 DHCPNAK. The client then goes back to the init state and broadcasts a 176 DHCPDISCOVER message. The server can now assign a new IP address to 177 the client by replying with a DHCPOFFER. If the DHCPFORCERENEW 178 message is lost, the DHCP server does not receive a DHCPREQUEST from 179 the client and retransmits the DHCPFORCERENEW message using an 180 exponential backoff algorithm. 182 The DHCPFORCERENEW message makes use of the normal DHCP message 183 format with DHCP option 53 (DHCP message type) value equal to 184 DHCPFORCERENEW (9). 186 As recognized in [RFC3203], usage of the DHCPFORCERENEW message to 187 reconfigure local configuration parameters other than IP addresses 188 can lead to the unnecessary interruption of active sessions. Thus, a 189 modification of the DHCPFORCERENEW message is desirable to avoid 190 service interruptions in such increasingly common situations. 192 2.2 DHCPFORCEINFORENEW: Extended DHCPFORCERENEW Message 194 The extended FORCERENEW message makes use of the normal DHCP message 195 format with DHCP option 53 (message type) value equal to 196 DHCPFORCEINFORENEW (TBD, see IANA considerations below). 198 Upon receipt of a DHCPFORCEINFORENEW, the client sends a DHCPINFORM 199 message to the server to request and obtain new configuration 200 information. 202 If the DHCPFORCEINFORENEW message is lost, the DHCP server does not 203 receive a DHCPINFORM from the client and retransmits the 204 DHCPFORCEINFORENEW message using an exponential backoff algorithm. 206 In order to assure backward compatibility with DHCP clients not 207 supporting the extended DHCPFORCERENEW message, if no DHCPINFORM is 208 received once the backoff expires, the DHCP server SHOULD send a 209 DHCPFORCERENEW message to brute force the reconfiguration by 210 reverting to the conventional DHCPv4 reconfiguration mechanism. 212 The fact that the DHCP server ultimately reverts to the 213 DHCPFORCERENEW message, however, complicates the ability of the 214 client to decline the FORCEINFORENEW message, as discussed in the 215 next section. 217 2.3 DHCPFORCEINFORENEW Client Decline 219 It is desirable to introduce a way to allow the client to decline the 220 DHCPFORCEINFORENEW request from the server. This further aligns the 221 client behavior in DHCPv4 server-initiated reconfiguration with the 222 corresponding behavior in DHCPv6. 224 Because of the server behavior defined in the previous section, 225 motivated by the objective of achieving backward compatibility with 226 clients not supporting the extended DHCPFORCERENEW message, the DHCP 227 client can't simply ignore the request, since that would eventually 228 result in a DHCPFORCERENEW message to be sent by the server. 230 One obvious solution is to forego backward compatibility and have the 231 DHCP server simply abandon the reconfiguration procedure at the end 232 of the DHCPINFOFORCERENEW reconfiguration procedure. 234 Alternatively, a mechanism for the client to explicit inform the 235 server that it is declining the server-initiated DHCPINFOFORCERENEW 236 reconfiguration procedure needs to be devised. 238 3. Security Considerations 240 The reconfiguration procedure using extended DHCPFORCERENEW message 241 described in this draft MUST be authenticated with the procedures 242 described in [RFC3118] or [RFC6704]. 244 The security considerations relating to the DHCPFORCEINFORENEW 245 message are the same as for DHCPFORCERENEW message discussed in 246 [RFC3203] and [RFC6704]. 248 4. IANA Considerations 250 IANA is requested to assign a new value for DHCP option 53 (DHCP 251 message type) [RFC2939] for the DHCPFORCEINFORENEW message from the 252 registry "DHCP Message Type 53 Values" maintained at 253 http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp- 254 parameters.xhtml 256 5. Acknowledgments 258 We would like to acknowledge Tomek Mrugalski, Christian Huitema and 259 Bernie Volz for their comments and reviews. 261 6. References 263 6.1 Normative References 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, March 1997. 268 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 269 RFC 2131, March 1997. 271 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 272 of New DHCP Options and Message Types", BCP 43, RFC 2939, 273 September 2000. 275 [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP 276 reconfigure extension", RFC 3203, December 2001. 278 [RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for 279 DHCP Messages", RFC 3118, June 2001. 281 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 282 C., and M. Carney, "Dynamic Host Configuration Protocol 283 for IPv6 (DHCPv6)", RFC 3315, July 2003. 285 [RFC6704] D. Miles et al., "Forcerenew Nonce Authentication", 286 RFC 6704, August 2012. 288 [RFC7341] Q. Sun et al., "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 289 RFC 7341, August 2012. 291 6.2 Informative References 293 [I-D. draft-ietf-dhc-rfc3315bis] T. Mrugalski et al., "Dynamic Host 294 Configuration Protocol for IPv6 (DHCPv6) bis", draft- 295 ietf-dhc-rfc3315bis-06 (work in progress), October 201. 297 Authors' Addresses 299 Luyuan Fang 300 eBay 301 411 108th Ave NE 302 Bellevue, WA 98004 303 Email: lufang@ebay.com 305 Deepak Bansal 306 Microsoft 307 15590 NE 31st St. 308 Redmond, WA 98052 309 Email: dbansal@microsoft.com 311 Fabio Chiussi 312 Seattle, WA 98116 313 Email: fabiochiussi@gmail.com