INTERNET-DRAFT Luyuan Fang Intended Status: Standards Track Deepak Bansal Expires: January 7, 2016 Microsoft Fabio Chiussi Cisco Systems July 6, 2015 Forcerenew Reconfiguration Extensions for DHCPv4 draft-fang-dhc-dhcpv4-forcerenew-extensions-00 Abstract This document extends the definition of the FORCERENEW message for parameter reconfiguration in DHCPv4. This extension makes the FORCERENEW 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) 2015 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 Seamless Reconfiguration in DHCPv4 July 6, 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Extended FORCERENEW Message for DHCPv4 . . . . . . . . . . . . 4 2.1 FORCERENEW Procedure . . . . . . . . . . . . . . . . . . . . 4 2.2 FORCEINFORENEW: Extended FORCERENEW Message . . . . . . . . 5 2.3 FORCEINFORENEW Client Decline . . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1 Normative References . . . . . . . . . . . . . . . . . . . 6 5.2 Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Fang et al. Expires [Page 2] INTERNET DRAFT Seamless Reconfiguration in DHCPv4 July 6, 2015 1. Introduction The ability for the DHCP server to initiate and execute reconfiguration of information in DHCP clients is becoming increasingly important in both IPv4 and IPv6 networks, as network and cloud operators use DFHCP more and more to distribute not just IP addresses, but also a variety of other configuration parameters to the clients. The reconfiguration procedure must keep service interruption to the clients to a minimum. In particular, in the case of reconfiguration of parameters other than IP addresses, service interruptions must be avoided. 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. 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 FORCERENEW message [RFC3203] and is less granular than its IPv6 counterpart, which can result in undesired effects. This is the consequence of two differences with respect to the reconfiguration procedure in DHCPv6. 1. The FORCERENEW message does not contain any indication for the client to distinguish a reconfiguration of IP addresses from a reconfiguration of some other information. As a result, the client always initiates a Renew/Reply transaction with the server. This makes it difficult to avoid service interruption even in case of reconfiguration of parameters other than IP addresses. 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. Fang et al. Expires [Page 3] INTERNET DRAFT Seamless Reconfiguration in DHCPv4 July 6, 2015 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 on a IPv6 core network. Thus, achieving similar reconfiguration behavior as DHCPv6 on a IPv4 network requires an extension to the FORCERENEW message. In this document, we extend the FORCERENEW message used in DHCPv4 by introducing a new Message Type FORCEINFORENEW 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 server. We also introduce a way for the server to decline the reconfiguration request. Any server-initiated reconfiguration requires authentication. The extended FORCERENEW 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 FORCENEW 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 FORCERENEW Message for DHCPv4 2.1 FORCERENEW Procedure This is the FORCERENEW procedure defined in [RFC3203]. The DHCP server sends a unicast FORCERENEW message to the client. Upon receipt of the unicast FORCERENEW 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 DHCP REQUEST with a DHCP NAK. The client then goes back to the init state and broadcasts a DHCP DISCOVER message. The server can now assign a new IP address to the client by replying with a DHCP OFFER. If the FORCERENEW Fang et al. Expires [Page 4] INTERNET DRAFT Seamless Reconfiguration in DHCPv4 July 6, 2015 message is lost, the DHCP server does not receive a DHCP REQUEST from the client and retransmits the FORCERENEW message using an exponential backoff algorithm. The FORCERENEW 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 FORCERENEW message to reconfigure local configuration parameters can lead to the interruption of active sessions. Thus, a modification of the FORCERENEW message is desirable to avoid service interruptions in the case of reconfiguration of parameters other than IP addresses. 2.2 FORCEINFORENEW: Extended FORCERENEW Message The extended FORCERENEW message makes use of the normal DHCP message format with DHCP option 53 (message type) value equal to DHCPFORCEINFORENEW (TBD). Upon receipt of a FORCEINFORENEW, the client sends a DHCPINFORM message to the server to request and obtain new configuration information. If the FORCEINFORENEW message is lost, the DHCP server does not receive a DHCPINFORM from the client and retransmits the FORCEINFORENEW message using an exponential backoff algorithm. For backward compatibility with DHCP clients not supporting the extended FORCERENEW message, if no DHCPINFORM is received once the backoff expires, the DHCP server SHOULD send a FORCERENEW message to brute force the reconfiguration by reverting to the conventional DHCPv4 reconfiguration mechanism. 2.3 FORCEINFORENEW Client Decline The client should be allowed to decline the FORCEINFORENEW request from the server. Because of the server behavior defined in the previous section, the client can't simply ignore the request, since that would eventually result in a FORCERENEW message to be sent by the server. To be completed. 3. Security Considerations The reconfiguration procedure using extended FORCERENEW message described in this draft MUST be authenticated with the procedures Fang et al. Expires [Page 5] INTERNET DRAFT Seamless Reconfiguration in DHCPv4 July 6, 2015 described in [RFC3118] or [RFC6704]. 4. IANA Considerations TBD. 5. References 5.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, December 2001. [RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, 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, July 2003. [RFC6704] D. Miles et al., "Forcerenew Nonce Authentication", RFC 6704, August 2012. [RFC7341] Q. Sun et al., "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 7341, August 2012. 5.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-01 (work in progress), July 2015. Authors' Addresses Luyuan Fang Microsoft 5600 148th Ave NE Redmond, WA 98052 Email: lufang@microsoft.com Deepak Bansal Fang et al. Expires [Page 6] INTERNET DRAFT Seamless Reconfiguration in DHCPv4 July 6, 2015 Microsoft 15590 NE 31st St. Redmond, WA 98052 Email: dbansal@microsoft.com Fabio Chiussi Cisco Systems 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004 Email: fchiussi@cisco.com Fang et al. Expires [Page 7]