--- 1/draft-ietf-dhc-dhcpv6-stateful-issues-07.txt 2014-10-22 14:14:54.731511283 -0700 +++ 2/draft-ietf-dhc-dhcpv6-stateful-issues-08.txt 2014-10-22 14:14:54.787512650 -0700 @@ -1,48 +1,48 @@ Network Working Group O. Troan Internet-Draft B. Volz Updates: 3315,3633 (if approved) Cisco Systems, Inc. Intended status: Standards Track M. Siodelski -Expires: April 5, 2015 ISC - October 2, 2014 +Expires: April 25, 2015 ISC + October 22, 2014 Issues and Recommendations with Multiple Stateful DHCPv6 Options - draft-ietf-dhc-dhcpv6-stateful-issues-07.txt + draft-ietf-dhc-dhcpv6-stateful-issues-08.txt Abstract Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written with the expectation that additional stateful DHCPv6 options would be developed. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 shoe-horned the new options for Prefix Delegation into DHCPv6. Implementation experience of the CPE model described in RFC 7084 has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. This document - updates RFC 3315 and RFC 3633. + updates RFC 3315 and RFC 3633 to address the identified issues. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on April 5, 2015. + This Internet-Draft will expire on April 25, 2015. Copyright Notice Copyright (c) 2014 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 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 @@ -50,172 +50,153 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 4. Handling of Multiple IA Options Types . . . . . . . . . . . . 4 - 4.1. Placement of Status Codes . . . . . . . . . . . . . . . . 5 + 4. Handling of Multiple IA Options Types . . . . . . . . . . . . 3 + 4.1. Placement of Status Codes . . . . . . . . . . . . . . . . 4 4.2. Advertise Message . . . . . . . . . . . . . . . . . . . . 6 4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 8 4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 8 4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 8 4.4.3. Updates to section 18.1.3 of RFC 3315 . . . . . . . . 9 4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 10 4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 11 - 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 . . . . . . . . 13 4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 15 4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 17 4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 18 4.6. Decline Should Not Necessarily Trigger a Release . . . . 19 4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction DHCPv6 [RFC3315] was not written with the expectation that additional stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation [RFC3633] shoe-horned the new options for Prefix Delegation into DHCPv6. Implementation experience of the CPE model described in [RFC7084] has shown issues with the DHCPv6 protocol in supporting multiple stateful option types, in particular IA_NA (non-temporary addresses) and IA_PD (delegated prefixes). This document describes a number of problems encountered with coexistence of the IA_NA and IA_PD option types and changes to the DHCPv6 protocol specifications to address these problems. The intention of this work is to clarify and, where needed, modify - the DHCP protocol specification to support multiple IA option types - within a single DHCP session. However, as it is not possible to know - what future IA option types might be used for, this work is primarily - to clarify DHCP operation when IA_NA and IA_PD options are being - requested as per [RFC7084]. And, to provide a framework to support - new IA option types, assuming they are similar enough. Future - documents that define new IA option types will need to specify - whether they fit into this framework or define the DHCP operation for - the new and existing IA option types, as appropriate. - - There are two general solutions to the problem of supporting multiple - IA option types. One is by using a separate DHCP session (separate - instances of the client state machine) per IA option type. While - conceptually simple, this approach has a number of issues: multiple - instances of the state machine in clients, additional DHCP protocol - traffic, 'collisions' between other configuration options, divergence - in that each IA option type specification specifies its 'own' version - of the DHCP protocol. The other is by using a single DHCP session - and state machine, which is the approach taken by this document (see - Section 4). + the DHCP protocol specification to support IA_NA and IA_PD option + types within a single DHCP session. Note that while IA_TA (temporary addresses) options may be included with other IA option type requests, these generally are not renewed (there are no T1/T2 times) and have a separate life cycle from IA_NA and IA_PD option types. DHCPv6 assigned temporary addresses also have limited value when DHCPv6 is used for non-temporary address assignment, as the privacy issues identified for IPv6 stateless address assignment ([RFC4941]) do not apply to DHCPv6 assignments. + Therefore, the IA_TA option type is mostly out of scope for this + document. The changes described in this document are intended to be incorporated in a new revision of the DHCPv6 protocol specification ([I-D.dhcwg-dhc-rfc3315bis]). 2. Conventions 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 [RFC2119]. 3. Terminology In addition to the terminology defined in [RFC3315], [RFC3633], and [RFC7227], the following terminology is used in this document: - Resource (allocable resource): A value (or a collection of values) - dynamically assigned to the client by - the server and being carried in the - stateful options. Examples of - resources are an IPv6 address or an - IPv6 prefix. Information about the - resources is transported in stateful - options such as IA_NA, for addresses, - and IA_PD, for prefix delegations. - In the future, other types of - resources and stateful options may be - defined. - - Identity association (IA): A collection of resources assigned to - a client. Each IA has an associated - IAID. A client may have more than - one IA assigned to it; for example, - one for each of its interfaces. Each - IA holds one type of IA option; for - example, an identity association for - non-temporary addresses (IA_NA) holds - non-temporary addresses. Throughout - this document, "IA" is used to refer - to an identity association without - identifying the type of resources in - the IA. + Identity association (IA): Throughout this document, "IA" is + used to refer to the Identity + Association containing addresses or + prefixes assigned to a client and + carried in the IA_NA or IA_PD options + respectively. IA option types: This is used to generally mean an - IA_NA and/or IA_PD and may also - include IA_TA, as well as future IA - options. + IA_NA and/or IA_PD option. Stateful options: Options that require dynamic binding state per client on the server. 4. Handling of Multiple IA Options Types DHCPv6 was written with the assumption that the only stateful options were for assigning addresses. DHCPv6 PD describes how to extend the DHCPv6 protocol to handle prefix delegation, but [RFC3633] did not consider how DHCP address assignment and prefix delegation could co- exist. If a client requests multiple IA option types, but the server is configured to only offer a subset of them, the client could react in several ways. Reset the state machine and continue to send Solicit messages, create separate DHCP sessions for each IA option type and continue to Solicit for the unfulfilled IA options, or it could continue with the single session, and include the unfulfilled IA options in subsequent messages to the server. + Reseting the state machine and continuing to send Solicit messages + may result in the client never completing DHCP and is generally not + considered a good solution. It can also result in a request storm if + the client does not appropriately rate limit its sending of Solicit + messages. + + Creating a separate DHCP session (separate instances of the client + state machine) per IA option type, while conceptually simple, has a + number of issues: multiple instances of the state machine in clients, + additional DHCP protocol traffic, 'collisions' between other + configuration options, divergence in that each IA option type + specification specifies its 'own' version of the DHCP protocol. + + This leaves a single DHCP session and state machine which is the + proposed solution. Here, the client can use what it is able to + obtain and can continue to request what it was previously unable to + obtain while maintaining a single session and state machine. + Proposed solution: the client should keep a single session with the server and include the missing options in subsequent messages (Request, Renew, and Rebind) to the server. 4.1. Placement of Status Codes 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 the Status Code option with the - NoAddrsAvail code is in the top-level. That makes sense when the - failure case is fatal. However, with the introduction of other - stateful option types, there may be cases where a server is not - willing to offer addresses, but is willing to offer other resources, - e.g. delegated prefixes. - - Ideally the Status Code option for IA specific status codes should be - encapsulated in the IA option for all DHCP messages. This also makes - the NoAddrsAvail and NoPrefixAvail Status Code option placement for + NoAddrsAvail code is in the top level. This makes sense if the + client is only 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 a Solicit message, it is possible that the server + offers no addresses but it offers some prefixes, and the client may + choose to send a Request message to obtain the offered prefixes. In + this case, it is better if the Status Code option for IA specific + status codes is encapsulated in the IA option to indicate that the + failure occurred for the specific IA. This also makes the + NoAddrsAvail and NoPrefixAvail Status Code option placement for Advertise messages identical to Reply messages. In addition, how a server formats the Advertise message when addresses are not available has been a point of some confusion and implementations seem to vary (some strictly follow RFC 3315 while others assumed it was encapsulated in the IA option as for Reply messages). Therefore, the proposed solution is: @@ -314,34 +295,46 @@ client handle the case where multiple IA options have different T1 and T2 times? In a multiple IA option type model, the T1/T2 times are protocol timers, that should be independent of the IA options themselves. If we were to redo the DHCP protocol from scratch the T1/T2 times should be carried in a separate DHCP option. Proposed solution: The server MUST set the T1/T2 times in all IA options in a Reply or Advertise message to the same value. To deal - with the case where servers have not yet been updated to do that, - clients MUST use the shortest (explicit or implicit) T1/T2 times - (larger than 0), from the same IA option, in the Reply. T1/T2 times - from other IAs are ignored. + with the case where servers have not yet been updated to do that, the + client MUST select a T1 and T2 time from all IA options which will + guarantee that the client will send Renew/Rebind messages not later + than at the T1/T2 times associated with any of the client's bindings. - The following paragraph should be added to Section 18.2.1, 18.2.3, + As an example, if the client receives a Reply with T1_NA of 3600 / + T2_NA of 5760 and T1_PD of 0 / T2_PD of 1800, the client SHOULD use + the T1_PD of 0 / T2_PD of 1800. The reason for this is that a T1 of + 0 means that the Renew time is at the client's discretion, but this + value cannot be greater than the T2 value (1800). + + The following paragraph should be added to Sections 18.2.1, 18.2.3, and 18.2.4 of RFC 3315: The T1/T2 times set in each applicable IA option for a Reply MUST be the same values across all IAs. The server MUST determine the T1/T2 times across all of the applicable client's bindings in the Reply. This facilitates the client being able to renew all of the bindings at the same time. + Note: This additional paragraph has also been included in the revised + text later for Sections 18.2.3 and 18.2.4 of RFC 3315. + + Changes for client T1/T2 handling are included in Section 4.4.3 and + Section 4.4.4. + 4.4. Renew and Rebind Messages This section presents issues with handling multiple IA option types in the context of creation and processing the Renew and Rebind messages. It also proposes relevant updates to the [RFC3315] and [RFC3633]. 4.4.1. Renew Message The Renew message, as described in [RFC3315], allows a client to only @@ -389,24 +382,29 @@ containing an IA option for the IA. The client includes IA Address options in the IA option for the addresses associated with the IA. The server determines new lifetimes for the addresses in the IA according to the administrative configuration of the server. The server may also add new addresses to the IA. The server may remove addresses from the IA by setting the preferred and valid lifetimes of those addresses to zero. The server controls the time at which the client contacts the server to extend the lifetimes on assigned addresses through the T1 - and T2 parameters assigned to an IA. + and T2 parameters assigned to an IA. However, as the client + Renews/Rebinds all IAs from the server at the same time, the client + MUST select a T1 and T2 time from all IA options which will + guarantee that the client will send Renew/Rebind messages not later + than at the T1/T2 times associated with any of the client's + bindings. - At time T1 for an IA, the client initiates a Renew/Reply message - exchange to extend the lifetimes on any addresses in the IA. + At time T1, the client initiates a Renew/Reply message exchange to + extend the lifetimes on any addresses in the IA. If T1 or T2 had been set to 0 by the server (for an IA_NA) or there are no T1 or T2 times (for an IA_TA) in a previous Reply, the client may send a Renew or Rebind message, respectively, at the client's discretion. The client sets the "msg-type" field to RENEW. The client generates a transaction ID and inserts this value in the "transaction-id" field. @@ -447,23 +445,23 @@ MRD Remaining time until T2 The message exchange is terminated when time T2 is reached (see section 18.1.4), at which time the client begins a Rebind message exchange. 4.4.4. Updates to Section 18.1.4 of RFC 3315 Replace Section 18.1.4 of RFC 3315 with the following text: - At time T2 for an IA (which will only be reached if the server to - which the Renew message was sent at time T1 has not responded), the - client initiates a Rebind/Reply message exchange with any available + At time T2 (which will only be reached if the server to which the + Renew message was sent at time T1 has not responded), the client + initiates a Rebind/Reply message exchange with any available server. The client constructs the Rebind message as described in 18.1.3 with the following differences: - The client sets the "msg-type" field to REBIND. - The client does not include the Server Identifier option in the Rebind message. @@ -533,25 +532,21 @@ duplicate address detection before using the received addresses for the traffic. If any of the addresses are found to be in use on the link, the client sends a Decline message to the server for those addresses as described in section 18.1.7. If the Reply was received in response to a Solicit (with a Rapid Commit option), Request, Renew or Rebind message, the client updates the information it has recorded about IAs from the IA options contained in the Reply message: - - Record T1 and T2 times. The client MUST use the shortest - (explicit or implicit) T1 and T2 times (larger than 0) from the - same IA option across all of the IA options to facilitate - initiating the renewal process for all bindings simultaneously. - T1/T2 times from other IAs are ignored. + - Record T1 and T2 times. - Add any new addresses in the IA option to the IA as recorded by the client. - Update lifetimes for any addresses in the IA option that the client already has recorded in the IA. - Discard any addresses from the IA, as recorded by the client, that have a valid lifetime of 0 in the IA Address option. @@ -559,49 +554,46 @@ recorded in the IA but that were not included in the IA from the server. Management of the specific configuration information is detailed in the definition of each option in section 22. The client examines the status code in each IA individually. If the client receives a NoAddrsAvail, the client has received no usable addresses in the IA. - If the client finds no usable addresses in any IA, the client MAY - use the Information-request message to obtain other configuration - information only. + If the client finds no usable addresses in any of the IAs, it may + either try another server (by restarting the DHCP server discovery + process) or use the Information-request message to obtain other + configuration information only. The client uses addresses and other information from any IAs that do not contain a Status Code option with the NoAddrsAvail code. For each IA for which the client receives NoAddrsAvail status code the client has the following choices: - The client includes the IA with no addresses in subsequent Renew and Rebind messages sent to the server, to request creation of the binding for the IA. - - Tries another server (perhaps restarting the DHCP server - discovery process). + - Tries another server (by restarting the DHCP server discovery + process). When the client receives a Reply message in response to a Renew or Rebind message, for each IA in the original Renew or Rebind message, the client: - - Sends a Request message if the IA sent in the Renew or Rebind - contained addresses that the client is currently using and the - server responded with a NoBinding status code. - - - Tries to obtain the IA from another server (by restarting the - DHCP discovery process) if the client attempted to obtain a new - binding in the Renew or Rebind message by sending an IA without - any addresses and the server responded with NoBinding status - code. + - Sends a Request message if the server responded with the + NoBinding status code. The client places only these IA options + in the Request message for which the server returned NoBinding + status code in the Reply message. The client continues to use + other bindings for which the server did not return an error. - Follows the retransmission procedure for Renew/Rebind messages as described in section 14 if the IA is not in the Reply message. - Otherwise accepts the information in the IA. When the client receives a valid Reply message in response to a Release message, the client considers the Release event completed, regardless of the Status Code option(s) returned by the server. @@ -879,26 +871,28 @@ 5. IANA Considerations This specification does not require any IANA actions. 6. Security Considerations There are no new security considerations pertaining to this document. 7. Acknowledgements - Thanks to many people that contributed to identify the issues in this - document, including Ralph Droms, John, Brzozowski, Ted Lemon, Hemant - Singh, Wes Beebee, Gaurau Halwasia, Bud Millword, Tim Winters, and - Rob Shakir. + Thanks to many people that contributed to identify the stateful + issues addressed by this document and for reviewing drafts of the + document, including Ralph Droms, John Brzozowski, Ted Lemon, Hemant + Singh, Wes Beebee, Gaurau Halwasia, Bud Millword, Tim Winters, Rob + Shakir, Jinmei Tatuya, Andrew Yourtchenko, and Fred Templin. 8. References + 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic