draft-ietf-dhc-dhcpv6-stateful-issues-08.txt   draft-ietf-dhc-dhcpv6-stateful-issues-09.txt 
Network Working Group O. Troan Network Working Group O. Troan
Internet-Draft B. Volz Internet-Draft B. Volz
Updates: 3315,3633 (if approved) Cisco Systems, Inc. Updates: 3315,3633 (if approved) Cisco Systems, Inc.
Intended status: Standards Track M. Siodelski Intended status: Standards Track M. Siodelski
Expires: April 25, 2015 ISC Expires: May 30, 2015 ISC
October 22, 2014 November 26, 2014
Issues and Recommendations with Multiple Stateful DHCPv6 Options Issues and Recommendations with Multiple Stateful DHCPv6 Options
draft-ietf-dhc-dhcpv6-stateful-issues-08.txt draft-ietf-dhc-dhcpv6-stateful-issues-09.txt
Abstract Abstract
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written
with the expectation that additional stateful DHCPv6 options would be with the expectation that additional stateful DHCPv6 options would be
developed. IPv6 Prefix Options for Dynamic Host Configuration developed. IPv6 Prefix Options for Dynamic Host Configuration
Protocol (DHCP) version 6 shoe-horned the new options for Prefix Protocol (DHCP) version 6 has since shoe-horned a new option for
Delegation into DHCPv6. Implementation experience of the CPE model Prefix Delegation into DHCPv6. Implementation experience of the CPE
described in RFC 7084 has shown multiple issues with the DHCPv6 model described in RFC 7084 has shown multiple issues with the DHCPv6
protocol in supporting multiple stateful options. This document protocol in supporting multiple stateful options. This document
updates RFC 3315 and RFC 3633 to address the identified issues. updates RFC 3315 and RFC 3633 to address the identified issues.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2015. This Internet-Draft will expire on May 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 43 skipping to change at page 2, line 43
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
DHCPv6 [RFC3315] was not written with the expectation that additional DHCPv6 [RFC3315] was not written with the expectation that additional
stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation
[RFC3633] shoe-horned the new options for Prefix Delegation into [RFC3633] has since shoe-horned a new option for Prefix Delegation
DHCPv6. Implementation experience of the CPE model described in into DHCPv6. Implementation experience of the CPE model described in
[RFC7084] has shown issues with the DHCPv6 protocol in supporting [RFC7084] has shown issues with the DHCPv6 protocol in supporting
multiple stateful option types, in particular IA_NA (non-temporary multiple stateful option types, in particular IA_NA (non-temporary
addresses) and IA_PD (delegated prefixes). addresses) and IA_PD (delegated prefixes).
This document describes a number of problems encountered with This document describes a number of problems encountered with
coexistence of the IA_NA and IA_PD option types and changes to the coexistence of the IA_NA and IA_PD option types and changes to the
DHCPv6 protocol specifications to address these problems. DHCPv6 protocol specifications to address these problems.
The intention of this work is to clarify and, where needed, modify The intention of this work is to clarify and, where needed, modify
the DHCP protocol specification to support IA_NA and IA_PD option the DHCP protocol specification to support IA_NA and IA_PD option
skipping to change at page 13, line 29 skipping to change at page 13, line 29
When the client receives a Reply message in response to a Renew or When the client receives a Reply message in response to a Renew or
Rebind message, for each IA in the original Renew or Rebind Rebind message, for each IA in the original Renew or Rebind
message, the client: message, the client:
- Sends a Request message if the server responded with the - Sends a Request message if the server responded with the
NoBinding status code. The client places only these IA options NoBinding status code. The client places only these IA options
in the Request message for which the server returned NoBinding in the Request message for which the server returned NoBinding
status code in the Reply message. The client continues to use status code in the Reply message. The client continues to use
other bindings for which the server did not return an error. other bindings for which the server did not return an error.
- Follows the retransmission procedure for Renew/Rebind messages - Sends a Renew/Rebind if the IA is not in the Reply message.
as described in section 14 if the IA is not in the Reply However, in this case, the client MUST limit the rate at which
message. it sends subsequent Renew/Rebind messages and limit the duration
of the time during which it sends the messages.
- Otherwise accepts the information in the IA. - Otherwise accepts the information in the IA.
When the client receives a valid Reply message in response to a When the client receives a valid Reply message in response to a
Release message, the client considers the Release event completed, Release message, the client considers the Release event completed,
regardless of the Status Code option(s) returned by the server. regardless of the Status Code option(s) returned by the server.
When the client receives a valid Reply message in response to a When the client receives a valid Reply message in response to a
Decline message, the client considers the Decline event completed, Decline message, the client considers the Decline event completed,
regardless of the Status Code option(s) returned by the server. regardless of the Status Code option(s) returned by the server.
skipping to change at page 17, line 40 skipping to change at page 17, line 40
Replace Section 12.2: Replace Section 12.2:
The delegating router behaves as follows when it cannot find a The delegating router behaves as follows when it cannot find a
binding for the requesting router's IA_PD: binding for the requesting router's IA_PD:
With: With:
For the Renew or Rebind, if the IA_PD contains no prefixes, i.e. For the Renew or Rebind, if the IA_PD contains no prefixes, i.e.
contains no IA Prefix option or the IPv6 prefix field in the IA contains no IA Prefix option or the IPv6 prefix field in the IA
Prefix option is set to 0, the delegating router MAY assign Prefix option is set to 0, the delegating router SHOULD assign
prefixes to the IA_PD according to the delegating router's prefixes to the IA_PD according to the delegating router's
explicit configuration information. In this case, when the server explicit configuration information. In this case, when the server
assigns new prefixes to the IA_PD, the server MAY use the value in assigns new prefixes to the IA_PD, the server MAY use the value in
the prefix-length field of the IA Prefix option as a hint for the the prefix-length field of the IA Prefix option as a hint for the
length of the prefixes being assigned. length of the prefixes being assigned.
The delegating router behaves as follows when it cannot find a The delegating router behaves as follows when it cannot find a
binding for the requesting router's IA_PD containing prefixes: binding for the requesting router's IA_PD containing prefixes:
4.5. Confirm Message 4.5. Confirm Message
skipping to change at page 20, line 22 skipping to change at page 20, line 22
[RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT
and INF_MAX_RT", RFC 7083, November 2013. and INF_MAX_RT", RFC 7083, November 2013.
8.2. Informative References 8.2. Informative References
[I-D.dhcwg-dhc-rfc3315bis] [I-D.dhcwg-dhc-rfc3315bis]
Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) bis", draft- Configuration Protocol for IPv6 (DHCPv6) bis", draft-
dhcwg-dhc-rfc3315bis-02 (work in progress), July 2014. dhcwg-dhc-rfc3315bis-03 (work in progress), October 2014.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059, November Detecting Network Attachment in IPv6", RFC 6059, November
2010. 2010.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
 End of changes. 8 change blocks. 
14 lines changed or deleted 15 lines changed or added

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