tech-invite   World Map     

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

RFC 8156

Proposed STD
Pages: 96
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: DHC

DHCPv6 Failover Protocol

Part 1 of 5, p. 1 to 18
None       Next Section

 


Top       ToC       Page 1 
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.

Top       Page 2 
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

Top      ToC       Page 3 
           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

Top      ToC       Page 4 
      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

Top      ToC       Page 5 
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.

Top      ToC       Page 6 
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".

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
   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.

Top      ToC       Page 9 
   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.

Top      ToC       Page 10 
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.

Top      ToC       Page 11 
   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.

Top      ToC       Page 12 
   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).

Top      ToC       Page 13 
   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

Top      ToC       Page 14 
   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

Top      ToC       Page 15 
   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.

Top      ToC       Page 16 
   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

Top      ToC       Page 17 
   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.

Top      ToC       Page 18 
 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


Next Section