draft-ietf-dhc-dhcpv4-forcerenew-extensions-01.txt   draft-ietf-dhc-dhcpv4-forcerenew-extensions-02.txt 
INTERNET-DRAFT Luyuan Fang INTERNET-DRAFT Luyuan Fang
Intended Status: Standards Track eBay Intended Status: Standards Track eBay
Expires: June 7, 2017 Deepak Bansal Expires: August 12, 2017 Deepak Bansal
Microsoft Microsoft
Fabio Chiussi Fabio Chiussi
Luiginius Luiginius
December 4, 2016 February 9, 2017
Forcerenew Reconfiguration Extensions for DHCPv4 Forcerenew Reconfiguration Extensions for DHCPv4
draft-ietf-dhc-dhcpv4-forcerenew-extensions-01 draft-ietf-dhc-dhcpv4-forcerenew-extensions-02
Abstract Abstract
This document extends the definition of the DHCPFORCERENEW message This document extends the definition of the DHCPFORCERENEW message
for parameter reconfiguration in DHCPv4. This extension makes the for parameter reconfiguration in DHCPv4. This extension makes the
DHCPFORCERENEW message more suitable to reconfigure configuration DHCPFORCERENEW message more suitable to reconfigure configuration
parameters other than IP addresses, and aligns the behavior of the parameters other than IP addresses, and aligns the behavior of the
reconfiguration procedure in DHCPv4 to the corresponding behavior in reconfiguration procedure in DHCPv4 to the corresponding behavior in
DHCPv6. DHCPv6.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Extended DHCPFORCERENEW Message for DHCPv4 . . . . . . . . . . 4 2. Extended DHCPFORCERENEW Message for DHCPv4 . . . . . . . . . . 4
2.1 DHCPFORCERENEW Procedure . . . . . . . . . . . . . . . . . . 4 2.1 DHCPFORCERENEW Procedure . . . . . . . . . . . . . . . . . . 4
2.2 DHCPFORCEINFORENEW: Extended DHCPFORCERENEW Message . . . . 5 2.2 DHCPFORCEINFORENEW: Extended DHCPFORCERENEW Message . . . . 4
2.3 DHCPFORCEINFORENEW Client Decline . . . . . . . . . . . . . 5 2.3 DHCPFORCEINFORENEW Client Decline . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6
6.2 Informative References . . . . . . . . . . . . . . . . . . 7 6.2 Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
Network and cloud operators increasingly use DHCP to distribute not Network and cloud operators increasingly use DHCP to distribute not
skipping to change at page 6, line 4 skipping to change at page 5, line 30
reverting to the conventional DHCPv4 reconfiguration mechanism. reverting to the conventional DHCPv4 reconfiguration mechanism.
The fact that the DHCP server ultimately reverts to the The fact that the DHCP server ultimately reverts to the
DHCPFORCERENEW message, however, complicates the ability of the DHCPFORCERENEW message, however, complicates the ability of the
client to decline the FORCEINFORENEW message, as discussed in the client to decline the FORCEINFORENEW message, as discussed in the
next section. next section.
2.3 DHCPFORCEINFORENEW Client Decline 2.3 DHCPFORCEINFORENEW Client Decline
It is desirable to introduce a way to allow the client to decline the It is desirable to introduce a way to allow the client to decline the
DHCPFORCEINFORENEW request from the server. This further aligns the DHCPFORCEINFORENEW request from the server.
client behavior in DHCPv4 server-initiated reconfiguration with the
corresponding behavior in DHCPv6.
Because of the server behavior defined in the previous section, Because of the server behavior defined in the previous section,
motivated by the objective of achieving backward compatibility with motivated by the objective of achieving backward compatibility with
clients not supporting the extended DHCPFORCERENEW message, the DHCP clients not supporting the extended DHCPFORCERENEW message, the DHCP
client can't simply ignore the request, since that would eventually client can't simply ignore the request, since that would eventually
result in a DHCPFORCERENEW message to be sent by the server. result in a DHCPFORCERENEW message to be sent by the server.
One obvious solution is to forego backward compatibility and have the One obvious solution is to forego backward compatibility and have the
DHCP server simply abandon the reconfiguration procedure at the end DHCP server simply abandon the reconfiguration procedure at the end
of the DHCPINFOFORCERENEW reconfiguration procedure. of the DHCPINFOFORCERENEW reconfiguration procedure.
Alternatively, a mechanism for the client to explicit inform the
server that it is declining the server-initiated DHCPINFOFORCERENEW
reconfiguration procedure needs to be devised.
3. Security Considerations 3. Security Considerations
The reconfiguration procedure using extended DHCPFORCERENEW message The reconfiguration procedure using extended DHCPFORCERENEW message
described in this draft MUST be authenticated with the procedures described in this draft MUST be authenticated with the procedures
described in [RFC3118] or [RFC6704]. described in [RFC3118] or [RFC6704].
The security considerations relating to the DHCPFORCEINFORENEW The security considerations relating to the DHCPFORCEINFORENEW
message are the same as for DHCPFORCERENEW message discussed in message are the same as for DHCPFORCERENEW message discussed in
[RFC3203] and [RFC6704]. [RFC3203] and [RFC6704].
skipping to change at page 6, line 50 skipping to change at page 6, line 23
5. Acknowledgments 5. Acknowledgments
We would like to acknowledge Tomek Mrugalski, Christian Huitema and We would like to acknowledge Tomek Mrugalski, Christian Huitema and
Bernie Volz for their comments and reviews. Bernie Volz for their comments and reviews.
6. References 6. References
6.1 Normative References 6.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>.
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
of New DHCP Options and Message Types", BCP 43, RFC 2939, of New DHCP Options and Message Types", BCP 43, RFC 2939,
September 2000. DOI 10.17487/RFC2939, September 2000, <http://www.rfc-
editor.org/info/rfc2939>.
[RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP
reconfigure extension", RFC 3203, December 2001. reconfigure extension", RFC 3203, DOI 10.17487/RFC3203,
December 2001, <http://www.rfc-editor.org/info/rfc3203>.
[RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for [RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for
DHCP Messages", RFC 3118, June 2001. DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001,
<http://www.rfc-editor.org/info/rfc3118>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC6704] D. Miles et al., "Forcerenew Nonce Authentication", [RFC6704] Miles, D., Dec, W., Bristow, J., and R. Maglione,
RFC 6704, August 2012. "Forcerenew Nonce Authentication", RFC 6704, DOI
10.17487/RFC6704, August 2012, <http://www.rfc-
editor.org/info/rfc6704>.
[RFC7341] Q. Sun et al., "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
RFC 7341, August 2012. Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",
RFC 7341, DOI 10.17487/RFC7341, August 2014,
<http://www.rfc-editor.org/info/rfc7341>.
6.2 Informative References 6.2 Informative References
[I-D. draft-ietf-dhc-rfc3315bis] T. Mrugalski et al., "Dynamic Host [I-D. draft-ietf-dhc-rfc3315bis] T. Mrugalski et al., "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) bis", draft- Configuration Protocol for IPv6 (DHCPv6) bis", draft-
ietf-dhc-rfc3315bis-06 (work in progress), October 201. ietf-dhc-rfc3315bis-06 (work in progress), October 2016.
Authors' Addresses Authors' Addresses
Luyuan Fang Luyuan Fang
eBay eBay
411 108th Ave NE 411 108th Ave NE
Bellevue, WA 98004 Bellevue, WA 98004
Email: lufang@ebay.com Email: lufang@ebay.com
Deepak Bansal Deepak Bansal
Microsoft Microsoft
15590 NE 31st St. 15590 NE 31st St.
Redmond, WA 98052 Redmond, WA 98052
Email: dbansal@microsoft.com Email: dbansal@microsoft.com
Fabio Chiussi Fabio Chiussi
Luiginius
Seattle, WA 98116 Seattle, WA 98116
Email: fabiochiussi@gmail.com Email: fabiochiussi@gmail.com
 End of changes. 19 change blocks. 
25 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/