INTERNET-DRAFT Luyuan Fang Intended Status: Standards Track eBay Expires: August 12, 2017 Deepak Bansal Microsoft Fabio Chiussi Luiginius February 9, 2017 Forcerenew Reconfiguration Extensions for DHCPv4 draft-ietf-dhc-dhcpv4-forcerenew-extensions-02 Abstract This document extends the definition of the DHCPFORCERENEW message for parameter reconfiguration in DHCPv4. This extension makes the DHCPFORCERENEW message more suitable to reconfigure configuration parameters other than IP addresses, and aligns the behavior of the reconfiguration procedure in DHCPv4 to the corresponding behavior in DHCPv6. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Fang et al. Expires [Page 1] INTERNET DRAFT Forcerenew Reconfiguration Extensions February 9, 2017 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Extended DHCPFORCERENEW Message for DHCPv4 . . . . . . . . . . 4 2.1 DHCPFORCERENEW Procedure . . . . . . . . . . . . . . . . . . 4 2.2 DHCPFORCEINFORENEW: Extended DHCPFORCERENEW Message . . . . 4 2.3 DHCPFORCEINFORENEW Client Decline . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 6.2 Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Network and cloud operators increasingly use DHCP to distribute not just IP addresses, but also a variety of other configuration parameters to the clients. The DHCP servers may need to reconfigure such other configuration parameters in the clients in isolation, i.e., without reconfiguring IP addresses. In the case of reconfiguration of only configuration parameters other than IP addresses, it is especially important that service interruptions be avoided. Towards this goal, it is desirable for a DHCP client, when receiving a reconfiguration request from the DHCP server, to be made aware of whether such a request includes reconfiguration of IP addresses or only pertains to other configuration parameters, and have the client adapt its behavior to each situation. Currently, this is achieved in DHCPv6, but not in DHCPv4. This draft proposes an extension of the FORCERENEW message in DHCPv4 to provide this additional desired client behavior. For historical reasons, the procedure for server-initiated reconfiguration of configuration parameters uses a different mechanism and produces a different behavior in DHCPv4 and in DHCPv6. Fang et al. Expires [Page 2] INTERNET DRAFT Forcerenew Reconfiguration Extensions February 9, 2017 This is especially noticeable in the case of reconfiguration of parameters other than IP addresses. In DHCPv6 [RFC3315] [I-D. draft-ietf-dhc-rfc3315bis], the DHCP server sends a Reconfigure message to a client to inform the client that the server has new or updated configuration parameters. The Reconfigure message allows the client to distinguish whether the reconfiguration pertains to the IP addresses, in which case the client initiates a Renew/Reply, or it pertains to other parameters, in which case the client initiates an Information-request/Reply. In addition, the DHCPv6 reconfiguration procedure includes a way for the client to decline the reconfiguration attempt. In DHCPv4 [RFC2131], the server-initiated reconfiguration procedure relies on the use of the DHCPFORCERENEW message [RFC3203] and is less granular than its IPv6 counterpart, which can result in service interruptions that could be otherwise avoided when the reconfiguration only involves parameters other than IP addresses. This is the consequence of two differences with respect to the reconfiguration procedure in DHCPv6. 1. The DHCPFORCERENEW message does not contain any indication for the client to distinguish a reconfiguration of IP addresses from a reconfiguration of some other configuration information. As a result, the client always initiates a Renew/Reply transaction with the server, which typically lead to service interruptions. 2. In DHCPv4, there is no easy way for the client to decline a server-initiated reconfiguration request. The ability for a client to decline server-initiated reconfiguration may turn useful in the case of configuration information reconfiguration. It should be noted that [RFC7341] specifies DHCPv4 over DHCPv6, thus making it possible to use the DHCPv6 reconfigure function to reconfigure parameters in DHCPv4. However, [RFC7341] is only applicable to a IPv6 core network. Thus, achieving similar reconfiguration behavior as DHCPv6 on a IPv4 network requires an extension to the DHCPFORCERENEW message. In this document, we extend the DHCPFORCERENEW message used in DHCPv4 by introducing a new Message Type DHCPFORCEINFORENEW to distinguish reconfiguration of IP addresses from reconfiguration of other information. In the latter case, we use the usual option mechanism to distribute new or updated parameters to the client. We also introduce a way for the client to decline the reconfiguration request. Fang et al. Expires [Page 3] INTERNET DRAFT Forcerenew Reconfiguration Extensions February 9, 2017 Any server-initiated reconfiguration requires authentication. The extended DHCPFORCERENEW message must be used with the security mechanisms described in [RFC6704], which aligns DHCPv4 authentication with DHCPv6 authentication described in [I-D. draft-ietf-dhc- rfc3315bis]. The extended DHCPFORCENEW message described in this document aligns the behavior of server-initiated reconfiguration in DHCPv4 with the corresponding behavior in DHCPv6. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. In this document, we use the terminology defined in [RFC3203] and in [I-D. draft-ietf-dhc-rfc3315bis]. 2. Extended DHCPFORCERENEW Message for DHCPv4 2.1 DHCPFORCERENEW Procedure This is the DHCPFORCERENEW procedure defined in [RFC3203]. The DHCP server sends a unicast DHCPFORCERENEW message to the client. Upon receipt of the unicast DHCPFORCERENEW message, the client enters a Renew/Reply transaction with the server to try to renew its lease according to normal DHCP procedures. If the server wants to assign a new IP address to the client, it replies to the DHCPREQUEST with a DHCPNAK. The client then goes back to the init state and broadcasts a DHCPDISCOVER message. The server can now assign a new IP address to the client by replying with a DHCPOFFER. If the DHCPFORCERENEW message is lost, the DHCP server does not receive a DHCPREQUEST from the client and retransmits the DHCPFORCERENEW message using an exponential backoff algorithm. The DHCPFORCERENEW message makes use of the normal DHCP message format with DHCP option 53 (DHCP message type) value equal to DHCPFORCERENEW (9). As recognized in [RFC3203], usage of the DHCPFORCERENEW message to reconfigure local configuration parameters other than IP addresses can lead to the unnecessary interruption of active sessions. Thus, a modification of the DHCPFORCERENEW message is desirable to avoid service interruptions in such increasingly common situations. 2.2 DHCPFORCEINFORENEW: Extended DHCPFORCERENEW Message Fang et al. Expires [Page 4] INTERNET DRAFT Forcerenew Reconfiguration Extensions February 9, 2017 The extended FORCERENEW message makes use of the normal DHCP message format with DHCP option 53 (message type) value equal to DHCPFORCEINFORENEW (TBD, see IANA considerations below). Upon receipt of a DHCPFORCEINFORENEW, the client sends a DHCPINFORM message to the server to request and obtain new configuration information. If the DHCPFORCEINFORENEW message is lost, the DHCP server does not receive a DHCPINFORM from the client and retransmits the DHCPFORCEINFORENEW message using an exponential backoff algorithm. In order to assure backward compatibility with DHCP clients not supporting the extended DHCPFORCERENEW message, if no DHCPINFORM is received once the backoff expires, the DHCP server SHOULD send a DHCPFORCERENEW message to brute force the reconfiguration by reverting to the conventional DHCPv4 reconfiguration mechanism. The fact that the DHCP server ultimately reverts to the DHCPFORCERENEW message, however, complicates the ability of the client to decline the FORCEINFORENEW message, as discussed in the next section. 2.3 DHCPFORCEINFORENEW Client Decline It is desirable to introduce a way to allow the client to decline the DHCPFORCEINFORENEW request from the server. Because of the server behavior defined in the previous section, motivated by the objective of achieving backward compatibility with clients not supporting the extended DHCPFORCERENEW message, the DHCP client can't simply ignore the request, since that would eventually result in a DHCPFORCERENEW message to be sent by the server. One obvious solution is to forego backward compatibility and have the DHCP server simply abandon the reconfiguration procedure at the end of the DHCPINFOFORCERENEW reconfiguration procedure. 3. Security Considerations The reconfiguration procedure using extended DHCPFORCERENEW message described in this draft MUST be authenticated with the procedures described in [RFC3118] or [RFC6704]. The security considerations relating to the DHCPFORCEINFORENEW message are the same as for DHCPFORCERENEW message discussed in [RFC3203] and [RFC6704]. Fang et al. Expires [Page 5] INTERNET DRAFT Forcerenew Reconfiguration Extensions February 9, 2017 4. IANA Considerations IANA is requested to assign a new value for DHCP option 53 (DHCP message type) [RFC2939] for the DHCPFORCEINFORENEW message from the registry "DHCP Message Type 53 Values" maintained at http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp- parameters.xhtml 5. Acknowledgments We would like to acknowledge Tomek Mrugalski, Christian Huitema and Bernie Volz for their comments and reviews. 6. References 6.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, . [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, DOI 10.17487/RFC2939, September 2000, . [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, DOI 10.17487/RFC3203, December 2001, . [RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001, . [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, . [RFC6704] Miles, D., Dec, W., Bristow, J., and R. Maglione, "Forcerenew Nonce Authentication", RFC 6704, DOI 10.17487/RFC6704, August 2012, . Fang et al. Expires [Page 6] INTERNET DRAFT Forcerenew Reconfiguration Extensions February 9, 2017 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 7341, DOI 10.17487/RFC7341, August 2014, . 6.2 Informative References [I-D. draft-ietf-dhc-rfc3315bis] T. Mrugalski et al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis", draft- ietf-dhc-rfc3315bis-06 (work in progress), October 2016. Authors' Addresses Luyuan Fang eBay 411 108th Ave NE Bellevue, WA 98004 Email: lufang@ebay.com Deepak Bansal Microsoft 15590 NE 31st St. Redmond, WA 98052 Email: dbansal@microsoft.com Fabio Chiussi Luiginius Seattle, WA 98116 Email: fabiochiussi@gmail.com Fang et al. Expires [Page 7]