draft-ietf-dhc-dhcpv6-stateful-issues-10.txt   draft-ietf-dhc-dhcpv6-stateful-issues-11.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: August 2, 2015 ISC Expires: August 16, 2015 ISC
January 29, 2015 February 12, 2015
Issues and Recommendations with Multiple Stateful DHCPv6 Options Issues and Recommendations with Multiple Stateful DHCPv6 Options
draft-ietf-dhc-dhcpv6-stateful-issues-10.txt draft-ietf-dhc-dhcpv6-stateful-issues-11.txt
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) The Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
specification defined two stateful options, IA_NA and IA_TA, but did specification defined two stateful options, IA_NA and IA_TA, but did
not anticipate the development of additional stateful options. not anticipate the development of additional stateful options.
DHCPv6 Prefix Delegation added the IA_PD option, which is stateful. DHCPv6 Prefix Delegation added the IA_PD option, which is stateful.
Applications that use IA_NA and IA_PD together have revealed issues Applications that use IA_NA and IA_PD together have revealed issues
that need to be addressed. This document updates RFC 3315 and RFC that need to be addressed. This document updates RFC 3315 and RFC
3633 to address these issues. 3633 to address these issues.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 August 2, 2015. This Internet-Draft will expire on August 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Handling of Multiple IA Option Types . . . . . . . . . . . . 4 4. Handling of Multiple IA Option Types . . . . . . . . . . . . 4
4.1. Placement of Status Codes in an Advertise Message . . . . 5 4.1. Placement of Status Codes in an Advertise Message . . . . 5
4.2. Advertise Message Processing by a Client . . . . . . . . 6 4.2. Advertise Message Processing by a Client . . . . . . . . 7
4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 7 4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 8 4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 9
4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 8 4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 9
4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 9 4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 10
4.4.3. Updates to section 18.1.3 of RFC 3315 . . . . . . . . 9 4.4.3. Updates to section 18.1.3 of RFC 3315 . . . . . . . . 10
4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 11 4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 12
4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 12 4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 13
4.4.6. Updates to Section 18.2.3 of RFC 3315 . . . . . . . . 14 4.4.6. Updates to Section 18.2.3 of RFC 3315 . . . . . . . . 15
4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 16 4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 16
4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 17 4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 18
4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 18 4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 19
4.6. Decline Should Not Necessarily Trigger a Release . . . . 19 4.6. Decline Should Not Necessarily Trigger a Release . . . . 20
4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 20 4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
DHCPv6 [RFC3315] was written without the expectation that additional DHCPv6 [RFC3315] was written without the expectation that additional
stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation
[RFC3633] since added a new stateful option for Prefix Delegation to [RFC3633] since added a new stateful option for Prefix Delegation to
DHCPv6. Implementation experience of the Customer Edge Router model DHCPv6. Implementation experience of the Customer Edge Router (CER)
described in [RFC7084] has shown issues with the DHCPv6 protocol in model described in [RFC7084] has shown issues with the DHCPv6
supporting multiple stateful option types, in particular IA_NA (non- protocol in supporting multiple stateful option types, in particular
temporary addresses) and IA_PD (delegated prefixes). IA_NA (non-temporary 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 specifies changes coexistence of the IA_NA and IA_PD option types and specifies changes
to the DHCPv6 protocol to address these problems. to the DHCPv6 protocol 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 DHCPv6 protocol specification to support IA_NA and IA_PD option the DHCPv6 protocol specification to support IA_NA and IA_PD option
types within a single DHCPv6 session. types within a single DHCPv6 session.
Note that while IA_TA (temporary addresses) options may be included Note that while IA_TA (temporary addresses) options may be included
skipping to change at page 4, line 29 skipping to change at page 4, line 42
2. Create separate DHCP sessions for each IA option type and 2. Create separate DHCP sessions for each IA option type and
continue to Solicit for the unfulfilled IA options, or continue to Solicit for the unfulfilled IA options, or
3. The client could continue with the single session, and include 3. The client could continue with the single session, and include
the unfulfilled IA options in subsequent messages to the server. the unfulfilled IA options in subsequent messages to the server.
Resetting the state machine and continuing to send Solicit messages Resetting the state machine and continuing to send Solicit messages
may result in the client never completing DHCP and is generally not may result in the client never completing DHCP and is generally not
considered a good solution. It can also result in a packet storm if considered a good solution. It can also result in a packet storm if
the client does not appropriately rate limit its sending of Solicit the client does not appropriately rate limit its sending of Solicit
messages. messages or there are many clients on the network. Client
implementors that follow this approach, are strongly advised to
implement the updates to RFC-3315 specified in [RFC7083].
Creating a separate DHCP session (separate instances of the client Creating a separate DHCP session (separate instances of the client
state machine) per IA option type, while conceptually simple, causes state machine) per IA option type, while conceptually simple, causes
a number of issues: additional host resources required to create and a number of issues: additional host resources required to create and
maintain multiple instances of the state machine in clients, maintain multiple instances of the state machine in clients,
additional DHCP protocol traffic, unnecessary duplication of other additional DHCP protocol traffic, unnecessary duplication of other
configuration options and the potential for conflict, divergence in configuration options and the potential for conflict, divergence in
that each IA option type specification specifies its 'own' version of that each IA option type specification specifies its 'own' version of
the DHCP protocol. the DHCP protocol.
We have chosen to recommend that clients use the remaining option: a The single session and state machine allows the client to use the
single DHCP session and state machine. The client maintains a single best configuration it is able to obtain from a single DHCP server
session and state machine. It uses the best configuration it is able during the configuration exchange. Note, however, that the server
to obtain during any configuration exchange. But it continues, in may not be configured to deliver the entire configuration requested
each subsequent configuration exchange, to request all the by the client. In that case the client could continue to operate
configuration information it is programmed to try to obtain, only using the configuration received, even if other servers can
including any stateful configuration options for which no results provide the missing configuration. In practice, especially in the
were returned in previous exchanges. case of handling IA_NA and IA_PD, this situation should be rare or a
temporary operational error. So, it is more likely for the client to
get all configuration if it continues, in each subsequent
configuration exchange, to request all the configuration information
it is programmed to try to obtain, including any stateful
configuration options for which no results were returned in previous
exchanges.
One major issue of this last approach is that it is difficult to
allow it with the current DHCPv6 specifications; in some cases they
are not clear enough, and in other cases existing restrictions can
make it impossible. This document introduces some clarifications and
small modifications to the current specifications to address these
concerns.
While all approaches have their own pros and cons, we recommend and
focus on approach 3 for this document because it is deemed to work
best for common cases of the mixed use of IA_NA and IA_PD. But this
document does not exclude other approaches. Also, in some corner
cases it may not be feasible to maintain a single DHCPv6 session for
both IA_NA and IA_PD. These corner cases are beyond the scope of
this document and may depend on the network in which the client (CER)
is designed to operate and on the functions the client is required to
perform.
The sections which follow update RFC 3315 and RFC 3633 to accommodate
the recommendation, though many of the changes are also applicable
even if other approaches are used.
4.1. Placement of Status Codes in an Advertise Message 4.1. Placement of Status Codes in an Advertise Message
In Reply messages IA specific status codes (i.e., NoAddrsAvail, In Reply messages IA specific status codes (i.e., NoAddrsAvail,
NotOnLink, NoBinding, NoPrefixAvail) are encapsulated in the IA NotOnLink, NoBinding, NoPrefixAvail) are encapsulated in the IA
option. In Advertise messages though, the NoAddrsAvail code is option. In Advertise messages though, the NoAddrsAvail code is
returned at in the top level. This makes sense if the client is only returned at in the top level. This makes sense if the client is only
interested in the assignment of the addresses and the failure case is interested in the assignment of the addresses and the failure case is
fatal. However, if the client sends both IA_NA and IA_PD options in fatal. However, if the client sends both IA_NA and IA_PD options in
a Solicit message, it is possible that the server offers no addresses a Solicit message, it is possible that the server offers no addresses
skipping to change at page 10, line 37 skipping to change at page 11, line 32
The client places the identifier of the destination server in a The client places the identifier of the destination server in a
Server Identifier option. Server Identifier option.
The client MUST include a Client Identifier option to identify The client MUST include a Client Identifier option to identify
itself to the server. The client adds any appropriate options, itself to the server. The client adds any appropriate options,
including one or more IA options. including one or more IA options.
For IAs to which addresses have been assigned, the client includes For IAs to which addresses have been assigned, the client includes
a corresponding IA option containing an IA Address option for each a corresponding IA option containing an IA Address option for each
address assigned to the IA. The client MUST not include addresses address assigned to the IA. The client MUST NOT include addresses
in any IA option that the client did not obtain from the server or in any IA option that the client did not obtain from the server or
that are no longer valid (that have a zero valid lifetime). that are no longer valid (that have a zero valid lifetime).
The client MAY include an IA option for each binding it desires but The client MAY include an IA option for each binding it desires but
has been unable to obtain. This IA option MUST NOT contain any has been unable to obtain. This IA option MUST NOT contain any
addresses. However, it MAY contain the IA Address option with IPv6 addresses. However, it MAY contain the IA Address option with IPv6
address field set to 0 to indicate the client's preference for the address field set to 0 to indicate the client's preference for the
preferred and valid lifetimes for any newly assigned addresses. preferred and valid lifetimes for any newly assigned addresses.
The client MUST include an Option Request option (see section 22.7) The client MUST include an Option Request option (see section 22.7)
skipping to change at page 21, line 15 skipping to change at page 22, line 13
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-03 (work in progress), October 2014. dhcwg-dhc-rfc3315bis-03 (work in progress), October 2014.
[I-D.ietf-mif-mpvd-arch] [I-D.ietf-mif-mpvd-arch]
Anipko, D., "Multiple Provisioning Domain Architecture", Anipko, D., "Multiple Provisioning Domain Architecture",
draft-ietf-mif-mpvd-arch-09 (work in progress), January draft-ietf-mif-mpvd-arch-10 (work in progress), February
2015. 2015.
[I-D.ietf-mif-mpvd-dhcp-support] [I-D.ietf-mif-mpvd-dhcp-support]
Krishnan, S., Korhonen, J., and S. Bhandari, "Support for Krishnan, S., Korhonen, J., and S. Bhandari, "Support for
multiple provisioning domains in DHCPv6", draft-ietf-mif- multiple provisioning domains in DHCPv6", draft-ietf-mif-
mpvd-dhcp-support-00 (work in progress), August 2014. mpvd-dhcp-support-00 (work in progress), August 2014.
[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.
 End of changes. 14 change blocks. 
38 lines changed or deleted 79 lines changed or added

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