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

Versions: 00 01 02

Network Working Group                                           R. Droms
INTERNET DRAFT                                       Bucknell University
                                                           November 1996
                                                        Expires May 1997


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

Status of this memo

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material 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
   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.

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



Droms                                                           [Page 1]


DRAFT              An Inter-server Protocol for DHCP       November 1996


   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.  In section 2, this document outlines a proposal for a set
   of functions provided by an inter-server protocol.  Section 3
   describes ways in which DHCP servers will use the protocol to
   coordinate assignment, release and expiration of bindings to
   guarantee consistent interactions between DHCP servers and clients.
   Section 4 poses some open questions about the protocol as described
   below.

   1.1 Terminology

   This document uses the following terms:

   o "DHCP client"

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

   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.

2. Protocol description

   The DHCP inter-server protocol includes the following functions:










Droms                                                           [Page 2]


DRAFT              An Inter-server Protocol for DHCP       November 1996


   1. Distribution of address assignment information
   2. Distribution of lease release (as a result of DHCPRELEASE)
      information
   3. Reallocation of available addresses
   4. Query about whether a specific address is "in use"

   The protocol uses TCP between pairs of servers.  Each server is
   configured with a list of all other servers.  The servers are also
   all configured with a pool of candidate IP addresses that may be
   assigned dynamically to DHCP clients.  Periodically or on demand, a
   server may contact one, some or all other DHCP servers to perform
   DHCP inter-server protocol functions.  All DHCP servers have
   synchronized clocks (e.g., using NTP).  Through these protocol
   sessions between pairs of servers, a server can inform other servers
   about new bindings or about lease extensions on existing bindings,
   can inform other servers about bindings that have been released and
   can search for IP addresses that are currently unused.

   The collection of bindings managed by the DHCP servers is essentially
   a distributed database.  The servers can use the inter-server
   protocol to synchronize changes to the database and ensure coherency
   among the individual servers.  However, latency in the
   synchronization process means that the bindings on some servers may
   be stale.  Potentially, clients could receive invalid configuration
   information based on these stale bindings.  The next section reviews
   specific cases in which bindings may change and ways in which servers
   can use the inter-server protocol to ensure that clients always
   receive valid configuration information.

3. Protocol actions

   There are several DHCP protocol interactions that can change the
   address assignment information managed by DHCP servers:


   * New address assignment
   * Lease extension
   * Lease expiration
   * RELEASE

   In the remainder of this section, each case is discussed along with
   inter-server protocol actions to avoid passing invalid configuration
   information to clients.








Droms                                                           [Page 3]


DRAFT              An Inter-server Protocol for DHCP       November 1996


3.1 New address assignment

   When a DHCP server assigns a new IP address to a DHCP client (as part
   of an INIT-state transaction), the server adds that assignment to its
   local database of bindings.  The server must use an IP address that
   is available for assignment and must inform other DHCP servers about
   the newly created binding.  The assigning server uses the DHCP
   inter-server protocol to contact each of the other servers to
   distribute the information about the new binding.

   To identify an IP address that may be used assigned to the new
   client, the server picks an address from the pool of assignable
   addresses (as described in section 2) that is not currently in the
   server's list of bindings.  The server then contacts each of the
   other servers to query about the status of that address.  If any of
   the other servers respond that the address is "in use", the querying
   server identifies a new candidate address and repeats the process. If
   none of the other servers respond that the address is "in use", the
   querying server may assign the address to the DHCP client.

   DISCUSSION:

      As an optimization, information about new bindings need not be
      forwarded to other DHCP servers immediately and can be distributed
      periodically as a batch update.  The primary drawback to delayed
      propagation of new bindings is the lack of redundancy until the
      new bindings are distributed to other servers.  Even with delayed
      propagation, the required check of candidate addresses will
      prevent assignment of any IP address to different DHCP clients by
      multiple servers.

      As an optimization, DHCP servers may maintain a list of available
      addresses that have been checked with other DHCP servers.  When
      queried about the availability of an address, a server that has
      such a list of previously checked addresses must either reply that
      the addresses are "in use" or must remove the address from its
      list and reply that the address is "not in use".

      DHCP servers may also request available addresses from other
      servers.  These addresses would be supplied (if available) from a
      list of available addresses on the remote server.

      A server MUST successfully contact all other servers before
      reassigning an address.







Droms                                                           [Page 4]


DRAFT              An Inter-server Protocol for DHCP       November 1996


3.2 Lease renewal

   A DHCP server may choose to extend the lease of a DHCP client in
   response to a DHCPREQUEST message from a client in INIT-REBOOT state.
   This lease extension is propagated by the extending server to other
   servers using the DHCP inter-server protocol.  The details of this
   propagation require a little care in their design; the servers must
   agree on the expiration date currently held by the client.  Thus, the
   extending server must check with all other servers to determine the
   lease expiration time that was issued last by any server; that last
   expiration must be propagated to all other servers.

   DISCUSSION:

      The delay between lease extension and distribution to other
      servers leaves a window in which some servers may have different
      lease expiration times for a particular binding.  During that
      window, a client may reboot and get an old lease expiration date
      or a server may determine that a lease has expired (based on an
      old lease expiration date) after it has been extended on another
      server.

      If a client receives an old expiration date (that has not been
      extended), the client will reset its expiration date to that old
      value.  If the lease is sufficiently close to expiring, the client
      will use DHCP to extend the lease.  Even if this extension takes
      place on a different server, the servers will eventually converge
      to agree on the expiration time last issued to the client.

      A server may determine that a lease has expired prior to
      notification of the extension of that lease.  If the server takes
      no explicit action other than to delete the expired binding from
      its database, the extended lease will propagate to the server from
      the extending server.  The following section describes lease
      expiration in more detail.

3.3 Lease expiration

   When a DHCP server determines that the lease on a binding has
   expired, the server simply drops that binding from its database and
   takes no other explicit action.  The address in that binding may be
   recovered at a later date, if needed, and will be checked according
   to the rules in section 3.1 before reassignment.

   DISCUSSION:

      If a server takes no other specific action than to delete the
      binding from its database, premature expiration (expiration based



Droms                                                           [Page 5]


DRAFT              An Inter-server Protocol for DHCP       November 1996


      on a stale expiration date) will have no effect.  The extending
      server will distribute the information about the lease extension
      to the other servers, synchronizing all of the other servers to
      the new expiration date.

      The only potential problem arising from premature expiration is
      reassignment of an address that is still in use.  The rules for
      checking an address prior to reassignment guarantee that no other
      server will have a binding for reassigned address and that the
      address is not in use prior to reassignment.

3.4 Lease RELEASE

   When a DHCP server receives a DHCPRELEASE from a client, the server
   contacts all other servers to distribute the release notification.
   The other servers discard the lease from their databases.  The
   address will be recovered, if needed, for reassignment according to
   the rules in section 3.1

   If the RELEASEing server discovers any other server that has
   responded to a DHCPREQUEST message from the DHCP client for the
   RELEASEd address after the RELEASE message was received, the client
   is still using the address and the lease is still valid.  In this
   case, the server that has responded to the DHCPREQUEST message
   retains the binding and distributes that binding to all of the other
   servers.

   DISCUSSION:

      The case discussed in the second paragraph is actually a DHCP
      protocol error on the part of the client; after issuing a
      DHCPRELEASE, the client MUST go to INIT state and request a new
      address.  However, as there is no mechanism in DHCP through which
      the server can inform the client of such an error, the servers
      must accommodate the error and maintain the consistency of the
      binding database.

4. Open questions


   * 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

     Because of the "lazy synchronization" of DHCP servers, it is



Droms                                                           [Page 6]


DRAFT              An Inter-server Protocol for DHCP       November 1996


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

   * Each server must know all other servers

     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 minimal
     relative to any other configuration required for DHCP servers.

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

     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.

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

     The protoocol 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.

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

   * Potential configuration for new server?

     One ancillary use of the inter-server protocol might be in
     configuring new DHCP servers.  Suppose the inter-server protocol
     were extended to allow download of a server's configuration file



Droms                                                           [Page 7]


DRAFT              An Inter-server Protocol for DHCP       November 1996


     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.

   * 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 inconsistent
     lease expiration times, etc.

5. Acknowledgments

   Many of the ideas in this proposal are due to Jeff Mogul, Greg
   Minshall, 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.

6. References

   [1] Droms, R., "<draft-ietf-dhc-dhcp-07.txt", Work in progress,
       November 1996.

7. Security Considerations

   Not addressed - but needed, I suspect.

7. Author's information


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

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







Droms                                                           [Page 8]


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