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 <January 7, 2016> [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 <January 7, 2016> [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 <January 7, 2016> [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 <January 7, 2016> [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 <January 7, 2016> [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 <January 7, 2016> [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 <January 7, 2016> [Page 7]