RFC 8156
DHCPv6 Failover Protocol
Pages: 96
Proposed Standard
Proposed Standard
Part 2 of 5 – Pages 19 to 40
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.
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.
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.
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
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.
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.
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
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 10355.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) . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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).
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 allowed5.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
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
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.
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.
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
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.
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.
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).
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.
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.
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)