Network Working Group R. Droms INTERNET DRAFT Bucknell University November 1996 Expires May 1997 An Inter-server Protocol for DHCP 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., "