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

Versions: 00

Network Working Group                                           R. Droms
INTERNET DRAFT                                       Bucknell University
                                                              K. Kinnear
                                           American Internet Corporation
                                                              April 1997
                                                    Expires October 1997


                   An Inter-server Protocol for DHCP
                <draft-ietf-dhc-interserver-alt-00.txt>


Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working docu-
   ments of the Internet Engineering Task Force (IETF), its areas, and
   its working groups. Note that other groups may also distribute work-
   ing documents as Internet-Drafts.

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

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

Abstract

   The DHCP protocol is designed to allow for multiple DHCP servers, so
   that reliability of DHCP service can be improved through the use of
   redundant servers.  To provide redundant service, all of the DHCP
   servers must be configured with the same information about assigned
   IP addresses and parameters; i.e., all of the servers must be config-
   ured with the same bindings.  Because DHCP servers may dynamically
   assign new addresses or configuration parameters, or extend the lease
   on an existing address assignment, the bindings on some servers may
   become out of date.  The DHCP inter-server protocol provides an auto-
   matic mechanism for synchronization of the bindings stored on a set
   of cooperating DHCP servers.

   This draft is a direct extension of draft-ietf-dhc-
   interserver-00.txt, but has been renamed draft-ietf-dhc-interserver-
   alt-00.txt since an alternative proposal (also a direct extension of
   draft-ietf-dhc-interserver-00.txt but in a different direction)



Droms & Kinnear                                                 [Page 1]


DRAFT                                                         April 1997


   exists named draft-ietf-dhc-interserver-01.txt.


1.  Introduction

   DHCP servers manage the assignment of IP address and configuration
   parameters to IP hosts.  The DHCP protocol specification [1] refers
   to the collection of configuration information assigned to a client
   as a "binding".  The DHCP protocol is designed to allow for multiple
   DHCP servers, so that reliability of DHCP service can be improved
   through the use of redundant servers.  To provide redundant service,
   all of the DHCP servers must be configured with the same information
   about assigned IP addresses and parameters; i.e., all of the servers
   must be configured with the same bindings.  Because DHCP servers may
   dynamically assign new addresses or configuration parameters, or
   extend the lease on an existing address assignment, the bindings on
   some servers may become out of date.

   The DHCP inter-server protocol provides an automatic mechanism for
   synchronization of the bindings stored on a set of cooperating DHCP
   servers.

   The remainder of this document is organized in the following sec-
   tions:

     2.  Goals and Requirements

         Defines the requirements and goals for the protocol.  Discusses
         limitations of the protocol.  Also contains a definition of
         several classes of failures as well as a list of specific fail-
         ures (which provide a useful common ground for discussion).

     3.  Overview

         Discusses in a general way the content of the information com-
         municated between servers implementing this protocol as well as
         the way that information is communicated.

         Defines some key concepts surrounding the allowable "states" of
         an IP address, including extensions critical to the operation
         of this protocol.

         Gives a brief sketch of the actions required by this protocol
         for each DHCP client request received by the server.

     4.  Groups





Droms & Kinnear                                                 [Page 2]


DRAFT                                                         April 1997


         Examines the concept of a group of servers as used by this pro-
         tocol, and defines the "group specifier" used in all messages
         of this protocol.

     5.  Protocol Messages

         Examines the general structure of the messages used by this
         protocol.  For each message, it lists the format of the message
         along with all possible success and error status returns.  Mes-
         sages discussed in two groups: Address Information Messages and
         Configuration Messages.

     6.  Protocol Operations

         The messages from Section 5 are grouped into some higher level
         operations, and these are explained: POLL, PUSH, DUMP, TRANS-
         FER, GROUP JOIN, GROUP LEAVE.

     7.  Protocol Actions

         The actions required by this protocol in response to incoming
         messages are detailed for each message a DHCP server can
         receive.  The messages are grouped in three sections:  DHCP
         Client Messages and Events, Address Information Messages, and
         Configuration Messages.  The first of these are the normal DHCP
         messages, and the second and third are the new messages gener-
         ated as part of this protocol.

     8.  IP Address State Transition

         This protocol expands the possible states for an IP address.
         The new states are described in Section 3.3.  This section
         describes all of the transitions between states in detail.

     9.  Server Initialization

         This section describes how a server becomes a member of a group
         to deliver a reliable DHCP service, as well as the actions to
         take on every server restart.

     10. Open Questions

         Poses open questions about the protocol.  The questions from
         draft-ietf-dhc-interserver-00.txt are included verbatim, and
         for some answers are supplied.  Questions new to this draft are
         included as well.





Droms & Kinnear                                                 [Page 3]


DRAFT                                                         April 1997


1.1.  The Language of Requirements

   Throughout this document, the words that are used to define the sig-
   nificance of particular requirements are capitalized.  These words
   are:

     o "MUST"

       This word or the adjective "REQUIRED" means that the item is an
       absolute requirement of this specification.

     o "MUST NOT"

       This phrase means that the item is an absolute prohibition of
       this specification.

     o "SHOULD"

       This word or the adjective "RECOMMENDED" means that there may
       exist valid reasons in particular circumstances to ignore this
       item, but the full implications should be understood and the case
       carefully weighed before choosing a different course.

     o "SHOULD NOT"

       This phrase means that there may exist valid reasons in particu-
       lar circumstances when the listed behavior is acceptable or even
       useful, but the full implications should be understood and the
       case carefully weighed before implementing any behavior described
       with this label.

     o "MAY"

       This word or the adjective "OPTIONAL" means that this item is
       truly optional.  One vendor may choose to include the item
       because a particular marketplace requires it or because it
       enhances the product, for example; another vendor may omit the
       same item.


1.2.  Terminology

   This document uses the following terms:

     o "DHCP client"

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



Droms & Kinnear                                                 [Page 4]


DRAFT                                                         April 1997


     o "client"

       Whenever the term client is used in this draft, it refers to a
       DHCP client (and not a server communicating with another server
       using this protocol).

     o "DHCP 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, including
       at least an IP address, associated with or "bound to" a DHCP
       client.  Bindings are managed by DHCP servers.

     o "active server"

       An active server is one which is capable of offering IP addresses
       to clients.

     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.


2.  Goals and Requirements

   There are several levels of goals for this protocol.  There are a set
   of requirements with which it must comply, and then there are a set
   of goals for the protocol and the way that it is used that are listed
   in priority order.


2.1.  Requirements on this Protocol

   The following list of requirements must be (and are) achieved by this
   protocol.

     1. Implementations of this protocol works with existing DHCP client
        implementations based on the DHCP protocol [1].  It must work
        with today's clients!




Droms & Kinnear                                                 [Page 5]


DRAFT                                                         April 1997


     2. Implementation works with existing BOOTP relay implementations.

     3. Can be specified with sufficient clarity that unique implementa-
        tions will work well together the first time (e.g. DHCP today
        largely meets this requirement).

     4. Work with minimum of two and a maximum of 16 servers.

2.2.  Goals of this Protocol

   The following are the goals of this protocol.  These goals are listed
   in priority order.  The protocol meets all of these goals.

     1. Avoid binding an IP address to a client while that binding is
        currently valid for another client.  In other words, don't allo-
        cate the same IP address to two clients.

     2. Ensure that an existing client can keep its existing IP address
        binding if it can communicate with any DHCP server using this
        protocol -- not just the server that originally offered it the
        binding.

        DISCUSSION:

           There is a subtle but very important point here.  For exam-
           ple, assume that there are five servers using this protocol.
           Everything is running fine, and then the network becomes par-
           titioned, and three servers can communicate among themselves,
           and the other two can communicate among themselves -- but the
           set of three cannot communicate with the set of two.  Each
           set, however, can communicate with some clients.

           In this situation, every client that can communicate with a
           DHCP server in either set should be able to continue to use
           its existing binding, even if the server that originally cre-
           ated the binding is not included in the set of servers with
           which it can communicate.

     3. Do not add any requirement for communication with another server
        to the processing between a DHCPDISCOVER and a DHCPOFFER or
        between a DHCPREQUEST and a DHCPACK.

        DISCUSSION:

           This is another subtle point.  The implications of this goal
           are that "lazy" update of IP address binding information is
           required.  In other words, because of this goal, the protocol
           cannot require one server to update another server with



Droms & Kinnear                                                 [Page 6]


DRAFT                                                         April 1997


           information concerning a new IP address binding prior to
           sending the DHCPACK to the DHCP client.

        As a result of this goal, a server may fail immediately after
        sending the DHCPACK to the client but prior to successfully
        sending a record of that information to any other server.
        Should this happen, the DHCP client is the only operational
        machine with a record of this binding -- and the protocol must
        be (and has been) designed to properly deal with this situation.

     3. Ensure that a new client can get an IP address from some server.

     4. If a server goes down, and an external agent determines that it
        is actually down as opposed to running but simply unable to com-
        municate with other servers, then the addresses that it cur-
        rently owns but are not yet bound may be recovered for use by
        other servers.

     5. Ensure that in the face of partition, where servers continue to
        run but cannot communicate with each other, the above goals and
        requirements are met.  In addition, when the partition condition
        is removed, allow graceful re-integration.


2.3.  Limitations of this Protocol

   The following are explicit limitations of this protocol.  This is not
   to say that they are not useful capabilities to have (that's why they
   are explicitly listed, so that it will be clear that this protocol
   does not supply them).

     1. Determination of permanent server failure.

        The protocol provides a way to propagate information about the
        permanent failure of a server, but no way to detect a permanent
        failure.  Transient failures are detected, but there is no mech-
        anism in this protocol to determine when a transient failure is
        really a permanent failure.  Some external agent must make this
        determination -- and must ensure that the server declared perma-
        nently failed is not simply partitioned from the other servers
        and unable to communicate with them.  The server which has been
        declared permanently failed by the external agent MUST be
        informed of that declaration prior to restart.

        DISCUSSION:

           The existing configuration messages would allow one server to
           declare another server as permanently failed and remove it



Droms & Kinnear                                                 [Page 7]


DRAFT                                                         April 1997


           from the group.  That is not the issue.  What makes fully
           automatic determination of permanent server failure impracti-
           cal is distinguishing between permanent server failure (which
           is easily defined as  transient server failure that has gone
           on too long) and partition of the group of servers.

           Once communication fails with a server, the other servers
           cannot know if it is still operating or not, and removing an
           operating server from the group is an activity fraught with
           peril.

           This protocol is designed that it will re-integrate cleanly
           when it can communicate again with the rest of the group.

           Group membership protocols typically handle a partition situ-
           ation (when they bother to handle it at all) by having the
           partitioned server determine that it has been partitioned and
           shut itself down.  It detects a partition condition in one of
           two ways:  either it can't communicate with the "master", or
           it can't communicate with the "majority" of the group.  In
           either case, it shuts down.

           We believe that this is not an appropriate response for a
           DHCP server.  If my DHCP client can talk to a DHCP server, I
           want my client to continue to operate -- I'm not interested
           in having the only DHCP server to which I can talk shut
           itself down!

     2. Some addresses are temporarily unavailable during transient
        server failure.

        The full range of existing IP addresses that are potentially
        available for allocation is reduced during the period of a tran-
        sient server failure.  The size of the pool of addresses that
        are available for allocation but not yet allocated SHOULD be
        configurable for each server.  If the server is subsequently
        declared to have undergone a permanent failure, these addresses
        will be made available again.

        Note that it is only the addresses not yet allocated but avail-
        able for allocation that are unusable during the period of a
        transient server failure.  IP addresses that have been allocated
        to clients may continue to be used by those clients even during
        server failure.  Indeed -- to allow existing clients to be able
        to renew their existing IP addresses even if the server who
        granted them the lease has failed is a primary reason why this
        protocol exists.




Droms & Kinnear                                                 [Page 8]


DRAFT                                                         April 1997


2.4.  Failures

   This section makes explicit both classes of failures as well as a
   list of specific failure scenarios in order to facilitate discussion
   of the capabilities of this protocol.

     o "transient server failure"

       A transient server failure is one where a server is unable to
       respond to requests, but later becomes operational and able to
       respond to requests.  Its local stable storage (i.e. whatever
       mechanism it uses to preserve its binding information) is accu-
       rate as of the time that transient server failure began.

     o "permanent server failure"

       A permanent server failure is one where a server is unable to
       respond to requests -- probably for an extended period. While the
       protocol defined in this document supports declaration of a per-
       manent server failure, the decision that a transient server fail-
       ure is in reality a permanent server failure is beyond the scope
       of this protocol.

       This determination will be likely be performed by some adminis-
       trative entity, although in the future a group membership proto-
       col could be integrated with the protocol defined in this docu-
       ment to make such determinations automatically.

     o "partition"

       A network partition is caused by a failure of the underlying com-
       munications substrate, such that two systems that could previ-
       ously communicate cannot now do so.  This may mimic transient
       server failure, but is not the same because in this case the
       server that appears to have failed may still be operational and
       interacting with clients.

       There is a form of partition known as "partial partition", where
       the transitivity of communication usually expected is not
       achieved.  Imagine a set of servers organized (for the purposes
       of exposition only) as a ring where each server can communicate
       with its neighbors, but nobody else -- and when the number of
       servers is greater than three, a partial partition situation
       exists.

       This term may also be used as a noun, as in "each partition may
       communicate with ...", and in this case it refers to the group of
       servers which can communicate normally (as distinguished from



Droms & Kinnear                                                 [Page 9]


DRAFT                                                         April 1997


       those with which that group cannot communicate).

     o "communication failure"

       Communications failure describes the condition where the communi-
       cation channel between two servers becomes impossible.  "Partial
       communication failure" describes the case where the normally
       bidirectional communications channel becomes unidirectional,
       where one server can send to but not receive from another server.

   Some examples of the above failures are given below:

     1. A single server crashes and reboots. [transient failure]

     2. A single server crashes and stays down for a period of hours and
        then reboots (either automatically or through some external
        agent).  [transient failure]

     3. A single server fails and never returns.  No permanent failure
        is declared for this server.  [transient failure]

     4. A single server fails. A permanent failure is declared for this
        server. [permanent failure]

     5. A group of two servers are partitioned so that they cannot com-
        municate, but each can communicate to some clients.  [partition]

     6. A group of five servers are partitioned so that three can commu-
        nicate together and the remaining two can also communicate, but
        the two partitions cannot communicate.  Each partition can com-
        municate with a subset of the clients, and these subsets are
        disjoint.  [partition]

     7. A group of five servers are partitioned so that three can commu-
        nicate together and the remaining two can also communicate, but
        the two partitions cannot communicate.  Each server continues to
        be able to communicate with all of the clients.  [partition]

        DISCUSSION:

           This situation is unlikely to occur, but the protocol should
           be able to handle it.

     8. Server A can send packets to server B, but cannot receive pack-
        ets from server B. [partial communications failure]

     9. There are four servers, A, B, C, and D.  A cannot communicate
        with C, B cannot communicate with D. [partial partition]



Droms & Kinnear                                                [Page 10]


DRAFT                                                         April 1997


   DISCUSSION:

      This section on failures may well not belong in the final docu-
      ment.  For the purposes of review of the rest of the protocol,
      however, defining a common language to describe failures and giv-
      ing specific examples of failures as an aid to discussion seemed
      useful.


3.  Overview

   At the most basic level, the DHCP protocol specifies the behavior of
   DHCP servers which communicate with DHCP clients in order to allocate
   IP address to the clients as well as provide a variety of configura-
   tion parameters information to them.  It is the allocation of IP
   addresses to clients by the server that creates a requirement to
   update what is known as "stable storage"  -- typically held on disk.
   This information is used to "remember" the IP address bindings that
   have been made by the DHCP server in order to avoid allocating the
   same IP address to two clients.

   The key motivation for an inter-server protocol is the desire to
   allow a client to continue to use its IP address (i.e. be able to
   renew its lease on an IP address) even if the server who initially
   offered it the lease on its IP address is unavailable for some rea-
   son.  In addition, no IP address should ever be bound to two clients
   simultaneously.

   Providing multiple DHCP servers to which each client can communicate
   is the first step in creating this reliable DHCP capability.

   In addition, these DHCP servers must communicate in order to provide
   this reliable DHCP capability.


3.1.  What information must be communicated between servers implementing
the inter-server protocol?

   Information about IP addresses is what is communicated among DHCP
   servers in order to provide this reliable DHCP service.  There are
   two types of information about IP addresses that are relevant to the
   inter-server protocol:


     o IP Address State Information

       Information on whether an IP address is bindable (i.e. could be
       offered to a DHCP client) or bound (i.e. is currently bound to a



Droms & Kinnear                                                [Page 11]


DRAFT                                                         April 1997


       client).

     o IP Address Binding Information

       If an IP address is bound to a client, then considerable informa-
       tion about that client must be stored in the stable storage of a
       DHCP server.  This information is maintained to allow a lease on
       an IP address to expire and that IP address to be re-used by
       another client.  It is also maintained to allow a client to check
       to see if it is using the "proper" addresses -- i.e.  the one to
       which it was bound.  As well, the server uses this information to
       check for errors when a client attempts to renew the lease on an
       IP address.

   The inter-server protocol described here involves communicating both
   types of information between servers.


3.2.  How is this information communicated between servers implementing
the inter-server protocol?

   The protocol requires that servers who implement it can communicate,
   each with the other, in a point-to-point manner (when all are operat-
   ing correctly).  It allows for the possibility that they can fail
   entirely (i.e. crash) or be unable to communicate with each other for
   a variety of reasons.

   These servers will periodically need to communicate with other
   servers in the group.  There are several recurring styles of communi-
   cation that, if defined, will assist in explaining the major concepts
   of this protocol.  These major styles of group communication are as
   follows:

     o POLL

       A POLL operation is used when one server must contact every other
       server in the group in order to request that they respond with
       some information (typically concerning an IP address).  Usually,
       if the server executing the POLL cannot contact all of the other
       servers, it will use whatever information it could glean from
       those it could contact.

       A COMPLETE POLL is like a POLL in that one server attempts to
       contact every other server -- but in a COMPLETE POLL it must
       receive a reply from all of them or the operation fails to com-
       plete.





Droms & Kinnear                                                [Page 12]


DRAFT                                                         April 1997


     o PUSH

       A PUSH operation is used when one server wants to send informa-
       tion to all of the other servers in the group.

     o DUMP

       A DUMP operation is used when one server sends information about
       every IP address binding it holds in its stable storage to
       another server.  This bulk transfer can be initiated by the
       server sending the information, or by the server who wishes to
       receive the information.

     o TRANSFER

       A TRANSFER operation is where one server engages in a
       request/reply dialog with a single other server, usually to
       transfer ownership of an IP address.

   Note that both PUSH and POLL involves operations to all of the
   servers in the group, while DUMP and TRANSFER are operations between
   two servers in the group.


3.3.  IP Address State

   Section 3.1 discussed the two kinds of IP address information that
   are communicated using this protocol.  The first of them, IP Address
   State, needs to be explained in more detail.


3.3.1.  IP Address State: Basic DHCP Protocol

   When an IP address is always controlled by a single DHCP server
   (implicit in the definition of DHCP in the current DHCP draft [1])
   the IP address is either in the BINDABLE state or the BOUND state.
   The following state diagram represents the states that an IP address
   may occupy based on the current DHCP draft.













Droms & Kinnear                                                [Page 13]


DRAFT                                                         April 1997


                        +-----------------+
                        |                 |
                        |    BINDABLE     |<-+
                        |                 |  |
                        +-----------------+  |
                                |            |
                                V            |
                        +-----------------+  |
                        |                 |  |
                        |     BOUND       |--+
                        |                 |
                        +-----------------+

      Figure 1:    Basic DHCP IP address state transition diagram



   When an IP address transitions from one of these states to the other,
   that transition must be recorded in the server's stable storage prior
   to the transition being "published" to any observer outside of the
   server.


3.3.2.  IP Address State: The Inter-server Protocol Extension

   The situation is more complex when multiple servers are managing the
   same set of IP addresses as required by this protocol.  Two new
   states are defined for an IP address.  One is called UNBINDABLE, the
   other EXPIRED.

   This is the state diagram for IP address state required by this pro-
   tocol:



















Droms & Kinnear                                                [Page 14]


DRAFT                                                         April 1997


                        +-----------------+
                        |                 |
                        |    UNBINDABLE   |<--+
                        |                 |   |
                        +-----------------+   |
                                |             |
                                V             |
                        +-----------------+   |
                        |                 |   |
                        |    BINDABLE     |   |
                        |                 |-->|
                        +-----------------+   |
                                |             |
                                V             |
                        +-----------------+   |
                        |                 |   |
                    +-->|     BOUND       |-->|
                    |   |                 |   |
                    |   +-----------------+   |
                    |           |             |
                    |           V             |
                    |   +-----------------+   |
                    |   |                 |   |
                    +---|    EXPIRED      |---+
                        |                 |
                        +-----------------+

      Figure 2:    Extended DHCP IP address state transition diagram
                   required for the Inter-server protocol.



   For every server which cooperates using this protocol, an IP address
   is in one of the following four states:

     o UNBINDABLE

       This state represents the default state for every IP address.
       Explicit action must be taken to move an IP address from this
       state into the BINDABLE state.  A COMPLETE POLL must be per-
       formed.

     o BINDABLE

       In this state, the IP address is available to be offered to a
       DHCP client, and if the client accepts the offer, it may be bound
       to that client.




Droms & Kinnear                                                [Page 15]


DRAFT                                                         April 1997


       An IP address is only BINDABLE by a single server at a time.  A
       server must know for precisely which IP addresses it has on its
       list of BINDABLE addresses.  A server does not know about any
       other server's list of BINDABLE addresses. (Although performance
       optimizations are possible where a server may develop hints about
       this information, they are not required).

       An IP address can move from the BINDABLE state into the BOUND
       state through the normal activity of the DHCP protocol where a
       server interacts with a client.

       A server can also transfer ownership of a BINDABLE IP address to
       another server upon request from that other server (and without
       any interaction beyond that with the other server).

     o BOUND

       An address that is BOUND is associated with a particular DHCP
       client, and usually is in use by that client (although it may
       have abandoned the lease on that IP address).  It may be termed
       BOUND to that client.

       When a DHCP client releases a lease on an IP address it moves
       into the UNBINDABLE state, but no explicit PUSH operation is
       required.

       When the lease time and any grace period implemented by a server
       both expire, then an IP address moves into the EXPIRED state.

       DISCUSSION:

            Many DHCP servers implement something called a "grace
            period", which is a period after the the lease on a binding
            expires that an IP address will not be offered to another
            DHCP client.  A lease which is in this "grace period" is
            still BOUND as far as the inter-server protocol is con-
            cerned.

     o EXPIRED

       An IP address is EXPIRED when it was BOUND and the term of the
       lease (and any implemented grace period) run out.  It may be
       termed EXPIRED to that client.

       An EXPIRED IP address may be made UNBINDABLE though a POLL of
       another server, or it may be moved back into the BOUND state by
       an REQUEST/INIT-REBOOT request from the previously bound client.




Droms & Kinnear                                                [Page 16]


DRAFT                                                         April 1997


3.4.  Overview of Server Operation

   This section will give a brief sketch of the IP address binding parts
   of the protocol (from the perspective of an already configured group
   of servers).  Many of the possible cases are not described here, and
   this section is not to be considered definitive. The definitive
   description of this information is in Section 7.1, and in the case of
   conflicts between this section and that one, the description in Sec-
   tion 7.1 will govern.


3.4.1.  DISCOVER

   Prior to the receipt of a DISCOVER message, each server should have
   built up a list of BINDABLE IP addresses -- for two reasons.  First,
   because a COMPLETE POLL is required to get a BINDABLE IP address, and
   a COMPLETE POLL may not be possible due to server failure at any
   given instant.  Second, because even if a COMPLETE POLL was possible
   it would generally take too long to do between a DISCOVER and an
   OFFER message.

   A server should offer a BINDABLE address to a client upon receipt of
   a DISCOVER message.

   There are no inter-server protocol activities required when a DIS-
   COVER is processed and an OFFER is returned to the client.


3.4.2.  REQUEST/SELECTING

   When a client accepts an offer by sending a SELECTING message, then
   the server updates its stable storage with the binding information
   and ACKs the client.  It must then perform a PUSH operation to push
   the binding information to all of the other servers (to which it can
   communicate at that time).


3.4.3.  REQUEST/INIT-REBOOT

   In the usual case where the server who created the binding for the
   requesting client managed to PUSH that information to the other
   servers, the receiving server will have (or be able to discover) the
   binding information for this client.  If this information can be ver-
   ified, then ACK the client -- else NAK it.







Droms & Kinnear                                                [Page 17]


DRAFT                                                         April 1997


3.4.4.  REQUEST/RENEWING

   Upon receipt of a RENEWAL message (which is unicast from the client
   to the server), it is expected that the server will have accurate
   information concerning the binding of the client.  If it does not,
   process the message like a REBINDING, below.  Given that the server
   has information sufficient to extend the lease, it should update its
   stable storage with the lease extension, and then ACK the client with
   the extended time.  Then it must perform a PUSH operation to the
   other servers with the updated binding information.


3.4.5.  REQUEST/REBINDING

   Upon receipt of a REBINDING message (which is broadcast from the
   client), the server will check to see if it has any information about
   the binding for this client.  There are several cases possible:

     1. Current information shows that this client owns the IP address.

        Extend the lease, update stable storage, ACK the client, and
        perform a PUSH with the information to the other servers.

     2. Current information shows that some other client is BOUND to
        this IP address.

        This is a problem. Make the IP address UNAVAILABLE (see Section
        10 for details).

     3. Current information says this IP address is UNBINDABLE.

        In this case, a server has probably created a binding and then
        failed to propagate the information to this server.   Perform a
        POLL operation to see if any communicating server has any better
        information.

        If information is returned, then move to the appropriate case in
        this list.

        If no information is returned, then extend the lease on the IP
        address, update stable storage, ACK the client, and PUSH the
        information to the other servers.


3.4.6.  Release

   When a release is received, if the client matches the binding infor-
   mation in the server, then update stable storage with the release,



Droms & Kinnear                                                [Page 18]


DRAFT                                                         April 1997


   set the IP address UNBINDABLE, and PUSH the information to the other
   servers.


3.4.7.  Expiration

   When a lease on an IP address expires, move the lease to the EXPIRED
   state and update stable storage with this information.  From now on,
   if some server performs a POLL operation to gather information about
   this IP address, make the IP address UNBINDABLE, update stable stor-
   age, and respond with the state of the IP address UNBINDABLE.


4.  Groups

   Fundamental to this protocol is the "group" of servers which are com-
   municating and with which the clients can communicate in order to
   provide a reliable DHCP service.


4.1.  Group Membership Definition

   Each "group" to which a server belongs is associated with a particu-
   lar set of address pools.  These address pools are those which exist
   on a single network segment (sometimes called a single "wire").

   An active server can be (and typically would be) a member of several
   groups simultaneously.  The groups to which a server attempts to
   become members are defined externally to this protocol.

   Each group has a unique 32bit group id which is used in the protocol
   messages of every type in this protocol.

   A server attempts to become a member of a particular group by using
   the configuration messages described below.  In addition, a server
   can remove another server from the group using these messages -- but
   in this case an external agent must ensure that the server being
   removed is truly inactive and not just partitioned.


4.2.  Group Specifier Definition

   Every protocol message (excluding only those mentioned later in this
   section) includes something called a "group specifier".  A group
   specifier consists of two 32 bit quantities:

     o Group ID




Droms & Kinnear                                                [Page 19]


DRAFT                                                         April 1997


       The group id is a 32 bit unsigned quantity which defines the
       group to which this message applies.  It is defined in the series
       of configuration messages below.  This group id applies to a set
       of address pools which exist on the same physical network.

       DISCUSSION:

          Just how does the first server in the group get selected?

          As well, just how does it select the group-id for the group?
          Group-id's don't have to be globally unique -- just unique
          amongst all of the servers who are connected using this proto-
          col.  But, this is pretty much the same thing.

          Possibly there is a way to figure out how to generate a group-
          id from the network numbers of the subnets contained in the
          group definition.

     o Group Sequence Number

       This 32 bit unsigned sequence number is incremented every time
       that the group moves into the proposal stage.  When it overflows
       beyond the 32 bit boundary, it will never increment back to zero,
       but will go to 1 instead.

       DISCUSSION:

          I've been told that there is a excellent and precise specifi-
          cation of a sequence number like this in the DNS RFC.  It
          should replace the paragraph above.

       This is the "generation number" of the group.

   A group specifier containing these two values is a part of every mes-
   sage in the inter-server protocol, except for the messages listed
   below:

     o    REQUEST-GROUPS

     o    REPLY-GROUPS

     o    REQUEST-GROUP-CONFIG

     o    REPLY-GROUP-CONFIG

     o    REQUEST-GROUP-MEMBERSHIP





Droms & Kinnear                                                [Page 20]


DRAFT                                                         April 1997


4.3.  Group Specifier Usage

   For every message sent which includes a group specifier, if the
   receiving server doesn't have a matching group sequence number in its
   current group specifier for that group, it will return an error: NAK-
   GROUP-SPECIFIER-MISMATCH.

   This error return will include its current group specifier, as well
   as the information that would be included in the REPLY-GROUP-
   MEMBERSHIP message (i.e. the list of servers currently in this group
   from the replying server's standpoint).

   It will also take additional action based on the relationship of the
   message's group sequence number to its current group sequence number.

     o  message group sequence number > server group sequence number

        In this case, the server sending the message has a "more up to
        date" version of the group than the receiving server.  The
        receiving server will drop the incoming message and return an
        error response as specified above, and then it will send a
        REQUEST-GROUP-MEMBERSHIP message to the server from which the
        message originated.  The REPLY-GROUP-MEMBERSHIP message which is
        returned will be used to update the server's group specifier and
        group definition.

        In the event that the current server is not a member of the
        group after that membership is updated by the REPLY-GROUP-
        MEMBERSHIP message, it will immediately cease to operate on all
        address pools associated with that group.

     o  message group sequence number < server group sequence number

        In this case, the server sending the message has a "less up to
        date" version of the group than the receiving server.  The error
        message the receiving server has returned contains the informa-
        tion necessary for the sending server to update its conception
        of group membership and retry the original packet.

   In this way, the most recent view of the membership of the group will
   eventually propagate throughout the group.


5.  Protocol Messages

   The various messages that make up the inter-server protocol are
   described in this section.  First, the overall structure of each mes-
   sage is described, and the the messages are described in two groups:



Droms & Kinnear                                                [Page 21]


DRAFT                                                         April 1997


   Address Information Messages, and Configuration Messages.

   The way the messages are used is explained in Sections 6 and 7.

5.1.  Message Structure

   All of the interserver messages have the following fields:

     o Group ID

       This is the group from the group specifier described in Section
       TBD.  A value of zero is not a legal group id and is used when no
       group id should be specified (i.e. for those few messages which
       don't have a group id).

     o Group Sequence Number

       This is the group sequence number from Section TBD.  It must be
       non-zero if the group id is non-zero.

     o Operation

       The operation is either a request or a reply, and there are a
       wide variety of each of them.  Possible operations are listed
       below:

       REQUEST-ADDRESS-INFORMATION | REPLY-ADDRESS-INFORMATION

       REQUEST-ADDRESS-INFORMATION-BINDABLE

       REQUEST-UPDATE-ADDRESS-INFORMATION | REPLY-UPDATE-ADDRESS-
       INFORMATION

       REQUEST-ADDRESS-INFORMATION-DUMP | REPLY-ADDRESS-INFORMATION-DUMP

       REQUEST-BINDABLE-ADDRESS | REPLY-BINDABLE-ADDRESS

       REQUEST-GROUPS | REPLY-GROUPS

       REQUEST-GROUP-CONFIG | REPLY-GROUP-CONFIG

       REQUEST-GROUP-MEMBERSHIP | REPLY-GROUP-MEMBERSHIP

       REQUEST-PROPOSE-GROUP-JOIN | REPLY-PROPOSE-GROUP-JOIN

       REQUEST-COMMIT-GROUP-JOIN | REPLY-COMMIT-GROUP-JOIN





Droms & Kinnear                                                [Page 22]


DRAFT                                                         April 1997


       REQUEST-PROPOSE-GROUP-LEAVE | REPLY-PROPOSE-GROUP-LEAVE

       REQUEST-COMMIT-GROUP-LEAVE | REPLY-COMMIT-GROUP-LEAVE

     o Result

       When the operation is a reply, the result is one of the follow-
       ing:

       ACK

       ACK-DATA

       NAK

       NAK-GROUP-SPECIFIER-MISMATCH-DATA


     o Data

       If there is any data for the operation, then it appears last.  It
       is possible from the Result of the operation to determine if
       there is any data.  For all of the results listed above, if they
       end in -DATA, then data appears in the data section.


5.2.  Address Information Messages

   The address information messages are used to exchange information
   about the state and binding of an IP address among the servers in the
   group.  The general content and usage of the binding data is first
   discussed, and following that the individual address information mes-
   sages are discussed.


5.2.1.  Binding Data and State Information

   When binding data is sent as part of an address information message,
   it contains the following information:

     o IP Address [ipaddr]

     o Expiration [int32] (delta from now)

     o Client ID [string]

     o MAC Address [string]




Droms & Kinnear                                                [Page 23]


DRAFT                                                         April 1997


     o Last Transaction [int32]

     o Last Transaction Time [int32] (delta from now)

     o Last Transaction Server [ipaddr]

   Each server must maintain as part of the binding information the
   "last transaction time", the "last transaction", and the "last trans-
   action server" associated with that binding.

   The last transaction time is the time at which the binding changed in
   response to a request (the last transaction) from the client.  The
   last transaction time is returned in an address information message
   as a number of seconds from "now".

   The possible last transactions are listed below.  This list is
   ordered by the precedence of the transactions and is used to help
   determine if a response to an address information message contains
   more recent information than that currently held by a server.

   The last transaction is one of the following:

     o DHCPREQUEST/SELECTING

     o DHCPREQUEST/REBINDING

     o DHCPREQUEST/INIT-REBOOT

     o DHCPREQUEST/RENEWING

     o DHCPRELEASE

     o EXPIRATION

   The IP address state information is transmitted as well, and it con-
   sists of one of the following states:


     o UNBINDABLE

     o BINDABLE

     o BOUND

     o EXPIRED






Droms & Kinnear                                                [Page 24]


DRAFT                                                         April 1997


5.2.2.  REQUEST-ADDRESS-INFORMATION | REPLY-ADDRESS-INFORMATION

   The REQUEST-ADDRESS-INFORMATION message contains a list of of all of
   the IP addresses for which a REPLY is requested.

   The REPLY-ADDRESS-INFORMATION message contains the binding data (see
   Section 5.2.1) for each IP address listed in the REQUEST.

   Additional detailed information describing the format and all possi-
   ble success and error returns of these messages is TBD.


5.2.3.  REQUEST-ADDRESS-INFORMATION-BINDABLE

   The REQUEST-ADDRESS-INFORMATION-BINDABLE message contains a list of
   of all of the IP addresses for which a REPLY is requested.  It is in
   the same format as the REQUEST-ADDRESS-INFORMATION message, but con-
   tains the additional information that the requester wishes to make
   the IP addresses listed BINDABLE if possible.

   A REPLY-ADDRESS-INFORMATION message (see above) is used to reply to
   this message.

   Additional detailed information describing the format and all possi-
   ble success and error returns of these messages is TBD.


5.2.4.  REQUEST-UPDATE-ADDRESS-INFORMATION | REPLY-UPDATE-ADDRESS-
INFORMATION

   The REQUEST-UPDATE-ADDRESS-INFORMATION message contains address bind-
   ing information (see Section 5.2.1) for every IP address for which an
   update is requested.

   Additional detailed information describing the format and all possi-
   ble success and error returns of these messages is TBD.


5.2.5.  REQUEST-ADDRESS-INFORMATION-DUMP | REPLY-ADDRESS-INFORMATION-
DUMP

   Detailed information describing the format and all possible success
   and error returns of these messages is TBD.








Droms & Kinnear                                                [Page 25]


DRAFT                                                         April 1997


5.2.6.  REQUEST-BINDABLE-ADDRESS | REPLY-BINDABLE-ADDRESS

   In the REQUEST-BINDABLE-ADDRESS message the requesting server must
   specify

     o The address pool in the group for which it wishes to acquire some
       BINDABLE addresses.

     o The number of number of BINDABLE addresses it is requesting.

     o The number of number of BINDABLE addresses it currently has for
       that address pool.

   Additional detailed information describing the format and all possi-
   ble success and error returns of these messages is TBD.


5.3.  Configuration Messages

   Configuration messages are used add a server to a group as well as to
   remove a server from a group.  A server must add itself to a group --
   it cannot be added by another server.  A server may be removed by any
   server in the group, including itself.

   DISCUSSION:

      As written, it is a requirement for a server to add itself to the
      group.  Is this a good idea? This prevents an external agent from
      adding a server to the group to which some existing group members
      could not communicate.

      Likewise, should an existing member of a group be required to
      remove a server from a group?  Again, as written, the answer is
      yes.  Of course, an external agent could become a member of the
      group (nothing requires it to be a DHCP server if it deals with
      the protocol messages successfully), remove another server from
      the group, and then remove itself from the group.

   In addition to changing the group membership, configuration messages
   are used to keep the various servers up to date with respect to the
   current membership of the group.


5.3.1.  REQUEST-GROUPS | REPLY-GROUPS

   Detailed information describing the format and all possible success
   and error returns of these messages is TBD.




Droms & Kinnear                                                [Page 26]


DRAFT                                                         April 1997


5.3.2.  REQUEST-GROUP-CONFIG | REPLY-GROUP-CONFIG

   Detailed information describing the format and all possible success
   and error returns of these messages is TBD.


5.3.3.  REQUEST-GROUP-MEMBERSHIP | REPLY-GROUP-MEMBERSHIP

   Detailed information describing the format and all possible success
   and error returns of these messages is TBD.


5.3.4.  REQUEST-PROPOSE-GROUP-JOIN | REPLY-PROPOSE-GROUP-JOIN

   Detailed information describing the format and all possible success
   and error returns of these messages is TBD.


5.3.5.  REQUEST-COMMIT-GROUP-JOIN | REPLY-COMMIT-GROUP-JOIN

   Detailed information describing the format and all possible success
   and error returns of these messages is TBD.


5.3.6.  REQUEST-PROPOSE-GROUP-LEAVE | REPLY-PROPOSE-GROUP-LEAVE

   Detailed information describing the format and all possible success
   and error returns of these messages is TBD.


5.3.7.  REQUEST-COMMIT-GROUP-LEAVE | REPLY-COMMIT-GROUP-LEAVE

   Detailed information describing the format and all possible success
   and error returns of these messages is TBD.


6.  Protocol Operations

   The protocol messages from the previous section can be combined to
   form the following, more complicated, operations:

     o POLL and COMLETE POLL

     o PUSH

     o DUMP





Droms & Kinnear                                                [Page 27]


DRAFT                                                         April 1997


     o TRANSFER

     o Determine the Available Groups

     o GROUP JOIN

     o GROUP LEAVE


6.1.  POLL and COMPLETE POLL

   In POLL operation, the exchange of REQUEST-ADDRESS-INFORMATION and
   REPLY-ADDRESS-INFORMATION messages is used by a server in order to
   determine if an IP address is in use by any other server, or to
   update its internal database with the most recent binding informa-
   tion.

   It will send a REQUEST-ADDRESS-INFORMATION message to every server in
   the group, and expect a REPLY-ADDRESS-INFORMATION message in response
   from each.  This can be done either serially, stepping through all of
   the servers in the group, or in parallel -- sending REQUEST-ADDRESS-
   INFORMATION messages to all of them at once.

   When COMPLETE POLL operation is used to move an address from the
   UNBINDABLE state into the BINDABLE state, the REQUEST-ADDRESS-
   INFORMATION-BINDABLE request is used. The REPLY-ADDRESS-INFORMATION
   message is still used as a reply.

   No address can be offered to a client until all servers in the group
   have been queried and responded.  All of the responses must have been
   ACK-DATA and the state of the IP addresses must have been UNBINDABLE.
   Once this operation is complete, the server can consider the IP
   address to be BINDABLE and must update its stable storage to that
   effect.

   Note that this operation would typically *not* be performed immedi-
   ately prior to making an offer to a client, but would be done in
   advance to build up a list of BINDABLE IP addresses that could be
   offered to clients.  The reasons for this are:

     1. It could take a fair amount of time to contact each DHCP server
        in the group to ask about the status of an address, and that
        would slow down the offer process.

     2. If *any* server in the group is down, this protocol cannot com-
        plete, and can never yield a positive answer.





Droms & Kinnear                                                [Page 28]


DRAFT                                                         April 1997


6.1.1.  PUSH

   This exchange of REQUEST-UPDATE-ADDRESS-INFORMATION and REPLY-UPDATE-
   ADDRESS-INFORMATION messages are used by one server to inform another
   server of the address binding information it has about a lease.

   The data part of the REQUEST-UPDATE-ADDRESS-INFORMATION message has
   the same form as the REPLY-ADDRESS-INFORMATION from the poll mode of
   this protocol, except that it is used to inform another server of
   updated information from the requester.

   The responding server will return an REPLY-UPDATE-ADDRESS-INFORMATION
   if the information sent in the REQUEST-UPDATE-ADDRESS-INFORMATION
   message was more recent than that available in its cache.  Prior to
   sending the ACK, it will update its stable storage with the new
   information.

   In the event that the responding server determines that it has more
   recent information than the requesting server (based on the algorithm
   in Section TBD above), it will reply with a REPLY-UPDATE-ADDRESS-
   INFORMATION message with a NAK-DATA which will also contain all of
   its latest information.  The requesting server -- which now is the
   recipient of a lot of information which it didn't anticipate --
   should update its stable storage with this latest information.  The
   requesting server is under no obligation to reply to the NAK message.

   DISCUSSION:

      Just how long should a server doing a PUSH of information try to
      get the information to the rest of the servers?  Since the entire
      protocol has been designed to allow "lazy update", then perhaps it
      is sufficient to try once or retry several times over less than a
      minute -- and then to stop trying.

      Actually, since the mismatch of group specifiers can at any time
      cause a packets to be dropped, whenever a NAK-GROUP-SPECIFIER-
      MISMATCH message is received, the sending server MUST retry the
      message that was sent after correcting its view of the group spec-
      ifier (and therefore the group definition).


6.2.  DUMP

   The push of all of the binding information for all IP addresses where
   the last transaction server is the sending server to another server
   can be triggered by a REQUEST-ADDRESS-INFORMATION-DUMP message sent
   to a server.  When a server receives a REQUEST-ADDRESS-INFORMATION-
   DUMP message, it will send a series of REQUEST-UPDATE-ADDRESS-



Droms & Kinnear                                                [Page 29]


DRAFT                                                         April 1997


   INFORMATION messages to the requester.  When it has completed the
   DUMP operation, it will send a REPLY-ADDRESS-INFORMATION-DUMP message
   with an ACK.



6.3.  TRANSFER

   The exchange of REQUEST-BINDABLE-ADDRESS and REPLY-BINDABLE-ADDRESS
   messages is used by a server in order to ask another single server
   for one of its BINDABLE addresses.  The address returned by the query
   must be BINDABLE by the responding server and, prior to this message
   being sent, must be set to be UNBINDABLE and recorded in that
   server's stable storage.

   This protocol exchange would typically be used by a server who ran
   out of available addresses to offer to new clients and could not gen-
   erate any new ones by using the COMPLETE POLL operation because:

     1. Some other server was down and so a COMPLETE POLL could not com-
        plete.

     2. While the COMPLETE POLL could complete, it could not yield any
        new addresses for allocation because all of them were currently
        either allocated to a client or already on the list of available
        addresses of other servers.


6.4.  Determine the Available Groups

   The first stage of becoming a server participating in the inter-
   server protocol is to determine the existing group id for each set of
   address pools for which participation in the inter-server protocol is
   desired.

   Assuming that a server has been provided or can discover the IP
   address of a server that is already in the group to which it wants to
   join, a server who wants to become a member of a group will send a
   REQUEST-GROUPS message to some server it thinks might belong to a
   group to which it wishes to join.

   Any server who receives a REQUEST-GROUPS message will reply with a
   REPLY-GROUPS message containing the set of group specifiers for every
   group to which it is a member.

   For each of the group specifiers specified in the REPLY-GROUPS mes-
   sage, the joining server will send a REQUEST-GROUP-CONFIG request to
   the server it is interrogating.   This message asks for the group



Droms & Kinnear                                                [Page 30]


DRAFT                                                         April 1997


   information for one group specifier.

   The response to the REQUEST-GROUP-CONFIG message will be a REPLY-
   GROUP-CONFIG message which will contain the latest group specifier,
   and the network number and subnet mask of every subnet associated
   with that group.

   From this information, the requesting server can determine if it
   wishes to participate in this group.


6.5.  GROUP JOIN

   There are two phases to involved in a server adding itself to a
   group.  The first is the proposal stage, and the second is the commit
   stage.


6.5.1.  GROUP JOIN -- Proposal Stage

   In the proposal stage, all of the servers in the group are synchro-
   nized by the joining server with respect to their current concept of
   group membership as well as the identity of the joining server.

   When a server decides to join a group, then it will issue a REQUEST-
   GROUP-MEMBERSHIP request, and the responding server will reply with
   REPLY-GROUP-MEMBERSHIP.  This message contains the latest group spec-
   ifier, along with the list of IP addresses that make up the group.

   The joining server must check to see that it is not already a member
   of this group before proceeding.

   The joining server now has the list of existing servers in the group,
   and has verified that it makes sense to be a member of this group.
   Now, it has to interact with each server currently in the group.

   It will send a REQUEST-PROPOSE-GROUP-JOIN request to every server in
   the group.  This message has the current group specifier in the mes-
   sage along with a revised group membership (i.e. the response from
   REPLY-GROUP-MEMBERSHIP with the addition of the joining server).

   Upon receipt of a REQUEST-PROPOSE-GROUP-JOIN request, if no existing
   proposal exists that has not timed out, a server will create a single
   "proposed" group specifier from the current group specifier by incre-
   menting the group sequence number by 1.   The creation of this pro-
   posed group specifier will inhibit the creation of another proposed
   group specifier for a 30 seconds.  The responding server will reply
   with REPLY-PROPOSE-GROUP-JOIN and an ACK.



Droms & Kinnear                                                [Page 31]


DRAFT                                                         April 1997


   If an existing proposal exists that has not timed out, the responding
   server will reply with REPLY-PROPOSE-GROUP-JOIN and a NAK-DATA.  This
   will include the same information as a REPLY-GROUP-MEMBERSHIP. (From
   this, the joining server can determine just who is attempting to join
   the group.)

   DISCUSSION:

      Clearly a deadlock situation can occur where two servers are try-
      ing to join a group at the same time, and each is working from
      "opposite ends" of the group.  In this case, where the joining
      server gets a failure from a REQUEST-PROPOSE-GROUP-JOIN message
      due to the existence of a valid proposal that has not timed out,
      then the joining server should backoff an amount of time that is
      based in part on its IP address before trying again.  The exact
      algorithm is TBD.

   This proposed group specifier will not be used in any messages until
   it moves to the accepted stage and become the current group specifier
   (see below for how it does that).

   If a second REQUEST-PROPOSE-GROUP-JOIN request is received from a
   server, that message will supersede the existing proposal and the
   timer will be reset.

   As the joining server cycles through the existing members of the
   group, it will be rationalizing the group specifiers among the group
   and the entire group's picture of the membership of the group.  If it
   encounters a server whose view of the group membership lags behind
   that of the server from which the joining server received its idea of
   group membership, then it will bring that server up to date.

   If, on the other hand, it encounters a server that has a more up to
   date version of the group membership than the one from which it is
   operating, it will have to update its idea of the group membership
   and then start the proposal sequence over.  All of the servers with
   which it has created proposals will be forced to update their view of
   group membership as part of this process.

   At the end of this process of proposal generation, all of the servers
   in the group share a common picture of both the group membership as
   well as the current proposal.


6.5.2.  GROUP JOIN -- Commit Stage

   The joining server must have started a timer when it sent out the
   first REQUEST-PROPOSE-GROUP-JOIN message, and if that timer has less



Droms & Kinnear                                                [Page 32]


DRAFT                                                         April 1997


   than time/2 time left on it, or the joining server SHOULD start over.

   Now, the joining server sends a REQUEST-COMMIT-GROUP-JOIN message
   (which contains the same information as the REQUEST-PROPOSE-GROUP-
   JOIN message) to the first server to which it sent the REQUEST-
   PROPOSE-GROUP-JOIN message.  That server must update its stable stor-
   age with the new group membership.  When that server has returned an
   REPLY-COMMIT-GROUP-JOIN message with an ACK, then the server has
   joined the group.  However, the joining server SHOULD also send
   REQUEST-COMMIT-GROUP-JOIN messages to all remaining servers in the
   group.

   Upon receipt of a REQUEST-COMMIT-GROUP-JOIN message, the current pro-
   posal is compared with the data in the REQUEST-COMMIT-GROUP-JOIN mes-
   sage, and if it compares successfully, the proposed new group becomes
   the current group and the group specifier is changed.  It returns
   REPLY-COMMIT-GROUP-JOIN and an ACK.

6.6.  GROUP LEAVE

   The process of removing a server from a group is largely identical to
   that used in a GROUP JOIN and described above.  It contains the same
   two phases -- "proposal" and "commit".  The messages used are:
   REQUEST-PROPOSE-GROUP-LEAVE -> REPLY-PROPOSE-GROUP-LEAVE, and
   REQUEST-COMMIT-GROUP-LEAVE -> REPLY-COMMIT-GROUP-LEAVE.

   The only other change from GROUP JOIN above is that when sending
   REQUEST-PROPOSE-GROUP-LEAVE messages and REQUEST-COMMIT-GROUP-LEAVE
   messages, while they are sent to all servers in the current group
   (including the server who is supposed to be leaving the group), if no
   reply from the server leaving the group is received, it is not con-
   sidered an error.

   The messages are sent to the leaving server in order to help preserve
   correct operation in the event that server is still operational.

   If a server receives a REQUEST-COMMIT-GROUP-LEAVE message from
   another server where the group defined does not include itself, it
   will cease operations on the address pools associated with that
   group.

   A server must be removed from a group by another server which is cur-
   rently a member of that group.








Droms & Kinnear                                                [Page 33]


DRAFT                                                         April 1997


7.  Protocol Actions

   This section gives the definitive details on the response a server
   should make to the receipt of various messages.  The messages are
   grouped into three sections:

     1. DHCP Client Messages and Events

        These are the messages that normally flow from a DHCP client to
        DHCP servers. This section explains the actions required by the
        inter-server protocol for each DHCP client message.

     2. Address Information Messages

        This section explains the required responses to Address Informa-
        tion messages.

     3. Configuration Messages

        This section explains the required responses to Configuration
        Messages.


7.1.  DHCP Client Messages and Events

   This section details the actions to be taken in response to the mes-
   sages that may be received by a DHCP server from a DHCP client.

   DISCUSSION:

      There is considerable commonality in the sections that describe
      the various DHCP client messages below.  Once the details have
      stabilized, it should be possible to compress the explanations.


7.1.1.  DISCOVER

   Prior to the receipt of a DISCOVER message, each server should have
   built of a list of BINDABLE IP addresses -- for two reasons.  First,
   because a COMPLETE POLL is required to get a BINDABLE IP address, and
   a COMPLETE POLL may not be possible due to server failure at any
   given instant.  Second, because even if a COMPLETE POLL were possi-
   ble, it would be unwise to require such an operation between a
   receipt of a DISCOVER message and the response of an OFFER to a
   client.

   There are several cases involved in processing a DISCOVER request,
   depending on the state of the requested IP address in the DISCOVER



Droms & Kinnear                                                [Page 34]


DRAFT                                                         April 1997


   request:

     o No specific IP address requested.

       Offer a BINDABLE address to the client.  Record that this address
       was offered in the cache memory of the server, but there is no
       need to update the stable storage of the server with any informa-
       tion.  The IP address continues to be BINDABLE.

     o Requested IP address is UNBINDABLE.

       If the IP address is UNBINDABLE, then perform a COMPLETE POLL
       operation in an attempt to make the IP address BINDABLE.  If the
       operation is successful, then respond as though the IP address
       were BINDABLE, below.  If the results of the attempt to make the
       IP address BINDABLE resulted in a discovery that the IP address
       is now BOUND, then respond as for BOUND, below.  Otherwise (i.e.
       the IP address is BINDABLE for some other server, or no a com-
       plete POLL was not possible) then respond as above for "No spe-
       cific IP address requested".

     o Requested IP address is BINDABLE.

       Offer the IP address to the client.  IP address remains BINDABLE.

     o Requested IP address is BOUND or EXPIRED.

       If the IP address is BOUND or EXPIRED to the requesting client,
       then offer it to the client.  Otherwise, respond as in "No spe-
       cific IP address requested", above.


7.1.2.  REQUEST/SELECTING

   The client uses a REQUEST/SELECTING to accept the offer of a lease
   made by a server.  When a server receives such a message, and where
   the server-id option reflects the IP address of that server, then if
   the IP address is in the following states the server should respond
   in the following way:

     o UNBINDABLE

       If the IP address is UNBINDABLE, then perform a COMPLETE POLL
       operation in an attempt to make the IP address BINDABLE.  If the
       operation is successful, then respond as though the IP address
       were BINDABLE, below.  If the results of the attempt to make the
       IP address BINDABLE resulted in a discovery that the IP address
       is now BOUND, then respond as for BOUND, below.  Otherwise (i.e.



Droms & Kinnear                                                [Page 35]


DRAFT                                                         April 1997


       the IP address is BINDABLE for some other server, or no a com-
       plete POLL was not possible) NAK the REQUEST.

     o BINDABLE

       If the IP address is BINDABLE and has been offered to the
       requester, then bind the IP address to the client, set the IP
       address BOUND, and update stable storage.  Then, ACK the client,
       and finally perform a PUSH operation of the binding information
       to the other servers.

     o BOUND or EXPIRED

       If the IP address is BOUND or EXPIRED to the requesting client,
       set the IP address to be BOUND, update the expiration time,
       update stable storage, and ACK the client.  Finally, perform a
       PUSH operation of the updated binding information to the other
       servers.

       If the IP address is BOUND or EXPIRED to some other client, then
       NAK the request.


7.1.3.  REQUEST/INIT-REBOOT

   The client uses a REQUEST/INIT-REBOOT to query the server (as part of
   the client boot process) to determine if a "remembered" binding is
   still valid.  If the requested IP address will be in one of the fol-
   lowing states:

     o UNBINDABLE

       If the IP address is UNBINDABLE, then perform a COMPLETE POLL
       operation in an attempt to make the IP address BINDABLE.  If the
       operation is successful, then respond as though the IP address
       were BINDABLE, below.  If the results of the attempt to make the
       IP address BINDABLE resulted in a discovery that the IP address
       is now BOUND, then respond as for BOUND, below.  Otherwise (i.e.
       the IP address is BINDABLE for some other server, or a complete
       POLL was not possible) NAK the REQUEST.

       DISCUSSION:

          This means that if a server creates a binding for a client and
          fails to PUSH the information to any other server prior to
          undergoing a server failure, and if the client is powered off
          prior to the time when it will issue a REBINDING message, it
          will not get back the same lease when it is powered back on.



Droms & Kinnear                                                [Page 36]


DRAFT                                                         April 1997


          The reasoning for this (and the difference from the REBINDING
          case below) is that in this case the server has no way to
          determine if the requested address in the INIT-REBOOT request
          is current or perhaps very old indeed.  In the REBINDING case
          the client is currently using the address, so the client at
          least believes that it is current and not in use by some other
          client.  In this case, however, no such assumption is possi-
          ble.

       In the case where a server which creates a binding fails prior to
       PUSHing the information about a lease to some other server, and
       the client which receives that binding makes it to a REBINDING
       request prior to either failing or being shutdown, it will get
       back the existing binding upon restart and INIT-REBOOT -- since
       the REBINDING will have caused a recovery of the binding informa-
       tion and that will have been distributed through a PUSH.

     o BINDABLE

       If the IP address is BINDABLE, then bind the IP address to the
       client, set the IP address BOUND, and update stable storage.
       Then, ACK the client, and finally perform a PUSH operation of the
       binding information to the other servers.

     o BOUND or EXPIRED

       If the IP address is BOUND or EXPIRED to the requesting client
       then set the IP address BOUND, update the expiration time, update
       stable storage, and ACK the client.  Finally, perform a PUSH
       operation of the updated binding information to the other
       servers.  If the IP address is BOUND or EXPIRED to some other
       client, then NAK the request.


7.1.4.  REQUEST/RENEWING

   Upon receipt of a RENEWAL message (which is unicast from the client
   to the server), it is expected that the server will have accurate
   information concerning the binding of the client.

   Perform the following actions if the IP address being renewed (i.e.
   the IP address in ciaddr) is in one of these states:

     o UNBINDABLE

       If the IP address is UNBINDABLE, then perform a COMPLETE POLL
       operation in an attempt to make the IP address BINDABLE.  If the
       operation is successful, then respond as though the IP address



Droms & Kinnear                                                [Page 37]


DRAFT                                                         April 1997


       were BINDABLE, below.  If the results of the attempt to make the
       IP address BINDABLE resulted in a discovery that the IP address
       is now BOUND, then respond as for BOUND, below.

       If the IP address is determined to be BINDABLE for some other
       server, then NAK the request, and set the IP address to be
       UNAVAILABLE since this likely represents a duplicate allocation
       of an IP address (see Section 10, Open Questions, for details).

       Otherwise NAK the request.

     o BINDABLE

       If the IP address is BINDABLE, then bind the IP address to the
       client, set the IP address BOUND, and update stable storage.
       Then, ACK the client, and finally perform a PUSH operation of the
       binding information to the other servers.

     o BOUND or EXPIRED

       If the IP address is BOUND or EXPIRED to the requesting client
       then update the expiration time, update stable storage, and ACK
       the client.  Finally, perform a PUSH operation of the updated
       binding information to the other servers.

       If the IP address is BOUND or EXPIRED to some other client, then
       NAK the request.

       Set the IP address to be UNAVAILABLE since this likely represents
       a duplicate allocation of an IP address (see Section 10, Open
       Questions, for details).


7.1.5.  REQUEST/REBINDING

   Upon receipt of a REBINDING message (which is broadcast from the
   client), the server will check to the state of the address requested
   for rebinding (i.e. the ciaddr).  There are several cases possible:

     o UNBINDABLE

       If the IP address is UNBINDABLE, then perform a COMPLETE POLL
       operation in an attempt to make the IP address BINDABLE.  If the
       operation is successful, then respond as though the IP address
       were BINDABLE, below.  If the results of the attempt to make the
       IP address BINDABLE resulted in a discovery that the IP address
       is now BOUND, then respond as for BOUND, below.




Droms & Kinnear                                                [Page 38]


DRAFT                                                         April 1997


       If the IP address is determined to be BINDABLE for some other
       server, then NAK the request.  Set the IP address to be UNAVAIL-
       ABLE since this likely represents a duplicate allocation of an IP
       address (see Section 10, Open Questions, for details).

       If no information is returned from any server that this IP
       address is anything but UNBINDABLE, then consider the address
       BOUND to this client, and proceed as in BOUND below.

       DISCUSSION:

          This is one of the key points of the inter-server protocol.
          In this case, a server has created a binding and then failed
          prior to telling any other server about that binding.  Eventu-
          ally, the client to whom that binding was made will attempt a
          REQUEST/REBINDING and contact a different server.  That dif-
          ferent server will be able to determine nothing about that IP
          address.  As far as can be determined, it is not BOUND to any
          client, and it is not BINDABLE for any other server.  In this
          restricted case, the server will renew the lease for the
          client and move the IP address into the BOUND state -- and
          PUSH this information to the rest of the servers.

          How can this be safe?  Well, remember that the client is
          presently using the IP address to make this request.  In this
          limited case where a server crashes before PUSHing information
          about a BOUND IP address to any other server, the client to
          whom the IP address is BOUND is the only running machine with
          any record of that binding.  In this case, the DHCP servers
          will accept that client's information about the binding as
          correct.

     o BINDABLE

       If the IP address is BINDABLE, then bind the IP address to the
       client, set the IP address BOUND, and update stable storage.
       Then, ACK the client, and finally perform a PUSH operation of the
       binding information to the other servers.

     o BOUND or EXPIRED

       If the IP address is BOUND or EXPIRED to the requesting client
       then update the expiration time, update stable storage, and ACK
       the client.  Finally, perform a PUSH operation of the updated
       binding information to the other servers.

       If the IP address is BOUND or EXPIRED to some other client, then
       NAK the request.



Droms & Kinnear                                                [Page 39]


DRAFT                                                         April 1997


       Set the IP address to be UNAVAILABLE since this likely represents
       a duplicate allocation of an IP address (see Section 10, Open
       Questions, for details).



7.1.6.  RELEASE

   When a RELEASE is received, an IP address will be in one of the fol-
   lowing states:

     o UNBINDABLE

       If the IP address is UNBINDABLE, then perform a POLL operation in
       an attempt to determine if this IP address is BOUND to any
       client.

       If the results of the POLL operation indicate that the IP address
       is now BOUND, then respond as for BOUND, below.

       If the IP address is determined to be BINDABLE for some other
       server, then NAK the request.  Set the IP address to be UNAVAIL-
       ABLE since this likely represents a duplicate allocation of an IP
       address (see Section 6, Open Questions, for details).

       Otherwise, ignore the RELEASE.

     o BINDABLE

       If the IP address is BINDABLE, ignore the RELEASE.

     o BOUND or EXPIRED

       If the IP address is BOUND or EXPIRED to the requesting client
       set the IP address to be UNBINDABLE, update stable storage, and
       PUSH the information to the other servers.


7.1.7.  Lease Period Expiration

   When the lease period on a BOUND IP address expires, set the IP
   address to be EXPIRED and update stable storage.


7.2.  Address Information Messages






Droms & Kinnear                                                [Page 40]


DRAFT                                                         April 1997


7.2.1.  REQUEST-ADDRESS-INFORMATION

   Build a REPLY-ADDRESS-INFORMATION message with binding information
   about each requested IP address.


7.2.2.  REPLY-ADDRESS-INFORMATION

   Compare the information received in the REPLY-ADDRESS-INFORMATION
   message with the information held in by this server.  Determine the
   "most recent" information in the following way:

   Compare the current most recent binding data (known as the current
   data) to binding data just received from the requesting server (known
   as the new data).  If the new last transaction time is:

     o  Later than the current time

        Replace the current data with the new data.

     o  Eearlier than the current time

        Leave the current data intact.

     o  within epsilon (value TBD) of the current time

        If the responding server for the new data matches the last
        transaction server in the new data and the last transaction
        server in the current data, replace the current data with the
        new data.

        Otherwise, compare the last transactions.  If they are the same,
        use the data that corresponds with the longest lease time.  If
        they are different, use the data whose corresponding last trans-
        action appears first in the list of possible last transactions
        in Section 5.2.1.

   DISCUSSION:

      This situation with multiple address information responses (or
      requests) with essentially identical transaction times would occur
      because several servers sent out a response to a broadcast REBIND-
      ING request, and the lease period was not configured the same on
      all of them.  There is absolutely no way to determine which of the
      ACK's the client accepted, and so using the information from the
      server which sent the latest lease expiration time is the only
      prudent course.




Droms & Kinnear                                                [Page 41]


DRAFT                                                         April 1997


7.2.3.  REQUEST-ADDRESS-INFORMATION-BINDABLE

   For each IP address in the message, if that IP address is currently
   EXPIRED, set it to UNBINDABLE and update stable storage prior to
   building the REPLY-ADDRESS-INFORMATION message.  Then build a REPLY-
   ADDRESS-INFORMATION message with binding information about each
   requested IP address.


7.2.4.  REQUEST-UPDATE-ADDRESS-INFORMATION

   Compare the binding data received in this message with the current
   binding information held by this server using the algorithm listed in
   REPLY-ADDRESS-INFORMATION, above.

   If the new information is more recent than the current information,
   replace the current information and return a REPLY-UPDATE-ADDRESS-
   INFORMATION message with an ACK.

   If the new information is not more recent than the current informa-
   tion, return the current information in a REPLY-UPDATE-ADDRESS-
   INFORMATION with a NAK-DATA.


7.2.5.  REPLY-UPDATE-ADDRESS-INFORMATION

   If the result is an ACK, do nothing.

   If the result is a NAK-DATA, compare the binding data received in
   this message with the current binding information held by this server
   using the algorithm in REPLY-ADDRESS-INFORMATION above.  If the new
   information is more recent than the current information, replace the
   current information.  Otherwise do nothing.


7.2.6.  REQUEST-ADDRESS-INFORMATION-DUMP

   Iterate though all of the IP addresses associated with this group,
   and send REQUEST-UPDATE-ADDRESS-INFORMATION messages to the request-
   ing server.  When this operation is complete, send a REPLY-ADDRESS-
   INFORMATION-DUMP with an ACK to the requesting server.


7.2.7.  REPLY-ADDRESS-INFORMATION-DUMP

   Mark the dump in progress complete.





Droms & Kinnear                                                [Page 42]


DRAFT                                                         April 1997


7.2.8.  REQUEST-BINDABLE-ADDRESS

   Build a REPLY-BINDABLE-ADDRESS message with TBD BINDABLE addresses.
   Set all of those addresses to be UNBINDABLE in this server, and prior
   to sending the message, update stable storage with the new state of
   these IP addresses.


7.2.9.  REPLY-BINDABLE-ADDRESS

   Add the BINDABLE IP addresses in the message to the list of BINDABLE
   IP addresses and update stable storage with this list.


7.3.  Configuration Messages


7.3.1.  REQUEST-GROUPS | REPLY-GROUPS

   Respond with a REPLY-GROUPS message.


7.3.2.  REQUEST-GROUP-CONFIG | REPLY-GROUP-CONFIG

   Respond with the group configuration in a REPLY-GROUP-CONFIG.


7.3.3.  REQUEST-GROUP-MEMBERSHIP | REPLY-GROUP-MEMBERSHIP

   Respond with the group membership in a REPLY-GROUP-MEMBERSHIP mes-
   sage.


7.3.4.  REQUEST-PROPOSE-GROUP-JOIN | REPLY-PROPOSE-GROUP-JOIN

   If there is an existing active proposal (i.e. one that has not timed
   out), reply with REPLY-PROPOSE-GROUP-JOIN and a NAK.  Note that there
   is only one active proposal per group per server -- and that it is
   used by both the JOIN and LEAVE messages.

   If there is no existing active proposal or if the existing active
   proposal is from the sending server of the REQUEST-PROPOSE-GROUP-
   JOIN, then create a new (or updated) proposal and start (restart) the
   timer for that proposal. In that new proposal, increment the group
   sequence number.






Droms & Kinnear                                                [Page 43]


DRAFT                                                         April 1997


7.3.5.  REQUEST-COMMIT-GROUP-JOIN | REPLY-COMMIT-GROUP-JOIN

   Make the outstanding proposal the current proposal.  Reply with a
   REPLY-COMMIT-GROUP-JOIN message and an ACK.


7.3.6.  REQUEST-PROPOSE-GROUP-LEAVE | REPLY-PROPOSE-GROUP-LEAVE

   If there is an existing active proposal (i.e. one that has not timed
   out), reply with REPLY-PROPOSE-GROUP-LEAVE and a NAK.  Note that
   there is only one active proposal per group per server -- and that it
   is used by both the JOIN and LEAVE messages.

   If there is no existing active proposal or if the existing active
   proposal is from the sending server of the REQUEST-PROPOSE-GROUP-
   LEAVE, then create a new (or updated) proposal and start (restart)
   the timer for that proposal. In that new proposal, increment the
   group sequence number.



7.3.7.  REQUEST-COMMIT-GROUP-LEAVE | REPLY-COMMIT-GROUP-LEAVE

   Make the outstanding proposal the current proposal.  Reply with a
   REPLY-COMMIT-GROUP-JOIN message and an ACK.


8.  IP Address State Transitions

   The possible states of an IP address were defined in Section 3.2.2,
   and the state transition diagram appears there.  The state transi-
   tions though which an IP address can move were discussed implicitly
   in Section 7 in the context of the receipt of DHCP messages from DHCP
   clients.  However, an explicit examination of the processing required
   of a server by this protocol on each of the state transitions will
   serve to highlight some important aspects of this protocol.

   The IP address state transitions are handled in the following way:

     o UNBINDABLE -> BINDABLE

       A fundamental point and guarantee of this state transition dia-
       gram is that for an IP address to move from the UNBINDABLE state
       (where it is not owned by any server) to the BINDABLE state
       (where it is owned by a single server) requires the server seek-
       ing to own the IP address to contact all of the other servers in
       the group.  It requires a COMPLETE POLL.




Droms & Kinnear                                                [Page 44]


DRAFT                                                         April 1997


       The server attempting to move an IP address from the UNBINDABLE
       to the BINDABLE state must ask every other server in the group if
       it believes that the IP address is currently UNBINDABLE.  If any
       server says that the IP address is either BINDABLE (i.e. it cur-
       rently owns the IP address) or BOUND (i.e. a client currently
       owns the IP address), then the server attempting to move the IP
       address from the UNBINDABLE to BINDABLE state MUST abandon the
       attempt.

       DISCUSSION:

          In addition (and this is important!) if the server attempting
          to move the IP address from the UNBINDABLE to the BINDABLE
          state fails to hear from some other server, then the attempt
          cannot complete.  This means that if a server cannot communi-
          cate with every other server (due to communications failure,
          transient server failure, or network partition) then this
          state transition cannot be made.

       Thus, all addresses in the UNBINDABLE state will stay in that
       state while any server in the group is out of communication with
       the group for any reason at all.

       Of course, the detailed description of the protocol suggests that
       a server build up a supply of BINDABLE IP addresses so that in
       the event of server failure it has BINDABLE addresses that are
       available to offer to new DHCP clients.

     o BINDABLE -> BOUND

       Once an IP address is BINDABLE it may be BOUND to a client
       through the normal actions of the DHCP protocol.  Once a server
       has received a DHCPREQUEST/SELECTING message from a client it can
       move the IP address into the BOUND state, update its stable stor-
       age, and reply with a DHCPACK message to the client.

       After the DHCPACK has been sent, the DHCP server MUST also
       attempt to update all servers in the group with information indi-
       cating that the IP address is now BOUND to a particular client.
       It must perform a PUSH operation with this information.

       DISCUSSION:

          In an ideal world, the server who created the binding would
          always succeed in updating all other servers in the group with
          the binding information.  Then, in the event that the binding
          server failed at some later time, another server to whom the
          client could broadcast would receive a DHCPREQUEST/REBINDING



Droms & Kinnear                                                [Page 45]


DRAFT                                                         April 1997


          request and could reply with updated binding information.

       However, there is obviously a window where a server can crash
       after sending a DHCPACK and prior to updating even one additional
       server.  This protocol has been designed so that not only is the
       process of updating all of the servers in the group with informa-
       tion concerning a new binding "lazy" (i.e.  performed after the
       actual binding is made), but also unnecessary for correct opera-
       tion.  The protocol only requires that a server try to update the
       other servers -- not that it succeed at updating even one server.

       The protocol accomplishes this by allowing a server to respond to
       a DHCPREQUEST/REBINDING message from a client without any infor-
       mation having been propagated from the server who created the
       binding.  Thus, a server who receives a rebinding request for an
       IP address about which it has no information must check with all
       available servers in the group, but in the absence of information
       to the contrary arriving within a relatively short timeout
       period, the server should respond to the rebinding request with
       an extension of the existing lease on the IP address.

     o BINDABLE -> UNBINDABLE

       A server can relinquish an IP address in the BINDABLE state that
       it owns simply by responding to requests for information about
       the IP address as if it were UNBINDABLE.  No explicit action need
       be taken other than to respond correctly to POLL operations from
       other servers.

     o BOUND -> UNBINDABLE

       In order for an IP address to move from the BOUND to the UNBIND-
       ABLE state, client that owns the IP address (i.e. to which it is
       BOUND) must send a DHCPRELEASE message.  In this case, the
       receiving server (which may or may not be the server who created
       original binding) will update its stable storage with information
       that the IP address is not currently BOUND by any client.  It
       should then transmit this information to all other servers to
       which it can communicate at that time by performing a PUSH opera-
       tion.

       In the event that the server fails to update any other server
       with the new information about the IP address prior to undergoing
       some failure, then the worst that will happen is that the other
       servers will believe that an IP address is in the BOUND state
       when it need not be.  Ultimately the lease on the IP address will
       expire.




Droms & Kinnear                                                [Page 46]


DRAFT                                                         April 1997


     o BOUND -> EXPIRED

       Any server which has information concerning a BOUND IP address
       may determine that the lease on the IP address has expired, and
       after an appropriate grace period has elapsed, that the IP
       address should be EXPIRED.

     o EXPIRED -> UNBINDABLE

       In this case, all the server need do is to respond to request for
       information on this IP address in such a way that it is clear
       that (as far as this server knows) no client is using the IP
       address.  If any server asks for information concerning this IP
       address, then the receiving server should set the IP address to
       be UNBINDABLE, update its stable storage, and respond to the
       requesting server.

     o EXPIRED -> BOUND

       If a server receives a message from a client and the IP address
       is EXPIRED, but was last BOUND to that client, then the IP
       address can be moved back into the BOUND state.  This is possible
       because no other server can have attempted to make this IP
       address BINDABLE.  If it had, the IP address would not be in the
       EXPIRED state anymore, but in the UNBINDABLE state (see the
       EXPIRED -> UNBINDABLE transition above).


9.  Server Initialization

   With regard to the inter-server protocol, there are two distinct
   forms of server initialization.  Remember that group membership is
   persistent -- i.e. saved in stable storage.  Given this, whenever a
   server initializes itself, it either has a record in its persistent
   storage of being a member of a group or it doesn't.  Each of these
   cases is described below.

9.1.  No record of any group membership.

   Use the technique in Section 6.4, Determining the Available Groups,
   determine the groups to which the server should belong.

   Use the GROUP JOIN technique from Section 6.5 to join the appropriate
   groups.

   Then use the address information messages to build up a list of BIND-
   ABLE IP addresses, one for each address pool in each group.




Droms & Kinnear                                                [Page 47]


DRAFT                                                         April 1997


   If insufficient IP addresses can be obtained using that technique,
   use the TRANSFER technique from Section 6.3 to acquire some BINDABLE
   IP addresses from some other server in the group.

   DISCUSSION:

      Just how many IP addresses should a server acquire?  First, it
      should be configurable for each server.  Second, it appears that
      all of the addresses should be acquired by one server or another.
      In any of the possible failure modes, it is better that the
      addresses not be UNBINDABLE -- since during transient server fail-
      ure the UNBINDABLE addresses will stay that way.

      The server should then initiate a DUMP operation (see Section 6.2)
      from each server in the group.


9.2.  The server believes that it is currently the member of a group.

   It is assumed that the list of groups to which this server belongs is
   held in stable storage.  Thus group membership is persistent.

   When a server is restarted for any reason, for all of the groups for
   which it believes that it is currently a member, it should send
   REQUEST-GROUP-MEMBERSHIP messages to the a server in that group.  It
   should use the reply to determine if it is or is not a member of that
   group, and take the appropriate action:

     o Still a member of the group

       The server should update its group specifier.

       It should revalidate the list of BINDABLE leases owned by this
       server if possible using a series of  COMPLETE POLL operations
       (see Section 6.1).  If responses cannot be obtained from all of
       the other group members, then assume that the current list of
       BINDABLE leases is all right.

       For every IP address where the current server is listed as the
       "last transaction server" in the state, use a POLL operation to
       determine the latest information about that IP address.

       Request a DUMP operation from each server in the group.  This
       will cause each server to update the requester with address
       information messages for all bindings for which that server is
       listed as the last transaction server.





Droms & Kinnear                                                [Page 48]


DRAFT                                                         April 1997


     o Not currently a member of the group

       The server should drop its current list of BINDABLE IP addresses
       associated with this group.

       The server should verify that the group is still the same group,
       i.e.  that it still is associated with the same subnets.  If it
       is, it should rejoin the group.

       It should rebuild its list of BINDABLE IP addresses using a COM-
       PLETE POLL operation.

       Request a DUMP operation from each server in the group.  This
       will cause each server to update the requester with address
       information messages for all bindings for which that server is
       listed as the last transaction server.


10.  Open questions

   The following open questions set off by the "*" character remain from
   the original draft:  draft-ietf-dhc-interserver-00.txt.  Comments
   have been added in square brackets [].  Additional open questions new
   to draft:  draft-ietf-dhc-interserver-01.txt are listed with the "o"
   character.


     * Are these the only cases in which binding information may become
       out of date?

     * Are these solutions correct?

     * INIT case needs EXISTING/NEW binding option [done]

     * Because of the "lazy synchronization" of DHCP servers, it is pos-
       sible that some servers may know about an existing binding while
       others do not.  As an optimization, DHCP clients should be able
       to select between existing bindings and new bindings in DHCPOFFER
       messages from servers.  A new option could be defined to indicate
       to the client whether a DHCPOFFER message represents a new or an
       existing binding.

       [A great idea, but requires client changes to be really effec-
       tive. Still, no reason not to put it in the servers now.]

     * Each server must know all other servers.





Droms & Kinnear                                                [Page 49]


DRAFT                                                         April 1997


       Requiring each server to know about every other server imposes
       additional administrative overhead in the configuration of DHCP
       servers.  However, this configuration overhead is probably mini-
       mal relative to any other configuration required for DHCP
       servers.

       [The configuration messages provide a step towards an answer
       here.]

     * Each server must contact all other servers before reassigning an
       address.

       [This is fundamental if we wish to use the "lazy synchronization"
       above -- you can't get one without the other.]

       There is a potential issue here in which no new DHCP clients can
       be configured if any of the DHCP servers cannot be contacted.
       Servers can mitigate this problem by maintaining a list of pre-
       checked addresses that can be allocated without contacting all
       other servers at the time of address allocation.

       The protocol may need additional definition of specific actions
       on the part of DHCP servers in response to situations in which a
       server cannot contact all other servers.  [Added a lot of these
       in this draft.]

     * Servers cooperating to achieve "fair" distribution of available
       addresses.

       The protocol may need additional mechanisms or definition of
       default behavior through which servers cooperate among themselves
       to ensure that each has a sufficient pool of prechecked-addresses
       on each network.

       [Not yet addressed, and needs work.]

     * User intervention in case of database incoherency.

       Fixing the collective database on the DHCP servers in case of a
       problem could be a *real* nightmare.

     * Potential deadlock in checking address - suppose two servers
       check the same address for reassignment simultaneously?

       [Needs some work, but easily solved by a bit of work in the
       address information messages specification.]





Droms & Kinnear                                                [Page 50]


DRAFT                                                         April 1997


     * Potential configuration for new server?

       One ancillary use of the inter-server protocol might be in con-
       figuring new DHCP servers.  Suppose the inter-server protocol
       were extended to allow download of a server's configuration file
       and to allow addition of a new server to the list of DHCP
       servers.  A new server might be configured by simply giving it
       the address of an existing server.  The new server could then
       download a list of all other known servers, the pool of candidate
       addresses, any special configuration information (e.g., vendor
       class information) and the existing bindings.  The new server
       could also announce itself to all of the other existing servers.

       [Pieces of this are in the current draft, principally in the con-
       figuration messages.  At this stage, a server can figure out
       which groups correspond with which subnets -- and can therefore
       determine which groups it wishes to join.  It must have a priori
       configuration information about the allocatable IP addresses for
       each subnet, and all other configuration information.

       Downloading configuration files would not be a great idea for
       servers which don't use configuration files.   I do believe that
       we could easily extend the configuration messages to support
       information about ranges of addresses in each subnet, and go a
       long way toward not only making the protocol more flexible but
       also more correct.]

     * DHCP server maintenance

       There is likely an opportunity for the development of a server
       management tool that would download the database information from
       all servers and check for conflicts/inconsistencies such as
       assignment of an IP address to multiple clients, bindings that
       are not replicated across all servers, bindings that have incon-
       sistent lease expiration times, etc.

     o Group-id selection.

       The group-id's for various groups need to be sufficiently unique
       that no server will ever be a member of two groups with the same
       group-id.  No mechanism is provided yet in this protocol to gen-
       erate group-id's which conform to this requirement.

       Possibly a group-id can be synthesized in some manner to ensure
       that they conform to this requirement.

     o The original draft discussed the requirement for each server to
       have a synchronized clock using available time synchronization



Droms & Kinnear                                                [Page 51]


DRAFT                                                         April 1997


       protocols.  That requirement has been removed in this draft, and
       in its place all times are sent in "seconds from now" as a signed
       32 bit number.  There is clearly a bit of additional complexity
       required to do this, but I have been so impressed at how well
       DHCP works with "relative" instead of "absolute" time that I felt
       the complexity of using relative time worth it (since using syn-
       chronized time is not without its own complexities).

     o There is clearly a need to batch multiple updates, and litle men-
       tion has yet been made as to how to achieve that batch operation.

     o What should the actual packet format look like?

       There is nothing in this draft which specifies the details of the
       packet format.  One approach would be to format the packets as a
       small delta from the current DHCP packets, and use presently one
       or more undefined dhcp-message-type values for the different pro-
       tocol messages.  The data in the packets could be easily format-
       ted as options.  All current DHCP servers have parsers built in
       which can handle the current packet formats, and so why invent
       yet another format when this one will do as well?

     o Do we really need TCP?

       Certainly the initial focus on this protocol has all of the
       servers using TCP to each other.  Within the confines of the
       actual draft I have not altered that approach, although I feel
       that UDP packets would be as effective.  The gains from having a
       connection "always up" seem to me to be outweighed by the diffi-
       culty of keeping a connection "always up" in the face of tran-
       sient server failures.  With proper care, idempotent UDP packets
       can solve the problems this protocol needs to solve with no addi-
       tional complexity beyond retransmission timeouts -- which are
       needed anyway if a server is down and the TCP connection is bro-
       ken.

     o UNAVAILABLE IP addresses

       There are several cases where a server can determine that some
       sort of serious error has occurred, and apparently an IP address
       is in an inconsistent state.  In these cases, the server should
       make the IP address UNAVAILABLE -- i.e. no other server should be
       able to operate on it.  Just what is necessary to make this hap-
       pen?  Could it be a passive response to address information mes-
       sages, or must it involve a complete push to all of the other
       servers, and a new IP address state?





Droms & Kinnear                                                [Page 52]


DRAFT                                                         April 1997


11.  Acknowledgments

   Many of the ideas in this proposal are due to Jeff Mogul, Greg Min-
   shall, Rob Stevens, Walt Wimer, Ted Lemon and the DHC working group.
   Thanks to all who have contributed their ideas and participated in
   the discussion of the inter-server protocol.

   At American Internet, Brad Parker and Mark Stapp have been key con-
   tributors to the design discussions that have resulted in our contri-
   butions to the this draft.  They have each invested many hours of
   work in this protocol.


12.  References


     [1] Droms, R., "draft-ietf-dhc-dhcp-09.txt", Work in progress,
         December 1996.


13.  Security Considerations

   Minimal security would be provided by configuring every server in a
   group with the IP addresses of the allowable servers that could ever
   join that group.

   Other, more powerful security approaches are TBD.


14.  Author's information

      Ralph Droms
      Computer Science Department
      323 Dana Engineering
      Bucknell University
      Lewisburg, PA 17837

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


      Kim Kinnear
      American Internet Corporation
      4 Preston Ct.
      Bedford, MA  01730-2334

      Phone: (617) 276-4587
      EMail: kinnear@american.com



Droms & Kinnear                                                [Page 53]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/