draft-ietf-dhc-failover-11.txt   draft-ietf-dhc-failover-12.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Mark Stapp Mark Stapp
Cisco Systems Cisco Systems
Bernie Volz Bernie Volz
Ericsson Ericsson
Steve Gonczi Steve Gonczi
Relicore Relicore
Greg Rabil Greg Rabil
Mike Dooley
Arun Kapur
Lucent Technologies Lucent Technologies
November 2002 Michael Dooley
Expires May 2003 Diamond IP Technologies
Arun Kapur
K5 Networks
March 2003
Expires September 2003
DHCP Failover Protocol DHCP Failover Protocol
<draft-ietf-dhc-failover-11.txt> <draft-ietf-dhc-failover-12.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 48 skipping to change at page 2, line 7
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
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 single network. Some sites are interested in running multiple
servers in such a way so as to provide redundancy in case of server servers in such a way so as to provide redundancy in case of server
failure. In order for this to work reliably, the cooperating primary failure. In order for this to work reliably, the cooperating primary
and secondary servers must maintain a consistent database of the and secondary servers must maintain a consistent database of the
lease information. This implies that servers will need to coordinate lease information. This implies that servers will need to coordinate
any and all lease activity so that this information is synchronized any and all lease activity so that this information is synchronized
skipping to change at page 2, line 38 skipping to change at page 2, line 42
3. Background and External Requirements......................... 9 3. Background and External Requirements......................... 9
3.1. Key aspects of the DHCP protocol........................... 9 3.1. Key aspects of the DHCP protocol........................... 9
3.2. BOOTP relay agent implementation........................... 11 3.2. BOOTP relay agent implementation........................... 11
3.3. What does it mean if a server can't communicate with its partner? 12 3.3. What does it mean if a server can't communicate with its partner? 12
3.4. Challenging scenarios for a Failover protocol.............. 13 3.4. Challenging scenarios for a Failover protocol.............. 13
3.5. Using TCP to detect partner server failure................. 14 3.5. Using TCP to detect partner server failure................. 14
4. Design Goals................................................. 15 4. Design Goals................................................. 15
4.1. Design goals for this protocol............................. 15 4.1. Design goals for this protocol............................. 15
4.2. Limitations of this protocol............................... 17 4.2. Limitations of this protocol............................... 17
5. Protocol Overview............................................ 17 5. Protocol Overview............................................ 17
5.1. Messages and States........................................ 17 5.1. Messages and States........................................ 18
5.2. Fundamental guarantees..................................... 20 5.2. Fundamental guarantees..................................... 20
5.3. Load balancing............................................. 27 5.3. Load balancing............................................. 27
5.4. IP address allocations between servers..................... 28 5.4. IP address allocations between servers..................... 28
5.5. Operating in NORMAL state.................................. 30 5.5. Operating in NORMAL state.................................. 30
5.6. Operating in COMMUNICATIONS-INTERRUPTED state.............. 31 5.6. Operating in COMMUNICATIONS-INTERRUPTED state.............. 31
5.7. Operating in PARTNER-DOWN state............................ 31 5.7. Operating in PARTNER-DOWN state............................ 31
5.8. Operating in RECOVER state................................. 31 5.8. Operating in RECOVER state................................. 31
5.9. Operating in STARTUP state................................. 31 5.9. Operating in STARTUP state................................. 31
5.10. Time synchronization between servers...................... 32 5.10. Time synchronization between servers...................... 32
5.11. IP address binding-status................................. 32 5.11. IP address binding-status................................. 33
5.12. DNS dynamic update considerations......................... 36 5.12. DNS dynamic update considerations......................... 36
5.13. Reservations and failover................................. 41 5.13. Reservations and failover................................. 41
5.14. Dynamic BOOTP and failover................................ 42 5.14. Dynamic BOOTP and failover................................ 42
5.15. Guidelines for selecting MCLT............................. 43 5.15. Guidelines for selecting MCLT............................. 43
5.16. What is sent in response to an UPDREQ or UPDREQALL message? 43 5.16. What is sent in response to an UPDREQ or UPDREQALL message? 43
5.17. How do you determine that your partner is "up to date" for 45 5.17. How do you determine that your partner is "up to date" for 45
6. Common Message Format........................................ 45 6. Common Message Format........................................ 45
6.1. Message header format...................................... 46 6.1. Message header format...................................... 46
6.2. Common option format....................................... 48 6.2. Common option format....................................... 48
6.3. Batching multiple binding update transactions in one BNDUPD mes- 49 6.3. Batching multiple binding update transactions in one BNDUPD mes- 49
skipping to change at page 4, line 47 skipping to change at page 4, line 50
14. Acknowledgments............................................. 127 14. Acknowledgments............................................. 127
15. References.................................................. 129 15. References.................................................. 129
16. Author's information........................................ 131 16. Author's information........................................ 131
17. Full Copyright Statement.................................... 132 17. Full Copyright Statement.................................... 132
1. Introduction 1. Introduction
DHCP [RFC 2131] allows for multiple servers to be operating on a sin- DHCP [RFC 2131] allows for multiple servers to be operating on a sin-
gle network. Some sites are interested in running multiple servers gle 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
since the DHCP subsystem is in many cases a critical part of the net- since the DHCP subsystem is in many cases a critical part of the
work infrastructure. network infrastructure.
This document defines a protocol to provide synchronization between This document defines a protocol to provide synchronization between
two servers in order that each can take over for the other should two servers in order that each can take over for the other should
either one fail or become unreachable. either one fail or become unreachable.
One server is designated the "primary" server, the other is the One server is designated the "primary" server, the other is the
"secondary" server, and most DHCP client requests are sent to each "secondary" server, and most DHCP client requests are sent to each
server (see section 3.1.1 for details). server (see section 3.1.1 for details).
In order to provide a high availability DHCP service, these In order to provide a high availability DHCP service, these
skipping to change at page 7, line 14 skipping to change at page 7, line 15
o "DNS" o "DNS"
An abbreviation for "Domain Name System", a scheme where a cen- An abbreviation for "Domain Name System", a scheme where a cen-
tral name repository is used to map names to IP addresses and IP tral name repository is used to map names to IP addresses and IP
addresses to names. addresses to names.
o "failover endpoint" o "failover endpoint"
The failover protocol allows for there to be a unique failover The failover protocol allows for there to be a unique failover
endpoint per partner per role (where role is primary or secon- endpoint per partner per role per relationship (where role is
dary). This failover endpoint can take actions and hold unique primary or secondary and the relationship is defined by the
states. There are thus a maximum of two failover endpoints per relationship-name option). This failover endpoint can take
server per partner (one for each partner as a primary and one actions and hold unique states. Typically, there is a one fail-
for that same partner as a secondary.) over endpoint per partner, although there may be more.
o "FQDN" o "FQDN"
An FQDN is a "fully qualified domain name". A fully qualified An FQDN is a "fully qualified domain name". A fully qualified
domain name generally is a host name with at least one zone domain name generally is a host name with at least one zone
name, for example "www.dhcp.org" is a fully qualified domain name, for example "www.dhcp.org" is a fully qualified domain
name. name.
o "lazy update" o "lazy update"
skipping to change at page 13, line 49 skipping to change at page 13, line 51
This scenario is handled by the failover protocol through control of This scenario is handled by the failover protocol through control of
the lease time and the use of the maximum client lead time (MCLT). the lease time and the use of the maximum client lead time (MCLT).
See section 5.2.1 for details. See section 5.2.1 for details.
3.4.2. Network partition where DHCP servers can't communicate but each 3.4.2. Network partition where DHCP servers can't communicate but each
can talk to clients: can talk to clients:
Several conditions are required for this situation to occur. First, Several conditions are required for this situation to occur. First,
due to a network failure, the primary and secondary servers cannot due to a network failure, the primary and secondary servers cannot
communicate. As well, some of the DHCP clients must be able to com- communicate. As well, some of the DHCP clients must be able to
municate with the primary server, and some of the clients must now communicate with the primary server, and some of the clients must now
only be able to communicate with the secondary server. When this only be able to communicate with the secondary server. When this
condition occurs, both primary and secondary servers could attempt to condition occurs, both primary and secondary servers could attempt to
allocate IP addresses for new clients from the same pool of available allocate IP addresses for new clients from the same pool of available
addresses. At some point, then, two clients will end up being allo- addresses. At some point, then, two clients will end up being allo-
cated the same IP address. This will cause problems when the network cated the same IP address. This will cause problems when the network
failure that created this situation is corrected. failure that created this situation is corrected.
The failover protocol deals with this situation by having the primary The failover protocol deals with this situation by having the primary
and secondary servers allocate addresses for new clients from dis- and secondary servers allocate addresses for new clients from dis-
joint address pools. See section 5.5 for details. joint address pools. See section 5.5 for details.
skipping to change at page 16, line 52 skipping to change at page 17, line 7
above goals and requirements may be met. In addition, when above goals and requirements may be met. In addition, when
the partition condition is removed, allow graceful automatic the partition condition is removed, allow graceful automatic
re-integration without requiring human intervention. re-integration without requiring human intervention.
14. If either primary or secondary server loses all of the infor- 14. If either primary or secondary server loses all of the infor-
mation that it has stored in stable storage, ensure that it be mation that it has stored in stable storage, ensure that it be
able to refresh its stable storage from the other server. able to refresh its stable storage from the other server.
15. Support load balancing between the primary and secondary 15. Support load balancing between the primary and secondary
servers, and allow configuration of the percentage of the servers, and allow configuration of the percentage of the
client population served by each with a moderately fine client population served by each with a moderately fine granu-
granularity. larity.
4.2. Limitations of this protocol 4.2. Limitations of this protocol
The following are explicit limitations of this protocol. The following are explicit limitations of this protocol.
1. This protocol provides only one level of redundancy through a 1. This protocol provides only one level of redundancy through a
single secondary server for each primary server. single secondary server for each primary server.
2. A subset of the address pool is reserved for secondary server 2. A subset of the address pool is reserved for secondary server
use. In order to handle the failure case where both servers use. In order to handle the failure case where both servers
skipping to change at page 19, line 30 skipping to change at page 19, line 34
ful. ful.
For instance, there might be several servers which are each primary For instance, there might be several servers which are each primary
for a distinct set of address pools, and one server which is secon- for a distinct set of address pools, and one server which is secon-
dary for all of those address pools. The situation with the pri- dary for all of those address pools. The situation with the pri-
maries is straightforward, but the secondary will need to maintain a maries is straightforward, but the secondary will need to maintain a
separate failover state, partner state, and communications up/down separate failover state, partner state, and communications up/down
status for each of the separate primary servers for which it is act- status for each of the separate primary servers for which it is act-
ing as a secondary. ing as a secondary.
The failover protocol calls for there to be a unique failover end- The failover protocol is SHOULD be configured with one failover rela-
point per partner per role (where role is primary or secondary). tionship between each pair of failover servers. In this case there is
This failover endpoint can take actions and hold unique states. one failover endpoint for that relationship on each partner. This
There are thus a maximum of two failover endpoints per partner (one failover relationship MUST have a unique name, which is communicated
for the partner as a primary and one for that same partner as a using the relationship-name option in the CONNECT and CONNECTACK mes-
secondary.) sages.
There is typically little need for addtional relationships between
any two servers but there MAY be more than one failover relationship
between two servers -- however each MUST have a unique relationship
name (stored in the relationship-name option).
Any failover endpoint can take actions and hold unique states.
Thus, in the case where there are two primary servers A and B each Thus, in the case where there are two primary servers A and B each
backed up by a single common secondary server C, there is one fail- backed up by a single common secondary server C, there is one fail-
over endpoint on each of A and B, and two different failover end- over endpoint on each of A and B, and two different failover end-
points on C. The two different failover endpoints on C each have points on C. The two different failover endpoints on C each have
unique states and independent TCP connections. unique states, unique relationship names, and independent TCP
connections.
This document frequently describes the behavior of the protocol in This document frequently describes the behavior of the protocol in
terms of primary and secondary servers, not primary and secondary terms of primary and secondary servers, not primary and secondary
failover endpoints. However, it is important to remember that every failover endpoints. However, it is important to remember that every
'server' described in this document is in reality a failover endpoint 'server' described in this document is in reality a failover endpoint
that resides in a particular process, and that many failover end- that resides in a particular process, and that many failover end-
points may reside in the same process. points may reside in the same server process.
It is not the case that there is a unique failover endpoint for each It is not the case that there is a unique failover endpoint for each
subnet address pool that participates in a failover relationship. On subnet address pool that participates in a failover relationship. On
one server, there is one failover endpoint per partner per role, one server, there is (typically) one failover endpoint per partner,
regardless of how many subnet address pools are managed by that com- regardless of how many subnet address pools are managed by that com-
bination of partner and role. Conversely, on a particular server, bination of partner and role. Conversely, on a particular server,
any given subnet address pool will be associated with exactly one any given subnet address pool will be associated with exactly one
failover endpoint. failover endpoint.
When a connection is received from the partner, the unique failover When a connection is received from the partner, the unique failover
endpoint to which the message is directed is determined solely by the endpoint to which the message is directed is determined solely by the
IP address of the partner and the port to which the connection is IP address of the partner, the relationship-name, and the role of the
directed by the partner. See section 8.2. receiving server. See section 8.2.
5.2. Fundamental guarantees 5.2. Fundamental guarantees
There a several fundamental restrictions this protocol places on what There a several fundamental restrictions this protocol places on what
one server can do in the absence of knowledge of the other server. one server can do in the absence of knowledge of the other server.
Operating within these restrictions allows certain guarantees to be Operating within these restrictions allows certain guarantees to be
made to the partner server, and these are key to the correct opera- made to the partner server, and these are key to the correct opera-
tion of the protocol. tion of the protocol.
5.2.1. Control of lease time 5.2.1. Control of lease time
skipping to change at page 32, line 17 skipping to change at page 32, line 17
enough to ensure that it will connect to the other server if that enough to ensure that it will connect to the other server if that
server is available for connections. server is available for connections.
5.10. Time synchronization between servers 5.10. Time synchronization between servers
The failover protocol is designed to operate between two servers The failover protocol is designed to operate between two servers
which have time values which differ by an arbitrarily large amount. which have time values which differ by an arbitrarily large amount.
A particular implementation MAY choose to only support servers whose A particular implementation MAY choose to only support servers whose
time values differ by an arbitrarily small amount. time values differ by an arbitrarily small amount.
Note that if an implementation that requires time synchronization
between servers encounters a case where the time is not synchronized
to its satisfaction between two servers, then this failure will prob-
ably prevent the two servers from reaching communications OK status.
In this occurs, and if both servers continue to operate and deal with
clients, potentially troublesome things can happen. For instance, if
there is a safe period configured on either server, then it will
eventually go into PARTNER-DOWN state, but in this case the partner
will not be down. This will almost certainly create problems. Thus,
some method to prevent this sort of situation SHOULD exist in imple-
mentations that can be configured to require time synchronization.
In any event, whether large or only small differences in time values In any event, whether large or only small differences in time values
are supported, every message that is received MUST be tagged with a are supported, every message that is sent MUST include the time and
time value as soon as possible after receipt. This time value is every packet that is received MUST be tagged with a time value as
used along with the time value that is sent in every message between soon as possible after receipt. This time value is used along with
the failover partners to develop a delta time between the servers. the time value that is sent in every message between the failover
This delta time is used during the connection process to establish a partners to develop a delta time between the servers. This delta
baseline delta time between the servers, and upon receipt of each time is used during the connection process to establish a baseline
message, the delta time for that message is used to refine the delta delta time between the servers, and upon receipt of each message, the
time for the server pair. delta time for that message is used to refine the delta time for the
server pair.
While the algorithm for this refinement of delta time is not speci- While the algorithm for this refinement of delta time is not speci-
fied as part of this protocol, a server SHOULD allow the delta time fied as part of this protocol, a server SHOULD allow the delta time
value for a pair of failover servers to be periodically updated to value for a pair of failover servers to be periodically updated to
account for time drift. In addition, the delta time value between account for time drift. In addition, the delta time value between
servers SHOULD be smoothed in some fashion, so that transient network servers SHOULD be smoothed in some fashion, so that transient network
delays will not cause it to vary wildly. delays will not cause it to vary wildly.
A server SHOULD recognize a drastic change in the delta time value as A server SHOULD recognize a drastic change in the delta time value as
an event to be signaled to a network administrator, as well as reset- an event to be signaled to a network administrator, as well as reset-
skipping to change at page 57, line 46 skipping to change at page 57, line 46
including receipt and processing of DHCP client requests, administra- including receipt and processing of DHCP client requests, administra-
tive inputs and receipt of BNDUPD messages. Every DHCP server needs tive inputs and receipt of BNDUPD messages. Every DHCP server needs
to respond to DHCP client requests and administrative inputs with to respond to DHCP client requests and administrative inputs with
changes to its internal record of the binding-status of an IP changes to its internal record of the binding-status of an IP
address, and this response is not in the scope of the failover proto- address, and this response is not in the scope of the failover proto-
col. However, the receipt of BNDUPD messages implies at least a pos- col. However, the receipt of BNDUPD messages implies at least a pos-
sible change of the binding-status for an IP address, and must be sible change of the binding-status for an IP address, and must be
discussed here. See section 7.1.2 for general actions to take upon discussed here. See section 7.1.2 for general actions to take upon
receipt of a BNDUPD message. receipt of a BNDUPD message.
When receiving a BNDUPD message, it is important to note that it may
not be current, in that the server receiving the BNDUPD message may
have had a more recent interaction with the DHCP client than its
partner who sent the BNDUPD message. In this case, the receiving
server MUST reject the BNDUPD message. The reject reason SHOULD be
15: "Outdated binding information". In addition, it is worth noting
that two (and possibly three) binding-status values are the direct
result of interaction with a DHCP client, ACTIVE and RELEASED (and
possibly ABANDONED). All other binding-status values are either the
result of the expiration of a time period or interaction with an
external agency (e.g., a network administrator).
Every BNDUPD message SHOULD contain a client-last-transaction-time Every BNDUPD message SHOULD contain a client-last-transaction-time
option, which MUST, if it appears, be the time that the server last option, which MUST, if it appears, be the time that the server last
interacted with the DHCP client. It MUST NOT be, for instance, the interacted with the DHCP client. It MUST NOT be, for instance, the
time that the lease on an IP address expired. If there has been no time that the lease on an IP address expired. If there has been no
interaction with the DHCP client in question (or there is no DHCP interaction with the DHCP client in question (or there is no DHCP
client presently associated with this IP address), then there will be client presently associated with this IP address), then there will be
no client-last-transaction-time option in the BNDUPD message. no client-last-transaction-time option in the BNDUPD message.
The list in Figure 7.1.3-1 is indexed by the binding-status that a The list in Figure 7.1.3-1 is indexed by the binding-status that a
server receives in a BNDUPD message. In many cases, the binding- server receives in a BNDUPD message. In many cases, the binding-
skipping to change at page 60, line 9 skipping to change at page 60, line 9
server". server".
7.1.4. Accepting the BNDUPD message 7.1.4. Accepting the BNDUPD message
When accepting a BNDUPD message, the information contained in the When accepting a BNDUPD message, the information contained in the
client-request-options and client-reply-options SHOULD be examined client-request-options and client-reply-options SHOULD be examined
for any information of interest to this server. For instance, a for any information of interest to this server. For instance, a
server which wished to detect changes in client specified host names server which wished to detect changes in client specified host names
might want to examine and save information from the host-name or might want to examine and save information from the host-name or
client-FQDN options. Servers which expect to utilize information client-FQDN options. Servers which expect to utilize information
from the relay-agent-information option would want to store this from the relay-agent-information option SHOULD store this informa-
information. tion.
7.1.5. Time values related to the BNDUPD message 7.1.5. Time values related to the BNDUPD message
There are four time values that MAY be sent in a BNDUPD message. There are four time values that MAY be sent in a BNDUPD message.
o lease-expiration-time o lease-expiration-time
The time that the server gave to the client, i.e., the time that The time that the server gave to the client, i.e., the time that
the server believes that the client's lease will expire. the server believes that the client's lease will expire.
skipping to change at page 81, line 27 skipping to change at page 81, line 27
connections between failover endpoints is used to determine if com- connections between failover endpoints is used to determine if com-
munications is "okay" or "failed". munications is "okay" or "failed".
A single TCP connection exists which connects two failover endpoints. A single TCP connection exists which connects two failover endpoints.
8.1. Connection granularity 8.1. Connection granularity
There exists one TCP connection between each set of failover end- There exists one TCP connection between each set of failover end-
points. See section 5.1.1 for an explanation of failover endpoints. points. See section 5.1.1 for an explanation of failover endpoints.
There are a maximum of two TCP connections between any two servers Typically there is one failover endpoint for each end of a failover
implementing the failover protocol, one for each of the possible relationship between two servers, and only a single relationship
failover endpoints between these two servers. There is a minimum of between any two servers. Given the integration of loadbalancing into
one TCP connection between one server and every other failover server the failover protocol, there is little value in having more than one
with which it implements the failover protocol. failover relationship between two servers, though the protocol will
support multiple relationships between two servers.
8.2. Creating the TCP connection
There are two ports used for initiating TCP connections, correspond- Each failover relationship MUST have a unique relationship-name, and
ing to the two roles that a server can fill with respect to another the relationship-name option is used to communicate this name in the
server. Every server implementing the failover protocol MUST listen CONNECT and CONNECTACK messages.
on at least one of these ports. Port 647 is the port to which pri-
mary servers will attempt a connection, and port 847 is the port to
which secondary servers will attempt a connection. When a connection
attempt is received on port 647, it is therefore from a primary
server, and the primary server is attempting to connect to this
secondary server. Likewise, when a connection attempt is received on
port 847, it is therefore from a secondary server, and the secondary
server is attempting to connect to this primary server." See the
schematic representation below:
Primary Server 8.2. Creating the TCP connection
--------------
Listens on port 847 for secondary server to connect to it
Periodically connects on port 647 to contact secondary
Secondary Server All failover TCP connections are initiated over port 647. Every
-------------- server implementing the failover protocol MUST listen on port 647.
Listens on port 647 for primary server to connect to it
Periodically connects on port 847 to contact primary
Every server implementing the failover protocol SHOULD attempt to Every server implementing the failover protocol SHOULD attempt to
connect to all of its partners periodically, where the period is connect to all of its partners periodically, where the period is
implementation dependent and SHOULD be configurable. In the event implementation dependent and SHOULD be configurable. In the event
that a connection has been rejected by a CONNECTACK message with a that a connection has been rejected by a CONNECTACK message with a
reject-reason option contained in it or a DISCONNECT message, a reject-reason option contained in it or a DISCONNECT message, a
server SHOULD reduce the frequency with which it attempts to connect server SHOULD reduce the frequency with which it attempts to connect
to that server but it SHOULD continue to attempt to connect periodi- to that server but it SHOULD continue to attempt to connect periodi-
cally. cally.
If a connection attempt has been received from another server in a When a connection attempt succeeds, if the server generating the
particular role (i.e., from a specific failover endpoint) then the connection attempt is a primary server for that relationship, then it
receiving server MUST NOT initiate a connection attempt to the MUST send a CONNECT message down the connection. If it is not a pri-
partner server in that same role. mary server for the relationship, then it MUST just drop the connec-
tion and wait for the primary server to connect to it.
If both servers happen to attempt to connect simultaneously, the When a connection attempt is received on port 647, the only informa-
secondary server MUST drop its attempt in favor of the primary's tion that the receiving server has is the IP address of the partner
attempt. Thus, in the event that a secondary server receives a con- initiating a connection. It also knows whether it has the primary
nection attempt to port 647 from a primary server when it has already role for any failover relationships with the connecting server. If
initiated a connection attempt to port 847 on the same primary it has any relationships for which it is a primary server, it should
server, it MUST accept the connection to port 647 and it MUST drop initiate a connection of its own to port 647 of the partner server,
drop the connection attempt to port 847. In the event that a primary one for each primary relationship it has with that server.
server receives a connection attempt to port 847 from a secondary
server when it has already initiated a connection attempt to port 647 If it has any relationships with the connecting server for which it
on that same server, it MUST reject the connection attempt to port is a seconary server, it should just await the CONNECT message to
847 and continue to pursue the connection attempt on port 647. determine which relationship this connection is to serve.
If it has no secondary relationships with the connecting server, it
SHOULD drop the connection.
To summarize -- a primary server MUST use a connection that it has
initiated in order to send a CONNECT message. Every server that is a
secondary server in a relationship attempts to create a connection to
the server which is primary in the relationship, but that connection
is only used to stimulate the primary server into recognizing that
the secondary server is ready for operation. The reason behind this
is that the secondary server has no way to communicate to the primary
server which relationship a connection is designed to serve.
A server which has multiple secondary relationships with a primary
server SHOULD only send one stimulus connection attempt to the pri-
mary server.
Once a connection is established, the primary server MUST send a CON- Once a connection is established, the primary server MUST send a CON-
NECT message across the connection. A secondary server MUST wait for NECT message across the connection. A secondary server MUST wait for
the CONNECT message from a primary server. the CONNECT message from a primary server. If the secondary server
doesn't receive a CONNECT message from the primary server in an ins-
tallation dependent amount of time, it MAY drop the connection and
send another stimulus connection attempt to the primary server.
Every CONNECT message includes a TLS-request option, and if the CON- Every CONNECT message includes a TLS-request option, and if the CON-
NECTACK message does not reject the CONNECT message and the TLS-reply NECTACK message does not reject the CONNECT message and the TLS-reply
option says TLS MUST be used, then the servers will immediately enter option says TLS MUST be used, then the servers will immediately enter
into TLS negotiation. into TLS negotiation.
Once TLS negotiation is complete, the primary server MUST resend the Once TLS negotiation is complete, the primary server MUST resend the
CONNECT message on the newly secured TLS connection and then wait for CONNECT message on the newly secured TLS connection and then wait for
the CONNECTACK message in response. The TLS-request and TLS-reply the CONNECTACK message in response. The TLS-request and TLS-reply
options MUST NOT appear in either this second CONNECT or its associ- options MUST NOT appear in either this second CONNECT or its associ-
skipping to change at page 85, line 5 skipping to change at page 84, line 51
leads to a requirement that the receiving server never block the leads to a requirement that the receiving server never block the
sending server from sending CONTACT messages. sending server from sending CONTACT messages.
In order to meet this requirement, each server tells the other server In order to meet this requirement, each server tells the other server
the number of outstanding BNDUPD messages that it will accept. The the number of outstanding BNDUPD messages that it will accept. The
receiving server is required to always be able to accept that many receiving server is required to always be able to accept that many
BNDUPD messages off of the connection's input queue even if it cannot BNDUPD messages off of the connection's input queue even if it cannot
process them immediately, and to accept all other messages immedi- process them immediately, and to accept all other messages immedi-
ately. ately.
Thus, the sending server's TCP is never blocked from sending a mes- Thus, the sending server's TCP is never blocked from sending a
sage except for very short periods, less than a few seconds unless message except for very short periods, less than a few seconds unless
the network connection itself has problems. In this case, if the the network connection itself has problems. In this case, if the
CONTACT messages don't make it to the partner then the partner will CONTACT messages don't make it to the partner then the partner will
close the connection. close the connection.
DISCUSSION: DISCUSSION:
When implementing this capability, one needs to be careful when When implementing this capability, one needs to be careful when
sending any message on the TCP connection as TCP can easily block sending any message on the TCP connection as TCP can easily block
the server if the local TCP send buffers are full. This can't be the server if the local TCP send buffers are full. This can't be
prevented because if the receiver is not reachable (via the net- prevented because if the receiver is not reachable (via the net-
skipping to change at page 86, line 52 skipping to change at page 86, line 50
Whenever a server makes a transition into a new state, it MUST record Whenever a server makes a transition into a new state, it MUST record
the state and the time at which it entered that state in stable the state and the time at which it entered that state in stable
storage. If communications is "ok", it MUST also send a STATE mes- storage. If communications is "ok", it MUST also send a STATE mes-
sage to its failover partner. sage to its failover partner.
Figure 9.2-1 is the diagram of the server state transitions. The Figure 9.2-1 is the diagram of the server state transitions. The
remainder of this section contains information important to the remainder of this section contains information important to the
understanding of that diagram. understanding of that diagram.
The server stays in the current state until all of the actions The server stays in the current state until all of the actions speci-
specified on the state transition are complete. If communications fied on the state transition are complete. If communications fails
fails during one of the actions, the server simply stays in the during one of the actions, the server simply stays in the current
current state and attempts a transition whenever the conditions for a state and attempts a transition whenever the conditions for a transi-
transition are later fulfilled. tion are later fulfilled.
In the state transition diagram below, the "+" or "-" in the upper In the state transition diagram below, the "+" or "-" in the upper
right corner of each state is a notation about whether communication right corner of each state is a notation about whether communication
is ongoing with the other server. is ongoing with the other server.
The legend "responsive", "balanced", or "unresponsive" in each state The legend "responsive", "balanced", or "unresponsive" in each state
indicates whether the server is responsive to all DHCP client indicates whether the server is responsive to all DHCP client
requests, running in load balanced mode, or totally unresponsive in requests, running in load balanced mode, or totally unresponsive in
the respective state. The terms "responsive" and "unresponsive" have the respective state. The terms "responsive" and "unresponsive" have
the obvious meanings, while "balanced" means that a DHCP server may the obvious meanings, while "balanced" means that a DHCP server may
respond to all DHCPREQUEST messages that are RENEWAL or REBINDING, respond to all DHCPREQUEST messages that are RENEWAL or REBINDING,
and to all other messages from clients for which the load balancing and to all other messages from clients for which the load balancing
algorithm indicates that it MUST respond to. See sections 5.3 and algorithm indicates that it MUST respond to. See sections 5.3 and
9.8.2 for details on load balancing. 9.8.2 for details on load balancing.
Note that in situations where a server does not respond to a DHCP
client message, it MUST NOT remember any of the information from that
message.
In the state transition diagram below, when communication is reesta- In the state transition diagram below, when communication is reesta-
blished between the two servers, each must record the state of the blished between the two servers, each must record the state of the
partner when communication was restored. State transitions on one partner when communication was restored. State transitions on one
server in some cases imply state transitions on the partner server, server in some cases imply state transitions on the partner server,
so a record of the current state of the partner server must be kept so a record of the current state of the partner server must be kept
by each server. by each server.
If the state of the partner changes while communicating a server If the state of the partner changes while communicating a server
moves through the communications-failed transition and into whatever moves through the communications-failed transition and into whatever
state results. It then immediately moves through whatever state state results. It then immediately moves through whatever state
skipping to change at page 131, line 26 skipping to change at page 131, line 26
16. Author's information 16. Author's information
Ralph Droms Ralph Droms
Kim Kinnear Kim Kinnear
Mark Stapp Mark Stapp
Cisco Systems Cisco Systems
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: (978) 244-8000 Phone: (978) 497-0000
EMail: rdroms@cisco.com EMail: rdroms@cisco.com
kkinnear@cisco.com kkinnear@cisco.com
mjs@cisco.com mjs@cisco.com
Bernie Volz Bernie Volz
Ericsson Ericsson
959 Concord St. 959 Concord St.
Framingham, MA 01701 Framingham, MA 01701
Phone: +1-617-513-9060 Phone: (508) 875-3162
EMail: bernie.volz@ericsson.com EMail: bernie.volz@ericsson.com
Steve Gonczi Steve Gonczi
Relicore, Inc. Relicore, Inc.
One Wall Street One Wall Street
Burlington, MA 01803 Burlington, MA 01803
Phone: (781) 229-1122 Phone: (781) 229-1122
Email: steve@relicore.com Email: steve@relicore.com
Greg Rabil, Mike Dooley, Arun Kapur Greg Rabil
Lucent Technologies Lucent Technologies
400 Lapp Road 400 Lapp Road
Malvern, PA 19355 Malvern, PA 19355
Phone: (800) 208-2747 Phone: (800) 208-2747
EMail: grabil@lucent.com EMail: grabil@lucent.com
mdooley@lucent.com
akapur@lucent.com Michael Dooley
Diamond IP Technologies
One E Uwchlan Ave, Suite 112
Exton, PA 19341
EMail: mdooley@diamondip.com
Arun Kapur
K5 Networks
2 Toll House Lane
Colts Neck, NJ 07722
Phone: (732) 817-9475
17. Full Copyright Statement 17. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to oth- This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis- assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations, references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
 End of changes. 

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