draft-ietf-dhc-failover-00.txt   draft-ietf-dhc-failover-01.txt 
Network Working Group Greg Rabil Network Working Group Greg Rabil
INTERNET DRAFT Mike Dooley INTERNET DRAFT Mike Dooley
Arun Kapur Obsoletes: draft-ietf-dhc-failover-00.txt Arun Kapur
Quadritek Systems Quadritek Systems
Ralph Droms Ralph Droms
Bucknell University Bucknell University
November 1997 February 1998
Expires May 1998 Expires August 1998
DHCP Failover Protocol DHCP Failover Protocol
<draft-ietf-dhc-failover-00.txt> <draft-ietf-dhc-failover-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 1, line 46 skipping to change at page 1, line 45
DHCP [RFC 2131] allows for multiple servers to be operating on a DHCP [RFC 2131] allows for multiple servers to be operating on a
single network. Some sites are interested in running multiple servers 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 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 In order for this to work reliably, the servers must maintain a
consistent database of the lease information. This implies that consistent database of the lease information. This implies that
servers will need to coordinate any and all lease activity so that servers will need to coordinate any and all lease activity so that
this information is synchronized in case of failover. this information is synchronized in case of failover.
This document defines a protocol to provide this synchronization This document defines a protocol to provide this synchronization
between two servers. One server is designated the ''primary'' server, between two servers. One server is designated the "primary" server,
the other is the ''secondary'' server. Additionally, this document the other is the "secondary" server. Additionally, this document
describes a protocol for the automatic transfer of control from the describes a protocol for the automatic transfer of control from the
primary to the secondary in the case of failure (failover), as well primary to the secondary in the case of failure (failover), as well
DRAFT DHCP Failover Protocol November 1997 DRAFT DHCP Failover Protocol November 1997
as the re-establishment of control by the primary server. as the re-establishment of control by the primary server.
1.0 Introduction 1.0 Introduction
As the use of DHCP servers in networked environments grows, the As the use of DHCP servers in networked environments grows, the
skipping to change at page 2, line 35 skipping to change at page 2, line 35
specifies how to guarantee reliable delivery of changes to the specifies how to guarantee reliable delivery of changes to the
secondary. This is required to synchronize the secondary's lease secondary. This is required to synchronize the secondary's lease
data with that of the primary. The protocol further specifies a data with that of the primary. The protocol further specifies a
mechanism for determining the state (operational or not) of the mechanism for determining the state (operational or not) of the
primary server. The secondary will be able to automatically service primary server. The secondary will be able to automatically service
DHCP requests upon failover. When the primary server becomes DHCP requests upon failover. When the primary server becomes
available again, the secondary will convey any changes that occurred available again, the secondary will convey any changes that occurred
since the time of failover back to the primary prior to the primary since the time of failover back to the primary prior to the primary
becoming operational. becoming operational.
1.1 Requirements 1.1 Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119]. document are to be interpreted as described in RFC 2119 [RFC 2119].
1.2 Terminology 1.2 DHCP Terminology
This document uses the following terms: This document uses the following terms:
o "DHCP client" or "client" o "DHCP client" or "client"
A DHCP client is an Internet host using DHCP to obtain A DHCP client is an Internet host using DHCP to obtain
configuration parameters such as a network address. configuration parameters such as a network address.
o "DHCP server" or "server" o "DHCP server" or "server"
skipping to change at page 3, line 24 skipping to change at page 3, line 24
o "secondary server" or "secondary" o "secondary server" or "secondary"
A DHCP server configured to act as a backup to a primary server; A DHCP server configured to act as a backup to a primary server;
the secondary answers requests from DHCP clients only if its the secondary answers requests from DHCP clients only if its
primary is unable to respond. primary is unable to respond.
o "bindings database" o "bindings database"
The collection of bindings managed by a primary and secondary. 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
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.
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 2.0 Protocol Summary
The protocol necessary in providing redundant/failover servers can be The protocol necessary in providing redundant/failover servers can be
grouped in three areas: grouped in three areas:
o Messages to keep the secondary server's lease data synchronized o Messages to keep the secondary server's lease data synchronized
with that of the primary so that when failover occurs, there is no with that of the primary so that when failover occurs, there is no
degradation of service degradation of service
o Messages that allow the secondary to determine the operational o Messages that allow the secondary to determine the operational
skipping to change at page 4, line 5 skipping to change at page 5, line 47
DHCPBNDADD - Primary notifies secondary of new binding DHCPBNDADD - Primary notifies secondary of new binding
DHCPBNDUPD - Primary notifies secondary of modified binding DHCPBNDUPD - Primary notifies secondary of modified binding
(e.g., extended lease) (e.g., extended lease)
DHCPBNDDEL - Primary notifies secondary of deleted binding DHCPBNDDEL - Primary notifies secondary of deleted binding
(e.g., expired or released lease) (e.g., expired or released lease)
In response to any of the above messages, the secondary server will In response to any of the above messages, the secondary server will
respond to the primary with a message describing the status of the respond to the primary with a message describing the status of the
binding addition, modification, or deletion. binding addition, modification, or deletion.
DRAFT DHCP Failover Protocol November 1997
DHCPBNDACK - Positive acknowledgment of binding change DHCPBNDACK - Positive acknowledgment of binding change
DHCPBNDNAK - Negative acknowledgment of binding change DHCPBNDNAK - Negative acknowledgment of binding change
2.2 Determination of operational state of a server 2.2 Determination of operational state of a server
In order to determine the state of a given server, a participant can In order to determine the state of a given server, a participant can
use the following message to poll (or "ping") the server: use the following message to poll (or "ping") the server:
DRAFT DHCP Failover Protocol November 1997
DHCPPOLL - Check if server is operational DHCPPOLL - Check if server is operational
In response to the DHCPPOLL message, the participant will listen for In response to the DHCPPOLL message, the participant will listen for
the following: the following:
DHCPPRPL - Poll reply DHCPPRPL - Poll reply
2.3 Primary requests control from the secondary 2.3 Primary requests control from the secondary
After a failover, when the primary server is restarted, the following After a failover, when the primary server is restarted, the following
skipping to change at page 5, line 4 skipping to change at page 6, line 45
field includes the number of octets in the option subcode byte and in field includes the number of octets in the option subcode byte and in
any additional data carried in the failover protocol message. any additional data carried in the failover protocol message.
Bindings are encoded in a format that is TBD. Bindings are encoded in a format that is TBD.
DISCUSSION DISCUSSION
The use of the REQUEST/REPLY field in the DHCP message header and The use of the REQUEST/REPLY field in the DHCP message header and
the UDP port to be used needs to be considered. the UDP port to be used needs to be considered.
The use of existing DHCP options and header fields to encode The use of existing DHCP options and header fields to encode
DRAFT DHCP Failover Protocol November 1997
bindings needs to be considered. bindings needs to be considered.
The sender places a 32-bit number in the DHCP header 'xid' field to The sender places a 32-bit number in the DHCP header 'xid' field to
uniquely identify each failover protocol message. The receiver uniquely identify each failover protocol message. The receiver
copies the contents of the 'xid' field into any reply or copies the contents of the 'xid' field into any reply or
acknowledgment message. acknowledgment message.
The sender is responsible for reliable transmission and any The sender is responsible for reliable transmission and any
retransmission. retransmission.
3.1 Primary keeps secondary lease data synchronized 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
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 DHCPBNDADD
------------------------------------------ ------------------------------------------
| XX | len | 1 | Binding information (TBD) | XX | len | 1 | Binding information
------------------------------------------ ------------------------------------------
The primary sends a DHCPBNDADD message to inform the secondary of a The primary sends a DHCPBNDADD message to inform the secondary of a
binding that has been added to the primary's set of bindings. binding that has been added to the primary's set of bindings.
DHCPBNDUPD DHCPBNDUPD
------------------------------------------ ------------------------------------------
| XX | len | 2 | Binding information (TBD) | XX | len | 2 | Binding information
------------------------------------------ ------------------------------------------
The primary sends a DHCPBNDUPD message to inform the secondary of a The primary sends a DHCPBNDUPD message to inform the secondary of a
binding that has been changed in the primary's set of bindings. binding that has been changed in the primary's set of bindings.
DHCPBNDDEL DHCPBNDDEL
------------------------------------------ ------------------------------------------
| XX | len | 3 | Binding information (TBD) | XX | len | 3 | Binding information
------------------------------------------ ------------------------------------------
The primary sends a DHCPBNDDEL message to inform the secondary of a The primary sends a DHCPBNDDEL message to inform the secondary of a
binding that has been deleted from the primary's set of bindings. binding that has been deleted from the primary's set of bindings.
DRAFT DHCP Failover Protocol November 1997
DHCPBNDACK DHCPBNDACK
-------------- --------------
| XX | 1 | 4 | | XX | 1 | 4 |
-------------- --------------
The secondary sends a DHCPBNDACK message to the primary to inform the The secondary sends a DHCPBNDACK message to the primary to inform the
primary that the binding change request identified by the 'xid' field primary that the binding change request identified by the 'xid' field
DRAFT DHCP Failover Protocol November 1997
has successfully been completed. has successfully been completed.
DHCPBNDNAK DHCPBNDNAK
-------------- --------------
| XX | 1 | 5 | | XX | 1 | 5 |
-------------- --------------
The secondary sends a DHCPBNDNAK message to the primary to inform the The secondary sends a DHCPBNDNAK message to the primary to inform the
primary that the secondary could not complete the binding change primary that the secondary could not complete the binding change
skipping to change at page 6, line 22 skipping to change at page 9, line 30
| XX | 1 | 5 | | XX | 1 | 5 |
-------------- --------------
The secondary sends a DHCPBNDNAK message to the primary to inform the The secondary sends a DHCPBNDNAK message to the primary to inform the
primary that the secondary could not complete the binding change primary that the secondary could not complete the binding change
request. For example, the secondary would send a DHCPBNDNAK in request. For example, the secondary would send a DHCPBNDNAK in
response to a DHCPBNDUPD request for which the secondary had no response to a DHCPBNDUPD request for which the secondary had no
recorded binding. recorded binding.
DISCUSSION DISCUSSION
The use of an additional field to indicate the reason for the The use of an additional field to indicate the reason for the
DHCPBNDNAK message should be considered. DHCPBNDNAK message should be considered.
3.2 Determination of operational state of a server 3.3 Determination of operational state of a server
DHCPPOLL DHCPPOLL
---------------------- ----------------------
| XX | 2 | 6 | flags | | XX | 2 | 6 | flags |
---------------------- ----------------------
A DHCP participant sends a DHCPPOLL message to a server to determine A DHCP participant sends a DHCPPOLL message to a server to determine
whether that server is currently operational. whether that server is currently operational.
A DHCP secondary periodically sends a DHCPPOLL to its primary to A DHCP secondary periodically sends a DHCPPOLL to its primary to
determine if the primary is currently operational. determine if the primary is currently operational.
A DHCP primary sends a DHCPPOLL to its secondary if the primary needs A DHCP primary sends a DHCPPOLL to its secondary if the primary needs
to determine if the secondary is operational. to determine if the secondary is operational.
A DHCP client sends a DHCPPOLL to a DHCP server to determine if the A DHCP client sends a DHCPPOLL to a DHCP server to determine if the
server is currently operational. server is currently operational.
The flags octet is defined as follows: CRRRRRRR, where the secondary The flags octet is defined as follows: CRRRRRRR, where the secondary
DRAFT DHCP Failover Protocol November 1997
sets the 'C' bit to 1 to indicate that it has taken control of the 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. bindings database, and the 'R' bits are reserved for future use.
DHCPPRPL DHCPPRPL
---------------------- ----------------------
| XX | 2 | 7 | flags | | XX | 2 | 7 | flags |
---------------------- ----------------------
DRAFT DHCP Failover Protocol November 1997
A DHCP participant replies to a DHCPPOLL message with a DHCPPRPL A DHCP participant replies to a DHCPPOLL message with a DHCPPRPL
message. The sender copies the 'xid' field from the DHCPPOLL message message. The sender copies the 'xid' field from the DHCPPOLL message
header into the 'xid' field in the DHCPPRPL message, header into the 'xid' field in the DHCPPRPL message,
The flags octet is defined as follows: ERRRRRRR, where the primary 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' 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 bit set to 1) to indicate to the secondary that the primary has not
relinquished control of the database. See section 4 for additional relinquished control of the database. See section 4 for additional
details. details.
DISCUSSION DISCUSSION
The DHCPPOLL and DHCPPRPL messages might also be useful to DHCP The DHCPPOLL and DHCPPRPL messages might also be useful to DHCP
clients to aid in determining the availability of specific DHCP clients to aid in determining the availability of specific DHCP
servers. Such use would avoid overloading the DHCPDISCOVER servers. Such use would avoid overloading the DHCPDISCOVER
message. message.
3.3 Primary requests control from the secondary 3.4 Primary requests control from the secondary
DHCPCTLREQ DHCPCTLREQ
-------------- --------------
| XX | 1 | 8 | | XX | 1 | 8 |
-------------- --------------
A primary sends a DHCPCTLREQ message to its secondary to request A primary sends a DHCPCTLREQ message to its secondary to request
control of the bindings database from the secondary. control of the bindings database from the secondary.
skipping to change at page 7, line 47 skipping to change at page 11, line 5
-------------- --------------
| XX | 1 | 9 | | XX | 1 | 9 |
-------------- --------------
A secondary sends a DHCPCTLRET to its primary to begin the process of A secondary sends a DHCPCTLRET to its primary to begin the process of
returning control of the bindings database to the secondary. After returning control of the bindings database to the secondary. After
sending the DHCPCTLRET message, the secondary sends a sequence of sending the DHCPCTLRET message, the secondary sends a sequence of
DHCPBNDADD, DHCPBNDUPD and DHCPBNDDEL messages to synchronize the DHCPBNDADD, DHCPBNDUPD and DHCPBNDDEL messages to synchronize the
primary's bindings database with the secondary's database. primary's bindings database with the secondary's database.
DRAFT DHCP Failover Protocol November 1997
DHCPCTLACK DHCPCTLACK
--------------- ---------------
| XX | 1 | 10 | | XX | 1 | 10 |
--------------- ---------------
A secondary sends a DHCPCTLACK to its primary to indicate that the A secondary sends a DHCPCTLACK to its primary to indicate that the
secondary has finished returning control to the primary. secondary has finished returning control to the primary.
DRAFT DHCP Failover Protocol November 1997
DISCUSSION DISCUSSION
Primary and secondary servers may need to exchange some additional Primary and secondary servers may need to exchange some additional
information in DHCPCTLREQ, DHCPCTLRET and DHCPCTLACK messages. information in DHCPCTLREQ, DHCPCTLRET and DHCPCTLACK messages.
This information would be encoded in an additional 'flags' or This information would be encoded in an additional 'flags' or
'data' field added to the control messages. 'data' field added to the control messages.
The synchronization essentially requires a reliable transmission The synchronization essentially requires a reliable transmission
protocol using DHCPBND* and DHCPBNDACK messages. An alternative protocol using DHCPBND* and DHCPBNDACK messages. An alternative
to using DHCPBND* messages to transfer bindings updates to the to using DHCPBND* messages to transfer bindings updates to the
skipping to change at page 8, line 36 skipping to change at page 11, line 45
o the primary sends notification of each change to its bindings o the primary sends notification of each change to its bindings
database to the secondary, and the secondary keeps its bindings database to the secondary, and the secondary keeps its bindings
database synchronized with the primary's database database synchronized with the primary's database
o the secondary periodically sends DHCPPOLL messages to the primary, o the secondary periodically sends DHCPPOLL messages to the primary,
and the primary responds to each DHCPPOLL message with a DHCPPRPL and the primary responds to each DHCPPOLL message with a DHCPPRPL
message message
If the secondary does not receive a DHCPPRPL response message, the If the secondary does not receive a DHCPPRPL response message, the
secondary takes control of the bindings database and begins secondary takes control of the bindings database and begins
answering requests from DHCP clients. answering requests from DHCP clients. Note that the secondary
should be able to be configured to not perform the automatic
switchover.
DISCUSSION DISCUSSION
The conditions under which a secondary takes control of the The conditions under which a secondary takes control of the
bindings database, e.g., the number of consecutive missing bindings database, e.g., the number of consecutive missing
acknowledgments, should be configurable in the secondary by the acknowledgments, should be configurable in the secondary by the
DHCP administrator. DHCP administrator.
DRAFT DHCP Failover Protocol November 1997
The secondary records any changes it makes to the bindings database The secondary records any changes it makes to the bindings database
while it has control. The secondary continues to send DHCPPOLL while it has control. The secondary continues to send DHCPPOLL
messages to the primary, with the 'D' bit set. messages to the primary, with the 'D' bit set.
To regain control of the bindings database, e.g., after the primary To regain control of the bindings database, e.g., after the primary
server has failed, the primary sends a DHCPCTLREQ message to the server has failed, the primary sends a DHCPCTLREQ message to the
secondary. The secondary stops answering DHCP client requests, and secondary. The secondary stops answering DHCP client requests, and
responds to its primary with a DHCPCTLRET message. After sending responds to its primary with a DHCPCTLRET message. After sending
the DHCPCTLRET message, the secondary sends DHCPBND* messages for the DHCPCTLRET message, the secondary sends DHCPBND* messages for
each of the changes it has made to the bindings database. The each of the changes it has made to the bindings database. The
DRAFT DHCP Failover Protocol November 1997
primary sends a DHCPBNDACK for each of the DHCPBND* messages it primary sends a DHCPBNDACK for each of the DHCPBND* messages it
receives. The secondary completes the transfer of control by receives. The secondary completes the transfer of control by
sending a DHCPCTLACK message to its primary. sending a DHCPCTLACK message to its primary.
If the primary server has not failed and has been answering DHCP If the primary server has not failed and has been answering DHCP
client requests, and receives a DHCPPOLL message from its secondary client requests, and receives a DHCPPOLL message from its secondary
with the 'D' bit set, then both the primary and the secondary have with the 'D' bit set, then both the primary and the secondary have
been answering DHCP client requests, and their bindings databases been answering DHCP client requests, and their bindings databases
may be unsynchronized. In this situation, the primary responds to may be unsynchronized. In this situation, the primary responds to
the secondary with a DHCPPRPL message with the 'E' bit set. Both the secondary with a DHCPPRPL message with the 'E' bit set. Both
skipping to change at page 9, line 29 skipping to change at page 12, line 39
databases. databases.
DISCUSSION DISCUSSION
It may be appropriate to state that, under administrator It may be appropriate to state that, under administrator
control, the primary and secondary both stop some or all DHCP control, the primary and secondary both stop some or all DHCP
services when the servers discover that both have been services when the servers discover that both have been
allocating DHCP addresses simultaneously and their databases are allocating DHCP addresses simultaneously and their databases are
potentially unsynchronized. 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
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 5 Acknowledgments
6 References 6 References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC2131, March 1997. RFC2131, March 1997.
skipping to change at page 10, line 5 skipping to change at page 13, line 51
Greg Rabil, Mike Dooley, Arun Kapur Greg Rabil, Mike Dooley, Arun Kapur
Quadritek Systems, Inc. Quadritek Systems, Inc.
10 Valley Stream Parkway, Quite 240 10 Valley Stream Parkway, Quite 240
Malvern, PA 19355 Malvern, PA 19355
Phone: (800) 408-2747 Phone: (800) 408-2747
E-mail: grabil@quadritek.com E-mail: grabil@quadritek.com
mdooley@quadritek.com mdooley@quadritek.com
akapur@quadritek.com akapur@quadritek.com
DRAFT DHCP Failover Protocol November 1997
Ralph Droms Ralph Droms
323 Dana Engineering 323 Dana Engineering
Bucknell University Bucknell University
DRAFT DHCP Failover Protocol November 1997
Lewisburg, PA 17837 Lewisburg, PA 17837
Phone: (717) 524-1145 Phone: (717) 524-1145
E-mail: droms@bucknell.edu E-mail: droms@bucknell.edu
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/