Issues and Recommendations with Multiple Stateful DHCPv6 Options
RFC 7550

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]