--- 1/draft-ietf-dhc-dhcpv6-stateful-issues-00.txt 2012-10-06 04:14:21.665425158 +0200 +++ 2/draft-ietf-dhc-dhcpv6-stateful-issues-01.txt 2012-10-06 04:14:21.681425485 +0200 @@ -1,18 +1,19 @@ Network Working Group O. Troan Internet-Draft B. Volz -Intended status: Standards Track Cisco Systems, Inc. -Expires: November 8, 2012 May 7, 2012 +Updates: 3315,3633 (if approved) Cisco Systems, Inc. +Intended status: Standards Track October 6, 2012 +Expires: April 9, 2013 Issues with multiple stateful DHCPv6 options - draft-ietf-dhc-dhcpv6-stateful-issues-00.txt + draft-ietf-dhc-dhcpv6-stateful-issues-01.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 has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. @@ -25,55 +26,57 @@ 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 November 8, 2012. + This Internet-Draft will expire on April 9, 2013. Copyright Notice Copyright (c) 2012 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 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 - 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 4. Handling of multiple IA options types . . . . . . . . . . . . . 4 - 4.1. Advertisement message . . . . . . . . . . . . . . . . . . . 4 - 4.2. Placement of Status codes . . . . . . . . . . . . . . . . . 5 - 4.3. T1/T2 timers . . . . . . . . . . . . . . . . . . . . . . . 5 - 4.4. Confirm message . . . . . . . . . . . . . . . . . . . . . . 6 - 4.5. Release messages . . . . . . . . . . . . . . . . . . . . . 6 - 4.6. Unanswered options . . . . . . . . . . . . . . . . . . . . 6 - 4.7. Multiple provisioning domains . . . . . . . . . . . . . . . 7 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 - 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Handling of multiple IA options types . . . . . . . . . . . . 4 + 4.1. Advertisement message . . . . . . . . . . . . . . . . . . 4 + 4.2. Placement of Status codes . . . . . . . . . . . . . . . . 5 + 4.3. T1/T2 timers . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.4. Renew and Rebind messages . . . . . . . . . . . . . . . . 6 + 4.5. Confirm message . . . . . . . . . . . . . . . . . . . . . 8 + 4.6. Release messages . . . . . . . . . . . . . . . . . . . . . 9 + 4.7. Multiple provisioning domains . . . . . . . . . . . . . . 9 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 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 [RFC6204] has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. @@ -114,38 +117,51 @@ addresses (IA_TA) holds temporary addresses (see "identity association for temporary addresses"). Throughout this document, "IA" is used to refer to an identity association without identifying the type of stateful option in the IA. 4. Handling of multiple IA options types DHCPv6 was written with the assumption that the only stateful options - where for assigning addresses. DHCPv6 PD describes how to extend the - DHCPv6 protocol to handle prefix delegation, but RFC3633 did not + 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 missing options, or it could continue + with the single session, and include the missing options on + subsequent messages to the server. + + Proposed solution: the client should keep a single session with the + server and include the missing options on subsequent messages + (Request, Renew, and Rebind) to the server. + 4.1. Advertisement message - RFC3315 specifies that a client must ignore an Advertise message if a - server will not assign any addresses to a client. A client + [RFC3315] specifies that a client must ignore an Advertise message if + a server will not assign any addresses to a client. A client requesting both IA_NA and IA_PD, with a server that only offers one of them, is not supported in the current protocol specification. - Proposed solution: a client should accept Advertise messages, even - when not all IA option types are being offered. A client should + Proposed solution: a client SHOULD accept Advertise messages, even + when not all IA option types are being offered. A client SHOULD ignore an Advertise message when no bindings at all are being - offered. + offered. The client SHOULD include the not offered IA option types + in its Request. - Replace Section 17.1.3: (existing errata) + Replace Section 17.1.3 of [RFC3315]: (existing errata) The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message(s) to the user. With: The client MUST ignore any Advertise message that contains no bindings (if only IA_NA and/or IA_TA options were requested, @@ -204,126 +220,187 @@ we were to redo the DHCP protocol from scratch the T1/T2 timers should be carried in a separate DHCP option. Proposed solution: The server SHOULD set the T1/T2 timers in all IA options in Reply and Advertise messages 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 timer (larger than 0) in any IA options in the Reply. Longer T1/T2 timers are ignored. -4.4. Confirm message +4.4. Renew and Rebind messages + + The Renew message, as described in [RFC3315], allows a client to only + renew bindings assigned via a Request message. The Rebind message, + as described in [RFC3315] does not explicitly specify what a server + should do when an IA option which contains no addresses is present. + + In a multiple IA option type model, the Renew does not support the + ability for the client to renew one IA option type while requesting + bindings for other IA option types that were not available when the + client sent the Request. + + Proposed solution: The client should continue with the IA options + received, while continuing to include the other IA options in + subsequent messages to the server. The client and server processing + need to be modified. Note that this change makes the server's IA + processing of Renew and Rebind similar to the Request processing. + + Replace Section 18.1.3 of [RFC3315]: + + At time T1 for an IA, the client initiates a Renew/Reply message + exchange to extend the lifetimes on any addresses in the IA. The + client includes an IA option with all addresses currently assigned + to the IA in its Renew message. + + With: + + At time T1 for an IA, the client initiates a Renew/Reply message + exchange to extend the lifetimes on any addresses in the IA. The + client includes an IA option with all addresses currently assigned + to the IA in its Renew message. The client also includes an IA + option for each binding it desires but has been unable to obtain. + + Replace Section 18.2.3 of [RFC3315]: + + If the server cannot find a client entry for the IA the server + returns the IA containing no addresses with a Status Code option + set to NoBinding in the Reply message. + + With: + + If the server cannot find a client entry for the IA the server + creates the bindings for that client according to the server's + policy and configuration information and records the IAs and + other information requested by the client. + + Note that clients that communicate with servers that do not support + this updated Renew processing will receive the NoBinding status for + the IA which had no bindings. The client MUST continue to process + the other IAs in the Reply. The client MAY attempt a Solicit/ + Advertise/Request/Reply sequence periodically to obtain bindings for + these IAs. However, it MUST limit the frequency at which is does + this to no more often than the renewal frequency. + + Replace Section 18.1.4 of [RFC3315]: + + 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 + server. The client includes an IA option with all addresses + currently assigned to the IA in its Rebind message. + + With: + + 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 + server. The client includes an IA option with all addresses + currently assigned to the IA in its Rebind message. The client + also includes an IA option for each binding it desires but has been + unable to obtain. + +4.5. Confirm message The Confirm message, as described in [RFC3315], is specific to address assignment. It lets a server without a binding to reply to the message, under the assumption that the server only needs knowledge about the prefix(es) on the link, to inform the client that the address is likely valid or not. This message is sent when e.g. the client has moved and needs to validate its addresses. Not all bindings can be validated by servers and the Confirm message provides for this by specifying that a server that is unable to determine the on-link status MUST NOT send a Reply. Note: Confirm has a specific meaning and does not overload Renew/ Rebind. It also is lower processing cost as the server does NOT need to extend lease times or otherwise send back other configuration options. Proposed solution: Allow and specify the Confirm message for other IA - option types. A server SHOULD respond to a Confirm message only if - it has definitive knowledge, based on the network configuration and - not the specific client's bindings, that the client is still on-link - or not on-link. - -4.5. Release messages + option types. The server performs the same test as for addresses on + the delegated prefixes (see [RFC3315], section 18.2.2). - A client can release any individual lease at any time. A client can - get "back" a lease by using a Renew message. It MAY do this at any - time, though must avoid creating a Renew storm. E.g. wait until T1. + Replace Section 12.1 of [RFC3633]: -4.6. Unanswered options + If such verification is needed the requesting router MUST initiate + a Rebind/Reply message exchange as described in section 18.1.4, + "Creation and Transmission of Rebind Messages" of RFC 3315, with + the exception that the retransmission parameters should be set as + for the Confirm message, described in section 18.1.2, "Creation + and Transmission of Confirm Messages" of RFC 3315. The requesting + router includes any IA_PDs, along with prefixes associated with + those IA_PDs in its Rebind message. - If a client requests multiple IA option types, but the server is - willing 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 missing options, or it could continue - with the single session, and include the missing options on - subsequent messages to the server. + ... - Proposed solution: the client should keep a single session with the - server. The client should continue with the IA options received, - while continuing to request the other IA options in subsequent - messages to the server. That means to continue to include the empty - unanswered IAs in subsequent Renew and Rebind messages. + The Confirm and Decline message types are not used with Prefix + Delegation. - For the IAs that the server will not offer a binding, it must reply - using the same behaviour as for a Request message. That is not with - the currently specified NoBinding status). This behaviour will not - require the server to remember the IAs that it is not willing to - serve. I.e. the change is to allow the client to include IAs in - Renew/Rebind messages for which it has not received bindings (yet). + With: - A client can only use the Renew (or Rebind) to request new IA options - if it already has one or more bindings. A client MUST NOT use Renew - (or Rebind) if it has no valid bindings it is renewing. + If such verification is needed the requesting router MUST initiate + a Confirm message exchange as described in section 18.1.2, + "Creation and Transmission of Confirm Messages" of RFC 3315. The + requesting router includes any IA_PDs, along with prefixes + associated with those IA_PDs in its Confirm message. - Replace Section 18.2.3: + ... - If the server cannot find a client entry for the IA the server - returns the IA containing no addresses with a Status Code option set - to NoBinding in the Reply message. + The Decline message type is not used with Prefix Delegation. - With: +4.6. Release messages - If the server cannot find a client entry for the IA but has one or - more bindings for the client, the server SHOULD treat this like a - Request message for the IA. If the server has no other bindings for - the client, the server SHOULD return the IA containing no bindings - with a Status Code option set to NoBinding in the Reply message. + A client can release any individual lease at any time. A client can + get "back" a lease by using a Renew message. It MAY do this at any + time, though must avoid creating a Renew storm. E.g. wait until T1. 4.7. Multiple provisioning domains This document has assumed that all DHCP servers on a network are in a single provisioning domain and thus should be "equal" in the service - that they offer. + that they offer. This was also assumed by [RFC3315] and [RFC3633]. One could envision a network where the DHCP servers are in multiple - provisioning domains, and it may be desireable to have the DHCP - client obtain different IA types from different provisioning domains. - How a client detects the multiple provisioning domains and how it - would interact with the multiple servers in these different domains - is outside the scope of this document and an area for future work. + provisioning domains, and it may be desirable to have the DHCP client + obtain different IA types from different provisioning domains. How a + client detects the multiple provisioning domains and how it would + interact with the multiple servers in these different domains is + outside the scope of this document and an area for future work. 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 -8. Normative References +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 Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. +8.2. Informative References + [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011. Authors' Addresses Ole Troan Cisco Systems, Inc. Philip Pedersens vei 20 N-1324 Lysaker,