Network Working Group Greg Rabil
INTERNET DRAFT Mike Dooley
Obsoletes: draft-ietf-dhc-failover-00.txt Arun Kapur
Quadritek Systems
Ralph Droms
Bucknell University
February 1998
Expires August 1998
DHCP Failover Protocol
<draft-ietf-dhc-failover-01.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
DHCP [RFC 2131] allows for multiple servers to be operating on a
single network. Some sites are interested in running multiple servers
in such a way so as to provide redundancy in case of server failure.
In order for this to work reliably, the servers must maintain a
consistent database of the lease information. This implies that
servers will need to coordinate any and all lease activity so that
this information is synchronized in case of failover.
This document defines a protocol to provide this synchronization
between two servers. One server is designated the "primary" server,
the other is the "secondary" server. Additionally, this document
describes a protocol for the automatic transfer of control from the
primary to the secondary in the case of failure (failover), as well
Rabil, Dooley, Kapur, Droms [Page 1]
DRAFT DHCP Failover Protocol November 1997
as the re-establishment of control by the primary server.
1.0 Introduction
As the use of DHCP servers in networked environments grows, the
dependency of those networks on the DHCP server increases. This is
particularly true of the hosts that receive their configuration
information from the DHCP server. Therefore, it is very important to
be able to provide reliable, continuous availability of DHCP
services.
This specification describes a protocol to support automatic failover
from a primary to its secondary server. The failover mechanism
allows the secondary server to perform DHCP actions while the primary
is down. Additionally, the protocol defines how control is passed
back to the primary when it becomes operational again.
In providing the specification for the failover, the protocol
specifies how to guarantee reliable delivery of changes to the
secondary. This is required to synchronize the secondary's lease
data with that of the primary. The protocol further specifies a
mechanism for determining the state (operational or not) of the
primary server. The secondary will be able to automatically service
DHCP requests upon failover. When the primary server becomes
available again, the secondary will convey any changes that occurred
since the time of failover back to the primary prior to the primary
becoming operational.
1.1 Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119].
1.2 DHCP Terminology
This document uses the following terms:
o "DHCP client" or "client"
A DHCP client is an Internet host using DHCP to obtain
configuration parameters such as a network address.
o "DHCP server" or "server"
A DHCP server is an Internet host that returns configuration
Rabil, Dooley, Kapur, Droms [Page 2]
DRAFT DHCP Failover Protocol November 1997
parameters to DHCP clients.
o "primary server" or "primary"
A DHCP server configured to provide primary service to a set of
DHCP clients.
o "secondary server" or "secondary"
A DHCP server configured to act as a backup to a primary server;
the secondary answers requests from DHCP clients only if its
primary is unable to respond.
o "bindings database"
The collection of bindings managed by a primary and secondary.
1.3 Requirements for this protocol
The following requirements must be met by this protocol.
o Implementations of this protocol must work with existing DHCP
clients.
o Implementations of this protocol must work with existing BOOTP
relay agents.
o The protocol must provide failover redundancy between servers that
are not located on the same subnet.
1.4 Goals of this protocol
o Provide for continued service to DHCP clients through an automated
mechanism in the event of failure of the primary server.
o Minimize the possibility of assigning an IP address to two
different clients simultaneously.
o Minimize any need for manual administrative intervention.
o Introduce no additional delays in server response time as a result
of inter-server communication.
o Share IP address ranges between primary and secondary servers;
i.e., impose no requirement that the pool of available IP addresses
be divided between servers.
o Continue to meet the goals and objectives of this protocol in the
Rabil, Dooley, Kapur, Droms [Page 3]
DRAFT DHCP Failover Protocol November 1997
event of server failure or network partition.
o Provide graceful reintegration of full protocol service after
server failure or network partition.
o Allow for one computer to act as a secondary server for multiple
primary servers. Where possible, primary and secondary servers
should be "logical" servers and not necessarily physical computers.
1.4 Limitations to this protocol
o Under normal operation, only one server at a time will service DHCP
client requests; this protocol provides reliability through
redundancy but not load balancing.
o This protocol provides only one level of redundancy through a
single secondary server for each primary server.
o Under certain combinations of failures, both a primary and
secondary server may be active and assign the same IP address to
different DHCP clients.
DISCUSSION:
The details of this failure mode are discussed in section X. In
summary, for duplicate address allocation to occur, a network
partition must occur that prevents the servers from exchanging
messages and a subnet partition must occur so that some DHCP
clients on the subnet can only reach the server while other
clients on that same subnet can only reach the secondary.
o Primary and secondary servers require external configuration to
acquire server addresses, available IP address ranges and other
client configuration information.
DISCUSSION:
This protocol assumes external configuration of primaries and
secondaries; e.g., through an independent internet configuration
management tool.
o The primary and secondary server must synchronized before an
address with an expired lease can be reassigned to a new client.
o The primary and secondary servers must halt all DHCP transaction
processing while resynchronizing after a system failure.
Rabil, Dooley, Kapur, Droms [Page 4]
DRAFT DHCP Failover Protocol November 1997
DISCUSSION:
Presumably, unless the primary and secondary servers have been
out of communication for an extended period, the servers will
have only a small amount of information to exchange. Thus, the
time during which the servers are not available to answer DHCP
requests will be minimal and should be bridged by the normal
DHCP client retransmission mechanism.
2.0 Protocol Summary
The protocol necessary in providing redundant/failover servers can be
grouped in three areas:
o Messages to keep the secondary server's lease data synchronized
with that of the primary so that when failover occurs, there is no
degradation of service
o Messages that allow the secondary to determine the operational
state of the primary, so as to know when to start servicing DHCP
traffic
o Messages that are used to coordinate the primary regaining control
when it has become available again.
2.1 Primary keeps secondary lease data synchronized
The messages for keeping the secondary's lease data up to date
include the following:
DHCPBNDADD - Primary notifies secondary of new binding
DHCPBNDUPD - Primary notifies secondary of modified binding
(e.g., extended lease)
DHCPBNDDEL - Primary notifies secondary of deleted binding
(e.g., expired or released lease)
In response to any of the above messages, the secondary server will
respond to the primary with a message describing the status of the
binding addition, modification, or deletion.
DHCPBNDACK - Positive acknowledgment of binding change
DHCPBNDNAK - Negative acknowledgment of binding change
2.2 Determination of operational state of a server
In order to determine the state of a given server, a participant can
use the following message to poll (or "ping") the server:
Rabil, Dooley, Kapur, Droms [Page 5]
DRAFT DHCP Failover Protocol November 1997
DHCPPOLL - Check if server is operational
In response to the DHCPPOLL message, the participant will listen for
the following:
DHCPPRPL - Poll reply
2.3 Primary requests control from the secondary
After a failover, when the primary server is restarted, the following
messages are used to coordinate the primary taking control back from
the secondary:
DHCPCTLREQ - Request for control
DHCPCTLRET - Return of control initiated
DHCPCTLACK - Return of control completed
3 Message formats and semantics
The failover protocol messages are encoded as a DHCP/BOOTP option in
a DHCP message. A DHCP message carrying a failover protocol message
carries only the failover protocol message option and no other
options. The DHCP message is unicast from the source to the
destination.
The option code for these messages is TBD. Within each failover
protocol message, the specific message type is indicated by an option
subcode in the first octet of the data area of the option. The 'len'
field includes the number of octets in the option subcode byte and in
any additional data carried in the failover protocol message.
Bindings are encoded in a format that is TBD.
DISCUSSION
The use of the REQUEST/REPLY field in the DHCP message header and
the UDP port to be used needs to be considered.
The use of existing DHCP options and header fields to encode
bindings needs to be considered.
The sender places a 32-bit number in the DHCP header 'xid' field to
uniquely identify each failover protocol message. The receiver
copies the contents of the 'xid' field into any reply or
acknowledgment message.
The sender is responsible for reliable transmission and any
retransmission.
Rabil, Dooley, Kapur, Droms [Page 6]
DRAFT DHCP Failover Protocol November 1997
3.1 Binding Information
Maintaining consistent binding information between the primary and
secondary servers is a high priority of this protocol. Both the
primary and secondary must be sychronized in order for the failover
operation to occur smoothly. The DHCPBNDADD, DHCPBNDUPD, and
DHCPBNDDEL messages described below require the following binding
information:
hType 1 byte
hLen 1 byte
chAddr 16 bytes
ipAddr 4 bytes
grantTime 4 bytes
expireTime 4 bytes
clientIdentifierLen 2 bytes
clientIdentifierData clientIdentifierLen bytes
status 2 bytes
hostNameLen 2 bytes
hostNameData hostNameLen bytes
domainNameLen 2 bytes
domainNameData domainNameLen bytes
The minimum size of the binding information is 32 bytes.
Note that the use of the client hardware address (hType, hLen, and
chAddr) are in order to facilitate servers which support both the
Bootp and DHCP protocols. Since most, if not all, Bootp clients do
not send a 'client identifier' option, it seems appropriate to use
this combination of fields of the Bootp packet to uniquely identify
the client within the primary and secondary servers' respective
bindings.
The 'ipaddr' is the IP address that the primary server has leased to
the client. The 'grantTime' and 'expireTime' fields are represented
as seconds since Jan 1, 1970 (i.e. ANSI C time_t time value
representation). An 'expireTime' of -1 (ffffffff) indicates an
infinite lease.
If available for the individual binding, the 'clientIdentifier'
fields SHOULD be provided by the primary server. These fields
correspond to the DHCP vendor extension option number 61. If such
information is provided, then the secondary SHOULD use this data to
uniquely identify the client within its bindings database as
discussed in RFC 2132 Section 9.14.
The 'status' field is used to convey the status of a particular
binding to the secondary server. The status may indicate that a
Rabil, Dooley, Kapur, Droms [Page 7]
DRAFT DHCP Failover Protocol November 1997
particular lease has expired, or that an address
The 'hostName' and 'domainName' fields can be used to maintain
information required for Dynamic DNS updates. These fields
correspond to the DHCP vendor extension option number 12 and 15,
respectively.
DISCUSSION
The complete list of fields that may be required in the binding
information is still under discussion. Based upon such
discussions and other requirements, the information may be
expanded or scaled back.
3.2 Primary keeps secondary lease data synchronized
DHCPBNDADD
------------------------------------------
| XX | len | 1 | Binding information
------------------------------------------
The primary sends a DHCPBNDADD message to inform the secondary of a
binding that has been added to the primary's set of bindings.
DHCPBNDUPD
------------------------------------------
| XX | len | 2 | Binding information
------------------------------------------
The primary sends a DHCPBNDUPD message to inform the secondary of a
binding that has been changed in the primary's set of bindings.
DHCPBNDDEL
------------------------------------------
| XX | len | 3 | Binding information
------------------------------------------
The primary sends a DHCPBNDDEL message to inform the secondary of a
binding that has been deleted from the primary's set of bindings.
Rabil, Dooley, Kapur, Droms [Page 8]
DRAFT DHCP Failover Protocol November 1997
DHCPBNDACK
--------------
| XX | 1 | 4 |
--------------
The secondary sends a DHCPBNDACK message to the primary to inform the
primary that the binding change request identified by the 'xid' field
has successfully been completed.
DHCPBNDNAK
--------------
| XX | 1 | 5 |
--------------
The secondary sends a DHCPBNDNAK message to the primary to inform the
primary that the secondary could not complete the binding change
request. For example, the secondary would send a DHCPBNDNAK in
response to a DHCPBNDUPD request for which the secondary had no
recorded binding.
DISCUSSION
The use of an additional field to indicate the reason for the
DHCPBNDNAK message should be considered.
3.3 Determination of operational state of a server
DHCPPOLL
----------------------
| XX | 2 | 6 | flags |
----------------------
A DHCP participant sends a DHCPPOLL message to a server to determine
whether that server is currently operational.
A DHCP secondary periodically sends a DHCPPOLL to its primary to
determine if the primary is currently operational.
A DHCP primary sends a DHCPPOLL to its secondary if the primary needs
to determine if the secondary is operational.
A DHCP client sends a DHCPPOLL to a DHCP server to determine if the
server is currently operational.
The flags octet is defined as follows: CRRRRRRR, where the secondary
Rabil, Dooley, Kapur, Droms [Page 9]
DRAFT DHCP Failover Protocol November 1997
sets the 'C' bit to 1 to indicate that it has taken control of the
bindings database, and the 'R' bits are reserved for future use.
DHCPPRPL
----------------------
| XX | 2 | 7 | flags |
----------------------
A DHCP participant replies to a DHCPPOLL message with a DHCPPRPL
message. The sender copies the 'xid' field from the DHCPPOLL message
header into the 'xid' field in the DHCPPRPL message,
The flags octet is defined as follows: ERRRRRRR, where the primary
sets the 'E' bit to 1 (in response to a DHCPPOLL message with the 'C'
bit set to 1) to indicate to the secondary that the primary has not
relinquished control of the database. See section 4 for additional
details.
DISCUSSION
The DHCPPOLL and DHCPPRPL messages might also be useful to DHCP
clients to aid in determining the availability of specific DHCP
servers. Such use would avoid overloading the DHCPDISCOVER
message.
3.4 Primary requests control from the secondary
DHCPCTLREQ
--------------
| XX | 1 | 8 |
--------------
A primary sends a DHCPCTLREQ message to its secondary to request
control of the bindings database from the secondary.
DHCPCTLRET
--------------
| XX | 1 | 9 |
--------------
A secondary sends a DHCPCTLRET to its primary to begin the process of
returning control of the bindings database to the secondary. After
sending the DHCPCTLRET message, the secondary sends a sequence of
DHCPBNDADD, DHCPBNDUPD and DHCPBNDDEL messages to synchronize the
primary's bindings database with the secondary's database.
Rabil, Dooley, Kapur, Droms [Page 10]
DRAFT DHCP Failover Protocol November 1997
DHCPCTLACK
---------------
| XX | 1 | 10 |
---------------
A secondary sends a DHCPCTLACK to its primary to indicate that the
secondary has finished returning control to the primary.
DISCUSSION
Primary and secondary servers may need to exchange some additional
information in DHCPCTLREQ, DHCPCTLRET and DHCPCTLACK messages.
This information would be encoded in an additional 'flags' or
'data' field added to the control messages.
The synchronization essentially requires a reliable transmission
protocol using DHCPBND* and DHCPBNDACK messages. An alternative
to using DHCPBND* messages to transfer bindings updates to the
primary would be to devise a separate transfer protocol based on
TCP.
4 Exchange of control between primary and secondary
The primary and secondary servers coordinate the exchange control
over the bindings database through the use of DHCPPOLL and DHCPCTLREQ
messages. In normal operation:
o the primary sends notification of each change to its bindings
database to the secondary, and the secondary keeps its bindings
database synchronized with the primary's database
o the secondary periodically sends DHCPPOLL messages to the primary,
and the primary responds to each DHCPPOLL message with a DHCPPRPL
message
If the secondary does not receive a DHCPPRPL response message, the
secondary takes control of the bindings database and begins
answering requests from DHCP clients. Note that the secondary
should be able to be configured to not perform the automatic
switchover.
DISCUSSION
The conditions under which a secondary takes control of the
bindings database, e.g., the number of consecutive missing
acknowledgments, should be configurable in the secondary by the
DHCP administrator.
Rabil, Dooley, Kapur, Droms [Page 11]
DRAFT DHCP Failover Protocol November 1997
The secondary records any changes it makes to the bindings database
while it has control. The secondary continues to send DHCPPOLL
messages to the primary, with the 'D' bit set.
To regain control of the bindings database, e.g., after the primary
server has failed, the primary sends a DHCPCTLREQ message to the
secondary. The secondary stops answering DHCP client requests, and
responds to its primary with a DHCPCTLRET message. After sending
the DHCPCTLRET message, the secondary sends DHCPBND* messages for
each of the changes it has made to the bindings database. The
primary sends a DHCPBNDACK for each of the DHCPBND* messages it
receives. The secondary completes the transfer of control by
sending a DHCPCTLACK message to its primary.
If the primary server has not failed and has been answering DHCP
client requests, and receives a DHCPPOLL message from its secondary
with the 'D' bit set, then both the primary and the secondary have
been answering DHCP client requests, and their bindings databases
may be unsynchronized. In this situation, the primary responds to
the secondary with a DHCPPRPL message with the 'E' bit set. Both
the primary and secondary servers notify a network administrator,
who must take steps to manually resynchronize the two bindings
databases.
DISCUSSION
It may be appropriate to state that, under administrator
control, the primary and secondary both stop some or all DHCP
services when the servers discover that both have been
allocating DHCP addresses simultaneously and their databases are
potentially unsynchronized.
4.1 Minimizing the potential for duplicate bindings
One of the goals outlined in section 1.4 of this draft is to
minimize the possibility of assigning an IP address to two
different clients simultaneously. This possibility can occur only
if both the primary and secondary servers are handling requests
from the same subnet at the same time. Since the basis for this
protocol is that the secondary only becomes "active" in the case
that it has determined that the primary is no longer operational,
the situation in which both are operational at the same time can
occur only if there exists a failure in the mechanism for
determining the status of the primary. This failure could occur,
for example, if all routes between the primary and secondary were
unavailable such that secondary would not get a response to a poll,
even though the primary is still operational. In such
circumstances, if so configured on the secondary (see section 4
Rabil, Dooley, Kapur, Droms [Page 12]
DRAFT DHCP Failover Protocol November 1997
above), manual intervention could be required to OK or disallow the
switchover.
If such an option is not configured, it is still possible for the
secondary to become active and servicing the same subnet(s) as the
primary. In this case, two clients could potentially get the same
IP address, but only if both clients are on the same subnet. This
situation could only occur if one of the client's packets went to
the primary and the other client's packets went to the secondary
server. This would be a very rare situation. However, as rare as
this may be, the potential exists, so another mechanism is needed
to ensure that this does not occur. Therefore, it is a requirement
of this protocol that each server particpating in the failover MUST
ping an address prior to offering that address. This should
eliminate virtually any possibility of duplicate addresses being
offered to clients from the participating servers.
5 Acknowledgments
6 References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC 2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC2131, March 1997.
[RFC 2132] Droms, R., "DHCP Options and BOOTP Vendor Extensions",
RFC2132, March 1997.
7 Security Considerations
8 Authors' Addresses
Greg Rabil, Mike Dooley, Arun Kapur
Quadritek Systems, Inc.
10 Valley Stream Parkway, Quite 240
Malvern, PA 19355
Phone: (800) 408-2747
E-mail: grabil@quadritek.com
mdooley@quadritek.com
akapur@quadritek.com
Ralph Droms
323 Dana Engineering
Bucknell University
Rabil, Dooley, Kapur, Droms [Page 13]
DRAFT DHCP Failover Protocol November 1997
Lewisburg, PA 17837
Phone: (717) 524-1145
E-mail: droms@bucknell.edu
Rabil, Dooley, Kapur, Droms [Page 14]