Network Working Group                                        Ralph Droms
INTERNET DRAFT                                       Bucknell University

                                                             Kim Kinnear
                                                              Mark Stapp
                                                           Cisco Systems

                                                             Bernie Volz
                                                            Steve Gonczi
                                                        Process Software

                                                              Greg Rabil
                                                             Mike Dooley
                                                              Arun Kapur
                                                     Lucent Technologies

                                                            October 1999

                                                              March 2000
                                                  Expires April September 2000

                         DHCP Failover Protocol
                    <draft-ietf-dhc-failover-05.txt>
                    <draft-ietf-dhc-failover-06.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (1999). (2000). All Rights Reserved.

Abstract

   DHCP [RFC 2131] allows for multiple servers to be operating on a
   single network.  Some sites are interested in running multiple
   servers in such a way so as to provide redundancy in case of server
   failure.  In order for this to work reliably, the cooperating primary
   and secondary servers must maintain a consistent database of the
   lease information.  This implies that servers will need to coordinate
   any and all lease activity so that this information is synchronized
   in case of failover.

   This document defines a protocol to provide this such synchronization
   between two servers.  One server is designated the "primary" server,
   the other is the "secondary" server.  This document also describes a
   way to integrate the failover protocol with the DHCP loadbalancing load balancing
   approach.

   This document is a significant substantial reorganization as well as a technical
   and editorial revision of draft-ietf-dhc-failover-
   04.txt. draft-ietf-dhc-failover-05.txt.

Table of Contents

    1.  Introduction................................................. 4
    2.  Terminology.................................................. 5
    2.1.  Requirements terminology................................... 5
    2.2.  DHCP and failover terminology.............................. 5
    3.  Background and External Requirements......................... 8
    3.1.  Key aspects of the DHCP protocol........................... 8 9
    3.2.  BOOTP relay agent implementation........................... 10 11
    3.3.  What does it mean if a server can't communicate with its partner? 11 12
    3.4.  Challenging scenarios for a Failover protocol.............. 12
    3.5.  Using TCP to detect partner server failure................. 13
    4.  Design Goals................................................. 14 15
    4.1.  Design requirements for this protocol...................... 14
    4.2.  Goals goals for this protocol.................................... protocol............................. 15
    4.3.
    4.2.  Limitations of this Protocol............................... protocol............................... 16
    5.  Protocol Overview............................................ 16 17
    5.1.  Messages and States........................................ 17
    5.2.  Fundamental restrictions................................... guarantees..................................... 19
    5.3.  Load balancing............................................. 26
    5.4.  Operating in NORMAL state.................................. 27
    5.5.  Operating in COMMUNICATIONS-INTERRUPTED state.............. 27
    5.6.  Operating in PARTNER-DOWN state............................ 27
    5.7.  Operating in RECOVER state................................. 28 27
    5.8.  Operating in STARTUP state................................. 28
    5.  Protocol Overview (continued)
    5.9.  Time synchronization between servers....................... 28
    5.10.  IP address binding-status................................. 29
    5.11.  DNS dynamic update considerations......................... 34 32
    5.12.  Reservations and failover................................. 38 36
    5.13.  Dynamic BOOTP and failover................................ 39 37
    5.14.  Guidelines for selecting MCLT............................. 39 38
    6.  Packet Formats............................................... 40
    6.1.  Common message Message Format........................................ 39
    6.1.  Message header format...................................... 40 39
    6.2.  Common option format....................................... 43 42
    6.3.  Batching multiple binding update transactions in one BNDUPD message format...................................... 55
    6.4.  BNDACK message format...................................... 58
    6.5.  Bulking for BNDUPD and BNDACK messages..................... 59
    6.6.  UPDREQ message format...................................... 60
    6.7.  UPDREQALL message format................................... 60
    6.8.  UPDDONE message format..................................... 60
    6.9.  POOLREQ message format..................................... 61
    6.10.  POOLRESP message format................................... 61
    6.11.  CONNECT message format.................................... 62
    6.12.  CONNECTACK message format................................. 62
    6.13.  STATE message format...................................... 63
    6.14.  CONTACT message format.................................... 64
    6.15.  DISCONNECT message format................................. 64 mes- 42
    7.  Protocol Messages............................................ 64 44
    7.1.  BNDUPD message............................................. 64 44
    7.2.  BNDACK message............................................. 75 54
    7.3.  UPDREQ message............................................. 76 57
    7.4.  UPDREQALL message.......................................... 78 59
    7.5.  UPDDONE message............................................ 79 59
    7.6.  POOLREQ message............................................ 80 60
    7.7.  POOLRESP message........................................... 81 61
    7.8.  CONNECT message............................................ 81 62
    7.9.  CONNECTACK message......................................... 85 66
    7.10.  STATE message............................................. 88 70
    7.11.  CONTACT message........................................... 89 71
    7.12.  DISCONNECT message........................................ 89 72
    8.  Connection Management........................................ 90 73
    8.1.  Connection granularity..................................... 90 73
    8.2.  Creating the TCP connection................................ 90 73
    8.3.  Using the TCP connection for determining communications status 91 75
    8.4.  Using the TCP connection for binding data.................. 93 77
    8.5.  Using the TCP connection for control messages.............. 94 77
    8.6.  Losing the TCP connection.................................. 94 77
    9.  Protocol States.............................................. 94  Failover Endpoint States..................................... 78
    9.1.  Server Initialization...................................... 95 78
    9.2.  Server State Transitions................................... 95 78
    9.3.  STARTUP state.............................................. 98 81
    9.4.  PARTNER-DOWN state......................................... 100 83
    9.5.  RECOVER state.............................................. 102 85
    9.6.  NORMAL state............................................... 104 88
    9.7.  COMMUNICATIONS-INTERRUPTED State........................... 107 90
    9.8.  POTENTIAL-CONFLICT state................................... 110 94
    9.9.  RESOLUTION-INTERRUPTED state............................... 111 95
    9.10.  RECOVER-DONE state........................................ 112 96
    9.11.  PAUSED state.............................................. 113 97
    9.12.  SHUTDOWN state............................................ 113 97
    10.  Safe Period................................................. 114 98
    11.  Security.................................................... 116 100
    11.1.  Simple shared secret...................................... 116 100
    11.2.  TLS....................................................... 117 101
    12.  Acknowledgments............................................. 117  Failover Options............................................ 102
    12.1.  addresses-transferred..................................... 102
    12.2.  assigned-IP-address....................................... 102
    12.3.  binding-status............................................ 103
    12.4.  client-identifier......................................... 103
    12.5.  client-hardware-address................................... 103
    12.6.  client-last-transaction-time.............................. 104
    12.7.  client-reply-options...................................... 104
    12.8.  client-request-options.................................... 105
    12.9.  DDNS...................................................... 106
    12.10.  hash-bucket-assignment................................... 107
    12.11.  lease-expiration-time.................................... 107
    12.12.  max-unacked-bndupd....................................... 107
    12.13.  MCLT..................................................... 108
    12.14.  message.................................................. 108
    12.15.  message-digest........................................... 108
    12.16.  potential-expiration-time................................ 109
    12.17.  receive-timer............................................ 109
    12.18.  protocol-version......................................... 109
    12.19.  reject-reason............................................ 110
    12.20.  sending-server-IP-address................................ 111
    12.21.  server-flags............................................. 111
    12.22.  server-state............................................. 112
    12.23.  start-time-of-state...................................... 112
    12.24.  TLS-reply................................................ 113
    12.25.  TLS-request.............................................. 113
    12.26.  vendor-class-identifier.................................. 113
    12.27.  vendor-specific-options.................................. 114
    13.  References.................................................. 119  IANA Considerations......................................... 114
    14.  Acknowledgments............................................. 114
    15.  References.................................................. 116
    16.  Author's information........................................ 120
    15. 117
    17.  Full Copyright Statement.................................... 121 118

1.  Introduction

   DHCP [RFC 2131] allows for multiple servers to be operating on a sin-
   gle network.  Some sites are interested in running multiple servers
   in such a way so as to provide redundancy in case of server failure
   since the DHCP subsystem is in many cases a critical part of the net-
   work infrastructure.

   This document defines a protocol to provide synchronization between
   two servers in order that each can take over for the other should
   either one fail or become unreachable.

   One server is designated the "primary" server,  the other is the
   "secondary" server, and all DHCP client requests are sent to each
   server.

   In order to provide a  high availability DHCP service, these
   cooperating primary and secondary servers must maintain a consistent
   database of lease information.  This implies that servers will need
   to coordinate any and all lease activity so that this information is
   synchronized syn-
   chronized in case failover is required.  The protocol messages and
   processing techniques required to maintain a consistent database are
   specified in the protocol described here.

   The failover protocol also contains an algorithm which allows each
   server to determine a way to which integrate the DHCP clients it should provide service
   when both servers are operating normally, and this capability can be
   used to support load balancing. load-
   balancing algorithm described in [LOADB] with the failover protocol.

2.  Terminology

   This section discusses both the generic requirements terminology com-
   mon to many IETF protocol specifications as well as specialized DHCP
   and failover protocol specific terminology.

2.1.  Requirements terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC 2119].

2.2.  DHCP and failover terminology

   This document uses the following terms:

      o  "binding"

         A binding is a collection of configuration parameters, includ-
         ing at least an IP address, associated with or "bound to" a
         DHCP client.  Bindings are managed by DHCP servers.

      o  "binding database"

         The collection of bindings managed by a primary and secondary.

      o  "binding update transaction"

         A binding update transaction refers to the set of information
         (contained in options) necessary to perform a binding update
         for a single IP address.  It will be comprised of the
         assigned-IP-address option and the binding-status option, along
         other options as appropriate.

      o  "binding-status"

         The binding-status is the status of an IP address with respect
         to its association with a client.  There are specific binding-
         status values defined for use by the failover protocol, e.g.,
         ACTIVE, FREE, RELEASED, ABANDONED, etc.  These are designed to
         map more or less directly onto the binding-status values used
         internally in most DHCP server implementations.  The term
         binding-status refers to the concept also sometimes known as
         "lease state" or "IP address state", but in this document the
         term "state" is reserved for the failover state of a failover
         endpoint, and binding-status is always used to refer to the
         state associated with an IP address or lease.

      o "DHCP client" or "client"

        A DHCP client is an Internet host using DHCP to obtain confi-
        guration parameters such as a network address.  The term
        "client" used within this document always means a DHCP client,
        and never one of the two failover servers.

      o "DHCP server" or "server"

        A DHCP server is an Internet host that returns configuration
        parameters to DHCP clients.

      o "binding"

        A binding is "DDNS"

        An abbreviation for "Dynamic DNS", which refers to the capabil-
        ity to update a collection of configuration parameters, including
        at least DNS server's name (actually resource record)
        database using an IP address, associated with or "bound to" a DHCP
        client.  Bindings are managed by DHCP servers. on-the-wire protocol defined in [RFC 2136].

      o "binding database"

        The collection of bindings managed by "DNS"

        An abbreviation for "Domain Name System", a primary scheme where a cen-
        tral name repository is used to map names to IP addresses and secondary. IP
        addresses to names.

      o "failover endpoint"

        The failover protocol allows for there to be a unique failover
        endpoint per partner per role (where role is primary or secon-
        dary).  This failover endpoint can take actions and hold unique
        states.  There are thus a maximum of two failover endpoints per
        server per partner (one for each partner as a primary and one
        for that same partner as a secondary.)

      o "lazy update"

        Lazy update refers to the requirement "FQDN"
        An FQDN is a "fully qualified domain name".  A fully qualified
        domain name generally is a host name with at least one zone
        name, for example "www.dhcp.org" is a fully qualified domain
        name.

      o "lazy update"

        Lazy update refers to the requirement placed on a server imple-
        menting a failover protocol to update its failover partner when-
        ever the binding database changes.  A failover protocol which
        didn't support lazy update would require the failover partner
        update to be complete before a DHCP server could respond to a
        DHCP client request with a DHCPACK.  A failover protocol which
        does support lazy update places no such restriction on the
        update of the failover partner server, and so a server can allo-
        cate an IP address or extend a lease on an IP address and then
        update its failover partner as time permits.  A failover proto-
        col which supports lazy update not only removes the requirement
        to update the failover partner prior to responding to a DHCP
        client with a DHCPACK, but also allows gathering up batches of
        updates from one failover server to its partner.

      o "subnet address pool"

        A subnet address pool is the set of IP address which is associ-
        ated with a particular network number and subnet mask.  In the
        simple case, there is a single network number and subnet mask
        and a set of IP addresses.  In the more complex case (sometimes
        called "secondary subnets", sometimes "superscopes"), several
        (apparently unrelated) network number and subnet mask combina-
        tions with their associated IP addresses may all be configured
        together into one subnet address pool.

      o "Primary server" or "Primary"

        A DHCP server configured to provide primary service to a set of
        DHCP clients for a particular set of subnet address pools.

      o "Secondary server" or "Secondary"

        A DHCP server configured to act as backup to a primary server
        for a particular set of subnet address pools.

      o "stable storage"

        Every DHCP server is assumed to have some form of what is called
        "stable storage".  Stable storage is used to hold information
        concerning IP address bindings (among other things) so that this
        information is not lost in the event of a server failure which
        requires restart of the server.

      o "MCLT"

        The MCLT refers to maximum client lead time.  This time is con-
        figured on the primary server and transmitted from the primary
        to the secondary server in the CONNECT message.  It is the max-
        imum amount of time that one server can give to extend a client lease for a
        client's binding beyond that the time known and ACKed by the partner server.
        See section 5.2.1 for details.

      o "DNS"

        An abbreviation for "Domain Name System", a scheme where a cen-
        tral name repository is used to map names to IP addresses and IP
        addresses to names.

      o "FQDN"

        An FQDN is a "fully qualified domain name".  A fully qualified
        domain name generally is a host name with at least one zone
        name, for example "www.dhcp.org" is a fully qualified domain
        name.

      o "partner"

        A "partner", for the purposes of this document, refers to a
        failover server, typically the other failover server.  In many
        (if not most) cases, the failover protocol is symmetric with
        respect to the primary or secondary nature of the servers, and
        so it is often appropriate to dicuss discuss "updating the partner
        server", since it could be a primary server updating a secondary
        server or a secondary server updating a primary server.

      o "Primary server" or "Primary"

        A DHCP server configured to provide primary service to a set of
        DHCP clients for a particular set of subnet address pools.

      o "RR"
        "RR" is an abbreviation for "resource record".  All records in
        the DNS are resource records.  The resource records of most
        relevance to this document are the "A" resource record, which
        maps a DNS name to a particular IP address, the "PTR" resource
        record, which allows a "reverse map", from the IP address back
        to a DNS name, and the "KEY" resource record, which is used in
        ways defined in [DDNS] to tag a DNS name with the identity of
        the DHCP client with which it is associated.

      o "DDNS"

        An abbreviation for "Dynamic DNS", which refers "Secondary server" or "Secondary"

        A DHCP server configured to the capabil-
        ity act as backup to update a DNS server's name (actually resource record)
        database using an on-the-wire protocol defined in [RFC2136]. primary server
        for a particular set of subnet address pools.

      o "binding-status"
        The binding-status "stable storage"

        Every DHCP server is the status assumed to have some form of an what is called
        "stable storage".  Stable storage is used to hold information
        concerning IP address with respect
        to its association with a client.  There are specific binding-
        status values defined for use by the failover protocol, e.g.,
        ACTIVE, FREE, RELEASED, ABANDONED, etc.  These are designed to
        map more or less directly onto the binding-status values used
        internally bindings (among other things) so that this
        information is not lost in most DHCP the event of a server implementations.  The term
        binding-status refers to failure which
        requires restart of the concept also sometimes known as
        "lease state" or "IP address state", but in server.

      o "state"

        In this document document, the term "state" is reserved for refers exclusively to the failover
        state of a failover endpoint, and binding-status for example: NORMAL,
        COMMUNICATIONS-INTERRUPTED, PARTNER-DOWN.  It is always not used to
        refer to the
        state associated with any attributes of an IP address or lease. a binding of an IP
        address.  See "binding-status".

      o "subnet address pool"

        A subnet address pool is the set of IP address which is associ-
        ated with a particular network number and subnet mask.  In the
        simple case, there is a single network number and subnet mask
        and a set of IP addresses.  In the more complex case (sometimes
        called "secondary subnets", sometimes "superscopes"), several
        (apparently unrelated) network number and subnet mask combina-
        tions with their associated IP addresses may all be configured
        together into one subnet address pool.

3.  Background and External Requirements

   This section highlights key aspects of the DHCP protocol on which the
   failover protocol depends.  It also discusses the requirements that
   the failover protocol places on other aspects of the network infras-
   tructure, and some general issues surrounding server failure detec-
   tion.
   detection.  Some failure scenarios that provide particular challenges
   to a failover protocol are discussed.  Finally, the challenges
   inherent in using a TCP connection as a means to detect failure of a
   partner server are elaborated.

3.1.  Key aspects of the DHCP protocol

   The failover protocol is designed to augment the DHCP protocol as
   described in RFC 2131 [RFC 2131].  There are several key aspects of
   the DHCP protocol which are required by the failover protocol in
   order to successfully meet its design goals.

3.1.1.  Broadcast behavior

   There are two aspects of the broadcast behavior of the DHCP protocol
   which are key to making the failover protocol operate successfully.
   The first is simply that the DHCP protocol requires a DHCP client to
   broadcast all DHCPDISCOVER and DHCPREQUEST/INIT-REBOOT messages.
   Because of this requirement, a DHCP client who was communicating with
   one server will automatically be able to communicate with another
   server if one is available.

   The second aspect of broadcast behavior is similar to the first, but
   involves the distinction between a DHCPREQUEST/RENEW and
   DHCPREQUEST/REBINDING.  A DHCPREQUEST/RENEW is the message that a
   DHCP client uses to extend its lease.  It is unicast to the DHCP
   server from which it acquired the lease.   However, the DHCP protocol
   (in a farsighted move), was explicitly designed so that in the event
   that a DHCP client cannot contact the server from which it received a
   lease on an IP address using a DHCPREQUEST/RENEW, the client is
   required to broadcast its renewal using a DHCPREQUEST/REBINDING to
   any available DHCP server.  Since all DHCP clients were required to
   implement this algorithm, the failover protocol can have a different
   server from the one that initially granted a lease be the server to
   renew a lease.  Thus, one server can take over for another with no
   interruption in the service as experience experienced by the DHCP client or its
   associated applications software.

3.1.2.  Client responsibility

   In the DHCP protocol the DHCP clients are entrusted with a consider-
   able responsibility.  In particular, after they are granted a lease
   on an IP address, they are enjoined to only use that IP address while
   their lease is valid.  Every DHCP client is expected to stop using an
   IP address if the expiration time on the lease has passed and if it
   cannot get an extension on the lease for that IP address from some
   DHCP server.  Thus, the correct behavior of every DHCP client in this
   regard is required to ensure the integrity of the DHCP service.  On
   the other hand, incorrect behavior by a client in this area will tend
   to adversely affect at most one other DHCP client.

   Furthermore, any DHCP client which sends in a DHCPREQUEST/RENEW or
   DHCPREQUEST/REBINDING to a DHCP server (either unicast for a RENEW or
   broadcast for a REBINDING) MUST still have time to run on the lease
   for that IP address.  The DHCP server sends the DHCPACK back unicast
   to the IP address from which the RENEW or REBINDING originated.

   Given the existing responsibility placed on the client to only use an
   IP address when the lease is valid, and to only send in a RENEW or
   REBINDING if the lease is valid, the failover protocol relies on DHCP
   clients to perform responsibly and will, in the absence of conflict-
   ing information, believe a DHCP client that is attempting to RENEW or
   REBIND a lease on an IP address is the legitimate owner of that IP
   address.

   If clients do not follow these rules, it is possible for an address
   to be in use by more than one client. For a single server, this hap-
   pens because the server has leased the expired address to another
   client and the original client is also attempting to use the address.
   The server would NAK the renewal request. This is made slightly worse
   in the failover protocol if the two servers are unable to communicate
   with each other and one server leases an available address to a new
   client while the other server receives a renewal from a different
   client.  In this case, both servers lease the same address to dif-
   ferent clients for the MCLT time.

   One troublesome issue is that of the DHCP client responsibility when
   sending in DHCPREQUEST/INIT-REBOOT requests.  While the original DHCP
   RFC was written to require a DHCP client to have time left to run on
   the lease for an IP address if the client is sending an INIT-REBOOT
   request, it was sufficiently unclear that some client vendors didn't
   realize this until recently.  Since the INIT-REBOOT request was sent
   with the IP address in the dhcp-requested-address option and not in
   the ciaddr (for perfectly good reasons), the similarity to the RENEW
   and REBINDING case was lost on many people.

   At present, the failover protocol does not assume that a client send-
   ing in an INIT-REBOOT request necessarily has a valid lease on the IP
   address appearing in the dhcp-requested-address option in the INIT-
   REBOOT request.

   The implications of this are as follows: Assume that there is a DHCP
   client that gets a lease from one server while that server is unable
   to communicate with its failover partner.  Then, assume that after
   that client reboots it is able only to communicate with the other
   failover server.  If the failover servers have not been able to com-
   municate
   communicate with each other during this process, then the DHCP client
   will get a new IP address instead of being able to continue to use
   its existing IP address. This will affect no applications on the DHCP
   client, since it is rebooting.  However, it will use up an additional
   IP address in this marginal case.

3.1.3.  Stable storage update before DHCPACK

   The DHCP protocol allocates resources, and in order to operate
   correctly it requires that a DHCP server update some form of stable
   storage prior to sending a DHCPACK to a DHCP client in order to grant
   that client a lease on an IP address.

   One of the goals of the failover protocol is that it not add signifi-
   cant additional time to this already time consuming requirement to
   update stable storage prior to a DHCPACK.  In particular, adding a
   requirement to communicate with another server prior to sending a
   DHCPACK would greatly simplify the failover protocol, but it would
   limit the potential scalability of any DHCP server which employed the
   failover protocol in an unacceptable manner.

3.2.  BOOTP relay agent implementation

   Many DHCP clients are not resident on the same network segment as a
   DHCP server.  In order to support this form of network architecture,
   most contemporary routers implement something known as a BOOTP Relay
   Agent.  This capability inside of a router listens for all broadcasts
   at the DHCP port, port 67, and will relay any broadcasts that it
   receives on to a DHCP server.  The IP address of the DHCP server must
   have been previously configured into the router.  As part of the
   relay process, the relay agent will place the address of the inter-
   face on which it received the broadcast into the giaddr field of the
   DHCP packet.

   Since the failover protocol requires two DHCP servers to receive any
   broadcast DHCP messages, in order to work with DHCP clients which are
   not local to the DHCP server, the BOOTP relay agent on the router
   closest to the DHCP client must be configured to point at more than
   one DHCP server.

   Most BOOTP relay agent implementations allow this duplication of
   packets.

   If this is not possible, an administrator might be able to configure
   the relay agent with a subnet broadcast address, but in this case the
   primary and secondary DHCP servers in a failover pair must both
   reside on the same subnet.   While this is a realistic configuration,
   it is not the one that most people will use.

3.3.  What does it mean if a server can't communicate with its partner?

   In any protocol designed to allow one server to take over some
   responsibilities from a partner server in the event of "failure" of
   that partner server, there is an inherent difficulty in determining
   when that partner server has failed.

   In fact, it is fundamentally impossible for one server to distinguish
   a network communications failure from the outright failure of the
   server to which it is trying to communicate.  In the case where each
   server is handing out resources (in this case IP addresses) to a
   client community, mistaking an inability to communicate with a
   partner server for failure of that partner server could easily cause
   both servers to be handing out the same IP addresses to different
   clients.

   One way that this is sometimes handled is for there to be more than
   two servers.  In the case of an odd number of servers, the servers
   that can still communicate with a majority of other servers will con-
   sider themselves operational, and any server which can't communicate
   to a majority of other servers must immediately cease operations.

   While this technique works in some domains, having the only server to
   which a DHCP client can communicate voluntarily shut itself down
   seems like something worth avoiding.

   The failover protocol will operate correctly while both servers are
   unable to communicate, whether they are both running or not.  At some
   point there may be resource contention, and if one of the servers is
   actually down, then the operator can inform the other operational server
   and the operational server will be able to use all of the downed failed
   server's resources.

   The protocol also allows detection of an orderly shutdown of a parti-
   cipating server.

3.4.  Challenging scenarios for a Failover protocol

   There exist two failure scenarios which provide particular challenges
   to the correctness guarantees of a failover protocol.

3.4.1.  Primary Server crash before "lazy" update:

   In the case where the primary server sends a DHCPACK to a client for
   a newly allocated IP address and then crashes prior to sending the
   corresponding update to the secondary server, the secondary server
   will have no record of the IP address allocation.  When the secondary
   server takes over, it may well try to allocate that IP address to a
   different client.  In the case where the first client to receive the
   IP address is not on the net at the time (yet while there was still
   time to run on its lease), an ICMP echo (i.e., ping) will not prevent
   the secondary server from allocating that IP address to a different
   client.

   The failover protocol deals with this situation by having the primary
   and secondary servers allocate addresses for new clients from dis-
   joint address pools.  See section 5.4 for details.

   A more likely (in that DHCPRENEWs are presumably more common than
   DHCPDISCOVERs) and more subtle version of this problem is where the
   primary server crashes after extending a client's lease time, and
   before updating the secondary with a new time using a lazy update.
   After the secondary takes over, if the client is not connected to the
   network the secondary will believe the client's lease has expired
   when, in fact, it has not.  In this case as well, the IP address
   might be reallocated to a different client while the first client is
   still using it.

   This scenario is handled by the failover protocol through control of
   the lease time and the use of the maximum client lead time (MCLT).
   See section 5.2.1  for details.

3.4.2.  Network partition where DHCP servers can't communicate but each
can talk to clients:

   Several conditions are required for this situation to occur.  First,
   due to a network failure, the primary and secondary servers cannot
   communicate.  As well, some of the DHCP clients must be able to com-
   municate with the primary server, and some of the clients must now
   only be able to communicate with the secondary server.  When this
   condition occurs, both primary and secondary servers could attempt to
   allocate IP addresses for new clients from the same pool of available
   addresses.  At some point, then, two clients will end up being allo-
   cated the same IP address.  This will cause problems when the network
   failure that created this situation is corrected.

   The failover protocol deals with this situation by having the primary
   and secondary servers allocate addresses for new clients from dis-
   joint address pools.  See section 5.4 for details.

3.5.  Using TCP to detect partner server failure

   There are several characteristics of TCP that are important to the
   functioning of the failover protocol, which uses one TCP connection
   for both bulk data transfer as well as to assess communications
   integrity with the other server.  Reliable and ordered message
   delivery are chief among these important characteristics.

   It would be nice to use the capabilities built in to TCP to allow it
   to determine if communications integrity exists to the failover
   partner but this strategy contains some problems which require
   analysis.  There exist three fundamental cases for an open TCP con-
   nection that must be examined.

      1.  When no data is being sent then no messages are traveling
          across the TCP connection.

      2.  When data is queued to be sent, and the receiver has not
          blocked the sending of additional data, then messages are
          flowing across the TCP connection containing the applications
          data.

      3.  When data is queued to be sent, and the receiver has blocked
          the transmission of additional data, then persist messages are
          flowing from the receiver to the sender to ensure that the
          sender doesn't miss the receiver opening the window for
          further transmissions.

   The first case can be turned into the second case by sending
   application-level keep-alive messages periodically when there is no
   other data queued to be sent.  Note TCP keep-alive messages might be
   used as well, but they present additional problems.

   Thus, we can ensure that the TCP connection has messages flowing
   periodically across the connection fairly easily.  The question
   remains as to what TCP will do if the other end of the connection
   fails to respond (either because of network partition or because the
   receiving server crashes). TCP will attempt to retransmit a message
   with an exponential backoff, and will eventually timeout that
   retransmission.  However, the length of that timeout cannot, in gen-
   eral, be set on a per-connection basis, and is frequently as long as
   nine minutes, though in some cases it may be as short as two minutes.
   One
   On some systems it can be set system-wide, while on some other systems it
   cannot be changed at all.

   A value for this timeout that would be appropriate for the failover
   protocol, say less than 1 minute, could have unpleasant side-effects
   on other applications running on the same server, assuming that it
   could be changed at all on the host operating system.

   Nine minutes is a long time for the DHCP service to be unavailable to
   any new clients that were being served by the server which has
   crashed, when there is another server running that could respond to
   them immediately as soon as it determines that its partner is not operational.

   The conclusion drawn from this analysis is that TCP provides very
   useful support for the failover protocol in the areas of reliable and
   ordered message delivery, but cannot by itself be relied upon to
   detect partner server failure in a fashion acceptable to the needs of
   the failover protocol.  Additional failover protocol capabilities
   will need to be
   have been created to support timely detection of partner server
   failure.  See section 8.3 for details on this mechanism.

4.  Design Goals

   This section lists the design requirements, the design goals, goals and the limitations of the
   failover protocol.

4.1.  Design requirements goals for this protocol

   The following list of requirements must be (and are) goals that are met by this pro-
   tocol. protocol.  They are
   listed in priority order.

      1.  Implementations of this protocol must work with existing DHCP
          client implementations based on the DHCP protocol [1].

      2.  Implementations of the protocol must work with existing BOOTP
          relay agent implementations.

      3.  The protocol must provide failover redundancy between servers
          that are not located on the same subnet.

4.2.  Goals for this protocol

   The following goals are met by this protocol as well, though they are
   less important than the requirements listed above. These goals are
   listed in priority order.

      1.

      4.  Provide for continued service to DHCP clients through an
          automated mechanism in the event of failure of the primary
          server.

      2.

      5.  Avoid binding an IP address to a client while that binding is
          currently valid for another client.  In other words, do not
          allocate the same IP address to two clients.

      3.

      6.  Minimize any need for manual administrative intervention.

      4.

      7.  Introduce no additional delays in server response time as a
          result of the network communications required to implement the
          failover protocol, i.e., don't require communications with the
          partner between the receipt of a DHCPREQUEST and the
          corresponding DHCPACK.

      5.

      8.  Share IP address ranges between primary and secondary servers;
          i.e., impose no requirement that the pool of available
          addresses be manually or permanently divided between servers.

      6.

      9.  Continue to meet the goals and objectives of this protocol in
          the event of server failure or network partition.

      7.

      10. Provide graceful reintegration of full protocol service after
          server failure or network partition.

      8.

      11. Allow for one computer to act as a secondary server for multi-
          ple primary servers. Other topologies (e.g.: mesh) are also
          possible.  The protocol must allow failover primary
          and secondary servers SHOULD configuration choices to be viewed as
          "logical" servers and made at a granular-
          ity smaller than "all of the subnets served by a single
          server", though individual implementations may not necessarily physical computers.

      9. choose to
          allow such flexibility.

      12. Ensure that an existing client can keep its existing IP
          address binding if it can communicate with either the primary
          or secondary DHCP server implementing this protocol - not just
          whichever server that originally offered it the binding.

      10.

      13. Ensure that a new client can get an IP address from some
          server.  Ensure that in the face of partition, where servers
          continue to run but cannot communicate with each other, the
          above goals and requirements may be met.  In addition, when
          the partition condition is removed, allow graceful automatic re-
          integration
          re-integration without requiring human intervention.

      11.

      14. If either primary or secondary server loses all of the infor-
          mation that is has stored in stable storage, ensure that it should be
          able to refresh its stable storage from the other server.

      12.

      15. Support load balancing between the primary and secondary
          servers, and allow configuration of the percentage of the
          client population served by each with a moderately fine granu-
          larity.

4.3.

4.2.  Limitations of this Protocol protocol

   The following are explicit limitations of this protocol.

      1.  This protocol provides only one level of redundancy through a
          single secondary server for each primary server.

      2.  A subset of the address pool is reserved for secondary server
          use.  In order to handle the failure case where both servers
          are able to communicate with DHCP clients, but unable to com-
          municate with each other, a subset of the IP address pool must
          be set aside as a private address pool for the secondary
          server.  The secondary can use these to service newly arrived
          DHCP clients during such a period.  The required size of this
          private pool SHOULD is be based only on the arrival rate of new DHCP
          clients and the length of expected downtime, and is not influ-
          enced in any way by the total number of DHCP clients supported
          by the server pair.

          The failover protocol can be used in a mode where both the
          primary and secondary servers can share the load between them
          when both are operating.  In this loadbalancing load balancing mode, the
          addresses allocated by the primary server to the secondary
          server are not unused, but are used instead to service the
          portion of the client base which to which the secondary server is
          required to respond.  See section 5.3 for more information on loadbalancing.
          load balancing.

      3.  The primary and secondary servers do not respond to client
          requests at all while recovering from a failure that could
          have resulted in duplicate IP assignments.  (When synchroniz-
          ing in POTENTIAL-CONFLICT state).

5.  Protocol Overview

   This section will discuss the failover protocol at a relatively high
   level of detail.  In the event that a description in this section
   conflicts (or appears to conflict due to the overview nature of this
   section) with information in later sections of this draft, the infor-
   mation in the later sections should be considered authoritative.

5.1.  Messages and States

   This protocol is centered around the message exchange used by one
   server to update the other server of binding database changes result-
   ing from DHCP client activity:

      o Communication of binding database changes

        The binding update (BNDUPD) message is used to send the binding
        database changes to the partner server, and the partner server
        responds with a binding acknowledgement (BNDACK) message when it
        has successfully committed those changes to its own stable
        storage.

   All of the other messages involve ancillary issues:

      o Management of available IP addresses

        The pool request (POOLREQ) is used by the secondary server to
        request an allocation of IP addresses from the primary server.

        The pool response (POOLRESP) is used by the primary server to
        inform the secondary server how many IP addresses were allocated
        to the secondary server as the result of the pool request.

      o Synchronization of the binding databases between the servers
        after they've been out of communications

        The update request (UPDREQ) message is used by one server to
        request that its partner send it all binding database informa-
        tion that it has not already seen.  The update request all
        (UPDREQALL) message is used by one server to request that all
        binding database information be sent in order to recover from a
        total loss of its binding database by the requesting server.
        The update done (UPDDONE) message is used by the responding
        server to indicate that all requested updates have been sent the
        responding server and acked by the requesting server.

      o Connection establishment

        The connect (CONNECT) message is used by the primary server to
        establish a high level connection with the other server, and to
        transmit several important configuration data items between the
        servers.  The connect acknowledgement message (CONNECTACK) is
        used by the secondary server to respond to a CONNECT message
        from the primary server.  The disconnect (DISCONNECT) message is
        used by either server when closing a connection.

      o Server synchronization

        The state change (STATE) message is used by either server to
        inform the other server of a change of failover state.

      o Connection integrity management

        The contact (CONTACT) message is used by either server to ensure
        that the other server continues to see the connection as opera-
        tional.  It MUST be transmitted periodically over every esta-
        blished connection if other message traffic is not flowing, and
        it MAY be sent at any time.

5.1.1.  Failover endpoints

   The proper operation of the failover protocol requires more than the
   transmission of messages between one server and the other.  Each end-
   point might seem to be a single DHCP server, but in fact there are
   many situations where additional flexibility in configuration is use-
   ful.

   For instance, there might be several servers which are each primary
   for a distinct set of address pools, and one server which is secon-
   dary for all of those address pools.  The situation with the pri-
   maries is straightforward, but the secondary will need to maintain a
   separate failover state, partner state, and communications up/down
   status for each of the separate primary servers for which it is act-
   ing as a secondary.

   The failover protocol calls for there to be a unique failover end-
   point per partner per role (where role is primary or secondary).
   This failover endpoint can take actions and hold unique states.
   There are thus a maximum of two failover endpoints per partner (one
   for the partner as a primary and one for that same partner as a
   secondary.)

   Thus, in the case where there are two primary servers A and B each
   backed up by a single common secondary server C, there is one fail-
   over endpoint on each of A and B, and two different failover end-
   points on C.  The two different failover endpoints on C each have
   unique states and independent TCP connections.

   This document frequently describes the behavior of the protocol in
   terms of pri-
   mary primary and secondary servers, not primary and secondary
   failover end-
   points. 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 many failover endpoints end-
   points may reside in the same process.

   It is not the case that there is a unique failover endpoint for each
   subnet address pool that participates in a failover relationship.  On
   one server, there is one failover endpoint per partner per role,
   regardless of how many subnets or subnet address pools are managed by that combination com-
   bination of partner and role.  Conversely, on a particular server,
   any given sub-
   net or subnet address pool 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
   IP address of the partner and the setting of the SECONDARY bit in the
   'flags' field of the CONTACT message.

   Throughout this document, the states and actions taken by "servers"
   are described.  The terms "server", "primary server", and "secondary
   server" are commonly used port to described which the failover endpoint taking
   these states and performing these actions.  This description connection is
   wholly accurate only for the simplest of cases, where all of the
   address pools on one server are backed up
   directed by all of the address pools
   on another server.  In this case, there is single failover endpoint
   in each server.  In all other cases, the term "server" is used to
   describe one of the two possible failover endpoints per partner.  See section 8.2.

5.2.  Fundamental restrictions guarantees

   There a several fundamental restrictions this protocol places on what
   one server can do in the absence of knowledge of the other server.
   Operating within these restrictions allows certain guarantees to be
   made to the partner server, and these restrictions are key to the correct operation opera-
   tion of the proto-
   col. protocol.

5.2.1.  Control of lease time

   The key problem with lazy update is that when the a server fails after
   updating a client with a particular lease time and before updating
   its partner, the partner will believe that a lease has expired even
   though the client still retains a valid lease on that IP address.

   In order to handle this problem, a period of time known as the "Max-
   imum Client Lead Time" (MCLT) is defined and must be known to both
   the primary and secondary servers.  Proper use of this time interval
   places an upper bound on the difference allowed between the lease
   time provided to a DHCP client by a server and the lease time known
   by that server's partner.  However, the MCLT is typically much less
   than the lease time that a server has been configured to offer a
   client, and so some strategy must exist to allow a server to offer
   the configured lease time to a client.  During a lazy update the
   updating server typically updates its partner with a potential
   expiration time which is longer than the lease time previously given
   to the client and which is longer than the lease time that the server
   has been configured to give a client.  This allows that server to
   give a longer lease time to the client the next time the client
   renews its lease, since the time that it will give to the client will
   not exceed the MCLT beyond the potential expiration time acknowledged
   by the its partner.

   The PARTNER-DOWN state exists so that a server can be sure that its
   partner is, indeed, down.  Correct operation while in that state
   requires (generally) that the server wait the MCLT after anything
   that happened prior to its transition into PARTNER-DOWN state (or,
   more accurately, when the other server went down if that is known).
   Thus, the server MUST wait the Maximum Client Lead Time MCLT after the partner server went
   down before allocating any of the partner's FREE
   addresses. addresses which were
   available for allocation.  In the event the partner was not in communication com-
   munication prior to going down, it might have allocated one or more
   of its FREE addresses to a DHCP client and been unable to inform the
   server entering PARTNER-DOWN prior to going down itself.  By waiting
   the MCLT after the time the partner went down, the server in
   PARTNER-DOWN state ensures that any clients which have a lease on one
   of the partner's FREE addresses will either time out or contact the
   server in PARTNER-DOWN by the time that period ends.

   In addition, once a server has transitioned to PARTNER-DOWN state, it
   MUST NOT reallocate an IP address from one client to another client
   until an additional MCLT interval after the lease by the original
   client expires.  (Actually, until the maximum client lead time after
   what it believes to be the lease expiration time of the first client.)

   Some optimizations exist for this restriction, in that it only
   applies to leases that were issued BEFORE entering PARTNER-DOWN. Once
   a server has entered PARTNER-DOWN and it leases out an address, it
   need not wait this time as long as it has never communicated with the
   partner since the lease was given out.

   The fundamental relationship on which much of the correctness of this
   protocol depends is that the lease expiration time known to a DHCP
   client MUST NOT be more than the maximum client lead time greater
   than the potential expiration time known to a server's partner.

   The remainder of this section makes the above fundamental relation-
   ship more explicit.

   This protocol requires a DHCP server to deal with several different
   lease intervals and places specific restrictions on their relation-
   ships. The purpose of these restrictions is to allow the other server
   in the pair to be able to make certain assumptions in the absence of
   an ability to communicate between servers.

   The different lease times are:

      o desired lease interval

        The desired lease interval 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 determina-
        tion is outside of the scope of this protocol. Typically this is
        the result of external configuration of a DHCP server.

      o actual lease interval

        The actual lease internal is the lease interval that a DHCP
        server gives out to a DHCP client in the dhcp-lease-time option
        of a DHCPACK packet.  It may be shorter than the desired client
        lease interval (as explained below).

      o potential lease interval

        The potential lease interval is the lease expiration interval
        the local server tells to its partner in the potential-
        expiration-time option of a BNDUPD message.

      o acknowledged potential lease interval

        The acknowledged potential lease interval is the potential lease
        interval the partner server has most recently acknowledged in
        the potential-expiration-time option of a BNDACK message.

   The key restriction (and guarantee) that any server makes with
   respect to lease intervals is that the actual client lease interval
   never exceeds the acknowledged potential lease interval (if any) by
   more than a fixed amount.  This fixed amount is called the "Maximum
   Client Lead Time" (MCLT).

   The MCLT MAY be configurable on the primary server, but for correct
   server operation it MUST be the same and known to both the primary
   and secondary servers.  The secondary server determines the MCLT from
   the MCLT option sent from the primary server to the secondary server
   in the CONNECT message.

   A server MUST record in its stable storage both the actual lease
   interval and the most recently acknowledged potential lease interval
   for each IP address binding.  It is assumed that the desired client
   lease interval can be determined through techniques outside of the
   scope of this protocol.  See section 7.1.4 7.1.5 for more details concern-
   ing the times that the server MUST record in its stable storage and
   the way that they interact with the lease time that may be offered to
   a DHCP client.

   Again, the fundamental relationship among these times which MUST be
   maintained is:

       actual lease interval <
       ( acknowledged potential lease interval + MCLT )

   Figure 5.1-1 5.2.1-1 illustrates a initial lease to a client using the
   rules discussed in the example which follows it.  Note that this is
   only one example -- as long as the fundamental relationship is
   preserved, the actual times used could be quite different.

              DHCP                 Primary             Secondary
       time   Client               Server               Server

                | (time in intervals) |  (absolute time)   |
                |                     |                    |
                | >-DHCPDISCOVER->    |                    |
                |     <---DHCPOFFER-< |                    |
                |                     |                    |
                | >-DHCPREQUEST->     |                    |
                |   (selecting)       |                    |
                |                     |                    |
         t      |  <--------DHCPACK-< |                    |
                |  lease-time=MCLT    |                    |
                |                     |    >-BNDUPD-->     |
                |                     |  lease-expiration=t+MCLT
                |                     |  potential-expiration=t+(MCLT/2)+X
                |                     |                    |
                |                     |     <-BNDACK-<     |
                |                     |  potential-expiration=t+(MCLT/2)+X
               ...                   ...                  ...
                |                     |                    |
      t+MCLT/2  | >-DHCPREQUEST->     |                    |
                |      (renew)        |                    |
                |                     |                    |
         t1     |  <--------DHCPACK-< |                    |
                |   lease-time=X      |                    |
                |                     |    >-BNDUPD-->     |
                |                     |  lease-expiration=t1+X
                |                     |  potential-expiration=t1+(X/2)+X
                |                     |                    |
                |                     |     <-BNDACK-<     |
                |                     |  potential-expiration=t1+(X/2)+X
               ...                   ...                  ...

           Figure 5.1-1: 5.2.1-1:  Lazy Update Message Traffic
                          X = Desired Lease Interval
                          Assumes renewal interval = lease interval / 2

   DISCUSSION:

      This protocol mandates no algorithm concerning these lease inter-
      vals, as long as only that the above fundamental relationship relation-
      ship concerning lease intervals is preserved.

      In the interests of clarity, however, let's examine a specific
      example.  The MCLT in this case is 1 hour.  The desired lease
      interval is 3 days, and its renewal time is half the lease inter-
      val.
      interval.

      The rules for this example are:

      o What to tell the client:

        Take the remainder of the acknowledged potential lease interval.
        If this is a new lease, then this value will be zero.  If this
        remainder plus the MCLT is greater than the desired lease inter-
        val, give the client the desired lease interval else give the
        client the remainder plus the MCLT.

      o What to tell the failover partner server:

        Take the renewal interval (typically half of the actual client
        lease interval), add to it the desired lease interval, and add
        it to the current time to yield the value that goes into the
        potential-expiration-time option.

        Also tell the failover partner the actual lease interval by
        adding it to the current time to yield the value that goes into
        the lease-expiration option.

      In operation this might work as follows:

      When a server makes an offer for a new lease on an IP address to a
      DHCP client, it determines the desired lease interval (in this
      case, 3 days).  It then examines the acknowledged potential lease
      interval (which in this case is zero) and determines the remainder
      of the time left to run, which is also zero.  To this it adds the
      MCLT.  Since the actual lease interval cannot be allowed to exceed
      the remainder of the current acknowledged potential lease interval
      plus the MCLT, the offer made to the client is for the remainder
      of the current acknowledged potential lease interval (i.e., zero)
      plus the MCLT.  Thus, the actual lease interval is 1 hour.

      Once the server has performed the ACK BNDACK to the DHCP client, it
      will update the secondary server with the lease information. However, How-
      ever, the desired potential lease interval will be composed of the
      one half of the current actual lease interval added to the desired
      lease interval. Thus, the secondary server is updated with a
      BNDUPD with a lease interval of 3 days + 1/2 hour specified in the
      potential-expiration-time option.

      When the primary server receives an ACK to its update of the
      secondary server's (partner's) potential lease interval, it
      records that as the acknowledged potential lease interval.  A
      server MUST NOT send a BNDACK in response to a BNDUPD message
      until it is sure that the information in the BNDUPD message
      resides in its stable storage.  Thus, the primary server in this
      case can be sure that the secondary server has recorded the poten-
      tial lease interval in its stable storage when the primary server
      receives a BNDACK message from the secondary server.

      When the DHCP client attempts to renew at T1 (approximately one
      half an hour from the start of the lease), the primary server
      again determines the desired lease interval, which is still 3
      days.  It then compares this with the remaining acknowledged
      potential lease interval (3 days + 1/2 hour) and adjusts for the
      time passed since the secondary was last updated (1/2 hour).  Thus
      the time remaining of the acknowledged potential lease interval is
      3 days.  Adding the MCLT to this yields 3 days plus 1 hour, which
      is more than the desired lease interval of 3 days.  So the client
      is renewed for the desired lease interval -- 3 days.

      When the primary DHCP server updates the secondary DHCP server
      after the DHCP client's renewal ACK is complete, it will calculate
      the desired potential lease interval as the T1 fraction of the
      actual client lease interval (1/2 of 3 days this time = 1.5 days).
      To this it will add the desired client lease interval of 3 days,
      yielding a total desired partner server lease interval 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
      lease interval so as to be able to always offer the client the
      desired client lease interval.

      Once the initial actual client lease interval of the MCLT is past,
      the protocol operates effectively like the DHCP protocol does
      today in its behavior concerning lease intervals. However, the
      guarantee that the actual client lease interval will never exceed
      the remaining acknowledged partner server lease interval by more
      than the MCLT allows full recovery from a variety of failures.

5.2.2.  Controlled re-allocation of IP addresses

   When in PARTNER-DOWN state there is a waiting period after which an
   IP address can be re-allocated to another client.  For leases which
   are available when the server enters PARTNER-DOWN state, the period
   is the MCLT from entry into PARTNER-DOWN state.  For IP addresses
   which are not available when the server enters PARTNER-DOWN state,
   the period is the MCLT after the lease becomes available.  See sec-
   tion 9.4.2 for more details.

   In any other state, a server cannot reallocate an address from one
   client to another without first notifying its partner (through a
   BNDUPD message) and receiving acknowledgement (through a BNDACK mes-
   sage)
   message) that its partner is aware that that first client is not
   using the address.

   This could be modeled in the following way.  Though this specific
   implementation is in no way required, it may serve to better illus-
   trate the concept.

   An "available" IP address on a server may be allocated to any client.
   An IP address which was leased to a client and which 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 IP address was EXPIRED or RELEASED through a BNDUPD.  When
   the sending server received the BNDACK for that IP address showing it
   was FREE, it would move the IP address from EXPIRED or RELEASED to
   FREE, and it would be available for allocation by the primary server
   to any clients.

   A server MAY reallocate an IP address in the EXPIRED or RELEASED
   state to the same client with no restrictions. restrictions provided it has not
   sent a BNDUPD message to its partner.  This situation would exist if
   the lease expired or was released after the transition into PARTNER-
   DOWN state, for instance.

5.3.  Load balancing

   In order to implement load balancing between a primary and secondary
   server pair, each server must respond to DHCPDISCOVER requests from
   some clients and not from other clients.  In order to do this suc-
   cessfully, each server must be able to determine immediately upon
   receipt of a DHCP client request whether it is to service this
   request or to ignore it in order to allow the other server to service
   the request.

   In addition, it should be possible to configure the percentage of
   clients which will be serviced by either the primary or secondary
   server.  This configuration should be more or less continuous, from
   all clients serviced by the primary through an even split with half
   serviced by each, to all clients serviced by the secondary.

   The technique chosen to support these goals is described in [LOADB].
   When using the load balancing algorithm in [LOADB] among two servers
   implementing the failover protocol, both servers MUST use the same
   information from the

   A bitmap-style Hash Bucket Assignment (as described in [LOADB]) is
   used to determine which DHCP client packet as the Request ID for the
   load balancing algorithm.  Both servers MUST use the dhcp-client-
   identifier (if it appears), clients can be processed.  There are two
   potential HBA's in a failover server -- a server HBA and the client-hardware-address if the
   dhcp-client-identifier does not. a failover
   HBA.   The client-hardware-address way that a server acquires a server HBA is con-
   structed from outside of the htype and chaddr fields
   scope of the DHCP client request failover protocol, but both servers in a failover pair
   MUST have the same manner as described for creation of the client-hardware-
   address option in section 6.2.

   A bitmap-style Hash Bucket Assignment (as described in section 5.2 of
   [LOADB]) server HBA. The failover HBA is sent by the
   primary server to the secondary server when-
   ever whenever a connection is established, esta-
   blished, using the hash-bucket-assignment option defined in section 6.2.  This Hash Bucket Assignment is used
   by
   12.10.

   When using the secondary server HBA (if any) and the failover HBA (if any), to
   decide which packets whether to process when in
   NORMAL state.

   The way in which either primary or secondary servers determine a DHCP request, the
   hash bucket assignment for it to use when server HBA always
   applies in other than NORMAL state
   is outside of the scope of this document.  Note, however, that the
   primary every failover state, and secondary servers MUST use identical hash bucket assign-
   ments when not in NORMAL state.  This common hash bucket assignment
   MAY be for all of the hash buckets, indicating that there is no other
   DHCP server sharing the load with this failover pair, or it MAY HBA (which MUST be
   for
   a subset of the hash buckets, which would indicate that there
   exists another server or server pair with which this DHCP server pair HBA) is sharing used by the load. secondary server to decide
   which packets to process when in NORMAL state.

5.4.  Operating in NORMAL state

   When in NORMAL state, each server services DHCPDISCOVER's and all
   other DHCP requests other than DHCPREQUEST/RENEWAL or
   DHCPREQUEST/REBINDING from the client set defined by the load balanc-
   ing algorithm.  Each server services DHCPREQUEST/RENEWAL or
   DHCPDISCOVER/REBINDING requests from any client.

   In general, whenever the binding database is changed in stable
   storage, then a BNDUPD message is sent with the contents of that
   change to the partner server.  The partner server then writes the
   information about that binding in its bindings database in stable
   storage and replies with a BNDACK message.

5.5.  Operating in COMMUNICATIONS-INTERRUPTED state

   When operating in COMMUNICATIONS-INTERRUPTED state, each server is
   operating independently, but does not assume that its partner is not
   operating.  The partner server might be operating and simply unable
   to communicate with this server, or might not be operating.

   Each server responds to the full range of DHCP client messages that
   it receives, but in such a way that graceful reintegration is always
   possible when its partner comes back into contact with it.

5.6.  Operating in PARTNER-DOWN state

   When operating in PARTNER-DOWN state, a server assumes that its
   partner is not currently operating, but does make allowances for the
   possibility that that server was operating in the past, though possi-
   bly out of communications with this server.  It responds to all DHCP
   client requests in PARTNER-DOWN state.

5.7.  Operating in RECOVER state

   A server operating in RECOVER state assumes that it is reintegrating
   with a server that has been operating in PARTNER-DOWN state, and that
   it needs to update its bindings database before it services DHCP
   client requests.

   A server may also operate in RECOVER state in order to fully recover
   its bindings database from its partner server.

5.8.  Operating in STARTUP state

   A server operating in STARTUP state assumes that failover is opera-
   tional, and it spends a short time whenever it comes up attempting to
   contact the partner.  During this time (generally a few seconds), the
   server is unresponsive to DHCP client requests.  This period exists
   in order to give a server a chance to determine that its partner has
   changed state since it was last in communications, and to react to
   that changed state (if any) prior to responding to DHCP client
   requests.

   The period of time a server remains in STARTUP state SHOULD be long
   enough to ensure that it will connect to the other server if that
   server is available for connections.

5.9.  Time synchronization between servers

   The failover protocol is designed to operate between two servers
   which have time values which differ by an arbitrarily large amount.
   A particular implementation MAY choose to only support servers whose
   time values differ by an arbitrarily small amount.

   In any event, whether large or only small differences in time values
   are supported, every message that is received MUST be tagged with a
   time value as soon as possible after receipt.  This time value is
   used along with the time value that is sent in every message between
   the failover partners to develop a delta time between the servers.
   This delta time is used during the connection process to establish a
   baseline delta time between the servers, and upon receipt of each
   message, the delta time for that message is used to refine the delta
   time for the server pair.

   While the algorithm for this refinement of delta time is not speci-
   fied as part of this protocol, a server SHOULD allow the delta time
   value for a pair of failover servers to be periodically updated to
   account for time drift.  In addition, the delta time value between
   servers SHOULD be smoothed in some fashion, so that transient network
   delays will not cause it to vary wildly.

   A server SHOULD recognize a drastic change in the delta time value as
   an event to be signaled to a network administrator. administrator, as well as reset-
   ting the time delta between the failover partners.

   The specific definitions of a minor or drastic change in delta time
   as well as the algorithm used to smooth minor changes into the run-
   ning delta time are implementation issues and are not further
   addresses in this document.

5.10.  IP address binding-status

   In most DHCP servers an IP address can take on several different
   binding-status values, sometimes also called states.  While no two
   DHCP servers probably have exactly the same possible binding-status
   values
   values, the DHCP RFC 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 denominator
   binding-status values must be defined.  It is not expected that these
   binding-status-values correspond with any actual implementation of
   the DHCP protocol in a DHCP server, but rather that the binding-
   status values defined in this document should be a superset common denominator
   of most
   if not all those in use by many DHCP server implementations.  It is a goal of
   this proto-
   col protocol that any DHCP server can map the various IP address binding-
   status
   binding-status values that it uses internally into these failover IP
   address binding-status values on transmission of binding database
   updates to its partner, and likewise that it can map any failover IP
   address binding-status values it received in a binding update into
   its internal IP address binding-status
   values upon receipt of a binding database update. values.

   The IP address binding-status values defined for the failover proto-
   col are:

      o FREE

        Lease

        IP address may be allocated by the primary to any DHCP client.
        When the MCLT has passed after its time of entry into PARTNER-
        DOWN state, the IP address may be allocated by the secondary to
        any DHCP client.

      o ACTIVE

        Lease is assigned to a client.  It MUST have  A client information
        associated with it. MUST appear.

      o EXPIRED

        Lease -- indicates that a client's binding on an IP address
        has expired. When the partner server ACK's the BNDUPD of an
        EXPIRED IP address, the server sets its internal state to FREE.
        It is then available to allocation to any client of the primary
        server.  It may be allocated to the same client.

      o RELEASED

        Lease client if a BNDUPD has
        not yet been released sent to the partner.  A client SHOULD appear.

      o RELEASED -- indicates that a DHCP client sent in a DHCPRELEASE
        message.  When the partner server ACK's the BNDUPD of an
        RELEASED IP address, the server sets its internal state to FREE,
        and it is available for allocation by the primary server to any
        DHCP client.  It may be allocated to the same client.

      o ABANDONED
        A server, or client flagged address as unusable.

      o RESET

        Lease was freed if a BNDUPD
        has not yet been sent to the partner.  A client SHOULD appear.

      o FREE -- is used when a DHCP server needs to communicate that an
        IP address is unused by some external agent. any DHCP client, but it was not just
        released, expired, or reset by a network administrator.  When
        the partner server ACK's the BNDUPD of an FREE IP address, the
        server sets its internal state such that it is available for
        allocation by the primary DHCP server to any DHCP client.  (Note
        that in PARTNER-DOWN state, after waiting the MCLT, the IP
        address MAY be allocated to a DHCP client by the secondary
        server.)  A client MAY appear.

      o ABANDONED -- indicates that an IP address is considered unusable
        by the DHCP subsystem.  An IP address for which a valid PING
        response was received SHOULD be set to ABANDONED.  An IP address
        for which a DHCPDECLINE was received should be set to ABANDONED.
        A client MUST NOT appear.

      o RESET -- indicates that this IP address was made available by
        operator command.  A client MAY appear.

      o BACKUP

        Lease belongs -- indicates that this IP address can be allocated by the
        secondary server to secondary's private a DHCP client at any time. When the MCLT has
        passed after its time of entry into PARTNER-DOWN state, the IP
        address pool. may be allocated by the primary to any DHCP client.  A
        client MAY appear.

   These binding-status values are communicated from one failover
   partner to another using the binding-status option, see section 6.2 12.3
   for details of this option.  Unless otherwise noted above there MAY
   be client information associated with each of these binding-status
   values.

   An IP address will move between these binding-status values using the
   following state transition diagram:

                                        DHCP client DECLINE or
                                        server detected problem
                                        from any state
                          +----------+     V   +---------+
         External   >---->|   RESET  |     |   |ABANDONED|
         command          |          |     +-->|         |
                          +----------+         +---------+
                               |
                           Comm w/Parter(1)
                               V
     +---------+  Comm(1) +----------+   Comm(1) +---------+
     | EXPIRED |--------->|  FREE    |<----------| RELEASED|
     |         | w/Parter |          | w/Partner |         |
     +---------+          +----------+           +---------+
       ^     ^             |        |                  ^
       | Exp. grace   IP address  IP addr alloc.       |
       | period ends  leased by   to secondary(2)      |
       |     |        primary       V                  |
       |     |             |      +----------+         |
       |     |             |      |  BACKUP  |         |
       |   wait for        |      |          |         |
       |  grace period     |      +----------+         |
       |     |             |       |                   |
       |     |             |    IP addr leased by      |
       |  Expired grace    |       secondary           |
       |  period exists    V       V                   |
       |     |           +----------+                  |
       |     | Lease on  |  ACTIVE  | DHCPRELEASE      |
       +-----+-IP addr---|          |------------------+
               expires   +----------+

       Figure 5.10-1:  Transitions between binding-status values.

       (1) This transition MAY also occur if the server is in
       PARTNER-DOWN state and the MCLT has passed since the entry
       in the RELEASED, EXPIRED, or RESET states.

       (2) This transition MAY occur if the server is the secondary
       and the MCLT has passed since its entry into PARTNER-DOWN state.

   Again, note that a DHCP server implementing the failover protocol
   does not have to implement either this state machine or use these
   particular binding-status values in its normal operation of allocat-
   ing
   allocating IP addresses to DHCP clients.  It only needs to map its
   internal binding-status-values onto these "standard" binding-status
   values, and map these "standard" binding-status values back into its
   internal binding-status values.  In particular,  For example, a server which implements imple-
   ments a grace period for a IP address binding SHOULD simply wait to
   update its partner server until the grace period on that binding has
   run out.

   The process of setting an IP address to FREE deserves some detailed
   discussion.  When an IP address is moved to the EXPIRED,RELEASED, or
   RESET binding-status on a server, it will send a BNDUPD with the
   binding-status of EXPIRED, RELEASED, or RESET to its partner.  If its
   partner agrees that is acceptable (see sections 7.1.2 and 7.13 7.1.3 con-
   cerning why a server might not accept a BNDUPD) it will return a
   BNDACK with no reject-reason, signifying that it accepted the update.
   As part of the BNDUPD processing, the server returning the BNDACK
   will set the binding-status of the IP address to FREE, and upon
   receipt of the BNDACK the server which sent the BNDUPD will set the
   binding-status of the IP address to FREE.  Thus, the EXPIRED,
   RELEASED, or RESET binding-status is something of a transitory state.
   This process is encoded in the transition diagram below above by "Comm
   w/Partner".

   An IP address will move between these lease binding-status values
   using the following state transition diagram:

5.11.  DNS dynamic update considerations

   DHCP client DECLINE or
                                        server detected problem
                                        from any state
                          +----------+     V   +---------+
         External   >---->|   RESET  |     |   |ABANDONED|
         command          |          |     +-->|         |
                          +----------+         +---------+
                               |
                           Comm w/Parter
                               V
     +---------+  Comm    +----------+   Comm    +---------+
     | EXPIRED |--------->|  FREE    |<----------| RELEASED|
     |         | w/Parter |          | w/Partner |         |
     +---------+          +----------+           +---------+
       ^     ^             |        |                  ^
       | Exp. grace   IP address  IP addr alloc.       |
       | period ends  leased by   to secondary         |
       |     |        primary       V                  |
       |     |             |      +----------+         |
       |     |             |      |  BACKUP  |         |
       |   wait for        |      |          |         |
       |  grace period     |      +----------+         |
       |     |             |       |                   |
       |     |             |    IP addr leased by      |
       |  Expired grace    |       secondary           |
       |  period exists    V       V                   |
       |     |           +----------+                  |
       |     | Lease on  |  ACTIVE  | DHCPRELEASE      |
       +-----+-IP addr---|          |------------------+
               expires   +----------+

       Figure 5.10-1:  Transitions between binding-status values.

   If a server receives a binding-status that it doesn't implement
   internally, it should do something reasonable. A server which doesn't
   support an ABANDONED binding-status could set the IP address ACTIVE
   and belonging to a client which will never be seen servers (and clients) can use DNS Dynamic Updates as described
   in a [RFC 2136] to maintain DNS name-mappings as they maintain DHCP request.

5.10.1.  IP address binding-status changes from BNDUPD messages

   IP addresses undergo binding status changes
   leases.  Many different administrative models for DHCP-DNS integra-
   tion are possible.  Descriptions of several reasons,
   including receipt and processing of these models, and
   guidelines that DHCP client requests, administra-
   tive inputs servers and receipt clients should follow in carrying
   them out, are laid out in [DDNS].  The nature of BNDUPD messages.  Every the DHCP server needs
   to respond to failover
   protocol introduces some issues concerning dynamic DNS updates that
   are not part of non-failover DHCP client request environments.  This section
   describes these issues, and administrative inputs with
   changes to its internal record of defines the binding-status of an IP
   address, information which failover
   partners should exchange and the protocol which they should follow in
   order to ensure consistent behavior.  The presence of this response is section
   should not in the scope be interpreted as requiring that implementations of the
   DHCP failover proto-
   col.  However, the receipt of BNDUPD messages implies at least a pos-
   sible change protocol must also support DDNS updates.  The purpose
   of this discussion is to clarify the binding-status for an IP address, areas where the DHCP failover
   and must be
   discussed here.  See section 7.1.2 DHCP-DDNS protocols intersect for general actions to take upon
   receipt the benefit of implementations
   which support both protocols, not to introduce a BNDUPD message.

   When receiving new requirement into
   the DHCP failover protocol.  Thus, a BNDUPD message, DHCP server which implements the
   failover protocol MAY also support dynamic DNS updates, but if it is important to note that
   does support dynamic DNS updates it may
   not be current, SHOULD utilize the techniques
   described here in that order to correctly distribute them between the server receiving
   failover partners.

5.11.1.  Relationship between failover and dynamic DNS update

   The failover protocol describes the BNDUPD message conditions under which each fail-
   over server may
   have had renew a more recent interaction with the DHCP client than lease to its
   partner who sent the BNDUPD message.  In this case, the receiving
   server MUST reject the BNDUPD message.  In addition, it is worth not-
   ing that two (and possibly three) binding-status values are the
   direct result of interaction with a current DHCP client, ACTIVE and RELEASED
   (and possibly ABANDONED).  All other binding-status values are either
   the result of
   describes the expiration of conditions under which it may grant a time period or interaction with an
   external agency (e.g., lease to a network admistrator).

   Every BNDUPD message SHOULD contain new
   DHCP client.  An analogous set of conditions determines when a client-last-transaction-time
   option, fail-
   over server should initiate a DDNS 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 assignments; allowing clients to continue using leases which MUST,
   they obtained from one failover partner even if it appears, be they can only commun-
   icate with the time that other partner; allowing the backup DHCP server last
   interacted to
   grant new leases even if it is unable to communicate with the DHCP client.  It MUST NOT be, primary
   server.  The desired external DDNS behavior for instance, DHCP failover servers
   is:

      1.  Allow timely DDNS updates from the
   time server which grants a
          client a lease. Recognize that the lease on an IP address expired.  If there has been no
   interaction with is often a DDNS update
          lifecycle which parallels the DHCP client in question (or there lease lifecycle. This is no DHCP
   client presently associated with this IP address), then there will be
   no client-last-transaction-time option in
          likely to include the BNDUPD message.

   The following list is indexed by addition of records when the binding-status that a server
   receives in a BNDUPD message.  In many cases, lease is
          granted, and the binding-status removal of
   an IP address within the receiving server's data storage will have an
   affect upon DNS records when the checks performed prior lease is sub-
          sequently made available for allocation to accepting the new binding-
   status in a BNDUPD message.

   In different client.

      2.  Communicate enough information between the following list, two failover
          servers to "accept" a BNDUPD means allow one to complete the DDNS update 'lifecycle'
          even if the
   server's bindings database with other server originally granted the information contained in lease.

      3.  Avoid redundant or overlapping DDNS updates, where both fail-
          over servers are attempting to perform DDNS updates for the
   BNDUPD and once that update
          same lease-client binding. Avoid situations where one partner
          is complete, send a BNDACK message
   corresponding attempting to add RRs related to the BNDUPD message.  To "reject" a BNDUPD means lease binding while the
          other partner is attempting to
   respond remove RRs related to the BNDUPD with a BNDACK with a reject-reason option
   included..

   When interpreting the rules in same
          lease binding.

5.11.2.  Use of the following list, if a BNDUPD
   doesn't have a client-last-transaction-time value, then it MUST NOT DDNS option

   In order for either server to be considered later than able to complete a DDNS update, or
   to remove DNS records which were added by its partner, both servers
   need to know the client-last-transaction-time in FQDN associated with the
   receiving server's lease-client binding.   If The
   FQDN associated with the BNDUPD contains a client-last-
   transaction-time value client's A RR and PTR RR SHOULD be communi-
   cated from the receiving server's binding does not,
   then server which adds records into the client-last-transaction-time value DNS to its partner.
   The initiating server SHOULD use the DDNS option in the BNDUPD MUST be
   considered later than mes-
   sages to inform the server's.

   The second rule concerns clients and IP addresses.  If partner server of the client in status of any DDNS updates
   associated with a BNDUPD message lease binding. Failover servers MAY choose not to
   include the client DDNS option in a receiving server's binding both
   exist and if they differ, then BNDUPD messages if there has been no
   change in the status of any DDNS update related to the lease binding.
   The partner server receiving server's binding- BNDUPD messages containing the DDNS
   option SHOULD compare the status is ACTIVE flags and the binding-status FQDN contained in the BNDUPD is ACTIVE, then
   if
   option data with the receiving current DDNS information it has associated with
   the lease binding, and update its notion of the DDNS status accord-
   ingly.

   The initiating server is MAY send a secondary server accept it, else reject
   it.

   Otherwise, look up BNDUPD to its partner before the binding-status in
   DDNS update has been successfully completed. If it does so, it SHOULD
   leave the BNDUPD in this list:

      o ACTIVE 'C' bit in BNDUPD

        If the receiving server's binding-status is ACTIVE, FREE, or
        BACKUP, then accept it.

        If Flags field clear, to indicate to the receiving server's binding-status is ABANDONED or RESET,
        then reject it.

        If
   partner that the receiving server's binding status is RELEASED, EXPIRED,
        then if DDNS update may not be complete. When the client-last-transaction-time in DDNS
   update has been successfully acknowledged by the BNDUPD is later
        than DNS server, the client-last-transaction-time in ini-
   tiating DHCP server SHOULD include the receiving server's
        binding, accept it, else reject it.

      o EXPIRED DDNS option in its next BNDUPD

        If
   message about the receiving server's binding-status is ACTIVE, then current
        time is later than binding, so that the receiving server's lease-expiration-time,
        accept it, else reject it.

        If partner server will be able to
   record the receiving server's binding-status is ABANDONED or RESET,
        reject it.

        If final status of the receiving server's binding-status is FREE or BACKUP,
        accept it.

        If DDNS update. The initiating server
   SHOULD set the receiving server's binding-status is RELEASED, then 'C' bit in the DDNS option if the client-last-transaction-time is greater in DDNS update was suc-
   cessfully accepted by the DNS server.

   Some implementations will choose to send a BNDUPD than
        in without waiting for
   the receiving server's binding, DDNS update to complete, and then accept it, else reject
        it.

      o RELEASED in will send a second BNDUPD

        If the receiving server's binding-status is ACTIVE, then if once
   the
        client-last-transaction-time DDNS update is greater than the client-last-
        transaction-time in complete. Other implementations will delay sending
   the receiving server's binding, accept it,
        else reject it.

        If partner a BNDUPD until the receiving server's binding-status is RELEASED, FREE or
        BACKUP, accept it.

        If DDNS update has been acknowledged by
   the receiving server's binding-status is ABANDONED or RESET,
        reject it.

      o FREE DNS server, or BACKUP until some time-limit has elapsed, in order to
   avoid sending a second BNDUPD.

   The Domain Name field in BNDUPD

        If the receiving server's binding-status is ACTIVE and DDNS option contains the
        current time is later than FQDN that will
   be associated with the lease-expiration-time accept it,
        else reject it.

        If A RR (if the receiving server's binding-status server is ABANDONED, reject
        it.

        If performing an A RR
   update for the receiving server's binding-status is FREE or BACKUP or
        RESET, accept it.

      o RESET or ABANDONDED in BNDUPD

        Accept client) and the new binding-status under all circumstances.

5.11.  DNS dynamic update considerations

   DHCP servers (and clients) can use DNS Dynamic Updates as described PTR RR. This FQDN may be composed in [RFC2136] to maintain DNS name-mappings as they maintain DHCP
   leases.  Many different administrative models for DHCP-DNS integra-
   tion are possible.  Descriptions
   any of several of these models, and
   guidelines that DHCP servers ways, depending on server configuration and clients should follow in carrying
   them out, are laid out the infor-
   mation provided by the client in [DDNS]. its DHCP messages. The nature of client may
   supply a hostname which it would like the DHCP failover
   protocol introduces some issues concerning dynamic DNS updates that
   are not part of non-failover DHCP environments.  This section
   describes these issues, and defines server to use in forming
   the FQDN, or it may supply the entire FQDN. The server may be config-
   ured to attempt to use the information which failover
   partners should exchange and the protocol which they should follow in
   order client supplies, it may be
   configured with an FQDN to ensure consistent behavior.  The presence of this section
   should not use for the client, or it may be interpreted as requiring config-
   ured to synthesize an FQDN. The responsive server SHOULD include the
   FQDN that implementations of it will be using in DDNS updates it initiates when it sends
   the
   DHCP failover protocol must also support DDNS updates.  The purpose
   of this discussion is to clarify option.

   Since the areas responsive server may not have completed the DDNS update at
   the time it sends the first BNDUPD 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 failover
   and DHCP-DDNS protocols intersect for
   client FQDNs are identical by modifying the benefit most-specific label in
   the FQDNs of implementations some of the clients in an attempt to generate unique
   FQDNs for them (a process sometimes called "disambiguation").  Alter-
   natively, at sites which support both protocols, not use some or all of the information which
   clients supply to introduce a new requirement into form the DHCP failover protocol.  Thus, FQDN, it's possible that a DHCP client's confi-
   guration may be changed so that it begins to supply new data.  The
   responsive server which implements may react by removing the
   failover protocol MAY also support dynamic DNS updates, but if it
   does support dynamic DNS updates records which it ori-
   ginally added for the client, and replacing them with records that
   refer to the client's new FQDN. In such cases, the responsive server
   SHOULD utilize include the techniques
   described here actual FQDN that was used in subsequent DDNS
   options.  The responsive server SHOULD include relevant client-option
   data in the client-request-options option in its BNDUPD messages.
   This information may be necessary in order to correctly distribute them between allow the
   failover partners.

5.11.1.  Relationship between failover and dynamic DNS update

   The failover protocol describes non-
   responsive partner to detect client configuration changes that change
   the conditions under hostname or FQDN data which each fail-
   over server may renew a lease to the client includes in its current DHCP client, and
   describes
   requests.

5.11.3.  Adding RRs to the conditions under DNS

   A failover server which is going to perform DDNS updates SHOULD ini-
   tiate the DDNS update when it may grant grants a new lease to a new
   DHCP client.  An analogous set of conditions determines when a fail-
   over server should The
   non-responsive partner SHOULD NOT initiate a DDNS update, and update when it should attempt
   to remove records from
   receives the DNS. BNDUPD after the lease has been granted. The failover protocol's conditions
   are based on
   protocol ensures that only one of the desired external behavior: avoiding duplicate
   address assignments; allowing clients partners will grant a lease to continue using leases which
   they obtained
   any individual client, so it follows that this requirement will
   prevent both partners from one failover partner even if they can only commun-
   icate with initiating updates simultaneously. The
   server initiating the other partner; allowing update SHOULD follow the backup DHCP protocol in [DDNS].
   The server may be configured to
   grant new leases even if it is unable to communicate with the primary
   server.  The desired external DDNS behavior for DHCP perform an A RR update on behalf of
   its clients, or not. Ordinarily, a failover servers
   is:

      1.  Allow timely server will not initiate
   DDNS updates from the server which grants a
          client when it renews leases. In two cases, however, a lease. Recognize that there is often failover
   server MAY initiate a DDNS update
          lifecycle which parallels the DHCP lease lifecycle. This is
          likely to include the addition of records when the it renews a lease is
          granted, and the removal of DNS records when to its
   existing client:

      1.  When the lease is sub-
          sequently made available for allocation to a different client.

      2.  Communicate enough information between was granted before the two failover
          servers to allow one server was configured to complete the
          perform DDNS update 'lifecycle'
          even if updates, the other server originally granted the lease.

      3.  Avoid redundant or overlapping DDNS updates, where both fail-
          over servers are attempting MAY be configured to perform DDNS
          updates for the
          same lease-client binding. Avoid situations where one partner
          is attempting to add RRs related when it next renews existing leases. Since both
          servers are responsive to a lease binding while the
          other partner renewals in NORMAL state, it is attempting to remove RRs related not
          enough to simply require the same
          lease binding.

5.11.2.  Use of the DDNS option

   In order for either non-responsive server to be able to complete avoid a DDNS update, or
   to remove
          DNS records which were added by its partner, both servers
   need to know the FQDN associated with the lease-client binding. update in this case.  The
   FQDN associated with the client's A RR and PTR RR SHOULD server which would be communi-
   cated responsive
          to a DHCPDISCOVER from this client (even though the server which adds records into current
          request is a DHCPREQUEST/RENEW) is the DNS to its partner.
   The initiating server SHOULD use which should
          initiate the DDNS option update.

      2.  If a server is in the BNDUPD mes-
   sages PARTNER-DOWN state, it can conclude that its
          partner is no longer attempting to inform perform an update for the partner server of
          existing client. If the status of any DDNS updates
   associated with a lease binding. Failover servers MAY choose remaining server has not to
   include recorded that
          an update for the DDNS option in BNDUPD messages if there binding has been no
   change in successfully completed, the status of any
          server MAY initiate a DDNS update.  It MAY initiate this
          update related immediately upon entry to PARTNER-DOWN state, it may
          perform this in the lease binding. background, or it MAY initiate this update
          upon next hearing from the DHCP client.

5.11.4.  Deleting RRs from the DNS

   The partner failover server receiving BNDUPD messages containing the ddn
   option which makes an IP address FREE SHOULD compare the status flags and the FQDN contained in the
   option data with the current initiate
   any DDNS information deletes, if it has associated with
   the lease binding, and update its notion recorded that DNS records were added on
   behalf of the DDNS status accord-
   ingly.

   The initiating client.

   A server MAY send not in PARTNER-DOWN state "makes an IP address FREE" when it
   initiates a BNDUPD to its with a binding-status of FREE, EXPIRED, or
   RELEASED.  Its partner before confirms this status by acking that BNDUPD,
   and upon receipt of the
   DDNS update ACK the server has been successfully completed. If it does so, it SHOULD
   leave "made the 'C' bit IP address
   FREE".  Conversely, a server in PARTNER-DOWN state "makes an IP
   address FREE" when it sets the Flags field clear, to indicate binding-status to FREE, since in
   PARTNER-DOWN state not communications is required with the
   partner partner.

   It is at this point that it should initiate the DDNS update may not be complete. When operations to
   delete RRs from the DDNS. Its partner SHOULD NOT initiate DDNS
   update has been successfully acknowledged by the
   deletes for DNS server, records related to the ini-
   tiating DHCP server SHOULD include lease binding as part of send-
   ing the DDNS option in its next BNDACK message.   The partner MAY have issued BNDUPD
   message about messages
   with a binding-status of FREE, EXPIRED, or RELEASED previously, but
   the binding, so other server will have NAKed these BNDUPD messages.

   The failover protocol ensures that only one of the two partner server
   servers will be able to
   record the final status of the DDNS update. make a lease FREE. The initiating server
   SHOULD set making the 'C' bit
   lease FREE may be doing so while it is in the DDNS option if the DDNS update was suc-
   cessfully accepted by the DNS server.

   Some implementations will choose to send a BNDUPD without waiting for
   the DDNS update to complete, and then will send NORMAL communication with
   its partner, or it may be in PARTNER-DOWN state. If a second BNDUPD once
   the DDNS update server is complete. Other implementations will delay sending
   the in
   PARTNER-DOWN state, it may be performing DDNS deletes for RRs which
   its partner added originally. This allows a BNDUPD until the DDNS update has been acknowledged by
   the DNS server, or until some time-limit has elapsed, in order single remaining partner
   server to
   avoid sending a second BNDUPD.

   The Domain Name field in assume responsibility for all of the DDNS option contains activity which
   the FQDN two servers were undertaking.

   Another implication of this approach is that no DDNS RR deletes will
   be associated with the A RR (if the performed while either server is performing an A RR
   update for the client) and the PTR RR. This FQDN may be composed in
   any of several ways, depending on server configuration and the infor-
   mation provided by COMMUNICATIONS-INTERRUPTED
   state, since no IP addresses are moved into the client in its FREE state during
   that period.

5.12.  Reservations and failover

   Some DHCP messages. The client may
   supply servers support a hostname which it would like the server capability to use in forming
   the FQDN, or it may supply the entire FQDN. The server may be config-
   ured to attempt to use the information the client supplies, it may be offer specific pre-
   configured with an FQDN IP addresses to use for DHCP clients.  These are real DHCP
   clients, they do the client, or it may be config-
   ured to synthesize an FQDN. The responsive server SHOULD include entire DHCP protocol, but these servers always
   offer the
   FQDN client a specific pre-configured IP address -- and they
   offer that IP address to no other clients.  Such a capability has
   several names, but it will be using is sometimes called a "reservation", in DDNS updates it initiates when it sends
   the DDNS option.

   Since that
   the responsive IP address is reserved for a particular DHCP client.

   In a situation where there are two DHCP server may not have completed the DDNS update at serving the time it sends same sub-
   net without using failover, the first BNDUPD about two DHCP server's need to have dis-
   joint IP address pools, but identical reservations for the lease binding, there may DHCP
   clients.

   In a failover context, both servers need to be cases where the FQDN in later BNDUPD messages does not match configured with the
   FQDN included
   proper reservations in earlier messages. For example, an identical manner, but if we stop there
   problems can occur around the responsive server
   may be configured to handle situations edge conditions where two or more DHCP client
   FQDNs reservations are identical by modifying the most-specific label
   made for an IP address that has already been leased to a different
   client.  Different servers handle this conflict in different ways,
   but the FQDNs
   of some goal of the clients in an attempt failover protocol is to generate unique FQDNs for
   them. Alternatively, at sites which use some or all allow correct operation
   with any server's approach to the normal processing of the informa-
   tion which clients supply DHCP pro-
   tocol.

   The general solution with regards to form the FQDN, it's possible that reservations is as follows.
   Whenever a
   client's configuration may be changed so that reserved IP address becomes FREE (i.e., when first config-
   ured or whenever a client frees it begins to supply new
   data. The responsive server may react by removing the DNS records
   which or it originally added for expires or is reset), the client, and replacing them with
   records
   primary server MUST show that refer IP address as FREE (and thus available
   for its own allocation) and it MUST send it to the client's new FQDN. In such cases, the
   responsive server SHOULD include the actual FQDN that was used in
   subsequent DDNS options. The responsive secondary server SHOULD include
   relevant client-option data
   as BACKUP, in order that the client-request-options option in
   its BNDUPD messages. This information may secondary server be necessary in order able to
   allow allocate it
   as well.

   When the non-responsive partner to detect client configuration
   changes that change reservation on an IP address is cancelled, if the hostname or FQDN data which IP address
   is currently FREE and the client
   includes in its DHCP requests.

5.11.3.  Adding RRs to server is the primary, or BACKUP and the DNS

   A failover
   server which is going to perform DDNS updates SHOULD ini-
   tiate the DDNS update when it grants secondary, the server MUST send a new lease BNDUPD to a client. The
   non-responsive partner SHOULD NOT initiate a DDNS update when it
   receives the BNDUPD after other
   server with the lease has been granted. The binding-status FREE.

5.13.  Dynamic BOOTP and failover
   protocol ensures that only one of the partners will grant

   Some DHCP servers support a lease capability to
   any individual client, so it follows that this requirement will
   prevent both partners from initiating updates simultaneously. The
   server initiating offer IP addresses to BOOTP
   clients without having a particular address previously allocated for
   those clients.  This capability is often called something like
   "dynamic BOOTP".  It is discussed briefly in RFC 1534 [RFC 1534].

   This capability has a negative interaction with the update SHOULD follow fundamental ele-
   ments of the protocol failover protocol, in [DDNS].
   The server may be configured to perform that an A RR update on behalf of
   its clients, or not. Ordinarily, address handed out to a failover server will not initiate
   DDNS updates
   BOOTP device has no term (or effectively no term, in that usually
   they are considered leases for "forever").  There is no opportunity
   to hand out a lease which is only the MCLT long when it renews leases. In two cases, however, first hearing
   from a failover BOOTP device, because they may only interact once with the
   DHCP server MAY initiate a DDNS update when it renews and they have no notion of a lease to its
   existing client:

      1.  When expiration time.  Thus
   the lease was granted before entire concept of the server was configured to
          perform DDNS updates, MCLT and waiting the server MAY be configured to perform
          updates MCLT after entering
   PARTNER-DOWN state is defeated when it next renews existing leases. Since both
          servers are responsive to renewals dealing with BOOTP devices.

   With some restrictions, however, dynamic BOOTP devices can be sup-
   ported in NORMAL state, a server on a subnet where failover is supported.  The only
   restriction (and it is not
          enough to simply require small) is that on any portion of the non-responsive server to avoid sub-
   net (in any address pool) where dynamic BOOTP devices can be allo-
   cated IP addresses, a
          DNS update in this case.  The DHCP server MUST NOT ever use any of the IP
   addresses which would be responsive
          to a DHCPDISCOVER from this client (even though were previously available for allocation by its fail-
   over partner.  Thus, the current
          request is a DHCPREQUEST/RENEW) is addresses allocated by the server which should
          initiate primary to the DDNS update.

      2.  If a
   secondary for allocation that might have been allocated to BOOTP dev-
   ices MUST NOT ever be used by the primary server even if it is in
   PARTNER-DOWN state, it can conclude state and has waited the MCLT after entering that its
          partner is no longer attempting to perform an update state.
   Conversely, addresses available for allocation by the
          existing client. If primary MUST
   NOT be used by the remaining server has not recorded that
          an update secondary even it is in PARTNER-DOWN state.  The
   reason for the binding has this is because one of those IP address could have been successfully completed,
   allocated by the secondary server MAY initiate a DDNS update.  It MAY initiate this
          update immediately upon entry to PARTNER-DOWN state, it may
          perform this in the background, or it MAY initiate this update
          upon next hearing from a BOOTP device, and the DHCP client.

5.11.4.  Deleting RRs from the DNS

   The failover primary
   server which makes a lease FREE SHOULD initiate any DDNS
   deletes, if it has recorded that DNS records were added on behalf would have no way of ever knowing that happened.

5.14.  Guidelines for selecting MCLT

   There is no one correct value for the client. MCLT.  There is an explicit
   tradeoff between various factors in selecting an MCLT value.

5.14.1.  Short MCLT

   A short MCLT value will mean that after entering PARTNER-DOWN state,
   a server "makes will only have to wait a lease FREE" when short time before it initiates a BNDUPD with can start
   allocating its partner's IP addresses to DHCP clients.  Furthermore,
   it will only have to wait a
   binding-status of FREE, EXPIRED, or RELEASED.  Its partner confirms
   this status by acking that BNDUPD, and upon receipt of the ACK the
   server has "made short time after the expiration of a
   lease on an IP address FREE". It is at this point that before it
   should initiate the DDNS operations to delete RRs from the DDNS.  Its
   partner SHOULD NOT initiate DDNS deletes for DNS records related can reallocate that IP address to
   another DHCP client.

   However the lease binding as part downside of sending the BNDACK message.   The
   partner MAY have issued BNDUPD messages with a binding-status of
   FREE, EXPIRED, or RELEASED previously, but the other server will have
   NAKed these BNDUPD messages.

   The failover protocol ensures short MCLT value is that only one of the two partner
   servers initial lease
   interval that will be able offered to make a lease FREE. The server making the
   lease FREE may every new DHCP client will be doing so while it is short,
   which will cause increased traffic as those clients will need to send
   in NORMAL communication with
   its partner, or it may be their first renew in PARTNER-DOWN state. If a half of a short MCLT time.  In addition,
   the lease extensions that a server is in
   PARTNER-DOWN state, it may COMMUNICATIONS-INTERRUPTED
   state can give will be performing DDNS deletes only the MCLT after the server has been in
   COMMUNICATIONS-INTERRUPTED for RRs which
   its partner added originally. This allows around the desired client lease
   period.  If a single remaining partner server to assume responsibility stays in COMMUNICATIONS-INTERRUPTED for all of that
   long, then the DDNS activity which leases it hands out will be short and that will
   increase the two servers were undertaking.

   Another implication of this approach is load on that no DDNS RR deletes server, possibly causing difficulty.

5.14.2.  Long MCLT

   A long MCLT value will mean that the initial lease period will be performed while either
   longer and the time that a server is in COMMUNICATIONS-INTERRUPTED
   state, since no IP addresses are moved into the FREE state during
   that period.

5.12.  Reservations and failover

   Some DHCP servers support
   will be able to extend leases (after it has been in COMMUNICATIONS-
   INTERRUPTED state for around the desired client lease period) will be
   longer.

   However, a capability server entering PARTNER-DOWN state will have to offer specific pre-
   configured wait the
   longer MCLT before being able to allocate its partner's IP addresses
   to new DHCP clients.  These  This may mean that additional IP addresses are real DHCP
   clients, they do
   required in order to cover this time period.  Further, the entire DHCP protocol, but these servers always
   offer the client a specific pre-configured IP address -- and they
   offer that IP address to no other clients.  Such a capability has
   several names, but it is sometimes called a "reservation", in that
   the IP address is reserved for a particular DHCP client.

   In a situation where there are two DHCP server serving the same sub-
   net without using failover, the two DHCP server's need to in
   PARTNER-DOWN will have dis-
   joint IP address pools, but identical reservations for the DHCP
   clients.

   In a failover context, both servers need to be configured with wait the
   proper reservations in an identical manner, but if we stop there
   problems longer MCLT from every lease
   expiration before it can occur around the edge conditions where reservations are
   made for reallocate an IP address that has already been leased to a different DHCP
   client.  Different servers handle this conflict in different ways,
   but the goal of

6.  Common Message Format

   This section discusses the common message format that all failover protocol is to allow correct operation
   with any server's approach to the normal processing of
   messages have in common, including the DHCP pro-
   tocol.

   The general solution with regards to reservations is message header format as follows.
   Whenever a reserved IP address becomes FREE (i.e., when first config-
   ured or whenever a client frees it or it expires or is reset), the
   primary server MUST show that IP address well
   as FREE (and thus available the common option format.  See section 12 for its own allocation) and it MUST send it to the secondary server
   as BACKUP, the definitions
   of the specific options used in order that the secondary server be able to allocate it
   as well.

5.13.  Dynamic BOOTP and failover

   Some DHCP servers support a capability to offer IP addresses to BOOTP
   clients without having a particular address previously allocated for
   those clients.  This capability is often called something like
   "dynamic BOOTP".  It is not a capability explicitly discussed protocol.

6.1.  Message header format

   The options contained in
   either the DHCP or BOOTP RFC's, but rather a pragmatic capability
   which can work reasonably well for a small set payload data section of legacy BOOTP dev-
   ices.

   This capability has a negative interaction with the fundamental ele-
   ments of failover
   message

   All failover protocol messages are sent over the TCP connection
   between failover protocol, in that an address handed out to endpoints and encoded using a
   BOOTP device has no term (or effectively no term, in that usually
   they are considered leases for "forever").  There is no opportunity message format
   specific to hand out the failover protocol.

   There exists a lease common message format for all failover messages, which is only
   utilizes the MCLT long when first hearing
   from options in a BOOTP device, because they may only interact once with way similar to the DHCP server protocol.  For each
   message type, some options are required and they have no notion of some are optional.  In
   addition, when a lease expiration time.  Thus message is received any options that are not under-
   stood by the entire concept receiving server MUST be ignored.

   All of the MCLT and waiting fields in the MCLT after entering
   PARTNER-DOWN state is broken when dealing with BOOTP devices.

   With some restrictions, however, dynamic BOOTP devices can fixed portion of the message MUST be sup-
   ported filled
   with correct data in a server on a subnet where failover every message sent.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        message length (2)     | msg type (1)  |payload off (1)|
   +---------------+---------------+---------------+---------------+
   |                            time (4)                           |
   +---------------------------------------------------------------+
   |                            xid (4)                            |
   +---------------------------------------------------------------+
   |     0 or more additional header bytes  (variable)             |
   +---------------------------------------------------------------+
   |                    payload data  (variable)                   |
   |                                                               |
   |               formatted as DHCP-style options                 |
   |           using a two byte option code and two byte length    |
   |                  See section 6.2 for details.                 |
   +---------------------------------------------------------------+
   message length - 2 bytes, network byte order

   This is supported. the length of the message.  It includes the two byte message
   length itself.  The only
   restriction (and it maximum length is not small) 2048 bytes.  The minimum length
   is that on any portion of the sub-
   net (in any address pool) where dynamic BOOTP devices can be allo-
   cated IP addresses, a DHCP server MUST NOT ever use any 12.

   msg type - 1 byte

   The message type field is used to distinguish between messages.

   The following message types are defined:

   Value   Message Type
   -----   ------------
   0       reserved    not used
   1       POOLREQ     request allocation of the IP addresses which were previously available for
   2       POOLRESP    respond with allocation by its fail-
   over partner.  Thus, the addresses allocated by the primary to count
   3       BNDUPD      update partner with binding info
   4       BNDACK      acknowledge receipt of binding update
   5       CONNECT     establish connection with the secondary
   6       CONNECTACK  respond to attempt to establish connection with partner
   7       UPDREQALL   request full transfer of binding info
   8       UPDDONE     ack send and ack of req'd binding info
   9       UPDREQ      req transfer of un-acked binding info
   10      STATE       inform partner of current state or state change
   11      CONTACT     probe communications integrity with partner
   12      DISCONNECT  close a connection

   New message types should be defined in one of two ranges, 0-127 or
   129-255.  The range of 0-127 is used for allocation messages that MUST NOT ever be used sup-
   ported by the primary server
   even every server, and if it is a server receives a message in PARTNER-DOWN state and has waited the MCLT after
   entering
   range of 0-127 that state. it doesn't understand, it MUST close the TCP con-
   nection.  The reason range of 128-255 is used for messages which MAY be sup-
   ported but are not required, and if a server receives a message in
   this is because one range that it does not understand it SHOULD ignore the message.

   payload offset - 1 byte

   The byte offset of those IP
   address could have been allocated by the secondary server to a BOOTP
   device, and Payload Data, from the primary server would have no way beginning of ever knowing that
   happened.

5.14.  Guidelines for selecting MCLT

   There is no one correct the
   failover message header. The value for the MCLT.  There current protocol version
   (version 1) is an explicit
   tradeoff between various factors in selecting an MCLT value.

5.14.1.  Short MCLT

   A short MCLT value will mean that after entering PARTNER-DOWN state,
   a server will only have to wait a short 8.

   time before it can start
   allocating its partner's IP addresses to DHCP clients.  Furthermore,
   it will only have to wait a short - 4 bytes, network byte order

   The absolute time after in GMT when the expiration of a
   lease on an IP address before it can reallocate that IP address message was transmitted,
   represented as seconds elapsed since Jan 1, 1970 (i.e., similar to
   another DHCP client.

   However
   the downside of a short MCLT ANSI C time_t time value representation).  While the ANSI C
   time_t value is that signed, the initial lease
   interval that will be offered to every new DHCP client will be short,
   which will cause increased traffic value used in this specification is
   unsigned.

   A server SHOULD set this time as those clients will need close to send
   in their first renew in a half of a short MCLT time.  In addition, the lease extensions that a server in COMMUNICATIONS-INTERRUPTED
   state can give will be only actual transmission of
   the MCLT after message as possible.

   xid - 4 bytes, network byte order

   This is the server has been in
   COMMUNICATIONS-INTERRUPTED for around transaction id of the desired client lease
   period.  If failover message. The sender of a server stays in COMMUNICATIONS-INTERRUPTED
   failover protocol message is responsible for that
   long, then the leases it hands out will be short setting this number, and that will
   increase
   the load on that server, possibly causing difficulty.

5.14.2.  Long MCLT

   A long MCLT value will mean that receiver of the initial lease period will be
   longer and message copies the time that a server in COMMUNICATIONS-INTERRUPTED state
   will be able to extend leases (after number over into any response
   message, treating it has been in COMMUNICATIONS-
   INTERRUPTED state for around the desired client lease period) will be
   longer.

   However, a server entering PARTNER-DOWN state will have to wait the
   longer MCLT before being able to allocate its partner's IP addresses
   to new DHCP clients.  This may mean as opaque data. The sender MUST ensure that additional IP addresses are
   required in order to cover this time period.  Further, the server in
   PARTNER-DOWN will have to wait the longer MCLT from
   every lease
   expiration before it can reallocate an IP address to a different DHCP
   client.

6.  Packet Formats

   This section discusses the common message format that all failover
   messages have in common, and then defines option used in the failover
   protocol.

6.1.  Common message format

   All failover protocol messages are sent from a particular failover endpoint over the
   associated TCP connection
   between has a unique transaction id.

   For failover endpoints and encoded using messages that have no corresponding response message,
   the XID value is meaningless, but MUST be supplied. The XID value is
   used solely by the receiver of a response message format
   specific to determine the failover protocol.

   There exists a common message format for all failover messages, which
   utilizes
   corresponding request message.

   Requests messages where the options XID is used in a way similar to the DHCP protocol.  For each
   message type, some options are required corresponding response
   messages are: POOLREQ, BNDUPD, CONNECT, UPDREQALL, and some UPDREQ. The
   corresponding response messages are optional.  In
   addition, when a message is received any POOLRESP, BNDACK, CONNECTACK,
   UPDDONE, and UPDDONE, respectively.

   As requests/responses don't survive connection reestablishment, XIDs
   only need

   payload data - variable length

   The options that are not
   understood by placed after the receiving server MUST be ignored.

   All header, after skipping payload
   offset bytes from beginning of the fields in the fixed portion of the message MUST be filled
   with correct message.  The payload data in every message sent.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         message length (2)     | msg type (1)  |payload off (1)|
   +---------------+---------------+---------------+---------------+
   |                            time (4)                           |
   +---------------------------------------------------------------+
   |                            xid (4)                            |
   +---------------------------------------------------------------+
   |     0 or more additional header bytes  (variable)             |
   +---------------------------------------------------------------+
   | options
   are not preceded by a "cookie" value.

   The payload data  (variable)                   |
   |                                                               |
   | is formatted as DHCP-style DHCP style options                 |
   | using a unique two byte
   option number space codes and two byte option lengths.  The option codes are in a
   namespace which is unique to the RFC TBD     |
   |                   format defined by [NAMESPACE]               |
   +---------------------------------------------------------------+

   message failover protocol.

   The maximum length - 2 bytes, network byte order

   This of the payload data in octets is 2048 less the length
   size of the message.  It includes header, i.e., the two byte message
   length itself.  The maximum message length is 2048 bytes.

   msg type - 1 byte octets.

6.2.  Common option format

   The options contained in the payload data section of the failover
   message type field is used to distinguish between messages. all use a two byte option number and two byte length format.

   The following message types option numbers are defined:

   Value   Message Type
   -----   ------------
   0       reserved    not used
   1       POOLREQ     request allocation of addresses
   2       POOLRESP    respond with allocation count
   3       BNDUPD      update partner with binding info
   4       BNDACK      acknowledge receipt of binding update
   5       CONNECT     establish connection with the secondary
   6       CONNECTACK  respond to attempt drawn from an option number space unique to establish connection with partner
   7       UPDREQALL   request full transfer of binding info
   8       UPDDONE     ack send and ack of req'd binding info
   9       UPDREQ      req transfer of un-acked binding info
   10      STATE       inform partner
   the failover protocol.  All of current state or state change
   11      CONTACT     probe communications integrity with partner
   12      DISCONNECT  close a connection

   New the message types should be defined in one of two ranges, 0-127 share a common
   option number space and common options definitions, though not all
   options are required or
   129-255.  The range of 0-127 is used meaningful for messages that MUST be sup-
   ported by every server, message.

   In contrast to the options which appear in DHCP client and if a server receives a
   messages, the options in failover message are ordered.  That is, for
   some messages the order in which the
   range of 0-127 that it doesn't understand, it MUST close options appear in the TCP con-
   nection.  The range of 128-255 payload
   data area is used for significant.  The messages for which MAY be sup-
   ported but option ordering is
   significant explicitly describe the ordering requirements.  If no
   ordering requirements are mentioned, then the order is not required, and if a server receives a message in
   this range signifi-
   cant for that it does not understand it SHOULD ignore the message.

   payload offset - 1 byte

   The byte offset of

   For all options which refer to time, they all use an absolute time in
   GMT.  Time synchronization has already been achieved between the Payload Data, from
   source and the beginning of target server using the
   failover CONNECT message header. and is updated
   and refined using the time in every packet.

   The time value for the current protocol version is 8.

   time - 4 bytes, an unsigned 32 bit integer in network byte order

   The absolute time in GMT when
   giving the message was transmitted,
   represented as number of seconds elapsed since Jan 1, 1970 (i.e., similar 00:00 UTC, 1st January 1970. This
   can be converted to
   the ANSI C time_t an NTP timestamp by adding decimal 2208988800.
   This time value representation).  While format will not wrap until the year 2106.  Until sometime
   in 2038, it is equal to the ANSI C time_t value (which is signed, the a signed 32
   bit value used and will overflow into a negative number in this specification 2038).

   Options should appear once only in each message (except for BNDUPD
   and BNDACK messages where bulking is
   unsigned.

   A server SHOULD set this time used, see section 6.3 for
   details.)  An option that appears twice is not concatenated, but
   treated as close an error.

   Specific option values are described in section 12.

   See section 13 for how to the actual transmission define additional options.

6.3.  Batching multiple binding update transactions in one BNDUPD mes-
sage

   Implementations of
   the message as possible.

   xid - 4 bytes, network byte order

   This this protocol MAY send multiple binding update
   transactions in one BNDUPD message, where a binding update transac-
   tion is defined as the transaction id set of options which are associated with the failover message.  The sender
   update of a
   failover single IP address.  All implementations of this protocol
   MUST be prepared to receive BNDUPD messages which contain multiple
   binding update transactions and respond correctly to them, including
   replying with a BNDACK message is responsible which contains status for setting this number, and the receiver of multiple
   binding update transactions contained in the message copies BNDUPD message.

   In the number over into any response
   message, treating it as opaque data.  The sender SHOULD ensure that
   every discussion of sending and receiving BNDUPD messages in section
   7.1 and BNDACK messages in section 7.2, each BNDUPD message sent from a particular failover endpoint over the
   associated TCP connection has a unique transaction id unless that and
   BNDACK message is assumed to contain a re-transmission.

   payload data - variable length

   The options are placed after the header, after skipping payload
   offset bytes from beginning of the message.  The payload data options
   are not preceded by a "cookie" value.

   The payload data is formatted as DHCP style options using the two
   byte option number and two byte option length format as specified single binding update transac-
   tion in order to reduce the recommendations complexity of the DHCP panel discussions in [NAMESPACE].

   The maximum length of section
   7.

   Multiple binding update transactions MAY be batched together in one
   BNDUPD protocol message with the payload data in octets is 2048 less sets for the
   size of individual tran-
   sactions delimited by the header, i.e., assigned-IP-address option, which MUST
   appear first in the maximum message length is 2048 octets.

6.2.  Common option format

   The set for each transaction.  Ordering of
   options contained between the assigned-IP-address options is not significant.
   This is illustrated in the payload data section of following schematic representation:

       Non-IP Address/Non-client specific options first
       assigned-IP-address option for the failover
   message all use first IP address
           Options pertaining to first address, including
           at least the two byte binding-status option number and two byte length format others as specified by the recommendations of the DHCP panel in [NAMESPACE].

   The option numbers are drawn from an
           required.
       assigned-IP-address option number space unique to for the failover protocol.  All of second IP address
           Options pertaining to second address, including
           at least the message types share a common binding-status option number space and common options definitions, though not all
   options are required or meaningful for every message.

   In contrast to the options which appear in DHCP client others as
           required.
        ...

   There MUST be a one-to-one correspondence between BNDUPD and server BNDACK
   messages, the options in failover and every BNDACK message are ordered.  That is, MUST contain status for
   some messages the order in which all of the options appear
   binding update transactions in the payload
   data area is significant. corresponding BNDUPD message.

   The messages BNDACK message corresponding to a BNDUPD message MUST contain
   assigned-IP-address options for which this is all of the case
   spell it out binding update transac-
   tions in detail.

   For all the BNDUPD message.  Thus, every BNDACK message contains
   exactly exactly the same assigned-IP-address options which refer to time, they all use an absolute time in
   GMT.  Time synchronization has already been achieved between as does its
   corresponding BNDUPD message.  The order of the
   source and assigned-IP-address
   options MAY, however, be different.

   In case the target server using the CONNECT message and is updated
   using chooses to reject some or all of the time IP address
   binding information in every packet.  All time fields a BNDUPD message in a BNDACK reply, the options
   defined below use BNDACK
   message MUST contain a time represented as seconds elapsed since Jan 1,
   1970 (i.e. ANSI C time_t time value representation).  Note reject-reason option following every
   assigned-IP-address option in order to indicate that this
   is (at present) a signed field.

   Additional options can be defined the binding
   update transaction for intervendor or vendor specific
   use that IP address was not accepted and why.  As
   with limited difficulty due to the large number of a BNDACK message containing a single binding update transaction,
   an assigned-IP-address option numbers
   available.

6.2.1.  binding-status

   This without any associated reject-reason
   option is used to convey indicates a successful binding update transaction.

7.  Protocol Messages

   This section contains the current state detailed definition of a binding.

       Code          Len     Type
   +-----+-----+------+-----+-----+
   |  0  |  1  |   0  |  1  | 1-7 |
   +-----+-----+------+-----+-----+

   Legal values for this option are:

   Value Binding Status
   ----- ------------------------------------------------
   1     FREE           Lease has never been used
   2     ACTIVE         Lease is assigned the protocol mes-
   sages, including the information to a client
   3     EXPIRED        Lease has expired
   4     RELEASED       Lease has been released by client
   5     ABANDONED      A server, or client flagged address include when sending the message,
   as unusable
   6     RESET          Lease was freed by some external agent
   7     BACKUP         Lease belongs to secondary's private address pool

6.2.2.  assigned-IP-address

   The IP address well as the actions to which this take upon receiving the message.

7.1.  BNDUPD message refers.

        Code         Len          Address
   +-----+-----+------+-----+----+-----+-----+-----+
   |  0  |  2  |   0  |  4  | a1 |  a2 |  a3 |  a4 |
   +-----+-----+------+-----+----+-----+-----+-----+

6.2.3.  sending-server-IP-address

   The IP address of binding update (BNDUPD) message is used to send the server sending this message.

        Code         Len          Address
   +-----+-----+------+-----+----+-----+-----+-----+
   |  0  |  3  |   0  |  4  | a1 |  a2 |  a3 |  a4 |
   +-----+-----+------+-----+----+-----+-----+-----+

6.2.4.  addresses-transferred

   A 32 bit unsigned long in network byte order. Reports binding data-
   base changes (known as binding update transactions) to the number partner
   server, and the partner server responds with a binding acknowledge-
   ment (BNDACK) message when it has successfully committed those
   changes to its own stable storage.

   The rest of
   addresses transferred by the primary failover protocol exists to determine whether the secondary
   partner server
   (addresses is able to be used for the secondary server's private address
   pool)

        Code         Len       Number of Addresses
   +-----+-----+------+-----+----+-----+-----+-----+
   |  0  |  4  |   0  |  4  | n1 |  n2 |  n3 |  n4 |
   +-----+-----+------+-----+----+-----+-----+-----+

6.2.5.  client-identifier

   The format, code communicate or not, and conventions used are identical to DHCP option
   61.

        Code         Len       Client Identifier
   +-----+-----+------+-----+----+-----+---
   |  0  |  5  |   0  |  n  | i1 |  i2 | ...
   +-----+-----+------+-----+----+-----+--

6.2.6.  client-hardware-address

   The format is similar enable the
   partners to DHCP option 61. Byte t1 (type) MUST be set exchange BNDUPD/BNDACK messages in order to the proper ARP hardware address code, keep their
   binding databases in stable storage synchronized.

   The rest of this section is written as defined though every BNDUPD message
   contains only a single binding update transaction in order to reduce
   the ARP
   section complexity of RFC 1700 (it MUST NOT be zero!)

        Code         Len     htype   chaddr
   +-----+-----+------+-----+----+-----+-----+---
   |  0  |  6  |   0  |  n  | t1 |  c1 |  c2 | ...
   +-----+-----+------+-----+----+-----+-----+---

   Either client-identifier, client-hardware-address or BOTH MAY be
   present in the discussion.  See section 6.3 for information on
   how to create and process BNDUPD and BNDACK messages which contain
   multiple binding update transactions. At least one of them  Note that while a server MAY
   generate BNDUPD messages with multiple binding update transactions,
   every server MUST be
   present.  If both are present, able to process a BNDUPD message which contains
   multiple binding update transactions and generate the corresponding
   BNDACK messages with status for multiple binding update transactions.

   The message type for the BNDUPD message is 3.

   The following table summarizes the various options for the BNDUPD
   message.

                                        binding-status            BACKUP
                                                                  RESET
                                                                  ABANDONED
   Option                        ACTIVE     EXPIRED    RELEASED   FREE
   ------                        ------     -------    --------   ----
   assigned-IP-address           MUST       MUST       MUST       MUST
   binding-status                MUST       MUST       MUST       MUST
   client-identifier             MAY        MAY        MAY        MAY(2)
   client-hardware-address       MUST be       MUST       MUST       MAY(2)
   lease-expiration-time         MUST       MUST NOT   MUST NOT   MUST NOT
   potential-expiration-time     MUST       MUST NOT   MUST NOT   MUST NOT
   start-time-of-state           SHOULD     SHOULD     SHOULD     SHOULD
   client-last-trans.-time       MUST       SHOULD     MUST       MAY
   DDNS(1)                       SHOULD     SHOULD     SHOULD     SHOULD
   client-request-options        SHOULD     SHOULD NOT SHOULD     SHOULD NOT
   client-reply-options          SHOULD     SHOULD NOT SHOULD NOT SHOULD NOT

   (1) Only SHOULD appear if server supports dynamic DNS.

   (2) MUST NOT if binding-status is ABANDONED.

             Table 7.1-1: Options used to
   uniquely identify the owner of in a BNDUPD message

7.1.1.  Sending the BNDUPD message

   A BNDUPD message SHOULD be generated whenever any binding (exactly as changes.  A
   change might be in RFC 2131).

6.2.7.  DDNS

   If an implementation supports Dynamic DNS updates, this option is
   used to communicate the status of binding-status, the DDNS update associated with lease-expiration-time, or
   even just the last-transaction-time.  In general, any time a
   particular lease binding.  The Flags field conveys DHCP
   server writes its stable storage, a BNDUPD message SHOULD be gen-
   erated.  This will often be the types result of DNS
   RRs that are to be updated by the processing of a DHCP server, and
   client request, but it might also be the status result of the
   DDNS update.  The Domain Name field conveys the a successful
   dynamic DNS FQDN that the
   DHCP server is using to update operation.

   BNDUPD (and BNDACK) messages refer to the client, binding-status of the IP
   address, and this protocol defines a series of binding-statuses, dis-
   cussed in DNS encoding as
   specified more detail below.  Some servers may not support all of
   these binding-statuses, and so in [RFC1035].

       Code         Len        Flags      Domain Name
   +-----+-----+------+-----+-----+------+------+-----+------
   |  0  |  7  |   0  |  n  |   flags    |  d1  |  d2 | ...
   +-----+-----+------+-----+-----+------+------+-----+------

   The Flags field is those cases they will not be sent.
   Upon receipt of a 16-bit field; several bit positions are
   specified here.

   15               7             0
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           MBZ         |P|D|A|C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The bits (numbered from BNDUPD message which contains an unsupported
   binding-status, a reasonable interpretation should be made (see sec-
   tion 5.10).

   All BNDUPD messages MUST contain the least-significant bit IP address of the binding update
   transaction in network
   byte-order) are used as follows:

   0 (C): A RR the assigned-IP-address option.

   All binding update successfully completed
   1 (A): Server is controlling A RR on behalf transactions contain a binding-status option, and
   it will have one of the values found in section 5.10.  Client infor-
   mation consists of client-hardware-address and possibly a client-
   identifier, and is explained in more detail later in this section.
   The following table indicates whether client
   2 (D): PTR RR information should or
   should not appear with each binding-status in a binding update successfully completed (Done)
   3 (P): Server is controlling PTR RR on behalf tran-
   saction:

       binding-status       includes client information
       ------------------------------------------------
       ACTIVE                      MUST
       EXPIRED                     SHOULD
       RELEASED                    SHOULD
       FREE                        MAY
       ABANDONED                   MUST NOT
       RESET                       MAY
       BACKUP                      MAY

         Table 7.1.1-1: Client information required by various
         binding-status values.

   The ACTIVE binding-status requires some options to indicate the
   length of the client
   4-15 : Must binding:

      o lease-expiration-time

        The lease-expiration-time option MUST appear, and be zero

   All of set to the unspecified bit positions SHOULD
        expiration time most recently ACKed to the DHCP client.  Note
        that the time ACKed to a DHCP client is a lease duration in
        seconds, while the lease-expiration-time option in a BNDUPD mes-
        sage is an absolute time value.

      o potential-expiration-time

        The potential-expiration-time option MUST appear, and be set to 0
        a value beyond that of the lease-expiration time.  This is the
        value that is ACKed by servers
   sending the Failover-DDNS option, and they BNDACK message.  A server sending a
        BNDUPD message MUST be ignored by servers
   receiving able to recover the option.

6.2.8.  reject-reason

   This potential-
        expiration-time sent in every BNDUPD, not just those that
        receive a corresponding BNDACK, in order to be able to protect
        against possible duplicate allocation of IP addresses after
        transitioning to PARTNER-DOWN state. See section 5.2.1 for
        details as to why the potential-expiration-time exists and
        guidelines for how to decide on the value.

   The following option information is used applies to selectively reject binding updates. It all BNDUPD messages,
   regardless of the value of the binding-status, unless otherwise
   noted.

   o Identifying the client

     For many of the binding-status values a client MUST appear while
     for others a client MAY be
   used appear, and for some a client MUST NOT
     appear.

     A client is identified in BNDACK a BNDUPD message by at least one and pos-
     sibly two options.   The client-hardware-address option MUST appear
     any time that a client appears in a BNDUPD message, always associated with an assigned-IP-address
   option, which and contains
     the IP address of hardware type and chaddr information from the update being rejected.

        Code         Len     Reason Code
   +-----+-----+------+-----+----------+
   |  0  |  8  |   0  |  1  |    R1    |
   +-----+-----+------+-----+----------+

   Reason codes :

   0   Reserved
   1   Illegal IP address (not part of DHCP request
     packet.  A failover client-identifier option MUST appear any address pool)
   2   Fatal conflict exists: address time
     that a client appears in use by other client.
   3   Missing binding information.
   4   Connection rejected, time mismatch too great.
   5   Connection rejected, invalid MCLT.
   6   Connection rejected, unknown reason.
   7   Connection rejected, duplicate connection.
   8   Connection rejected, invalid failover partner.
   9   TLS not supported
   10  TLS supported but not configured
   11  TLS required but not supported by partner
   12  Message digest not supported
   13  Message digest not configured
   14  Protocol version mismatch
   15  Missing binding information
   16  Outdated binding information
   17  Less critical binding information
   18  No traffic within sufficient time
   19  Hash bucket assignment conflict
   20-253, reserved.
   254 Unknown: Error occurred but does not match any reason code
   255 Reserved for code expansion

6.2.9. a BNDUPD message

   This option is if and only if that
     client used to supply a human readable message.  It may be
   used in association DHCP client-identifier option when communicating with
     the Reject Reason Code to provide a human
   readable error message DHCP server.  See section 12.7 and 12.8 for the reject.

        Code         Len         Text
   +-----+-----+------+-----+------+-----+--
   |  0  |  9  |   0  |  n  |  c1  | c2  | ...
   +-----+-----+------+-----+------+-----+--

6.2.10.  MCLT

   Maximum Client Lead Time, in seconds.  A 32 bit integer value, in
   network byte order.

        Code         Len             Time
   +-----+-----+------+-----+----+-----+-----+-----+
   |  0  |  10 |   0  |  4  | t1 |  t2 |  t3 |  t4 |
   +-----+-----+------+-----+----+-----+-----+-----+

6.2.11.  vendor-class-identifier

   A string which identifies the vendor details of the failover protocol
   implementation.

   The code for this option is 60, and its minimum length is 1.

        Code         Len           vendor class string
   +-----+-----+------+-----+----+-----+---
   |  0  |  11 |   0  |  n  | c1 |  c2 |  ...
   +-----+-----+------+-----+----+-----+---

6.2.12.  lease-expiration-time

   The lease expiration time expressed as an absolute time in GMT
   represented as seconds elapsed since Jan 1, 1970 (i.e.  ANSI C time_t
   time value representation).

   The lease expiration time is the time that a server has ACKed how to
     construct these two options from a DHCP client.

        Code         Len          Time
   +-----+-----+------+-----+----+-----+-----+-----+
   |  0  |  13 |   0  |  4  | t1 |  t2 |  t3 |  t4 |
   +-----+-----+------+-----+----+-----+-----+-----+

6.2.13.  potential-expiration-time

   The potential expiration time expressed as an absolute time in GMT
   represented as seconds elapsed since Jan 1, 1970 (i.e.  ANSI C time_t
   time value representation). request packet.

   o start-time-of-state

     The potential expiration time start-time-of-state SHOULD appear.  It is set to the time at
     which this IP address first took on the state that one server tells
   another server that it may ACK corresponds to a client.

        Code         Len          Time
   +-----+-----+------+-----+----+-----+-----+-----+
   |  0  |  14 |   0  |  4  | t1 |  t2 |  t3 |  t4 |
   +-----+-----+------+-----+----+-----+-----+-----+

6.2.14.  grace-expiration-time

   The grace expiration time expressed as an absolute time in GMT
   represented as seconds elapsed since Jan 1, 1970 (i.e.  ANSI C time_t
   time
     the current value representation). of binding-status.

   o last-transaction-time

     The grace expiration time last-transaction-time value SHOULD appear.  This is the time that a grace period will
   expire.

        Code         Len          Time
   +-----+-----+------+-----+----+-----+-----+-----+
   |  0  |  15 |   0  |  4  | t1 |  t2 |  t3 |  t4 |
   +-----+-----+------+-----+----+-----+-----+-----+

6.2.15.  client-last-transaction-time

   The time at
     which this DHCP server last received a DHCP request packet from a
   particular the DHCP client
     referenced by the client-identifier or client-hardware-address that
     was associated with the IP address referenced by the assigned-IP-
     address.

   o DDNS

     If the DHCP server is performing dynamic DNS operations on behalf
     of the DHCP client expressed as an absolute time in GMT represented as
   seconds elapsed since Jan 1, 1970 (i.e.  ANSI C time_t time value
   representation).

        Code         Len       Partner Down Time
   +-----+-----+------+-----+----+-----+-----+-----+
   |  0  |  16 |   0  |  4  | t1 |  t2 |  t3 |  t4 |
   +-----+-----+------+-----+----+-----+-----+-----+

6.2.16.  start-time-of-state

   The time at which by the state contained in this message began,
   expressed as an absolute time in GMT represented as seconds elapsed
   since Jan 1, 1970 (i.e.  ANSI C time_t time value representation).

   This option is used for different states in different messages.  In a
   BNDUPD message client-identifier or client-
     hardware-address, then it represents the start time of should include a DDNS option containing
     the state host name, domain name, and status of the lease
   in any dynamic DNS opera-
     tions enabled.

   o client-request-options

     If the BNDUPD message.  In was triggered by a STATE message, it represents the start
   time request from a DHCP client (typi-
     cally those with binding-status of ACTIVE and RELEASED), then the partner server's failover state.

        Code         Len      Start Time
     server SHOULD include options of State
   +-----+-----+------+-----+----+-----+-----+-----+
   |  0  |  17 |   0  |  4  | t1 |  t2 |  t3 |  t4 |
   +-----+-----+------+-----+----+-----+-----+-----+

6.2.17.  server-state

   This option is used interest to convey the current state of the a failover
   endpoint in the sending server.

       Code          Len     Server State
   +-----+-----+------+-----+-----+
   |  0  |  18 |   0  |  1  | 1-9 |
   +-----+-----+------+-----+-----+

   Legal values for this option are:

   Value   Server State
   -----   -------------------------------------------------------------
   0       reserved
   1       STARTUP                      Startup state (1)
   2       NORMAL                       Normal state
   3       COMMUNICATIONS-INTERRUPTED   Communication interrupted (safe)
   4       PARTNER-DOWN                 Partner down (unsafe mode)
   5       POTENTIAL-CONFLICT           Synchronizing
   6       RECOVER                      Recovering bindings from partner
   7       PAUSED                       Shutting down for a short period.
   8       SHUTDOWN                     Shutting down for an extended
                                        period.
   9       RECOVER-DONE                 Interlock state prior to NORMAL

6.2.18.  server-flags

   This option is used to convey the current flags of
     from the failover
   endpoint client's request packet in the sending server.

       Code          Len     Server Flags
   +-----+-----+------+-----+-------+
   |  0  |  19 |   0  |  1  | flags |
   +-----+-----+------+-----+-------+

   Legal values client-request-options for this option are:

   Currently, bit 5 is defined.  All other bits
   are reserved, and must be set
     transmission to 0.

      o STARTUP

        Bit 5 is its partner.

     A server sending a BNDUPD SHOULD remember the STARTUP flag.  Bit 5 MUST be set to 1 whenever "interesting" options
     or the
        server is in STARTUP state, and set to 0 otherwise.  (Note information that
        when in STARTUP state, the state transmitted would appear in the server-state an "interesting" option is usually the last recorded state from stable storage,
        but see section 9.3 for details.)

6.2.19.  vendor-specific-options

   This option is used to convey options specific to
     transmission at a particular
   vendor's implementation.  The vendor class identifier time when the BNDUPD is used to
   specify which option space not closely associated
     with a DHCP client request.

     A server SHOULD send the embedded following "interesting" options.  It MAY
     send any DHCP client options.  As new options are drawn from.

   It functions similarly to defined, the vendor class identifier and vendor
   specific RFC
     defining these options SHOULD include information that they are
     "interesting to failover servers" if they should be sent as part of
     a BNDUPD.

         option          option
         number          name
         -----------------------------------------

         12              host-name
         81              client-FQDN [DDNS]
         82              relay-agent-information [AGENTINFO]
         TBD             user-class [USERCLASS]
         60              vendor-class-identifier

           Table 7.1.1-2: Options which SHOULD be sent in
           the DHCP protocol.

   This client-request-options option contains other options in a BNDUPD message.

   o client-reply-options

     If the same two byte code, two
   byte length format.  If this option appears in BNDUPD was triggered by a message without request from a
   corresponding vendor class identifier, it MUST be ignored.

        Code         Len        Embedded options
   +-----+-----+------+-----+----+-----+---
   |  0  |  20 |   0  |  n  | c1 |  c2 |  ...
   +-----+-----+------+-----+----+-----+---

6.2.20.  max-unacked-bndupd

   The maximum number DHCP client (typi-
     cally those with binding-status of BNDUPD message that this ACTIVE and RELEASED), then the
     server is prepared SHOULD include options of interest to
   accept over a failover partner
     from the TCP connection without causing server's DHCP reply packet in the TCP connection client-reply-options for
     transmission to
   block.

        Code         Len     Maximum Unacked BNDUPD
   +-----+-----+------+-----+----+-----+-----+-----+
   |  0  |  21 |   0  |  4  | n1 |  n2 |  n3 |  n4 |
   +-----+-----+------+-----+----+-----+-----+-----+

6.2.21.  receive-timer

   The number of seconds within which the its partner.

     A server must receive sending a message
   from its partner, BNDUPD SHOULD remember the "interesting" options
     or it will assume the information that would appear in an "interesting" option for
     transmission at a time when the partner BNDUPD is down or the
   communication path to not closely associated
     with a DHCP client request.

     A server SHOULD send the partner has failed.

        Code         Len         Receive Timer
   +-----+-----+------+-----+----+-----+-----+-----+
   |  0  |  23 |   0  |  4  | s1 |  s2 |  s3 |  s4 |
   +-----+-----+------+-----+----+-----+-----+-----+

6.2.22.  hash-bucket-assignment

   The set of hash values to which following "interesting" options.  It MAY
     send any DHCP client options.  As new options are defined, the receiving server MUST respond.
   See section 5.3 for more RFC
     defining these options SHOULD include information on how this option is used.

   The format and usage that they are
     "interesting to failover servers" if they should be sent as part of the data
     a BNDUPD.

         option          option
         number          name
         -----------------------------------------

         58              renewal-time
         59              rebinding-time

           Table 7.1.1-3: Options which SHOULD be sent in this
           the client-reply-options option is defined in
   [LOADB].

        Code         Len        Hash Buckets
   +-----+-----+------+-----+----+-----+-----+-----+
   |  0  |  24 |   0  |  32 | b1 |  b2 | ... | b32 |
   +-----+-----+------+-----+----+-----+-----+-----+

6.2.23.  message-digest a BNDUPD message.

   The BNDUPD message digest for this message.

   This option consists of SHOULD be sent as soon as possible from the time
   that the DHCP client received a variable number of bytes which contain response and the
   message digest of lease bindings data-
   base is written on stable storage.

7.1.2.  Receiving the BNDUPD message prior to the inclusion of this option.

   When this option appears in a server receives a BNDUPD message, it MUST appear as the last
   option in needs to decide how to
   processes the message.

        Code         Len       Message Digest
   +-----+-----+------+-----+----+-----+-----
   |  0  |  25 |   0  |  n  | d1 |  d2 | ...
   +-----+-----+------+-----+----+-----+-----

6.2.24.  protocol-version binding update transaction it contains and whether that
   transaction represents a conflict of any sort. The protocol version being conflict resolu-
   tion process MUST be used by on the server. It is only sent receipt of every BNDUPD message, not
   just those that are received while in the
   CONNECT and CONNECTACK messages.

        Code         Len    Version
   +-----+-----+------+-----+----+
   |  0  |  26 |   0  |  1  | v1 |
   +-----+-----+------+-----+----+

6.2.25.  TLS-request

   This option contains information relating to TLS security
   negotiation.  It is sent POTENTIAL-CONFLICT state, in a CONNECT message

   The first byte, req, is
   order to increase the TLS request from this server.  A value robustness of
   0 indicates no TLS operation, a value the protocol.

   There are three sorts of 1 indicates that TLS
   operation is desired, and a value of 2 indicates that TLS operation
   is required to establish communications with this server.

   The second byte, acc, conflicts:

      o Two clients, one IP address conflict

        This is what this server will accept the duplicate IP address allocation conflict. There are
        two different clients each allocated the same address.  See sec-
        tion 7.1.3 for TLS
   operation.  A value of 0 means that this server will not accept TLS
   connections.  A value of 1 means that how to resolve this server will accept TLS
   connections.

   If req is not zero, then acc MUST be 1. conflict.

      o Two IP addresses, one client conflict

        This allows conflict exists when a client on one server which is not configured to require TLS support
   to inform its partner that it will accept associated
        with a TLS connection although
   it one IP address, and on the other server with a different
        IP address in the same or a related subnet. This does not desire one, for instance.

        Code         Len  request accept
   +-----+-----+------+-----+----+----+
   |  0  |  27 |   0  |  2  | req| acc|
   +-----+-----+------+-----+----+----+

6.2.26.  TLS-reply

   This option contains information relating refer
        to TLS security
   negotiation.  It is sent the case where a single client has addresses in multiple dif-
        ferent subnets or administrative domains, but rather the case
        where on the same subnet the client has as lease on one IP
        address in one server and on a CONNECTACK message

   The value of 0 indicates no TLS operation, different IP address on the other
        server.

        This conflict may or may not be a value of 1 indicates problem for a given DHCP
        server implementation.  In the event that TLS operation is required.

        Code         Len     TLS
   +-----+-----+------+-----+----+
   |  0  |  28 |   0  |  1  | t1 |
   +-----+-----+------+-----+----+

6.2.27.  client-request-options

   This option contains options from a DHCP client's request.  It server requires
        that a DHCP client have only one outstanding lease for an IP
        address on one subnet, this conflict should be resolved by
        accepting the update which has the latest client-last-
        transaction-time.

      o binding-status conflict

        This is
   sent normal conflict, where one server is updating the other
        with newer information.  See section 7.1.3 for details of how to
        resolve these conflicts.

7.1.3.  Deciding whether to accept the binding update transaction in a
BNDUPD message.  The first 4 bytes message

   IP addresses undergo binding status changes for several reasons,
   including receipt and processing of the option contain
   the "magic number" DHCP client requests, administra-
   tive inputs and receipt of the option area from which the BNDUPD messages.  Every DHCP client's
   request options were taken server needs
   to respond to DHCP client requests and serves administrative inputs with
   changes to define the format its internal record of the
   rest binding-status of the sub-options contained in an IP
   address, and this option.  After the magic
   number, the options included are response is not in the normal options format
   appropriate for that magic number.

   A server SHOULD NOT include all scope of the options in a DHCP client
   request in this option, but rather failover proto-
   col.  However, the receipt of BNDUPD messages implies at least a server SHOULD include only those
   options which are pos-
   sible change of likely interest to its partner server. the binding-status for an IP address, and must be
   discussed here.  See section 7.1 7.1.2 for details.

        Code         Len         Magic Number      Embedded options
   +-----+-----+------+-----+----+----+----+----+----+----+--
   |  0  |  29 |   0  |  n  | m1 | m2 | m3 | m4 | b1 | b2 |  ...
   +-----+-----+------+-----+----+----+----+----+----+----+--

6.2.28.  client-reply-options

   This option contains options from general actions to take upon
   receipt of a DHCP server's reply BNDUPD message.

   When receiving a BNDUPD message, it is important to note that it may
   not be current, in that the server receiving the BNDUPD message may
   have had a more recent interaction with the DHCP client request.  It is than its
   partner who sent in a the BNDUPD message.  The first 4 bytes
   of the option contain  In this case, the "magic number" of receiving
   server MUST reject the option area from
   which BNDUPD message.  In addition, it is worth not-
   ing that two (and possibly three) binding-status values are the
   direct result of interaction with a DHCP reply options were taken client, ACTIVE and serves to define RELEASED
   (and possibly ABANDONED).  All other binding-status values are either
   the
   format result of the rest expiration of a time period or interaction with an
   external agency (e.g., a network admistrator).

   Every BNDUPD message SHOULD contain a client-last-transaction-time
   option, which MUST, if it appears, be the sub-options contained in this option.
   After time that the magic number, server last
   interacted with the options included are DHCP client.  It MUST NOT be, for instance, the
   time that the lease on an IP address expired.  If there has been no
   interaction with the DHCP client in question (or there is no DHCP
   client presently associated with this IP address), then there will be
   no client-last-transaction-time option in the normal
   options format appropriate for BNDUPD message.

   The following list is indexed by the binding-status that magic number.

   A a server SHOULD NOT include all of the options
   receives in a DHCP BNDUPD message.  In many cases, the binding-status of
   an IP address within the receiving server's
   reply data storage will have an
   affect upon the checks performed prior to a client's request accepting the new binding-
   status in this option, but rather a server
   SHOULD include only those options which are of likely interest BNDUPD message.

   In the following list, to its
   partner server.  See section 7.1 for details.

        Code         Len         Magic Number      Embedded options
   +-----+-----+------+-----+----+----+----+----+----+----+--
   |  0  |  30 |   0  |  n  | m1 | m2 | m3 | m4 | b1 | b2 |  ...
   +-----+-----+------+-----+----+----+----+----+----+----+--

6.3. "accept" a BNDUPD message format

   The binding means to update the
   server's bindings database with the information contained in the
   BNDUPD and once that update (BNDUPD) message is used to complete, send the binding data-
   base changes a BNDACK message
   corresponding to the partner server.

   The message type for BNDUPD message.  To "reject" a BNDUPD means to
   respond to the BNDUPD message is 3.

   The xid of with a BNDACK with a reject-reason option
   included.

   When interpreting the rules in the following list, if a BNDUPD
   doesn't have a client-last-transaction-time value, then it MUST NOT
   be unique with respect to other failover
   messages transmitted from this failover endpoint.

   The following table summarizes considered later than the various options for client-last-transaction-time in the
   receiving server's binding.   If the BNDUPD contains a client-last-
   transaction-time value and the receiving server's binding does not,
   then the client-last-transaction-time value in the BNDUPD
   message.

                                        binding-status

   Option                        ACTIVE     EXPIRED    RELEASED   FREE
   ------                        ------     -------    --------   ----
   assigned-IP-address           MUST       MUST       MUST       MUST
   binding-status                MUST       MUST MUST       MUST
   client-identifier             MAY        MAY        MAY        MAY
   client-hardware-address       MUST       MUST       MUST       MAY
   lease-expiration-time         MUST       MUST NOT   MUST NOT   MUST NOT
   potential-expiration-time     MUST       MUST NOT   MUST NOT   MUST NOT
   grace-expiration-time         MUST NOT   MUST NOT   MUST NOT   MUST NOT
   start-time-of-state           SHOULD     SHOULD     SHOULD     SHOULD
   client-last-trans.-time       MUST       SHOULD     MUST       MAY
   DDNS(1)                       SHOULD     SHOULD     SHOULD     SHOULD
   client-request-options        SHOULD     SHOULD NOT SHOULD     SHOULD NOT
   client-reply-options          SHOULD     SHOULD NOT SHOULD     SHOULD NOT
   all others                    MAY        MAY        MAY        MAY

                                        binding-status

                                BACKUP
                                RESET
   Option                       ABANDONED
   ------                       ---------
   assigned-IP-address          MUST
   binding-status               MUST
   client-identifier            MAY(2)
   client-hardware-address      MAY(2)
   lease-expiration-time        MUST NOT
   potential-expiration-time    MUST NOT
   grace-expiration-time        MUST NOT
   start-time-of-state          SHOULD
   client-last-trans.-time      MAY
   DDNS(1)                      SHOULD
   client-request-options       SHOULD NOT
   client-reply-options         SHOULD NOT
   all others                   MAY

   (1) Only SHOULD appear if server supports dynamic DNS.

   (2) MUST NOT if binding-status is ABANDONED.

             Table 6.3-1: Options used be
   considered later than the server's.

   The second rule concerns clients and IP addresses.  If the clients in
   a BNDUPD message

6.4.  BNDACK message format

   A server sends a binding acknowledgement (BNDACK) message when it has
   successfully committed binding database changes received from a fail-
   over partner and in a BNDUPD message to its own stable storage.

   The message type for receiving server's binding differ, then if
   the BNDACK message receiving server's binding-status is 4.

   The xid in a BNDACK MUST be the same as the xid of ACTIVE and the corresponding
   BNDUPD.

   The following table summarizes binding-
   status in the options for BNDUPD is ACTIVE, then if the BNDACK message. receiving server is a
   secondary server accept it, else reject it.

                        binding-status

   Option in received BNDUPD
       binding-status
       in recieving                                  FREE     RESET
       server          ACTIVE   EXPIRED   RELEASED   FREE
   ------                        ------     -------    --------   ----
   assigned-IP-address           MUST       MUST       MUST       MUST
   binding-status                MUST       MUST       MUST       MUST
   client-identifier             MAY        MAY        MAY        MAY
   client-hardware-address       MUST       MUST       MUST       MAY
   reject-reason                 MAY        MAY        MAY        MAY
   message                       MAY        MAY        MAY        MAY
   lease-expiration-time         MUST       MUST NOT   MUST NOT   MUST NOT
   potential-expiration-time     MUST       MUST NOT   MUST NOT   MUST NOT
   grace-expiration-time         MUST NOT   MUST NOT   MUST NOT   MUST NOT
   start-time-of-state           SHOULD     SHOULD     SHOULD     SHOULD
   client-last-trans.-time       SHOULD     SHOULD     SHOULD     MAY
   DDNS(1)                       SHOULD     SHOULD     SHOULD     SHOULD
   all others                    MAY        MAY        MAY        MAY

                                        binding-status   BACKUP  ABANDONED

       ACTIVE          accept    time(2)   time(1)    time(2)  accept
       EXPIRED         time(1)   accept    accept     accept   accept
       RELEASED        time(1)   time(1)   accept     accept   accept
       FREE/BACKUP     accept    accept    accept     accept   accept
       RESET
   Option           time(3)   accept    accept     accept   accept
       ABANDONED
   ------                       ---------
   assigned-IP-address          MUST
   binding-status               MUST
   client-identifier            MAY
   client-hardware-address      MAY(2)
   reject-reason                MAY
   message                      MAY
   lease-expiration-time        MUST NOT
   potential-expiration-time    MUST NOT
   grace-expiration-time        MUST NOT
   start-time-of-state          SHOULD
   client-last-trans.-time      MAY
   DDNS(1)                      SHOULD
   all others                   MAY

   (1) Only SHOULD appear if       reject    reject    reject     reject   accept

       time(1): If the server supports dynamic DNS.

   (2) MUST NOT if binding-status is ABANDONED.

              Table 6.4-1: Options used client-last-transaction-time in a BNDACK message

6.5.  Bulking for the BNDUPD and BNDACK messages
   DISCUSSION:

      Bulking
       is planned for this protocol, but it hasn't been specified later than the client-last-transaction-time in this revision of the draft.  Once
       receiving server's binding, accept it, else reject it.

       time(2): If the draft settles down, we
      will specify current time is later than the bulking approach receiving
       servers' lease-expiration-time, accept it, else reject it.

       time(3): If the client-last-transaction-time in detail.

6.6.  UPDREQ message format

   The update request (UPDREQ) message is used by one server to request
   that its partner send it all binding database information that it has
   not already seen.

   The message type for the UPDREQ message BNDUPD
       is 9.

   The xid later than the start-time-of-state in a UPDREQ message MUST be unique among the receiving server's
       binding, accept it, else reject it.

                Figure 7.1.3-1:  Accepting BNDUPD messages transmitted
   from this failover endpoint during

7.1.4.  Accepting the life of this connection.

   There are no options that MUST appear BNDUPD message

   When accepting a BNDUPD message, the information contained in an UPDREQALL message.  Any
   option MAY appear, though very few will likely the
   client-request-options and client-reply-options SHOULD be useful.

6.7.  UPDREQALL message format

   The update request all (UPDREQALL) message is used by one examined
   for any information of interest to this server.  For instance, a
   server which wished to
   request that all binding database information be sent detect changes in order client specified host names
   might want to
   recover examine and save information from a total loss of its binding database by the requesting
   server.

   The message type for the UPDREQALL message is 7.

   The xid in a UPDREQALL message MUST be unique among messages
   transmitted host-name or
   client-FQDN options.  Server's which expect to utilize information
   from this failover endpoint during the life of relay-agent-information option would want to store this con-
   nection.
   information.

7.1.5.  Time values related to the BNDUPD message

   There are no options four time values that MUST appear in an UPDREQALL message.  Any
   option MAY appear, though very few will likely be useful.

6.8.  UPDDONE message format sent in a BNDUPD message.

      o lease-expiration-time

        The update done (UPDDONE) message is used by time that the responding server gave to
   indicate the client, i.e., the time that all requested updates have been sent by
        the responding server as BNDUPD messages and responded believes that the client's lease will expire.

      o potential-expiration-time

        The time that the server wants to be sure its partner waits
        (added to by the requesting MCLT) before assuming that this lease has expired.
        Typically some time beyond the desired client lease time.

      o client-last-transaction-time

        The time that the client last interacted with this server.

      o start-time-of-state

        The time at which the binding first went into the current state.

   As discussed in section 5.2, each server
   using BNDACK messages.  While a BNDACK message MUST have been
   received for knows what its partner has
   ACKed with regard to potential-expiration time.  In addition, each BNDUPD message prior
   server needs to remember what it has told its partner as the transmission of
   potential-expiration-time.  Moreover, each server must remember what
   it has acked to the
   UPDDONE message, this doesn't necessarily mean that all of *other* server as the BNDUPD
   messages were accepted, only most recent potential-
   expiration-time from that all of them were responded to with
   a BNDACK message.  Thus, a NAK (comprised of server.

   Remember that each server sends a BNDACK message con-
   taining potential-expiration-time and
   receives an ACK for that as well as receiving a reject-reason option) could be used potential-
   expiration-time and needing to reject a BNDUPD, but remember what it has acked for that.

   While they don't have to be named in any particular way, the purposes of the UPDDONE message, such NAK would count as times
   that a
   response server needs to the associated BNDUPD message, and would not block the
   eventual transmission of the UPDDONE message.

   The message type remember for the UPDDONE message is 7.

   The xid every IP address in an UPDDONE message MUST be identical order to
   implement the xid in the
   UPDREQ or UPDREQALL message failover protocol are:

      o lease-expiration-time

        The time that initiated this server gave to the update process.

   There are no options that MUST appear in an UPDDONE message.  Any
   option MAY appear, though very few will likely DHCP client.  A DHCP
        server needs to remember this time already, just to be useful.

6.9.  POOLREQ message format a DHCP
        server.

      o sent-potential-expiration-time

        The pool request (POOLREQ) is used by the secondary server latest time sent to request
   an allocation of IP addresses from the primary server. partner for a potential-expiration-
        time.

      o acked-potential-expiration-time

        The message type latest time that the partner has acked for a potential
        expiration time.  Typically the POOLREQ message same as sent-potential-
        expiration-time if there is 1. not a BNDUPD outstanding.

      o received-potential-expiration-time

        The xid in latest time that this server has ever received as a POOLREQ message MUST be unique among messages transmit-
   ted
        potential-expiration-time from its partner in a BNDUPD that this failover endpoint during the life of this connection.

   There
        server ACKed.

   So, a server has to remember two additional times concerning BNDUPD
   messages that it has initiated, and one additional time concerning
   BNDUPD message that it has received.  How are no options these times used?

   First, let's look at the time that MUST appear in DHCP server can offer to a POOLREQ message.  Any
   option MAY appear.

6.10.  POOLRESP message format

   The pool response (POOLRESP) DHCP
   client.  A server can offer to a to a DHCP client a time that is used by no
   longer than the MCLT beyond the max( received-potential-expiration-
   time, acked-potential-expiration-time).  One might think that the primary
   server should be able to inform offer only the secondary server how many IP addresses were allocated MCLT beyond the acked-
   potential-expiration-time, and while that is certainly simple and
   easy to understand, it has negative consequences in actual operation.

   To illustrate this, in the simple case where the primary updates the
   secondary server as for a while and then fails, if the result of secondary can then renew
   the pool request.

   The message type client for only the POOLRESP message is 2.

   The xid in MCLT beyond the POOLRESP message MUST acked-potential-expiration-
   time, then the secondary will only be identical able to renew the xid in the
   POOLREQ message client for which this POOLRESP is a response.

   The following table shows
   the options that MUST appear in a POOLRESP
   message:

           Option
           ------
           addresses-transferred       MUST

                          Table 6.10-1: Options used in MCLT, because the secondary has never sent a POOLREQ message

6.11.  CONNECT message format

   The connect (CONNECT) message is used by BNDUPD packet to the
   primary server concerning this IP address and client, and so its acked-
   potential-expiration-time is zero.

   However, since the secondary is allowed to estab-
   lish a high level connection renew the client with the other server, and to transmit
   several important configuration data items between
   MCLT beyond the servers.

   The message type max( received-potential-expiration-time, acked-
   potential-expiration-time), then the secondary can usually renew the
   client for the CONNECT message full lease period, at least for the first renew it
   sees from the client, since the received-potential-expiration-time is 5.
   generally longer than the client's desired lease interval.  The xid
   difference in renew times could make a CONNECT message MUST be unique among messages transmit-
   ted from this failover endpoint during big difference in server load
   on the life of secondary in this connection.

   The CONNECT message MUST be the first message sent down a newly esta-
   blished connection.

   The following table summarizes the options that case.

   What are associated with the CONNECT message:

   Option
   ------
   sending-server-IP-address   MUST
   max-unacked-bndupd          MUST
   receive-timer               MUST
   vendor-class-identifier     MUST
   protocol-version            MUST
   TLS-request                 MUST
   MCLT                        MUST
   hash-bucket-assignment      MUST
   all others                  MAY

              Table 6.11-1: Options used in a CONNECT message

6.12.  CONNECTACK message format

   The connect response (CONNECTACK) message is used by consequences of allowing a secondary server to respond to the receipt of offer a CONNECT message from DHCP client
   a lease term of the pri-
   mary server.

   The message type for MCLT beyond the CONNECTACK message is 6. max( received-potential-
   expiration-time, acked-potential-expiration-time)?  The xid in the CONNECTACK message MUST be identical consequences
   appear whenever a server enters PARTNER-DOWN state, and affect how
   long that server has to the xid in the
   CONNECT message for which wait before reallocating expired leases.
   With this CONNECTACK is approach, when a response.

   The following table summarizes the options associated with server goes into PARTNER-DOWN state, it
   must wait the CON-
   NECTACK message:

   Option
   ------
   sending-server-IP-address   MUST
   max-unacked-bndupd          MUST
   receive-timer               MUST
   vendor-class-identifier     MUST
   protocol-version            MUST
   TLS-request                 MUST
   reject-reason               MAY(1)
   message                     MAY MCLT                        MUST NOT
   hash-bucket-assignment      MUST NOT

   (1) Indicates a rejection of beyond the CONNECT message.

              Table 6.12-1: Options used in a CONNECTACK message

6.13.  STATE message format

   The state (STATE) message is used by either server max( lease-expiration-time, sent-
   potential-expiration-time, acked-potential-expiration-time,
   received-potential-expiration-time ) for each IP address before it
   can reallocate that IP address to communicate another DHCP client.   One might
   normally think that it needed to wait only the
   current state of MCLT beyond the failover endpoint with max(
   lease-expiration-time, received-potential-expiration-time ), i.e.,
   beyond what it has told the client and what it has explicitly acked
   to the other server.  It
   MUST be sent immediately after connection negotiation completes  But with the other server, and it MUST be sent whenever the server's state
   changes.

   The message type for optimization discussed above --
   where either server can offer the STATE message is 10.

   The xid in DHCP client a STATE message MUST lease term of the
   MCLT beyond the max( received-potential-expiration-time, acked-
   potential-expiration-time), then the additional times sent-
   potential-expiration-time and acked-potential-expiration-time must be unique among messages transmitted
   from this failover endpoint during
   added into the life expression, since the partner could have used those
   times as part of its own lease time calculation.

   Thus this connection.

   The following table shows the options that MUST appear in optimization may require a STATE
   message:

           Option
           ------
           sending-state               MUST
           server-flags                MUST
           start-time-of-state         MUST

                      Table 6.13-1: Options used longer waiting time when enter-
   ing PARTNER-DOWN state, but will generally allow servers to operate
   considerably more effectively when running in COMMUNICATIONS-
   INTERRUPTED state.

7.2.  BNDACK message

   A server sends a STATE binding acknowledgement (BNDACK) message

6.14.  CONTACT when it has
   processed a BNDUPD message format

   The contact (CONTACT) and after it has successfully committed to
   stable storage any binding database changes made as a result of pro-
   cessing the BNDUPD message.  A BNDACK message is used by either server to verify that
   the connection both accept
   or reject a BNDUPD message.  A BNDACK message which contains a
   reject-reason option is operational a rejection of the corresponding BNDUPD mes-
   sage.

   In order to reduce the other server.

   The message type for complexity of the CONTACT message is 11.

   The xid in a CONTACT message MUST be unique among messages transmit-
   ted from this failover endpoint during discussion, the life rest of this connection.

   There are no options that MUST be used in a CONTACT message.

6.15.  DISCONNECT message format

   The disconnect (DISCONNECT) message is used by either server just
   prior to closing a connection.

   The message type for the DISCONNECT message
   section is 12.

   The xid in a DISCONNECT message MUST be unique among messages
   transmitted from this failover endpoint during the life of this con-
   nection.

   The DISCONNECT message MUST be the last written as though every BNDUPD message sent down contains only a connec-
   tion before it is closed.

   The following table summarizes the options that are associated with
   the DISCONNECT message:

   Option
   ------
   reject-reason               MUST
   single binding update transaction and thus every corresponding BNDACK
   message                     SHOULD

              Table 6.15-1: Options used in would also contain reply information about only a DISCONNECT message

7.  Protocol Messages

   This single
   binding update transaction.  See section contains the detailed definition of the protocol mes-
   sages, including the 6.3 for information on how
   to include when sending the message,
   as well as the actions to take upon receiving the message.

7.1. create and process BNDUPD message

   The and BNDACK messages which contain multi-
   ple binding update (BNDUPD) message is used to send the transactions.

   Note that while a server MAY generate BNDUPD messages with multiple
   binding data-
   base changes update transactions, every server MUST be able to the partner server, process a
   BNDUPD message which contains multiple binding update transactions
   and generate the partner server responds corresponding BNDACK messages with status for multi-
   ple binding update transactions.  If a server does not every create
   BNDUPD messages which contain multiple binding acknowledgement (BNDACK) message when update transactions,
   then it has success-
   fully committed those changes to its own stable storage.

   The rest of the failover protocol exists does not need to determine whether the
   partner server is be able to communicate or not, and to enable the
   partners process a received BNDACK message
   with multiple binding update transactions.  However, all servers MUST
   be able to exchange BNDUPD/BNDACK create BNDACK messages in order to keep their which deal with multiple binding databases
   update transactions received in stable storage synchronized.

7.1.1.  Sending the a BNDUPD message

   A message.

   Every BNDUPD message SHOULD be generated whenever any binding changes.  A
   change might be in the binding-status, the lease-expiration-time, or
   even just the last-transaction-time.  In general, any time a DHCP
   client sends in a packet that results in is received by a DHCP server writing MUST be responded
   to its
   stable storage, with a BNDUPD message SHOULD be generated. corresponding BNDACK message.  The receiving server SHOULD
   respond quickly to every BNDUPD (and BNDACK) messages refer message but it MAY choose to the binding-status respond
   preferentially to DHCP client requests instead of the
   IP address, and this protocol defines BNDUPD messages,
   since there is no absolute time period within which a series of binding-statuses,
   discussed in more detail below.  Some servers may not support all of
   these binding-statuses, and so in those cases they will not BNDACK must be sent,
   and upon receipt
   sent in response to a reasonable interpretation should be made.

   All BNDUPD messages MUST contain the IP address message, while DHCP clients frequently
   have strict time constraints.

   A BNDACK message can only be sent in response to a BNDUPD message
   using the assigned-IP-
   address option, and it contains the IP address about same TCP connection from which the BNDUPD message is being sent.

   All was
   received, since the XID's in BNDUPD messages MUST contain are guaranteed unique
   only during the binding-status option, and it
   will have one life of the values in the following list.  This list
   discusses the meanings a single TCP connection.  When a connection
   to a partner server goes down, a server with unprocessed BNDUPD mes-
   sages MAY simply drop all of the various binding-statuses and the infor-
   mation those messages, since it can be sure
   that should go into the partner will resend them when they are next in communica-
   tions, albeit with a different XID.  A server with unprocessed BNDUPD message
   messages when a TCP connection goes down MAY instead choose to pro-
   cess those BNDUPD messages, but it MUST NOT send any BNDACK messages
   in response (again because of them.

      o ACTIVE

        Indicates that the IP address issues surrounding XID uniqueness).

   The message type for the BNDACK message is currently leased to a DHCP
        client.

        client-hardware-address 4.

   The client-hardware-address option MUST appear, and be set from following table summarizes the htype and chaddr of options for the DHCP client to which this IP address
        is leased. BNDACK message.

                                        binding-status            BACKUP
                                                                  RESET
                                                                  ABANDONED
   Option                        ACTIVE     EXPIRED    RELEASED   FREE
   ------                        ------     -------    --------   ----
   assigned-IP-address           MUST       MUST       MUST       MUST
   binding-status                MUST       MUST       MUST       MUST
   client-identifier

        If             MAY        MAY        MAY        MAY
   client-hardware-address       MUST       MUST       MUST       MAY(2)
   reject-reason                 MAY        MAY        MAY        MAY
   message                       MAY        MAY        MAY        MAY
   lease-expiration-time         MUST       MUST NOT   MUST NOT   MUST NOT
   potential-expiration-time     MUST       MUST NOT   MUST NOT   MUST NOT
   start-time-of-state           SHOULD     SHOULD     SHOULD     SHOULD
   client-last-trans.-time       SHOULD     SHOULD     SHOULD     MAY
   DDNS(1)                       SHOULD     SHOULD     SHOULD     SHOULD

   (1) Only SHOULD appear if the DHCP client to which this IP address server supports dynamic DNS.

   (2) MUST NOT if binding-status is leased ABANDONED.

              Table 7.2-1: Options used in a
        client-identifier option to identify itself, then BNDACK message

7.2.1.  Sending the client-
        identifier BNDACK message

   The BNDACK message MUST contain the same xid as the corresponding
   BNDUPD message.

   All of the options which appear in the BNDUPD message, else it message MUST NOT
        appear.

        lease-expiration-time be
   included in the BNDACK message.  The lease-expiration-time option MUST appear, and values in the options MAY be set
   updated to reflect current information on the
        expiration time most recently ACKed to server sending the DHCP client.
   BNDACK.   Note that the time ACKed update of this information may be used for infor-
   mational purposes, but MUST NOT be assumed to a DHCP client is a lease duration necessarily be recorded
   in
        seconds, while the lease-expiration-time option in a stable storage of the server who sent the BNDUPD mes-
        sage message
   because there is an absolute time value.

        potential-expiration-time

        The potential-expiration-time option no corresponding ACK of the BNDACK message.  Any
   information that SHOULD be recorded in the partner server's stable
   storage MUST appear, and be set to transmitted in a value beyond that of subsequent BNDUPD.

   If the lease-expiration time.  This server is accepting the
        value that is ACKed by BNDUPD, the BNDACK message includes
   only those options that appeared in the BNDUPD message.  A If the server sending a
        BNDUPD message
   is rejecting the BNDUPD, the additional option reject-reason MUST be able to recover
   appear in the potential-
        expiration-time sent BNDACK message, and the message option SHOULD appear in every BNDUPD, not just those that
        receive
   this case containing a corresponding BNDACK, human-readable error message describing in order to be able to protect
        against possible duplicate allocation of IP addresses after
        transitioning to PARTNER-DOWN state. See section 5.2.1 for
        details as to why
   some detail the potential-expiration-time exists and
        guidelines reason for how to decide the value.

      o EXPIRED

        A binding-status rejection of EXPIRED is used when the BNDUPD message.

   If the server rejects the BNDUPD message with a client's binding on
        an IP address has expired BNDACK and a reject-
   reason option, it may be because the server does not wish to imple-
        ment an expired-grace period.  When believes that it has
   binding information that the partner other server ACK's the should know.  A server
   which is rejecting a BNDUPD may initiate a BNDUPD of an EXPIRED IP address, the server sets its internal
        state own in order
   to FREE.  It update its partner with what it believes is then available to allocation to any client
        of better binding infor-
   mation, but it MUST ensure through some means that it will not end up
   in a situation where each server is sending BNDUPD messages as fast
   as possible because they can't agree on which server has better bind-
   ing data.  Placing a considerable delay on the primary server.

        client-hardware-address

        There SHOULD be initiation of a DHCP client associated BNDUPD
   message after sending a BNDACK with a reject-reason would be one way
   to ensure this situation doesn't occur.

7.2.2.  Receiving the IP address
        whose binding has expired.  If there is, then the client-
        hardware-address BNDACK message

   When a server receives a BNDACK message, if it doesn't contain a
   reject-reason option MUST appear, and be set from that means that the htype BNDUPD message was accepted,
   and chaddr of the DHCP client to server which this IP address was
        leased.

        client-identifier

        There sent the BNDUPD SHOULD be a DHCP client associated update its stable storage
   with the IP address
        whose binding has expired.  If there is, then if potential-expiration-time value sent in the DHCP client
        to which this IP address was leased used a client-identifier
        option to identify itself, then BNDUPD message
   and returned in the client-identifier MUST
        appear BNDACK message.  Other values sent in the BNDUPD message, else it MUST NOT appear.

      o RELEASED
        A binding-status of RELEASED is
   message MAY be used when as desired.

   If the BNDACK message contains a DHCP client sends in reject-reason option, that means
   that the BNDUPD was rejected.  There SHOULD be a DHCPRELEASE message option in
   the BNDACK giving a text reason for the rejection, and the server does not wish
   SHOULD log the message in some way.  The server MUST NOT immediately
   try to implement
        a released-grace period.  When resend the BNDACK message as there is no reason to believe the
   partner won't reject it a second time.  However a server ACK's the
        BNDUPD of an RELEASED IP address, MAY choose
   to send another BNDACK at some future time, for instance when the
   server sets next processes an update request from its internal
        state to FREE, and it partner.

7.3.  UPDREQ message

   The update request (UPDREQ) message is available for allocation used by the primary one server to any DHCP client.

        client-hardware-address

        There SHOULD be a DHCP client associated with request
   that its partner send it all of the IP address
        whose binding database information that
   it has been released.  If there is, then not already seen.   Since each server is required to keep
   track at all times of the client-
        hardware-address option MUST appear, and be set from binding information the htype other server has
   received and chaddr ACKed, one server can request transmission of all un-
   ACKed binding database information held by the DHCP client which released this IP address.

        client-identifier

        There SHOULD be a DHCP client associated with the IP address
        whose binding has been released.  If there is, then if other server by using
   the DHCP
        client which released this IP address UPDREQ message.

   The UPDREQ message is used a client-identifier
        option to identify itself, then the client-identifier MUST
        appear in whenever the BNDUPD message, else sending server cannot proceed
   before it MUST NOT appear.

      o FREE

        A binding-status of FREE is used when has processed all previously un-ACKed binding update infor-
   mation, since the UPDREQ message should yield a DHCP server needs to
        communicate that an IP address corresponding UPDDONE
   message.  The UPDDONE message is available for allocation to
        another server, but it was not just released, expired, or reset
        by a network administrator.  When sent until the partner server ACK's that sent
   the
        BNDUPD UPDREQ message has responded to all of an FREE IP address, the server sets its internal state
        such that it is available for allocation BNDUPD messages gen-
   erated by any DHCP client.

        client-hardware-address

        There MAY be a DHCP client associated with the IP address whose
        binding is now desired to UPDREQ message with BNDACK messages (they may either be FREE.  If there is, then
   accepted or rejected by the
        client-hardware-address option BNDACK messages, but they MUST appear, and be set from have been
   responded to). Thus, the
        htype and chaddr sender of the DHCP client which released this IP
        address.

        client-identifier

        There MAY UPDREQ message can be a DHCP client associated with the IP address whose
        binding is now desired sure
   upon receipt of an UPDDONE message that it has received and committed
   to be FREE.  If there is, then if stable storage all outstanding binding database updates.

   See section 9, Failover Endpoint States, for the
        DHCP client which released this IP address used a client-
        identifier option to identify itself, then details of when the client-identifier
        MUST appear in
   UPDREQ message is sent.

7.3.1.  Sending the BNDUPD message, else it MUST NOT appear.

        client-hardware-address
        There MAY be a DHCP client associated with UPDREQ message

   The message type for the IP address whose
        binding UPDREQ message is 9.

   The UPDREQ message has now expired.  If there is, then no message specific options.

7.3.2.  Receiving the client-
        hardware-address option UPDREQ message

   A server receiving an UPDREQ message MUST appear, and be set from send all binding database
   changes that have not yet been ACKed by the htype
        and chaddr of sending server.   These
   changes are sent as undistinguished BNDUPD messages.

   However, the DHCP client server which released this IP address.

        client-identifier

        There MAY be a DHCP client associated with received and is processing the IP address whose
        binding has now expired.  If there is, then if UPDREQ mes-
   sage MUST track the DHCP client
        which most recently leased this IP address used a client-
        identifier option BNDACK messages that correspond to identify itself, then the client-identifier
        MUST appear in the BNDUPD message, else it
   messages triggered by the UPDREQ message and, when they are all
   received, the server MUST NOT appear.

        grace-expiration-time send an UPDDONE message.

   The grace-expiration-time option MUST appear, and is the length
        of time that this server will wait before trying to make processing the IP
        address available after UPDREQ message and sending BNDUPD messages
   to its partner SHOULD only track the lease has expired BNDUPD and BNDACK message pairs
   for this IP
        address.

        client-hardware-address

        There MAY be a DHCP client associated with the IP address whose unACKed binding has now been released by sending a DHCPRELEASE.  If
        there is, then the client-hardware-address option MUST appear,
        and be set from database changes that were present upon the htype and chaddr
   receipt of the DHCP client UPDREQ message.  A server which
        released this IP address.

        client-identifier

        There MAY be a DHCP client associated with the IP address whose
        binding has been released.  If there is, then if the DHCP client
        which most recently leased this IP address used a client-
        identifier option to identify itself, then the client-identifier
        MUST appear in the received an UPDREQ
   message SHOULD send BNDUPD messages for binding database changes that
   occur after receipt of the UPDREQ message, else but it MUST SHOULD NOT appear.

        client-hardware-address

        There MAY be a DHCP client associated with include
   those additional BNDUPD messages and their corresponding BNDACK mes-
   sages in the IP address whose
        binding is now desired accounting necessary to be FREE.  If there is, then consider the
        client-hardware-address option MUST appear, UPDREQ complete and be set from
   subsequently send the
        htype and chaddr UPDDONE message.  If some additional binding
   database changes end up becoming part of the DHCP client which released this IP
        address.

        client-identifier

        There MAY be a DHCP client associated with set of BNDUPD messages
   considered as part of the IP address whose
        binding is now desired UPDREQ (due to be FREE.  If there is, then if whatever algorithm the
        DHCP client which released this IP address used
   server uses to scan its bindings database for unacked changes) it
   will probably not cause any difficulty, but a client-
        identifier option server MUST NOT attempt
   to identify itself, then include all such later BNDUPD messages in the client-identifier
        MUST appear accounting for the
   UPDREQ in order to be able to transmit an UPDDONE message.

   When queuing up the BNDUPD message, else it MUST NOT appear.

        grace-expiration-time

        The grace-expiration-time MUST appear, and is messages for transmission to the length sender of time
        that this
   the UPDREQ message, the server will wait before trying to make processing the IP address
        available after UPDREQ message MUST
   honor the lease was released for this IP address

      o ABANDONED

        An ABANDONED IP address is one that has been considered unusable
        by value returned in the DHCP subsystem.  An IP address for which a valid PING
        response was received SHOULD be max-unacked-bndupd option in the CON-
   NECT or CONNECTACK message that set to ABANDONED.

        client-hardware-address

        There SHOULD NOT be a DHCP client associated up the connection with an ABANDONDED
        IP address.  The client-hardware-address option the send-
   ing server.  It MUST NOT appear
        in the send more BNDUPD message.

        client-identifier

        There SHOULD NOT be a DHCP client associated with messages without receiving
   corresponding BNDACKs than the IP address
        whose binding has now been ABANDONED.  The client-identifier
        option MUST-NOT appear value returned in the BNDUPD message.

      o RESET max-unacked-bndupd.

7.4.  UPDREQALL message

   The RESET value of the binding-status update request all (UPDREQALL) message is used by one server to indicate
   request that
        this IP address was made available by operator command.

      o BACKUP

        The BACKUP value its partner send it all of binding-status indicates that this IP
        address belongs to the secondary server, and can be allocated by
        that binding database informa-
   tion.  This message is used to allow one server to recover from a DHCP client at any time.

        client-hardware-address

        There MAY be a DHCP client associated with an BACKUP IP address.
        If there is, the client-hardware-address option MUST appear, and
        be set from the htype and chaddr
   failure of the DHCP client to which
        this IP address was most recently associated.

        client-identifier
        There MAY be a DHCP client associated with this IP address.  If
        the DHCP client to which this IP address is leased used a
        client-identifier option stable storage and to identify itself, then the client-
        identifier MUST appear restore its binding database in its
   entirety from the BNDUPD message, else it MUST NOT
        appear.

   The following option other server.

   A server which sends an UPDREQALL message cannot proceed until all of
   its binding update information is generic to restored, and it knows that all BNDUPD messages,
   regardless of
   that information is restored when an UPDDONE message is received.

   See section 9, Protocol state transitions, for the value details of when
   the binding-status.

   o start-time-of-state

     The start-time-of-state SHOULD appear.  It UPDREQALL message is set to the time at
     which this IP address first took on sent.

   The message type for the state that corresponds to UPDREQALL message is 7.

   The UPDREQALL message has no message specific options.

7.4.1.  Sending the current value of binding-status.

   o last-transaction-time UPDREQALL message

   The last-transaction-time value SHOULD appear.  This UPDREQALL is sent.

7.4.2.  Receiving the time at
     which this DHCP UPDREQALL message

   A server last received a packet from the DHCP client
     referenced by receiving an UPDREQALL message MUST send all binding data-
   base information to the client-identifier or client-hardware-address that
     was associated with sending server.  These changes are sent as
   undistinguished BNDUPD messages. Otherwise the IP address referenced by processing is the assigned-IP-
     address.

   o DDNS

     If same
   as for the DHCP server UPDREQ message.  See section 7.3.2 for details.

7.5.  UPDDONE message

   The update done (UPDDONE) message is performing dynamic DNS operations on behalf used by a server receiving an
   UPDREQ or UPDREQALL message to signify that it has sent all of the DHCP client represented
   BNDUPD messages requested by the client-identifier UPDREQ or client-
     hardware-address, then UPDREQALL request and that
   it should include has received a DDNS option containing BNDACK for each of those messages.

   While a BNDACK message MUST have been received for each BNDUPD mes-
   sage prior to the host name, domain name, and status transmission of the UPDDONE message, this doesn't
   necessarily mean that all of any dynamic DNS opera-
     tions enabled.

   o client-request-options

     If the BNDUPD was triggered by messages were accepted, only
   that all of them were responded to with a request from BNDACK message.  Thus, a DHCP client (typi-
     cally those with binding-status of ACTIVE and RELEASED), then the
     server SHOULD include options
   NAK (comprised of interest a BNDACK message containing a reject-reason option)
   could be used to reject a failover partner
     from BNDUPD, but for the client's request packet in purposes of the client-request-options for
     transmission to its partner.

     A server sending UPDDONE
   message, such NAK would count as a response to the associated BNDUPD need
   message, and would not remember block the "interesting"
     options or eventual transmission of the information that would appear in an "interesting"
     option UPDDONE
   message.

   The message type for transmission at a time when the BNDUPD UPDDONE message is not closely
     associated with a DHCP client request.

     A server SHOULD send the following "interesting" options.  It MAY
     send any DHCP client 8.

   The xid in an UPDDONE message MUST be identical to the xid in the
   UPDREQ or UPDREQALL message that initiated the update process.

   The UPDDONE message has no message specific options.  As new options are defined,

7.5.1.  Sending the RFC
     defining these options UPDDONE message

   The UPDDONE message SHOULD include information that they are
     "interesting to failover servers" if they should be sent as part of
     a BNDUPD.

         option          option
         number          name
         -----------------------------------------

         12              host-name
         81              client-FQDN [DDNS]
         82              relay-agent-information [AGENTINFO]
         TBD             user-class [USERCLASS]
         60              vendor-class-identifier

           Table 7.1.1-1: Options which SHOULD be sent in soon as the client-request-options option in last BNDACK message
   corresponding to a BNDUPD message.

   o client-reply-options

     If the BNDUPD was triggered message requested by a request the UPDREQ or
   UPDREQALL is received from a DHCP client (typi-
     cally those with binding-status of ACTIVE and RELEASED), then the server SHOULD include options which sent the UPDREQ or
   UPDREQALL.  The XID of interest to a failover partner
     from the server's DHCP reply packet in UPDDONE message MUST be the client-reply-options for
     transmission to its partner. same as the
   XID of the corresponding UPDREQ or UPDREQALL message.

7.5.2.  Receiving the UPDDONE message

   A server sending a BNDUPD need not remember receiving the "interesting"
     options or UPDDONE message knows that all of the information informa-
   tion that would appear it requested by sending an UPDREQ or UPDREQALL message has
   now been sent and that it has recorded this information in its stable
   storage.  It typically uses that the receipt of an "interesting"
     option for transmission at UPDDONE message to
   move to a time when the BNDUPD different failover state.  See sections 9.5.2 and 9.8.3 for
   details.

7.6.  POOLREQ message

   The pool request (POOLREQ) message is not closely
     associated with a DHCP client request.

     A used by the secondary server SHOULD send to
   request an allocation of IP addresses from the following "interesting" options. primary server.   It MAY
     send any DHCP client options.  As new options are defined, the RFC
     defining these options SHOULD include information that they are
     "interesting to failover servers" if they should
   MUST be sent as part of by a BNDUPD.

         option          option
         number          name
         -----------------------------------------

         58              renewal-time
         59              rebinding-time

           Table 7.1.1-2: Options which SHOULD be sent in
           the client-reply-options option in secondary server to a BNDUPD message. primary server to request IP
   address allocation by the primary.  The IP addresses allocated are
   transmitted using normal BNDUPD messages from the primary to the
   secondary.

   The POOLREQ message SHOULD be sent as soon as possible from the time secondary to the primary
   whenever the secondary transitions into NORMAL state.  It SHOULD
   periodically be resent in order that any change in the DHCP client received a response and number of
   available IP addresses on the lease bindings data-
   base is written primary be reflected in the pool on stable storage.

7.1.2. the
   secondary.  The period may be influenced by the secondary server's
   leasing activity.

   The message type for the POOLREQ message is 1.

   The POOLREQ message has no message specific options.

7.6.1.  Sending the POOLREQ message

   The POOLREQ message is sent.

7.6.2.  Receiving the BNDUPD POOLREQ message

   When a primary server receives a BNDUPD message, POOLREQ message it needs to decide how to
   processes SHOULD examine
   the message binding database and whether determine how many IP addresses the message represents a conflict
   of any sort. The conflict resolution process SHOULD be used on secon-
   dary server should have, and set these IP addresses to BACKUP state.
   It SHOULD then send BNDUPD messages concerning all of these IP
   addresses to the
   receipt secondary server.

   Servers frequently have several kinds of every BNDUPD message, not just those IP addresses available on a
   particular network segment.  The failover protocol assumes that both
   primary and secondary servers are received
   while in POTENTIAL-CONFLICT state, configured in order to increase such a way that each
   knows the robust-
   ness type and number of IP addresses on every network segment
   participating in the failover protocol.

   There are three sorts of conflicts:

      o Two clients one IP address conflict

        This  The primary server is
   responsible for allocating the duplicate secondary server the correct propor-
   tion of available IP address allocation conflict. There are
        two different clients addresses of each allocated kind, and the same address.  There
        cannot be a client conflict unless there secondary server
   is a client specified responsible for being configured in such a way that it can tell
   the BNDUPD message.  See section 5.10.1 for how to resolve
        this conflict.

      o Two kind of every IP addresses one client conflict

        This conflict exists when a client address based solely on one the IP address itself.

   A primary server is associated
        with a one MUST keep track of how many IP address, addresses were allo-
   cated as a result of processing the POOLREQ message, and on send that
   number in the other POOLRESP message.

   A primary server with MAY choose to defer processing a different
        IP address in the same or POOLREQ message
   until a related subnet. This does not refer more convenient time to the case where a single client has addresses in multiple dif-
        ferent subnets or administrative domains, process it, but rather the case
        where it should not depend
   on the same subnet secondary server to resend the client has as lease on one IP
        address POOLREQ message in one that case.

   If a secondary server and on receives a different IP address on the other
        server.

        This conflict may or may not be POOLREQ message it SHOULD report an
   error.

7.7.  POOLRESP message

   A primary server sends a problem for POOLRESP message to a given DHCP secondary server implementation.  In after
   the event that a DHCP server requires
        that a DHCP client have only one outstanding lease allocation process for an IP
        address on one subnet, this conflict should be resolved by
        accepting the update which has available addresses to the latest client-last-
        transaction-time.

      o binding-status conflict

        This is normal conflict, where one secondary
   server is updating the other
        with newer information.  See section 5.10.1 for details complete.  Typically this message will precede some of how the
   BNDUPD messages that the primary uses to resolve these conflicts.

      See section 5.10.1 for details of how send the actual allocated IP
   addresses to process binding-status
      changes in BNDUPD messages.

7.1.3.  Accepting the BNDUPD secondary.

   The message

   When accepting a BNDUPD message, type for the information contained POOLRESP message is 2.

   The xid in the
   client-request-options and client-reply-options SHOULD POOLRESP message MUST be examined
   for any information of interest to this server.  For instance, a
   server which wished identical to detect changes the xid in client specified host names
   might want examine and save information from the host-name or
   client-FQDN options.  Server's
   POOLREQ message for which expect to utilize information
   from the relay-agent-information option would want to store this
   information.

7.1.4.  Time values related to POOLRESP is a response.

7.7.1.  Sending the BNDUPD POOLRESP message

   There are three time values that may be sent

   The POOLRESP message MUST contain the same xid as the corresponding
   POOLREQ message.

   Only one option MUST appear in a BNDUPD message. POOLREQ message:

      o lease-expiration-time addresses-transferred

        The time that the server gave number of addresses allocated to the client, i.e., the time that
        the secondary server believes that the client's lease will expire.

      o potential-expiration-time

        The time that by the
        primary server wants to be sure its partner waits
        (added to as a result of a POOLREQ is contained in the MCLT) before assuming that
        addresses-transferred option in a POOLRESP message.  Note this lease has expired.
        Typically some time beyond
        is the desired client lease time.

      o client-last-transaction-time

        The time number of addresses that are transferred to the client last interacted with this server.

   As discussed secondary
        in section 5.2, each server knows what its partner has
   ACKed with regard to potential-expiration time.  In addition, each
   server needs to remember what it has told its partner the primary's binding database as a result of the
   potential-expiration-time.  Moreover, each server must remember what correspond-
        ing POOLREQ message, and that it has acked may be some time before they
        can all be transmitted to the *other* secondary server as through the most recent potential-
   expiration-time from that server.

   Remember that each server sends use
        of BNDUPD messages.

7.7.2.  Receiving the POOLRESP message

   When a potential-expiration-time and secondary server receives an ACK for that as well as receiving a potential-
   expiration-time and needing to remember what POOLRESP message, it has acked for that.

   While they don't have to be named in any particular way, SHOULD send
   another POOLRESP message if the times
   that value of the addresses-transferred
   option is non-zero.

   Typically, no other action is taken on the reception of a server needs POOLRESP
   message.

7.8.  CONNECT message

   The connect message is used to remember establish an applications level con-
   nection over a newly created TCP connection.  It gives the source
   information for every IP address in order to
   implement the failover protocol are:

      o lease-expiration-time
        The time that this server gave to connection, and critical configuration informa-
   tion.  It MUST be sent only by the DHCP client.  A DHCP primary server.  Either server needs to remember this time already, just to be can
   initiate a DHCP
        server.

      o sent-potential-expiration-time

        The latest time TCP connection, but the CONNECT message is only sent to by
   the partner for a potential-expiration-
        time.

      o acked-potential-expiration-time primary server.

   The latest time that the partner has acked message type for a potential
        expiration time.  Typically the same as sent-potential-
        expiration-time if there CONNECT message is not 5.

   The CONNECT message MUST be the first message sent down a BNDUPD outstanding.

      o received-potential-expiration-time newly esta-
   blished connection, and it MUST be sent only by the primary server.

   The latest time following table summarizes the options that this server has ever received as a
        potential-expiration-time from its partner are associated with
   the CONNECT message:

   Option
   ------
   sending-server-IP-address   MUST
   max-unacked-bndupd          MUST
   receive-timer               MUST
   vendor-class-identifier     MUST
   protocol-version            MUST
   TLS-request                 MUST
   MCLT                        MUST
   hash-bucket-assignment      MUST

              Table 7.8-1: Options used in a BNDUPD that this CONNECT message

7.8.1.  Sending the CONNECT message

   The CONNECT message MUST be the first message sent by the primary
   server ACKed.

   So, after the establishment of a server has to remember two additional times concerning BNDUPD
   messages that it has initiated, and one additional time concerning
   BNDUPD message that it has received.  How are these times used?

   First, let's look at the time that DHCP server can offer to new TCP connection with a DHCP
   client.  A secon-
   dary server can offer to a to a DHCP client a time that is no
   longer than participating in the MCLT beyond failover protocol.

   The xid of the max( received-potential-expiration-
   time, acked-potential-expiration-time).  One might think that CONNECT message must be unique.

   The IP address of the primary server should MUST be able to offer only the MCLT beyond placed in the acked-
   potential-expiration-time, and while that sending-
   server-IP-address option.  This information is certainly simple and
   easy to understand, it has negative consequences in actual operation.

   To illustrate this, placed in an option
   inside of the simple case where message in order to allow the primary updates identity of the
   secondary for sender to
   be covered by a while and then fails, if shared secret.

   The number of BNDUPD messages the secondary primary server can then renew
   the client for only the MCLT beyond the acked-potential-expiration-
   time, then accept without
   blocking the secondary will only TCP connection MUST be able to renew the client for
   the MCLT, because placed in the secondary has never sent max-unacked-bndupd
   option.  This MUST be a BNDUPD packet number equal to the
   primary concerning this IP address and client, or greater than 1, SHOULD be
   a number greater than 10, and so its acked-
   potential-expiration-time is zero.

   However, if we allow the secondary to renew SHOULD be a number less than 100.

   The length of the client with receive timer (tReceive, see section 8.3) MUST be
   placed in the receive-timer option.

   The MCLT
   beyond MUST be placed in the max( received-potential-expiration-time, acked-potential-
   expiration-time), then MCLT option.

   The hash-bucket-assignment option MUST be included in the secondary can usually renew CONNECT
   message.  In the client event that load balancing is not configured for this
   server, the full lease period, at least for hash-bucket-assignment option will indicate that.  The
   value of the first renew it sees hash-bucket-assignment option is determined from the
   client, since the received-potential-expiration-time is generally
   longer than
   specific buckets that the client's desired lease interval.  The difference in
   renew times could make a big difference in primary server load on has determined that the
   secondary server MUST service as part of the load-balancing algo-
   rithm.  The way in which the primary server determines this case.

   What are informa-
   tion is outside the consequences scope of allowing a this protocol definition.  The primary
   server to offer a DHCP client SHOULD be configured with a lease term percentage of the MCLT beyond the max( received-potential-
   expiration-time, acked-potential-expiration-time)?  The consequences
   appear whenever a server enters PARTNER-DOWN state, and affect how
   long clients that the
   secondary server has will be instructed to wait before reallocating expired leases.
   With this approach, when a server goes into PARTNER-DOWN state, it
   must wait service, and the MCLT beyond primary
   server SHOULD use the max( lease-expiration-time, sent-
   potential-expiration-time, acked-potential-expiration-time,
   received-potential-expiration-time ) for each IP address before it
   can reallocate that IP address algorithm in [LOADB] to another DHCP client.   One might
   normally think that generate a Hash Bucket
   Assignment which it needed sends to wait only the MCLT beyond secondary server.

   The vendor class identifier MUST be placed in the max(
   lease-expiration-time, received-potential-expiration-time ), i.e.,
   beyond what it has told the client and what it has explicitly acked
   to the other server.  But with the optimization discussed above --
   where either server can offer the DHCP client a lease term vendor-class-
   identifier option.

   The protocol-version option MUST be included in every CONNECT mes-
   sage.  The current value of the
   MCLT beyond the max( received-potential-expiration-time, acked-
   potential-expiration-time), then the additional times sent-
   potential-expiration-time and acked-potential-expiration-time must protocol version is 1.

   The TLS-request option MUST be
   added into the expression, since sent and contains the partner could have used those
   times desired TLS con-
   nection request as part of its own lease time calculation.

   Thus well as information concerning whether TLS is sup-
   ported.    If this optimization may require a longer waiting time when enter-
   ing PARTNER-DOWN state, but will generally allow servers to operate
   considerably more effectively when running in COMMUNICATIONS-
   INTERRUPTED state.

7.2.  BNDACK message

   Every BNDUPD CONNECT message that is received by being sent over a server already
   created TLS connection, the TLS-request MUST be responded
   to with NOT appear.

7.8.2.  Receiving the CONNECT message

   When a corresponding BNDACK message.  The receiving server SHOULD
   respond quickly to every BNDUPD message but receives a TCP connection on the failover port, if it MAY choose to respond
   preferentially to DHCP client requests instead of BNDUPD messages,
   since there
   is no absolute time period within which a BNDACK must be
   sent in response to PRIMARY server it should send a BNDUPD CONNECT message, and DHCP clients frequently do
   have time constraints that must be met.

   A BNDACK message can only be sent in response to if it is a BNDUPD message
   using the same TCP connection from which the BNDUPD
   secondary server it should wait for a CONNECT message was
   received, since the XID's in BNDUPD messages are guaranteed unique
   only during the life before sending
   any messages.  To avoid denial of service attacks, a single TCP connection.  When secondary should
   only wait for a connection
   to CONNECT message on a partner server goes down, new connection for a server with unprocessed BNDUPD mes-
   sages MAY simply drop all limited
   amount of those messages, since it can be sure
   that time and close the partner will retransmit them when they are next in communi-
   cations.  A connection if none is received during
   that time.

   When a secondary server with unprocessed BNDUPD messages when receives a TCP con-
   nection goes down MAY instead choose to process those BNDUPD mes-
   sages, but CONNECT message it MUST NOT send any BNDACK messages in response (again
   because of should:

      1.  Record the issues surrounding XID uniqueness).

7.2.1.  Sending time at which the BNDACK message

   The BNDACK message MUST contain the same xid as was received.

      2.  Examine the corresponding
   BNDUPD message.

   All protocol-version option, and decide if this server
          is capable of interoperating with another server running that
          protocol version.  If not, send the options which appear in the BNDUPD CONNECTACK message with
          the appropriate reject-reason.  The server MUST be
   included include its
          protocol-version in the BNDACK CONNECTACK message.  The values in

      3.  Examine the options MAY be
   updated to reflect current information on TLS-request option.  Figure out the server sending TLS-reply
          value based on the
   BNDACK.   Note that update capabilities and configuration of this information may be used
          server.  If the result for infor-
   mational purposes, but MUST NOT be assumed to necessarily be recorded
   in the stable storage of the server who sent TLS-reply value is a 1 and the BNDUPD message
   because there
          connection is no corresponding ACK accepted, indicating use of TLS, then immedi-
          ately send the BNDACK message.  Any
   information that SHOULD be recorded in the partner server's stable
   storage MUST be transmitted in a subsequent BNDUPD. CONNECTACK message and go into TLS negotiation.
          If the server is accepting TLS-reply value implies rejection of the BNDUPD, connection,
          then immediately send the BNDACK CONNECTACK message includes
   only those options that appeared with the TLS-
          reply value and the appropriate reject-reason option value.
          In all other cases, save the TLS-reply option information for
          the eventual CONNECTACK message.

          The possibilities for TLS-request and TLS-reply are:

          CONNECT CONNECTACK
            TLS     TLS
          request  reply
                        Reject
            t1      t1  Reason   Comments
            --      --  ------   --------
            0       0           no TLS used
            0       1    11     primary won't use TLS, secondary requires TLS
            1       0           primary desires TLS, secondary doesn't
            1       1           primary desires TLS, secondary will use TLS
            2       0    9, 10  primary requires TLS and secondary won't
            2       1           primary requires TLS and secondary will use TLS

      4.  Check to see if there is a message-digest option in the BNDUPD CON-
          NECT message.  If there was, and the server
   is rejecting does not support
          message-digests, then reject the BNDUPD, connection with the additional option appropri-
          ate reject-reason MUST
   appear in the BNDACK message, and CONNECTACK.  If the message option SHOULD appear in server does sup-
          port message-digests, then check this case containing a human-readable error message describing in
   some detail the reason for validity
          based on the rejection of the BNDUPD message.

   If message-digest, and reject it if the server rejects digest indi-
          cates the BNDUPD message with a BNDACK was altered.

      5.  Determine if the sender (from the sending-server-IP-address
          option) and a reject-
   reason option, it may be because the server believes that it has
   binding information that implicit role of the other server should know.  A sender (i.e., primary)
          represents a server with which is rejecting a BNDUPD may initiate a BNDUPD of its own in order the receiver was configured to update its partner with what it believes
          engage in failover activity.  This is better binding infor-
   mation, but it MUST ensure through some means performed after the any
          TLS or message digest processing so that it will not end up occurs after a situation where each server
          secure connection is sending BNDUPD messages as fast as
   possible because they can't agree on which server has better binding
   data.  Placing a reasonable delay on created, to ensure that there is no
          tampering with the initiation IP address of a BNDUPD mes-
   sage after the partner.

          If not, then the receiving server should reject the CONNECT
          request by sending a BNDACK CONNECTACK message with a reject-reason would be one way to
   ensure this situation doesn't occur.

7.2.2.  Receiving the BNDACK message

   When a server receives a BNDACK message, if
          value of: 8, invalid failover partner.

          If it doesn't contain a
   reject-reason option that means that is, then the BNDUPD message was accepted,
   and receiving failover endpoint should be
          determined.

      6.  Decide if the server which sent time delta between the BNDUPD MUST update its stable storage
   with sending of the potential-expiration-time value sent message,
          in the BNDUPD message time field, and returned in the BNDACK message.  Other values sent in receipt of the BNDUPD
   message MAY be used as desired.

7.3.  UPDREQ message

   The update request (UPDREQ) message message, recorded in
          step 1 above, is used by one acceptable.  A server MAY require an arbi-
          trarily small delta in time values in order to set up a fail-
          over connection with another server.  See section 5.9 for
          information on time synchronization.

          If the delta between the time values is too great, the server
          should reject the CONNECT request
   that its partner send it all by sending a CONNECTACK
          message with a reject-reason of 4, time mismatch too great.

          If the binding database information that
   it has time mismatch is not already seen.   Since each considered too great then the
          receiving server is required MUST record the delta between the servers.
          The receiving server MUST use this delta to keep
   track at correct all times of the binding information the other server has
          absolute times received and ACKed, one server can request transmission of all un-
   ACKed binding database information held by from the other server by using
   the UPDREQ message.

   The UPDREQ message in all time-
          valued options.  Note that server's can participate in fail-
          over with arbitrarily great time mismatches, as long as it is used whenever
          more or less constant.

      7.  If the sending receiving server cannot proceed
   before is a secondary server, it has processed all previously un-ACKed binding update infor-
   mation, since MUST examine
          the UPDREQ message should yield a corresponding UPDDONE
   message.  The UPDDONE message is not sent until MCLT option in the server that sent CONNECT request and use the UPDREQ message has responded to all value of
          the BNDUPD messages gen-
   erated by MCLT as the UPDREQ message MCLT for this failover endpoint.

          A receiving secondary server SHOULD be able to operate with BNDACK messages. Thus,
          any MCLT sent by the sender primary,  but if it cannot, then it
          should send a CONNECTACK with a reject-reason of 5, MCLT
          mismatch.

      8.  The server MUST store hash-bucket-assignment option for use
          during processing during NORMAL state.  If this hash bucket
          assignment conflicts with the UPDREQ message can be sure upon receipt of an UPDDONE message
   that it has received and committed to stable storage all outstanding
   binding database updates.

   See section 9, Protocol state transitions, secondary server's configured
          hash bucket assignment for use in other than NORMAL state, the details
          secondary server should send a CONNECTACK with a reject reason
          of when
   the UPDREQ message is sent.

7.3.1.  Sending 19, Hash bucket assignment conflict.

      9.  The receiving server MAY use the UPDREQ vendor-class-identifier to do
          vendor specific processing.

7.9.  CONNECTACK message

   There are no options for the UPDREQ message.

   The UPDREQ CONNECTACK message is sent with to accept or reject a unique xid.

7.3.2.  Receiving the UPDREQ message

   A server receiving an UPDREQ message MUST send all binding database
   changes that have not yet been ACKed by the sending server.   These
   changes are CONNECT message.
   It is sent as undistinguished BNDUPD messages.

   However, by the secondary server which received and is processing the UPDREQ mes-
   sage MUST track a CONNECT message.

   Attempting immediately to reconnect after either receiving a CONNEC-
   TACK with a reject-reason or after sending a CONNECTACK with a
   reject-reason could yield unwanted looping behavior, since the BNDACK messages reason
   that correspond to the BNDUPD
   messages triggered by connection was rejected may well not have changed since the UPDREQ message and, when they are all
   received,
   last attempt.  A simple suggested solution is to wait a minute or two
   after sending or receiving a CONNECTACK message with a reject-reason
   before attempting to reestablish communication.

   The message type for the server MUST send an UPDDONE message. CONNECTACK message is 6.

   The server processing following table summarizes the UPDREQ options associated with the CON-
   NECTACK message:

   Option
   ------
   sending-server-IP-address   MUST
   max-unacked-bndupd          MUST
   receive-timer               MUST
   vendor-class-identifier     MUST
   protocol-version            MUST
   TLS-request                 MUST
   reject-reason               MAY(1)
   message and sending BNDUPD messages
   to its partner SHOULD only track                     MAY
   MCLT                        MUST NOT
   hash-bucket-assignment      MUST NOT

   (1) Indicates a rejection of the BNDUPD and BNDACK CONNECT message.

              Table 7.9-1: Options used in a CONNECTACK message pairs
   for unACKed binding database changes that were present upon

7.9.1.  Sending the
   receipt CONNECTACK message

   The xid of the UPDREQ message.  A server which has received an UPDREQ CONNECTACK message SHOULD send BNDUPD messages for binding database changes MUST be that
   occur after receipt of the UPDREQ message, but it SHOULD NOT include
   those additional BNDUPD messages and their corresponding BNDACK mes-
   sages in the accounting necessary to consider the UPDREQ complete and
   subsequently send the UPDDONE
   CONNECT message.  If some additional binding
   database changes end up becoming part

   The IP address of the set of BNDUPD messages
   considered as part sending server MUST be placed in the sending-
   server-IP-address option.  This information is placed in an option
   inside of the UPDREQ (due message in order to whatever algorithm allow the
   server uses identity of the sender to scan its bindings database for unacked changes) it
   will probably not cause any difficulty, but
   be covered by a server shared secret.

   The protocol-version option MUST NOT attempt
   to include all such later BNDUPD messages be included in every CONNECTACK mes-
   sage.  The current value of the accounting for protocol version is 1.

   If the
   UPDREQ in order to connection has been rejected, the reject-reason option MUST be able to transmit
   placed in the CONNECTACK message with an UPDDONE message.

   When queuing up appropriate reason, and a
   message option SHOULD be included with a human-readable error message
   describing the BNDUPD messages reason for transmission to the sender of rejection in some detail.  If the UPDREQ message,
   reject-reason option appears, then the remaining options listed below
   do not appear.  The sending server processing should close the UPDREQ message MUST
   honor connection after
   sending the value returned CONNECTACK if the connection was rejected.

   The results of the TLS negotiation MUST be placed in the max-unacked-bndupd TLS-reply
   option.  If this CONNECTACK message is being sent over an already TLS
   secured connection, then there MUST NOT be a TLS-reply option.

   If there was a message-digest option in the CON-
   NECT or CONNECT message, then
   there MUST be a message-digest in the CONNECTACK message that set up the connection with and any sub-
   sequent messages if the send-
   ing server.  It MUST NOT send more CONNECTACK does not contain a reject-reason.

   The number of BNDUPD messages the server can accept without receiving
   corresponding BNDACKs than blocking
   the value returned TCP connection MUST be placed in max-unacked-bndupd.

7.4.  UPDREQALL message

   The update request all (UPDREQALL) message is used by one server to
   request that its partner send it all of the binding database informa-
   tion. max-unacked-bndupd option.
   This message is used to allow one server to recover from SHOULD be a
   failure of stable storage number greater than 10, and to restore its binding database in its
   entirety from the other server.

   A server which sends an UPDREQALL message cannot proceed until all of
   its binding update information is restored, and it knows that all SHOULD be a number less
   than 100.

   The length of
   that information is restored when an UPDDONE message is received.

   See the receive timer (tReceive, see section 9, Protocol state transitions, for 8.3) MUST be
   placed in the details of when receive-timer option.

   The vendor class identifier MUST be placed in the UPDREQALL message vendor-class-
   identifier option.

   If the server is sent.

7.4.1.  Sending rejecting the UPDREQALL message

   There are no options for CONNECT message, then the UPDREQALL message.

   The UPDREQALL reject-
   reason option MUST appear.  A message is sent with option SHOULD appear to give a unique xid.

7.4.2.  Receiving
   human readable version of the UPDREQALL message

   A server receiving an UPDREQALL rejection reason.

   After a connection is created (either by sending a CONNECTACK message MUST send all binding data-
   base information
   to the first CONNECT message, or sending server.  These changes are sent as
   undistinguished BNDUPD messages.

   However, the server processing the UPDREQALL a CONNECTACK message MUST track the
   BNDACK messages that correspond to the BNDUPD messages triggered by
   the UPDREQALL a
   CONNECT message and, when they are all received, received over a TLS connection), the server MUST send an UPDDONE
   a STATE message.

   Just as specified for the processing of the UPDREQ message,

   After a connection is created, the server processing MUST start two timers for
   the UPDREQALL message connection: tSend and sending BNDUPD messages
   to its partner tReceive.   The tSend timer SHOULD only track be
   approximately 33 percent of the BNDUPD and BNDACK message pairs
   for unACKed binding database changes that were present upon time in the
   receipt of receiver-timer option in
   the UPDREQALL corresponding CONNECT message.  A server which has received an
   UPDREQALL message  The tReceive timer SHOULD send BNDUPD messages for binding database
   changes that occur after receipt of be the UPDREQ message, but it SHOULD
   NOT include those additional BNDUPD messages and their corresponding
   BNDACK messages
   time sent in the accounting necessary to consider the UPDREQALL
   complete and subsequently send receiver-timer option in the UPDDONE CONNECTACK message.

   The tReceive timer is reset whenever a message is received from this
   TCP connection.  If some addi-
   tional binding database changes end up becoming part of it ever expires, the set of
   BNDUPD messages TCP connection is dropped
   and communications with this partner is considered as part of the UPDREALLQ (due to whatever
   algorithm the server uses to scan its bindings database for unacked
   changes) it will probably not cause any difficulty, but ok.

   The tSend timer is reset whenever a server MUST
   NOT attempt to include all such later BNDUPD messages in the account-
   ing for the UPDREQALL in order to be able to transmit an UPDDONE mes-
   sage. message is sent over this connec-
   tion. When queuing up the BNDUPD messages for transmission to the sender of
   the UPDREQALL message, the server processing the UPDREQALL it expires, a CONTACT message MUST honor be sent.

7.9.2.  Receiving the value returned in CONNECTACK message

   If a CONNECTACK message is received with a different XID from the max-unacked-bndupd option one
   in the CONNECT or that was sent, it SHOULD be ignored.

   When a CONNECTACK message that set up is received, the connection with following actions should
   be taken:

      1.  Record the sending
   server.  It MUST NOT send more BNDUPD messages without receiving
   corresponding BNDACKs than time the value returned in max-unacked-bndupd.

7.5.  UPDDONE message

   The update done (UPDDONE) message was received.

      2.  Check to see if there is used by a server receiving an
   UPDREQ or UPDREQALL message to signify that it has sent all of the
   BNDUPD messages requested by reject-reason option in the UPDREQ or UPDREQALL request and that
   it has received CONNEC-
          TACK message.  If not, continue with step 3.  If there is a BNDACK for each of those messages.

7.5.1.  Sending
          reject-reason option, the UPDDONE message

   The UPDDONE message server SHOULD be sent as soon as report the last BNDACK message
   corresponding to error code.
          If a BNDUPD message requested by the UPDREQ or
   UPDREQALL is received from the option appears a server which sent SHOULD display the UPDREQ or
   UPDREQALL.  The XID of string
          from the UPDDONE message option in a user visible way.  The server
          MUST be the same as close the
   XID of connection if a reject-reason option appears.

      3.  Check to see if the corresponding UPDREQ or UPDREQALL message.

7.5.2.  Receiving xid on the UPDDONE CONNECTACK matches an outstand-
          ing CONNECT message

   A server receiving on this TCP connection.

      4.  Check the UPDDONE message knows that all value of the informa-
   tion that it requested by sending an UPDREQ or UPDREQALL message has
   now been sent TLS-reply option, and that if it has recorded this information in its stable
   storage.  It typically uses that the receipt was 1, then
          skip processing of an UPDDONE message to
   move to a different failover state.  See sections 9.5.2 and 9.8.3 for
   details.

7.6.  POOLREQ message

   The pool request (POOLREQ) message is used by the secondary server to
   request an allocation rest of IP addresses from the primary server.   It
   MUST be sent by CONNECTACK message, and
          immediately enter into TLS connection setup.

          If it does not, a secondary server SHOULD report an error.

          This step occurs prior to steps 5 and 6 in order to allow
          creation of a primary server secure connection (if required) prior to request IP
   address allocation by pro-
          cessing the primary.  The protocol version and IP addresses allocated are
   transmitted using normal BNDUPD messages from the primary to address information.

      5.  Examine the
   secondary.

   The POOLREQ message SHOULD be sent from value of the secondary protocol-version option.  If this
          server is able to establish connections with another server
          running this protocol version, then continue, else close the primary
   whenever
          connection.

      6.  Decide if the secondary transitions into NORMAL state.  It SHOULD
   periodically be resent in order that any change in time delta between the number sending of
   available IP addresses on the primary be reflected message,
          in the pool on the
   secondary.  The period may be influenced by the secondary server's
   leasing activity.

7.6.1.  Sending time field, and the POOLREQ message

   The POOLREQ message has no options.  It must be sent with a unique
   xid.

7.6.2.  Receiving receipt of the POOLREQ message

   When a primary message, recorded in
          step 1 above, is acceptable.  A server receives MAY require an arbi-
          trarily small delta in time values in order to set up a POOLREQ message it SHOULD examine fail-
          over connection with another server.

          If the binding database and determine how many IP addresses delta between the time values is too great, the secon-
   dary server
          should have, and set these IP addresses to BACKUP state.
   It SHOULD then send BNDUPD messages concerning all of these IP
   addresses to the secondary server.

   Servers frequently have several kinds of IP addresses available on a
   particular network segment.  The failover protocol assumes that both
   primary and secondary servers are configured in such a way that each
   knows drop the type and number of IP addresses on every network segment
   participating in TCP connection.

          If the failover protocol.  The primary server time mismatch is
   responsible for allocating not considered too great then the secondary
          receiving server MUST record the delta between the servers.
          The receiving server MUST use this delta to correct propor-
   tion of available IP addresses all of each kind, and the secondary
          absolute times received from the other server
   is responsible for being configured in such a way all time-
          valued options.  Note that it can tell the kind of every IP address based solely on failover protocol is con-
          structed so that two servers can be failover partners with
          arbitrarily great time mismatches.

      7.  If the IP address itself.

   A primary receiving server MUST keep track of how many IP addresses were allo-
   cated as is a result of processing secondary server, it MUST examine
          the POOLREQ message, and send that
   number MCLT option in the POOLRESP message. CONNECT request and use the value of
          the MCLT as the MCLT for this failover endpoint.

          A primary receiving secondary server MAY choose to defer processing a POOLREQ message
   until a more convenient time SHOULD be able to process it, operate with
          any MCLT sent by the primary,  but if it should not depend
   on the secondary server to retransmit cannot, then it MUST
          drop the POOLREQ message in that
   case. TCP connection.

      8.  If a secondary server receives a POOLREQ message it SHOULD report an
   error.

7.7.  POOLRESP message

   A primary the receiving server sends a POOLRESP message to is a secondary server after server, it MUST store
          the allocation process hash-bucket-assignment option for available addresses to the secondary
   server is complete.  Typically use during processing
          during NORMAL state.  If this message will precede some of hash bucket assignment conflicts
          with the
   BNDUPD messages that server's configured hash bucket assignment for use in
          other than NORMAL state, the primary uses to secondary server should send a
          CONNECTACK with a reject reason of 19, Hash bucket assignment
          conflict.

      9.  The receiving server MAY use the actual allocated IP
   addresses vendor-class-identifier to do
          vendor specific processing.

      10. After accepting a CONNECTACK message, the secondary.

7.7.1.  Sending the POOLRESP message

   The POOLRESP message server MUST contain the same xid as the corresponding
   POOLREQ send a
          STATE message.

   The only option which MUST appear in

          After receiving a POOLREQ message is:

      o addressed-transferred

        The number of addresses allocated to CONNECTACK message, the secondary server by MUST start
          two timers for the
        primary server as a result connection: tSend and tReceive.   The tSend
          timer SHOULD be approximately 20 percent of a POOLREQ is contained the time in the
        addresses-transferred
          receiver-timer option in a POOLRESP message.  Note this
        is the number of addresses that are transferred corresponding CONNECTACK message.
          The tReceive timer SHOULD be set to the secondary time sent in the primary's binding database as
          receiver-timer option in the CONNECT message.

          The tReceive timer is reset whenever a result of message is received
          from this TCP connection.  If it ever expires, the correspond-
        ing POOLREQ message, TCP connec-
          tion is dropped and that it may be some time before they
        can all be transmitted to the secondary server through the use
        of BNDUPD messages.

7.7.2.  Receiving the POOLRESP message

   When a secondary server receives communications with this partner is con-
          sidered not ok.

          The tSend timer is reset whenever a POOLRESP message, it SHOULD send
   another POOLRESP message if the value of the addresses-transferred
   option is non-zero.

   Typically, no other action is taken on the reception of sent over this
          connection. When it expires, a POOLRESP
   message.

7.8.  CONNECT CONTACT message MUST be sent.

7.10.  STATE message

   The connect state (STATE) message is used to establish an applications level con-
   nection over a newly created TCP connection.  It gives communicate the source
   information for current failover
   state to the connection, and some important configuration
   information.  It partner server.

   The STATE message MUST be sent only by the primary server.  Either
   server can initiate after sending a TCP connection, but the CONNECT CONNECTACK message is only
   that didn't contain a reject-reason option, and MUST be sent by the primary server.

7.8.1.  Sending the CONNECT after
   receiving a CONNECTACK message

   The CONNECT without a reject-reason option.

   A STATE message MUST be the first message sent by the primary
   server after whenever the establishment of failover endpoint changes
   its failover state and a new TCP connection with a secon-
   dary server participating in exists to the partner.

   The STATE message requires no response from the failover protocol. partner.

   The xid of message type for the CONNECT STATE message must be unique. is 10.

   The IP address of following table shows the primary server options that MUST be placed appear in a STATE
   message:

   Option
   ------
   sending-state               MUST
   server-flags                MUST
   start-time-of-state         MUST

              Table 7.10-1: Options used in a STATE message

7.10.1.  Sending the sending-
   server-IP-address option.  This information STATE message

   The current failover state is placed in an the server-state option
   inside and
   the current state of the message STARTUP flag is placed in order to allow the identity of server-flags
   option.

   The message is sent with a unique xid.

   A server SHOULD only send the sender to
   be covered by STATE message either when the connec-
   tion is created (i.e, after sending or receiving a shared secret.

   The number of BNDUPD messages CONNECTACK message
   with no reject-reason option), or when there is a change from the primary server can accept without
   blocking
   values sent in a previous STATE message.

7.10.2.  Receiving the TCP connection MUST be placed STATE message

   Every STATE message SHOULD indicate a change in state or a change in
   the max-unacked-bndupd
   option.  This MUST be flags.

   When a number equal STATE message is received, any state transitions specified in
   section 9 are taken.

   No response to or greater than 1, SHOULD be a number greater than 10, and SHOULD be STATE message is required.

7.11.  CONTACT message

   The contact (CONTACT) message is sent to verify communications
   integrity with a number less than 100. failover partner.  The length CONTACT message is sent when
   no messages have been sent to the failover partner for a specified
   period of time.  This is determined by the receive tSend timer (tReceive, see expiring (see
   section 8.3) MUST be
   placed in 8.3).

   The message type for the receive-timer option. CONTACT message is 11.

   The MCLT MUST be placed in CONTACT message has no message specific options.

7.11.1.  Sending the MCLT option. CONTACT message

   The hash-bucket-assignment option MUST be included in CONTACT message is sent.

7.11.2.  Receiving the CONNECT
   message.  In CONTACT message

   When a CONTACT message is received, the event tReceive timer is reset (as
   it is with any message that load balancing is not configured for this
   server, the hash-bucket-assignment option will indicate that.  The
   value of received).

   A server MAY use the hash-bucket-assignment option is determined from time in the
   specific buckets that time field and the primary server has determined that time recorded
   above to refine the
   secondary server MUST service as part of delta time calculations between the load-balancing algo-
   rithm. servers.

7.12.  DISCONNECT message

   The way in which the primary server determines this informa-
   tion DISCONNECT is outside the scope of this protocol definition.  The primary
   server SHOULD be configured with last message sent over a connection before
   dropping an established connection.

   After sending or receiving a DISCONNECT message, a percentage of clients that the
   secondary server will be instructed needs to
   have some mechanism to prevent an error loop. Simply reconnecting to service, and
   the primary
   server SHOULD use partner immediately is not the algorithm in [LOADB] best option, especially after
   several consecutive attempts.

   A simple suggested solution is to generate wait a Hash Bucket
   Assignment which it sends minute or two after sending
   or receiving a DISCONNECT before attempting to reestablish communica-
   tion.

   The message type for the secondary server. DISCONNECT message is 12.

   The vendor class identifier DISCONNECT message MUST be placed in the vendor-class-
   identifier option. last message sent down a connec-
   tion before it is closed.

   The protocol-version option following table summarizes the options that are associated with
   the DISCONNECT message:

   Option
   ------
   reject-reason               MUST be included
   message                     SHOULD

              Table 7.12-1: Options used in every CONNECT mes-
   sage.  The current value of a DISCONNECT message

7.12.1.  Sending the protocol version is 1. DISCONNECT message

   The TLS-request option DISCONNECT message MUST be sent and contains the desired TLS con-
   nection request as well as information concerning whether TLS is sup-
   ported.    If this CONNECT last message is being sent over a already
   created TLS connection, the TLS-request MUST NOT appear.

7.8.2.  Receiving by the CONNECT message

   When a server receives
   which is dropping a TCP connection on connection.

   The xid of the failover port, if it
   is a PRIMARY server it should send a CONNECT message, and if it is DISCONNECT message must be unique.

   The reject-reason option MUST appear giving a
   secondary server it should wait for reason why the connec-
   tion was dropped.  A message option SHOULD appear giving a CONNECT message. human
   readable error message with possibly more details.

7.12.2.  Receiving the DISCONNECT message

   When a secondary server receives a CONNECT DISCONNECT message it should:

      1.  Record the time at which should log the message
   if there was received.

      2.  Examine the protocol-version option, one and decide possibly raise an alarm of some sort if this the
   reject reason was one that was sufficiently serious.

8.  Connection Management

   Servers participating in the failover protocol communicate over TCP
   connections.   These TCP connections are used both to transmit bind-
   ing information from one server
          is capable of interoperating with to another as well as to allow each
   server running that
          protocol version.  If not, send the CONNECTACK message to determine whether communications is possible with the appropriate reject-reason.  The server MUST include its
          protocol-version in other
   server.

   Central to the CONNECTACK message.

      3.  Examine operation of the TLS-request option.  Figure out the TLS-reply
          value based on the capabilities and configuration failover protocol is a notion of this
          server, and save it for the CONNECTACK message.  If
   "communications okay" or "communications failed".  Failover state
   transitions are taken in many cases when the
          results status of communications
   with the TLS negotiation result in a connection rejec-
          tion, then go immediately to send partner changes, and the CONNECTACK message.

          The possibilities are:

               CONNECT        CONNECTACK
             TLS-request       TLS-reply

                                    Reject
              req acc          t1   Reason   Comments
              --- ---          --   ------   --------
              0   0            0
              0   0            1    11       receiver requires TLS
              0   1            0
              0   1            1
              1   0            -             request doesn't make sense
              1   1            0
              1   1            1
              2   0            -             request doesn't make sense
              2   1            0    9 existence or 10  receiver won't do TLS
              2   1            1

      4.  Check non-existence of a TCP
   connections between failover endpoints is used to see determine if there com-
   munications is "okay" or "failed".

   A single TCP connection exists which connects two failover endpoints.

8.1.  Connection granularity

   There exists one TCP connection between each set of failover end-
   points.  See section 5.1.1 for an explanation of failover endpoints.

   There are a message-digest option in the CON-
          NECT message.  If there was, and maximum of two TCP connections between any two servers
   implementing the server does not support
          message-digests, then reject failover protocol, one for each of the possible
   failover endpoints between these two servers.  There is a minimum of
   one TCP connection between one server and every other failover server
   with which it implements the appropri-
          ate reject-reason in the CONNECTACK.

      5.  Determine if the sender (from the sending-server-IP-address
          option) and failover protocol.

8.2.  Creating the implicit role of TCP connection

   There are two ports used for initiating TCP connections, correspond-
   ing to the sender (i.e., primary)
          represents two roles that a server can fill with which the receiver was configured respect to
          engage in another
   server.  Every server implementing the failover activity.  This protcol MUST listen
   on at least one of these ports.  Port 647 is performed after the any
          TLS processing so that it occurs after port to which pri-
   mary servers will attempt a connection, and port TBD is the port to
   which secondary servers will attempt a connection.  When a secure connection
   attempt is
          created, received on port 647 it is therefore from a primary
   server, and it is attempting to ensure that there connect to this server as a secondary
   server.  Likewise, when an attempt to connect is no tampering with received on port TBD
   the IP
          address connection attempt is from a secondary server, and it is attempt-
   ing to connect to this server as a primary server.  The source port
   of any TCP connection is unimportant.

   Every server implementing the partner.

          If not, then failover protocol SHOULD attempt to
   connect to all of its partners periodically, where the receiving server should reject period is
   implementation dependent and SHOULD be configurable.  In the CONNECT
          request event
   that a connection has been rejected by sending a CONNECTACK message with a
   reject-reason
          value of: 8, invalid failover partner.

          If option contained in it is, or a DISCONNECT message, a
   server SHOULD reduce the frequency with which it attempts to connect
   to that server but it SHOULD continue to attempt to connect periodi-
   cally.

   If a connection attempt has been received from another server in a
   particular role (i.e., from a specific failover endpoint) then the
   receiving failover endpoint should be
          determined.

      6.  Decide if server MUST NOT initiate a connection attempt to the time delta between
   partner server in that same role.

   If both servers happen to attempt to connect simultaneously, the sending
   secondary server MUST drop its attempt in favor of the message, primary's
   attempt.  Thus, in the time field, event that a secondary server receives a con-
   nection attempt to port 647 from a primary server when it has already
   initiated a connection attempt to port TBD on the same primary
   server, it MUST accept the connection to port 647 and it MUST drop
   drop the receipt of connection attempt to port TBD. In the message, recorded in
          step 1 above, is acceptable.  A event that a primary
   server MAY require an arbi-
          trarily small delta in time values in order receives a connection attempt to set up port TBD from a secondary
   server when it has already initiated a fail-
          over connection with another server.  See section 5.9 for
          information attempt to port 647
   on time synchronization.

          If that same server, it MUST reject the delta between connection attempt to port
   TBD and continue to pursue the time values connection attempt on port 647.

   Once a connection is too great, established, the primary server
          should reject MUST send a CON-
   NECT message across the connection.  A secondary server MUST wait for
   the CONNECT request by sending message from a CONNECTACK mes-
          sage with primary server.

   Every CONNECT message includes a reject-reason of 4, time mismatch too great.

          If TLS-request option, and if the time mismatch is CON-
   NECTACK message does not considered too great reject the CONNECT message and the TLS-reply
   option says TLS MUST be used, then the
          receiving servers will immediately enter
   into TLS negotiation.

   Once TLS negotiation is complete, the primary server MUST record resend the delta between
   CONNECT message on the servers. newly secured TLS connection and then wait for
   the CONNECTACK message in response.  The receiving server TLS-request and TLS-reply
   options MUST use this delta to correct all of the
          absolute times received from have the other server same values in all time-
          valued options.  Note that server's can participate this second CONNECT and CONNEC-
   TACK message as they had in fail- the first messages.

   The second message sent over with arbitrarily great time mismatches, as long as it is
          more a new connection (either a bare TCP con-
   nection or less constant.

      7.  If the receiving server a connection utilizing TLS) is a secondary server, it MUST examine
          the MCLT option in the CONNECT request and use STATE message.  Upon the value
   receipt of this message, the MCLT as the MCLT for receiver can consider communications up.

   It is entirely possible that two servers will attempt to make connec-
   tions to each other essentially simultaneously, and in this failover endpoint.

          A receiving case the
   secondary server SHOULD will be able to operate with
          any MCLT sent by the primary,  but if it cannot, then it
          should send a CONNECTACK with waiting for a reject-reason of 5, MCLT
          mismatch.

      8. CONNECT message on each con-
   nection.  The primary server MUST store hash-bucket-assignment option for use
          during processing during NORMAL state.  If this hash bucket
          assignment conflicts with send a CONNECT message over one
   connection and it MUST close the secondary server's configured
          hash bucket assignment for use in other than NORMAL state, the connection.

   A secondary server should send a CONNECTACK MUST NOT respond to the closing of a TCP connec-
   tion with a reject reason
          of 19, Hash bucket assignment conflict.

      9.  The receiving server MAY use the vendor-class-identifier blind attempt to do
          vendor specific processing.

7.9.  CONNECTACK message reconnect -- there may be another TCP
   connection to the same failover partner already in use.

8.3.  Using the TCP connection for determining communications status

   The CONNECTACK message TCP connection is sent used to accept determine the communications status of
   the other server, i.e., communications-ok, or reject communications-
   interrupted.

   Three things must happen for a CONNECT message.
   It is sent by the secondary server which received a CONNECT message.

   Attempting immediately to reconnect after either receiving a CONNEC-
   TACK with a reject-reason or after sending a CONNECTACK with a
   reject-reason could yield unwanted looping behavior, since the reason consider that the communications
   are ok with respect to another server:

      1.  A TCP connection was rejected may well not have changed since must be established to the
   last attempt. other server.

      2.  A simple suggested solution is to wait a minute or two
   after sending or receiving a CONNECTACK CONNECT message with must be received and a reject-reason
   before attempting to reestablish communication.

7.9.1.  Sending the CONNECTACK message
          sent in response.  The xid of the CONNECTACK message MUST be that of the corresponding CONNECT message.

   The IP address of the sending server MUST be placed in the sending-
   server-IP-address option.  This information is placed in an option
   inside of the message in order is used to allow determine
          the identity identify of the sender to
   be covered by a shared secret.

   The protocol-version option MUST be included in every CONNECTACK mes-
   sage.  The current value failover endpoint of the protocol version is 1.

   If other end of the
          TCP connection has been rejected, -- without it, the reject-reason option MUST failover endpoint cannot be
   placed in
          uniquely determined.  Without knowledge of the CONNECTACK message failover end-
          point, then the entity with an appropriate reason, and a which communications is ok is
          undetermined.

      3.  A STATE message option SHOULD must be included with a human-readable error message
   describing the reason for the rejection in some detail.  If the
   reject-reason option appears, then received from the remaining options listed below
   do not appear.  The sending other server should close the connection after
   sending over
          the CONNECTACK if connection.  This STATE message initializes important
          information necessary to the connection was rejected.

   The results operation of the TLS negotiation MUST be placed in the TLS-reply
   option.  If this CONNECTACK message is being sent over an already TLS
   secured connection, then there MUST NOT be a TLS-reply option.

   If there was a message-digest option in the CONNECT message, then
   there MUST be a message-digest in state machine
          the CONNECTACK message and any sub-
   sequent messages if governs the CONNECTACK does not contain a reject-reason.

   The number behavior of BNDUPD messages the this failover endpoint.

   There are two ways that a server can accept without blocking
   the determine that communications
   has failed:

      1.  The TCP connection MUST be placed in the max-unacked-bndupd option.
   This SHOULD be a number greater than 10, and SHOULD be can go down, yielding an error when
          attempting to send or receive a number less
   than 100.

   The length message. This will happen at
          least as often as the period of the receive timer (tReceive, see section 8.3) MUST be
   placed in the receive-timer option. tSend timer.

      2.  The vendor class identifier MUST be placed in the vendor-class-
   identifier option.

   If the server tReceive timer can expire.

   In either of these cases, communications is rejecting considered interrupted.

   Several difficulties arise when trying to use one TCP connection for
   both bulk data transfer as well as to sense the CONNECT message, then communications status
   of the reject-
   reason option MUST appear.  A message option SHOULD appear to give a
   human readable version other server.   One aspect of the rejection reason.

   After a connection problem stems from the dif-
   ferent requirements of both uses.  The bulk data transfer is created (either by sending a CONNECTACK message of
   course critically important to the first CONNECT message, or sending a CONNECTACK message to a
   CONNECT message received over a TLS connection), protocol, but the server MUST send
   a STATE message.

   After speed with which
   it is processed is not terribly significant.  It might well be
   minutes before a connection BNDUPD message is created, the server MUST start two timers for
   the connection: tSend processed, and tReceive.   The tSend timer SHOULD be
   approximately 33 percent while not optimal,
   such an occasional delay doesn't compromise the correctness of the time in
   protocol. However, the receiver-timer option in speed with which one server detects the corresponding CONNECT message.  The tReceive timer SHOULD other
   server is up (or, more importantly, down) is more highly constrained.
   Generally one server should be able to detect that the
   time sent in the receiver-timer option in the CONNECTACK message.

   The tReceive timer other server
   is reset whenever not communicating within a message is received from this
   TCP connection.  If minute or less.

   These differing time constraints makes it ever expires, difficult to use the same
   TCP connection is dropped
   and for data transfer as well as to sense communications with this partner is considered not ok.
   integrity.   See section 3.5 for additional details on TCP.

   The tSend timer solution to this problem is reset whenever a to require that some message is be
   received by each end of the connection within a limited time or that
   the connection will be considered down.  If no messages have been
   sent over this connec-
   tion. When it expires, recently, then a CONTACT message MUST be is sent.

7.9.2.  Receiving

   In the CONNECTACK message

   If a CONNECTACK message case where there is received with no data queued to be sent, this is not a different XID from the one
   problem, but in the CONNECT that was sent, it SHOULD be ignored.

   When a CONNECTACK message case where there is received, the following actions should data queued to be taken:

      1.  Record sent to the time
   partner, then the CONTACT message was received.

      2.  Check to see if there will not actually be transmitted
   until the queued data is a reject-reason option in sent.  Section 3.5 explains why waiting for
   TCP to determine that the CONNEC-
          TACK message.  If not, continue with step 3.  If there connection is down is not acceptable, and
   leads a
          reject-reason option, requirement that the receiving server SHOULD report never block the error code.
          If a message option appears a sending
   server SHOULD display the string from sending CONTACT messages.

   In order to meet this requirement, each server tells the message option in a user visible way.  The other server
          MUST close
   the connection if a reject-reason option appears.

      3.  Check to see if the xid on the CONNECTACK matches an outstand-
          ing CONNECT message on this TCP connection.

      4.  Check the value of the TLS-reply option, and if it was 1, then
          skip processing of the rest number of the CONNECTACK message, and
          immediately enter into TLS connection setup.

          If outstanding BNDUPD messages that it does not, a will accept.  The
   receiving server SHOULD report an error.

          This step occurs prior is required to steps 5 and 6 in order always be able to allow
          creation accept that many
   BNDUPD messages off of a secure connection (if required) prior to pro-
          cessing the protocol version connection's input queue even if it cannot
   process them immediately, and IP address information.

      5.  Examine to accept all other messages immedi-
   ately.

   Thus, the value of sending server's TCP is never blocked from sending a mes-
   sage except for very short periods, less than a few seconds unless
   the protocol-version option.  If network connection itself has problems.  In this
          server is able case, if the
   CONTACT messages don't make it to establish connections with another server
          running this protocol version, the partner then continue, else the partner will
   close the connection.

      6.  Decide if the time delta between the

   DISCUSSION:

      When implementing this capability, one needs to be careful when
      sending of the message,
          in the time field, and the receipt of any message on the message, recorded in
          step 1 above, is acceptable.  A server MAY require an arbi-
          trarily small delta in time values in order to set up a fail-
          over TCP connection with another server.

          If the delta between the time values is too great, as TCP can easily block
      the server
          should drop if the local TCP connection.

          If send buffers are full.  This can't be
      prevented because if the time mismatch receiver is not considered too great then the
          receiving server MUST record reachable (via the delta between net-
      work), the servers.
          The receiving server MUST use this delta sending TCP can't send and thus it will be unable to correct all of the
          absolute times received from
      empty the other server in local TCP send buffers.  So, all time-
          valued options.  Note that the failover protocol is con-
          structed so that two servers can be failover partners with
          arbitrarily great send operations either
      need to assume they may block for some time mismatches.

      7.  If the receiving server is a secondary server, it MUST examine or non-blocking sends
      must be used.

8.4.  Using the MCLT option TCP connection for binding data

   Binding data, in the CONNECT request and use the value form of
          the MCLT as the MCLT for this failover endpoint.

          A receiving secondary server SHOULD be able BNDUPD messages and BNDACK messages to operate with
          any MCLT
   respond to them, are sent by the primary,  but if it cannot, then it MUST
          drop across the TCP connection.

      8.  If

   In order to support timely detection of any failure in the receiving server is a secondary partner
   server, it MUST store
          the hash-bucket-assignment option for use during processing
          during NORMAL state.  If this hash bucket assignment conflicts
          with the server's configured hash bucket assignment TCP connection MUST NOT block for use in
          other more than NORMAL state, a very short
   time, on the secondary server should send order of a
          CONNECTACK with a reject reason of 19, Hash bucket assignment
          conflict.

      9.  The receiving server MAY use the vendor-class-identifier to do
          vendor specific processing.

      10. After accepting few seconds.  Therefore, a CONNECTACK message, the server that is
   sending BNDUPD messages MUST send only a
          STATE message.

          After restricted number before
   receiving a CONNECTACK message, the server MUST start
          two timers for the connection: tSend and tReceive. BNDACK messages about previous messages sent.

   The tSend
          timer SHOULD be approximately 20 percent number of the time in the
          receiver-timer option in the corresponding CONNECTACK message.
          The tReceive timer SHOULD be set outstanding BNDUPD messages that each server will
   accept without causing TCP to the time block transmission of additional data
   (i.e, CONTACT messages) is sent by each server in the
          receiver-timer option CONNECT and
   CONNECTACK messages in the CONNECT message. max-unacked-bndupd option.

8.5.  Using the TCP connection for control messages

   The tReceive timer is reset whenever a message TCP connection is received used for control messages: POOLREQ, UPDREQ,
   STATE, CONTACT, UPDREQALL and the corresponding reply messages: POOL-
   RESP, UPDDONE.  A server MUST immediately accept all of these mes-
   sages from this the TCP connection.  If it ever expires,  A server MUST immediately accept any
   BNDACK which is received as well.

8.6.  Losing the TCP connec-
          tion connection

   When the TCP connection is dropped and lost, then communications with this partner is con-
          sidered not ok.

          The tSend timer is reset whenever a message is sent over this
          connection. When it expires, a CONTACT message MUST be sent.

7.10.  STATE message

   The state (STATE) message is used to communicate ok with
   the current failover
   state other server.  A server which has lost communications SHOULD
   immediately attempt to reconnect to the partner server.

   The STATE other server, and should
   retry these connection attempts periodically.

   An acknowledgement message MUST be sent after sending a CONNECTACK (BNDACK, POOLRESP, UPDDONE) message
   that didn't contain a reject-reason option, and MUST can
   only be sent after
   receiving a CONNECTACK message without in response to a reject-reason option.

   A STATE request message MUST be sent whenever (BNDUPD, POOLREQ,
   UPDREQ, UPDREQALL) on the failover endpoint changes
   its failover state and a same TCP connection exists to the partner.

   The STATE message requires no response from which the failover partner.

7.10.1.  Sending request
   was received, in part since the STATE message

   The current failover state is placed XID's in the server-state option and request messages are
   guaranteed unique only during the current state life of a single TCP connection.

   When a connection to a partner server goes down, a server with unpro-
   cessed request messages MAY simply drop all of those messages, since
   it can be sure that the STARTUP flag is placed partner will resend them when they are next
   in the server-flags
   option.

   The message is sent with a unique xid. communications.  A server SHOULD only with unprocessed BNDUPD messages when a
   TCP connection goes down MAY instead choose to process those BNDUPD
   messages, but it MUST NOT send any BNDACK messages in response (again
   because of the STATE message either when issues surrounding XID uniqueness).

   When the connec-
   tion TCP connection is created (i.e, after sending or receiving a CONNECTACK closed explicitly, the DISCONNECT message
   with no a reject-reason option), or when there is option (and, ideally, a change from the
   values message option) MUST be
   sent in a previous STATE message.

7.10.2.  Receiving over the STATE message

   Every STATE message SHOULD indicate a change in state or TCP connection.

9.  Failover Endpoint States

   This section discusses the various states that a change failover endpoint
   may take, and the server actions required when entering the state,
   operating in the flags.

   When a STATE message state, and leaving the state, as well as the events
   that cause transitions out of the state into another state.

   The state transition diagram in Figure 9.2-1 is received, any relevant for this
   section. This is the common state transitions specified transition diagram for both servers
   in
   section 9 are taken.

   No response to a STATE message is required.

7.11.  CONTACT message

   The contact (CONTACT) message failover pair.  In the event that the textual description of a
   state differs from the state transition diagram, the textual descrip-
   tion is sent to verify be considered authoritative.

9.1.  Server Initialization

   When a server starts it starts out in STARTUP state.  See section 9.3
   below for details.

9.2.  Server State Transitions

   Whenever a server transitions into a new state, it MUST record the
   state and the time at which it entered that state in stable storage.
   If communications
   integrity with is "ok", it MUST also send a STATE message to its
   failover partner. The CONTACT message

   Figure 9.2-1 is sent when
   no messages have been sent the diagram of the server state transitions. The
   remainder of this section contains information important to the failover partner
   understanding of that diagram.

   The server stays in the current state until all of the actions speci-
   fied on the state transition are complete.  If communications fails
   during one of the actions, the server simply stays in the current
   state and attempts a transition whenever the conditions for a specified
   period transi-
   tion are later fulfilled.

   In the state transition diagram below, the "+" or "-" in the upper
   right corner of time.  This each state is determined by the tSend timer expiring (see
   section 8.3).

7.11.1.  Sending a notation about whether communication
   is ongoing with the CONTACT message other server.

   The CONTACT message legend "responsive", "balanced", or "unresponsive" in each state
   indicates whether the server is sent.

7.11.2.  Receiving responsive to all DHCP client
   requests, running in load balanced mode, or totally unresponsive in
   the CONTACT message

   When respective state.  The terms "responsive" and "unresponsive" have
   the obvious meanings, while "balanced" means that a CONTACT message is received, DHCP server may
   respond to all DHCPREQUEST messages that are RENEWAL or REBINDING,
   and to all other messages from clients for which the tReceive timer is reset (as load balancing
   algorithm indicates that it MUST respond to.  See sections 5.3 and
   9.6.2 for details on load balancing.

   In the state transition diagram below, when communication is with any message that reesta-
   blished between the two servers, each must record the state of the
   partner when communication was restored.  State transitions on one
   server in some cases imply state transitions on the partner server,
   so a record of the current state of the partner server must be kept
   by each server.

   If the state of the partner changes while communicating a server
   moves through the communications-failed transition and into whatever
   state results.  It then immediately moves through whatever state
   transition is received). appropriate given the current state of the partner
   server.  A server MAY use performing this operation SHOULD NOT close the time TCP
   connection to its partner.

   DISCUSSION:

      The point of this technique is simplicity, both in explanation of
      the time field protocol and in its implementation.  The alternative to this
      technique of memory of partner state and automatic state transi-
      tion on change of partner state is to have every state in the time fol-
      lowing diagram have a state transition for every possible state of
      the partner.  With the approach adopted, only the states in which
      communications are reestablished require a state transition for
      each possible partner state.

   The current state of a server MUST be recorded
   above in stable storage and
   thus be available to refine the delta time calculations between the servers.

7.12.  DISCONNECT message server after a server restart.

        +---------------+  V  +--------------+
        |    RECOVER  - |  |  |   STARTUP  - |
        |(unresponsive) |  +->|(unresponsive)|
        +---------------+     +--------------+
           Comm. OK            +-----------------+
          Other State:-RECOVER |  PARTNER DOWN - |<-----------------+
          |      |             | (responsive)    |                  |
         All   POTENTIAL-      +-----------------+ +--------------+ |
       Others  CONFLICT------------ | --------+    |  RESOLUTION -| |
          |                     Comm. OK      |    |  INTERRUPTED | |
         UPDREQ(ALL)          Other State:    |  +-| (responsive) | |
       Wait UPDDONE            |        |     |  | +--------------+ |
     Wait MCLT from fail   RECOVER  All Others| Comm. OK  ^     |   |
      +--------------+         |        V     V  V        |    Ext. |
      |RECOVER-DONE +|      +--+    +--------------+    Comm.  Cmd. |
      |(unresponsive)|      |       |  POTENTIAL + |    Failed  |   |
      +--------------+   Wait for +>|  CONFLICT    |------+     +-->|
         Comm. OK         Other   | |(unresponsive)|<--------+      |
     +--Other State:-+    State:  | +--------------+         |      |
     |   |           |   RECOVER  |         |                |      |
     |   All      POTENT.  DONE   | Resolve Conflict         |      |
     |  Others:  CONFLICT-- | ----+     (see 9.8)            |      |
     | Wait for             V               V                |      |
     | Other State: NORMAL +-----------------+               |      |
     |   V                 |     NORMAL    + | External      |      |
     |   +--+----------+-->|   (balanced)    |-Command---+-- | -----+
     |      ^          ^   +-----------------+           |   |
     |      |          |            |                    |   |
     |  Wait for   Comm. OK       Comm.            External  |
     |   Other      Other        Failed            Command   |
     |   State:     State:          |                or  |   |
     |RECOVER-DONE  NORMAL     Start Safe        Safe    |   |
     |      |     COMM. INT.  Period Timer       Period  |   |
     |   Comm. OK.     |            V            expiration  |
     |  Other State:   |  +------------------+           |   |
     |    RECOVER      +--| COMMUNICATIONS - |-----------+   |
     V      +-------------|   INTERRUPTED    |   Comm. OK    |
    RECOVER               |  (responsive)    |--Other State:-+
    RECOVER-DONE--------->+------------------+   All Others

           Figure 9.2-1:  Server state diagram.

9.3.  STARTUP state

   The DISCONNECT is the last message sent over a connection before
   dropping STARTUP state affords an established connection.

   After sending or receiving a DISCONNECT message, opportunity for a server needs to
   have some mechanism to prevent an error loop. Simply reconnecting to
   the probe its
   partner immediately is not the best option, especially after
   several consecutive attempts.

   A simple suggested solution is to wait a minute or two after sending
   or receiving a DISCONNECT server, before attempting starting to reestablish communica-
   tion.

7.12.1.  Sending the DISCONNECT message

   The DISCONNECT message MUST be the last message sent by service DHCP clients.

   DISCUSSION:

      Without the STARTUP state, a server
   which is dropping would likely start in a TCP connection.

   The xid state
      derived from its previously stored state (held in stable storage),
      if any.  However, this may be inconsistent with the current state
      of the DISCONNECT message must be unique. partner.  The reject-reason option MUST appear giving a reason why the connec-
   tion was dropped.  A message option SHOULD appear giving a human
   readable error message with possibly more details.

7.12.2.  Receiving STARTUP state affords the DISCONNECT message

   When opportunity for a
      server receives a DISCONNECT message it should log to potentially learn the message
   if there was one partner's state and possibly raise an alarm of some sort determine if
      that state is consistent with its derived starting state or
      whether some significant state change has occurred at the
   reject reason was one partner
      that was sufficiently serious.

8.  Connection Management

   Servers participating in forces the failover protocol communicate over TCP
   connections.   These TCP connections are used both to transmit bind-
   ing information from one server to start in another as well as to allow each
   server to determine whether communications state.  This is possible with
      especially critical if significant time has elapsed while the other
   server.

   Central
      server was down.

9.3.1.  Operation while in STARTUP state

   Whenever a server is in STARTUP state, it MUST be unresponsive to
   DHCP client requests, and so the operation of time spent in the failover protocol STARTUP state is
   necessarily short, typically on the order of a notion few seconds to a few
   tens of
   "communications okay" or "communications failed".  Failover state
   transitions are taken seconds.  The exact time spent in many cases when the status of communications
   with STARTUP state is imple-
   mentation dependent, and the partner changes, primary and secondary server are not
   required to spend the existence or non-existence same amount of time in the STARTUP state.

   Whenever a TCP
   connections between failover endpoints STATE message is used sent to determine if com-
   munications is "okay" or "failed".

   A single TCP connection exists which connects two failover endpoints.

8.1.  Connection granularity

   There exists one TCP connection between each set of failover end-
   points.  See section 5.1.1 for an explanation of failover endpoint.

   There are a maximum of two TCP connections between any two servers
   implementing the failover protocol, one for each of the possible
   failover endpoints between these two servers.  There is a minimum of
   one TCP connection between one server and every other failover server
   with which it implements partner while in STARTUP
   state the failover protocol.

8.2.  Creating STARTUP bit MUST be set in the TCP connection

   Every server implementing server-flags option and the
   previously recorded failover protocol state MUST listen on port
   647 for incoming failover TCP connections.  The source port of be placed in the
   TCP connection is unimportant.

   Every server-state
   option.

9.3.2.  Transition out of STARTUP state

   Each server implementing starts out in startup state every time it initializes
   itself, and performs the failover protocol SHOULD attempt to
   connect to all following algorithm as part of its partners periodically, where the period is
   implementation dependent and SHOULD be configurable. In the event
   that a connection has been rejected by a CONNECTACK message with a
   reject-reason option contained initiali-
   zation:

      1.  Is there any record in it or a DISCONNECT message, stable storage of a
   server SHOULD r educe previous failover
          state?  If yes, set previous-state to the frequency last recorded state
          in stable storage, and continue with which it attempts to connect
   to step 2.

          Is there any configuration information that indicates that
          this server was previously running but lost its stable
          storage?  Such information must typically come from some
          administrative intervention, since it SHOULD continue to attempt to connect periodi-
   cally.

   Once a connection is established, the primary server MUST send difficult for a CON-
   NECT message across the connection.  A secondary
          server MUST wait for
   the CONNECT message to distinguish first startup from a primary server.

   Every CONNECT message includes a TLS-request option, and if the CON-
   NECTACK message does not reject startup after it
          has lost its stable storage.  If yes, then set the CONNECT message previous-
          state to RECOVER, and set the TLS-reply
   option says TLS MUST time-of-failure to whatever time
          was configured, and go on to step 2.  This time-of-failure
          will be used, then used in the servers will immediately enter transition out of the RECOVER state into TLS negotiation.

   Once TLS negotiation
          the RECOVER-DONE state, below.

          If there is complete, no record of any previous failover state in stable
          storage nor of any previous operational activity for this
          server, then set the previous-state to PARTNER-DOWN if this
          server is a primary and RECOVER if this server MUST resend is a secondary,
          and set the
   CONNECT message on time-of-failure to a time before the newly secured TLS connection and then wait for maximum-
          client-lead-time before now.  If using standard Posix times, 0
          would typically do quite well.

      2.  Is the CONNECTACK message in response.  The TLS-request and TLS-reply
   options MUST have previous-state NORMAL?  If yes, set the same values in this second CONNECT and CONNEC-
   TACK message as they had in previous-state
          to COMMUNICATIONS-INTERRUPTED.

      3.  Start the first messages. STARTUP state timer.  The second message sent over a new connection (either a bare TCP con-
   nection or a connection utilizing TLS) is time that a STATE message.  Upon the
   receipt of this message, server remains
          in the receiver can consider STARTUP state (absent any communications up.

   It with its
          partner) is entirely possible that two servers will attempt to make connec-
   tions to each other essentially simultaneously, implementation dependent and in this case the
   secondary server will SHOULD be waiting configur-
          able.  It SHOULD be long enough to for a CONNECT message on each con-
   nection.  The primary server MUST send a CONNECT message over one TCP connection and it MUST close the other connection.

   A secondary server MUST NOT respond to the closing of be
          created to a TCP connec-
   tion with heavily loaded partner across a blind attempt slow network.

      4.  Attempt to reconnect -- there may be another create a TCP connection to the same failover partner already partner.
          See section 8.2.

      5.  Wait for "communications okay", i.e., the process discussed in use.

8.3.  Using
          section 8.2 "Creating the TCP connection for determining communications status

   The TCP connection is used Connection", to determine complete,
          including the communications status receipt of
   the other server, i.e., communications-ok, or communications-
   interrupted.

   Three things must happen for a server to consider that STATE message from the partner.

          When and if communications
   are ok with respect to another server:

      1.  A TCP connection must be established to become "okay", clear the other server.

      2.  A CONNECT message must be received STARTUP
          flag, and a CONNECTACK message
          sent in response.  The CONNECT message is used set the current state to determine the identify of previous-state.

          If the failover endpoint of partner is in PARTNER-DOWN state, and if the other end of time at
          which it entered PARTNER-DOWN state (as received in the
          TCP connection -- without it,
          start-time-of-state option in the failover endpoint cannot be
          uniquely determined.  Without knowledge of STATE message) is later than
          the failover end-
          point, last recorded time of operation of this server, then set
          the entity with current state to RECOVER.  If the time at which communications is ok it entered
          PARTNER-DOWN state is
          undetermined.

      3.  A STATE message must be received from the other server over
          the connection.  This STATE message initializes important
          information necessary to earlier than the last recorded time of
          operation of this server, then set the current state machine to
          POTENTIAL-CONFLICT.

          Then, transition to the governs current state and take the behavior "communica-
          tions okay" state transition based on the current state of
          this failover endpoint.

   There are two ways that a server can determine that communications
   has failed:

      1. and the partner.

      7.  If the startup time expires, take an implementation dependent
          action:  The TCP connection can server MAY go down, yielding an error when
          attempting to send or receive a message. This will happen at
          least as often as the period of previous-state, or the tSend timer.

      2.  The tReceive timer can expire.

   In either of these cases, communications is considered interrupted.

   Several difficulties arise when trying
          server MAY wait.

          Reasons to use one TCP connection for
   both bulk data transfer as well as go to sense previous-state and begin processing:

          If the communications status
   of current server is the other server.   One aspect of only operational server, then if
          it waits, there will be no operational DHCP servers.  This
          situation could occur very easily where one server fails and
          then the problem stems from other crashes and reboots.  If the dif-
   ferent requirements of both uses.  The bulk data transfer is of
   course critically important to rebooting server
          doesn't start processing DHCP client requests without first
          being in communication with the protocol, but other server, then the speed with which
   it is processed level
          of DHCP redundancy is not terribly significant.  It might well be
   minutes before a BNDUPD message particularly high.  This is processed, and while not optimal,
   such an occasional delay doesn't compromise
          appropriate approach if the correctness possibility of partition is low,
          or if the
   protocol. However, safe period expiration time is well beyond the time
          at which an operator would notice and react to a partition
          situation.  It is also quite appropriate if the speed with which one server detects safe period
          will never expire.

          Reasons to wait:

          If the other current server has been down for longer than the
          maximum-client-lead-time, and it is up (or, more importantly, down) is more highly constrained.
   Generally one server should be able to detect that partitioned from the other server
   is not communicating within a minute or less.

   These differing time constraints makes
          server, then when it difficult returns it will attempt to use the same
   TCP connection for data transfer as well as to sense communications
   integrity.   See section 3.5 for additional details on TCP.

   The solution its own
          available addresses to this problem is allocate to require that some message new DHCP clients, and the
          other server may well be
   received by each end in PARTNER-DOWN state and may have
          already allocated some of those available addresses to DHCP
          clients.  In cases where the possibility of partition is high,
          and the connection within a limited safe period expiration time or that
   the connection will be considered down.  If no messages have been
   sent recently, then a CONTACT message is sent.

   In less than the case where there likely
          operator reaction time, this is no data queued a good approach to be sent, this use.

9.4.  PARTNER-DOWN state

   PARTNER-DOWN state is not a
   problem, but state either server can enter.  When in this
   state, the case where there is data queued to be sent to the
   partner, then the CONTACT message will server does not actually be transmitted
   until the queued data is sent.  Section 3.5 explains why waiting for
   TCP to determine assume that the connection is down is not acceptable, other server could still
   be operating and
   leads servicing a requirement different set of clients, but instead
   assumes that it is the receiving server never block the sending only server from sending CONTACT messages.

   In order to meet this requirement, each operating. If one server tells is in
   PARTNER-DOWN state, the other server
   the number of outstanding BNDUPD messages that it will accept. MUST NOT be operating.

9.4.1.  Upon entry to PARTNER-DOWN state

   No special actions are required when entering PARTNER-DOWN state.

   The
   receiving server is required should continue to always be able attempt to connect to accept that many
   BNDUPD messages off of the connection's input queue even if it cannot
   process them immediately, and partner
   periodically.

9.4.2.  Operation while in PARTNER-DOWN state

   A server in PARTNER-DOWN state MUST respond to accept DHCP client requests.
   It will allow renewal of all other messages immedi-
   ately.

   Thus, the sending server's TCP is never blocked outstanding leases on IP addresses, and
   will allocate IP addresses from sending a mes-
   sage except for very short periods, less than its own pool, and after a few seconds unless fixed
   period of time (the MCLT interval) has elapsed from entry into
   PARTNER-DOWN state, it will allocate IP addresses from the network connection itself set of all
   available IP addresses.

   Once a server has problems.  In this case, if entered NORMAL state, the
   CONTACT messages don't make it to PARTNER-DOWN state is
   entered only on command of an external agency (typically an adminis-
   trator of some sort) or after the partner then expiration of an externally config-
   ured minimum safe-time after the partner will
   close beginning of COMMUNICATIONS-
   INTERRUPTED state.

   Any available IP address tagged as available for allocation by the connection.

   DISCUSSION:

      When implementing this capability, one needs
   other server (at entry to PARTNER-DOWN state) MUST NOT be careful when
      sending any message on allocated
   to a new client until the TCP connection as TCP can easily block maximum-client-lead-time beyond the entry
   into PARTNER-DOWN state has elapsed.

   A server if in PARTNER-DOWN state MUST NOT allocate an IP address to a
   DHCP client different from that to which it was allocated at the local TCP send buffers are full.  This can't be
      prevented because if
   entrance to PARTNER-DOWN state until the receiver is not reachable (via maximum-client-lead-time
   beyond the net-
      work), maximum of the sending TCP can't send following times: client expiration time,
   most recently transmitted potential-expiration-time, most recently
   received ack of potential-expiration-time from the partner, and thus it will be unable most
   recently acked potential-expiration-time to
      empty the local TCP send buffers.  So, all send operations either
      need to assume they may block partner.  See section
   7.1.5 for some details.  If this time or non-blocking sends
      must would be used.

8.4.  Using earlier than the TCP connection for binding data

   Binding data, in current
   time plus the form of BNDUPD messages and BNDACK messages to
   respond to them, are sent across maximum-client-lead-time, then the TCP connection.

   In order to support timely detection of any failure in time the partner
   server, server
   entered PARTNER-DOWN state plus the TCP connection MUST NOT block maximum-client-lead-time is used.

   Two options exist for more than a very short
   time, on lease times given out while in PARTNER-DOWN
   state, with different ramifications flowing from each.

   If the order of a few seconds.  Therefore, a server that is
   sending BNDUPD messages MUST send only a restricted number before
   receiving BNDACK messages about previous messages sent.

   The number of outstanding BNDUPD messages that each server will
   accept without causing TCP wishes the Failover protocol to block transmission protect it from loss of additional data
   (i.e, CONTACT messages) is sent by each server
   stable storage in PARTNER-DOWN state, then it should ensure that the CONNECT and
   CONNECTACK messages
   MCLT based lease time restrictions in Section 5.1 are maintained,
   even in PARTNER-DOWN state.

   If the max-unacked-bndupd option.

8.5.  Using the TCP connection for control messages

   The TCP connection is used for control messages: POOLREQ, UPDREQ,
   STATE, CONTACT, UPDREQALL and the corresponding reply messages: POOL-
   RESP, UPDDONE.  A server MUST immediately accept all of these mes-
   sages from wishes to forego the TCP connection.  A server MUST immediately accept any
   BNDACK which is received as well.

8.6.  Losing protection of the TCP connection

   When Failover proto-
   col in the TCP connection is lost, event of loss of stable storage, then communications is not ok with
   the other server. it need recognize no
   restrictions on actual client lease times while in PARTNER-DOWN
   state.

   A server which has lost communications SHOULD
   immediately in PARTNER-DOWN state MUST continue to attempt to reconnect establish
   communications and synchronization with its partner.

9.4.3.  Transitions out of PARTNER-DOWN state

   When a server in PARTNER-DOWN state succeeds in establishing a con-
   nection to its partner, its actions are conditional on the other server, state and should
   retry these connection attempts periodically.

   A BNDACK message can only be sent
   flags received in response to a BNDUPD message
   using the same TCP connection STATE message from which the BNDUPD message was
   received, since other server as part of
   the process of establishing the connection.

   If the XID's STARTUP bit is set in BNDUPD messages are guaranteed unique
   only during the life server-flags option of a single TCP connection.  When a connection
   to a partner server goes down, received
   STATE message, a server with unprocessed BNDUPD mes-
   sages MAY simply drop all of those messages, since it can be sure
   that the partner will retransmit them when they are next in communi-
   cations.  A server with unprocessed BNDUPD messages when a TCP con-
   nection goes down MAY instead choose to process those BNDUPD mes-
   sages, but it PARTNER-DOWN state MUST NOT send take any BNDACK state
   transitions based on reestablishing communications. Essentially, if a
   server is in PARTNER-DOWN state, it ignores all STATE messages from
   its partner that have the STARTUP bit set in response (again
   because the server-flags option
   of the issues surrounding XID uniqueness).

   When STATE message.

   If the TCP connection STARTUP bit is closed explicitly, not set in the DISCONNECT message
   with a reject-reason server-flags option (and, ideally, of a STATE
   message option) MUST be
   sent over the TCP connection.

9.  Protocol States

   This section discusses the various states that received from its partner, then a failover endpoint
   may take, and the server actions required when entering the state,
   operating in PARTNER-DOWN
   state takes the state, and leaving the state, as well as following actions based on the events
   that cause transitions out value of the server-
   state into another state.

   The state transition diagram option in Figure 9.2-1 is relevant for this
   section. This is the common received STATE message:

      o partner in NORMAL, COMMUNICATIONS-INTERRUPTED, PARTNER-DOWN or
        POTENTIAL-CONFLICT state

        transition diagram for both servers to POTENTIAL-CONFLICT state

      o partner in a failover pair.  In the event that the textual description of a RECOVER state differs from the

        stay in PARTNER-DOWN state

      o partner in RECOVER-DONE state

        transition diagram, into NORMAL state

9.5.  RECOVER state

   This state indicates that the textual descrip-
   tion is to be considered authoritative.

9.1.  Server Initialization

   When a server starts it starts out has no information in STARTUP state.  See section 9.4
   below for details.

9.2.  Server State Transitions

   Whenever its stable
   storage or that it is re-integrating with a server transitions into a new state, it MUST record the in PARTNER-DOWN
   state and the time at which after it entered that state has been down.  A server in stable storage.
   If communications is "ok", it this state MUST also send a STATE message attempt to
   refresh its
   failover partner.

   Figure 9.2-1 is the diagram of stable storage from the server other server.

9.5.1.  Operation in RECOVER state transitions. The
   remainder of this section contains information important

   A server in RECOVER MUST NOT respond to the
   understanding of that diagram.

   The DHCP client requests.

   A server stays in the current RECOVER state until all of the actions speci-
   fied on will attempt to reestablish communications
   with the other server.

9.5.2.  Transitions out of RECOVER state transition are complete.

   If communications fails
   during one of the actions, the other server simply stays is in the current POTENTIAL-CONFLICT state and attempts a transition whenever the conditions for a transi-
   tion when communica-
   tions are later fulfilled.

   In the state transition diagram below, reestablished, then the "+" or "-" server in the upper
   right corner of each RECOVER state is a notation about whether communication
   is ongoing with the other server.

   The legend "responsive", "balanced", or "unresponsive" in each will move
   to POTENTIAL-CONFLICT state
   indicates whether itself.

   If the other server is responsive to all DHCP client
   requests, running in load balanced mode, or totally unresponsive RECOVER state, then this server SHOULD sig-
   nal an error and halt processing.

   If the other server is in any other state, then the respective state.  The terms "responsive" and "unresponsive" have server in RECOVER
   state will request an update of missing binding information by send-
   ing an UPDREQ message.  If the obvious meanings, while "balanced" means that a DHCP server may
   respond to all DHCPREQUEST messages that are RENEWAL has been instructed (through
   configuration or REBINDING,
   and to all other messages external agency) that it has lost its stable
   storage, or if it has deduced that from clients for which the load balancing
   algorithm indicates fact that it MUST respond to.  See sections 5.3 and
   9.6.2 for details on load balancing.

   In the state transition diagram below, when communication is reesta-
   blished between the two servers, each must has no
   record the state of the
   partner when communication was restored.  State transitions on one
   server in some cases imply state transitions on the ever having talked to its partner, while its partner server,
   so does
   have a record of the current state 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 start a timer whose expiration is set to a time equal to the
   time the partner server must be kept
   by each server.

   If went down (if known) or the state of current time (if the partner changes while communicating a server
   moves through
   down-time is unknown) plus the communications-failed maximum-client-lead-time.  When this
   timer goes off, the server will transition and into whatever
   state results.  It then immediately moves through whatever state
   transition RECOVER-DONE state.
   This is appropriate given the current state to allow any IP addresses that were allocated by this server
   prior to loss of its client binding information in stable storage to
   contact the partner
   server.  A other server performing this operation SHOULD NOT close the TCP
   connection or to its partner. time out.

   See Figure 9.5.2-1.

   DISCUSSION:

      The point of actual requirement on this technique is simplicity, both wait period in explanation of RECOVER is that it
      start when the protocol and in its implementation.  The alternative to this
      technique of memory of partner state and automatic state transi-
      tion on change of partner state recovering server went down, not necessarily when
      it came back up.  If the time when the recovering server failed is
      known, it could be communicated to have every state in the fol-
      lowing diagram have a state transition for every possible state recovering server (perhaps
      through actions of the partner.  With network administrator), and the approach adopted, only wait period
      could be reduced to the maximum-client-lead-time less the differ-
      ence between the states in which
      communications are reestablished require a state transition for
      each possible partner state.

   The current state of a server MUST be recorded in stable storage time and
   thus be available to the time the server after a server restart.

        +---------------+  V  +--------------+
        |    RECOVER  - |  |  |   STARTUP  - |
        |(unresponsive) |  +->|(unresponsive)|
        +---------------+     +--------------+
           Comm. OK            +-----------------+
          Other State:-RECOVER failed.  In
      this way, the waiting period could be minimized.

   If an UPDDONE message isn't received within an implementation depen-
   dent amount of time, and no BNDUPD message are being received, the
   connection SHOULD be dropped.

                A                                        B
              Server                                  Server

                |  PARTNER DOWN - |<-----------------+                                        |
             RECOVER                               PARTNER-DOWN
                |                                        | (responsive)
                | >--UPDREQ-------------------->         |
         All   POTENTIAL-      +-----------------+ +--------------+
                |
       Others  CONFLICT------------                                        | --------+
                |  RESOLUTION        <---------------------BNDUPD--< |
                | >--BNDACK-------------------->         |                     Comm. OK
               ...                                      ...
                |                                        |  INTERRUPTED
                |        <---------------------BNDUPD--< |
         UPDREQ(ALL)          Other State:
                |  +-| (responsive) >--BNDACK-------------------->         |
                |
       Wait UPDDONE                                        |
                |        <--------------------UPDDONE--< |
                | +--------------+                                        |
       Wait MCLT from fail   RECOVER  All Others| Comm. OK  ^     |   |
      +--------------+         |        V     V  V        |    Ext. |
      |RECOVER-DONE +|      +--+    +--------------+    Comm.  Cmd. |
      |(unresponsive)|      |       |  POTENTIAL + |    Failed  |   |
      +--------------+   Wait for +>|  CONFLICT    |------+     +-->|
         Comm. OK         Other   | |(unresponsive)|<--------+      |
     +--Other State:-+    State:  | +--------------+         |      |
     |   |           |   RECOVER  |         |                |      |
     |   All      POTENT.  DONE   | Resolve Conflict         |      |
     |  Others:  CONFLICT-- | ----+     (see 9.8) last known                         |
          time of operation                              |
                | Wait for             V               V                                        |
           RECOVER-DONE                                  |
                | Other State: NORMAL +-----------------+                                        |
                | >--STATE-(RECOVER-DONE)------>         |   V
                |                                     NORMAL    + | External      |      |
     |   +--+----------+-->|   (balanced)    |-Command---+-- | -----+
     |      ^          ^   +-----------------+           |   |
     |      |          |            |                    |   |
     |  Wait for   Comm. OK       Comm.            External  |
     |   Other      Other        Failed            Command   |
     |   State:     State:          |                or
                |        <-------------(NORMAL)-STATE--< |
     |RECOVER-DONE
             NORMAL     Start Safe        Safe    |   |
     |      |     COMM. INT.  Period Timer       Period  |   |
     |   Comm. OK.     |            V            expiration  |
     |  Other State:   |  +------------------+           |                                      |
                |    RECOVER      +--| COMMUNICATIONS - |-----------+ >---- State-(NORMAL)--------------->
                |
     V      +-------------|   INTERRUPTED                                        |   Comm. OK
                |
    RECOVER                                        |  (responsive)    |--Other State:-+
    RECOVER-DONE--------->+------------------+   All Others

              Figure 9.2-1:  Server 9.5.2-1:  Transition out of RECOVER state diagram.

9.3.  STARTUP

9.6.  NORMAL state

   The STARTUP

   NORMAL state affords an opportunity for a server to probe its
   partner server, before starting to service DHCP clients.

   DISCUSSION:

      Without is the STARTUP state, state used by a server would likely start in a state
      derived from its previously stored state (held in stable storage),
      if any.  However, this may be inconsistent when it is communicating
   with the current other server, and any required resynchronization has been
   performed. While some bindings database synchronization is performed
   in NORMAL state, potential conflicts are resolved prior to entry into
   NORMAL state
      of the partner.  The STARTUP as is binding database data loss.

9.6.1.  Upon entry to NORMAL state affords the opportunity for

   When entering NORMAL state, a server will send to potentially learn the partner's state and determine if
      that state is consistent with its derived starting state or
      whether some significant state change has occurred at the partner
      that forces the other server to start in another state.  This
   all currently unacknowledged binding updates as BNDUPD messages.

   When the above process is
      especially critical complete, if significant time has elapsed while the server was down.

9.3.1.  Operation while in STARTUP entering NORMAL
   state

   Whenever a server is in STARTUP state, a secondary server, then it MUST be unresponsive to will request IP addresses for
   allocation using the POOLREQ message.

9.6.2.  Processing DHCP client requests, requests and so the time spent in the STARTUP state is
   necessarily short, typically on the order of a few seconds to load balancing

   In NORMAL state, a few
   tens of seconds.  The exact time spent server MUST process every DHCPREQUEST/RENEWAL or
   DHCPREQUEST/REBINDING request it receives. And, it processes other
   requests only for those clients as dictated by the load balancing
   algorithm specified in [LOADB].

   As discussed in section 5.3, each server will take the STARTUP state is imple-
   mentation dependent, and client-
   identifier from each DHCP client request (or the primary and secondary server are not
   required client-hardware-
   address, i.e., the htype concatenated to spend the same amount front of time in the STARTUP state.

   Whenever a STATE message chaddr if
   no client-identifier is sent to the partner while present in STARTUP
   state the STARTUP bit MUST be set request) and use it as the
   'Request ID' specified in [LOADB].  After applying the server-flags option algorithm
   specified in [LOADB] and comparing the
   previously recorded result with the hash bucket
   assignment (performed during connect processing between failover state MUST
   servers), each failover server will be placed in able to unambiguously deter-
   mine if it should processes the server-state
   option.

9.3.2.  Transition out of STARTUP state

   Each DHCP client request.

   In NORMAL state, a server starts out in startup state MUST process every time DHCPREQUEST/RENEWAL or
   DHCPREQUEST/REBINDING request it initializes
   itself, and performs the following algorithm as part of its initiali-
   zation:

      1.  Is there any record receives.

9.6.3.  Operation in stable storage of a previous failover
          state?  If yes, set previous-state to the last recorded NORMAL state

   When in stable storage, and continue with step 2.

          Is there any configuration information that indicates NORMAL state, for every DHCP client request that
          this server was previously running but lost its stable
          storage?  Such information must typically come from some
          administrative intervention, since it is difficult for
   processes, as determined by the algorithm described in section 9.6.2,
   above, a server to distinguish first startup from a startup after it
          has lost its stable storage.  If yes, then set the previous-
          state to RECOVER, and set will operate in the time-of-failure to whatever following manner:

      o Lease time
          was configured, and go on calculations
        As discussed in section 5.2.1, "Control of lease time", the
        lease interval given to step 2.  This time-of-failure
          will a DHCP client can never be used in more than the transition out of
        MCLT greater than the RECOVER state into most recently received potential-
        expiration-time from the RECOVER-DONE state, below.

          If there is no record of any previous failover state in stable
          storage nor of any previous operational activity for this
          server, then set partner or the previous-state to PARTNER-DOWN if this
          server current time,
        whichever is later.

        As long as a primary and RECOVER if this server is a secondary,
          and set adheres to this constraint, the time-of-failure specifics of
        the lease interval that it gives to a time before the maximum-
          client-lead-time before now.  If using standard Posix times, 0
          would typically do quite well.

      2.  Is DHCP client or the previous-state NORMAL?  If yes, set value
        of the previous-state potential-expiration-time sent to COMMUNICATIONS-INTERRUPTED.

      3.  Start the STARTUP state timer.  The time its failover partner
        are implementation dependent.  One possible approach is dis-
        cussed in section 5.2.1, but that a server remains particular approach is in no
        way required by this protocol.

        See section 7.1.5 for details concerning the STARTUP state (absent any communications with its
          partner) is implementation dependent storage of time
        associated IP addresses and SHOULD be configur-
          able.  It SHOULD be long enough how to use these times when calcu-
        lating lease times for a TCP connection to be
          created to a heavily loaded DHCP clients.

      o Lazy update of partner across server

        After an ACK of a slow network.

      4.  Attempt to create IP address binding, the server servicing a TCP connection
        DHCP client request attempts to update its partner with the failover partner.
          See section 8.2.

      5.  Wait for "communications okay", i.e., the process discussed new
        binding information.  The lease time used in
          section 8.2 "Creating the TCP Connection", to complete,
          including the receipt update of a STATE message from the partner.

          When and if communications become "okay", clear the STARTUP
          flag, and set the current state
        secondary MUST be at that given to the previous-state.

          If the partner is DHCP client in PARTNER-DOWN state, the
        DHCPACK, and if the time potential-expiration-time MUST be at
          which it entered PARTNER-DOWN state (as received in the
          start-time-of-state option in the STATE message) is later than least the last recorded time of operation
        lease time, and SHOULD be considerably longer.

      o Reallocation of this server, then set
          the current state IP addresses between clients

        Whenever a client binding is released or expires, a BNDUPD mes-
        sage must be sent to RECOVER.  If partner, setting the time at which it entered
          PARTNER-DOWN binding state to
        RELEASED or EXPIRED.  However, until a BNDACK is earlier than the last recorded time of
          operation of received for
        this server, then set message, the current state IP address cannot be allocated to
          POTENTIAL-CONFLICT.

          Then, transition another
        client.  It can be allocated to the current state and take the "communica-
          tions okay" state transition based on the current state of
          this same client again.

   In normal state, each server and the partner.

      7.  If the startup time expires, take an implementation dependent
          action:  The receives binding updates from its
   partner server MAY go in BNDUPD messages.  It records these in its client
   binding database in stable storage and then sends a corresponding
   BNDACK message to the previous-state, or primary server.  It MUST ensure that the
          server MAY wait.

          Reasons infor-
   mation is recorded in stable storage prior to go sending the BNDACK mes-
   sage back to previous-state and begin processing:

          If the current primary server.

9.6.4.  Transitions out of NORMAL state

   If an external command is received by a server in NORMAL state
   informing it that its partner is the only operational server, down, then if
          it waits, there will transition into PARTNER-
   DOWN state.  Generally, this would be no operational DHCP servers.  This
          situation could occur very easily an unusual situation, where one
   some external agency new the partner server fails and
          then was down.  Using the other crashes
   command in this case would be appropriate if the polling interval and reboots.
   timeout were long.

   If the rebooting a server
          doesn't start processing DHCP client requests without first
          being in communication with the other server, then the level NORMAL state fails to receive acks to messages sent to
   its partner for an implementation dependent period of DHCP redundancy is not particularly high. time, it MAY
   move into COMMUNICATIONS-INTERRUPTED state.  This is an
          appropriate approach situation might
   occur if the possibility partner server was capable of partition is low,
          or if maintaining the safe period expiration time is well beyond TCP con-
   nection between the time
          at which an operator would notice server and react to a partition
          situation.  It is also quite appropriate if capable of sending a CONTACT mes-
   sage every tSend seconds, but was (for some reason) incapable of pro-
   cessing BNDUPD messages.

   If the safe period
          will never expire.

          Reasons communications is determined to wait: not be "ok" (as defined in
   section 8), then transition into COMMUNICATIONS-INTERRUPTED state.

   If the current a server has been down for longer than in NORMAL state receives any messages from its partner
   where the
          maximum-client-lead-time, and it is partitioned partner has changed state from that expected by the other
          server, server
   in NORMAL state, then when it returns the server should transition into
   COMMUNICATIONS-INTERRUPTED state and take the appropriate state tran-
   sition from there.  For example, it will attempt would be expected for the partner
   to use its own
          available addresses transition from POTENTIAL-CONFLICT into NORMAL state, but not for
   the partner to allocate transition from NORMAL into POTENTIAL-CONFLICT state.

9.7.  COMMUNICATIONS-INTERRUPTED State

   A server goes into COMMUNICATIONS-INTERRUPTED state whenever it is
   unable to new DHCP clients, and communicate with the other server may well be in PARTNER-DOWN state server.  Primary and may have
          already allocated some of those available addresses to DHCP
          clients.  In cases where secondary
   servers cycle automatically (without administrative intervention)
   between NORMAL and COMMUNICATIONS-INTERRUPTED state as the possibility of partition is high, network
   connection between them fails and recovers, or as the safe period expiration time is less than partner server
   cycles between operational and non-operational.  No duplicate IP
   address allocation can occur while the likely
          operator reaction time, this is a good approach servers cycle between these
   states.

9.7.1.  Upon entry to use.

9.4.  PARTNER-DOWN state

   PARTNER-DOWN COMMUNICATIONS-INTERRUPTED state is

   When a state either server can enter.  When in this enters COMMUNICATIONS-INTERRUPTED state, the server does not assume that the other server could still
   be operating if it has been
   configured to support an automatic transition out of COMMUNICATIONS-
   INTERRUPTED state and servicing into PARTNER-DOWN state (i.e., a different set "safe period"
   has been configured, see section 10), then a timer MUST be started
   for the length of clients, but instead
   assumes that it is the only server operating. If one configured safe period.

   A server is in
   PARTNER-DOWN state, transitioning into the other server MUST NOT be operating.

9.4.1.  Upon entry to PARTNER-DOWN COMMUNICATIONS-INTERRUPTED state

   No special actions are required when entering PARTNER-DOWN state.

   The server should continue to attempt from
   the NORMAL state SHOULD raise some alarm condition to connect alert adminis-
   trative staff to a potential problem in the partner
   periodically.

9.4.2. DHCP subsystem.

9.7.2.  Operation while in PARTNER-DOWN COMMUNICATIONS-INTERRUPTED State

   In this state

   A a server in PARTNER-DOWN state MUST respond to all DHCP client requests.
   It will allow renewal of all outstanding leases on IP addresses, requests, and
   will allocate
   the algorithm for load balancing described in section 5.3 MUST NOT be
   used.  When allocating new IP addresses addresses, each server allocates from
   its own pool, and after a fixed
   period of time (the MCLT interval) has elapsed from entry into
   PARTNER-DOWN state, it will allocate IP addresses from the set of all
   available IP addresses.

   Once a server has entered NORMAL state, the PARTNER-DOWN state is
   entered only on command of an external agency (typically an adminis-
   trator of some sort) or after the expiration of an externally config-
   ured minimum safe-time after the beginning of COMMUNICATIONS-
   INTERRUPTED state.

   Any available IP address tagged as belonging to pool, where the other server (at
   entry to PARTNER-DOWN state) primary MUST NOT be used until the maximum-
   client-lead-time beyond allocate only FREE IP
   addresses, and the entry into PARTNER-DOWN state has
   elapsed.

   A server in PARTNER-DOWN state secondary MUST NOT allocate an only BACKUP IP address addresses.
   When responding to renewal requests, each server will allow continued
   renewal of a DHCP client different from client's current lease on an IP address irrespec-
   tive of whether that to which it lease was allocated at given out by the
   entrance to PARTNER-DOWN state until receiving server or
   not, although the maximum-client-lead-time
   beyond renewal period MUST not exceed the maximum of the following times: client expiration time,
   most recently transmitted potential-expiration-time, most recently
   received ack of potential-expiration-time from the partner, and most
   recently acked potential-expiration-time to the partner.  See section
   7.1.4 for details.  If this time would be earlier than the current
   lead time plus the maximum-client-lead-time, then (MCLT) beyond the time potential-expiration-time already ack-
   nowledged by the other server
   entered PARTNER-DOWN state plus or the maximum-client-lead-time is used.

   Two options exist for lease times given out while in PARTNER-DOWN
   state, with different ramifications flowing lease-expiration-time or
   potential-expiration-time received from each.

   If the server wishes partner server.

   However, since the Failover protocol to protect it from loss of
   stable storage server cannot communicate with its partner in PARTNER-DOWN this
   state, then it should ensure that the
   MCLT based lease acknowledged-potential-expiration time restrictions in Section 5.1 are maintained,
   even will not be updated
   in PARTNER-DOWN state.

   If any new bindings.  This is likely to eventually cause the server wishes actual-
   client-lease-times to forego be the protection of current time plus the Failover proto-
   col in maximum-client-
   lead-time (unless this is greater than the event of loss of stable storage, then it need recognize no
   restrictions on actual client lease times while in PARTNER-DOWN
   state.

   A server in PARTNER-DOWN state MUST continue to attempt to establish
   communications and synchronization with its partner.

9.4.3.  Transitions desired-client-lease-
   time).

9.7.3.  Transition out of PARTNER-DOWN state

   When COMMUNICATIONS-INTERRUPTED State

   If the safe period timer expires while a server is in PARTNER-DOWN state succeeds in establishing a con-
   nection 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.
   COMMUNICATIONS-INTERRUPTED state, it will transition immediately into
   PARTNER-DOWN state.

   If the STARTUP bit an external command is set in the server-flags option of a received
   STATE message, by a server in PARTNER-DOWN state MUST NOT take any COMMUNICATIONS-
   INTERRUPTED state
   transitions based on reestablishing communications. Essentially, if a
   server is in PARTNER-DOWN state, informing it ignores all STATE messages from that its partner that have the STARTUP bit set in the server-flags option
   of the STATE message. is down, it will
   transition immediately into PARTNER-DOWN state.

   If the STARTUP bit communications is not set in restored with the server-flags option of a STATE
   message received from its partner, other server, then a the server
   in PARTNER-DOWN COMMUNICATIONS-INTERRUPTED state will transition into another
   state takes the following actions based on the value state of the server- partner:

      o partner in NORMAL or COMMUNICATIONS-INTERRUPTED

        The partner SHOULD NOT be in NORMAL state option here, since upon res-
        toration of communications it MUST have created a new TCP con-
        nection which would have forced it into COMMUNICATIONS-
        INTERRUPTED state.  Still, we should account for every state
        just in case.

        Transition into the received STATE message: NORMAL state.

      o partner in RECOVER
        Stay in COMMUNICATIONS-INTERRUPTED state.

      o partner in RECOVER-DONE

        Transition into NORMAL state.

      o partner in NORMAL, COMMUNICATIONS-INTERRUPTED, PARTNER-DOWN or POTENTIAL-CONFLICT state

        transition to

        Transition into POTENTIAL-CONFLICT state state.

      o partner in RECOVER state

        stay PAUSED

        Stay in PARTNER-DOWN state COMMUNICATIONS-INTERRUPTED state.

      o partner in RECOVER-DONE state

        transition SHUTDOWN

        Transition into PARTNER-DOWN state.

   The following figure illustrates the transition from NORMAL to
   COMMUNICATIONS-INTERRUPTED state

9.5.  RECOVER 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------------------->         |
                |        <-----------------CONNECTACK--< |
                |        <-------------------STATE-----< |
                |                                     NORMAL
                | >--STATE--------------------->         |
              NORMAL                                     |
                | >--BNDUPD-------------------->         |
                |        <---------------------BNDACK--< |
                |                                        |
                |        <---------------------BNDUPD--< |
                | >------BNDACK---------------->         |
               ...                                      ...
                |                                        |
                |        <--------------------POOLREQ--< |
                | >--POOLRESP-(2)-------------->         |
                |                                        |
                | >--BNDUPD-(#1)--------------->         |
                |        <---------------------BNDACK--< |
                |                                        |
                |        <--------------------POOLREQ--< |
                | >--POOLRESP-(0)-------------->         |
                |                                        |
                | >--BNDUPD-(#2)--------------->         |
                |        <---------------------BNDACK--< |
                |                                        |

       Figure 9.7.3-1:  Transition from NORMAL to COMMUNICATIONS-
                        INTERRUPTED and back (example with 2
                        addresses allocated to secondary)

9.8.  POTENTIAL-CONFLICT state

   This state indicates that the server has no information in its stable
   storage or that it is re-integrating two servers are attempting to re-
   integrate with a server each other, but at least one of them was running in PARTNER-DOWN a
   state after it has been down.  A server in this that did not guarantee automatic reintegration would be
   possible.  In POTENTIAL-CONFLICT state will attempt to
   refresh its stable storage from the other server.

9.5.1.  Operation in RECOVER state

   A server in RECOVER MUST NOT respond to DHCP client requests.

   A server in RECOVER state will attempt to reestablish communications
   with servers may determine that
   the other server.

9.5.2.  Transitions out same IP address has been offered and accepted by two different
   DHCP clients.

   It is a goal of RECOVER state

   If this protocol to minimize the other server is in possibility that
   POTENTIAL-CONFLICT state when communica-
   tions are reestablished, then the server in RECOVER state will move is ever entered.

9.8.1.  Upon entry to POTENTIAL-CONFLICT state itself.

   If the other server is in RECOVER state, then this server SHOULD sig-
   nal an error and halt processing.

   If the other server is in any other state, then the

   When a primary server in RECOVER enters POTENTIAL-CONFLICT state will it should
   request an update of missing binding information by send-
   ing an UPDREQ message.  If the server has been instructed (through
   configuration or other external agency) that it has lost its stable
   storage, it MUST the secondary send an UPDREQALL message, otherwise it MUST send an
   UPDREQ message.

   It will wait for an UPDDONE message, and upon receipt all updates of that message which it will start a timer whose expiration is set to a time equal to the
   time the server went down (if known) or the current time (if the
   down-time is unknown) plus the maximum-client-lead-time.  When this
   timer goes off, the server will transition into RECOVER-DONE state.
   This is to allow any IP addresses that were allocated
   currently unaware by this server
   prior to loss of its client binding information in stable storage to
   contact the other server or sending an UPDREQ message to time out.

   See Figure 9.5.2-1.

   DISCUSSION:

      The actual requirement on this wait period in RECOVER is that it
      start when the recovering secondary
   server.

   A secondary server went down, not necessarily when entering POTENTIAL-CONFLICT state will wait for
   the primary to send it came back up. an UPDREQ message.

9.8.2.

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

9.8.3.  Transitions out of POTENTIAL-CONFLICT state

   If communications fails with the time when partner while in POTENTIAL-CONFLICT
   state, then the recovering server failed is
      known, will transition to RESOLUTION-INTERRUPTED
   state.

   Whenever either server receives an UPDDONE message from its partner
   while in POTENTIAL-CONFLICT state, it could be communicated MUST transition to NORMAL
   state.  This will cause the recovering primary server (perhaps
      through actions of the network administrator), and the wait period
      could be reduced to leave POTENTIAL-
   CONFLICT state prior to the maximum-client-lead-time less the differ-
      ence between secondary, since the current time primary sends an
   UPDREQ message and the time the server failed.  In
      this way, the waiting period could be minimized.

   If receives an UPDDONE message isn't received within before the secondary sends an implementation depen-
   dent amount of time, and no BNDUPD
   UPDREQ message are being received, then and receives its UPDDONE message.

   When a secondary server receives an indication that the UPDREQ(ALL) primary
   server has transitioned from POTENTIAL-CONFLICT to NORMAL state, it
   SHOULD send an UPDREQ message will be re-transmitted.

                A                                        B to the primary server.

              Primary                                Secondary
              Server                                  Server

                |                                        |
             RECOVER                               PARTNER-DOWN
         POTENTIAL-CONFLICT                    POTENTIAL-CONFLICT
                |                                        |
                | >--UPDREQ-------------------->         |
                |                                        |
                |        <---------------------BNDUPD--< |
                | >--BNDACK-------------------->         |
               ...                                      ...
                |                                        |
                |        <---------------------BNDUPD--< |
                | >--BNDACK-------------------->         |
                |                                        |
                |        <--------------------UPDDONE--< |
              NORMAL                                     |
                |
       Wait MCLT from last known >--STATE--(NORMAL)----------->         |
          time of operation
                |        <---------------------UPDREQ--< |
                |
           RECOVER-DONE                                        |
                | >--BNDUPD-------------------->         |
                | >--STATE-(RECOVER-DONE)------>        <---------------------BNDACK--< |
               ...                                      ...
                |                                     NORMAL >--BNDUPD-------------------->         |
                |        <---------------------BNDACK--< |
                |                                        |
                | >--UPDDONE------------------->         |        <-------------(NORMAL)-STATE--<
                |                                     NORMAL
                |                                        |
                |        <--------------------POOLREQ--< |
                | >------POOLRESP-(n)---------->         |
                |              addresses                 |

           Figure 9.5.2-1: 9.8.3-1:  Transition out of RECOVER state

9.6.  NORMAL POTENTIAL-CONFLICT

9.9.  RESOLUTION-INTERRUPTED state

   NORMAL

   This state is indicates that the state used by a server when it is communicating two servers were attempting to re-
   integrate with the each other server, and any required resynchronization has been
   performed. While some bindings database synchronization is performed in NORMAL POTENTIAL-CONFLICT state, potential conflicts are resolved but
   communications failed prior to entry into
   NORMAL state as is binding database data loss.

9.6.1. completion of re-integration.

   If the servers remained in POTENTIAL-CONFLICT while communications
   was interrupted, neither server would be responsive to DHCP client
   requests, and if one server had crashed, then there might be no
   server able to process DHCP requests.

9.9.1.  Upon Entry entry to NORMAL RESOLUTION-INTERRUPTED state

   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 enters RESOLUTION-INTERRUPTED state is a secondary server, then it will request IP addresses for
   allocation using SHOULD raise an
   alarm condition to alert administrative staff of a problem in the POOLREQ message.

9.6.2.  Processing
   DHCP client requests and load balancing

   When subsystem.

9.9.2.  Operation in NORMAL state, each RESOLUTION-INTERRUPTED state

   In this state a server MUST process respond to all requests from some DHCP clients, client requests, and MUST NOT process
   any request other than a
   DHCPREQUEST/RENEWAL or a DHCPREQUEST/REBINDING request from some
   other DHCP clients.

   However, if the load balancing algorithm specified (described in [LOADB] is used
   with a pair of servers implementing the failover protocol, then section 5.3) MUST NOT be used.  When
   allocating new IP addresses, each server needs SHOULD allocate from its own
   IP address pool (if that can be determined), where the primary SHOULD
   allocate only FREE IP addresses, and the secondary SHOULD allocate
   only BACKUP IP addresses.  When responding to test renewal requests, each incoming
   server will allow continued renewal of a DHCP client request to see if it
   should process client's current lease
   on an IP address irrespective of whether that request.

   As discussed in section 5.3, each lease was given out by
   the receiving server will take or not, although the client-
   identifier from each DHCP client request (or renewal period MUST not
   exceed the client-hardware-
   address, i.e., maximum client lead time (MCLT) beyond the htype concatenated to potential-
   expiration-time already acknowledged by the front of other server or the chaddr if
   no client-identifier is present in
   lease-expiration-time or potential-expiration-time received from the request) and use it as
   partner server.

   However, since the
   'Request ID' specified server cannot communicate with its partner in [LOADB].  After applying this
   state, the algorithm
   specified acknowledged-potential-expiration time will not be updated
   in [LOADB] and comparing the result any new bindings.

9.9.3.  Transitions out of RESOLUTION-INTERRUPTED state

   If an external command is received by a server in RESOLUTION-
   INTERRUPTED state informing it that its partner is down, it will
   transition immediately into PARTNER-DOWN state.

   If communications is restored with the hash bucket
   assignment (performed during connect processing between failover
   servers), each failover other server, then the server
   in RESOLUTION-INTERRUPTED state will be able transition into POTENTIAL-
   CONFLICT state.

9.10.  RECOVER-DONE state

   This state exists to unambiguously deter-
   mine if it should processes the DHCP client request.

   In allow an interlocked transition for one server
   from RECOVER state and another server from PARTNER-DOWN or
   COMMUNICATIONS-INTERRUPTED state into NORMAL state, a state.

9.10.1.  Operation in RECOVER-DONE state

   A server in RECOVER-DONE state MUST process every respond only to
   DHCPREQUEST/RENEWAL or and DHCPREQUEST/REBINDING request it receives.

9.6.3.  Operation in NORMAL DHCP messages.

9.10.2.  Transitions out of RECOVER-DONE state

   When a server in RECOVER-DONE state determines that its partner
   server has entered NORMAL state, for every DHCP client request that then it
   processes, will transition into NORMAL
   state as determined by the algorithm described well.

   If communications fails while in section 9.6.2,
   above, RECOVER-DONE state, a server will operate in the following manner:

      o Lease time calculations

        As discussed
   stay in section 5.2.1, "Control RECOVER-DONE state.

9.11.  PAUSED state

   This state exists to allow one server to inform another that it will
   be out of lease time", the
        lease interval given service for what is predicted to a DHCP client can never be more than a relatively short
   time, and to allow the
        MCLT greater than other server to transition to COMMUNICATIONS-
   INTERRUPTED state immediately and to begin servicing all DHCP clients
   with no interruption in service to new DHCP clients.

   A server which is aware that it is shutting down temporarily SHOULD
   send a STATE message with the most recently received potential-
        expiration-time from server-state option containing PAUSED
   state and close the failover partner TCP connection.

   While a server may or may not transition internally into PAUSED
   state, the current time,
        whichever 'previous' state determined when it is later.

        As long as a server adheres to this constraint, restarted MUST be
   the specifics of state the lease interval that it gives server was in prior to a DHCP client or the value
        of receiving the potential-expiration-time sent command to its failover partner
        are implementation dependent.  One possible approach is
        discussed in section 5.2.1, but that particular approach is in
        no way required by this protocol. shut-
   down and restart and which precedes its entry into the PAUSED state.
   See section 7.1.4 for details 9.3.2 concerning the storage of time
        associated IP addresses and how to use these times when calcu-
        lating lease times for DHCP clients.

      o Lazy update of partner server

        After an ACK of a IP address binding, the previous state upon
   server servicing a
        DHCP client request attempts restart.

9.11.1.  Upon entry to update its partner with the new
        binding information.  The lease time used in the update of PAUSED state

   When entering PAUSED state, the
        secondary server MUST be at that given to store the DHCP client previous state
   in the
        DHCPACK, stable storage, and use that state as the potential-expiration-time previous state when it
   is restarted.

9.11.2.  Transitions out of PAUSED state

   A server transitions out of PAUSED state by being restarted.  At that
   time, the previous state MUST be at least the
        lease time, and SHOULD be longer.

      o Reallocation of IP addresses between clients

        Whenever a client binding is released or expires, a BNDUPD mes-
        sage must be sent state the server was in prior to partner, setting
   entering the binding PAUSED state.

9.12.  SHUTDOWN state

   This state exists to
        RELEASED or EXPIRED.  However, until a BNDACK is received for
        this message, the IP address cannot be allocated allow one server to inform another
        client.  It can that it will
   be allocated out of service for what is predicted to be a relatively long time,
   and to allow the same client again.

   In normal other server to transition immediately to PARTNER-
   DOWN state, and take over completely for the each server receives binding updates from its
   partner going down.

   A server in BNDUPD messages.  It records these in its client
   binding database in stable storage and then sends which is aware that it is shutting down SHOULD send a corresponding
   BNDACK STATE
   message to with the primary server.  It MUST ensure that server-state field containing SHUTDOWN.

   While a server may or may not transition internally into SHUTDOWN
   state, the infor-
   mation 'previous' state determined when it is recorded in stable storage restarted MUST be
   the state active prior to sending the BNDACK mes-
   sage back command to shutdown.  See section 9.3.2
   concerning the primary server.

9.6.4.  Transitions out use of NORMAL the previous state

   If an external command is received by a upon server in NORMAL restart.

9.12.1.  Upon entry to SHUTDOWN state
   informing it that its partner is down, then transition into PARTNER-
   DOWN state.

   If a

   When entering SHUTDOWN state, the server in NORMAL MUST record the previous
   state fails to receive acks to messages sent to
   its partner in stable storage for an implementation dependent period of time, it MAY
   move into COMMUNICATIONS-INTERRUPTED state.  This situation might
   occur if use when the partner server was capable of maintaining is restarted.  It
   also MUST record the TCP con-
   nection between current time as the last time operational.

   A server and also capable of sending which is aware that it is shutting down SHOULD send a CONTACT mes-
   sage every tSend seconds, but was (for some reason) incapable of pro-
   cessing BNDUPD messages.

   If STATE
   message with the communications is determined to not be "ok" (as defined server-state field containing SHUTDOWN.

9.12.2.  Operation in
   section 8), then transition into COMMUNICATIONS-INTERRUPTED state.

   If a SHUTDOWN state

   A server in NORMAL SHUTDOWN state MUST NOT respond to any DHCP client input.

   If a server receives any messages from its partner
   where message indicating that the partner has changed
   moved to PARTNER-DOWN state from that expected by the server while it is in NORMAL state, SHUTDOWN state then the server should transition into
   COMMUNICATIONS-INTERRUPTED it
   MUST record RECOVER state and take as the appropriate previous state tran-
   sition from there.  For example, it would to be expected used when it is
   restarted.

   A server SHOULD wait for a few seconds after informing the partner
   to transition from POTENTIAL-CONFLICT of
   entry into NORMAL state, but not for SHUTDOWN state (if communications are okay) to determine
   if the partner to transition from NORMAL into POTENTIAL-CONFLICT entered PARTNER-DOWN state.

9.7.  COMMUNICATIONS-INTERRUPTED State

9.12.3.  Transitions out of SHUTDOWN state

   A server goes into COMMUNICATIONS-INTERRUPTED transitions out of SHUTDOWN state whenever it is
   unable by being restarted.

10.  Safe Period

   Due to communicate with the other server.  Primary and secondary
   servers cycle automatically (without administrative intervention)
   between NORMAL and COMMUNICATIONS-INTERRUPTED state as the network
   connection between them fails and recovers, or as the partner restrictions imposed on each server
   cycles between operational and non-operational.  No duplicate IP
   address allocation can occur while the servers cycle between these
   states.

9.7.1.  Upon Entry to COMMUNICATIONS-INTERRUPTED state

   When a server enters in
   COMMUNICATIONS-INTERRUPTED state, if it has been
   configured to support an automatic transition out of COMMUNICATIONS-
   INTERRUPTED state and into PARTNER-DOWN long-term operation in this state (i.e., a "safe period"
   has been configured, see section 10), then a timer MUST be started
   is not feasible for a the length of the configured safe period.

   A server transitioning into the COMMUNICATIONS-INTERRUPTED state from either server.  One reason that these states
   exist at all, is to allow the NORMAL state SHOULD raise some alarm condition servers to alert adminis-
   trative staff easily survive transient
   network communications failures of a few minutes to a potential problem in few days
   (although the DHCP subsystem.

9.7.2.  Operation in COMMUNICATIONS-INTERRUPTED State

   In this state actual time periods will depend a server MUST respond to all great deal on the
   DHCP client requests, and activity of the algorithm for load balancing described network in section 5.3 MUST NOT be
   used.  When allocating new IP addresses, each server allocates from
   its own IP address pool, where the primary MUST allocate only FREE IP
   addresses, terms of arrival and departure of
   DHCP clients on the secondary MUST allocate only BACKUP IP addresses.
   When responding network).

   Eventually, when the servers are unable to renewal requests, each server communicate, they will allow continued
   renewal
   have to move into a state where they no longer can re-integrate
   without some possibility of a DHCP client's current lease on an duplicate IP address irrespec-
   tive of whether allocation.  There
   are two ways that lease was given out by the receiving server or
   not, although the renewal period MUST not exceed the maximum client
   lead time (MCLT) beyond the potential-expiration-time already ack-
   nowledged they can move into this state (known as PARTNER-
   DOWN).

   They can either be informed by the other server or the lease-expiration-time or
   potential-expiration-time received from external command that, indeed, the
   partner server.

   However, since the server cannot communicate with its partner in is down.  In this
   state, the acknowledged-potential-expiration time will not be updated case, there is no difficulty in any new bindings.  This mov-
   ing into the PARTNER-DOWN state since it is likely to eventually cause an accurate reflection of
   reality and the actual-
   client-lease-times protocol has been designed to be operate correctly (even
   during reintegration) as long as, when in PARTNER-DOWN state the current time plus
   partner is, indeed, down.

   The more difficult scenario is when the maximum-client-
   lead-time (unless servers are running unat-
   tended for extended periods, and in this case an option is greater than the desired-client-lease-
   time).

9.7.3.  Transition out of COMMUNICATIONS-INTERRUPTED State

   If the safe period timer expires while provided
   to configure something called a server "safe-period" into each server.  This
   OPTIONAL safe-period is in the
   COMMUNICATIONS-INTERRUPTED state, it period after which either the primary or
   secondary server will automatically transition immediately into to PARTNER-DOWN from
   COMMUNICATIONS-INTERRUPTED state.  If an external command this transition is received by a server in COMMUNICATIONS-
   INTERRUPTED state informing it that its completed
   and the partner is not down, it then the possibility of duplicate IP
   address allocations will
   transition immediately exist.

   The goal of the "safe-period" is to allow network operations staff
   some time to react to a server moving into PARTNER-DOWN COMMUNICATIONS-INTERRUPTED
   state.

   If communications  During the safe-period the only requirement is restored with that the other server, then net-
   work operations staff determine if both servers are still running --
   and if they are, to either fix the server
   in COMMUNICATIONS-INTERRUPTED state will transition into another
   state based on network communications failure
   between them, or to take one of the state servers down before the  expira-
   tion of the partner:

      o partner in NORMAL or COMMUNICATIONS-INTERRUPTED safe-period.

   The partner really SHOULD NOT be in NORMAL state here, since
        upon restoration length of communications the safe-period is MUST have created a new
        TCP connection which would have forced it into COMMUNICATIONS-
        INTERRUPTED state.  Still, we should account for every state
        just installation dependent, and depends
   in case.

        Transition into large part on the NORMAL state.

      o partner in RECOVER

        Stay in COMMUNICATIONS-INTERRUPTED state.

      o partner in RECOVER-DONE

        Transition into NORMAL state.

      o partner in PARTNER-DOWN or POTENTIAL-CONFLICT

        Transition into POTENTIAL-CONFLICT state.

      o partner in PAUSED

        Stay in COMMUNICATIONS-INTERRUPTED state.

      o partner in SHUTDOWN

        Transition into PARTNER-DOWN state.

   The following figure illustrates number of unallocated IP addresses within the transition from NORMAL to
   COMMUNICATIONS-INTERRUPTED state
   subnet address pool and then back the expected frequency of arrival of previ-
   ously unknown DHCP clients requiring IP addresses.  Many environments
   should be able 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------------------->         |
                |        <-----------------CONNECTACK--< |
                |        <-------------------STATE-----< |
                |                                     NORMAL
                | >--STATE--------------------->         |
              NORMAL                                     |
                | >--BNDUPD-------------------->         |
                |        <---------------------BNDACK--< |
                |                                        |
                |        <---------------------BNDUPD--< |
                | >------BNDACK---------------->         |
               ...                                      ...
                |                                        |
                |        <--------------------POOLREQ--< |
                | >--POOLRESP-(2)-------------->         |
                |                                        |
                | >--BNDUPD-(#1)--------------->         |
                |        <---------------------BNDACK--< |
                |                                        |
                |        <--------------------POOLREQ--< |
                | >--POOLRESP-(0)-------------->         |
                |                                        |
                | >--BNDUPD-(#2)--------------->         |
                |        <---------------------BNDACK--< |
                |                                        |

       Figure 9.7.3-1:  Transition support safe-periods of several days.

   During this safe period, either server will allow renewals from NORMAL any
   existing client.  The only limitation concerns the need for IP
   addresses for the DHCP server to COMMUNICATIONS-
                        INTERRUPTED hand out to new DHCP clients and back (example with 2 the
   need to re-allocate IP addresses to different DHCP clients.

   The number of "extra" IP addresses allocated required is equal to secondary)

9.8.  POTENTIAL-CONFLICT state the expected
   total number of new DHCP clients encountered during the safe period.
   This state indicates that is dependent only on the two servers are attempting to re-
   integrate with each other, but at least one arrival rate of them was running in a
   state that did new DHCP clients, not guarantee automatic reintegration would be
   possible.
   the total number of outstanding leases on IP addresses.

   In POTENTIAL-CONFLICT state the servers may determine unlikely event that a relatively short safe period of an hour
   is all that can be used (given a dearth of IP addresses or a very
   high arrival rate of new DHCP clients), even that can provide sub-
   stantial benefits in allowing the same DHCP subsystem to ride through
   minor problems that could occur and be fixed within that hour.  In
   these cases, no possibility of duplicate IP address has been offered allocation
   exists, and accepted by two different
   DHCP clients.

   It re-integration after the failure is a goal of this solved will be
   automatic and require no operator intervention.

11.  Security

   The Failover protocol communicates DHCP lease activity and this data
   is generally easily discovered via other means, such as by pinging
   addresses and doing DNS lookups. Therefore, the need to minimize encrypt the possibility that
   POTENTIAL-CONFLICT state
   data over the wire is ever entered.

9.8.1.  Upon Entry likely not great (though some sites may feel
   differently).

   However, it is very desirable to POTENTIAL-CONFLICT

   When a primary server enters POTENTIAL-CONFLICT assure the integrity of failover
   partners and to thus ensure proper operation of the servers. For
   example, denial of service attacks are possible by the communication
   of invalid state it should
   request that information to one or both servers.

   Therefore, the secondary send it all updates Failover protocol MUST be capable of being secured by
   using a simple shared secret message digest which it is
   currently unaware covers each mes-
   sage.  This provides authentication of the servers, but does not pro-
   vide encryption of the data exchange.

   The Failover protocol MAY also be secured by using TLS [RFC 2246]
   (Transport Layer Security) if encryption of the data exchange is
   desired.  The use of the shared secret or TLS will not protect
   against TCP or IP layer attacks (such as someone sending an UPDREQ message fake TCP RST
   segments). IPsec SHOULD be used to protect against most (if not all)
   of these kinds of attacks.

11.1.  Simple shared secret

   Messages between the secondary failover partners are authenticated through the
   use of a shared secret, which is never sent over the network and must
   be known by each server.

   A secondary How each server entering POTENTIAL-CONFLICT state will wait is told about this shared
   secret and secures its storage of the shared secret is outside the
   scope of this document.  If a server is configured with a shared
   secret for a partner, it MUST send the primary message-digest option in ALL
   messages to send that partner and it an UPDREQ message.

9.8.2.  Operation in POTENTIAL-CONFLICT state

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

9.8.3.  Transitions out of POTENTIAL-CONFLICT state

   If communications fails with the messages received from
   that partner while in POTENTIAL-CONFLICT
   state, then without a primary server will transition to PARTNER-DOWN state
   and message-digest option as failing authentica-
   tion.

   If a secondary server will stay is not configured with a shared secret for a partner, it
   MUST NOT send the message-digest option in POTENTIAL-CONFLICT state.

   Whenever either server receives an UPDDONE any message from its to that
   partner
   while in POTENTIAL-CONFLICT state, and it MUST transition to NORMAL
   state.  This will cause the primary server to leave POTENTIAL-
   CONFLICT state prior treat any messages received from that partner
   with a message-digest option as failing authentication.

   The shared secret is used to calculate a 16 octet message-digest
   which is sent in every failover message as the secondary, since message-digest option.
   See section 12.15. The message-digest contains a one-way 16 octet MD5
   [RFC 1321] hash calculated over a stream of octets consisting of the primary sends an
   UPDREQ
   entire message and receives an UPDDONE before concatenated with the secondary sends an
   UPDREQ message and receives its UPDDONE message.

   When a secondary server receives an indication that shared secret.

   For calculation, the primary
   server has transitioned from POTENTIAL-CONFLICT to NORMAL state, it
   SHOULD send an UPDREQ message to includes the primary server.

              Primary                                Secondary
              Server                                  Server

                |                                        |
         POTENTIAL-CONFLICT                    POTENTIAL-CONFLICT
                |                                        |
                | >--UPDREQ-------------------->         |
                |                                        |
                |        <---------------------BNDUPD--< |
                | >--BNDACK-------------------->         |
               ...                                      ...
                |                                        |
                |        <---------------------BNDUPD--< |
                | >--BNDACK-------------------->         |
                |                                        |
                |        <--------------------UPDDONE--< |
              NORMAL                                     |
                | >--STATE--(NORMAL)----------->         |
                |        <---------------------UPDREQ--< |
                |                                        |
                | >--BNDUPD-------------------->         |
                |        <---------------------BNDACK--< |
               ...                                      ...
                | >--BNDUPD-------------------->         |
                |        <---------------------BNDACK--< |
                |                                        |
                | >--UPDDONE------------------->         |
                |                                     NORMAL
                |                                        |
                |        <--------------------POOLREQ--< |
                | >------POOLRESP-(n)---------->         |
                |              addresses                 |

           Figure 9.8.3-1:  Transition out message-digest option with
   the message-digest data zeroed (16-octets of POTENTIAL-CONFLICT

9.9.  RESOLUTION-INTERRUPTED state

   This state indicates that zero). Once the two servers were attempting to re-
   integrate with each other in POTENTIAL-CONFLICT state, but
   communications failed prior to completion calcula-
   tion is complete, these 16 octets of re-integration.

   If zero are replaced by the servers remained in POTENTIAL-CONFLICT while communications
   was interrupted, neither server would be responsive 16-
   octet MD5 hash and the message is sent.

   For verification, the 16-octet message-digest is saved and replaced
   with 16-octets of zero and calculated per above. The resulting MD5
   hash is compared to DHCP client
   requests, the received hash and if one server had crashed, then there might be no
   server able to process DHCP requests.

9.9.1.  Upon Entry they match, the message
   is assumed authenticated.

   A failover partner that fails to RESOLUTION-INTERRUPTED state

   When authenticate a server enters RESOLUTION-INTERRUPTED SHOULD raise an alarm
   condition to alert administrative staff of received message or
   receives a problem in the DHCP sub-
   system.

9.9.2.  Operation in RESOLUTION-INTERRUPTED state

   In this state message without a server message-digest option when configured
   with a shared secret MUST respond to all DHCP client requests, close the connection immediately and
   any load balancing (described take
   steps to notify operators.

   This use of the shared secret is very similar to that used for RADIUS
   Accounting [RFC 2139].

11.2.  TLS

   TLS, Transport Layer Security, as specified in section 5.3) MUST NOT [RFC 2246] MAY be
   used.  When
   allocating new IP addresses, each server SHOULD allocate from its own
   IP address pool (if that can  The use of TLS would be determined), where similar to the primary MUST
   allocate only FREE IP addresses, way it is used with
   SMTP [RFC 2487] and IMAP/POP3/ACAP [RFC 2595].

   To request the secondary MUST allocate only
   BACKUP IP addresses.  When responding to renewal requests, each
   server will allow continued renewal of a DHCP client's current lease
   on an IP address irrespective use of whether that lease was given out by TLS, the receiving server or not, although the renewal period that successfully opened a con-
   nection to its peer MUST not
   exceed the maximum client lead time (MCLT) beyond send the potential-
   expiration-time already acknowledged by TLS option as part of the other CONNECT
   message.  The server or the
   lease-expiration-time or potential-expiration-time received from the
   partner server.

   However, since receiving the server cannot communicate TLS option MUST respond with a
   TLS-reply option indicating its partner acceptance or rejection of the TLS-
   request in the CONNECT message.

   If the CONNECTACK message contained a TLS-reply of 1 , then both
   servers begin TLS negotiation.

   Upon completion of this
   state, negotiation, the acknowledged-potential-expiration time will not be updated
   in server which originally sent
   the CONNECT message MUST resent its CONNECT message without any new bindings.

9.9.3.  Transitions out TLS-
   request, and must wait for a corresponding CONNECTACK.

   Implementation of RESOLUTION-INTERRUPTED state

   If an external command the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [RFC 2246]
   cipher suite is received by a server REQUIRED in RESOLUTION-
   INTERRUPTED state informing it that its partner Failover servers supporting TLS. This is down,
   important as it will
   transition immediately into PARTNER-DOWN state.

   If communications is restored with the other server, then the server
   in RESOLUTION-INTERRUPTED state will transition into POTENTIAL-
   CONFLICT state.

9.10.  RECOVER-DONE state assures that any two compliant implementations can be
   configured to interoperate.

12.  Failover Options

   This state exists section lists all of the options that are currently defined to allow an interlocked transition
   be used with the failover protocol.  See section 6.2 for one server
   from RECOVER state and another server from PARTNER-DOWN or
   COMMUNICATIONS-INTERRUPTED state into NORMAL state.

9.10.1.  Operation in RECOVER-DONE state details con-
   cerning time values.

12.1.  addresses-transferred

   A server 32 bit unsigned long in RECOVER-DONE state MUST respond only network byte order. Reports the number of
   addresses transferred by the primary to
   DHCPREQUEST/RENEWAL and DHCPREQUEST/REBINDING DHCP messages.

9.10.2.  Transitions out the secondary server
   (addresses to be used for the secondary server's private address
   pool).

        Code        Len       Number of RECOVER-DONE Addresses
   +-----+-----+-----+-----+----+-----+-----+-----+
   |  0  |  1  |  0  |  4  | n1 |  n2 |  n3 |  n4 |
   +-----+-----+-----+-----+----+-----+-----+-----+

12.2.  assigned-IP-address

   The DHCP managed IP address to which this message refers.

        Code        Len          Address
   +-----+-----+-----+-----+----+-----+-----+-----+
   |  0  |  2  |  0  |  4  | a1 |  a2 |  a3 |  a4 |
   +-----+-----+-----+-----+----+-----+-----+-----+

12.3.  binding-status

   This option is used to convey the current state

   When of a server in RECOVER-DONE state determines that its partner
   server binding.

       Code         Len     Type
   +-----+-----+-----+-----+-----+
   |  0  |  3  |  0  |  1  | 1-7 |
   +-----+-----+-----+-----+-----+

   Legal values for this option are:

   Value Binding Status
   ----- ------------------------------------------------
   1     FREE           Lease is currently available
   2     ACTIVE         Lease is assigned to a client
   3     EXPIRED        Lease has entered NORMAL state, then it will transition into NORMAL
   state expired
   4     RELEASED       Lease has been released by client
   5     ABANDONED      A server, or client flagged address as well.

9.11.  PAUSED state

   This state exists to allow one server unusable
   6     RESET          Lease was freed by some external agent
   7     BACKUP         Lease belongs to inform another that it will
   be out of service for what secondary's private address pool

12.4.  client-identifier

   This is predicted to be a relatively short
   time, and to allow the other server to transition to COMMUNICATIONS-
   INTERRUPTED state immediately and to begin servicing all DHCP clients client-identifier for the client associated with no interruption in service a
   binding.  The client-identifier data is subject to new the same
   conventions as DHCP clients.

   A server which is aware that it option 81 [RFC 2132].

        Code        Len       Client Identifier
   +-----+-----+-----+-----+----+-----+---
   |  0  |  4  |  0  |  n  | i1 |  i2 | ...
   +-----+-----+-----+-----+----+-----+--

12.5.  client-hardware-address

   This is shutting down temporarily SHOULD
   send a STATE message with the server-state option containing PAUSED
   state and close hardware address for the TCP connection.

   While client associated with a server may or may not transition internally into PAUSED
   state, the 'previous' state determined when it is restarted
   binding.  Byte t1 (type) MUST be
   the state the server was in prior set to receiving the command to shut-
   down and restart and which precedes its entry into proper ARP hardware
   address code, as defined in the PAUSED state.
   See ARP section 9.3.2 concerning the use of the previous state upon RFC 1700 (it MUST NOT
   be zero!)

        Code        Len     htype   chaddr
   +-----+-----+-----+-----+----+-----+-----+---
   |  0  |  5  |  0  |  n  | t1 |  c1 |  c2 | ...
   +-----+-----+-----+-----+----+-----+-----+---

12.6.  client-last-transaction-time

   The time at which this server restart.

9.11.1.  Upon entry last received a DHCP request from a
   particular client expressed as an absolute time (see section 6.2).

        Code        Len       Partner Down Time
   +-----+-----+-----+-----+----+-----+-----+-----+
   |  0  |  6  |  0  |  4  | t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+----+-----+-----+-----+

12.7.  client-reply-options

   This option contains options from a DHCP server's reply to PAUSED state

   When entering PAUSED state, a DHCP
   client request.  It is sent in a BNDUPD message.  The first 4 bytes
   of the server MUST store option contain the previous state
   in stable storage, "magic number" of the option area from
   which the DHCP reply options were taken and use that state as serves to define the previous state when it
   is restarted.

9.11.2.  Transitions out
   format of PAUSED state

   A server transitions out the rest of PAUSED state by being restarted.  At that
   time, the previous state MUST be sub-options contained in this option.
   After the state magic number, the server was options included are in prior to
   entering the PAUSED state.

9.12.  SHUTDOWN state

   This state exists to allow one server to inform another normal
   options format appropriate for that it will
   be out magic number.

   A server SHOULD NOT include all of service for what is predicted to be the options in a relatively long time,
   and DHCP server's
   reply to allow the other a client's request in this option, but rather a server
   SHOULD include only those options which are of likely interest to transition immediately to PARTNER-
   DOWN state, and take over completely its
   partner server.  See section 7.1 for the server going down.

   A server which is aware that it details.

        Code        Len         Magic Number      Embedded options
   +-----+-----+-----+-----+----+----+----+----+----+----+--
   |  0  |  7  |  0  |  n  | m1 | m2 | m3 | m4 | b1 | b2 |  ...
   +-----+-----+-----+-----+----+----+----+----+----+----+--

12.8.  client-request-options

   This option contains options from a DHCP client's request.  It is shutting down SHOULD send
   sent in a STATE
   message with BNDUPD message.  The first 4 bytes of the server-state field containing SHUTDOWN.

   While a server may or may not transition internally into SHUTDOWN
   state, option contain
   the 'previous' state determined when it is restarted MUST be "magic number" of the state active prior to option area from which the command DHCP client's
   request options were taken and serves to shutdown.  See section 9.3.2
   concerning define the use format of the previous state upon server restart.

9.12.1.  Upon entry to SHUTDOWN state

   When entering SHUTDOWN state, the server MUST record
   rest of the previous
   state sub-options contained in stable storage for use when this option.  After the server is restarted.  It
   also MUST record magic
   number, the current time as options included are in the last time operational. normal options format
   appropriate for that magic number.

   A server which is aware that it is shutting down SHOULD send a STATE
   message with NOT include all of the server-state field containing SHUTDOWN.

9.12.2.  Operation in SHUTDOWN state

   A server options in SHUTDOWN state MUST NOT respond to any a DHCP client input.

   If
   request in this option, but rather a server receives any message indicating that the partner has
   moved SHOULD include only those
   options which are of likely interest to PARTNER-DOWN state while it its partner server.  See
   section 7.1 for details.

        Code        Len         Magic Number      Embedded options
   +-----+-----+-----+-----+----+----+----+----+----+----+--
   |  0  |  8  |  0  |  n  | m1 | m2 | m3 | m4 | b1 | b2 |  ...
   +-----+-----+-----+-----+----+----+----+----+----+----+--

12.9.  DDNS

   If an implementation supports Dynamic DNS updates, this option is in SHUTDOWN state then it
   MUST record RECOVER state as the previous state to be
   used when it is
   restarted.

   A server SHOULD wait for to communicate the status of the DDNS update associated with a few seconds after informing
   particular lease binding.  The Flags field conveys the partner types of
   entry into SHUTDOWN state (if communications DNS
   RRs that are okay) to determine
   if it will enter PARTNER-DOWN state.

9.12.3.  Transitions out be updated by the DHCP server, and the status of SHUTDOWN state

   A the
   DDNS update.  The Domain Name field conveys the DNS FQDN that the
   DHCP server transitions out of SHUTDOWN state by being restarted.

10.  Safe Period

   Due is using to refer to the restrictions imposed on each server while client, in
   COMMUNICATIONS-INTERRUPTED state, long-term operation DNS encoding as
   specified in this state
   is not feasible for either server.  One reason that these states
   exist at all, [RFC 1035].

       Code        Len        Flags      Domain Name
   +-----+-----+-----+-----+-----+------+------+-----+------
   |  0  |  9  |  0  |  n  |   flags    |  d1  |  d2 | ...
   +-----+-----+-----+-----+-----+------+------+-----+------

   The Flags field is to allow a 16-bit field; several bit positions are
   specified here.

                        1 1 1 1 1 1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|A|D|P|       MBZ             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The bits (numbered from the servers to easily survive transient least-significant bit in network communications failures
   byte-order) are used as follows:

   0 (C): A RR update successfully completed
   1 (A): Server is controlling A RR on behalf of a few minutes to a few days
   (although the actual time periods will depend a great deal client
   2 (D): PTR RR update successfully completed (Done)
   3 (P): Server is controlling PTR RR on the
   DHCP activity behalf of the network in terms of arrival and departure client
   4-15 : Must be zero

   All of
   DHCP clients on the network).

   Eventually, when the servers are unable to communicate, they will
   have unspecified bit positions SHOULD be set to move into a state where they no longer can re-integrate
   without some possibility of a duplicate IP address allocation.  There
   are two ways that 0 by servers
   sending the Failover-DDNS option, and they can move into this state (known as PARTNER-
   DOWN).

   They can either MUST be informed ignored by external command that, indeed, the
   partner server is down.  In this case, there is no difficulty in mov-
   ing into servers
   receiving the PARTNER-DOWN state since it is an accurate reflection option.

12.10.  hash-bucket-assignment

   The set of
   reality and the protocol has been designed hash values to operate correctly (even
   during reintegration) if, when in PARTNER-DOWN state which the partner is,
   indeed, down.

   The receiving server MUST respond.
   See section 5.3 for more difficult scenario information on how this option is when the servers are running unat-
   tended for extended periods, used.

   The format and usage of the data in this case an option is provided
   to configure something called a "safe-period" into each server.  This
   OPTIONAL safe-period defined in
   [LOADB].

        Code        Len        Hash Buckets
   +-----+-----+-----+-----+----+-----+-----+-----+
   |  0  |  10 |  0  |  32 | b1 |  b2 | ... | b32 |
   +-----+-----+-----+-----+----+-----+-----+-----+

12.11.  lease-expiration-time

   The lease expiration time is the period after which either the primary or
   secondary lease interval that a DHCP server will automatically transition
   has ACKed to a DHCP client added to PARTNER-DOWN from
   COMMUNICATIONS-INTERRUPTED state.  If this transition is completed
   and the partner is not down, then the possibility of duplicate IP
   address allocations will exist. time at which that ACK was
   transmitted -- expressed as an absolute time (see section 6.2).

        Code        Len          Time
   +-----+-----+-----+-----+----+-----+-----+-----+
   |  0  |  11 |  0  |  4  | t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+----+-----+-----+-----+

12.12.  max-unacked-bndupd

   The goal maximum number of the "safe-period" BNDUPD message that this server is prepared to allow network operations staff
   some time to react to a server moving into COMMUNICATIONS-INTERRUPTED
   state.  During the safe-period
   accept over the only requirement is that TCP connection without causing the net-
   work operations staff determine if both servers are still running --
   and if they are, TCP connection to either fix the
   block.  A 32 bit unsigned integer value, in network communications failure
   between them, or to take one of the servers down before the  expira-
   tion of the safe-period.

   The length of the safe-period is installation dependent, and depends byte order.

        Code        Len     Maximum Unacked BNDUPD
   +-----+-----+-----+-----+----+-----+-----+-----+
   |  0  |  12 |  0  |  4  | n1 |  n2 |  n3 |  n4 |
   +-----+-----+-----+-----+----+-----+-----+-----+

12.13.  MCLT

   Maximum Client Lead Time, an interval, in large part on the number of unallocated IP addresses within the
   subnet address pool and the expected frequency of arrival of previ-
   ously unknown DHCP clients requiring IP addresses.  Many environments
   should seconds.  A 32 bit unsigned
   integer value, in network byte order.

        Code        Len             Time
   +-----+-----+-----+-----+----+-----+-----+-----+
   |  0  |  13 |  0  |  4  | t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+----+-----+-----+-----+

12.14.  message

   This option is used to supply a human readable message text.  It may
   be able to support safe-periods of several days.

   During this safe period, either server will allow renewals from any
   existing client.  The only limitation concerns the need for IP
   addresses for used in association with the DHCP server to hand out Reject Reason Code to new DHCP clients and provide a human
   readable error message for the
   need to re-allocate IP addresses to different DHCP clients. reject.

        Code        Len         Text
   +-----+-----+-----+-----+------+-----+--
   |  0  |  14 |  0  |  n  |  c1  | c2  | ...
   +-----+-----+-----+-----+------+-----+--

12.15.  message-digest

   The message digest for this message.

   This option consists of a variable number of "extra" IP addresses required is equal to bytes which contain the expected
   total number
   message digest of new DHCP clients encountered during the safe period.
   This is dependent only on message prior to the arrival rate inclusion of new DHCP clients, not this option.

   When this option appears in a message, it MUST appear as the total number of outstanding leases on IP addresses.

   In last
   option in the unlikely event that a relatively short safe period of an hour message.  It MUST appear in every message if message
   digests are required.

        Code        Len       Message Digest
   +-----+-----+-----+-----+----+-----+-----
   |  0  |  15 |  0  |  n  | d1 |  d2 | ...
   +-----+-----+-----+-----+----+-----+-----

12.16.  potential-expiration-time

   The potential expiration time is all the time that can be used (given a dearth of IP addresses or a very
   high arrival rate of new DHCP clients), even one server tells
   another server that can provide sub-
   stantial benefits it may wish to grant in allowing the DHCP subsystem a lease to ride through
   minor problems that could occur and be fixed a DHCP client.
   It is an absolute time.  See section 6.2.

        Code        Len          Time
   +-----+-----+-----+-----+----+-----+-----+-----+
   |  0  |  16 |  0  |  4  | t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+----+-----+-----+-----+

12.17.  receive-timer

   The number of seconds (an interval) within which the server must
   receive a message from its partner, or it will assume that hour.  In
   these cases, no possibility of duplicate IP address allocation
   exists, and re-integration after
   communications with the failure partner is solved will be
   automatic and require no operator intervention.

11.  Security not ok.  An unsigned 32 bit
   integer in network byte order.

        Code        Len         Receive Timer
   +-----+-----+-----+-----+----+-----+-----+-----+
   |  0  |  17 |  0  |  4  | s1 |  s2 |  s3 |  s4 |
   +-----+-----+-----+-----+----+-----+-----+-----+

12.18.  protocol-version

   The Failover protocol communicates DHCP lease activity and this data
   is generally easily discovered via other means, such as version being used by pinging
   addresses and doing DNS lookups. Therefore, the need to encrypt server. It is only sent in the
   data over
   CONNECT and CONNECTACK messages.  The current value for the wire version
   is likely not great (though some sites may feel
   differently).

   However, it 1.

        Code        Len    Version
   +-----+-----+-----+-----+-----+
   |  0  |  18 |  0  |  1  |  1  |
   +-----+-----+-----+-----+-----+

12.19.  reject-reason

   This option is very desirable used to assure selectively reject binding updates. It MAY be
   used in BNDACK message, always associated with an assigned-IP-address
   option, which contains the integrity of failover
   partners and to thus ensure proper operation IP address of the servers. For
   example, denial update being rejected.

        Code        Len   Reason Code
   +-----+-----+-----+-----+-----+
   |  0  |  19 |  0  |  1  |  R1 |
   +-----+-----+-----+-----+-----+

   Reason codes :

   0   Reserved
   1   Illegal IP address (not part of service attacks are possible any address pool).
   2   Fatal conflict exists: address in use by the communication
   of other client.
   3   Missing binding information.
   4   Connection rejected, time mismatch too great.
   5   Connection rejected, invalid state information to one or both servers.

   Therefore, the Failover protocol MUST be capable of being secured MCLT.
   6   Connection rejected, unknown reason.
   7   Connection rejected, duplicate connection.
   8   Connection rejected, invalid failover partner.
   9   TLS not supported.
   10  TLS supported but not configured.
   11  TLS required but not supported by
   using a simple shared secret message partner.
   12  Message digest which covers each mes-
   sage.  This provides authentication of the servers, not supported.
   13  Message digest not configured.
   14  Protocol version mismatch.
   15  Missing binding information.
   16  Outdated binding information.
   17  Less critical binding information.
   18  No traffic within sufficient time.
   19  Hash bucket assignment conflict.
   20-253, reserved.
   254 Unknown: Error occurred but does not pro-
   vide encryption of the data exchange. match any reason code.
   255 Reserved for code expansion.

12.20.  sending-server-IP-address

   The Failover protocol MAY also be secured by using TLS [TLS] (Tran-
   sport Layer Security) if encryption IP address of the data exchange server sending this message.  This option is desired.
   The use of
   required for all messages if the shared secret or TLS will not protect against TCP or
   IP layer attacks (such as someone sending fake TCP RST segments).
   IPsec SHOULD be message digest option used.

        Code        Len          Address
   +-----+-----+-----+-----+----+-----+-----+-----+
   |  0  |  20 |  0  |  4  | a1 |  a2 |  a3 |  a4 |
   +-----+-----+-----+-----+----+-----+-----+-----+

12.21.  server-flags

   This option is used to protect against most (if not all) of these
   kinds convey the current flags of attacks.

11.1.  Simple shared secret

   Messages between the failover partners are authenticated through
   endpoint in the
   use of a shared secret, which sending server.

       Code         Len     Server Flags
   +-----+-----+-----+-----+-------+
   |  0  |  21 |  0  |  1  | flags |
   +-----+-----+-----+-----+-------+

   The flags field is never sent over an 8-bit field; one bit position is
   specified here.

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

   The bits (numbered from the least-significant bit in network and must
   byte-order) are used as follows:

   0 (S): STARTUP,
          Bit 5 MUST be known by each server. How each set to 1
          whenever the server is told about this shared
   secret in STARTUP state, and secures its storage of set to 0 otherwise.
          (Note that when in STARTUP state, the shared secret is outside state transmitted in the
   scope of this document.  If a server
          server-state option is configured with a shared
   secret for a partner, it MUST send usually the message-digest option in ALL
   messages to that partner and it MUST treat any messages received last recorded state from
   that partner without a message-digest
          stable storage, but see section 9.3 for details.)
   1-7  : Must be zero

12.22.  server-state

   This option as failing authentica-
   tion.

   If a server is not configured with a shared secret for a partner, it
   MUST NOT send used to convey the message-digest option current state of the failover
   endpoint in any message to that
   partner and it MUST treat any messages received the sending server.

       Code         Len   Server State
   +-----+-----+-----+-----+-----+
   |  0  |  22 |  0  |  1  | 1-9 |
   +-----+-----+-----+-----+-----+

   Legal values for this option are:

   Value   Server State
   -----   -------------------------------------------------------------
   0       reserved
   1       STARTUP                      Startup state (1)
   2       NORMAL                       Normal state
   3       COMMUNICATIONS-INTERRUPTED   Communication interrupted (safe)
   4       PARTNER-DOWN                 Partner down (unsafe mode)
   5       POTENTIAL-CONFLICT           Synchronizing
   6       RECOVER                      Recovering bindings from that partner
   with
   7       PAUSED                       Shutting down for a message-digest option as failing authentication. short period.
   8       SHUTDOWN                     Shutting down for an extended
                                        period.
   9       RECOVER-DONE                 Interlock state prior to NORMAL

   (1) The shared secret STARTUP state is used never sent to calculate a 16 octet message-digest
   which the partner server, it is sent
   indicated by the STARTUP bit in every failover message as the message-digest option.
   See server-flags options (see section 6.2.25. The message-digest contains a one-way 16 octet
   MD5 [MD5] hash calculated over
   12.21).

12.23.  start-time-of-state

   This option is used for different states in different messages.  In a stream of octets consisting of the
   entire message concatenated with the shared secret.

   For calculation, the
   BNDUPD message includes the message-digest option with it represents the message-digest data zeroed (16-octets start time of zero). Once the calcula-
   tion is complete, these 16 octets state of zero are replaced by the 16-
   octet MD5 hash and lease
   in the message is sent.

   For verification, BNDUPD message.  In a STATE message, it represents the 16-octet message-digest is saved and replaced
   with 16-octets start
   time of zero and calculated per above. The resulting MD5
   hash is compared to the received hash and if they match, the message
   is assumed authenticated.

   A failover partner that fails server's failover state.  In all cases it is an
   absolute time.

        Code        Len      Start Time of State
   +-----+-----+-----+-----+----+-----+-----+-----+
   |  0  |  23 |  0  |  4  | t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+----+-----+-----+-----+

12.24.  TLS-reply

   This option contains information relating to authenticate a received message or
   receives TLS security
   negotiation.  It is sent in a CONNECTACK message without a message-digest option when configured
   with

   A t1 value of 0 indicates no TLS operation, a shared secret MUST close the connection immediately and take
   steps to notify operators.

   This use value of the shared secret 1 indicates
   that TLS operation is very similar required.

        Code        Len      TLS
   +-----+-----+-----+-----+-----+
   |  0  |  24 |  0  |  1  |  t1 |
   +-----+-----+-----+-----+-----+

12.25.  TLS-request

   This option contains information relating to that used for RADIUS
   Accounting [RADIUS].

11.2. TLS

   TLS, Transport Layer Security, as specified security
   negotiation.  It is sent in [TLS] MAY be used. a CONNECT message.

   The use t1 byte is the TLS request from this server.  A value of 0
   indicates no TLS would be similar to operation (to communicate the way it other server MUST NOT
   require TLS), a value of 1 indicates that TLS operation is used with SMTP
   [SMTPTLS] and IMAP/POP3/ACAP [IPAMTLS].

   To request desired
   but not required (to communicate, the use other server MAY utilize TLS),
   and a value of TLS, 2 indicates that TLS operation is required (to
   communicate the other server that successfully opened a con-
   nection to its peer MUST send the utilize TLS) to establish
   communications with this server.

        Code        Len      TLS option as part
   +-----+-----+-----+-----+-----+
   |  0  |  25 |  0  |  2  |  t1 |
   +-----+-----+-----+-----+-----+

12.26.  vendor-class-identifier

   A string which identifies the vendor of the CONNECT
   message. failover protocol
   implementation.

        Code        Len    vendor class string
   +-----+-----+-----+-----+----+-----+---
   |  0  |  26 |  0  |  n  | c1 |  c2 |  ...
   +-----+-----+-----+-----+----+-----+---

12.27.  vendor-specific-options

   This option is used to convey options specific to a particular
   vendor's implementation.  The server receiving vendor class identifier is used to
   specify which option space the embedded options are drawn from.

   It functions similarly to the TLS option MUST respond with a
   TLS-reply option indicating its acceptance or rejection of vendor class identifier and vendor
   specific options in the TLS-
   request DHCP protocol.

   This option contains other options in the CONNECT message. same two byte code, two
   byte length format.  If the CONNECTACK message contained a TLS-reply of 1 , then both
   servers begin TLS negotiation.

   Upon completion of this negotiation, the server which originally sent
   the CONNECT message MUST resent its CONNECT option appears in a message without any TLS-
   request, and must wait for a
   corresponding CONNECTACK.

   Implementation vendor class identifier, it MUST be ignored.

        Code        Len     Embedded options
   +-----+-----+-----+-----+----+-----+---
   |  0  |  27 |  0  |  n  | c1 |  c2 |  ...
   +-----+-----+-----+-----+----+-----+---

13.  IANA Considerations

   This document defines several number spaces (failover options, fail-
   over message types, and failover reject reason codes). For all of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher
   suite is REQUIRED
   these number spaces, certain values are defined in Failover servers supporting TLS. This is impor-
   tant this specifica-
   tion.  New values may only be defined by IETF Consensus, as it assures described
   in [RFC 2434]. Basically, this means that any two compliant implementations can be con-
   figured to interoperate.

12. they are defined by RFCs
   approved by the IESG.

14.  Acknowledgments

   Ralph Droms started it all, by sketching out an initial interserver
   draft that embodied ideas from several past IETF meetings.  In that
   draft, he acknowledged contributions by Jeff Mogul, Greg Minshall,
   Rob Stevens, Walt Wimer, Ted Lemon, and the DHC working group.

   Kim Kinnear and Bob Cole each extended that draft, separately and
   then together, until they created an interserver draft that supported
   any number of servers.  The complexity of that approach was just too
   great, and that draft wasn't greeted with enthusiasm by many, includ-
   ing its authors.

   It did however lead to a much simpler approach embodied in the first
   Failover draft by Greg Rabil, Mike Dooley, Arun Kapur and Ralph
   Droms.  This draft posited only two servers -- a primary and a secon-
   dary.
   secondary.

   Kim Kinnear then wrote the Safe Failover draft to layer on top of the
   Failover Draft and increase its robustness in the face of certain
   rare network failures.

   At the spring 1998 IETF meeting in LA, the DHC working group said
   that they wanted a merged Failover and Safe Failover draft.  Steve
   Gonczi and Bernie Volz stepped up and produced the raw material for
   such a merged draft, along with a new message format designed around
   DHCP options and other extensions and clarifications.  Kim Kinnear
   edited their work into draft format and made other changes in time
   for the Summer Chicago IETF meeting.

   During the summer and fall of 1998, two groups worked on separate
   implementations of the UDP failover draft.  Bernie Volz and Steve
   Gonczi constituted one group, and Kim Kinnear, Mark Stapp and Paul
   Fox made up the other.  These two groups worked together to produce
   considerable changes and simplifications of the protocol during that
   period, and Steve Gonczi and Kim Kinnear edited those changes into
   -03 draft in time for submission to the December 1998 Orlando IETF
   meeting.

   In February of 1999 Kim Kinnear and Mark Stapp hosted a meeting on
   people interested in the failover draft.  During that meeting a gen-
   eral agreement was reached to recast the failover protocol to use TCP
   instead of UDP.  In addition, the group together brainstormed a work-
   able load-balancing technique.  Kim Kinnear rewrote the entire draft
   to include the changes made at that meeting as well as to restructure
   the draft along guidelines suggested by Thomas Narten.  The result
   was the -04 draft, submitted prior to the Oslo IETF meeting.

   The initial idea for a hash-based load balancing approach was offered
   by Ted Lemon, and the determination of an algorithm and its integra-
   tion into the draft was done by Steve Gonczi.  The security section
   was spearheaded by Bernie Volz.  Both contributed considerably to the
   ideas and text in the rest of the draft with several reviews.

   In early October of 1999, three conference calls were held to discuss
   the -04 draft.  The current draft (-05) -05 includes changes as a result of those calls,
   perhaps the largest of which was to remove the load- load balancing
   approach into a separate draft.   Thanks to all of the many people whoe
   who participated in the conference calls.  This current draft
   was changed  Changes were made because
   of contributions by: Ted Lemon, David Erdmann, Richard Jones, Rob
   Stevens, Thomas Narten, Diana Lane, and Andre Kos-
   tur. Kostur.

   Another conference call was held in mid-January of 2000, and this
   latest draft, the -06, was produced to tighten up the the -05 draft
   both technically as well as editorially.

   These most recent changes have not been widely circulated among the
   other
   authors, but that does not preclude any of them from expressing
   disagreement with what is contained in this draft at any future time. authors.

   Many people have reviewed the various earlier drafts that went into
   this result.  At American Internet, ideas were contributed by Brad
   Parker.  At Cisco Systems Paul Fox and Ellen Garvey contributed to
   the design of the protocol.

   Glenn Waters of Nortel Networks contributed ideas and enthusiasm to
   make a Failover protocol that was both "safe" and "lazy".

13.

15.  References

   [AGENTINFO] Patrick, M., "draft-ietf-dhc-agent-options-08.txt", Janu-
      ary, 2000.

   [DDNS] Rekhter, Y., Stapp, M., "draft-ietf-dhc-dhcp-dns-11.txt",
      October, 1999.

   [LOADB] Volz, B., Gonczi, S., Lemon, T., Stevens, R., "draft-ietf-
      dhc-loadb-00.txt", October, 1999.

   [RFC 2131] 1035] Mockapetris, P., "Domain Names - Implementation and
      Specification", November, 1987.

   [RFC 1321] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algo-
      rithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data
      Security Inc., April 1992.

   [RFC 1534] Droms, R., "Dynamic Host Configuration Protocol", "Interoperation between DHCP and BOOTP", RFC
      2131, March 1997.
      1534, October 1993.

   [RFC 2119] Bradner, S. "Key words for use in RFCs to Indicate
      Requirement Levels", RFC 2119.

   [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
      2131, March 1997.

   [RFC 2132] Alexander, S.,  Droms, R., "DHCP Options and BOOTP Vendor
      Extensions", Internet RFC 2132, March 1997.

   [TLS]

   [RFC 2136] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
      Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
      1997
   [RFC 2139] Rigney, C., "Radius Accounting", RFC 2139, Livingston
      Enterprises, April 1997.

   [RFC 2246] Dierks, T., "The TLS Protocol, Version 1.0", RFC 2246,
      January 1999.

   [SMTPTLS]

   [RFC 2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
      IANA Considerations Section in RFCs", BCP 26, RFC 2434, October
      1998.

   [RFC 2487] Hoffman, P., "SMTP Service Extension for Secure SMTP over
      TLS", RFC 2487, January 1999.

   [IMAPTLS]

   [RFC 2595] Newman, C., "Using TLS with IMAP, POP3, and ACAP", RFC
      2595, June 1999.

   [NAMESPACE] Carney, M., "draft-ietf-dhc-option_review_and_namespace-
      00.txt", June 1999.

   [DDNS] Rekhter, Y., Stapp, M., "draft-ietf-dhc-dhcp-dns-11.txt",
      October, 1999.

   [MD5] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm",
      RFC 1321, MIT Laboratory for Computer Science, RSA Data Security
      Inc., April 1992.

   [RADIUS] Rigney, C., "Radius Accounting", RFC 2139, Livingston Enter-
      prises, April 1997.

   [LOADB] Volz, B., Gonczi, S., Lemon, T., Stevens, R., "draft-ietf-
      dhc-loadb-00.txt", October, 1999.

   [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specif-
      ication", November, 1987.

   [AGENTINFO] Patrick, M., "draft-ietf-dhc-agent-options-07.txt",
      August, 1999.

   [USERCLASS] Droms, R., Demirtjis A., Stump, G., Droms, Gu, Y., Vyaghrapuri,
      R., "draft-ietf-dhc-
      userclass-04.txt", October, 1999.

   [RFC2136] P. Vixie, S. Thomson, Y. Rekhter, Beser, B., Privat, J. Bound, "Dynamic
      Updates in the Domain Name System (DNS UPDATE)", RFC2136, April
      1997

14. "draft-ietf-dhc-userclass-05.txt",
      February, 2000.

16.  Author's information

      Ralph Droms
      323 Dana Engineering
      Bucknell University
      Lewisburg, PA  17837

      Phone: (717) 524-1145
      EMail: droms@bucknell.edu

      Greg Rabil, Mike Dooley, Arun Kapur
      Lucent Technologies
      10 Valley Stream Parkway, Suite 240
      400 Lapp Road
      Malvern, PA 19355

      Phone: (800) 208-2747

      EMail: grabil@lucent.com
             mdooley@lucent.com
             akapur@lucent.com

      Kim Kinnear
      Mark Stapp
      Cisco Systems
      250 Apollo Drive
      Chelmsford, MA  01824
      Phone: (978) 244-8000

      EMail: kkinnear@cisco.com
             mjs@cisco.com

      Bernie Volz
      Steve Gonczi
      Process Software Corporation
      959 Concord St.
      Framingham, MA  01701

      Phone: (508) 879-6994

      EMail: volz@process.com
             gonczi@process.com

15.

17.  Full Copyright Statement

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all
such copies and derivative works.  However, this document itself may not
be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations,
except as needed for the  purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet Stan-
dards process must be followed, or as required to translate it into
languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT-
NESS FOR A PARTICULAR PURPOSE.

Open Issues

   These issues need to be resolved:

      1.  Need to figure out how to get 16 bit options without referenc-
          ing the [NAMESPACE] draft, since it doesn't really define them
          anymore.  Get another port number for connections.

      2.  We need  Resolve how to deal with the option space, and the procedures for
          managing it.  Probably IANA. handle secondary IP address allocation.

      3.  Figure out a better way to identify vendors.  How about an
          SNMP Enterprise MIB value?

      4.  Need to tie reject-reasons to text of draft, remove obsolete
          reject-reasons.

      5.  Using tables, compress description of sending BNDUPD message
          to save duplicated words, enhance description of differences.