tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 8156

 
 
 

DHCPv6 Failover Protocol

Part 3 of 5, p. 40 to 65
Prev Section       Next Section

 


prevText      Top      ToC       Page 40 
6.  Connection Management

   Communication between failover partners takes place over a long-lived
   TCP connection.  This connection is always initiated by the primary
   server, and if the long-lived connection is lost it is the
   responsibility of the primary server to attempt to reconnect to the
   secondary server.  The detailed process used by the primary server
   when initiating a connection and by the secondary server when
   responding to a connection attempt as documented in Section 6.1 is
   followed each time a connection is established, regardless of any
   previous connection between the failover partners.

6.1.  Creating Connections

   Every primary server implementing the failover protocol MUST
   periodically attempt to create a TCP connection to the dhcp-failover
   port (647) of all of its configured partners, where the period is
   implementation dependent and SHOULD be configurable.  In the event
   that a connection has been rejected by a CONNECTREPLY message with an
   OPTION_STATUS_CODE option contained in it or a DISCONNECT message, a
   server SHOULD reduce the frequency with which it attempts to connect
   to that server, but it MUST continue to attempt to connect
   periodically.

   Every secondary server implementing the failover protocol MUST listen
   for TCP connection attempts on the dhcp-failover port (647) from a
   primary server.

   After a primary server successfully establishes a TCP connection to a
   secondary server, it MUST continue the connection process as
   described in Section 8.2 of [RFC7653].  In the language of that
   section, the primary failover server operates as the "requestor" and
   the secondary failover server operates as the "DHCP server".  The
   message that is sent over the newly established connection is a
   CONNECT message, instead of an ACTIVELEASEQUERY message.

   When a secondary server receives a connection attempt, the only
   information that the secondary server has is the IP address of the
   partner initiating a connection.  If it has any relationships with
   the connecting server for which it is a secondary server, it should

Top      Up      ToC       Page 41 
   operate as described in Section 9.1 of [RFC7653], with the exception
   that instead of waiting for an Active Leasequery message it will wait
   for a CONNECT message.  Once it has received the CONNECT message, it
   will use the information in that message to determine which
   relationship this connection is to service.

   If it has no secondary relationships with the connecting server, it
   MUST drop the connection.

   To summarize -- a primary server MUST use a connection that it has
   initiated in order to send a CONNECT message.  Every server that is a
   secondary server in a relationship MUST listen for CONNECT messages
   from the primary server.

   When the CONNECT and CONNECTREPLY exchange successfully produces a
   working failover connection, the next message sent over a new
   connection is a STATE message.  See Section 6.3.  Upon the receipt of
   the STATE message, the receiver can consider communications "OK".

6.1.1.  Sending a CONNECT Message

   The CONNECT message is sent with information about the failover
   configuration on the primary server.  The message MUST contain at
   least the following information in the options area:

   o  OPTION_F_PROTOCOL_VERSION containing the protocol version that the
      primary server will use when sending failover messages.

   o  OPTION_F_MCLT containing the configured MCLT.

   o  OPTION_F_KEEPALIVE_TIME containing the number of seconds (an
      interval) within which the server must receive a message from its
      partner, or it will assume that communications from the partner
      are not "OK".

   o  OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of
      BNDUPD messages that this server is prepared to accept over the
      failover connection without causing the connection to block.  This
      implements application-level flow control over the connection, so
      that a flood of BNDUPD messages does not cause the connection to
      block and thereby prevent other messages from being transmitted
      over the connection and received by the failover partner.

Top      Up      ToC       Page 42 
   o  OPTION_F_RELATIONSHIP_NAME containing the name of the failover
      relationship to which this connection applies.  If there is no
      OPTION_F_RELATIONSHIP_NAME in the CONNECT message, it indicates
      that there is only a single relationship between this pair of
      primary and secondary servers.

   o  OPTION_F_CONNECT_FLAGS containing information about certain
      attributes of the connecting servers.

6.1.2.  Receiving a CONNECT Message

   A server receiving a CONNECT message must process the information in
   the message and decide whether or not to accept the connection.  The
   processing is performed as follows:

   o  sent-time - The secondary server checks the sent-time to see if it
      is within 5 seconds of its current time.  See Section 7.1.  If it
      is not, return ExcessiveTimeSkew in the OPTION_STATUS_CODE to
      reject the CONNECT message.

   o  OPTION_F_PROTOCOL_VERSION - The secondary server decides if the
      protocol version of the primary server is supported by the
      secondary server.  If it is not, return NotSupported in the
      OPTION_STATUS_CODE to reject the CONNECT message.

   o  OPTION_F_MCLT - Use this MCLT supplied by the primary server.
      Remember this MCLT, and use it until a different MCLT is supplied
      by some subsequent CONNECT message.

   o  OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the
      FO_KEEPALIVE_TIME (Section 6.5) when implementing the
      Unreachability Detection algorithm described in Section 6.6.

   o  OPTION_F_MAX_UNACKED_BNDUPD - Ensure that the maximum amount of
      unacked BNDUPD messages queued to the primary server never exceeds
      the value in the OPTION_F_MAX_UNACKED_BNDUPD option.

   o  OPTION_F_CONNECT_FLAGS - Ensure that the secondary server can
      process information from the primary server as specified in the
      flags.  For example, if the secondary server cannot process prefix
      delegation with variable-sized prefixes delegated from the same
      delegable prefix and the primary server says that it can, the
      secondary should reject the connection.

Top      Up      ToC       Page 43 
   A CONNECT message SHOULD always be followed by a CONNECTREPLY
   message, to either (1) accept the connection or (2) reject the
   connection by including an OPTION_STATUS_CODE option with a
   status-code indicating the reason for the rejection.  If accepting
   the connection attempt, then send a CONNECTREPLY message with the
   following information:

   o  OPTION_F_PROTOCOL_VERSION containing the protocol version being
      used by the secondary server when sending failover messages.

   o  OPTION_F_MCLT containing the MCLT currently in use on the
      secondary server.  This MUST equal the MCLT that was in the
      OPTION_F_MCLT option in the CONNECT message.

   o  OPTION_F_KEEPALIVE_TIME containing the number of seconds (an
      interval) within which the server must receive a message from its
      partner, or it will assume that communications from the partner
      are not "OK".

   o  OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of
      BNDUPD messages that this server is prepared to accept over the
      failover connection without causing the connection to block.  This
      implements application-level flow control over the connection, so
      that a flood of BNDUPD messages does not cause the connection to
      block and thereby prevent other messages from being transmitted
      over the connection and received by the failover partner.

   o  OPTION_F_CONNECT_FLAGS containing information describing the
      attributes of the secondary server that the primary needs to
      know about.

   After sending a CONNECTREPLY message to accept the primary server's
   CONNECT message, the secondary server MUST send a STATE message (see
   Section 6.3).

6.1.3.  Receiving a CONNECTREPLY Message

   A server receiving a CONNECTREPLY message must process the
   information in the message and decide whether or not to continue to
   employ the connection.  The processing is performed as follows:

   o  OPTION_F_PROTOCOL_VERSION - The primary server decides if the
      protocol version in use by the secondary server is supported by
      the primary server.  If it is not, send a DISCONNECT message and
      drop the connection.  If it is supported, continue processing.  It
      is possible that the primary and secondary servers will each be
      sending different versions of the protocol to the other server.

Top      Up      ToC       Page 44 
      The extent to which this is supported will be defined partly by
      as-yet-unknown differences in the protocols that the versions
      represent and partly by the capabilities of the two
      implementations involved in the failover relationship.

   o  OPTION_F_MCLT - Compare the MCLT received with the configured
      MCLT.  If they are different, send a DISCONNECT message and drop
      the connection.

   o  OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the
      FO_KEEPALIVE_TIME (Section 6.5) when implementing the
      Unreachability Detection algorithm described in Section 6.6.

   o  OPTION_F_MAX_UNACKED_BNDUPD - Ensure that the maximum amount of
      unacked BNDUPD messages queued to the secondary server never
      exceeds the value in the OPTION_F_MAX_UNACKED_BNDUPD option.

   o  OPTION_F_CONNECT_FLAGS - Ensure that the primary server can
      process information from the secondary server as specified in the
      flags.  For example, if the primary server cannot process prefix
      delegation with variable-sized prefixes delegated from the same
      delegable prefix and the secondary server says that it can, the
      primary should drop the connection.

   After receiving a CONNECTREPLY message that accepted the primary
   server's CONNECT message, the primary server MUST send a STATE
   message (see Section 6.3).

6.2.  Endpoint Identification

   A failover endpoint is always associated with a set of DHCP prefixes
   that are configured on the DHCP server where the endpoint appears.  A
   DHCP prefix MUST NOT be associated with more than one failover
   endpoint.

   The failover protocol SHOULD be configured with one failover
   relationship between each pair of failover servers.  In this case,
   there is one failover endpoint for that relationship on each failover
   partner.  This failover relationship MUST have a unique name.

   Any failover endpoint can take actions and hold unique states.

   This document frequently describes the behavior of the failover
   protocol in terms of primary and secondary servers, not primary and
   secondary failover endpoints.  However, it is important to remember
   that every "server" described in this document is in reality a
   failover endpoint that resides in a particular process and that
   several failover endpoints may reside in the same server process.

Top      Up      ToC       Page 45 
   It is not the case that there is a unique failover endpoint for each
   prefix that participates in a failover relationship.  On one server,
   there is (typically) one failover endpoint per partner, regardless of
   how many prefixes are managed by that combination of partner and
   role.  On a particular server, any given prefix that participates in
   failover will be associated with exactly one failover endpoint.

   When a connection is received from the partner, the unique failover
   endpoint to which the message is directed is determined solely by the
   IPv6 address of the partner, the relationship name, and the role of
   the receiving server.

6.3.  Sending a STATE Message

   A server MUST send a STATE message to its failover partner whenever
   the state of the failover endpoint changes.  Sending the occasional
   duplicate STATE message will not cause any problems; note, however,
   that not updating the failover partner with information about a
   failover endpoint state change can, in many cases, cause the entire
   failover protocol to be inoperative.

   The STATE message is sent with information about the endpoint state
   of the failover relationship.  The STATE message MUST contain at
   least the following information in the options area:

   o  OPTION_F_SERVER_STATE containing the state of this failover
      endpoint.

   o  OPTION_F_SERVER_FLAGS containing the flag values associated with
      this failover endpoint.

   o  OPTION_F_START_TIME_OF_STATE containing the time when this became
      the state of this failover endpoint.

   o  OPTION_F_PARTNER_DOWN_TIME containing the time that this failover
      endpoint went into PARTNER-DOWN state if this server is in
      PARTNER-DOWN state.  If this server isn't in PARTNER-DOWN state,
      do not include this option.

   The server sending a STATE message SHOULD ensure that this
   information is written to stable storage prior to enqueuing it to its
   failover partner.

Top      Up      ToC       Page 46 
6.4.  Receiving a STATE Message

   A server receiving a STATE message must process the information in
   the message and decide how to react to the information.  The
   processing is performed as follows:

   o  OPTION_F_SERVER_STATE - If this represents a change in state for
      the failover partner, react according to the instructions in
      Section 8.1.  If the state is not PARTNER-DOWN, clear any memory
      of the partner-down-time.

   o  OPTION_F_SERVER_FLAGS - Remember these flags in an appropriate
      data area so they can be referenced later.

   o  OPTION_F_START_TIME_OF_STATE - Remember this information in an
      appropriate data area so it can be referenced later.

   o  OPTION_F_PARTNER_DOWN_TIME - If the value of the
      OPTION_F_SERVER_STATE is PARTNER-DOWN, remember this information
      in an appropriate data area so it can be referenced later.

   A server receiving a STATE message SHOULD ensure that this
   information is written to stable storage.

6.5.  Connection Maintenance Parameters

   The following parameters and timers are used to ensure the integrity
   of the connections between two failover servers.

   Parameter                      Default  Description
   ---------------------------------------------------------------------
   FO_KEEPALIVE_TIMER             timer    counts down to time
                                           connection assumed dead
                                           due to lack of messages

   FO_KEEPALIVE_TIME              60       maximum time server will
                                           consider connection still up
                                           with no messages

   FO_CONTACT_PER_KEEPALIVE_TIME  4        number of CONTACT messages
                                           to send during partner's
                                           FO_KEEPALIVE_TIME period

   FO_SEND_TIMER                  timer    counts down to time to send
                                           next CONTACT message

Top      Up      ToC       Page 47 
   FO_SEND_TIME                   15       maximum time to wait between
                                           sending CONTACT messages
                                           if no other traffic.
                                           Created from partner's
                                           FO_KEEPALIVE_TIME divided by
                                           FO_CONTACT_PER_KEEPALIVE_TIME

6.6.  Unreachability Detection

   Each partner MUST maintain an FO_SEND_TIMER for each failover
   connection.  The FO_SEND_TIMER for a particular connection is reset
   to FO_SEND_TIME every time any message is transmitted on that
   connection, and the timer counts down once per second.  If the timer
   reaches zero, a CONTACT message is transmitted on that connection and
   the timer for that connection is reset to FO_SEND_TIME.  The CONTACT
   message may be transmitted at any time.  An implementation MAY use
   additional mechanisms to detect partner unreachability.

   The FO_SEND_TIME is initialized from the configured FO_KEEPALIVE_TIME
   divided by FO_CONTACT_PER_KEEPALIVE_TIME.  When a CONNECT or
   CONNECTREPLY message is received on a connection, the received
   OPTION_F_KEEPALIVE_TIME option is checked, and the value in that
   option is used to calculate the FO_SEND_TIME for that connection by
   dividing the value received by the configured
   FO_CONTACT_PER_KEEPALIVE_TIME.

   Each partner MUST maintain an FO_KEEPALIVE_TIMER for each failover
   connection.  This timer is initialized to FO_KEEPALIVE_TIME and
   counts down once per second.  It is reset to FO_KEEPALIVE_TIME
   whenever a message is received on that connection.  If it ever
   reaches zero, that connection is considered dead.  In addition, the
   FO_KEEPALIVE_TIME for that connection MUST be sent to the failover
   partner on every CONNECT or CONNECTREPLY message in the
   OPTION_F_KEEPALIVE_TIME option.

7.  Binding Updates and Acks

7.1.  Time Skew

   Partners exchange information about known lease states.  To reliably
   compare a known lease state with an update received from a partner,
   servers must be able to reliably compare the times stored in the
   known lease state with the times received in the update.  The
   failover protocol adopts the simple approach of requiring that the
   failover partners use some mechanism to synchronize the clocks on the
   two servers to within an accuracy of roughly 5 seconds.

Top      Up      ToC       Page 48 
   A mechanism to measure and track relative time differences between
   servers is necessary to ensure this synchronization.  To do so, each
   message contains the time of the transmission in the sent-time field
   of the message (see Section 5.2).  The transmitting server MUST set
   this as close to the actual transmission as possible.  The receiving
   partner MUST store its own timestamp of reception as close to the
   actual reception as possible.  The received timestamp information is
   then compared with the local timestamp.

7.2.  Information Model

   In most DHCP servers, a lease on an IPv6 address or a prefix can take
   on several different binding-status values, sometimes also called
   "lease states".  While no two DHCP server implementations will have
   exactly the same possible binding-status values, [RFC3315] enforces
   some commonality among the general semantics of the binding-status
   values used by various DHCP server implementations.

   In order to transmit binding database updates between one server and
   another using the failover protocol, some common binding-status
   values must be defined.  It is not expected that these values
   correspond to any actual implementation of DHCPv6 in a DHCP server,
   but rather that the binding-status values defined in this document
   should be convertible back and forth between those defined below and
   those in use by many DHCP server implementations.

   The lease binding-status values defined for the failover protocol are
   listed below.  Unless otherwise noted below, there MAY be client
   information associated with each of these binding-status values.

   ACTIVE - The lease is assigned to a client.  Client identification
      data MUST appear.

   EXPIRED - This value indicates that a client's binding on a given
      lease has expired.  When the partner acks the BNDUPD message of an
      expired lease, the server sets its internal state to PENDING-FREE.
      Client identification SHOULD appear.

   RELEASED - This value indicates that a client sent a RELEASE message.
      When the partner acks the BNDUPD message of a released lease, the
      server sets its internal state to PENDING-FREE.  Client
      identification SHOULD appear.

Top      Up      ToC       Page 49 
   PENDING-FREE - Once a lease is expired or released, its state becomes
      PENDING-FREE.  Depending on which algorithm was used to allocate a
      given lease, PENDING-FREE may mean either FREE or FREE-BACKUP.
      Implementations do not have to implement this PENDING-FREE state
      but may choose to switch to the destination state directly.  For
      clarity of representation, this transitional PENDING-FREE state is
      treated as a separate state.

   FREE - This value is used when a DHCP server needs to communicate
      that a lease is unused by any client, but it was not just
      released, expired, or reset by a network administrator.  When the
      partner acks the BNDUPD message of a FREE lease, the server marks
      the lease as available for assignment by the primary server.  Note
      that on a secondary server running in PARTNER-DOWN state, after
      waiting the MCLT, the lease MAY be allocated to a client by the
      secondary server.  Client identification MAY appear and indicates,
      as a hint, the last client to have used this lease.

   FREE-BACKUP - This value indicates that this lease can be allocated
      by the secondary server to a client at any time.  Note that on the
      primary server running in PARTNER-DOWN state, after waiting the
      MCLT, the lease MAY be allocated to a client by the primary server
      if the proportional algorithm was used.  Client identification MAY
      appear and indicates, as a hint, the last client to have used this
      lease.

   ABANDONED - This value indicates that a lease is considered unusable
      by the DHCP system.  The primary reason for entering such a state
      is the reception of a DECLINE message for the lease.  Client
      identification MAY appear.

   RESET - This value indicates that this lease was made available by an
      operator command.  This is a distinct state so that the reason
      that the lease became FREE can be determined.  Client
      identification MAY appear.

   Which binding-status values are associated with a timeout is
   implementation dependent.  Some binding-status values, such as
   ACTIVE, will have a timeout value in all implementations, while
   others, such as ABANDONED, will have a timeout value in some
   implementations and not in others.  In some implementations, a
   binding-status value may be associated with a timeout in some
   circumstances and not in others.  The receipt of a BNDUPD message
   with a particular binding-status value and an
   OPTION_F_STATE_EXPIRATION_TIME indicates that this particular
   binding-status value is associated with a timeout.

Top      Up      ToC       Page 50 
   The lease state machine is presented in Figure 2.  Most states are
   stationary, i.e., the lease stays in a given state until an external
   event triggers transition to another state.  The only transitive
   state is PENDING-FREE.  Once it is reached, the state machine
   immediately transitions to either FREE or FREE-BACKUP state.

                               +---------+
                /------------->|  ACTIVE |<--------------\
                |              +---------+               |
                |                |  |  |                 |
                |       /--(8)--/  (3)  \--(9)-\         |
                |      |            |           |        |
                |      V            V           V        |
                |  +-------+   +--------+   +---------+  |
                |  |EXPIRED|   |RELEASED|   |ABANDONED|  |
                |  +-------+   +--------+   +---------+  |
                |      |            |            |       |
                |      |            |           (10)     |
                |      |            |            V       |
                |      |            |       +---------+  |
                |      |            |       |  RESET  |  |
                |      |            |       +---------+  |
                |      |            |            |       |
                |       \--(4)--\  (4)  /--(4)--/        |
                |                |  |  |                 |
               (1)               V  V  V                (2)
                |              /---------\               |
                |              | PENDING-|               |
                |              |  FREE   |               |
                |              \---------/               |
                |                 |   |                  |
                |         /-(5)--/     \-(6)-\           |
                |        |                    |          |
                |        V                    V          |
                |    +-------+         +-----------+     |
                \----|  FREE |<--(7)-->|FREE-BACKUP|-----/
                     +-------+         +-----------+

                          PENDING-FREE transition

                       Figure 2: Lease State Machine

Top      Up      ToC       Page 51 
   Transitions between states will result from the following events:

   (1)   The primary server allocates a lease.

   (2)   The secondary server allocates a lease.

   (3)   The client sends RELEASE, and the lease is released.

   (4)   The partner acknowledges the state change.  This transition MAY
         also occur if the server is in PARTNER-DOWN state and the MCLT
         has passed since the entry into RELEASED, EXPIRED, or RESET
         states.

   (5)   The lease belongs to a pool that is governed by proportional
         allocation, or independent allocation is used and this lease
         belongs to the primary server's pool.

   (6)   The lease belongs to a pool that is governed by independent
         allocation, and the lease belongs to the secondary server.

   (7)   A pool rebalance event occurs (POOLREQ/POOLRESP messages are
         exchanged).  Delegable prefixes belonging to the primary server
         can be assigned to the secondary server's pool (transition from
         FREE to FREE-BACKUP) or vice versa.

   (8)   The lease has expired.

   (9)   A DECLINE message is received, or a lease is deemed unusable
         for other reasons.

   (10)  An administrative action is taken to restore an abandoned lease
         to a usable state.  This transition MAY occur due to
         implementation-specific handling of an ABANDONED lease.  One
         possible example of this is a Neighbor Discovery or ICMPv6 Echo
         check to see if the address is still in use.

Top      Up      ToC       Page 52 
   The lease that is no longer in use (due to expiration or release)
   becomes PENDING-FREE.  Depending on what allocation algorithm is
   used, the lease that is no longer in use returns to the primary pool
   (FREE) or the secondary pool (FREE-BACKUP).  The conditions for
   specific transitions are depicted in Figure 3.

                 +----------------+---------+-----------+
                 | \   Lease owner|         |           |
                 |  \----------\  | Primary | Secondary |
                 |Algorithm     \ |         |           |
                 +----------------+---------+-----------+
                 | Proportional   | FREE    |FREE-BACKUP|
                 | Independent    | FREE    |    FREE   |
                 +----------------+---------+-----------+

                 Figure 3: PENDING-FREE State Transitions

7.3.  Times Required for Exchanging Binding Updates

   Each server must keep track of the following specific times beyond
   those required by the base DHCP specification [RFC3315].

   expiration-time
      The greatest lifetime that this server has ever acked to its
      failover partner in a BNDREPLY message.

   acked-partner-lifetime
      The greatest lifetime that the failover partner has ever acked to
      this server in a BNDREPLY message.

   partner-lifetime
      The time value that will be sent (or that has been sent) to the
      partner to indicate the time after which the partner can consider
      the lease expired.  When a BNDUPD message is received, this value
      can be updated from the received OPTION_F_EXPIRATION_TIME.

   client-last-transaction-time
      The time when this server most recently interacted with the client
      associated with this lease.

   partner-raw-clt-time
      The time when the partner most recently interacted with the client
      associated with this lease.  This time remains exactly as it was
      received by this server and MUST NOT be adjusted in any way.

Top      Up      ToC       Page 53 
   start-time-of-state
      The time when the binding-status of this lease was changed to its
      current value.

   state-expiration-time
      The time when the current state of this lease will expire.

7.4.  Sending Binding Updates

   Every BNDUPD message contains information about either (1) a single
   client binding in an OPTION_CLIENT_DATA option that includes IAADDR
   or IAPREFIX options associated with that client or (2) a single
   prefix lease in an OPTION_IAPREFIX option for prefixes that are
   currently not associated with any clients.

   All information about a particular client binding MUST be contained
   in a single OPTION_CLIENT_DATA option (see Section 4.1.2.2 of
   [RFC5007]).  The OPTION_CLIENT_DATA option contains at least the data
   shown below in its client-options section:

   o  OPTION_CLIENTID containing the DUID of the client most recently
      associated with this lease MUST appear.

   o  OPTION_LQ_BASE_TIME containing the absolute time that the
      information was placed in this OPTION_CLIENT_DATA option (see
      Section 6.3.1 of [RFC7653]) MUST appear.

   o  OPTION_VSS (see Section 3.4 of [RFC6607]).  This option MUST NOT
      appear if the information in this OPTION_CLIENT_DATA option is
      associated with the global, default VPN.  This option MUST appear
      if the information in this OPTION_CLIENT_DATA option is associated
      with a VPN other than the global, default VPN.  Support of
      [RFC6607] is not required, and if it is not supported, then an
      OPTION_VSS MUST NOT appear.  If [RFC6607] is supported, then an
      OPTION_VSS MUST appear if and only if a VPN other than the global,
      default VPN is used.

   o  OPTION_F_RECONFIGURE_DATA containing the time and reconfigure key,
      if any.

   o  OPTION_LQ_RELAY_DATA containing information described in
      Section 4.1.2.4 of [RFC5007], if any exists.

Top      Up      ToC       Page 54 
   o  OPTION_IA_NA or OPTION_IA_TA for an IPv6 address, or OPTION_IA_PD
      for an IPv6 prefix.  More than one of either of these options MAY
      appear if more than one of them are associated with this client.
      At least one of an OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD
      must appear.

      *  IAID - Identity Association used by the client, while obtaining
         a given lease.  Note that (1) one client may use many IAIDs
         simultaneously and (2) IAIDs for OPTION_IA_NA, OPTION_IA_TA,
         and OPTION_IA_PD are orthogonal number spaces.

      *  T1 time sent to client.

      *  T2 time sent to client.

      *  Inside of the IA_NA-options, IA_TA-options, or IA_PD-options
         sections:

         +  OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for
            an IPv6 prefix MUST appear.

            -  IPv6 address or IPv6 prefix (with length).

            -  Preferred lifetime sent to client.

            -  Valid lifetime sent to client.

            -  Inside of the IAaddr-options or IAprefix-options:

               o  OPTION_F_BINDING_STATUS containing the binding-status
                  MUST appear.

               o  OPTION_F_START_TIME_OF_STATE containing the
                  start-time-of-state MUST appear.

               o  OPTION_F_STATE_EXPIRATION_TIME (absolute) containing
                  the state-expiration-time*.

               o  OPTION_CLT_TIME (relative) containing the
                  client-last-transaction-time.  See [RFC5007] for a
                  description of this option.

               o  OPTION_F_PARTNER_LIFETIME (absolute) containing the
                  partner-lifetime*.

               o  OPTION_F_PARTNER_RAW_CLT_TIME (absolute) containing
                  the partner-raw-clt-time.

Top      Up      ToC       Page 55 
               o  OPTION_F_EXPIRATION_TIME (absolute) containing the
                  expiration-time*.

               o  OPTION_CLIENT_FQDN containing the FQDN information
                  associated with this lease and client, if any.

   Information about a prefix lease is contained in a single
   OPTION_IAPREFIX option.  Only a single OPTION_IAPREFIX option may
   appear in a BNDUPD message outside of an OPTION_CLIENT_DATA option.
   In detail:

   o  OPTION_IAPREFIX for a prefix lease.

      *  IPv6 prefix (with length).

      *  Inside of the IAprefix-options section:

         +  OPTION_VSS (see Section 3.4 of [RFC6607]).  This option
            MUST NOT appear if the information in this OPTION_IAPREFIX
            option is associated with the global, default VPN.  This
            option MUST appear if the information in this
            OPTION_IAPREFIX option is associated with a VPN other than
            the global, default VPN.  Support of [RFC6607] is not
            required, and if it is not supported, then an OPTION_VSS
            MUST NOT appear.  If [RFC6607] is supported, then an
            OPTION_VSS MUST appear if and only if a VPN other than the
            global, default VPN is used.

         +  OPTION_LQ_BASE_TIME containing the absolute time that this
            information was placed in this OPTIONS_IAPREFIX option (see
            Section 6.3.1 of [RFC7653]) MUST appear.

         +  OPTION_F_BINDING_STATUS containing the binding-status MUST
            appear.

         +  OPTION_F_START_TIME_OF_STATE containing the
            start-time-of-state MUST appear.

         +  OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the
            state-expiration-time*.

         +  OPTION_F_PARTNER_LIFETIME (absolute) containing the
            partner-lifetime*.

         +  OPTION_F_EXPIRATION_TIME (absolute) containing the
            expiration-time*.

Top      Up      ToC       Page 56 
   Items marked with a single asterisk (*) MUST appear only if the value
   in the OPTION_F_BINDING_STATUS is associated with a timeout;
   otherwise, it MUST NOT appear.  See Section 7.2 for details.

   The OPTION_CLT_TIME MUST, if it appears, be the time that the server
   last interacted with the DHCP client.  It MUST NOT be, for instance,
   the time that the lease expired if there has been no interaction with
   the DHCP client in question.

   A server SHOULD be prepared to clean up DNS information once the
   lease expires or is released.  See Section 9 for a detailed
   discussion about DNS update.  Another reason the partner may be
   interested in keeping additional data is to enable better support for
   Leasequery [RFC5007], Bulk Leasequery [RFC5460], or Active Leasequery
   [RFC7653], some of which feature queries based on Relay-ID, link
   address, or Remote-ID.

7.5.  Receiving Binding Updates

7.5.1.  Monitoring Time Skew

   The sent-time from the failover message is compared with the current
   time of the receiving server as recorded when it received the
   message.  The difference is noted, and if it is greater than
   5 seconds the receiving server SHOULD drop the connection.  A message
   SHOULD be logged to signal the reason for the connection being
   dropped.

   Any time can be before, after, or essentially the same as another
   time.  Any time that ends up being +/- 5 seconds of another time
   SHOULD be considered to be representing the same time when performing
   a comparison between two times.

7.5.2.  Acknowledging Reception

   Upon acceptance of a binding update, the server MUST notify its
   partner that it has processed the binding update (and updated its
   lease state database if necessary) by sending a BNDREPLY message.  A
   server MUST NOT send the BNDREPLY message before its binding database
   is updated.

Top      Up      ToC       Page 57 
7.5.3.  Processing Binding Updates

   When a BNDUPD message is received, it MUST contain either a single
   OPTION_CLIENT_DATA option or a single OPTION_IAPREFIX option.

   When analyzing a BNDUPD message from a partner server, if there is
   insufficient information in the BNDUPD message to process it, then it
   is rejected with an OPTION_STATUS_CODE of
   "MissingBindingInformation".

   The server receiving a BNDUPD message from its partner must evaluate
   the received information in each OPTION_CLIENT_DATA or IAPREFIX
   option to see if it is consistent with the server's already-known
   state and, if it is not, decide to accept or reject the information.
   Section 7.5.4 provides details regarding how the server makes this
   determination.

   A server receiving a BNDUPD message MUST respond to the sender of
   that message with a BNDREPLY message that contains the same
   transaction-id as the BNDUPD message.  This BNDREPLY message MUST
   contain either a single OPTION_CLIENT_DATA option or a single
   OPTION_IAPREFIX option, corresponding to whatever was received in the
   BNDUPD message.

   An OPTION_CLIENT_DATA option or an OPTION_IAPREFIX option in the
   BNDREPLY message that is accepted SHOULD NOT contain an
   OPTION_STATUS_CODE unless a status message needs to be sent to the
   failover partner, in which case it SHOULD include an
   OPTION_STATUS_CODE option with a status-code indicating success and
   whatever message is needed.

   To indicate rejection of the information in an OPTION_CLIENT_DATA
   option or an OPTION_IAPREFIX option, an OPTION_STATUS_CODE SHOULD be
   included with a status-code indicating an error in the
   OPTION_CLIENT_DATA option or OPTION_IAPREFIX option in the BNDREPLY
   message.

7.5.4.  Accept or Reject?

   The first task in processing the information in an OPTION_CLIENT_DATA
   option or OPTION_IAPREFIX option is to extract the client information
   (if any) and lease information out of the option and to access the
   address lease or prefix lease information in the server's binding
   database.

   If an OPTION_VSS option is specified in the OPTION_CLIENT_DATA option
   or OPTION_IAPREFIX option and the VPN specified in the OPTION_VSS
   option does not appear in the configuration of the receiving server,

Top      Up      ToC       Page 58 
   then reject the entire OPTION_CLIENT_DATA option or OPTION_IAPREFIX
   option by including an OPTION_STATUS_CODE option with a status-code
   of "ConfigurationConflict".

   If the lease specified in the OPTION_CLIENT_DATA option or
   OPTION_IAPREFIX option is not a lease associated with the failover
   endpoint that received the OPTION_CLIENT_DATA option, then reject it
   by including an OPTION_STATUS_CODE option with a status-code of
   "ConfigurationConflict".

   In general, acceptance or rejection is based on the comparison of two
   different time values -- one from the OPTION_CLIENT_DATA option or
   OPTION_IAPREFIX option in the BNDUPD message, and one from the
   receiving server's binding database associated with the address or
   prefix lease found in the BNDUPD message.  The time for the BNDUPD
   message where the OPTION_F_BINDING_STATUS is ACTIVE, EXPIRED, or
   RELEASED is the OPTION_CLT_TIME if one appears, or the
   OPTION_F_START_TIME_OF_STATE if one does not.  For other
   binding-status values, the time for the BNDUPD message is the
   later of (1) the OPTION_CLT_TIME if one appears or (2) the
   OPTION_F_START_TIME_OF_STATE.  The time for the lease in the server's
   binding database is the client-last-transaction-time if one appears,
   or the start-time-of-state if one does not.

   The basic approach is to compare these times, and if the one from the
   BNDUPD message is clearly later, then accept the information in the
   OPTION_CLIENT_DATA option or OPTION_IAPREFIX option.  If the one from
   the server's binding database is clearly later, then reject the
   information in the BNDUPD message.  The challenge comes when they are
   essentially the same (i.e., +/- 5 seconds).  In this case, they are
   considered identical, despite the minor differences.  Figure 4 shows
   a table containing the rules for dealing with all of these
   situations.

                          binding-status in received OPTION_CLIENT_DATA
                                                     or OPTION_IAPREFIX
   binding-status in
   receiving server's                                 FREE        RESET
   lease state DB   ACTIVE   EXPIRED   RELEASED   FREE-BACKUP  ABANDONED
   ---------------------------------------------------------------------
   ACTIVE           accept(3) time(1)   accept     time(1)      accept
   EXPIRED          accept    accept    accept     accept       accept
   RELEASED         accept    accept    accept     accept       accept
   FREE/FREE-BACKUP accept    accept    accept     accept       accept
   RESET            time(2)   accept    accept     accept       accept
   ABANDONED        accept    accept    accept     accept       accept

                       Figure 4: Conflict Resolution

Top      Up      ToC       Page 59 
   accept:  If the time value in the OPTION_CLIENT_DATA option or
      OPTION_IAPREFIX option is later than the time value in the
      server's binding database, accept it, else reject it.

   time(1):  If the current time is later than the receiving server's
      state-expiration-time, accept it, else reject it.

   time(2):  If the OPTION_CLT_TIME value (if it appears) in the
      OPTION_CLIENT_DATA is later than the start-time-of-state in the
      receiving server's binding, accept it, else reject it.

   accept,time(1),time(2):  If rejecting, use a status-code of
      "OutdatedBindingInformation".

   accept(3):  If the clients in an OPTION_CLIENT_DATA option and in a
      receiving server's binding differ, then if time(2) or the
      receiving server is a secondary accept it, else reject it with a
      status-code of "AddressInUse".  If the clients match, accept the
      update.

   The lease update may be accepted or rejected.  If a lease is rejected
   with "OutdatedBindingInformation", then the flag in the lease that
   indicates that the partner should be updated with the information in
   this lease SHOULD be set; otherwise, it SHOULD NOT be changed.  If
   this flag was previously not set, then an update MAY be transmitted
   immediately to the partner (though the BNDREPLY to this BNDUPD
   message SHOULD be sent first).  If this flag was previously set, an
   update SHOULD NOT be transmitted immediately to the partner.  In this
   case, an update will be sent during the next periodic scan, but not
   immediately, thus preventing a possible update storm should the
   servers be unable to agree.  Ultimately, the server with the most
   recent binding information should have its update accepted by its
   partner.

7.5.5.  Accepting Updates

   When the information in an OPTION_CLIENT_DATA option or
   OPTION_IAPREFIX option has been accepted, some of that information is
   stored in the receiving server's binding database, and a
   corresponding OPTION_CLIENT_DATA option or OPTION_IAPREFIX option is
   entered into a BNDREPLY message.  The information to enter into the
   OPTION_CLIENT_DATA option or OPTION_IAPREFIX option in the BNDREPLY
   message is described in Section 7.6.

Top      Up      ToC       Page 60 
   The information contained in an accepted OPTION_CLIENT_DATA option is
   stored in the receiving server's binding database as follows:

   1.  The OPTION_CLIENTID is used to find the client.

   2.  The other data contained in the top level of the
       OPTION_CLIENT_DATA option is stored with the client as
       appropriate.

   3.  For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD
       options in the OPTION_CLIENT_DATA option and for each of the
       OPTION_IAADDR or OPTION_IAPREFIX options in the IA_* options:

       a.  OPTION_F_BINDING_STATUS is stored as the binding-status.

       b.  OPTION_F_PARTNER_LIFETIME is stored in the expiration-time.

       c.  OPTION_F_STATE_EXPIRATION_TIME is stored in the
           state-expiration-time.

       d.  OPTION_CLT_TIME [RFC5007] is stored in the
           partner-raw-clt-time.

       e.  OPTION_F_PARTNER_RAW_CLT_TIME replaces the
           client-last-transaction-time if it is later than the current
           client-last-transaction-time.

       f.  OPTION_F_EXPIRATION_TIME replaces the partner-lifetime if it
           is later than the current partner-lifetime.

   The information contained in an accepted single OPTION_IAPREFIX
   option that is not contained in an OPTION_CLIENT_DATA option is
   stored in the receiving server's binding database as follows:

   1.  The IPv6 prefix is used to find the prefix.

   2.  Inside of the IAprefix-options section:

       a.  OPTION_F_BINDING_STATUS is stored as the binding-status.

       b.  OPTION_F_PARTNER_LIFETIME (if any) is stored in the
           expiration-time.

       c.  OPTION_F_STATE_EXPIRATION_TIME (if any) is stored in the
           state-expiration-time.

Top      Up      ToC       Page 61 
       d.  OPTION_F_EXPIRATION_TIME (if any) replaces the
           partner-lifetime if it is later than the current
           partner-lifetime.

7.6.  Sending Binding Replies

   A server MUST respond to every BNDUPD message with a BNDREPLY
   message.  The BNDREPLY message MUST contain an OPTION_CLIENT_DATA
   option if the BNDUPD message contained an OPTION_CLIENT_DATA option,
   or it MUST contain an OPTION_IAPREFIX option if the BNDUPD message
   contained an OPTION_IAPREFIX option.  The BNDREPLY message MUST have
   the same transaction-id as the BNDUPD message to which it is a
   response.

   Acceptance or rejection of all of or a particular part of the BNDUPD
   message is signaled with an OPTION_STATUS_CODE option.  An
   OPTION_STATUS_CODE option containing a status-code representing an
   error is significant, while an OPTION_STATUS_CODE option whose
   status-code contains success is considered informational but does not
   affect the processing of the BNDREPLY message when it is received by
   the server that sent the BNDUPD message.

   Rejection of all of or part of the information in a BNDUPD message is
   signaled in a BNDREPLY message by using the OPTION_STATUS_CODE
   message with an error in the status-code field.  This rejection can
   take place at either of two levels -- the top level of the option
   hierarchy or the bottom level of the option hierarchy:

   1.  Entire BNDUPD: The OPTION_STATUS_CODE containing an error is
       present in the outermost option of the BNDREPLY message -- either
       the single OPTION_CLIENT_DATA option or the single
       OPTION_IAPREFIX option.  An example of this sort of error might
       be that an OPTION_VSS option was present and specified a VPN that
       might not exist in the receiving server.

   2.  Single address or prefix: The OPTION_STATUS_CODE containing an
       error is present in a single IAADDR or IAPREFIX option that is
       itself contained in an OPTION_IA_NA, OPTION_IA_TA, or
       OPTION_IA_PD option.  An example of this sort of error might be
       that a particular IPv6 address was specified in an IAADDR option
       that doesn't appear in the receiving server's configuration.

   Rejection occurring at either of these levels indicates rejection of
   all of the information contained in the option (including any other
   options contained in that option) where the OPTION_STATUS_CODE option
   containing an error appears.  The converse is not true -- an
   OPTION_STATUS_CODE option containing success does not signify that
   all of the contained information has been accepted.

Top      Up      ToC       Page 62 
   If the BNDREPLY message contains an OPTION_CLIENT_DATA option, then
   the OPTION_CLIENT_DATA option MUST contain at least the data shown
   below in its client-options section:

   o  OPTION_CLIENTID containing the DUID of the client most recently
      associated with this IPv6 address.

   o  OPTION_VSS from the BNDUPD message, if any.

   o  OPTION_IA_NA or OPTION_IA_TA for an IPv6 address or OPTION_IA_PD
      for an IPv6 prefix.  More than one of either of these options MAY
      appear if there are more than one of them associated with this
      client.

      *  Inside of the IA_NA-options, IA_TA-options, or IA_PD-options
         sections:

         +  OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for
            an IPv6 prefix.

            -  IPv6 address or IPv6 prefix (with length).

            -  Inside of the IAaddr-options or IAprefix-options:

               o  OPTION_STATUS_CODE containing an error code, or
                  containing a success code if a message is required.
                  An OPTION_STATUS_CODE option SHOULD NOT appear with a
                  success code unless a message associated with the
                  success code needs to be included.  The lack of an
                  OPTION_STATUS_CODE option is an indication of success.

               o  OPTION_F_BINDING_STATUS containing the binding-status
                  received in the BNDUPD message.

               o  OPTION_F_STATE_EXPIRATION_TIME (absolute) containing
                  the state-expiration-time received in the BNDUPD
                  message.

               o  OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a
                  duplicate of the OPTION_F_PARTNER_LIFETIME received in
                  the BNDUPD message.

Top      Up      ToC       Page 63 
   If the BNDREPLY message contains a single OPTION_IAPREFIX option not
   contained in an OPTION_CLIENT_DATA option, then the OPTION_IAPREFIX
   option MUST contain at least the data shown below:

   o  IPv6 prefix (with length).

   o  IAprefix-options:

      *  OPTION_VSS from the BNDUPD message, if any.

      *  OPTION_STATUS_CODE containing an error code, or containing a
         success code if a message is required.  If the information in
         the corresponding OPTION_IAPREFIX in the BNDUPD message was
         accepted and no status message was required (which is the usual
         case), no OPTION_STATUS_CODE option appears.

      *  OPTION_F_BINDING_STATUS containing the binding-status received
         in the BNDREPLY message.

      *  OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the
         state-expiration-time received in the BNDREPLY message.

      *  OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a
         duplicate of the OPTION_F_PARTNER_LIFETIME received in the
         BNDREPLY message.

7.7.  Receiving Binding Acks

   When a BNDREPLY message is received, the overall OPTION_CLIENT_DATA
   option or the overall OPTION_IAPREFIX option may contain an
   OPTION_STATUS_CODE containing an error that represents a rejection of
   the entire BNDUPD message.  An enclosed OPTION_IA_NA, OPTION_IA_TA,
   or OPTION_IA_PD option may also contain an OPTION_STATUS_CODE
   containing an error that indicates that everything in the containing
   option has been rejected.  Alternatively, an individual IAADDR or
   IAPREFIX option may contain an OPTION_STATUS_CODE option containing
   an error that indicates that the IAADDR or IAPREFIX option has been
   rejected.  An OPTION_STATUS_CODE containing a success code has no
   bearing on the acceptance status of the BNDREPLY message at any
   level.

   Receipt of a rejection (or a part of a BNDREPLY message that has been
   rejected) requires no processing, other than remembering that it has
   been encountered.

Top      Up      ToC       Page 64 
   The information contained in the BNDREPLY message in an
   OPTION_CLIENT_DATA that represents an acceptance is stored with the
   appropriate client and lease, as follows:

   1.  The OPTION_CLIENTID is used to find the client.

   2.  For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD
       options in the OPTION_CLIENT_DATA option and for each of the
       OPTION_IAADDR or OPTION_IAPREFIX options they contain:

       a.  OPTION_F_PARTNER_LIFETIME_SENT is stored in the
           acked-partner-lifetime.

       b.  The partner-lifetime is set to 0 to indicate that no more
           information needs to be sent to the partner.

   Alternatively, the BNDREPLY message may contain a single
   OPTION_IAPREFIX option not contained in an OPTION_CLIENT_DATA option,
   representing information concerning a single prefix lease.  If the
   IAprefix-options section of the OPTION_IAPREFIX option contains an
   OPTION_STATUS_CODE representing an error, then it is considered a
   rejection of the corresponding BNDUPD message.  If the
   OPTION_IAPREFIX option does not contain an OPTION_STATUS_CODE option
   or if the OPTION_STATUS_CODE option contains a success status, then
   the three items in the following list are stored in the lease state
   database, in the section associated with the prefix lease represented
   by the OPTION_IAPREFIX option.

   1.  OPTION_F_BINDING_STATUS containing the binding-status received in
       the BNDREPLY message.

   2.  OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the
       state-expiration-time received in the BNDREPLY message.

   3.  OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a duplicate
       of the OPTION_F_PARTNER_LIFETIME received in the BNDREPLY
       message.

Top      Up      ToC       Page 65 
7.8.  BNDUPD/BNDREPLY Data Flow

   Figure 5 shows the relationship of the times described in Section 7.3
   to the options used to transmit them.  It also relates the times on
   one failover partner to the other failover partner.

   ----------------------- BNDUPD ---------------------------------

     Source on            OPTION_F in            Storage on
    Sending Server  ->   BNDUPD message   ->   Receiving Server


                                     [always update]

   partner-lifetime      PARTNER_LIFETIME      expiration-time

   client-last-transaction-time  CLT_TIME      partner-raw-clt-time
   start-time-of-state   START_TIME_OF_STATE   start-time-of-state
   state-expiration-time STATE_EXPIRATION_TIME state-expiration-time

                              [update only if received > current]

   expiration-time       EXPIRATION_TIME       partner-lifetime
   partner-raw-clt-time  PARTNER_RAW_CLT_TIME
                                          client-last-transaction-time

   ----------------------- BNDREPLY -------------------------------

     Storage on            OPTION_F in           Storage on
    Receiving Server <-   BNDUPD message   <-   Sending Server

           [always update]

   acked-partner-lifetime PARTNER_LIFETIME_SENT duplicate of received
                                                  PARTNER_LIFETIME
   (nothing to update)    STATE_EXPIRATION_TIME state-expiration-time

   ----------------------------------------------------------------

                Figure 5: BNDUPD and BNDREPLY Time Handling


Next Section