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]
