Network Working Group                                        Ralph Droms
INTERNET DRAFT                                       Bucknell University

                                                              Greg Rabil
                                                             Mike Dooley
                                                              Arun Kapur
                                                       Quadritek Systems

                                                             Kim Kinnear
						       American	Internet
                                                              Mark Stapp
                                                           Cisco Systems

                                                            Steve Gonczi
                                                             Bernie Volz
                                                        Process Software

							     August

                                                           November 1998
                                                       Expires March June 1999

                         DHCP Failover Protocol
		    <draft-ietf-dhc-failover-02.txt>
                    <draft-ietf-dhc-failover-03.txt>

Status of this Memo

   This document is an Internet-Draft.  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 Internet- Drafts as reference
   material or to cite them other than as ``work "work in progress.'' progress."

   To learn view the	current	status entire list of any Internet-Draft, current Internet-Drafts, please check the
   ``1id-abstracts.txt''
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), ftp.nordu.net (Northern
   Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim),
   ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

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 primary and
   Secondary

DRAFT                                                      November 1998

   secondary servers must maintain a consistent database of the lease

DRAFT							    January 1998
   information.  This implies that servers will need to coordinate any
   and all lease activity so that this information is synchronized in
   case of failover.

   This document defines a protocol to provide this synchronization
   between two servers. One server is designated the "Primary" server,
   the other is the "Secondary" server. Additionally, this document
   describes a protocol for the automatic transfer of control from the
   Primary
   primary to the Secondary secondary in the case of failure (failover), as well
   as a network partition.

   This document is a merge of draft-ietf-dhc-failover-01.txt and
   draft-ietf-dhc-safe-failover-proto-00.txt, along with substantial
   changes to each.  Unfortunately, this merge was not completed with
   sufficient time to allow review by any of further develops the authors of concepts presented in draft-ietf-
   dhc-failover-01.txt,	and so it may well not reflect their views even
   though their	names appear as	authors.  See Section 11, issue	#1 and
   Section 12 for more details.
   dhc-failover-02.txt.

1.  Introduction

   As the use of DHCP servers in networked environments grows, the
   dependency of those networks on the DHCP server increases.  This is
   particularly true of the hosts that receive their configuration
   information from the DHCP server.  Therefore, it is very important to
   be able to provide reliable, continuous availability of DHCP ser-
   vices.

   This specification describes a protocol to support automatic failover
   from a primary to its secondary server.  The failover mechanism
   allows the secondary server to perform DHCP actions while the primary
   is down, or when a network failure prevents the primary and secondary
   from communicating.  The protocol also specifies how reintegration is
   achieved when the primary again becomes operational or when the pri-
   mary and secondary can again communicate.

   In providing the specification for the failover, the protocol speci-
   fies how to guarantee reliable delivery of binding changes to the secondary.
   partner server.  This is required to synchronize the secondary's lease data with that
   of between
   the primary. primary and the secondary.  The protocol further specifies a
   mechanism to allow
   the secondary either server to determine if it can communicate
   with the primary
   server. its partner.  The secondary will automatically begin to service
   DHCP requests whenever it cannot communicate with the primary.  When
   the primary server becomes available again, the secondary will convey
   any changes that occurred since the time of failover back to the	primary. pri-
   mary.

   Through careful control of the difference between the lease times

DRAFT							    January 1998
   offered to DHCP clients and the lease time known by the secondary
   server, the protocol allows the primary to communicate with the
   secondary after the primary has completed communication with the DHCP
   client (a technique known as "lazy" update) and still guarantee that

DRAFT                                                      November 1998

   duplicate IP address allocations do not occur.  Thus, the protocol
   does not directly impact the ability of a DHCP server to respond to
   DHCP client requests.

1.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].

1.2.  DHCP Terminology

   This document uses the following terms:

      o "DHCP client" or "client"

        A DHCP client is an Internet host using DHCP to obtain confi-
        guration parameters such as a network address.

      o "DHCP server" or "server"

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

      o "binding"

        A binding is a collection of configuration parameters, includ-
	  ing including
        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 "subnet address pool"

        A subnet address pool is the set of IP address which is asso-
	  ciated associ-
        ated with a particular network number and subnet mask.  In the
        simple case, there is a single network number and subnet mask
        and a set of IP addresses.  In the more complex case (sometimes
        called "secondary subnets", sometimes "super-
	  scopes"), "superscopes"), several
        (apparently unrelated) network number and subnet mask combinations combina-
        tions with their associated IP addresses

DRAFT							    January 1998 may all be configured
        together into one subnet address pool.

      o "primary "Primary server" or "primary" "Primary"

DRAFT                                                      November 1998

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

      o "secondary "Secondary server" or	"secondary" "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.

1.3.  Requirements for this protocol

   The following list of goals must be (and are) achieved by this proto-
   col.

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

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

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

1.4.  Goals for this protocol

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

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

      3.  Minimize any need for manual administrative intervention.

DRAFT							    January 1998

      4.  Introduce no additional delays in server response time as a
          result of inter-server communication. the communications required to implement the Fail-
          over protocol.

DRAFT                                                      November 1998

      5.  Share IP address ranges between primary and secondary servers;
          i.e., impose no requirement that the pool of avail-
	   able available
          addresses be divided between servers.

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

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

      8.  Allow for one computer to act as a Secondary	Server secondary server for mul-
	   tiple Primary Servers. multi-
          ple primary servers. Other topologies (e.g.: mesh) are also
          possible.  Primary  primary and Secondary Servers secondary servers SHOULD be viewed as
          "logical" servers and not necessarily physical computers.

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

	10.Ensure

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

	11.If

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

1.5.  Limitations of this Protocol

   The following are explicit limitations of this protocol.

      1.  Under normal operation, only one server at a time will ser-
	   vice	DHCP hand
          out new IP addresses, but client requests; this lease renewals are serviced
          by both servers; the protocol provides reliability through
          redundancy but not and some degree of load balancing. balancing of lease
          renewals.

      2.  This protocol provides only one level of redundancy through a
          single Secondary Server secondary server for each Primary Server. primary server.

      3.  The protocol provides a way to detect when the primary and
          secondary server cannot communicate, but once this condition

DRAFT							    January 1998
          has been detected, does not (indeed, cannot) provide any way

DRAFT                                                      November 1998

          to further distinguish between network failure and failure of
          one of the servers. The protocol allows detection of an ord-
          erly shutdown of a participating server.

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

      5.  The Primary primary and Secondary Servers SHOULD pause normal DHCP
	   transaction processing while	resynchronizing, after a system
	   failure.

2.  Protocol Operations

   The protocol	necessary in providing redundant/failover secondary servers can be
   grouped in three areas:

	o Messages do not respond to keep the Secondary Server's lease	data synchron-
	  ized with that of the	Primary	so client
          requests at all while recovering from a failure that	when failover occurs,
	  there	is no degradation could
          have resulted in duplicate IP assignments.  (When synchroniz-
          ing in POTENTIAL-CONFLICT state).

2.  Protocol Operations

   The protocol features a small number of service.

	o Messages that	allow the Secondary messages to determine the communicate bind-
   ing information, operational
	  state	of the Primary,	so as status and to know when manage various
   disconnect-reconnect scenarios between servers.

2.1.  Message Addressing and Configuration granularity

   When discussing messages, an important question is "to whom are mes-
   sages sent" and "from whom are messages sent".  What is the address-
   able entity from which and to start servicing
	  DHCP traffic.

	o Messages that which messages are used sent?

   At one level, this would seem to coordinate the Primary regaining
	  control when it has become available again.

2.1.  Time synchronization between communicating servers

   Each	Binding	update message carries be a "sent time stamp" (the	time
   when	the message was	sent single DHCP server, but in	GMT). This provides fact
   there are many situations where additional flexibility in configura-
   tion is useful.  For instance, there might be several servers which
   are each primary for a simple mechanism
   to determine	any "time drift" between communicating servers.

   DISCUSSION:

      If an UDP	packet distinct set of address pools, and one server
   which is successfully transmitted (i.e.: it does not
      get lost), secondary for all of those address pools.  The situation
   with the packet travel time primaries is negligible in straightforward, but the framework

DRAFT							    January 1998

      of  DHCP leases.	By providing secondary will need to
   maintain a GMT "sent time" stamp, the reci-
      pient can	compare	this with its notion separate failover state, partner state, and communications
   up/down status for each of the current GMT	time at
      the time separate primary servers for which it receives the packet.	The difference (plus the packet
      travel time, which we ignore)
   is the time	drift. acting as a secondary.

   The recipient
      can use this time	drift value protocol allows for there to bias all	"absolute time"	values
      it receives from be a unique failover entity per
   partner per role (where role is primary or secondary).  This failover
   entity can take actions and hold unique states.  There are thus a

DRAFT                                                      November 1998

   maximum of two failover entities per partner (one for the sender.

2.2.  Failover Protocol	Messages

   The Failover	Protocol messages partner as
   a primary and one for that same partner as a secondary.)

   Thus, in the case where there are encoded using two primary servers A and B each
   backed up by a packet format
   specific to single common secondary server C, there is one fail-
   over entity on each of A and B, and two different failover entities
   on C.  The two different failover entities on C each have unique
   states and message xid ranges.  As far as the Failover Protocol. To allow easy  recognition protocol described in
   this draft is concerned, they constitute different "servers",
   although they are certainly part of
   Failover Protocol messages, BOOTP packet "op" field values  3..14 one server (as the term is com-
   monly used) if they reside in the same process.

   It is not the case that there is subnet granularity for each failover
   entity.  On one server, there is one failover entity per "partner-
   role", regardless of how many subnets or address pools are
   proposed to mark various Failover Protocol messages.	A Failover Pro-
   tocol managed by
   that combination of partner and role.  Conversely, any given subnet
   or pool will be associated with exactly one failover entity on a sin-
   gle server (but it will also be associated with the corresponding
   partner's failover entity.)

   When a message is always unicast received from the source to partner, the destination.
   The sender, and never unique failover
   entity to which the recipient message is responsible for reliable re-
   transmission. directed is determined solely by the
   IP address of the partner and the setting of the SECONDARY bit in the
   'flags' field of the message header.

   Throughout this document, the states and actions taken by "servers"
   are described.  The terms "server", "primary server", and "secondary
   server" are commonly used to described the entity taking these states
   and taking actions.  This description is wholly accurate only for the
   simplest of cases, where all of the address pools on one server are
   backed up by all of the address pools on another server.  In this
   case, there is a "true" primary and secondary server.  In all other
   cases, the term "server" is used to describe one of the two possible
   failover entities per partner.

2.2.  Packet transport

   All messages sent by this protocol are sent in UDP packets.  All mes-
   sages are unicast from the sender to the receiver.  The next section
   discusses the port to use when sending DHCP failover UDP packets.

   DISCUSSION:

      See section 8, Extended discussion #1, for a discussion of the
      reasons to use UDP as the protocol.

DRAFT                                                      November 1998

2.3.  Port usage

   Compliant servers SHOULD use port 647 (assigned to dhcp-failover by
   IANA) for sending and receiving Failover protocol messages, though
   they MAY be configured to use a different port (including ports 67 or
   68).

   Since the use of port 67 and 68 is allowed, the messages are format-
   ted in such a way that they can be distinguished from DHCP or BOOTP
   messages by the use of distinct message 'op' codes.  Note that send-
   ing failover messages on port 67 to servers not designed to support
   them may not only not work, but may cause those servers to operate
   incorrectly or to crash.

   DISCUSSION:

      Some implementors have a strong requirement for using a separate
      port for the Failover protocol, and the use of the allocated port
      647 will accommodate them.  Some other implementors seem equally
      committed to allowing failover packets to be sent to the standard
      DHCP port, port 67.  The above language strongly suggests that the
      failover port be used (by using SHOULD), but leaves open the pos-
      sibility of using the standard DHCP port (or any other) for
      servers designed to operate in that fashion.

2.4.  Time synchronization between communicating servers

   Each Binding update message carries a "sent time stamp" (the time
   when the message was sent in GMT). This provides a simple mechanism
   to determine any "time drift" between communicating servers.

   DISCUSSION:

      If a UDP packet is successfully transmitted (i.e.: it does not get
      lost), the packet travel time is negligible in the framework of
      DHCP leases.  By providing a GMT "sent time" stamp, the recipient
      can compare this with its notion of the current GMT time at the
      time it receives the packet.  The difference (plus the packet
      travel time, which we ignore) is the time drift.  The recipient
      MUST use this time drift value to bias "absolute time" values it
      receives from the sender.

2.5.  Failover Protocol Messages

   The Failover protocol messages are sent using UDP and encoded using a
   packet format specific to the Failover protocol. To allow easy
   recognition of and separation of Failover protocol messages from

DRAFT                                                      November 1998

   BOOTP and DHCP messages, BOOTP packet 'op' field values  3..11 are
   used to indicate various Failover protocol message types. A Failover
   protocol message is always unicast from the source to the destination
   using the port defined in section 2.2. The sender, and never the
   recipient is responsible for retransmission when necessary.

2.6.  Failover protocol packet header format

   All of the fields in the fixed portion of the packet 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     op (1)    |     rev (1)   |        payload offset (2)     |
   +---------------+---------------+---------------+---------------+
   |                            xid (4)                            |
   +---------------------------------------------------------------+
   |              sending server ID ( IP address ) (4)             |
   +---------------------------------------------------------------+
   |                          time stamp (4)                       |
   +---------------------------------------------------------------+
   |     state (1) |    flags(1)   |       reserved (2)            |
   +---------------+---------------+---------------+---------------+
   |     0 or more additional header bytes  (variable)             |
   +---------------------------------------------------------------+
   |     Payload Data, formatted as DHCP-style options             |
   |     (although using a unique option number space)             |
   |                     (variable)                                |
   +---------------------------------------------------------------+

DRAFT                                                      November 1998

   op - 1 byte

   These values extend the number space of the existing BOOTP message
   type "Op" field.

   The following message types are defined:

   Value   Message Type
   -----   ------------
   0       reserved to BOOTP/DHCP, unused by failover
   1       BOOTREQUEST (reserved to BOOTP/DHCP, unused by failover)
   2       BOOTREPLY   (reserved to BOOTP/DHCP, unused by failover)
   3       DHCPPOOLREQ         request allocation of addresses
   4       DHCPPOOLRESP        respond with allocation count
   5       DHCPBNDUPD          update partner with binding info
   6       DHCPBNDACK          acknowledge receipt of binding update
   7       DHCPPOLL            probe partner for comm. integrity
   8       DHCPPRPL            acknowledge comm. integrity
   9       DHCPUPDATEREQALL    request full transfer of binding info
   10      DHCPUPDATEDONE      ack send and ack of req'd binding info
   11      DHCPUPDATEREQ       req transfer of un-acked binding info

   rev - 1 byte

   Failover protocol version supported.  Set to 1 for the Failover
   protocol described in this draft.  The value 255 is reserved for
   experimental implementations.  Such implementations SHOULD use the
   DHCP Vendor Class option to recognize a partner server which is using
   the same vendor's experimental implementation.

   payload offset - 2 bytes, network byte order

   The byte offset of the Payload area, from the beginning of the
   Failover packet header. The value for the current protocol version is
   20.

   xid - 4 bytes, network byte order

   The sender of a Failover protocol packet is responsible for setting
   this number, and the receiver of the packet copies the number over
   into any response packet, treating it as opaque data.  The sender
   SHOULD ensure that every packet sent to a particular IP address and
   port combination has a unique transaction id unless that packet is a
   re-transmission.

DRAFT                                                      November 1998

   sending server ID - 4 bytes, network byte order

   The IP address of the sending server.  In conjunction with the
   setting of the SECONDARY flag, this uniquely determines the failover
   entity sending the message as well as that destined to receive the
   message.

   This is placed in the packet instead of being recovered from the IP
   header for security purposes (see section 8).

   time stamp - 4 bytes, unsigned, network byte order

   A time stamp, indicating the time when the packet was sent.  The time
   is a 32 bit unsigned long value in network byte order, in units of
   seconds (GMT since EPOCH).

   It is used to determine the time drift between the sender and the
   recipient. The time drift is defined as the difference between
   "Arrive Time (GMT)" and "(Send Time (GMT)".  The actual packet travel
   time is assumed to be negligible in this context. All Date-Time
   values contained in Failover Protocol	packet header format

   0		       1		   2		       3
   0 1 2 3 4 5 6 7 8 9 0 messages MUST be corrected by the time
   drift before being stored by the recipient.

   state - 1 2 3 4 5 6 7 8 9 byte

   This field indicates the state of the sender, at the time the packet
   was sent.  The field MUST be set in every Failover message.  The
   server state value can be one of the following:

   Value   Server State
   -----   -------------------------------------------------------------
   0       NO-STATE                     May only occur in POLL messages.
                                        The partner should reply, but
                                        should not react with any state
                                        transition.
   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 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |	 op (1)	   |	 rev (1)   |	    payload offset (2)	   |
   +---------------+---------------+---------------+---------------+
   |				xid (4)				   |
   +---------------------------------------------------------------+
   |	     0 or more additional header bytes	(variable)	   |
   +---------------------------------------------------------------+
   |	       Payload data, formatted as DHCP-style options	   |
   |	       (although using       RECOVER-DONE                 Interlock state prior to NORMAL

DRAFT                                                      November 1998

   Note 1: The STARTUP state is never set in the State field of the mes-
   sage, but rather is represented by the setting of the STARTUP flag
   (see the description of the Flags field immediately below).  When the
   server is in the STARTUP state, the state transmitted in the State
   byte is the PREVIOUS state (usually, but not always, the last
   recorded in stable storage prior to a unique	option number space)	   |
   |			       (variable)			   |
   +---------------------------------------------------------------+

   op server going down -- see sec-
   tion 6.3 for details.)

   flags - 1 byte

   These values	extend

   Currently, bits 7 (MSB), 6, and 5 are defined.  All other bits are
   reserved, and must be set to 0.

      o SECONDARY

        Bit 7 is the number space	of SECONDARY flag and defines the existing	BOOTP message
   type	"Op" field.  The following types are defined:

DRAFT							    January 1998

   3		   DHCPPOOLREQ
   4		   DHCPPOOLRESP
   5		   DHCPBNDUPD
   6		   DHCPBNDACK server role.  Bit 7		   DHCPPOLL
   8		   DHCPPRPL
   9		   DHCPCTLREQ
   10		   DHCPCTLRET
   11		   DHCPCTLACK
   12		   DHCPCTLACKACK
   13		   DHCPREQUEREQ
   14		   DHCPREQUERESP

   rev - 1 byte

   Failover protocol version supported.	Set to
        is 0 if the sender is a primary server, 1 if it is a secondary
        server.  Note that this role is fixed for the Failover Proto-
   col described in this draft.

   payload offset - 2 bytes, network byte order

   The byte offset duration of the Payload area,	from
        relationship between primary and secondary server.  In particu-
        lar, it does not change when and if the beginning secondary server "takes
        over" for the primary server when it enters COMMUNICATIONS-
        INTERRUPTED or PARTNER-DOWN state -- each server retains its
        role throughout all of its state transitions.

      o RESTART

        Bit 6 is the Fail-
   over	packet header. RESTART flag.  If bit 6 is 1, the sender is res-
        tarting.  A server MUST set this bit every time it is re-
        started, and it MUST clear the bit upon receiving the first
        DHCPPRPL to a DHCPPOLL message it has sent with the bit set.

        Whenever a DHCPPOLL message is sent with the RESTART bit set in
        the 'flags' field, the MCLT Option, Option 235, MUST be
        included.

        Whenever a message with the RESTART bit is received by a server,
        it MUST transition through the communications failed state tran-
        sition.  The value for RESTART bit signals that the partner server has
        been restarted, and if communications is already considered to
        have failed, then nothing need be done.  If, however, the
        partner server appeared to be operating correctly, then it was
        able to restart without the current protocol version is 8.

   xid - 4 bytes, network byte order receiving server noticing that it
        was ever gone.  The sender of a failover protocol packet communications failed transition is responsible for setting forced
        in this	number,	and case to restart any on-going resynchronization processes
        that were operating with the	receiver of partner server.  See section 6.3
        for additional information.

        Whenever a DHCPPOLL message is sent with the	packet copies RESTART bit set,

DRAFT                                                      November 1998

        the number over
   into	any response packet.  To server SHOULD include a Vendor Class Identifier, Option 60,
        in the receiver it message to identify the server to its partner.

      o STARTUP

        Bit 5 is opaque.  The sender
   SHOULD ensure that every packet sent the STARTUP flag.  Bit 5 MUST be set to a particular	IP address 1 whenever the
        server is in STARTUP state, and
   port	combination has	a unique transaction id	unless set to 0 otherwise.  (Note that packet
        when in STARTUP state, the state transmitted in the 'state'
        field is a
   re-transmission.

2.4. usually the last recorded state from stable storage,
        but see section 6.3 for details.)

   reserved - 2 bytes

   2 filler bytes, reserved.

2.7.  DHCPPOOLREQ and DHCPPOOLRESP:

   Whenever

   A secondary server requests addresses for its unique use from the	Secondary
   primary server transitions into NORMAL mode, it first
   sends a by using the DHCPPOOLREQ message	to initiate a transfer of a small range message.  The primary is in
   complete charge of IP how many addresses that the secondary receives.

   The primary server will serve as its private address pool.

   This	is necessary, because initially allocate IP addresses to the Secondary secondary server has no such
   address pool,
   upon receipt of a DHCPPOOLREQ message and its pool gets depleted when it hands out inform the secondary server
   of the number of additional addresses allocated in COMMUNICATION-INTERRUPTED	mode. This is why this allocation
   cycle by sending the request is sent
   every time number in the Secondary server transitions into NORMAL mode.  The
   DHCPPOOLREQ message does not	carry any payload data. DHCPPOOLRESP message.

   When the Primary
   Server primary server gets a DHCPPOOLREQ message, it computes which
   addresses should be transferred to the Secondary, secondary, and queues up
   DHCPBNDUPD transac-
   tions, transactions by setting the Status of	these bindings the selected
   addresses to "BACKUP".  Having done this, it sends a DHCPPOOLRESP
   message.  The DHCPPOOLRESP message

DRAFT							    January 1998 carries the "Number of addresses
   transferred" as its payload.  The Secondary primary server does not have to
   wait until all the above binding updates have been acknowledged,

   The secondary server keeps sending DHCPPOOLREQ messages until it
   receives a  DHCPPOOLRESP with "Number of addresses transferred" = 0,
   or it decides that the partner is not responding.  Each one of these
   message MUST	have the same transaction ID.

   If a new	transaction ID
   is used in one of these messages, the receiving secondary server will begin the
   transmission	of the DHCPBNDUPD messages all over again.  To be clear,
   if the Secondary Server receives a  DHCPPOOLRESP message with "Number
   of addresses transferred" > 0, it MUST send another DHCPPOOLREQ mes-
   sage.
   sage, since additional addresses may still be waiting for it.  How-
   ever, the time at which it sends subsequent DHCPPOOLREQ messages is
   implementation dependent.  This mechanism makes it possible for the Primary Server
   primary server to pace the transfer (e.g., it could generate all
   addresses all at once, or
   one-by-one). one-by-one) and to some degree for the
   secondary to pace their receipt.

DRAFT                                                      November 1998

   The Primary Server must primary server MUST respond to each DHCPPOOLREQ message it
   receives. If it has already generated all private addresses, or it
   has no available addresses, it MUST send  DHCPPOOLRESP with "Number
   of addresses transferred" = 0.

2.5.  DHCPREQUEREQ

   The secondary server MAY send a DHCPPOOLREQ message at any time, and
   although the primary server is under no obligation to allocate any
   additional addresses, it MUST respond with a DHCPPOOLRESP indicating
   how many new addresses it has allocated or 0 if no new addresses were
   allocated.

2.8.  DHCPUPDATEREQ, DHCPUPDATEREQALL and DHCPREQUERESP: DHCPUPDATEDONE:

   Whenever either server wishes to be updated with the information that the
   other server knows and but has not yet transmitted to it, transmitted, it will send a
   DHCPREQUEREQ.

   The DHCPREQUEREQ message does not carry any payload data.
   DHCPUPDATEREQ or DHCPUPDATEREQALL message.

   When the either server gets a	DHCPREQUEREQ DHCPUPDATEREQ or DHCPUPDATEREQALL message,
   it computes which updates should be transferred to the	Secondary, partner, and
   queues up DHCPBNDUPD transactions as appropriate.  Having done	this,  Once all such
   updates have been acknowledged, it sends a DHCPRE-
   QUERESP DHCPUPDATEDONE message. The	DHCPREQUESP

   If the message carries that initiated this process was a DHCPUPDATEREQ mes-
   sage, the	"Number	of receiving server will transmit only DHCPBNDUPD messages for
   IP addresses queued up"	as which its payload.	The set	of binding updates
   queued up will depend on information indicates that its partner has not
   acked.

   If, however, the message that initiated this process was a DHCPUP-
   DATEREQALL message, the	requesting server's state. (The	state
   has already been communicated via prior DHCPPOLL/DHCPPRPL messages)

   The Secondary receiving server	keeps sending DHCPPREQUEREQ will transmit DHCPBNDUPD
   messages for all IP addresses involved in failover with this partner
   in this role.

   The secondary server periodically re-transmits the DHCPUPDATEREQ mes-
   sage, until it receives a  DHCPREQUERESP DHCPUPDATEDONE message with "Number of addresses queued up" = 0, a matching
   'xid' field, or until it decides that the partner is not responding.

   This approach is similar to the same
   approach DHCPPOOLREQ/DHCPPOOLRESP message
   exchange, with one critical difference: the DHCPPOOLRESP is sent as
   soon as	in the DHCPPOOLREQ/DHCPPOOLRESP	messages binding updates are queued up, but the DHCPUPDATEDONE
   message is used.  Each
   one deferred until all of  these DHCPREQUEREQ the sender's DHCPBNDUPD messages
   have been successfully transmitted and a corresponding DHCPBNDACK
   message has been received for each of them.

   The server processing a DHCPUPDATEREQ message MUST NOT send a
   corresponding DHCPUPDATEDONE message until all of the DHCPBNDUPD mes-
   sages have been acked by the partner with a DHCPBNDACK message.

DRAFT                                                      November 1998

   Any retransmissions of the DHCPUPDATEREQ message MUST have the same
   transaction ID.  Use of a new transaction ID will may cause re-building rebuilding of
   the outgoing binding update queue.

   The Primary Server must respond to each DHCPREQUEREQ queue or other processing in the server
   with a negative effect on performance.

2.9.  DHCPBNDUPD

   One server notifies its partner of a binding state change by using
   the DHCPBNDUPD message.

   Every DHCPBNDUPD message MUST contain:

      o An Assigned IP Address Option (Option 50).

      o A DHCP Binding Status (Option X).

      o Where the Binding Status is ACTIVE, EXPIRED, RELEASED, or RESET,
        it
   receives. If	it has already queued up all MUST also contain one or both of the previously unsent
   bindings update, then Client Identifier
        (Option 61) and the Client Hardware Address (Option X+3). In the
        case where the Binding Status is ACTIVE, it MUST send  DHCPREQUERESP with "Number of
   addresses queued up"	= 0.

DRAFT							    January 1998

2.6.  DHCPBNDUPD

   The Primary notifies	Secondary (or contain the
        Lease Duration, Option 51.

      o Where dynamic DNS updates are being used by the sending server,
        the other	way around) Client FQDN Option, Option 81, is used by the sender to
        communication the status of a the binding
   state and data change. update to its partner.
   In response to a binding update, the recipient server MUST respond
   with a  DHCPBNDACK message.

   Multiple binding updates can MAY be batched up, and sent in one Failover	Protocol message.

2.7.
   protocol message (see section 3.1).

2.10.  DHCPBNDACK

   This message implements either a positive, positive or negative acknowledgement acknowledgment
   of one or more binding updates.

   A binding update, (or a batch of binding updates sent as one message)
   are matched up with their associated acknowledgment by having the
   same	Xid 'xid' field value in the message header.

   The server sending a DHCPBNDACK message MAY include any of the
   options that are acceptable in a DHCPBNDUPD message when the
   DHCPBNDACK message is returned to the sender.  It MUST include at
   least the Assigned IP Address Option.

   If any of this informa-
   tion information differs from the information in the
   DHCPBNDUPD message, the receiver SHOULD MUST NOT update its bindings

DRAFT                                                      November 1998

   database with that information upon receipt of the DHCPBNDACK mes-
   sage, since the sender will have no way of knowing if the receiver
   actually received the message.

   The DHCPBNDACK MAY selectively reject one or more updates updates, by includ-
   ing one or more IP address - Reject Reason option pairs in the mes-
   sage body.

   The DHCPBNDACK implicitly acknowledges any binding updates it replies
   to, except those it enumerates using Reject Reason Codes.

2.8.  DHCPPOLL

   In order to determine the state of a	given server, or to communicate
   a critical change in	its own	status,	a participant can use the above
   message.

   This	message	inquires about the current state

   Implementations of the	recipient, this protocol MAY send batched updates, and
   tells the recipient what state the sender is.

   In response to the DHCPPOLL message,	the participant	will listen for
   a DHCPPRPL message.

DRAFT							    January 1998

2.9.  DHCPPRPL

   This	message	replies they
   MUST be prepared to the receive batched updates.

2.11.  DHCPPOLL	message	(PRPL=Poll reply). The
   DHCPPRPL also carries server	status information (see	message	payload
   details below).

   After a failover, when the Primary Server is	restarted, the following
   messages are	used to	coordinate the Primary taking control back from
   the Secondary:

   DHCPCTLREQ	  - Request for	control
   DHCPCTLRET	  - Return of control initiated
   DHCPCTLACK	  - Return of control completed
   DHCPCTLACKACK  - Return of control completed	message	acknowledged.

   The Primary Server sends a DHCPCTLREQ message, indicating that it
   would like to take control of the bindings database.	 The Secondary
   Server replies with a DHCPCTLRET message, which serves as a signal to

   In the Primary "Stand by to receive binding updates".  This message then
   is followed by a set absence of binding updates from	the secondary to the
   primary.  When all updates have been	transmitted (and acknowledged)
   from	Secondary to Primary, other messages, a DHCPCTLACK DHCPPOLL message is sent from the
   Secondary to	the Primary, used to	signal that "all updates from the Secon-
   dary	are now	completed".

   DISCUSSION:

      Note, that the DHCPCTLACK	message	type must be transmitted reli-
      ably, as
   verify the Primary Server will not start servicing clients,
      until it has received communications integrity of the	DHCPCTLACK message.  To	provide	this
      reliability, link between the DCHPCTLACKACK message primary
   and secondary servers.  It is	provided. This provides
      an acknowledgment used by either server whenever there is
   some question about either the communications integrity or running
   status of the DHCPCTLACK message, other server.

   Since current state and the DHCPCTLACK
      message will be periodically re-sent until it other status information is acknowledged.  We
      could  just periodically re- send	the DHCPCTLACK message until we
      start receiving binding updates from the Primary,	but transmitted in
   every DHCPPOLL and in every DHCPPRPL message, the	Primary
      may not have any updates DHCPPOLL and
   DHCPPRPL exchange can also be used to send at all, hence the need for an
      explicit DCHPCTLACKACK   message.

   The Primary Server transitions into NORMAL state upon receiving signal a
   DHCPCTLACK from the secondary, when change in status by a
   server or as a way to request an update of the secondary has completed send-
   ing all status of its updates during synchronization. The  DHCPCTLACKACK partner.

   Whenever a DHCPPOLL message is needed to	prevent	the primary from waiting and not servic-
   ing clients if the DHCPCTLACK message got lost.  The	Secondary server
   will	keep re-sending	the DHCPCTLACK message,	until:

	1. It Decides that generated it MUST have a unique value
   in the primary 'xid' field, unless it is not responding, so the Secon-
	   dary	server goes into COMMUNICATION-	INTERRUPTED mode.

DRAFT							    January 1998

	2. It receives a DHCPCTLACKACK or retransmission of a DHCPBNDUPD previously
   un-acked DHCPPOLL message.

2.12.  DHCPPRPL

   This message from simply replies to the
	   primary.  The Primary's DHCPBNDUPD messages would start
	   arriving at DHCPPOLL message (PRPL = Poll
   reply).  Like all messages, it needs to have all of the Secondary server, if fixed
   portions of the Primary did	get failover packet header filled in, including the
	   DHCPCTLACK, but state
   and the DHCPCTLACKACK message got lost. flags fields.

3.  Protocol Payload Data Format

   Payload data is encoded as a set of flexible DHCP/BOOTP style
   options. options
   [RFC 2132].  (The usual 1 byte option code, 1 byte length, and
   "length" bytes of data).  The options are placed after the header,
   after skip-
   ping skipping PayloadOffset bytes.  The payload data options are not
   preceded by a "cookie" value.

DRAFT                                                      November 1998

   Since the packet is NOT a DHCP/BOOTP protocol packet, the options
   used here do not conflict with any existing "proper" DHCP/BOOTP
   options.  In fact, these options are allocated in relationship to the
   DHCP option space in the following way.

   In cases where the syntax and semantics of a Failover Payload Option
   is identical to that of a DHCP/BOOTP option, the same number option number
   is used.  For options unique to the Failover protocol, options option numbers
   starting at 230 are used.

   Thus, all new Failover Protocol protocol option numbers are assigned from a
   continuous range beginning with 230.	 This number is	shown as an X in
   the tables below.

   The protocol is permissive in allowing various other DHCP options in
   binding updates.  As long as the sender wishes to use an option, it
   MAY include it.  On the other hand, the recipient MUST ignore any
   option it is not expecting. prepared to process.

3.1.  Batching multiple binding updates in one packet

   Implementations of this protocol MAY send batched updates, and they
   MUST be prepared to receive batched updates.

   Multiple DHCPBNDUPD transactions can MAY be batched together in one UDP
   packet. Option
   protocol message.  Data sets for individual transaction transactions MUST always
   begin with the Assigned IP address Address (Option	50) . This is the only restriction on
   payload item	ordering. In any other case, payload data items	can be
   included in any desired order.

   In case an implementation chooses to	use the	DHCPBNDNAK mechanism,
   the DHCPBNDNAK message SHOULD contain one or	more 50).  Option 50s	from the
   NAK-ed message, to indicate which specific update items are being
   NAK-ed.

   While ordering
   between the synchronization Assigned IP Address options is	in progress, the secondary MUST	NOT
   accept client requests, and the primary MUST	NOT send any not significant.

   If batched updates to
   the secondary. This is necessary to allow the Primary to are sent, they MUST be the sole
   arbitrator of any conflicting updates.

DRAFT							    January 1998

3.1.  DHCP Server Status

   This	option is used to convey the current state of a	server.

    Code  Len  Type
   +--+---+------+
   | X|	1 | 1-15 |
   +--+---+------+

   Allowed values for this option:

   Value Message Type
   ----- ------------
   1	 UNKNOWN-STATE
   2	 PRIMARY-NORMAL		   Normal state
   3	 BACKUP-NORMAL
   4	 PRIMARY-COMINT		   Communication interrupted (safe)
   5	 BACKUP-COMINT
   6	 PRIMARY-PARTNERDOWN	   Partner down	(unsafe
				   mode)
   7	 BACKUP-PARTNERDOWN
   8	 PRIMARY-CONFLICT	   Synchronizing, after	a
				   "Partner-Down"
				   divergence
   9	 PRIMARY-SYNC		   Synchronizing, after	a
				   "communications-
				   interrupted"
				   divergence.
   10	 BACKUP-SYNC
   11	 PRIMARY-RECOVER	   Recovering ALL
				   bindings from partner
   12	 BACKUP-RECOVER
   13	 FAILOVER-DISABLED	   The server is running
				   with	the failover
				   protocol disabled.
				   (standalone)

   14	 SERVER-PAUSED		    The	server is inactive,
				   shutting down for a sort period.
   15	 SERVER-SHUTDOWN	    The	server is inactive,
				   shutting down formatted as follows:

       Non-IP Address/Non-client specific options first
       Assigned IP address option (50) for the first address
           Options pertaining to first address, including
           at least DHCP Binding Status (230)
       Assigned IP address option (50) for the second address
           Options pertaining to second address, including
           at least DHCP Binding Status (230)
        ...

   In case an	extended period.

   When implementation chooses to reject some or all of the IP
   address binding information in a server is being re-started, it should	send DHCPBNDUPD message in a DHCPPOLL DHCPBNDACK
   reply, the DHCPBNDACK message MUST contain one or more Assigned IP
   Address (Option 50) / Reject Reason Code pairs to its partner, reporting its status	(SERVER-PAUSED).  In response, indicate that the recipient SHOULD	go into	COMMUNICATION-INTERRUPTED mode.
   updates for the address(es) were not accepted.  The Assigned IP
   Address options communicates which updates out of the batch are being
   rejected, and the Reject Reason Code indicates why.  Any IP addresses

DRAFT							    January                                                      November 1998

   When	a server is being shut down,  it should	send a DHCPPOLL

   present in the DHCPBNDUPD message
   to its partner, reporting its status	(SERVER-SHUTDOWN).

   In response, without corresponding Option 50/
   Reject Reason Code pairs in the recipient SHOULD go	into PARTNER-DOWN mode. DHCPBNDACK message are implicitly
   acked by the DHCPBNDACK message.  If the DHCPBNDUPD message only con-
   tains one binding update and that update is rejected, a DHCPBNDACK
   with a single Assigned IP Address / Reject Reason Code pair MUST be
   sent.

3.2.  DHCP Binding Status

   This option is used to convey the current state of a binding. This
   option is mandatory for DHCPBNDUPD messages.

   Code     Len  Type
   +-----+-----+-----+
   | X+1 230 |  1  | 1-7 |
   +-----+-----+-----+
   Legal values for this option are:

   Value   Message Type Binding Status
   -----   ------------ ------------------------------------------------
   1     FREE		  The lease       Lease has never been used
   2     ACTIVE     Lease is assigned to a client *
   3     EXPIRED    Lease has expired
   4     RELEASED	  A client   Lease has been released the	lease by client
   5     ABANDONED  A server server, or client flagged address as not usable. unusable
   6     RESET      Lease was freed by some external agent. agent
   7     BACKUP     Lease	is set aside for Secondary
			  server's belongs to secondary's private address pool. pool

3.3.  Assigned IP address

   Uses identical code and format to DHCP Option 50 (requested IP
   address).  This option is mandatory for DHCPBNDUPD messages and in
   any DHCPBNDACK message where a Reject Reason Code option appears.

   Code   Len          Address
   +-----+-----+-----+-----+-----+-----+
   |  50 |  4  |  a1 |  a2 |  a3 |  a4 |
   +-----+-----+-----+-----+-----+-----+

DRAFT							    January                                                      November 1998

3.4.  Lease  Absolute time

   This absolute time is used for the lease grant time as well the
   partner-down time.    When used in a DHCPBNDUPD or DHCPBNDACK
   message, it represents the lease grant time time.  When used in a DHCPPOLL
   message, it represents the partner-down time.

   An absolute, GMT time value for this option, as time synchronization
   has already been achieved between the source and the target server
   using the Sent Time Stamp option. time field in the message.  Represented as seconds elapsed
   since Jan 1, 1970 (i.e. ANSI C time_t time value representation).
   Note that this is (at present) a signed field.

   Code   Len           Time
   +------+-----+-----+-----+-----+-----+
   | X+2 231  |  4  |  t1 |  t2 |  t3 |  t4 |
   +------+-----+-----+-----+-----+-----+

3.5.  Sent Time	Stamp

   A time stamp	using GMT, when	the packet was sent. It	is used	to
   determine the time drift between the	sender and the recipient. The
   time	drift is defined as the	difference between "Arrive Time	(GMT)"
   and (Send Time (GMT)" .  The	actual packet travel time is assumed to
   be negligible in this context. All Date-Time	values contained  in
   Failover messages will be corrected by the time drift before	being
   stored by the recipient.

   Code	  Len		Time
   +-----+-----+-----+-----+-----+-----+
   | X+3 |  4  |  t1 |	t2 |  t3 |  t4 |
   +-----+-----+-----+-----+-----+-----+

   The time is a 32 bit	unsigned long in network byte order, in	units of
   seconds (GMT	since EPOCH).

3.6.  Number of addresses transferred to Secondary Server

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

DRAFT							    January 1998

   Code   Len		Time     Number of Addresses
   +-----+-----+-----+-----+-----+-----+
   | X+4 232 |  4  |  t1  n1 |	t2  n2 |  t3  n3 |  t4  n4 |
   +-----+-----+-----+-----+-----+-----+

3.7.

3.6.  Lease Duration

   Uses the format and code of the standard DHCP IP Address Lease Time
   option. It is used by the DHCP protocol in the exact	same way by the
   DHCPOFFER message.
   option (51).  The time is in units of seconds, and is specified as a
   32-bit  unsigned integer. A Lease Duration of 0xFFFFFFFF indi-
   cates indicates an
   infinite lease.

   Code   Len         Lease Time
   +-----+-----+-----+-----+-----+-----+
   |  51 |  4  |  t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+-----+-----+

3.8.

DRAFT                                                      November 1998

3.7.  Client Identifier

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

   Code   Len   Type  Client-Identifier
   +-----+-----+-----+-----+-----+---
   |  61 |  n  |  t1 |  i1 |  i2 | ...
   +-----+-----+-----+-----+-----+---

3.9.

3.8.  Client Hardware Address

   The format is similar to DHCP option 61. T1 (type) MUST be set to the
   proper ARP hardware address code ( it code, as defined in the ARP section of
   RFC 1700 (it MUST NOT be zero!)  TBD: Refer-
   ence	the ARP	document here.

DRAFT							    January 1998

   Code   Len   Type  Client-Identifier   MAC address
   +-----+-----+-----+-----+-----+---
   | X+5 233 |  n  |  t1 |	i1  m1 |  i2  m2 | ...
   +-----+-----+-----+-----+-----+---

   Either Client Id, Client Hardware Address or BOTH MAY be present in
   binding update transactions. At least one of them MUST be present.
   If both are present, the Client Id MUST be used to uniquely identify
   the owner of the binding (exactly as in RFC 2131).

3.10.

3.9.  Host Name

   Uses the format and code of DHCP option 12.

   Code   Len                 Host Name
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  12 |  n  |  h1 |  h2 |  h3 |  h4 |  h5 |  h6 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

3.11.

3.10.  Domain Name

   Uses the format and code of DHCP option 15.

   Code   Len   Domain Name
   +-----+-----+-----+-----+-----+-----+--
   |  15 |  n  |  d1 |  d2 |  d3 |  d4 |  ...
   +-----+-----+-----+-----+-----+-----+--

DRAFT                                                      November 1998

3.11.  Client FQDN

   If an implementation supports Dynamic DNS updates, this option can be
   used to communicate the DNS name that was set. Uses the format and
   code of the Client FQDN option (81) as described in <draft-ietf-dhc-
   dhcp-dns-08.txt>.

   Code   Len   Flags Rcode1 Rcode2 Domain Name
   +-----+-----+-----+------+------+-----+------
   |  81 |  n  |  f  |  r1  |  r2  |  d1 | d2...
   +-----+-----+-----+------+------+-----+------

3.12.  Reject Reason Code

   This option is used to selectively reject binding updates. It MAY be
   used in DHCPBNDACK message, always following an option 50.(The option 50.  Option 50
   contains the IP address of the specific update being rejected).

DRAFT							    January 1998 rejected.

   Note that a Message option, DHCP Option 56, may be included to give a
   human readable error indication along with the Reject Reason Code.

   Code   Len   Reason code
   +-----+-----+-----+
   +-----+-----+----------+
   | X+6 234 |  1  |    R1    |
   +-----+-----+-----+-
   +-----+-----+----------+

   Reason codes :

   0   Reserved
   1   Illegal IP address (not part of any address pool)
   2   Fatal conflict exists: address in use by other client.

3.13.  MDLI

   Maximum Delta Lease Interval, in seconds.  A	32  bit	integer	value,
   in netwotk byte order.

   Code	  Len		Time
   +------+-----+-----+-----+-----+-----+
   | X+7  |  4	|  t1 |	 t2 |  t3 |  t4	|
   +------+-----+-----+-----+-----+-----+

4.  Exchange of	control	between	Primary	and Secondary

   The Primary and Secondary Servers coordinate	the exchange control
   over	the bindings database through the use of DHCPPOLL and DHCPCTLREQ
   messages.  In normal	operation:

   The Primary sends notification of each change to its	bindings data-
   base	to the Secondary, and the Secondary keeps its bindings database
   synchronized	with the Primary's database.

   The Secondary periodically sends DHCPPOLL messages to the Primary,
   and the Primary responds to each DHCPPOLL message with a DHCPPRPL
   message. If the Secondary
   3 - 253 Reserved for new Reason Codes.
   254 Unknown: Error occurred but does not receive a	DHCPPRPL response mes-
   sage, the Secondary takes control of	the bindings database and begins
   answering requests from DHCP	clients.  Note that the	Secondary should
   be able to be configured to not perform the automatic switch-over.

   The conditions under	which a	Secondary takes	control	of the bindings
   database, e.g., the number of consecutive missing acknowledgments,
   should be configurable in the Secondary by the DHCP administrator. match any reason code
   255 Reserved for code expansion

DRAFT							    January                                                      November 1998

   The Secondary records any changes it	makes to the bindings database
   while it has	control. The Secondary continues to send DHCPPOLL mes-
   sages to the	Primary.  The DHCPPOLL messages	also carry information
   on the state	of the Secondary Server.

   To regain control of	the bindings database, e.g., after the Primary
   Server has recovered	from a failure,	or

3.13.  Message

   This option is used to supply a partitioned network condi-
   tion, human readable message.  It may be
   used in association with the Primary sends Reject Reason Code to provide a DHCPCTLREQ human
   readable error message	to for the Secondary.  The
   Secondary stops answering DHCP client requests, reject.

   Code   Len      Text
   +-----+-----+------+-----+--
   | 56  |  1  |  c1  | c2  | ...
   +-----+-----+------+-----+--

3.14.  MCLT - Maximum Client Lead Time

   Maximum Client Lead Time, in seconds.  A 32 bit integer value, in
   network byte order. This option MUST be used in DHCPPOLL and responds	to its
   Primary with	a DHCPCTLRET message.  After sending DHCPPRPL
   messages, when the DHCPCTLRET mes-
   sage, server is NOT in normal state.

   Code   Len           Time
   +------+-----+-----+-----+-----+-----+
   | 235  |  4  |  t1 |  t2 |  t3 |  t4 |
   +------+-----+-----+-----+-----+-----+

3.15.  Vendor Class Identifier

   A string which identifies the Secondary sends DHCPBNDUPD	messages for each vendor of the changes
   it has made to the bindings database. failover protocol
   implementation.

   The Primary sends a DHCPBNDACK code for each DHCPBNDUPD message it
   receives.  The Secondary completes the transfer of control by sending
   a DHCPCTLACK	message	to the Primary as soon as all of this option is 60, and its updates
   were	acknowledged.

   Note, that the Primary SHOULD NOT send any DHCPBNDUPD messages while
   synchronization minimum length is in progress with 1.

   Code    Len    Vendor Class Identifier
   +-----+-----+-----+-----+-----+--
   | 60  |  n  |  i1 |  i2 |  i3 | ...
   +-----+-----+-----+-----+-----+--

4.  Challenging scenarios for a Failover protocol

   There exist a number of failure scenarios which will challenge the Secondary.

   Once
   correctness guarantees of the synchronization is completed, and Failover protocol.  Two of the Primary transitions
   into	NORMAL state, and starts sending DHCPBNDUPD transactions on any
   accumulated binding changes it may have.

5.  Duplicate address assignment
   scenarios

   In the following two	scenarios, that the Failover protocol	could end up allocating
   duplicate IP	addresses, unless was specifically designed to
   handle correctly are detailed in this section in order to motivate
   some of the measures recommended in Section 6.
   are taken: more unusual aspects of the protocol's operations.

DRAFT                                                      November 1998

4.1.  Primary Server crash before "lazy" update:

   In the case where the Pri-
   mary	Server primary server sends an	ACK a DHCPACK to a client for
   a newly allocated IP address and then crashes prior to sending the
   corresponding update to the
   Secondary Server, secondary server, the Secondary Server secondary server
   will have no record of the IP address allocation.  When the Secondary Server 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 secondary server from allocating that IP address to different
   client.

   This is handled in the protocol by having the primary and secondary
   allocate addresses for new clients from distinct address pools.

   A more likely (in that DHCPRENEWs are presumably more common than
   DHCPDISCOVERs) and more subtle version of this problem is where the Primary
   Server
   primary server crashes after extending a client's lease time, and
   before updating the	Secondary secondary with a new time using a lazy update.
   After the
   Secondary secondary takes over, if the client is not connected to the
   network the Secondary 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

DRAFT							    January 1998 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 the next section for details.

4.2.  Network partition where 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 primary and Secondary
   Servers secondary servers cannot
   communicate.  As well, some of the DHCP clients must be able to
   communicate with the Primary Server, primary server, and some of the clients must now
   only be able to communicate with the Secondary
   Server. secondary server.  When this
   condition occurs, both Primary primary and Secondary
   Servers 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
   allocated the same IP address. This will cause potentially serious
   problems when the network failure that created this situation is
   corrected.

   The next section details how

   This is handled in the Failover Protocol prevents either of protocol by having the above scenarios (and other related scenarios) primary and secondary
   servers allocate addresses for new clients from causing dupli-
   cate	IP distinct address allocation.

6.

DRAFT                                                      November 1998

   pools.

   The specifics of how these two scenarios are handled are supplied in
   the next section.

5.  Duplicate Address Assignment Control

   There are several ways that the Failover protocol avoids the possi-
   bility of duplicate address assignment.

6.1.

5.1.  Control of lease time

   The key problem with lazy update is that when the primary a server fails
   after updating a client with a particular lease time and before
   updating its partner, the	secondary server, the secondary	server 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- "Max-
   imum	delta lease interval" (MDLI) 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 the
   secondary server. that server's partner.  In order that this is not the maximum
   lease time that	the primary a server can ever provide to a client, during a lazy
   update the primary updating server typically updates the secondary its partner with lease
   time informa-
   tion information which is longer than the lease time previously given
   to the client.

   In the case where the secondary needs  This allows that server to give a longer lease time
   to take over from the primary, client the next time the secondary will not reallocate any IP addresses from one client to
   a different clients. renews its lease.

   When transitioning moving to the PARTNER-DOWN state (where the secondary a server is allowed to
   reallocate the partner's IP addresses),	the

DRAFT							    January 1998

   secondary a server will wait the maximum-delta-lease-interval	before complet-
   ing the state transition. Max-
   imum Client Lead Time before allocating any IP addresses from its
   partner's pool to any new DHCP clients.  Thus, any clients which have
   a lease on an IP address with a lease time greater	that than that known by
   the secondary server moving into PARTNER-DOWN state will either have contacted the secondary during
   that	time or server during the MCLT period or their lease leases will have expired.

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

   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

DRAFT                                                      November 1998

   than the lease expiration time known to a server's partner.

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

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

   The different lease times are:

      o desired client lease interval

        The desired client lease interval is the lease interval that
	  the a
        DHCP server would like to give to	the a DHCP client in the absence
        of any restrictions imposed by the Failover Protocol. protocol.  Its
        determination is outside of the scope of this protocol.
	  Typically Typi-
        cally this is the result of external configuration of a DHCP
        server.

      o actual client lease interval

        The actual client lease internal is the lease interval that
	  that a
        DHCP server gives out to	the a DHCP client.  It may be shorter than
        the desired client lease interval (as explained below).

      o Primary Server lease interval

	  The Primary Server lease interval is the interval after which
	  the Primary Server believes that DHCP	client's lease will
	  expire.

	o desired Secondary Server partner server lease interval

        The desired Secondary	Server partner server lease interval is the lease expira-
        tion interval the Primary Server local server tells to the Secondary Server after which
	  the lease will expire. its partner.

      o acknowledged Secondary Server partner server lease interval

        The acknowledged Secondary Server partner server lease interval is the inter-
	  val interval
        the Secondary Server partner server has most recently acknowledged.

   The key restriction (and guarantee) that the Primary Server any server makes with
   respect to lease intervals is that the actual client

DRAFT							    January 1998 lease interval
   never exceeds the acknowledged	Secondary Server partner server lease interval (if any)
   by more than a fixed amount.  This fixed amount is called the "maximum delta lease interval"
	  (MDLI). "Max-
   imum Client Lead Time" (MCLT).

   The MDLI MCLT MAY be configurable, but for correct server operation it
   MUST be the same and known to both the Primary primary and secondary servers.

   It is transmitted from the primary to the secondary in every message

DRAFT                                                      November 1998

   sent with the RESTART bit set, and Secondary Servers. also in every poll and poll reply
   message.  The Primary Server secondary MUST ensure that its value agrees with that
   of the primary.  See section 3.14 concerning the MCLT Option.

   A server MUST record in its state stable storage both the	Primary	Server local server
   lease interval and the most recently acknowledged Secondary Server partner server
   lease interval. 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.

   The above lease time	descriptions are written for the case where the
   where the Primary server is operating and in	communication with the
   Secondary server.  In the case where	the Secondary server is	operat-
   ing out of communications with the Primary server, then the relation-
   ships must hold in

   Again, the other	direction.

   The fundamental relationship among these times which MUST be	main-
   tained
   maintained is:

       actual client lease interval <
       ( acknowledged other server partner lease interval + MDLI MCLT )

   The "acknowledged other server partner lease interval" is the acknowledged
   secondary secon-
   dary server lease interval for the Primary primary server, and it would be
   the acknowledged primary server lease interval for the Secondary secondary
   server when it is operating out of contact with the Primary primary server.

   Figure 5.1-1 illustrates a initial lease to a client using the rules
   discussed in the example which follows it.

DRAFT                                                      November 1998

          DHCP                 Primary             Secondary
          Client               Server               Server

            |                     |                    |
            | >-DHCPDISCOVER->    |                    |
            |     <---DHCPOFFER-< |                    |
            |                     |                    |
            | >-DHCPREQUEST->     |                    |
            |   (selecting)       |                    |
            |                     |                    |
            |  <--------DHCPACK-< |                    |
            |      ^    (MCLT)    |                    |
            |      :              | >-DHCPBNDUPD-->    |
            |      :              |  (1/2 MCLT + X )   |
            |      :              |                    |
            |      :              |     <-DHCPBNDACK-< |
            |   MCLT / 2          |                    |
           ...     :             ...                  ...
            |      :              |                    |
            |      V              |                    |
            | >-DHCPREQUEST->     |                    |
            |      (renew)        |                    |
            |                     |                    |
            |  <--------DHCPACK-< |                    |
            |      ^    (X)       |                    |
            |      :              | >-DHCPBNDUPD-->    |
            |      :              |   ( 1/2 X + X )    |
            |      :              |                    |
            |      :              |     <-DHCPBNDACK-< |
            |    X / 2            |                    |
            |      :              |                    |
           ...    ...            ...                  ...

           Figure 5.1-1:  Lazy Update Message Traffic
                          X = Desired Client Lease Interval

   DISCUSSION:

      This protocol mandates no	particular detailed algorithms concern-
      ing mandates no algorithm concerning these lease intervals, inter-
      vals, as long as above fundamental relation-
      ship relationship is preserved.

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

DRAFT                                                      November 1998

      The rules for this example are:

      o What to tell the client:

        Take the remainder of the acknowledged partner server 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
        client lease interval, give the client the desired client 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), and add to it the desired client lease inter-
        val.

      In operation this might work as fol-
      lows: follows:

      When a Primary Server primary server makes an offer for a new lease on an IP
      address to a DHCP client, it determines the desired client lease
      interval (in this case, 3 days).  It then examines the ack-
      nowledged	Secondary partner lease interval (which in this case is	 zero).

DRAFT							    January 1998

      Since the	actual client lease interval can not be	allowed	to
      exceed the current Secondary lease interval by more than the MDLI,
      the offer	made to	the DHCP client	(the actual client lease inter-
      val) is for (essentially)	the MDLI, 1 hour.

      Once the Primary Server has performed the	ACK to the DHCP	client,
      it will update the Secondary Server with the lease information.
      However, the Secondary Server lease interval will	be composed of
      the current actual client	lease interval + ( 1.5 * desired client
      lease interval). Thus, zero) and
      determines the Secondary Server is updated with a
      lease interval remainder of	4.5 days + 1 hour.

      When the Primary Server receives an ACK time left to its update of the
      Secondary	Server's lease interval, run, which is also
      zero.  To this it records that as the	ack-
      nowledged	Secondary Server lease interval.  The Primary Server
      MUST ensure that adds the Secondary Server has	received and recorded in
      its stable storage the Secondary Server lease interval.

      When MCLT.  Since the DHCP actual client attempts
      lease interval cannot be allowed to renew at	T2 (approximately one
      half an hour from exceed the start remainder of the lease),
      current partner lease interval plus the Primary Server
      again determines MCLT, the offer made to
      the desired client lease	time, which is still 3
      days.  It	then compares this with for the remaining acknowledged
      Secondary	Server remainder of the current partner lease
      interval (adjusting for the time passed
      since (i.e., zero) plus the	Secondary Server was last updated), which is 4.5 days +
      to MCLT.  Thus, the desired actual client
      lease interval as it is less than the ack-
      nowledged	Secondary lease	interval.

      When 1 hour.

      Once the Primary DHCP primary server updates has performed the Secondary DHCP server
      after ACK to the DHCP client's renewal ACK is complete, client,
      it will calculate update the Secondary Server secondary server with the lease information.
      However, the desired partner server lease interval as will be com-
      posed of the one half of the current actual client lease interval (3 days this time) + .5
      added to the desired client lease	interval
      (1.5 days).  In this way, interval. Thus, the Primary attempts to	have secondary
      server is updated with a DHCPBNDUPD with a lease interval of 3
      days + 1/2 hour specified in the Secon-
      dary always "lead" Lease Duration Option (Option
      51).

      When the client in primary server receives an ACK to its understanding update of the	client's
      secondary server's (partner's) lease interval.

      Once interval, it records that as
      the initial actual client acknowledged partner server lease interval of the MDLI interval.  A server MUST NOT
      send a DHCPBNDACK in response to a DHCPBNDUPD message until it is past,
      sure that the protocol operates effectively	like information in the DHCP protocol does
      today DHCPBNDUPD message resides in its behavior concerning lease intervals.	However,
      stable storage.  Thus, the
      guarantee primary server in this case can be sure
      that the actual	client lease interval will never exceed secondary server has recorded the acknowledged Secondary Server desired partner server
      lease interval by more than the
      MDLI allows full recovery	from failures in lazy update.

6.2.  Controlled re-allocation of IP addresses

   When its stable storage when the servers cannot communicate neither primary server will allow an IP
   address previously used by one client to be offered to a different
   client.  As
      receives a corollary, during normal operations DHCPBNDACK message from the primary server secondary server.

DRAFT							    January                                                      November 1998

   must	update

      When the secondary server whenever a lease expires or DHCP client attempts to renew at T1 (approximately one
      half an IP
   address is released,	and must receive acknowledgement of that update
   before offering hour from the IP address start of the expired or released IP	address
   to a	different client.

7.  Server States

   The following server	states are defined:

   NORMAL State:

   NORMAL state	is lease), the state used by a primary server when it can communicate
      again determines the desired client lease interval, which is still
      3 days.  It then compares this with the other remaining acknowledged
      partner server in lease interval (3 days + 1/2 hour) and adjusts for
      the	Primary-Secondary Server pair. When in
   this	state, time passed since the Primary responds to DHCP clients requests, while secondary was last updated (1/2 hour).
      Thus the
   Secondary does not.

   COMMUNICATION-INTERRUPTED state:

   A remaining time on the acknowledged partner server goes into this state whenever it lease
      interval is	unable to communicate
   with	the other server. Both 3 days.  Adding the Primary and Secondary Servers can go
   into MCLT to this state, although yields 3 days plus 1
      hour, which is less than the behavior changes that result are dif-
   ferent. Primary and Secondary Servers cycle automatically (without
   administrative intervention)	between	NORMAL and COMMUNICATION-
   INTERRUPTED state as desired client lease interval of 3
      days.  So the client is renewed for the network connection between them fails and
   recovers, or	as desired client lease
      interval -- 3 days.

      When the partner primary DHCP server cycles between operational and
   non-operational. No duplicate IP address allocation can occur while updates the servers cycle between these states.  In this state both servers
   may respond to secondary DHCP client requests.	 When allocating new IP
   addresses, each server allocates from a different pool. When	respond-
   ing to
      after the DHCP client's renewal requests, each ACK is complete, it will calculate
      the desired partner server 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 allow continued renewal add the desired client lease interval of 3
      days, yielding a DHCP 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 current
      lease on an IP address.

   PARTNER-DOWN	state:

   PARTNER-DOWN	state is a state either	server can enter. interval so as to be able to always offer the client the
      desired client lease interval.

      Once a server
   has entered NORMAL state, the PARTNER-DOWN state is entered only on
   command of an external agency (typically an administrator initial actual client lease interval of	some
   sort) or after the expiration of an externally configured minimum
   safe-time after MCLT is past,
      the beginning 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 COMMUNICATION-INTERRUPTED state. failures.

5.2.  Controlled re-allocation of IP addresses

   When in this	state, the server PARTNER-DOWN state (after a period defined in detail in sec-
   tion 6.5.2 has passed), a there are no longer assumes that the restrictions on reallocating a
   lease from one client to another.

   In any other state, a server could	still be operational and servicing cannot reallocate an address from one
   client to another without first notifying (through a DHCPBNDUPD mes-
   sage) and receiving acknowledgement (through a different set of
   clients, but	instead	assumes DHCPBNDACK message)
   that it its partner is aware that that first client is not using the only server operating.
   Only	one server should
   address.

   This could be operating modeled in the following way (though this state at	a time.	The
   server specific
   implementation is in this state	will respond to	DHCP client requests. It will
   allow renewal of all	outstanding leases on IP addresses, and	will
   allocate no way required).  An "available" IP addresses from its own pool, and	after address on
   a	fixed period of
   time, it will allocate IP addresses from the	set of all available IP

DRAFT							    January 1998

   addresses. The server will transition out of	PARTNER-DOWN state after
   automatic re-integration the	companion server is complete.  This
   automatic re- integration will typically may be initiated by the	restart
   of the server allocated to any client.  An IP address which was down.

   POTENTIAL-CONFLICT state:

   This	state indicates	that the two servers are attempting
   leased to rein-
   tegrate with	each other, but	at least one of	them was running in a
   state client and which expired or was released by that did not guarantee	automatic reintegration client
   would take on a new state, say "pending-available".  When an IP
   address became "pending-available", the partner server would be possi-
   ble.	 In POTENTIAL-CONFLICT state

DRAFT                                                      November 1998

   notified that this IP address was "available" through a DHCPBNDUPD.
   When the servers may determine sending server received the DHCPBNDACK for that IP address
   showing it was "available", it would move the
   same IP address has been offered from
   "pending-available" to "available", and	accepted by two	different DHCP it would be available for
   allocation to any clients.

   RECOVER state:

   This	state indicates	that the server	has no information in its stable
   storage.

   A server MAY reallocate an IP address in	this "pending-available" state will	attempt to refresh its stable
   storage from
   the other server.

   SYNC	state: same client with no restrictions.

5.3.  Secondary renewal of leases

   When operating in NORMAL state, a secondary server MAY process
   DHCPREQUEST messages for renewal or rebinding leases.  In this state, the Secondary	Server attempts	to synchronize its
   stable storage with the Primary Server.  Both case,
   the Primary requirements for control of lease time and Secon-
   dary	may have information re-allocation of IP
   addresses are the same as that of the other lacks.

8.  Primary primary server.

6.  Server Operation

   This section discusses the operation of the primary a server implementing the
   Failover protocol using the state transition diagram in Figure 8.2-1.

8.1.  Primary 6.2-1.
   This is the common state transition diagram for both servers in a
   pair.

6.1.  Server Initialization

   When	the Primary Server starts, there are three possibilities: a server starts it
   has never started before and	therefore has no record	of any previous
   state nor starts out in STARTUP state.  See section 6.4
   below for details.

6.2.  Establishing Communications Integrity

   Central to the operation of	any client binding information;	it has started before
   and has the Failover protocol is a record notion of a previous state	and possibly
   "communications okay" or "communications failed".  State transitions
   are taken in many cases when the status of	some client
   binding information;	it has started before, but failed catastrophi-
   cally, communications with the
   partner changes.

   A specific discipline exists for establishing and now has no record	of any previous	state (nor verifying communi-
   cations integrity.  Communications is set to "okay" whenever a mes-
   sage sent is acked by the partner.  After an implementation dependent
   length of any client
   binding information).

   When time from the Primary Server starts, communications "okay" event the communica-
   tions with the partner are deemed to have "failed" if it has any record	of no subsequent
   acknowledgments have been received.  Whenever a previous
   state, then if that state was NORMAL DHCPPRPL, DHCPUP-
   DATEDONE, DHCPPOOLRESP or COMMUNICATION-INTERRUPTED it
   moves DHCPBNDACK is received this time period is
   restarted.

   Obviously, as the time period elapses, a server SHOULD send DHCPPOLL
   messages in order to COMMUNICATION- INTERRUPTED state.  If that state was
   PARTNER-DOWN elicit a DHCPPRPL message in reply, which will

DRAFT                                                      November 1998

   reset the time period.

   While an implementation SHOULD restart this time period on every
   DHCPUPDATEDONE, DHCPPOOLRESP or POTENTIAL-CONFLICT, then DHCPBNDACK or DHCPRPL, it moves MAY choose
   to	PARTNER-DOWN
   state.  If only restart it on a DHCPPRPL.

   This technique ensures that state was RECOVER, then two-way communications integrity exists
   between the Primary Server moves into servers.  Were the RECOVER state.

DRAFT							    January 1998

   If it has no	record timeout period to be reset on the
   receipt of any previous state, then either this is an
   initial startup, or a recovery message from the partner, a catastrophic network failure where
   stable storage and all client binding information was lost. These are
   distinguished by recovery from a catastrophic failure being indicated
   by some external configuration indication one
   server could send but not receive messages to the Primary Server.

8.2.  Primary partner could lead
   to failure of the entire redundant DHCP subsystem.  For example, in a
   situation where the primary could send but not receive any messages,
   the secondary would never take over from the primary and yet DHCP
   clients would not receive any service.

6.3.  Server State Transitions

   Figure 8.2-1 6.2-1 is the diagram of the Primary Server's server state transi-
   tions. 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
   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 Secondary Server. other server.

   The legend "responsive" and "responsive", "partially-responsive", or "unresponsive" in
   each state indicates whether the Primary Server server is responsive to DHCP client
   requests in the respective state.  The terms "responsive" and
   "unresponsive" have the obvious meanings, while "partially-
   responsive" means that a DHCP server may respond to DHCPREQUEST mes-
   sages that are RENEWAL or REBINDING, but to no other messages.

   In the diagram state transition diagram below, when communication is
   reestablished reesta-
   blished between the Primary and Secondary Server, the Primary
   server two servers, each must record the state of the Secondary Server
   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 a message is received from a partner with the state equal to zero
   (0), then the commun-
   ication receiving server should respond to that message with a
   DHCPPRPL if it was reestablished. a DHCPPOLL, but under no circumstances should it

DRAFT                                                      November 1998

   consider communications to be "okay", nor take any state transitions
   based on receipt of that message.

   If the state of the Secondary Server partner changes while communicating,
   then	the Primary Server communicating a server
   moves through the communications-failed tran-
   sition, transition and into whatever
   state results.  It then immediately moves through whatever state
   transition is appropriate given the current state of the	Secondary Server. partner
   server.

   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.

   All

   The current state transitions of the	Primary	Server a server must be recorded in its stable storage, storage and
   thus be available to the server after a server restart.

DRAFT							    January                                                      November 1998

   restart.

	       Previous	Primary	State:

	 NORMAL	or     RECOVER	       PARTNER DOWN
       COMMUNICATION  <ext. cmd>    POTENTIAL CONFLICT
	INTERRUPTED	  |		<none>
       +---+

        +---------------+  V  +--------------+
        |
       |     +----------------+	+-----------------+
       |     |    RECOVER  - |  |		- |  |   STARTUP  - |	  RECOVER
        |(unresponsive) |  +->|(unresponsive)|
        +---------------+     +--------------+
           Comm. OK             +-----------------+
          Other State:-RECOVER  |  PARTNER DOWN - |<-----+
          |      | (unresponsive) |              | (responsive)    |      |
       |     +----------------+
         All   POTENTIAL-       +-----------------+      |
       Others  CONFLICT------------ | --------+  ^(see   |
          |	 |	 ^	 |
       |   Comm. OK		 |                     Comm. OK      |  | 6.93) |   Sec.	State:		 |  Sec.
         UPDATEREQ(ALL)       Other State:	Comm.    |  +-----+ |
       Wait UPDATEDONE         |        |		 V  All	Others	Failed     | Comm.  | |
     Wait MCLT from fail   RECOVER	    +<---+	 V	 |	 |
       |  All Others| Failed | |	    +-------------+
      +--------------+         |        V     V  |  Others     |	 Comm. OK |  POTENTIAL
      |RECOVER-DONE +|      +--+    +--------------+   | |
      |(unresponsive)|      |	  Note	Sec. State:       |  CONFLICT  POTENTIAL + |<--+ |
      +--------------+   Wait for +>|  CONFLICT    |     |
         Comm. OK         Other   |	  Poss.	 RECOVER    |(responsive) |<---- |(unresponsive)|<--- | --+
     +--Other State:-+    State:  | +--------------+     |    V	  Error	  NORMAL    +-------------+   |
     |   | Sec->Pri           |	 Pri->Sec   RECOVER  |         |            |   |
     |   Sync   All      POTENT.  DONE   |	  Sync. Resolve Conflict     |   |
     |  Others:  CONFLICT-- | ----+     (see 6.9)        |   |
     | Wait for             V               V            |   |
     | Wait MDLI  | Other State: NORMAL +-----------------+           |   |
     | from Fail. |   V                 |     NORMAL    + | External  |   |
     |    V	    V	   |	 NORMAL   +--+----------+-->|(see 6.72, 6.73) |-Command-->+   |
     |    +-----++------>|  (responsive)   |		 |   |
       |      ^          ^   +-----------------+           |   |
     |      |          |            |                    |   |      Pri<->Sec
     |  Wait for   Comm. OK       Comm.            External  |
     |	Sync   Other      Other        Failed            Command   |
     |   State:     State:          |                or  |   |
     |RECOVER-DONE  NORMAL     Start Safe        Safe    |   |
     |			or      |     COMM. INT.  Period Timer       Period  |      Comm. OK   |	       "Safe Period"
     |   Comm. OK.     |     Sec. State:            V            expiration  |
     |       NORMAL	   +-----------------+		 |   |  Other State:   |     COMM. INT.  +------------------+           |		   - |---------->+   |
     |      RECOVER------|    RECOVER      +--| COMMUNICATIONS - |-----------+   |		     |
       |		   |
     V      +-------------|   INTERRUPTED    |   Comm. OK    |
       +------------------>|
    RECOVER               |  (responsive)   |--Sec. State:--+
			   +-----------------+    |--Other State:-+
    RECOVER-DONE--------->+------------------+   All Others

           Figure 8.2-1:  Primary 6.2-1:  Server state diagram.

DRAFT							    January                                                      November 1998

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

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

   Whenever any message is sent to the partner while in STARTUP state
   the STARTUP bit MUST be set in the 'flags' field of the message
   header.

6.4.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.  Ensure that the RESTART bit is set in the 'flags' field of the
          failover message header.  Once set, the RESTART bit must
          remain set in all failover messages sent by the server to the
          partner until the first acknowledgment of a message is
          received from that partner.  This is required to assure that
          the partner knows that the server has restarted, even if the
          partner itself is unreachable for a long while.

DRAFT                                                      November 1998

8.3.  Primary Server

          Do not send any messages until step 5.

      2.  Is there any record in	PARTNER-DOWN stable storage of a previous failover
          state?  If yes, set previous-state to the last recorded state

   When
          in stable storage, and continue with step 3.

          Is there any configuration information that indicates that
          this server was previously running but lost its stable
          storage?  Such information must typically come from some
          administrative intervention, since it 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 3.  This time-of-failure
          will be used in PARTNER-DOWN state, the Primary Server	operates largely
   as does a normal DHCP server, with none transition out of the special algorithms
   described RECOVER state into
          the RECOVER-DONE state, below.  In	PARTNER-DOWN

          If there is no record of any previous failover state in stable
          storage nor of any previous operational activity for this
          server, then set the Primary Server MUST
   respond to DHCP client requests.

   Any available IP address tagged as belonging previous-state to RECOVER and set the Secondary Server
   (at entry
          time-of-failure to	PARTNER-DOWN state) MUST NOT be	used until a time before the MDLI
   beyond maximum-client-lead-time
          before now.  If using standard Posix times, 0 would typically
          do quite well.

      3.  Is the entry into PARTNER-DOWN previous-state NORMAL?  If yes, set the previous-state
          to COMMUNICATIONS-INTERRUPTED.

      4.  Start the STARTUP state timer.  The time that a server remains
          in the STARTUP state has	elapsed.

   The Primary Server MUST NOT allocate	an IP address (absent any communications with its
          partner) is implementation dependent (and would typically be
          configurable).  It should be long enough to poll several times
          and stand a good chance to receive a DHCP	client
   different from that response to which	it was allocated at least one
          poll from a heavily loaded partner across a slow network.

      5.  Start sending DHCPPOLL messages (with both the	entrance to
   PARTNER-DOWN	state until RESTART and
          STARTUP bits set in the	MDLI beyond 'flags' field).

      6.  Wait for "communications okay", i.e., the	its expiration time has
   elapsed.  If	this time would	be earlier than receipt of an
          DHCPPRPL message.

          When a DHCPPRPL message is received, clear the current time plus RESTART flag,
          clear the MDLI, then STARTUP flag, and set the current time plus state to the MDLI is used.

   Two options exist for lease times, with different ramifications flow-
   ing from each.
          previous-state.

          If the Primary Server wishes	the Failover Protocol to protect it from
   loss	of stable storage partner is in any PARTNER-DOWN state,	then it	should ensure that the
   MDLI	based lease and if its partner-
          down time restrictions (received in Section 6.1 are maintained,
   even	in PARTNER-DOWN	state.

   If the Primary Server wishes	to forego the protection of the	Failover
   Protocol DHCPPRPL message in the event Absolute
          Time Option) is later than the last recorded time of loss operation
          of stable storage, this server, then it need recog-
   nize	no restrictions	on actual client lease times while in PARTNER-
   DOWN	state.

   The Primary Server MUST poll set the Secondary Server and attempt current state to
   establish communications RECOVER.

DRAFT                                                      November 1998

          Then, transition to the current state and	synchronization	with it.

   Once take the Primary succeeds in	contacting "communica-
          tions okay" state transition based on the Secondary Server, current state of
          this server and the
   Primary examines partner.

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

          Reasons to go to previous-state and begin processing:

          If the state of
   the Secondary Server current server is RECOVER or NORMAL, 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 both	servers	have
   been	running	in such	a way that duplicate IP	address	allocations were
   inhibited.  In this case, the Primary Server	updates other crashes and reboots.  If the Secondary
   Server with its rebooting server
          doesn't start processing DHCP client binding information, and moves into requests without first
          being in communication with the NORMAL
   state.

   Once	contact	has been established, if other server, then the state level
          of DHCP redundancy is not particularly high.  This is an
          appropriate approach if the Secondary
   Server possibility of partition is anything other than RECOVER low,
          or NORMAL then	the Primary
   Server moves	into if the POTENTIAL-CONFLICT state.

8.4.  Primary Server in	RECOVER	state

   When	Primary	Server safe period expiration time is initialized in well beyond the RECOVER state it expects to

DRAFT							    January 1998

   refresh its stable storage from time
          at which an existing Secondary Server.  In
   this	state operator would notice and react to a partition
          situation.  It is also quite appropriate if the Primary Server MUST NOT respond safe period
          will never expire.

          Reasons to DHCP client
   requests.

   When wait:

          If the Primary Server succeeds in contacting current server has been down for longer than the Secondary	Server,
   if
          maximum-client-lead-time, and it determines that the Secondary Server is itself	in the RECOVER
   state (which	indicates that the Secondary Server has	no existing
   client binding information), partitioned from the Primary Server will	move directly
   into	NORMAL state after signaling some kind of an error (since some
   person had other
          server, then when it returns it will attempt to explicitly start use its own
          available addresses to allocate to new DHCP clients, and the Primary Server
          other server may well be in	RECOVER PARTNER-DOWN state and may have
          already allocated some of those available addresses to
   refresh its lost client binding information from DHCP
          clients.  In cases where the	Secondary, possibility of partition is high,
          and the Secondary had no	state).

   If the Primary Server determines that safe period expiration time is less than the Secondary Server likely
          operator reaction time, this is in any a good approach to use.

6.5.  PARTNER-DOWN state other than RECOVER, then

   PARTNER-DOWN state is a state either server can enter.  When in this
   state, the Secondary	Server has some	client
   binding information server does not assume that the	Primary	Server needs before other server could still
   be operating and servicing a different set of clients, but instead
   assumes that it moves
   into is the NORMAL state.  The Primary Server will attempt only server operating.  For this reason, only
   one server should be operating in this state at a time.

6.5.1.  Upon Entry to refresh
   its PARTNER-DOWN state from

   When entering PARTNER-DOWN state a server MUST record the Secondary	Server, time of
   entry, and must transmit it will remain during every DHCPPOLL message or DHCPPRPL

DRAFT                                                      November 1998

   message sent while in the
   RECOVER state until it is successful PARTNER-DOWN state.

6.5.2.  Operation while in doing so.

   The Primary Server MUST remain PARTNER-DOWN state

   A server in RECOVER PARTNER-DOWN state until a period of at
   least the MDLI has passed since the Primary Server was known	to have
   failed.  This is MUST respond to DHCP client requests.
   It will allow any 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 that were	allocated by from the
   Primary Server prior	to loss set of Primary Server client binding infor-
   mation in stable storage to contact all
   available IP addresses.

   Once a server has entered NORMAL state, the Secondary Server or to time
   out.

   DISCUSSION:

      The actual requirement on	this wait period in RECOVER PARTNER-DOWN state is that it
      start when the Primary Server went down, not necessarily when it
      came back	up.  If
   entered only on command of an external agency (typically an adminis-
   trator of some sort) or after the time when expiration of an externally config-
   ured minimum safe-time after the Primary Server failed	is
      known, then it could be communicated beginning of COMMUNICATIONS-
   INTERRUPTED state.

   Any available IP address tagged as belonging to the recovering server, and
      the wait period could be reduced other server (at
   entry to PARTNER-DOWN state) MUST NOT be used until the MDLI less	the difference
      between the current time and the time maximum-
   client-lead-time beyond the entry into PARTNER-DOWN state has
   elapsed.

   A server failed. In this
      way, the waiting period could be minimized.

8.5.  Primary Server in	NORMAL PARTNER-DOWN state

   When	in NORMAL state, the Primary Server takes the following	actions
   to implement	the Safe Failover Protocol:

	o Lease	Time Calculations

	  As discussed in Section 6.1, "Control	of lease time",	the
	  lease	interval given MUST NOT allocate an IP address to a
   DHCP client	can never be more than different from that to which it was allocated at the maximum delta lease interval greater than
   entrance to PARTNER-DOWN state until the acknowledged

DRAFT							    January 1998

	  Secondary Server lease interval.

	  As long as maximum-client-lead-time
   beyond the Primary Server	adheres	to its expiration time has elapsed.  If this	constraint, time would be
   earlier than the
	  specifics of current time plus the lease intervals that	it gives to either maximum-client-lead-time, then
   the
	  DHCP client or current time plus the Secondary DHCP server are implementation
	  dependent. One possible approach is shown in Section 6.1, but
	  that particular approach maximum-client-lead-time is used.

   Two options exist for lease times given out while in no way	required by this proto-
	  col.

	o Lazy Update of Secondary Server

	  After	an ACK of a IP address binding, PARTNER-DOWN
   state, with different ramifications flowing from each.

   If the Primary Server
	  attempts to update server wishes the Secondary with Failover protocol to protect it from loss of
   stable storage in PARTNER-DOWN state, then it should ensure that the binding information.
	  The
   MCLT based lease time used restrictions in Section 5.1 are maintained,
   even in PARTNER-DOWN state.

   If the update of the Secondary MUST be at
	  least	that given server wishes to forego the DHCP client protection of the Failover proto-
   col in the DHCPACK.  It MAY,
	  however, be longer.

	o Reallocation event of IP Addresses Between Clients

	  Whenever a loss of stable storage, then it need recognize no
   restrictions on actual client binding is released, a DHCPBNDUPD message
	  must be sent to the Secondary	Server,	setting	the binding lease times while in PARTNER-DOWN
   state.

   A server in PARTNER-DOWN state MUST poll its partner and attempt to RELEASED. However, until
   establish communications and synchronization.

   While a DHCPBNDACK server is received for
	  this message, in PARTNER-DOWN state, it MUST send the IP address cannot be allocated to another
	  client.

8.6.  Primary Server absolute
   time of entry into PARTNER-DOWN using the absolute time option in	COMMUNICATION-INTERRUPTED Mode

DRAFT                                                      November 1998

   every DHCPPOLL and DHCPRPL message sent.

6.5.3.  Transitions out of PARTNER-DOWN state

   When a server in COMMUNICATION-INTERRUPTED PARTNER-DOWN state the Primary Server operates succeeds in such a way that correct operation	is ensured even	if the Secondary
   Server is still up and operational, but unable to communicate to the
   Secondary Server. When communications contacting its
   partner, its actions are reestablished between conditional on the
   Primary state and Secondary Servers, if both are still flags received
   in COMMUNICATION-
   INTERRUPTED state, then the re-integration of their operation will
   proceed automatically and without human intervention.  The protocol message from the other server.

   If the STARTUP bit is designed to ensure that reintegration will proceed set in an error
   free	manner and that	no actions taken by either the 'flags' field of a received DHCPPOLL
   message, the server while in
   COMMUNICATION-INTERRUPTED PARTNER-DOWN state will	cause problems during reintegra-
   tion.

   The Primary Server operates in COMMUNICATION-INTERRUPTED send a DHCPPRPL mes-
   sage with its current state as it
   does	in NORMAL state.

   However, since it cannot communicate (and with the Secondary absolute PARTNER-DOWN time
   in this
   state, the acknowledged-Secondary-lease-time	will not be updated DHCPPRPL).  A server in PARTNER-DOWN state MUST NOT take any new bindings. This
   state transitions based on reestablishing communications if the
   STARTUP bit is likely to eventually cause set in the actual-
   client-lease-times to be 'flags' field of the	current-time plus messages that reesta-
   blished communications.

   If the MDLI (unless this STARTUP bit is greater than not set in the desired-client-lease-time).

DRAFT							    January 1998

   The Primary Server can simply queue updates to 'flags' field then a server in
   PARTNER-DOWN state will move into POTENTIAL-CONFLICT state if the Secondary	on com-
   munication interruption and stay
   other server is in the NORMAL NORMAL, COMMUNICATIONS-INTERRUPTED, PARTNER-
   DOWN, or POTENTIAL-CONFLICT state. If, at

   If the time
   communication with STARTUP bit is not set in the Secondary 'flags' field, then a server in
   PARTNER-DOWN state will stay in PARTNER-DOWN state if it detects that
   the other server is reestablished, in RECOVER state.

   If the Secondary
   remains STARTUP bit is not set in the 'flags' field, then a server in
   PARTNER-DOWN state moves into NORMAL state as well,	then the queued	updates	for if it detects that the
   Secondary will simply be processed.

   COMMUNICATION-INTERRUPTED
   other server is in RECOVER-DONE state.

6.6.  RECOVER state for

   This state indicates that the Primary Server is a signal server has no information in its stable
   storage or that it has stopped queuing updates to the Secondary, and is	able to
   respond to re-integrating with a	variety	of possible Secondary states.

   It is anticipated that some alarm condition would be	raised upon the
   transition from NORMAL server in PARTNER-DOWN
   state	to COMMUNICATION-INTERRUPTED state. Once
   the Primary Server after it has been down.  A server in COMMUNICATION-INTERRUPTED this state for a
   period equal	to the safe-period, then it can	(if configured will attempt to do so)
   transition into
   refresh its stable storage from the PARTNER-DOWN state.  An external	command	may also
   force a transition to PARTNER-DOWN state.

9.  Secondary Server other server.

6.6.1.  Operation

   The Secondary Server	responds in RECOVER state

   A server in RECOVER MUST NOT respond to DHCP client	requests only request.

   A server in RECOVER state will attempt to reestablish communications
   with the
   PARTNER-DOWN	and COMMUNICATION-INTERRUPTED states.

9.1.  Secondary	Server Initialization

   When other server.

6.6.2.  Transitions out of RECOVER state

   If the Secondary Server starts, there other server is in POTENTIAL-CONFLICT state when communica-
   tions are three possibilities: it
   has never started before and	therefore has no record	of any previous reestablished, then the server in RECOVER state nor of	any client binding information;	it has started before
   and has a record of a previous will move
   to POTENTIAL-CONFLICT state itself.

DRAFT                                                      November 1998

   If the other server is in RECOVER state, then this server SHOULD sig-
   nal an error and possibly of	some client
   binding information;	it has started before, but failed catastrophi-
   cally, and now has no record	of halt processing.

   If the other server is in any previous other state, then the server in RECOVER
   state (nor will request an update of any client missing binding information).

   When information by send-
   ing an UPDATEREQ message.  If the Secondary Server starts, if server has been configured to indi-
   cate that it has any record lost its stable storage, it will send an
   UPDATEREQALL message, otherwise it will send an UPDATEREQ message.

   It will wait for an UPDATEDONE message, and upon receipt of a previous
   state, then if that state was NORMAL, COMMUNICATION-INTERRUPTED, or
   SYNC, mes-
   sage it moves will start a timer whose expiration is set to COMMUNICATION-INTERRUPTED state. If that state was
   PARTNER-DOWN	or POTENTIAL-CONFLICT, then it moves a time equal to	PARTNER-DOWN
   state. In all other cases (both other previous states and
   the cases
   where there is no record of a previous state), the Secondary	Server
   moves into time the RECOVER state.

9.2.  Secondary	Server State Transitions

   The server stays in went down (if known) or the current state until all of the actions speci-
   fied	on time (if
   the state transition	are complete.  If communications fails
   during one of down-time is unknown) plus the actions, maximum-client-lead-time.  When
   this timer goes off, the server simply	stays will go 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 current
   state and attempts a	transition whenever the	conditions for a

DRAFT							    January 1998

   transition are later	fulfilled.

   In the state	transition diagram below, the "+" other server or "-" to time out.

   See Figure 6.6-1.

   DISCUSSION:

      The actual requirement on this wait period in the	upper
   right corner	of each	state RECOVER is a notation about whether communication that it
      start when the recovering server went down, not necessarily when
      it came back up.  If the time when the recovering server failed is ongoing with
      known, then it could be communicated to the Primary Server. The legend responsive" recovering server, and
   "unresponsive" in each state	indicates whether
      the Secondary	Server
   is responsive wait period could be reduced to DHCP client	requests in the	respective state.

   In maximum-client-lead-time
      less the state	transition diagram below, when communication is	reesta-
   blished difference between the Secondary current time and Primary Server, the Secondary
   Server must record the state	of time the Primary Server when
      server failed. In this way, the communi-
   cations was reestablished. waiting period could be minimized.

   If the state an UPDATEDONE message isn't received within an implementation
   dependent amount of the Primary Server changes
   while communicating,	then the Secondary Server moves	through	the
   communications-interrupted transition, and into whatever state
   results.  At	that time, it and no DHCPBNDUPD message are being
   received, then immediately moves through whatever
   state transition is appropriate for the current state of the	Primary
   Server.

   All state transitions of the	Secondary Server must be recorded in its
   stable storage, and thus UPDATEREQ(ALL) message will be available to the	server after a server
   restart.

DRAFT							    January 1998

	       Previous	Secondary State:

	 NORMAL	   RECOVER	  PARTNER DOWN
       COMM. INT.   <none>	POTENTIAL CONFLICT
	  SYNC	      |		       |
       +---+	      V		       V
       |     +----------------+	+-----------------+
       |     |	  RECOVER   - |	|  PARTNER DOWN	- |<-----+
       |     | (unresponsive) |	|  (responsive)	  |	 |
       |     +----------------+	+-----------------+	 |
       |       |		 |	|	 ^	 |
       |   Comm. OK		 |   Comm. OK	 |	 |
       |   Pri.	State:		 |  Pri. State:	Comm.	 |
       |    |	   |		 V  All	Others	Failed	 |
       |    |	RECOVER	    +<---+	V	 |	 |
       |    |	   |	    |	    +--------------+	 |
       |    |	   |	 Comm. OK   |  POTENTIAL + |	 |
       |   All	   |	Pri. State: |  CONFLICT	   |	 | re-transmitted.

DRAFT                                                      November 1998

                A                                        B
              Server                                  Server

                |  Others                                        |
             RECOVER    |(unresponsive)|<--- | --+
       |    |	  Note	    |	    +--------------+	 |   |
       |    |	  Poss.	 Sec->Pri	    |		 |   |
       |    V	  Error	  Sync.	      Resolve Conflict	 |   |
       | Pri->Sec  |	    V		    V		 |   |
       |   Sync	   |	   +-----------------+		 |   |
       |    V	   V	   |	 NORMAL	   + |-External->+   |
       |    +-----++------>| (unresponsive)  | Command	 |   |
       |	  ^	   +-----------------+		 |   |                               PARTNER-DOWN
                |      Pri<->Sec                                        |	       ^
                | >--DHCPUPDATEREQ------------->         |
                |	Sync                                        |	 Start Alloc Timer
                |        <-----------------DHCPBNDUPD--< |
                | >--DHCPBNDACK---------------->         |
               ...                                      ...
                |	    Sec->Pri                                        |
                |        <-----------------DHCPBNDUPD--< |  +--------------+
                |	      Sync >--DHCPBNDACK---------------->         |
                |                                        |
                |	       + |--->+        <-------------DHCPUPDATEDONE--< |	    External
                |                                        |
       Wait MCLT from last known                         |	SYNC
          time of operation                              |  Comm.   Comm. OK	     Command
                |                                        |
           RECOVER-DONE                                  | unresponsive
                | Failed  Pri.	State:		or                                        |
                |  +--------------+ >--DHCPPOLL-(RECOVER-DONE)--->         |	     RECOVER   "Safe Period"
                |        <-------------------DHCPPRPL--< |	  ^	      V
                |	 expiration                                        |
                |                                     NORMAL
                |	  +------------------+                                        |
                |        <----------(NORMAL)-DHCPPOLL--< |      Comm. OK
                | COMMUNICATIONS - |---------->+ >--DHCPPRPL------------------>         |
                |     Pri. State:                                        |    INTERRUPTED
             NORMAL                                      |	 Comm. OK
                |                                        |       NORMAL-----|   (responsive)   |--Pri. State:--+
                |     COMM. INT.	  +------------------+	All Others                                        |		     ^
       +---------------------+

              Figure 9.2-1:	 Secondary Server State	Diagram. 6.6-1:  Transition out of RECOVER state

DRAFT							    January                                                      November 1998

9.3.  Secondary	Server in RECOVER

6.7.  NORMAL state

   The Secondary DHCP server comes up in

   NORMAL state is the RECOVER state used by a server when it has
   no record of	any previous state (or that previous state was RECOVER).

   It stays can communicate
   with the other server.  When in this state until	it establishes communication with state, the
   Primary Server, and is unresponsive primary responds to
   DHCP client all clients requests in this
   state. Essentially and while the secondary only responds to
   renewal or rebinding requests which it receives.  This is idle until it can contact one of the Primary
   Server.

   When	it establishes communication with
   few states where the Primary Server, it
   attempts to load its	client binding database	from that operation of the Primary
   Server primary and secondary servers
   are quite different.

6.7.1.  Upon Entry to NORMAL state

   When entering NORMAL state, a server will send to the other server
   all currently unacknowledged DHCPBNDUPD messages.

   When the above process is complete, if the server entering NORMAL
   state is a secondary server, then it will will request IP addresses
   for allocation using the DHCPPOOLREQ message and the techniques specified
   described in section 6.

   Once	the Secondary Server's client binding database is refreshed from
   that	of the Primary,	the Secondary Server moves into 2.5.

6.7.2.  Operation in NORMAL state.

9.4.  Secondary state: Primary Server

   When in NORMAL state

   In normal state, the	Secondary Server receives state	updates	from the
   Primary Server in DHCPBNDUPD	messages.  It records these in its
   client binding database in stable storage and then sends primary server takes the
   corresponding DHCPBNDACK message following actions
   to implement the Primary Server.

   While Failover protocol:

      o Lease Time Calculations

        As discussed in NORMAL state, the Secondary	Server MUST also acquire a
   series section 5.1, "Control of IP	addresses from lease time", the Primary Server lease
        interval given to a DHCP client can never be	used more than the
        maximum-client-lead-time greater than the acknowledged partner-
        server-lease-interval.

        As long as the primary server adheres to	satisfy
   DHCPDISCOVER	requests from DHCP clients when	in COMMUNICATION- INTER-
   RUPTED state. See Section 2.2.2 for details of this acquisition pro-
   cess.

   The Secondary Server	periodically polls constraint, the Primary Server with
        specifics of the
   DHCPPOLL message. If lease intervals that it fails gives to receive a DHCPPRPL message in reply
   after a configured number of	retries	or some	administratively deter-
   mined time, the Secondary Server transitions	into COMMUNICATION-
   INTERRUPTED state. Both the DHCPPOLL	and DHCPPRPL messages carry either the
   current status of
        DHCP client or the sender.

   If an external command secondary DHCP server are implementation
        dependent. One possible approach is received shown in section 5.1, but
        that particular approach is in no way required by the this protocol.

      o Lazy Update of Secondary Server, it can
   move	from NORMAL to PARTNER-	DOWN state directly.  Such a command
   might be sent when the Primary Server was removed from server, and

        After an
   operator wanted ACK of a IP address binding, the Secondary Server primary server
        attempts to take	over immediately and
   completely from the Primary Server.(Note that update the Secondary Server
   takes over from secondary with the Primary Server when binding information.
        The lease time used in COMMUNICATION- INTERRUPTED
   state, but less completely than the update of the secondary MUST be at
        least that given to the DHCP client in PARTNER-DOWN state). the DHCPACK.  It MAY,
        however, be longer.

DRAFT							    January                                                      November 1998

9.5.  Secondary	Server in COMMUNICATION-INTERRUPTED state

   When	in COMMUNICATION-INTERRUPTED state the Secondary Server	operates
   in such

      o Reallocation of IP Addresses Between Clients

        Whenever a way that correct operation client binding is ensured even	if released, a DHCPBNDUPD message must
        be sent to the Primary
   Server secondary server, setting the binding state to
        RELEASED. However, until a DHCPBNDACK is still up and operational, but unable received for this mes-
        sage, the IP address cannot be allocated to communicate another client.  It
        can be allocated to the
   Secondary Server. When communications are reestablished between the
   Primary and Secondary Servers, if both are still same client again.

6.7.3.  Operation in COMMUNICATION-
   INTERRUPTED NORMAL state: Secondary Server

   In normal state, then the re-integration of their operation will
   proceed automatically and without human intervention.  The protocol
   is designed to ensure that reintegration will proceed in an error
   free	manner and that	no actions taken by either secondary server receives binding updates from
   the primary server while in
   COMMUNICATION-INTERRUPTED state will	cause any conflicts to occur
   during re-integration.

   In COMMUNICATION-INTERRUPTED	state, DHCPBNDUPD messages.  It records these in its
   client binding database in stable storage and then sends the Secondary Server responds
   corresponding DHCPBNDACK message to
   DHCP	client requests.

   When	processing a DHCPREQUEST from a	DHCP client, the Secondary
   Server primary server.  It MUST
   ensure that the client- lease-time is never more	than information is recorded in stable storage prior to
   sending the DHCPBNDACK message back to the
   maximum-delta-lease-	interval from primary server.

   While in NORMAL state, the current-time,	independent secondary server MUST also acquire a
   series of IP addresses from the desired-	client-lease-time.

   When	processing a DHCPRELEASE request primary server to be used to satisfy
   DHCPDISCOVER requests from a DHCP client or the
   expiration clients when in COMMUNICATIONS-
   INTERRUPTED state.  See section 2.5 for details of a lease, this acquisition
   process.

   The secondary server periodically polls the Secondary	Server must not	reallocate primary server with the
   IP address to a different client.
   DHCPPOLL message.  If the same client subsequently
   performs a DHCPDISCOVER request, the	Secondary Server SHOULD	offer it
   the previously used IP address.

   When	processing fails to receive a DHCPDISCOVER request from DHCPPRPL message in reply
   after a DHCP client, configured number of retries or some administratively deter-
   mined time, the secon-
   dary	MUST allocate IP addresses from secondary server transitions into COMMUNICATIONS-
   INTERRUPTED state.  Both the list DHCPPOLL and DHCPPRPL messages carry the
   current state of IP addresses that it
   acquired from the Primary Server in RECOVER state. sender.

   When it exhausts
   this	list, it MUST stop responding in normal state, a secondary server is responsive to DHCPDISCOVER DHCP client
   requests (except
   those it can	satisfy	by offering expired if they are RENEWAL or released	IP addresses to
   their previously bound clients).

   The Secondary Server	MUST continue REBINDING. Any changes it makes to send DHCPPOLL messages
   any leases based on these responses should be sent to the
   Primary Server when primary
   server using DHCPBNDUPD messages.

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

   If a server in COMMUNICATION-INTERRUPTED NORMAL state fails to receive acks to any messages
   sent to its partner for an implementation dependent period of time,
   it will move into COMMUNICATIONS-INTERRUPTED state. (See section
   6.2).

DRAFT                                                      November 1998

   If it
   receives a DHCPPRPL message server in reply, the Secondary Server determines
   the NORMAL state of receives any messages from its partner
   where the Primary Server.  If partner has changed state from that expected by the Primary Server is server
   in NORMAL
   or COMMUNICATION-INTERRUPTED state, then the	Secondary Server moves server should transition into
   COMMUNICATIONS-INTERRUPTED state and take the SYNC state.

   If, however, appropriate state tran-
   sition from there.  For example, it would be expected for the Primary Server is in RECOVER partner
   to transition from POTENTIAL-CONFLICT into NORMAL state,	then but not for
   the Secon-
   dary	Server updates partner to transition from NORMAL into POTENTIAL-CONFLICT state.

6.8.  COMMUNICATIONS-INTERRUPTED State

   A server goes into COMMUNICATIONS-INTERRUPTED state whenever it is
   unable to communicate with the other server.  Primary Server with its known client	binding
   information, and moves into secondary
   servers cycle automatically (without administrative intervention)
   between NORMAL and COMMUNICATIONS-INTERRUPTED state upon completion of that
   update.

   If instructed to by an outside agency (e.g.,	an administrator), as the

DRAFT							    January 1998

   Secondary Server SHOULD move	into PARTNER-DOWN state.  Once network
   connection between them fails and recovers, or as the
   Secondary Server has	been in	COMMUNICATION-INTERRUPTED partner server
   cycles between operational and non-operational.  No duplicate IP
   address allocation can occur while the servers cycle between these
   states.

6.8.1.  Upon Entry to COMMUNICATIONS-INTERRUPTED state	for

   When a
   period equal	to the safe-period, then server enters COMMUNICATIONS-INTERRUPTED state, if it may	(if has been
   configured to do so) support an automatic transition out of COMMUNICATIONS-
   INTERRUPTED state and into the PARTNER-DOWN state in the absence of state, then a timer MUST be
   started for an external
   command.

9.6.  Secondary	Server in SYNCH	state

   The Secondary Server	does not respond to DHCP client	requests when in
   SYNCH state.

   DISCUSSION:

      This implementation dependent period.

   It is anticipated that some alarm condition would be raised upon the entire reason	for this states	existence, otherwise the
      activities specified for this state could	happen as part of a
      state
   transition from the	COMMUNICATION-INTERRUPTED NORMAL state to the
      NORMAL COMMUNICATIONS-INTERRUPTED state. However,

6.8.2.  Operation in	the COMMUNICATION-INTERRUPTED COMMUNICATIONS-INTERRUPTED State

   In this state the
      Secondary	Server responds a server may respond to DHCP client requests. Having	the
      Secondary	Server respond  When
   allocating new IP addresses, each server allocates from its own IP
   address pool.  When responding to renewal requests, each server will
   allow continued renewal of a DHCP client's current lease on an IP
   address, although the renewal period MUST not exceed the maximum
   client requests during lead time (MCLT) beyond the syn-
      chronization process (and	thus taking actions requiring further
      synchronization) seemed like a bad idea.

   The Secondary Server	synchronizes its information with lease time already acknowledged by
   the Primary
   Server while other server.

   A server operates in COMMUNICATIONS-INTERRUPTED state as the primary
   server does in SYNCH NORMAL state.	 Both Primary and Secondary Servers may
   have	information

   However, since the	other lacks because of operations performed
   while communications	were interrupted.

   During server cannot communicate with its partner in this
   state, the synchronization process, acknowledged-partner-lease-time will not be updated in any
   new bindings.  This is likely to eventually cause the Secondary Server continues actual-client-
   lease-times to
   poll be the Primary Server with	DHCPPOLL messages. current-time plus the maximum-client-lead-time

DRAFT                                                      November 1998

   (unless this is greater than the desired-client-lease-time).

6.8.3.  Transition out of COMMUNICATIONS-INTERRUPTED State

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

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

   If communications is restored with the other server, then the server
   in COMMUNICATIONS-INTERRUPTED state will go into COMMUNICATION-INTERRUPTED state.

   When	synchronization	is complete, another state based
   on the Secondary Server moves state of the partner:

      o partner in NORMAL or COMMUNICATIONS-INTERRUPTED

        The server will transition into the NORMAL state.

9.7.  Secondary	Server

      o partner in RECOVER

        Stay in COMMUNICATIONS-INTERRUPTED state.

      o partner in RECOVER-DONE

        Transition into NORMAL state.

      o partner in PARTNER-DOWN state

   The Secondary Server	responds to DHCP client	requests when or POTENTIAL-CONFLICT

        Transition into POTENTIAL-CONFLICT state.

      o partner in PAUSED

        Stay in COMMUNICATIONS-INTERRUPTED state.

      o partner in SHUTDOWN

        Transition into PARTNER-DOWN state.

   Any available IP address which does not belong to the private pool
   established by the

DRAFT                                                      November 1998

             Primary                                Secondary
              Server (at entry                                  Server

              NORMAL                                  NORMAL
                | >--DHCPPOLL----->:                     |
                |                  :<--------DHCPPOLL--< |
                |                  :                     |
           COMMUNICATIONS          :              COMMUNICATIONS
             INTERRUPTED           :                INTERRUPTED
                |                  :                     |
                | >--DHCPPOLL------------------>         |
                |        <-------------------DHCPPRPL--< |
              NORMAL                                     |
                |                                        |
                | >--DHCPBNDUPD---------------->         |
                |        <-----------------DHCPBNDACK--< |
                |                                        |
                |        <-------------------DHCPPOLL--< |
                | >--DHCPPRPL------------------>         |
                |                                     NORMAL
                |                                        |
                |        <-----------------DHCPBNDUPD--< |
                | >--DHCPBNDACK---------------->         |
               ...                                      ...
                |                                        |
                |        <----------------DHCPPOOLREQ--< |
                | >--DHCPPOOLRESP-(2)---------->         |
                |                                        |
                | >--DHCPBNDUPD-(#1)----------->         |
                |        <-----------------DHCPBNDACK--< |
                |                                        |
                |        <----------------DHCPPOOLREQ--< |
                | >--DHCPPOOLRESP-(0)---------->         |
                |                                        |
                | >--DHCPBNDUPD-(#2)----------->         |
                |        <-----------------DHCPBNDACK--< |
                |                                        |

       Figure 6.8-1:  Transition from NORMAL to PARTNER-DOWN state)
   MUST	NOT COMMUNICATIONS-
                      INTERRUPTED and back (example with 2
                      addresses allocated to secondary)

DRAFT                                                      November 1998

6.9.  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 used until
   possible.  In POTENTIAL-CONFLICT state the MDLI beyond servers may determine that
   the entry into PARTNER-DOWN
   state has elapsed.

   The Secondary Server	MUST NOT allocate an 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.

6.9.1.  Upon Entry to POTENTIAL-CONFLICT

   When a DHCP client
   different from primary server enters POTENTIAL-CONFLICT state it should
   request that to the secondary send it all updates of which it was allocated at the	entrance is
   currently unaware by sending an UPDATEREQ message to

DRAFT							    January 1998

   PARTNER-DOWN	state until the	MDLI beyond the	its expiration time has
   elapsed. If this time would be earlier than the current time	plus the
   MDLI, then the current time plus the	MDLI is	used.

   Two options exist secondary
   server.

   A secondary server entering POTENTIAL-CONFLICT state will wait for lease times, with different ramifications flow-
   ing from each.

   If the Secondary Server wishes
   the Failover Protocol primary to protect it
   from	loss of	stable storage in any state, then send it should ensure that
   the MDLI based lease	time restrictions an UPDATEREQ message.

6.9.2.  Operation in Section 6.1 are maintained,
   even POTENTIAL-CONFLICT state

   Any server in PARTNER-DOWN	state.

   If the Secondary Server wishes POTENTIAL-CONFLICT state MUST be unresponsive to forego the	protection incom-
   ing DHCP requests.

6.9.3.  Transitions out of POTENTIAL-CONFLICT state

   If communications fails with the safe
   Failover Protocol in	the event of loss of stable storage, then it MAY
   recognize no	restrictions on	actual client lease times partner while in
   PARTNER-DOWN	state.

   The Secondary Server	continues to poll the Primary Server with
   DHCPPOLL messages.  If the Secondary	Server receives POTENTIAL-CONFLICT
   state, then a reply, primary server will transition to PARTNER-DOWN state
   and the
   Primary Server is a secondary server will stay in POTENTIAL-CONFLICT state.

   Whenever either server receives an UPDATEDONE message from its
   partner, it MUST transition to NORMAL state.  This will cause the RECOVER state, the Secondary Server	updates
   the Primary Server with all of the Secondary's client binding infor-
   mation, and then moves into
   primary server to leave POTENTIAL-CONFLICT state prior to the NORMAL state.

   If communications with secon-
   dary, since the Primary Server are reestablished, primary sends an UPDATEREQ message and receives an
   UPDATEDONE before the
   Primary Server is in	any other state	but RECOVER, the Secondary
   Server moves	into secondary sends an UPDATEREQ message and
   receives its UPDATEDONE message.

   When a secondary server receives an indication that the primary
   server has transitioned from POTENTIAL-CONFLICT state (as does to NORMAL state, it
   SHOULD send an UPDATEREQ message to the primary server.

DRAFT                                                      November 1998

              Primary
   Server).

9.8.                                Secondary
              Server in                                  Server

                |                                        |
         POTENTIAL-CONFLICT state

   The secondary server	enters                    POTENTIAL-CONFLICT state	when the combi-
   nation
                |                                        |
                | >--DHCPUPDATEREQ------------->         |
                |                                        |
                |        <-----------------DHCPBNDUPD--< |
                | >--DHCPBNDACK---------------->         |
               ...                                      ...
                |                                        |
                |        <-----------------DHCPBNDUPD--< |
                | >--DHCPBNDACK---------------->         |
                |                                        |
                |        <-------------DHCPUPDATEDONE--< |
              NORMAL                                     |
                | >--DHCPPOLL--(NORMAL) ------->         |
                |        <-------------------DHCPPRPL--< |
                |                                        |
                |        <--------------DHCPUPDATEREQ--< |
                |                                        |
                | >--DHCPBNDUPD---------------->         |
                |        <-----------------DHCPBNDACK--< |
               ...                                      ...
                |                                        |
                | >--DHCPBNDUPD---------------->         |
                |        <-----------------DHCPBNDACK--< |
                |                                        |
                | >--DHCPUPDATEDONE------------>         |
                |                                        |
                |                                     NORMAL
                |                                        |
                |        <----------------DHCPPOOLREQ--< |
                | >--DHCPPOOLRESP-------------->         |
                |                                        |

           Figure 6.9-1:  Transition out of its POTENTIAL-CONFLICT

DRAFT                                                      November 1998

6.10.  RECOVER-DONE state and that	of the primary indicate	that a potential
   conflict of IP address allocation has occurred.  There is no	guaran-
   tee that such a conflict has	occurred -- just the possibility.  In
   this

   This state each server compares its client binding information with
   that	of the other exists to allow an interlocked transition for one server
   from RECOVER state and	any conflicts are resolved in an imple-
   mentation dependent manner.

   When	(and if) the resolution	process	completes, each another server moves from PARTNER-DOWN or
   COMMUNICATIONS-INTERRUPTED state into	the NORMAL state.

10.  Safe Period

   Due

6.10.1.  Operation in RECOVER-DOWN state

   A server in RECOVER-DONE state is responsive only to the restrictions imposed on each RENEWAL and
   REBINDING DHCP messages.

6.10.2.  Transitions out of RECOVER-DONE state

   When a server while in
   COMMUNICATION-INTERRUPTED RECOVER-DONE state determines that its partner
   server has entered NORMAL state, long-term operation	in this then it will transition into NORMAL
   state is
   not feasible	for either server. One reason that these states	exist at
   all,	is as well.

6.11.  PAUSED state

   This state exists to allow the	servers one server to easily survive transient network

DRAFT							    January 1998

   communications failures inform another that it will
   be out of a	few minutes service for what is predicted to be a few days (although the
   actual time periods will depend a great deal	on the DHCP activity of
   the network in terms	of arrival relatively short
   time, and departure of DHCP clients on the
   network).

   Eventually, when to allow the	servers	are unable other server to communicate, they	will
   have transition to move	into a COMMUNICATIONS-
   INTERRUPTED state where they	no longer can re-integrate
   without the some possibility	of immediately and (if it is 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 secondary server) to
   begin servicing clients with no interruption.

   A server which is down. In this case, there aware that it is no difficulty	in mov-
   ing shutting down temporarily SHOULD
   send one or more DHCPPOLL messages with the 'state' field containing
   PAUSED.

   While a server may or may not transition internally into PAUSED
   state, the	PARTNER-DOWN 'previous' state since determined when it is an accurate reflection of
   reality and restarted MUST be
   the protocol has	been designed to operate correctly (even
   during reintegration) if, when in PARTNER-DOWN state the partner is,
   indeed, down.

   The other difficulty	is when server was in prior to receiving the servers are	running	unattended for
   extended periods, command to shut-
   down and in this case restart and its entry into the option is provided PAUSED state.

6.11.1.  Upon entry to	config-
   ure something called	a "safe- period" into each server. This	OPTIONAL
   safe-period is PAUSED state

   When entering PAUSED state, the period after which either server MUST remember the Primary or Secondary
   Server will automatically transition	to PARTNER-DOWN	from
   COMMUNICATION-INTERRUPTED state.  If	this transition	is completed previous
   state, and use that state as the partner previous state when it is not down, then the possibility restarted.

6.11.2.  Transitions out of duplicate IP address
   allocations will exist.

   The goal PAUSED state

   A server transitions out of PAUSED state by being restarted.  At that
   time, the "safe-period" is previous state MUST be the state the server was in prior to
   entering the PAUSED state.

DRAFT                                                      November 1998

6.12.  SHUTDOWN state

   This state exists to allow network operations	staff
   some	time one server to	react inform another that it will
   be out of service for what is predicted to be a server moving into COMMUNICATION-INTERRUPTED
   state.  During the safe-period the only requirement is that the net-
   work	operations staff determine if both servers are still running -- relatively long time,
   and if they are, to either fix allow the network communications failure
   between them, or other server to transition immediately to PARTNER-
   DOWN state, and take one	of over completely for the servers server going down.

   A server which is aware that it is shutting down before the	expira-
   tion	of SHOULD send one or
   more DHCPPOLL messages with the safe-period.

   The length of 'state' field containing SHUTDOWN.

   While a server may or may not transition internally into SHUTDOWN
   state, the safe-period 'previous' state determined when it 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	previ-
   ously unknown DHCP clients requiring	IP addresses.  Many environments
   should restarted MUST be able
   the state active prior 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 command to shutdown unless the DHCP server
   detects that its partner has moved to hand out PARTNER-DOWN, in which case it
   MUST be RECOVER.

6.12.1.  Upon entry to	new DHCP clients and SHUTDOWN state

   When entering SHUTDOWN state, the
   need	to re-allocate IP addresses to different DHCP clients.

   The number of "extra" IP addresses required is equal	to server MUST record the expected
   total number	of new DHCP clients encountered	during previous
   state in stable storage for use when the safe	period.

DRAFT							    January 1998

   This server is dependent only on the arrival rate of new DHCP clients, not restarted.  It
   also MUST record the total number of outstanding leases on IP	addresses.

   In current time as the unlikely event that a	relatively short safe period of	an hour
   is all that can last time operational.

   A DHCPPOLL message SHOULD 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 sent to the DHCP subsystem partner with the 'state'
   field containing SHUTDOWN state.

6.12.2.

   A server in SHUTDOWN state MUST be unresponsive to ride through DHCP client input.

   If a
   minor problems that could occur and be fixed	within server receives any message indicating 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.  Open Issues

A number of details remain partner has
   moved to be worked	out.  They are as follows:

     1.	Level of Agreement and Completion

	This draft PARTNER-DOWN state while it is incomplete in two	senses.	 First,	none of SHUTDOWN state (e.g in
   response to the
	authors	agree with everything written, and quite DHCPPOLL it sent containing 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 number few seconds after informing the partner of
	issues remain
   entry into SHUTDOWN state (if communications are okay) to be worked determine
   if it will enter PARTNER-DOWN state.

6.12.3.  Transitions out of SHUTDOWN state

   A server transitions out among the various authors (to say
	nothing	about the rest of SHUTDOWN state by being restarted.

7.  Safe Period

   Due to the community).  Second, restrictions imposed on each server while in
   COMMUNICATIONS-INTERRUPTED state, long-term operation in this	draft state

DRAFT                                                      November 1998

   is not yet	complete enough	to support creation of inter-operable
	implementations.

	However, we believe feasible for either server.  One reason that even though this draft	is very	much a
	work in	progress, there these states
   exist at all, is value with sharing it with to allow the rest servers to easily survive transient
   network communications failures of the DHCP community in its current form.

     2.	Failover Port

	We need a few minutes to resolve whether the Failover	protocol runs with a few days
   (although the
	same or actual time periods will depend a different port as great deal on the
   DHCP protocol.	In the interests
	of allowing implementation activity of the Failover protocol by a dif-
	ferent process or sub-process, having it use a different port
	seems reasonable.

     3.	High Level Operations

	While the detailed operations are beginning to come together,
	the higher level operations (like reintegration) are, as yet,
	incompletely specifcied.  This will be rectified network in a later
	revision.

     4.	Option Spaces

	The draft currently reflects some rather fuzzy goals terms of arrival and departure of	using
   DHCP options where they	apply but also defining	new options.  It

DRAFT							    January 1998

	uses clients on the "user defined option space" for this, which is	probably
	not a good idea.  Perhaps network).

   Eventually, when the DHCP Panel servers are unable to communicate, they will produce
   have to move into a	larger
	option space in	which all state where they no longer can re-integrate
   without the some possibility of these options a duplicate IP address allocation.
   There are two ways that they can move into this state (known as
   PARTNER-DOWN).

   They can either be defined, or
	perhaps	(as it written in informed by external command that, indeed, the draft)
   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 will	just
	have has been designed to	define entirely	unique options.

     5.	Subnet Level Granularity

	This protocol talks about a server being operate correctly (even
   during reintegration) if, when in one PARTNER-DOWN state or
	another, however the desire partner is,
   indeed, down.

   The more difficult scenario is when the servers are running unat-
   tended for extended periods, and in this	protocol case an option is provided
   to operate
	independently in configure something called a "safe-period" into each address pool for server.  This
   OPTIONAL safe-period is the period after which a either the primary and or
   secondary server is defined.  In will automatically transition to PARTNER-DOWN from
   COMMUNICATIONS-INTERRUPTED state.  If this way, transition is completed
   and the "server"	state
	really refers to partner is not down, then the possibility of duplicate IP
   address allocations will exist.

   The goal of the "subnet" "safe-period" is to allow network operations staff
   some time to react to a server moving into COMMUNICATIONS-INTERRUPTED
   state.  Once  During the protocol safe-period the only requirement is vali-
	dated, that the editing net-
   work	to make	it operate at subnet granularity
	will be	performed.

     6.	Secondary Server Communications	with DHCP Clients

	There operations staff determine if both servers are two situations where we may want still running --
   and if they are, to allow either fix the	secon-
	dary server network communications failure
   between them, or to communicate with	DHCP clients even though take one of the
	secondary can communicate with servers down before the primary and would normally be
	unresponsive to	DHCP client requests.  expira-
   tion of the safe-period.

   The first situation which deserves consideration is where length of the
	secondary has given a DHCP client a lease safe-period is installation dependent, and depends
   in large part on an the number of unallocated IP address when
	it was not able	to communicate with addresses within the	primary,
   subnet address pool and then subse-
	quently the secondary becomes expected frequency of arrival of previ-
   ously unknown DHCP clients requiring IP addresses.  Many environments
   should be able to communicate with support safe-periods of several days.

   During this safe period, either server will allow renewals from any
   existing client.  The only limitation concerns the pri-
	mary.  When need for IP
   addresses for the	client unicasts	its DHCPREQUEST DHCP server to the secondary hand out to renew its lease, new DHCP clients and the	secondary will not be able
   need to communi-
	cate with the client (as this protocol re-allocate IP addresses to different DHCP clients.

DRAFT                                                      November 1998

   The number of "extra" IP addresses required is defined).  Should we
	allow the Secondary equal to extend the lease	for expected
   total number of new DHCP clients encountered during the safe period.
   This is dependent only on the arrival rate of new DHCP client and
	then inform clients, not
   the	primary 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	extension using	the DHCPBNDUPD
	message can provide sub-
   stantial benefits in allowing the same was	as the Primary uses DHCP subsystem to ride through
   minor problems that could occur and be fixed within that message? 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.

8.  Security

   The second situation arises where a client can only communicate Failover protocol MAY be secured with a simple shared secret mes-
   sage digest which covers each message.  Since there are a number of
   configuration parameters that must be the secondary due to some network failure,	but the	primary
	and secondary same on each server can communicate.  As written, the protocol
	will in a
   pair, it is not allow the secondary unreasonable to	offer require a	lease to the DHCP
	client,	but it would shared secret be	straightforward	to modify configured
   as well.

   Only information within the protocol
	to allow packet and covered by the secondary to do so.  The only difficult part message digest
   is used for operation of
	this change to the protocol would be to	suggest	how the	secon-
	dary would know protocol.  It is for this reason that
   the DHCP client could talk	only to IP address of the
	secondary.  But, given that if sending server is sent in the DHCP	primary	could talk to 'sending server
   id' field of the DHCP client, fixed header of the secondary would expect to hear about failover message when it in
	DHCPBNDUPD messages at some point, might
   seem that the absence of such messages same information could be used as a signal to communicate to recovered from the	DHCP client source
   address of the IP packet.

9.  Extended Discussion

   Some areas in
	question.

DRAFT							    January 1998

     7. the draft above warranted more extended discussion than
   was feasible to insert directly into the next.

      1.  UDP or TCP

          There has been much debate about the utility of using UDP for the failover
          Failover protocol, since it doesn't supply guaranteed
          delivery.  Certainly rebuilding	TCP out	of  UDP would be	a mis-
	take.  Some factors to consider	in this	debate are has been chosen as follows: the protocol of choice for
          the failover protocol due to the following factors:

          First, it is important to recognize that mere receipt of a
          packet by the other server in the pair (e.g., receipt of a
          DHCPBNDUPD packet by the secondary server) is not sufficient
          for the primary to update its own bindings database with new infor-
	mation
          information about what the secondary knows.  In all cases of

DRAFT                                                      November 1998

          transfers of bindings binding information, the server of a DHCPBNDUPD
          message MUST update its own stable storage prior to replying
          with a DHCPBNDACK message (except in the marginal case where
          all of the updates are rejected).  An action is required by
          the receiving server and an explicit ACK is needed by the
          sending server to ensure the integrity of the protocol.  So,
          just know-
	ing knowing that the other server has received a Failover
          protocol packet is not intrinsically interesting.

          Second, the DHCP protocol, both the client and server side, is
          being implemented in progressively smaller and smaller
          machines.  While this progression is most evident in DHCP
          clients, there exist implementations today of DHCP servers
          embedded in devices that are by no stretch of the imagination
          traditional "servers" running mainstream operating systems.
          In many ways, the Fail-
	over Failover protocol is very well suited to
          such devices.  Adding addi-
	tional additional protocol infrastructure
          requirements to implement the Failover protocol could	easily might prevent
          its implementation in devices that in some ways need it most. most
          (devices with limited stable storage of their own).

          Third, there are only a few cases where the Failover protocol
          requires guaranteed delivery of packets.  In particular, the
          normal Primary to Secondary DHCPBNDUPD message to do not have to
          be delivered reliably.  The consequences of lost DHCPBNDUPD mes-
	sages
          messages are handled by the use of the MDLI, MCLT, for the simple
          reason that since these messages are "lazy", they may not get
          delivered because of a server failover Failover prior to their
          transmission.  Given
	that the  The protocol is robust in the face of loss of
          either a DHCPBNDUPD message or a DHCPBNDACK message, message.

          Furthermore, a technique known as "fire and forget" may be
          used with this protocol and two cooperating implementations.
          If the DHCPBNDACK message contains all of the information originally ori-
          ginally in the DHCPBNDUPD message, then the DHCPBNDUPD message
          may be transmitted and forgotten by the sending server (typically (typi-
          cally the primary).  When and if the secondary receives the
          DHCPBNDUPD and replies with a DHCPBNDACK message and the	primary pri-
          mary receives it, the primary will update its

DRAFT							    January 1998 stable storage
          with a new picture of what the secondary knows about the lease
          time.  If either of these messages is lost, the only downside
          is that the DHCP client associated with the bind-
	ing binding in question ques-
          tion may receive a shorter lease for one lease period than it
          would otherwise.   This "fire and forget" technique could substantially sub-
          stantially ease both the complexity of implementation and
          memory requirements of an implementation of the Failover
	protocol, pro-
          tocol, especially where two servers were communicating over a
          very slow link.

12.

DRAFT                                                      November 1998

10.  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 led 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 Fail-
   over
   Failover draft by Greg Rabil, Mike Dooley, and 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 the 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, changes in time
   for the Summer Chicago IETF meeting.

   During the summer and that	is what	you fall of 1998, two groups have been working on
   separate implementations of the evolving draft.  Bernie Volz and
   Steve Gonczi constitute one group, and Kim Kinnear, Mark Stapp and
   Paul Fox make up the other.  These two groups have worked together to
   produce considerable changes and simplifications of the protocol dur-
   ing this period, and Steve Gonczi and Kim Kinnear have edited these
   changes into this latest revision in time for submission to the
   December 1998 Orlando IETF meeting.

   These most recent changes have been reviewed by Ralph Droms, Greg
   Rabil, Bernie Volz, Steve Gonczi, Mark Stapp, Paul Fox, and Kim Kin-
   near.  This does not preclude any of these people from expressing
   disagreement with what is contained in your hands. this draft at any future time.

   Many people have reviewed the various earlier drafts that went into
   this result.  At American Internet, ideas	have been were contributed by Mark
   Stapp, Brad Parker,
   Parker.  At Cisco Systems, Paul Fox, and Ellen Garvey. Garvey have contri-
   buted greatly to the form of the protocol.  Glenn Waters of Bay

DRAFT                                                      November 1998

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

13.

11.  References

	[1]

   [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
      2131, March 1997.

	[2]

   [RFC 2119] Bradner, S. "Key words for use in RFCs to Indicate
      Requirement Levels", RFC 2119.

   [RFC 2132] Alexander, S.,  Droms, R., "DHCP Options and BOOTP Vendor
      Extensions", Internet RFC 2132, March 1997.

DRAFT							    January 1998

	[3] Rabil, G., Dooley, M., Kapur, A., Droms, R., "DHCP Failover
	    Protocol", draft-ietf-dhc-failover-00.txt.

	[4] Gudmundsson, Olafur, "Security Architecture	for DHCP",
	    draft-ietf-dhc-security-arch-00.txt.

14.

12.  Author's information

      Ralph Droms
      323 Dana Engineering
      Bucknell University
      Lewisburg, PA  17837

      Phone: (717) 524-1145
      EMail: droms@bucknell.edu

      Greg Rabil, Mike Dooley, Arun Kapur
      Quadritek	Systems, Inc.
      Lucent Technologies (Quadritek)
      10 Valley Stream Parkway, Suite 240
      Malvern, PA 19355

      Phone: (800) 208-2747

      EMail: grabil@quadritek.com
	     mdooley@quadritek.com
	     akapur@quadritek.com grabil@lucent.com
             mdooley@lucent.com
             akapur@lucent.com

      Kim Kinnear
      American Internet	Corporation
      4	Preston	Ct.
      Bedford,
      Mark Stapp
      Cisco Systems
      250 Apollo Drive
      Chelmsford, MA  01730-2334  01824

      Phone: (781) 276-4587 (978) 244-8000

DRAFT                                                      November 1998

      EMail: kinnear@american.com kkinnear@cisco.com
             mjs@cisco.com

      Steve Gonczi, Bernie Volz
      Process Software Corporation
      959 Concord St.
      Framingham, MA  01701

      Phone: (508) 879-6994

      EMail: gonczi@process.com
             volz@process.com