[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12

Network Working Group                                        Ralph Droms
INTERNET DRAFT                                               Kim Kinnear
                                                              Mark Stapp
                                                           Cisco Systems

                                                             Bernie Volz
                                                                Ericsson

                                                            Steve Gonczi
                                                                Relicore

                                                              Greg Rabil
                                                     Lucent Technologies

                                                          Michael Dooley
                                                 Diamond IP Technologies

                                                              Arun Kapur
                                                             K5 Networks

                                                              March 2003
                                                  Expires September 2003


                         DHCP Failover Protocol
                    <draft-ietf-dhc-failover-12.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.




Droms, et. al.           Expires September 2003                 [Page 1]

Internet Draft           DHCP Failover Protocol              March 2003


Copyright Notice

   Copyright (C) The Internet Society (2003). 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 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 load balancing
   approach.


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......................... 9
    3.1.  Key aspects of the DHCP protocol........................... 9
    3.2.  BOOTP relay agent implementation........................... 11
    3.3.  What does it mean if a server can't communicate with its partner? 12
    3.4.  Challenging scenarios for a Failover protocol.............. 13
    3.5.  Using TCP to detect partner server failure................. 14
    4.  Design Goals................................................. 15
    4.1.  Design goals for this protocol............................. 15
    4.2.  Limitations of this protocol............................... 17
    5.  Protocol Overview............................................ 17
    5.1.  Messages and States........................................ 18
    5.2.  Fundamental guarantees..................................... 20
    5.3.  Load balancing............................................. 27
    5.4.  IP address allocations between servers..................... 28
    5.5.  Operating in NORMAL state.................................. 30
    5.6.  Operating in COMMUNICATIONS-INTERRUPTED state.............. 31
    5.7.  Operating in PARTNER-DOWN state............................ 31





Droms, et. al.           Expires September 2003                 [Page 2]

Internet Draft           DHCP Failover Protocol              March 2003



    5.8.  Operating in RECOVER state................................. 31
    5.9.  Operating in STARTUP state................................. 31
    5.10.  Time synchronization between servers...................... 32
    5.11.  IP address binding-status................................. 33
    5.12.  DNS dynamic update considerations......................... 36
    5.13.  Reservations and failover................................. 41
    5.14.  Dynamic BOOTP and failover................................ 42
    5.15.  Guidelines for selecting MCLT............................. 43
    5.16.  What is sent in response to an UPDREQ or UPDREQALL message? 43
    5.17.  How do you determine that your partner is "up to date" for 45
    6.  Common Message Format........................................ 45
    6.1.  Message header format...................................... 46
    6.2.  Common option format....................................... 48
    6.3.  Batching multiple binding update transactions in one BNDUPD mes- 49
    7.  Protocol Messages............................................ 51
    7.1.  BNDUPD message [3]......................................... 51
    7.2.  BNDACK message [4]......................................... 62
    7.3.  UPDREQ message [9]......................................... 65
    7.4.  UPDREQALL message [7]...................................... 66
    7.5.  UPDDONE message [8]........................................ 67
    7.6.  POOLREQ message [1]........................................ 68
    7.7.  POOLRESP message [2]....................................... 69
    7.8.  CONNECT message [5]........................................ 70
    7.9.  CONNECTACK message [6]..................................... 74
    7.10.  STATE message [10]........................................ 78
    7.11.  CONTACT message [11]...................................... 79
    7.12.  DISCONNECT message [12]................................... 80
    8.  Connection Management........................................ 81
    8.1.  Connection granularity..................................... 81
    8.2.  Creating the TCP connection................................ 81
    8.3.  Using the TCP connection for determining communications status 83
    8.4.  Using the TCP connection for binding data.................. 85
    8.5.  Using the TCP connection for control messages.............. 85
    8.6.  Losing the TCP connection.................................. 85
    9.  Failover Endpoint States..................................... 86
    9.1.  Server Initialization...................................... 86
    9.2.  Server State Transitions................................... 86
    9.3.  STARTUP state.............................................. 90
    9.4.  PARTNER-DOWN state......................................... 93
    9.5.  RECOVER state.............................................. 95
    9.6.  RECOVER-WAIT state......................................... 97
    9.7.  RECOVER-DONE state......................................... 98
    9.9.  COMMUNICATIONS-INTERRUPTED State........................... 101
    9.10.  POTENTIAL-CONFLICT state.................................. 105
    9.11.  RESOLUTION-INTERRUPTED state.............................. 107
    9.12.  CONFLICT-DONE state....................................... 108
    9.13.  PAUSED state.............................................. 108



Droms, et. al.           Expires September 2003                 [Page 3]

Internet Draft           DHCP Failover Protocol              March 2003


    9.14.  SHUTDOWN state............................................ 109
    10.  Safe Period................................................. 110
    11.  Security.................................................... 111
    11.1.  Simple shared secret...................................... 112
    11.2.  TLS....................................................... 113
    12.  Failover Options............................................ 113
    12.1.  addresses-transferred..................................... 114
    12.2.  assigned-IP-address....................................... 114
    12.3.  binding-status............................................ 114
    12.4.  client-identifier......................................... 115
    12.5.  client-hardware-address................................... 115
    12.6.  client-last-transaction-time.............................. 115
    12.7.  client-reply-options...................................... 116
    12.8.  client-request-options.................................... 116
    12.9.  DDNS...................................................... 117
    12.10.  delayed-service-parameter................................ 118
    12.11.  hash-bucket-assignment................................... 118
    12.12.  IP-flags................................................. 119
    12.13.  lease-expiration-time.................................... 120
    12.14.  max-unacked-bndupd....................................... 120
    12.15.  MCLT..................................................... 120
    12.16.  message.................................................. 121
    12.17.  message-digest........................................... 121
    12.18.  potential-expiration-time................................ 122
    12.19.  receive-timer............................................ 122
    12.20.  protocol-version......................................... 122
    12.21.  reject-reason............................................ 123
    12.22.  relationship-name........................................ 124
    12.23.  server-flags............................................. 124
    12.24.  server-state............................................. 125
    12.25.  start-time-of-state...................................... 125
    12.26.  TLS-reply................................................ 126
    12.27.  TLS-request.............................................. 126
    12.28.  vendor-class-identifier.................................. 126
    12.29.  vendor-specific-options.................................. 127
    13.  IANA Considerations......................................... 127
    14.  Acknowledgments............................................. 127
    15.  References.................................................. 129
    16.  Author's information........................................ 131
    17.  Full Copyright Statement.................................... 132


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



Droms, et. al.           Expires September 2003                 [Page 4]

Internet Draft           DHCP Failover Protocol              March 2003


   network 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 most DHCP client requests are sent to each
   server (see section 3.1.1 for details).

   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 all lease activity so that this information is 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 a way to integrate the DHCP load-
   balancing algorithm described in [RFC 3074] with the failover proto-
   col.

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  "available IP address"

         An IP address is "available" if it may be allocated by a
         specific DHCP server.  An IP address is considered (for the
         purposes of this document) to be available to a single server
         for allocation unless otherwise noted.  An IP address available
         for allocation on a primary server has state FREE, and an IP
         address available for allocation on a secondary server has
         state BACKUP.



Droms, et. al.           Expires September 2003                 [Page 5]

Internet Draft           DHCP Failover Protocol              March 2003


      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, the binding-status option, along
         with 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 "DDNS"

        An abbreviation for "Dynamic DNS", which refers to the capabil-
        ity to update a DNS server's name (actually resource record)



Droms, et. al.           Expires September 2003                 [Page 6]

Internet Draft           DHCP Failover Protocol              March 2003


        database using an on-the-wire protocol defined in [RFC 2136].

      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 "failover endpoint"

        The failover protocol allows for there to be a unique failover
        endpoint per partner per role per relationship (where role is
        primary or secondary and the relationship is defined by the
        relationship-name option).  This failover endpoint can take
        actions and hold unique states.  Typically, there is a one fail-
        over endpoint per partner, although there may be more.

      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 "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 "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 extend a lease for a
        client's binding beyond the time known by the partner server.



Droms, et. al.           Expires September 2003                 [Page 7]

Internet Draft           DHCP Failover Protocol              March 2003


        See section 5.2.1 for details.

      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 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 [FQDN] to tag a DNS name with the identity of
        the DHCP client with which it is associated.

      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 "state"

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



Droms, et. al.           Expires September 2003                 [Page 8]

Internet Draft           DHCP Failover Protocol              March 2003


      o "subnet address pool"

        A subnet address pool is the set of IP addresses which is asso-
        ciated 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.  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



Droms, et. al.           Expires September 2003                 [Page 9]

Internet Draft           DHCP Failover Protocol              March 2003


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



Droms, et. al.           Expires September 2003                [Page 10]

Internet Draft           DHCP Failover Protocol              March 2003


   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 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
   unacceptably limit the potential scalability of any DHCP server which
   employed the failover protocol.

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



Droms, et. al.           Expires September 2003                [Page 11]

Internet Draft           DHCP Failover Protocol              March 2003


   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.

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 operational server



Droms, et. al.           Expires September 2003                [Page 12]

Internet Draft           DHCP Failover Protocol              March 2003


   and the operational server will be able to use all of the 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.5 for details.

   A more likely (in that DHCPREQUEST/RENEWs 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



Droms, et. al.           Expires September 2003                [Page 13]

Internet Draft           DHCP Failover Protocol              March 2003


   communicate 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.5 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 on a TCP connection, the TCP layer
          also does not exchange any signaling messages to assure that
          the peer is still up.

      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



Droms, et. al.           Expires September 2003                [Page 14]

Internet Draft           DHCP Failover Protocol              March 2003


   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.
   On some systems it can be set system-wide, while on 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 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
   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 goals and the limitations of the fail-
   over protocol.

4.1.  Design goals for this protocol

   The following is a list of goals that are met by this protocol.  They
   are listed in priority order.

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

      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.  Provide for continued service to DHCP clients through an



Droms, et. al.           Expires September 2003                [Page 15]

Internet Draft           DHCP Failover Protocol              March 2003


          automated mechanism in the event of failure of the primary
          server.

      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.

      6.  Minimize any need for manual administrative intervention.

      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.

      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.

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

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

      11. Allow for one computer to act as a secondary server for multi-
          ple primary servers.  The protocol must allow failover primary
          and secondary configuration choices to be made at a granular-
          ity smaller than "all of the subnets served by a single
          server", though individual implementations may not 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.

      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 without requiring human intervention.

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




Droms, et. al.           Expires September 2003                [Page 16]

Internet Draft           DHCP Failover Protocol              March 2003


      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.2.  Limitations of this 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 is 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 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 to which the secondary server is
          required to respond.  See section 5.3 for more information on
          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.




Droms, et. al.           Expires September 2003                [Page 17]

Internet Draft           DHCP Failover Protocol              March 2003


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) message is used by the secondary
        server to request an allocation of IP addresses from the primary
        server.  The pool response (POOLRESP) message 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.




Droms, et. al.           Expires September 2003                [Page 18]

Internet Draft           DHCP Failover Protocol              March 2003


      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 is SHOULD be configured with one failover rela-
   tionship between each pair of failover servers. In this case there is
   one failover endpoint for that relationship on each partner.  This
   failover relationship MUST have a unique name, which is communicated
   using the relationship-name option in the CONNECT and CONNECTACK mes-
   sages.

   There is typically little need for addtional relationships between
   any two servers but there MAY be more than one failover relationship
   between two servers -- however each MUST have a unique relationship
   name (stored in the relationship-name option).

   Any failover endpoint can take actions and hold unique states.

   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, unique relationship names, and independent TCP



Droms, et. al.           Expires September 2003                [Page 19]

Internet Draft           DHCP Failover Protocol              March 2003


   connections.

   This document frequently describes the behavior of the protocol in
   terms of primary and secondary servers, not primary and secondary
   failover endpoints.  However, it is important to remember that every
   'server' described in this document is in reality a failover endpoint
   that resides in a particular process, and that many failover end-
   points may reside in the same server 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 (typically) one failover endpoint per partner,
   regardless of how many subnet address pools are managed by that com-
   bination of partner and role.  Conversely, on a particular server,
   any given 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, the relationship-name, and the role of the
   receiving server. See section 8.2.

5.2.  Fundamental 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 are key to the correct opera-
   tion of the protocol.

5.2.1.  Control of lease time

   The key problem with lazy update is that when 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



Droms, et. al.           Expires September 2003                [Page 20]

Internet Draft           DHCP Failover Protocol              March 2003


   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 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 MCLT after the partner server went
   down before allocating any of the partner's addresses which were
   available for allocation.  In the event the partner was not in 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 made a transition to PARTNER-DOWN
   state, it MUST NOT reallocate an IP address from one client to
   another client until the longer of the following two times:

      o The MCLT after the time the partner server went down (see
        above).

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



Droms, et. al.           Expires September 2003                [Page 21]

Internet Draft           DHCP Failover Protocol              March 2003


   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 restric-
     tions imposed by the Failover protocol.  Its determination is out-
     side 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



Droms, et. al.           Expires September 2003                [Page 22]

Internet Draft           DHCP Failover Protocol              March 2003


   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.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.2.1-1 illustrates an 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.
































Droms, et. al.           Expires September 2003                [Page 23]

Internet Draft           DHCP Failover Protocol              March 2003



              DHCP                 Primary             Secondary
       time   Client               Server               Server

                | (time in intervals) |  (absolute time)   |
                |                     |                    |
                | >-DHCPDISCOVER->    |                    |
                |     <---DHCPOFFER-< |                    |
                |  lease-time=MCLT    |                    |
                |                     |                    |
                | >-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.2.1-1:  Lazy Update Message Traffic
                          X = Desired Lease Interval
                          Assumes renewal interval = lease interval / 2


   DISCUSSION:

      This protocol mandates only that the above fundamental 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



Droms, et. al.           Expires September 2003                [Page 24]

Internet Draft           DHCP Failover Protocol              March 2003


      interval is 3 days, and its renewal time is half the lease inter-
      val.

      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 DHCPACK to the DHCP client, it
      will update the secondary server with the lease information. How-
      ever, the desired potential lease interval will be composed of 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 a BNDACK to its update of the
      secondary server's (partner's) potential lease interval, it
      records that as the acknowledged potential lease interval.  A



Droms, et. al.           Expires September 2003                [Page 25]

Internet Draft           DHCP Failover Protocol              March 2003


      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 IP addresses
   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 IP address becomes available.
   See section 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



Droms, et. al.           Expires September 2003                [Page 26]

Internet Draft           DHCP Failover Protocol              March 2003


   BNDUPD message) and receiving acknowledgement (through a BNDACK mes-
   sage) 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 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 [RFC
   3074].

   A bitmap-style Hash Bucket Assignment (as described in [RFC 3074]) is
   used to determine which DHCP clients can be processed.  There are two
   potential HBA's in a failover server -- a server HBA and a failover
   HBA.   The way that a server acquires a server HBA is outside of the



Droms, et. al.           Expires September 2003                [Page 27]

Internet Draft           DHCP Failover Protocol              March 2003


   scope of the failover protocol, but both servers in a failover pair
   MUST have the same server HBA. The failover HBA (which specifies the
   clients that the secondary is supposed to process) is sent by the
   primary server to the secondary server whenever a connection is esta-
   blished, using the hash-bucket-assignment option defined in section
   12.11.

   When using the server HBA (if any) and the failover HBA (if any), to
   decide whether to process a DHCP request, the server HBA always
   applies in every failover state, and the failover HBA (which MUST be
   a subset of the server HBA) is used by the secondary server to decide
   which packets to process when in NORMAL state.

5.4.  IP address allocations between servers

   The failover protocol allows a DHCP server which implements it to
   operate correctly in spite of the uncertainty over whether its
   partner has failed or whether the communications link to its partner
   has failed.  This is made possible in part by the existence of
   separate address pools on each server for allocation to newly arrived
   DHCP clients.

   Thus, each server has its own pool of available IP addresses.  Note
   that an IP address is not "owned" by a particular server throughout
   its entire lifetime.  Only an IP address which is available is
   "owned" by a particular server -- once it has been leased to a DHCP
   client, it is not owned by either failover partner.  When it finally
   becomes available again, it will be owned initially by the primary
   server, and it may or may not be allocated to the secondary server by
   the primary server.

   So, the flow of IP address ownership is as follows: initially an IP
   address is owned by the primary server.  It may be allocated to the
   secondary server if it is available, and then it is owned by the
   secondary server.  Either server can allocate available IP addresses
   which they own to DHCP clients, in which case they cease to own them.
   When the DHCP client releases the address or the lease on it expires,
   it will again become available and will be owned by the primary.

   An IP address will not become owned by the server which allocated it
   initially when it is released or the lease expires because, in gen-
   eral, that server will have had to replenish its pool of available
   addresses well in advance of any likely lease expirations.  Thus,
   having a particular IP address cycle back to the secondary might well
   put the secondary more out of balance with respect to the primary
   instead of enhancing the balance of available addresses between them.

   These address pools are used when in COMMUNICATIONS-INTERRUPTED state



Droms, et. al.           Expires September 2003                [Page 28]

Internet Draft           DHCP Failover Protocol              March 2003


   and while waiting for the MCLT expiration in PARTNER-DOWN state.  In
   addition, when using load balancing, these pools are used when in
   NORMAL state as well.

   This allocation and maintenance of these address pools is an area of
   some sensitivity, since the goal is to maintain a more or less con-
   stant ratio of available addresses between the two servers.

   The initial allocation when the servers first integrate is triggered
   by the POOLREQ message from the secondary to the primary.  This is
   followed by the POOLRESP message where the primary tells the secon-
   dary how many IP addresses it allocated to the secondary.  Then, the
   primary sends the allocated IP addresses to the secondary via BNDUPD
   messages.  l The POOLREQ/POOLRESP message is a trigger to the primary
   to perform a scan of its database and to ensure that the secondary
   has enough IP addresses (based on some configured ratio).

   The actual IP addresses are sent to the secondary using the BNDUPD
   message with a state of BACKUP, which indicates the IP address is now
   available for allocation by the secondary.  Once the message is sent,
   the primary MUST NOT use these addresses for allocation to DHCP
   clients.

   The POOLREQ/POOLRESP message exchange initiated by the secondary is
   valid at any time, and the primary server SHOULD, whenever it
   receives the POOLREQ message, scan its database of address pools and
   determine if the secondary needs more IP addresses from any of the IP
   address pools.

   However, in order to support a reasonably dynamic balance of the IP
   addresses between the failover partners, the primary server needs to
   do additional work to ensure that the secondary server has as many IP
   addresses as it needs (but that it doesn't have *more* than it needs
   either).

   The primary server SHOULD examine the balance of available addresses
   between the primary and secondary for a particular address pool when-
   ever the number of available addresses for either the primary or
   secondary changes.  The primary server SHOULD adjust the available
   address balance as required to ensure the configured address balance,
   excepting that the primary server SHOULD employ some threshold
   mechanism to such a balance adjustment in order to minimize the over-
   head of maintaining this balance.

   An example of a threshold approach is: do not attempt to re-balance
   the available pools on the primary and secondary until the out of
   balance value exceeds a configured value.




Droms, et. al.           Expires September 2003                [Page 29]

Internet Draft           DHCP Failover Protocol              March 2003


   The primary server can, at any time, send an available IP address to
   the secondary using a BNDUPD with the state BACKUP.  The primary
   server can attempt to take an available IP address away from the
   secondary by sending a BNDUPD with the state FREE.  If the secondary
   accepts the BNDUPD, then it is now available to the PRIMARY and not
   available to the secondary.  Of course, the secondary MUST reject
   that BNDUPD if it has already used that IP address for a DHCP client.

   Whenever the primary server examines the possible available IP
   addresses which it could send to the secondary server, the primary
   server SHOULD take into account whether load balancing is in use, and
   it SHOULD attempt to send to the secondary any IP addresses whose
   most recent client would be processed by the secondary under the
   current load balancing regime in use.  Likewise, when removing avail-
   able IP addresses from the secondary server when load balancing is in
   use, the primary server SHOULD first remove those IP addresses whose
   most recent client would be processed by the primary server under the
   current load balancing regime in use.

5.5.  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 [RFC 3074].  Each server services DHCPREQUEST/RENEWAL
   or DHCPDISCOVER/REBINDING requests from any client.

   In general, whenever the binding database is changed in stable
   storage (other than a change resulting from receiving a BNDUPD from
   the failover partner), then a BNDUPD message is sent with the con-
   tents 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.

   The binding database in a DHCP server would normally be changed as a
   result of DHCP protocol activity with a DHCP client  (e.g., granting
   a lease to a DHCP client through the familiar
   DISCOVER/OFFER/REQUEST/ACK cycle or extending a lease due to a
   renewal from a DHCP client) or possibly (on some servers) because a
   lease has expired or undergone another state change that must be
   recorded in the DHCP binding database.  These are the state changes
   that would be communicated to the partner server using a BNDUPD mes-
   sage.  Of course, receipt of a BNDUPD message itself will normally
   cause an update of the binding database for all of the IP addresses
   contained in the BNDUPD, and a binding database change such as this
   MUST NOT trigger a corresponding BNDUPD message to the partner.





Droms, et. al.           Expires September 2003                [Page 30]

Internet Draft           DHCP Failover Protocol              March 2003


5.6.  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 (subject to server load balancing [RFC 3074]), but in
   such a way that graceful reintegration is always possible when its
   partner comes back into contact with it.

5.7.  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 (subject to server load balanc-
   ing [RFC 3074]).

5.8.  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.9.  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 short time, the server is unrespon-
   sive 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 startup period SHOULD be conditioned on the length of time the
   server has been down (if that can be determined).  If the server has
   been down less than the MCLT then it can wait only a few (say 5 or
   10) seconds.  If it has been down a longer time (such that the
   partner may well have moved to PARTNER-DOWN state), a considerably
   longer startup period of 30 to 60 seconds may be warranted, since the
   consequences of running while the partner is in PARTNER-DOWN state



Droms, et. al.           Expires September 2003                [Page 31]

Internet Draft           DHCP Failover Protocol              March 2003


   are unpleasant.

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

   Note that if an implementation that requires time synchronization
   between servers encounters a case where the time is not synchronized
   to its satisfaction between two servers, then this failure will prob-
   ably prevent the two servers from reaching communications OK status.
   In this occurs, and if both servers continue to operate and deal with
   clients, potentially troublesome things can happen.  For instance, if
   there is a safe period configured on either server, then it will
   eventually go into PARTNER-DOWN state, but in this case the partner
   will not be down.  This will almost certainly create problems.  Thus,
   some method to prevent this sort of situation SHOULD exist in imple-
   mentations that can be configured to require time synchronization.

   In any event, whether large or only small differences in time values
   are supported, every message that is sent MUST include the time and
   every packet 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, as well as reset-
   ting the time delta between the failover partners.

   The specific definitions of a minor or drastic change in delta time



Droms, et. al.           Expires September 2003                [Page 32]

Internet Draft           DHCP Failover Protocol              March 2003


   as well as the algorithm used to smooth minor changes into the run-
   ning delta time are implementation issues and are not further
   addressed in this document.

5.11.  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, 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 common denominator
   of those in use by many DHCP server implementations.  It is a goal of
   this protocol that any DHCP server can map the various IP address
   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.

   The IP address binding-status values defined for the failover proto-
   col are listed below.  Unless otherwise noted below, there MAY be
   client information associated with each of these binding-status
   values.

      o ACTIVE -- Lease is assigned to a client. Client identification
        MUST appear.

      o EXPIRED -- 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 for allocation to any client of the primary
        server.  It may be allocated to the same client on the server
        where the lease expired if a BNDUPD containing the EXPIRED state
        has not yet been sent to the partner (e.g., in the event that
        the servers are not in communication).  Client identification
        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,



Droms, et. al.           Expires September 2003                [Page 33]

Internet Draft           DHCP Failover Protocol              March 2003


        and it is available for allocation by the primary server to any
        DHCP client.  It may be allocated to the same client if a BNDUPD
        has not yet been sent to the partner.  Client identification
        SHOULD appear.

      o FREE -- is used when a DHCP server needs to communicate that an
        IP address is unused by 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 a 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.)

        Note that when an IP address that was allocated by the secondary
        reverts to the FREE state, it must (like any other IP address)
        be assigned to the secondary through the POOLREQ/BNDUPD process
        before the secondary can reallocate it.

        Client identification 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.
        Client identification MUST NOT appear.

      o RESET -- indicates that this IP address was made available by
        operator command.  This is a distinct state so that the reason
        that the IP address became FREE can be determined.  Client iden-
        tification MAY appear.

      o BACKUP -- indicates that this IP address can be allocated by the
        secondary server to a DHCP client at any time. When the MCLT has
        passed after its time of entry into PARTNER-DOWN state, the IP
        address may be allocated by the primary to any DHCP client.
        Client identification MAY appear.

   These binding-status values are communicated from one failover
   partner to another using the binding-status option, see section 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:




Droms, et. al.           Expires September 2003                [Page 34]

Internet Draft           DHCP Failover Protocol              March 2003




                                        DHCP client DECLINE or
                                        server detected problem
                                        from any state
                                                  |
                                                  V
                          +----------+         +--+------+
         External   >---->|   RESET  |   (3)   |ABANDONED|
         command          |          +<--------+         |
                          +----------+         +---------+
                               |
                           Comm w/Parter(1)
                               V
     +---------+  Comm(1) +----------+   Comm(1) +---------+
     | EXPIRED |--------->|  FREE    |<----------| RELEASED|
     |         | w/Parter |          | w/Partner |         |
     +---------+          +----------+           +---------+
       ^     ^             |    |  +-----------+       ^
       |     |             |    |              |       |
       | Exp. grace     IP |  IP addr alloc.  IP addr  |
       | period ends  address  to sec.(2)     reserved |
       |     |        leased    V              |       |
       |     |        by   |   +----------+    |       |
       |     |        primary  |  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.11-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.

       (3) This transition MAY occur due to an implementation specific
       handling of ABANDONED IP addresses.



Droms, et. al.           Expires September 2003                [Page 35]

Internet Draft           DHCP Failover Protocol              March 2003





   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 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.  For example, a server which implements 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.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 above by "Comm
   w/Partner".

5.12.  DNS dynamic update considerations

   DHCP servers (and clients) can use DNS Dynamic Updates as described
   in [RFC 2136] to maintain DNS name-mappings as they maintain DHCP
   leases.  Many different administrative models for DHCP-DNS integra-
   tion are possible.  Descriptions of several of these models, and
   guidelines that DHCP servers and clients should follow in carrying
   them out, are laid out in [FQDN].  The nature of 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 the information which failover
   partners should exchange and the protocol which they should follow in
   order to ensure consistent behavior.  The presence of this section
   should not be interpreted as requiring that implementations of the
   DHCP failover protocol must also support DDNS updates.  The purpose
   of this discussion is to clarify the areas where the DHCP failover
   and DHCP-DDNS protocols intersect for the benefit of implementations
   which support both protocols, not to introduce a new requirement into
   the DHCP failover protocol.  Thus, a DHCP server which implements the



Droms, et. al.           Expires September 2003                [Page 36]

Internet Draft           DHCP Failover Protocol              March 2003


   failover protocol MAY also support dynamic DNS updates, but if it
   does support dynamic DNS updates it SHOULD utilize the techniques
   described here in order to correctly distribute them between the
   failover partners.  See [FQDN], [DNSRES], and [DHCID] for details of
   how DHCP servers update DNS.

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

5.12.1.  Relationship between failover and dynamic DNS update

   The failover protocol describes the conditions under which each fail-
   over server may renew a lease to its current DHCP client, and
   describes the conditions under which it may grant a lease to a new
   DHCP client.  An analogous set of conditions determines when a 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
   they obtained from one failover partner even if they can only commun-
   icate with the other partner; allowing the backup DHCP server to
   grant new leases even if it is unable to communicate with the primary
   server.  The desired external DDNS behavior for DHCP failover servers
   is:

      1.  Allow timely DDNS updates from the server which grants a
          client a lease. Recognize that there is often a DDNS update
          lifecycle which parallels the DHCP lease lifecycle. This is
          likely to include the addition of records when the lease is
          granted, and the removal of DNS records when the lease is sub-
          sequently made available for allocation to a different client.

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

      3.  Avoid redundant or overlapping DDNS updates, where both fail-
          over servers are attempting to perform DDNS updates for the
          same lease-client binding. Avoid situations where one partner
          is attempting to add RRs related to a lease binding while the



Droms, et. al.           Expires September 2003                [Page 37]

Internet Draft           DHCP Failover Protocol              March 2003


          other partner is attempting to remove RRs related to the same
          lease binding.

5.12.2.  Use of the DDNS option

   In order for either server to be able to complete 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. The
   FQDN associated with the client's A RR and PTR RR SHOULD be communi-
   cated from the server which adds records into the DNS to its partner.
   The initiating server SHOULD use the DDNS option in the BNDUPD mes-
   sages to inform the partner server of the status of any DDNS updates
   associated with a lease binding. Failover servers MAY choose not to
   include the DDNS option in BNDUPD messages if there has been no
   change in the status of any DDNS update related to the lease binding.
   The partner server receiving BNDUPD messages containing the DDNS
   option SHOULD compare the status flags and the FQDN contained in the
   option data with the current DDNS information it has associated with
   the lease binding, and update its notion of the DDNS status accord-
   ingly.

   The initiating server MAY send a BNDUPD to its partner before the
   DDNS update has been successfully completed. If it does so, it SHOULD
   leave the 'C' bit in the Flags field clear, to indicate to the
   partner that the DDNS update may not be complete. When the DDNS
   update has been successfully acknowledged by the DNS server, the ini-
   tiating DHCP server SHOULD include the DDNS option in its next BNDUPD
   message about the binding, so that the partner server will be able to
   record the final status of the DDNS update. The initiating server
   SHOULD set the 'C' bit 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 a second BNDUPD once
   the DDNS update is complete. Other implementations will delay sending
   the partner a BNDUPD until the DDNS update has been acknowledged by
   the DNS server, or until some time-limit has elapsed, in order to
   avoid sending a second BNDUPD.

   The Domain Name field in the DDNS option contains the FQDN that will
   be associated with the A RR (if the 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 the client in its DHCP messages. The client may
   supply a hostname which it would like the 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 the client supplies, it may be
   configured with an FQDN to use for the client, or it may be



Droms, et. al.           Expires September 2003                [Page 38]

Internet Draft           DHCP Failover Protocol              March 2003


   configured to synthesize an FQDN. The responsive server SHOULD
   include the FQDN that it will be using in DDNS updates it initiates
   when it sends the DDNS option.

   Since the 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
   client FQDNs are identical by modifying the most-specific label in
   the FQDNs of some of the clients in an attempt to generate unique
   FQDNs for them (a process sometimes called "disambiguation").  Alter-
   natively, at sites which use some or all of the information which
   clients supply to form the FQDN, it's possible that a client's confi-
   guration may be changed so that it begins to supply new data.  The
   responsive server may react by removing the DNS 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 include the 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 allow the non-
   responsive partner to detect client configuration changes that change
   the hostname or FQDN data which the client includes in its DHCP
   requests.

5.12.3.  Adding RRs to the DNS

   A failover server which is going to perform DDNS updates SHOULD ini-
   tiate the DDNS update when it grants a new lease to a client. The
   non-responsive partner SHOULD NOT initiate a DDNS update when it
   receives the BNDUPD after the lease has been granted. The failover
   protocol ensures that only one of the partners will grant a lease to
   any individual client, so it follows that this requirement will
   prevent both partners from initiating updates simultaneously. The
   server initiating the update SHOULD follow the protocol in [FQDN].
   The server may be configured to perform an A RR update on behalf of
   its clients, or not. Ordinarily, a failover server will not initiate
   DDNS updates when it renews leases. In two cases, however, a failover
   server MAY initiate a DDNS update when it renews a lease to its
   existing client:

      1.  When the lease was granted before the server was configured to
          perform DDNS updates, the server MAY be configured to perform
          updates when it next renews existing leases. Since both
          servers are responsive to renewals in NORMAL state, it is not
          enough to simply require the non-responsive server to avoid a
          DNS update in this case.  The server which would be responsive



Droms, et. al.           Expires September 2003                [Page 39]

Internet Draft           DHCP Failover Protocol              March 2003


          to a DHCPDISCOVER from this client (even though the current
          request is a DHCPREQUEST/RENEW) is the server which should
          initiate the DDNS update.

      2.  If a server is in PARTNER-DOWN state, it can conclude that its
          partner is no longer attempting to perform an update for the
          existing client. If the remaining server has not recorded that
          an update for the binding has been successfully completed, the
          server MAY initiate a 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 the DHCP client.

5.12.4.  Deleting RRs from the DNS

   The failover server which makes an IP address FREE SHOULD initiate
   any DDNS deletes, if it has recorded that DNS records were added on
   behalf of the client.

   A server not in PARTNER-DOWN state "makes an IP address FREE" when it
   initiates a BNDUPD with 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 the IP address
   FREE".  Conversely, a server in PARTNER-DOWN state "makes an IP
   address FREE" when it sets the binding-status to FREE, since in
   PARTNER-DOWN state no communications is required with the partner.

   It is at this point that it should initiate the DDNS operations to
   delete RRs from the DDNS. Its partner SHOULD NOT initiate DDNS
   deletes for DNS records related to the lease binding as part of send-
   ing 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 that only one of the two partner
   servers will be able to make a lease FREE. The server making the
   lease FREE may be doing so while it is in NORMAL communication with
   its partner, or it may be in PARTNER-DOWN state. If a server is in
   PARTNER-DOWN state, it may be performing DDNS deletes for RRs which
   its partner added originally. This allows a single remaining partner
   server to assume responsibility for all of the DDNS activity which
   the two servers were undertaking.

   Another implication of this approach is that no DDNS RR deletes will
   be performed while either server is in COMMUNICATIONS-INTERRUPTED
   state, since no IP addresses are moved into the FREE state during
   that period.




Droms, et. al.           Expires September 2003                [Page 40]

Internet Draft           DHCP Failover Protocol              March 2003


5.13.  Reservations and failover

   Some DHCP servers support a capability to offer specific pre-
   configured IP addresses to DHCP clients.  These are real DHCP
   clients, they do 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 servers serving the same sub-
   net without using failover, the two DHCP server's need to have dis-
   joint IP address pools, but identical reservations for the DHCP
   clients.

   In a failover context, both servers need to be configured with the
   proper reservations in an identical manner, but if we stop there
   problems can occur around the edge conditions where reservations are
   made for an IP address that has already been leased to a different
   client.  Different servers handle this conflict in different ways,
   but the goal of the failover protocol is to allow correct operation
   with any server's approach to the normal processing of the DHCP pro-
   tocol.

   The general solution with regards to reservations is 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 as FREE (and thus available
   for its own allocation) and it MUST send it to the secondary server
   with the R bit set in the IP-flags option and the binding-status
   BACKUP.

   Note that this implies that a reserved IP address goes through the
   normal state changes from FREE to ACTIVE (and possibly back to FREE).
   The failover protocol supports this approach to reservations, i.e.,
   where the IP address undergoes the normal state changes of any IP
   address, but it can only be offered to the client for which it is
   reserved.  Other approaches to the support of reservations exist in
   some DHCP server implementations (e.g., where the IP address is
   apparently leased to a particular client forever, without any expira-
   tion).  The goal is for the failover protocol to support any of the
   usual approaches to reservations, both those that allow an IP address
   to go through different states when reserved, and those that don't.

   From the above, it follows that a reservation soley on the secondary
   will not necessarily allow the secondary to offer that address to
   client to whom it is reserved.  The reservation must also appear on
   the primary as well for the secondary to be able to offer the IP



Droms, et. al.           Expires September 2003                [Page 41]

Internet Draft           DHCP Failover Protocol              March 2003


   address to the client to which is is reserved.

   When the reservation on an IP address is cancelled, if the IP address
   is currently FREE and the server is the primary, or BACKUP and the
   server is the secondary, the server MUST send a BNDUPD to the other
   server with the binding-status FREE and the R bit clear.

5.14.  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 discussed briefly in RFC 1534 [RFC 1534].

   This capability has a negative interaction with the fundamental ele-
   ments of the failover protocol, in that an address handed out to a
   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 first hearing
   from a BOOTP device, because they may only interact once with the
   DHCP server and they have no notion of a lease expiration time.  Thus
   the entire concept of the MCLT and waiting the MCLT after entering
   PARTNER-DOWN state is defeated when dealing with BOOTP devices.

   With some restrictions, however, dynamic BOOTP devices can be sup-
   ported in a server on a subnet where failover is supported.  The only
   restriction (and it is not small) 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 of the IP
   addresses which were previously available for allocation by its fail-
   over partner.  Thus, the addresses allocated by the primary to the
   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 and has waited the MCLT after entering that state.
   Conversely, addresses available for allocation by the primary MUST
   NOT be used by the secondary even it is in PARTNER-DOWN state.  The
   reason for this is because one of those IP address could have been
   allocated by the secondary server to a BOOTP device, and the primary
   server would have no way of ever knowing that happened.

   Whenever a server sends BNDUPD message to its partner, if the client
   associated with the IP address is a BOOTP client, then the server
   MUST set the B bit in the IP-flags option.

   There is a very slight possibility that a BOOTP client could get an
   IP address on each server of a failover pair.  When these two servers
   eventually attempt to resolve this conflict, they SHOULD agree to
   disagree, since it is not possible to know which IP address the BOOTP



Droms, et. al.           Expires September 2003                [Page 42]

Internet Draft           DHCP Failover Protocol              March 2003


   client will actually use -- indeed, it could use both.  Operator
   intervention will, in general, be required to rectify this situation.
   Fortunately, it is extremely unlikely to ever actually occur.

5.15.  Guidelines for selecting MCLT

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

5.15.1.  Short MCLT

   A short MCLT value will mean that after entering PARTNER-DOWN state,
   a server will only have to wait a short time before it can start
   allocating its partner's IP addresses to DHCP clients.  Furthermore,
   it will only have to wait a short time after the expiration of a
   lease on an IP address before it can reallocate that IP address to
   another DHCP client.

   However the downside of a short MCLT value is that the initial lease
   interval that will be offered to every new DHCP client will be short,
   which will cause increased traffic as those clients will need 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 the MCLT after the server has been in
   COMMUNICATIONS-INTERRUPTED for around the desired client lease
   period.  If a server stays in COMMUNICATIONS-INTERRUPTED for that
   long, then the leases it hands out will be short and that will
   increase the load on that server, possibly causing difficulty.

5.15.2.  Long MCLT

   A long MCLT value will mean that the initial lease period will be
   longer and the time that a server in COMMUNICATIONS-INTERRUPTED state
   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 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 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.

5.16.  What is sent in response to an UPDREQ or UPDREQALL message?

   In section 7.3, the UPDREQ message is defined, and it says that the



Droms, et. al.           Expires September 2003                [Page 43]

Internet Draft           DHCP Failover Protocol              March 2003


   receiving server sends to the requesting server "all of the binding
   database information that it has not already seen".  In section
   7.4.2, the UPDREQALL message is defined, and it says that the receiv-
   ing server sends to the requesting server "all binding database
   information".

   Both of these statements need further elaboration.

   First, for the UPDREQ message, the information to be sent in BNDUPD
   messages concerns "all of the binding database information it has not
   already seen".  Since every BNDUPD is acked by the receiving server,
   the sending server need only keep track of which IP addresses have
   binding database changes not yet seen by the partner, and when they
   are finally acked by the partner it can record that.  Thus, at any
   time, it knows which IP addresses have unacked binding database
   information.  This is less simple when, across reconfigurations of
   the servers, an IP address can change the failover partner to which
   it is associated.  In that case, it is important to reset the indica-
   tion that the partner has seen this binding information.  See section
   5.17, below, for a more complete discussion of this issue.

   Second, in the event that a failover server's binding database infor-
   mation is restored from a backup, it will be partially out of date.
   In this case, its partner's indication of which binding database
   information the restored server has seen will be also be out of date.

   The solution to this problem is for a server which is connecting with
   its partner to check the partner's last communicated time, and if it
   is very much ahead of its own last communicated time, go to into
   RECOVER state and transmit an UPDREQALL to allow it to refresh its
   state.  See section 9.3.2, step 5.  If the partner's last communi-
   cated time is very much behind its own record of when it last commun-
   icated with the partner, then it SHOULD invalidate its information on
   which binding database information the partner server knows, so that
   it will send all of its relevant binding database information to the
   partner.

   Third, in the event that a server receives a UPDREQALL message, what
   constitutes "all binding database information"?  At first glance this
   would seem to be information on every configured IP address in the
   server.  While this would be technically correct, it may impose a
   serious and unacceptable performance penalty on servers which have
   millions of configured IP addresses.  What can be done to lessen the
   data that must be sent for an UPDREQALL?

   When sending "all binding database information", if the sending
   server sends only information concerning IP addresses which have been
   at some time associated with clients, it will send enough information



Droms, et. al.           Expires September 2003                [Page 44]

Internet Draft           DHCP Failover Protocol              March 2003


   to satisfy the needs of the failover protocol.  It need not send
   information on any IP addresses that have never been used, since
   presumably they will be initialized as available to the primary
   server (i.e.  FREE) on any server employing failover.

5.17.  How do you determine that your partner is "up to date" for
specific binding?

   Throughout this document, one server is assumed to know for each IP
   address binding whether or not its partner is "up to date" for that
   binding.  There are some subtle issues involved in recording this "up
   to date" information about a specific binding.

   In a steady state world, it would suffice to have a single bit in the
   binding database to represent the information about whether the
   partner was or was not up to date.

   In a more complex environment a configuration change affecting a par-
   ticular IP address may change the failover endpoint with which it is
   associated, and if this should happen, any "up to date" bit which is
   written into the bindings database will be accurate for only the pre-
   vious failover endpoint, but not the current failover endpoint.  If
   failover is disabled and then re-enabled (and the "up to date" bits,
   if used, are not cleared) problems can also occur.

   A server MUST have be able to relate the "up to date" condition to a
   particular failover endpoint and even a particular instantiation of
   that failover endpoint.  The techniques to do this are implementation
   dependent.

   In addition, section 7.4 requires that a server be able to remember
   that an UPDREQALL message has been received and to treat every UPDREQ
   message as an UPDREQALL message until the first UPDDONE message is
   sent.  One way to do this is to clear all of the "up to date" indica-
   tions for an entire failover endpoint upon receipt of an UPDREQALL
   message, thereby ensuring that every active binding will be sent to
   the partner whether through the completion of this UPDREQALL or
   through processing of a subsequent UPDREQ message.  This is actually
   better than remembering that an UPDREQALL was received and turning
   every UPDREQ into an UPDREQALL, since any information sent in an
   incomplete UPDREQALL (or subsequent UPDREQ messages turned into "all"
   messages) will be remembered and not re-sent.

6.  Common Message Format

   This section discusses the common message format that all failover
   messages have in common, including the message header format as well
   as the common option format.  See section 12 for the the definitions



Droms, et. al.           Expires September 2003                [Page 45]

Internet Draft           DHCP Failover Protocol              March 2003


   of the specific options used in the failover protocol.

6.1.  Message header format

   The options contained in the payload data section of the failover
   message all use a two byte option number and two byte length format.

   All failover protocol messages are sent over the TCP connection
   between failover endpoints and encoded using a message format
   specific to the failover protocol.

   There exists a common message format for all failover messages, which
   utilizes the options in a way similar to the DHCP protocol.  For each
   message type, some options are required and some are optional.  In
   addition, when a message is received any options that are not under-
   stood by the receiving server MUST be ignored.

   All of the fields in the fixed portion of the message MUST be filled
   with correct 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)             |
   +---------------------------------------------------------------+
   |                    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 the length of the message in bytes. It includes the two byte
   message length itself.  The maximum length is 2048 bytes.  The
   minimum length is 12.






Droms, et. al.           Expires September 2003                [Page 46]

Internet Draft           DHCP Failover Protocol              March 2003


   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 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 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      request 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 messages that MUST be sup-
   ported by every server, and if a server receives a message in the
   range of 0-127 that it doesn't understand, it MUST close the TCP con-
   nection.  The 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 range that it does not understand it SHOULD ignore the message.

   payload offset - 1 byte

   The byte offset of the Payload Data, from the beginning of the
   failover message header. The value for the current protocol version
   (version 1) is 8.

   time - 4 bytes, network byte order

   The absolute time in GMT when the message was transmitted,
   represented as seconds elapsed since Jan 1, 1970 (i.e., similar to
   the ANSI C time_t time value representation).  While the ANSI C
   time_t value is signed, the value used in this specification is
   unsigned.

   A server SHOULD set this time as close to the actual transmission of
   the message as possible.




Droms, et. al.           Expires September 2003                [Page 47]

Internet Draft           DHCP Failover Protocol              March 2003


   xid - 4 bytes, network byte order

   This is the transaction id of the failover message. The sender of a
   failover protocol message is responsible for setting this number, and
   the receiver of the message copies the number over into any response
   message, treating it as opaque data. The sender MUST ensure that
   every message sent from a particular failover endpoint over the
   associated TCP connection has a unique transaction id.

   For failover 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 to determine the
   corresponding request message.

   Request messages where the XID is used in the corresponding response
   messages are: POOLREQ, BNDUPD, CONNECT, UPDREQALL, and UPDREQ. The
   corresponding response messages are POOLRESP, BNDACK, CONNECTACK,
   UPDDONE, and UPDDONE, respectively.

   As requests/responses don't survive connection reestablishment, XIDs
   only need to be unique during a specific connection.


   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 two byte
   option codes and two byte option lengths.  The option codes are in a
   namespace which is unique to the failover protocol.

   The maximum length of the payload data in octets is 2048 less the
   size of the header, i.e., the maximum message length is 2048 octets.

6.2.  Common option format

   The options contained in the payload data section of the failover
   message all use a two byte option number and two byte length format.

   The option numbers are drawn from an option number space unique to
   the failover protocol.  All of the message types share a common
   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 and server
   messages, the options in failover message are ordered.  That is, for



Droms, et. al.           Expires September 2003                [Page 48]

Internet Draft           DHCP Failover Protocol              March 2003


   some messages the order in which the options appear in the payload
   data area is significant.  The messages for which option ordering is
   significant explicitly describe the ordering requirements.  If no
   ordering requirements are mentioned, then the order is not signifi-
   cant for that message.

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

   The time value is an unsigned 32 bit integer in network byte order
   giving the number of seconds since 00:00 UTC, 1st January 1970. This
   can be converted to an NTP timestamp by adding decimal 2208988800.
   This time format will not wrap until the year 2106.  Until sometime
   in 2038, it is equal to the ANSI C time_t value (which is a signed 32
   bit value and will overflow into a negative number in 2038).

   Options should appear once only in each message (except for BNDUPD
   and BNDACK messages where bulking is used, see section 6.3 for
   details.)  An option that appears twice is not concatenated, but
   treated as an error.

   Specific option values are described in section 12.

   See section 13 for how to define additional options.

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

   Implementations of this protocol MAY send multiple binding update
   transactions in one BNDUPD message, where a binding update transac-
   tion is defined as the set of options which are associated with the
   update of a 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 which contains status for the multiple
   binding update transactions contained in the BNDUPD message.

   In the discussion of sending and receiving BNDUPD messages in section
   7.1 and BNDACK messages in section 7.2, each BNDUPD message and
   BNDACK message is assumed to contain a single binding update transac-
   tion in order to reduce the complexity of the discussions in section
   7.

   Multiple binding update transactions MAY be batched together in one
   BNDUPD protocol message with the data sets for the individual tran-
   sactions delimited by the assigned-IP-address option, which MUST



Droms, et. al.           Expires September 2003                [Page 49]

Internet Draft           DHCP Failover Protocol              March 2003


   appear first in the option set for each transaction.  Ordering of
   options between the assigned-IP-address options is not significant.
   This is illustrated in the following schematic representation:


       Non-IP Address/Non-client specific options first
       assigned-IP-address option for the first IP address
           Options pertaining to first address, including at least the
           binding-status option and others as required.
       assigned-IP-address option for the second IP address
           Options pertaining to second address, including at least the
           binding-status option and others as required.
       ...
       Trailing options (message digest).


   There MUST be a one-to-one correspondence between BNDUPD and BNDACK
   messages, and every BNDACK message MUST contain status for all of the
   binding update transactions in the corresponding BNDUPD message.

   The BNDACK message corresponding to a BNDUPD message MUST contain
   assigned-IP-address options for all of the binding update transac-
   tions in the BNDUPD message.  Thus, every BNDACK message contains
   exactly the same assigned-IP-address options as does its correspond-
   ing BNDUPD message.  The order of the assigned-IP-address options
   MAY, however, be different.  Here is a schematic representation of a
   BNDACK:


       Non-IP Address/Non-client specific options first
       assigned-IP-address option for the first IP address
           If rejected, reject-reason option and message option.
       assigned-IP-address option for the second IP address
           If rejected, reject-reason option and message option.
       ...
       Trailing options (message digest).


   In case the server chooses to reject some or all of the IP address
   binding information in a BNDUPD message in a BNDACK reply, the BNDACK
   message MUST contain a reject-reason option following every failed
   assigned-IP-address option in order to indicate that the binding
   update transaction for that IP address was not accepted and why.  As
   with a BNDACK message containing a single binding update transaction,
   an assigned-IP-address option without any associated reject-reason
   option indicates a successful binding update transaction.





Droms, et. al.           Expires September 2003                [Page 50]

Internet Draft           DHCP Failover Protocol              March 2003


7.  Protocol Messages

   This section contains the detailed definition of the protocol mes-
   sages, including the information to include when sending the message,
   as well as the actions to take upon receiving the message.  The mes-
   sage type for each message appears as [n] in the heading for the mes-
   sage (see section 6.1).

7.1.  BNDUPD message [3]

   The binding update (BNDUPD) message is used to send the binding data-
   base changes (known as binding update transactions) to the 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 the failover protocol exists to determine whether the
   partner server is able to communicate or not, and to enable the
   partners to exchange BNDUPD/BNDACK messages in order to keep their
   binding databases in stable storage synchronized.

   The rest of this section is written as though every BNDUPD message
   contains only a single binding update transaction in order to reduce
   the complexity of the discussion.  See section 6.3 for information on
   how to create and process BNDUPD and BNDACK messages which contain
   multiple binding update transactions.  Note that while a server MAY
   generate BNDUPD messages with multiple binding update transactions,
   every server MUST be 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 following table summarizes the various options for the BNDUPD
   message.


















Droms, et. al.           Expires September 2003                [Page 51]

Internet Draft           DHCP Failover Protocol              March 2003




                                        binding-status            BACKUP
                                                                  RESET
                                                                  ABANDONED
   Option                        ACTIVE     EXPIRED    RELEASED   FREE
   ------                        ------     -------    --------   ----
   assigned-IP-address (3)       MUST       MUST       MUST       MUST
   IP-flags                      MUST(4)    MUST(4)    MUST(4)    MUST(4)
   binding-status                MUST       MUST       MUST       MUST
   client-identifier             MAY        MAY        MAY        MAY(2)
   client-hardware-address       MUST       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) MUST if server is performing dynamic DNS for this IP address, else
       MUST NOT.
   (2) MUST NOT if binding-status is ABANDONED.
   (3) assigned-IP-address MUST be the first option for an IP address
   (4) IP-flags option MUST appear if any flags are non-zero, else it
       MAY appear.

             Table 7.1-1: Options used in a BNDUPD message


7.1.1.  Sending the BNDUPD message

   A 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
   server writes its stable storage, a BNDUPD message SHOULD be gen-
   erated.  This will often be the result of the processing of a DHCP
   client request, but it might also be the result of a successful
   dynamic DNS update operation.  Stable storage updates due to BNDUPD
   or BNDACK messages SHOULD NOT result in additional BNDUPD messages.

   BNDUPD (and BNDACK) messages refer to the binding-status of the IP
   address, and this protocol defines a series of binding-statuses, dis-
   cussed in more detail below.  Some servers may not support all of
   these binding-statuses, and so in those cases they will not be sent.
   Upon receipt of a BNDUPD message which contains an unsupported
   binding-status, a reasonable interpretation should be made (see sec-
   tion 5.10).



Droms, et. al.           Expires September 2003                [Page 52]

Internet Draft           DHCP Failover Protocol              March 2003


   All BNDUPD messages MUST contain the IP address of the binding update
   transaction in the assigned-IP-address option.

   All binding update transactions MUST contain an IP-flags option if
   the value of any of the flags would be non-zero.  The IP-flags option
   MAY be omitted if all of the flags that it contains are zero.  The
   IP-flags option contains a flag which indicates if the IP address is
   currently reserved on the server sending the BNDUPD message.  It also
   contains a flag which indicates that the lease is associated with a
   client that used the BOOTP protocol (as opposed to the DHCP protocol)
   to interact with the DHCP server.

   All binding update transactions contain a binding-status option, and
   it will have one of the values found in section 5.11.  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 information should or
   should not appear with each binding-status in a binding update 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 binding:


      o lease-expiration-time

        The lease-expiration-time option MUST appear, and be set to the
        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



Droms, et. al.           Expires September 2003                [Page 53]

Internet Draft           DHCP Failover Protocol              March 2003


        The potential-expiration-time option MUST appear, and be set to
        a value beyond that of the lease-expiration time.  This is the
        value that is ACKed by the BNDACK message.  A server sending a
        BNDUPD message MUST be able to recover the 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 applies to 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 appear, and for some a client MUST NOT
     appear.

     A client is identified in 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, and contains
     the hardware type and chaddr information from the DHCP request
     packet.  A failover client-identifier option MUST appear any time
     that a client appears in a BNDUPD message if and only if that
     client used a DHCP client-identifier option when communicating with
     the DHCP server.  See section 12.5 and 12.4 for details of how to
     construct these two options from a DHCP request packet.

   o start-time-of-state

     The start-time-of-state SHOULD appear.  It is set to the time at
     which this IP address first took on the state that corresponds to
     the current value of binding-status.

   o last-transaction-time

     The last-transaction-time value SHOULD appear.  This is the time at
     which this DHCP server last received a packet from 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



Droms, et. al.           Expires September 2003                [Page 54]

Internet Draft           DHCP Failover Protocol              March 2003


     of the DHCP client represented by the client-identifier or client-
     hardware-address, then it should include a DDNS option containing
     the domain name and status of any dynamic DNS operations enabled.

   o client-request-options

     If the BNDUPD was triggered by a request from a DHCP client (typi-
     cally those with binding-status of ACTIVE and RELEASED), then the
     server SHOULD include options of interest to a failover partner
     from the client's request packet in the client-request-options for
     transmission to its partner (see section 12.8).

     A server sending a BNDUPD SHOULD remember the "interesting" options
     or the information that would appear in an "interesting" option for
     transmission at a time when the BNDUPD is not closely associated
     with a DHCP client request.

     A server SHOULD send the following "interesting" options.  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 be sent as part of
     a BNDUPD.


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

         12              host-name
         81              client-FQDN [FQDN]
         82              relay-agent-information [RFC 3046]
         77              user-class [RFC 3004]
         60              vendor-class-identifier
         118             subnet-selection [RFC 3011]

           Table 7.1.1-2: Options which SHOULD be sent in
           the client-request-options option in a BNDUPD message.


   o client-reply-options

     If the BNDUPD was triggered by a request from a DHCP client (typi-
     cally those with binding-status of ACTIVE and RELEASED), then the
     server SHOULD include options of interest to a failover partner
     from the server's DHCP reply packet in the client-reply-options for
     transmission to its partner (see section 12.7).

     A server sending a BNDUPD SHOULD remember the "interesting" options



Droms, et. al.           Expires September 2003                [Page 55]

Internet Draft           DHCP Failover Protocol              March 2003


     or the information that would appear in an "interesting" option for
     transmission at a time when the BNDUPD is not closely associated
     with a DHCP client request.

     A server SHOULD send the following "interesting" options.  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 be sent as part of
     a BNDUPD.


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

         58              renewal-time
         59              rebinding-time

           Table 7.1.1-3: Options which SHOULD be sent in
           the client-reply-options option in a BNDUPD message.


   The BNDUPD message SHOULD be sent as soon as possible from the time
   that the DHCP client received a response and the lease bindings data-
   base is written on stable storage.

7.1.2.  Receiving the BNDUPD message

   When a server receives a BNDUPD message, it needs to decide how to
   process the binding update transaction it contains and whether that
   transaction represents a conflict of any sort. The conflict resolu-
   tion process MUST be used on the receipt of every BNDUPD message, not
   just those that are received while in POTENTIAL-CONFLICT state, in
   order to increase the robustness of the protocol.

   There are three sorts of conflicts:

      o Two clients, one IP address conflict

        This is the duplicate IP address allocation conflict. There are
        two different clients each allocated the same address.  See sec-
        tion 7.1.3 for how to resolve this conflict.

      o Two IP addresses, one client conflict

        This conflict exists when a client on one server is associated
        with a one IP address, and on the other server with a different
        IP address in the same or a related subnet. This does not refer



Droms, et. al.           Expires September 2003                [Page 56]

Internet Draft           DHCP Failover Protocol              March 2003


        to 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 different IP address on the other
        server.

        This conflict may or may not be a problem for a given DHCP
        server implementation.  In the event that a DHCP 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 lease information which has the latest client-
        last-transaction-time.

      o binding-status conflict

        This is 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

   When analyzing a BNDUPD message from a partner server, if there is
   insufficient information in the BNDUPD to process it, then reject the
   BNDUPD with reject-reason 3: "Missing binding information".

   If the IP address in the BNDUPD is not an IP address associated with
   the failover endpoint which received the BNDUPD message, then reject
   it with reject-reason 1: "Illegal IP address (not part of any address
   pool)".

   IP addresses undergo binding status changes for several reasons,
   including receipt and processing of DHCP client requests, administra-
   tive inputs and receipt of BNDUPD messages.  Every DHCP server needs
   to respond to DHCP client requests and administrative inputs with
   changes to its internal record of the binding-status of an IP
   address, and this response is not in the scope of the failover proto-
   col.  However, the receipt of BNDUPD messages implies at least a pos-
   sible change of the binding-status for an IP address, and must be
   discussed here.  See section 7.1.2 for general actions to take upon
   receipt of a BNDUPD message.

   Every BNDUPD message SHOULD contain a client-last-transaction-time
   option, which MUST, if it appears, be the time that the server last
   interacted with the DHCP client.  It MUST NOT be, for instance, the
   time that the lease 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



Droms, et. al.           Expires September 2003                [Page 57]

Internet Draft           DHCP Failover Protocol              March 2003


   no client-last-transaction-time option in the BNDUPD message.

   The list in Figure 7.1.3-1 is indexed by the binding-status that a
   server receives in a BNDUPD message.  In many cases, the binding-
   status of an IP address within the receiving server's data storage
   will have an affect upon the checks performed prior to accepting the
   new binding-status in a BNDUPD message.

   In Figure 7.1.3-1, to "accept" a BNDUPD means to update the server's
   bindings database with the information contained in the BNDUPD and
   once that update is complete, send a BNDACK message corresponding to
   the BNDUPD message.  To "reject" a BNDUPD means to respond to the
   BNDUPD with a BNDACK with a reject-reason option included.

   When interpreting the information in the following table (Figure
   7.1.3-1), for those rules that are listed with "time" -- if a BNDUPD
   doesn't have a client-last-transaction-time value, then it MUST NOT
   be considered later than the 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 MUST be
   considered later than the server's.





























Droms, et. al.           Expires September 2003                [Page 58]

Internet Draft           DHCP Failover Protocol              March 2003



                        binding-status in received BNDUPD
       binding-status
       in receiving                                  FREE       RESET
       server          ACTIVE   EXPIRED   RELEASED   BACKUP   ABANDONED

       ACTIVE          accept(5) 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           time(3)   accept    accept     accept    accept
       ABANDONED       reject(4) reject(4) reject(4)  reject(4) accept

       time(1): If the client-last-transaction-time in the BNDUPD
       is later than the client-last-transaction-time in the
       receiving server's binding, accept it, else reject it.

       time(2): If the current time is later than the receiving
       servers' lease-expiration-time, accept it, else reject it.

       time(3): If the client-last-transaction-time in the BNDUPD
       is later than the start-time-of-state in the receiving server's
       binding, accept it, else reject it.

       (1,2,3): If rejecting, use reject reason 15: "Outdated binding
       information".

       (4): Use reject reason 16: "Less critical binding information".

       (5): If the clients in a BNDUPD message and in a receiving
       server's binding differ, then if the receiving server is a
       secondary accept it, else reject it with a reject reason of 2:
       "Fatal conflict exists: address in use by other client".

                Figure 7.1.3-1:  Accepting BNDUPD messages



   If the IP address in the BNDUPD message has the R flag set in the
   IP-flags option, indicating it is a reserved IP address, and if the
   binding-status in the BNDUPD is BACKUP, then if the receiving server
   does not show the IP address as reserved, the receiving server SHOULD
   reject the BNDUPD using reject reason 19: "IP not reserved on this
   server".

7.1.4.  Accepting the BNDUPD message

   When accepting a BNDUPD message, the information contained in the



Droms, et. al.           Expires September 2003                [Page 59]

Internet Draft           DHCP Failover Protocol              March 2003


   client-request-options and client-reply-options SHOULD be examined
   for any information of interest to this server.  For instance, a
   server which wished to detect changes in client specified host names
   might want to examine and save information from the host-name or
   client-FQDN options.  Servers which expect to utilize information
   from the relay-agent-information option SHOULD store this informa-
   tion.

7.1.5.  Time values related to the BNDUPD message

   There are four time values that MAY be sent in a BNDUPD message.

      o lease-expiration-time

        The time that the server gave to the client, i.e., the time that
        the server 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 the 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 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 as the
   potential-expiration-time.  Moreover, each server must remember what
   it has acked to the *other* server as the most recent potential-
   expiration-time from that server.

   Remember that each server sends a potential-expiration-time and
   receives an ACK for that as well as receiving a potential-
   expiration-time and needing to remember what it has acked for that.

   While they don't have to be named in any particular way, the times
   that a server needs to remember for every IP address in order to
   implement the failover protocol are:

      o lease-expiration-time




Droms, et. al.           Expires September 2003                [Page 60]

Internet Draft           DHCP Failover Protocol              March 2003


        The time that a server gave to the DHCP client.  A DHCP server
        needs to remember this time already, just to be a DHCP server.
        A server SHOULD update this time with the lease-expiration time
        received from a partner in a BNDUPD if the received lease-
        expiration time is later than the lease-expiration time recorded
        for this binding.

      o sent-potential-expiration-time

        The latest time sent to the partner for a potential-expiration-
        time.

      o acked-potential-expiration-time

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

      o received-potential-expiration-time

        The latest time that this server has ever received as a
        potential-expiration-time from its partner in a BNDUPD that this
        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 these times used?

   First, let's look at the time that a DHCP server can offer to a DHCP
   client.  A server can offer to a DHCP client a time that is no longer
   than the MCLT beyond the max( received-potential-expiration-time,
   acked-potential-expiration-time).  One might think that the server
   should be able to offer only the 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 for a while and then fails, if the secondary can then renew
   the client for only the MCLT beyond the acked-potential-expiration-
   time, then the secondary will only be able to renew the client for
   the MCLT, because the secondary has never sent a BNDUPD packet to the
   primary concerning this IP address and client, and so its acked-
   potential-expiration-time is zero.

   However, since the secondary is allowed to renew the client with the
   MCLT beyond the max( received-potential-expiration-time, acked-
   potential-expiration-time), then the secondary can usually renew the
   client for the full lease period, at least for the first renew it



Droms, et. al.           Expires September 2003                [Page 61]

Internet Draft           DHCP Failover Protocol              March 2003


   sees from the client, since the received-potential-expiration-time is
   generally longer than the client's desired lease interval.  The
   difference in renew times could make a big difference in server load
   on the secondary in this case.

   What are the consequences of allowing a server to offer a DHCP client
   a lease term 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 that server has to wait before reallocating expired leases.
   With this approach, when a server goes into PARTNER-DOWN state, it
   must wait the MCLT beyond 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 to another DHCP client.   One might
   normally think that it needed to wait only the MCLT beyond 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 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
   added into the expression, since the partner could have used those
   times as part of its own lease time calculation.

   Thus 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 [4]

   A server sends a binding acknowledgement (BNDACK) message when it has
   processed a BNDUPD message 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 to both accept
   or reject a BNDUPD message.  A BNDACK message which contains a
   reject-reason option is a rejection of the corresponding BNDUPD mes-
   sage.

   In order to reduce the complexity of the discussion, the rest of this
   section is written as though every BNDUPD message contains only a
   single binding update transaction and thus every corresponding BNDACK
   message would also contain reply information about only a single
   binding update transaction.  See section 6.3 for information on how
   to create and process BNDUPD and BNDACK messages which contain multi-
   ple binding update transactions.



Droms, et. al.           Expires September 2003                [Page 62]

Internet Draft           DHCP Failover Protocol              March 2003


   Note that while a server MAY generate BNDUPD messages with multiple
   binding update transactions, every server MUST be able to process a
   BNDUPD message which contains multiple binding update transactions
   and generate the corresponding BNDACK messages with status for multi-
   ple binding update transactions.  If a server does not ever create
   BNDUPD messages which contain multiple binding update transactions,
   then it does not need to be able to process a received BNDACK message
   with multiple binding update transactions.  However, all servers MUST
   be able to create BNDACK messages which deal with multiple binding
   update transactions received in a BNDUPD message.

   Every BNDUPD message that is received by a server MUST be responded
   to with a corresponding BNDACK message.  The receiving server SHOULD
   respond quickly to every BNDUPD message but 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 a BNDUPD message, while DHCP clients frequently
   have strict time constraints.

   A BNDACK message can only be sent in response to a BNDUPD message
   using the same TCP connection from which the BNDUPD message was
   received, since the XID's in BNDUPD messages are guaranteed unique
   only during the life of 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 those messages, since it can be sure
   that the partner will resend them when they are next in communica-
   tions (albeit with a different XID), or it MAY instead choose to pro-
   cess those BNDUPD messages, but it MUST NOT send any BNDACK messages
   in response.

   The following table summarizes the options for the BNDACK message.




















Droms, et. al.           Expires September 2003                [Page 63]

Internet Draft           DHCP Failover Protocol              March 2003




   Option                        accept       reject
   ------                        ------       ------
   assigned-IP-address  (1)      MUST         MUST
   IP-flags                      SHOULD NOT   SHOULD NOT
   binding-status                SHOULD NOT   SHOULD NOT
   client-identifier             SHOULD NOT   SHOULD NOT
   client-hardware-address       SHOULD NOT   SHOULD NOT
   reject-reason                 SHOULD NOT   MUST
   message                       SHOULD NOT   SHOULD
   lease-expiration-time         SHOULD NOT   SHOULD NOT
   potential-expiration-time     SHOULD NOT   SHOULD NOT
   start-time-of-state           SHOULD NOT   SHOULD NOT
   client-last-trans.-time       SHOULD NOT   SHOULD NOT
   DDNS(1)                       SHOULD NOT   SHOULD NOT

   (1) assigned-IP-address MUST be the first option for an IP address

              Table 7.2-1: Options used in a BNDACK message


7.2.1.  Sending the BNDACK message

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

   The assigned-IP-address option from the BNDUPD message MUST be
   included in the BNDACK message.  Any additional options from the
   BNDUPD message SHOULD NOT appear in the BNDACK message.  Note that
   any information sent in options (e.g, a later lease-expiration time)
   in the BNDACK message MUST NOT be assumed to necessarily be recorded
   in the stable storage of the server who receives the BNDACK message
   because there is no corresponding ACK of the BNDACK message.  Any
   information that SHOULD be recorded in the partner server's stable
   storage MUST be transmitted in a subsequent BNDUPD.

   If the server is accepting the BNDUPD, the BNDACK message includes
   only the assigned-IP-address option.  If the server is rejecting the
   BNDUPD, the additional option reject-reason MUST appear in the BNDACK
   message, and the message option SHOULD appear in this case containing
   a human-readable error message describing in some detail the reason
   for the rejection of the BNDUPD message.

   If the server rejects the BNDUPD message with a BNDACK and a reject-
   reason option, it may be because the server believes that it has
   binding information that the other server should know.  A server
   which is rejecting a BNDUPD may initiate a BNDUPD of its own in order



Droms, et. al.           Expires September 2003                [Page 64]

Internet Draft           DHCP Failover Protocol              March 2003


   to update its partner with what it believes is 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 initiation of a 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 BNDACK message

   When a server receives a BNDACK message, if it doesn't contain a
   reject-reason option that means that the BNDUPD message was accepted,
   and the server which sent the BNDUPD SHOULD update its stable storage
   with the potential-expiration-time value sent in the BNDUPD message.

   If the BNDACK message contains a reject-reason option, that means
   that the BNDUPD was rejected.  There SHOULD be a message option in
   the BNDACK giving a text reason for the rejection, and the server
   SHOULD log the message in some way.  The server MUST NOT immediately
   try to resend the BNDUPD message as there is no reason to believe the
   partner won't reject it a second time.  However a server MAY choose
   to send another BNDUPD at some future time, for instance when the
   server next processes an update request from its partner.

7.3.  UPDREQ message [9]

   The update request (UPDREQ) message is used by one server to request
   that its partner send it all of the binding database information that
   it has not already seen.   Since each server is required to keep
   track at all times of the binding information the other server has
   ACKed, one server can request transmission of all un-ACKed binding
   database information held by the other server by using the UPDREQ
   message.

   The UPDREQ message is used whenever the sending server cannot proceed
   before it has processed all previously un-ACKed binding update infor-
   mation, since the UPDREQ message should yield a corresponding UPDDONE
   message.  The UPDDONE message is not sent until the server that sent
   the UPDREQ message has responded to all of the BNDUPD messages gen-
   erated by the UPDREQ message with BNDACK messages (they may either be
   accepted or rejected by the BNDACK messages, but they MUST have been
   responded to). Thus, the sender of 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, Failover Endpoint States, for the details of when the
   UPDREQ message is sent.




Droms, et. al.           Expires September 2003                [Page 65]

Internet Draft           DHCP Failover Protocol              March 2003


7.3.1.  Sending the UPDREQ message

   The UPDREQ message has no message specific options.

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 sent as undistinguished BNDUPD messages.

   However, the server which received and is processing the UPDREQ mes-
   sage MUST track the BNDACK messages that correspond to the BNDUPD
   messages triggered by the UPDREQ message and, when they are all
   received, the server MUST send an UPDDONE message.

   The server processing the UPDREQ message and sending BNDUPD messages
   to its partner SHOULD only track the BNDUPD and BNDACK message pairs
   for unACKed binding database changes that were present upon the
   receipt of the UPDREQ message.  A server which has received an UPDREQ
   message SHOULD send BNDUPD messages for binding database changes 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 message.  If some additional binding
   database changes end up becoming part of the set of BNDUPD messages
   considered as part of the UPDREQ (due to whatever algorithm the
   server uses to scan its bindings database for unacked changes) it
   will probably not cause any difficulty, but a server MUST NOT attempt
   to include all such later BNDUPD messages in the accounting for the
   UPDREQ in order to be able to transmit an UPDDONE message.

   When queuing up the BNDUPD messages for transmission to the sender of
   the UPDREQ message, the server processing the UPDREQ message MUST
   honor the value returned in the max-unacked-bndupd option in the CON-
   NECT or CONNECTACK message that set up the connection with the send-
   ing server.  It MUST NOT send more BNDUPD messages without receiving
   corresponding BNDACKs than the value returned in max-unacked-bndupd.
   (See section 8 for more details.)

7.4.  UPDREQALL message [7]

   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.  This message is used to allow one server to recover from a
   failure of stable storage 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



Droms, et. al.           Expires September 2003                [Page 66]

Internet Draft           DHCP Failover Protocol              March 2003


   its binding update information is restored, and it knows that all of
   that information is restored when an UPDDONE message is received.

   See section 9, Protocol state transitions, for the details of when
   the UPDREQALL message is sent.

   The UPDREQALL message has no message specific options.

7.4.1.  Sending the UPDREQALL message

   The UPDREQALL is sent.

7.4.2.  Receiving the UPDREQALL message

   A server receiving an UPDREQALL message MUST send all binding data-
   base information to the sending server.  See section 5.16 for details
   of what might actually comprise "all binding database information".

   A server receiving an UPDREQALL message MUST remember that such a
   message has been received, ensure that all binding information extant
   at that point is sent to the partner prior to any UPDDONE message
   being sent to that partner.  One way to do this is to remember the
   receipt of an UPDREQALL message and to and treat every subsequent
   UPDREQ message as an UPDREQALL message until it sends the first
   UPDDONE message after receipt of the UPDREQALL message.  This
   requirement exists because communications may fail and become re-
   established between the two servers, and the specific conditions
   which provoked the UPDREQALL message may not longer exist even though
   the UPDREQALL message may not yet have completed.  See section 5.17
   for information on a more efficient way to meet the above require-
   ment.

   These changes are sent as undistinguished BNDUPD messages. Otherwise
   the processing is the same as for the UPDREQ message.  See section
   7.3.2 for details.

7.5.  UPDDONE message [8]

   The update done (UPDDONE) message is used by a server receiving an
   UPDREQ or UPDREQALL message to signify that it has sent all of the
   BNDUPD messages requested by the UPDREQ or UPDREQALL request and that
   it has received a BNDACK for each of those messages.

   While a BNDACK message MUST have been received for each BNDUPD mes-
   sage prior to the transmission of the UPDDONE message, this doesn't
   necessarily mean that all of the BNDUPD messages were accepted, only
   that all of them were responded to with a BNDACK message.  Thus, a
   NAK (comprised of a BNDACK message containing a reject-reason option)



Droms, et. al.           Expires September 2003                [Page 67]

Internet Draft           DHCP Failover Protocol              March 2003


   could be used to reject a BNDUPD, but for the purposes of the UPDDONE
   message, such NAK would count as a response to the associated BNDUPD
   message, and would not block the eventual transmission of the UPDDONE
   message.

   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.

7.5.1.  Sending the UPDDONE message

   The UPDDONE message SHOULD be sent as soon as the last BNDACK message
   corresponding to a BNDUPD message requested by the UPDREQ or
   UPDREQALL is received from the server which sent the UPDREQ or
   UPDREQALL.  The XID of the UPDDONE message MUST be the same as the
   XID of the corresponding UPDREQ or UPDREQALL message.

7.5.2.  Receiving the UPDDONE message

   A server receiving the UPDDONE message knows that all of the informa-
   tion that 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 the receipt 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 [1]

   The pool request (POOLREQ) message is used by the secondary server to
   request an allocation of IP addresses from the primary server.   It
   MUST be sent by a secondary server to a 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 from the secondary to the primary
   whenever the secondary makes a transition into NORMAL state.  It
   SHOULD periodically be resent in order that any change in the number
   of available IP addresses on the primary be reflected in the pool on
   the secondary.  The period may be influenced by the secondary
   server's leasing activity.

   The POOLREQ message has no message specific options.

7.6.1.  Sending the POOLREQ message

   The POOLREQ message is sent.



Droms, et. al.           Expires September 2003                [Page 68]

Internet Draft           DHCP Failover Protocol              March 2003


7.6.2.  Receiving the POOLREQ message

   When a primary server receives a POOLREQ message it SHOULD examine
   the binding database and determine how many IP addresses 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 the type and number of IP addresses on every network segment
   participating in the failover protocol.  The primary server is
   responsible for allocating the secondary server the correct propor-
   tion of available IP addresses of each kind, and the secondary server
   is responsible for being configured in such a way that it can tell
   the kind of every IP address based solely on the IP address itself.

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

   A primary server MAY choose to defer processing a POOLREQ message
   until a more convenient time to process it, but it should not depend
   on the secondary server to resend the POOLREQ message in that case.

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

7.7.  POOLRESP message [2]

   A primary server sends a POOLRESP message to a secondary server after
   the allocation process for available addresses to the secondary
   server is complete.  Typically this message will precede some of the
   BNDUPD messages that the primary uses to send the actual allocated IP
   addresses to the secondary.

   The xid in the POOLRESP message MUST be identical to the xid in the
   POOLREQ message for which this POOLRESP is a response.


7.7.1.  Sending the POOLRESP message

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

   Only one option MUST appear in a POOLREQ message:




Droms, et. al.           Expires September 2003                [Page 69]

Internet Draft           DHCP Failover Protocol              March 2003


      o addresses-transferred

        The number of addresses allocated to the secondary server by the
        primary server as a result of a POOLREQ is contained in the
        addresses-transferred option in a POOLRESP message.  Note this
        is the number of addresses that are transferred to the secondary
        in the primary's binding database as a result of the correspond-
        ing POOLREQ message, 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 a POOLRESP message, it SHOULD send
   another POOLREQ message if the value of the addresses-transferred
   option is non-zero.

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

7.8.  CONNECT message [5]

   The connect message is used to establish an applications level con-
   nection over a newly created TCP connection.  It gives the source
   information for the connection and critical configuration informa-
   tion.  It MUST be sent only by the primary server.  Either server can
   initiate a TCP connection, but the CONNECT message is only sent by
   the primary server.

   The CONNECT message MUST be the first message sent down a newly esta-
   blished connection, and it MUST be sent only by the primary server.

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

















Droms, et. al.           Expires September 2003                [Page 70]

Internet Draft           DHCP Failover Protocol              March 2003




   Option
   ------
   relationship-name           MUST
   max-unacked-bndupd          MUST
   receive-timer               MUST
   vendor-class-identifier     MUST
   protocol-version            MUST
   TLS-request                 MUST (1)
   MCLT                        MUST
   hash-bucket-assignment      MUST

   (1) MUST NOT if CONNECT is being sent over a TLS connection

              Table 7.8-1: Options used in a CONNECT message


7.8.1.  Sending the CONNECT message

   The CONNECT message MUST be the first message sent by the primary
   server after the establishment of a new TCP connection with a secon-
   dary server participating in the failover protocol.

   The xid of the CONNECT message is not related to any previous xid
   sequence, but initiates the sequence for this connection.

   The name of the failover relationship MUST be placed in the
   relationship-name option.  This information is placed in an option
   inside of the message in order to allow the identity of the sender to
   be covered by a shared secret.

   The number of BNDUPD messages the primary server can accept without
   blocking the TCP connection MUST be placed in the max-unacked-bndupd
   option.  This MUST be a number equal to or greater than 1, SHOULD be
   a number greater than 10, and SHOULD be a number less than 100.

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

   The MCLT MUST be placed in the MCLT option.

   The hash-bucket-assignment option MUST be included in the CONNECT
   message.  In the event that load balancing is not configured for this
   server, the hash-bucket-assignment option will indicate that.  The
   value of the hash-bucket-assignment option is determined from the
   specific buckets that the primary server has determined that the
   secondary server MUST service as part of the load-balancing



Droms, et. al.           Expires September 2003                [Page 71]

Internet Draft           DHCP Failover Protocol              March 2003


   algorithm.  The way in which the primary server determines this
   information is outside the scope of this protocol definition.  The
   primary server SHOULD be configured with a percentage of clients that
   the secondary server will be instructed to service, and the primary
   server SHOULD use the algorithm in [RFC 3074] to generate a Hash
   Bucket Assignment which it sends to the secondary server.

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

   The protocol-version option MUST be included in every CONNECT mes-
   sage.  The current value of the protocol version is 1.

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

7.8.2.  Receiving the CONNECT message

   When a server established a TCP connection on a failover port, if it
   is a PRIMARY server it should send a CONNECT message, and if it is a
   secondary server it should wait for a CONNECT message before sending
   any messages.  To avoid denial of service attacks, a secondary should
   only wait for a CONNECT message on a new connection for a limited
   amount of time and close the connection if none is received during
   that time.

   When a secondary server receives a CONNECT message it should:

      1.  Record the time at which the message was received.

      2.  Examine the protocol-version option, and decide if this server
          is capable of interoperating with another server running that
          protocol version.  If not, send the CONNECTACK message with
          the reject reason 14: "Protocol version mismatch".  The server
          MUST include its protocol-version in the CONNECTACK message.

      3.  Examine the TLS-request option.  Figure out the TLS-reply
          value based on the capabilities and configuration of this
          server.  If the result for the TLS-reply value is a 1 and the
          connection is accepted, indicating use of TLS, then immedi-
          ately send the CONNECTACK message and go into TLS negotiation.
          If the TLS-reply value implies rejection of the connection,
          then immediately send the CONNECTACK message 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.



Droms, et. al.           Expires September 2003                [Page 72]

Internet Draft           DHCP Failover Protocol              March 2003


          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 CON-
          NECT message.  If there was, and the server does not support
          message-digests, then reject the connection with reject reason
          12: "Message digest not supported" in the CONNECTACK.  If the
          server does support message-digests, then check this message
          for validity based on the message-digest, and reject it if the
          digest indicates the message was altered with reject reason
          20: "Message digest failed to compare".

      5.  Determine if the sender (from the relationship-name option)
          and the implicit role of the sender (i.e., primary) represents
          a server with which the receiver was configured to engage in
          failover activity.  This is performed after any TLS or message
          digest processing so that it occurs after a secure connection
          is created, to ensure that there is no tampering with the
          relationship name of the partner.  In the absence of any other
          security capability (i.e., when TLS or a message digest is not
          used), the server MAY wish to be configured with the IP
          address of the partner and check the source-ip of the CONNECT
          message against that IP address as a weak form of security.

          If not, then the receiving server should reject the CONNECT
          request by sending a CONNECTACK message with a reject-reason
          value of: 8, invalid failover partner.

          If it is, then the receiving failover endpoint should be
          determined.

      6.  Decide if the time delta between the sending of the message,
          in the time field, and the receipt of the message, recorded in
          step 1 above, is acceptable.  A server MAY require an



Droms, et. al.           Expires September 2003                [Page 73]

Internet Draft           DHCP Failover Protocol              March 2003


          arbitrarily small delta in time values in order to set up a
          failover connection with another server.  See section 5.10 for
          information on time synchronization.

          If the delta between the time values is too great, the server
          should reject the CONNECT request by sending a CONNECTACK mes-
          sage with a reject-reason of 4, time mismatch too great.

          If the time mismatch is not considered too great then the
          receiving server MUST record the delta between the servers.
          The receiving server MUST use this delta to correct all of the
          absolute times received from the other server in all time-
          valued options.  Note that servers can participate in failover
          with arbitrarily great time mismatches, as long as it is more
          or less constant.

      7.  Examine the MCLT option in the CONNECT request and use the
          value of the MCLT as the MCLT for this failover endpoint.

          The secondary server SHOULD be able to operate with any MCLT
          sent by the primary,  but if it cannot, then it should send a
          CONNECTACK with a reject-reason of 5, MCLT mismatch.  In the
          event that the MCLT from the primary does not match that con-
          figured on the secondary, and the secondary will run with the
          primary's value, then the secondary MUST save the MCLT in
          secondary storage since it will need it even if it cannot con-
          tact the primary.  The secondary MUST NOT use a different MCLT
          value than it received from the primary even if it cannot con-
          tact the primary.

      8.  The server MUST store hash-bucket-assignment option for use
          during processing during NORMAL state.  If this hash bucket
          assignment conflicts with the secondary server's configured
          hash bucket assignment for use in other than NORMAL state, the
          secondary server should send 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.

7.9.  CONNECTACK message [6]

   The CONNECTACK message is sent to accept or reject 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



Droms, et. al.           Expires September 2003                [Page 74]

Internet Draft           DHCP Failover Protocol              March 2003


   that the connection was rejected may well not have changed since the
   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 following table summarizes the options associated with the CON-
   NECTACK message:


   Option                     accept       reject
   ------
   relationship-name           MUST        MUST
   max-unacked-bndupd          MUST        MUST NOT
   receive-timer               MUST        MUST NOT
   vendor-class-identifier     MUST        MUST NOT
   protocol-version            MUST        MUST
   TLS-reply                   (1)         (2)
   reject-reason               MUST NOT    MUST
   message                     MUST NOT    SHOULD
   MCLT                        MUST NOT    MUST NOT
   hash-bucket-assignment      MUST NOT    MUST NOT

   (1) MUST NOT if sending CONNECTACK after TLS negotiation, MUST
   if TLS-request in CONNECT, else MUST NOT.
   (2) MUST if TLS-request in CONNECT message, else MUST NOT.

              Table 7.9-1: Options used in a CONNECTACK message


7.9.1.  Sending the CONNECTACK message

   The xid of the CONNECTACK message MUST be that of the corresponding
   CONNECT message.

   The name of the relationship MUST be placed in the relationship-name
   option.  This information is placed in an option inside of the mes-
   sage in order to allow the identity 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 of the protocol version is 1.

   If the connection has been rejected, the reject-reason option MUST be
   placed in the CONNECTACK message with an appropriate reason, and a
   message option SHOULD be included with a human-readable error message
   describing the reason for the rejection in some detail.  If the
   reject-reason option appears, then the remaining options listed below
   do not appear.  The sending server should close the connection after



Droms, et. al.           Expires September 2003                [Page 75]

Internet Draft           DHCP Failover Protocol              March 2003


   sending the CONNECTACK if the connection was rejected.

   The results 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 the CONNECTACK message and any sub-
   sequent messages if the CONNECTACK does not contain a reject-reason.

   The number of BNDUPD messages the server can accept without blocking
   the TCP connection MUST be placed in the max-unacked-bndupd option.
   This SHOULD be a number greater than 10, and SHOULD be a number less
   than 100.

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

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

   After a connection is created (either by sending a CONNECTACK message
   to the first CONNECT message, or sending a CONNECTACK message to a
   CONNECT message received over a TLS connection), the server MUST send
   a STATE message.

   After a connection is created, the server MUST start two timers for
   the connection: tSend and tReceive.   The tSend timer SHOULD be
   approximately 33 percent of the time in the receiver-timer option in
   the corresponding CONNECT message.  The tReceive timer SHOULD be the
   time sent in the receiver-timer option in the CONNECTACK message.

   The tReceive timer is reset whenever a message is received from this
   TCP connection.  If it ever expires, the TCP connection is dropped
   and communications with this partner is considered not ok.  The
   reject reason 17: "No traffic within sufficient time" is placed in
   the DISCONNECT message sent prior to dropping the TCP connection.

   The tSend timer is reset whenever a message is sent over this connec-
   tion. When it expires, a CONTACT message MUST be sent.

7.9.2.  Receiving the CONNECTACK message

   If a CONNECTACK message is received with a different XID from the one
   in the CONNECT that was sent, it SHOULD be ignored.  To avoid denial
   of service attacks, a primary should only wait for a CONNECTACK mes-
   sage on a new connection for a limited amount of time and close the
   connection if none is received during that time.



Droms, et. al.           Expires September 2003                [Page 76]

Internet Draft           DHCP Failover Protocol              March 2003


   When a CONNECTACK message is received, the following actions should
   be taken:

      1.  Record the time the message was received.

      2.  Check to see if the xid on the CONNECTACK matches an outstand-
          ing CONNECT message on this TCP connection.

      3.  Check to see if there is a reject-reason option in the CONNEC-
          TACK message.  If not, continue with step 3.  If there is a
          reject-reason option, the server SHOULD report the error code.
          If a message option appears a server SHOULD display the string
          from the message option in a user visible way.  The server
          MUST close the connection if a reject-reason option appears.

      4.  Check the value of the TLS-reply option (if any, which there
          won't be if this CONNECT is taking place utilizing TLS), and
          if it was 1, then skip processing of the rest of the CONNEC-
          TACK message, and immediately enter into TLS connection setup.

          This step occurs prior to steps 5 and 6 in order to allow
          creation of a secure connection (if required) prior to pro-
          cessing the protocol version and IP address information.

      5.  Examine the value of the protocol-version option.  If this
          server is able to establish connections with another server
          running this protocol version, then continue, else close the
          connection.

      6.  Decide if the time delta between the sending of the message,
          in the time field, and the receipt of 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 connection with another server.

          If the delta between the time values is too great, the server
          should drop the TCP connection (see section 7.12).

          If the time mismatch is not considered too great then the
          receiving server MUST record the delta between the servers.
          The receiving server MUST use this delta to correct all of the
          absolute times received from the other server in all time-
          valued options.  Note that the failover protocol is con-
          structed so that two servers can be failover partners with
          arbitrarily great time mismatches.

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



Droms, et. al.           Expires September 2003                [Page 77]

Internet Draft           DHCP Failover Protocol              March 2003


      8.  After accepting a CONNECTACK message, the server MUST send a
          STATE message.

          After receiving a CONNECTACK message, the server MUST start
          two timers for the connection: tSend and tReceive.   The tSend
          timer SHOULD be approximately 20 percent of the time in the
          receiver-timer option in the corresponding CONNECTACK message.
          The tReceive timer SHOULD be set to the time sent in the
          receiver-timer option in the CONNECT message.

          The tReceive timer is reset whenever a message is received
          from this TCP connection.  If it ever expires, the TCP connec-
          tion is dropped and communications with this partner is con-
          sidered not ok.  The reject reason 17: "No traffic within suf-
          ficient time" is placed in the DISCONNECT message sent prior
          to dropping the TCP connection.

          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 [10]

   The state (STATE) message is used to communicate the current failover
   state to the partner server.

   The STATE message MUST be sent after sending a CONNECTACK message
   that didn't contain a reject-reason option, and MUST be sent after
   receiving a CONNECTACK message without a reject-reason option.

   A STATE message MUST be sent whenever the failover endpoint changes
   its failover state and a connection exists to the partner.

   The STATE message requires no response from the failover partner.

   The following table shows the options that MUST 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






Droms, et. al.           Expires September 2003                [Page 78]

Internet Draft           DHCP Failover Protocol              March 2003


7.10.1.  Sending the STATE message

   The current failover state is placed in the server-state option and
   the current state of the STARTUP flag is placed in the server-flags
   option.

   The message is sent with a unique xid.

   A server SHOULD only send the STATE message either when the connec-
   tion is created (i.e, after sending or receiving a CONNECTACK message
   with no reject-reason option), or when there is a change from the
   values sent in a previous STATE message.

7.10.2.  Receiving the STATE message

   Every STATE message SHOULD indicate a change in state or a change in
   the flags.

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

   No response to a STATE message is required.

7.11.  CONTACT message [11]

   The contact (CONTACT) message is sent to verify communications
   integrity with a failover partner.  The 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 tSend timer expiring (see
   section 8.3).

   The CONTACT message has no message specific options.

7.11.1.  Sending the CONTACT message

   The CONTACT message is sent.

7.11.2.  Receiving the CONTACT message

   When a CONTACT message is received, the tReceive timer is reset (as
   it is with any message that is received).

   A server SHOULD use the time in the time field and the time the mes-
   sage was received to refine the delta time calculations between the
   servers.






Droms, et. al.           Expires September 2003                [Page 79]

Internet Draft           DHCP Failover Protocol              March 2003


7.12.  DISCONNECT message [12]

   The DISCONNECT is the last message sent over a connection before
   dropping an established connection (note that an established connec-
   tion is one where a CONNECTACK has been sent without a reject rea-
   son).

   After sending or receiving a DISCONNECT message, a server needs to
   have some mechanism to prevent an error loop. Simply reconnecting to
   the 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 before attempting to reestablish communica-
   tion.

   The DISCONNECT message MUST be the last message sent down a connec-
   tion before it is closed.

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


   Option
   ------
   reject-reason               MUST
   message                     SHOULD

              Table 7.12-1: Options used in a DISCONNECT message



7.12.1.  Sending the DISCONNECT message

   The DISCONNECT message MUST be the last message sent by the a server
   which is dropping a TCP connection.

   The xid of the DISCONNECT message must be unique.

   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 the DISCONNECT message

   When a server receives a DISCONNECT message it should log the message
   if there was one and possibly raise an alarm of some sort if the
   reject reason was one that was sufficiently serious.



Droms, et. al.           Expires September 2003                [Page 80]

Internet Draft           DHCP Failover Protocol              March 2003


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 to another as well as to allow each
   server to determine whether communications is possible with the other
   server.

   Central to the operation of the failover protocol is a notion of
   "communications okay" or "communications failed".  Failover state
   transitions are taken in many cases when the status of communications
   with the partner changes, and the existence or non-existence of a TCP
   connections between failover endpoints is used 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 endpoints.

   Typically there is one failover endpoint for each end of a failover
   relationship between two servers, and only a single relationship
   between any two servers.  Given the integration of loadbalancing into
   the failover protocol, there is little value in having more than one
   failover relationship between two servers, though the protocol will
   support multiple relationships between two servers.

   Each failover relationship MUST have a unique relationship-name, and
   the relationship-name option is used to communicate this name in the
   CONNECT and CONNECTACK messages.

8.2.  Creating the TCP connection

   All failover TCP connections are initiated over port 647.  Every
   server implementing the failover protocol MUST listen on port 647.

   Every server implementing the failover protocol SHOULD attempt to
   connect to all 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 in it 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.

   When a connection attempt succeeds, if the server generating the



Droms, et. al.           Expires September 2003                [Page 81]

Internet Draft           DHCP Failover Protocol              March 2003


   connection attempt is a primary server for that relationship, then it
   MUST send a CONNECT message down the connection.  If it is not a pri-
   mary server for the relationship, then it MUST just drop the connec-
   tion and wait for the primary server to connect to it.

   When a connection attempt is received on port 647, the only informa-
   tion that the receiving server has is the IP address of the partner
   initiating a connection.  It also knows whether it has the primary
   role for any failover relationships with the connecting server.  If
   it has any relationships for which it is a primary server, it should
   initiate a connection of its own to port 647 of the partner server,
   one for each primary relationship it has with that server.

   If it has any relationships with the connecting server for which it
   is a seconary server, it should just await the CONNECT message to
   determine which relationship this connection is to serve.

   If it has no secondary relationships with the connecting server, it
   SHOULD drop the connection.

   To summarize -- a primary server MUST use a connection that it has
   initiated in order to send a CONNECT message.  Every server that is a
   secondary server in a relationship attempts to create a connection to
   the server which is primary in the relationship, but that connection
   is only used to stimulate the primary server into recognizing that
   the secondary server is ready for operation.  The reason behind this
   is that the secondary server has no way to communicate to the primary
   server which relationship a connection is designed to serve.

   A server which has multiple secondary relationships with a primary
   server SHOULD only send one stimulus connection attempt to the pri-
   mary server.

   Once a connection is established, the primary server MUST send a CON-
   NECT message across the connection.  A secondary server MUST wait for
   the CONNECT message from a primary server.  If the secondary server
   doesn't receive a CONNECT message from the primary server in an ins-
   tallation dependent amount of time, it MAY drop the connection and
   send another stimulus connection attempt to the primary server.

   Every CONNECT message includes a TLS-request option, and if the CON-
   NECTACK message does not reject the CONNECT message and the TLS-reply
   option says TLS MUST be used, then the servers will immediately enter
   into TLS negotiation.

   Once TLS negotiation is complete, the primary server MUST resend the
   CONNECT message on the newly secured TLS connection and then wait for
   the CONNECTACK message in response.  The TLS-request and TLS-reply



Droms, et. al.           Expires September 2003                [Page 82]

Internet Draft           DHCP Failover Protocol              March 2003


   options MUST NOT appear in either this second CONNECT or its associ-
   ated CONNECTACK message as they had in the first messages.

   The second message sent over a new connection (either a bare TCP con-
   nection or a connection utilizing TLS) is a STATE message.  Upon the
   receipt of this message, the 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 case the
   secondary server will be waiting for a CONNECT message on each con-
   nection.  The primary server MUST send a CONNECT message over one
   connection and it MUST close the other connection.

   A secondary server MUST NOT respond to the closing of a TCP connec-
   tion with a blind attempt to 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 TCP connection is used to determine the communications status of
   the other server, i.e., communications-ok, or communications-
   interrupted.

   Three things must happen for a server to consider that communications
   are ok with respect to another server:


      1.  A TCP connection must be established to the other server.

      2.  A CONNECT message must be received and a CONNECTACK message
          sent in response.  The CONNECT message is used to determine
          the identify of the failover endpoint of the other end of the
          TCP connection -- without it, the failover endpoint cannot be
          uniquely determined.  Without knowledge of the failover end-
          point, then the entity with which communications is ok is
          undetermined.

      3.  A STATE message must be received from the other server over
          the connection.  This STATE message initializes important
          information necessary to the operation of the state machine
          the governs the behavior of this failover endpoint.

   There are two ways that a server can determine that communications
   has failed:


      1.  The TCP connection can go down, yielding an error when
          attempting to send or receive a message. This will happen at



Droms, et. al.           Expires September 2003                [Page 83]

Internet Draft           DHCP Failover Protocol              March 2003


          least as often as the period of the tSend timer.

      2.  The tReceive timer can expire.

   In either of these cases, communications is considered interrupted.

   If the tReceive timer expires, the connection MUST be dropped.  The
   reject reason 17: "No traffic within sufficient time" is placed in
   the DISCONNECT message sent prior to dropping the TCP connection.

   Several difficulties arise when trying to use one TCP connection for
   both bulk data transfer as well as to sense the communications status
   of the other server.   One aspect of the problem stems from the dif-
   ferent requirements of both uses.  The bulk data transfer is of
   course critically important to the protocol, but the speed with which
   it is processed is not terribly significant.  It might well be
   minutes before a BNDUPD message is processed, and while not optimal,
   such an occasional delay doesn't compromise the correctness of the
   protocol. However, the speed with which one server detects the other
   server is up (or, more importantly, down) is more highly constrained.
   Generally one server should be able to detect that the other server
   is not communicating within a minute or less.

   These differing time constraints makes it difficult 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 to this problem is to require that some message 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 recently, then a CONTACT message is sent.

   In the case where there is no data queued to be sent, this is not a
   problem, but in the case where there is data queued to be sent to the
   partner, then the CONTACT message will not actually be transmitted
   until the queued data is sent.  Section 3.5 explains why waiting for
   TCP to determine that the connection is down is not acceptable, and
   leads to a requirement that the receiving server never block the
   sending server from sending CONTACT messages.

   In order to meet this requirement, each server tells the other server
   the number of outstanding BNDUPD messages that it will accept.  The
   receiving server is required to always be able to accept that many
   BNDUPD messages off of the connection's input queue even if it cannot
   process them immediately, and to accept all other messages immedi-
   ately.

   Thus, the sending server's TCP is never blocked from sending a



Droms, et. al.           Expires September 2003                [Page 84]

Internet Draft           DHCP Failover Protocol              March 2003


   message except for very short periods, less than a few seconds unless
   the network connection itself has problems.  In this case, if the
   CONTACT messages don't make it to the partner then the partner will
   close the connection.

   DISCUSSION:

      When implementing this capability, one needs to be careful when
      sending any message on the TCP connection as TCP can easily block
      the server if the local TCP send buffers are full.  This can't be
      prevented because if the receiver is not reachable (via the net-
      work), the sending TCP can't send and thus it will be unable to
      empty the local TCP send buffers.  So, all send operations either
      need to assume they may block for some time or non-blocking sends
      must be used carefully.

8.4.  Using the TCP connection for binding data

   Binding data, in the form of BNDUPD messages and BNDACK messages to
   respond to them, are sent across the TCP connection.

   In order to support timely detection of any failure in the partner
   server, the TCP connection MUST NOT block for more than a very short
   time, on 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 to block transmission of additional data
   (i.e, CONTACT messages) is sent by each server in the CONNECT and
   CONNECTACK messages in 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 the TCP connection.  A server MUST immediately accept any
   BNDACK which is received as well.

8.6.  Losing the TCP connection

   When the TCP connection is lost, then communications is not ok with
   the other server.  A server which has lost communications SHOULD
   immediately attempt to reconnect to the other server, and should
   retry these connection attempts periodically.

   An acknowledgement message (BNDACK, POOLRESP, UPDDONE) message can



Droms, et. al.           Expires September 2003                [Page 85]

Internet Draft           DHCP Failover Protocol              March 2003


   only be sent in response to a request message (BNDUPD, POOLREQ,
   UPDREQ, UPDREQALL) on the same TCP connection from which the request
   was received, in part since the XID's in the request messages are
   guaranteed unique only during the 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 partner will resend them when they are next
   in communications.  A server 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 issues surrounding XID uniqueness).

   When the TCP connection is closed explicitly, the DISCONNECT message
   with a reject-reason option (and, ideally, a message option) MUST be
   sent over the TCP connection.

9.  Failover Endpoint States

   This section discusses the various states that a failover endpoint
   may take, and the server actions required when entering the state,
   operating in the 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 relevant for this
   section. This is the common state transition diagram for both servers
   in a failover pair.  In the event that the textual description of a
   state differs from the state transition diagram, the textual descrip-
   tion is to 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 makes a transition into a new state, it MUST record
   the state and the time at which it entered that state in stable
   storage.  If communications is "ok", it MUST also send a STATE mes-
   sage to its failover partner.

   Figure 9.2-1 is the diagram of the server state transitions. The
   remainder of this section contains information important to the
   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



Droms, et. al.           Expires September 2003                [Page 86]

Internet Draft           DHCP Failover Protocol              March 2003


   during one of the actions, the server simply stays in the current
   state and attempts a transition whenever the conditions for a transi-
   tion are later fulfilled.

   In the state transition diagram below, the "+" or "-" in the upper
   right corner of each state is a notation about whether communication
   is ongoing with the other server.

   The legend "responsive", "balanced", or "unresponsive" in each state
   indicates whether the server is responsive to all DHCP client
   requests, running in load balanced mode, or totally unresponsive in
   the respective state.  The terms "responsive" and "unresponsive" have
   the obvious meanings, while "balanced" means that a DHCP server may
   respond to all DHCPREQUEST messages that are RENEWAL or REBINDING,
   and to all other messages from clients for which the load balancing
   algorithm indicates that it MUST respond to.  See sections 5.3 and
   9.8.2 for details on load balancing.

   Note that in situations where a server does not respond to a DHCP
   client message, it MUST NOT remember any of the information from that
   message.

   In the state transition diagram below, when communication is 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 appropriate given the current state of the partner
   server.  A server performing this operation SHOULD NOT close the TCP
   connection to its partner.

   DISCUSSION:

      The point of this technique is simplicity, both in explanation of
      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 is to have every state in the 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 in stable storage and



Droms, et. al.           Expires September 2003                [Page 87]

Internet Draft           DHCP Failover Protocol              March 2003


   thus be available to the server after a server restart.

   A transition into SHUTDOWN or PAUSED state is not represented in the
   following figure, since other than sending that state to its partner,
   the remaining actions involved look just like the server halting in
   its otherwise current state, which then becomes the previous state
   upon server restart.












































Droms, et. al.           Expires September 2003                [Page 88]

Internet Draft           DHCP Failover Protocol              March 2003



        +---------------+  V  +--------------+
        |    RECOVER -|+|  |  |   STARTUP  - |
        |(unresponsive) |  +->+(unresponsive)|
        +------+--------+     +--------------+
        +-Comm. OK             +-----------------+
        |     Other State:     |  PARTNER DOWN - +<----------------------+
        |    RESOLUTION-INTER. | (responsive)    |                       ^
       All     POTENTIAL-      +----+------------+                       |
      Others   CONFLICT------------ | --------+                          |
        |      CONFLICT-DONE     Comm. OK     |     +--------------+     |
     UPDREQ or                 Other State:   |  +--+ RESOLUTION - |     |
     UPDREQALL                  |       |     |  |  | INTERRUPTED  |     |
     Rcv UPDDONE             RECOVER    All   |  |  | (responsive) |     |
        |  +---------------+    |      Others |  |  +------------+-+     |
        +->+RECOVER-WAIT +-| RECOVER    |     |  |         ^     |       |
           |(unresponsive) |  WAIT or   |     |  Comm.     |    Ext.     |
           +-----------+---+  DONE      |     |  OK     Comm.   Cmd----->+
    Comm.---+     Wait MCLT     |       V     V  V     Failed            |
    Changed |          V    +---+   +---+-----+--+-+       |             |
     |  +---+----------++   |       |  POTENTIAL + +-------+             |
     |  |RECOVER-DONE +-|  Wait     |  CONFLICT    +------+              |
     +->+(unresponsive) |  for      |(unresponsive)|   Primary           |
        +------+--------+  Other  +>+----+--------++   resolve     Comm. |
         Comm. OK          State: |      |        ^    conflict  Changed |
    +---Other State:-+   RECOVER  |   Secondary   |       V       V   |  |
    |    |           |     DONE   |    resolve    |   ++----------+---++ |
    | All Others:  POTENT.  |     |   conflict    |   |CONFLICT-DONE-|+| |
    | Wait for    CONFLICT- | ----+    see (9.10) |   | (responsive)   | |
    | Other State:          V            V        |   +------+---------+ |
    | NORMAL or RECOVER    ++------------+---+      Other State: NORMAL  |
    |    |       DONE      |     NORMAL    + +<--------------+           |
    |    +--+----------+-->+   (balanced)    +-------External Command--->+
    |       ^          ^   +--------+--------+       or Other State:     |
    |       |          |            |             |  SHUTDOWN            |
    |   Wait for   Comm. OK  Comm. Failed or      |                      |
    |    Other      Other    Other State: PAUSED  |               External
    |    State:     State:          |             |                Command
    | RECOVER-DONE  NORMAL     Start Safe      Comm. OK                or
    |       |     COMM. INT.  Period Timer    Other State:            Safe
    |    Comm. OK.     |            V          All Others           Period
    |   Other State:   |  +---------+--------+    |             expiration
    |     RECOVER      +--+ COMMUNICATIONS - +----+                      |
    |       +-------------+   INTERRUPTED    |                           |
    RECOVER               |  (responsive)    +-------------------------->+
    RECOVER-WAIT--------->+------------------+
                    Figure 9.2-1:  Server state diagram.




Droms, et. al.           Expires September 2003                [Page 89]

Internet Draft           DHCP Failover Protocol              March 2003



9.3.  STARTUP state

   The STARTUP state affords an opportunity for a server to probe its
   partner server, before starting to service DHCP clients.

   DISCUSSION:

      Without the STARTUP state, 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 with the current state
      of the partner.  The STARTUP state affords the opportunity for a
      server 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 server to start in another state.  This is
      especially critical if significant time has elapsed while the
      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 time spent in the STARTUP state is
   necessarily short, typically on the order of a few seconds to a few
   tens of seconds.  The exact time spent in the STARTUP state is imple-
   mentation dependent, and the primary and secondary server are not
   required to spend the same amount of time in the STARTUP state.  See
   section 5.9 for some guidelines on the time to spend in STARTUP
   state.

   Whenever a STATE message is sent to the partner while in STARTUP
   state the STARTUP bit MUST be set in the server-flags option and the
   previously recorded failover state MUST be placed in the server-state
   option.


9.3.2.  Transition out of STARTUP state

   Each server starts out in startup state every time it initializes
   itself, and performs the following algorithm as part of its initiali-
   zation:

      1.  Is there any record in stable storage of a previous failover
          state?  If yes, set previous-state to the last recorded state
          in stable storage, and continue with step 2.

          Is there any configuration information that indicates that



Droms, et. al.           Expires September 2003                [Page 90]

Internet Draft           DHCP Failover Protocol              March 2003


          this server was previously running but lost its stable
          storage?  Such information must typically come from some
          administrative intervention, since it is difficult for 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 the time-of-failure to whatever time
          was configured, and go on to step 2.  This time-of-failure
          will be used in the transition out of the RECOVER-WAIT state
          into the RECOVER-DONE state, below.

          If there is no record of any previous failover state in stable
          storage for this server, then set the previous-state to
          RECOVER and set the time-of-failure to a time before the
          maximum-client-lead-time before now.  If using standard Posix
          times, 0 would typically do quite well.  This will allow two
          servers which already have lease information to synchronize
          themselves prior to operating.

          Note that neither server is responsive to DHCP client requests
          while in the RECOVER state.  If both servers can communicate,
          however, they will come out of the RECOVER state and progress
          through RECOVER-WAIT to RECOVER-DONE and thence to NORMAL or
          COMMUNICATIONS-INTERRUPTED state quickly.  If both have state,
          then they will exchange information.  If only one has state,
          then the one that does not will complete its update of its
          partner quickly (since it has nothing to send).

          In some cases, an existing server will be commissioned as a
          failover server and brought back into operation where its
          partner is not yet available.  In this case, the newly commis-
          sioned failover server will not operate until its partner
          comes online  -- but it has operational responsibilities as a
          DHCP server nonetheless.  To properly handle this situation, a
          server SHOULD be configurable in such a way as to move
          directly into PARTNER-DOWN state after the startup period
          expires if it has been unable to contact its partner during
          the startup period.

      2.  If the previous state is one where communications was "OK",
          then set the previous state to the state that is the result of
          the communications failed state transition in Figure 9.2-1 (if
          such transition is shown -- some states don't have a communi-
          cations failed state transition, since they allow both commun-
          ications OK and failed).

      3.  Start the STARTUP state timer.  The time that a server remains
          in the STARTUP state (absent any communications with its
          partner) is implementation dependent and SHOULD be



Droms, et. al.           Expires September 2003                [Page 91]

Internet Draft           DHCP Failover Protocol              March 2003


          configurable.  It SHOULD be long enough for a TCP connection
          to be created to a heavily loaded partner across a slow net-
          work.

      4.  Attempt to create a TCP connection to the failover partner.
          See section 8.2.

      5.  Wait for "communications okay", i.e., the process discussed in
          section 8.2 "Creating the TCP Connection", to complete,
          including the receipt of a STATE message from the partner.

          When and if communications become "okay", clear the STARTUP
          flag, and set the current state to the previous-state.

          If the partner is in PARTNER-DOWN state, and if the time at
          which it entered PARTNER-DOWN state (as received in the
          start-time-of-state option in the STATE message) is later than
          the last recorded time of operation of this server, then set
          the current state to RECOVER.  If the time at which it entered
          PARTNER-DOWN state is earlier than the last recorded time of
          operation of this server, then set the current state to
          POTENTIAL-CONFLICT.

          Then, transition to the current state and take the "communica-
          tions okay" state transition based on the current state of
          this server and the partner.

      6.  If the startup time expires, take an implementation dependent
          action:  The server MAY go to the previous-state, or the
          server MAY wait.

          Reasons to go to previous-state and begin processing:

          If the current server is the 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 other crashes and reboots.  If the rebooting server
          doesn't start processing DHCP client requests without first
          being in communication with the other server, then the level
          of DHCP redundancy is not particularly high.  This is an
          appropriate approach if the possibility of partition is low,
          or if the 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 safe period
          will never expire.

          Reasons to wait:




Droms, et. al.           Expires September 2003                [Page 92]

Internet Draft           DHCP Failover Protocol              March 2003


          If the current server has been down for longer than the
          maximum-client-lead-time, and it is partitioned from the other
          server, then when it returns it will attempt to use its own
          available addresses to allocate to new DHCP clients, and the
          other server may well be 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 safe period expiration time is less than the likely
          operator reaction time, this is a good approach to use.

9.4.  PARTNER-DOWN state

   PARTNER-DOWN state is a state either server can enter.  When in this
   state, the server does not assume that the other server could still
   be operating and servicing a different set of clients, but instead
   assumes that it is the only server operating. If one server is in
   PARTNER-DOWN state, the other server MUST NOT be operating.


9.4.1.  Upon entry to PARTNER-DOWN state

   No special actions are required when entering PARTNER-DOWN state.

   The server should continue to attempt to connect to the partner
   periodically.


9.4.2.  Operation while in PARTNER-DOWN state

   A server in PARTNER-DOWN state MUST respond to DHCP client requests.
   It will allow renewal of all outstanding leases on IP addresses, and
   will allocate IP addresses 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 IP address tagged as available for allocation by the other server
   (at entry to PARTNER-DOWN state) MUST NOT be allocated to a new
   client until the maximum-client-lead-time beyond the entry into
   PARTNER-DOWN state has elapsed.

   A server in PARTNER-DOWN state MUST NOT allocate an IP address to a



Droms, et. al.           Expires September 2003                [Page 93]

Internet Draft           DHCP Failover Protocol              March 2003


   DHCP client different from that to which it was allocated at the
   entrance to PARTNER-DOWN state until the maximum-client-lead-time
   beyond 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.5 for details.  If this time would be earlier than the current
   time plus the maximum-client-lead-time, then the time the server
   entered PARTNER-DOWN state plus the maximum-client-lead-time is used.

   Two options exist for lease times given out while in PARTNER-DOWN
   state, with different ramifications flowing from each.

   If the server wishes the Failover protocol to protect it from loss of
   stable storage in PARTNER-DOWN state, then it should ensure that the
   MCLT based lease time restrictions in section 5.1 are maintained,
   even in PARTNER-DOWN state.

   If the server wishes to forego the protection of the Failover proto-
   col in 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 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 state and
   flags received in the STATE message from the other server as part of
   the process of establishing the connection.

   If the STARTUP bit is set in the server-flags option of a received
   STATE message, a server in PARTNER-DOWN state MUST NOT take any 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 the server-flags option
   of the STATE message.

   If the STARTUP bit is not set in the server-flags option of a STATE
   message received from its partner, then a server in PARTNER-DOWN
   state takes the following actions based on the value of the server-
   state option in the received STATE message (either immediately after
   establishing communications or at any time later when a new state is
   received):

      o partner in NORMAL, COMMUNICATIONS-INTERRUPTED, PARTNER-DOWN,



Droms, et. al.           Expires September 2003                [Page 94]

Internet Draft           DHCP Failover Protocol              March 2003


        POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, or CONFLICT-DONE
        state

        transition to POTENTIAL-CONFLICT state

      o partner in RECOVER, RECOVER-WAIT, SHUTDOWN, PAUSED state

        stay in PARTNER-DOWN state

      o partner in RECOVER-DONE state

        transition into NORMAL state

9.5.  RECOVER state

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

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 the other server.

9.5.2.  Transitions out of RECOVER state

   If the other server is in POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED,
   or CONFLICT-DONE state when communications are reestablished, then
   the server in RECOVER state will move to POTENTIAL-CONFLICT state
   itself.

   If the other server is in any other state, then the server in RECOVER
   state will 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, or if it has deduced that from the fact that it has no
   record of ever having talked to its partner, while its partner does
   have a record of communicating with it, it MUST send an UPDREQALL
   message, otherwise it MUST send an UPDREQ message.  See Figure
   9.5.2-1.

   It will wait for an UPDDONE message, and upon receipt of that message
   it will transition to RECOVER-WAIT state.

   If communications fails during the reception of the results of the



Droms, et. al.           Expires September 2003                [Page 95]

Internet Draft           DHCP Failover Protocol              March 2003


   UPDREQ or UPDREQALL message, the server will remain in RECOVER state,
   and will re-issue the UPDREQ or UPDREQALL when communications are
   re-established.  (See section 5.17).

   If an UPDDONE message isn't received within an implementation depen-
   dent amount of time, and no BNDUPD messages are being received, the
   connection SHOULD be dropped.




                A                                        B
              Server                                  Server

                |                                        |
             RECOVER                               PARTNER-DOWN
                |                                        |
                | >--UPDREQ-------------------->         |
                |                                        |
                |        <---------------------BNDUPD--< |
                | >--BNDACK-------------------->         |
               ...                                      ...
                |                                        |
                |        <---------------------BNDUPD--< |
                | >--BNDACK-------------------->         |
                |                                        |
                |        <--------------------UPDDONE--< |
                |                                        |
           RECOVER-WAIT                                  |
                |                                        |
                | >--STATE-(RECOVER-WAIT)------>         |
                |                                        |
                |                                        |
       Wait MCLT from last known                         |
          time of failover operation                     |
                |                                        |
           RECOVER-DONE                                  |
                |                                        |
                | >--STATE-(RECOVER-DONE)------>         |
                |                                     NORMAL
                |        <-------------(NORMAL)-STATE--< |
             NORMAL                                      |
                | >---- State-(NORMAL)--------------->
                |                                        |
                |                                        |

              Figure 9.5.2-1:  Transition out of RECOVER state




Droms, et. al.           Expires September 2003                [Page 96]

Internet Draft           DHCP Failover Protocol              March 2003



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

9.6.  RECOVER-WAIT state

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

9.6.1.  Operation in RECOVER-WAIT state

   A server in RECOVER-WAIT MUST NOT respond to DHCP client requests.

9.6.2.  Transitions out of RECOVER-WAIT state

   Upon entry to RECOVER-WAIT state the server MUST start a timer whose
   expiration is set to a time equal to the time the server went down
   (if known) or the time the server started (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 by this server
   prior to loss of its client binding information in stable storage to
   contact the other server or to time out.

   If this is the first time this server has run failover -- as
   determined by the information received from the partner, not
   necessarily only as determined by this server's stable storage (as
   that may have been lost), then the waiting time discussed above may
   be skipped, and the server may transition immediately to RECOVER-DONE
   state.

   See Figure 9.5.2-1.

   DISCUSSION:

      The actual requirement on this wait period in RECOVER is that it
      start not before the 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 the recovering server
      (perhaps through actions of the network administrator), and the
      wait period could be reduced to the maximum-client-lead-time less



Droms, et. al.           Expires September 2003                [Page 97]

Internet Draft           DHCP Failover Protocol              March 2003


      the difference between the current time and the time the server
      failed.  In this way, the waiting period could be minimized.
      Various heuristics could be used to estimate this time, for
      example if the recovering server periodically updates stable
      storage with a time stamp, the wait period could be calculated to
      start at the time of the last update of stable storage plus the
      time required for the next update (which never occurred).  This
      estimate is later than the server went down, but probably not too
      much later.

      If the server has never before run failover, then there is no need
      to wait in this state -- but, again, to determine if this server
      has run failover it is vital that the information provided by the
      partner be utilized, since the stable storage of this server may
      have been lost.

   If communications fails while a server is in RECOVER-WAIT state, it
   has no effect on the operation of this state.  The server SHOULD
   continue to operate its timer, and the timer goes off during the
   period where communications with the other server have failed, then
   the server SHOULD transition to RECOVER-DONE state.  This is rare --
   failover state transitions are not usually made while communications
   are interrupted, but in this case there is no reason to inhibit the
   timer.  A server MAY state in RECOVER-WAIT state even after expiry of
   the timer and transition to RECOVER-DONE state upon re-establishing
   communications with the partner if desired.  The key point here is to
   allow the timer to continue to operate, not whether or not the state
   transition is made before or after communications are re-established.


9.7.  RECOVER-DONE state

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

9.7.1.  Operation in RECOVER-DONE state

   A server in RECOVER-DONE state MUST respond only to
   DHCPREQUEST/RENEWAL and DHCPREQUEST/REBINDING DHCP messages.

9.7.2.  Transitions out of RECOVER-DONE state

   When a server in RECOVER-DONE state determines that its partner
   server has entered NORMAL or RECOVER-DONE state, then it will transi-
   tion into NORMAL state.

   If communications fails while in RECOVER-DONE state, a server will



Droms, et. al.           Expires September 2003                [Page 98]

Internet Draft           DHCP Failover Protocol              March 2003


   stay in RECOVER-DONE state.


   9.8.  NORMAL state

   NORMAL state is the state used by a server when it is communicating
   with the other server, and any required resynchronization has been
   performed. While some bindings database synchronization is performed
   in NORMAL state, potential conflicts are resolved prior to entry into
   NORMAL state as is binding database data loss.


9.8.1.  Upon entry to NORMAL 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
   state is a secondary server, then it will request IP addresses for
   allocation using the POOLREQ message.


9.8.2.  Processing DHCP client requests and load balancing

   In NORMAL state, a 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 [RFC 3074].

   As discussed in section 5.3, each server will take the client-
   identifier from each DHCP client request (or the client-hardware-
   address, i.e., the chaddr if no client-identifier is present in the
   request) and use it as the 'Request ID' specified in [RFC 3074].
   After applying the algorithm specified in [RFC 3074] and comparing
   the result with the hash bucket assignment (performed during connect
   processing between failover servers), each failover server will be
   able to unambiguously determine if it should process the DHCP client
   request.

9.8.3.  Operation in NORMAL state

   When in NORMAL state, for every DHCP client request that it
   processes, as determined by the algorithm described in section 9.8.2,
   above, a server will operate in the following manner:

      o Lease time calculations

        As discussed in section 5.2.1, "Control of lease time", the



Droms, et. al.           Expires September 2003                [Page 99]

Internet Draft           DHCP Failover Protocol              March 2003


        lease interval given to a DHCP client can never be more than the
        MCLT greater than the most recently received potential-
        expiration-time from the failover partner or the current time,
        whichever is later.

        As long as a server adheres to this constraint, the specifics of
        the lease interval that it gives to a DHCP client or the value
        of the potential-expiration-time sent to its failover partner
        are implementation dependent.  One possible approach is dis-
        cussed in section 5.2.1, but that particular approach is in no
        way required by this protocol.

        See section 7.1.5 for details concerning the storage of time
        associated with IP addresses and how to use these times when
        calculating lease times for DHCP clients.

      o Lazy update of partner server

        After an DHCPACK of a IP address binding, the server servicing a
        DHCP client request attempts to update its partner with the new
        binding information.  The lease time used in the update of the
        secondary MUST be at least that given to the DHCP client in the
        DHCPACK, and the potential-expiration-time MUST be at least the
        lease time, and SHOULD be considerably longer.

      o Reallocation of IP addresses between clients

        Whenever a client binding is released or expires, a BNDUPD mes-
        sage must be sent to the partner, setting the binding state to
        RELEASED or EXPIRED.  However, until a BNDACK is received for
        this message, the IP address cannot be allocated to another
        client.  It cannot be allocated to the same client again if a
        BNDUPD was sent, otherwise it can.  See section 5.2.2.

   In normal state, each server receives binding updates from its
   partner server in BNDUPD messages.  It records these in its client
   binding database in stable storage and then sends a corresponding
   BNDACK message to its partner server.  It MUST ensure that the infor-
   mation is recorded in stable storage prior to sending the BNDACK mes-
   sage back to its partner.


9.8.4.  Transitions out of NORMAL state

   If an external command is received by a server in NORMAL state
   informing it that its partner is down, then transition into PARTNER-
   DOWN state.  Generally, this would be an unusual situation, where
   some external agency knew the partner server was down.  Using the



Droms, et. al.           Expires September 2003               [Page 100]

Internet Draft           DHCP Failover Protocol              March 2003


   command in this case would be appropriate if the polling interval and
   timeout were long.

   If a server in NORMAL state fails to receive acks to messages sent to
   its partner for an implementation dependent period of time, it MAY
   move into COMMUNICATIONS-INTERRUPTED state.  This situation might
   occur if the partner server was capable of maintaining the TCP con-
   nection between the server and also capable of sending a CONTACT mes-
   sage every tSend seconds, but was (for some reason) incapable of pro-
   cessing BNDUPD messages.

   If the communications is determined to not be "ok" (as defined in
   section 8), then transition into COMMUNICATIONS-INTERRUPTED state.

   If a server in NORMAL state receives any messages from its partner
   where the partner has changed state from that expected by the server
   in NORMAL state, then the server should transition into
   COMMUNICATIONS-INTERRUPTED state and take the appropriate state tran-
   sition from there.  For example, it would be expected for the partner
   to transition from POTENTIAL-CONFLICT into NORMAL state, but not for
   the partner to transition from NORMAL into POTENTIAL-CONFLICT state.

   If a server in NORMAL state receives any messages from its partner
   where the PARTNER has changed into PAUSED state, the server should
   transition into COMMUNICATIONS-INTERRUPTED state.  If a server in
   NORMAL state receives any messages from its partner where the PARTNER
   has changed into SHUTDOWN state, the server should transition into
   PARTNER-DOWN state.

9.9.  COMMUNICATIONS-INTERRUPTED State

   A server goes into COMMUNICATIONS-INTERRUPTED state whenever it is
   unable 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 server
   cycles between operational and non-operational.  No duplicate IP
   address allocation can occur while the servers cycle between these
   states.


9.9.1.  Upon entry to COMMUNICATIONS-INTERRUPTED state

   When a server enters COMMUNICATIONS-INTERRUPTED state, if it has been
   configured to support an automatic transition out of COMMUNICATIONS-
   INTERRUPTED state and into PARTNER-DOWN state (i.e., a "safe period"
   has been configured, see section 10), then a timer MUST be started
   for the length of the configured safe period.



Droms, et. al.           Expires September 2003               [Page 101]

Internet Draft           DHCP Failover Protocol              March 2003


   A server transitioning into the COMMUNICATIONS-INTERRUPTED state from
   the NORMAL state SHOULD raise some alarm condition to alert adminis-
   trative staff to a potential problem in the DHCP subsystem.


9.9.2.  Operation in COMMUNICATIONS-INTERRUPTED State

   In this state a server MUST respond to all DHCP client requests, and
   the algorithm for load balancing described 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, and 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 irrespec-
   tive of whether 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 latest of: 1) the potential-expiration-
   time already acknowledged by the other server, or 2) the lease-
   expiration-time, or 3) the potential-expiration-time received from
   the partner server.

   However, since the server cannot communicate with its partner in this
   state, the acknowledged-potential-expiration time will not be updated
   in any new bindings.  This is likely to eventually cause the actual-
   client-lease-times to be the current time plus the maximum-client-
   lead-time (unless this is greater than the desired-client-lease-
   time).

   The server should continue to try to establish a connection with its
   partner.


9.9.3.  Transition out of COMMUNICATIONS-INTERRUPTED State

   If the safe period timer expires while a server is in the
   COMMUNICATIONS-INTERRUPTED state, it will transition immediately into
   PARTNER-DOWN state.

   If an external command is received by a server in COMMUNICATIONS-
   INTERRUPTED state informing it that its partner is down, it will
   transition immediately into PARTNER-DOWN state.

   If communications is restored with the other server, then the server
   in COMMUNICATIONS-INTERRUPTED state will transition into another
   state based on the state of the partner:

      o partner in NORMAL or COMMUNICATIONS-INTERRUPTED




Droms, et. al.           Expires September 2003               [Page 102]

Internet Draft           DHCP Failover Protocol              March 2003


        The partner SHOULD NOT be in NORMAL state 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 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, POTENTIAL-CONFLICT, CONFLICT-DONE, or
        RESOLUTION-INTERRUPTED

        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 the transition from NORMAL to
   COMMUNICATIONS-INTERRUPTED state and then back to NORMAL state again.




















Droms, et. al.           Expires September 2003               [Page 103]

Internet Draft           DHCP Failover Protocol              March 2003



             Primary                                Secondary
              Server                                  Server

              NORMAL                                  NORMAL
                | >--CONTACT------------------->         |
                |        <--------------------CONTACT--< |
                |         [TCP connection broken]        |
           COMMUNICATIONS          :              COMMUNICATIONS
             INTERRUPTED           :                INTERRUPTED
                |      [attempt new TCP connection]      |
                |         [connection succeeds]          |
                |                                        |
                | >--CONNECT------------------->         |
                |        <-----------------CONNECTACK--< |
                |                                     NORMAL
                |        <-------------------STATE-----< |
              NORMAL                                     |
                | >--STATE--------------------->         |
                |
                | >--BNDUPD-------------------->         |
                |        <---------------------BNDACK--< |
                |                                        |
                |        <---------------------BNDUPD--< |
                | >------BNDACK---------------->         |
               ...                                      ...
                |                                        |
                |        <--------------------POOLREQ--< |
                | >--POOLRESP-(2)-------------->         |
                |                                        |
                | >--BNDUPD-(#1)--------------->         |
                |        <---------------------BNDACK--< |
                |                                        |
                |        <--------------------POOLREQ--< |
                | >--POOLRESP-(0)-------------->         |
                |                                        |
                | >--BNDUPD-(#2)--------------->         |
                |        <---------------------BNDACK--< |
                |                                        |

       Figure 9.9.3-1:  Transition from NORMAL to COMMUNICATIONS-
                        INTERRUPTED and back (example with 2
                        addresses allocated to secondary)








Droms, et. al.           Expires September 2003               [Page 104]

Internet Draft           DHCP Failover Protocol              March 2003



9.10.  POTENTIAL-CONFLICT state

   This state indicates that the two servers are attempting to re-
   integrate with each other, but at least one of them was running in a
   state that did not guarantee automatic reintegration would be
   possible.  In POTENTIAL-CONFLICT state the servers may determine that
   the same IP address has been offered and accepted by two different
   DHCP clients.

   It is a goal of this protocol to minimize the possibility that
   POTENTIAL-CONFLICT state is ever entered.

9.10.1.  Upon entry to POTENTIAL-CONFLICT state

   When a primary server enters POTENTIAL-CONFLICT state it should
   request that the secondary send it all updates of which it is
   currently unaware by sending an UPDREQ message to the secondary
   server.

   A secondary server entering POTENTIAL-CONFLICT state will wait for
   the primary to send it an UPDREQ message.

9.10.2.  Operation in POTENTIAL-CONFLICT state

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


9.10.3.  Transitions out of POTENTIAL-CONFLICT state

   If communications fails with the partner while in POTENTIAL-CONFLICT
   state, then the server will transition to RESOLUTION-INTERRUPTED
   state.

   Whenever either server receives an UPDDONE message from its partner
   while in POTENTIAL-CONFLICT state, it MUST transition to a new state.
   The primary MUST transition to CONFLICT-DONE state, and the secondary
   MUST transition to NORMAL state.  This will cause the primary server
   to leave POTENTIAL-CONFLICT state prior to the secondary, since the
   primary sends an UPDREQ message and receives an UPDDONE before the
   secondary sends an UPDREQ message and receives its UPDDONE message.

   When a secondary server receives an indication that the primary
   server has made a transition from POTENTIAL-CONFLICT to CONFLICT-DONE
   state, it SHOULD send an UPDREQ message to the primary server.





Droms, et. al.           Expires September 2003               [Page 105]

Internet Draft           DHCP Failover Protocol              March 2003




              Primary                                Secondary
              Server                                  Server

                |                                        |
         POTENTIAL-CONFLICT                    POTENTIAL-CONFLICT
                |                                        |
                | >--UPDREQ-------------------->         |
                |                                        |
                |        <---------------------BNDUPD--< |
                | >--BNDACK-------------------->         |
               ...                                      ...
                |                                        |
                |        <---------------------BNDUPD--< |
                | >--BNDACK-------------------->         |
                |                                        |
                |        <--------------------UPDDONE--< |
          CONFLICT-DONE                                  |
                | >--STATE--(CONFLICT-DONE)---->         |
                |        <---------------------UPDREQ--< |
                |                                        |
                | >--BNDUPD-------------------->         |
                |        <---------------------BNDACK--< |
               ...                                      ...
                | >--BNDUPD-------------------->         |
                |        <---------------------BNDACK--< |
                |                                        |
                | >--UPDDONE------------------->         |
                |                                     NORMAL
                |        <------------STATE--(NORMAL)--< |
             NORMAL                                      |
                | >--STATE--(NORMAL)----------->         |
                |                                        |
                |        <--------------------POOLREQ--< |
                | >------POOLRESP-(n)---------->         |
                |              addresses                 |

           Figure 9.10.3-1:  Transition out of POTENTIAL-CONFLICT












Droms, et. al.           Expires September 2003               [Page 106]

Internet Draft           DHCP Failover Protocol              March 2003



9.11.  RESOLUTION-INTERRUPTED state

   This state indicates that the two servers were attempting to re-
   integrate with each other in POTENTIAL-CONFLICT state, but
   communications failed prior to 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.11.1.  Upon entry to RESOLUTION-INTERRUPTED state

   When a server enters RESOLUTION-INTERRUPTED state it SHOULD raise an
   alarm condition to alert administrative staff of a problem in the
   DHCP subsystem.

9.11.2.  Operation in RESOLUTION-INTERRUPTED state

   In this state a server MUST respond to all DHCP client requests, and
   any load balancing (described in section 5.3) MUST NOT be used.  When
   allocating new IP addresses, each server 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 renewal requests, each
   server will allow continued renewal of a DHCP client's current lease
   on an IP address irrespective of whether 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 latest of: 1)
   the potential-expiration-time already acknowledged by the other
   server or 2) the lease-expiration-time or 3) `potential-expiration-
   time received from the partner server.

   However, since the server cannot communicate with its partner in this
   state, the acknowledged-potential-expiration time will not be updated
   in any new bindings.


9.11.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 other server, then the server
   in RESOLUTION-INTERRUPTED state will transition into POTENTIAL-
   CONFLICT state.



Droms, et. al.           Expires September 2003               [Page 107]

Internet Draft           DHCP Failover Protocol              March 2003



9.12.  CONFLICT-DONE state

   This state indicates that during the process where the two servers
   are attempting to re-integrate with each other, the primary server
   has received all of the updates from the secondary server.  It make a
   transition into CONFLICT-DONE state in order that it may be totally
   responsive to the client load, as opposed to NORMAL state where it
   would be in a "balanced" responsive state, running the load balancing
   algorithm.

9.12.1.  Upon entry to CONFLICT-DONE state

   A secondary server should never enter CONFLICT-DONE state.

9.12.2.  Operation in CONFLICT-DONE state

   A primary server in CONFLICT-DONE state is fully responsive to all
   DHCP clients (similar to the situation in COMMUNICATIONS-INTERRUPTED
   state).

   If communications fails, remain in CONFLICT-DONE state.  If communi-
   cations becomes OK, remain in CONFLICT-DONE state until the condi-
   tions for transition out become satisfied.


9.12.3.  Transitions out of CONFLICT-DONE state

   If communications fails with the partner while in CONFLICT-DONE
   state, then the server will remain in CONFLICT-DONE state.

   When a primary server determines that the secondary server has made a
   transition into NORMAL state, the primary server will also transition
   into NORMAL state.

9.13.  PAUSED state

   This state exists to allow one server to inform another that it will
   be out of service for what 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
   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 server-state option containing PAUSED
   state and close the TCP connection.

   While a server may or may not transition internally into PAUSED



Droms, et. al.           Expires September 2003               [Page 108]

Internet Draft           DHCP Failover Protocol              March 2003


   state, the 'previous' state determined when it is restarted MUST be
   the state the server was in prior to receiving the command to shut-
   down and restart and which precedes its entry into the PAUSED state.
   See section 9.3.2 concerning the use of the previous state upon
   server restart.

9.13.1.  Upon entry to PAUSED state

   When entering PAUSED state, the server MUST store the previous state
   in stable storage, and use that state as the previous state when it
   is restarted.

9.13.2.  Transitions out of PAUSED state

   A server makes a transition out of PAUSED state by being restarted.
   At that time, the previous state MUST be the state the server was in
   prior to entering the PAUSED state.


9.14.  SHUTDOWN state

   This state exists to allow one server to inform another that it will
   be out of service for what is predicted to be a relatively long time,
   and to allow the other server to transition immediately to PARTNER-
   DOWN state, and take over completely for the server going down.

9.14.1.  Upon entry to SHUTDOWN state

   When entering SHUTDOWN state, the server MUST record the previous
   state in stable storage for use when the server is restarted.  It
   also MUST record the current time as the last time operational.

   A server which is aware that it is shutting down SHOULD send a STATE
   message with the server-state field containing SHUTDOWN.

9.14.2.  Operation in SHUTDOWN state

   A server in SHUTDOWN state MUST NOT respond to any DHCP client input.

   If a server receives any message indicating that the partner has
   moved to PARTNER-DOWN state while it 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 a few seconds after informing the partner of
   entry into SHUTDOWN state (if communications are okay) to determine
   if the partner entered PARTNER-DOWN state.




Droms, et. al.           Expires September 2003               [Page 109]

Internet Draft           DHCP Failover Protocol              March 2003


9.14.3.  Transitions out of SHUTDOWN state

   A server makes a transition out of SHUTDOWN state by being restarted.

10.  Safe Period

   Due to the restrictions imposed on each server while in
   COMMUNICATIONS-INTERRUPTED state, long-term operation in this state
   is not feasible for either server.  One reason that these states
   exist at all, is to allow the servers to easily survive transient
   network communications failures of a few minutes to a few days
   (although the actual time periods will depend a great deal on the
   DHCP activity of the network in terms of arrival and departure of
   DHCP clients on the network).

   Eventually, when the servers are unable to communicate, they will
   have 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 they can move into this state (known as PARTNER-
   DOWN).

   They can either be informed by external command that, indeed, the
   partner server is down.  In this case, there is no difficulty in mov-
   ing into the PARTNER-DOWN state since it is an accurate reflection of
   reality and the protocol has been designed to operate correctly (even
   during reintegration) as long as, when in PARTNER-DOWN state the
   partner is, indeed, down.

   The more difficult scenario is when the servers are running unat-
   tended for extended periods, and in this case an option is provided
   to configure something called a "safe-period" into each server.  This
   OPTIONAL safe-period is the period after which either the primary or
   secondary server will automatically transition 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.

   The goal of the "safe-period" is to allow network operations staff
   some time to react to a server moving into COMMUNICATIONS-INTERRUPTED
   state.  During the safe-period the only requirement is that the net-
   work operations staff determine if both servers are still running --
   and if they are, to either fix the 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
   in large part on the number of unallocated IP addresses within the
   subnet address pool and the expected frequency of arrival of



Droms, et. al.           Expires September 2003               [Page 110]

Internet Draft           DHCP Failover Protocol              March 2003


   previously unknown DHCP clients requiring IP addresses.  Many
   environments should 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 the DHCP server to hand out to new DHCP clients and the
   need to re-allocate IP addresses to different DHCP clients.

   The number of "extra" IP addresses required is equal to the expected
   total number of new DHCP clients encountered during the safe period.
   This is dependent only on the arrival rate of new DHCP clients, not
   the total number of outstanding leases on IP addresses.

   In the 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 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 allocation
   exists, and re-integration after the failure is 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 encrypt the
   data over the wire is likely not great (though some sites may feel
   differently).

   However, it is very desirable to 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 information to one or both servers.

   Therefore, the Failover protocol MUST be capable of being secured by
   using a simple shared secret message digest which 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 fake TCP RST
   segments). IPsec [RFC 2401] SHOULD be used to protect against most
   (if not all) of these kinds of attacks.





Droms, et. al.           Expires September 2003               [Page 111]

Internet Draft           DHCP Failover Protocol              March 2003


11.1.  Simple shared secret

   Messages between the failover partners can be authenticated through
   the use of a shared secret, which is never sent over the network and
   must be known by each server. How each server 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 message-digest option in ALL
   messages to that partner and it MUST treat any messages received from
   that partner without a message-digest option as failing authentica-
   tion and reject them with reject reason 21: "Missing message digest".
   Note that the message digest option MUST be the first option in the
   message.

   If a server is not configured with a shared secret for a partner, it
   MUST NOT send the message-digest option in any message to that
   partner and it MUST treat any messages received from that partner
   with a message-digest option as failing authentication with reject
   reason 13: "Message digest not configured".

   The shared secret is used to calculate a 16 octet message-digest
   which is sent in every failover message in the message-digest option.
   See section 12.16. The message-digest contains a one-way 16 octet
   HMAC-MD5 [RFC 2104] hash calculated over a stream of octets consist-
   ing of the entire message concatenated with the shared secret.

   For calculation, the message includes the message-digest option with
   the message-digest data zeroed (16-octets of zero). Once the calcula-
   tion is complete, these 16 octets of zero are replaced by the 16-
   octet HMAC-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 HMAC-
   MD5 hash is compared to the received hash and if they match, the mes-
   sage is assumed authenticated.

   A failover partner that fails to authenticate a received message or
   receives a message without a message-digest option when configured
   with a shared secret MUST close the connection immediately and take
   steps to notify operators.

   Every time a CONNECT message is received, the time at which that mes-
   sage was sent by the partner (i.e., the time that actually appears in
   the message itself) MUST be saved.  If a CONNECT message is ever
   received containing that time or containing a time before that time,
   it MUST be rejected.

   The XID (see section 6.1) of every message received at a failover



Droms, et. al.           Expires September 2003               [Page 112]

Internet Draft           DHCP Failover Protocol              March 2003


   endpoint MUST be greater than that of the previous message received
   on that failover endpoint or the message just received MUST be
   rejected.

   A server MAY operate with arbitrary time skew between servers (see
   section 5.10), but when using a shared secret administrators MAY wish
   to configure a maximum allowable time skew between a failover server
   and its partner(s).  Servers SHOULD allow an administrator to config-
   ure a maximum allowable time skew between two failover partners.

11.2.  TLS

   TLS, Transport Layer Security, as specified in [RFC 2246] MAY be
   used.  The use of TLS would be similar to the way it is used with
   SMTP [RFC 2487] and IMAP/POP3/ACAP [RFC 2595].

   To request the use of TLS, the primary MUST send the TLS-request
   option as part of the CONNECT message. The secondary receiving the
   TLS-request option MUST respond with a TLS-reply option indicating
   its acceptance or rejection of the TLS-request in the CONNECT mes-
   sage."

   If the CONNECTACK message contained a TLS-reply of 1 , then both
   servers immediately begin TLS negotiation.

   Upon completion of this negotiation, the primary server sends another
   CONNECT message without any TLS-request option, and must wait for a
   corresponding CONNECTACK.

   Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [RFC 2246]
   cipher suite is REQUIRED in Failover servers supporting TLS. This is
   important as it assures that any two compliant implementations can be
   configured to interoperate.

12.  Failover Options

   This section lists all of the options that are currently defined to
   be used with the failover protocol.  See section 6.2 for details con-
   cerning time values.












Droms, et. al.           Expires September 2003               [Page 113]

Internet Draft           DHCP Failover Protocol              March 2003



12.1.  addresses-transferred

   A 32 bit unsigned long in network byte order. Reports the number of
   addresses transferred by the primary to the secondary server
   (addresses to be used for the secondary server's private address
   pool).

        Code        Len       Number of 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 of a 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 to the primary
   2     ACTIVE         Lease is assigned to a client
   3     EXPIRED        Lease has expired
   4     RELEASED       Lease has been released by client
   5     ABANDONED      A server, or client flagged address as unusable
   6     RESET          Lease was freed by some external agent
   7     BACKUP         Lease belongs to secondary's private address pool







Droms, et. al.           Expires September 2003               [Page 114]

Internet Draft           DHCP Failover Protocol              March 2003



12.4.  client-identifier

   This is the client-identifier for the client associated with a
   binding.  The client-identifier data is subject to the same
   conventions as DHCP option 81 [RFC 2132].

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


12.5.  client-hardware-address

   This is the hardware address for the client associated with a
   binding.  Byte t1 (type) MUST be set to the proper ARP hardware
   address code, as defined in the ARP section of 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 last received a DHCP request from a
   particular client expressed as an absolute time (see section 6.2).


        Code        Len    client last transaction time
   +-----+-----+-----+-----+----+-----+-----+-----+
   |  0  |  6  |  0  |  4  | t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+----+-----+-----+-----+















Droms, et. al.           Expires September 2003               [Page 115]

Internet Draft           DHCP Failover Protocol              March 2003



12.7.  client-reply-options

   This option contains options from a DHCP server's reply to a DHCP
   client request.  It is sent in a BNDUPD message.  The first 4 bytes
   of the option contain the "magic number" of the option area from
   which the DHCP reply options were taken and serves to define the
   format of the rest of the sub-options contained in this option.
   After the magic number, the options included are in the normal
   options format appropriate for that magic number.

   A server SHOULD NOT include all of the options in a DHCP server's
   reply to a client's request in this option, but rather a server
   SHOULD include only those options which are of likely interest to its
   partner server.  See section 7.1 for 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
   sent in a BNDUPD message.  The first 4 bytes of the option contain
   the "magic number" of the option area from which the DHCP client's
   request options were taken and serves to define the format of the
   rest of the sub-options contained in this option.  After the magic
   number, the options included are in the normal options format
   appropriate for that magic number.

   A server SHOULD NOT include all of the options in a DHCP client
   request in this option, but rather a server SHOULD include only those
   options which are of likely interest to 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 |  ...
   +-----+-----+-----+-----+----+----+----+----+----+----+--










Droms, et. al.           Expires September 2003               [Page 116]

Internet Draft           DHCP Failover Protocol              March 2003



12.9.  DDNS

   If an implementation supports Dynamic DNS updates, this option is
   used to communicate the status of the DDNS update associated with a
   particular lease binding.  The Flags field conveys the types of DNS
   RRs that are to be updated by the DHCP server, and the status of the
   DDNS update.  The Domain Name field conveys the DNS FQDN that the
   DHCP server is using to refer to the client, in DNS encoding as
   specified in [RFC 1035].

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

   The Flags field is 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 least-significant bit in network
   byte-order) are used as follows:

   0 (C): name to address (such as A RR) update successfully completed
   1 (A): Server is controlling A RR on behalf of the client
   2 (D): address to name (such as PTR RR) update successfully completed (Done)
   3 (P): Server is controlling PTR RR on behalf of the client
   4-15 : Must be zero

   All of the unspecified bit positions SHOULD be set to 0 by servers
   sending the Failover-DDNS option, and they MUST be ignored by servers
   receiving the option.














Droms, et. al.           Expires September 2003               [Page 117]

Internet Draft           DHCP Failover Protocol              March 2003



12.10.  delayed-service-parameter

   The delayed-service-parameter is an optional load balancing tuning
   parameter, defined in [RFC 3074].  If it is used, it MUST be sent in
   the same message as the hash-bucket-assignment option (see section
   12.11).

   Format :


       Code        Len    Seconds
   +-----+-----+-----+-----+----+
   |  0  |  10 |  0  |  1  | S  |
   +-----+-----+-----+-----+----+

   S is a one byte value, 1..255.


12.11.  hash-bucket-assignment

   A set of load balancing hash values for the secondary server.  A one
   bit in the hash buckets indicates that the secondary is to service
   that set of clients.  See section 5.3 for more information on how
   this option is used.  This option is only sent from the primary to
   the secondary.

   The format and usage of the data in this option is defined in [RFC
   3074].

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

















Droms, et. al.           Expires September 2003               [Page 118]

Internet Draft           DHCP Failover Protocol              March 2003



12.12.  IP-flags

   This option is used to convey the current flags of the assigned-IP-
   address option preceding it.

       Code         Len       IP Flags
   +-----+-----+-----+-----+-----+-----+
   |  0  |  12 |  0  |  1  |  f1 |  f2 |
   +-----+-----+-----+-----+-----+-----+

   The IP-flags field is a 16-bit field; two 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|B|           MBZ             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The bits (numbered from the least-significant bit in network
   byte-order) are used as follows:

   0 (R): RESERVED  (this bit allocated and in use and named "RESERVED")
          Bit 0 MUST be set to 1 whenever the IP address in the preceding
          assigned-IP-address option is reserved on the server sending the
          packet.
   1 (B): BOOTP
          Bit 1 MUST be set to 1 whenever the IP address in the preceding
          assigned-IP-address option is a an IP address which has been
          allocated due to an interaction with a BOOTP client (as opposed
          to a DHCP client).
   2-15  : Must be zero


















Droms, et. al.           Expires September 2003               [Page 119]

Internet Draft           DHCP Failover Protocol              March 2003



12.13.  lease-expiration-time

   The lease expiration time is the lease interval that a DHCP server
   has ACKed to a DHCP client added to the time at which that ACK was
   transmitted -- expressed as an absolute time (see section 6.2).


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


12.14.  max-unacked-bndupd

   The maximum number of BNDUPD message that this server is prepared to
   accept over the TCP connection without causing the TCP connection to
   block.  A 32 bit unsigned integer value, in network byte order.


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


12.15.  MCLT

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

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















Droms, et. al.           Expires September 2003               [Page 120]

Internet Draft           DHCP Failover Protocol              March 2003



12.16.  message

   This option is used to supply a human readable message text.  It may
   be used in association with the Reject Reason Code to provide a human
   readable error message for the reject.


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


12.17.  message-digest

   The message digest for this message.

   This option consists of a variable number of bytes which contain the
   message digest of the message prior to the inclusion of this option.

   When this option appears in a message, it MUST appear as the first
   option in the message.  It MUST appear in every message if message
   digests are required.  The Type MUST be configurable (once additional
   types are defined).  When additional types are defined, they MUST be
   specified as either optional (MAY be supported) or required (MUST be
   supported).  See the section on IANA considerations for more details.

        Code        Len      Type   Message Digest
   +-----+-----+-----+-----+-----+-----+-----+--
   |  0  |  17 |  0  |  n  |  t  |  d1 |  d2 | ...
   +-----+-----+-----+-----+-----+-----+-----+--


      Type:    0      Not Allowed
               1      HMAC-MD5
               2-255  Not Allowed














Droms, et. al.           Expires September 2003               [Page 121]

Internet Draft           DHCP Failover Protocol              March 2003



12.18.  potential-expiration-time

   The potential expiration time is the time that one server tells
   another server that it may wish to grant in a lease to a DHCP client.
   It is an absolute time.  See section 6.2.


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


12.19.  receive-timer

   The number of seconds (an interval) within which the server must
   receive a message from its partner, or it will assume that
   communications with the partner is not ok.  An unsigned 32 bit
   integer in network byte order.

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


12.20.  protocol-version

   The protocol version being used by the server. It is only sent in the
   CONNECT and CONNECTACK messages.  The current value for the version
   is 1.

        Code        Len    Version
   +-----+-----+-----+-----+-----+
   |  0  |  20 |  0  |  1  |  1  |
   +-----+-----+-----+-----+-----+














Droms, et. al.           Expires September 2003               [Page 122]

Internet Draft           DHCP Failover Protocol              March 2003



12.21.  reject-reason

   This option is used to selectively reject binding updates. It MAY be
   used in a BNDACK message or a CONNECTACK message, always associated
   with an assigned-IP-address option, which contains the IP address of
   the update being rejected.

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

   Reason codes (section where referenced in parentheses):

   0   Reserved
   1   Illegal IP address (not part of any address pool). (7.1.3)
   2   Fatal conflict exists: address in use by other client. (7.1.3)
   3   Missing binding information. (7.1.3)
   4   Connection rejected, time mismatch too great. (7.8.2)
   5   Connection rejected, invalid MCLT. (7.8.2)
   6   Connection rejected, unknown reason. (not specifically referenced)
   7   Connection rejected, duplicate connection. (unused)
   8   Connection rejected, invalid failover partner. (7.8.2)
   9   TLS not supported. (7.8.2)
   10  TLS supported but not configured. (7.8.2)
   11  TLS required but not supported by partner. (7.8.2)
   12  Message digest not supported. (11.1)
   13  Message digest not configured. (11.1)
   14  Protocol version mismatch. (7.8.2)
   15  Outdated binding information. (7.1.3)
   16  Less critical binding information. (7.1.3)
   17  No traffic within sufficient time. (8.6)
   18  Hash bucket assignment conflict. (7.8.2)
   19  IP not reserved on this server. (7.1.3)
   20  Message digest failed to compare. (7.8.2)
   21  Missing message digest. (7.1.3)
   22-253, reserved.
   254 Unknown: Error occurred but does not match any reason code.
   255 Reserved for code expansion.











Droms, et. al.           Expires September 2003               [Page 123]

Internet Draft           DHCP Failover Protocol              March 2003



12.22.  relationship-name

   A string which is a unique identifier for the failover relationship.

        Code        Len       Relationship Name
   +-----+-----+-----+-----+----+-----+---
   |  0  |  22 |  0  |  n  | c1 |  c2 |  ...
   +-----+-----+-----+-----+----+-----+---


12.23.  server-flags

   This option is used to convey the current flags of the failover
   endpoint in the sending server.

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

   The flags field is 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
   byte-order) are used as follows:

   0 (S): STARTUP,
          Bit 0 MUST be set to 1 whenever the server is in STARTUP state,
          and set to 0 otherwise.  (Note that when in STARTUP state, the
          state transmitted in the server-state option is usually the last
          recorded state from stable storage, but see section 9.3 for
          details.)
   1-7  : Must be zero











Droms, et. al.           Expires September 2003               [Page 124]

Internet Draft           DHCP Failover Protocol              March 2003



12.24.  server-state

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

       Code         Len   Server State
   +-----+-----+-----+-----+-----+
   |  0  |  24 |  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
   10      RESOLUTION-INTERRUPTED       Comm. failed during resolution
   11      CONFLICT-DONE                Primary has resolved its conflicts

   (1) The STARTUP state is never sent to the partner server, it is
   indicated by the STARTUP bit in the server-flags options (see section
   12.22).


12.25.  start-time-of-state

   This option is used for different states in different messages.  In a
   BNDUPD message it represents the start time of the state of the lease
   in the BNDUPD message.  In a STATE message, it represents the start
   time of the partner server's failover state.  In all cases it is an
   absolute time.


        Code        Len      Start Time of State
   +-----+-----+-----+-----+----+-----+-----+-----+
   |  0  |  25 |  0  |  4  | t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+----+-----+-----+-----+




Droms, et. al.           Expires September 2003               [Page 125]

Internet Draft           DHCP Failover Protocol              March 2003



12.26.  TLS-reply

   This option contains information relating to TLS security
   negotiation.  It is sent in a CONNECTACK message

   A t1 value of 0 indicates no TLS operation, a value of 1 indicates
   that TLS operation is required.

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


12.27.  TLS-request

   This option contains information relating to TLS security
   negotiation.  It is sent in a CONNECT message.

   The t1 byte is the TLS request from the primary server.  A value of 0
   indicates no TLS operation (to communicate the secondary server MUST
   NOT require TLS), a value of 1 indicates that TLS operation is
   desired but not required (to communicate, the secondary server MAY
   utilize TLS), and a value of 2 indicates that TLS operation is
   required (to communicate the secondary server MUST utilize TLS) to
   establish communications with the primary server.

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


12.28.  vendor-class-identifier

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

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








Droms, et. al.           Expires September 2003               [Page 126]

Internet Draft           DHCP Failover Protocol              March 2003



12.29.  vendor-specific-options

   This option is used to convey options specific to a particular
   vendor's implementation.  The vendor class identifier is used to
   specify which option space the embedded options are drawn from.
   Every message that uses vendor specific options MUST have a vendor-
   class-identifier option in it.

   It functions similarly to the vendor class identifier and vendor
   specific options in the DHCP protocol.

   This option contains other options in the same two byte code, two
   byte length format.  If this option appears in a message without a
   corresponding vendor class identifier, it MUST be ignored.

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




13.  IANA Considerations

   This document defines several number spaces (failover options, fail-
   over message types, message digest types, and failover reject reason
   codes). For all of these number spaces, certain values are defined in
   this specification.  New values may only be defined by IETF Con-
   sensus, as described in [RFC 2434]. Basically, this means that 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



Droms, et. al.           Expires September 2003               [Page 127]

Internet Draft           DHCP Failover Protocol              March 2003


   Failover draft by Greg Rabil, Mike Dooley, Arun Kapur and Ralph
   Droms.  This draft posited only two servers -- a primary and a secon-
   dary.

   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.

   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.

   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 of
   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 -05 includes changes as a result of those calls,
   perhaps the largest of which was to remove the load balancing



Droms, et. al.           Expires September 2003               [Page 128]

Internet Draft           DHCP Failover Protocol              March 2003


   approach into a separate draft.   Thanks to all of the many people
   who participated in the conference calls.  Changes were made because
   of contributions by: Ted Lemon, David Erdmann, Richard Jones, Rob
   Stevens, Thomas Narten, Diana Lane, and Andre Kostur.

   Another conference call was held in mid-January of 2000, and the -06
   draft was produced to tighten up the the -05 draft both technically
   as well as editorially.

   The -07 draft was edited by Kim Kinnear and was based in part on
   reviews by Richard Jones, Bernie Volz, and Steve Gonczi.  It embodies
   several technical updates as well as numerous editorial revisions
   that enhanced both correctness as well as clarity.

   The -08 draft was edited by Kim Kinnear and was based on the results
   of two conference calls held in October and November of 2000.  It
   includes the correct second port number, a new state to synchronize
   conflict resolution with load balancing, a generally accepted
   approach to secondary pool allocation, and many other updates based
   on both operational as well as implementation experience.

   The -09 draft was edited by Kim Kinnear based on discussions held at
   the Minneapolis IETF in December of 2000, as well as issues raised by
   Ted Lemon based on implementation and deployment.  The specific
   changes were mailed to the dhcp-v4 list.

   The -10 draft differed from the -09 draft in that figure 9.8.3-1 was
   correctly relabeled figure 9.10.3-1, and it was updated to include
   the CONFLICT-DONE message.  One of the authors affiliations was also
   updated.

   This, the -11 draft differs only slightly from the -10 draft in
   correcting another author affiliation.

   These most recent changes have not been widely circulated among the
   other authors prior to submission to the IETF.

   Glenn Waters of Nortel Networks contributed ideas and enthusiasm to
   make a Failover protocol that was both "safe" and "lazy".


15.  References


   [DHCID] Stapp, M., Lemon, T., Gustafsson, A., "draft-ietf-dnsext-
      dhcid-rr-02.txt", March, 2001.

   [DNSRES] Stapp, M., "draft-ietf-dhc-dns-resolution-01.txt", March,



Droms, et. al.           Expires September 2003               [Page 129]

Internet Draft           DHCP Failover Protocol              March 2003


      2001.

   [FQDN] Rekhter, Y., Stapp, M., "draft-ietf-dhc-fqdn-option-01.txt",
      March, 2001.

   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
      Specification", November, 1987.

   [RFC 1534] Droms, R., "Interoperation between DHCP and BOOTP", RFC
      1534, October 1993.

   [RFC 2104] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC: Keyed
      Hashing for Message Authentication", RFC 2104, IBM T.J. Watson
      Research Center, University of California at San Diego, February
      1997.

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

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

   [RFC 2401] Kent, S., Atkinson, R., "Security Architecture for the
      Internet Protocol", RFC 2401, November 1998.

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

   [RFC 2595] Newman, C., "Using TLS with IMAP, POP3, and ACAP", RFC
      2595, June 1999.




Droms, et. al.           Expires September 2003               [Page 130]

Internet Draft           DHCP Failover Protocol              March 2003


   [RFC 3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis,
      A., Privat, J.  "The User Class Option for DHCP", November 2000.

   [RFC 3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP",
      November 2000.

   [RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
      3046, January 2001.

   [RFC 3074] Volz, B., Gonczi, S., Lemon, T., Stevens, R., "DHC Load-
      balancing Algorithm", February, 2001.

16.  Author's information

      Ralph Droms
      Kim Kinnear
      Mark Stapp
      Cisco Systems
      250 Apollo Drive
      Chelmsford, MA  01824

      Phone: (978) 497-0000

      EMail: rdroms@cisco.com
             kkinnear@cisco.com
             mjs@cisco.com



      Bernie Volz
      Ericsson
      959 Concord St.
      Framingham, MA  01701

      Phone: (508) 875-3162

      EMail: bernie.volz@ericsson.com


      Steve Gonczi
      Relicore, Inc.
      One Wall Street
      Burlington, MA 01803

      Phone: (781) 229-1122

      Email: steve@relicore.com




Droms, et. al.           Expires September 2003               [Page 131]

Internet Draft           DHCP Failover Protocol              March 2003


      Greg Rabil
      Lucent Technologies
      400 Lapp Road
      Malvern, PA 19355

      Phone: (800) 208-2747

      EMail: grabil@lucent.com




      Michael Dooley
      Diamond IP Technologies
      One E Uwchlan Ave, Suite 112
      Exton, PA 19341

      EMail: mdooley@diamondip.com




      Arun Kapur
      K5 Networks
      2 Toll House Lane
      Colts Neck, NJ 07722

      Phone: (732) 817-9475

17.  Full Copyright Statement

Copyright (C) The Internet Society (2003). 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.



Droms, et. al.           Expires September 2003               [Page 132]

Internet Draft           DHCP Failover Protocol              March 2003


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.













































Droms, et. al.           Expires September 2003               [Page 133]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/