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