GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8156

Internet Engineering Task Force (IETF) T. Mrugalski Request for Comments: 8156 ISC Category: Standards Track K. Kinnear ISSN: 2070-1721 Cisco

                                                             June 2017
                      DHCPv6 Failover Protocol

Abstract

 DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6
 (DHCPv6)" (RFC 3315) does not offer server redundancy.  This document
 defines a protocol implementation to provide DHCPv6 failover, a
 mechanism for running two servers with the capability for either
 server to take over clients' leases in case of server failure or
 network partition.  It meets the requirements for DHCPv6 failover
 detailed in "DHCPv6 Failover Requirements" (RFC 7031).

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc8156.

Copyright Notice

 Copyright (c) 2017 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Mrugalski & Kinnear Standards Track [Page 1] RFC 8156 DHCPv6 Failover Protocol June 2017

Table of Contents

 1. Introduction ....................................................5
 2. Requirements Language ...........................................5
 3. Glossary ........................................................6
 4. Failover Concepts and Mechanisms ...............................10
    4.1. Required Server Configuration .............................10
    4.2. IPv6 Address and Delegable Prefix Allocation ..............10
         4.2.1. Independent Allocation .............................10
                4.2.1.1. Independent Allocation Algorithm ..........11
         4.2.2. Proportional Allocation ............................11
                4.2.2.1. Reallocating Leases .......................13
    4.3. Lazy Updates ..............................................14
    4.4. Maximum Client Lead Time (MCLT) ...........................14
         4.4.1. MCLT Example .......................................16
 5. Message and Option Definitions .................................19
    5.1. Message Framing for TCP ...................................19
    5.2. Failover Message Format ...................................19
    5.3. Messages ..................................................20
         5.3.1. BNDUPD .............................................20
         5.3.2. BNDREPLY ...........................................20
         5.3.3. POOLREQ ............................................20
         5.3.4. POOLRESP ...........................................21
         5.3.5. UPDREQ .............................................21
         5.3.6. UPDREQALL ..........................................21
         5.3.7. UPDDONE ............................................21
         5.3.8. CONNECT ............................................21
         5.3.9. CONNECTREPLY .......................................22
         5.3.10. DISCONNECT ........................................22
         5.3.11. STATE .............................................22
         5.3.12. CONTACT ...........................................22
    5.4. Transaction-id ............................................22
    5.5. Options ...................................................23
         5.5.1. OPTION_F_BINDING_STATUS ............................23
         5.5.2. OPTION_F_CONNECT_FLAGS .............................24
         5.5.3. OPTION_F_DNS_REMOVAL_INFO ..........................25
                5.5.3.1. OPTION_F_DNS_HOST_NAME ....................26
                5.5.3.2. OPTION_F_DNS_ZONE_NAME ....................26
                5.5.3.3. OPTION_F_DNS_FLAGS ........................27
         5.5.4. OPTION_F_EXPIRATION_TIME ...........................28
         5.5.5. OPTION_F_MAX_UNACKED_BNDUPD ........................29
         5.5.6. OPTION_F_MCLT ......................................29
         5.5.7. OPTION_F_PARTNER_LIFETIME ..........................30
         5.5.8. OPTION_F_PARTNER_LIFETIME_SENT .....................30
         5.5.9. OPTION_F_PARTNER_DOWN_TIME .........................31
         5.5.10. OPTION_F_PARTNER_RAW_CLT_TIME .....................32
         5.5.11. OPTION_F_PROTOCOL_VERSION .........................32

Mrugalski & Kinnear Standards Track [Page 2] RFC 8156 DHCPv6 Failover Protocol June 2017

         5.5.12. OPTION_F_KEEPALIVE_TIME ...........................33
         5.5.13. OPTION_F_RECONFIGURE_DATA .........................34
         5.5.14. OPTION_F_RELATIONSHIP_NAME ........................35
         5.5.15. OPTION_F_SERVER_FLAGS .............................36
         5.5.16. OPTION_F_SERVER_STATE .............................37
         5.5.17. OPTION_F_START_TIME_OF_STATE ......................38
         5.5.18. OPTION_F_STATE_EXPIRATION_TIME ....................38
    5.6. Status Codes ..............................................39
 6. Connection Management ..........................................40
    6.1. Creating Connections ......................................40
         6.1.1. Sending a CONNECT Message ..........................41
         6.1.2. Receiving a CONNECT Message ........................42
         6.1.3. Receiving a CONNECTREPLY Message ...................43
    6.2. Endpoint Identification ...................................44
    6.3. Sending a STATE Message ...................................45
    6.4. Receiving a STATE Message .................................46
    6.5. Connection Maintenance Parameters .........................46
    6.6. Unreachability Detection ..................................47
 7. Binding Updates and Acks .......................................47
    7.1. Time Skew .................................................47
    7.2. Information Model .........................................48
    7.3. Times Required for Exchanging Binding Updates .............52
    7.4. Sending Binding Updates ...................................53
    7.5. Receiving Binding Updates .................................56
         7.5.1. Monitoring Time Skew ...............................56
         7.5.2. Acknowledging Reception ............................56
         7.5.3. Processing Binding Updates .........................57
         7.5.4. Accept or Reject? ..................................57
         7.5.5. Accepting Updates ..................................59
    7.6. Sending Binding Replies ...................................61
    7.7. Receiving Binding Acks ....................................63
    7.8. BNDUPD/BNDREPLY Data Flow .................................65
 8. Endpoint States ................................................66
    8.1. State Machine Operation ...................................66
    8.2. State Machine Initialization ..............................69
    8.3. STARTUP State .............................................70
         8.3.1. Operation in STARTUP State .........................70
         8.3.2. Transition out of STARTUP State ....................70
    8.4. PARTNER-DOWN State ........................................72
         8.4.1. Operation in PARTNER-DOWN State ....................72
         8.4.2. Transition out of PARTNER-DOWN State ...............73
    8.5. RECOVER State .............................................74
         8.5.1. Operation in RECOVER State .........................74
         8.5.2. Transition out of RECOVER State ....................74
    8.6. RECOVER-WAIT State ........................................76
         8.6.1. Operation in RECOVER-WAIT State ....................76
         8.6.2. Transition out of RECOVER-WAIT State ...............76

Mrugalski & Kinnear Standards Track [Page 3] RFC 8156 DHCPv6 Failover Protocol June 2017

    8.7. RECOVER-DONE State ........................................77
         8.7.1. Operation in RECOVER-DONE State ....................77
         8.7.2. Transition out of RECOVER-DONE State ...............77
    8.8. NORMAL State ..............................................77
         8.8.1. Operation in NORMAL State ..........................78
         8.8.2. Transition out of NORMAL State .....................78
    8.9. COMMUNICATIONS-INTERRUPTED State ..........................79
         8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State ......80
         8.9.2. Transition out of COMMUNICATIONS-INTERRUPTED
                State ..............................................80
    8.10. POTENTIAL-CONFLICT State .................................82
         8.10.1. Operation in POTENTIAL-CONFLICT State .............82
         8.10.2. Transition out of POTENTIAL-CONFLICT State ........82
    8.11. RESOLUTION-INTERRUPTED State .............................83
         8.11.1. Operation in RESOLUTION-INTERRUPTED State .........84
         8.11.2. Transition out of RESOLUTION-INTERRUPTED State ....84
    8.12. CONFLICT-DONE State ......................................84
         8.12.1. Operation in CONFLICT-DONE State ..................85
         8.12.2. Transition out of CONFLICT-DONE State .............85
 9. DNS Update Considerations ......................................85
    9.1. Relationship between Failover and DNS Update ..............86
    9.2. Exchanging DNS Update Information .........................87
    9.3. Adding RRs to the DNS .....................................89
    9.4. Deleting RRs from the DNS .................................90
    9.5. Name Assignment with No Update of DNS .....................91
 10. Security Considerations .......................................91
 11. IANA Considerations ...........................................92
 12. References ....................................................94
    12.1. Normative References .....................................94
    12.2. Informative References ...................................96
 Acknowledgements ..................................................96
 Authors' Addresses ................................................96

Mrugalski & Kinnear Standards Track [Page 4] RFC 8156 DHCPv6 Failover Protocol June 2017

1. Introduction

 This document defines a DHCPv6 failover protocol, which is a
 mechanism for running two DHCPv6 servers [RFC3315] with the
 capability for either server to take over clients' leases in case of
 server failover or network partition.  For a general overview of
 DHCPv6 failover problems, use cases, benefits, and shortcomings, see
 [RFC7031].
 The failover protocol provides a means for cooperating DHCP servers
 to work together to provide a service to DHCP clients with
 availability that is increased beyond the availability that could be
 provided by a single DHCP server operating alone.  It is designed to
 protect DHCP clients against server unreachability, including server
 failure and network partition.  It is possible to deploy exactly two
 servers that are able to continue providing a lease for an IPv6
 address [RFC3315] or on an IPv6 prefix [RFC3633] without the DHCP
 client experiencing lease expiration or a reassignment of a lease to
 a different IPv6 address or prefix in the event of failure by one or
 the other of the two servers.
 The failover protocol defines an active-passive mode, sometimes also
 called a "hot standby" model.  This means that during normal
 operation one server is active (i.e., it actively responds to
 clients' requests) while the second is passive (i.e., it receives
 clients' requests but responds only to those specifically directed to
 it).  The secondary server maintains a copy of the binding database
 and is ready to take over all incoming queries in case the primary
 server fails.
 The failover protocol is designed to provide lease stability for
 leases with valid lifetimes beyond a short period.  The DHCPv6
 failover protocol MUST NOT be used for new leases shorter than
 30 seconds.  Leases reaching the end of their lifetimes are not
 affected by this restriction.
 The failover protocol fulfills all DHCPv6 failover requirements
 defined in [RFC7031].

2. Requirements Language

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
 "OPTIONAL" in this document are to be interpreted as described in
 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
 capitals, as shown here.

Mrugalski & Kinnear Standards Track [Page 5] RFC 8156 DHCPv6 Failover Protocol June 2017

3. Glossary

 This is a supplemental glossary that should be used in combination
 with the definitions in Section 2 of RFC 7031 [RFC7031].
 o  Absolute Time
    "Absolute time" refers to the time in seconds since midnight
    January 1, 2000 UTC, modulo 2^32.
 o  Address Lease
    "Address lease" refers to a lease involving an IPv6 address.
    Typically used when it is necessary to distinguish the lease for
    an IPv6 address from a lease for a DHCP prefix.  See the
    definitions for "delegated prefix" and "prefix lease" below.
 o  auto-partner-down
    "auto-partner-down" refers to a capability where a failover server
    will move from COMMUNICATIONS-INTERRUPTED state to PARTNER-DOWN
    state automatically, without operator intervention.
 o  Available (Lease or Prefix)
    A lease or delegable prefix is available if it could be allocated
    for use by a DHCP client.  It is available on the main server when
    it is in the FREE state and available on the secondary server when
    it is in the FREE-BACKUP state.  The term "available" is sometimes
    used when it would be awkward to say "FREE on the primary server
    and FREE-BACKUP on the secondary server".
 o  Binding-Status
    A lease can hold a variety of states (see Section 5.5.1 for a
    list); these are also referred to as the "binding-status" of the
    lease.
 o  Delegable Prefix
    "Delegable prefix" refers to a prefix from which other prefixes
    may be delegated, using the mechanisms described in [RFC3633].  A
    prefix that has been delegated is known as a "delegated prefix" or
    a "prefix lease".

Mrugalski & Kinnear Standards Track [Page 6] RFC 8156 DHCPv6 Failover Protocol June 2017

 o  Delegated Prefix
    A delegated prefix is a prefix that has been delegated to a DHCP
    client as described in [RFC3633].  Depending on the context, a
    delegated prefix may also be described as a "prefix lease" when it
    is necessary to distinguish it from an "address lease".
 o  DHCP Prefix
    A DHCP prefix is part of the IPv6 address space configured to be
    managed by a DHCP server.
 o  Failover Endpoint
    The failover protocol permits a unique failover "endpoint" for
    each failover relationship in which a failover server
    participates.  The failover relationship is defined by a
    relationship name and includes
  • the failover partner IP address,
  • the role this server takes with respect to that partner

(primary or secondary), and

  • the prefixes from which addresses can be leased, as well as

prefixes from which other prefixes can be delegated (delegable

       prefixes), that are associated with that relationship.
    The failover endpoint can take actions and hold unique states.
    Typically, there is one failover endpoint per partner (server),
    although there may be more.
 o  Failover Communication
    "Failover communication" refers to all messages exchanged between
    partners.
 o  Independent Allocation
    "Independent allocation" refers to an allocation algorithm that
    splits the available pool of address leases between the primary
    and secondary servers.  It is used for IPv6 address allocations.
    See Section 4.2.1.

Mrugalski & Kinnear Standards Track [Page 7] RFC 8156 DHCPv6 Failover Protocol June 2017

 o  Lease
    A lease is an association of a DHCP client with an IPv6 address or
    delegated prefix.  This might refer to either an existing
    association or a potential association.
 o  MCLT (Maximum Client Lead Time)
    The fundamental relationship on which much of the correctness of
    the failover protocol depends is that the lease expiration time
    known to a DHCP client MUST NOT be greater by more than the MCLT
    beyond the later of the partner lifetime acknowledged by that
    server's failover partner or the current time (i.e., now).  See
    Section 4.4.
 o  Partner
    The other DHCP server that participates in a failover relationship
    is referred to as the "partner".  When the role (primary or
    secondary) is not important, the other server is referred to as a
    "failover partner" or sometimes simply "partner".
 o  Prefix Lease
    A prefix lease is a lease involving a prefix that is delegated or
    could be delegated, as opposed to a lease for a single IPv6
    address.  A prefix lease can also be described as a "delegated
    prefix".
 o  Primary Server
    The primary server is the first of the two DHCP servers that
    participate in a failover relationship.  When both servers are
    operating, this server handles most of the client traffic.  Its
    failover partner is referred to as the "secondary server".
 o  Proportional Allocation
    "Proportional allocation" is an allocation algorithm that splits
    the delegable prefixes between the primary and secondary servers
    and maintains a more or less fixed proportion of the delegable
    prefixes between both servers.  See Section 4.2.2.

Mrugalski & Kinnear Standards Track [Page 8] RFC 8156 DHCPv6 Failover Protocol June 2017

 o  Renew Responsive
    A server that is "renew responsive" will respond to valid DHCP
    client messages that are directed to it by having an
    OPTION_SERVERID option in the message that contains the DHCP
    Unique Identifier (DUID) of the renew responsive server.  See
    [RFC3315].
 o  Responsive
    A server that is responsive will respond to all valid DHCP client
    messages.
 o  Secondary Server
    The secondary server is the second of the two DHCP servers that
    participate in a failover relationship.  Its failover partner is
    referred to as the "primary server" (as defined above).  When both
    servers are operating, this server (the secondary) typically does
    not handle client traffic and acts as a backup to the primary
    server.  However, it will respond to RENEW requests directed
    specifically to it.
 o  Server
    "Server" refers to a DHCP server that implements DHCPv6 failover.
    "Server" and "failover endpoint" are synonymous only if the server
    participates in only one failover relationship.
 o  State
    The term "state" is used in two ways in this document.  A failover
    endpoint is always in some state, and there are a series of states
    that a failover endpoint can move through.  See Section 8 for
    details of the failover endpoint states.  A lease also has a
    state, and this is sometimes referred to as a "binding-status".
    See Section 5.5.1 for a list of the states a lease can hold.
 o  Unresponsive
    A server that is unresponsive will not respond to DHCP client
    messages.

Mrugalski & Kinnear Standards Track [Page 9] RFC 8156 DHCPv6 Failover Protocol June 2017

4. Failover Concepts and Mechanisms

 The following concepts and mechanisms are necessary for the operation
 of the failover protocol.  They are not currently employed by DHCPv6
 [RFC3315].  The failover protocol provides support for all of these
 concepts and mechanisms.

4.1. Required Server Configuration

 Servers frequently have several kinds of leases available on a
 particular network segment.  The failover protocol assumes that both
 the primary server and the secondary server are configured
 identically with regard to the prefixes and links involved in DHCP.
 For delegable prefixes (involved in proportional allocation), the
 primary server is responsible for allocating to the secondary server
 the correct proportion of the available delegable prefixes.  IPv6
 addresses (involved in independent allocation) are allocated to the
 primary and secondary servers algorithmically and do not require an
 explicit message transfer to be distributed.

4.2. IPv6 Address and Delegable Prefix Allocation

 Currently, there are two allocation algorithms defined: one for
 address leases and one for prefix leases.

4.2.1. Independent Allocation

 In this allocation scheme, which is used for allocating individual
 IPv6 addresses, available IPv6 addresses are permanently (until
 server configuration changes) split between servers.  Available IPv6
 addresses are split between the primary and secondary servers as part
 of initial connection establishment.  Once IPv6 addresses are
 allocated to each server, there is no need to reassign them.  The
 IPv6 address allocation is algorithmic in nature and does not require
 a message exchange for each server to know which IPv6 addresses it
 has been allocated.  This algorithm is simpler than proportional
 allocation, since it does not require a rebalancing mechanism.  It
 also assumes that the pool assigned to each server will never be
 depleted.
 Once each server is assigned a pool of IPv6 addresses during initial
 connection establishment, it may allocate its assigned IPv6 addresses
 to clients.  Once a client releases a lease or its lease on an IPv6
 address expires, the returned IPv6 address returns to the pool for
 the server that leased it.  A lease on an IPv6 address can be renewed
 by a responsive server or by a renew responsive server.  When an IPv6
 address goes PENDING-FREE (see Section 7.2), it is owned by whichever
 server it is allocated to by the independent allocation algorithm.

Mrugalski & Kinnear Standards Track [Page 10] RFC 8156 DHCPv6 Failover Protocol June 2017

 IPv6 addresses, which use the independent allocation approach, will
 be ignored when a server processes a POOLREQ message.
 During COMMUNICATIONS-INTERRUPTED events, a partner MAY continue
 extending existing address leases as requested by clients.  An
 operational partner MUST NOT lease IPv6 addresses that were assigned
 to its downed partner and later expired or that were released or
 declined by a client.  When it is in PARTNER-DOWN state, a server
 MUST allocate new leases from its own pool.  It MUST NOT use its
 partner's pool to allocate new leases.

4.2.1.1. Independent Allocation Algorithm

 For each address that can be allocated, the primary server MUST
 allocate only IPv6 addresses when the low-order bit (i.e., bit 127)
 is equal to 1, and the secondary server MUST allocate only the IPv6
 addresses when the low-order bit (i.e., bit 127) is equal to 0.

4.2.2. Proportional Allocation

 In this allocation scheme, each server has its own pool of prefixes
 available for delegation, known as "delegable prefixes".  These
 delegable prefixes may be prefixes from which other prefixes can be
 delegated, or they may be prefixes that are the correct size for
 delegation but are not, at present, delegated to a particular client.
 Remaining delegable prefixes are split between the primary and
 secondary servers in a configured proportion.  Note that a delegated
 prefix (also known as a "prefix lease") is not "owned" by a
 particular server.  Only a delegable prefix that is available is
 owned by a particular server -- once it has been delegated (leased)
 to a client, it becomes a prefix lease and is not owned by either
 failover partner.  When it finally becomes available again, it will
 be initially owned by the primary server, and it may or may not be
 allocated to the secondary server by the primary server.
 The flow of a delegable prefix is as follows: initially, the
 delegable prefix is part of a set of delegable prefixes, all of which
 are initially owned by the primary server.  A delegable prefix may be
 allocated to the secondary server, and it is then owned by the
 secondary server.  Either server can allocate and delegate prefixes
 out of the delegable prefixes that they own.  Once these prefixes are
 delegated (leased) to clients, the servers cease to own them, and
 they are owned by the clients to which they have been delegated
 (leased).  When the client releases the delegated prefix or the lease
 on it expires, the prefix will again become available, will again be
 a delegable prefix, and will be owned by the primary.

Mrugalski & Kinnear Standards Track [Page 11] RFC 8156 DHCPv6 Failover Protocol June 2017

 A server delegates prefixes only from its own pool of delegable
 prefixes in all states except for PARTNER-DOWN.  In PARTNER-DOWN
 state, the operational partner can delegate prefixes from either pool
 (both its own, and its partner's after some time constraints have
 elapsed).  The operational partner SHOULD allocate from its own pool
 before using its partner's pool.  The allocation and maintenance of
 these pools of delegable prefixes are important, since the goal is to
 maintain a more or less constant ratio of delegable prefixes between
 the two servers.
 Each server knows which delegable prefixes are in its own pool as
 well as which are in its partner's pool, so that it can allocate
 delegable prefixes from its partner's pool without communication with
 its partner if that becomes necessary.
 The initial allocation of delegable prefixes from the primary to the
 secondary when the servers first integrate is triggered by the
 POOLREQ message from the secondary to the primary.  This is followed
 (at some point) by the POOLRESP message, where the primary tells the
 secondary that it received and processed the POOLREQ message.  The
 primary sends the allocated delegable prefixes to the secondary as
 prefix leases via BNDUPD messages.  The POOLRESP message may be sent
 before, during, or at the completion of the BNDUPD message exchanges
 that were triggered by the POOLREQ message.  The POOLREQ/POOLRESP
 message exchange is a trigger to the primary to perform a scan of its
 database and to ensure that the secondary has enough delegable
 prefixes (based on some configured ratio).
 The delegable prefixes are sent to the secondary as prefix leases
 using the BNDUPD message containing an OPTION_IAPREFIX with a state
 of FREE-BACKUP, which indicates that the prefix lease is now
 available for allocation by the secondary.  Once the message is sent,
 the primary MUST NOT use these prefixes for allocation to DHCP
 clients (except when the server is in PARTNER-DOWN state).
 The POOLREQ/POOLRESP message exchange initiated by the secondary is
 valid at any time both partners remain in contact, and the primary
 server SHOULD, whenever it receives the POOLREQ message, scan its
 database of delegable prefixes and determine if the secondary needs
 more delegable prefixes from any of the delegable prefixes that it
 currently owns.
 In order to support a reasonably dynamic balance of the leases
 between the failover partners, the primary server needs to do
 additional work to ensure that the secondary server has as many
 delegable prefixes as it needs (but that it doesn't have more than
 it needs).

Mrugalski & Kinnear Standards Track [Page 12] RFC 8156 DHCPv6 Failover Protocol June 2017

 The primary server SHOULD examine the balance of delegable prefixes
 between the primary and secondary for a particular prefix whenever
 the number of possibly delegable prefixes for either the primary or
 secondary changes by more than a predetermined amount.  Typically,
 this comparison would not involve actually comparing the count of
 existing instances of delegable prefixes but would instead involve
 determining the number of prefixes that could be delegated given the
 address ranges of the delegable prefixes allocated to each server.
 The primary server SHOULD adjust the delegable prefix balance as
 required to ensure the configured delegable prefix balance, except
 that the primary server SHOULD employ some threshold mechanism to
 such a balance adjustment in order to minimize the overhead of
 maintaining this balance.
 The primary server can, at any time, send an available delegable
 prefix to the secondary using a BNDUPD message with the state
 FREE-BACKUP.  The primary server can attempt to take an available
 delegable prefix away from the secondary by sending a BNDUPD message
 with the state FREE.  If the secondary accepts the BNDUPD message,
 then the lease is now available to the primary and not available to
 the secondary.  Of course, the secondary MUST reject that BNDUPD
 message if it has already allocated that lease to a DHCP client.

4.2.2.1. Reallocating Leases

 When the server is in PARTNER-DOWN state, there is a waiting period
 after which a delegated prefix can be reallocated to another client.
 For delegable prefixes that are "available" when the server enters
 PARTNER-DOWN state, the period is the MCLT from the entry into
 PARTNER-DOWN state.  For delegated prefixes that are not available
 when the server enters PARTNER-DOWN state, the period is the MCLT
 after the later of the following times: the acked-partner-lifetime,
 the partner-lifetime (if any), the expiration-time, or the entry into
 PARTNER-DOWN time.
 In any other state, a server cannot reallocate a delegated prefix
 from one client to another without first notifying its partner
 (through a BNDUPD message) and receiving acknowledgement (through a
 BNDREPLY message) that its partner is aware that the first client is
 not using the lease.
 Specifically, an "available" delegable prefix on a server may be
 allocated to any client.  A prefix that was delegated (leased) to a
 client and that expired or was released by that client would take on
 a new state -- EXPIRED or RELEASED, respectively.  The partner server
 would then be notified that this delegated prefix was EXPIRED or
 RELEASED through a BNDUPD message.  When the sending server received
 the BNDREPLY message for that delegated prefix showing that it was

Mrugalski & Kinnear Standards Track [Page 13] RFC 8156 DHCPv6 Failover Protocol June 2017

 FREE, it would move the lease from EXPIRED or RELEASED to FREE, and
 the prefix would be available for allocation by the primary server to
 any clients.
 A server MAY reallocate a delegated prefix in the EXPIRED or RELEASED
 state to the same client with no restrictions, provided it has not
 sent a BNDUPD message regarding the delegated prefix to its partner.
 This situation would exist if the prefix lease expired or was
 released after the transition into PARTNER-DOWN state, for instance.

4.3. Lazy Updates

 [RFC7031] includes the requirement that failover must not introduce
 significant performance impact on server response times (see
 Sections 7 and 5.2.2 of [RFC7031]).  In order to realize this
 requirement, a server implementing the failover protocol must be able
 to respond to a DHCP client without waiting to update its failover
 partner whenever the binding database changes.  The "lazy update"
 mechanism allows a server to allocate a new lease or extend an
 existing lease, respond to the DHCP client, and then update its
 failover partner as time permits.
 Although the "lazy update" mechanism does not introduce additional
 delays in server response times, it introduces other difficulties.
 The key problem with lazy update is that when a server fails after
 updating a DHCP client with a particular valid lifetime but before
 updating its failover partner, the failover partner will eventually
 believe that the client's lease has expired -- even though the DHCP
 client still retains a valid lease on that address or prefix.  It is
 also possible that the failover partner will have no record at all of
 the lease being assigned to the DHCP client.  Both of these issues
 are dealt with by using the MCLT when allocating or extending leases
 (see Section 4.4).

4.4. Maximum Client Lead Time (MCLT)

 In order to handle problems introduced by lazy updates (see
 Section 4.3), a period of time known as the "Maximum Client Lead
 Time" (MCLT) is defined and must be known to both the primary server
 and the secondary server.  Proper use of this time interval places an
 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.
 The MCLT is typically much less than the valid lifetime that a server
 has been configured to offer a client, and so some strategy must
 exist to allow a server to offer the configured valid lifetime to a
 client.  During a lazy update, the updating server updates its

Mrugalski & Kinnear Standards Track [Page 14] RFC 8156 DHCPv6 Failover Protocol June 2017

 failover partner with a partner lifetime that is longer than the
 valid lifetime previously given to the DHCP client and that is longer
 than the valid lifetime that the server has been configured to give a
 client.  This allows the server to give the configured valid lifetime
 to the client the next time the client renews its lease, since the
 time that it will give to the client will not be longer than the MCLT
 beyond the partner lifetime acknowledged by its partner or the
 current time.
 The fundamental relationship on which the failover protocol depends
 is as follows: the lease expiration time known to a DHCP client
 MUST NOT be greater by more than the MCLT beyond the later of the
 partner lifetime acknowledged by that server's failover partner or
 the current time.
 The remainder of this section makes the above fundamental
 relationship more explicit.
 The failover protocol requires a DHCP server to deal with several
 different lease intervals and places specific restrictions on their
 relationships.  The purpose of these restrictions is to allow the
 partner to be able to make certain assumptions in the absence of an
 ability to communicate between servers.
 In the following explanation, all of the lifetimes are "valid"
 lifetimes, in the context of [RFC3315].
 The different times are as follows:
 desired lifetime:
    The desired lifetime is the lease interval that a DHCP server
    would like to give to a DHCP client in the absence of any
    restrictions imposed by the failover protocol.  Its determination
    is outside of the scope of the failover protocol.  Typically, this
    is the result of external configuration of a DHCP server.
 actual lifetime:
    The actual lifetime is the lease interval that a DHCP server gives
    out to a DHCP client.  It may be shorter than the desired lifetime
    (as explained below).
 partner lifetime:
    The partner lifetime is the lease expiration interval the local
    server sends to its partner in a BNDUPD message.

Mrugalski & Kinnear Standards Track [Page 15] RFC 8156 DHCPv6 Failover Protocol June 2017

 acknowledged partner lifetime:
    The acknowledged partner lifetime is the partner lifetime the
    partner server has most recently acknowledged in a BNDREPLY
    message.

4.4.1. MCLT Example

 The following example demonstrates the MCLT concept in practice.  The
 values used are arbitrarily chosen and are not a recommendation for
 actual values.  The MCLT in this case is 1 hour.  The desired
 lifetime is 3 days, and its renewal time is half the lifetime.
 When a server makes an offer for a new lease on an IPv6 address to a
 DHCP client, it determines the desired lifetime (in this case,
 3 days).  It then examines the acknowledged partner lifetime (which,
 in this case, is zero) and determines the remainder of the time left
 to run, which is also zero.  It adds the MCLT to this value.  Since
 the actual lifetime cannot be allowed to exceed the remainder of the
 current acknowledged partner lifetime plus the MCLT, the offer made
 to the client is for the remainder of the current acknowledged
 partner lifetime (i.e., zero) plus the MCLT.  Thus, the actual
 lifetime is 1 hour (the MCLT).
 Once the server has sent the REPLY to the DHCP client, it will update
 its failover partner with the lease information using a BNDUPD
 message.  The partner lifetime will be composed of the T1 fraction
 (1/2) of the actual lifetime added to the desired lifetime.  Thus,
 the failover partner is updated using a BNDUPD message with a partner
 lifetime of 1/2 hour + 3 days.
 When the primary server receives a BNDREPLY to its update of the
 secondary server's (partner's) partner lifetime, it records that as
 the acknowledged partner lifetime.  A server MUST NOT send a BNDREPLY
 message in response to a BNDUPD message until it is sure that the
 information in the BNDUPD message has been updated in its lease
 database.  See Section 7.5.2.  Thus, the primary server in this case
 can be sure that the secondary server has recorded the partner
 lifetime in its stable storage when the primary server receives a
 BNDREPLY message from the secondary server.
 When the DHCP client attempts to renew at T1 (approximately 1/2 hour
 from the start of the lease), the primary server again determines the
 desired lifetime, which is still 3 days.  It then compares this with
 the original acknowledged partner lifetime (1/2 hour + 3 days) and
 adjusts for the time passed since the secondary was last updated
 (1/2 hour).  Thus, the remaining time for the acknowledged partner

Mrugalski & Kinnear Standards Track [Page 16] RFC 8156 DHCPv6 Failover Protocol June 2017

 interval is 3 days.  Adding the MCLT to this yields 3 days plus
 1 hour, which is more than the desired lifetime of 3 days.  So, the
 client may have its lease renewed for the desired lifetime -- 3 days.
 When the primary DHCP server updates the secondary DHCP server after
 the DHCP client's renewal REPLY is complete, it will calculate the
 partner lifetime as the T1 fraction of the actual client lifetime
 (1/2 of 3 days = 1.5 days).  To this it will add the desired lifetime
 of 3 days, yielding a total partner lifetime of 4.5 days.  In this
 way, the primary attempts to have the secondary always "lead" the
 client in its understanding of the client's lifetime so as to be able
 to always offer the client the desired lifetime.
 Once the initial actual client lifetime of the MCLT has passed, the
 failover protocol operates effectively like DHCP does today in its
 behavior concerning lifetimes.  However, the guarantee that the
 actual client lifetime will never exceed the partner server's
 remaining acknowledged partner lifetime by more than the MCLT allows
 full recovery from a variety of DHCP server failures.

Mrugalski & Kinnear Standards Track [Page 17] RFC 8156 DHCPv6 Failover Protocol June 2017

Fundamental relationship:

 lease time = floor( desired lifetime, acked-partner-lifetime + MCLT )
Initial conditions: MCLT = 1h, desired lifetime = 3d
           DHCPv6               Primary             Secondary
    time   Client               Server               Server
             | >-SOLICIT------>    |                    |
             |  acknowledged partner lifetime = 0       |
             |  lease time = floor( 3d, 0 + 1h ) = 1h   |
             |   <-----ADVERTISE-< |                    |
             |    lease-time = 1h  |                    |
             | >-REQUEST------>    |                    |
      t      |   <---------REPLY-< |                    |
             |    lease-time = 1h  |                    |
             |                     |  >-BNDUPD------>   |
             |                     |  partner-lifetime = 1/2h + 3d
             |                     |    <----BNDREPLY-< |
             |                     |  partner-lifetime = 1/2h + 3d
             |acknowledged partner lifetime = 1/2h + 3d |
1/2h passes ...                   ...                  ...
   t+1/2h    | >-RENEW-------->    |                    |
             |   acknowledged partner lifetime = 3d     |
             |   lease time = floor( 3d, 3d + 1h ) = 3d |
             |   <---------REPLY-< |                    |
             |   lease-time = 3d   |                    |
             |                     | >-BNDUPD------->   |
             |                     |  partner-lifetime = 1.5d + 3d
             |                     |    <----BNDREPLY-< |
             |                     |  partner-lifetime = 1.5d + 3d
             |acknowledged partner lifetime = 1.5d + 3d |
1.5d passes ...                   ...                  ...
             |                     |                    |

t+1.5d + 1/2h | >-RENEW——–> | |

             |  acknowledged partner lifetime = 3d      |
             |   lease time = floor( 3d, 3d + 1h ) = 3d |
             |   <---------REPLY-< |                    |
             |   lease-time = 3d   |                    |
             |                     | >-BNDUPD------->   |
             |                     |  partner-lifetime = 1.5d + 3d
             |                     |    <----BNDREPLY-< |
             |                     |  partner-lifetime = 1.5d + 3d
             |acknowledged partner lifetime = 1.5d + 3d |
                        Figure 1: MCLT Example

Mrugalski & Kinnear Standards Track [Page 18] RFC 8156 DHCPv6 Failover Protocol June 2017

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.

Mrugalski & Kinnear Standards Track [Page 19] RFC 8156 DHCPv6 Failover Protocol June 2017

  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.

Mrugalski & Kinnear Standards Track [Page 20] RFC 8156 DHCPv6 Failover Protocol June 2017

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.

Mrugalski & Kinnear Standards Track [Page 21] RFC 8156 DHCPv6 Failover Protocol June 2017

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

Mrugalski & Kinnear Standards Track [Page 22] RFC 8156 DHCPv6 Failover Protocol June 2017

 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.

Mrugalski & Kinnear Standards Track [Page 23] RFC 8156 DHCPv6 Failover Protocol June 2017

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.

Mrugalski & Kinnear Standards Track [Page 24] RFC 8156 DHCPv6 Failover Protocol June 2017

 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

Mrugalski & Kinnear Standards Track [Page 25] RFC 8156 DHCPv6 Failover Protocol June 2017

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)                          .
  .                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Mrugalski & Kinnear Standards Track [Page 26] RFC 8156 DHCPv6 Failover Protocol June 2017

  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.

Mrugalski & Kinnear Standards Track [Page 27] RFC 8156 DHCPv6 Failover Protocol June 2017

 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).

Mrugalski & Kinnear Standards Track [Page 28] RFC 8156 DHCPv6 Failover Protocol June 2017

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

Mrugalski & Kinnear Standards Track [Page 29] RFC 8156 DHCPv6 Failover Protocol June 2017

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                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Mrugalski & Kinnear Standards Track [Page 30] RFC 8156 DHCPv6 Failover Protocol June 2017

  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).

Mrugalski & Kinnear Standards Track [Page 31] RFC 8156 DHCPv6 Failover Protocol June 2017

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.

Mrugalski & Kinnear Standards Track [Page 32] RFC 8156 DHCPv6 Failover Protocol June 2017

 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.

Mrugalski & Kinnear Standards Track [Page 33] RFC 8156 DHCPv6 Failover Protocol June 2017

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

Mrugalski & Kinnear Standards Track [Page 34] RFC 8156 DHCPv6 Failover Protocol June 2017

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.

Mrugalski & Kinnear Standards Track [Page 35] RFC 8156 DHCPv6 Failover Protocol June 2017

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.

Mrugalski & Kinnear Standards Track [Page 36] RFC 8156 DHCPv6 Failover Protocol June 2017

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).

Mrugalski & Kinnear Standards Track [Page 37] RFC 8156 DHCPv6 Failover Protocol June 2017

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.

Mrugalski & Kinnear Standards Track [Page 38] RFC 8156 DHCPv6 Failover Protocol June 2017

 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.

Mrugalski & Kinnear Standards Track [Page 39] RFC 8156 DHCPv6 Failover Protocol June 2017

 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.

6. Connection Management

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

6.1. Creating Connections

 Every primary server implementing the failover protocol MUST
 periodically attempt to create a TCP connection to the dhcp-failover
 port (647) of all of its configured partners, where the period is
 implementation dependent and SHOULD be configurable.  In the event
 that a connection has been rejected by a CONNECTREPLY message with an
 OPTION_STATUS_CODE option contained in it or a DISCONNECT message, a
 server SHOULD reduce the frequency with which it attempts to connect
 to that server, but it MUST continue to attempt to connect
 periodically.
 Every secondary server implementing the failover protocol MUST listen
 for TCP connection attempts on the dhcp-failover port (647) from a
 primary server.
 After a primary server successfully establishes a TCP connection to a
 secondary server, it MUST continue the connection process as
 described in Section 8.2 of [RFC7653].  In the language of that
 section, the primary failover server operates as the "requestor" and
 the secondary failover server operates as the "DHCP server".  The
 message that is sent over the newly established connection is a
 CONNECT message, instead of an ACTIVELEASEQUERY message.
 When a secondary server receives a connection attempt, the only
 information that the secondary server has is the IP address of the
 partner initiating a connection.  If it has any relationships with
 the connecting server for which it is a secondary server, it should

Mrugalski & Kinnear Standards Track [Page 40] RFC 8156 DHCPv6 Failover Protocol June 2017

 operate as described in Section 9.1 of [RFC7653], with the exception
 that instead of waiting for an Active Leasequery message it will wait
 for a CONNECT message.  Once it has received the CONNECT message, it
 will use the information in that message to determine which
 relationship this connection is to service.
 If it has no secondary relationships with the connecting server, it
 MUST drop the connection.
 To summarize -- a primary server MUST use a connection that it has
 initiated in order to send a CONNECT message.  Every server that is a
 secondary server in a relationship MUST listen for CONNECT messages
 from the primary server.
 When the CONNECT and CONNECTREPLY exchange successfully produces a
 working failover connection, the next message sent over a new
 connection is a STATE message.  See Section 6.3.  Upon the receipt of
 the STATE message, the receiver can consider communications "OK".

6.1.1. Sending a CONNECT Message

 The CONNECT message is sent with information about the failover
 configuration on the primary server.  The message MUST contain at
 least the following information in the options area:
 o  OPTION_F_PROTOCOL_VERSION containing the protocol version that the
    primary server will use when sending failover messages.
 o  OPTION_F_MCLT containing the configured MCLT.
 o  OPTION_F_KEEPALIVE_TIME containing the number of seconds (an
    interval) within which the server must receive a message from its
    partner, or it will assume that communications from the partner
    are not "OK".
 o  OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of
    BNDUPD messages that this server is prepared to accept over the
    failover connection without causing the connection to block.  This
    implements application-level flow control over the connection, so
    that a flood of BNDUPD messages does not cause the connection to
    block and thereby prevent other messages from being transmitted
    over the connection and received by the failover partner.

Mrugalski & Kinnear Standards Track [Page 41] RFC 8156 DHCPv6 Failover Protocol June 2017

 o  OPTION_F_RELATIONSHIP_NAME containing the name of the failover
    relationship to which this connection applies.  If there is no
    OPTION_F_RELATIONSHIP_NAME in the CONNECT message, it indicates
    that there is only a single relationship between this pair of
    primary and secondary servers.
 o  OPTION_F_CONNECT_FLAGS containing information about certain
    attributes of the connecting servers.

6.1.2. Receiving a CONNECT Message

 A server receiving a CONNECT message must process the information in
 the message and decide whether or not to accept the connection.  The
 processing is performed as follows:
 o  sent-time - The secondary server checks the sent-time to see if it
    is within 5 seconds of its current time.  See Section 7.1.  If it
    is not, return ExcessiveTimeSkew in the OPTION_STATUS_CODE to
    reject the CONNECT message.
 o  OPTION_F_PROTOCOL_VERSION - The secondary server decides if the
    protocol version of the primary server is supported by the
    secondary server.  If it is not, return NotSupported in the
    OPTION_STATUS_CODE to reject the CONNECT message.
 o  OPTION_F_MCLT - Use this MCLT supplied by the primary server.
    Remember this MCLT, and use it until a different MCLT is supplied
    by some subsequent CONNECT message.
 o  OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the
    FO_KEEPALIVE_TIME (Section 6.5) when implementing the
    Unreachability Detection algorithm described in Section 6.6.
 o  OPTION_F_MAX_UNACKED_BNDUPD - Ensure that the maximum amount of
    unacked BNDUPD messages queued to the primary server never exceeds
    the value in the OPTION_F_MAX_UNACKED_BNDUPD option.
 o  OPTION_F_CONNECT_FLAGS - Ensure that the secondary server can
    process information from the primary server as specified in the
    flags.  For example, if the secondary server cannot process prefix
    delegation with variable-sized prefixes delegated from the same
    delegable prefix and the primary server says that it can, the
    secondary should reject the connection.

Mrugalski & Kinnear Standards Track [Page 42] RFC 8156 DHCPv6 Failover Protocol June 2017

 A CONNECT message SHOULD always be followed by a CONNECTREPLY
 message, to either (1) accept the connection or (2) reject the
 connection by including an OPTION_STATUS_CODE option with a
 status-code indicating the reason for the rejection.  If accepting
 the connection attempt, then send a CONNECTREPLY message with the
 following information:
 o  OPTION_F_PROTOCOL_VERSION containing the protocol version being
    used by the secondary server when sending failover messages.
 o  OPTION_F_MCLT containing the MCLT currently in use on the
    secondary server.  This MUST equal the MCLT that was in the
    OPTION_F_MCLT option in the CONNECT message.
 o  OPTION_F_KEEPALIVE_TIME containing the number of seconds (an
    interval) within which the server must receive a message from its
    partner, or it will assume that communications from the partner
    are not "OK".
 o  OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of
    BNDUPD messages that this server is prepared to accept over the
    failover connection without causing the connection to block.  This
    implements application-level flow control over the connection, so
    that a flood of BNDUPD messages does not cause the connection to
    block and thereby prevent other messages from being transmitted
    over the connection and received by the failover partner.
 o  OPTION_F_CONNECT_FLAGS containing information describing the
    attributes of the secondary server that the primary needs to
    know about.
 After sending a CONNECTREPLY message to accept the primary server's
 CONNECT message, the secondary server MUST send a STATE message (see
 Section 6.3).

6.1.3. Receiving a CONNECTREPLY Message

 A server receiving a CONNECTREPLY message must process the
 information in the message and decide whether or not to continue to
 employ the connection.  The processing is performed as follows:
 o  OPTION_F_PROTOCOL_VERSION - The primary server decides if the
    protocol version in use by the secondary server is supported by
    the primary server.  If it is not, send a DISCONNECT message and
    drop the connection.  If it is supported, continue processing.  It
    is possible that the primary and secondary servers will each be
    sending different versions of the protocol to the other server.

Mrugalski & Kinnear Standards Track [Page 43] RFC 8156 DHCPv6 Failover Protocol June 2017

    The extent to which this is supported will be defined partly by
    as-yet-unknown differences in the protocols that the versions
    represent and partly by the capabilities of the two
    implementations involved in the failover relationship.
 o  OPTION_F_MCLT - Compare the MCLT received with the configured
    MCLT.  If they are different, send a DISCONNECT message and drop
    the connection.
 o  OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the
    FO_KEEPALIVE_TIME (Section 6.5) when implementing the
    Unreachability Detection algorithm described in Section 6.6.
 o  OPTION_F_MAX_UNACKED_BNDUPD - Ensure that the maximum amount of
    unacked BNDUPD messages queued to the secondary server never
    exceeds the value in the OPTION_F_MAX_UNACKED_BNDUPD option.
 o  OPTION_F_CONNECT_FLAGS - Ensure that the primary server can
    process information from the secondary server as specified in the
    flags.  For example, if the primary server cannot process prefix
    delegation with variable-sized prefixes delegated from the same
    delegable prefix and the secondary server says that it can, the
    primary should drop the connection.
 After receiving a CONNECTREPLY message that accepted the primary
 server's CONNECT message, the primary server MUST send a STATE
 message (see Section 6.3).

6.2. Endpoint Identification

 A failover endpoint is always associated with a set of DHCP prefixes
 that are configured on the DHCP server where the endpoint appears.  A
 DHCP prefix MUST NOT be associated with more than one failover
 endpoint.
 The failover protocol SHOULD be configured with one failover
 relationship between each pair of failover servers.  In this case,
 there is one failover endpoint for that relationship on each failover
 partner.  This failover relationship MUST have a unique name.
 Any failover endpoint can take actions and hold unique states.
 This document frequently describes the behavior of the failover
 protocol in terms of primary and secondary servers, not primary and
 secondary failover endpoints.  However, it is important to remember
 that every "server" described in this document is in reality a
 failover endpoint that resides in a particular process and that
 several failover endpoints may reside in the same server process.

Mrugalski & Kinnear Standards Track [Page 44] RFC 8156 DHCPv6 Failover Protocol June 2017

 It is not the case that there is a unique failover endpoint for each
 prefix that participates in a failover relationship.  On one server,
 there is (typically) one failover endpoint per partner, regardless of
 how many prefixes are managed by that combination of partner and
 role.  On a particular server, any given prefix that participates in
 failover will be associated with exactly one failover endpoint.
 When a connection is received from the partner, the unique failover
 endpoint to which the message is directed is determined solely by the
 IPv6 address of the partner, the relationship name, and the role of
 the receiving server.

6.3. Sending a STATE Message

 A server MUST send a STATE message to its failover partner whenever
 the state of the failover endpoint changes.  Sending the occasional
 duplicate STATE message will not cause any problems; note, however,
 that not updating the failover partner with information about a
 failover endpoint state change can, in many cases, cause the entire
 failover protocol to be inoperative.
 The STATE message is sent with information about the endpoint state
 of the failover relationship.  The STATE message MUST contain at
 least the following information in the options area:
 o  OPTION_F_SERVER_STATE containing the state of this failover
    endpoint.
 o  OPTION_F_SERVER_FLAGS containing the flag values associated with
    this failover endpoint.
 o  OPTION_F_START_TIME_OF_STATE containing the time when this became
    the state of this failover endpoint.
 o  OPTION_F_PARTNER_DOWN_TIME containing the time that this failover
    endpoint went into PARTNER-DOWN state if this server is in
    PARTNER-DOWN state.  If this server isn't in PARTNER-DOWN state,
    do not include this option.
 The server sending a STATE message SHOULD ensure that this
 information is written to stable storage prior to enqueuing it to its
 failover partner.

Mrugalski & Kinnear Standards Track [Page 45] RFC 8156 DHCPv6 Failover Protocol June 2017

6.4. Receiving a STATE Message

 A server receiving a STATE message must process the information in
 the message and decide how to react to the information.  The
 processing is performed as follows:
 o  OPTION_F_SERVER_STATE - If this represents a change in state for
    the failover partner, react according to the instructions in
    Section 8.1.  If the state is not PARTNER-DOWN, clear any memory
    of the partner-down-time.
 o  OPTION_F_SERVER_FLAGS - Remember these flags in an appropriate
    data area so they can be referenced later.
 o  OPTION_F_START_TIME_OF_STATE - Remember this information in an
    appropriate data area so it can be referenced later.
 o  OPTION_F_PARTNER_DOWN_TIME - If the value of the
    OPTION_F_SERVER_STATE is PARTNER-DOWN, remember this information
    in an appropriate data area so it can be referenced later.
 A server receiving a STATE message SHOULD ensure that this
 information is written to stable storage.

6.5. Connection Maintenance Parameters

 The following parameters and timers are used to ensure the integrity
 of the connections between two failover servers.
 Parameter                      Default  Description
 ---------------------------------------------------------------------
 FO_KEEPALIVE_TIMER             timer    counts down to time
                                         connection assumed dead
                                         due to lack of messages
 FO_KEEPALIVE_TIME              60       maximum time server will
                                         consider connection still up
                                         with no messages
 FO_CONTACT_PER_KEEPALIVE_TIME  4        number of CONTACT messages
                                         to send during partner's
                                         FO_KEEPALIVE_TIME period
 FO_SEND_TIMER                  timer    counts down to time to send
                                         next CONTACT message

Mrugalski & Kinnear Standards Track [Page 46] RFC 8156 DHCPv6 Failover Protocol June 2017

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

6.6. Unreachability Detection

 Each partner MUST maintain an FO_SEND_TIMER for each failover
 connection.  The FO_SEND_TIMER for a particular connection is reset
 to FO_SEND_TIME every time any message is transmitted on that
 connection, and the timer counts down once per second.  If the timer
 reaches zero, a CONTACT message is transmitted on that connection and
 the timer for that connection is reset to FO_SEND_TIME.  The CONTACT
 message may be transmitted at any time.  An implementation MAY use
 additional mechanisms to detect partner unreachability.
 The FO_SEND_TIME is initialized from the configured FO_KEEPALIVE_TIME
 divided by FO_CONTACT_PER_KEEPALIVE_TIME.  When a CONNECT or
 CONNECTREPLY message is received on a connection, the received
 OPTION_F_KEEPALIVE_TIME option is checked, and the value in that
 option is used to calculate the FO_SEND_TIME for that connection by
 dividing the value received by the configured
 FO_CONTACT_PER_KEEPALIVE_TIME.
 Each partner MUST maintain an FO_KEEPALIVE_TIMER for each failover
 connection.  This timer is initialized to FO_KEEPALIVE_TIME and
 counts down once per second.  It is reset to FO_KEEPALIVE_TIME
 whenever a message is received on that connection.  If it ever
 reaches zero, that connection is considered dead.  In addition, the
 FO_KEEPALIVE_TIME for that connection MUST be sent to the failover
 partner on every CONNECT or CONNECTREPLY message in the
 OPTION_F_KEEPALIVE_TIME option.

7. Binding Updates and Acks

7.1. Time Skew

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

Mrugalski & Kinnear Standards Track [Page 47] RFC 8156 DHCPv6 Failover Protocol June 2017

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

7.2. Information Model

 In most DHCP servers, a lease on an IPv6 address or a prefix can take
 on several different binding-status values, sometimes also called
 "lease states".  While no two DHCP server implementations will have
 exactly the same possible binding-status values, [RFC3315] enforces
 some commonality among the general semantics of the binding-status
 values used by various DHCP server implementations.
 In order to transmit binding database updates between one server and
 another using the failover protocol, some common binding-status
 values must be defined.  It is not expected that these values
 correspond to any actual implementation of DHCPv6 in a DHCP server,
 but rather that the binding-status values defined in this document
 should be convertible back and forth between those defined below and
 those in use by many DHCP server implementations.
 The lease binding-status values defined for the failover protocol are
 listed below.  Unless otherwise noted below, there MAY be client
 information associated with each of these binding-status values.
 ACTIVE - The lease is assigned to a client.  Client identification
    data MUST appear.
 EXPIRED - This value indicates that a client's binding on a given
    lease has expired.  When the partner acks the BNDUPD message of an
    expired lease, the server sets its internal state to PENDING-FREE.
    Client identification SHOULD appear.
 RELEASED - This value indicates that a client sent a RELEASE message.
    When the partner acks the BNDUPD message of a released lease, the
    server sets its internal state to PENDING-FREE.  Client
    identification SHOULD appear.

Mrugalski & Kinnear Standards Track [Page 48] RFC 8156 DHCPv6 Failover Protocol June 2017

 PENDING-FREE - Once a lease is expired or released, its state becomes
    PENDING-FREE.  Depending on which algorithm was used to allocate a
    given lease, PENDING-FREE may mean either FREE or FREE-BACKUP.
    Implementations do not have to implement this PENDING-FREE state
    but may choose to switch to the destination state directly.  For
    clarity of representation, this transitional PENDING-FREE state is
    treated as a separate state.
 FREE - This value is used when a DHCP server needs to communicate
    that a lease is unused by any client, but it was not just
    released, expired, or reset by a network administrator.  When the
    partner acks the BNDUPD message of a FREE lease, the server marks
    the lease as available for assignment by the primary server.  Note
    that on a secondary server running in PARTNER-DOWN state, after
    waiting the MCLT, the lease MAY be allocated to a client by the
    secondary server.  Client identification MAY appear and indicates,
    as a hint, the last client to have used this lease.
 FREE-BACKUP - This value indicates that this lease can be allocated
    by the secondary server to a client at any time.  Note that on the
    primary server running in PARTNER-DOWN state, after waiting the
    MCLT, the lease MAY be allocated to a client by the primary server
    if the proportional algorithm was used.  Client identification MAY
    appear and indicates, as a hint, the last client to have used this
    lease.
 ABANDONED - This value indicates that a lease is considered unusable
    by the DHCP system.  The primary reason for entering such a state
    is the reception of a DECLINE message for the lease.  Client
    identification MAY appear.
 RESET - This value indicates that this lease was made available by an
    operator command.  This is a distinct state so that the reason
    that the lease became FREE can be determined.  Client
    identification MAY appear.
 Which binding-status values are associated with a timeout is
 implementation dependent.  Some binding-status values, such as
 ACTIVE, will have a timeout value in all implementations, while
 others, such as ABANDONED, will have a timeout value in some
 implementations and not in others.  In some implementations, a
 binding-status value may be associated with a timeout in some
 circumstances and not in others.  The receipt of a BNDUPD message
 with a particular binding-status value and an
 OPTION_F_STATE_EXPIRATION_TIME indicates that this particular
 binding-status value is associated with a timeout.

Mrugalski & Kinnear Standards Track [Page 49] RFC 8156 DHCPv6 Failover Protocol June 2017

 The lease state machine is presented in Figure 2.  Most states are
 stationary, i.e., the lease stays in a given state until an external
 event triggers transition to another state.  The only transitive
 state is PENDING-FREE.  Once it is reached, the state machine
 immediately transitions to either FREE or FREE-BACKUP state.
                             +---------+
              /------------->|  ACTIVE |<--------------\
              |              +---------+               |
              |                |  |  |                 |
              |       /--(8)--/  (3)  \--(9)-\         |
              |      |            |           |        |
              |      V            V           V        |
              |  +-------+   +--------+   +---------+  |
              |  |EXPIRED|   |RELEASED|   |ABANDONED|  |
              |  +-------+   +--------+   +---------+  |
              |      |            |            |       |
              |      |            |           (10)     |
              |      |            |            V       |
              |      |            |       +---------+  |
              |      |            |       |  RESET  |  |
              |      |            |       +---------+  |
              |      |            |            |       |
              |       \--(4)--\  (4)  /--(4)--/        |
              |                |  |  |                 |
             (1)               V  V  V                (2)
              |              /---------\               |
              |              | PENDING-|               |
              |              |  FREE   |               |
              |              \---------/               |
              |                 |   |                  |
              |         /-(5)--/     \-(6)-\           |
              |        |                    |          |
              |        V                    V          |
              |    +-------+         +-----------+     |
              \----|  FREE |<--(7)-->|FREE-BACKUP|-----/
                   +-------+         +-----------+
                        PENDING-FREE transition
                     Figure 2: Lease State Machine

Mrugalski & Kinnear Standards Track [Page 50] RFC 8156 DHCPv6 Failover Protocol June 2017

 Transitions between states will result from the following events:
 (1)   The primary server allocates a lease.
 (2)   The secondary server allocates a lease.
 (3)   The client sends RELEASE, and the lease is released.
 (4)   The partner acknowledges the state change.  This transition MAY
       also occur if the server is in PARTNER-DOWN state and the MCLT
       has passed since the entry into RELEASED, EXPIRED, or RESET
       states.
 (5)   The lease belongs to a pool that is governed by proportional
       allocation, or independent allocation is used and this lease
       belongs to the primary server's pool.
 (6)   The lease belongs to a pool that is governed by independent
       allocation, and the lease belongs to the secondary server.
 (7)   A pool rebalance event occurs (POOLREQ/POOLRESP messages are
       exchanged).  Delegable prefixes belonging to the primary server
       can be assigned to the secondary server's pool (transition from
       FREE to FREE-BACKUP) or vice versa.
 (8)   The lease has expired.
 (9)   A DECLINE message is received, or a lease is deemed unusable
       for other reasons.
 (10)  An administrative action is taken to restore an abandoned lease
       to a usable state.  This transition MAY occur due to
       implementation-specific handling of an ABANDONED lease.  One
       possible example of this is a Neighbor Discovery or ICMPv6 Echo
       check to see if the address is still in use.

Mrugalski & Kinnear Standards Track [Page 51] RFC 8156 DHCPv6 Failover Protocol June 2017

 The lease that is no longer in use (due to expiration or release)
 becomes PENDING-FREE.  Depending on what allocation algorithm is
 used, the lease that is no longer in use returns to the primary pool
 (FREE) or the secondary pool (FREE-BACKUP).  The conditions for
 specific transitions are depicted in Figure 3.
               +----------------+---------+-----------+
               | \   Lease owner|         |           |
               |  \----------\  | Primary | Secondary |
               |Algorithm     \ |         |           |
               +----------------+---------+-----------+
               | Proportional   | FREE    |FREE-BACKUP|
               | Independent    | FREE    |    FREE   |
               +----------------+---------+-----------+
               Figure 3: PENDING-FREE State Transitions

7.3. Times Required for Exchanging Binding Updates

 Each server must keep track of the following specific times beyond
 those required by the base DHCP specification [RFC3315].
 expiration-time
    The greatest lifetime that this server has ever acked to its
    failover partner in a BNDREPLY message.
 acked-partner-lifetime
    The greatest lifetime that the failover partner has ever acked to
    this server in a BNDREPLY message.
 partner-lifetime
    The time value that will be sent (or that has been sent) to the
    partner to indicate the time after which the partner can consider
    the lease expired.  When a BNDUPD message is received, this value
    can be updated from the received OPTION_F_EXPIRATION_TIME.
 client-last-transaction-time
    The time when this server most recently interacted with the client
    associated with this lease.
 partner-raw-clt-time
    The time when the partner most recently interacted with the client
    associated with this lease.  This time remains exactly as it was
    received by this server and MUST NOT be adjusted in any way.

Mrugalski & Kinnear Standards Track [Page 52] RFC 8156 DHCPv6 Failover Protocol June 2017

 start-time-of-state
    The time when the binding-status of this lease was changed to its
    current value.
 state-expiration-time
    The time when the current state of this lease will expire.

7.4. Sending Binding Updates

 Every BNDUPD message contains information about either (1) a single
 client binding in an OPTION_CLIENT_DATA option that includes IAADDR
 or IAPREFIX options associated with that client or (2) a single
 prefix lease in an OPTION_IAPREFIX option for prefixes that are
 currently not associated with any clients.
 All information about a particular client binding MUST be contained
 in a single OPTION_CLIENT_DATA option (see Section 4.1.2.2 of
 [RFC5007]).  The OPTION_CLIENT_DATA option contains at least the data
 shown below in its client-options section:
 o  OPTION_CLIENTID containing the DUID of the client most recently
    associated with this lease MUST appear.
 o  OPTION_LQ_BASE_TIME containing the absolute time that the
    information was placed in this OPTION_CLIENT_DATA option (see
    Section 6.3.1 of [RFC7653]) MUST appear.
 o  OPTION_VSS (see Section 3.4 of [RFC6607]).  This option MUST NOT
    appear if the information in this OPTION_CLIENT_DATA option is
    associated with the global, default VPN.  This option MUST appear
    if the information in this OPTION_CLIENT_DATA option is associated
    with a VPN other than the global, default VPN.  Support of
    [RFC6607] is not required, and if it is not supported, then an
    OPTION_VSS MUST NOT appear.  If [RFC6607] is supported, then an
    OPTION_VSS MUST appear if and only if a VPN other than the global,
    default VPN is used.
 o  OPTION_F_RECONFIGURE_DATA containing the time and reconfigure key,
    if any.
 o  OPTION_LQ_RELAY_DATA containing information described in
    Section 4.1.2.4 of [RFC5007], if any exists.

Mrugalski & Kinnear Standards Track [Page 53] RFC 8156 DHCPv6 Failover Protocol June 2017

 o  OPTION_IA_NA or OPTION_IA_TA for an IPv6 address, or OPTION_IA_PD
    for an IPv6 prefix.  More than one of either of these options MAY
    appear if more than one of them are associated with this client.
    At least one of an OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD
    must appear.
  • IAID - Identity Association used by the client, while obtaining

a given lease. Note that (1) one client may use many IAIDs

       simultaneously and (2) IAIDs for OPTION_IA_NA, OPTION_IA_TA,
       and OPTION_IA_PD are orthogonal number spaces.
  • T1 time sent to client.
  • T2 time sent to client.
  • Inside of the IA_NA-options, IA_TA-options, or IA_PD-options

sections:

       +  OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for
          an IPv6 prefix MUST appear.
  1. IPv6 address or IPv6 prefix (with length).
  1. Preferred lifetime sent to client.
  1. Valid lifetime sent to client.
  1. Inside of the IAaddr-options or IAprefix-options:
             o  OPTION_F_BINDING_STATUS containing the binding-status
                MUST appear.
             o  OPTION_F_START_TIME_OF_STATE containing the
                start-time-of-state MUST appear.
             o  OPTION_F_STATE_EXPIRATION_TIME (absolute) containing
                the state-expiration-time*.
             o  OPTION_CLT_TIME (relative) containing the
                client-last-transaction-time.  See [RFC5007] for a
                description of this option.
             o  OPTION_F_PARTNER_LIFETIME (absolute) containing the
                partner-lifetime*.
             o  OPTION_F_PARTNER_RAW_CLT_TIME (absolute) containing
                the partner-raw-clt-time.

Mrugalski & Kinnear Standards Track [Page 54] RFC 8156 DHCPv6 Failover Protocol June 2017

             o  OPTION_F_EXPIRATION_TIME (absolute) containing the
                expiration-time*.
             o  OPTION_CLIENT_FQDN containing the FQDN information
                associated with this lease and client, if any.
 Information about a prefix lease is contained in a single
 OPTION_IAPREFIX option.  Only a single OPTION_IAPREFIX option may
 appear in a BNDUPD message outside of an OPTION_CLIENT_DATA option.
 In detail:
 o  OPTION_IAPREFIX for a prefix lease.
  • IPv6 prefix (with length).
  • Inside of the IAprefix-options section:
       +  OPTION_VSS (see Section 3.4 of [RFC6607]).  This option
          MUST NOT appear if the information in this OPTION_IAPREFIX
          option is associated with the global, default VPN.  This
          option MUST appear if the information in this
          OPTION_IAPREFIX option is associated with a VPN other than
          the global, default VPN.  Support of [RFC6607] is not
          required, and if it is not supported, then an OPTION_VSS
          MUST NOT appear.  If [RFC6607] is supported, then an
          OPTION_VSS MUST appear if and only if a VPN other than the
          global, default VPN is used.
       +  OPTION_LQ_BASE_TIME containing the absolute time that this
          information was placed in this OPTIONS_IAPREFIX option (see
          Section 6.3.1 of [RFC7653]) MUST appear.
       +  OPTION_F_BINDING_STATUS containing the binding-status MUST
          appear.
       +  OPTION_F_START_TIME_OF_STATE containing the
          start-time-of-state MUST appear.
       +  OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the
          state-expiration-time*.
       +  OPTION_F_PARTNER_LIFETIME (absolute) containing the
          partner-lifetime*.
       +  OPTION_F_EXPIRATION_TIME (absolute) containing the
          expiration-time*.

Mrugalski & Kinnear Standards Track [Page 55] RFC 8156 DHCPv6 Failover Protocol June 2017

 Items marked with a single asterisk (*) MUST appear only if the value
 in the OPTION_F_BINDING_STATUS is associated with a timeout;
 otherwise, it MUST NOT appear.  See Section 7.2 for details.
 The OPTION_CLT_TIME MUST, if it appears, be the time that the server
 last interacted with the DHCP client.  It MUST NOT be, for instance,
 the time that the lease expired if there has been no interaction with
 the DHCP client in question.
 A server SHOULD be prepared to clean up DNS information once the
 lease expires or is released.  See Section 9 for a detailed
 discussion about DNS update.  Another reason the partner may be
 interested in keeping additional data is to enable better support for
 Leasequery [RFC5007], Bulk Leasequery [RFC5460], or Active Leasequery
 [RFC7653], some of which feature queries based on Relay-ID, link
 address, or Remote-ID.

7.5. Receiving Binding Updates

7.5.1. Monitoring Time Skew

 The sent-time from the failover message is compared with the current
 time of the receiving server as recorded when it received the
 message.  The difference is noted, and if it is greater than
 5 seconds the receiving server SHOULD drop the connection.  A message
 SHOULD be logged to signal the reason for the connection being
 dropped.
 Any time can be before, after, or essentially the same as another
 time.  Any time that ends up being +/- 5 seconds of another time
 SHOULD be considered to be representing the same time when performing
 a comparison between two times.

7.5.2. Acknowledging Reception

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

Mrugalski & Kinnear Standards Track [Page 56] RFC 8156 DHCPv6 Failover Protocol June 2017

7.5.3. Processing Binding Updates

 When a BNDUPD message is received, it MUST contain either a single
 OPTION_CLIENT_DATA option or a single OPTION_IAPREFIX option.
 When analyzing a BNDUPD message from a partner server, if there is
 insufficient information in the BNDUPD message to process it, then it
 is rejected with an OPTION_STATUS_CODE of
 "MissingBindingInformation".
 The server receiving a BNDUPD message from its partner must evaluate
 the received information in each OPTION_CLIENT_DATA or IAPREFIX
 option to see if it is consistent with the server's already-known
 state and, if it is not, decide to accept or reject the information.
 Section 7.5.4 provides details regarding how the server makes this
 determination.
 A server receiving a BNDUPD message MUST respond to the sender of
 that message with a BNDREPLY message that contains the same
 transaction-id as the BNDUPD message.  This BNDREPLY message MUST
 contain either a single OPTION_CLIENT_DATA option or a single
 OPTION_IAPREFIX option, corresponding to whatever was received in the
 BNDUPD message.
 An OPTION_CLIENT_DATA option or an OPTION_IAPREFIX option in the
 BNDREPLY message that is accepted SHOULD NOT contain an
 OPTION_STATUS_CODE unless a status message needs to be sent to the
 failover partner, in which case it SHOULD include an
 OPTION_STATUS_CODE option with a status-code indicating success and
 whatever message is needed.
 To indicate rejection of the information in an OPTION_CLIENT_DATA
 option or an OPTION_IAPREFIX option, an OPTION_STATUS_CODE SHOULD be
 included with a status-code indicating an error in the
 OPTION_CLIENT_DATA option or OPTION_IAPREFIX option in the BNDREPLY
 message.

7.5.4. Accept or Reject?

 The first task in processing the information in an OPTION_CLIENT_DATA
 option or OPTION_IAPREFIX option is to extract the client information
 (if any) and lease information out of the option and to access the
 address lease or prefix lease information in the server's binding
 database.
 If an OPTION_VSS option is specified in the OPTION_CLIENT_DATA option
 or OPTION_IAPREFIX option and the VPN specified in the OPTION_VSS
 option does not appear in the configuration of the receiving server,

Mrugalski & Kinnear Standards Track [Page 57] RFC 8156 DHCPv6 Failover Protocol June 2017

 then reject the entire OPTION_CLIENT_DATA option or OPTION_IAPREFIX
 option by including an OPTION_STATUS_CODE option with a status-code
 of "ConfigurationConflict".
 If the lease specified in the OPTION_CLIENT_DATA option or
 OPTION_IAPREFIX option is not a lease associated with the failover
 endpoint that received the OPTION_CLIENT_DATA option, then reject it
 by including an OPTION_STATUS_CODE option with a status-code of
 "ConfigurationConflict".
 In general, acceptance or rejection is based on the comparison of two
 different time values -- one from the OPTION_CLIENT_DATA option or
 OPTION_IAPREFIX option in the BNDUPD message, and one from the
 receiving server's binding database associated with the address or
 prefix lease found in the BNDUPD message.  The time for the BNDUPD
 message where the OPTION_F_BINDING_STATUS is ACTIVE, EXPIRED, or
 RELEASED is the OPTION_CLT_TIME if one appears, or the
 OPTION_F_START_TIME_OF_STATE if one does not.  For other
 binding-status values, the time for the BNDUPD message is the
 later of (1) the OPTION_CLT_TIME if one appears or (2) the
 OPTION_F_START_TIME_OF_STATE.  The time for the lease in the server's
 binding database is the client-last-transaction-time if one appears,
 or the start-time-of-state if one does not.
 The basic approach is to compare these times, and if the one from the
 BNDUPD message is clearly later, then accept the information in the
 OPTION_CLIENT_DATA option or OPTION_IAPREFIX option.  If the one from
 the server's binding database is clearly later, then reject the
 information in the BNDUPD message.  The challenge comes when they are
 essentially the same (i.e., +/- 5 seconds).  In this case, they are
 considered identical, despite the minor differences.  Figure 4 shows
 a table containing the rules for dealing with all of these
 situations.
                        binding-status in received OPTION_CLIENT_DATA
                                                   or OPTION_IAPREFIX
 binding-status in
 receiving server's                                 FREE        RESET
 lease state DB   ACTIVE   EXPIRED   RELEASED   FREE-BACKUP  ABANDONED
 ---------------------------------------------------------------------
 ACTIVE           accept(3) time(1)   accept     time(1)      accept
 EXPIRED          accept    accept    accept     accept       accept
 RELEASED         accept    accept    accept     accept       accept
 FREE/FREE-BACKUP accept    accept    accept     accept       accept
 RESET            time(2)   accept    accept     accept       accept
 ABANDONED        accept    accept    accept     accept       accept
                     Figure 4: Conflict Resolution

Mrugalski & Kinnear Standards Track [Page 58] RFC 8156 DHCPv6 Failover Protocol June 2017

 accept:  If the time value in the OPTION_CLIENT_DATA option or
    OPTION_IAPREFIX option is later than the time value in the
    server's binding database, accept it, else reject it.
 time(1):  If the current time is later than the receiving server's
    state-expiration-time, accept it, else reject it.
 time(2):  If the OPTION_CLT_TIME value (if it appears) in the
    OPTION_CLIENT_DATA is later than the start-time-of-state in the
    receiving server's binding, accept it, else reject it.
 accept,time(1),time(2):  If rejecting, use a status-code of
    "OutdatedBindingInformation".
 accept(3):  If the clients in an OPTION_CLIENT_DATA option and in a
    receiving server's binding differ, then if time(2) or the
    receiving server is a secondary accept it, else reject it with a
    status-code of "AddressInUse".  If the clients match, accept the
    update.
 The lease update may be accepted or rejected.  If a lease is rejected
 with "OutdatedBindingInformation", then the flag in the lease that
 indicates that the partner should be updated with the information in
 this lease SHOULD be set; otherwise, it SHOULD NOT be changed.  If
 this flag was previously not set, then an update MAY be transmitted
 immediately to the partner (though the BNDREPLY to this BNDUPD
 message SHOULD be sent first).  If this flag was previously set, an
 update SHOULD NOT be transmitted immediately to the partner.  In this
 case, an update will be sent during the next periodic scan, but not
 immediately, thus preventing a possible update storm should the
 servers be unable to agree.  Ultimately, the server with the most
 recent binding information should have its update accepted by its
 partner.

7.5.5. Accepting Updates

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

Mrugalski & Kinnear Standards Track [Page 59] RFC 8156 DHCPv6 Failover Protocol June 2017

 The information contained in an accepted OPTION_CLIENT_DATA option is
 stored in the receiving server's binding database as follows:
 1.  The OPTION_CLIENTID is used to find the client.
 2.  The other data contained in the top level of the
     OPTION_CLIENT_DATA option is stored with the client as
     appropriate.
 3.  For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD
     options in the OPTION_CLIENT_DATA option and for each of the
     OPTION_IAADDR or OPTION_IAPREFIX options in the IA_* options:
     a.  OPTION_F_BINDING_STATUS is stored as the binding-status.
     b.  OPTION_F_PARTNER_LIFETIME is stored in the expiration-time.
     c.  OPTION_F_STATE_EXPIRATION_TIME is stored in the
         state-expiration-time.
     d.  OPTION_CLT_TIME [RFC5007] is stored in the
         partner-raw-clt-time.
     e.  OPTION_F_PARTNER_RAW_CLT_TIME replaces the
         client-last-transaction-time if it is later than the current
         client-last-transaction-time.
     f.  OPTION_F_EXPIRATION_TIME replaces the partner-lifetime if it
         is later than the current partner-lifetime.
 The information contained in an accepted single OPTION_IAPREFIX
 option that is not contained in an OPTION_CLIENT_DATA option is
 stored in the receiving server's binding database as follows:
 1.  The IPv6 prefix is used to find the prefix.
 2.  Inside of the IAprefix-options section:
     a.  OPTION_F_BINDING_STATUS is stored as the binding-status.
     b.  OPTION_F_PARTNER_LIFETIME (if any) is stored in the
         expiration-time.
     c.  OPTION_F_STATE_EXPIRATION_TIME (if any) is stored in the
         state-expiration-time.

Mrugalski & Kinnear Standards Track [Page 60] RFC 8156 DHCPv6 Failover Protocol June 2017

     d.  OPTION_F_EXPIRATION_TIME (if any) replaces the
         partner-lifetime if it is later than the current
         partner-lifetime.

7.6. Sending Binding Replies

 A server MUST respond to every BNDUPD message with a BNDREPLY
 message.  The BNDREPLY message MUST contain an OPTION_CLIENT_DATA
 option if the BNDUPD message contained an OPTION_CLIENT_DATA option,
 or it MUST contain an OPTION_IAPREFIX option if the BNDUPD message
 contained an OPTION_IAPREFIX option.  The BNDREPLY message MUST have
 the same transaction-id as the BNDUPD message to which it is a
 response.
 Acceptance or rejection of all of or a particular part of the BNDUPD
 message is signaled with an OPTION_STATUS_CODE option.  An
 OPTION_STATUS_CODE option containing a status-code representing an
 error is significant, while an OPTION_STATUS_CODE option whose
 status-code contains success is considered informational but does not
 affect the processing of the BNDREPLY message when it is received by
 the server that sent the BNDUPD message.
 Rejection of all of or part of the information in a BNDUPD message is
 signaled in a BNDREPLY message by using the OPTION_STATUS_CODE
 message with an error in the status-code field.  This rejection can
 take place at either of two levels -- the top level of the option
 hierarchy or the bottom level of the option hierarchy:
 1.  Entire BNDUPD: The OPTION_STATUS_CODE containing an error is
     present in the outermost option of the BNDREPLY message -- either
     the single OPTION_CLIENT_DATA option or the single
     OPTION_IAPREFIX option.  An example of this sort of error might
     be that an OPTION_VSS option was present and specified a VPN that
     might not exist in the receiving server.
 2.  Single address or prefix: The OPTION_STATUS_CODE containing an
     error is present in a single IAADDR or IAPREFIX option that is
     itself contained in an OPTION_IA_NA, OPTION_IA_TA, or
     OPTION_IA_PD option.  An example of this sort of error might be
     that a particular IPv6 address was specified in an IAADDR option
     that doesn't appear in the receiving server's configuration.
 Rejection occurring at either of these levels indicates rejection of
 all of the information contained in the option (including any other
 options contained in that option) where the OPTION_STATUS_CODE option
 containing an error appears.  The converse is not true -- an
 OPTION_STATUS_CODE option containing success does not signify that
 all of the contained information has been accepted.

Mrugalski & Kinnear Standards Track [Page 61] RFC 8156 DHCPv6 Failover Protocol June 2017

 If the BNDREPLY message contains an OPTION_CLIENT_DATA option, then
 the OPTION_CLIENT_DATA option MUST contain at least the data shown
 below in its client-options section:
 o  OPTION_CLIENTID containing the DUID of the client most recently
    associated with this IPv6 address.
 o  OPTION_VSS from the BNDUPD message, if any.
 o  OPTION_IA_NA or OPTION_IA_TA for an IPv6 address or OPTION_IA_PD
    for an IPv6 prefix.  More than one of either of these options MAY
    appear if there are more than one of them associated with this
    client.
  • Inside of the IA_NA-options, IA_TA-options, or IA_PD-options

sections:

       +  OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for
          an IPv6 prefix.
  1. IPv6 address or IPv6 prefix (with length).
  1. Inside of the IAaddr-options or IAprefix-options:
             o  OPTION_STATUS_CODE containing an error code, or
                containing a success code if a message is required.
                An OPTION_STATUS_CODE option SHOULD NOT appear with a
                success code unless a message associated with the
                success code needs to be included.  The lack of an
                OPTION_STATUS_CODE option is an indication of success.
             o  OPTION_F_BINDING_STATUS containing the binding-status
                received in the BNDUPD message.
             o  OPTION_F_STATE_EXPIRATION_TIME (absolute) containing
                the state-expiration-time received in the BNDUPD
                message.
             o  OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a
                duplicate of the OPTION_F_PARTNER_LIFETIME received in
                the BNDUPD message.

Mrugalski & Kinnear Standards Track [Page 62] RFC 8156 DHCPv6 Failover Protocol June 2017

 If the BNDREPLY message contains a single OPTION_IAPREFIX option not
 contained in an OPTION_CLIENT_DATA option, then the OPTION_IAPREFIX
 option MUST contain at least the data shown below:
 o  IPv6 prefix (with length).
 o  IAprefix-options:
  • OPTION_VSS from the BNDUPD message, if any.
  • OPTION_STATUS_CODE containing an error code, or containing a

success code if a message is required. If the information in

       the corresponding OPTION_IAPREFIX in the BNDUPD message was
       accepted and no status message was required (which is the usual
       case), no OPTION_STATUS_CODE option appears.
  • OPTION_F_BINDING_STATUS containing the binding-status received

in the BNDREPLY message.

  • OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the

state-expiration-time received in the BNDREPLY message.

  • OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a

duplicate of the OPTION_F_PARTNER_LIFETIME received in the

       BNDREPLY message.

7.7. Receiving Binding Acks

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

Mrugalski & Kinnear Standards Track [Page 63] RFC 8156 DHCPv6 Failover Protocol June 2017

 The information contained in the BNDREPLY message in an
 OPTION_CLIENT_DATA that represents an acceptance is stored with the
 appropriate client and lease, as follows:
 1.  The OPTION_CLIENTID is used to find the client.
 2.  For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD
     options in the OPTION_CLIENT_DATA option and for each of the
     OPTION_IAADDR or OPTION_IAPREFIX options they contain:
     a.  OPTION_F_PARTNER_LIFETIME_SENT is stored in the
         acked-partner-lifetime.
     b.  The partner-lifetime is set to 0 to indicate that no more
         information needs to be sent to the partner.
 Alternatively, the BNDREPLY message may contain a single
 OPTION_IAPREFIX option not contained in an OPTION_CLIENT_DATA option,
 representing information concerning a single prefix lease.  If the
 IAprefix-options section of the OPTION_IAPREFIX option contains an
 OPTION_STATUS_CODE representing an error, then it is considered a
 rejection of the corresponding BNDUPD message.  If the
 OPTION_IAPREFIX option does not contain an OPTION_STATUS_CODE option
 or if the OPTION_STATUS_CODE option contains a success status, then
 the three items in the following list are stored in the lease state
 database, in the section associated with the prefix lease represented
 by the OPTION_IAPREFIX option.
 1.  OPTION_F_BINDING_STATUS containing the binding-status received in
     the BNDREPLY message.
 2.  OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the
     state-expiration-time received in the BNDREPLY message.
 3.  OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a duplicate
     of the OPTION_F_PARTNER_LIFETIME received in the BNDREPLY
     message.

Mrugalski & Kinnear Standards Track [Page 64] RFC 8156 DHCPv6 Failover Protocol June 2017

7.8. BNDUPD/BNDREPLY Data Flow

 Figure 5 shows the relationship of the times described in Section 7.3
 to the options used to transmit them.  It also relates the times on
 one failover partner to the other failover partner.
  1. ———————- BNDUPD ———————————
   Source on            OPTION_F in            Storage on
  Sending Server  ->   BNDUPD message   ->   Receiving Server
                                   [always update]
 partner-lifetime      PARTNER_LIFETIME      expiration-time
 client-last-transaction-time  CLT_TIME      partner-raw-clt-time
 start-time-of-state   START_TIME_OF_STATE   start-time-of-state
 state-expiration-time STATE_EXPIRATION_TIME state-expiration-time
                            [update only if received > current]
 expiration-time       EXPIRATION_TIME       partner-lifetime
 partner-raw-clt-time  PARTNER_RAW_CLT_TIME
                                        client-last-transaction-time
  1. ———————- BNDREPLY ——————————-
   Storage on            OPTION_F in           Storage on
  Receiving Server <-   BNDUPD message   <-   Sending Server
         [always update]
 acked-partner-lifetime PARTNER_LIFETIME_SENT duplicate of received
                                                PARTNER_LIFETIME
 (nothing to update)    STATE_EXPIRATION_TIME state-expiration-time
  1. —————————————————————
              Figure 5: BNDUPD and BNDREPLY Time Handling

Mrugalski & Kinnear Standards Track [Page 65] RFC 8156 DHCPv6 Failover Protocol June 2017

8. Endpoint States

8.1. State Machine Operation

 Each server (or, more accurately, failover endpoint) can take on a
 variety of failover states.  These states play a crucial role in
 determining the actions that a server will perform when processing a
 request from a DHCP client as well as dealing with changing external
 conditions (e.g., loss of connection to a failover partner).
 The failover state in which a server is running controls the
 following behaviors:
 o  Responsiveness - the server is either responsive to DHCP client
    requests, renew responsive, or unresponsive.
 o  Allocation Pool - which pool of addresses (or prefixes) can be
    used for advertisement on receipt of a SOLICIT or allocation on
    receipt of a REQUEST, RENEW, or REBIND message.
 o  MCLT - ensure that valid lifetimes are not beyond what the partner
    has acked plus the MCLT (unless the failover state doesn't require
    this restriction).
 A server will transition from one failover state to another based on
 the specific values held by the following state variables:
 o  Current failover state.
 o  Communications status ("OK" or not "OK").
 o  Partner's failover state (if known).
 Whenever any of the above state variables change state, the state
 machine is invoked, which may then trigger a change in the current
 failover state.  Thus, whenever the communications status changes,
 the state machine processing is invoked.  This may or may not result
 in a change in the current failover state.
 Whenever a server transitions to a new failover state, the new state
 MUST be communicated to its failover partner in a STATE message if
 the communications status is "OK".  In addition, whenever a server
 makes a transition into a new state, it MUST record the new state,
 its current understanding of its partner's state, and the time at
 which it entered the new state in stable storage.

Mrugalski & Kinnear Standards Track [Page 66] RFC 8156 DHCPv6 Failover Protocol June 2017

 The state transition diagram below (Figure 6) gives a condensed view
 of the state machine.  If there are any differences between text
 describing a particular state and the information shown in Figure 6,
 the text should be considered authoritative.
 In Figure 6, the terms "responsive", "r-responsive", and
 "unresponsive" appear in the states and refer to whether the server
 in the indicated state is allowed to be responsive, renew responsive,
 or unresponsive, respectively.  The "+", "-", or "*" in the upper
 right corner of each state is a notation about whether communication
 is ongoing with the other server, with "+" meaning that
 communications are "OK", "-" meaning that communications are
 interrupted, and "*" meaning that communications may be either "OK"
 or interrupted.

Mrugalski & Kinnear Standards Track [Page 67] RFC 8156 DHCPv6 Failover Protocol June 2017

     +---------------+  V  +--------------+
     |    RECOVER  * |  |  |   STARTUP  - |
     |(unresponsive) |  +->+(unresponsive)|
     +------+--------+     +--------------+
     +-Comm. OK             +-----------------+
     |     Other State:     |  PARTNER-DOWN - +<---------------------+
     |    RESOLUTION-INTER. | (responsive)    |                      ^
    All     POTENTIAL-      +----+------------+                      |
   Others   CONFLICT------------ | --------+                         |
     |      CONFLICT-DONE     Comm. OK     |     +--------------+    |
  UPDREQ or                 Other State:   |  +--+ RESOLUTION - |    |
  UPDREQALL                  |       |     |  |  | INTERRUPTED  |    |
  Rcv UPDDONE             RECOVER    All   |  |  | (responsive) |    |
     |  +---------------+    |      Others |  |  +------+-----+-+    |
     +->+RECOVER-WAIT * | RECOVER-   |     |  |         ^     |      |
        |(unresponsive) |  WAIT or   |     |  Comm.     |    Ext.    |
        +-----------+---+  DONE      |     |  OK     Comm.   Cmd---->+
 Comm.---+     Wait MCLT     |       V     V  V     Failed           |
 Changed |          V    +---+   +---+-----+--+-+       |            |
  |  +---+----------++   |       | POTENTIAL  + +-------+            |
  |  |RECOVER-DONE * |  Wait     | CONFLICT     +------+             |
  +->+(unresponsive) |  for      |(unresponsive)|   Primary          |
     +------+--------+  Other  +>+----+--------++   resolve    Comm. |
      Comm. OK          State: |      |        ^    conflict  Changed|
 +---Other State:-+   RECOVER- |   Secondary   |       V       V   | |
 |    |           |     DONE   |   resolve     |  +----+-------+--++ |
 | All Others:  POTENT.  |     |   conflict    |  |CONFLICT-DONE * | |
 | Wait for    CONFLICT--|-----+      |        |  | (responsive)   | |
 | Other State:          V            V        |  +-------+--------+ |
 | NORMAL or RECOVER-   ++------------+---+    | Other State: NORMAL |
 |    |       DONE      |     NORMAL    + +<--------------+          |
 |    +--+----------+-->+ pri: responsive +-------External Command-->+
 |       ^          ^   |sec: r-responsive|    |                     |
 |       |          |   +--------+--------+    |                     |
 |       |          |            |             |                     |
 |   Wait for   Comm. OK  Comm. Failed         |             External
 |    Other      Other           |             |             Command
 |    State:     State:     Start Auto         |                or
 | RECOVER-DONE  NORMAL    Partner Down     Comm. OK           Auto
 |       |     COMM.-INT.      Timer       Other State:       Partner
 |    Comm. OK      |            V          All Others         Down
 |   Other State:   |  +---------+--------+    |            expiration
 |     RECOVER      +--+ COMMUNICATIONS - +----+                     |
 |       +-------------+   INTERRUPTED    |                          |
 RECOVER               |  (responsive)    +------------------------->+
 RECOVER-WAIT--------->+------------------+
               Figure 6: Failover Endpoint State Machine

Mrugalski & Kinnear Standards Track [Page 68] RFC 8156 DHCPv6 Failover Protocol June 2017

8.2. State Machine Initialization

 The state machine is characterized by storage (in stable storage) of
 at least the following information:
 o  Current failover state.
 o  Previous failover state.
 o  Start time of current failover state.
 o  Partner's failover state.
 o  Start time of partner's failover state.
 o  Time most recent message received from partner.
 The state machine is initialized by reading these data items from
 stable storage and restoring their values from the information saved.
 If there is no information in stable storage concerning these items,
 then they should be initialized as follows:
 o  Current failover state: Primary: PARTNER-DOWN, Secondary: RECOVER.
 o  Previous failover state: None.
 o  Start time of current failover state: Current time.
 o  Partner's failover state: None until reception of STATE message.
 o  Start time of partner's failover state: None until reception of
    STATE message.
 o  Time most recent message received from partner: None until message
    received.

Mrugalski & Kinnear Standards Track [Page 69] RFC 8156 DHCPv6 Failover Protocol June 2017

8.3. STARTUP State

 The STARTUP state affords an opportunity for a server to probe its
 partner server before starting to service DHCP clients.  When in the
 STARTUP state, a server attempts to learn its partner's state and
 determine (using that information if it is available) what state it
 should enter.
 The STARTUP state is not shown with any specific state transitions in
 the state machine diagram (Figure 6) because the processing during
 the STARTUP state can cause the server to transition to any of the
 other states, so that specific state transition arcs would only
 obscure other information.

8.3.1. Operation in STARTUP State

 The server MUST NOT be responsive to DHCP clients in STARTUP state.
 Whenever a STATE message is sent to the partner while in STARTUP
 state, the STARTUP flag MUST be set in the OPTION_F_SERVER_FLAGS
 option and the previously recorded failover state MUST be placed in
 the OPTION_F_SERVER_STATE option, each of which is included in the
 STATE message.

8.3.2. Transition out of STARTUP State

 The algorithm below is followed every time the server initializes
 itself and enters STARTUP state.
 The variables PREVIOUS-STATE and CURRENT-STATE are defined for use in
 the algorithm description below.  PREVIOUS-STATE is simply for
 storage of a state, while CURRENT-STATE not only stores the current
 state but also changes the current state of the failover endpoint to
 whatever state is set in CURRENT-STATE.
 Step 1: If there is any record of a previous failover state in stable
         storage for this server, then set the PREVIOUS-STATE to the
         last recorded value in stable storage and the TIME-OF-FAILURE
         to the time the server failed or a time beyond which the
         server could not have been operating, and go to Step 2.
         If there is no record of any previous failover state in
         stable storage for this server, then set the PREVIOUS-STATE
         to RECOVER, and set the TIME-OF-FAILURE to 0.  This will
         allow two servers that already have lease information to
         synchronize themselves prior to operating.

Mrugalski & Kinnear Standards Track [Page 70] RFC 8156 DHCPv6 Failover Protocol June 2017

         In some cases, an existing server will be commissioned as a
         failover server and brought back into operation when its
         partner is not yet available.  In this case, the newly
         commissioned failover server will not operate until its
         partner comes online -- but it has operational
         responsibilities as a DHCP server nonetheless.  To properly
         handle this situation, a server SHOULD be configurable in
         such a way as to move directly into PARTNER-DOWN state after
         the startup period expires if it has been unable to contact
         its partner during the startup period.
 Step 2: Implementations will differ in the ways that they deal with
         the state machine for failover endpoint states.  In many
         cases, state transitions will occur when communications go
         from "OK" to failed or from failed to "OK", and some
         implementations will implement a portion of their state
         machine processing based on these changes.
         In these cases, during startup, if the PREVIOUS-STATE is one
         where communications were "OK", then set the PREVIOUS-STATE
         to the state that is the result of the communication failed
         state transition when in that state (if such a transition
         exists -- some states don't have a communication failed state
         transition, since they allow both "communications OK" and
         "failed").
 Step 3: Start the STARTUP state timer.  The time that a server
         remains in the STARTUP state (absent any communications with
         its partner) is implementation dependent but SHOULD be short.
         It SHOULD be long enough for a TCP connection to a heavily
         loaded partner to be created across a slow network.
 Step 4: If the server is a primary server, attempt to create a TCP
         connection to the failover partner.  If the server is a
         secondary server, listen on the failover port and wait for
         the primary server to connect.  See Section 6.1.

Mrugalski & Kinnear Standards Track [Page 71] RFC 8156 DHCPv6 Failover Protocol June 2017

 Step 5: Wait for "communications OK".
         When and if communications become "OK", clear the STARTUP
         flag, and set the CURRENT-STATE to the PREVIOUS-STATE.
         If the partner is in PARTNER-DOWN state and if the time at
         which it entered PARTNER-DOWN state (as received in the
         OPTION_F_START_TIME_OF_STATE option in the STATE message) is
         later than the last recorded time of operation of this
         server, then set CURRENT-STATE to RECOVER.  If the time at
         which it entered PARTNER-DOWN state is earlier than the last
         recorded time of operation of this server, then set
         CURRENT-STATE to POTENTIAL-CONFLICT.
         Then, transition to the CURRENT-STATE and take the
         "communications OK" state transition based on the
         CURRENT-STATE of this server and the partner.
 Step 6: If the startup time expires prior to communications becoming
         "OK", the server SHOULD transition to PREVIOUS-STATE.

8.4. PARTNER-DOWN State

 PARTNER-DOWN state is a state either server can enter.  When in this
 state, the server assumes that it is the only server operating and
 serving the client base.  If one server is in PARTNER-DOWN state, the
 other server MUST NOT be operating.
 A server can enter PARTNER-DOWN state as a result of either
 (1) operator intervention (when an operator determines that the
 server's partner is, indeed, down) or (2) an optional
 auto-partner-down capability where PARTNER-DOWN state is entered
 automatically after a server has been in COMMUNICATIONS-INTERRUPTED
 state for a predetermined period of time.

8.4.1. Operation in PARTNER-DOWN State

 The server MUST be responsive in PARTNER-DOWN state, regardless of
 whether it is primary or secondary.
 It will allow renewal of all outstanding leases.
 For delegable prefixes, the server will allocate leases from its own
 pool, and after a fixed period of time (the MCLT interval) has
 elapsed from entry into PARTNER-DOWN state, it may allocate delegable
 prefixes from the set of all available pools.  The server MUST fully
 deplete its own pool before starting allocations from its downed
 partner's pool.

Mrugalski & Kinnear Standards Track [Page 72] RFC 8156 DHCPv6 Failover Protocol June 2017

 IPv6 addresses available for independent allocation by the other
 server (upon entering PARTNER-DOWN state) SHOULD NOT be allocated to
 a client.  If one elects to do so anyway, they MUST NOT be allocated
 to a new client until the MCLT beyond the entry into PARTNER-DOWN
 state has elapsed.
 A server in PARTNER-DOWN state MUST NOT allocate a lease to a DHCP
 client different from the client to which it was allocated at the
 time of entry into PARTNER-DOWN state until the MCLT beyond the
 maximum of the following times: client expiration time, most recently
 transmitted partner-lifetime, most recently received ack of the
 partner-time from the partner, and most recently acked
 partner-lifetime to the partner.  If this time would be earlier than
 the current time plus the MCLT, then the time the server entered
 PARTNER-DOWN state plus the MCLT is used.
 The server is not restricted by the MCLT when offering valid
 lifetimes while in PARTNER-DOWN state.
 In the unlikely case when there are two servers operating in
 PARTNER-DOWN state, there is a chance that duplicate leases for the
 same prefix could be assigned.  This leads to a POTENTIAL-CONFLICT
 (unresponsive) state when the servers reestablish contact.  This
 issue of duplicate leases can be prevented as long as the server
 grants new leases from its own pool; therefore, the server operating
 in PARTNER-DOWN state MUST use its own pool first for new leases
 before assigning any leases from its downed partner's pool.

8.4.2. Transition out of PARTNER-DOWN State

 When a server in PARTNER-DOWN state succeeds in establishing a
 connection to its partner, its actions are conditional on the state
 and flags received in the STATE message from the other server as part
 of the process of establishing the connection.
 If the STARTUP bit is set in the OPTION_F_SERVER_FLAGS option of a
 received STATE message, a server in PARTNER-DOWN state MUST NOT take
 any state transitions based on reestablishing communications.  If a
 server is in PARTNER-DOWN state, it ignores all STATE messages from
 its partner that have the STARTUP bit set in the
 OPTION_F_SERVER_FLAGS option of the STATE message.

Mrugalski & Kinnear Standards Track [Page 73] RFC 8156 DHCPv6 Failover Protocol June 2017

 If the STARTUP bit is not set in the OPTION_F_SERVER_FLAGS option of
 a STATE message received from its partner, then a server in
 PARTNER-DOWN state takes the following actions, based on the state of
 the partner as received in a STATE message (either immediately after
 establishing communications or at any time later when a new state is
 received):
 o  If the partner is in NORMAL, COMMUNICATIONS-INTERRUPTED,
    PARTNER-DOWN, POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, or
    CONFLICT-DONE state, then transition to POTENTIAL-CONFLICT state.
 o  If the partner is in RECOVER or RECOVER-WAIT state, then stay in
    PARTNER-DOWN state.
 o  If the partner is in RECOVER-DONE state, then transition to
    NORMAL state.

8.5. RECOVER State

 This state indicates that the server has no information in its stable
 storage or that it is reintegrating with a server in PARTNER-DOWN
 state after it has been down.  A server in this state MUST attempt to
 refresh its stable storage from the other server.

8.5.1. Operation in RECOVER State

 The server MUST NOT be responsive in RECOVER state.
 A server in RECOVER state will attempt to reestablish communications
 with the other server.

8.5.2. Transition out of RECOVER State

 If the other server is in POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED,
 or CONFLICT-DONE state when communications are reestablished, then
 the server in RECOVER state will move itself to POTENTIAL-CONFLICT
 state.
 If the other server is in any other state, then the server in RECOVER
 state will request an update of missing binding information by
 sending an UPDREQ message.  If the server has determined that it has
 lost its stable storage because it has no record of ever having
 talked to its partner even though its partner does have a record of
 communicating with it, it MUST send an UPDREQALL message; otherwise,
 it MUST send an UPDREQ message.
 It will wait for an UPDDONE message, and upon receipt of that message
 it will transition to RECOVER-WAIT state.

Mrugalski & Kinnear Standards Track [Page 74] RFC 8156 DHCPv6 Failover Protocol June 2017

 If communication fails during the reception of the results of the
 UPDREQ or UPDREQALL message, the server will remain in RECOVER state
 and will reissue the UPDREQ or UPDREQALL message when communications
 are reestablished.
 If an UPDDONE message isn't received within an implementation-
 dependent amount of time and no BNDUPD messages are being received,
 the connection SHOULD be dropped.
                 A                                        B
               Server                                  Server
                 |                                        |
              RECOVER                               PARTNER-DOWN
                 |                                        |
                 | >--UPDREQ-------------------->         |
                 |                                        |
                 |        <---------------------BNDUPD--< |
                 | >--BNDREPLY------------------>         |
                ...                                      ...
                 |                                        |
                 |        <---------------------BNDUPD--< |
                 | >--BNDREPLY------------------>         |
                 |                                        |
                 |        <--------------------UPDDONE--< |
                 |                                        |
            RECOVER-WAIT                                  |
                 |                                        |
                 | >--STATE-(RECOVER-WAIT)------>         |
                 |                                        |
                 |                                        |
        Wait MCLT from last known                         |
           time of failover operation                     |
                 |                                        |
            RECOVER-DONE                                  |
                 |                                        |
                 | >--STATE-(RECOVER-DONE)------>         |
                 |                                     NORMAL
                 |        <-------------(NORMAL)-STATE--< |
              NORMAL                                      |
                 | >---- State-(NORMAL)--------------->   |
                 |                                        |
                 |                                        |
               Figure 7: Transition out of RECOVER State

Mrugalski & Kinnear Standards Track [Page 75] RFC 8156 DHCPv6 Failover Protocol June 2017

 If at any time while a server is in RECOVER state communication
 fails, the server will stay in RECOVER state.  When communications
 are restored, it will restart the process of transitioning out of
 RECOVER state.

8.6. RECOVER-WAIT State

 This state indicates that the server has sent an UPDREQ or UPDREQALL
 message and has received the UPDDONE message indicating that it has
 received all outstanding binding update information.  In the
 RECOVER-WAIT state, the server will wait for the MCLT in order to
 ensure that any processing that this server might have done prior to
 losing its stable storage will not cause future difficulties.

8.6.1. Operation in RECOVER-WAIT State

 The server MUST NOT be responsive in RECOVER-WAIT state.

8.6.2. Transition out of RECOVER-WAIT State

 Upon entry into RECOVER-WAIT state, the server MUST start a timer
 whose expiration is set to a time equal to the time the server went
 down (the TIME-OF-FAILURE from Section 8.3.2), if known, or the time
 the server started (if the TIME-OF-FAILURE is unknown), plus the
 MCLT.  When this timer expires, the server will transition into
 RECOVER-DONE state.
 This allows any IPv6 addresses or prefixes that were allocated by
 this server prior to the loss of its client binding information in
 stable storage to contact the other server or to time out.
 If the server has never before run failover, then there is no need to
 wait in this state, and the server MAY transition immediately to
 RECOVER-DONE state.  However, to determine if this server has run
 failover, it is vital that the information provided by the partner be
 utilized, since the stable storage of this server may have been lost.
 If communication fails while a server is in RECOVER-WAIT state, it
 has no effect on the operation of this state.  The server SHOULD
 continue to operate its timer, and if the timer expires during the
 period where communications with the other server have failed, then
 the server SHOULD transition to RECOVER-DONE state.  This is rare --
 failover state transitions are not usually made while communications
 are interrupted, but in this case there is no reason to inhibit this
 transition.

Mrugalski & Kinnear Standards Track [Page 76] RFC 8156 DHCPv6 Failover Protocol June 2017

8.7. RECOVER-DONE State

 This state exists to allow an interlocked transition for one server
 from RECOVER state and another server from PARTNER-DOWN or
 COMMUNICATIONS-INTERRUPTED state into NORMAL state.

8.7.1. Operation in RECOVER-DONE State

 A server in RECOVER-DONE state SHOULD be renew responsive and MAY
 respond to RENEW requests but MUST only change the state of a lease
 that appears in the RENEW request.  It MUST NOT allocate any
 additional leases when in RECOVER-DONE state and should only respond
 to RENEW requests where it already has a record of the lease.

8.7.2. Transition out of RECOVER-DONE State

 When a server in RECOVER-DONE state determines that its partner
 server has entered NORMAL or RECOVER-DONE state, it will transition
 into NORMAL state.
 If the partner server enters RECOVER or RECOVER-WAIT state, this
 server transitions to COMMUNICATIONS-INTERRUPTED.
 If the partner server enters POTENTIAL-CONFLICT state, this server
 enters POTENTIAL-CONFLICT state as well.
 If communication fails while in RECOVER-DONE state, a server will
 stay in RECOVER-DONE state.

8.8. NORMAL State

 NORMAL state is the state used by a server when it is communicating
 with the other server and any required resynchronization has been
 performed.  While some binding database synchronization is performed
 in NORMAL state, potential conflicts are resolved prior to entry into
 NORMAL state, as is binding database data loss.
 When entering NORMAL state, a server will send to the other server
 all currently unacknowledged binding updates as BNDUPD messages.
 When the above process is complete, if the server entering NORMAL
 state is a secondary server, then it will request delegable prefixes
 for allocation using the POOLREQ message.

Mrugalski & Kinnear Standards Track [Page 77] RFC 8156 DHCPv6 Failover Protocol June 2017

8.8.1. Operation in NORMAL State

 The primary server is responsive in NORMAL state.  The secondary is
 renew responsive in NORMAL state.
 When in NORMAL state, a primary server will operate in the following
 manner:
 Valid lifetime calculations
    As discussed in Section 4.4, the lease interval given to a DHCP
    client can never be more than the MCLT greater than the most
    recently acknowledged partner lifetime received from the failover
    partner or the current time, whichever is later.
    As long as a server adheres to this constraint, the specifics of
    the lease interval that it gives to a DHCP client or the value of
    the partner lifetime sent to its failover partner are
    implementation dependent.
 Lazy update of partner server
    After sending a REPLY that includes a lease update to a client,
    the server servicing a DHCP client request attempts to update its
    partner with the new binding information.  See Section 4.3.
 Reallocation of leases between clients
    Whenever a client binding is released or expires, a BNDUPD message
    must be sent to the partner, setting the binding state to RELEASED
    or EXPIRED.  However, until a BNDREPLY is received for this
    message, the lease cannot be allocated to another client.  It
    cannot be allocated to the same client again if a BNDUPD message
    was sent; otherwise, it can.  See Section 4.2.2.1 for details.
 In NORMAL state, each server receives binding updates from its
 partner server in BNDUPD messages (see Section 7.5.5).  It records
 these in its binding database in stable storage and then sends a
 corresponding BNDREPLY message to its partner server (see
 Section 7.6).

8.8.2. Transition out of NORMAL State

 If a server in NORMAL state receives an external command informing it
 that its partner is down, it will transition immediately into
 PARTNER-DOWN state.  Generally, this would be an unusual situation,
 where some external agency knew the partner server was down prior to
 the failover server discovering it on its own.

Mrugalski & Kinnear Standards Track [Page 78] RFC 8156 DHCPv6 Failover Protocol June 2017

 If a server in NORMAL state fails to receive acks to messages sent to
 its partner for an implementation-dependent period of time, it MAY
 move into COMMUNICATIONS-INTERRUPTED state.  This situation might
 occur if the partner server was capable of maintaining the TCP
 connection between the server and also capable of sending a CONTACT
 message periodically but was (for some reason) incapable of
 processing BNDUPD messages.
 If it is determined that communications are not "OK" (as defined in
 Section 6.6), then the server should transition into
 COMMUNICATIONS-INTERRUPTED state.
 If a server in NORMAL state receives any messages from its partner
 where the partner has changed state from that expected by the server
 in NORMAL state, then the server should transition into
 COMMUNICATIONS-INTERRUPTED state and take the appropriate state
 transition from there.  For example, it would be expected that the
 partner would transition from POTENTIAL-CONFLICT state into NORMAL
 state but not that the partner would transition from NORMAL state
 into POTENTIAL-CONFLICT state.
 If a server in NORMAL state receives a DISCONNECT message from its
 partner, then the server should transition into
 COMMUNICATIONS-INTERRUPTED state.

8.9. COMMUNICATIONS-INTERRUPTED State

 A server goes into COMMUNICATIONS-INTERRUPTED state whenever it is
 unable to communicate with its partner.  Primary and secondary
 servers cycle automatically (without administrative intervention)
 between NORMAL state and COMMUNICATIONS-INTERRUPTED state as the
 network connection between them fails and recovers, or as the partner
 server cycles between operational and non-operational.  No allocation
 of duplicate leases can occur while the servers cycle between these
 states.
 When a server enters COMMUNICATIONS-INTERRUPTED state, if it has been
 configured to support an automatic transition out of
 COMMUNICATIONS-INTERRUPTED state and into PARTNER-DOWN state (i.e.,
 auto-partner-down has been configured), then a timer is started for
 the length of the configured auto-partner-down period.
 A server transitioning into the COMMUNICATIONS-INTERRUPTED state from
 the NORMAL state SHOULD raise an alarm condition to alert
 administrative staff to a potential problem in the DHCP subsystem.

Mrugalski & Kinnear Standards Track [Page 79] RFC 8156 DHCPv6 Failover Protocol June 2017

8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State

 In this state, a server MUST respond to all DHCP client requests.
 When allocating new leases, each server allocates from its own pool,
 where the primary MUST allocate only FREE delegable prefixes and the
 secondary MUST allocate only FREE-BACKUP delegable prefixes, and each
 server allocates from its own independent IPv6 address ranges.  When
 responding to RENEW messages, each server will allow continued
 renewal of a DHCP client's current lease, regardless of whether that
 lease was given out by the receiving server or not, although the
 renewal period MUST NOT exceed the MCLT beyond the later of (1) the
 partner lifetime already acknowledged by the other server or (2) now.
 However, since the server cannot communicate with its partner in this
 state, the acknowledged partner lifetime will not be updated, despite
 continued RENEW message processing.  This is likely to eventually
 cause the actual lifetimes to converge to the MCLT (unless this is
 greater than the desired lease time, which would be unusual).
 The server should continue to try to establish a connection with its
 partner.

8.9.2. Transition out of COMMUNICATIONS-INTERRUPTED State

 If the auto-partner-down timer expires while a server is in
 COMMUNICATIONS-INTERRUPTED state, it will transition immediately into
 PARTNER-DOWN state.
 If a server in COMMUNICATIONS-INTERRUPTED state receives an external
 command informing it that its partner is down, it will transition
 immediately into PARTNER-DOWN state.
 If communications with the other server are restored, then the server
 in COMMUNICATIONS-INTERRUPTED state will transition into another
 state based on the state of the partner:
 o  NORMAL or COMMUNICATIONS-INTERRUPTED: Transition into
    NORMAL state.
 o  RECOVER: Stay in COMMUNICATIONS-INTERRUPTED state.
 o  RECOVER-DONE: Transition into NORMAL state.
 o  PARTNER-DOWN, POTENTIAL-CONFLICT, CONFLICT-DONE, or
    RESOLUTION-INTERRUPTED: Transition into POTENTIAL-CONFLICT state.

Mrugalski & Kinnear Standards Track [Page 80] RFC 8156 DHCPv6 Failover Protocol June 2017

 Figure 8 illustrates the transition from NORMAL state to
 COMMUNICATIONS-INTERRUPTED state and then back to NORMAL state again.
           Primary                                Secondary
            Server                                  Server
            NORMAL                                  NORMAL
              | >--CONTACT------------------->         |
              |        <--------------------CONTACT--< |
              |         [TCP connection broken]        |
         COMMUNICATIONS-         :              COMMUNICATIONS-
           INTERRUPTED           :                INTERRUPTED
              |      [attempt new TCP connection]      |
              |         [connection succeeds]          |
              |                                        |
              | >--CONNECT------------------->         |
              |        <---------------CONNECTREPLY--< |
              | >--STATE--------------------->         |
              |                                     NORMAL
              |        <-------------------STATE-----< |
            NORMAL                                     |
              |                                        |
              | >--BNDUPD-------------------->         |
              |        <-------------------BNDREPLY--< |
              |                                        |
              |        <---------------------BNDUPD--< |
              | >------BNDREPLY-------------->         |
             ...                                      ...
              |                                        |
              |        <--------------------POOLREQ--< |
              | >--POOLRESP------------------>         |
              |                                        |
              | >--BNDUPD-(#1)--------------->         |
              |        <-------------------BNDREPLY--< |
              |                                        |
              | >--BNDUPD-(#2)--------------->         |
              |        <-------------------BNDREPLY--< |
              |                                        |
                Figure 8: Transition from NORMAL State
             to COMMUNICATIONS-INTERRUPTED State and Back

Mrugalski & Kinnear Standards Track [Page 81] RFC 8156 DHCPv6 Failover Protocol June 2017

8.10. POTENTIAL-CONFLICT State

 This state indicates that the two servers are attempting to
 reintegrate with each other but at least one of them was running in a
 state that did not guarantee that automatic reintegration would be
 possible.  In POTENTIAL-CONFLICT state, the servers may determine
 that the same lease has been offered and accepted by two different
 clients.
 A goal of the failover protocol is to minimize the possibility that
 POTENTIAL-CONFLICT state is ever entered.
 When a primary server enters POTENTIAL-CONFLICT state, it should
 request that the secondary send it all updates that the primary
 server has not yet acknowledged by sending an UPDREQ message to the
 secondary server.
 A secondary server entering POTENTIAL-CONFLICT state will wait for
 the primary to send it an UPDREQ message.

8.10.1. Operation in POTENTIAL-CONFLICT State

 Any server in POTENTIAL-CONFLICT state MUST NOT process any incoming
 DHCP requests.

8.10.2. Transition out of POTENTIAL-CONFLICT State

 If communication with the partner fails while in POTENTIAL-CONFLICT
 state, then the server will transition to RESOLUTION-INTERRUPTED
 state.
 Whenever either server receives an UPDDONE message from its partner
 while in POTENTIAL-CONFLICT state, it MUST transition to a new state.
 The primary MUST transition to CONFLICT-DONE state, and the secondary
 MUST transition to NORMAL state.  This will cause the primary server
 to leave POTENTIAL-CONFLICT state prior to the secondary, since the
 primary sends an UPDREQ message and receives an UPDDONE message
 before the secondary sends an UPDREQ message and receives its UPDDONE
 message.
 When a secondary server receives an indication that the primary
 server has made a transition from POTENTIAL-CONFLICT to CONFLICT-DONE
 state, it SHOULD send an UPDREQ message to the primary server.

Mrugalski & Kinnear Standards Track [Page 82] RFC 8156 DHCPv6 Failover Protocol June 2017

           Primary                                Secondary
           Server                                  Server
             |                                        |
       POTENTIAL-CONFLICT                    POTENTIAL-CONFLICT
             |                                        |
             | >--UPDREQ-------------------->         |
             |                                        |
             |        <---------------------BNDUPD--< |
             | >--BNDREPLY------------------>         |
            ...                                      ...
             |                                        |
             |        <---------------------BNDUPD--< |
             | >--BNDREPLY------------------>         |
             |                                        |
             |        <--------------------UPDDONE--< |
       CONFLICT-DONE                                  |
             | >--STATE--(CONFLICT-DONE)---->         |
             |        <---------------------UPDREQ--< |
             |                                        |
             | >--BNDUPD-------------------->         |
             |        <-------------------BNDREPLY--< |
            ...                                      ...
             | >--BNDUPD-------------------->         |
             |        <-------------------BNDREPLY--< |
             |                                        |
             | >--UPDDONE------------------->         |
             |                                     NORMAL
             |        <------------STATE--(NORMAL)--< |
          NORMAL                                      |
             | >--STATE--(NORMAL)----------->         |
             |                                        |
             |        <--------------------POOLREQ--< |
             | >------POOLRESP-------------->         |
             |                                        |
         Figure 9: Transition out of POTENTIAL-CONFLICT State

8.11. RESOLUTION-INTERRUPTED State

 This state indicates that the two servers were attempting to
 reintegrate with each other in POTENTIAL-CONFLICT state but
 communication failed prior to completion of reintegration.
 The RESOLUTION-INTERRUPTED state exists because servers are not
 responsive in POTENTIAL-CONFLICT state, and if one server drops out
 of service while both servers are in POTENTIAL-CONFLICT state, the
 server that remains in service will not be able to process DHCP

Mrugalski & Kinnear Standards Track [Page 83] RFC 8156 DHCPv6 Failover Protocol June 2017

 client requests and there will be no DHCP server available to process
 client requests.  The RESOLUTION-INTERRUPTED state is the state that
 a server moves to if its partner disappears while it is in
 POTENTIAL-CONFLICT state.
 When a server enters RESOLUTION-INTERRUPTED state, it SHOULD raise an
 alarm condition to alert administrative staff of a problem in the
 DHCP subsystem.

8.11.1. Operation in RESOLUTION-INTERRUPTED State

 In this state, a server MUST respond to all DHCP client requests.
 When allocating new leases, each server SHOULD allocate from its own
 pool (if that can be determined), where the primary SHOULD allocate
 only FREE leases and the secondary SHOULD allocate only FREE-BACKUP
 leases.  When responding to renewal requests, each server will allow
 continued renewal of a DHCP client's current lease, independent of
 whether that lease was given out by the receiving server or not,
 although the renewal period MUST NOT exceed the MCLT beyond the
 later of (1) the partner lifetime already acknowledged by the other
 server or (2) now.
 However, since the server cannot communicate with its partner in this
 state, the acknowledged partner lifetime will not be updated in any
 new bindings.

8.11.2. Transition out of RESOLUTION-INTERRUPTED State

 If a server in RESOLUTION-INTERRUPTED state receives an external
 command informing it that its partner is down, it will transition
 immediately into PARTNER-DOWN state.
 If communications with the other server are restored, then the server
 in RESOLUTION-INTERRUPTED state will transition into
 POTENTIAL-CONFLICT state.

8.12. CONFLICT-DONE State

 This state indicates that during the process where the two servers
 are attempting to reintegrate with each other, the primary server has
 received all of the updates from the secondary server.  It makes a
 transition into CONFLICT-DONE state so that it can be totally
 responsive to the client load.  There is no operational difference
 between CONFLICT-DONE and NORMAL for the primary server, as in both
 states it responds to all clients' requests.  The distinction between
 CONFLICT-DONE and NORMAL states is necessary in the event that a
 load-balancing extension is ever defined.

Mrugalski & Kinnear Standards Track [Page 84] RFC 8156 DHCPv6 Failover Protocol June 2017

8.12.1. Operation in CONFLICT-DONE State

 A primary server in CONFLICT-DONE state is fully responsive to all
 DHCP clients (similar to the situation in COMMUNICATIONS-INTERRUPTED
 state).
 If communication fails, remain in CONFLICT-DONE state.  If
 communication becomes "OK", remain in CONFLICT-DONE state until the
 conditions for transition out of CONFLICT-DONE state are satisfied.

8.12.2. Transition out of CONFLICT-DONE State

 If communication with the partner fails while in CONFLICT-DONE state,
 then the server will remain in CONFLICT-DONE state.
 When a primary server determines that the secondary server has made a
 transition into NORMAL state, the primary server will also transition
 into NORMAL state.

9. DNS Update Considerations

 DHCP servers (and clients) can use "DNS update" as described in
 RFC 2136 [RFC2136] to maintain DNS name mappings as they maintain
 DHCP leases.  Many different administrative models for DHCP-DNS
 integration are possible.  Descriptions of several of these models,
 and guidelines that DHCP servers and clients should follow in
 carrying them out, are laid out in RFC 4704 [RFC4704].
 The nature of the failover protocol introduces some issues concerning
 DNS updates that are not part of non-failover environments.  This
 section describes these issues and defines the information that
 failover partners should exchange in order to ensure consistent
 behavior.  The presence of this section should not be interpreted as
 a requirement that an implementation of the DHCPv6 failover protocol
 also support DNS updates.
 The purpose of this discussion is to clarify the areas where the
 failover and DHCP DNS update protocols intersect for the benefit of
 implementations that support both protocols, not to introduce a new
 requirement into the DHCPv6 failover protocol.  Thus, a DHCP server
 that implements the failover protocol MAY also support DNS updates,
 but if it does support DNS updates it SHOULD utilize the techniques
 described here in order to correctly distribute them between the
 failover partners.  See RFC 4704 [RFC4704] as well as RFC 4703
 [RFC4703] for information on how DHCP servers deal with potential
 conflicts when updating DNS even without failover.

Mrugalski & Kinnear Standards Track [Page 85] RFC 8156 DHCPv6 Failover Protocol June 2017

 From the standpoint of the failover protocol, there is no reason why
 a server that is utilizing the DNS update protocol to update a DNS
 server should not be a partner with a server that is not utilizing
 the DNS update protocol to update a DNS server.  However, a server
 that is not able to support DNS update or is not configured to
 support DNS update SHOULD output a warning message when it receives
 BNDUPD messages that indicate that its failover partner is configured
 to support the DNS update protocol to update a DNS server.  An
 implementation MAY consider this an error and refuse to accept the
 BNDUPD message by returning the status DNSUpdateNotSupported in an
 OPTION_STATUS_CODE option in the BNDREPLY message, or it MAY choose
 to operate anyway, having warned the administrator of the problem in
 some way.

9.1. Relationship between Failover and DNS Update

 The failover protocol describes the conditions under which each
 failover server may renew a lease to its current DHCP client and
 describes the conditions under which it may grant a lease to a new
 DHCP client.  An analogous set of conditions determines when a
 failover server should initiate a DNS update, and when it should
 attempt to remove records from the DNS.  The failover protocol's
 conditions are based on the desired external behavior: avoiding
 duplicate address and prefix assignments, allowing clients to
 continue using leases that they obtained from one failover partner
 even if they can only communicate with the other partner, and
 allowing the secondary DHCP server to grant new leases even if it is
 unable to communicate with the primary server.  The desired external
 DNS update behavior for DHCPv6 failover servers is similar to that
 described above for the failover protocol itself:
 1.  Allow timely DNS updates from the server that grants a lease to a
     client.  Recognize that there is often a DNS update "lifecycle"
     that parallels the DHCP lease lifecycle.  This is likely to
     include the addition of records when the lease is granted and the
     removal of DNS records when the lease is subsequently made
     available for allocation to a different client.
 2.  Communicate enough information between the two failover servers
     to allow one to complete the DNS update lifecycle even if the
     other server originally granted the lease.
 3.  Avoid redundant or overlapping DNS updates where both failover
     servers are attempting to perform DNS updates for the same
     lease-client binding.

Mrugalski & Kinnear Standards Track [Page 86] RFC 8156 DHCPv6 Failover Protocol June 2017

 4.  Avoid situations where one partner is attempting to add resource
     records (RRs) related to a lease binding while the other partner
     is attempting to remove RRs related to the same lease binding.
 While DHCPv6 servers configured for DNS update typically perform
 these operations on both the AAAA and the PTR RRs, this is not
 required.  It is entirely possible that a DHCPv6 server could be
 configured to only update the DNS with PTR records, and the DHCPv6
 clients could be responsible for updating the DNS with their own AAAA
 records.  In this case, the discussions here would apply only to the
 PTR records.

9.2. Exchanging DNS Update Information

 In order for either server to be able to complete a DNS update or to
 remove DNS records that were added by its partner, both servers need
 to know the FQDN associated with the lease-client binding.  In
 addition, to properly handle DNS updates, additional information is
 required.  All of the following information needs to be transmitted
 between the failover partners:
 1.  The FQDN that the client requested be associated with the lease.
     If the client doesn't request a particular FQDN and one is
     synthesized by the failover server or if the failover server is
     configured to replace a client-requested FQDN with a different
     FQDN, then the server-generated value would be used.
 2.  The FQDN that was actually placed in the DNS for this lease.  It
     may differ from the client-requested FQDN due to some form of
     disambiguation or other DHCP server configuration (as described
     above).
 3.  The status of any DNS update operations in progress or completed.
 4.  Information sufficient to allow the failover partner to remove
     the FQDN from the DNS, should that become necessary.
 These data items are the minimum necessary set to reliably allow two
 failover partners to successfully share the responsibility to keep
 the DNS up to date with the leases allocated to clients.
 This information would typically be included in BNDUPD messages sent
 from one failover partner to the other.  Failover servers MAY choose
 not to include this information in BNDUPD messages if there has been
 no change in the status of any DNS update related to the lease.

Mrugalski & Kinnear Standards Track [Page 87] RFC 8156 DHCPv6 Failover Protocol June 2017

 The partner server receiving BNDUPD messages containing the DNS
 update information SHOULD compare the status information and the FQDN
 with the current DNS update information it has associated with the
 lease binding and update its notion of the DNS update status
 accordingly.
 Some implementations will instead choose to send a BNDUPD message
 without waiting for the DNS update to complete and then will send a
 second BNDUPD message once the DNS update is complete.  Other
 implementations will delay sending the partner a BNDUPD message until
 the DNS update has been acknowledged by the DNS server, or until some
 time limit has elapsed, in order to avoid sending a second BNDUPD
 message.
 The FQDN option contains the FQDN that will be associated with the
 AAAA RR (if the server is performing a AAAA RR update for the
 client).  The PTR RR can be generated automatically from the IPv6
 address value.  The FQDN may be composed in any of several ways,
 depending on server configuration and the information provided by the
 client in its DHCP messages.  The client may supply a hostname that
 it would like the server to use in forming the FQDN, or it may supply
 the entire FQDN.  The server may be configured to attempt to use the
 information the client supplies, it may be configured with an FQDN to
 use for the client, or it may be configured to synthesize an FQDN.
 Since the server interacting with the client may not have completed
 the DNS update at the time it sends the first BNDUPD message about
 the lease binding, there may be cases where the FQDN in later BNDUPD
 messages does not match the FQDN included in earlier messages.  For
 example, the responsive server may be configured to handle situations
 where two or more DHCP client FQDNs are identical by modifying the
 most-specific label in the FQDNs of some of the clients in an attempt
 to generate unique FQDNs for them (a process sometimes called
 "disambiguation").  Alternatively, at sites that use some or all of
 the information that clients supply to form the FQDN, it's possible
 that a client's configuration may be changed so that it begins to
 supply new data.  The server interacting with the client may react by
 removing the DNS records that it originally added for the client and
 replacing them with records that refer to the client's new FQDN.  In
 such cases, the server SHOULD include the actual FQDN that was used
 in subsequent DNS update options in any BNDUPD messages exchanged
 between the failover partners.  This server SHOULD include relevant
 information in its BNDUPD messages.  This information may be
 necessary in order to allow the non-responsive partner to detect
 client configuration changes that change the hostname or FQDN data
 that the client includes in its DHCPv6 requests.

Mrugalski & Kinnear Standards Track [Page 88] RFC 8156 DHCPv6 Failover Protocol June 2017

9.3. Adding RRs to the DNS

 A failover server that is going to perform DNS updates SHOULD
 initiate the DNS update when it grants a new lease to a client.  The
 server that did not grant the lease SHOULD NOT initiate a DNS update
 when it receives the BNDUPD message after the lease has been granted.
 The failover protocol ensures that only one of the partners will
 grant a lease to any individual client, so it follows that this
 requirement will prevent both partners from initiating updates
 simultaneously.  The server initiating the update SHOULD follow the
 protocol in RFC 4704 [RFC4704].  The server may be configured to
 perform a AAAA RR update on behalf of its clients, or not.
 Ordinarily, a failover server will not initiate DNS updates when it
 renews leases.  In two cases, however, a failover server MAY initiate
 a DNS update when it renews a lease to its existing client:
 1.  When the lease was granted before the server was configured to
     perform DNS updates, the server MAY be configured to perform
     updates when it next renews existing leases.
 2.  If a server is in PARTNER-DOWN state, it can conclude that its
     partner is no longer attempting to perform an update for the
     existing client.  If the remaining server has not recorded that
     an update for the binding has been successfully completed, the
     server MAY initiate a DNS update.  It may initiate this update
     immediately upon entry into PARTNER-DOWN state, it may perform
     this in the background, or it may initiate this update upon next
     hearing from the DHCP client.
 Note that, regardless of the use of failover, there is a use case for
 updating the DNS on every lease renewal.  If there is a concern that
 the information in the DNS does not match the information in the DHCP
 server, updating the DNS on lease renewal is one way to gradually
 ensure that the DNS has information that corresponds correctly to the
 information in the DHCP server.

Mrugalski & Kinnear Standards Track [Page 89] RFC 8156 DHCPv6 Failover Protocol June 2017

9.4. Deleting RRs from the DNS

 The failover server that makes a lease PENDING-FREE SHOULD initiate
 any DNS deletes if it has recorded that DNS records were added on
 behalf of the client.
 A server not in PARTNER-DOWN state "makes a lease PENDING-FREE" when
 it initiates a BNDUPD message with a binding-status of FREE,
 FREE-BACKUP, EXPIRED, or RELEASED.  Its partner confirms this status
 by acking that BNDUPD message, and upon receipt of the BNDREPLY
 message the server has "made the lease PENDING-FREE".  Conversely, a
 server in PARTNER-DOWN state "makes a lease PENDING-FREE" when it
 sets the binding-status to FREE, since in PARTNER-DOWN state no
 communications with the partner are required.
 It is at this point that it should initiate the DNS operations to
 delete RRs from the DNS.  Its partner SHOULD NOT initiate DNS deletes
 for DNS records related to the lease binding as part of sending the
 BNDREPLY message.  The partner MAY have issued BNDUPD messages with a
 binding-status of FREE, EXPIRED, or RELEASED previously, but the
 other server will have rejected these BNDUPD messages.
 The failover protocol ensures that only one of the two partner
 servers will be able to make a lease PENDING-FREE.  The server making
 the lease PENDING-FREE may be doing so while it is communicating in
 NORMAL state with its partner, or it may be in PARTNER-DOWN state.
 If a server is in PARTNER-DOWN state, it may be performing DNS
 deletes for RRs that its partner added originally.  This allows a
 single remaining partner server to assume responsibility for all of
 the DNS update activity that the two servers were undertaking.
 Another implication of this approach is that no DNS RR deletes will
 be performed while either server is in COMMUNICATIONS-INTERRUPTED
 state, since no leases are moved into the PENDING-FREE state during
 that period.
 A failover server SHOULD ensure that a server failure while making a
 lease PENDING-FREE and initiating a DNS delete does not somehow leave
 the lease with an RR in the DNS with nothing recorded in the lease
 state database to trigger a DNS delete.

Mrugalski & Kinnear Standards Track [Page 90] RFC 8156 DHCPv6 Failover Protocol June 2017

9.5. Name Assignment with No Update of DNS

 In some cases, a DHCP server is configured to return a name to the
 DHCP client but not enter that name into the DNS.  This is typically
 a name that it has discovered or generated from information it has
 received from the client.  In this case, this name information SHOULD
 be communicated to the failover partner, if only to ensure that they
 will return the same name in the event the partner becomes the server
 with which the DHCP client begins to interact.

10. Security Considerations

 DHCPv6 failover is an extension of a standard DHCPv6 protocol, so all
 security considerations from Section 23 of [RFC3315] and Section 15
 of [RFC3633] related to the server apply.
 The use of TCP introduces some additional concerns.  Attacks that
 attempt to exhaust the DHCP server's available TCP connection
 resources can compromise the ability of legitimate partners to
 receive service.  Malicious requestors who succeed in establishing
 connections but who then send invalid messages, partial messages, or
 no messages at all can also exhaust a server's pool of available
 connections.
 DHCPv6 failover can operate in secure or insecure mode.  Secure mode
 (using Transport Layer Security (TLS) [RFC5246]) would be indicated
 when the TCP connection between failover partners is open to external
 monitoring or interception.  Insecure mode should only be used when
 the TCP connection between failover partners remains within a set of
 protected systems.  Details of such protections are beyond the scope
 of this document.  Failover servers MUST use the approach documented
 in Section 9.1 of [RFC7653] to decide whether or not to use TLS when
 connecting with the failover partner.
 The threats created by using failover directly mirror those from
 using DHCPv6 itself: information leakage through monitoring, and
 disruption of address assignment and configuration.  Monitoring the
 failover TCP connection provides no additional data beyond that
 available from monitoring the interactions between DHCPv6 clients and
 the DHCPv6 server.  Likewise, manipulating the data flow between
 failover servers provides no additional opportunities to disrupt
 address assignment and configuration beyond that provided by acting
 as a counterfeit DHCP server.  Protection from both threats is easier
 than with basic DHCPv6, as only a single TCP connection needs to be
 protected.  Either use secure mode to protect that TCP connection or
 ensure that it can only exist with a set of protected systems.

Mrugalski & Kinnear Standards Track [Page 91] RFC 8156 DHCPv6 Failover Protocol June 2017

 When operating in secure mode, TLS is used to secure the connection.
 The recommendations in [RFC7525] SHOULD be followed when negotiating
 a TLS connection.
 Servers SHOULD offer configuration parameters to limit the sources of
 incoming connections through validation and use of the digital
 certificates presented to create a TLS connection.  They SHOULD also
 limit the number of accepted connections and limit the period of time
 during which an idle connection will be left open.
 Authentication for DHCPv6 messages [RFC3315] MUST NOT be used to
 attempt to secure transmission of the messages described in this
 document.  If authentication is desired, secure mode using TLS SHOULD
 be employed as described in Sections 8.2 and 9.1 of [RFC7653].

11. IANA Considerations

 IANA has assigned values for the following new DHCPv6 message types
 in the registry maintained at <http://www.iana.org/assignments/
 dhcpv6-parameters>:
 o  BNDUPD (24)
 o  BNDREPLY (25)
 o  POOLREQ (26)
 o  POOLRESP (27)
 o  UPDREQ (28)
 o  UPDREQALL (29)
 o  UPDDONE (30)
 o  CONNECT (31)
 o  CONNECTREPLY (32)
 o  DISCONNECT (33)
 o  STATE (34)
 o  CONTACT (35)

Mrugalski & Kinnear Standards Track [Page 92] RFC 8156 DHCPv6 Failover Protocol June 2017

 IANA has assigned values for the following new DHCPv6 option codes in
 the registry maintained at <http://www.iana.org/assignments/
 dhcpv6-parameters>:
 o  OPTION_F_BINDING_STATUS (114)
 o  OPTION_F_CONNECT_FLAGS (115)
 o  OPTION_F_DNS_REMOVAL_INFO (116)
 o  OPTION_F_DNS_HOST_NAME (117)
 o  OPTION_F_DNS_ZONE_NAME (118)
 o  OPTION_F_DNS_FLAGS (119)
 o  OPTION_F_EXPIRATION_TIME (120)
 o  OPTION_F_MAX_UNACKED_BNDUPD (121)
 o  OPTION_F_MCLT (122)
 o  OPTION_F_PARTNER_LIFETIME (123)
 o  OPTION_F_PARTNER_LIFETIME_SENT (124)
 o  OPTION_F_PARTNER_DOWN_TIME (125)
 o  OPTION_F_PARTNER_RAW_CLT_TIME (126)
 o  OPTION_F_PROTOCOL_VERSION (127)
 o  OPTION_F_KEEPALIVE_TIME (128)
 o  OPTION_F_RECONFIGURE_DATA (129)
 o  OPTION_F_RELATIONSHIP_NAME (130)
 o  OPTION_F_SERVER_FLAGS (131)
 o  OPTION_F_SERVER_STATE (132)
 o  OPTION_F_START_TIME_OF_STATE (133)
 o  OPTION_F_STATE_EXPIRATION_TIME (134)

Mrugalski & Kinnear Standards Track [Page 93] RFC 8156 DHCPv6 Failover Protocol June 2017

 IANA has assigned values for the following new DHCPv6 status codes in
 the registry maintained at <http://www.iana.org/assignments/
 dhcpv6-parameters>:
 o  AddressInUse (16)
 o  ConfigurationConflict (17)
 o  MissingBindingInformation (18)
 o  OutdatedBindingInformation (19)
 o  ServerShuttingDown (20)
 o  DNSUpdateNotSupported (21)
 o  ExcessiveTimeSkew (22)

12. References

12.1. Normative References

 [RFC1035]  Mockapetris, P., "Domain names - implementation and
            specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
            November 1987, <http://www.rfc-editor.org/info/rfc1035>.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
            "Dynamic Updates in the Domain Name System (DNS UPDATE)",
            RFC 2136, DOI 10.17487/RFC2136, April 1997,
            <http://www.rfc-editor.org/info/rfc2136>.
 [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
            C., and M. Carney, "Dynamic Host Configuration Protocol
            for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315,
            July 2003, <http://www.rfc-editor.org/info/rfc3315>.
 [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
            Host Configuration Protocol (DHCP) version 6", RFC 3633,
            DOI 10.17487/RFC3633, December 2003,
            <http://www.rfc-editor.org/info/rfc3633>.

Mrugalski & Kinnear Standards Track [Page 94] RFC 8156 DHCPv6 Failover Protocol June 2017

 [RFC4703]  Stapp, M. and B. Volz, "Resolution of Fully Qualified
            Domain Name (FQDN) Conflicts among Dynamic Host
            Configuration Protocol (DHCP) Clients", RFC 4703,
            DOI 10.17487/RFC4703, October 2006,
            <http://www.rfc-editor.org/info/rfc4703>.
 [RFC4704]  Volz, B., "The Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
            Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
            <http://www.rfc-editor.org/info/rfc4704>.
 [RFC5007]  Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
            "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007,
            September 2007, <http://www.rfc-editor.org/info/rfc5007>.
 [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
            (TLS) Protocol Version 1.2", RFC 5246,
            DOI 10.17487/RFC5246, August 2008,
            <http://www.rfc-editor.org/info/rfc5246>.
 [RFC5460]  Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
            DOI 10.17487/RFC5460, February 2009,
            <http://www.rfc-editor.org/info/rfc5460>.
 [RFC6607]  Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet
            Selection Options for DHCPv4 and DHCPv6", RFC 6607,
            DOI 10.17487/RFC6607, April 2012,
            <http://www.rfc-editor.org/info/rfc6607>.
 [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
            "Recommendations for Secure Use of Transport Layer
            Security (TLS) and Datagram Transport Layer Security
            (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
            May 2015, <http://www.rfc-editor.org/info/rfc7525>.
 [RFC7653]  Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6
            Active Leasequery", RFC 7653, DOI 10.17487/RFC7653,
            October 2015, <http://www.rfc-editor.org/info/rfc7653>.
 [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
            RFC 2119 Key Words", BCP 14, RFC 8174,
            DOI 10.17487/RFC8174, May 2017,
            <http://www.rfc-editor.org/info/rfc8174>.

Mrugalski & Kinnear Standards Track [Page 95] RFC 8156 DHCPv6 Failover Protocol June 2017

12.2. Informative References

 [RFC7031]  Mrugalski, T. and K. Kinnear, "DHCPv6 Failover
            Requirements", RFC 7031, DOI 10.17487/RFC7031,
            September 2013, <http://www.rfc-editor.org/info/rfc7031>.

Acknowledgements

 This document extensively uses concepts, definitions, and other parts
 of an effort to document failover for DHCPv4.  The authors would like
 to thank Shawn Routhier, Greg Rabil, Bernie Volz, and Marcin
 Siodelski for their significant involvement and contributions.  In
 particular, Bernie Volz and Shawn Routhier provided detailed and
 substantive technical reviews of the document.  The RFC Editor also
 caught several important technical issues.  The authors would like to
 thank Vithalprasad Gaitonde, Krzysztof Gierlowski, Krzysztof Nowicki,
 and Michal Hoeft for their insightful comments.

Authors' Addresses

 Tomek Mrugalski
 Internet Systems Consortium, Inc.
 950 Charter Street
 Redwood City, California  94063
 United States of America
 Email: tomasz.mrugalski@gmail.com
 Kim Kinnear
 Cisco Systems, Inc.
 200 Beaver Brook Road
 Boxborough, Massachusetts  01719
 United States of America
 Phone: +1 978 936 0000
 Email: kkinnear@cisco.com

Mrugalski & Kinnear Standards Track [Page 96]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8156.txt · Last modified: 2017/06/08 21:57 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki