12.  Identity Association

   An Identity Association (IA) is a construct through which a server
   and a client can identify, group, and manage a set of related IPv6
   addresses or delegated prefixes.  Each IA consists of an IAID and
   associated configuration information.

   The IAID uniquely identifies the IA and MUST be chosen to be unique
   among the IAIDs for that IA type on the client (e.g., an IA_NA with
   an IAID of 0 and an IA_PD with an IAID of 0 are each considered
   unique).  The IAID is chosen by the client.  For any given use of an
   IA by the client, the IAID for that IA MUST be consistent across
   restarts of the DHCP client.  The client may maintain consistency by
   either storing the IAID in non-volatile storage or using an algorithm
   that will consistently produce the same IAID as long as the
   configuration of the client has not changed.  There may be no way for
   a client to maintain consistency of the IAIDs if it does not have
   non-volatile storage and the client's hardware configuration changes.
   If the client uses only one IAID, it can use a well-known value,
   e.g., zero.

   If the client wishes to obtain a distinctly new address or prefix and
   deprecate the existing one, the client sends a Release message to the
   server for the IAs using the original IAID.  The client then creates
   a new IAID, to be used in future messages to obtain leases for the
   new IA.

12.1.  Identity Associations for Address Assignment

   A client must associate at least one distinct IA with each of its
   network interfaces for which it is to request the assignment of IPv6
   addresses from a DHCP server.  The client uses the IAs assigned to an
   interface to obtain configuration information from a server for that
   interface.  Each such IA must be associated with exactly one
   interface.

   The configuration information in an IA_NA option consists of one or
   more IPv6 addresses along with the T1 and T2 values for the IA.  See
   Section 21.4 for details regarding the representation of an IA_NA in
   a DHCP message.

   The configuration information in an IA_TA option consists of one or
   more IPv6 addresses.  See Section 21.5 for details regarding the
   representation of an IA_TA in a DHCP message.

   Each address in an IA has a preferred lifetime and a valid lifetime,
   as defined in [RFC4862].  The lifetimes are transmitted from the DHCP
   server to the client in the IA Address option (see Section 21.6).
   The lifetimes apply to the use of addresses; see Section 5.5.4 of
   [RFC4862].

12.2.  Identity Associations for Prefix Delegation

   An IA_PD is different from an IA for address assignment in that it
   does not need to be associated with exactly one interface.  One IA_PD
   can be associated with the client, with a set of interfaces, or with
   exactly one interface.  A client configured to request delegated
   prefixes must create at least one distinct IA_PD.  It may associate a
   distinct IA_PD with each of its downstream network interfaces and use
   that IA_PD to obtain a prefix for that interface from the server.

   The configuration information in an IA_PD option consists of one or
   more prefixes along with the T1 and T2 values for the IA_PD.  See
   Section 21.21 for details regarding the representation of an IA_PD in
   a DHCP message.

   Each delegated prefix in an IA has a preferred lifetime and a valid
   lifetime, as defined in [RFC4862].  The lifetimes are transmitted
   from the DHCP server to the client in the IA Prefix option (see
   Section 21.22).  The lifetimes apply to the use of delegated
   prefixes; see Section 5.5.4 of [RFC4862].

13.  Assignment to an IA

13.1.  Selecting Addresses for Assignment to an IA_NA

   A server selects addresses to be assigned to an IA_NA according to
   the address assignment policies determined by the server
   administrator and the specific information the server determines
   about the client from some combination of the following sources:

   -  The link to which the client is attached.  The server determines
      the link as follows:

      *  If the server receives the message directly from the client and
         the source address in the IP datagram in which the message was
         received is a link-local address, then the client is on the
         same link to which the interface over which the message was
         received is attached.

      *  If the server receives the message from a forwarding relay
         agent, then the client is on the same link as the one to which
         the interface, identified by the link-address field in the
         message from the relay agent, is attached.  According to
         [RFC6221], the server MUST ignore any link-address field whose
         value is zero.  The link-address in this case may come from any
         of the Relay-forward messages encapsulated in the received
         Relay-forward, and in general the most encapsulated (closest
         Relay-forward to the client) has the most useful value.

      *  If the server receives the message directly from the client and
         the source address in the IP datagram in which the message was
         received is not a link-local address, then the client is on the
         link identified by the source address in the IP datagram (note
         that this situation can occur only if the server has enabled
         the use of unicast message delivery by the client and the
         client has sent a message for which unicast delivery is
         allowed).

   -  The DUID supplied by the client.

   -  Other information in options supplied by the client, e.g., IA
      Address options (see Section 21.6) that include the client's
      requests for specific addresses.

   -  Other information in options supplied by the relay agent.

   By default, DHCP server implementations SHOULD NOT generate
   predictable addresses (see Section 4.7 of [RFC7721]).  Server
   implementers are encouraged to review [RFC4941], [RFC7824], and
   [RFC7707] as to possible considerations for how to generate
   addresses.

   A server MUST NOT assign an address that is otherwise reserved for
   some other purpose.  For example, a server MUST NOT assign addresses
   that use a reserved IPv6 Interface Identifier [RFC5453] [RFC7136]
   [IANA-RESERVED-IID].

   See [RFC7969] for a more detailed discussion on how servers determine
   a client's location on the network.

13.2.  Assignment of Temporary Addresses

   A client may request the assignment of temporary addresses (see
   [RFC4941] for the definition of temporary addresses).  DHCP handling
   of address assignment is no different for temporary addresses.

   Clients ask for temporary addresses, and servers assign them.
   Temporary addresses are carried in the IA_TA option (see
   Section 21.5).  Each IA_TA option typically contains at least one
   temporary address for each of the prefixes on the link to which the
   client is attached.

   The lifetime of the assigned temporary address is set in the IA
   Address option (see Section 21.6) encapsulated in the IA_TA option.
   It is RECOMMENDED to set short lifetimes, typically shorter than
   TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME (see Section 5 of
   [RFC4941]).

   A DHCP server implementation MAY generate temporary addresses,
   referring to the algorithm defined in Section 3.2.1 of [RFC4941],
   with the additional condition that any new address is not the same as
   any assigned address.

   The server MAY update the DNS for a temporary address, as described
   in Section 4 of [RFC4941].

   On the clients, by default, temporary addresses are preferred in
   source address selection, according to Rule 7 in Section 5 of
   [RFC6724].  However, this policy can be overridden.

   One of the most important properties of a temporary address is to
   make it difficult to link the address to different actions over time.
   So, it is NOT RECOMMENDED for a client to renew temporary addresses,
   though DHCP provides for such a possibility (see Section 21.5).

13.3.  Assignment of Prefixes for IA_PD

   The mechanism through which the server selects prefix(es) for
   delegation is not specified in this document.  Examples of ways in
   which the server might select prefix(es) for a client include static
   assignment based on subscription to an ISP, dynamic assignment from a
   pool of available prefixes, and selection based on an external
   authority such as a RADIUS server using the Framed-IPv6-Prefix option
   as described in [RFC3162].

14.  Transmission of Messages by a Client

   Unless otherwise specified in this document or in a document that
   describes how IPv6 is carried over a specific type of link (for link
   types that do not support multicast), a client sends DHCP messages to
   the All_DHCP_Relay_Agents_and_Servers multicast address.

   DHCP servers SHOULD NOT check to see whether the Layer 2 address used
   was multicast or not, as long as the Layer 3 address was correct.

   A client uses multicast to reach all servers or an individual server.
   An individual server is indicated by specifying that server's DUID in
   a Server Identifier option (see Section 21.3) in the client's
   message.  (All servers will receive this message, but only the
   indicated server will respond.)  All servers are indicated when this
   option is not supplied.

   A client may send some messages directly to a server using unicast,
   as described in Section 21.12.

14.1.  Rate Limiting

   In order to avoid prolonged message bursts that may be caused by
   possible logic loops, a DHCP client MUST limit the rate of DHCP
   messages it transmits or retransmits.  One example is that a client
   obtains an address or delegated prefix but does not like the
   response, so it reverts back to the Solicit procedure, discovers the
   same (sole) server, requests an address or delegated prefix, and gets
   the same address or delegated prefix as before (as the server has

   this previously requested lease assigned to this client).  This loop
   can repeat infinitely if there is not a quit/stop mechanism.
   Therefore, a client must not initiate transmissions too frequently.

   A recommended method for implementing the rate-limiting function is a
   token bucket (see Appendix A of [RFC3290]), limiting the average rate
   of transmission to a certain number in a certain time interval.  This
   method of bounding burstiness also guarantees that the long-term
   transmission rate will not be exceeded.

   A transmission rate limit SHOULD be configurable.  A possible default
   could be 20 packets in 20 seconds.

   For a device that has multiple interfaces, the limit MUST be enforced
   on a per-interface basis.

   Rate limiting of forwarded DHCP messages and server-side messages is
   out of scope for this specification.

14.2.  Client Behavior when T1 and/or T2 Are 0

   In certain cases, T1 and/or T2 values may be set to 0.  Currently,
   there are three such cases:

   1.  a client received an IA_NA option (see Section 21.4) with a zero
       value

   2.  a client received an IA_PD option (see Section 21.21) with a zero
       value

   3.  a client received an IA_TA option (see Section 21.5) (which does
       not contain T1 and T2 fields and these leases are not generally
       renewed)

   This is an indication that the renew and rebind times are left to the
   discretion of the client.  However, they are not completely
   discretionary.

   When T1 and/or T2 values are set to 0, the client MUST choose a time
   to avoid packet storms.  In particular, it MUST NOT transmit
   immediately.  If the client received multiple IA options, it SHOULD
   pick renew and/or rebind transmission times so all IA options are
   handled in one exchange, if possible.  The client MUST choose renew
   and rebind times to not violate rate-limiting restrictions as defined
   in Section 14.1.

15.  Reliability of Client-Initiated Message Exchanges

   DHCP clients are responsible for reliable delivery of messages in the
   client-initiated message exchanges described in Section 18.  If a
   DHCP client fails to receive an expected response from a server, the
   client must retransmit its message according to the retransmission
   strategy described in this section.

   Note that the procedure described in this section is slightly
   modified when used with the Solicit message.  The modified procedure
   is described in Section 18.2.1.

   The client begins the message exchange by transmitting a message to
   the server.  The message exchange terminates when either (1) the
   client successfully receives the appropriate response or responses
   from a server or servers or (2) the message exchange is considered to
   have failed according to the retransmission mechanism described
   below.

   The client MUST update an "elapsed-time" value within an Elapsed Time
   option (see Section 21.9) in the retransmitted message.  In some
   cases, the client may also need to modify values in IA Address
   options (see Section 21.6) or IA Prefix options (see Section 21.22)
   if a valid lifetime for any of the client's leases expires before
   retransmission.  Thus, whenever this document refers to a
   "retransmission" of a client's message, it refers to both modifying
   the original message and sending this new message instance to the
   server.

   The client retransmission behavior is controlled and described by the
   following variables:

      RT      Retransmission timeout

      IRT     Initial retransmission time

      MRC     Maximum retransmission count

      MRT     Maximum retransmission time

      MRD     Maximum retransmission duration

      RAND    Randomization factor

   Specific values for each of these parameters relevant to the various
   messages are given in the subsections of Section 18.2, using values
   defined in Table 1 in Section 7.6.  The algorithm for RAND is common
   across all message transmissions.

   With each message transmission or retransmission, the client sets RT
   according to the rules given below.  If RT expires before the message
   exchange terminates, the client recomputes RT and retransmits the
   message.

   Each of the computations of a new RT includes a randomization factor
   (RAND), which is a random number chosen with a uniform distribution
   between -0.1 and +0.1.  The randomization factor is included to
   minimize synchronization of messages transmitted by DHCP clients.

   The algorithm for choosing a random number does not need to be
   cryptographically sound.  The algorithm SHOULD produce a different
   sequence of random numbers from each invocation of the DHCP client.

   RT for the first message transmission is based on IRT:

      RT = IRT + RAND*IRT

   RT for each subsequent message transmission is based on the previous
   value of RT:

      RT = 2*RTprev + RAND*RTprev

   MRT specifies an upper bound on the value of RT (disregarding the
   randomization added by the use of RAND).  If MRT has a value of 0,
   there is no upper limit on the value of RT.  Otherwise:

      if (RT > MRT)
         RT = MRT + RAND*MRT

   MRC specifies an upper bound on the number of times a client may
   retransmit a message.  Unless MRC is zero, the message exchange fails
   once the client has transmitted the message MRC times.

   MRD specifies an upper bound on the length of time a client may
   retransmit a message.  Unless MRD is zero, the message exchange fails
   once MRD seconds have elapsed since the client first transmitted the
   message.

   If both MRC and MRD are non-zero, the message exchange fails whenever
   either of the conditions specified in the previous two paragraphs
   is met.

   If both MRC and MRD are zero, the client continues to transmit the
   message until it receives a response.

   A client is not expected to listen for a response during the entire
   RT period and may turn off listening capabilities after waiting at
   least the shorter of RT and MAX_WAIT_TIME due to power consumption
   saving or other reasons.  Of course, a client MUST listen for a
   Reconfigure if it has negotiated for its use with the server.

16.  Message Validation

   This section describes which options are valid in which kinds of
   message types and explains what to do when a client or server
   receives a message that contains known options that are invalid for
   that message.  For example, an IA option is not allowed to appear in
   an Information-request message.

   Clients and servers MAY choose to either (1) extract information from
   such a message if the information is of use to the recipient or
   (2) ignore such a message completely and just discard it.

   If a server receives a message that it considers invalid, it MAY send
   a Reply message (or Advertise message, as appropriate) with a Server
   Identifier option (see Section 21.3), a Client Identifier option (see
   Section 21.2) (if one was included in the message), and a Status Code
   option (see Section 21.13) with status UnspecFail.

   Clients, relay agents, and servers MUST NOT discard messages that
   contain unknown options (or instances of vendor options with unknown
   enterprise-number values).  These should be ignored as if they were
   not present.  This is critical to provide for future extensions of
   DHCP.

   A server MUST discard any Solicit, Confirm, Rebind, or
   Information-request messages it receives with a Layer 3 unicast
   destination address.

   A client or server MUST discard any received DHCP messages with an
   unknown message type.

16.1.  Use of Transaction IDs

   The "transaction-id" field holds a value used by clients and servers
   to synchronize server responses to client messages.  A client SHOULD
   generate a random number that cannot easily be guessed or predicted
   to use as the transaction ID for each new message it sends.  Note
   that if a client generates easily predictable transaction
   identifiers, it may become more vulnerable to certain kinds of
   attacks from off-path intruders.  A client MUST leave the transaction
   ID unchanged in retransmissions of a message.

16.2.  Solicit Message

   Clients MUST discard any received Solicit messages.

   Servers MUST discard any Solicit messages that do not include a
   Client Identifier option or that do include a Server Identifier
   option.

16.3.  Advertise Message

   Clients MUST discard any received Advertise message that meets any of
   the following conditions:

   -  the message does not include a Server Identifier option (see
      Section 21.3).

   -  the message does not include a Client Identifier option (see
      Section 21.2).

   -  the contents of the Client Identifier option do not match the
      client's DUID.

   -  the "transaction-id" field value does not match the value the
      client used in its Solicit message.

   Servers and relay agents MUST discard any received Advertise
   messages.

16.4.  Request Message

   Clients MUST discard any received Request messages.

   Servers MUST discard any received Request message that meets any of
   the following conditions:

   -  the message does not include a Server Identifier option (see
      Section 21.3).

   -  the contents of the Server Identifier option do not match the
      server's DUID.

   -  the message does not include a Client Identifier option (see
      Section 21.2).

16.5.  Confirm Message

   Clients MUST discard any received Confirm messages.

   Servers MUST discard any received Confirm messages that do not
   include a Client Identifier option (see Section 21.2) or that do
   include a Server Identifier option (see Section 21.3).

16.6.  Renew Message

   Clients MUST discard any received Renew messages.

   Servers MUST discard any received Renew message that meets any of the
   following conditions:

   -  the message does not include a Server Identifier option (see
      Section 21.3).

   -  the contents of the Server Identifier option do not match the
      server's identifier.

   -  the message does not include a Client Identifier option (see
      Section 21.2).

16.7.  Rebind Message

   Clients MUST discard any received Rebind messages.

   Servers MUST discard any received Rebind messages that do not include
   a Client Identifier option (see Section 21.2) or that do include a
   Server Identifier option (see Section 21.3).

16.8.  Decline Message

   Clients MUST discard any received Decline messages.

   Servers MUST discard any received Decline message that meets any of
   the following conditions:

   -  the message does not include a Server Identifier option (see
      Section 21.3).

   -  the contents of the Server Identifier option do not match the
      server's identifier.

   -  the message does not include a Client Identifier option (see
      Section 21.2).

16.9.  Release Message

   Clients MUST discard any received Release messages.

   Servers MUST discard any received Release message that meets any of
   the following conditions:

   -  the message does not include a Server Identifier option (see
      Section 21.3).

   -  the contents of the Server Identifier option do not match the
      server's identifier.

   -  the message does not include a Client Identifier option (see
      Section 21.2).

16.10.  Reply Message

   Clients MUST discard any received Reply message that meets any of the
   following conditions:

   -  the message does not include a Server Identifier option (see
      Section 21.3).

   -  the "transaction-id" field in the message does not match the value
      used in the original message.

   If the client included a Client Identifier option (see Section 21.2)
   in the original message, the Reply message MUST include a Client
   Identifier option, and the contents of the Client Identifier option
   MUST match the DUID of the client.  If the client did not include a
   Client Identifier option in the original message, the Reply message
   MUST NOT include a Client Identifier option.

   Servers and relay agents MUST discard any received Reply messages.

16.11.  Reconfigure Message

   Servers and relay agents MUST discard any received Reconfigure
   messages.

   Clients MUST discard any Reconfigure message that meets any of the
   following conditions:

   -  the message was not unicast to the client.

   -  the message does not include a Server Identifier option (see
      Section 21.3).

   -  the message does not include a Client Identifier option (see
      Section 21.2) that contains the client's DUID.

   -  the message does not include a Reconfigure Message option (see
      Section 21.19).

   -  the Reconfigure Message option msg-type is not a valid value.

   -  the message does not include authentication (such as RKAP; see
      Section 20.4) or fails authentication validation.

16.12.  Information-request Message

   Clients MUST discard any received Information-request messages.

   Servers MUST discard any received Information-request message that
   meets any of the following conditions:

   -  the message includes a Server Identifier option (see
      Section 21.3), and the DUID in the option does not match the
      server's DUID.

   -  the message includes an IA option.

16.13.  Relay-forward Message

   Clients MUST discard any received Relay-forward messages.

16.14.  Relay-reply Message

   Clients and servers MUST discard any received Relay-reply messages.

17.  Client Source Address and Interface Selection

   The client's behavior regarding interface selection is different,
   depending on the purpose of the configuration.

17.1.  Source Address and Interface Selection for Address Assignment

   When a client sends a DHCP message to the
   All_DHCP_Relay_Agents_and_Servers multicast address, it SHOULD send
   the message through the interface for which configuration information
   (including the addresses) is being requested.  However, the client
   MAY send the message through another interface if the interface for
   which configuration is being requested is a logical interface without
   direct link attachment or the client is certain that two interfaces
   are attached to the same link.

   When a client sends a DHCP message directly to a server using unicast
   (after receiving the Server Unicast option (see Section 21.12) from
   that server), the source address in the header of the IPv6 datagram
   MUST be an address assigned to the interface for which the client is
   interested in obtaining configuration and that is suitable for use by
   the server in responding to the client.

17.2.  Source Address and Interface Selection for Prefix Delegation

   Delegated prefixes are not associated with a particular interface in
   the same way as addresses are for address assignment as mentioned in
   Section 17.1 above.

   When a client sends a DHCP message for the purpose of prefix
   delegation, it SHOULD be sent on the interface associated with the
   upstream router (typically, connected to an ISP network); see
   [RFC7084].  The upstream interface is typically determined by
   configuration.  This rule applies even in the case where a separate
   IA_PD is used for each downstream interface.

   When a client sends a DHCP message directly to a server using unicast
   (after receiving the Server Unicast option (see Section 21.12) from
   that server), the source address SHOULD be an address that is from
   the upstream interface and that is suitable for use by the server in
   responding to the client.