tech-invite   World Map     

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

RFC 8156

 
 
 

DHCPv6 Failover Protocol

Part 2 of 5, p. 19 to 40
Prev Section       Next Section

 


prevText      Top      ToC       Page 19 
5.  Message and Option Definitions

5.1.  Message Framing for TCP

   Failover communication is conducted over a TCP connection established
   between the partners.  The failover protocol uses the framing format
   specified in Section 5.1 of "DHCPv6 Bulk Leasequery" [RFC5460] but
   uses different message types with a different message format, as
   described in Section 5.2 of this document.  The TCP connection
   between failover servers is made to a specific port -- the
   dhcp-failover port, port 647.  All information is sent over the
   connection as typical DHCP messages that convey DHCP options,
   following the format defined in Section 22.1 of [RFC3315].

5.2.  Failover Message Format

   All failover messages defined below share a common format with a
   fixed-size header and a variable format area for options.  All values
   in the message header and in any included options are in network byte
   order.

   The following diagram illustrates the format (which is compatible
   with the format described in Section 6 of [RFC3315]) of DHCP messages
   exchanged between failover partners:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    msg-type   |               transaction-id                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           sent-time                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               .
    .                            options                            .
    .                           (variable)                          .
    .                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    msg-type             Identifies the DHCP message type; the
                         available message types are listed below.

    transaction-id       The transaction-id for this message exchange.

Top      Up      ToC       Page 20 
    sent-time            The time the message was transmitted (set
                         as close to transmission as practical),
                         in seconds since midnight (UTC),
                         January 1, 2000, modulo 2^32.  Used to
                         determine the time skew of the failover
                         partners.

    options              Options carried in this message.  These
                         options are all defined in the "Option Codes"
                         sub-registry of the "Dynamic Host
                         Configuration Protocol for IPv6 (DHCPv6)"
                         registry.  A number of existing DHCPv6
                         options are used, and several more are
                         defined in this document.

5.3.  Messages

   The following sections list the new message types defined for
   failover communication.

5.3.1.  BNDUPD

   The binding update message, BNDUPD (24), is used to send the binding
   lease changes to the partner.  At most one OPTION_CLIENT_DATA option
   may appear in a BNDUPD message.  Note that not all data in a BNDUPD
   message is sent in an OPTION_CLIENT_DATA option.  Information about
   delegable prefixes not currently allocated to a particular client is
   sent in BNDUPD messages but not within OPTION_CLIENT_DATA options.
   The partner is expected to respond with a BNDREPLY message.

5.3.2.  BNDREPLY

   The binding acknowledgement message, BNDREPLY (25), is used for
   confirmation of the received BNDUPD message.  It may contain a
   positive or negative response (e.g., due to a detected lease
   conflict).

5.3.3.  POOLREQ

   The pool request message, POOLREQ (26), is used by the secondary
   server to request allocation of delegable prefixes from the primary
   server.  The primary responds with a POOLRESP message.

Top      Up      ToC       Page 21 
5.3.4.  POOLRESP

   The pool response message, POOLRESP (27), is used by the primary
   server to indicate that it has received the secondary server's
   request to ensure that delegable prefixes are balanced between the
   primary and secondary servers.  It does not indicate that all of the
   BNDUPD messages that might be created from any rebalancing have been
   sent or responded to; it only indicates reception and acceptance of
   the task of ensuring that the balance is examined and corrected as
   necessary.

5.3.5.  UPDREQ

   The update request message, UPDREQ (28), is used by one server to
   request that its partner send all binding database changes that have
   not yet been confirmed.  The partner is expected to respond with zero
   or more BNDUPD messages, followed by an UPDDONE message that signals
   that all of the BNDUPD messages have been sent and a corresponding
   BNDREPLY message has been received for each of them.

5.3.6.  UPDREQALL

   The update request all message, UPDREQALL (29), is used by one server
   to request that all binding database information present in the other
   server be sent to the requesting server, in order for the requesting
   server to recover from a total loss of its binding database.  A
   server receiving this request responds with zero or more BNDUPD
   messages, followed by an UPDDONE message that signals that all of the
   BNDUPD messages have been sent and a corresponding BNDREPLY message
   has been received for each of them.

5.3.7.  UPDDONE

   The update done message, UPDDONE (30), is used by the server
   responding to an UPDREQ or UPDREQALL message to indicate that all
   requested updates have been sent by the responding server and acked
   by the requesting server.

5.3.8.  CONNECT

   The connect message, CONNECT (31), is used by the primary server to
   establish a failover connection with the secondary server and to
   transmit several important configuration attributes between the
   servers.  The partner is expected to confirm by responding with a
   CONNECTREPLY message.

Top      Up      ToC       Page 22 
5.3.9.  CONNECTREPLY

   The connect acknowledgement message, CONNECTREPLY (32), is used by
   the secondary server to respond to a CONNECT message from the primary
   server.

5.3.10.  DISCONNECT

   The disconnect message, DISCONNECT (33), is used by either server
   when closing a connection and shutting down.  No response is required
   for this message.  The DISCONNECT message SHOULD contain an
   OPTION_STATUS_CODE option with an appropriate status.  Often, this
   will be ServerShuttingDown.  See Section 5.6.  A server SHOULD
   include a descriptive message as to what caused the disconnect
   message.

5.3.11.  STATE

   The state message, STATE (34), is used by either server to inform its
   partner about a change of failover state.  In some cases, it may be
   used to also inform the partner about the current state, e.g., after
   connection is established in the COMMUNICATIONS-INTERRUPTED or
   PARTNER-DOWN states.

5.3.12.  CONTACT

   The contact message, CONTACT (35), is used by either server to ensure
   that its partner continues to see the connection as operational.  It
   MUST be transmitted periodically over every established connection if
   other message traffic is not flowing, and it MAY be sent at any time.
   See Section 6.5.

5.4.  Transaction-id

   The initiator of a message exchange MUST set the transaction-id (see
   Section 5.2).  This means that all of the messages above except
   BNDREPLY, POOLRESP, UPDDONE, and CONNECTREPLY must set the
   transaction-id.  The transaction-id MUST be unique among all
   currently outstanding messages sent to the failover partner.  A
   straightforward way to ensure this is to simply use an incrementing
   value, with one caveat: The UPDREQ and UPDREQALL messages may be
   separated by a considerable time prior to the receipt of an UPDDONE
   message.  While the usual pattern of message exchange would have the
   partner doing the vast majority of message initiation, it is remotely
   possible that the partner that initiated the UPDREQ or UPDREQALL
   messages might also send enough messages to wrap the 24-bit
   transaction-id and duplicate the transaction-id of the outstanding
   UPDREQ or UPDREQALL messages.  Thus, it is important to ensure that

Top      Up      ToC       Page 23 
   the transaction-id of a currently outstanding UPDREQ or UPDREQALL
   message is not replicated in any message initiated prior to the
   receipt of the corresponding UPDDONE message.

5.5.  Options

   The following new options are defined.

5.5.1.  OPTION_F_BINDING_STATUS

   The binding-status is an implementation-independent representation of
   the status (or the state) of a lease on an IPv6 address or prefix.

   This is an unsigned byte.

   The code for this option is 114.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    OPTION_F_BINDING_STATUS    |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | binding-status|
    +-+-+-+-+-+-+-+-+

    option-code       OPTION_F_BINDING_STATUS (114)
    option-len        1
    binding-status    The binding-status.  See below:

      Value   binding-status
      -----   --------------
      0       reserved
      1       ACTIVE
      2       EXPIRED
      3       RELEASED
      4       PENDING-FREE
      5       FREE
      6       FREE-BACKUP
      7       ABANDONED
      8       RESET

   The binding-status values are discussed in Section 7.2.

Top      Up      ToC       Page 24 
5.5.2.  OPTION_F_CONNECT_FLAGS

   This option provides flags that indicate attributes of the connecting
   server.

   This option consists of an unsigned 16-bit integer in network byte
   order.

   The code for this option is 115.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    OPTION_F_CONNECT_FLAGS     |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             flags             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code       OPTION_F_CONNECT_FLAGS (115)
    option-len        2
    flags             flag bits.  See below:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           MBZ               |F|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The bits (numbered from the most significant bit in network
      byte order) are used as follows:

      0-14:   MBZ
              Must be zero.
      15 (F): FIXED_PD_LENGTH
              Set to 1 to indicate that all prefixes delegated from a
              given delegable prefix have the same prefix length (size).
              If this is not set, the prefixes delegated from one
              delegable prefix may have different sizes.

   If the FIXED_PD_LENGTH bit is not set, it indicates that prefixes of
   a range of sizes can be delegated from a given delegable prefix.
   Note that if the FIXED_PD_LENGTH bit is set, each delegable prefix
   may have its own fixed size -- this flag does not imply that all
   prefixes delegated will be the same size, but rather that all
   prefixes delegated from the same delegable prefix will be the
   same size.

Top      Up      ToC       Page 25 
   If the FIXED_PD_LENGTH bit is set, the length used for each prefix is
   specified independently of the failover protocol but must be known to
   both failover partners.  It might be specified in the configuration
   for each delegable prefix, or it might be fixed for the entire
   server.

5.5.3.  OPTION_F_DNS_REMOVAL_INFO

   This option contains the information necessary to remove a DNS name
   that was entered by the failover partner.

   The code for this option is 116.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   OPTION_F_DNS_REMOVAL_INFO   |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      encapsulated-options                     |
    |                           (variable)                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code       OPTION_F_DNS_REMOVAL_INFO (116)
    option-len        variable
    options           Three possible encapsulated options:
                         OPTION_F_DNS_HOST_NAME
                         OPTION_F_DNS_ZONE_NAME
                         OPTION_F_DNS_FLAGS

Top      Up      ToC       Page 26 
5.5.3.1.  OPTION_F_DNS_HOST_NAME

   This option contains the hostname that was entered into the DNS by
   the failover partner.

   This is a DNS name encoded using the format specified in [RFC1035],
   as also specified in Section 8 of [RFC3315].

   The code for this option is 117.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     OPTION_F_DNS_HOST_NAME    |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               .
    .                                                               .
    .                           host-name                           .
    .                           (variable)                          .
    .                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code       OPTION_F_DNS_HOST_NAME (117)
    option-len        length of host-name
    host-name         hostname encoded per RFC 1035

5.5.3.2.  OPTION_F_DNS_ZONE_NAME

   This option contains the zone name that was entered into the DNS by
   the failover partner.

   This is a DNS name encoded using the format specified in [RFC1035],
   as also specified in Section 8 of [RFC3315].

   The code for this option is 118.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     OPTION_F_DNS_ZONE_NAME    |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               .
    .                                                               .
    .                           zone-name                           .
    .                           (variable)                          .
    .                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 27 
    option-code       OPTION_F_DNS_ZONE_NAME (118)
    option-len        length of zone-name
    zone-name         zone name encoded per RFC 1035

5.5.3.3.  OPTION_F_DNS_FLAGS

   This option provides flags that indicate what needs to be done to
   remove this DNS name.

   This option consists of an unsigned 16-bit integer in network byte
   order.

   The code for this option is 119.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       OPTION_F_DNS_FLAGS      |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             flags             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code       OPTION_F_DNS_FLAGS (119)
    option-len        2
    flags             flag bits.  See below:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           MBZ         |U|S|R|F|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The bits (numbered from the most significant bit in network
      byte order) are used as follows:

      0-11:   MBZ
              Must be zero.
      12 (U): USING_REQUESTED_FQDN
              Set to 1 to indicate that the name used came from the
              Fully Qualified Domain Name (FQDN) that was received
              from the client.
      13 (S): SYNTHESIZED_NAME
              Set to 1 to indicate that the name was synthesized
              based on some algorithm.
      14 (R): REV_UPTODATE
              Set to 1 to indicate that the reverse zone is up to date.
      15 (F): FWD_UPTODATE
              Set to 1 to indicate that the forward zone is up to date.

Top      Up      ToC       Page 28 
   If both the U bit and the S bit are unset, then the name must have
   been provided from some alternative configuration, such as client
   registration in some database accessible to the DHCP server.

5.5.4.  OPTION_F_EXPIRATION_TIME

   This option specifies the greatest lifetime that this server has ever
   acked to its partner in a BNDREPLY message for a particular lease or
   prefix.  This MUST be an absolute time (i.e., seconds since midnight
   January 1, 2000 UTC, modulo 2^32).

   This is an unsigned 32-bit integer in network byte order.

   The code for this option is 120.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   OPTION_F_EXPIRATION_TIME    |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        expiration-time                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code         OPTION_F_EXPIRATION_TIME (120)
    option-len          4
    expiration-time     The expiration time.  This MUST be an
                        absolute time (i.e., seconds since midnight
                        January 1, 2000 UTC, modulo 2^32).

Top      Up      ToC       Page 29 
5.5.5.  OPTION_F_MAX_UNACKED_BNDUPD

   This option specifies the maximum number of BNDUPD messages that this
   server is prepared to accept over the TCP connection without causing
   the TCP connection to block.

   This is an unsigned 32-bit integer in network byte order.

   The code for this option is 121.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  OPTION_F_MAX_UNACKED_BNDUPD  |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       max-unacked-bndupd                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code           OPTION_F_MAX_UNACKED_BNDUPD (121)
    option-len            4
    max-unacked-bndupd    Maximum number of unacked BNDUPD messages
                          allowed

5.5.6.  OPTION_F_MCLT

   The Maximum Client Lead Time (MCLT) is the upper bound on the
   difference allowed between the valid lifetime provided to a DHCP
   client by a server and the valid lifetime known by that server's
   failover partner.  It is an interval, measured in seconds.  See
   Section 4.4.

   This is an unsigned 32-bit integer in network byte order.

   The code for this option is 122.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         OPTION_F_MCLT         |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              mclt                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code       OPTION_F_MCLT (122)
    option-len        4
    mclt              The MCLT, in seconds

Top      Up      ToC       Page 30 
5.5.7.  OPTION_F_PARTNER_LIFETIME

   This option specifies the time after which the partner can consider
   an IPv6 address expired and is able to reuse the IPv6 address.
   This MUST be an absolute time (i.e., seconds since midnight
   January 1, 2000 UTC, modulo 2^32).

   This is an unsigned 32-bit integer in network byte order.

   The code for this option is 123.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   OPTION_F_PARTNER_LIFETIME   |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        partner-lifetime                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code          OPTION_F_PARTNER_LIFETIME (123)
    option-len           4
    partner-lifetime     The partner lifetime.  This MUST be an
                         absolute time (i.e., seconds since midnight
                         January 1, 2000 UTC, modulo 2^32).

5.5.8.  OPTION_F_PARTNER_LIFETIME_SENT

   This option indicates the time that was received in an
   OPTION_F_PARTNER_LIFETIME option (Section 5.5.7).  This is an exact
   duplicate (echo) of the time received in the
   OPTION_F_PARTNER_LIFETIME option; it is not adjusted in any way.
   This MUST be an absolute time (i.e., seconds since midnight
   January 1, 2000 UTC, modulo 2^32).

   This is an unsigned 32-bit integer in network byte order.

   The code for this option is 124.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |OPTION_F_PARTNER_LIFETIME_SENT |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      partner-lifetime-sent                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 31 
    option-code              OPTION_F_PARTNER_LIFETIME_SENT (124)
    option-len               4
    partner-lifetime-sent    The partner-lifetime received in an
                             OPTION_F_PARTNER_LIFETIME option.
                             This MUST be an absolute time
                             (i.e., seconds since midnight
                             January 1, 2000 UTC, modulo 2^32).

5.5.9.  OPTION_F_PARTNER_DOWN_TIME

   This option specifies the time that the server most recently lost
   communications with its failover partner.  This MUST be an absolute
   time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).

   This is an unsigned 32-bit integer in network byte order.

   The code for this option is 125.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   OPTION_F_PARTNER_DOWN_TIME  |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       partner-down-time                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code          OPTION_F_PARTNER_DOWN_TIME (125)
    option-len           4
    partner-down-time    Contains the PARTNER-DOWN time.  This MUST be
                         an absolute time (i.e., seconds since midnight
                         January 1, 2000 UTC, modulo 2^32).

Top      Up      ToC       Page 32 
5.5.10.  OPTION_F_PARTNER_RAW_CLT_TIME

   This option specifies the time when the partner most recently
   interacted with the DHCP client associated with this IPv6 address or
   prefix.  This MUST be an absolute time (i.e., seconds since midnight
   January 1, 2000 UTC, modulo 2^32).

   This is an unsigned 32-bit integer in network byte order.

   The code for this option is 126.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | OPTION_F_PARTNER_RAW_CLT_TIME |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      partner-raw-clt-time                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code             OPTION_F_PARTNER_RAW_CLT_TIME (126)
    option-len              4
    partner-raw-clt-time    Contains the partner-raw-clt-time.
                            This MUST be an absolute time
                            (i.e., seconds since midnight
                            January 1, 2000 UTC, modulo 2^32).

5.5.11.  OPTION_F_PROTOCOL_VERSION

   The protocol version allows one failover partner to determine the
   version of the protocol being used by the other partner, to allow for
   changes and upgrades in the future.  Two components are provided, to
   allow large and small changes to be represented in one 32-bit number.
   The intent is that large changes would result in an increment of the
   value of major-version, while small changes would result in an
   increment of the value of minor-version.  As subsequent updates and
   extensions of this document can define changes to these values in any
   way deemed appropriate, no attempt is made to further define "large"
   and "small" in this document.

Top      Up      ToC       Page 33 
   This option consists of two unsigned 16-bit integers in network byte
   order.

   The code for this option is 127.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   OPTION_F_PROTOCOL_VERSION   |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        major-version          |        minor-version          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code       OPTION_F_PROTOCOL_VERSION (127)
    option-len        4
    major-version     The major version of the protocol.  Initially 1.
    minor-version     The minor version of the protocol.  Initially 0.

5.5.12.  OPTION_F_KEEPALIVE_TIME

   This option specifies 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".

   This is an unsigned 32-bit integer in network byte order.

   The code for this option is 128.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    OPTION_F_KEEPALIVE_TIME    |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         keepalive-time                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code       OPTION_F_KEEPALIVE_TIME (128)
    option-len        4
    receive-time      The keepalive-time.  An interval of seconds.

Top      Up      ToC       Page 34 
5.5.13.  OPTION_F_RECONFIGURE_DATA

   This option contains the information necessary for one failover
   partner to use the reconfigure-key created on the other failover
   partner.

   The code for this option is 129.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   OPTION_F_RECONFIGURE_DATA   |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        reconfigure-time                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               .
    .                                                               .
    .                        reconfigure-key                        .
    .                           (variable)                          .
    .                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code         OPTION_F_RECONFIGURE_DATA (129)
    option-len          4 + length of reconfigure-key
    reconfigure-time    Time at which reconfigure-key was created.
                        This MUST be an absolute time
                        (i.e., seconds since midnight
                        January 1, 2000 UTC, modulo 2^32).
    reconfigure-key     The reconfigure key

Top      Up      ToC       Page 35 
5.5.14.  OPTION_F_RELATIONSHIP_NAME

   This option specifies a name for this failover relationship.  It is
   used to distinguish between relationships when there are multiple
   failover relationships between two failover servers.

   This is a UTF-8 encoded text string suitable for display to an end
   user.  It MUST NOT be null-terminated.

   The code for this option is 130.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   OPTION_F_RELATIONSHIP_NAME  |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               .
    .                                                               .
    .                       relationship-name                       .
    .                           (variable)                          .
    .                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code          OPTION_F_RELATIONSHIP_NAME (130)
    option-len           length of relationship-name
    relationship-name    A UTF-8 encoded text string suitable for
                         display to an end user.  MUST NOT be
                         null-terminated.

Top      Up      ToC       Page 36 
5.5.15.  OPTION_F_SERVER_FLAGS

   The OPTION_F_SERVER_FLAGS option specifies information associated
   with the failover endpoint sending the option.

   This is an unsigned byte.

   The code for this option is 131.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     OPTION_F_SERVER_FLAGS     |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  server-flags |
    +-+-+-+-+-+-+-+-+

    option-code       OPTION_F_SERVER_FLAGS (131)
    option-len        1
    server-flags      The server flags.  See below:

     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |   MBZ   |A|S|C|
    +-+-+-+-+-+-+-+-+

    The bits (numbered from the most significant bit in network
    byte order) are used as follows:

    0-4:   MBZ
           Must be zero.
    5 (A): ACK_STARTUP
           Set to 1 to indicate that the OPTION_F_SERVER_FLAGS option
           that was most recently received contained the
           STARTUP bit set.
    6 (S): STARTUP
           MUST be set to 1 whenever the server is in STARTUP state.
    7 (C): COMMUNICATED
           Set to 1 to indicate that the sending server has
           communicated with its partner.

Top      Up      ToC       Page 37 
5.5.16.  OPTION_F_SERVER_STATE

   The OPTION_F_SERVER_STATE option specifies the endpoint state of the
   server sending the option.

   This is an unsigned byte.

   The code for this option is 132.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     OPTION_F_SERVER_STATE     |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  server-state |
    +-+-+-+-+-+-+-+-+

    option-code       OPTION_F_SERVER_STATE (132)
    option-len        1
    server-state      Failover endpoint state

   Value   Server State
   -----   -------------------------------------------------------------
   0       reserved
   1       STARTUP                      Startup state (1)
   2       NORMAL                       Normal state
   3       COMMUNICATIONS-INTERRUPTED   Communications interrupted
   4       PARTNER-DOWN                 Partner down
   5       POTENTIAL-CONFLICT           Synchronizing
   6       RECOVER                      Recovering bindings from partner
   7       RECOVER-WAIT                 Waiting out MCLT after RECOVER
   8       RECOVER-DONE                 Interlock state prior to NORMAL
   9       RESOLUTION-INTERRUPTED       Comm. failed during resolution
   10      CONFLICT-DONE                Primary resolved its conflicts

   These states are discussed in detail in Section 8.

   (1) The STARTUP state is never sent to the partner server; it is
       indicated by the STARTUP bit in the OPTION_F_SERVER_FLAGS option
       (see Section 8.3).

Top      Up      ToC       Page 38 
5.5.17.  OPTION_F_START_TIME_OF_STATE

   The OPTION_F_START_TIME_OF_STATE option specifies the time at which
   the associated state began to hold its current value.  When this
   option appears in a STATE message, the state to which it refers is
   the server endpoint state.  When it appears in an IA_NA-options,
   IA_TA-options, or IA_PD-options field, the state to which it refers
   is the binding-status value in the OPTION_IA_NA, OPTION_IA_TA, or
   OPTION_IA_PD option, respectively.  This MUST be an absolute time
   (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).

   This is an unsigned 32-bit integer in network byte order.

   The code for this option is 133.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  OPTION_F_START_TIME_OF_STATE |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      start-time-of-state                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code            OPTION_F_START_TIME_OF_STATE (133)
    option-len             4
    start-time-of-state    The start time of the current state.
                           This MUST be an absolute time (i.e., seconds
                           since midnight January 1, 2000 UTC,
                           modulo 2^32).

5.5.18.  OPTION_F_STATE_EXPIRATION_TIME

   The OPTION_F_STATE_EXPIRATION_TIME option specifies the time at which
   the current state of this lease will expire.  This MUST be an
   absolute time (i.e., seconds since midnight January 1, 2000 UTC,
   modulo 2^32).

   Note that states other than ACTIVE may have a time associated with
   them.  In particular, EXPIRED might have a time associated with it,
   in the event that some sort of "grace period" existed where the lease
   would not be reused for a period after the lease expired.  The
   ABANDONED state might have a time associated with it, in the event
   that the servers participating in failover had a time after which an
   ABANDONED lease might be placed back into a pool for allocation to a
   client.  In general, if there is an OPTION_STATE_EXPIRATION_TIME
   associated with a particular state, that indicates that the
   associated state will expire and move to a different state at
   that time.

Top      Up      ToC       Page 39 
   This is an unsigned 32-bit integer in network byte order.

   The code for this option is 134.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | OPTION_F_STATE_EXPIRATION_TIME|           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     state-expiration-time                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code              OPTION_F_STATE_EXPIRATION_TIME (134)
    option-len               4
    state-expiration-time    The time at which the current state of the
                             lease will expire.  This MUST be an
                             absolute time (i.e., seconds since midnight
                             January 1, 2000 UTC, modulo 2^32).

5.6.  Status Codes

   The following new status codes are defined to be used in the
   OPTION_STATUS_CODE option.

   AddressInUse (16)
      One client on one server has leases that are in conflict with the
      leases that the client has on another server.  Alternatively, the
      address could be associated with a different Identity Association
      Identifier (IAID) on each server.

   ConfigurationConflict (17)
      The configuration implied by the information in a BNDUPD message
      (e.g., the IPv6 address or prefix address) is in direct conflict
      with the information known to the receiving server.

   MissingBindingInformation (18)
      There is insufficient information in a BNDUPD message to
      effectively process it.

   OutdatedBindingInformation (19)
      The information in a server's binding database conflicts with the
      information found in an incoming BNDUPD message and the server
      believes that the information in its binding database more
      accurately reflects reality.

   ServerShuttingDown (20)
      The server is undergoing an operator-directed or otherwise planned
      shutdown.

Top      Up      ToC       Page 40 
   DNSUpdateNotSupported (21)
      A server receives a BNDUPD message with DNS update information
      included and the server doesn't support DNS update.

   ExcessiveTimeSkew (22)
      A server detects that the time skew between its current time and
      its partner's current time is greater than 5 seconds.



(page 40 continued on part 3)

Next Section