diff options
Diffstat (limited to 'doc/rfc/rfc7550.txt')
| -rw-r--r-- | doc/rfc/rfc7550.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc7550.txt b/doc/rfc/rfc7550.txt new file mode 100644 index 0000000..d9293ab --- /dev/null +++ b/doc/rfc/rfc7550.txt @@ -0,0 +1,1347 @@ + + + + + + +Internet Engineering Task Force (IETF) O. Troan +Request for Comments: 7550 B. Volz +Updates: 3315, 3633 Cisco Systems, Inc. +Category: Standards Track M. Siodelski +ISSN: 2070-1721 ISC + May 2015 + + + Issues and Recommendations with Multiple Stateful DHCPv6 Options + +Abstract + + The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) + specification defined two stateful options, IA_NA and IA_TA, but did + not anticipate the development of additional stateful options. + DHCPv6 Prefix Delegation added the IA_PD option, which is stateful. + Applications that use IA_NA and IA_PD together have revealed issues + that need to be addressed. This document updates RFCs 3315 and 3633 + to address these issues. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7550. + + + + + + + + + + + + + + + + + + +Troan, et al. Standards Track [Page 1] + +RFC 7550 Multiple Stateful Options May 2015 + + +Copyright Notice + + Copyright (c) 2015 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. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Troan, et al. Standards Track [Page 2] + +RFC 7550 Multiple Stateful Options May 2015 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Handling of Multiple IA Option Types . . . . . . . . . . . . 4 + 4.1. Placement of Status Codes in an Advertise Message . . . . 6 + 4.2. Advertise Message Processing by a Client . . . . . . . . 8 + 4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 9 + 4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 10 + 4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 10 + 4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 11 + 4.4.3. Updates to Section 18.1.3 of RFC 3315 . . . . . . . . 11 + 4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 13 + 4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 14 + 4.4.6. Updates to Section 18.2.3 of RFC 3315 . . . . . . . . 16 + 4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 18 + 4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 20 + 4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 21 + 4.6. Decline Should Not Necessarily Trigger a Release . . . . 22 + 4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 22 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 22 + 6.2. Informative References . . . . . . . . . . . . . . . . . 23 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 + +1. Introduction + + DHCPv6 [RFC3315] was written without the expectation that additional + stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation + [RFC3633] since added a new stateful option for Prefix Delegation to + DHCPv6. Implementation experience of the Customer Edge (CE) router + 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 specifies changes + to the DHCPv6 protocol to address these problems. + + The intention of this work is to clarify and, where needed, modify + the DHCPv6 protocol specification to support IA_NA and IA_PD option + types within a single DHCPv6 session. + + + + + + +Troan, et al. Standards Track [Page 3] + +RFC 7550 Multiple Stateful Options May 2015 + + + 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. 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 + [DHCPv6]. + +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: + + 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 option. + + Stateful options: Options that require a dynamic binding state per + client on the server. + + Top-level options: Top-level options are DHCPv6 options that are not + encapsulated within other options, excluding the Relay Message + option. Options encapsulated by Relay Message options, but not by + any other option, are still top-level options, whether they appear + in a relay agent message or a server message; see [RFC7227]. + +4. Handling of Multiple IA Option Types + + The DHCPv6 specification [RFC3315] was written with the assumption + that the only stateful options were for assigning addresses. DHCPv6 + Prefix Delegation [RFC3633] describes how to extend the DHCPv6 + protocol to handle prefix delegation, but does not clearly specify + how the DHCP address assignment and prefix delegation coexist. + + + + + + +Troan, et al. Standards Track [Page 4] + +RFC 7550 Multiple Stateful Options May 2015 + + + 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: + + 1. Reset the state machine and continue to send Solicit messages, + + 2. Create separate DHCP sessions for each IA option type and + continue to Solicit for the unfulfilled IA options, or + + 3. The client could continue with the single session and include the + unfulfilled IA options in subsequent messages to the server. + + Resetting 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 packet storm if + the client does not appropriately rate limit its sending of Solicit + messages or if there are many clients on the network. Client + implementors that follow this approach SHOULD implement the updates + to RFC 3315 specified in [RFC7083]. + + Creating a separate DHCP session (separate instances of the client + state machine) per IA option type, while conceptually simple, causes + a number of issues: additional host resources required to create and + maintain multiple instances of the state machine in clients, + additional DHCP protocol traffic, unnecessary duplication of other + configuration options and the potential for conflict, and divergence + in that each IA option type specification specifies its 'own' version + of the DHCP protocol. + + The single session and state machine allows the client to use the + best configuration it is able to obtain from a single DHCP server + during the configuration exchange. Note, however, that the server + may not be configured to deliver the entire configuration requested + by the client. In that case, the client could continue to operate + only using the configuration received, even if other servers can + provide the missing configuration. In practice, especially in the + case of handling IA_NA and IA_PD, this situation should be rare or a + temporary operational error. So, it is more likely for the client to + get all configuration if it continues, in each subsequent + configuration exchange, to request all the configuration information + it is programmed to try to obtain, including any stateful + configuration options for which no results were returned in previous + exchanges. + + + + + + + + +Troan, et al. Standards Track [Page 5] + +RFC 7550 Multiple Stateful Options May 2015 + + + One major issue of this last approach is that it is difficult to + allow it with the current DHCPv6 specifications; in some cases they + are not clear enough, and in other cases existing restrictions can + make it impossible. This document introduces some clarifications and + small modifications to the current specifications to address these + concerns. + + While all approaches have their own pros and cons, approach number 3 + above SHOULD be used and is the focus of this document because it is + deemed to work best for common cases of the mixed use of IA_NA and + IA_PD. But this document does not exclude other approaches. Also, + in some corner cases it may not be feasible to maintain a single + DHCPv6 session for both IA_NA and IA_PD. These corner cases are + beyond the scope of this document and may depend on the network in + which the client (CE router) is designed to operate and on the + functions the client is required to perform. + + The sections that follow update RFCs 3315 and 3633 to accommodate the + recommendation, though many of the changes are also applicable even + if other approaches are used. + +4.1. Placement of Status Codes in an Advertise Message + + In Reply messages, IA-specific status codes (i.e., NoAddrsAvail, + NotOnLink, NoBinding, and NoPrefixAvail) are encapsulated in the IA + option. In Advertise messages though, the NoAddrsAvail code is + returned at 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 will offer some + prefixes but no addresses, 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). + + + + + + + + +Troan, et al. Standards Track [Page 6] + +RFC 7550 Multiple Stateful Options May 2015 + + + We have chosen the following solution: + + Clients MUST handle each of the following Advertise message formats + when there are no addresses available (even when no other IA option + types were in the Solicit): + + 1. Advertise containing the IA_NAs and/or IA_TAs with an + encapsulated Status Code option of NoAddrsAvail and no top-level + Status Code option. + + 2. Advertise containing just a top-level Status Code option of + NoAddrsAvail and no IA_NAs/IA_TAs. + + 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. + + Note: Clients MUST handle the last two formats listed above to + facilitate backward compatibility with the servers that have not been + updated to this specification. + + See Section 4.2 for updated text for Section 17.1.3 of RFC 3315 and + Section 11.1 of RFC 3633. + + Servers MUST return the Status Code option of NoAddrsAvail + encapsulated in IA_NA/IA_TA options and MUST NOT return a top-level + Status Code option of NoAddrsAvail when no addresses will be assigned + (number 1 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 the following text (which addresses the existing erratum + [Err2472]): + + 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. + + + +Troan, et al. Standards Track [Page 7] + +RFC 7550 Multiple Stateful Options May 2015 + + +4.2. Advertise Message Processing by a Client + + [RFC3315] specifies that a client must ignore an Advertise message if + a server will not assign any addresses to a client, and [RFC3633] + specifies that a client must ignore an Advertise message if a server + returns the NoPrefixAvail status to a requesting router. Thus, a + client requesting both IA_NA and IA_PD, with a server that only + offers either addresses or delegated prefixes, is not supported by + the current protocol specifications. + + 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 when none of the + requested IA options include offered addresses or delegated 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 the following text (which addresses the existing erratum + [Err2471] and 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) and + - MUST process an included INF_MAX_RT option (RFC 7083). + + A client can display any associated status message(s) to the user + or activity log. + + The client ignoring this Advertise message MUST NOT restart the + Solicit retransmission timer. + + + + + + + + + + +Troan, et al. Standards Track [Page 8] + +RFC 7550 Multiple Stateful Options May 2015 + + + 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 set + of IAs, as well as the set of other configuration options + advertised. + + And, replace the last paragraph of Section 11.1 of RFC 3633 with the + following text (which addresses the existing erratum [Err2469]): + + The requesting router 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 requesting router: + + - MUST process an included SOL_MAX_RT option (RFC 7083) and + - MUST process an included INF_MAX_RT option (RFC 7083). + + A client can display any associated status message(s) to the user + or activity log. + + The requesting router ignoring this Advertise message MUST NOT + restart the Solicit retransmission timer. + +4.3. T1/T2 Timers + + The T1 and T2 times 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 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. + + 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, the client MUST + select a T1 and T2 time from all IA options, which will guarantee + + + + +Troan, et al. Standards Track [Page 9] + +RFC 7550 Multiple Stateful Options May 2015 + + + that the client will send Renew/Rebind messages not later than at the + T1/T2 times associated with any of the client's bindings. + + 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 in this document for Sections 18.2.3 and 18.2.4 of RFC + 3315. + + Changes for client T1/T2 handling are included in Sections 4.4.3 and + 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 introduces relevant updates to [RFC3315] and + [RFC3633]. + +4.4.1. Renew Message + + In multiple IA option type models, the client may include multiple IA + options in the Request message, and the server may create bindings + only for a subset of the IA options included by the client. For the + IA options in the Request message for which the server does not + create the bindings, the server sends the IA options in the Reply + message with the NoAddrsAvail or NoPrefixAvail status codes. + + The client may accept the bindings created by the server, but may + desire the other bindings to be created once they become available, + e.g., when the server configuration is changed. The client that + accepted the bindings created by the server will periodically send a + Renew message to extend their lifetimes. However, the Renew message, + + + + + +Troan, et al. Standards Track [Page 10] + +RFC 7550 Multiple Stateful Options May 2015 + + + as described in [RFC3315], does not support the ability for the + client to extend the lifetimes of the bindings for some IAs, while + requesting bindings for other IAs. + + Solution: The client, which sends a Renew message to extend the + lifetimes of the bindings assigned to the client, SHOULD include IA + options for these bindings as well as IA options for all other + bindings that the client desires but has been unable to obtain. 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. + +4.4.2. Rebind Message + + According to Section 4.4.1, the client includes IA options in a Renew + message for the bindings it desires but has been unable to obtain by + sending a Request message, apart from the IA options for the existing + bindings. + + At time T2, the client stops sending Renew messages to the server and + initiates the Rebind/Reply message exchange with any available + server. In this case, it should be possible to continue trying to + obtain new bindings using the Rebind message if the client failed to + get the response from the server to the Renew message. + + Solution: The client SHOULD continue to include the IA options + received from the server, and it MAY include additional IA options to + request creation of the 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 + assigned to an IA, the client sends a Renew message to the server + from which the addresses were obtained, which includes an IA option + for the IA whose address lifetimes are to be extended. The client + includes IA Address options within the IA option for the addresses + assigned to the IA. The server determines new lifetimes for these + addresses according to the administrative configuration of the + server. The server may also add new addresses to the IA. The + server can remove addresses from the IA by returning IA Address + options for such addresses with preferred and valid lifetimes set + to 0. + + 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. However, as the client + + + +Troan, et al. Standards Track [Page 11] + +RFC 7550 Multiple Stateful Options May 2015 + + + 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, 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. + + The client places the identifier of the destination server in a + Server Identifier option. + + The client MUST include a Client Identifier option to identify + itself to the server. The client adds any appropriate options, + including one or more IA options. + + For IAs to which addresses have been assigned, the client includes + a corresponding IA option containing an IA Address option for each + address assigned to the IA. The client MUST NOT include addresses + in any IA option that the client did not obtain from the server or + that are no longer valid (that have a valid lifetime of 0). + + 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 the + "IPv6 address" field set to 0 to indicate the client's preference + for the preferred and valid lifetimes for any 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. + + + + + + + + + +Troan, et al. Standards Track [Page 12] + +RFC 7550 Multiple Stateful Options May 2015 + + + 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 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 (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 section + 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. + + The client 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 client may choose to + include this IA without any addresses (or with only a hint for + lifetimes) in subsequent Rebind messages to indicate that the + client is interested in assignment of the addresses to this IA. + + + +Troan, et al. Standards Track [Page 13] + +RFC 7550 Multiple Stateful Options May 2015 + + + The message exchange is terminated when the valid lifetimes of all + addresses across all IAs have expired, at which time the client + uses the Solicit message to locate a new DHCP server and sends a + Request for the expired IAs to the new server. + +4.4.5. Updates to Section 18.1.8 of RFC 3315 + + Replace Section 18.1.8 of RFC 3315 with the following text: + + Upon the receipt of a valid Reply message in response to a Solicit + (with a Rapid Commit option), Request, Confirm, Renew, Rebind, or + Information-request message, the client extracts the configuration + information contained in the Reply. The client MAY choose to + report any status code or message from the Status Code option in + the Reply message. + + If the client receives a Reply message with a status code + containing UnspecFail, the server is indicating that it was unable + to process the message due to an unspecified failure condition. If + the client retransmits the original message to the same server to + retry the desired operation, the client MUST limit the rate at + which it retransmits the message and limit the duration of the time + during which it retransmits the message. + + When the client receives a Reply message with a Status Code option + with the value UseMulticast, the client records the receipt of the + message and sends subsequent messages to the server through the + interface on which the message was received using multicast. The + client resends the original message using multicast. + + When the client receives a NotOnLink status from the server in + response to a Confirm message, the client performs DHCP server + solicitation, as described in section 17, and client-initiated + configuration, as described in section 18. If the client receives + any Reply messages that do not indicate a NotOnLink status, the + client can use the addresses in the IA and ignore any messages that + indicate a NotOnLink status. + + When the client receives a NotOnLink status from the server in + response to a Request, the client can either reissue the Request + 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 the + previous Reply messages from the server. The client performs the + duplicate address detection before using the received addresses for + + + +Troan, et al. Standards Track [Page 14] + +RFC 7550 Multiple Stateful Options May 2015 + + + 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. + + - 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. + + - Leave unchanged any information about addresses the client has + 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 status code, the client has + received no usable addresses in the IA. + + If the client can operate with the addresses obtained from the + server, the client uses addresses and other information from any + IAs that do not contain a Status Code option with the NoAddrsAvail + status code. The client MAY include the IAs for which it received + the NoAddrsAvail status code, with no addresses, in subsequent + Renew and Rebind messages sent to the server, to retry obtaining + the addresses for these IAs. + + If the client cannot operate without the addresses for the IAs for + which it received the NoAddrsAvail status code, the client may try + another server (perhaps by restarting the DHCP server discovery + process). + + If the client finds no usable addresses in any of the IAs, it may + either try another server (perhaps restarting the DHCP server + discovery process) or use the Information-request message to obtain + other configuration information only. + + + +Troan, et al. Standards Track [Page 15] + +RFC 7550 Multiple Stateful Options May 2015 + + + When the client receives a Reply message in response to a Renew or + Rebind message, the client: + + - sends a Request message if any of the IAs in the Reply message + contains the NoBinding status code. The client places IA + options in this message for only those IAs for which the server + returned the NoBinding status code in the Reply message. The + client continues to use other bindings for which the server did + not return an error. + + - sends a Renew/Rebind if any of the IAs are not in the Reply + message, but in this case the client MUST limit the rate at + which it sends these messages, to avoid the Renew/Rebind storm. + + - 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. + + 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 by the server. + +4.4.6. Updates to Section 18.2.3 of RFC 3315 + + Replace Section 18.2.3 of RFC 3315 with the following text: + + When the server receives a Renew message via unicast from a client + to which the server has 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's DUID, the Client + Identifier option from the client message, and no other options. + + For each IA in the Renew message from a client, the server locates + the client's binding and verifies that the information in the IA + from the client matches the information stored for that client. + + If the server finds the client entry for the IA, the server sends + back the IA to the client with new lifetimes and, if applicable, + T1/T2 times. If the server is unable to extend the lifetimes of an + address in the IA, the server MAY choose not to include the IA + Address option for this address. + + The server may choose to change the list of addresses and the + lifetimes of addresses in IAs that are returned to the client. + + + + +Troan, et al. Standards Track [Page 16] + +RFC 7550 Multiple Stateful Options May 2015 + + + If the server finds that any of the addresses in the IA are not + appropriate for the link to which the client is attached, the + server returns the address to the client with lifetimes of 0. + + For each IA for which the server cannot find a client entry, the + server 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, the server SHOULD create a binding + and return 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 IA Address option + (if included) as a hint. + + - If the server is configured to create new bindings as a result + of processing Renew messages, but the server will not assign any + addresses to an IA, the server returns the IA option containing + a Status Code option with the NoAddrsAvail status code and a + status message for a user. + + - If the server does not support creation of new bindings for the + client sending a Renew message, or if this behavior is disabled + according to the server's policy or configuration information, + the server returns the IA option 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 to REPLY and copying the transaction ID from the Renew + message into the "transaction-id" field. + + The server MUST include a Server Identifier option containing the + server's DUID and the Client Identifier option from the Renew + message in the Reply message. + + The server 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 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. + + + + + + + +Troan, et al. Standards Track [Page 17] + +RFC 7550 Multiple Stateful Options May 2015 + + +4.4.7. Updates to Section 18.2.4 of RFC 3315 + + Replace Section 18.2.4 of RFC 3315 with the following text: + + When the server receives a Rebind 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 that client. + + If the server finds the client entry for the IA and the server + determines that the addresses in the IA are appropriate for the + link to which the client's interface is attached according to the + server's explicit configuration information, the server SHOULD + send back the IA to the client with new lifetimes and, if + applicable, T1/T2 times. If the server is unable to extend the + lifetimes of an address in the IA, the server MAY choose not to + include the IA Address option for this address. + + If the server finds that the client entry for the IA and any of + the addresses are no longer appropriate for the link to which the + client's interface is attached according to the server's explicit + configuration information, the server returns the address to the + client with lifetimes of 0. + + If the server cannot find a client entry for the IA, the IA + contains addresses and the server determines that the addresses in + the IA are not appropriate for the link to which the client's + interface is attached according to the server's explicit + configuration information, the server MAY send a Reply message to + the client containing the client's IA, with the lifetimes for the + addresses in the IA set to 0. This Reply constitutes an explicit + notification to the client that the addresses in the IA are no + longer valid. In this situation, if the server does not send a + Reply message, it silently discards the Rebind message. + + Otherwise, for each IA for which the server cannot find a client + entry, the server 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 Rebind messages (also see the note about the + Rapid Commit option below), the server SHOULD create a binding + and return 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 IA Address option + (if included) as a hint. + + + + + +Troan, et al. Standards Track [Page 18] + +RFC 7550 Multiple Stateful Options May 2015 + + + - If the server is configured to create new bindings as a result + of processing Rebind messages, but the server will not assign + any addresses to an IA, the server returns the IA option + containing a Status Code option with the NoAddrsAvail status + code and a status message for a user. + + - If the server does not support creation of new bindings for the + client sending a Rebind message, or if this behavior is + disabled according to the server's policy or configuration + information, the server returns the IA option containing a + Status Code option with the NoBinding status code and a status + message for a user. + + When the server creates new bindings for the IA, it is possible + that other servers also create bindings as a result of receiving + the same Rebind message. This is the same issue as in the + Discussion under "Rapid Commit Option"; see section 22.14. + Therefore, the server SHOULD only create new bindings during + processing of a Rebind message if the server is configured to + respond with a Reply message to a Solicit message containing the + Rapid Commit option. + + The server constructs a Reply message by setting the "msg-type" + field to REPLY and copying the transaction ID from the Rebind + message into the "transaction-id" field. + + The server MUST include a Server Identifier option containing the + server's DUID and the Client Identifier option from the Rebind + message in the Reply message. + + The server 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 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. + + + + + + + + + + + + +Troan, et al. Standards Track [Page 19] + +RFC 7550 Multiple Stateful Options May 2015 + + +4.4.8. Updates to RFC 3633 + + Replace the following text in Section 12.1 of RFC 3633: + + Each prefix has valid and preferred lifetimes whose durations are + specified in the IA_PD Prefix option for that prefix. The + requesting router uses Renew and Rebind messages to request the + extension of the lifetimes of a delegated prefix. + + With: + + Each prefix has valid and preferred lifetimes whose durations are + specified in the IA_PD Prefix option for that prefix. The + requesting router uses Renew and Rebind messages to request the + extension of the lifetimes of a delegated prefix. + + The requesting router MAY include IA_PD options without any + prefixes, i.e., without an IA Prefix option or with the IPv6 + prefix field of the IA Prefix option set to 0, in a Renew or + Rebind message to obtain bindings it desires but has been unable + to obtain. The requesting router MAY set the "prefix-length" + field of the IA Prefix option as a hint to the server. As in + [RFC3315], the requesting router MAY also provide lifetime hints + in the IA Prefix option. + + Replace the following text in Section 12.2 of RFC 3633: + + The delegating router behaves as follows when it cannot find a + binding for the requesting router's IA_PD: + + With: + + For the Renew or Rebind, if the IA_PD contains no IA Prefix option + or it contains an IA Prefix option with the IPv6 prefix field set + to 0, the delegating router SHOULD assign prefixes to the IA_PD + according to the delegating router's explicit configuration + information. In this case, if the IA_PD contains an IA Prefix + option with the IPv6 prefix field set to 0, the delegating router + MAY use the value in the "prefix-length" field of the IA Prefix + option as a hint for the length of the prefixes to be assigned. + The delegating router MAY also respect lifetime hints provided by + the requesting router in the IA Prefix option. + + The delegating router behaves as follows when it cannot find a + binding for the requesting router's IA_PD containing prefixes: + + + + + + +Troan, et al. Standards Track [Page 20] + +RFC 7550 Multiple Stateful Options May 2015 + + +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 has a 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 an 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 delegating router (server) has + the binding for the IAs. In that case, a requesting router (client) + MUST use the Rebind message in place of the Confirm message and it + MUST include all of its bindings, even address IAs. + + 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. + + + + + + + + +Troan, et al. Standards Track [Page 21] + +RFC 7550 Multiple Stateful Options May 2015 + + +4.6. Decline Should Not Necessarily Trigger a Release + + Some client 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). + + 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. The client SHOULD treat + the failure to acquire a binding as a result of the conflict, to be + equivalent to not having received the binding, insofar as it behaves + when sending Renew and Rebind messages. + +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 (see [MPVD-ARCH] and + [DHCPv6-SUPPORT]). + +5. Security Considerations + + There are no new security considerations pertaining to this document. + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July + 2003, <http://www.rfc-editor.org/info/rfc3315>. + + + + + + +Troan, et al. Standards Track [Page 22] + +RFC 7550 Multiple Stateful Options May 2015 + + + [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic + Host Configuration Protocol (DHCP) version 6", RFC 3633, + DOI 10.17487/RFC3633, December 2003, + <http://www.rfc-editor.org/info/rfc3633>. + + [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT + and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November + 2013, <http://www.rfc-editor.org/info/rfc7083>. + +6.2. Informative References + + [DHCPv6] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., + Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host + Configuration Protocol for IPv6 (DHCPv6) bis", Work in + Progress, draft-ietf-dhc-rfc3315bis-00, March 2015. + + [DHCPv6-SUPPORT] + Krishnan, S., Korhonen, J., and S. Bhandari, "Support for + multiple provisioning domains in DHCPv6", Work in + Progress, draft-ietf-mif-mpvd-dhcp-support-01, March 2015. + + [Err2469] RFC Errata, Errata ID 2469, RFC 3633, + <http://www.rfc-editor.org>. + + [Err2471] RFC Errata, Errata ID 2471, RFC 3315, + <http://www.rfc-editor.org>. + + [Err2472] RFC Errata, Errata ID 2472, RFC 3315, + <http://www.rfc-editor.org>. + + [MPVD-ARCH] + Anipko, D., "Multiple Provisioning Domain Architecture", + Work in Progress, draft-ietf-mif-mpvd-arch-11, March 2015. + + [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for + Detecting Network Attachment in IPv6", RFC 6059, + DOI 10.17487/RFC6059, November 2010, + <http://www.rfc-editor.org/info/rfc6059>. + + [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic + Requirements for IPv6 Customer Edge Routers", RFC 7084, + DOI 10.17487/RFC7084, November 2013, + <http://www.rfc-editor.org/info/rfc7084>. + + [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and + S. Krishnan, "Guidelines for Creating New DHCPv6 Options", + BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, + <http://www.rfc-editor.org/info/rfc7227>. + + + +Troan, et al. Standards Track [Page 23] + +RFC 7550 Multiple Stateful Options May 2015 + + +Acknowledgements + + Thanks to the many people that contributed to identify the stateful + issues addressed by this document and for reviewing drafts of this + document, including Ralph Droms, John Brzozowski, Ted Lemon, Hemant + Singh, Wes Beebee, Gaurau Halwasia, Bud Millword, Tim Winters, Rob + Shakir, Jinmei Tatuya, Andrew Yourtchenko, Fred Templin, Tomek + Mrugalski, Suresh Krishnan, and Ian Farrer. + +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 + United States + + EMail: volz@cisco.com + + + Marcin Siodelski + ISC + 950 Charter Street + Redwood City, CA 94063 + United States + + EMail: msiodelski@gmail.com + + + + + + + + + + + + + + + +Troan, et al. Standards Track [Page 24] + |