Network Working Group O. Troan Internet-Draft B. Volz Updates: 3315,3633 (if approved) Cisco Systems, Inc. Intended status: Standards Track M. Siodelski Expires:January 1,April 5, 2015 ISCJune 30,October 2, 2014 Issues and Recommendations withmultiple statefulMultiple Stateful DHCPv6options draft-ietf-dhc-dhcpv6-stateful-issues-06.txtOptions draft-ietf-dhc-dhcpv6-stateful-issues-07.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. 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 onJanuary 1,April 5, 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Handling ofmultipleMultiple IAoptions typesOptions Types . . . . . . . . . . . . 4 4.1. Placement of Status Codes . . . . . . . . . . . . . . . . 5 4.2. Advertise Message . . . . . . . . . . . . . . . . . . . . 6 4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 7 4.4. RenewMessage . . .and Rebind Messages . . . . . . . . . . . . . . . . 8 4.4.1. Renew Message . . .7 4.4.1. Updates to RFC 3315. . . . . . . . . . . . . . . . . 8 4.4.2.Updates to RFC 3633 . . . . . . . . . . . . . .Rebind Message . . .9 4.4.3. Creation and Transmission of Renew Messages (unified text). . . . . . . . . . . . . . . . 8 4.4.3. Updates to section 18.1.3 of RFC 3315 . . . . . . . . 9 4.4.4.ReceiptUpdates to Section 18.1.4 ofRenew Messages (unified text) . . . . . . 11 4.5. Rebind Message . . . . . . . . . . . . .RFC 3315 . . . . . . . .11 4.5.1.10 4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . .. . . . . . . . . 12 4.5.2.11 4.4.6. Updates to Section 18.2.3 of RFC3633 . . . . . . . . .3315 . . . . . . . . 144.5.3. Creation and Transmission4.4.7. Updates to Section 18.2.4 ofRebind Messages (unified text) . . . . .RFC 3315 . . . . . . . . 15 4.4.8. Updates to RFC 3633 . . . . . . . . . . .15 4.5.4. Receipt of Rebind Messages (unified text). . . . . .16 4.6.17 4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . .17 4.7.18 4.6. Decline Should Not Necessarily Trigger a Release . . . .18 4.8.19 4.7. Multiple Provisioning Domains . . . . . . . . . . . . . .1819 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . .1920 8.2. Informative References . . . . . . . . . . . . . . . . .1920 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 shownmultipleissues with the DHCPv6 protocol in supporting multiple stateful option types, in particular IA_NA (non-temporary addresses) andIA_PD.IA_PD (delegated prefixes). This document describes a number of problems encountered withmultiple IAcoexistence of the IA_NA and IA_PD option types andrecommendedchanges to the DHCPv6 protocolspecifications.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.This problem can also be solved by implementing a separate DHCP session (separate client state machine) perHowever, as it is not possible to know what future IA optiontype. This latter approach has a number of issues: additionaltypes might be used for, this work is primarily to clarify DHCPprotocol traffic, 'collisions' between statelessoperation when IA_NA and IA_PD optionsalso included with theare being requested as per [RFC7084]. And, to provide a framework to support new IAoptions, divergence inoption types, assuming they are similar enough. Future documents thateachdefine new IA optiontype specification specifiestypes 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). 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.IA_TADHCPv6 assigned temporary addresses alsohashave 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. The changes described in this documentwillare intended to be incorporated in a new revision of the DHCPv6 protocol specification[RFC3315].([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.An exampleExamples oftheresourcesare: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 ofstateful optionsresources 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 fortemporarynon-temporary addresses(IA_TA)(IA_NA) holdstemporary addresses (see "identity association for temporary addresses").non-temporary addresses. Throughout this document, "IA" is used to refer to an identity association without identifying the type ofstateful optionresources in the IA. IA option types: This is used to generally mean an IA_NA and/or IA_PD and may also include IA_TA, as well asanyfuture IA options. Stateful options: Options that require dynamic binding state per client on the server. 4. Handling ofmultipleMultiple IAoptions typesOptions 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 optionsonin subsequent messages to the server. Proposed solution: the client should keep a single session with the server and include the missing optionsonin 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 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.WithHowever, with the introduction ofmultiple IAother stateful option types, theremightmay bea casecases where a server is not willing to offer addresses, butmight beis willing to offer otherstateful option types. While a Status Code option is implicitly bound to a specific type of IA,resources, e.g.NoPrefixAvail is only applicable to IA_PD and NoAddrsAvail is only applicable to IA_NA/IA_TA, it may be problematic to make this assumption for all status codes.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 Advertise messages identical to Reply messages.However,In addition, how a server formats the Advertise message when addresses are not available has been a point of some confusion and implementations seem tovary.vary (some strictly follow RFC 3315 while others assumed it was encapsulated in the IA option as for Reply messages). Therefore, theProposedproposed solution is: Clients MUST be prepared to handle each of the following Advertise messages formats when there are no addresses available (even when noIA_PD wasother IA option types were in the Solicit): 1. Advertise containing just a top-level Status Code option (of NoAddrsAvail) and no IA_NAs/IA_TAs. 2. Advertise containing the IA_NAs and/or IA_TAs with encapsulated Status Code option (of NoAddrsAvail) and no top-level Status Code option. 3. Advertise containing a top-level Status Code option (of NoAddrsAvail) and IA_NAs and/or IA_TAs with a Status Code option (of NoAddrsAvail). Servers MUSTusereturn the Status Code option (of NoAddrsAvail) encapsulated in an IA_NA/IA_TA options and not as a top-level Status Code option (of NoAddrsAvail) when no addresses will be assigned (2 in the above list). This means that the Advertise response matches the Reply response with respect to the handling of the NoAddrsAvail status. Replace the following paragraph in RFC 3315, section 17.2.2: If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. With: If the server will not assign any addresses to an IA in a subsequent Request from the client, the server MUST include the IA in the Advertise message with no addresses in the IA and a Status Code option encapsulated in the IA containing status code NoAddrsAvail. 4.2. Advertise Message [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. And, in this case, the client SHOULD include the not offered IA option types in its Request. A client SHOULD only ignore an Advertise message whennoall IAoption includes anyoptions include no offered addresses or delegatedprefixes (or any future allocable resource).prefixes. Note that ignored messages MUST still be processed for SOL_MAX_RT and INF_MAX_RT options as specified in [RFC7083]. Replace Section 17.1.3 of RFC 3315: (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 (this includes the changes made by [RFC7083]): The client MUST ignore any Advertise message that contains no addresses (IAADDR options encapsulated in IA_NA or IA_TA options) and no delegated prefixes (IAPREFIX options encapsulated in IA_PD options, see RFC 3633) with the exception that the client MUST process an included SOL_MAX_RT option (RFC 7083), MUST process an included INF_MAX_RT option (RFC 7083), and MAY display any associated status message(s) to the user. And, replace: - The client MAY choose a less-preferred server if that server has a better set of advertised parameters, such as the available addresses advertised in IAs. With: - The client MAY choose a less-preferred server if that server has a better set of advertised parameters, such as the available options advertised in IAs. It is important to note that the receipt of an Advertise message without any addresses and delegated prefixes does not imply that the client should restart the Solicit retransmissions timers. Doing so would lead to a Solicit/Advertise storm. 4.3. T1/T2 Timers The T1 and T2timerstimes determine when the client will contact the server to extend lifetimes of information received in an IA. How should a client handle the case where multiple IA options have different T1 and T2timers?times? In a multiple IA option type model, the T1/T2timerstimes are protocol timers, that should be independent of the IA options themselves. If we were to redo the DHCP protocol from scratch the T1/T2timerstimes should be carried in a separate DHCP option. Proposed solution: The serverSHOULDMUST set the T1/T2timerstimes in all IA options in a Replyandor Advertisemessagesmessage 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/T2timertimes (larger than0) in any0), from the same IAoptionsoption, in the Reply.LongerT1/T2timerstimes from other IAs are ignored. The following paragraph should be added to Section 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. 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 renew bindings assigned via a Request message. 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 similar to the Request processing.The first two subsections contain the required updates to [RFC3315] and [RFC3633] to accommodate this behavior on4.4.2. Rebind Message In Section 4.4.1 it has been proposed that the clientand the server. The remaining two subsections propose a "unified" text to be includedincludes IA options in a Renew message for the[I-D.dhcwg-dhc-rfc3315bis], describingbindings it desires but has been unable to obtain by sending a Request message, apart from theclient's and server's behaviorIA options forrenewing both addresses and prefixes. 4.4.1. Updates to RFC 3315 Replace Section 18.1.3 of RFC 3315:the existing bindings. At timeT1 for an IA,T2, the client stops sending Renew messages to the server and initiatesa Renew/Replythe Rebind/Reply message exchange with any available server. In this case, it should be possible toextendcontinue trying to obtain new bindings using thelifetimes on any addresses inRebind message if theIA. Theclientincludes an IA option with all addresses currently assignedfailed to get the response from the server to theIA in itsRenew message.With: At time T1The 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. Proposed solution: The client should continue with the IA options received and it MAY include additional IA options to request creation of additional bindings. 4.4.3. Updates to section 18.1.3 of RFC 3315 Replace Section 18.1.3 of RFC 3315 with the following text: To extend the valid and preferred lifetimes for the addresses associated with an IA, the clientinitiatessends aRenew/ReplyRenew messageexchangetoextendthelifetimes on anyserver from which the client obtained the addresses in theIA. The client includesIA containing an IA optionwith all addresses currently assigned tofor theIA in its Renew message.IA. The clientalsoincludesanIA Address options in the IA option foreach binding it desires but has been unable to obtain. Replace Section 18.2.3 of RFC 3315: Ifthe addresses associated with the IA. The servercannot find a client entrydetermines new lifetimes for the addresses in the IA according to theserver returnsadministrative configuration of theIA containing noserver. The server may also add new addresseswith a Status Code option settoNoBinding in the Reply message. With: Ifthe IA. The servercannot find a client entry formay remove addresses from the IA by setting the preferred and valid lifetimes of those addresses to zero. The servercreatescontrols the time at which thebindings for thatclientaccordingcontacts the server to extend theserver's policy and configuration information and returnslifetimes on assigned addresses through theIAsT1 andother information requested byT2 parameters assigned to an IA. At time T1 for an IA, theclient. 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 it does this to no more often than the renewal frequency. 4.4.2. Updates to RFC 3633 Replace Section 12.2 of RFC 3633: Renew message: If the delegating router cannot find a binding for the requesting router's IA_PD the delegating router returns the IA_PD containing no prefixes with a Status Code option set to NoBinding in the Reply message. With: Renew message: If the delegating router cannot find a binding for the requesting router's IA_PD, the delegating router creates the bindings for that client according to the server's policy and configuration information and returns the IAs and other information requested by the client. 4.4.3. Creation and Transmission of Renew Messages (unified text) To extend the valid and preferred lifetimes for the resources associated with IAs, the client sends a Renew message to the server from which the client obtained the resources. The server controls the time at which the client contacts the server to extend the lifetimes on client's bindings through the T1 and T2 parameters assigned to IAs. The server SHOULD assign the same T1 and T2 value to each binding assigned to the client. In this case the client uses the common T1 or T2 value returned in the IAs to determine the time when it should send Renew or Rebind message to the server. If the server sends different T1/T2 values for different IAs, the client uses the shortest T1/T2 value (larger than 0). T1/T2 values in other IA options are ignored. If T1 or T2 is set to 0 by the server for all IA_NA and IA_PD options, or there are no T1 or T2 times (for an IA_TA), the client may send Renew or Rebind message, respectively, at the client's discretion. At time T1, the client that initiates a Renew/Reply message exchange, includes IA options for all bindings for which it desires to extend lifetimes in its Renew message. For each IA being included, the client includes all resources currently associated with the IA. The client also includes IA option for each binding it desires but has been unable to obtain. For example: a client which has non- temporary addresses assigned but hasn't been delegated a prefix, may include an IA_PD option (in addition to the IA_NA option) in the Renew message to request prefix delegation. Theclientconstructinginitiates aRenewRenew/Reply messageSHOULD NOT include resources in IA options that the client does not have. If the client included a resource it does not have and the server does not allocate this resource for the client, the server will return the resourceexchange to extend theclientlifetimes on any addresses in theIA with the lifetimesIA. If T1 or T2 had been set to0. This is a signal to0 by theclient to not use this resource. TheserverMAY allocate(for an IA_NA) or there are no T1 or T2 times (for an IA_TA) in adifferent resource toprevious Reply, the clientandmay sendit ina Renew or Rebind message, respectively, at thesame IA.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. The client places the identifier of the destination server in a Server Identifier option. The client MUST include a Client Identifier option toidentify itselfidentify itself to the server. The client adds any appropriate options, including one or more IA options. The client includes an IA option with all addresses currently assigned to the IA in its Renew message. The client also includes IA options for all other bindings for which the client desires to extend the lifetimes of addresses. The client MUST only include addresses in the IA that the client obtained from the server and are still valid (have non-zero lifetime). 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 addresses. However, it MAY contain the IA Address option with IPv6 address field set to 0 to indicate theserver. The client addsclient's preference for the preferred and valid lifetimes for anyappropriate options, including one or more IA options.newly assigned addresses. The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned. The client transmits the message according to section 14, using the following parameters: IRT REN_TIMEOUT MRT REN_MAX_RT MRC 0 MRD Remaining time until T2If the server finds that any resource sent by the client is not appropriate, according to the server's configuration information, the server sends back the IA with the corresponding IA Address (for inappropriate address), IA Prefix option (for inappropriate prefix) or other option appropriate for the type of the resource, with lifetimes set to 0. The client which receives the option with lifetimes set to 0 MUST NOT use the corresponding resource.The message exchange is terminated when time T2 isreached,reached (see section 18.1.4), at which time the client begins a Rebind message exchange. 4.4.4.Receipt of Renew Messages (unified text) When the server receives a Renew message via unicast from a clientUpdates towhich the server has not sent a unicast option, the server discards the Renew message and responds with a Reply message containing a Status Code optionSection 18.1.4 of RFC 3315 Replace Section 18.1.4 of RFC 3315 with thevalue UseMulticast, a Server Identifier option containing the server's DUID, the Client Identifier option from the client message, and no other options. When the server receives a Renew message that contains an IA option from a client, it locates the client's binding and verifies that the information in the IA from the client matches the information stored for the client. If the server cannot find a client entry for the IA, the server creates the bindingsfollowing text: At time T2 forthat client according to the server's policy and configuration information and returns the IAs and other information requested by the client. For eachan IAfor which the server(which willnot create a bindingonly be reached if the serverreturns an IA option containing a Status Code option settoNoBinding in the Reply message. Ifwhich theserver finds that any resourceRenew message was sentby the client isat time T1 has notappropriate, according to the server's configuration information, the server sends backresponded), theIAclient initiates a Rebind/Reply message exchange withthe corresponding IA Address (for invalid address), IA Prefix option (for invalid prefix) oranyother option appropriate for the type of the resource, with lifetimes set to 0.available server. Theserverclient constructsa Replythe Rebind messageby settingas described in 18.1.3 with the following differences: - The client sets the "msg-type" field toREPLY, and copying the transaction ID from the Renew message into the transaction-id field.REBIND. - Theserver MUSTclient does not includea Server Identifier option containingtheserver's DUID and the ClientServer Identifier optionfrom the Renew messagein theReplyRebind message. Theserver includes other options containing configuration information to be returnedclient transmits the message according to section 14, using the following parameters: IRT REB_TIMEOUT MRT REB_MAX_RT MRC 0 MRD Remaining time until valid lifetimes of all addresses in all IAs have expired If all addresses for an IA have expired the clientas describedmay choose to include this IA without any addresses (or with only a hint for lifetimes) in[RFC3315]. 4.5.subsequent RebindMessage In the Section 4.4 it has been proposedmessages to indicate that the clientincludes IA optionsis interested ina Renew message forassignment of thebindings it desires but has been unableaddresses toobtain by sending a Request message, apart from the IA options forthis IA. The message exchange is terminated when theexisting bindings. At time T2 (being a shortest, greater than 0, timevalid lifetimes of all addresses across allclient's IAs),IAs have expired, at which time the clientstops sending Renew messagesmay use a Solicit message tothelocate a new DHCP server andinitiatessend a Request for theRebind/Reply message exchange with any available server. In this case, it should be possible to continue tryingexpired IAs toobtain new bindings using the Rebind message iftheclient failednew server. 4.4.5. Updates togetSection 18.1.8 of RFC 3315 Replace Section 18.1.8 of RFC 3315 with theresponse fromfollowing text: Upon theserverreceipt of a valid Reply message in response tothe Renew message. Thea Solicit (with a Rapid Commit option), Request, Confirm, Renew, Rebind or Information-request message,as describedthe client extracts the configuration information contained in[RFC3315] does not explicitly specify what a server should do when an IA option which contains no addresses is present. Proposed solution:the Reply. The clientshould continue with the IA options received and itMAYinclude additional IA options to request creation of additional bindings. The first two subsections contain the required updates to [RFC3315] and [RFC3633]choose toaccommodate this behavior on the client andreport any status code or message from theserver. The remaining two subsections propose a "unified" text to be includedstatus code option in the[I-D.dhcwg-dhc-rfc3315bis], describingReply message. If theclient's and server's behaviorclient receives a Reply message withrespect to processing different IA option types inasingle Rebind message. 4.5.1. Updates to RFC 3315 Replace Section 18.1.4 of RFC 3315: At time T2 for an IA (which will only be reached ifStatus Code containing UnspecFail, the server is indicating that it was unable towhichprocess theRenewmessagewas sent at time T1 has not responded),due to an unspecified failure condition. If the clientinitiates a Rebind/Replyretransmits the original messageexchange with any available server. The client includes an IA option with all addresses currently assignedto theIA in its Rebind message. With: At time T2 for an IA (which will only be reached if thesame server to retry the desired operation, the client MUST limit the rate at which it retransmits theRenewmessagewas sent atand limit the duration of the timeT1 has not responded),during which it retransmits the message. When the clientinitiatesreceives aRebind/ReplyReply messageexchangewithany available server. The client includes an IAa Status Code option withall addresses currently assigned totheIA in its Rebind message. The client also includes an IA option (withoutvalue UseMulticast, theIA Address option) for each binding it desires but has been unable to obtain. Theclientconstructing a Rebind message SHOULD NOT include addresses in IA options thatrecords theclient does not have. Ifreceipt of theclient included an address it does not havemessage and sends subsequent messages to the serverdoes not allocate this address for the client, the server will returnthrough theIA Address option containing address included byinterface on which the message was received using multicast. The clientinresends theIA with lifetimes set to 0. This is an indication tooriginal message using multicast. When the clientto not use this address. The server MAY allocatereceives adifferent addressNotOnLink status from the server in response to a Confirm message, the client performs DHCP server solicitation, as described in section 17, andsend itclient-initiated configuration as described in section 18. If thesame IA. Replace Section 18.2.4 of RFC 3315 withclient receives any Reply messages that do not indicate a NotOnLink status, thefollowing text to clarify howclient can use theserver should handle all ofaddresses in thepossible conditions:IA and ignore any messages that indicate a NotOnLink status. When theserverclient receives aRebind message that contains an IA optionNotOnLink status from the server in response to aclient, it locatesRequest, theclient's binding and verifies thatclient can either re-issue theinformationRequest without specifying any addresses or restart the DHCP server discovery process (see section 17). The client SHOULD perform duplicate address detection [17] on each of the received addresses in any IAs, on which it has not performed duplicate address detection during processing of any of theIAprevious Reply messages from the server. The clientmatchesperforms theinformation storedduplicate address detection before using the received addresses forthat client. Iftheserver findstraffic. If any of the addresses are found to be in use on theIA forlink, the clientandsends a Decline message to the serverdetermines that thefor those addresses as described in section 18.1.7. If theIA are appropriate for the link to which the client's interface is attached accordingReply was received in response to a Solicit (with a Rapid Commit option), Request, Renew or Rebind message, theserver's explicit configuration information,client updates theserver SHOULD send backinformation it has recorded about IAs from the IAtooptions contained in the Reply message: - Record T1 and T2 times. The clientwith new lifetimesMUST 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/T2times. Iftimes from other IAs are ignored. - Add any new addresses in theserver cannot find a client entryIA option to the IA as recorded by the client. - Update lifetimes for any addresses in the IAandoption that theserver determinesclient 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. - Leave unchanged any information about addresses the client has recorded in the IAarebut that were notappropriate forincluded in thelink to whichIA from theclient's interface is attached according toserver. Management of theserver's explicitspecific configurationinformation, the server MAY send a Reply message toinformation is detailed in the definition of each option in section 22. The clientcontainingexamines theclient's IA, withstatus code in each IA individually. If thelifetimes forclient receives a NoAddrsAvail, the client has received no usable addresses in theIA set to zero. This Reply constitutes an explicit notification toIA. If the clientthat thefinds no usable addresses in any IA, theIA are no longer valid. In this situation, ifclient MAY use theserver doesInformation-request message to obtain other configuration information only. The client uses addresses and other information from any IAs that do notsendcontain aReply message it silently discardsStatus Code option with theRebind message. IfNoAddrsAvail code. For each IA for which theserver cannot find acliententry forreceives NoAddrsAvail status code theIA andclient has the following choices: - The client includes the IAis empty (i.e. containswith noaddresses), the server MAY assign theaddressesto this IAin subsequent Renew andsend a Reply messageRebind messages sent to theclient with this IA containing allocated addresses with lifetimes and T1/T2 times. Inserver, to request creation of thecase whenbinding for the IA. - Tries another server (perhaps restarting the DHCP server discovery process). When the clientincluded addressesreceives a Reply message inthe IA, included addresses are appropriateresponse to a Renew or Rebind message, for each IA in thelink to whichoriginal Renew or Rebind message, theclient's interface is attached according toclient: - Sends a Request message if theserver's explicit configuration information and they are notIA sent inuse,theserver MAY allocate theseRenew or Rebind contained addressestothat theclient. Ifclient is currently using and the serverdoes not allocate addressesresponded with a NoBinding status code. - Tries to obtain theclient, theIA from another serverreturns(by restarting theIA containing only Status Code option setDHCP discovery process) if the client attempted toNoBindingobtain a new binding in theReply message. WhenRenew or Rebind message by sending an IA without any addresses and the servercreates new bindingsresponded with NoBinding status code. - Follows the retransmission procedure for Renew/Rebind messages as described in section 14 if the IAitispossible that other servers also create bindings as a result of receivingnot in thesame RebindReply message.This is- Otherwise accepts thesame issue asinformation in theDiscussion under the Rapid Commit option, see section 22.14. Therefore, the server SHOULD only create new bindings during processing of a Rebind message ifIA. When theserver is configured to respond withclient receives a valid Reply message in response to aSolicit message containingRelease message, theRapid Commit option. The server constructsclient considers the Release event completed, regardless of the Status Code option(s) returned by the server. When the client receives a valid Reply message in response to a Decline message, the client considers the Decline event completed, regardless of the Status Code option(s) returned bysettingthe"msg-type" fieldserver. 4.4.6. Updates toREPLY, and copyingSection 18.2.3 of RFC 3315 Replace Section 18.2.3 of RFC 3315 with thetransaction ID fromfollowing text: When theRebindserver receives a Renew messageintovia unicast from a client to which thetransaction-id field. TheserverMUST includehas not sent a unicast option, the server discards the Renew message and responds with a Reply message containing a Status Code option with the value UseMulticast, a Server Identifier option containing the server'sDUID andDUID, the Client Identifier option from theRebind messageclient message, and no other options. For each IA in theReply message. TheRenew message from a client, the serverincludes other options containing configuration information to be returned tolocates theclient as describedclient's binding and verifies that the information insection 18.2. 4.5.2. Updates to RFC 3633 Replace Section 12.2 of RFC 3633: Rebind message: Ifthedelegating router cannot find a binding forIA from therequesting router's IA_PD andclient matches thedelegating router determinesinformation stored for that client. If theprefixesserver finds the addresses in theIA_PD are not appropriateIA for thelink to which the requesting router's interface is attached according toclient then thedelegating routers explicit configuration,server sends back thedelegating router MAY send a Reply messageIA to therequesting router containing the IA_PDclient with new lifetimes and, if applicable, T1/T2 times. If the server is unable to extend the lifetimes ofthe prefixesan address in theIA_PD setIA, the server MAY choose not tozero. This Reply constitutes an explicit notificationinclude the IA Address option for this address. The server may choose to change therequesting router thatlist of addresses and theprefixeslifetimes of addresses inthe IA_PDIAs that areno longer valid. If the delegating router is unablereturned todetermine if the prefix is not appropriate for the link,theRebind message is discarded. with: Rebind message:client. If thedelegating router cannot find a binding for the requesting router's IA_PD and the delegating router determinesserver finds that any of theprefixesaddresses in theIA_PDIA are not appropriate for the link to which therequesting router's interfaceclient isattached according to the delegating routers explicit configuration, the delegating router MAY send a Reply message toattached, therequesting router containingserver returns theIA_PD withaddress to the client with lifetimes of 0. For each IA for which theprefixes inserver cannot find a client entry, theIA_PD set to zero. This Reply constitutes an explicit notificationserver has the following choices depending on the server's policy and configuration information: - If the server is configured to create new bindings as a result of processing Renew messages, therequesting router thatserver SHOULD create a binding and return theprefixesIA with allocated addresses with lifetimes and, if applicable, T1/T2 times and other information requested by the client. The server MAY use values in theIA_PD are no longer valid.IA Address option (if included) as a hint. - If thedelegating routerserver isunableconfigured todetermine ifcreate new bindings as a result of processing Renew messages, but theprefix isserver will notappropriate forassign any addresses to an IA, thelink,server returns theRebindIA option containing a Status Code option with the NoAddrsAvail status code and a status messageis discarded.for a user. - If theIA_PD contains no prefixes or the prefixes are appropriateserver does not support creation of new bindings for thelink to which the requesting router's interfaceclient sending a Renew message, or if this behavior isattacheddisabled according to thedelegating router's explicitserver's policy or configurationinformation and if prefixes are not in use,information, the server returns thedelegating router MAY assign prefixes to this IA_PD. 4.5.3. Creation and Transmission of Rebind Messages (unified text) At time T2 for anIA(which will only be reached ifoption containing a Status code option with the NoBinding status code and a status message for a user. The server constructs a Reply message by setting the "msg-type" field towhichREPLY, and copying the transaction ID from the Renew messagewas sent at time T1 has not responded),into theclient initiatestransaction-id field. The server MUST include aRebind/Reply message exchange with any available server. For each IA being included,Server Identifier option containing theclient stores all resources currently associated withserver's DUID and theIA.Client Identifier option from the Renew message in the Reply message. Theclient alsoserver includes other options containing configuration information to be returned to the client as described in section 18.2. The T1/T2 times set in each applicable IA option foreach binding it desires but has been unable to obtain. For example: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 clientwhich has non- temporary addresses assigned but has not been delegated a prefix, may include an IA_PD option (in additionbeing able to renew all of theIA_NA option) inbindings at theRebind messagesame time. 4.4.7. Updates torequestSection 18.2.4 of RFC 3315 Replace Section 18.2.4 of RFC 3315 with theprefix delegation. The client constructingfollowing text: When the server receives a Rebind messageSHOULD NOT include resources inthat contains an IAoptionsoption from a client, it locates the client's binding and verifies that the information in the IA from the clientdoes not have.matches the information stored for that client. If the server finds the addresses in the IA for the clientincluded a resource it does not haveand the serverdoes not allocate this resourcedetermines that the addresses in the IA are appropriate for theclient,link to which the client's interface is attached according to the server's explicit configuration information, the serverwill return the appropriate option containingSHOULD send back theresource (e.g.IAAddress, IA Prefix) withto the client with new lifetimesset to 0. Thisand, if applicable, T1/T2 times. If the server isan indicationunable to extend the lifetimes of an address in the IA, theclient to not use this resource. Theserver MAYallocate a different resourcechoose not to include the IA Address option for this address. If the server finds the client entry for the IA andsend it inany of thesame IA. The client setsaddresses are no longer appropriate for the"msg-type" fieldlink toREBIND. The client generates a transaction ID and inserts this value inwhich the"transaction-id" field. The client MUST include a Client Identifier optionclient's interface is attached according toidentify itselfthe server's explicit configuration information, the server returns the addresses to theserver. The client adds any appropriate options, including one or more IA options. TheclientMUST include the listwith lifetimes ofresources0. If the server cannot find a clientcurrently has associated withentry for theIAsIA, the IA contains addresses and the server determines that the addresses in theRebind message. The client MUST include an Option Request optionIA are not appropriate for the link toindicatewhich theoptions that clientclient's interface isinterested in receiving. The client MAY include options with data values as hintsattached according to theserver about parameter valuesserver's explicit configuration information, theclient would likeserver MAY send a Reply message tohave returned. Thethe clienttransmitscontaining themessage according to Section 14, usingclient's IA, with thefollowing parameters: IRT REB_TIMEOUT MRT REB_MAX_RT MRC 0 MRD Remaining time until validlifetimesof allfor the addressesor prefixesin the IAhave expired The message exchange is terminated whenset to 0. This Reply constitutes an explicit notification to thevalid lifetimes of allclient that theresources assigned toaddresses in the IAexpire, at which timeare no longer valid. In this situation, if theclient has several alternative actions to choose from; for example: - The client may choose to use a Solicit message to locate a new DHCPserveranddoes not send aRequest forReply message it silently discards theexpiredRebind message. Otherwise, for each IAtofor which thenew server. - Theserver cannot find a clientmay have other resources in other IAs, soentry, theclient may choose to discardserver has theexpired IA and usefollowing choices depending on theother IAs. 4.5.4. Receipt of Rebind Messages (unified text) Whenserver's policy and configuration information: - If the serverreceivesis configured to create new bindings as a result of processing Rebindmessage that contains an IAmessages (also see the note about the Rapid Commit optionfrom a client, it locatesbelow), theclient'sserver SHOULD create a binding andverifies thatreturn the IA with allocated addresses with lifetimes and, if applicable, T1/T2 times and other information requested by the client. The server MAY use values in the IAfrom the client matches the information stored for that client.Address option (if included) as a hint. - If the serverfindsis configured to create new bindings as a result of processing Rebind messages, but theresource inserver will not assign any addresses to an IA, the server returns the IAforoption containing a Status Code option with theclientNoAddrsAvail status code and a status message for a user. - If the serverdetermines that the resources in the IA are appropriatedoes not support creation of new bindings for thelink to which the client's interfaceclient sending a Rebind message, or if this behavior isattacheddisabled according to the server'sexplicitpolicy or configuration information, the serverSHOULD send backreturns the IAto the clientoption containing a Status Code option withnew lifetimesthe NoBinding status code andT1/T2 times. Ifa status message for a user. When the servercannot find a client entrycreates new bindings for the IAand the server determinesit is possible that other servers also create bindings as a result of receiving theresources in the IA are not appropriate forsame Rebind message. This is thelink to whichsame issue as in theclient's interface is attached according toDiscussion under theserver's explicit configuration information,Rapid Commit option, see section 22.14. Therefore, the serverMAY sendSHOULD only create new bindings during processing of aReplyRebind messageto the client containing the client's IA, with the lifetimes for the resources inif theIA setserver is configured tozero. Thisrespond with a Replyconstitutes an explicit notificationmessage to a Solicit message containing theclient that the resources in the IA are no longer valid. In this situation, if theRapid Commit option. The serverdoes not sendconstructs a Reply messageit silently discardsby setting the "msg-type" field to REPLY, and copying the transaction ID from the Rebindmessage. Ifmessage into the transaction-id field. The servercannot findMUST include aclient entry forServer Identifier option containing theIAserver's DUID and theIA is empty (i.e. contains no resources),Client Identifier option from theserver MAY assignRebind message in theresourcesReply message. The server includes other options containing configuration information tothisbe returned to the client as described in section 18.2. The T1/T2 times set in each applicable IAand sendoption for a Replymessage toMUST be theclient with this IA containing allocated resources with lifetimes and T1/T2 times. Insame values across all IAs. The server MUST determine thecase whenT1/T2 times across all of theclient included resourcesapplicable client's bindings in theIA, included resources are appropriate forReply. This facilitates thelinkclient being able towhichrenew all of theclient's interface is attached according tobindings at theserver's explicit configuration informationsame time. 4.4.8. Updates to RFC 3633 Replace Section 12.1: Each prefix has valid andtheypreferred lifetimes whose durations arenotspecified inuse,theserver MAY allocate these resourcesIA_PD Prefix option for that prefix. The requesting router uses Renew and Rebind messages to request theclient. Ifextension of theserver does not allocate resources tolifetimes of a delegated prefix. With: Each prefix has valid and preferred lifetimes whose durations are specified in theclient,IA_PD Prefix option for that prefix. The requesting router uses Renew and Rebind messages to request theserver returnsextension of the lifetimes of a delegated prefix. The requesting router MAY include IA_PD options without any prefixes, i.e. without IAcontaining only Status CodePrefix option or with IPv6 prefix field of IA Prefix option set toNoBinding0, inthe Reply message. When the server creates new bindings for the IA it is possible that other servers also create bindings asaresult of receiving the sameRenew or Rebindmessage. This is the same issue as in the Discussion under the Rapid Commit option, see section 22.14 of [RFC3315]. Therefore, the server SHOULD only create newmessage to obtain bindingsduring processingit desires but has been unable to obtain. The requesting router MAY set the prefix-length field ofa Rebind message iftheserver is configured to respond withIA Prefix option as aReply messagehint toa Solicit message containingtheRapid Commit option.server. Replace Section 12.2: Theserver constructsdelegating router behaves as follows when it cannot find aReply message by settingbinding for the"msg-type"requesting router's IA_PD: With: 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 Prefix option is set toREPLY, and copying0, thetransaction ID fromdelegating router MAY assign prefixes to theRebind message intoIA_PD according to the delegating router's explicit configuration information. In this case, when thetransaction-id field. TheserverMUST include a Server Identifier option containingassigns new prefixes to theserver's DUID andIA_PD, theClient Identifier option fromserver MAY use theRebind messagevalue in theReply message. The server includes other options containing configuration information to be returned toprefix-length field of theclientIA Prefix option asdescribed in section 18.2. 4.6.a hint for the length of the prefixes being assigned. The delegating router behaves as follows when it cannot find a binding for the requesting router's IA_PD containing prefixes: 4.5. Confirm Message The Confirm message, as described in [RFC3315], is specific to address assignment. It allows 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. The Confirm message is used by the client to verify that it has not moved to a different link. For IAs with addresses, the mechanism used to verify if a client has moved or not, is by matching the link's on-link prefix(es) (typically a /64) against the prefix-length first bits of the addresses provided by the client in the IA_NA or IA_TA IA-types. As a consequence Confirm can only be used when the client has an IA with address(es) (IA_NA or IA_TA). A client MUST have a binding including an IA with addresses to use the Confirm message. A client with IAs with addresses as well as other IA-types MAY, depending on the IA-type, use the Confirm message to detect if the client has moved to a different link. A client that does not have a binding with an IA with addresses MUST use the Rebind message instead. IA_PD requires verification that the server has the binding for the IAs. In that case a client MUST use the Rebind message in place of the Confirm message and it MUST include all of its bindings, even address IAs.4.7.Note that Section 18.1.2 of RFC 3315 states that a client MUST initiate a Confirm when it may have moved to a new link. This is relaxed to a SHOULD as a client may have determined whether it has or has not moved using other techniques, such as described in [RFC6059]. And, as stated above, a client with delegated prefixes, MUST send a Rebind instead of a Confirm. 4.6. Decline Should Not Necessarily Trigger a Release Someclients willclient implementations have been found to send a Release message for other bindings they may have received after they determine a conflict and have correctly sent a Decline message for the conflicting address(es). It is recommended that a client SHOULD NOT send a Release message for other bindings it may have received just because it sent a Decline message. The client should retain the non-conflicting bindings.4.8.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. 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 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. 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. 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. [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT and INF_MAX_RT", RFC 7083, November 2013. 8.2. Informative References [I-D.dhcwg-dhc-rfc3315bis] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis", draft-dhcwg-dhc-rfc3315bis-01dhcwg-dhc-rfc3315bis-02 (work in progress),MayJuly 2014. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, November 2010. [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, November 2013. [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, May 2014. Authors' Addresses Ole Troan Cisco Systems, Inc. Philip Pedersens vei 20 N-1324 Lysaker Norway Email: ot@cisco.com Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 USA Email: volz@cisco.com Marcin Siodelski ISC 950 Charter Street Redwood City, CA 94063 USA Email: msiodelski@gmail.com