Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8156

DHCPv6 Failover Protocol

Pages: 96
Proposed Standard
Part 2 of 5 – Pages 19 to 40
First   Prev   Next

Top   ToC   RFC8156 - Page 19   prevText

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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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   ToC   RFC8156 - 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