draft-ietf-dhc-failover-08.txt   draft-ietf-dhc-failover-09.txt 
Network Working Group Ralph Droms Network Working Group Ralph Droms
INTERNET DRAFT Kim Kinnear INTERNET DRAFT Kim Kinnear
Mark Stapp Mark Stapp
Cisco Systems Cisco Systems
Bernie Volz Bernie Volz
IPWorks Ericsson
Steve Gonczi Steve Gonczi
Network Engines Network Engines
Greg Rabil Greg Rabil
Mike Dooley Mike Dooley
Arun Kapur Arun Kapur
Lucent Technologies Lucent Technologies
July 2000 July 2001
Expires January 2001 Expires January 2002
DHCP Failover Protocol DHCP Failover Protocol
<draft-ietf-dhc-failover-08.txt> <draft-ietf-dhc-failover-09.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 1, line 48
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 (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). 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
in case of failover. in case of failover.
This document defines a protocol to provide such synchronization This document defines a protocol to provide such 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. This document also describes a the other is the "secondary" server. This document also describes a
way to integrate the failover protocol with the DHCP load balancing way to integrate the failover protocol with the DHCP load balancing
approach. approach.
This document is a substantial reorganization as well as a technical
and editorial revision of draft-ietf-dhc-failover-05.txt.
Table of Contents Table of Contents
1. Introduction................................................. 4 1. Introduction................................................. 4
2. Terminology.................................................. 5 2. Terminology.................................................. 5
2.1. Requirements terminology................................... 5 2.1. Requirements terminology................................... 5
2.2. DHCP and failover terminology.............................. 5 2.2. DHCP and failover terminology.............................. 5
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........................................ 17
5.2. Fundamental guarantees..................................... 20 5.2. Fundamental guarantees..................................... 20
5.3. Load balancing............................................. 26 5.3. Load balancing............................................. 27
5.4. IP address allocations between servers..................... 27 5.4. IP address allocations between servers..................... 28
5.5. Operating in NORMAL state.................................. 29 5.5. Operating in NORMAL state.................................. 30
5.6. Operating in COMMUNICATIONS-INTERRUPTED state.............. 29 5.6. Operating in COMMUNICATIONS-INTERRUPTED state.............. 31
5.7. Operating in PARTNER-DOWN state............................ 30 5.7. Operating in PARTNER-DOWN state............................ 31
5.8. Operating in RECOVER state................................. 30 5.8. Operating in RECOVER state................................. 31
5.9. Operating in STARTUP state................................. 30 5.9. Operating in STARTUP state................................. 31
5.10. Time synchronization between servers...................... 30 5.10. Time synchronization between servers...................... 32
5.11. IP address binding-status................................. 31 5.11. IP address binding-status................................. 32
5.12. DNS dynamic update considerations......................... 35 5.12. DNS dynamic update considerations......................... 36
5.13. Reservations and failover................................. 39 5.13. Reservations and failover................................. 41
5.14. Dynamic BOOTP and failover................................ 41 5.14. Dynamic BOOTP and failover................................ 42
5.15. Guidelines for selecting MCLT............................. 41 5.15. Guidelines for selecting MCLT............................. 43
5.16. What is sent in response to an UPDREQ or UPDREQALL message? 42 5.16. What is sent in response to an UPDREQ or UPDREQALL message? 43
6. Common Message Format........................................ 43 5.17. How do you determine that your partner is "up to date" for 45
6.1. Message header format...................................... 43 6. Common Message Format........................................ 45
6.2. Common option format....................................... 46 6.1. Message header format...................................... 46
6.3. Batching multiple binding update transactions in one BNDUPD mes- 47 6.2. Common option format....................................... 48
7. Protocol Messages............................................ 49 6.3. Batching multiple binding update transactions in one BNDUPD mes- 49
7.1. BNDUPD message [3]......................................... 49 7. Protocol Messages............................................ 51
7.2. BNDACK message [4]......................................... 60 7.1. BNDUPD message [3]......................................... 51
7.3. UPDREQ message [9]......................................... 63 7.2. BNDACK message [4]......................................... 62
7.4. UPDREQALL message [7]...................................... 64 7.3. UPDREQ message [9]......................................... 65
7.5. UPDDONE message [8]........................................ 65 7.4. UPDREQALL message [7]...................................... 66
7.6. POOLREQ message [1]........................................ 65 7.5. UPDDONE message [8]........................................ 67
7.7. POOLRESP message [2]....................................... 66 7.6. POOLREQ message [1]........................................ 68
7.8. CONNECT message [5]........................................ 67 7.7. POOLRESP message [2]....................................... 69
7.9. CONNECTACK message [6]..................................... 71 7.8. CONNECT message [5]........................................ 70
7.10. STATE message [10]........................................ 75 7.9. CONNECTACK message [6]..................................... 74
7.11. CONTACT message [11]...................................... 76 7.10. STATE message [10]........................................ 78
7.12. DISCONNECT message [12]................................... 76 7.11. CONTACT message [11]...................................... 79
8. Connection Management........................................ 77 7.12. DISCONNECT message [12]................................... 80
8.1. Connection granularity..................................... 78 8. Connection Management........................................ 81
8.2. Creating the TCP connection................................ 78 8.1. Connection granularity..................................... 81
8.3. Using the TCP connection for determining communications status 80 8.2. Creating the TCP connection................................ 81
8.4. Using the TCP connection for binding data.................. 82 8.3. Using the TCP connection for determining communications status 83
8.5. Using the TCP connection for control messages.............. 82 8.4. Using the TCP connection for binding data.................. 85
8.6. Losing the TCP connection.................................. 82 8.5. Using the TCP connection for control messages.............. 85
9. Failover Endpoint States..................................... 83 8.6. Losing the TCP connection.................................. 85
9.1. Server Initialization...................................... 83 9. Failover Endpoint States..................................... 86
9.2. Server State Transitions................................... 83 9.1. Server Initialization...................................... 86
9.3. STARTUP state.............................................. 86 9.2. Server State Transitions................................... 86
9.4. PARTNER-DOWN state......................................... 88 9.3. STARTUP state.............................................. 90
9.5. RECOVER state.............................................. 90 9.4. PARTNER-DOWN state......................................... 93
9.6. NORMAL state............................................... 93 9.5. RECOVER state.............................................. 95
9.7. COMMUNICATIONS-INTERRUPTED State........................... 95 9.6. RECOVER-WAIT state......................................... 97
9.8. POTENTIAL-CONFLICT state................................... 99 9.7. RECOVER-DONE state......................................... 98
9.9. RESOLUTION-INTERRUPTED state............................... 100 9.9. COMMUNICATIONS-INTERRUPTED State........................... 101
9.10. CONFLICT-DONE state....................................... 101 9.10. POTENTIAL-CONFLICT state.................................. 105
9.12. PAUSED state.............................................. 102 9.11. RESOLUTION-INTERRUPTED state.............................. 107
9.13. SHUTDOWN state............................................ 103 9.12. CONFLICT-DONE state....................................... 108
10. Safe Period................................................. 104 9.13. PAUSED state.............................................. 108
11. Security.................................................... 105 9.14. SHUTDOWN state............................................ 109
11.1. Simple shared secret...................................... 106 10. Safe Period................................................. 110
11.2. TLS....................................................... 107 11. Security.................................................... 111
12. Failover Options............................................ 107 11.1. Simple shared secret...................................... 112
12.1. addresses-transferred..................................... 108 11.2. TLS....................................................... 113
12.2. assigned-IP-address....................................... 108 12. Failover Options............................................ 113
12.3. binding-status............................................ 108 12.1. addresses-transferred..................................... 114
12.4. client-identifier......................................... 109 12.2. assigned-IP-address....................................... 114
12.5. client-hardware-address................................... 109 12.3. binding-status............................................ 114
12.6. client-last-transaction-time.............................. 109 12.4. client-identifier......................................... 115
12.7. client-reply-options...................................... 110 12.5. client-hardware-address................................... 115
12.8. client-request-options.................................... 110 12.6. client-last-transaction-time.............................. 115
12.9. DDNS...................................................... 111 12.7. client-reply-options...................................... 116
12.10. delayed-service-parameter................................ 112 12.8. client-request-options.................................... 116
12.11. hash-bucket-assignment................................... 112 12.9. DDNS...................................................... 117
12.12. IP-flags................................................. 113 12.10. delayed-service-parameter................................ 118
12.13. lease-expiration-time.................................... 114 12.11. hash-bucket-assignment................................... 118
12.14. max-unacked-bndupd....................................... 114 12.12. IP-flags................................................. 119
12.15. MCLT..................................................... 114 12.13. lease-expiration-time.................................... 120
12.16. message.................................................. 115 12.14. max-unacked-bndupd....................................... 120
12.17. message-digest........................................... 115 12.15. MCLT..................................................... 120
12.18. potential-expiration-time................................ 115 12.16. message.................................................. 121
12.19. receive-timer............................................ 116 12.17. message-digest........................................... 121
12.20. protocol-version......................................... 116 12.18. potential-expiration-time................................ 122
12.21. reject-reason............................................ 117 12.19. receive-timer............................................ 122
12.22. sending-server-IP-address................................ 118 12.20. protocol-version......................................... 122
12.23. server-flags............................................. 118 12.21. reject-reason............................................ 123
12.24. server-state............................................. 119 12.22. relationship-name........................................ 124
12.25. start-time-of-state...................................... 119 12.23. server-flags............................................. 124
12.26. TLS-reply................................................ 120 12.24. server-state............................................. 125
12.27. TLS-request.............................................. 120 12.25. start-time-of-state...................................... 125
12.28. vendor-class-identifier.................................. 120 12.26. TLS-reply................................................ 126
12.29. vendor-specific-options.................................. 121 12.27. TLS-request.............................................. 126
13. IANA Considerations......................................... 121 12.28. vendor-class-identifier.................................. 126
14. Acknowledgments............................................. 121 12.29. vendor-specific-options.................................. 127
15. References.................................................. 123 13. IANA Considerations......................................... 127
16. Author's information........................................ 124 14. Acknowledgments............................................. 127
17. Full Copyright Statement.................................... 125 15. References.................................................. 129
16. Author's information........................................ 131
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 net-
work infrastructure. work 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
cooperating primary and secondary servers must maintain a consistent cooperating primary and secondary servers must maintain a consistent
database of lease information. This implies that servers will need database of lease information. This implies that servers will need
to coordinate all lease activity so that this information is syn- to coordinate all lease activity so that this information is syn-
chronized in case failover is required. The protocol messages and chronized in case failover is required. The protocol messages and
processing techniques required to maintain a consistent database are processing techniques required to maintain a consistent database are
specified in the protocol described here. specified in the protocol described here.
The failover protocol also contains a way to integrate the DHCP load- The failover protocol also contains a way to integrate the DHCP load-
balancing algorithm described in [LOADB] with the failover protocol. balancing algorithm described in [RFC 3074] with the failover proto-
col.
2. Terminology 2. Terminology
This section discusses both the generic requirements terminology com- This section discusses both the generic requirements terminology com-
mon to many IETF protocol specifications as well as specialized DHCP mon to many IETF protocol specifications as well as specialized DHCP
and failover protocol specific terminology. and failover protocol specific terminology.
2.1. Requirements terminology 2.1. Requirements terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 8, line 25 skipping to change at page 8, line 28
DHCP clients for a particular set of subnet address pools. DHCP clients for a particular set of subnet address pools.
o "RR" o "RR"
"RR" is an abbreviation for "resource record". All records in "RR" is an abbreviation for "resource record". All records in
the DNS are resource records. The resource records of most the DNS are resource records. The resource records of most
relevance to this document are the "A" resource record, which relevance to this document are the "A" resource record, which
maps a DNS name to a particular IP address, the "PTR" resource maps a DNS name to a particular IP address, the "PTR" resource
record, which allows a "reverse map", from the IP address back record, which allows a "reverse map", from the IP address back
to a DNS name, and the "KEY" resource record, which is used in to a DNS name, and the "KEY" resource record, which is used in
ways defined in [DDNS] to tag a DNS name with the identity of ways defined in [FQDN] to tag a DNS name with the identity of
the DHCP client with which it is associated. the DHCP client with which it is associated.
o "Secondary server" or "Secondary" o "Secondary server" or "Secondary"
A DHCP server configured to act as backup to a primary server A DHCP server configured to act as backup to a primary server
for a particular set of subnet address pools. for a particular set of subnet address pools.
o "stable storage" o "stable storage"
Every DHCP server is assumed to have some form of what is called Every DHCP server is assumed to have some form of what is called
skipping to change at page 8, line 50 skipping to change at page 9, line 4
o "state" o "state"
In this document, the term "state" refers exclusively to the In this document, the term "state" refers exclusively to the
state of a failover endpoint, for example: NORMAL, state of a failover endpoint, for example: NORMAL,
COMMUNICATIONS-INTERRUPTED, PARTNER-DOWN. It is not used to COMMUNICATIONS-INTERRUPTED, PARTNER-DOWN. It is not used to
refer to any attributes of an IP address or a binding of an IP refer to any attributes of an IP address or a binding of an IP
address. See "binding-status". address. See "binding-status".
o "subnet address pool" o "subnet address pool"
A subnet address pool is the set of IP addresses which is asso-
A subnet address pool is the set of IP addresses which is ciated with a particular network number and subnet mask. In the
associated with a particular network number and subnet mask. In simple case, there is a single network number and subnet mask
the simple case, there is a single network number and subnet and a set of IP addresses. In the more complex case (sometimes
mask and a set of IP addresses. In the more complex case (some- called "secondary subnets", sometimes "superscopes"), several
times called "secondary subnets", sometimes "superscopes"), (apparently unrelated) network number and subnet mask combina-
several (apparently unrelated) network number and subnet mask tions with their associated IP addresses may all be configured
combinations with their associated IP addresses may all be con- together into one subnet address pool.
figured together into one subnet address pool.
3. Background and External Requirements 3. Background and External Requirements
This section highlights key aspects of the DHCP protocol on which the This section highlights key aspects of the DHCP protocol on which the
failover protocol depends. It also discusses the requirements that failover protocol depends. It also discusses the requirements that
the failover protocol places on other aspects of the network infras- the failover protocol places on other aspects of the network infras-
tructure, and some general issues surrounding server failure detec- tructure, and some general issues surrounding server failure detec-
tion. Some failure scenarios that provide particular challenges to a tion. Some failure scenarios that provide particular challenges to a
failover protocol are discussed. Finally, the challenges inherent in failover protocol are discussed. Finally, the challenges inherent in
using a TCP connection as a means to detect failure of a partner using a TCP connection as a means to detect failure of a partner
skipping to change at page 12, line 52 skipping to change at page 13, line 5
which a DHCP client can communicate voluntarily shut itself down which a DHCP client can communicate voluntarily shut itself down
seems like something worth avoiding. seems like something worth avoiding.
The failover protocol will operate correctly while both servers are The failover protocol will operate correctly while both servers are
unable to communicate, whether they are both running or not. At some unable to communicate, whether they are both running or not. At some
point there may be resource contention, and if one of the servers is point there may be resource contention, and if one of the servers is
actually down, then the operator can inform the operational server actually down, then the operator can inform the operational server
and the operational server will be able to use all of the failed and the operational server will be able to use all of the failed
server's resources. server's resources.
The protocol also allows detection of an orderly shutdown of a The protocol also allows detection of an orderly shutdown of a parti-
participating server. cipating server.
3.4. Challenging scenarios for a Failover protocol 3.4. Challenging scenarios for a Failover protocol
There exist two failure scenarios which provide particular challenges There exist two failure scenarios which provide particular challenges
to the correctness guarantees of a failover protocol. to the correctness guarantees of a failover protocol.
3.4.1. Primary Server crash before "lazy" update: 3.4.1. Primary Server crash before "lazy" update:
In the case where the primary server sends a DHCPACK to a client for In the case where the primary server sends a DHCPACK to a client for
a newly allocated IP address and then crashes prior to sending the a newly allocated IP address and then crashes prior to sending the
skipping to change at page 13, line 28 skipping to change at page 13, line 30
different client. In the case where the first client to receive the different client. In the case where the first client to receive the
IP address is not on the net at the time (yet while there was still IP address is not on the net at the time (yet while there was still
time to run on its lease), an ICMP echo (i.e., ping) will not prevent time to run on its lease), an ICMP echo (i.e., ping) will not prevent
the secondary server from allocating that IP address to a different the secondary server from allocating that IP address to a different
client. client.
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.
A more likely (in that DHCPRENEWs are presumably more common than A more likely (in that DHCPREQUEST/RENEWs are presumably more common
DHCPDISCOVERs) and more subtle version of this problem is where the than DHCPDISCOVERs) and more subtle version of this problem is where
primary server crashes after extending a client's lease time, and the primary server crashes after extending a client's lease time, and
before updating the secondary with a new time using a lazy update. before updating the secondary with a new time using a lazy update.
After the secondary takes over, if the client is not connected to the After the secondary takes over, if the client is not connected to the
network the secondary will believe the client's lease has expired network the secondary will believe the client's lease has expired
when, in fact, it has not. In this case as well, the IP address when, in fact, it has not. In this case as well, the IP address
might be reallocated to a different client while the first client is might be reallocated to a different client while the first client is
still using it. still using it.
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.
skipping to change at page 14, line 26 skipping to change at page 14, line 27
for both bulk data transfer as well as to assess communications for both bulk data transfer as well as to assess communications
integrity with the other server. Reliable and ordered message integrity with the other server. Reliable and ordered message
delivery are chief among these important characteristics. delivery are chief among these important characteristics.
It would be nice to use the capabilities built in to TCP to allow it It would be nice to use the capabilities built in to TCP to allow it
to determine if communications integrity exists to the failover to determine if communications integrity exists to the failover
partner but this strategy contains some problems which require partner but this strategy contains some problems which require
analysis. There exist three fundamental cases for an open TCP con- analysis. There exist three fundamental cases for an open TCP con-
nection that must be examined. nection that must be examined.
1. When no data is being sent then no messages are traveling 1. When no data is being sent on a TCP connection, the TCP layer
across the TCP connection. also does not exchange any signaling messages to assure that
the peer is still up.
2. When data is queued to be sent, and the receiver has not 2. When data is queued to be sent, and the receiver has not
blocked the sending of additional data, then messages are blocked the sending of additional data, then messages are
flowing across the TCP connection containing the applications flowing across the TCP connection containing the applications
data. data.
3. When data is queued to be sent, and the receiver has blocked 3. When data is queued to be sent, and the receiver has blocked
the transmission of additional data, then persist messages are the transmission of additional data, then persist messages are
flowing from the receiver to the sender to ensure that the flowing from the receiver to the sender to ensure that the
sender doesn't miss the receiver opening the window for sender doesn't miss the receiver opening the window for
skipping to change at page 14, line 51 skipping to change at page 15, line 5
application-level keep-alive messages periodically when there is no application-level keep-alive messages periodically when there is no
other data queued to be sent. Note TCP keep-alive messages might be other data queued to be sent. Note TCP keep-alive messages might be
used as well, but they present additional problems. used as well, but they present additional problems.
Thus, we can ensure that the TCP connection has messages flowing Thus, we can ensure that the TCP connection has messages flowing
periodically across the connection fairly easily. The question periodically across the connection fairly easily. The question
remains as to what TCP will do if the other end of the connection remains as to what TCP will do if the other end of the connection
fails to respond (either because of network partition or because the fails to respond (either because of network partition or because the
receiving server crashes). TCP will attempt to retransmit a message receiving server crashes). TCP will attempt to retransmit a message
with an exponential backoff, and will eventually timeout that with an exponential backoff, and will eventually timeout that
retransmission. However, the length of that timeout cannot, in retransmission. However, the length of that timeout cannot, in gen-
general, be set on a per-connection basis, and is frequently as long eral, be set on a per-connection basis, and is frequently as long as
as nine minutes, though in some cases it may be as short as two nine minutes, though in some cases it may be as short as two minutes.
minutes. On some systems it can be set system-wide, while on other On some systems it can be set system-wide, while on other systems it
systems it cannot be changed at all. cannot be changed at all.
A value for this timeout that would be appropriate for the failover A value for this timeout that would be appropriate for the failover
protocol, say less than 1 minute, could have unpleasant side-effects protocol, say less than 1 minute, could have unpleasant side-effects
on other applications running on the same server, assuming that it on other applications running on the same server, assuming that it
could be changed at all on the host operating system. could be changed at all on the host operating system.
Nine minutes is a long time for the DHCP service to be unavailable to Nine minutes is a long time for the DHCP service to be unavailable to
any new clients that were being served by the server which has any new clients that were being served by the server which has
crashed, when there is another server running that could respond to crashed, when there is another server running that could respond to
them as soon as it determines that its partner is not operational. them as soon as it determines that its partner is not operational.
skipping to change at page 15, line 38 skipping to change at page 15, line 40
This section lists the design goals and the limitations of the fail- This section lists the design goals and the limitations of the fail-
over protocol. over protocol.
4.1. Design goals for this protocol 4.1. Design goals for this protocol
The following is a list of goals that are met by this protocol. They The following is a list of goals that are met by this protocol. They
are listed in priority order. are listed in priority order.
1. Implementations of this protocol must work with existing DHCP 1. Implementations of this protocol must work with existing DHCP
client implementations based on the DHCP protocol [1]. client implementations based on the DHCP protocol [RFC 2131].
2. Implementations of the protocol must work with existing BOOTP 2. Implementations of the protocol must work with existing BOOTP
relay agent implementations. relay agent implementations.
3. The protocol must provide failover redundancy between servers 3. The protocol must provide failover redundancy between servers
that are not located on the same subnet. that are not located on the same subnet.
4. Provide for continued service to DHCP clients through an 4. Provide for continued service to DHCP clients through an
automated mechanism in the event of failure of the primary automated mechanism in the event of failure of the primary
server. server.
skipping to change at page 16, line 49 skipping to change at page 16, line 52
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 granu- client population served by each with a moderately fine
larity. granularity.
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 18, line 17 skipping to change at page 18, line 19
The binding update (BNDUPD) message is used to send the binding The binding update (BNDUPD) message is used to send the binding
database changes to the partner server, and the partner server database changes to the partner server, and the partner server
responds with a binding acknowledgement (BNDACK) message when it responds with a binding acknowledgement (BNDACK) message when it
has successfully committed those changes to its own stable has successfully committed those changes to its own stable
storage. storage.
All of the other messages involve ancillary issues: All of the other messages involve ancillary issues:
o Management of available IP addresses o Management of available IP addresses
The pool request (POOLREQ) is used by the secondary server to The pool request (POOLREQ) message is used by the secondary
request an allocation of IP addresses from the primary server. server to request an allocation of IP addresses from the primary
The pool response (POOLRESP) is used by the primary server to server. The pool response (POOLRESP) message is used by the
inform the secondary server how many IP addresses were allocated primary server to inform the secondary server how many IP
to the secondary server as the result of the pool request. addresses were allocated to the secondary server as the result
of the pool request.
o Synchronization of the binding databases between the servers o Synchronization of the binding databases between the servers
after they've been out of communications after they've been out of communications
The update request (UPDREQ) message is used by one server to The update request (UPDREQ) message is used by one server to
request that its partner send it all binding database informa- request that its partner send it all binding database informa-
tion that it has not already seen. The update request all tion that it has not already seen. The update request all
(UPDREQALL) message is used by one server to request that all (UPDREQALL) message is used by one server to request that all
binding database information be sent in order to recover from a binding database information be sent in order to recover from a
total loss of its binding database by the requesting server. total loss of its binding database by the requesting server.
skipping to change at page 20, line 51 skipping to change at page 21, line 7
not exceed the MCLT beyond the potential expiration time acknowledged not exceed the MCLT beyond the potential expiration time acknowledged
by its partner. by its partner.
The PARTNER-DOWN state exists so that a server can be sure that its The PARTNER-DOWN state exists so that a server can be sure that its
partner is, indeed, down. Correct operation while in that state partner is, indeed, down. Correct operation while in that state
requires (generally) that the server wait the MCLT after anything requires (generally) that the server wait the MCLT after anything
that happened prior to its transition into PARTNER-DOWN state (or, that happened prior to its transition into PARTNER-DOWN state (or,
more accurately, when the other server went down if that is known). more accurately, when the other server went down if that is known).
Thus, the server MUST wait the MCLT after the partner server went Thus, the server MUST wait the MCLT after the partner server went
down before allocating any of the partner's addresses which were down before allocating any of the partner's addresses which were
available for allocation. In the event the partner was not in available for allocation. In the event the partner was not in com-
communication prior to going down, it might have allocated one or munication prior to going down, it might have allocated one or more
more of its FREE addresses to a DHCP client and been unable to inform of its FREE addresses to a DHCP client and been unable to inform the
the server entering PARTNER-DOWN prior to going down itself. By server entering PARTNER-DOWN prior to going down itself. By waiting
waiting the MCLT after the time the partner went down, the server in the MCLT after the time the partner went down, the server in
PARTNER-DOWN state ensures that any clients which have a lease on one PARTNER-DOWN state ensures that any clients which have a lease on one
of the partner's FREE addresses will either time out or contact the of the partner's FREE addresses will either time out or contact the
server in PARTNER-DOWN by the time that period ends. server in PARTNER-DOWN by the time that period ends.
In addition, once a server has transitioned to PARTNER-DOWN state, it In addition, once a server has made a transition to PARTNER-DOWN
MUST NOT reallocate an IP address from one client to another client state, it MUST NOT reallocate an IP address from one client to
until an additional MCLT interval after the lease by the original another client until the longer of the following two times:
client expires. (Actually, until the maximum client lead time after
what it believes to be the lease expiration time of the client.) o The MCLT after the time the partner server went down (see
above).
o An additional MCLT interval after the lease by the original
client expires. (Actually, until the maximum client lead time
after what it believes to be the lease expiration time of the
client.)
Some optimizations exist for this restriction, in that it only Some optimizations exist for this restriction, in that it only
applies to leases that were issued BEFORE entering PARTNER-DOWN. Once applies to leases that were issued BEFORE entering PARTNER-DOWN. Once
a server has entered PARTNER-DOWN and it leases out an address, it a server has entered PARTNER-DOWN and it leases out an address, it
need not wait this time as long as it has never communicated with the need not wait this time as long as it has never communicated with the
partner since the lease was given out. partner since the lease was given out.
The fundamental relationship on which much of the correctness of this The fundamental relationship on which much of the correctness of this
protocol depends is that the lease expiration time known to a DHCP protocol depends is that the lease expiration time known to a DHCP
client MUST NOT be more than the maximum client lead time greater client MUST NOT be more than the maximum client lead time greater
skipping to change at page 21, line 41 skipping to change at page 22, line 4
This protocol requires a DHCP server to deal with several different This protocol requires a DHCP server to deal with several different
lease intervals and places specific restrictions on their relation- lease intervals and places specific restrictions on their relation-
ships. The purpose of these restrictions is to allow the other server ships. The purpose of these restrictions is to allow the other server
in the pair to be able to make certain assumptions in the absence of in the pair to be able to make certain assumptions in the absence of
an ability to communicate between servers. an ability to communicate between servers.
The different lease times are: The different lease times are:
o desired lease interval o desired lease interval
The desired lease interval is the lease interval that a DHCP server
The desired lease interval is the lease interval that a DHCP would like to give to a DHCP client in the absence of any restric-
server would like to give to a DHCP client in the absence of any tions imposed by the Failover protocol. Its determination is out-
restrictions imposed by the Failover protocol. Its determina- side of the scope of this protocol. Typically this is the result of
tion is outside of the scope of this protocol. Typically this is external configuration of a DHCP server.
the result of external configuration of a DHCP server.
o actual lease interval o actual lease interval
The actual lease internal is the lease interval that a DHCP The actual lease internal is the lease interval that a DHCP server
server gives out to a DHCP client in the dhcp-lease-time option gives out to a DHCP client in the dhcp-lease-time option of a
of a DHCPACK packet. It may be shorter than the desired client DHCPACK packet. It may be shorter than the desired client lease
lease interval (as explained below). interval (as explained below).
o potential lease interval o potential lease interval
The potential lease interval is the lease expiration interval The potential lease interval is the lease expiration interval the
the local server tells to its partner in the potential- local server tells to its partner in the potential-expiration-time
expiration-time option of a BNDUPD message. option of a BNDUPD message.
o acknowledged potential lease interval o acknowledged potential lease interval
The acknowledged potential lease interval is the potential lease The acknowledged potential lease interval is the potential lease
interval the partner server has most recently acknowledged in interval the partner server has most recently acknowledged in the
the potential-expiration-time option of a BNDACK message. potential-expiration-time option of a BNDACK message.
The key restriction (and guarantee) that any server makes with The key restriction (and guarantee) that any server makes with
respect to lease intervals is that the actual client lease interval respect to lease intervals is that the actual client lease interval
never exceeds the acknowledged potential lease interval (if any) by never exceeds the acknowledged potential lease interval (if any) by
more than a fixed amount. This fixed amount is called the "Maximum more than a fixed amount. This fixed amount is called the "Maximum
Client Lead Time" (MCLT). Client Lead Time" (MCLT).
The MCLT MAY be configurable on the primary server, but for correct The MCLT MAY be configurable on the primary server, but for correct
server operation it MUST be the same and known to both the primary server operation it MUST be the same and known to both the primary
and secondary servers. The secondary server determines the MCLT from and secondary servers. The secondary server determines the MCLT from
skipping to change at page 23, line 12 skipping to change at page 24, line 12
only one example -- as long as the fundamental relationship is only one example -- as long as the fundamental relationship is
preserved, the actual times used could be quite different. preserved, the actual times used could be quite different.
DHCP Primary Secondary DHCP Primary Secondary
time Client Server Server time Client Server Server
| (time in intervals) | (absolute time) | | (time in intervals) | (absolute time) |
| | | | | |
| >-DHCPDISCOVER-> | | | >-DHCPDISCOVER-> | |
| <---DHCPOFFER-< | | | <---DHCPOFFER-< | |
| lease-time=MCLT | |
| | | | | |
| >-DHCPREQUEST-> | | | >-DHCPREQUEST-> | |
| (selecting) | | | (selecting) | |
| | | | | |
t | <--------DHCPACK-< | | t | <--------DHCPACK-< | |
| lease-time=MCLT | | | lease-time=MCLT | |
| | >-BNDUPD--> | | | >-BNDUPD--> |
| | lease-expiration=t+MCLT | | lease-expiration=t+MCLT
| | potential-expiration=t+(MCLT/2)+X | | potential-expiration=t+(MCLT/2)+X
| | | | | |
skipping to change at page 23, line 50 skipping to change at page 25, line 4
X = Desired Lease Interval X = Desired Lease Interval
Assumes renewal interval = lease interval / 2 Assumes renewal interval = lease interval / 2
DISCUSSION: DISCUSSION:
This protocol mandates only that the above fundamental relation- This protocol mandates only that the above fundamental relation-
ship concerning lease intervals is preserved. ship concerning lease intervals is preserved.
In the interests of clarity, however, let's examine a specific In the interests of clarity, however, let's examine a specific
example. The MCLT in this case is 1 hour. The desired lease example. The MCLT in this case is 1 hour. The desired lease
interval is 3 days, and its renewal time is half the lease interval is 3 days, and its renewal time is half the lease inter-
interval. val.
The rules for this example are: The rules for this example are:
o What to tell the client: o What to tell the client:
Take the remainder of the acknowledged potential lease interval. Take the remainder of the acknowledged potential lease interval.
If this is a new lease, then this value will be zero. If this If this is a new lease, then this value will be zero. If this
remainder plus the MCLT is greater than the desired lease inter- remainder plus the MCLT is greater than the desired lease inter-
val, give the client the desired lease interval else give the val, give the client the desired lease interval else give the
client the remainder plus the MCLT. client the remainder plus the MCLT.
skipping to change at page 24, line 40 skipping to change at page 25, line 41
DHCP client, it determines the desired lease interval (in this DHCP client, it determines the desired lease interval (in this
case, 3 days). It then examines the acknowledged potential lease case, 3 days). It then examines the acknowledged potential lease
interval (which in this case is zero) and determines the remainder interval (which in this case is zero) and determines the remainder
of the time left to run, which is also zero. To this it adds the of the time left to run, which is also zero. To this it adds the
MCLT. Since the actual lease interval cannot be allowed to exceed MCLT. Since the actual lease interval cannot be allowed to exceed
the remainder of the current acknowledged potential lease interval the remainder of the current acknowledged potential lease interval
plus the MCLT, the offer made to the client is for the remainder plus the MCLT, the offer made to the client is for the remainder
of the current acknowledged potential lease interval (i.e., zero) of the current acknowledged potential lease interval (i.e., zero)
plus the MCLT. Thus, the actual lease interval is 1 hour. plus the MCLT. Thus, the actual lease interval is 1 hour.
Once the server has performed the BNDACK to the DHCP client, it Once the server has performed the DHCPACK to the DHCP client, it
will update the secondary server with the lease information. How- will update the secondary server with the lease information. How-
ever, the desired potential lease interval will be composed of the ever, the desired potential lease interval will be composed of one
one half of the current actual lease interval added to the desired half of the current actual lease interval added to the desired
lease interval. Thus, the secondary server is updated with a lease interval. Thus, the secondary server is updated with a
BNDUPD with a lease interval of 3 days + 1/2 hour specified in the BNDUPD with a lease interval of 3 days + 1/2 hour specified in the
potential-expiration-time option. potential-expiration-time option.
When the primary server receives an ACK to its update of the When the primary server receives a BNDACK to its update of the
secondary server's (partner's) potential lease interval, it secondary server's (partner's) potential lease interval, it
records that as the acknowledged potential lease interval. A records that as the acknowledged potential lease interval. A
server MUST NOT send a BNDACK in response to a BNDUPD message server MUST NOT send a BNDACK in response to a BNDUPD message
until it is sure that the information in the BNDUPD message until it is sure that the information in the BNDUPD message
resides in its stable storage. Thus, the primary server in this resides in its stable storage. Thus, the primary server in this
case can be sure that the secondary server has recorded the poten- case can be sure that the secondary server has recorded the poten-
tial lease interval in its stable storage when the primary server tial lease interval in its stable storage when the primary server
receives a BNDACK message from the secondary server. receives a BNDACK message from the secondary server.
When the DHCP client attempts to renew at T1 (approximately one When the DHCP client attempts to renew at T1 (approximately one
skipping to change at page 25, line 42 skipping to change at page 26, line 43
Once the initial actual client lease interval of the MCLT is past, Once the initial actual client lease interval of the MCLT is past,
the protocol operates effectively like the DHCP protocol does the protocol operates effectively like the DHCP protocol does
today in its behavior concerning lease intervals. However, the today in its behavior concerning lease intervals. However, the
guarantee that the actual client lease interval will never exceed guarantee that the actual client lease interval will never exceed
the remaining acknowledged partner server lease interval by more the remaining acknowledged partner server lease interval by more
than the MCLT allows full recovery from a variety of failures. than the MCLT allows full recovery from a variety of failures.
5.2.2. Controlled re-allocation of IP addresses 5.2.2. Controlled re-allocation of IP addresses
When in PARTNER-DOWN state there is a waiting period after which an When in PARTNER-DOWN state there is a waiting period after which an
IP address can be re-allocated to another client. For leases which IP address can be re-allocated to another client. For IP addresses
are available when the server enters PARTNER-DOWN state, the period which are available when the server enters PARTNER-DOWN state, the
is the MCLT from entry into PARTNER-DOWN state. For IP addresses period is the MCLT from entry into PARTNER-DOWN state. For IP
which are not available when the server enters PARTNER-DOWN state, addresses which are not available when the server enters PARTNER-DOWN
the period is the MCLT after the lease becomes available. See sec- state, the period is the MCLT after the IP address becomes available.
tion 9.4.2 for more details. See section 9.4.2 for more details.
In any other state, a server cannot reallocate an address from one In any other state, a server cannot reallocate an address from one
client to another without first notifying its partner (through a client to another without first notifying its partner (through a
BNDUPD message) and receiving acknowledgement (through a BNDACK BNDUPD message) and receiving acknowledgement (through a BNDACK mes-
message) that its partner is aware that that first client is not sage) that its partner is aware that that first client is not using
using the address. the address.
This could be modeled in the following way. Though this specific This could be modeled in the following way. Though this specific
implementation is in no way required, it may serve to better illus- implementation is in no way required, it may serve to better illus-
trate the concept. trate the concept.
An "available" IP address on a server may be allocated to any client. An "available" IP address on a server may be allocated to any client.
An IP address which was leased to a client and which expired or was An IP address which was leased to a client and which expired or was
released by that client would take on a new state, EXPIRED or released by that client would take on a new state, EXPIRED or
RELEASED respectively. The partner server would then be notified RELEASED respectively. The partner server would then be notified
that this IP address was EXPIRED or RELEASED through a BNDUPD. When that this IP address was EXPIRED or RELEASED through a BNDUPD. When
skipping to change at page 26, line 43 skipping to change at page 27, line 44
receipt of a DHCP client request whether it is to service this receipt of a DHCP client request whether it is to service this
request or to ignore it in order to allow the other server to service request or to ignore it in order to allow the other server to service
the request. the request.
In addition, it should be possible to configure the percentage of In addition, it should be possible to configure the percentage of
clients which will be serviced by either the primary or secondary clients which will be serviced by either the primary or secondary
server. This configuration should be more or less continuous, from server. This configuration should be more or less continuous, from
all clients serviced by the primary through an even split with half all clients serviced by the primary through an even split with half
serviced by each, to all clients serviced by the secondary. serviced by each, to all clients serviced by the secondary.
The technique chosen to support these goals is described in [LOADB]. The technique chosen to support these goals is described in [RFC
3074].
A bitmap-style Hash Bucket Assignment (as described in [LOADB]) is A bitmap-style Hash Bucket Assignment (as described in [RFC 3074]) is
used to determine which DHCP clients can be processed. There are two used to determine which DHCP clients can be processed. There are two
potential HBA's in a failover server -- a server HBA and a failover potential HBA's in a failover server -- a server HBA and a failover
HBA. The way that a server acquires a server HBA is outside of the HBA. The way that a server acquires a server HBA is outside of the
scope of the failover protocol, but both servers in a failover pair scope of the failover protocol, but both servers in a failover pair
MUST have the same server HBA. The failover HBA (which specifies the MUST have the same server HBA. The failover HBA (which specifies the
clients that the secondary is supposed to process) is sent by the clients that the secondary is supposed to process) is sent by the
primary server to the secondary server whenever a connection is esta- primary server to the secondary server whenever a connection is esta-
blished, using the hash-bucket-assignment option defined in section blished, using the hash-bucket-assignment option defined in section
12.11. 12.11.
skipping to change at page 27, line 46 skipping to change at page 28, line 48
secondary server. Either server can allocate available IP addresses secondary server. Either server can allocate available IP addresses
which they own to DHCP clients, in which case they cease to own them. which they own to DHCP clients, in which case they cease to own them.
When the DHCP client releases the address or the lease on it expires, When the DHCP client releases the address or the lease on it expires,
it will again become available and will be owned by the primary. it will again become available and will be owned by the primary.
An IP address will not become owned by the server which allocated it An IP address will not become owned by the server which allocated it
initially when it is released or the lease expires because, in gen- initially when it is released or the lease expires because, in gen-
eral, that server will have had to replenish its pool of available eral, that server will have had to replenish its pool of available
addresses well in advance of any likely lease expirations. Thus, addresses well in advance of any likely lease expirations. Thus,
having a particular IP address cycle back to the secondary might well having a particular IP address cycle back to the secondary might well
put the secondary more out of balance with respect to the primary as put the secondary more out of balance with respect to the primary
it is to enhance the balance of available addresses between them. instead of enhancing the balance of available addresses between them.
These address pools are used when in COMMUNICATIONS-INTERRUPTED state These address pools are used when in COMMUNICATIONS-INTERRUPTED state
and while waiting for the MCLT expiration in PARTNER-DOWN state. In and while waiting for the MCLT expiration in PARTNER-DOWN state. In
addition, when using load balancing, these pools are used when in addition, when using load balancing, these pools are used when in
NORMAL state as well. NORMAL state as well.
These allocation and maintenance of these address pools is an area of This allocation and maintenance of these address pools is an area of
some sensitivity, since the goal is to maintain a more or less con- some sensitivity, since the goal is to maintain a more or less con-
stant ratio of available addresses between the two servers. stant ratio of available addresses between the two servers.
The initial allocation when the servers first integrate is triggered The initial allocation when the servers first integrate is triggered
by the POOLREQ message from the secondary to the primary. This is by the POOLREQ message from the secondary to the primary. This is
followed by the POOLRESP message where the primary tells the secon- followed by the POOLRESP message where the primary tells the secon-
dary how many IP addresses it allocated to the secondary. Then, the dary how many IP addresses it allocated to the secondary. Then, the
primary sends the allocated IP addresses to the secondary. The primary sends the allocated IP addresses to the secondary via BNDUPD
POOLREQ/POOLRESP message is a trigger to the primary to perform a messages. l The POOLREQ/POOLRESP message is a trigger to the primary
scan of its database and to ensure that the secondary has enough IP to perform a scan of its database and to ensure that the secondary
addresses (based on some configured ratio). has enough IP addresses (based on some configured ratio).
The actual IP addresses are sent to the secondary using the BNDUPD The actual IP addresses are sent to the secondary using the BNDUPD
message with a state of BACKUP, which indicates the IP address is now message with a state of BACKUP, which indicates the IP address is now
available for allocation by the secondary. available for allocation by the secondary. Once the message is sent,
the primary MUST NOT use these addresses for allocation to DHCP
clients.
The POOLREQ/POOLRESP message exchange initiated by the secondary is The POOLREQ/POOLRESP message exchange initiated by the secondary is
valid at any time, and the primary server SHOULD, whenever it valid at any time, and the primary server SHOULD, whenever it
receives the POOLREQ message, scan its database of address pools and receives the POOLREQ message, scan its database of address pools and
determine if the secondary needs more IP addresses from any of the IP determine if the secondary needs more IP addresses from any of the IP
address pools. address pools.
However, in order to support a reasonably dynamic balance of the IP However, in order to support a reasonably dynamic balance of the IP
addresses between the failover partners, the primary server needs to addresses between the failover partners, the primary server needs to
do additional work to ensure that the secondary server has as many IP do additional work to ensure that the secondary server has as many IP
skipping to change at page 29, line 11 skipping to change at page 30, line 16
the secondary using a BNDUPD with the state BACKUP. The primary the secondary using a BNDUPD with the state BACKUP. The primary
server can attempt to take an available IP address away from the server can attempt to take an available IP address away from the
secondary by sending a BNDUPD with the state FREE. If the secondary secondary by sending a BNDUPD with the state FREE. If the secondary
accepts the BNDUPD, then it is now available to the PRIMARY and not accepts the BNDUPD, then it is now available to the PRIMARY and not
available to the secondary. Of course, the secondary MUST reject available to the secondary. Of course, the secondary MUST reject
that BNDUPD if it has already used that IP address for a DHCP client. that BNDUPD if it has already used that IP address for a DHCP client.
Whenever the primary server examines the possible available IP Whenever the primary server examines the possible available IP
addresses which it could send to the secondary server, the primary addresses which it could send to the secondary server, the primary
server SHOULD take into account whether load balancing is in use, and server SHOULD take into account whether load balancing is in use, and
if it is the primary server SHOULD attempt to send to the secondary it SHOULD attempt to send to the secondary any IP addresses whose
any IP addresses whose most recent client would be processed by the most recent client would be processed by the secondary under the
secondary under the current load balancing regime in use. Likewise, current load balancing regime in use. Likewise, when removing avail-
when removing available IP addresses from the secondary server when able IP addresses from the secondary server when load balancing is in
load balancing is in use, the primary server SHOULD first remove use, the primary server SHOULD first remove those IP addresses whose
those IP addresses whose most recent client would be processed by the most recent client would be processed by the primary server under the
primary server under the current load balancing regime in use. current load balancing regime in use.
5.5. Operating in NORMAL state 5.5. Operating in NORMAL state
When in NORMAL state, each server services DHCPDISCOVER's and all When in NORMAL state, each server services DHCPDISCOVER's and all
other DHCP requests other than DHCPREQUEST/RENEWAL or other DHCP requests other than DHCPREQUEST/RENEWAL or
DHCPREQUEST/REBINDING from the client set defined by the load balanc- DHCPREQUEST/REBINDING from the client set defined by the load balanc-
ing algorithm [LOADB]. Each server services DHCPREQUEST/RENEWAL or ing algorithm [RFC 3074]. Each server services DHCPREQUEST/RENEWAL
DHCPDISCOVER/REBINDING requests from any client. or DHCPDISCOVER/REBINDING requests from any client.
In general, whenever the binding database is changed in stable In general, whenever the binding database is changed in stable
storage (other than a change resulting from receiving a BNDUPD from storage (other than a change resulting from receiving a BNDUPD from
the failover partner), then a BNDUPD message is sent with the con- the failover partner), then a BNDUPD message is sent with the con-
tents of that change to the partner server. The partner server then tents of that change to the partner server. The partner server then
writes the information about that binding in its bindings database in writes the information about that binding in its bindings database in
stable storage and replies with a BNDACK message. stable storage and replies with a BNDACK message.
The binding database in a DHCP server would normally be changed as a The binding database in a DHCP server would normally be changed as a
result of DHCP protocol activity with a DHCP client (e.g., granting result of DHCP protocol activity with a DHCP client (e.g., granting
skipping to change at page 30, line 7 skipping to change at page 31, line 13
MUST NOT trigger a corresponding BNDUPD message to the partner. MUST NOT trigger a corresponding BNDUPD message to the partner.
5.6. Operating in COMMUNICATIONS-INTERRUPTED state 5.6. Operating in COMMUNICATIONS-INTERRUPTED state
When operating in COMMUNICATIONS-INTERRUPTED state, each server is When operating in COMMUNICATIONS-INTERRUPTED state, each server is
operating independently, but does not assume that its partner is not operating independently, but does not assume that its partner is not
operating. The partner server might be operating and simply unable operating. The partner server might be operating and simply unable
to communicate with this server, or might not be operating. to communicate with this server, or might not be operating.
Each server responds to the full range of DHCP client messages that Each server responds to the full range of DHCP client messages that
it receives, but in such a way that graceful reintegration is always it receives (subject to server load balancing [RFC 3074]), but in
possible when its partner comes back into contact with it. such a way that graceful reintegration is always possible when its
partner comes back into contact with it.
5.7. Operating in PARTNER-DOWN state 5.7. Operating in PARTNER-DOWN state
When operating in PARTNER-DOWN state, a server assumes that its When operating in PARTNER-DOWN state, a server assumes that its
partner is not currently operating, but does make allowances for the partner is not currently operating, but does make allowances for the
possibility that that server was operating in the past, though possi- possibility that that server was operating in the past, though possi-
bly out of communications with this server. It responds to all DHCP bly out of communications with this server. It responds to all DHCP
client requests in PARTNER-DOWN state. client requests in PARTNER-DOWN state (subject to server load balanc-
ing [RFC 3074]).
5.8. Operating in RECOVER state 5.8. Operating in RECOVER state
A server operating in RECOVER state assumes that it is reintegrating A server operating in RECOVER state assumes that it is reintegrating
with a server that has been operating in PARTNER-DOWN state, and that with a server that has been operating in PARTNER-DOWN state, and that
it needs to update its bindings database before it services DHCP it needs to update its bindings database before it services DHCP
client requests. client requests.
A server may also operate in RECOVER state in order to fully recover A server may also operate in RECOVER state in order to fully recover
its bindings database from its partner server. its bindings database from its partner server.
5.9. Operating in STARTUP state 5.9. Operating in STARTUP state
A server operating in STARTUP state assumes that failover is opera- A server operating in STARTUP state assumes that failover is opera-
tional, and it spends a short time whenever it comes up attempting to tional, and it spends a short time whenever it comes up attempting to
contact the partner. During this time (generally a few seconds), the contact the partner. During this short time, the server is unrespon-
server is unresponsive to DHCP client requests. This period exists sive to DHCP client requests. This period exists in order to give a
in order to give a server a chance to determine that its partner has server a chance to determine that its partner has changed state since
changed state since it was last in communications, and to react to it was last in communications, and to react to that changed state (if
that changed state (if any) prior to responding to DHCP client any) prior to responding to DHCP client requests.
requests.
The startup period SHOULD be conditioned on the length of time the
server has been down (if that can be determined). If the server has
been down less than the MCLT then it can wait only a few (say 5 or
10) seconds. If it has been down a longer time (such that the
partner may well have moved to PARTNER-DOWN state), a considerably
longer startup period of 30 to 60 seconds may be warranted, since the
consequences of running while the partner is in PARTNER-DOWN state
are unpleasant.
The period of time a server remains in STARTUP state SHOULD be long The period of time a server remains in STARTUP state SHOULD be long
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
skipping to change at page 31, line 26 skipping to change at page 32, line 41
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-
ting the time delta between the failover partners. ting the time delta between the failover partners.
The specific definitions of a minor or drastic change in delta time The specific definitions of a minor or drastic change in delta time
as well as the algorithm used to smooth minor changes into the run- as well as the algorithm used to smooth minor changes into the run-
ning delta time are implementation issues and are not further ning delta time are implementation issues and are not further
addresses in this document. addressed in this document.
5.11. IP address binding-status 5.11. IP address binding-status
In most DHCP servers an IP address can take on several different In most DHCP servers an IP address can take on several different
binding-status values, sometimes also called states. While no two binding-status values, sometimes also called states. While no two
DHCP servers probably have exactly the same possible binding-status DHCP servers probably have exactly the same possible binding-status
values, the DHCP RFC enforces some commonality among the general values, the DHCP RFC enforces some commonality among the general
semantics of the binding-status values used by various DHCP server semantics of the binding-status values used by various DHCP server
implementations. implementations.
skipping to change at page 31, line 51 skipping to change at page 33, line 19
the DHCP protocol in a DHCP server, but rather that the binding- the DHCP protocol in a DHCP server, but rather that the binding-
status values defined in this document should be a common denominator status values defined in this document should be a common denominator
of those in use by many DHCP server implementations. It is a goal of of those in use by many DHCP server implementations. It is a goal of
this protocol that any DHCP server can map the various IP address this protocol that any DHCP server can map the various IP address
binding-status values that it uses internally into these failover IP binding-status values that it uses internally into these failover IP
address binding-status values on transmission of binding database address binding-status values on transmission of binding database
updates to its partner, and likewise that it can map any failover IP updates to its partner, and likewise that it can map any failover IP
address binding-status values it received in a binding update into address binding-status values it received in a binding update into
its internal IP address binding-status values. its internal IP address binding-status values.
The IP address binding-status values defined for the failover The IP address binding-status values defined for the failover proto-
protocol are listed below. Unless otherwise noted below, there MAY col are listed below. Unless otherwise noted below, there MAY be
be client information associated with each of these binding-status client information associated with each of these binding-status
values. values.
o
o ACTIVE -- Lease is assigned to a client. Client identification o ACTIVE -- Lease is assigned to a client. Client identification
MUST appear. MUST appear.
o EXPIRED -- indicates that a client's binding on an IP address o EXPIRED -- indicates that a client's binding on an IP address
has expired. When the partner server ACK's the BNDUPD of an has expired. When the partner server ACK's the BNDUPD of an
EXPIRED IP address, the server sets its internal state to FREE. EXPIRED IP address, the server sets its internal state to FREE.
It is then available for allocation to any client of the primary It is then available for allocation to any client of the primary
server. It may be allocated to the same client on the server server. It may be allocated to the same client on the server
where the lease expired if a BNDUPD containing the EXPIRED state where the lease expired if a BNDUPD containing the EXPIRED state
has not yet been sent to the partner (e.g., in the event that has not yet been sent to the partner (e.g., in the event that
skipping to change at page 34, line 8 skipping to change at page 35, line 8
for details of this option. Unless otherwise noted above there MAY for details of this option. Unless otherwise noted above there MAY
be client information associated with each of these binding-status be client information associated with each of these binding-status
values. values.
An IP address will move between these binding-status values using the An IP address will move between these binding-status values using the
following state transition diagram: following state transition diagram:
DHCP client DECLINE or DHCP client DECLINE or
server detected problem server detected problem
from any state from any state
+----------+ V +---------+ |
External >---->| RESET | | |ABANDONED| V
command | | +-->| | +----------+ +--+------+
External >---->| RESET | (3) |ABANDONED|
command | +<--------+ |
+----------+ +---------+ +----------+ +---------+
| |
Comm w/Parter(1) Comm w/Parter(1)
V V
+---------+ Comm(1) +----------+ Comm(1) +---------+ +---------+ Comm(1) +----------+ Comm(1) +---------+
| EXPIRED |--------->| FREE |<----------| RELEASED| | EXPIRED |--------->| FREE |<----------| RELEASED|
| | w/Parter | | w/Partner | | | | w/Parter | | w/Partner | |
+---------+ +----------+ +---------+ +---------+ +----------+ +---------+
^ ^ | | +-----------+ ^ ^ ^ | | +-----------+ ^
| | | | | | | | | | | |
| Exp. grace IP | IP addr alloc. IP addr | | Exp. grace IP | IP addr alloc. IP addr |
| period ends address to sec.(2) reserved | | period ends address to sec.(2) reserved |
| | leasedy V | | | | leased V | |
| | by | +----------+ | | | | by | +----------+ | |
| | primary | BACKUP |<---+ | | | primary | BACKUP |<---+ |
| wait for | | | | | wait for | | | |
| grace period | +----------+ | | grace period | +----------+ |
| | | | | | | | | |
| | | IP addr leased by | | | | IP addr leased by |
| Expired grace | secondary | | Expired grace | secondary |
| period exists V V | | period exists V V |
| | +----------+ | | | +----------+ |
| | Lease on | ACTIVE | DHCPRELEASE | | | Lease on | ACTIVE | DHCPRELEASE |
+-----+-IP addr---| |------------------+ +-----+-IP addr---| |------------------+
expires +----------+ expires +----------+
Figure 5.10-1: Transitions between binding-status values. Figure 5.11-1: Transitions between binding-status values.
(1) This transition MAY also occur if the server is in (1) This transition MAY also occur if the server is in
PARTNER-DOWN state and the MCLT has passed since the entry PARTNER-DOWN state and the MCLT has passed since the entry
in the RELEASED, EXPIRED, or RESET states. in the RELEASED, EXPIRED, or RESET states.
(2) This transition MAY occur if the server is the secondary (2) This transition MAY occur if the server is the secondary
and the MCLT has passed since its entry into PARTNER-DOWN state. and the MCLT has passed since its entry into PARTNER-DOWN state.
(3) This transition MAY occur due to an implementation specific
handling of ABANDONED IP addresses.
Again, note that a DHCP server implementing the failover protocol Again, note that a DHCP server implementing the failover protocol
does not have to implement either this state machine or use these does not have to implement either this state machine or use these
particular binding-status values in its normal operation of allocat- particular binding-status values in its normal operation of allocat-
ing IP addresses to DHCP clients. It only needs to map its internal ing IP addresses to DHCP clients. It only needs to map its internal
binding-status-values onto these "standard" binding-status values, binding-status-values onto these "standard" binding-status values,
and map these "standard" binding-status values back into its internal and map these "standard" binding-status values back into its internal
binding-status values. For example, a server which implements a binding-status values. For example, a server which implements a
grace period for a IP address binding SHOULD simply wait to update grace period for a IP address binding SHOULD simply wait to update
its partner server until the grace period on that binding has run its partner server until the grace period on that binding has run
out. out.
skipping to change at page 35, line 35 skipping to change at page 36, line 38
This process is encoded in the transition diagram above by "Comm This process is encoded in the transition diagram above by "Comm
w/Partner". w/Partner".
5.12. DNS dynamic update considerations 5.12. DNS dynamic update considerations
DHCP servers (and clients) can use DNS Dynamic Updates as described DHCP servers (and clients) can use DNS Dynamic Updates as described
in [RFC 2136] to maintain DNS name-mappings as they maintain DHCP in [RFC 2136] to maintain DNS name-mappings as they maintain DHCP
leases. Many different administrative models for DHCP-DNS integra- leases. Many different administrative models for DHCP-DNS integra-
tion are possible. Descriptions of several of these models, and tion are possible. Descriptions of several of these models, and
guidelines that DHCP servers and clients should follow in carrying guidelines that DHCP servers and clients should follow in carrying
them out, are laid out in [DDNS]. The nature of the DHCP failover them out, are laid out in [FQDN]. The nature of the DHCP failover
protocol introduces some issues concerning dynamic DNS updates that protocol introduces some issues concerning dynamic DNS updates that
are not part of non-failover DHCP environments. This section are not part of non-failover DHCP environments. This section
describes these issues, and defines the information which failover describes these issues, and defines the information which failover
partners should exchange and the protocol which they should follow in partners should exchange and the protocol which they should follow in
order to ensure consistent behavior. The presence of this section order to ensure consistent behavior. The presence of this section
should not be interpreted as requiring that implementations of the should not be interpreted as requiring that implementations of the
DHCP failover protocol must also support DDNS updates. The purpose DHCP failover protocol must also support DDNS updates. The purpose
of this discussion is to clarify the areas where the DHCP failover of this discussion is to clarify the areas where the DHCP failover
and DHCP-DDNS protocols intersect for the benefit of implementations and DHCP-DDNS protocols intersect for the benefit of implementations
which support both protocols, not to introduce a new requirement into which support both protocols, not to introduce a new requirement into
the DHCP failover protocol. Thus, a DHCP server which implements the the DHCP failover protocol. Thus, a DHCP server which implements the
failover protocol MAY also support dynamic DNS updates, but if it failover protocol MAY also support dynamic DNS updates, but if it
does support dynamic DNS updates it SHOULD utilize the techniques does support dynamic DNS updates it SHOULD utilize the techniques
described here in order to correctly distribute them between the described here in order to correctly distribute them between the
failover partners. failover partners. See [FQDN], [DNSRES], and [DHCID] for details of
how DHCP servers update DNS.
From the standpoint of the failover protocol, there is no reason why From the standpoint of the failover protocol, there is no reason why
a server which is utilizing the DDNS protocol to update a DNS server a server which is utilizing the DDNS protocol to update a DNS server
should not be a partner with a server which is not utilizing the DDNS should not be a partner with a server which is not utilizing the DDNS
protocol to update a DNS server. However, a server which is not able protocol to update a DNS server. However, a server which is not able
to support DDNS or is not configured to support DDNS SHOULD output a to support DDNS or is not configured to support DDNS SHOULD output a
warning message when it receives BNDUPD messages which indicate that warning message when it receives BNDUPD messages which indicate that
its failover partner is configured to support the DDNS protocol to its failover partner is configured to support the DDNS protocol to
update a DNS server. An implementation MAY consider this an error update a DNS server. An implementation MAY consider this an error
and refuse to operate, or it MAY choose to operate anyway, having and refuse to operate, or it MAY choose to operate anyway, having
skipping to change at page 37, line 45 skipping to change at page 38, line 51
avoid sending a second BNDUPD. avoid sending a second BNDUPD.
The Domain Name field in the DDNS option contains the FQDN that will The Domain Name field in the DDNS option contains the FQDN that will
be associated with the A RR (if the server is performing an A RR be associated with the A RR (if the server is performing an A RR
update for the client) and the PTR RR. This FQDN may be composed in update for the client) and the PTR RR. This FQDN may be composed in
any of several ways, depending on server configuration and the infor- any of several ways, depending on server configuration and the infor-
mation provided by the client in its DHCP messages. The client may mation provided by the client in its DHCP messages. The client may
supply a hostname which it would like the server to use in forming supply a hostname which it would like the server to use in forming
the FQDN, or it may supply the entire FQDN. The server may be config- the FQDN, or it may supply the entire FQDN. The server may be config-
ured to attempt to use the information the client supplies, it may be ured to attempt to use the information the client supplies, it may be
configured with an FQDN to use for the client, or it may be config- configured with an FQDN to use for the client, or it may be
ured to synthesize an FQDN. The responsive server SHOULD include the configured to synthesize an FQDN. The responsive server SHOULD
FQDN that it will be using in DDNS updates it initiates when it sends include the FQDN that it will be using in DDNS updates it initiates
the DDNS option. when it sends the DDNS option.
Since the responsive server may not have completed the DDNS update at Since the responsive server may not have completed the DDNS update at
the time it sends the first BNDUPD about the lease binding, there may the time it sends the first BNDUPD about the lease binding, there may
be cases where the FQDN in later BNDUPD messages does not match the be cases where the FQDN in later BNDUPD messages does not match the
FQDN included in earlier messages. For example, the responsive FQDN included in earlier messages. For example, the responsive
server may be configured to handle situations where two or more DHCP server may be configured to handle situations where two or more DHCP
client FQDNs are identical by modifying the most-specific label in client FQDNs are identical by modifying the most-specific label in
the FQDNs of some of the clients in an attempt to generate unique the FQDNs of some of the clients in an attempt to generate unique
FQDNs for them (a process sometimes called "disambiguation"). Alter- FQDNs for them (a process sometimes called "disambiguation"). Alter-
natively, at sites which use some or all of the information which natively, at sites which use some or all of the information which
skipping to change at page 38, line 33 skipping to change at page 39, line 39
5.12.3. Adding RRs to the DNS 5.12.3. Adding RRs to the DNS
A failover server which is going to perform DDNS updates SHOULD ini- A failover server which is going to perform DDNS updates SHOULD ini-
tiate the DDNS update when it grants a new lease to a client. The tiate the DDNS update when it grants a new lease to a client. The
non-responsive partner SHOULD NOT initiate a DDNS update when it non-responsive partner SHOULD NOT initiate a DDNS update when it
receives the BNDUPD after the lease has been granted. The failover receives the BNDUPD after the lease has been granted. The failover
protocol ensures that only one of the partners will grant a lease to protocol ensures that only one of the partners will grant a lease to
any individual client, so it follows that this requirement will any individual client, so it follows that this requirement will
prevent both partners from initiating updates simultaneously. The prevent both partners from initiating updates simultaneously. The
server initiating the update SHOULD follow the protocol in [DDNS]. server initiating the update SHOULD follow the protocol in [FQDN].
The server may be configured to perform an A RR update on behalf of The server may be configured to perform an A RR update on behalf of
its clients, or not. Ordinarily, a failover server will not initiate its clients, or not. Ordinarily, a failover server will not initiate
DDNS updates when it renews leases. In two cases, however, a failover DDNS updates when it renews leases. In two cases, however, a failover
server MAY initiate a DDNS update when it renews a lease to its server MAY initiate a DDNS update when it renews a lease to its
existing client: existing client:
1. When the lease was granted before the server was configured to 1. When the lease was granted before the server was configured to
perform DDNS updates, the server MAY be configured to perform perform DDNS updates, the server MAY be configured to perform
updates when it next renews existing leases. Since both updates when it next renews existing leases. Since both
servers are responsive to renewals in NORMAL state, it is not servers are responsive to renewals in NORMAL state, it is not
skipping to change at page 39, line 23 skipping to change at page 40, line 29
The failover server which makes an IP address FREE SHOULD initiate The failover server which makes an IP address FREE SHOULD initiate
any DDNS deletes, if it has recorded that DNS records were added on any DDNS deletes, if it has recorded that DNS records were added on
behalf of the client. behalf of the client.
A server not in PARTNER-DOWN state "makes an IP address FREE" when it A server not in PARTNER-DOWN state "makes an IP address FREE" when it
initiates a BNDUPD with a binding-status of FREE, EXPIRED, or initiates a BNDUPD with a binding-status of FREE, EXPIRED, or
RELEASED. Its partner confirms this status by acking that BNDUPD, RELEASED. Its partner confirms this status by acking that BNDUPD,
and upon receipt of the ACK the server has "made the IP address and upon receipt of the ACK the server has "made the IP address
FREE". Conversely, a server in PARTNER-DOWN state "makes an IP FREE". Conversely, a server in PARTNER-DOWN state "makes an IP
address FREE" when it sets the binding-status to FREE, since in address FREE" when it sets the binding-status to FREE, since in
PARTNER-DOWN state not communications is required with the partner. PARTNER-DOWN state no communications is required with the partner.
It is at this point that it should initiate the DDNS operations to It is at this point that it should initiate the DDNS operations to
delete RRs from the DDNS. Its partner SHOULD NOT initiate DDNS delete RRs from the DDNS. Its partner SHOULD NOT initiate DDNS
deletes for DNS records related to the lease binding as part of send- deletes for DNS records related to the lease binding as part of send-
ing the BNDACK message. The partner MAY have issued BNDUPD messages ing the BNDACK message. The partner MAY have issued BNDUPD messages
with a binding-status of FREE, EXPIRED, or RELEASED previously, but with a binding-status of FREE, EXPIRED, or RELEASED previously, but
the other server will have NAKed these BNDUPD messages. the other server will have NAKed these BNDUPD messages.
The failover protocol ensures that only one of the two partner The failover protocol ensures that only one of the two partner
servers will be able to make a lease FREE. The server making the servers will be able to make a lease FREE. The server making the
skipping to change at page 40, line 32 skipping to change at page 41, line 39
The general solution with regards to reservations is as follows. The general solution with regards to reservations is as follows.
Whenever a reserved IP address becomes FREE (i.e., when first config- Whenever a reserved IP address becomes FREE (i.e., when first config-
ured or whenever a client frees it or it expires or is reset), the ured or whenever a client frees it or it expires or is reset), the
primary server MUST show that IP address as FREE (and thus available primary server MUST show that IP address as FREE (and thus available
for its own allocation) and it MUST send it to the secondary server for its own allocation) and it MUST send it to the secondary server
with the R bit set in the IP-flags option and the binding-status with the R bit set in the IP-flags option and the binding-status
BACKUP. BACKUP.
Note that this implies that a reserved IP address goes through the Note that this implies that a reserved IP address goes through the
normal state changes from FREE to ACTIVE (and possibly back to FREE). normal state changes from FREE to ACTIVE (and possibly back to FREE).
The failover protcol supports this approach to reservations, i.e., The failover protocol supports this approach to reservations, i.e.,
where the IP address undergoes the normal state changes of any IP where the IP address undergoes the normal state changes of any IP
address, but it can only be offered to the client for which it is address, but it can only be offered to the client for which it is
reserved. Other approaches to the support of reservations exist in reserved. Other approaches to the support of reservations exist in
some DHCP server implementations (e.g., where the IP address is some DHCP server implementations (e.g., where the IP address is
apparently leased to a particular client forever, without any expira- apparently leased to a particular client forever, without any expira-
tion). The goal is for the failover protocol to support any of the tion). The goal is for the failover protocol to support any of the
usual approaches to reservations, both those that allow an IP address usual approaches to reservations, both those that allow an IP address
to go through different states when reserved, and those that don't. to go through different states when reserved, and those that don't.
From the above, it follows that a reservation soley on the secondary From the above, it follows that a reservation soley on the secondary
will not necessarily allow the secondary to offer that address to will not necessarily allow the secondary to offer that address to
client to whom it is reserved. The reservation must also appear on client to whom it is reserved. The reservation must also appear on
the primary as well for the secondary to be able to offer the IP the primary as well for the secondary to be able to offer the IP
address to the client to which is is reserved. address to the client to which is is reserved.
When the reservation on an IP address is cancelled, if the IP address When the reservation on an IP address is cancelled, if the IP address
is currently FREE and the server is the primary, or BACKUP and the is currently FREE and the server is the primary, or BACKUP and the
server is the secondary, the server MUST send a BNDUPD to the other server is the secondary, the server MUST send a BNDUPD to the other
server with the binding-status FREE. server with the binding-status FREE and the R bit clear.
5.14. Dynamic BOOTP and failover 5.14. Dynamic BOOTP and failover
Some DHCP servers support a capability to offer IP addresses to BOOTP Some DHCP servers support a capability to offer IP addresses to BOOTP
clients without having a particular address previously allocated for clients without having a particular address previously allocated for
those clients. This capability is often called something like those clients. This capability is often called something like
"dynamic BOOTP". It is discussed briefly in RFC 1534 [RFC 1534]. "dynamic BOOTP". It is discussed briefly in RFC 1534 [RFC 1534].
This capability has a negative interaction with the fundamental ele- This capability has a negative interaction with the fundamental ele-
ments of the failover protocol, in that an address handed out to a ments of the failover protocol, in that an address handed out to a
skipping to change at page 41, line 39 skipping to change at page 42, line 45
secondary for allocation that might have been allocated to BOOTP dev- secondary for allocation that might have been allocated to BOOTP dev-
ices MUST NOT ever be used by the primary server even if it is in ices MUST NOT ever be used by the primary server even if it is in
PARTNER-DOWN state and has waited the MCLT after entering that state. PARTNER-DOWN state and has waited the MCLT after entering that state.
Conversely, addresses available for allocation by the primary MUST Conversely, addresses available for allocation by the primary MUST
NOT be used by the secondary even it is in PARTNER-DOWN state. The NOT be used by the secondary even it is in PARTNER-DOWN state. The
reason for this is because one of those IP address could have been reason for this is because one of those IP address could have been
allocated by the secondary server to a BOOTP device, and the primary allocated by the secondary server to a BOOTP device, and the primary
server would have no way of ever knowing that happened. server would have no way of ever knowing that happened.
Whenever a server sends BNDUPD message to its partner, if the client Whenever a server sends BNDUPD message to its partner, if the client
of associated with the IP address is a BOOTP client, then the server associated with the IP address is a BOOTP client, then the server
MUST set the B bit in the IP-flags option. MUST set the B bit in the IP-flags option.
There is a very slight possibility that a BOOTP client could get an
IP address on each server of a failover pair. When these two servers
eventually attempt to resolve this conflict, they SHOULD agree to
disagree, since it is not possible to know which IP address the BOOTP
client will actually use -- indeed, it could use both. Operator
intervention will, in general, be required to rectify this situation.
Fortunately, it is extremely unlikely to ever actually occur.
5.15. Guidelines for selecting MCLT 5.15. Guidelines for selecting MCLT
There is no one correct value for the MCLT. There is an explicit There is no one correct value for the MCLT. There is an explicit
tradeoff between various factors in selecting an MCLT value. tradeoff between various factors in selecting an MCLT value.
5.15.1. Short MCLT 5.15.1. Short MCLT
A short MCLT value will mean that after entering PARTNER-DOWN state, A short MCLT value will mean that after entering PARTNER-DOWN state,
a server will only have to wait a short time before it can start a server will only have to wait a short time before it can start
allocating its partner's IP addresses to DHCP clients. Furthermore, allocating its partner's IP addresses to DHCP clients. Furthermore,
skipping to change at page 42, line 47 skipping to change at page 44, line 14
receiving server sends to the requesting server "all of the binding receiving server sends to the requesting server "all of the binding
database information that it has not already seen". In section database information that it has not already seen". In section
7.4.2, the UPDREQALL message is defined, and it says that the receiv- 7.4.2, the UPDREQALL message is defined, and it says that the receiv-
ing server sends to the requesting server "all binding database ing server sends to the requesting server "all binding database
information". information".
Both of these statements need further elaboration. Both of these statements need further elaboration.
First, for the UPDREQ message, the information to be sent in BNDUPD First, for the UPDREQ message, the information to be sent in BNDUPD
messages concerns "all of the binding database information it has not messages concerns "all of the binding database information it has not
already seen". Since every BNDUPD is acked by the receving server, already seen". Since every BNDUPD is acked by the receiving server,
the sending server need only keep track of which IP addresses have the sending server need only keep track of which IP addresses have
binding database changes not yet seen by the partner, and when they binding database changes not yet seen by the partner, and when they
are finally acked by the partner it can record that. Thus, at any are finally acked by the partner it can record that. Thus, at any
time, it knows which IP addresses have unacked binding database time, it knows which IP addresses have unacked binding database
information. This is less simple when, across reconfigurations of information. This is less simple when, across reconfigurations of
the servers, an IP address can change the failover partner to which the servers, an IP address can change the failover partner to which
it is associated. In that case, it is important to reset the indica- it is associated. In that case, it is important to reset the indica-
tion that the partner has seen this binding information. tion that the partner has seen this binding information. See section
5.17, below, for a more complete discussion of this issue.
Second, in the event that a failover server's binding database infor- Second, in the event that a failover server's binding database infor-
mation is restored from a backup, it will be partially out of date. mation is restored from a backup, it will be partially out of date.
In this case, its partner's indication of which binding database In this case, its partner's indication of which binding database
information the restored server has seen will be also be out of date. information the restored server has seen will be also be out of date.
The solution to this problem is for a server which is connecting with The solution to this problem is for a server which is connecting with
its partner to check the partner's last communicated time, and if it its partner to check the partner's last communicated time, and if it
is very much ahead of its own last communicated time, to to into is very much ahead of its own last communicated time, go to into
recover state and transmit an UPDREQALL to allow it to refresh its RECOVER state and transmit an UPDREQALL to allow it to refresh its
state. See section 9.3.2, step 5. If the partner's last communi- state. See section 9.3.2, step 5. If the partner's last communi-
cated time is very much behind its own record of when it last commun- cated time is very much behind its own record of when it last commun-
icated with the partner, then it SHOULD invalidate its information on icated with the partner, then it SHOULD invalidate its information on
which binding database information the partner server knows, so that which binding database information the partner server knows, so that
it will send all of its relevant binding database information to the it will send all of its relevant binding database information to the
partner. partner.
Third, in the event that a server receives a UPDREQALL message, what Third, in the event that a server receives a UPDREQALL message, what
constitutes "all binding database information"? At first glance this constitutes "all binding database information"? At first glance this
would seem to be information on every configured IP address in the would seem to be information on every configured IP address in the
skipping to change at page 43, line 41 skipping to change at page 45, line 9
data that must be sent for an UPDREQALL? data that must be sent for an UPDREQALL?
When sending "all binding database information", if the sending When sending "all binding database information", if the sending
server sends only information concerning IP addresses which have been server sends only information concerning IP addresses which have been
at some time associated with clients, it will send enough information at some time associated with clients, it will send enough information
to satisfy the needs of the failover protocol. It need not send to satisfy the needs of the failover protocol. It need not send
information on any IP addresses that have never been used, since information on any IP addresses that have never been used, since
presumably they will be initialized as available to the primary presumably they will be initialized as available to the primary
server (i.e. FREE) on any server employing failover. server (i.e. FREE) on any server employing failover.
5.17. How do you determine that your partner is "up to date" for
specific binding?
Throughout this document, one server is assumed to know for each IP
address binding whether or not its partner is "up to date" for that
binding. There are some subtle issues involved in recording this "up
to date" information about a specific binding.
In a steady state world, it would suffice to have a single bit in the
binding database to represent the information about whether the
partner was or was not up to date.
In a more complex environment a configuration change affecting a par-
ticular IP address may change the failover endpoint with which it is
associated, and if this should happen, any "up to date" bit which is
written into the bindings database will be accurate for only the pre-
vious failover endpoint, but not the current failover endpoint. If
failover is disabled and then re-enabled (and the "up to date" bits,
if used, are not cleared) problems can also occur.
A server MUST have be able to relate the "up to date" condition to a
particular failover endpoint and even a particular instantiation of
that failover endpoint. The techniques to do this are implementation
dependent.
In addition, section 7.4 requires that a server be able to remember
that an UPDREQALL message has been received and to treat every UPDREQ
message as an UPDREQALL message until the first UPDDONE message is
sent. One way to do this is to clear all of the "up to date" indica-
tions for an entire failover endpoint upon receipt of an UPDREQALL
message, thereby ensuring that every active binding will be sent to
the partner whether through the completion of this UPDREQALL or
through processing of a subsequent UPDREQ message. This is actually
better than remembering that an UPDREQALL was received and turning
every UPDREQ into an UPDREQALL, since any information sent in an
incomplete UPDREQALL (or subsequent UPDREQ messages turned into "all"
messages) will be remembered and not re-sent.
6. Common Message Format 6. Common Message Format
This section discusses the common message format that all failover This section discusses the common message format that all failover
messages have in common, including the message header format as well messages have in common, including the message header format as well
as the common option format. See section 12 for the the definitions as the common option format. See section 12 for the the definitions
of the specific options used in the failover protocol. of the specific options used in the failover protocol.
6.1. Message header format 6.1. Message header format
The options contained in the payload data section of the failover The options contained in the payload data section of the failover
skipping to change at page 44, line 38 skipping to change at page 46, line 44
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| payload data (variable) | | payload data (variable) |
| | | |
| formatted as DHCP-style options | | formatted as DHCP-style options |
| using a two byte option code and two byte length | | using a two byte option code and two byte length |
| See section 6.2 for details. | | See section 6.2 for details. |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
message length - 2 bytes, network byte order message length - 2 bytes, network byte order
This is the length of the message. It includes the two byte message This is the length of the message in bytes. It includes the two byte
length itself. The maximum length is 2048 bytes. The minimum length message length itself. The maximum length is 2048 bytes. The
is 12. minimum length is 12.
msg type - 1 byte msg type - 1 byte
The message type field is used to distinguish between messages. The message type field is used to distinguish between messages.
The following message types are defined: The following message types are defined:
Value Message Type Value Message Type
----- ------------ ----- ------------
0 reserved not used 0 reserved not used
1 POOLREQ request allocation of addresses 1 POOLREQ request allocation of addresses
2 POOLRESP respond with allocation count 2 POOLRESP respond with allocation count
3 BNDUPD update partner with binding info 3 BNDUPD update partner with binding info
4 BNDACK acknowledge receipt of binding update 4 BNDACK acknowledge receipt of binding update
5 CONNECT establish connection with the secondary 5 CONNECT establish connection with the secondary
6 CONNECTACK respond to attempt to establish connection with partner 6 CONNECTACK respond to attempt to establish connection with partner
7 UPDREQALL request full transfer of binding info 7 UPDREQALL request full transfer of binding info
8 UPDDONE ack send and ack of req'd binding info 8 UPDDONE ack send and ack of req'd binding info
9 UPDREQ req transfer of un-acked binding info 9 UPDREQ request transfer of un-acked binding info
10 STATE inform partner of current state or state change 10 STATE inform partner of current state or state change
11 CONTACT probe communications integrity with partner 11 CONTACT probe communications integrity with partner
12 DISCONNECT close a connection 12 DISCONNECT close a connection
New message types should be defined in one of two ranges, 0-127 or New message types should be defined in one of two ranges, 0-127 or
129-255. The range of 0-127 is used for messages that MUST be sup- 129-255. The range of 0-127 is used for messages that MUST be sup-
ported by every server, and if a server receives a message in the ported by every server, and if a server receives a message in the
range of 0-127 that it doesn't understand, it MUST close the TCP con- range of 0-127 that it doesn't understand, it MUST close the TCP con-
nection. The range of 128-255 is used for messages which MAY be sup- nection. The range of 128-255 is used for messages which MAY be sup-
ported but are not required, and if a server receives a message in ported but are not required, and if a server receives a message in
skipping to change at page 46, line 19 skipping to change at page 48, line 19
the receiver of the message copies the number over into any response the receiver of the message copies the number over into any response
message, treating it as opaque data. The sender MUST ensure that message, treating it as opaque data. The sender MUST ensure that
every message sent from a particular failover endpoint over the every message sent from a particular failover endpoint over the
associated TCP connection has a unique transaction id. associated TCP connection has a unique transaction id.
For failover messages that have no corresponding response message, For failover messages that have no corresponding response message,
the XID value is meaningless, but MUST be supplied. The XID value is the XID value is meaningless, but MUST be supplied. The XID value is
used solely by the receiver of a response message to determine the used solely by the receiver of a response message to determine the
corresponding request message. corresponding request message.
Requests messages where the XID is used in the corresponding response Request messages where the XID is used in the corresponding response
messages are: POOLREQ, BNDUPD, CONNECT, UPDREQALL, and UPDREQ. The messages are: POOLREQ, BNDUPD, CONNECT, UPDREQALL, and UPDREQ. The
corresponding response messages are POOLRESP, BNDACK, CONNECTACK, corresponding response messages are POOLRESP, BNDACK, CONNECTACK,
UPDDONE, and UPDDONE, respectively. UPDDONE, and UPDDONE, respectively.
As requests/responses don't survive connection reestablishment, XIDs As requests/responses don't survive connection reestablishment, XIDs
only need to be unique during a specific connection. only need to be unique during a specific connection.
payload data - variable length payload data - variable length
The options are placed after the header, after skipping payload The options are placed after the header, after skipping payload
skipping to change at page 48, line 40 skipping to change at page 50, line 40
Non-IP Address/Non-client specific options first Non-IP Address/Non-client specific options first
assigned-IP-address option for the first IP address assigned-IP-address option for the first IP address
If rejected, reject-reason option and message option. If rejected, reject-reason option and message option.
assigned-IP-address option for the second IP address assigned-IP-address option for the second IP address
If rejected, reject-reason option and message option. If rejected, reject-reason option and message option.
... ...
Trailing options (message digest). Trailing options (message digest).
In case the server chooses to reject some or all of the IP address In case the server chooses to reject some or all of the IP address
binding information in a BNDUPD message in a BNDACK reply, the BNDACK binding information in a BNDUPD message in a BNDACK reply, the BNDACK
message MUST contain a reject-reason option following every message MUST contain a reject-reason option following every failed
assigned-IP-address option in order to indicate that the binding assigned-IP-address option in order to indicate that the binding
update transaction for that IP address was not accepted and why. As update transaction for that IP address was not accepted and why. As
with a BNDACK message containing a single binding update transaction, with a BNDACK message containing a single binding update transaction,
an assigned-IP-address option without any associated reject-reason an assigned-IP-address option without any associated reject-reason
option indicates a successful binding update transaction. option indicates a successful binding update transaction.
7. Protocol Messages 7. Protocol Messages
This section contains the detailed definition of the protocol mes- This section contains the detailed definition of the protocol mes-
sages, including the information to include when sending the message, sages, including the information to include when sending the message,
skipping to change at page 53, line 32 skipping to change at page 55, line 32
send any DHCP client options. As new options are defined, the RFC send any DHCP client options. As new options are defined, the RFC
defining these options SHOULD include information that they are defining these options SHOULD include information that they are
"interesting to failover servers" if they should be sent as part of "interesting to failover servers" if they should be sent as part of
a BNDUPD. a BNDUPD.
option option option option
number name number name
----------------------------------------- -----------------------------------------
12 host-name 12 host-name
81 client-FQDN [DDNS] 81 client-FQDN [FQDN]
82 relay-agent-information [AGENTINFO] 82 relay-agent-information [RFC 3046]
TBD user-class [USERCLASS] 77 user-class [RFC 3004]
60 vendor-class-identifier 60 vendor-class-identifier
118 subnet-selection [RFC 3011]
Table 7.1.1-2: Options which SHOULD be sent in Table 7.1.1-2: Options which SHOULD be sent in
the client-request-options option in a BNDUPD message. the client-request-options option in a BNDUPD message.
o client-reply-options o client-reply-options
If the BNDUPD was triggered by a request from a DHCP client (typi- If the BNDUPD was triggered by a request from a DHCP client (typi-
cally those with binding-status of ACTIVE and RELEASED), then the cally those with binding-status of ACTIVE and RELEASED), then the
server SHOULD include options of interest to a failover partner server SHOULD include options of interest to a failover partner
from the server's DHCP reply packet in the client-reply-options for from the server's DHCP reply packet in the client-reply-options for
skipping to change at page 54, line 49 skipping to change at page 57, line 4
This is the duplicate IP address allocation conflict. There are This is the duplicate IP address allocation conflict. There are
two different clients each allocated the same address. See sec- two different clients each allocated the same address. See sec-
tion 7.1.3 for how to resolve this conflict. tion 7.1.3 for how to resolve this conflict.
o Two IP addresses, one client conflict o Two IP addresses, one client conflict
This conflict exists when a client on one server is associated This conflict exists when a client on one server is associated
with a one IP address, and on the other server with a different with a one IP address, and on the other server with a different
IP address in the same or a related subnet. This does not refer IP address in the same or a related subnet. This does not refer
to the case where a single client has addresses in multiple to the case where a single client has addresses in multiple dif-
different subnets or administrative domains, but rather the case ferent subnets or administrative domains, but rather the case
where on the same subnet the client has as lease on one IP where on the same subnet the client has as lease on one IP
address in one server and on a different IP address on the other address in one server and on a different IP address on the other
server. server.
This conflict may or may not be a problem for a given DHCP This conflict may or may not be a problem for a given DHCP
server implementation. In the event that a DHCP server requires server implementation. In the event that a DHCP server requires
that a DHCP client have only one outstanding lease for an IP that a DHCP client have only one outstanding lease for an IP
address on one subnet, this conflict should be resolved by address on one subnet, this conflict should be resolved by
accepting the update which has the latest client-last- accepting the lease information which has the latest client-
transaction-time. last-transaction-time.
o binding-status conflict o binding-status conflict
This is normal conflict, where one server is updating the other This is normal conflict, where one server is updating the other
with newer information. See section 7.1.3 for details of how to with newer information. See section 7.1.3 for details of how to
resolve these conflicts. resolve these conflicts.
7.1.3. Deciding whether to accept the binding update transaction in a 7.1.3. Deciding whether to accept the binding update transaction in a
BNDUPD message BNDUPD message
skipping to change at page 56, line 29 skipping to change at page 58, line 30
status of an IP address within the receiving server's data storage status of an IP address within the receiving server's data storage
will have an affect upon the checks performed prior to accepting the will have an affect upon the checks performed prior to accepting the
new binding-status in a BNDUPD message. new binding-status in a BNDUPD message.
In Figure 7.1.3-1, to "accept" a BNDUPD means to update the server's In Figure 7.1.3-1, to "accept" a BNDUPD means to update the server's
bindings database with the information contained in the BNDUPD and bindings database with the information contained in the BNDUPD and
once that update is complete, send a BNDACK message corresponding to once that update is complete, send a BNDACK message corresponding to
the BNDUPD message. To "reject" a BNDUPD means to respond to the the BNDUPD message. To "reject" a BNDUPD means to respond to the
BNDUPD with a BNDACK with a reject-reason option included. BNDUPD with a BNDACK with a reject-reason option included.
When interpreting the rules in the following list, if a BNDUPD When interpreting the information in the following table (Figure
7.1.3-1), for those rules that are listed with "time" -- if a BNDUPD
doesn't have a client-last-transaction-time value, then it MUST NOT doesn't have a client-last-transaction-time value, then it MUST NOT
be considered later than the client-last-transaction-time in the be considered later than the client-last-transaction-time in the
receiving server's binding. If the BNDUPD contains a client-last- receiving server's binding. If the BNDUPD contains a client-last-
transaction-time value and the receiving server's binding does not, transaction-time value and the receiving server's binding does not,
then the client-last-transaction-time value in the BNDUPD MUST be then the client-last-transaction-time value in the BNDUPD MUST be
considered later than the server's. considered later than the server's.
The second rule concerns clients and IP addresses. If the clients in
a BNDUPD message and in a receiving server's binding differ, then if
the receiving server's binding-status is ACTIVE and the binding-
status in the BNDUPD is ACTIVE, then if the receiving server is a
secondary server accept it, else reject it with a reject reason of 2:
"Fatal conflict exists: address in use by other client".
binding-status in received BNDUPD binding-status in received BNDUPD
binding-status binding-status
in receiving FREE RESET in receiving FREE RESET
server ACTIVE EXPIRED RELEASED BACKUP ABANDONED server ACTIVE EXPIRED RELEASED BACKUP ABANDONED
ACTIVE accept time(2) time(1) time(2) accept ACTIVE accept(5) time(2) time(1) time(2) accept
EXPIRED time(1) accept accept accept accept EXPIRED time(1) accept accept accept accept
RELEASED time(1) time(1) accept accept accept RELEASED time(1) time(1) accept accept accept
FREE/BACKUP accept accept accept accept accept FREE/BACKUP accept accept accept accept accept
RESET time(3) accept accept accept accept RESET time(3) accept accept accept accept
ABANDONED reject(4) reject(4) reject(4) reject(4) accept ABANDONED reject(4) reject(4) reject(4) reject(4) accept
time(1): If the client-last-transaction-time in the BNDUPD time(1): If the client-last-transaction-time in the BNDUPD
is later than the client-last-transaction-time in the is later than the client-last-transaction-time in the
receiving server's binding, accept it, else reject it. receiving server's binding, accept it, else reject it.
skipping to change at page 57, line 33 skipping to change at page 59, line 33
time(3): If the client-last-transaction-time in the BNDUPD time(3): If the client-last-transaction-time in the BNDUPD
is later than the start-time-of-state in the receiving server's is later than the start-time-of-state in the receiving server's
binding, accept it, else reject it. binding, accept it, else reject it.
(1,2,3): If rejecting, use reject reason 15: "Outdated binding (1,2,3): If rejecting, use reject reason 15: "Outdated binding
information". information".
(4): Use reject reason 16: "Less critical binding information". (4): Use reject reason 16: "Less critical binding information".
(5): If the clients in a BNDUPD message and in a receiving
server's binding differ, then if the receiving server is a
secondary accept it, else reject it with a reject reason of 2:
"Fatal conflict exists: address in use by other client".
Figure 7.1.3-1: Accepting BNDUPD messages Figure 7.1.3-1: Accepting BNDUPD messages
If the IP address in the BNDUPD message has the R flag set in the If the IP address in the BNDUPD message has the R flag set in the
IP-flags option, indicating it is a reserved IP address, and if the IP-flags option, indicating it is a reserved IP address, and if the
binding-status in the BNDUPD is BACKUP, then if the receiving server binding-status in the BNDUPD is BACKUP, then if the receiving server
does not show the IP address as reserved, the receiving server SHOULD does not show the IP address as reserved, the receiving server SHOULD
reject the BNDUPD using reject reason 19: "IP not reserved on this reject the BNDUPD using reject reason 19: "IP not reserved on this
server". server".
7.1.4. Accepting the BNDUPD message 7.1.4. Accepting the BNDUPD message
skipping to change at page 60, line 52 skipping to change at page 63, line 8
section is written as though every BNDUPD message contains only a section is written as though every BNDUPD message contains only a
single binding update transaction and thus every corresponding BNDACK single binding update transaction and thus every corresponding BNDACK
message would also contain reply information about only a single message would also contain reply information about only a single
binding update transaction. See section 6.3 for information on how binding update transaction. See section 6.3 for information on how
to create and process BNDUPD and BNDACK messages which contain multi- to create and process BNDUPD and BNDACK messages which contain multi-
ple binding update transactions. ple binding update transactions.
Note that while a server MAY generate BNDUPD messages with multiple Note that while a server MAY generate BNDUPD messages with multiple
binding update transactions, every server MUST be able to process a binding update transactions, every server MUST be able to process a
BNDUPD message which contains multiple binding update transactions BNDUPD message which contains multiple binding update transactions
and generate the corresponding BNDACK messages with status for and generate the corresponding BNDACK messages with status for multi-
multiple binding update transactions. If a server does not ever ple binding update transactions. If a server does not ever create
create BNDUPD messages which contain multiple binding update transac- BNDUPD messages which contain multiple binding update transactions,
tions, then it does not need to be able to process a received BNDACK then it does not need to be able to process a received BNDACK message
message with multiple binding update transactions. However, all with multiple binding update transactions. However, all servers MUST
servers MUST be able to create BNDACK messages which deal with multi- be able to create BNDACK messages which deal with multiple binding
ple binding update transactions received in a BNDUPD message. update transactions received in a BNDUPD message.
Every BNDUPD message that is received by a server MUST be responded Every BNDUPD message that is received by a server MUST be responded
to with a corresponding BNDACK message. The receiving server SHOULD to with a corresponding BNDACK message. The receiving server SHOULD
respond quickly to every BNDUPD message but it MAY choose to respond respond quickly to every BNDUPD message but it MAY choose to respond
preferentially to DHCP client requests instead of BNDUPD messages, preferentially to DHCP client requests instead of BNDUPD messages,
since there is no absolute time period within which a BNDACK must be since there is no absolute time period within which a BNDACK must be
sent in response to a BNDUPD message, while DHCP clients frequently sent in response to a BNDUPD message, while DHCP clients frequently
have strict time constraints. have strict time constraints.
A BNDACK message can only be sent in response to a BNDUPD message A BNDACK message can only be sent in response to a BNDUPD message
skipping to change at page 62, line 44 skipping to change at page 65, line 17
as possible because they can't agree on which server has better bind- as possible because they can't agree on which server has better bind-
ing data. Placing a considerable delay on the initiation of a BNDUPD ing data. Placing a considerable delay on the initiation of a BNDUPD
message after sending a BNDACK with a reject-reason would be one way message after sending a BNDACK with a reject-reason would be one way
to ensure this situation doesn't occur. to ensure this situation doesn't occur.
7.2.2. Receiving the BNDACK message 7.2.2. Receiving the BNDACK message
When a server receives a BNDACK message, if it doesn't contain a When a server receives a BNDACK message, if it doesn't contain a
reject-reason option that means that the BNDUPD message was accepted, reject-reason option that means that the BNDUPD message was accepted,
and the server which sent the BNDUPD SHOULD update its stable storage and the server which sent the BNDUPD SHOULD update its stable storage
with the potential-expiration-time value sent in the BNDUPD message with the potential-expiration-time value sent in the BNDUPD message.
and returned in the BNDACK message. Other values sent in the BNDUPD
message MAY be used as desired.
If the BNDACK message contains a reject-reason option, that means If the BNDACK message contains a reject-reason option, that means
that the BNDUPD was rejected. There SHOULD be a message option in that the BNDUPD was rejected. There SHOULD be a message option in
the BNDACK giving a text reason for the rejection, and the server the BNDACK giving a text reason for the rejection, and the server
SHOULD log the message in some way. The server MUST NOT immediately SHOULD log the message in some way. The server MUST NOT immediately
try to resend the BNDUPD message as there is no reason to believe the try to resend the BNDUPD message as there is no reason to believe the
partner won't reject it a second time. However a server MAY choose partner won't reject it a second time. However a server MAY choose
to send another BNDUPD at some future time, for instance when the to send another BNDUPD at some future time, for instance when the
server next processes an update request from its partner. server next processes an update request from its partner.
7.3. UPDREQ message [9] 7.3. UPDREQ message [9]
The update request (UPDREQ) message is used by one server to request The update request (UPDREQ) message is used by one server to request
that its partner send it all of the binding database information that that its partner send it all of the binding database information that
it has not already seen. Since each server is required to keep it has not already seen. Since each server is required to keep
track at all times of the binding information the other server has track at all times of the binding information the other server has
received and ACKed, one server can request transmission of all un- ACKed, one server can request transmission of all un-ACKed binding
ACKed binding database information held by the other server by using database information held by the other server by using the UPDREQ
the UPDREQ message. message.
The UPDREQ message is used whenever the sending server cannot proceed The UPDREQ message is used whenever the sending server cannot proceed
before it has processed all previously un-ACKed binding update infor- before it has processed all previously un-ACKed binding update infor-
mation, since the UPDREQ message should yield a corresponding UPDDONE mation, since the UPDREQ message should yield a corresponding UPDDONE
message. The UPDDONE message is not sent until the server that sent message. The UPDDONE message is not sent until the server that sent
the UPDREQ message has responded to all of the BNDUPD messages gen- the UPDREQ message has responded to all of the BNDUPD messages gen-
erated by the UPDREQ message with BNDACK messages (they may either be erated by the UPDREQ message with BNDACK messages (they may either be
accepted or rejected by the BNDACK messages, but they MUST have been accepted or rejected by the BNDACK messages, but they MUST have been
responded to). Thus, the sender of the UPDREQ message can be sure responded to). Thus, the sender of the UPDREQ message can be sure
upon receipt of an UPDDONE message that it has received and committed upon receipt of an UPDDONE message that it has received and committed
skipping to change at page 64, line 21 skipping to change at page 66, line 42
will probably not cause any difficulty, but a server MUST NOT attempt will probably not cause any difficulty, but a server MUST NOT attempt
to include all such later BNDUPD messages in the accounting for the to include all such later BNDUPD messages in the accounting for the
UPDREQ in order to be able to transmit an UPDDONE message. UPDREQ in order to be able to transmit an UPDDONE message.
When queuing up the BNDUPD messages for transmission to the sender of When queuing up the BNDUPD messages for transmission to the sender of
the UPDREQ message, the server processing the UPDREQ message MUST the UPDREQ message, the server processing the UPDREQ message MUST
honor the value returned in the max-unacked-bndupd option in the CON- honor the value returned in the max-unacked-bndupd option in the CON-
NECT or CONNECTACK message that set up the connection with the send- NECT or CONNECTACK message that set up the connection with the send-
ing server. It MUST NOT send more BNDUPD messages without receiving ing server. It MUST NOT send more BNDUPD messages without receiving
corresponding BNDACKs than the value returned in max-unacked-bndupd. corresponding BNDACKs than the value returned in max-unacked-bndupd.
(See section 8 for more details.)
7.4. UPDREQALL message [7] 7.4. UPDREQALL message [7]
The update request all (UPDREQALL) message is used by one server to The update request all (UPDREQALL) message is used by one server to
request that its partner send it all of the binding database informa- request that its partner send it all of the binding database informa-
tion. This message is used to allow one server to recover from a tion. This message is used to allow one server to recover from a
failure of stable storage and to restore its binding database in its failure of stable storage and to restore its binding database in its
entirety from the other server. entirety from the other server.
A server which sends an UPDREQALL message cannot proceed until all of A server which sends an UPDREQALL message cannot proceed until all of
skipping to change at page 64, line 46 skipping to change at page 67, line 19
The UPDREQALL message has no message specific options. The UPDREQALL message has no message specific options.
7.4.1. Sending the UPDREQALL message 7.4.1. Sending the UPDREQALL message
The UPDREQALL is sent. The UPDREQALL is sent.
7.4.2. Receiving the UPDREQALL message 7.4.2. Receiving the UPDREQALL message
A server receiving an UPDREQALL message MUST send all binding data- A server receiving an UPDREQALL message MUST send all binding data-
base information to the sending server. These changes are sent as base information to the sending server. See section 5.16 for details
undistinguished BNDUPD messages. Otherwise the processing is the same of what might actually comprise "all binding database information".
as for the UPDREQ message. See section 7.3.2 for details.
A server receiving an UPDREQALL message MUST remember that such a
message has been received, ensure that all binding information extant
at that point is sent to the partner prior to any UPDDONE message
being sent to that partner. One way to do this is to remember the
receipt of an UPDREQALL message and to and treat every subsequent
UPDREQ message as an UPDREQALL message until it sends the first
UPDDONE message after receipt of the UPDREQALL message. This
requirement exists because communications may fail and become re-
established between the two servers, and the specific conditions
which provoked the UPDREQALL message may not longer exist even though
the UPDREQALL message may not yet have completed. See section 5.17
for information on a more efficient way to meet the above require-
ment.
These changes are sent as undistinguished BNDUPD messages. Otherwise
the processing is the same as for the UPDREQ message. See section
7.3.2 for details.
7.5. UPDDONE message [8] 7.5. UPDDONE message [8]
The update done (UPDDONE) message is used by a server receiving an The update done (UPDDONE) message is used by a server receiving an
UPDREQ or UPDREQALL message to signify that it has sent all of the UPDREQ or UPDREQALL message to signify that it has sent all of the
BNDUPD messages requested by the UPDREQ or UPDREQALL request and that BNDUPD messages requested by the UPDREQ or UPDREQALL request and that
it has received a BNDACK for each of those messages. it has received a BNDACK for each of those messages.
While a BNDACK message MUST have been received for each BNDUPD mes- While a BNDACK message MUST have been received for each BNDUPD mes-
sage prior to the transmission of the UPDDONE message, this doesn't sage prior to the transmission of the UPDDONE message, this doesn't
skipping to change at page 66, line 6 skipping to change at page 68, line 41
7.6. POOLREQ message [1] 7.6. POOLREQ message [1]
The pool request (POOLREQ) message is used by the secondary server to The pool request (POOLREQ) message is used by the secondary server to
request an allocation of IP addresses from the primary server. It request an allocation of IP addresses from the primary server. It
MUST be sent by a secondary server to a primary server to request IP MUST be sent by a secondary server to a primary server to request IP
address allocation by the primary. The IP addresses allocated are address allocation by the primary. The IP addresses allocated are
transmitted using normal BNDUPD messages from the primary to the transmitted using normal BNDUPD messages from the primary to the
secondary. secondary.
The POOLREQ message SHOULD be sent from the secondary to the primary The POOLREQ message SHOULD be sent from the secondary to the primary
whenever the secondary transitions into NORMAL state. It SHOULD whenever the secondary makes a transition into NORMAL state. It
periodically be resent in order that any change in the number of SHOULD periodically be resent in order that any change in the number
available IP addresses on the primary be reflected in the pool on the of available IP addresses on the primary be reflected in the pool on
secondary. The period may be influenced by the secondary server's the secondary. The period may be influenced by the secondary
leasing activity. server's leasing activity.
The POOLREQ message has no message specific options. The POOLREQ message has no message specific options.
7.6.1. Sending the POOLREQ message 7.6.1. Sending the POOLREQ message
The POOLREQ message is sent. The POOLREQ message is sent.
7.6.2. Receiving the POOLREQ message 7.6.2. Receiving the POOLREQ message
When a primary server receives a POOLREQ message it SHOULD examine When a primary server receives a POOLREQ message it SHOULD examine
skipping to change at page 67, line 40 skipping to change at page 70, line 29
another POOLREQ message if the value of the addresses-transferred another POOLREQ message if the value of the addresses-transferred
option is non-zero. option is non-zero.
Typically, no other action is taken on the reception of a POOLRESP Typically, no other action is taken on the reception of a POOLRESP
message. message.
7.8. CONNECT message [5] 7.8. CONNECT message [5]
The connect message is used to establish an applications level con- The connect message is used to establish an applications level con-
nection over a newly created TCP connection. It gives the source nection over a newly created TCP connection. It gives the source
information for the connection, and critical configuration informa- information for the connection and critical configuration informa-
tion. It MUST be sent only by the primary server. Either server can tion. It MUST be sent only by the primary server. Either server can
initiate a TCP connection, but the CONNECT message is only sent by initiate a TCP connection, but the CONNECT message is only sent by
the primary server. the primary server.
The CONNECT message MUST be the first message sent down a newly esta- The CONNECT message MUST be the first message sent down a newly esta-
blished connection, and it MUST be sent only by the primary server. blished connection, and it MUST be sent only by the primary server.
The following table summarizes the options that are associated with The following table summarizes the options that are associated with
the CONNECT message: the CONNECT message:
Option Option
------ ------
sending-server-IP-address MUST relationship-name MUST
max-unacked-bndupd MUST max-unacked-bndupd MUST
receive-timer MUST receive-timer MUST
vendor-class-identifier MUST vendor-class-identifier MUST
protocol-version MUST protocol-version MUST
TLS-request MUST (1) TLS-request MUST (1)
MCLT MUST MCLT MUST
hash-bucket-assignment MUST hash-bucket-assignment MUST
(1) MUST NOT if CONNECT is being sent over a TLS connection (1) MUST NOT if CONNECT is being sent over a TLS connection
Table 7.8-1: Options used in a CONNECT message Table 7.8-1: Options used in a CONNECT message
7.8.1. Sending the CONNECT message 7.8.1. Sending the CONNECT message
The CONNECT message MUST be the first message sent by the primary The CONNECT message MUST be the first message sent by the primary
server after the establishment of a new TCP connection with a secon- server after the establishment of a new TCP connection with a secon-
dary server participating in the failover protocol. dary server participating in the failover protocol.
The xid of the CONNECT message must be unique. The xid of the CONNECT message is not related to any previous xid
sequence, but initiates the sequence for this connection.
The IP address of the primary server MUST be placed in the sending- The name of the failover relationship MUST be placed in the
server-IP-address option. This information is placed in an option relationship-name option. This information is placed in an option
inside of the message in order to allow the identity of the sender to inside of the message in order to allow the identity of the sender to
be covered by a shared secret. be covered by a shared secret.
The number of BNDUPD messages the primary server can accept without The number of BNDUPD messages the primary server can accept without
blocking the TCP connection MUST be placed in the max-unacked-bndupd blocking the TCP connection MUST be placed in the max-unacked-bndupd
option. This MUST be a number equal to or greater than 1, SHOULD be option. This MUST be a number equal to or greater than 1, SHOULD be
a number greater than 10, and SHOULD be a number less than 100. a number greater than 10, and SHOULD be a number less than 100.
The length of the receive timer (tReceive, see section 8.3) MUST be The length of the receive timer (tReceive, see section 8.3) MUST be
placed in the receive-timer option. placed in the receive-timer option.
The MCLT MUST be placed in the MCLT option. The MCLT MUST be placed in the MCLT option.
The hash-bucket-assignment option MUST be included in the CONNECT The hash-bucket-assignment option MUST be included in the CONNECT
message. In the event that load balancing is not configured for this message. In the event that load balancing is not configured for this
server, the hash-bucket-assignment option will indicate that. The server, the hash-bucket-assignment option will indicate that. The
value of the hash-bucket-assignment option is determined from the value of the hash-bucket-assignment option is determined from the
specific buckets that the primary server has determined that the specific buckets that the primary server has determined that the
secondary server MUST service as part of the load-balancing algo- secondary server MUST service as part of the load-balancing
rithm. The way in which the primary server determines this algorithm. The way in which the primary server determines this
information is outside the scope of this protocol definition. The information is outside the scope of this protocol definition. The
primary server SHOULD be configured with a percentage of clients that primary server SHOULD be configured with a percentage of clients that
the secondary server will be instructed to service, and the primary the secondary server will be instructed to service, and the primary
server SHOULD use the algorithm in [LOADB] to generate a Hash Bucket server SHOULD use the algorithm in [RFC 3074] to generate a Hash
Assignment which it sends to the secondary server. Bucket Assignment which it sends to the secondary server.
The vendor class identifier MUST be placed in the vendor-class- The vendor class identifier MUST be placed in the vendor-class-
identifier option. identifier option.
The protocol-version option MUST be included in every CONNECT mes- The protocol-version option MUST be included in every CONNECT mes-
sage. The current value of the protocol version is 1. sage. The current value of the protocol version is 1.
The TLS-request option MUST be sent and contains the desired TLS con- The TLS-request option MUST be sent and contains the desired TLS con-
nection request as well as information concerning whether TLS is sup- nection request as well as information concerning whether TLS is sup-
ported. If this CONNECT message is being sent over a already ported. If this CONNECT message is being sent over a already
created TLS connection, the TLS-request MUST NOT appear. created TLS connection, the TLS-request MUST NOT appear.
7.8.2. Receiving the CONNECT message 7.8.2. Receiving the CONNECT message
When a server receives a TCP connection on the failover port, if it When a server established a TCP connection on a failover port, if it
is a PRIMARY server it should send a CONNECT message, and if it is a is a PRIMARY server it should send a CONNECT message, and if it is a
secondary server it should wait for a CONNECT message before sending secondary server it should wait for a CONNECT message before sending
any messages. To avoid denial of service attacks, a secondary should any messages. To avoid denial of service attacks, a secondary should
only wait for a CONNECT message on a new connection for a limited only wait for a CONNECT message on a new connection for a limited
amount of time and close the connection if none is received during amount of time and close the connection if none is received during
that time. that time.
When a secondary server receives a CONNECT message it should: When a secondary server receives a CONNECT message it should:
1. Record the time at which the message was received. 1. Record the time at which the message was received.
skipping to change at page 70, line 29 skipping to change at page 73, line 29
4. Check to see if there is a message-digest option in the CON- 4. Check to see if there is a message-digest option in the CON-
NECT message. If there was, and the server does not support NECT message. If there was, and the server does not support
message-digests, then reject the connection with reject reason message-digests, then reject the connection with reject reason
12: "Message digest not supported" in the CONNECTACK. If the 12: "Message digest not supported" in the CONNECTACK. If the
server does support message-digests, then check this message server does support message-digests, then check this message
for validity based on the message-digest, and reject it if the for validity based on the message-digest, and reject it if the
digest indicates the message was altered with reject reason digest indicates the message was altered with reject reason
20: "Message digest failed to compare". 20: "Message digest failed to compare".
5. Determine if the sender (from the sending-server-IP-address 5. Determine if the sender (from the relationship-name option)
option) and the implicit role of the sender (i.e., primary) and the implicit role of the sender (i.e., primary) represents
represents a server with which the receiver was configured to a server with which the receiver was configured to engage in
engage in failover activity. This is performed after any TLS failover activity. This is performed after any TLS or message
or message digest processing so that it occurs after a secure digest processing so that it occurs after a secure connection
connection is created, to ensure that there is no tampering is created, to ensure that there is no tampering with the
with the IP address of the partner. relationship name of the partner. In the absence of any other
security capability (i.e., when TLS or a message digest is not
used), the server MAY wish to be configured with the IP
address of the partner and check the source-ip of the CONNECT
message against that IP address as a weak form of security.
If not, then the receiving server should reject the CONNECT If not, then the receiving server should reject the CONNECT
request by sending a CONNECTACK message with a reject-reason request by sending a CONNECTACK message with a reject-reason
value of: 8, invalid failover partner. value of: 8, invalid failover partner.
If it is, then the receiving failover endpoint should be If it is, then the receiving failover endpoint should be
determined. determined.
6. Decide if the time delta between the sending of the message, 6. Decide if the time delta between the sending of the message,
in the time field, and the receipt of the message, recorded in in the time field, and the receipt of the message, recorded in
step 1 above, is acceptable. A server MAY require an arbi- step 1 above, is acceptable. A server MAY require an
trarily small delta in time values in order to set up a fail- arbitrarily small delta in time values in order to set up a
over connection with another server. See section 5.10 for failover connection with another server. See section 5.10 for
information on time synchronization. information on time synchronization.
If the delta between the time values is too great, the server If the delta between the time values is too great, the server
should reject the CONNECT request by sending a CONNECTACK mes- should reject the CONNECT request by sending a CONNECTACK mes-
sage with a reject-reason of 4, time mismatch too great. sage with a reject-reason of 4, time mismatch too great.
If the time mismatch is not considered too great then the If the time mismatch is not considered too great then the
receiving server MUST record the delta between the servers. receiving server MUST record the delta between the servers.
The receiving server MUST use this delta to correct all of the The receiving server MUST use this delta to correct all of the
absolute times received from the other server in all time- absolute times received from the other server in all time-
valued options. Note that servers can participate in failover valued options. Note that servers can participate in failover
with arbitrarily great time mismatches, as long as it is more with arbitrarily great time mismatches, as long as it is more
or less constant. or less constant.
7. Examine the MCLT option in the CONNECT request and use the 7. Examine the MCLT option in the CONNECT request and use the
value of the MCLT as the MCLT for this failover endpoint. value of the MCLT as the MCLT for this failover endpoint.
The secondary server SHOULD be able to operate with any MCLT The secondary server SHOULD be able to operate with any MCLT
sent by the primary, but if it cannot, then it should send a sent by the primary, but if it cannot, then it should send a
CONNECTACK with a reject-reason of 5, MCLT mismatch. CONNECTACK with a reject-reason of 5, MCLT mismatch. In the
event that the MCLT from the primary does not match that con-
figured on the secondary, and the secondary will run with the
primary's value, then the secondary MUST save the MCLT in
secondary storage since it will need it even if it cannot con-
tact the primary. The secondary MUST NOT use a different MCLT
value than it received from the primary even if it cannot con-
tact the primary.
8. The server MUST store hash-bucket-assignment option for use 8. The server MUST store hash-bucket-assignment option for use
during processing during NORMAL state. If this hash bucket during processing during NORMAL state. If this hash bucket
assignment conflicts with the secondary server's configured assignment conflicts with the secondary server's configured
hash bucket assignment for use in other than NORMAL state, the hash bucket assignment for use in other than NORMAL state, the
secondary server should send a CONNECTACK with a reject reason secondary server should send a CONNECTACK with a reject reason
of 19, Hash bucket assignment conflict. of 19, Hash bucket assignment conflict.
9. The receiving server MAY use the vendor-class-identifier to do 9. The receiving server MAY use the vendor-class-identifier to do
vendor specific processing. vendor specific processing.
skipping to change at page 72, line 7 skipping to change at page 75, line 14
that the connection was rejected may well not have changed since the that the connection was rejected may well not have changed since the
last attempt. A simple suggested solution is to wait a minute or two last attempt. A simple suggested solution is to wait a minute or two
after sending or receiving a CONNECTACK message with a reject-reason after sending or receiving a CONNECTACK message with a reject-reason
before attempting to reestablish communication. before attempting to reestablish communication.
The following table summarizes the options associated with the CON- The following table summarizes the options associated with the CON-
NECTACK message: NECTACK message:
Option accept reject Option accept reject
------ ------
sending-server-IP-address MUST MUST relationship-name MUST MUST
max-unacked-bndupd MUST MUST NOT max-unacked-bndupd MUST MUST NOT
receive-timer MUST MUST NOT receive-timer MUST MUST NOT
vendor-class-identifier MUST MUST NOT vendor-class-identifier MUST MUST NOT
protocol-version MUST MUST protocol-version MUST MUST
TLS-reply (1) (2) TLS-reply (1) (2)
reject-reason MUST NOT MUST reject-reason MUST NOT MUST
message MUST NOT SHOULD message MUST NOT SHOULD
MCLT MUST NOT MUST NOT MCLT MUST NOT MUST NOT
hash-bucket-assignment MUST NOT MUST NOT hash-bucket-assignment MUST NOT MUST NOT
skipping to change at page 72, line 29 skipping to change at page 75, line 36
if TLS-request in CONNECT, else MUST NOT. if TLS-request in CONNECT, else MUST NOT.
(2) MUST if TLS-request in CONNECT message, else MUST NOT. (2) MUST if TLS-request in CONNECT message, else MUST NOT.
Table 7.9-1: Options used in a CONNECTACK message Table 7.9-1: Options used in a CONNECTACK message
7.9.1. Sending the CONNECTACK message 7.9.1. Sending the CONNECTACK message
The xid of the CONNECTACK message MUST be that of the corresponding The xid of the CONNECTACK message MUST be that of the corresponding
CONNECT message. CONNECT message.
The IP address of the sending server MUST be placed in the sending- The name of the relationship MUST be placed in the relationship-name
server-IP-address option. This information is placed in an option option. This information is placed in an option inside of the mes-
inside of the message in order to allow the identity of the sender to sage in order to allow the identity of the sender to be covered by a
be covered by a shared secret. shared secret.
The protocol-version option MUST be included in every CONNECTACK mes- The protocol-version option MUST be included in every CONNECTACK mes-
sage. The current value of the protocol version is 1. sage. The current value of the protocol version is 1.
If the connection has been rejected, the reject-reason option MUST be If the connection has been rejected, the reject-reason option MUST be
placed in the CONNECTACK message with an appropriate reason, and a placed in the CONNECTACK message with an appropriate reason, and a
message option SHOULD be included with a human-readable error message message option SHOULD be included with a human-readable error message
describing the reason for the rejection in some detail. If the describing the reason for the rejection in some detail. If the
reject-reason option appears, then the remaining options listed below reject-reason option appears, then the remaining options listed below
do not appear. The sending server should close the connection after do not appear. The sending server should close the connection after
skipping to change at page 73, line 41 skipping to change at page 76, line 48
and communications with this partner is considered not ok. The and communications with this partner is considered not ok. The
reject reason 17: "No traffic within sufficient time" is placed in reject reason 17: "No traffic within sufficient time" is placed in
the DISCONNECT message sent prior to dropping the TCP connection. the DISCONNECT message sent prior to dropping the TCP connection.
The tSend timer is reset whenever a message is sent over this connec- The tSend timer is reset whenever a message is sent over this connec-
tion. When it expires, a CONTACT message MUST be sent. tion. When it expires, a CONTACT message MUST be sent.
7.9.2. Receiving the CONNECTACK message 7.9.2. Receiving the CONNECTACK message
If a CONNECTACK message is received with a different XID from the one If a CONNECTACK message is received with a different XID from the one
in the CONNECT that was sent, it SHOULD be ignored. in the CONNECT that was sent, it SHOULD be ignored. To avoid denial
of service attacks, a primary should only wait for a CONNECTACK mes-
sage on a new connection for a limited amount of time and close the
connection if none is received during that time.
When a CONNECTACK message is received, the following actions should When a CONNECTACK message is received, the following actions should
be taken: be taken:
1. Record the time the message was received. 1. Record the time the message was received.
2. Check to see if the xid on the CONNECTACK matches an outstand- 2. Check to see if the xid on the CONNECTACK matches an outstand-
ing CONNECT message on this TCP connection. ing CONNECT message on this TCP connection.
3. Check to see if there is a reject-reason option in the 3. Check to see if there is a reject-reason option in the CONNEC-
CONNECTACK message. If not, continue with step 3. If there TACK message. If not, continue with step 3. If there is a
is a reject-reason option, the server SHOULD report the error reject-reason option, the server SHOULD report the error code.
code. If a message option appears a server SHOULD display the If a message option appears a server SHOULD display the string
string from the message option in a user visible way. The from the message option in a user visible way. The server
server MUST close the connection if a reject-reason option MUST close the connection if a reject-reason option appears.
appears.
4. Check the value of the TLS-reply option (if any, which there 4. Check the value of the TLS-reply option (if any, which there
won't be if this CONNECT is taking place utilizing TLS), and won't be if this CONNECT is taking place utilizing TLS), and
if it was 1, then skip processing of the rest of the CONNEC- if it was 1, then skip processing of the rest of the CONNEC-
TACK message, and immediately enter into TLS connection setup. TACK message, and immediately enter into TLS connection setup.
This step occurs prior to steps 5 and 6 in order to allow This step occurs prior to steps 5 and 6 in order to allow
creation of a secure connection (if required) prior to pro- creation of a secure connection (if required) prior to pro-
cessing the protocol version and IP address information. cessing the protocol version and IP address information.
skipping to change at page 74, line 32 skipping to change at page 77, line 41
running this protocol version, then continue, else close the running this protocol version, then continue, else close the
connection. connection.
6. Decide if the time delta between the sending of the message, 6. Decide if the time delta between the sending of the message,
in the time field, and the receipt of the message, recorded in in the time field, and the receipt of the message, recorded in
step 1 above, is acceptable. A server MAY require an arbi- step 1 above, is acceptable. A server MAY require an arbi-
trarily small delta in time values in order to set up a fail- trarily small delta in time values in order to set up a fail-
over connection with another server. over connection with another server.
If the delta between the time values is too great, the server If the delta between the time values is too great, the server
should drop the TCP connection. should drop the TCP connection (see section 7.12).
If the time mismatch is not considered too great then the If the time mismatch is not considered too great then the
receiving server MUST record the delta between the servers. receiving server MUST record the delta between the servers.
The receiving server MUST use this delta to correct all of the The receiving server MUST use this delta to correct all of the
absolute times received from the other server in all time- absolute times received from the other server in all time-
valued options. Note that the failover protocol is con- valued options. Note that the failover protocol is con-
structed so that two servers can be failover partners with structed so that two servers can be failover partners with
arbitrarily great time mismatches. arbitrarily great time mismatches.
7. The receiving server MAY use the vendor-class-identifier to do 7. The receiving server MAY use the vendor-class-identifier to do
skipping to change at page 78, line 27 skipping to change at page 81, line 37
There are a maximum of two TCP connections between any two servers There are a maximum of two TCP connections between any two servers
implementing the failover protocol, one for each of the possible implementing the failover protocol, one for each of the possible
failover endpoints between these two servers. There is a minimum of failover endpoints between these two servers. There is a minimum of
one TCP connection between one server and every other failover server one TCP connection between one server and every other failover server
with which it implements the failover protocol. with which it implements the failover protocol.
8.2. Creating the TCP connection 8.2. Creating the TCP connection
There are two ports used for initiating TCP connections, correspond- There are two ports used for initiating TCP connections, correspond-
ing to the two roles that a server can fill with respect to another ing to the two roles that a server can fill with respect to another
server. Every server implementing the failover protcol MUST listen server. Every server implementing the failover protocol MUST listen
on at least one of these ports. Port 647 is the port to which pri- 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 mary servers will attempt a connection, and port 847 is the port to
which secondary servers will attempt a connection. When a connection which secondary servers will attempt a connection. When a connection
attempt is received on port 647 it is therefore from a primary attempt is received on port 647, it is therefore from a primary
server, and it is attempting to connect to this server to become a server, and the primary server is attempting to connect to this
secondary server for it. Likewise, when an attempt to connect is secondary server. Likewise, when a connection attempt is received on
received on port 847 the connection attempt is from a secondary port 847, it is therefore from a secondary server, and the secondary
server, and it is attempting to connect to this server to be a pri- server is attempting to connect to this primary server." See the
mary server. The source port of any TCP connection is unimportant. schematic representation below:
See the schematic representation below:
Primary Server Primary Server
-------------- --------------
Listens on port 847 for secondary server to connect to it Listens on port 847 for secondary server to connect to it
Periodically connects on port 647 to contact secondary Periodically connects on port 647 to contact secondary
Secondary Server Secondary Server
-------------- --------------
Listens on port 647 for primary server to connect to it Listens on port 647 for primary server to connect to it
Periodically connects on port TDB to contact primary 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.
skipping to change at page 80, line 45 skipping to change at page 84, line 13
has failed: has failed:
1. The TCP connection can go down, yielding an error when 1. The TCP connection can go down, yielding an error when
attempting to send or receive a message. This will happen at attempting to send or receive a message. This will happen at
least as often as the period of the tSend timer. least as often as the period of the tSend timer.
2. The tReceive timer can expire. 2. The tReceive timer can expire.
In either of these cases, communications is considered interrupted. In either of these cases, communications is considered interrupted.
If the tReceive timer expires, the connnection MUST be dropped. The If the tReceive timer expires, the connection MUST be dropped. The
reject reason 17: "No traffic within sufficient time" is placed in reject reason 17: "No traffic within sufficient time" is placed in
the DISCONNECT message sent prior to dropping the TCP connection. the DISCONNECT message sent prior to dropping the TCP connection.
Several difficulties arise when trying to use one TCP connection for Several difficulties arise when trying to use one TCP connection for
both bulk data transfer as well as to sense the communications status both bulk data transfer as well as to sense the communications status
of the other server. One aspect of the problem stems from the dif- of the other server. One aspect of the problem stems from the dif-
ferent requirements of both uses. The bulk data transfer is of ferent requirements of both uses. The bulk data transfer is of
course critically important to the protocol, but the speed with which course critically important to the protocol, but the speed with which
it is processed is not terribly significant. It might well be it is processed is not terribly significant. It might well be
minutes before a BNDUPD message is processed, and while not optimal, minutes before a BNDUPD message is processed, and while not optimal,
skipping to change at page 81, line 30 skipping to change at page 84, line 44
The solution to this problem is to require that some message be The solution to this problem is to require that some message be
received by each end of the connection within a limited time or that received by each end of the connection within a limited time or that
the connection will be considered down. If no messages have been the connection will be considered down. If no messages have been
sent recently, then a CONTACT message is sent. sent recently, then a CONTACT message is sent.
In the case where there is no data queued to be sent, this is not a In the case where there is no data queued to be sent, this is not a
problem, but in the case where there is data queued to be sent to the problem, but in the case where there is data queued to be sent to the
partner, then the CONTACT message will not actually be transmitted partner, then the CONTACT message will not actually be transmitted
until the queued data is sent. Section 3.5 explains why waiting for until the queued data is sent. Section 3.5 explains why waiting for
TCP to determine that the connection is down is not acceptable, and TCP to determine that the connection is down is not acceptable, and
leads a requirement that the receiving server never block the sending leads to a requirement that the receiving server never block the
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 mes-
sage except for very short periods, less than a few seconds unless sage 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 prevented because if the receiver is not reachable (via the net-
network), the sending TCP can't send and thus it will be unable to work), the sending TCP can't send and thus it will be unable to
empty the local TCP send buffers. So, all send operations either empty the local TCP send buffers. So, all send operations either
need to assume they may block for some time or non-blocking sends need to assume they may block for some time or non-blocking sends
must be used. must be used carefully.
8.4. Using the TCP connection for binding data 8.4. Using the TCP connection for binding data
Binding data, in the form of BNDUPD messages and BNDACK messages to Binding data, in the form of BNDUPD messages and BNDACK messages to
respond to them, are sent across the TCP connection. respond to them, are sent across the TCP connection.
In order to support timely detection of any failure in the partner In order to support timely detection of any failure in the partner
server, the TCP connection MUST NOT block for more than a very short server, the TCP connection MUST NOT block for more than a very short
time, on the order of a few seconds. Therefore, a server that is time, on the order of a few seconds. Therefore, a server that is
sending BNDUPD messages MUST send only a restricted number before sending BNDUPD messages MUST send only a restricted number before
skipping to change at page 83, line 30 skipping to change at page 86, line 43
state differs from the state transition diagram, the textual descrip- state differs from the state transition diagram, the textual descrip-
tion is to be considered authoritative. tion is to be considered authoritative.
9.1. Server Initialization 9.1. Server Initialization
When a server starts it starts out in STARTUP state. See section 9.3 When a server starts it starts out in STARTUP state. See section 9.3
below for details. below for details.
9.2. Server State Transitions 9.2. Server State Transitions
Whenever a server transitions into a new state, it MUST record the Whenever a server makes a transition into a new state, it MUST record
state and the time at which it entered that state in stable storage. the state and the time at which it entered that state in stable
If communications is "ok", it MUST also send a STATE message to its storage. If communications is "ok", it MUST also send a STATE mes-
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 speci- The server stays in the current state until all of the actions
fied on the state transition are complete. If communications fails specified on the state transition are complete. If communications
during one of the actions, the server simply stays in the current fails during one of the actions, the server simply stays in the
state and attempts a transition whenever the conditions for a transi- current state and attempts a transition whenever the conditions for a
tion are later fulfilled. transition 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.6.2 for details on load balancing. 9.8.2 for details on load balancing.
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
skipping to change at page 85, line 7 skipping to change at page 89, line 7
thus be available to the server after a server restart. thus be available to the server after a server restart.
A transition into SHUTDOWN or PAUSED state is not represented in the A transition into SHUTDOWN or PAUSED state is not represented in the
following figure, since other than sending that state to its partner, following figure, since other than sending that state to its partner,
the remaining actions involved look just like the server halting in the remaining actions involved look just like the server halting in
its otherwise current state, which then becomes the previous state its otherwise current state, which then becomes the previous state
upon server restart. upon server restart.
+---------------+ V +--------------+ +---------------+ V +--------------+
| RECOVER -|+| | | STARTUP - | | RECOVER -|+| | | STARTUP - |
+->+(unresponsive) | +->+(unresponsive)| |(unresponsive) | +->+(unresponsive)|
| +------+--------+ +--------------+ +------+--------+ +--------------+
| Comm. OK +-----------------+ +-Comm. OK +-----------------+
Comm. Other State:RECOVER | PARTNER DOWN - +<----------------------+ | Other State: | PARTNER DOWN - +<----------------------+
Fail | RESOLUTION-INTER. | (responsive) | ^ | RESOLUTION-INTER. | (responsive) | ^
| All POTENTIAL- +----+------------+ +--------------+ | All POTENTIAL- +----+------------+ |
| Others CONFLICT------------ | --------+ | RESOLUTION -| | Others CONFLICT------------ | --------+ |
| | CONFLICT-DONE Comm. OK | | INTERRUPTED | | | CONFLICT-DONE Comm. OK | +--------------+ |
[UPDREQALL Other State: | +-+ (responsive) | | UPDREQ or Other State: | +--+ RESOLUTION - | |
[Wait UPDDONEE | | | | +------+------++ | UPDREQALL | | | | | INTERRUPTED | |
[Wait MCLT from fail RECOVER All Others| Comm.OK ^ | | Rcv UPDDONE RECOVER All | | | (responsive) | |
+---+----------+ | V V V Comm. Ext. | | +---------------+ | Others | | +------------+-+ |
|RECOVER-DONE +| +--+ +---+-----+--+-+ Failed Cmd----->+ +->+RECOVER-WAIT +-| RECOVER | | | ^ | |
|(unresponsive)| | | POTENTIAL + +------+ | |(unresponsive) | WAIT or | | Comm. | Ext. |
+------+-------+ Wait for +>+ CONFLICT +-Pri. Resolve Comm. | +-----------+---+ DONE | | OK Comm. Cmd----->+
Comm. OK Other | |(unresponsive)| Conflict CHANGED | Comm.---+ Wait MCLT | V V V Failed |
+--Other State:-+ State: | +----+--------++ V V | | Changed | V +---+ +---+-----+--+-+ | |
| | | RECOVER | | ^ ++----------+---++ | | +---+----------++ | | POTENTIAL + +-------+ |
| All POTENT. DONE | Sec. Resolve | |CONFLICT-DONE-|+| | | |RECOVER-DONE +-| Wait | CONFLICT +------+ |
| Others: CONFLICT-- | ----+ Conflict(9.8) | | (responsive) | | +->+(unresponsive) | for |(unresponsive)| Primary |
| Wait for V V | +------+---------+ | +------+--------+ Other +>+----+--------++ resolve Comm. |
| Other State: NORMAL ++------------+---+ Other State: NORMAL | Comm. OK State: | | ^ conflict Changed |
| V | NORMAL + +<--------------+ | +---Other State:-+ RECOVER | Secondary | V V | |
| | | DONE | resolve | ++----------+---++ |
| All Others: POTENT. | | conflict | |CONFLICT-DONE-|+| |
| Wait for CONFLICT- | ----+ see (9.10) | | (responsive) | |
| Other State: V V | +------+---------+ |
| NORMAL or RECOVER ++------------+---+ Other State: NORMAL |
| | DONE | NORMAL + +<--------------+ |
| +--+----------+-->+ (balanced) +-------External Command--->+ | +--+----------+-->+ (balanced) +-------External Command--->+
| ^ ^ +--------+--------+ or Other State: | | ^ ^ +--------+--------+ or Other State: |
| | | | | SHUTDOWN | | | | | | SHUTDOWN |
| Wait for Comm. OK Comm. Failed or | | | Wait for Comm. OK Comm. Failed or | |
| Other Other Other State: PAUSED | External | Other Other Other State: PAUSED | External
| State: State: | | Command | State: State: | | Command
|RECOVER-DONE NORMAL Start Safe Comm. OK or |RECOVER-DONE NORMAL Start Safe Comm. OK or
| | COMM. INT. Period Timer Other State: Safe | | COMM. INT. Period Timer Other State: Safe
| Comm. OK. | V All Others Period | Comm. OK. | V All Others Period
| Other State: | +---------+--------+ | expiration | Other State: | +---------+--------+ | expiration
| RECOVER +--+ COMMUNICATIONS - +----+ | | RECOVER +--+ COMMUNICATIONS - +----+ |
V +-------------+ INTERRUPTED | | | +-------------+ INTERRUPTED | |
RECOVER | (responsive) +-------------------------->+ RECOVER | (responsive) +-------------------------->+
RECOVER-DONE--------->+------------------+ RECOVER-WAIT--------->+------------------+
Figure 9.2-1: Server state diagram. Figure 9.2-1: Server state diagram.
9.3. STARTUP state 9.3. STARTUP state
The STARTUP state affords an opportunity for a server to probe its The STARTUP state affords an opportunity for a server to probe its
partner server, before starting to service DHCP clients. partner server, before starting to service DHCP clients.
DISCUSSION: DISCUSSION:
Without the STARTUP state, a server would likely start in a state Without the STARTUP state, a server would likely start in a state
skipping to change at page 86, line 30 skipping to change at page 90, line 30
especially critical if significant time has elapsed while the especially critical if significant time has elapsed while the
server was down. server was down.
9.3.1. Operation while in STARTUP state 9.3.1. Operation while in STARTUP state
Whenever a server is in STARTUP state, it MUST be unresponsive to Whenever a server is in STARTUP state, it MUST be unresponsive to
DHCP client requests, and so the time spent in the STARTUP state is DHCP client requests, and so the time spent in the STARTUP state is
necessarily short, typically on the order of a few seconds to a few necessarily short, typically on the order of a few seconds to a few
tens of seconds. The exact time spent in the STARTUP state is imple- tens of seconds. The exact time spent in the STARTUP state is imple-
mentation dependent, and the primary and secondary server are not mentation dependent, and the primary and secondary server are not
required to spend the same amount of time in the STARTUP state. required to spend the same amount of time in the STARTUP state. See
section 5.9 for some guidelines on the time to spend in STARTUP
state.
Whenever a STATE message is sent to the partner while in STARTUP Whenever a STATE message is sent to the partner while in STARTUP
state the STARTUP bit MUST be set in the server-flags option and the state the STARTUP bit MUST be set in the server-flags option and the
previously recorded failover state MUST be placed in the server-state previously recorded failover state MUST be placed in the server-state
option. option.
9.3.2. Transition out of STARTUP state 9.3.2. Transition out of STARTUP state
Each server starts out in startup state every time it initializes Each server starts out in startup state every time it initializes
itself, and performs the following algorithm as part of its initiali- itself, and performs the following algorithm as part of its initiali-
skipping to change at page 87, line 9 skipping to change at page 91, line 11
in stable storage, and continue with step 2. in stable storage, and continue with step 2.
Is there any configuration information that indicates that Is there any configuration information that indicates that
this server was previously running but lost its stable this server was previously running but lost its stable
storage? Such information must typically come from some storage? Such information must typically come from some
administrative intervention, since it is difficult for a administrative intervention, since it is difficult for a
server to distinguish first startup from a startup after it server to distinguish first startup from a startup after it
has lost its stable storage. If yes, then set the previous- has lost its stable storage. If yes, then set the previous-
state to RECOVER, and set the time-of-failure to whatever time state to RECOVER, and set the time-of-failure to whatever time
was configured, and go on to step 2. This time-of-failure was configured, and go on to step 2. This time-of-failure
will be used in the transition out of the RECOVER state into will be used in the transition out of the RECOVER-WAIT state
the RECOVER-DONE state, below. into the RECOVER-DONE state, below.
If there is no record of any previous failover state in stable If there is no record of any previous failover state in stable
storage nor of any previous operational activity for this storage for this server, then set the previous-state to
server, then set the previous-state to PARTNER-DOWN if this RECOVER and set the time-of-failure to a time before the
server is a primary and RECOVER if this server is a secondary, maximum-client-lead-time before now. If using standard Posix
and set the time-of-failure to a time before the maximum- times, 0 would typically do quite well. This will allow two
client-lead-time before now. If using standard Posix times, 0 servers which already have lease information to synchronize
would typically do quite well. themselves prior to operating.
Note that neither server is responsive to DHCP client requests
while in the RECOVER state. If both servers can communicate,
however, they will come out of the RECOVER state and progress
through RECOVER-WAIT to RECOVER-DONE and thence to NORMAL or
COMMUNICATIONS-INTERRUPTED state quickly. If both have state,
then they will exchange information. If only one has state,
then the one that does not will complete its update of its
partner quickly (since it has nothing to send).
In some cases, an existing server will be commissioned as a
failover server and brought back into operation where its
partner is not yet available. In this case, the newly commis-
sioned failover server will not operate until its partner
comes online -- but it has operational responsibilities as a
DHCP server nonetheless. To properly handle this situation, a
server SHOULD be configurable in such a way as to move
directly into PARTNER-DOWN state after the startup period
expires if it has been unable to contact its partner during
the startup period.
2. If the previous state is one where communications was "OK", 2. If the previous state is one where communications was "OK",
then set the previous state to the state that is the result of then set the previous state to the state that is the result of
the communiations failed state transition in Figure 9.2-1 (if the communications failed state transition in Figure 9.2-1 (if
any -- some states both). such transition is shown -- some states don't have a communi-
cations failed state transition, since they allow both commun-
ications OK and failed).
3. Start the STARTUP state timer. The time that a server remains 3. Start the STARTUP state timer. The time that a server remains
in the STARTUP state (absent any communications with its in the STARTUP state (absent any communications with its
partner) is implementation dependent and SHOULD be configur- partner) is implementation dependent and SHOULD be
able. It SHOULD be long enough for a TCP connection to be configurable. It SHOULD be long enough for a TCP connection
created to a heavily loaded partner across a slow network. to be created to a heavily loaded partner across a slow net-
work.
4. Attempt to create a TCP connection to the failover partner. 4. Attempt to create a TCP connection to the failover partner.
See section 8.2. See section 8.2.
5. Wait for "communications okay", i.e., the process discussed in 5. Wait for "communications okay", i.e., the process discussed in
section 8.2 "Creating the TCP Connection", to complete, section 8.2 "Creating the TCP Connection", to complete,
including the receipt of a STATE message from the partner. including the receipt of a STATE message from the partner.
When and if communications become "okay", clear the STARTUP When and if communications become "okay", clear the STARTUP
flag, and set the current state to the previous-state. flag, and set the current state to the previous-state.
skipping to change at page 89, line 20 skipping to change at page 93, line 45
period of time (the MCLT interval) has elapsed from entry into period of time (the MCLT interval) has elapsed from entry into
PARTNER-DOWN state, it will allocate IP addresses from the set of all PARTNER-DOWN state, it will allocate IP addresses from the set of all
available IP addresses. available IP addresses.
Once a server has entered NORMAL state, the PARTNER-DOWN state is Once a server has entered NORMAL state, the PARTNER-DOWN state is
entered only on command of an external agency (typically an adminis- entered only on command of an external agency (typically an adminis-
trator of some sort) or after the expiration of an externally config- trator of some sort) or after the expiration of an externally config-
ured minimum safe-time after the beginning of COMMUNICATIONS- ured minimum safe-time after the beginning of COMMUNICATIONS-
INTERRUPTED state. INTERRUPTED state.
Any available IP address tagged as available for allocation by the Any IP address tagged as available for allocation by the other server
other server (at entry to PARTNER-DOWN state) MUST NOT be allocated (at entry to PARTNER-DOWN state) MUST NOT be allocated to a new
to a new client until the maximum-client-lead-time beyond the entry client until the maximum-client-lead-time beyond the entry into
into PARTNER-DOWN state has elapsed. PARTNER-DOWN state has elapsed.
A server in PARTNER-DOWN state MUST NOT allocate an IP address to a A server in PARTNER-DOWN state MUST NOT allocate an IP address to a
DHCP client different from that to which it was allocated at the DHCP client different from that to which it was allocated at the
entrance to PARTNER-DOWN state until the maximum-client-lead-time entrance to PARTNER-DOWN state until the maximum-client-lead-time
beyond the maximum of the following times: client expiration time, beyond the maximum of the following times: client expiration time,
most recently transmitted potential-expiration-time, most recently most recently transmitted potential-expiration-time, most recently
received ack of potential-expiration-time from the partner, and most received ack of potential-expiration-time from the partner, and most
recently acked potential-expiration-time to the partner. See section recently acked potential-expiration-time to the partner. See section
7.1.5 for details. If this time would be earlier than the current 7.1.5 for details. If this time would be earlier than the current
time plus the maximum-client-lead-time, then the time the server time plus the maximum-client-lead-time, then the time the server
entered PARTNER-DOWN state plus the maximum-client-lead-time is used. entered PARTNER-DOWN state plus the maximum-client-lead-time is used.
Two options exist for lease times given out while in PARTNER-DOWN Two options exist for lease times given out while in PARTNER-DOWN
state, with different ramifications flowing from each. state, with different ramifications flowing from each.
If the server wishes the Failover protocol to protect it from loss of If the server wishes the Failover protocol to protect it from loss of
stable storage in PARTNER-DOWN state, then it should ensure that the stable storage in PARTNER-DOWN state, then it should ensure that the
MCLT based lease time restrictions in Section 5.1 are maintained, MCLT based lease time restrictions in section 5.1 are maintained,
even in PARTNER-DOWN state. even in PARTNER-DOWN state.
If the server wishes to forego the protection of the Failover proto- If the server wishes to forego the protection of the Failover proto-
col in the event of loss of stable storage, then it need recognize no col in the event of loss of stable storage, then it need recognize no
restrictions on actual client lease times while in PARTNER-DOWN restrictions on actual client lease times while in PARTNER-DOWN
state. state.
A server in PARTNER-DOWN state MUST continue to attempt to establish A server in PARTNER-DOWN state MUST continue to attempt to establish
communications and synchronization with its partner. communications and synchronization with its partner.
skipping to change at page 90, line 22 skipping to change at page 94, line 47
If the STARTUP bit is set in the server-flags option of a received If the STARTUP bit is set in the server-flags option of a received
STATE message, a server in PARTNER-DOWN state MUST NOT take any state STATE message, a server in PARTNER-DOWN state MUST NOT take any state
transitions based on reestablishing communications. Essentially, if a transitions based on reestablishing communications. Essentially, if a
server is in PARTNER-DOWN state, it ignores all STATE messages from server is in PARTNER-DOWN state, it ignores all STATE messages from
its partner that have the STARTUP bit set in the server-flags option its partner that have the STARTUP bit set in the server-flags option
of the STATE message. of the STATE message.
If the STARTUP bit is not set in the server-flags option of a STATE If the STARTUP bit is not set in the server-flags option of a STATE
message received from its partner, then a server in PARTNER-DOWN message received from its partner, then a server in PARTNER-DOWN
state takes the following actions based on the value of the server- state takes the following actions based on the value of the server-
state option in the received STATE message: state option in the received STATE message (either immediately after
establishing communications or at any time later when a new state is
received):
o partner in NORMAL, COMMUNICATIONS-INTERRUPTED, PARTNER-DOWN, o partner in NORMAL, COMMUNICATIONS-INTERRUPTED, PARTNER-DOWN,
POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, or CONFLICT-DONE POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, or CONFLICT-DONE
state state
transition to POTENTIAL-CONFLICT state transition to POTENTIAL-CONFLICT state
o partner in RECOVER, SHUTDOWN, PAUSED state o partner in RECOVER, RECOVER-WAIT, SHUTDOWN, PAUSED state
stay in PARTNER-DOWN state stay in PARTNER-DOWN state
o partner in RECOVER-DONE state o partner in RECOVER-DONE state
transition into NORMAL state transition into NORMAL state
9.5. RECOVER state 9.5. RECOVER state
This state indicates that the server has no information in its stable This state indicates that the server has no information in its stable
skipping to change at page 91, line 12 skipping to change at page 95, line 38
A server in RECOVER state will attempt to reestablish communications A server in RECOVER state will attempt to reestablish communications
with the other server. with the other server.
9.5.2. Transitions out of RECOVER state 9.5.2. Transitions out of RECOVER state
If the other server is in POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, If the other server is in POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED,
or CONFLICT-DONE state when communications are reestablished, then or CONFLICT-DONE state when communications are reestablished, then
the server in RECOVER state will move to POTENTIAL-CONFLICT state the server in RECOVER state will move to POTENTIAL-CONFLICT state
itself. itself.
If the other server is in RECOVER state, then this server SHOULD sig-
nal an error and halt processing.
If the other server is in any other state, then the server in RECOVER If the other server is in any other state, then the server in RECOVER
state will request an update of missing binding information by send- state will request an update of missing binding information by send-
ing an UPDREQ message. If the server has been instructed (through ing an UPDREQ message. If the server has been instructed (through
configuration or other external agency) that it has lost its stable configuration or other external agency) that it has lost its stable
storage, or if it has deduced that from the fact that it has no storage, or if it has deduced that from the fact that it has no
record of ever having talked to its partner, while its partner does record of ever having talked to its partner, while its partner does
have a record of communicating with it, it MUST send an UPDREQALL have a record of communicating with it, it MUST send an UPDREQALL
message, otherwise it MUST send an UPDREQ message. message, otherwise it MUST send an UPDREQ message. See Figure
9.5.2-1.
It will wait for an UPDDONE message, and upon receipt of that message It will wait for an UPDDONE message, and upon receipt of that message
it will start a timer whose expiration is set to a time equal to the it will transition to RECOVER-WAIT state.
time the server went down (if known) or the time the server started
(if the down-time is unknown) plus the maximum-client-lead-time.
When this timer goes off, the server will transition into RECOVER-
DONE state. This is to allow any IP addresses that were allocated by
this server prior to loss of its client binding information in stable
storage to contact the other server or to time out.
See Figure 9.5.2-1.
DISCUSSION:
The actual requirement on this wait period in RECOVER is that it If communications fails during the reception of the results of the
start not before the recovering server went down, not necessarily UPDREQ or UPDREQALL message, the server will remain in RECOVER state,
when it came back up. If the time when the recovering server and will re-issue the UPDREQ or UPDREQALL when communications are
failed is known, it could be communicated to the recovering server re-established. (See section 5.17).
(perhaps through actions of the network administrator), and the
wait period could be reduced to the maximum-client-lead-time less
the difference between the current time and the time the server
failed. In this way, the waiting period could be minimized.
Various heuristics could be used to estimate this time, for exam-
ple if the recovering server periodically updates stable storage
with a time stamp, the wait period could be calculated to start at
the time of the last update of stable storage plus the time
required for the next update (which never occurred). This esti-
mate is later than the server went down, but probably not too much
later.
If an UPDDONE message isn't received within an implementation depen- If an UPDDONE message isn't received within an implementation depen-
dent amount of time, and no BNDUPD messages are being received, the dent amount of time, and no BNDUPD messages are being received, the
connection SHOULD be dropped. connection SHOULD be dropped.
A B A B
Server Server Server Server
| | | |
RECOVER PARTNER-DOWN RECOVER PARTNER-DOWN
skipping to change at page 92, line 26 skipping to change at page 96, line 29
| | | |
| <---------------------BNDUPD--< | | <---------------------BNDUPD--< |
| >--BNDACK--------------------> | | >--BNDACK--------------------> |
... ... ... ...
| | | |
| <---------------------BNDUPD--< | | <---------------------BNDUPD--< |
| >--BNDACK--------------------> | | >--BNDACK--------------------> |
| | | |
| <--------------------UPDDONE--< | | <--------------------UPDDONE--< |
| | | |
RECOVER-WAIT |
| |
| >--STATE-(RECOVER-WAIT)------> |
| |
| |
Wait MCLT from last known | Wait MCLT from last known |
time of operation | time of failover operation |
| | | |
RECOVER-DONE | RECOVER-DONE |
| | | |
| >--STATE-(RECOVER-DONE)------> | | >--STATE-(RECOVER-DONE)------> |
| NORMAL | NORMAL
| <-------------(NORMAL)-STATE--< | | <-------------(NORMAL)-STATE--< |
NORMAL | NORMAL |
| >---- State-(NORMAL)---------------> | >---- State-(NORMAL)--------------->
| | | |
| | | |
Figure 9.5.2-1: Transition out of RECOVER state Figure 9.5.2-1: Transition out of RECOVER state
If, at any time while a server is in RECOVER state communications fails, If, at any time while a server is in RECOVER state communications fails,
the server will stay in RECOVER state. When communications are the server will stay in RECOVER state. When communications are
restored, it will restart the process of transitioning out of RECOVER restored, it will restart the process of transitioning out of RECOVER
state. state.
9.6. NORMAL state 9.6. RECOVER-WAIT state
This state indicates that the server has done an UPDREQ or UPDREQALL
and has received the UPDDONE message indicating that it has received
all outstanding binding update information. In the RECOVER-WAIT
state the server will wait for the MCLT in order to ensure that any
processing that this server might have done prior to losing its
stable storage will not cause future difficulties.
9.6.1. Operation in RECOVER-WAIT state
A server in RECOVER-WAIT MUST NOT respond to DHCP client requests.
9.6.2. Transitions out of RECOVER-WAIT state
Upon entry to RECOVER-WAIT state the server MUST start a timer whose
expiration is set to a time equal to the time the server went down
(if known) or the time the server started (if the down-time is
unknown) plus the maximum-client-lead-time. When this timer goes
off, the server will transition into RECOVER-DONE state.
This is to allow any IP addresses that were allocated by this server
prior to loss of its client binding information in stable storage to
contact the other server or to time out.
If this is the first time this server has run failover -- as
determined by the information received from the partner, not
necessarily only as determined by this server's stable storage (as
that may have been lost), then the waiting time discussed above may
be skipped, and the server may transition immediately to RECOVER-DONE
state.
See Figure 9.5.2-1.
DISCUSSION:
The actual requirement on this wait period in RECOVER is that it
start not before the recovering server went down, not necessarily
when it came back up. If the time when the recovering server
failed is known, it could be communicated to the recovering server
(perhaps through actions of the network administrator), and the
wait period could be reduced to the maximum-client-lead-time less
the difference between the current time and the time the server
failed. In this way, the waiting period could be minimized.
Various heuristics could be used to estimate this time, for
example if the recovering server periodically updates stable
storage with a time stamp, the wait period could be calculated to
start at the time of the last update of stable storage plus the
time required for the next update (which never occurred). This
estimate is later than the server went down, but probably not too
much later.
If the server has never before run failover, then there is no need
to wait in this state -- but, again, to determine if this server
has run failover it is vital that the information provided by the
partner be utilized, since the stable storage of this server may
have been lost.
If communications fails while a server is in RECOVER-WAIT state, it
has no effect on the operation of this state. The server SHOULD
continue to operate its timer, and the timer goes off during the
period where communications with the other server have failed, then
the server SHOULD transition to RECOVER-DONE state. This is rare --
failover state transitions are not usually made while communications
are interrupted, but in this case there is no reason to inhibit the
timer. A server MAY state in RECOVER-WAIT state even after expiry of
the timer and transition to RECOVER-DONE state upon re-establishing
communications with the partner if desired. The key point here is to
allow the timer to continue to operate, not whether or not the state
transition is made before or after communications are re-established.
9.7. RECOVER-DONE state
This state exists to allow an interlocked transition for one server
from RECOVER state and another server from PARTNER-DOWN or
COMMUNICATIONS-INTERRUPTED state into NORMAL state.
9.7.1. Operation in RECOVER-DONE state
A server in RECOVER-DONE state MUST respond only to
DHCPREQUEST/RENEWAL and DHCPREQUEST/REBINDING DHCP messages.
9.7.2. Transitions out of RECOVER-DONE state
When a server in RECOVER-DONE state determines that its partner
server has entered NORMAL or RECOVER-DONE state, then it will transi-
tion into NORMAL state.
If communications fails while in RECOVER-DONE state, a server will
stay in RECOVER-DONE state.
9.8. NORMAL state
NORMAL state is the state used by a server when it is communicating NORMAL state is the state used by a server when it is communicating
with the other server, and any required resynchronization has been with the other server, and any required resynchronization has been
performed. While some bindings database synchronization is performed performed. While some bindings database synchronization is performed
in NORMAL state, potential conflicts are resolved prior to entry into in NORMAL state, potential conflicts are resolved prior to entry into
NORMAL state as is binding database data loss. NORMAL state as is binding database data loss.
9.6.1. Upon entry to NORMAL state 9.8.1. Upon entry to NORMAL state
When entering NORMAL state, a server will send to the other server When entering NORMAL state, a server will send to the other server
all currently unacknowledged binding updates as BNDUPD messages. all currently unacknowledged binding updates as BNDUPD messages.
When the above process is complete, if the server entering NORMAL When the above process is complete, if the server entering NORMAL
state is a secondary server, then it will request IP addresses for state is a secondary server, then it will request IP addresses for
allocation using the POOLREQ message. allocation using the POOLREQ message.
9.6.2. Processing DHCP client requests and load balancing 9.8.2. Processing DHCP client requests and load balancing
In NORMAL state, a server MUST process every DHCPREQUEST/RENEWAL or In NORMAL state, a server MUST process every DHCPREQUEST/RENEWAL or
DHCPREQUEST/REBINDING request it receives. And, it processes other DHCPREQUEST/REBINDING request it receives. And, it processes other
requests only for those clients as dictated by the load balancing requests only for those clients as dictated by the load balancing
algorithm specified in [LOADB]. algorithm specified in [RFC 3074].
As discussed in section 5.3, each server will take the client- As discussed in section 5.3, each server will take the client-
identifier from each DHCP client request (or the client-hardware- identifier from each DHCP client request (or the client-hardware-
address, i.e., the htype concatenated to the front of the chaddr if address, i.e., the chaddr if no client-identifier is present in the
no client-identifier is present in the request) and use it as the request) and use it as the 'Request ID' specified in [RFC 3074].
'Request ID' specified in [LOADB]. After applying the algorithm After applying the algorithm specified in [RFC 3074] and comparing
specified in [LOADB] and comparing the result with the hash bucket the result with the hash bucket assignment (performed during connect
assignment (performed during connect processing between failover processing between failover servers), each failover server will be
servers), each failover server will be able to unambiguously deter- able to unambiguously determine if it should process the DHCP client
mine if it should process the DHCP client request. request.
9.6.3. Operation in NORMAL state 9.8.3. Operation in NORMAL state
When in NORMAL state, for every DHCP client request that it When in NORMAL state, for every DHCP client request that it
processes, as determined by the algorithm described in section 9.6.2, processes, as determined by the algorithm described in section 9.8.2,
above, a server will operate in the following manner: above, a server will operate in the following manner:
o Lease time calculations o Lease time calculations
As discussed in section 5.2.1, "Control of lease time", the As discussed in section 5.2.1, "Control of lease time", the
lease interval given to a DHCP client can never be more than the lease interval given to a DHCP client can never be more than the
MCLT greater than the most recently received potential- MCLT greater than the most recently received potential-
expiration-time from the failover partner or the current time, expiration-time from the failover partner or the current time,
whichever is later. whichever is later.
As long as a server adheres to this constraint, the specifics of As long as a server adheres to this constraint, the specifics of
the lease interval that it gives to a DHCP client or the value the lease interval that it gives to a DHCP client or the value
of the potential-expiration-time sent to its failover partner of the potential-expiration-time sent to its failover partner
are implementation dependent. One possible approach is dis- are implementation dependent. One possible approach is dis-
cussed in section 5.2.1, but that particular approach is in no cussed in section 5.2.1, but that particular approach is in no
way required by this protocol. way required by this protocol.
See section 7.1.5 for details concerning the storage of time See section 7.1.5 for details concerning the storage of time
associated IP addresses and how to use these times when calcu- associated with IP addresses and how to use these times when
lating lease times for DHCP clients. calculating lease times for DHCP clients.
o Lazy update of partner server o Lazy update of partner server
After an ACK of a IP address binding, the server servicing a After an DHCPACK of a IP address binding, the server servicing a
DHCP client request attempts to update its partner with the new DHCP client request attempts to update its partner with the new
binding information. The lease time used in the update of the binding information. The lease time used in the update of the
secondary MUST be at least that given to the DHCP client in the secondary MUST be at least that given to the DHCP client in the
DHCPACK, and the potential-expiration-time MUST be at least the DHCPACK, and the potential-expiration-time MUST be at least the
lease time, and SHOULD be considerably longer. lease time, and SHOULD be considerably longer.
o Reallocation of IP addresses between clients o Reallocation of IP addresses between clients
Whenever a client binding is released or expires, a BNDUPD mes- Whenever a client binding is released or expires, a BNDUPD mes-
sage must be sent to partner, setting the binding state to sage must be sent to the partner, setting the binding state to
RELEASED or EXPIRED. However, until a BNDACK is received for RELEASED or EXPIRED. However, until a BNDACK is received for
this message, the IP address cannot be allocated to another this message, the IP address cannot be allocated to another
client. It can be allocated to the same client again. client. It cannot be allocated to the same client again if a
BNDUPD was sent, otherwise it can. See section 5.2.2.
In normal state, each server receives binding updates from its In normal state, each server receives binding updates from its
partner server in BNDUPD messages. It records these in its client partner server in BNDUPD messages. It records these in its client
binding database in stable storage and then sends a corresponding binding database in stable storage and then sends a corresponding
BNDACK message to the primary server. It MUST ensure that the infor- BNDACK message to its partner server. It MUST ensure that the infor-
mation is recorded in stable storage prior to sending the BNDACK mes- mation is recorded in stable storage prior to sending the BNDACK mes-
sage back to its partner. sage back to its partner.
9.6.4. Transitions out of NORMAL state 9.8.4. Transitions out of NORMAL state
If an external command is received by a server in NORMAL state If an external command is received by a server in NORMAL state
informing it that its partner is down, then transition into PARTNER- informing it that its partner is down, then transition into PARTNER-
DOWN state. Generally, this would be an unusual situation, where DOWN state. Generally, this would be an unusual situation, where
some external agency knew the partner server was down. Using the some external agency knew the partner server was down. Using the
command in this case would be appropriate if the polling interval and command in this case would be appropriate if the polling interval and
timeout were long. timeout were long.
If a server in NORMAL state fails to receive acks to messages sent to If a server in NORMAL state fails to receive acks to messages sent to
its partner for an implementation dependent period of time, it MAY its partner for an implementation dependent period of time, it MAY
skipping to change at page 95, line 32 skipping to change at page 101, line 30
in NORMAL state, then the server should transition into in NORMAL state, then the server should transition into
COMMUNICATIONS-INTERRUPTED state and take the appropriate state tran- COMMUNICATIONS-INTERRUPTED state and take the appropriate state tran-
sition from there. For example, it would be expected for the partner sition from there. For example, it would be expected for the partner
to transition from POTENTIAL-CONFLICT into NORMAL state, but not for to transition from POTENTIAL-CONFLICT into NORMAL state, but not for
the partner to transition from NORMAL into POTENTIAL-CONFLICT state. the partner to transition from NORMAL into POTENTIAL-CONFLICT state.
If a server in NORMAL state receives any messages from its partner If a server in NORMAL state receives any messages from its partner
where the PARTNER has changed into PAUSED state, the server should where the PARTNER has changed into PAUSED state, the server should
transition into COMMUNICATIONS-INTERRUPTED state. If a server in transition into COMMUNICATIONS-INTERRUPTED state. If a server in
NORMAL state receives any messages from its partner where the PARTNER NORMAL state receives any messages from its partner where the PARTNER
has changed into SHUTUDOWN state, the server should transition into has changed into SHUTDOWN state, the server should transition into
PARTNER-DOWN state. PARTNER-DOWN state.
9.7. COMMUNICATIONS-INTERRUPTED State 9.9. COMMUNICATIONS-INTERRUPTED State
A server goes into COMMUNICATIONS-INTERRUPTED state whenever it is A server goes into COMMUNICATIONS-INTERRUPTED state whenever it is
unable to communicate with the other server. Primary and secondary unable to communicate with the other server. Primary and secondary
servers cycle automatically (without administrative intervention) servers cycle automatically (without administrative intervention)
between NORMAL and COMMUNICATIONS-INTERRUPTED state as the network between NORMAL and COMMUNICATIONS-INTERRUPTED state as the network
connection between them fails and recovers, or as the partner server connection between them fails and recovers, or as the partner server
cycles between operational and non-operational. No duplicate IP cycles between operational and non-operational. No duplicate IP
address allocation can occur while the servers cycle between these address allocation can occur while the servers cycle between these
states. states.
9.7.1. Upon entry to COMMUNICATIONS-INTERRUPTED state 9.9.1. Upon entry to COMMUNICATIONS-INTERRUPTED state
When a server enters COMMUNICATIONS-INTERRUPTED state, if it has been When a server enters COMMUNICATIONS-INTERRUPTED state, if it has been
configured to support an automatic transition out of COMMUNICATIONS- configured to support an automatic transition out of COMMUNICATIONS-
INTERRUPTED state and into PARTNER-DOWN state (i.e., a "safe period" INTERRUPTED state and into PARTNER-DOWN state (i.e., a "safe period"
has been configured, see section 10), then a timer MUST be started has been configured, see section 10), then a timer MUST be started
for the length of the configured safe period. for the length of the configured safe period.
A server transitioning into the COMMUNICATIONS-INTERRUPTED state from A server transitioning into the COMMUNICATIONS-INTERRUPTED state from
the NORMAL state SHOULD raise some alarm condition to alert adminis- the NORMAL state SHOULD raise some alarm condition to alert adminis-
trative staff to a potential problem in the DHCP subsystem. trative staff to a potential problem in the DHCP subsystem.
9.7.2. Operation in COMMUNICATIONS-INTERRUPTED State 9.9.2. Operation in COMMUNICATIONS-INTERRUPTED State
In this state a server MUST respond to all DHCP client requests, and In this state a server MUST respond to all DHCP client requests, and
the algorithm for load balancing described in section 5.3 MUST NOT be the algorithm for load balancing described in section 5.3 MUST NOT be
used. When allocating new IP addresses, each server allocates from used. When allocating new IP addresses, each server allocates from
its own IP address pool, where the primary MUST allocate only FREE IP its own IP address pool, where the primary MUST allocate only FREE IP
addresses, and the secondary MUST allocate only BACKUP IP addresses. addresses, and the secondary MUST allocate only BACKUP IP addresses.
When responding to renewal requests, each server will allow continued When responding to renewal requests, each server will allow continued
renewal of a DHCP client's current lease on an IP address irrespec- renewal of a DHCP client's current lease on an IP address irrespec-
tive of whether that lease was given out by the receiving server or tive of whether that lease was given out by the receiving server or
not, although the renewal period MUST NOT exceed the maximum client not, although the renewal period MUST NOT exceed the maximum client
skipping to change at page 96, line 34 skipping to change at page 102, line 32
expiration-time, or 3) the potential-expiration-time received from expiration-time, or 3) the potential-expiration-time received from
the partner server. the partner server.
However, since the server cannot communicate with its partner in this However, since the server cannot communicate with its partner in this
state, the acknowledged-potential-expiration time will not be updated state, the acknowledged-potential-expiration time will not be updated
in any new bindings. This is likely to eventually cause the actual- in any new bindings. This is likely to eventually cause the actual-
client-lease-times to be the current time plus the maximum-client- client-lease-times to be the current time plus the maximum-client-
lead-time (unless this is greater than the desired-client-lease- lead-time (unless this is greater than the desired-client-lease-
time). time).
9.7.3. Transition out of COMMUNICATIONS-INTERRUPTED State The server should continue to try to establish a connection with its
partner.
9.9.3. Transition out of COMMUNICATIONS-INTERRUPTED State
If the safe period timer expires while a server is in the If the safe period timer expires while a server is in the
COMMUNICATIONS-INTERRUPTED state, it will transition immediately into COMMUNICATIONS-INTERRUPTED state, it will transition immediately into
PARTNER-DOWN state. PARTNER-DOWN state.
If an external command is received by a server in COMMUNICATIONS- If an external command is received by a server in COMMUNICATIONS-
INTERRUPTED state informing it that its partner is down, it will INTERRUPTED state informing it that its partner is down, it will
transition immediately into PARTNER-DOWN state. transition immediately into PARTNER-DOWN state.
If communications is restored with the other server, then the server If communications is restored with the other server, then the server
skipping to change at page 98, line 19 skipping to change at page 104, line 19
| >--CONTACT-------------------> | | >--CONTACT-------------------> |
| <--------------------CONTACT--< | | <--------------------CONTACT--< |
| [TCP connection broken] | | [TCP connection broken] |
COMMUNICATIONS : COMMUNICATIONS COMMUNICATIONS : COMMUNICATIONS
INTERRUPTED : INTERRUPTED INTERRUPTED : INTERRUPTED
| [attempt new TCP connection] | | [attempt new TCP connection] |
| [connection succeeds] | | [connection succeeds] |
| | | |
| >--CONNECT-------------------> | | >--CONNECT-------------------> |
| <-----------------CONNECTACK--< | | <-----------------CONNECTACK--< |
| <-------------------STATE-----< |
| NORMAL | NORMAL
| >--STATE---------------------> | | <-------------------STATE-----< |
NORMAL | NORMAL |
| >--STATE---------------------> |
|
| >--BNDUPD--------------------> | | >--BNDUPD--------------------> |
| <---------------------BNDACK--< | | <---------------------BNDACK--< |
| | | |
| <---------------------BNDUPD--< | | <---------------------BNDUPD--< |
| >------BNDACK----------------> | | >------BNDACK----------------> |
... ... ... ...
| | | |
| <--------------------POOLREQ--< | | <--------------------POOLREQ--< |
| >--POOLRESP-(2)--------------> | | >--POOLRESP-(2)--------------> |
| | | |
| >--BNDUPD-(#1)---------------> | | >--BNDUPD-(#1)---------------> |
| <---------------------BNDACK--< | | <---------------------BNDACK--< |
| | | |
| <--------------------POOLREQ--< | | <--------------------POOLREQ--< |
| >--POOLRESP-(0)--------------> | | >--POOLRESP-(0)--------------> |
| | | |
| >--BNDUPD-(#2)---------------> | | >--BNDUPD-(#2)---------------> |
| <---------------------BNDACK--< | | <---------------------BNDACK--< |
| | | |
Figure 9.7.3-1: Transition from NORMAL to COMMUNICATIONS- Figure 9.9.3-1: Transition from NORMAL to COMMUNICATIONS-
INTERRUPTED and back (example with 2 INTERRUPTED and back (example with 2
addresses allocated to secondary) addresses allocated to secondary)
9.8. POTENTIAL-CONFLICT state 9.10. POTENTIAL-CONFLICT state
This state indicates that the two servers are attempting to re- This state indicates that the two servers are attempting to re-
integrate with each other, but at least one of them was running in a integrate with each other, but at least one of them was running in a
state that did not guarantee automatic reintegration would be state that did not guarantee automatic reintegration would be
possible. In POTENTIAL-CONFLICT state the servers may determine that possible. In POTENTIAL-CONFLICT state the servers may determine that
the same IP address has been offered and accepted by two different the same IP address has been offered and accepted by two different
DHCP clients. DHCP clients.
It is a goal of this protocol to minimize the possibility that It is a goal of this protocol to minimize the possibility that
POTENTIAL-CONFLICT state is ever entered. POTENTIAL-CONFLICT state is ever entered.
9.8.1. Upon entry to POTENTIAL-CONFLICT state 9.10.1. Upon entry to POTENTIAL-CONFLICT state
When a primary server enters POTENTIAL-CONFLICT state it should When a primary server enters POTENTIAL-CONFLICT state it should
request that the secondary send it all updates of which it is request that the secondary send it all updates of which it is
currently unaware by sending an UPDREQ message to the secondary currently unaware by sending an UPDREQ message to the secondary
server. server.
A secondary server entering POTENTIAL-CONFLICT state will wait for A secondary server entering POTENTIAL-CONFLICT state will wait for
the primary to send it an UPDREQ message. the primary to send it an UPDREQ message.
9.8.2. Operation in POTENTIAL-CONFLICT state 9.10.2. Operation in POTENTIAL-CONFLICT state
Any server in POTENTIAL-CONFLICT state MUST NOT process any incoming Any server in POTENTIAL-CONFLICT state MUST NOT process any incoming
DHCP requests. DHCP requests.
9.8.3. Transitions out of POTENTIAL-CONFLICT state 9.10.3. Transitions out of POTENTIAL-CONFLICT state
If communications fails with the partner while in POTENTIAL-CONFLICT If communications fails with the partner while in POTENTIAL-CONFLICT
state, then the server will transition to RESOLUTION-INTERRUPTED state, then the server will transition to RESOLUTION-INTERRUPTED
state. state.
Whenever either server receives an UPDDONE message from its partner Whenever either server receives an UPDDONE message from its partner
while in POTENTIAL-CONFLICT state, it MUST transition to a new state. while in POTENTIAL-CONFLICT state, it MUST transition to a new state.
The primary MUST transition to CONFLICT-DONE state, and the secondary The primary MUST transition to CONFLICT-DONE state, and the secondary
MUST transition to NORMAL state. This will cause the primary server MUST transition to NORMAL state. This will cause the primary server
to leave POTENTIAL-CONFLICT state prior to the secondary, since the to leave POTENTIAL-CONFLICT state prior to the secondary, since the
primary sends an UPDREQ message and receives an UPDDONE before the primary sends an UPDREQ message and receives an UPDDONE before the
secondary sends an UPDREQ message and receives its UPDDONE message. secondary sends an UPDREQ message and receives its UPDDONE message.
When a secondary server receives an indication that the primary When a secondary server receives an indication that the primary
server has transitioned from POTENTIAL-CONFLICT to CONFLICT-DONE server has made a transition from POTENTIAL-CONFLICT to CONFLICT-DONE
state, it SHOULD send an UPDREQ message to the primary server. state, it SHOULD send an UPDREQ message to the primary server.
Primary Secondary Primary Secondary
Server Server Server Server
| | | |
POTENTIAL-CONFLICT POTENTIAL-CONFLICT POTENTIAL-CONFLICT POTENTIAL-CONFLICT
| | | |
| >--UPDREQ--------------------> | | >--UPDREQ--------------------> |
| | | |
skipping to change at page 100, line 33 skipping to change at page 106, line 33
| <---------------------UPDREQ--< | | <---------------------UPDREQ--< |
| | | |
| >--BNDUPD--------------------> | | >--BNDUPD--------------------> |
| <---------------------BNDACK--< | | <---------------------BNDACK--< |
... ... ... ...
| >--BNDUPD--------------------> | | >--BNDUPD--------------------> |
| <---------------------BNDACK--< | | <---------------------BNDACK--< |
| | | |
| >--UPDDONE-------------------> | | >--UPDDONE-------------------> |
| NORMAL | NORMAL
| <------------STATE--(NORMAL)--< |
| | | |
| <--------------------POOLREQ--< | | <--------------------POOLREQ--< |
| >------POOLRESP-(n)----------> | | >------POOLRESP-(n)----------> |
| addresses | | addresses |
Figure 9.8.3-1: Transition out of POTENTIAL-CONFLICT Figure 9.8.3-1: Transition out of POTENTIAL-CONFLICT
9.9. RESOLUTION-INTERRUPTED state 9.11. RESOLUTION-INTERRUPTED state
This state indicates that the two servers were attempting to re- This state indicates that the two servers were attempting to re-
integrate with each other in POTENTIAL-CONFLICT state, but integrate with each other in POTENTIAL-CONFLICT state, but
communications failed prior to completion of re-integration. communications failed prior to completion of re-integration.
If the servers remained in POTENTIAL-CONFLICT while communications If the servers remained in POTENTIAL-CONFLICT while communications
was interrupted, neither server would be responsive to DHCP client was interrupted, neither server would be responsive to DHCP client
requests, and if one server had crashed, then there might be no requests, and if one server had crashed, then there might be no
server able to process DHCP requests. server able to process DHCP requests.
9.9.1. Upon entry to RESOLUTION-INTERRUPTED state 9.11.1. Upon entry to RESOLUTION-INTERRUPTED state
When a server enters RESOLUTION-INTERRUPTED state it SHOULD raise an When a server enters RESOLUTION-INTERRUPTED state it SHOULD raise an
alarm condition to alert administrative staff of a problem in the alarm condition to alert administrative staff of a problem in the
DHCP subsystem. DHCP subsystem.
9.9.2. Operation in RESOLUTION-INTERRUPTED state 9.11.2. Operation in RESOLUTION-INTERRUPTED state
In this state a server MUST respond to all DHCP client requests, and In this state a server MUST respond to all DHCP client requests, and
any load balancing (described in section 5.3) MUST NOT be used. When any load balancing (described in section 5.3) MUST NOT be used. When
allocating new IP addresses, each server SHOULD allocate from its own allocating new IP addresses, each server SHOULD allocate from its own
IP address pool (if that can be determined), where the primary SHOULD IP address pool (if that can be determined), where the primary SHOULD
allocate only FREE IP addresses, and the secondary SHOULD allocate allocate only FREE IP addresses, and the secondary SHOULD allocate
only BACKUP IP addresses. When responding to renewal requests, each only BACKUP IP addresses. When responding to renewal requests, each
server will allow continued renewal of a DHCP client's current lease server will allow continued renewal of a DHCP client's current lease
on an IP address irrespective of whether that lease was given out by on an IP address irrespective of whether that lease was given out by
the receiving server or not, although the renewal period MUST not the receiving server or not, although the renewal period MUST not
exceed the maximum client lead time (MCLT) beyond the latest of: 1) exceed the maximum client lead time (MCLT) beyond the latest of: 1)
the potential-expiration-time already acknowledged by the other the potential-expiration-time already acknowledged by the other
server or 2) the lease-expiration-time or 3) `potential-expiration- server or 2) the lease-expiration-time or 3) `potential-expiration-
time received from the partner server. time received from the partner server.
However, since the server cannot communicate with its partner in this However, since the server cannot communicate with its partner in this
state, the acknowledged-potential-expiration time will not be updated state, the acknowledged-potential-expiration time will not be updated
in any new bindings. in any new bindings.
9.9.3. Transitions out of RESOLUTION-INTERRUPTED state 9.11.3. Transitions out of RESOLUTION-INTERRUPTED state
If an external command is received by a server in RESOLUTION- If an external command is received by a server in RESOLUTION-
INTERRUPTED state informing it that its partner is down, it will INTERRUPTED state informing it that its partner is down, it will
transition immediately into PARTNER-DOWN state. transition immediately into PARTNER-DOWN state.
If communications is restored with the other server, then the server If communications is restored with the other server, then the server
in RESOLUTION-INTERRUPTED state will transition into POTENTIAL- in RESOLUTION-INTERRUPTED state will transition into POTENTIAL-
CONFLICT state. CONFLICT state.
9.10. CONFLICT-DONE state 9.12. CONFLICT-DONE state
This state indicates that during the process where the two servers This state indicates that during the process where the two servers
are attempting to re-integrate with each other, the primary server are attempting to re-integrate with each other, the primary server
has received all of the updates from the secondary server. It has received all of the updates from the secondary server. It make a
transitions into CONFLICT-DONE state in order that it may be totally transition into CONFLICT-DONE state in order that it may be totally
responsive to the client load, as opposed to NORMAL state where it responsive to the client load, as opposed to NORMAL state where it
would be in a "balanced" responsive state, running the load balancing would be in a "balanced" responsive state, running the load balancing
algorithm. algorithm.
9.10.1. Upon entry to CONFLICT-DONE state 9.12.1. Upon entry to CONFLICT-DONE state
A secondary server should never enter CONFLICT-DONE state. A secondary server should never enter CONFLICT-DONE state.
9.10.2. Operation in CONFLICT-DONE state 9.12.2. Operation in CONFLICT-DONE state
A primary server in CONFLICT-DONE state is fully responsive to all A primary server in CONFLICT-DONE state is fully responsive to all
DHCP clients (similar to the situation in COMMUNICATIONS-INTERRUPTED DHCP clients (similar to the situation in COMMUNICATIONS-INTERRUPTED
state). state).
If communications fails, remain in CONFLICT-DONE state. If communi- If communications fails, remain in CONFLICT-DONE state. If communi-
cations becomes OK, remain in CONFLICT-DONE state until the condi- cations becomes OK, remain in CONFLICT-DONE state until the condi-
tions for transition out become satistifed. tions for transition out become satisfied.
9.10.3. Transitions out of CONFLICT-DONE state 9.12.3. Transitions out of CONFLICT-DONE state
If communications fails with the partner while in CONFLICT-DONE If communications fails with the partner while in CONFLICT-DONE
state, then the server will remain in CONFLICT-DONE state. state, then the server will remain in CONFLICT-DONE state.
When a primary server determines that the secondary server has tran- When a primary server determines that the secondary server has made a
sitioned into NORMAL state, the primary server will also transition transition into NORMAL state, the primary server will also transition
into NORMAL state. into NORMAL state.
9.11. RECOVER-DONE state 9.13. PAUSED state
This state exists to allow an interlocked transition for one server
from RECOVER state and another server from PARTNER-DOWN or
COMMUNICATIONS-INTERRUPTED state into NORMAL state.
9.11.1. Operation in RECOVER-DONE state
A server in RECOVER-DONE state MUST respond only to
DHCPREQUEST/RENEWAL and DHCPREQUEST/REBINDING DHCP messages.
9.11.2. Transitions out of RECOVER-DONE state
When a server in RECOVER-DONE state determines that its partner
server has entered NORMAL state, then it will transition into NORMAL
state as well.
If communications fails while in RECOVER-DONE state, a server will
stay in RECOVER-DONE state.
9.12. PAUSED state
This state exists to allow one server to inform another that it will This state exists to allow one server to inform another that it will
be out of service for what is predicted to be a relatively short be out of service for what is predicted to be a relatively short
time, and to allow the other server to transition to COMMUNICATIONS- time, and to allow the other server to transition to COMMUNICATIONS-
INTERRUPTED state immediately and to begin servicing all DHCP clients INTERRUPTED state immediately and to begin servicing all DHCP clients
with no interruption in service to new DHCP clients. with no interruption in service to new DHCP clients.
A server which is aware that it is shutting down temporarily SHOULD A server which is aware that it is shutting down temporarily SHOULD
send a STATE message with the server-state option containing PAUSED send a STATE message with the server-state option containing PAUSED
state and close the TCP connection. state and close the TCP connection.
While a server may or may not transition internally into PAUSED While a server may or may not transition internally into PAUSED
state, the 'previous' state determined when it is restarted MUST be state, the 'previous' state determined when it is restarted MUST be
the state the server was in prior to receiving the command to shut- the state the server was in prior to receiving the command to shut-
down and restart and which precedes its entry into the PAUSED state. down and restart and which precedes its entry into the PAUSED state.
See section 9.3.2 concerning the use of the previous state upon See section 9.3.2 concerning the use of the previous state upon
server restart. server restart.
9.12.1. Upon entry to PAUSED state 9.13.1. Upon entry to PAUSED state
When entering PAUSED state, the server MUST store the previous state When entering PAUSED state, the server MUST store the previous state
in stable storage, and use that state as the previous state when it in stable storage, and use that state as the previous state when it
is restarted. is restarted.
9.12.2. Transitions out of PAUSED state 9.13.2. Transitions out of PAUSED state
A server transitions out of PAUSED state by being restarted. At that A server makes a transition out of PAUSED state by being restarted.
time, the previous state MUST be the state the server was in prior to At that time, the previous state MUST be the state the server was in
entering the PAUSED state. prior to entering the PAUSED state.
9.13. SHUTDOWN state 9.14. SHUTDOWN state
This state exists to allow one server to inform another that it will This state exists to allow one server to inform another that it will
be out of service for what is predicted to be a relatively long time, be out of service for what is predicted to be a relatively long time,
and to allow the other server to transition immediately to PARTNER- and to allow the other server to transition immediately to PARTNER-
DOWN state, and take over completely for the server going down. DOWN state, and take over completely for the server going down.
A server which is aware that it is shutting down SHOULD send a STATE 9.14.1. Upon entry to SHUTDOWN state
message with the server-state field containing SHUTDOWN.
While a server may or may not transition internally into SHUTDOWN
state, the 'previous' state determined when it is restarted MUST be
the state active prior to the command to shutdown. See section 9.3.2
concerning the use of the previous state upon server restart.
9.13.1. Upon entry to SHUTDOWN state
When entering SHUTDOWN state, the server MUST record the previous When entering SHUTDOWN state, the server MUST record the previous
state in stable storage for use when the server is restarted. It state in stable storage for use when the server is restarted. It
also MUST record the current time as the last time operational. also MUST record the current time as the last time operational.
A server which is aware that it is shutting down SHOULD send a STATE A server which is aware that it is shutting down SHOULD send a STATE
message with the server-state field containing SHUTDOWN. message with the server-state field containing SHUTDOWN.
9.13.2. Operation in SHUTDOWN state 9.14.2. Operation in SHUTDOWN state
A server in SHUTDOWN state MUST NOT respond to any DHCP client input. A server in SHUTDOWN state MUST NOT respond to any DHCP client input.
If a server receives any message indicating that the partner has If a server receives any message indicating that the partner has
moved to PARTNER-DOWN state while it is in SHUTDOWN state then it moved to PARTNER-DOWN state while it is in SHUTDOWN state then it
MUST record RECOVER state as the previous state to be used when it is MUST record RECOVER state as the previous state to be used when it is
restarted. restarted.
A server SHOULD wait for a few seconds after informing the partner of A server SHOULD wait for a few seconds after informing the partner of
entry into SHUTDOWN state (if communications are okay) to determine entry into SHUTDOWN state (if communications are okay) to determine
if the partner entered PARTNER-DOWN state. if the partner entered PARTNER-DOWN state.
9.13.3. Transitions out of SHUTDOWN state 9.14.3. Transitions out of SHUTDOWN state
A server transitions out of SHUTDOWN state by being restarted. A server makes a transition out of SHUTDOWN state by being restarted.
10. Safe Period 10. Safe Period
Due to the restrictions imposed on each server while in Due to the restrictions imposed on each server while in
COMMUNICATIONS-INTERRUPTED state, long-term operation in this state COMMUNICATIONS-INTERRUPTED state, long-term operation in this state
is not feasible for either server. One reason that these states is not feasible for either server. One reason that these states
exist at all, is to allow the servers to easily survive transient exist at all, is to allow the servers to easily survive transient
network communications failures of a few minutes to a few days network communications failures of a few minutes to a few days
(although the actual time periods will depend a great deal on the (although the actual time periods will depend a great deal on the
DHCP activity of the network in terms of arrival and departure of DHCP activity of the network in terms of arrival and departure of
skipping to change at page 104, line 50 skipping to change at page 110, line 33
are two ways that they can move into this state (known as PARTNER- are two ways that they can move into this state (known as PARTNER-
DOWN). DOWN).
They can either be informed by external command that, indeed, the They can either be informed by external command that, indeed, the
partner server is down. In this case, there is no difficulty in mov- partner server is down. In this case, there is no difficulty in mov-
ing into the PARTNER-DOWN state since it is an accurate reflection of ing into the PARTNER-DOWN state since it is an accurate reflection of
reality and the protocol has been designed to operate correctly (even reality and the protocol has been designed to operate correctly (even
during reintegration) as long as, when in PARTNER-DOWN state the during reintegration) as long as, when in PARTNER-DOWN state the
partner is, indeed, down. partner is, indeed, down.
The more difficult scenario is when the servers are running The more difficult scenario is when the servers are running unat-
unattended for extended periods, and in this case an option is pro- tended for extended periods, and in this case an option is provided
vided to configure something called a "safe-period" into each server. to configure something called a "safe-period" into each server. This
This OPTIONAL safe-period is the period after which either the pri- OPTIONAL safe-period is the period after which either the primary or
mary or secondary server will automatically transition to PARTNER- secondary server will automatically transition to PARTNER-DOWN from
DOWN from COMMUNICATIONS-INTERRUPTED state. If this transition is COMMUNICATIONS-INTERRUPTED state. If this transition is completed
completed and the partner is not down, then the possibility of dupli- and the partner is not down, then the possibility of duplicate IP
cate IP address allocations will exist. address allocations will exist.
The goal of the "safe-period" is to allow network operations staff The goal of the "safe-period" is to allow network operations staff
some time to react to a server moving into COMMUNICATIONS-INTERRUPTED some time to react to a server moving into COMMUNICATIONS-INTERRUPTED
state. During the safe-period the only requirement is that the net- state. During the safe-period the only requirement is that the net-
work operations staff determine if both servers are still running -- work operations staff determine if both servers are still running --
and if they are, to either fix the network communications failure and if they are, to either fix the network communications failure
between them, or to take one of the servers down before the expira- between them, or to take one of the servers down before the expira-
tion of the safe-period. tion of the safe-period.
The length of the safe-period is installation dependent, and depends The length of the safe-period is installation dependent, and depends
in large part on the number of unallocated IP addresses within the in large part on the number of unallocated IP addresses within the
subnet address pool and the expected frequency of arrival of previ- subnet address pool and the expected frequency of arrival of
ously unknown DHCP clients requiring IP addresses. Many environments previously unknown DHCP clients requiring IP addresses. Many
should be able to support safe-periods of several days. environments should be able to support safe-periods of several days.
During this safe period, either server will allow renewals from any During this safe period, either server will allow renewals from any
existing client. The only limitation concerns the need for IP existing client. The only limitation concerns the need for IP
addresses for the DHCP server to hand out to new DHCP clients and the addresses for the DHCP server to hand out to new DHCP clients and the
need to re-allocate IP addresses to different DHCP clients. need to re-allocate IP addresses to different DHCP clients.
The number of "extra" IP addresses required is equal to the expected The number of "extra" IP addresses required is equal to the expected
total number of new DHCP clients encountered during the safe period. total number of new DHCP clients encountered during the safe period.
This is dependent only on the arrival rate of new DHCP clients, not This is dependent only on the arrival rate of new DHCP clients, not
the total number of outstanding leases on IP addresses. the total number of outstanding leases on IP addresses.
skipping to change at page 106, line 19 skipping to change at page 111, line 48
Therefore, the Failover protocol MUST be capable of being secured by Therefore, the Failover protocol MUST be capable of being secured by
using a simple shared secret message digest which covers each mes- using a simple shared secret message digest which covers each mes-
sage. This provides authentication of the servers, but does not pro- sage. This provides authentication of the servers, but does not pro-
vide encryption of the data exchange. vide encryption of the data exchange.
The Failover protocol MAY also be secured by using TLS [RFC 2246] The Failover protocol MAY also be secured by using TLS [RFC 2246]
(Transport Layer Security) if encryption of the data exchange is (Transport Layer Security) if encryption of the data exchange is
desired. The use of the shared secret or TLS will not protect desired. The use of the shared secret or TLS will not protect
against TCP or IP layer attacks (such as someone sending fake TCP RST against TCP or IP layer attacks (such as someone sending fake TCP RST
segments). IPsec SHOULD be used to protect against most (if not all) segments). IPsec [RFC 2401] SHOULD be used to protect against most
of these kinds of attacks. (if not all) of these kinds of attacks.
11.1. Simple shared secret 11.1. Simple shared secret
Messages between the failover partners are authenticated through the Messages between the failover partners can be authenticated through
use of a shared secret, which is never sent over the network and must the use of a shared secret, which is never sent over the network and
be known by each server. How each server is told about this shared must be known by each server. How each server is told about this
secret and secures its storage of the shared secret is outside the shared secret and secures its storage of the shared secret is outside
scope of this document. If a server is configured with a shared the scope of this document. If a server is configured with a shared
secret for a partner, it MUST send the message-digest option in ALL secret for a partner, it MUST send the message-digest option in ALL
messages to that partner and it MUST treat any messages received from messages to that partner and it MUST treat any messages received from
that partner without a message-digest option as failing authentica- that partner without a message-digest option as failing authentica-
tion and reject them with reject reason 21: "Missing message digest". tion and reject them with reject reason 21: "Missing message digest".
Note that the message digest option MUST be the first option in the
message.
If a server is not configured with a shared secret for a partner, it If a server is not configured with a shared secret for a partner, it
MUST NOT send the message-digest option in any message to that MUST NOT send the message-digest option in any message to that
partner and it MUST treat any messages received from that partner partner and it MUST treat any messages received from that partner
with a message-digest option as failing authentication with reject with a message-digest option as failing authentication with reject
reason 13: "Message digest not configured". reason 13: "Message digest not configured".
The shared secret is used to calculate a 16 octet message-digest The shared secret is used to calculate a 16 octet message-digest
which is sent in every failover message as the message-digest option. which is sent in every failover message in the message-digest option.
See section 12.17. The message-digest contains a one-way 16 octet MD5 See section 12.16. The message-digest contains a one-way 16 octet
[RFC 1321] hash calculated over a stream of octets consisting of the HMAC-MD5 [RFC 2104] hash calculated over a stream of octets consist-
entire message concatenated with the shared secret. ing of the entire message concatenated with the shared secret.
For calculation, the message includes the message-digest option with For calculation, the message includes the message-digest option with
the message-digest data zeroed (16-octets of zero). Once the calcula- the message-digest data zeroed (16-octets of zero). Once the calcula-
tion is complete, these 16 octets of zero are replaced by the 16- tion is complete, these 16 octets of zero are replaced by the 16-
octet MD5 hash and the message is sent. octet HMAC-MD5 hash and the message is sent.
For verification, the 16-octet message-digest is saved and replaced For verification, the 16-octet message-digest is saved and replaced
with 16-octets of zero and calculated per above. The resulting MD5 with 16-octets of zero and calculated per above. The resulting HMAC-
hash is compared to the received hash and if they match, the message MD5 hash is compared to the received hash and if they match, the mes-
is assumed authenticated. sage is assumed authenticated.
A failover partner that fails to authenticate a received message or A failover partner that fails to authenticate a received message or
receives a message without a message-digest option when configured receives a message without a message-digest option when configured
with a shared secret MUST close the connection immediately and take with a shared secret MUST close the connection immediately and take
steps to notify operators. steps to notify operators.
This use of the shared secret is very similar to that used for RADIUS Every time a CONNECT message is received, the time at which that mes-
Accounting [RFC 2139]. sage was sent by the partner (i.e., the time that actually appears in
the message itself) MUST be saved. If a CONNECT message is ever
received containing that time or containing a time before that time,
it MUST be rejected.
The XID (see section 6.1) of every message received at a failover
endpoint MUST be greater than that of the previous message received
on that failover endpoint or the message just received MUST be
rejected.
A server MAY operate with arbitrary time skew between servers (see
section 5.10), but when using a shared secret administrators MAY wish
to configure a maximum allowable time skew between a failover server
and its partner(s). Servers SHOULD allow an administrator to config-
ure a maximum allowable time skew between two failover partners.
11.2. TLS 11.2. TLS
TLS, Transport Layer Security, as specified in [RFC 2246] MAY be TLS, Transport Layer Security, as specified in [RFC 2246] MAY be
used. The use of TLS would be similar to the way it is used with used. The use of TLS would be similar to the way it is used with
SMTP [RFC 2487] and IMAP/POP3/ACAP [RFC 2595]. SMTP [RFC 2487] and IMAP/POP3/ACAP [RFC 2595].
To request the use of TLS, the server that successfully opened a con- To request the use of TLS, the primary MUST send the TLS-request
nection to its peer MUST send the TLS option as part of the CONNECT option as part of the CONNECT message. The secondary receiving the
message. The server receiving the TLS option MUST respond with a TLS-request option MUST respond with a TLS-reply option indicating
TLS-reply option indicating its acceptance or rejection of the TLS- its acceptance or rejection of the TLS-request in the CONNECT mes-
request in the CONNECT message. sage."
If the CONNECTACK message contained a TLS-reply of 1 , then both If the CONNECTACK message contained a TLS-reply of 1 , then both
servers begin TLS negotiation. servers immediately begin TLS negotiation.
Upon completion of this negotiation, the server which originally sent Upon completion of this negotiation, the primary server sends another
the CONNECT message MUST resend its CONNECT message without any TLS- CONNECT message without any TLS-request option, and must wait for a
request, and must wait for a corresponding CONNECTACK. corresponding CONNECTACK.
Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [RFC 2246] Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [RFC 2246]
cipher suite is REQUIRED in Failover servers supporting TLS. This is cipher suite is REQUIRED in Failover servers supporting TLS. This is
important as it assures that any two compliant implementations can be important as it assures that any two compliant implementations can be
configured to interoperate. configured to interoperate.
12. Failover Options 12. Failover Options
This section lists all of the options that are currently defined to This section lists all of the options that are currently defined to
be used with the failover protocol. See section 6.2 for details con- be used with the failover protocol. See section 6.2 for details con-
skipping to change at page 108, line 39 skipping to change at page 114, line 39
Code Len Type Code Len Type
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
| 0 | 3 | 0 | 1 | 1-7 | | 0 | 3 | 0 | 1 | 1-7 |
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
Legal values for this option are: Legal values for this option are:
Value Binding Status Value Binding Status
----- ------------------------------------------------ ----- ------------------------------------------------
1 FREE Lease is currently available 1 FREE Lease is currently available to the primary
2 ACTIVE Lease is assigned to a client 2 ACTIVE Lease is assigned to a client
3 EXPIRED Lease has expired 3 EXPIRED Lease has expired
4 RELEASED Lease has been released by client 4 RELEASED Lease has been released by client
5 ABANDONED A server, or client flagged address as unusable 5 ABANDONED A server, or client flagged address as unusable
6 RESET Lease was freed by some external agent 6 RESET Lease was freed by some external agent
7 BACKUP Lease belongs to secondary's private address pool 7 BACKUP Lease belongs to secondary's private address pool
12.4. client-identifier 12.4. client-identifier
This is the client-identifier for the client associated with a This is the client-identifier for the client associated with a
skipping to change at page 111, line 32 skipping to change at page 117, line 32
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|A|D|P| MBZ | |C|A|D|P| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bits (numbered from the least-significant bit in network The bits (numbered from the least-significant bit in network
byte-order) are used as follows: byte-order) are used as follows:
0 (C): A RR update successfully completed 0 (C): name to address (such as A RR) update successfully completed
1 (A): Server is controlling A RR on behalf of the client 1 (A): Server is controlling A RR on behalf of the client
2 (D): PTR RR update successfully completed (Done) 2 (D): address to name (such as PTR RR) update successfully completed (Done)
3 (P): Server is controlling PTR RR on behalf of the client 3 (P): Server is controlling PTR RR on behalf of the client
4-15 : Must be zero 4-15 : Must be zero
All of the unspecified bit positions SHOULD be set to 0 by servers All of the unspecified bit positions SHOULD be set to 0 by servers
sending the Failover-DDNS option, and they MUST be ignored by servers sending the Failover-DDNS option, and they MUST be ignored by servers
receiving the option. receiving the option.
12.10. delayed-service-parameter 12.10. delayed-service-parameter
The delayed-service-parameter is an optional load balancing tuning The delayed-service-parameter is an optional load balancing tuning
parameter, defined in [LOADB]. If it is used, it MUST be sent in the parameter, defined in [RFC 3074]. If it is used, it MUST be sent in
same message as the hash-bucket-assignment option (see section the same message as the hash-bucket-assignment option (see section
12.11). Format : 12.11).
Format :
Code Len Seconds Code Len Seconds
+-----+-----+-----+-----+----+ +-----+-----+-----+-----+----+
| 0 | 10 | 0 | 1 | S | | 0 | 10 | 0 | 1 | S |
+-----+-----+-----+-----+----+ +-----+-----+-----+-----+----+
S is a one byte value, 1..255. S is a one byte value, 1..255.
12.11. hash-bucket-assignment 12.11. hash-bucket-assignment
A set of load balancing hash values for the secondary server. A one A set of load balancing hash values for the secondary server. A one
bit in the hash buckets indicates that the secondary is to service bit in the hash buckets indicates that the secondary is to service
that set of clients. See section 5.3 for more information on how that set of clients. See section 5.3 for more information on how
this option is used. This option is only sent from the primary to this option is used. This option is only sent from the primary to
the secondary. the secondary.
The format and usage of the data in this option is defined in The format and usage of the data in this option is defined in [RFC
[LOADB]. 3074].
Code Len Hash Buckets Code Len Hash Buckets
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | 11 | 0 | 32 | b1 | b2 | ... | b32 | | 0 | 11 | 0 | 32 | b1 | b2 | ... | b32 |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
12.12. IP-flags 12.12. IP-flags
This option is used to convey the current flags of the assigned-IP- This option is used to convey the current flags of the assigned-IP-
address option preceding it. address option preceding it.
skipping to change at page 113, line 27 skipping to change at page 119, line 27
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|B| MBZ | |R|B| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bits (numbered from the least-significant bit in network The bits (numbered from the least-significant bit in network
byte-order) are used as follows: byte-order) are used as follows:
0 (R): RESERVED 0 (R): RESERVED (this bit allocated and in use and named "RESERVED")
Bit 0 MUST be set to 1 whenever the IP address in the preceding Bit 0 MUST be set to 1 whenever the IP address in the preceding
assigned-IP-address option is reserved on the server sending the assigned-IP-address option is reserved on the server sending the
packet. packet.
1 (B): BOOTP 1 (B): BOOTP
Bit 1 MUST be set to 1 whenever the IP address in the preceding Bit 1 MUST be set to 1 whenever the IP address in the preceding
assigned-IP-address option is a an IP address which has been assigned-IP-address option is a an IP address which has been
allocated due to an interaction with a BOOTP client (as opposed allocated due to an interaction with a BOOTP client (as opposed
to a DHCP client). to a DHCP client).
2-15 : Must be zero 2-15 : Must be zero
skipping to change at page 115, line 23 skipping to change at page 121, line 23
| 0 | 16 | 0 | n | c1 | c2 | ... | 0 | 16 | 0 | n | c1 | c2 | ...
+-----+-----+-----+-----+------+-----+-- +-----+-----+-----+-----+------+-----+--
12.17. message-digest 12.17. message-digest
The message digest for this message. The message digest for this message.
This option consists of a variable number of bytes which contain the This option consists of a variable number of bytes which contain the
message digest of the message prior to the inclusion of this option. message digest of the message prior to the inclusion of this option.
When this option appears in a message, it MUST appear as the last When this option appears in a message, it MUST appear as the first
option in the message. It MUST appear in every message if message option in the message. It MUST appear in every message if message
digests are required. digests are required. The Type MUST be configurable (once additional
types are defined). When additional types are defined, they MUST be
specified as either optional (MAY be supported) or required (MUST be
supported). See the section on IANA considerations for more details.
Code Len Message Digest Code Len Type Message Digest
+-----+-----+-----+-----+----+-----+----- +-----+-----+-----+-----+-----+-----+-----+--
| 0 | 17 | 0 | n | d1 | d2 | ... | 0 | 17 | 0 | n | t | d1 | d2 | ...
+-----+-----+-----+-----+----+-----+----- +-----+-----+-----+-----+-----+-----+-----+--
Type: 0 Not Allowed
1 HMAC-MD5
2-255 Not Allowed
12.18. potential-expiration-time 12.18. potential-expiration-time
The potential expiration time is the time that one server tells The potential expiration time is the time that one server tells
another server that it may wish to grant in a lease to a DHCP client. another server that it may wish to grant in a lease to a DHCP client.
It is an absolute time. See section 6.2. It is an absolute time. See section 6.2.
Code Len Time Code Len Time
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
| 0 | 18 | 0 | 4 | t1 | t2 | t3 | t4 | | 0 | 18 | 0 | 4 | t1 | t2 | t3 | t4 |
skipping to change at page 118, line 5 skipping to change at page 124, line 5
16 Less critical binding information. (7.1.3) 16 Less critical binding information. (7.1.3)
17 No traffic within sufficient time. (8.6) 17 No traffic within sufficient time. (8.6)
18 Hash bucket assignment conflict. (7.8.2) 18 Hash bucket assignment conflict. (7.8.2)
19 IP not reserved on this server. (7.1.3) 19 IP not reserved on this server. (7.1.3)
20 Message digest failed to compare. (7.8.2) 20 Message digest failed to compare. (7.8.2)
21 Missing message digest. (7.1.3) 21 Missing message digest. (7.1.3)
22-253, reserved. 22-253, reserved.
254 Unknown: Error occurred but does not match any reason code. 254 Unknown: Error occurred but does not match any reason code.
255 Reserved for code expansion. 255 Reserved for code expansion.
12.22. sending-server-IP-address 12.22. relationship-name
The IP address of the server sending this message. This option is A string which is a unique identifier for the failover relationship.
required for all messages if the message digest option used.
Code Len Address Code Len Relationship Name
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+---
| 0 | 22 | 0 | 4 | a1 | a2 | a3 | a4 | | 0 | 22 | 0 | n | c1 | c2 | ...
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+---
12.23. server-flags 12.23. server-flags
This option is used to convey the current flags of the failover This option is used to convey the current flags of the failover
endpoint in the sending server. endpoint in the sending server.
Code Len Server Flags Code Len Server Flags
+-----+-----+-----+-----+-------+ +-----+-----+-----+-----+-------+
| 0 | 23 | 0 | 1 | flags | | 0 | 23 | 0 | 1 | flags |
+-----+-----+-----+-----+-------+ +-----+-----+-----+-----+-------+
skipping to change at page 120, line 23 skipping to change at page 126, line 23
Code Len TLS Code Len TLS
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
| 0 | 26 | 0 | 1 | t1 | | 0 | 26 | 0 | 1 | t1 |
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
12.27. TLS-request 12.27. TLS-request
This option contains information relating to TLS security This option contains information relating to TLS security
negotiation. It is sent in a CONNECT message. negotiation. It is sent in a CONNECT message.
The t1 byte is the TLS request from this server. A value of 0 The t1 byte is the TLS request from the primary server. A value of 0
indicates no TLS operation (to communicate the other server MUST NOT indicates no TLS operation (to communicate the secondary server MUST
require TLS), a value of 1 indicates that TLS operation is desired NOT require TLS), a value of 1 indicates that TLS operation is
but not required (to communicate, the other server MAY utilize TLS), desired but not required (to communicate, the secondary server MAY
and a value of 2 indicates that TLS operation is required (to utilize TLS), and a value of 2 indicates that TLS operation is
communicate the other server MUST utilize TLS) to establish required (to communicate the secondary server MUST utilize TLS) to
communications with this server. establish communications with the primary server.
Code Len TLS Code Len TLS
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
| 0 | 27 | 0 | 1 | t1 | | 0 | 27 | 0 | 1 | t1 |
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
12.28. vendor-class-identifier 12.28. vendor-class-identifier
A string which identifies the vendor of the failover protocol A string which identifies the vendor of the failover protocol
implementation. implementation.
skipping to change at page 121, line 10 skipping to change at page 127, line 10
Code Len vendor class string Code Len vendor class string
+-----+-----+-----+-----+----+-----+--- +-----+-----+-----+-----+----+-----+---
| 0 | 28 | 0 | n | c1 | c2 | ... | 0 | 28 | 0 | n | c1 | c2 | ...
+-----+-----+-----+-----+----+-----+--- +-----+-----+-----+-----+----+-----+---
12.29. vendor-specific-options 12.29. vendor-specific-options
This option is used to convey options specific to a particular This option is used to convey options specific to a particular
vendor's implementation. The vendor class identifier is used to vendor's implementation. The vendor class identifier is used to
specify which option space the embedded options are drawn from. specify which option space the embedded options are drawn from.
Every message that uses vendor specific options MUST have a vendor-
class-identifier option in it.
It functions similarly to the vendor class identifier and vendor It functions similarly to the vendor class identifier and vendor
specific options in the DHCP protocol. specific options in the DHCP protocol.
This option contains other options in the same two byte code, two This option contains other options in the same two byte code, two
byte length format. If this option appears in a message without a byte length format. If this option appears in a message without a
corresponding vendor class identifier, it MUST be ignored. corresponding vendor class identifier, it MUST be ignored.
Code Len Embedded options Code Len Embedded options
+-----+-----+-----+-----+----+-----+--- +-----+-----+-----+-----+----+-----+---
| 0 | 29 | 0 | n | c1 | c2 | ... | 0 | 29 | 0 | n | c1 | c2 | ...
+-----+-----+-----+-----+----+-----+--- +-----+-----+-----+-----+----+-----+---
13. IANA Considerations 13. IANA Considerations
This document defines several number spaces (failover options, fail- This document defines several number spaces (failover options, fail-
over message types, and failover reject reason codes). For all of over message types, message digest types, and failover reject reason
these number spaces, certain values are defined in this specifica- codes). For all of these number spaces, certain values are defined in
tion. New values may only be defined by IETF Consensus, as described this specification. New values may only be defined by IETF Con-
in [RFC 2434]. Basically, this means that they are defined by RFCs sensus, as described in [RFC 2434]. Basically, this means that they
approved by the IESG. are defined by RFCs approved by the IESG.
14. Acknowledgments 14. Acknowledgments
Ralph Droms started it all, by sketching out an initial interserver Ralph Droms started it all, by sketching out an initial interserver
draft that embodied ideas from several past IETF meetings. In that draft that embodied ideas from several past IETF meetings. In that
draft, he acknowledged contributions by Jeff Mogul, Greg Minshall, draft, he acknowledged contributions by Jeff Mogul, Greg Minshall,
Rob Stevens, Walt Wimer, Ted Lemon, and the DHC working group. Rob Stevens, Walt Wimer, Ted Lemon, and the DHC working group.
Kim Kinnear and Bob Cole each extended that draft, separately and Kim Kinnear and Bob Cole each extended that draft, separately and
then together, until they created an interserver draft that supported then together, until they created an interserver draft that supported
any number of servers. The complexity of that approach was just too any number of servers. The complexity of that approach was just too
great, and that draft wasn't greeted with enthusiasm by many, includ- great, and that draft wasn't greeted with enthusiasm by many, includ-
ing its authors. ing its authors.
It did however lead to a much simpler approach embodied in the first It did however lead to a much simpler approach embodied in the first
Failover draft by Greg Rabil, Mike Dooley, Arun Kapur and Ralph Failover draft by Greg Rabil, Mike Dooley, Arun Kapur and Ralph
Droms. This draft posited only two servers -- a primary and a Droms. This draft posited only two servers -- a primary and a secon-
secondary. dary.
Kim Kinnear then wrote the Safe Failover draft to layer on top of the Kim Kinnear then wrote the Safe Failover draft to layer on top of the
Failover Draft and increase its robustness in the face of certain Failover Draft and increase its robustness in the face of certain
rare network failures. rare network failures.
At the spring 1998 IETF meeting in LA, the DHC working group said At the spring 1998 IETF meeting in LA, the DHC working group said
that they wanted a merged Failover and Safe Failover draft. Steve that they wanted a merged Failover and Safe Failover draft. Steve
Gonczi and Bernie Volz stepped up and produced the raw material for Gonczi and Bernie Volz stepped up and produced the raw material for
such a merged draft, along with a new message format designed around such a merged draft, along with a new message format designed around
DHCP options and other extensions and clarifications. Kim Kinnear DHCP options and other extensions and clarifications. Kim Kinnear
skipping to change at page 123, line 16 skipping to change at page 129, line 18
Another conference call was held in mid-January of 2000, and the -06 Another conference call was held in mid-January of 2000, and the -06
draft was produced to tighten up the the -05 draft both technically draft was produced to tighten up the the -05 draft both technically
as well as editorially. as well as editorially.
The -07 draft was edited by Kim Kinnear and was based in part on The -07 draft was edited by Kim Kinnear and was based in part on
reviews by Richard Jones, Bernie Volz, and Steve Gonczi. It embodies reviews by Richard Jones, Bernie Volz, and Steve Gonczi. It embodies
several technical updates as well as numerous editorial revisions several technical updates as well as numerous editorial revisions
that enhanced both correctness as well as clarity. that enhanced both correctness as well as clarity.
This, the -08 draft was edited by Kim Kinnear and was based on the The -08 draft was edited by Kim Kinnear and was based on the results
results of two conference calls held in October and November of 2000. of two conference calls held in October and November of 2000. It
It includes the correct second port number, a new state to synchron- includes the correct second port number, a new state to synchronize
ize conflict resolution with load balancing, a generally accepted conflict resolution with load balancing, a generally accepted
approach to secondary pool allocation, and many other updates based approach to secondary pool allocation, and many other updates based
on both operational as well as implementation experience. on both operational as well as implementation experience.
This, the -09 draft was edited by Kim Kinnear based on discussions
held at the Minneapolis IETF in December of 2000, as well as issues
raised by Ted Lemon based on implementation and deployment. The
specific changes were mailed to the dhcp-v4 list.
These most recent changes have not been widely circulated among the These most recent changes have not been widely circulated among the
other authors prior to submission to the IETF. other authors prior to submission to the IETF.
Glenn Waters of Nortel Networks contributed ideas and enthusiasm to Glenn Waters of Nortel Networks contributed ideas and enthusiasm to
make a Failover protocol that was both "safe" and "lazy". make a Failover protocol that was both "safe" and "lazy".
15. References 15. References
[AGENTINFO] Patrick, M., "draft-ietf-dhc-agent-options-11.txt", July, [DHCID] Stapp, M., Lemon, T., Gustafsson, A., "draft-ietf-dnsext-
2000. dhcid-rr-02.txt", March, 2001.
[DDNS] Rekhter, Y., Stapp, M., "draft-ietf-dhc-dhcp-dns-12.txt", [DNSRES] Stapp, M., "draft-ietf-dhc-dns-resolution-01.txt", March,
March, 2000. 2001.
[LOADB] Volz, B., Gonczi, S., Lemon, T., Stevens, R., "draft-ietf- [FQDN] Rekhter, Y., Stapp, M., "draft-ietf-dhc-fqdn-option-01.txt",
dhc-loadb-02.txt", July, 1999. March, 2001.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specification", November, 1987. Specification", November, 1987.
[RFC 1321] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algo-
rithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data
Security Inc., April 1992.
[RFC 1534] Droms, R., "Interoperation between DHCP and BOOTP", RFC [RFC 1534] Droms, R., "Interoperation between DHCP and BOOTP", RFC
1534, October 1993. 1534, October 1993.
[RFC 2104] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC: Keyed
Hashing for Message Authentication", RFC 2104, IBM T.J. Watson
Research Center, University of California at San Diego, February
1997.
[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. Requirement Levels", RFC 2119.
[RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor [RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
Extensions", Internet RFC 2132, March 1997. Extensions", Internet RFC 2132, March 1997.
[RFC 2136] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic [RFC 2136] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
1997 1997
[RFC 2139] Rigney, C., "Radius Accounting", RFC 2139, Livingston [RFC 2139] Rigney, C., "Radius Accounting", RFC 2139, Livingston
Enterprises, April 1997. Enterprises, April 1997.
[RFC 2246] Dierks, T., "The TLS Protocol, Version 1.0", RFC 2246, [RFC 2246] Dierks, T., "The TLS Protocol, Version 1.0", RFC 2246,
January 1999. January 1999.
[RFC 2401] Kent, S., Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC 2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an [RFC 2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October IANA Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
[RFC 2487] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC 2487] Hoffman, P., "SMTP Service Extension for Secure SMTP over
TLS", RFC 2487, January 1999. TLS", RFC 2487, January 1999.
[RFC 2595] Newman, C., "Using TLS with IMAP, POP3, and ACAP", RFC [RFC 2595] Newman, C., "Using TLS with IMAP, POP3, and ACAP", RFC
2595, June 1999. 2595, June 1999.
[USERCLASS] Droms, R., Demirtjis A., Stump, G., Gu, Y., Vyaghrapuri, [RFC 3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis,
R., Beser, B., Privat, J. "draft-ietf-dhc-userclass-08.txt", July, A., Privat, J. "The User Class Option for DHCP", November 2000.
2000.
[RFC 3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP",
November 2000.
[RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[RFC 3074] Volz, B., Gonczi, S., Lemon, T., Stevens, R., "DHC Load-
balancing Algorithm", February, 2001.
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
skipping to change at page 125, line 4 skipping to change at page 131, line 22
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) 244-8000
EMail: rdroms@cisco.com EMail: rdroms@cisco.com
kkinnear@cisco.com kkinnear@cisco.com
mjs@cisco.com mjs@cisco.com
Bernie Volz Bernie Volz
IPWorks, Inc. Ericsson
959 Concord St. 959 Concord St.
Framingham, MA 01701 Framingham, MA 01701
Phone: (508) 879-1809 Phone: +1-617-513-9060
EMail: volz@ipworks.com EMail: bernie.volz@ericsson.com
Steve Gonczi Steve Gonczi
Network Engines, Inc. Network Engines, Inc.
25 Dan Road 25 Dan Road
Canton, MA 02021-2817 Canton, MA 02021-2817
Phone: (781) 332-1165 Phone: (781) 332-1165
Email: steve.gonczi@networkengines.com Email: steve.gonczi@networkengines.com
 End of changes. 

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