draft-ietf-dhc-failover-07.txt   draft-ietf-dhc-failover-08.txt 
Network Working Group Ralph Droms Network Working Group Ralph Droms
INTERNET DRAFT Bucknell University INTERNET DRAFT Kim Kinnear
Kim Kinnear
Mark Stapp Mark Stapp
Cisco Systems Cisco Systems
Bernie Volz Bernie Volz
IPWorks IPWorks
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 2000
Expires January 2001 Expires January 2001
DHCP Failover Protocol DHCP Failover Protocol
<draft-ietf-dhc-failover-07.txt> <draft-ietf-dhc-failover-08.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 2, line 39 skipping to change at page 2, line 35
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.............. 12 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............................... 16 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............................................. 26
5.4. Operating in NORMAL state.................................. 27 5.4. IP address allocations between servers..................... 27
5.5. Operating in COMMUNICATIONS-INTERRUPTED state.............. 27 5.5. Operating in NORMAL state.................................. 29
5.6. Operating in PARTNER-DOWN state............................ 28 5.6. Operating in COMMUNICATIONS-INTERRUPTED state.............. 29
5.7. Operating in RECOVER state................................. 28 5.7. Operating in PARTNER-DOWN state............................ 30
5.8. Operating in STARTUP state................................. 28 5.8. Operating in RECOVER state................................. 30
5.9. Time synchronization between servers....................... 28 5.9. Operating in STARTUP state................................. 30
5.10. IP address binding-status................................. 29 5.10. Time synchronization between servers...................... 30
5.11. DNS dynamic update considerations......................... 33 5.11. IP address binding-status................................. 31
5.12. Reservations and failover................................. 37 5.12. DNS dynamic update considerations......................... 35
5.13. Dynamic BOOTP and failover................................ 39 5.13. Reservations and failover................................. 39
5.14. Guidelines for selecting MCLT............................. 39 5.14. Dynamic BOOTP and failover................................ 41
6. Common Message Format........................................ 40 5.15. Guidelines for selecting MCLT............................. 41
6.1. Message header format...................................... 40 5.16. What is sent in response to an UPDREQ or UPDREQALL message? 42
6.2. Common option format....................................... 43 6. Common Message Format........................................ 43
6.3. Batching multiple binding update transactions in one BNDUPD mes- 44 6.1. Message header format...................................... 43
7. Protocol Messages............................................ 46 6.2. Common option format....................................... 46
7.1. BNDUPD message [3]......................................... 46 6.3. Batching multiple binding update transactions in one BNDUPD mes- 47
7.2. BNDACK message [4]......................................... 56 7. Protocol Messages............................................ 49
7.3. UPDREQ message [9]......................................... 59 7.1. BNDUPD message [3]......................................... 49
7.4. UPDREQALL message [7]...................................... 60 7.2. BNDACK message [4]......................................... 60
7.5. UPDDONE message [8]........................................ 61 7.3. UPDREQ message [9]......................................... 63
7.6. POOLREQ message [1]........................................ 62 7.4. UPDREQALL message [7]...................................... 64
7.7. POOLRESP message [2]....................................... 63 7.5. UPDDONE message [8]........................................ 65
7.8. CONNECT message [5]........................................ 64 7.6. POOLREQ message [1]........................................ 65
7.9. CONNECTACK message [6]..................................... 68 7.7. POOLRESP message [2]....................................... 66
7.10. STATE message [10]........................................ 71 7.8. CONNECT message [5]........................................ 67
7.11. CONTACT message [11]...................................... 72 7.9. CONNECTACK message [6]..................................... 71
7.12. DISCONNECT message [12]................................... 73 7.10. STATE message [10]........................................ 75
8. Connection Management........................................ 74 7.11. CONTACT message [11]...................................... 76
8.1. Connection granularity..................................... 74 7.12. DISCONNECT message [12]................................... 76
8.2. Creating the TCP connection................................ 74 8. Connection Management........................................ 77
8.3. Using the TCP connection for determining communications status 76 8.1. Connection granularity..................................... 78
8.4. Using the TCP connection for binding data.................. 78 8.2. Creating the TCP connection................................ 78
8.5. Using the TCP connection for control messages.............. 78 8.3. Using the TCP connection for determining communications status 80
8.6. Losing the TCP connection.................................. 78 8.4. Using the TCP connection for binding data.................. 82
9. Failover Endpoint States..................................... 79 8.5. Using the TCP connection for control messages.............. 82
9.1. Server Initialization...................................... 79 8.6. Losing the TCP connection.................................. 82
9.2. Server State Transitions................................... 79 9. Failover Endpoint States..................................... 83
9.3. STARTUP state.............................................. 82 9.1. Server Initialization...................................... 83
9.4. PARTNER-DOWN state......................................... 84 9.2. Server State Transitions................................... 83
9.5. RECOVER state.............................................. 86 9.3. STARTUP state.............................................. 86
9.6. NORMAL state............................................... 89 9.4. PARTNER-DOWN state......................................... 88
9.7. COMMUNICATIONS-INTERRUPTED State........................... 91 9.5. RECOVER state.............................................. 90
9.8. POTENTIAL-CONFLICT state................................... 95 9.6. NORMAL state............................................... 93
9.9. RESOLUTION-INTERRUPTED state............................... 96 9.7. COMMUNICATIONS-INTERRUPTED State........................... 95
9.10. RECOVER-DONE state........................................ 97 9.8. POTENTIAL-CONFLICT state................................... 99
9.11. PAUSED state.............................................. 98 9.9. RESOLUTION-INTERRUPTED state............................... 100
9.12. SHUTDOWN state............................................ 98 9.10. CONFLICT-DONE state....................................... 101
10. Safe Period................................................. 99 9.12. PAUSED state.............................................. 102
11. Security.................................................... 101 9.13. SHUTDOWN state............................................ 103
11.1. Simple shared secret...................................... 101 10. Safe Period................................................. 104
11.2. TLS....................................................... 102 11. Security.................................................... 105
12. Failover Options............................................ 103 11.1. Simple shared secret...................................... 106
12.1. addresses-transferred..................................... 103 11.2. TLS....................................................... 107
12.2. assigned-IP-address....................................... 103 12. Failover Options............................................ 107
12.3. binding-status............................................ 104 12.1. addresses-transferred..................................... 108
12.4. client-identifier......................................... 104 12.2. assigned-IP-address....................................... 108
12.5. client-hardware-address................................... 105 12.3. binding-status............................................ 108
12.6. client-last-transaction-time.............................. 105 12.4. client-identifier......................................... 109
12.7. client-reply-options...................................... 105 12.5. client-hardware-address................................... 109
12.8. client-request-options.................................... 106 12.6. client-last-transaction-time.............................. 109
12.9. DDNS...................................................... 107 12.7. client-reply-options...................................... 110
12.10. delayed-service-parameter................................ 108 12.8. client-request-options.................................... 110
12.11. hash-bucket-assignment................................... 108 12.9. DDNS...................................................... 111
12.12. lease-expiration-time.................................... 108 12.10. delayed-service-parameter................................ 112
12.13. max-unacked-bndupd....................................... 109 12.11. hash-bucket-assignment................................... 112
12.14. MCLT..................................................... 109 12.12. IP-flags................................................. 113
12.15. message.................................................. 109 12.13. lease-expiration-time.................................... 114
12.16. message-digest........................................... 110 12.14. max-unacked-bndupd....................................... 114
12.17. potential-expiration-time................................ 110 12.15. MCLT..................................................... 114
12.18. receive-timer............................................ 110 12.16. message.................................................. 115
12.19. protocol-version......................................... 111 12.17. message-digest........................................... 115
12.20. reject-reason............................................ 112 12.18. potential-expiration-time................................ 115
12.21. sending-server-IP-address................................ 113 12.19. receive-timer............................................ 116
12.22. server-flags............................................. 113 12.20. protocol-version......................................... 116
12.23. server-state............................................. 114 12.21. reject-reason............................................ 117
12.24. start-time-of-state...................................... 114 12.22. sending-server-IP-address................................ 118
12.25. TLS-reply................................................ 115 12.23. server-flags............................................. 118
12.26. TLS-request.............................................. 115 12.24. server-state............................................. 119
12.27. vendor-class-identifier.................................. 115 12.25. start-time-of-state...................................... 119
12.28. vendor-specific-options.................................. 116 12.26. TLS-reply................................................ 120
13. IANA Considerations......................................... 116 12.27. TLS-request.............................................. 120
14. Acknowledgments............................................. 116 12.28. vendor-class-identifier.................................. 120
15. References.................................................. 118 12.29. vendor-specific-options.................................. 121
16. Author's information........................................ 119 13. IANA Considerations......................................... 121
17. Full Copyright Statement.................................... 120 14. Acknowledgments............................................. 121
15. References.................................................. 123
16. Author's information........................................ 124
17. Full Copyright Statement.................................... 125
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
skipping to change at page 5, line 37 skipping to change at page 5, line 37
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119]. document are to be interpreted as described in RFC 2119 [RFC 2119].
2.2. DHCP and failover terminology 2.2. DHCP and failover terminology
This document uses the following terms: This document uses the following terms:
o "available IP address"
An IP address is "available" if it may be allocated by a
specific DHCP server. An IP address is considered (for the
purposes of this document) to be available to a single server
for allocation unless otherwise noted. An IP address available
for allocation on a primary server has state FREE, and an IP
address available for allocation on a secondary server has
state BACKUP.
o "binding" o "binding"
A binding is a collection of configuration parameters, includ- A binding is a collection of configuration parameters, includ-
ing at least an IP address, associated with or "bound to" a ing at least an IP address, associated with or "bound to" a
DHCP client. Bindings are managed by DHCP servers. DHCP client. Bindings are managed by DHCP servers.
o "binding database" o "binding database"
The collection of bindings managed by a primary and secondary. The collection of bindings managed by a primary and secondary.
o "binding update transaction" o "binding update transaction"
A binding update transaction refers to the set of information A binding update transaction refers to the set of information
(contained in options) necessary to perform a binding update (contained in options) necessary to perform a binding update
for a single IP address. It will be comprised of the for a single IP address. It will be comprised of the
assigned-IP-address option and the binding-status option, along assigned-IP-address option, the binding-status option, along
other options as appropriate. with other options as appropriate.
o "binding-status" o "binding-status"
The binding-status is the status of an IP address with respect The binding-status is the status of an IP address with respect
to its association with a client. There are specific binding- to its association with a client. There are specific binding-
status values defined for use by the failover protocol, e.g., status values defined for use by the failover protocol, e.g.,
ACTIVE, FREE, RELEASED, ABANDONED, etc. These are designed to ACTIVE, FREE, RELEASED, ABANDONED, etc. These are designed to
map more or less directly onto the binding-status values used map more or less directly onto the binding-status values used
internally in most DHCP server implementations. The term internally in most DHCP server implementations. The term
binding-status refers to the concept also sometimes known as binding-status refers to the concept also sometimes known as
skipping to change at page 8, line 41 skipping to change at page 8, line 51
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 43 skipping to change at page 12, line 52
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 parti- The protocol also allows detection of an orderly shutdown of a
cipating server. participating 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 20 skipping to change at page 13, line 26
will have no record of the IP address allocation. When the secondary will have no record of the IP address allocation. When the secondary
server takes over, it may well try to allocate that IP address to a server takes over, it may well try to allocate that IP address to a
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.4 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 DHCPRENEWs are presumably more common than
DHCPDISCOVERs) and more subtle version of this problem is where the DHCPDISCOVERs) and more subtle version of this problem is where the
primary server crashes after extending a client's lease time, and 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.
skipping to change at page 13, line 52 skipping to change at page 14, line 10
municate with the primary server, and some of the clients must now municate with the primary server, and some of the clients must now
only be able to communicate with the secondary server. When this only be able to communicate with the secondary server. When this
condition occurs, both primary and secondary servers could attempt to condition occurs, both primary and secondary servers could attempt to
allocate IP addresses for new clients from the same pool of available allocate IP addresses for new clients from the same pool of available
addresses. At some point, then, two clients will end up being allo- addresses. At some point, then, two clients will end up being allo-
cated the same IP address. This will cause problems when the network cated the same IP address. This will cause problems when the network
failure that created this situation is corrected. failure that created this situation is corrected.
The failover protocol deals with this situation by having the primary The failover protocol deals with this situation by having the primary
and secondary servers allocate addresses for new clients from dis- and secondary servers allocate addresses for new clients from dis-
joint address pools. See section 5.4 for details. joint address pools. See section 5.5 for details.
3.5. Using TCP to detect partner server failure 3.5. Using TCP to detect partner server failure
There are several characteristics of TCP that are important to the There are several characteristics of TCP that are important to the
functioning of the failover protocol, which uses one TCP connection functioning of the failover protocol, which uses one TCP connection
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
skipping to change at page 14, line 44 skipping to change at page 14, line 51
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 gen- retransmission. However, the length of that timeout cannot, in
eral, be set on a per-connection basis, and is frequently as long as general, be set on a per-connection basis, and is frequently as long
nine minutes, though in some cases it may be as short as two minutes. as nine minutes, though in some cases it may be as short as two
On some systems it can be set system-wide, while on other systems it minutes. On some systems it can be set system-wide, while on other
cannot be changed at all. systems it 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 20, line 45 skipping to change at page 20, line 51
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 com- available for allocation. In the event the partner was not in
munication prior to going down, it might have allocated one or more communication prior to going down, it might have allocated one or
of its FREE addresses to a DHCP client and been unable to inform the more of its FREE addresses to a DHCP client and been unable to inform
server entering PARTNER-DOWN prior to going down itself. By waiting the server entering PARTNER-DOWN prior to going down itself. By
the MCLT after the time the partner went down, the server in waiting 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 transitioned to PARTNER-DOWN state, it
MUST NOT reallocate an IP address from one client to another client MUST NOT reallocate an IP address from one client to another client
until an additional MCLT interval after the lease by the original until an additional MCLT interval after the lease by the original
client expires. (Actually, until the maximum client lead time after client expires. (Actually, until the maximum client lead time after
what it believes to be the lease expiration time of the client.) what it believes to be the lease expiration time of the client.)
skipping to change at page 26, line 50 skipping to change at page 26, line 50
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 [LOADB].
A bitmap-style Hash Bucket Assignment (as described in [LOADB]) is A bitmap-style Hash Bucket Assignment (as described in [LOADB]) 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 is sent by 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
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.
When using the server HBA (if any) and the failover HBA (if any), to When using the server HBA (if any) and the failover HBA (if any), to
decide whether to process a DHCP request, the server HBA always decide whether to process a DHCP request, the server HBA always
applies in every failover state, and the failover HBA (which MUST be applies in every failover state, and the failover HBA (which MUST be
a subset of the server HBA) is used by the secondary server to decide a subset of the server HBA) is used by the secondary server to decide
which packets to process when in NORMAL state. which packets to process when in NORMAL state.
5.4. Operating in NORMAL state 5.4. IP address allocations between servers
The failover protocol allows a DHCP server which implements it to
operate correctly in spite of the uncertainty over whether its
partner has failed or whether the communications link to its partner
has failed. This is made possible in part by the existence of
separate address pools on each server for allocation to newly arrived
DHCP clients.
Thus, each server has its own pool of available IP addresses. Note
that an IP address is not "owned" by a particular server throughout
its entire lifetime. Only an IP address which is available is
"owned" by a particular server -- once it has been leased to a DHCP
client, it is not owned by either failover partner. When it finally
becomes available again, it will be owned initially by the primary
server, and it may or may not be allocated to the secondary server by
the primary server.
So, the flow of IP address ownership is as follows: initially an IP
address is owned by the primary server. It may be allocated to the
secondary server if it is available, and then it is owned by the
secondary server. Either server can allocate available IP addresses
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,
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
initially when it is released or the lease expires because, in gen-
eral, that server will have had to replenish its pool of available
addresses well in advance of any likely lease expirations. Thus,
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
it is to enhance the balance of available addresses between them.
These address pools are used when in COMMUNICATIONS-INTERRUPTED state
and while waiting for the MCLT expiration in PARTNER-DOWN state. In
addition, when using load balancing, these pools are used when in
NORMAL state as well.
These allocation and maintenance of these address pools is an area of
some sensitivity, since the goal is to maintain a more or less con-
stant ratio of available addresses between the two servers.
The initial allocation when the servers first integrate is triggered
by the POOLREQ message from the secondary to the primary. This is
followed by the POOLRESP message where the primary tells the secon-
dary how many IP addresses it allocated to the secondary. Then, the
primary sends the allocated IP addresses to the secondary. The
POOLREQ/POOLRESP message is a trigger to the primary to perform a
scan of its database and to ensure that the secondary has enough IP
addresses (based on some configured ratio).
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
available for allocation by the secondary.
The POOLREQ/POOLRESP message exchange initiated by the secondary is
valid at any time, and the primary server SHOULD, whenever it
receives the POOLREQ message, scan its database of address pools and
determine if the secondary needs more IP addresses from any of the IP
address pools.
However, in order to support a reasonably dynamic balance of the IP
addresses between the failover partners, the primary server needs to
do additional work to ensure that the secondary server has as many IP
addresses as it needs (but that it doesn't have *more* than it needs
either).
The primary server SHOULD examine the balance of available addresses
between the primary and secondary for a particular address pool when-
ever the number of available addresses for either the primary or
secondary changes. The primary server SHOULD adjust the available
address balance as required to ensure the configured address balance,
excepting that the primary server SHOULD employ some threshold
mechanism to such a balance adjustment in order to minimize the over-
head of maintaining this balance.
An example of a threshold approach is: do not attempt to re-balance
the available pools on the primary and secondary until the out of
balance value exceeds a configured value.
The primary server can, at any time, send an available IP address to
the secondary using a BNDUPD with the state BACKUP. The primary
server can attempt to take an available IP address away from the
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
available to the secondary. Of course, the secondary MUST reject
that BNDUPD if it has already used that IP address for a DHCP client.
Whenever the primary server examines the possible available IP
addresses which it could send to the secondary server, the primary
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
any IP addresses whose most recent client would be processed by the
secondary under the current load balancing regime in use. Likewise,
when removing available IP addresses from the secondary server when
load balancing is in use, the primary server SHOULD first remove
those IP addresses whose most recent client would be processed by the
primary server under the current load balancing regime in use.
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 [LOADB]. Each server services DHCPREQUEST/RENEWAL or
DHCPDISCOVER/REBINDING requests from any client. 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-
skipping to change at page 27, line 42 skipping to change at page 29, line 47
DISCOVER/OFFER/REQUEST/ACK cycle or extending a lease due to a DISCOVER/OFFER/REQUEST/ACK cycle or extending a lease due to a
renewal from a DHCP client) or possibly (on some servers) because a renewal from a DHCP client) or possibly (on some servers) because a
lease has expired or undergone another state change that must be lease has expired or undergone another state change that must be
recorded in the DHCP binding database. These are the state changes recorded in the DHCP binding database. These are the state changes
that would be communicated to the partner server using a BNDUPD mes- that would be communicated to the partner server using a BNDUPD mes-
sage. Of course, receipt of a BNDUPD message itself will normally sage. Of course, receipt of a BNDUPD message itself will normally
cause an update of the binding database for all of the IP addresses cause an update of the binding database for all of the IP addresses
contained in the BNDUPD, and a binding database change such as this contained in the BNDUPD, and a binding database change such as this
MUST NOT trigger a corresponding BNDUPD message to the partner. MUST NOT trigger a corresponding BNDUPD message to the partner.
5.5. 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, but in such a way that graceful reintegration is always
possible when its partner comes back into contact with it. possible when its partner comes back into contact with it.
5.6. 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.
5.7. 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.8. 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 time (generally a few seconds), the
server is unresponsive to DHCP client requests. This period exists server is unresponsive to DHCP client requests. This period exists
in order to give a server a chance to determine that its partner has in order to give a server a chance to determine that its partner has
changed state since it was last in communications, and to react to changed state since it was last in communications, and to react to
that changed state (if any) prior to responding to DHCP client that changed state (if any) prior to responding to DHCP client
requests. requests.
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.9. Time synchronization between servers 5.10. Time synchronization between servers
The failover protocol is designed to operate between two servers The failover protocol is designed to operate between two servers
which have time values which differ by an arbitrarily large amount. which have time values which differ by an arbitrarily large amount.
A particular implementation MAY choose to only support servers whose A particular implementation MAY choose to only support servers whose
time values differ by an arbitrarily small amount. time values differ by an arbitrarily small amount.
In any event, whether large or only small differences in time values In any event, whether large or only small differences in time values
are supported, every message that is received MUST be tagged with a are supported, every message that is received MUST be tagged with a
time value as soon as possible after receipt. This time value is time value as soon as possible after receipt. This time value is
used along with the time value that is sent in every message between used along with the time value that is sent in every message between
skipping to change at page 29, line 22 skipping to change at page 31, line 28
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. addresses in this document.
5.10. 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.
In order to transmit binding database updates between one server and In order to transmit binding database updates between one server and
another using the failover protocol, some common denominator another using the failover protocol, some common denominator
skipping to change at page 29, line 45 skipping to change at page 31, line 51
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 proto- The IP address binding-status values defined for the failover
col are listed below. Unless otherwise noted below, there MAY be protocol are listed below. Unless otherwise noted below, there MAY
client information associated with each of these binding-status be client information associated with each of these binding-status
values. values.
o 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 32, line 23 skipping to change at page 34, line 23
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 V | | | leasedy V | |
| | by | +----------+ +---------+ | | | by | +----------+ | |
| | primary| BACKUP | | BACKUP- | | | | primary | BACKUP |<---+ |
| wait for | | | | RESERVED| | | 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.10-1: Transitions between binding-status values.
skipping to change at page 33, line 28 skipping to change at page 35, line 28
cerning why a server might not accept a BNDUPD) it will return a cerning why a server might not accept a BNDUPD) it will return a
BNDACK with no reject-reason, signifying that it accepted the update. BNDACK with no reject-reason, signifying that it accepted the update.
As part of the BNDUPD processing, the server returning the BNDACK As part of the BNDUPD processing, the server returning the BNDACK
will set the binding-status of the IP address to FREE, and upon will set the binding-status of the IP address to FREE, and upon
receipt of the BNDACK the server which sent the BNDUPD will set the receipt of the BNDACK the server which sent the BNDUPD will set the
binding-status of the IP address to FREE. Thus, the EXPIRED, binding-status of the IP address to FREE. Thus, the EXPIRED,
RELEASED, or RESET binding-status is something of a transitory state. RELEASED, or RESET binding-status is something of a transitory state.
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.11. 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 [DDNS]. 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
skipping to change at page 34, line 16 skipping to change at page 36, line 16
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
warned the user of the problem in some way. warned the user of the problem in some way.
5.11.1. Relationship between failover and dynamic DNS update 5.12.1. Relationship between failover and dynamic DNS update
The failover protocol describes the conditions under which each fail- The failover protocol describes the conditions under which each fail-
over server may renew a lease to its current DHCP client, and over server may renew a lease to its current DHCP client, and
describes the conditions under which it may grant a lease to a new describes the conditions under which it may grant a lease to a new
DHCP client. An analogous set of conditions determines when a fail- DHCP client. An analogous set of conditions determines when a fail-
over server should initiate a DDNS update, and when it should attempt over server should initiate a DDNS update, and when it should attempt
to remove records from the DNS. The failover protocol's conditions to remove records from the DNS. The failover protocol's conditions
are based on the desired external behavior: avoiding duplicate are based on the desired external behavior: avoiding duplicate
address assignments; allowing clients to continue using leases which address assignments; allowing clients to continue using leases which
they obtained from one failover partner even if they can only commun- they obtained from one failover partner even if they can only commun-
skipping to change at page 34, line 50 skipping to change at page 36, line 50
servers to allow one to complete the DDNS update 'lifecycle' servers to allow one to complete the DDNS update 'lifecycle'
even if the other server originally granted the lease. even if the other server originally granted the lease.
3. Avoid redundant or overlapping DDNS updates, where both fail- 3. Avoid redundant or overlapping DDNS updates, where both fail-
over servers are attempting to perform DDNS updates for the over servers are attempting to perform DDNS updates for the
same lease-client binding. Avoid situations where one partner same lease-client binding. Avoid situations where one partner
is attempting to add RRs related to a lease binding while the is attempting to add RRs related to a lease binding while the
other partner is attempting to remove RRs related to the same other partner is attempting to remove RRs related to the same
lease binding. lease binding.
5.11.2. Use of the DDNS option 5.12.2. Use of the DDNS option
In order for either server to be able to complete a DDNS update, or In order for either server to be able to complete a DDNS update, or
to remove DNS records which were added by its partner, both servers to remove DNS records which were added by its partner, both servers
need to know the FQDN associated with the lease-client binding. The need to know the FQDN associated with the lease-client binding. The
FQDN associated with the client's A RR and PTR RR SHOULD be communi- FQDN associated with the client's A RR and PTR RR SHOULD be communi-
cated from the server which adds records into the DNS to its partner. cated from the server which adds records into the DNS to its partner.
The initiating server SHOULD use the DDNS option in the BNDUPD mes- The initiating server SHOULD use the DDNS option in the BNDUPD mes-
sages to inform the partner server of the status of any DDNS updates sages to inform the partner server of the status of any DDNS updates
associated with a lease binding. Failover servers MAY choose not to associated with a lease binding. Failover servers MAY choose not to
include the DDNS option in BNDUPD messages if there has been no include the DDNS option in BNDUPD messages if there has been no
skipping to change at page 36, line 24 skipping to change at page 38, line 24
ginally added for the client, and replacing them with records that ginally added for the client, and replacing them with records that
refer to the client's new FQDN. In such cases, the responsive server refer to the client's new FQDN. In such cases, the responsive server
SHOULD include the actual FQDN that was used in subsequent DDNS SHOULD include the actual FQDN that was used in subsequent DDNS
options. The responsive server SHOULD include relevant client-option options. The responsive server SHOULD include relevant client-option
data in the client-request-options option in its BNDUPD messages. data in the client-request-options option in its BNDUPD messages.
This information may be necessary in order to allow the non- This information may be necessary in order to allow the non-
responsive partner to detect client configuration changes that change responsive partner to detect client configuration changes that change
the hostname or FQDN data which the client includes in its DHCP the hostname or FQDN data which the client includes in its DHCP
requests. requests.
5.11.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 [DDNS].
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
skipping to change at page 37, line 11 skipping to change at page 39, line 11
2. If a server is in PARTNER-DOWN state, it can conclude that its 2. If a server is in PARTNER-DOWN state, it can conclude that its
partner is no longer attempting to perform an update for the partner is no longer attempting to perform an update for the
existing client. If the remaining server has not recorded that existing client. If the remaining server has not recorded that
an update for the binding has been successfully completed, the an update for the binding has been successfully completed, the
server MAY initiate a DDNS update. It MAY initiate this server MAY initiate a DDNS update. It MAY initiate this
update immediately upon entry to PARTNER-DOWN state, it may update immediately upon entry to PARTNER-DOWN state, it may
perform this in the background, or it MAY initiate this update perform this in the background, or it MAY initiate this update
upon next hearing from the DHCP client. upon next hearing from the DHCP client.
5.11.4. Deleting RRs from the DNS 5.12.4. Deleting RRs from the DNS
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
skipping to change at page 37, line 46 skipping to change at page 39, line 46
PARTNER-DOWN state, it may be performing DDNS deletes for RRs which PARTNER-DOWN state, it may be performing DDNS deletes for RRs which
its partner added originally. This allows a single remaining partner its partner added originally. This allows a single remaining partner
server to assume responsibility for all of the DDNS activity which server to assume responsibility for all of the DDNS activity which
the two servers were undertaking. the two servers were undertaking.
Another implication of this approach is that no DDNS RR deletes will Another implication of this approach is that no DDNS RR deletes will
be performed while either server is in COMMUNICATIONS-INTERRUPTED be performed while either server is in COMMUNICATIONS-INTERRUPTED
state, since no IP addresses are moved into the FREE state during state, since no IP addresses are moved into the FREE state during
that period. that period.
5.12. Reservations and failover 5.13. Reservations and failover
Some DHCP servers support a capability to offer specific pre- Some DHCP servers support a capability to offer specific pre-
configured IP addresses to DHCP clients. These are real DHCP configured IP addresses to DHCP clients. These are real DHCP
clients, they do the entire DHCP protocol, but these servers always clients, they do the entire DHCP protocol, but these servers always
offer the client a specific pre-configured IP address -- and they offer the client a specific pre-configured IP address -- and they
offer that IP address to no other clients. Such a capability has offer that IP address to no other clients. Such a capability has
several names, but it is sometimes called a "reservation", in that several names, but it is sometimes called a "reservation", in that
the IP address is reserved for a particular DHCP client. the IP address is reserved for a particular DHCP client.
In a situation where there are two DHCP servers serving the same sub- In a situation where there are two DHCP servers serving the same sub-
skipping to change at page 38, line 27 skipping to change at page 40, line 27
client. Different servers handle this conflict in different ways, client. Different servers handle this conflict in different ways,
but the goal of the failover protocol is to allow correct operation but the goal of the failover protocol is to allow correct operation
with any server's approach to the normal processing of the DHCP pro- with any server's approach to the normal processing of the DHCP pro-
tocol. tocol.
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
as BACKUP-RESERVED, in order that the secondary server be able to with the R bit set in the IP-flags option and the binding-status
allocate it as well. 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 protcol 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
skipping to change at page 39, line 5 skipping to change at page 41, line 5
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.
5.13. 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
BOOTP device has no term (or effectively no term, in that usually BOOTP device has no term (or effectively no term, in that usually
they are considered leases for "forever"). There is no opportunity they are considered leases for "forever"). There is no opportunity
skipping to change at page 39, line 38 skipping to change at page 41, line 38
over partner. Thus, the addresses allocated by the primary to the over partner. Thus, the addresses allocated by the primary to the
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.
5.14. Guidelines for selecting MCLT 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
MUST set the B bit in the IP-flags option.
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.14.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,
it will only have to wait a short time after the expiration of a it will only have to wait a short time after the expiration of a
lease on an IP address before it can reallocate that IP address to lease on an IP address before it can reallocate that IP address to
another DHCP client. another DHCP client.
However the downside of a short MCLT value is that the initial lease However the downside of a short MCLT value is that the initial lease
interval that will be offered to every new DHCP client will be short, interval that will be offered to every new DHCP client will be short,
which will cause increased traffic as those clients will need to send which will cause increased traffic as those clients will need to send
in their first renew in a half of a short MCLT time. In addition, in their first renew in a half of a short MCLT time. In addition,
the lease extensions that a server in COMMUNICATIONS-INTERRUPTED the lease extensions that a server in COMMUNICATIONS-INTERRUPTED
state can give will be only the MCLT after the server has been in state can give will be only the MCLT after the server has been in
COMMUNICATIONS-INTERRUPTED for around the desired client lease COMMUNICATIONS-INTERRUPTED for around the desired client lease
period. If a server stays in COMMUNICATIONS-INTERRUPTED for that period. If a server stays in COMMUNICATIONS-INTERRUPTED for that
long, then the leases it hands out will be short and that will long, then the leases it hands out will be short and that will
increase the load on that server, possibly causing difficulty. increase the load on that server, possibly causing difficulty.
5.14.2. Long MCLT 5.15.2. Long MCLT
A long MCLT value will mean that the initial lease period will be A long MCLT value will mean that the initial lease period will be
longer and the time that a server in COMMUNICATIONS-INTERRUPTED state longer and the time that a server in COMMUNICATIONS-INTERRUPTED state
will be able to extend leases (after it has been in COMMUNICATIONS- will be able to extend leases (after it has been in COMMUNICATIONS-
INTERRUPTED state for around the desired client lease period) will be INTERRUPTED state for around the desired client lease period) will be
longer. longer.
However, a server entering PARTNER-DOWN state will have to wait the However, a server entering PARTNER-DOWN state will have to wait the
longer MCLT before being able to allocate its partner's IP addresses longer MCLT before being able to allocate its partner's IP addresses
to new DHCP clients. This may mean that additional IP addresses are to new DHCP clients. This may mean that additional IP addresses are
required in order to cover this time period. Further, the server in required in order to cover this time period. Further, the server in
PARTNER-DOWN will have to wait the longer MCLT from every lease PARTNER-DOWN will have to wait the longer MCLT from every lease
expiration before it can reallocate an IP address to a different DHCP expiration before it can reallocate an IP address to a different DHCP
client. client.
5.16. What is sent in response to an UPDREQ or UPDREQALL message?
In section 7.3, the UPDREQ message is defined, and it says that the
receiving server sends to the requesting server "all of the binding
database information that it has not already seen". In section
7.4.2, the UPDREQALL message is defined, and it says that the receiv-
ing server sends to the requesting server "all binding database
information".
Both of these statements need further elaboration.
First, for the UPDREQ message, the information to be sent in BNDUPD
messages concerns "all of the binding database information it has not
already seen". Since every BNDUPD is acked by the receving server,
the sending server need only keep track of which IP addresses have
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
time, it knows which IP addresses have unacked binding database
information. This is less simple when, across reconfigurations of
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-
tion that the partner has seen this binding information.
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.
In this case, its partner's indication of which binding database
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
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
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-
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
which binding database information the partner server knows, so that
it will send all of its relevant binding database information to the
partner.
Third, in the event that a server receives a UPDREQALL message, what
constitutes "all binding database information"? At first glance this
would seem to be information on every configured IP address in the
server. While this would be technically correct, it may impose a
serious and unacceptable performance penalty on servers which have
millions of configured IP addresses. What can be done to lessen the
data that must be sent for an UPDREQALL?
When sending "all binding database information", if the sending
server sends only information concerning IP addresses which have been
at some time associated with clients, it will send enough information
to satisfy the needs of the failover protocol. It need not send
information on any IP addresses that have never been used, since
presumably they will be initialized as available to the primary
server (i.e. FREE) on any server employing failover.
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 45, line 10 skipping to change at page 48, line 10
Multiple binding update transactions MAY be batched together in one Multiple binding update transactions MAY be batched together in one
BNDUPD protocol message with the data sets for the individual tran- BNDUPD protocol message with the data sets for the individual tran-
sactions delimited by the assigned-IP-address option, which MUST sactions delimited by the assigned-IP-address option, which MUST
appear first in the option set for each transaction. Ordering of appear first in the option set for each transaction. Ordering of
options between the assigned-IP-address options is not significant. options between the assigned-IP-address options is not significant.
This is illustrated in the following schematic representation: This is illustrated in the following schematic representation:
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
Options pertaining to first address, including Options pertaining to first address, including at least the
at least the binding-status option and others as binding-status option and others as required.
required.
assigned-IP-address option for the second IP address assigned-IP-address option for the second IP address
Options pertaining to second address, including Options pertaining to second address, including at least the
at least the binding-status option and others as binding-status option and others as required.
required.
... ...
Trailing options (message digest). Trailing options (message digest).
There MUST be a one-to-one correspondence between BNDUPD and BNDACK There MUST be a one-to-one correspondence between BNDUPD and BNDACK
messages, and every BNDACK message MUST contain status for all of the messages, and every BNDACK message MUST contain status for all of the
binding update transactions in the corresponding BNDUPD message. binding update transactions in the corresponding BNDUPD message.
The BNDACK message corresponding to a BNDUPD message MUST contain The BNDACK message corresponding to a BNDUPD message MUST contain
assigned-IP-address options for all of the binding update transac- assigned-IP-address options for all of the binding update transac-
tions in the BNDUPD message. Thus, every BNDACK message contains tions in the BNDUPD message. Thus, every BNDACK message contains
skipping to change at page 47, line 11 skipping to change at page 50, line 11
The following table summarizes the various options for the BNDUPD The following table summarizes the various options for the BNDUPD
message. message.
binding-status BACKUP binding-status BACKUP
RESET RESET
ABANDONED ABANDONED
Option ACTIVE EXPIRED RELEASED FREE Option ACTIVE EXPIRED RELEASED FREE
------ ------ ------- -------- ---- ------ ------ ------- -------- ----
assigned-IP-address (3) MUST MUST MUST MUST assigned-IP-address (3) MUST MUST MUST MUST
IP-flags MUST(4) MUST(4) MUST(4) MUST(4)
binding-status MUST MUST MUST MUST binding-status MUST MUST MUST MUST
client-identifier MAY MAY MAY MAY(2) client-identifier MAY MAY MAY MAY(2)
client-hardware-address MUST MUST MUST MAY(2) client-hardware-address MUST MUST MUST MAY(2)
lease-expiration-time MUST MUST NOT MUST NOT MUST NOT lease-expiration-time MUST MUST NOT MUST NOT MUST NOT
potential-expiration-time MUST MUST NOT MUST NOT MUST NOT potential-expiration-time MUST MUST NOT MUST NOT MUST NOT
start-time-of-state SHOULD SHOULD SHOULD SHOULD start-time-of-state SHOULD SHOULD SHOULD SHOULD
client-last-trans.-time MUST SHOULD MUST MAY client-last-trans.-time MUST SHOULD MUST MAY
DDNS(1) SHOULD SHOULD SHOULD SHOULD DDNS(1) SHOULD SHOULD SHOULD SHOULD
client-request-options SHOULD SHOULD NOT SHOULD SHOULD NOT client-request-options SHOULD SHOULD NOT SHOULD SHOULD NOT
client-reply-options SHOULD SHOULD NOT SHOULD NOT SHOULD NOT client-reply-options SHOULD SHOULD NOT SHOULD NOT SHOULD NOT
(1) MUST if server is performing dynamic DNS for this IP address, else (1) MUST if server is performing dynamic DNS for this IP address, else
MUST NOT. MUST NOT.
(2) MUST NOT if binding-status is ABANDONED. (2) MUST NOT if binding-status is ABANDONED.
(3) assigned-IP-address MUST be the first option for an IP address (3) assigned-IP-address MUST be the first option for an IP address
(4) IP-flags option MUST appear if any flags are non-zero, else it
MAY appear.
Table 7.1-1: Options used in a BNDUPD message Table 7.1-1: Options used in a BNDUPD message
7.1.1. Sending the BNDUPD message 7.1.1. Sending the BNDUPD message
A BNDUPD message SHOULD be generated whenever any binding changes. A A BNDUPD message SHOULD be generated whenever any binding changes. A
change might be in the binding-status, the lease-expiration-time, or change might be in the binding-status, the lease-expiration-time, or
even just the last-transaction-time. In general, any time a DHCP even just the last-transaction-time. In general, any time a DHCP
server writes its stable storage, a BNDUPD message SHOULD be gen- server writes its stable storage, a BNDUPD message SHOULD be gen-
erated. This will often be the result of the processing of a DHCP erated. This will often be the result of the processing of a DHCP
client request, but it might also be the result of a successful client request, but it might also be the result of a successful
dynamic DNS update operation. dynamic DNS update operation. Stable storage updates due to BNDUPD
or BNDACK messages SHOULD NOT result in additional BNDUPD messages.
BNDUPD (and BNDACK) messages refer to the binding-status of the IP BNDUPD (and BNDACK) messages refer to the binding-status of the IP
address, and this protocol defines a series of binding-statuses, dis- address, and this protocol defines a series of binding-statuses, dis-
cussed in more detail below. Some servers may not support all of cussed in more detail below. Some servers may not support all of
these binding-statuses, and so in those cases they will not be sent. these binding-statuses, and so in those cases they will not be sent.
Upon receipt of a BNDUPD message which contains an unsupported Upon receipt of a BNDUPD message which contains an unsupported
binding-status, a reasonable interpretation should be made (see sec- binding-status, a reasonable interpretation should be made (see sec-
tion 5.10). tion 5.10).
All BNDUPD messages MUST contain the IP address of the binding update All BNDUPD messages MUST contain the IP address of the binding update
transaction in the assigned-IP-address option. transaction in the assigned-IP-address option.
All binding update transactions MUST contain an IP-flags option if
the value of any of the flags would be non-zero. The IP-flags option
MAY be omitted if all of the flags that it contains are zero. The
IP-flags option contains a flag which indicates if the IP address is
currently reserved on the server sending the BNDUPD message. It also
contains a flag which indicates that the lease is associated with a
client that used the BOOTP protocol (as opposed to the DHCP protocol)
to interact with the DHCP server.
All binding update transactions contain a binding-status option, and All binding update transactions contain a binding-status option, and
it will have one of the values found in section 5.10. Client infor- it will have one of the values found in section 5.11. Client infor-
mation consists of client-hardware-address and possibly a client- mation consists of client-hardware-address and possibly a client-
identifier, and is explained in more detail later in this section. identifier, and is explained in more detail later in this section.
The following table indicates whether client information should or The following table indicates whether client information should or
should not appear with each binding-status in a binding update tran- should not appear with each binding-status in a binding update tran-
saction: saction:
binding-status includes client information binding-status includes client information
------------------------------------------------ ------------------------------------------------
ACTIVE MUST ACTIVE MUST
EXPIRED SHOULD EXPIRED SHOULD
skipping to change at page 51, line 41 skipping to change at page 54, line 49
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 dif- to the case where a single client has addresses in multiple
ferent subnets or administrative domains, but rather the case different 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 update which has the latest client-last-
transaction-time. 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
When analyzing a BNDUPD message from a partner server, if there is
insufficient information in the BNDUPD to process it, then reject the
BNDUPD with reject-reason 3: "Missing binding information".
If the IP address in the BNDUPD is not an IP address associated with
the failover endpoint which received the BNDUPD message, then reject
it with reject-reason 1: "Illegal IP address (not part of any address
pool)".
IP addresses undergo binding status changes for several reasons, IP addresses undergo binding status changes for several reasons,
including receipt and processing of DHCP client requests, administra- including receipt and processing of DHCP client requests, administra-
tive inputs and receipt of BNDUPD messages. Every DHCP server needs tive inputs and receipt of BNDUPD messages. Every DHCP server needs
to respond to DHCP client requests and administrative inputs with to respond to DHCP client requests and administrative inputs with
changes to its internal record of the binding-status of an IP changes to its internal record of the binding-status of an IP
address, and this response is not in the scope of the failover proto- address, and this response is not in the scope of the failover proto-
col. However, the receipt of BNDUPD messages implies at least a pos- col. However, the receipt of BNDUPD messages implies at least a pos-
sible change of the binding-status for an IP address, and must be sible change of the binding-status for an IP address, and must be
discussed here. See section 7.1.2 for general actions to take upon discussed here. See section 7.1.2 for general actions to take upon
receipt of a BNDUPD message. receipt of a BNDUPD message.
When receiving a BNDUPD message, it is important to note that it may When receiving a BNDUPD message, it is important to note that it may
not be current, in that the server receiving the BNDUPD message may not be current, in that the server receiving the BNDUPD message may
have had a more recent interaction with the DHCP client than its have had a more recent interaction with the DHCP client than its
partner who sent the BNDUPD message. In this case, the receiving partner who sent the BNDUPD message. In this case, the receiving
server MUST reject the BNDUPD message. In addition, it is worth not- server MUST reject the BNDUPD message. The reject reason SHOULD be
ing that two (and possibly three) binding-status values are the 15: "Outdated binding information". In addition, it is worth noting
direct result of interaction with a DHCP client, ACTIVE and RELEASED that two (and possibly three) binding-status values are the direct
(and possibly ABANDONED). All other binding-status values are either result of interaction with a DHCP client, ACTIVE and RELEASED (and
the result of the expiration of a time period or interaction with an possibly ABANDONED). All other binding-status values are either the
result of the expiration of a time period or interaction with an
external agency (e.g., a network administrator). external agency (e.g., a network administrator).
Every BNDUPD message SHOULD contain a client-last-transaction-time Every BNDUPD message SHOULD contain a client-last-transaction-time
option, which MUST, if it appears, be the time that the server last option, which MUST, if it appears, be the time that the server last
interacted with the DHCP client. It MUST NOT be, for instance, the interacted with the DHCP client. It MUST NOT be, for instance, the
time that the lease on an IP address expired. If there has been no time that the lease on an IP address expired. If there has been no
interaction with the DHCP client in question (or there is no DHCP interaction with the DHCP client in question (or there is no DHCP
client presently associated with this IP address), then there will be client presently associated with this IP address), then there will be
no client-last-transaction-time option in the BNDUPD message. no client-last-transaction-time option in the BNDUPD message.
skipping to change at page 53, line 23 skipping to change at page 56, line 41
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 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 a BNDUPD message and in a receiving server's binding differ, then if
the receiving server's binding-status is ACTIVE and the binding- the receiving server's binding-status is ACTIVE and the binding-
status in the BNDUPD is ACTIVE, then if the receiving server is a status in the BNDUPD is ACTIVE, then if the receiving server is a
secondary server accept it, else reject it. 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 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 reject reject reject 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.
time(2): If the current time is later than the receiving time(2): If the current time is later than the receiving
servers' lease-expiration-time, accept it, else reject it. servers' lease-expiration-time, accept it, else reject it.
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
information".
(4): Use reject reason 16: "Less critical binding information".
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
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
does not show the IP address as reserved, the receiving server SHOULD
reject the BNDUPD using reject reason 19: "IP not reserved on this
server".
7.1.4. Accepting the BNDUPD message 7.1.4. Accepting the BNDUPD message
When accepting a BNDUPD message, the information contained in the When accepting a BNDUPD message, the information contained in the
client-request-options and client-reply-options SHOULD be examined client-request-options and client-reply-options SHOULD be examined
for any information of interest to this server. For instance, a for any information of interest to this server. For instance, a
server which wished to detect changes in client specified host names server which wished to detect changes in client specified host names
might want to examine and save information from the host-name or might want to examine and save information from the host-name or
client-FQDN options. Servers which expect to utilize information client-FQDN options. Servers which expect to utilize information
from the relay-agent-information option would want to store this from the relay-agent-information option would want to store this
information. information.
skipping to change at page 57, line 10 skipping to change at page 60, line 52
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 multi- and generate the corresponding BNDACK messages with status for
ple binding update transactions. If a server does not ever create multiple binding update transactions. If a server does not ever
BNDUPD messages which contain multiple binding update transactions, create BNDUPD messages which contain multiple binding update transac-
then it does not need to be able to process a received BNDACK message tions, then it does not need to be able to process a received BNDACK
with multiple binding update transactions. However, all servers MUST message with multiple binding update transactions. However, all
be able to create BNDACK messages which deal with multiple binding servers MUST be able to create BNDACK messages which deal with multi-
update transactions received in a BNDUPD message. ple binding 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 58, line 5 skipping to change at page 61, line 32
only during the life of a single TCP connection. When a connection only during the life of a single TCP connection. When a connection
to a partner server goes down, a server with unprocessed BNDUPD mes- to a partner server goes down, a server with unprocessed BNDUPD mes-
sages MAY simply drop all of those messages, since it can be sure sages MAY simply drop all of those messages, since it can be sure
that the partner will resend them when they are next in communica- that the partner will resend them when they are next in communica-
tions (albeit with a different XID), or it MAY instead choose to pro- tions (albeit with a different XID), or it MAY instead choose to pro-
cess those BNDUPD messages, but it MUST NOT send any BNDACK messages cess those BNDUPD messages, but it MUST NOT send any BNDACK messages
in response. in response.
The following table summarizes the options for the BNDACK message. The following table summarizes the options for the BNDACK message.
binding-status BACKUP Option accept reject
RESET ------ ------ ------
ABANDONED assigned-IP-address (1) MUST MUST
Option ACTIVE EXPIRED RELEASED FREE IP-flags SHOULD NOT SHOULD NOT
------ ------ ------- -------- ---- binding-status SHOULD NOT SHOULD NOT
assigned-IP-address (3) MUST MUST MUST MUST client-identifier SHOULD NOT SHOULD NOT
binding-status MUST MUST MUST MUST client-hardware-address SHOULD NOT SHOULD NOT
client-identifier MAY MAY MAY MAY(2) reject-reason SHOULD NOT MUST
client-hardware-address MUST MUST MUST MAY(2) message SHOULD NOT SHOULD
reject-reason MAY MAY MAY MAY lease-expiration-time SHOULD NOT SHOULD NOT
message MAY MAY MAY MAY potential-expiration-time SHOULD NOT SHOULD NOT
lease-expiration-time MUST MUST NOT MUST NOT MUST NOT start-time-of-state SHOULD NOT SHOULD NOT
potential-expiration-time MUST MUST NOT MUST NOT MUST NOT client-last-trans.-time SHOULD NOT SHOULD NOT
start-time-of-state SHOULD SHOULD SHOULD SHOULD DDNS(1) SHOULD NOT SHOULD NOT
client-last-trans.-time SHOULD SHOULD SHOULD MAY
DDNS(1) SHOULD SHOULD SHOULD SHOULD
(1) MUST if server is performing dynamic DNS for this IP address, else (1) assigned-IP-address MUST be the first option for an IP address
MUST NOT.
(2) MUST NOT if binding-status is ABANDONED.
(3) assigned-IP-address MUST be the first option for an IP address
Table 7.2-1: Options used in a BNDACK message Table 7.2-1: Options used in a BNDACK message
7.2.1. Sending the BNDACK message 7.2.1. Sending the BNDACK message
The BNDACK message MUST contain the same xid as the corresponding The BNDACK message MUST contain the same xid as the corresponding
BNDUPD message. BNDUPD message.
The assigned-IP-address option from the BNDUPD message MUST be The assigned-IP-address option from the BNDUPD message MUST be
included in the BNDACK message. Any additional options from the included in the BNDACK message. Any additional options from the
skipping to change at page 60, line 51 skipping to change at page 64, line 25
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.
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 request that its partner send it all of the binding database informa-
information. This message is used to allow one server to recover tion. This message is used to allow one server to recover from a
from a failure of stable storage and to restore its binding database failure of stable storage and to restore its binding database in its
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
its binding update information is restored, and it knows that all of its binding update information is restored, and it knows that all of
that information is restored when an UPDDONE message is received. that information is restored when an UPDDONE message is received.
See section 9, Protocol state transitions, for the details of when See section 9, Protocol state transitions, for the details of when
the UPDREQALL message is sent. the UPDREQALL message is sent.
The UPDREQALL message has no message specific options. The UPDREQALL message has no message specific options.
skipping to change at page 65, line 28 skipping to change at page 68, line 49
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 algo-
rithm. The way in which the primary server determines this informa- rithm. The way in which the primary server determines this
tion is outside the scope of this protocol definition. The primary information is outside the scope of this protocol definition. The
server SHOULD be configured with a percentage of clients that the primary server SHOULD be configured with a percentage of clients that
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 [LOADB] to generate a Hash Bucket
Assignment which it sends to the secondary server. 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-
skipping to change at page 66, line 14 skipping to change at page 69, line 38
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.
2. Examine the protocol-version option, and decide if this server 2. Examine the protocol-version option, and decide if this server
is capable of interoperating with another server running that is capable of interoperating with another server running that
protocol version. If not, send the CONNECTACK message with protocol version. If not, send the CONNECTACK message with
the appropriate reject-reason. The server MUST include its the reject reason 14: "Protocol version mismatch". The server
protocol-version in the CONNECTACK message. MUST include its protocol-version in the CONNECTACK message.
3. Examine the TLS-request option. Figure out the TLS-reply 3. Examine the TLS-request option. Figure out the TLS-reply
value based on the capabilities and configuration of this value based on the capabilities and configuration of this
server. If the result for the TLS-reply value is a 1 and the server. If the result for the TLS-reply value is a 1 and the
connection is accepted, indicating use of TLS, then immedi- connection is accepted, indicating use of TLS, then immedi-
ately send the CONNECTACK message and go into TLS negotiation. ately send the CONNECTACK message and go into TLS negotiation.
If the TLS-reply value implies rejection of the connection, If the TLS-reply value implies rejection of the connection,
then immediately send the CONNECTACK message with the TLS- then immediately send the CONNECTACK message with the TLS-
reply value and the appropriate reject-reason option value. reply value and the appropriate reject-reason option value.
In all other cases, save the TLS-reply option information for In all other cases, save the TLS-reply option information for
skipping to change at page 66, line 45 skipping to change at page 70, line 22
-- -- ------ -------- -- -- ------ --------
0 0 no TLS used 0 0 no TLS used
0 1 11 primary won't use TLS, secondary requires TLS 0 1 11 primary won't use TLS, secondary requires TLS
1 0 primary desires TLS, secondary doesn't 1 0 primary desires TLS, secondary doesn't
1 1 primary desires TLS, secondary will use TLS 1 1 primary desires TLS, secondary will use TLS
2 0 9, 10 primary requires TLS and secondary won't 2 0 9, 10 primary requires TLS and secondary won't
2 1 primary requires TLS and secondary will use TLS 2 1 primary requires TLS and secondary will use TLS
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 the appropri- message-digests, then reject the connection with reject reason
ate reject-reason in the CONNECTACK. If the server does sup- 12: "Message digest not supported" in the CONNECTACK. If the
port message-digests, then check this message for validity server does support message-digests, then check this message
based on the message-digest, and reject it if the digest indi- for validity based on the message-digest, and reject it if the
cates the message was altered. digest indicates the message was altered with reject reason
20: "Message digest failed to compare".
5. Determine if the sender (from the sending-server-IP-address 5. Determine if the sender (from the sending-server-IP-address
option) and the implicit role of the sender (i.e., primary) option) and the implicit role of the sender (i.e., primary)
represents a server with which the receiver was configured to represents a server with which the receiver was configured to
engage in failover activity. This is performed after any TLS engage in failover activity. This is performed after any TLS
or message digest processing so that it occurs after a secure or message digest processing so that it occurs after a secure
connection is created, to ensure that there is no tampering connection is created, to ensure that there is no tampering
with the IP address of the partner. with the IP address of the partner.
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 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. See section 5.9 for over 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-
skipping to change at page 68, line 24 skipping to change at page 72, line 5
TACK with a reject-reason or after sending a CONNECTACK with a TACK with a reject-reason or after sending a CONNECTACK with a
reject-reason could yield unwanted looping behavior, since the reason reject-reason could yield unwanted looping behavior, since the reason
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 Option accept reject
------ ------
sending-server-IP-address MUST sending-server-IP-address MUST MUST
max-unacked-bndupd MUST max-unacked-bndupd MUST MUST NOT
receive-timer MUST receive-timer MUST MUST NOT
vendor-class-identifier MUST vendor-class-identifier MUST MUST NOT
protocol-version MUST protocol-version MUST MUST
TLS-request MUST(1) TLS-reply (1) (2)
reject-reason MAY(2) reject-reason MUST NOT MUST
message MAY message MUST NOT SHOULD
MCLT MUST NOT MCLT MUST NOT MUST NOT
hash-bucket-assignment MUST NOT hash-bucket-assignment MUST NOT MUST NOT
(1) MUST NOT if sending CONNECTACK after TLS negotiation (1) MUST NOT if sending CONNECTACK after TLS negotiation, MUST
(2) Indicates a rejection of the CONNECT message. if TLS-request in CONNECT, 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 IP address of the sending server MUST be placed in the sending-
server-IP-address option. This information is placed in an option server-IP-address option. This information is placed in an option
skipping to change at page 69, line 48 skipping to change at page 73, line 31
a STATE message. a STATE message.
After a connection is created, the server MUST start two timers for After a connection is created, the server MUST start two timers for
the connection: tSend and tReceive. The tSend timer SHOULD be the connection: tSend and tReceive. The tSend timer SHOULD be
approximately 33 percent of the time in the receiver-timer option in approximately 33 percent of the time in the receiver-timer option in
the corresponding CONNECT message. The tReceive timer SHOULD be the the corresponding CONNECT message. The tReceive timer SHOULD be the
time sent in the receiver-timer option in the CONNECTACK message. time sent in the receiver-timer option in the CONNECTACK message.
The tReceive timer is reset whenever a message is received from this The tReceive timer is reset whenever a message is received from this
TCP connection. If it ever expires, the TCP connection is dropped TCP connection. If it ever expires, the TCP connection is dropped
and communications with this partner is considered not ok. and communications with this partner is considered not ok. The
reject reason 17: "No traffic within sufficient time" is placed in
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.
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 CONNEC- 3. Check to see if there is a reject-reason option in the
TACK message. If not, continue with step 3. If there is a CONNECTACK message. If not, continue with step 3. If there
reject-reason option, the server SHOULD report the error code. is a reject-reason option, the server SHOULD report the error
If a message option appears a server SHOULD display the string code. If a message option appears a server SHOULD display the
from the message option in a user visible way. The server string from the message option in a user visible way. The
MUST close the connection if a reject-reason option appears. server MUST close the connection if a reject-reason option
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 70, line 52 skipping to change at page 74, line 38
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.
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 valued options. Note that the failover protocol is con-
constructed 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
vendor specific processing. vendor specific processing.
8. After accepting a CONNECTACK message, the server MUST send a 8. After accepting a CONNECTACK message, the server MUST send a
STATE message. STATE message.
After receiving a CONNECTACK message, the server MUST start After receiving a CONNECTACK message, the server MUST start
two timers for the connection: tSend and tReceive. The tSend two timers for the connection: tSend and tReceive. The tSend
skipping to change at page 71, line 17 skipping to change at page 75, line 4
7. The receiving server MAY use the vendor-class-identifier to do 7. The receiving server MAY use the vendor-class-identifier to do
vendor specific processing. vendor specific processing.
8. After accepting a CONNECTACK message, the server MUST send a 8. After accepting a CONNECTACK message, the server MUST send a
STATE message. STATE message.
After receiving a CONNECTACK message, the server MUST start After receiving a CONNECTACK message, the server MUST start
two timers for the connection: tSend and tReceive. The tSend two timers for the connection: tSend and tReceive. The tSend
timer SHOULD be approximately 20 percent of the time in the timer SHOULD be approximately 20 percent of the time in the
receiver-timer option in the corresponding CONNECTACK message. receiver-timer option in the corresponding CONNECTACK message.
The tReceive timer SHOULD be set to the time sent in the The tReceive timer SHOULD be set to the time sent in the
receiver-timer option in the CONNECT message. receiver-timer option in the CONNECT message.
The tReceive timer is reset whenever a message is received The tReceive timer is reset whenever a message is received
from this TCP connection. If it ever expires, the TCP connec- from this TCP connection. If it ever expires, the TCP connec-
tion is dropped and communications with this partner is con- tion is dropped and communications with this partner is con-
sidered not ok. sidered not ok. The reject reason 17: "No traffic within suf-
ficient time" is placed in the DISCONNECT message sent prior
to dropping the TCP connection.
The tSend timer is reset whenever a message is sent over this The tSend timer is reset whenever a message is sent over this
connection. When it expires, a CONTACT message MUST be sent. connection. When it expires, a CONTACT message MUST be sent.
7.10. STATE message [10] 7.10. STATE message [10]
The state (STATE) message is used to communicate the current failover The state (STATE) message is used to communicate the current failover
state to the partner server. state to the partner server.
The STATE message MUST be sent after sending a CONNECTACK message The STATE message MUST be sent after sending a CONNECTACK message
skipping to change at page 74, line 49 skipping to change at page 78, line 29
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 protcol 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 TBD 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 it is attempting to connect to this server to become a
secondary server for it. Likewise, when an attempt to connect is secondary server for it. Likewise, when an attempt to connect is
received on port TBD the connection attempt is from a secondary received on port 847 the connection attempt is from a secondary
server, and it is attempting to connect to this server to be a pri- server, and it is attempting to connect to this server to be a pri-
mary server. The source port of any TCP connection is unimportant. mary server. The source port of any TCP connection is unimportant.
See the schematic representation below: See the schematic representation below:
Primary Server Primary Server
-------------- --------------
Listens on port TBD 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 TDB 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
skipping to change at page 75, line 38 skipping to change at page 79, line 21
If a connection attempt has been received from another server in a If a connection attempt has been received from another server in a
particular role (i.e., from a specific failover endpoint) then the particular role (i.e., from a specific failover endpoint) then the
receiving server MUST NOT initiate a connection attempt to the receiving server MUST NOT initiate a connection attempt to the
partner server in that same role. partner server in that same role.
If both servers happen to attempt to connect simultaneously, the If both servers happen to attempt to connect simultaneously, the
secondary server MUST drop its attempt in favor of the primary's secondary server MUST drop its attempt in favor of the primary's
attempt. Thus, in the event that a secondary server receives a con- attempt. Thus, in the event that a secondary server receives a con-
nection attempt to port 647 from a primary server when it has already nection attempt to port 647 from a primary server when it has already
initiated a connection attempt to port TBD on the same primary initiated a connection attempt to port 847 on the same primary
server, it MUST accept the connection to port 647 and it MUST drop server, it MUST accept the connection to port 647 and it MUST drop
drop the connection attempt to port TBD. In the event that a primary drop the connection attempt to port 847. In the event that a primary
server receives a connection attempt to port TBD from a secondary server receives a connection attempt to port 847 from a secondary
server when it has already initiated a connection attempt to port 647 server when it has already initiated a connection attempt to port 647
on that same server, it MUST reject the connection attempt to port on that same server, it MUST reject the connection attempt to port
TBD and continue to pursue the connection attempt on port 647. 847 and continue to pursue the connection attempt on port 647.
Once a connection is established, the primary server MUST send a CON- Once a connection is established, the primary server MUST send a CON-
NECT message across the connection. A secondary server MUST wait for NECT message across the connection. A secondary server MUST wait for
the CONNECT message from a primary server. the CONNECT message from a primary server.
Every CONNECT message includes a TLS-request option, and if the CON- Every CONNECT message includes a TLS-request option, and if the CON-
NECTACK message does not reject the CONNECT message and the TLS-reply NECTACK message does not reject the CONNECT message and the TLS-reply
option says TLS MUST be used, then the servers will immediately enter option says TLS MUST be used, then the servers will immediately enter
into TLS negotiation. into TLS negotiation.
skipping to change at page 77, line 17 skipping to change at page 80, line 45
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
reject reason 17: "No traffic within sufficient time" is placed in
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,
such an occasional delay doesn't compromise the correctness of the such an occasional delay doesn't compromise the correctness of the
protocol. However, the speed with which one server detects the other protocol. However, the speed with which one server detects the other
server is up (or, more importantly, down) is more highly constrained. server is up (or, more importantly, down) is more highly constrained.
skipping to change at page 78, line 18 skipping to change at page 81, line 51
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 net- prevented because if the receiver is not reachable (via the
work), the sending TCP can't send and thus it will be unable to network), 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.
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
skipping to change at page 81, line 6 skipping to change at page 84, line 39
technique of memory of partner state and automatic state transi- technique of memory of partner state and automatic state transi-
tion on change of partner state is to have every state in the fol- tion on change of partner state is to have every state in the fol-
lowing diagram have a state transition for every possible state of lowing diagram have a state transition for every possible state of
the partner. With the approach adopted, only the states in which the partner. With the approach adopted, only the states in which
communications are reestablished require a state transition for communications are reestablished require a state transition for
each possible partner state. each possible partner state.
The current state of a server MUST be recorded in stable storage and The current state of a server MUST be recorded in stable storage and
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
following figure, since other than sending that state to its partner,
the remaining actions involved look just like the server halting in
its otherwise current state, which then becomes the previous state
upon server restart.
+---------------+ V +--------------+ +---------------+ V +--------------+
| RECOVER - | | | STARTUP - | | RECOVER -|+| | | STARTUP - |
|(unresponsive) | +->|(unresponsive)| +->+(unresponsive) | +->+(unresponsive)|
+---------------+ +--------------+ | +------+--------+ +--------------+
Comm. OK +-----------------+ | Comm. OK +-----------------+
Other State:-RECOVER | PARTNER DOWN - |<-----------------+ Comm. Other State:RECOVER | PARTNER DOWN - +<----------------------+
| | | (responsive) | | Fail | RESOLUTION-INTER. | (responsive) | ^
All POTENTIAL- +-----------------+ +--------------+ | | All POTENTIAL- +----+------------+ +--------------+ |
Others CONFLICT------------ | --------+ | RESOLUTION -| | | Others CONFLICT------------ | --------+ | RESOLUTION -| |
| Comm. OK | | INTERRUPTED | | | | CONFLICT-DONE Comm. OK | | INTERRUPTED | |
UPDREQ(ALL) Other State: | +-| (responsive) | | [UPDREQALL Other State: | +-+ (responsive) | |
Wait UPDDONE | | | | +--------------+ | [Wait UPDDONEE | | | | +------+------++ |
Wait MCLT from fail RECOVER All Others| Comm. OK ^ | | [Wait MCLT from fail RECOVER All Others| Comm.OK ^ | |
+--------------+ | V V V | Ext. | +---+----------+ | V V V Comm. Ext. |
|RECOVER-DONE +| +--+ +--------------+ Comm. Cmd. | |RECOVER-DONE +| +--+ +---+-----+--+-+ Failed Cmd----->+
|(unresponsive)| | | POTENTIAL + | Failed | | |(unresponsive)| | | POTENTIAL + +------+ |
+--------------+ Wait for +>| CONFLICT |------+ +-->| +------+-------+ Wait for +>+ CONFLICT +-Pri. Resolve Comm. |
Comm. OK Other | |(unresponsive)|<--------+ | Comm. OK Other | |(unresponsive)| Conflict CHANGED |
+--Other State:-+ State: | +--------------+ | | +--Other State:-+ State: | +----+--------++ V V | |
| | | RECOVER | | | | | | | RECOVER | | ^ ++----------+---++ |
| All POTENT. DONE | Resolve Conflict | | | All POTENT. DONE | Sec. Resolve | |CONFLICT-DONE-|+| |
| Others: CONFLICT-- | ----+ (see 9.8) | | | Others: CONFLICT-- | ----+ Conflict(9.8) | | (responsive) | |
| Wait for V V | | | Wait for V V | +------+---------+ |
| Other State: NORMAL +-----------------+ | | | Other State: NORMAL ++------------+---+ Other State: NORMAL |
| V | NORMAL + | External | | | V | NORMAL + +<--------------+ |
| +--+----------+-->| (balanced) |-Command---+-- | -----+ | +--+----------+-->+ (balanced) +-------External Command--->+
| ^ ^ +-----------------+ | | | ^ ^ +--------+--------+ or Other State: |
| | | | | | | | | | | SHUTDOWN |
| Wait for Comm. OK Comm. External | | Wait for Comm. OK Comm. Failed or | |
| Other Other Failed Command | | Other Other Other State: PAUSED | External
| State: State: | or | | | State: State: | | Command
|RECOVER-DONE NORMAL Start Safe Safe | | |RECOVER-DONE NORMAL Start Safe Comm. OK or
| | COMM. INT. Period Timer Period | | | | COMM. INT. Period Timer Other State: Safe
| Comm. OK. | V expiration | | Comm. OK. | V All Others Period
| Other State: | +------------------+ | | | Other State: | +---------+--------+ | expiration
| RECOVER +--| COMMUNICATIONS - |-----------+ | | RECOVER +--+ COMMUNICATIONS - +----+ |
V +-------------| INTERRUPTED | Comm. OK | V +-------------+ INTERRUPTED | |
RECOVER | (responsive) |--Other State:-+ RECOVER | (responsive) +-------------------------->+
RECOVER-DONE--------->+------------------+ All Others RECOVER-DONE--------->+------------------+
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:
skipping to change at page 83, line 20 skipping to change at page 87, line 20
the RECOVER-DONE state, below. 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 nor of any previous operational activity for this
server, then set the previous-state to PARTNER-DOWN if this server, then set the previous-state to PARTNER-DOWN if this
server is a primary and RECOVER if this server is a secondary, server is a primary and RECOVER if this server is a secondary,
and set the time-of-failure to a time before the maximum- and set the time-of-failure to a time before the maximum-
client-lead-time before now. If using standard Posix times, 0 client-lead-time before now. If using standard Posix times, 0
would typically do quite well. would typically do quite well.
2. Is the previous-state NORMAL? If yes, set the previous-state 2. If the previous state is one where communications was "OK",
to COMMUNICATIONS-INTERRUPTED. then set the previous state to the state that is the result of
the communiations failed state transition in Figure 9.2-1 (if
any -- some states both).
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 configur-
able. It SHOULD be long enough for a TCP connection to be able. It SHOULD be long enough for a TCP connection to be
created to a heavily loaded partner across a slow network. created to a heavily loaded partner across a slow network.
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.
skipping to change at page 84, line 5 skipping to change at page 88, line 6
the last recorded time of operation of this server, then set the last recorded time of operation of this server, then set
the current state to RECOVER. If the time at which it entered the current state to RECOVER. If the time at which it entered
PARTNER-DOWN state is earlier than the last recorded time of PARTNER-DOWN state is earlier than the last recorded time of
operation of this server, then set the current state to operation of this server, then set the current state to
POTENTIAL-CONFLICT. POTENTIAL-CONFLICT.
Then, transition to the current state and take the "communica- Then, transition to the current state and take the "communica-
tions okay" state transition based on the current state of tions okay" state transition based on the current state of
this server and the partner. this server and the partner.
7. If the startup time expires, take an implementation dependent 6. If the startup time expires, take an implementation dependent
action: The server MAY go to the previous-state, or the action: The server MAY go to the previous-state, or the
server MAY wait. server MAY wait.
Reasons to go to previous-state and begin processing: Reasons to go to previous-state and begin processing:
If the current server is the only operational server, then if If the current server is the only operational server, then if
it waits, there will be no operational DHCP servers. This it waits, there will be no operational DHCP servers. This
situation could occur very easily where one server fails and situation could occur very easily where one server fails and
then the other crashes and reboots. If the rebooting server then the other crashes and reboots. If the rebooting server
doesn't start processing DHCP client requests without first doesn't start processing DHCP client requests without first
skipping to change at page 86, line 24 skipping to change at page 90, line 24
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:
o partner in NORMAL, COMMUNICATIONS-INTERRUPTED, PARTNER-DOWN or o partner in NORMAL, COMMUNICATIONS-INTERRUPTED, PARTNER-DOWN,
POTENTIAL-CONFLICT state POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, or CONFLICT-DONE
state
transition to POTENTIAL-CONFLICT state transition to POTENTIAL-CONFLICT state
o partner in RECOVER state o partner in RECOVER, 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 87, line 7 skipping to change at page 91, line 7
9.5.1. Operation in RECOVER state 9.5.1. Operation in RECOVER state
A server in RECOVER MUST NOT respond to DHCP client requests. A server in RECOVER MUST NOT respond to DHCP client requests.
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 state when communica- If the other server is in POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED,
tions are reestablished, then the server in RECOVER state will move or CONFLICT-DONE state when communications are reestablished, then
to POTENTIAL-CONFLICT state itself. the server in RECOVER state will move to POTENTIAL-CONFLICT state
itself.
If the other server is in RECOVER state, then this server SHOULD sig- If the other server is in RECOVER state, then this server SHOULD sig-
nal an error and halt processing. 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.
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 start a timer whose expiration is set to a time equal to the
time the server went down (if known) or the current time (if the time the server went down (if known) or the time the server started
down-time is unknown) plus the maximum-client-lead-time. When this (if the down-time is unknown) plus the maximum-client-lead-time.
timer goes off, the server will transition into RECOVER-DONE state. When this timer goes off, the server will transition into RECOVER-
This is to allow any IP addresses that were allocated by this server DONE state. This is to allow any IP addresses that were allocated by
prior to loss of its client binding information in stable storage to this server prior to loss of its client binding information in stable
contact the other server or to time out. storage to contact the other server or to time out.
See Figure 9.5.2-1. See Figure 9.5.2-1.
DISCUSSION: DISCUSSION:
The actual requirement on this wait period in RECOVER is that it The actual requirement on this wait period in RECOVER is that it
start not before the recovering server went down, not necessarily start not before the recovering server went down, not necessarily
when it came back up. If the time when the recovering server when it came back up. If the time when the recovering server
failed is known, it could be communicated to the recovering server failed is known, it could be communicated to the recovering server
(perhaps through actions of the network administrator), and the (perhaps through actions of the network administrator), and the
skipping to change at page 87, line 52 skipping to change at page 92, line 5
the difference between the current time and the time the server the difference between the current time and the time the server
failed. In this way, the waiting period could be minimized. failed. In this way, the waiting period could be minimized.
Various heuristics could be used to estimate this time, for exam- Various heuristics could be used to estimate this time, for exam-
ple if the recovering server periodically updates stable storage ple if the recovering server periodically updates stable storage
with a time stamp, the wait period could be calculated to start at 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 the time of the last update of stable storage plus the time
required for the next update (which never occurred). This esti- required for the next update (which never occurred). This esti-
mate is later than the server went down, but probably not too much mate is later than the server went down, but probably not too much
later. later.
If an UPDDONE message isn't received within an implementation If an UPDDONE message isn't received within an implementation depen-
dependent amount of time, and no BNDUPD messages are being received, dent amount of time, and no BNDUPD messages are being received, the
the connection SHOULD be dropped. connection SHOULD be dropped.
A B A B
Server Server Server Server
| | | |
RECOVER PARTNER-DOWN RECOVER PARTNER-DOWN
| | | |
| >--UPDREQ--------------------> | | >--UPDREQ--------------------> |
| | | |
| <---------------------BNDUPD--< | | <---------------------BNDUPD--< |
skipping to change at page 89, line 5 skipping to change at page 93, line 5
| >--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,
the server will stay in RECOVER state. When communications are
restored, it will restart the process of transitioning out of RECOVER
state.
9.6. NORMAL state 9.6. 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.6.1. Upon entry to NORMAL state
skipping to change at page 91, line 24 skipping to change at page 95, line 28
section 8), then transition into COMMUNICATIONS-INTERRUPTED state. section 8), then transition into COMMUNICATIONS-INTERRUPTED 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 state from that expected by the server where the partner has changed state from that expected by the server
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
where the PARTNER has changed into PAUSED state, the server should
transition into COMMUNICATIONS-INTERRUPTED state. If a server in
NORMAL state receives any messages from its partner where the PARTNER
has changed into SHUTUDOWN state, the server should transition into
PARTNER-DOWN state.
9.7. COMMUNICATIONS-INTERRUPTED State 9.7. 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.
skipping to change at page 93, line 9 skipping to change at page 97, line 20
Transition into the NORMAL state. Transition into the NORMAL state.
o partner in RECOVER o partner in RECOVER
Stay in COMMUNICATIONS-INTERRUPTED state. Stay in COMMUNICATIONS-INTERRUPTED state.
o partner in RECOVER-DONE o partner in RECOVER-DONE
Transition into NORMAL state. Transition into NORMAL state.
o partner in PARTNER-DOWN or POTENTIAL-CONFLICT o partner in PARTNER-DOWN, POTENTIAL-CONFLICT, CONFLICT-DONE, or
RESOLUTION-INTERRUPTED
Transition into POTENTIAL-CONFLICT state. Transition into POTENTIAL-CONFLICT state.
o partner in PAUSED o partner in PAUSED
Stay in COMMUNICATIONS-INTERRUPTED state. Stay in COMMUNICATIONS-INTERRUPTED state.
o partner in SHUTDOWN o partner in SHUTDOWN
Transition into PARTNER-DOWN state. Transition into PARTNER-DOWN state.
skipping to change at page 95, line 27 skipping to change at page 99, line 27
9.8.1. Upon entry to POTENTIAL-CONFLICT state 9.8.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. 9.8.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.8.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 NORMAL while in POTENTIAL-CONFLICT state, it MUST transition to a new state.
state. This will cause the primary server to leave POTENTIAL- The primary MUST transition to CONFLICT-DONE state, and the secondary
CONFLICT state prior to the secondary, since the primary sends an MUST transition to NORMAL state. This will cause the primary server
UPDREQ message and receives an UPDDONE before the secondary sends an to leave POTENTIAL-CONFLICT state prior to the secondary, since the
UPDREQ message and receives its UPDDONE message. primary sends an UPDREQ message and receives an UPDDONE before the
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 NORMAL state, it server has transitioned from POTENTIAL-CONFLICT to CONFLICT-DONE
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--------------------> |
| | | |
| <---------------------BNDUPD--< | | <---------------------BNDUPD--< |
skipping to change at page 97, line 41 skipping to change at page 101, line 41
9.9.3. Transitions out of RESOLUTION-INTERRUPTED state 9.9.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. RECOVER-DONE state 9.10. CONFLICT-DONE state
This state indicates that during the process where the two servers
are attempting to re-integrate with each other, the primary server
has received all of the updates from the secondary server. It
transitions into CONFLICT-DONE state in order that it may be totally
responsive to the client load, as opposed to NORMAL state where it
would be in a "balanced" responsive state, running the load balancing
algorithm.
9.10.1. Upon entry to CONFLICT-DONE state
A secondary server should never enter CONFLICT-DONE state.
9.10.2. Operation in CONFLICT-DONE state
A primary server in CONFLICT-DONE state is fully responsive to all
DHCP clients (similar to the situation in COMMUNICATIONS-INTERRUPTED
state).
If communications fails, remain in CONFLICT-DONE state. If communi-
cations becomes OK, remain in CONFLICT-DONE state until the condi-
tions for transition out become satistifed.
9.10.3. Transitions out of CONFLICT-DONE state
If communications fails with the partner while in CONFLICT-DONE
state, then the server will remain in CONFLICT-DONE state.
When a primary server determines that the secondary server has tran-
sitioned into NORMAL state, the primary server will also transition
into NORMAL state.
9.11. RECOVER-DONE state
This state exists to allow an interlocked transition for one server This state exists to allow an interlocked transition for one server
from RECOVER state and another server from PARTNER-DOWN or from RECOVER state and another server from PARTNER-DOWN or
COMMUNICATIONS-INTERRUPTED state into NORMAL state. COMMUNICATIONS-INTERRUPTED state into NORMAL state.
9.10.1. Operation in RECOVER-DONE state 9.11.1. Operation in RECOVER-DONE state
A server in RECOVER-DONE state MUST respond only to A server in RECOVER-DONE state MUST respond only to
DHCPREQUEST/RENEWAL and DHCPREQUEST/REBINDING DHCP messages. DHCPREQUEST/RENEWAL and DHCPREQUEST/REBINDING DHCP messages.
9.10.2. Transitions out of RECOVER-DONE state 9.11.2. Transitions out of RECOVER-DONE state
When a server in RECOVER-DONE state determines that its partner When a server in RECOVER-DONE state determines that its partner
server has entered NORMAL state, then it will transition into NORMAL server has entered NORMAL state, then it will transition into NORMAL
state as well. state as well.
If communications fails while in RECOVER-DONE state, a server will If communications fails while in RECOVER-DONE state, a server will
stay in RECOVER-DONE state. stay in RECOVER-DONE state.
9.11. PAUSED 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.11.1. Upon entry to PAUSED state 9.12.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.11.2. Transitions out of PAUSED state 9.12.2. Transitions out of PAUSED state
A server transitions out of PAUSED state by being restarted. At that A server transitions out of PAUSED state by being restarted. At that
time, the previous state MUST be the state the server was in prior to time, the previous state MUST be the state the server was in prior to
entering the PAUSED state. entering the PAUSED state.
9.12. SHUTDOWN state 9.13. 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 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.
While a server may or may not transition internally into SHUTDOWN While a server may or may not transition internally into SHUTDOWN
state, the 'previous' state determined when it is restarted MUST be 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 the state active prior to the command to shutdown. See section 9.3.2
concerning the use of the previous state upon server restart. concerning the use of the previous state upon server restart.
9.12.1. Upon entry to SHUTDOWN state 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.12.2. Operation in SHUTDOWN state 9.13.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.12.3. Transitions out of SHUTDOWN state 9.13.3. Transitions out of SHUTDOWN state
A server transitions out of SHUTDOWN state by being restarted. A server transitions 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
skipping to change at page 100, line 15 skipping to change at page 104, line 50
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 unat- The more difficult scenario is when the servers are running
tended for extended periods, and in this case an option is provided unattended for extended periods, and in this case an option is pro-
to configure something called a "safe-period" into each server. This vided to configure something called a "safe-period" into each server.
OPTIONAL safe-period is the period after which either the primary or This OPTIONAL safe-period is the period after which either the pri-
secondary server will automatically transition to PARTNER-DOWN from mary or secondary server will automatically transition to PARTNER-
COMMUNICATIONS-INTERRUPTED state. If this transition is completed DOWN from COMMUNICATIONS-INTERRUPTED state. If this transition is
and the partner is not down, then the possibility of duplicate IP completed and the partner is not down, then the possibility of dupli-
address allocations will exist. cate IP 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
skipping to change at page 101, line 44 skipping to change at page 106, line 32
11.1. Simple shared secret 11.1. Simple shared secret
Messages between the failover partners are authenticated through the Messages between the failover partners are authenticated through the
use of a shared secret, which is never sent over the network and must use of a shared secret, which is never sent over the network and must
be known by each server. How each server is told about this shared be known by each server. How each server is told about this shared
secret and secures its storage of the shared secret is outside the secret and secures its storage of the shared secret is outside the
scope of this document. If a server is configured with a shared 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. tion and reject them with reject reason 21: "Missing message digest".
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 a message-digest option as failing authentication with reject
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 as the message-digest option.
See section 12.16. The message-digest contains a one-way 16 octet MD5 See section 12.17. The message-digest contains a one-way 16 octet MD5
[RFC 1321] hash calculated over a stream of octets consisting of the [RFC 1321] hash calculated over a stream of octets consisting of the
entire message concatenated with the shared secret. 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 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 MD5
skipping to change at page 104, line 25 skipping to change at page 109, line 4
Value Binding Status Value Binding Status
----- ------------------------------------------------ ----- ------------------------------------------------
1 FREE Lease is currently available 1 FREE Lease is currently available
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
8 BACKUP-RESERVED Lease belongs to secondary's private address pool
as well as primary's since it is reserved on primary.
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
binding. The client-identifier data is subject to the same binding. The client-identifier data is subject to the same
conventions as DHCP option 81 [RFC 2132]. conventions as DHCP option 81 [RFC 2132].
Code Len Client Identifier Code Len Client Identifier
+-----+-----+-----+-----+----+-----+--- +-----+-----+-----+-----+----+-----+---
| 0 | 4 | 0 | n | i1 | i2 | ... | 0 | 4 | 0 | n | i1 | i2 | ...
skipping to change at page 108, line 21 skipping to change at page 112, line 21
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. See A set of load balancing hash values for the secondary server. A one
section 5.3 for more information on how this option is used. 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
this option is used. This option is only sent from the primary to
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
[LOADB]. [LOADB].
Code Len Hash Buckets Code Len Hash Buckets
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | 11 | 0 | 32 | b1 | b2 | ... | b32 | | 0 | 11 | 0 | 32 | b1 | b2 | ... | b32 |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
12.12. lease-expiration-time 12.12. IP-flags
This option is used to convey the current flags of the assigned-IP-
address option preceding it.
Code Len IP Flags
+-----+-----+-----+-----+-----+-----+
| 0 | 12 | 0 | 1 | f1 | f2 |
+-----+-----+-----+-----+-----+-----+
The IP-flags field is a 16-bit field; two bit positions are
specified here.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|B| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bits (numbered from the least-significant bit in network
byte-order) are used as follows:
0 (R): RESERVED
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
packet.
1 (B): BOOTP
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
allocated due to an interaction with a BOOTP client (as opposed
to a DHCP client).
2-15 : Must be zero
12.13. lease-expiration-time
The lease expiration time is the lease interval that a DHCP server The lease expiration time is the lease interval that a DHCP server
has ACKed to a DHCP client added to the time at which that ACK was has ACKed to a DHCP client added to the time at which that ACK was
transmitted -- expressed as an absolute time (see section 6.2). transmitted -- expressed as an absolute time (see section 6.2).
Code Len Time Code Len Time
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
| 0 | 12 | 0 | 4 | t1 | t2 | t3 | t4 | | 0 | 13 | 0 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
12.13. max-unacked-bndupd 12.14. max-unacked-bndupd
The maximum number of BNDUPD message that this server is prepared to The maximum number of BNDUPD message that this server is prepared to
accept over the TCP connection without causing the TCP connection to accept over the TCP connection without causing the TCP connection to
block. A 32 bit unsigned integer value, in network byte order. block. A 32 bit unsigned integer value, in network byte order.
Code Len Maximum Unacked BNDUPD Code Len Maximum Unacked BNDUPD
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
| 0 | 13 | 0 | 4 | n1 | n2 | n3 | n4 | | 0 | 14 | 0 | 4 | n1 | n2 | n3 | n4 |
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
12.14. MCLT 12.15. MCLT
Maximum Client Lead Time, an interval, in seconds. A 32 bit unsigned Maximum Client Lead Time, an interval, in seconds. A 32 bit unsigned
integer value, in network byte order. integer value, in network byte order.
Code Len Time Code Len Time
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
| 0 | 14 | 0 | 4 | t1 | t2 | t3 | t4 | | 0 | 15 | 0 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
12.15. message 12.16. message
This option is used to supply a human readable message text. It may This option is used to supply a human readable message text. It may
be used in association with the Reject Reason Code to provide a human be used in association with the Reject Reason Code to provide a human
readable error message for the reject. readable error message for the reject.
Code Len Text Code Len Text
+-----+-----+-----+-----+------+-----+-- +-----+-----+-----+-----+------+-----+--
| 0 | 15 | 0 | n | c1 | c2 | ... | 0 | 16 | 0 | n | c1 | c2 | ...
+-----+-----+-----+-----+------+-----+-- +-----+-----+-----+-----+------+-----+--
12.16. 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 last
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.
Code Len Message Digest Code Len Message Digest
+-----+-----+-----+-----+----+-----+----- +-----+-----+-----+-----+----+-----+-----
| 0 | 16 | 0 | n | d1 | d2 | ... | 0 | 17 | 0 | n | d1 | d2 | ...
+-----+-----+-----+-----+----+-----+----- +-----+-----+-----+-----+----+-----+-----
12.17. 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 | 17 | 0 | 4 | t1 | t2 | t3 | t4 | | 0 | 18 | 0 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
12.18. receive-timer 12.19. receive-timer
The number of seconds (an interval) within which the server must The number of seconds (an interval) within which the server must
receive a message from its partner, or it will assume that receive a message from its partner, or it will assume that
communications with the partner is not ok. An unsigned 32 bit communications with the partner is not ok. An unsigned 32 bit
integer in network byte order. integer in network byte order.
Code Len Receive Timer Code Len Receive Timer
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
| 0 | 18 | 0 | 4 | s1 | s2 | s3 | s4 | | 0 | 19 | 0 | 4 | s1 | s2 | s3 | s4 |
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
12.19. protocol-version 12.20. protocol-version
The protocol version being used by the server. It is only sent in the The protocol version being used by the server. It is only sent in the
CONNECT and CONNECTACK messages. The current value for the version CONNECT and CONNECTACK messages. The current value for the version
is 1. is 1.
Code Len Version Code Len Version
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
| 0 | 19 | 0 | 1 | 1 | | 0 | 20 | 0 | 1 | 1 |
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
12.20. reject-reason 12.21. reject-reason
This option is used to selectively reject binding updates. It MAY be This option is used to selectively reject binding updates. It MAY be
used in a BNDACK message or a CONNECTACK message, always associated used in a BNDACK message or a CONNECTACK message, always associated
with an assigned-IP-address option, which contains the IP address of with an assigned-IP-address option, which contains the IP address of
the update being rejected. the update being rejected.
Code Len Reason Code Code Len Reason Code
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
| 0 | 20 | 0 | 1 | R1 | | 0 | 21 | 0 | 1 | R1 |
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
Reason codes : Reason codes (section where referenced in parentheses):
0 Reserved 0 Reserved
1 Illegal IP address (not part of any address pool). 1 Illegal IP address (not part of any address pool). (7.1.3)
2 Fatal conflict exists: address in use by other client. 2 Fatal conflict exists: address in use by other client. (7.1.3)
3 Missing binding information. 3 Missing binding information. (7.1.3)
4 Connection rejected, time mismatch too great. 4 Connection rejected, time mismatch too great. (7.8.2)
5 Connection rejected, invalid MCLT. 5 Connection rejected, invalid MCLT. (7.8.2)
6 Connection rejected, unknown reason. 6 Connection rejected, unknown reason. (not specifically referenced)
7 Connection rejected, duplicate connection. 7 Connection rejected, duplicate connection. (unused)
8 Connection rejected, invalid failover partner. 8 Connection rejected, invalid failover partner. (7.8.2)
9 TLS not supported. 9 TLS not supported. (7.8.2)
10 TLS supported but not configured. 10 TLS supported but not configured. (7.8.2)
11 TLS required but not supported by partner. 11 TLS required but not supported by partner. (7.8.2)
12 Message digest not supported. 12 Message digest not supported. (11.1)
13 Message digest not configured. 13 Message digest not configured. (11.1)
14 Protocol version mismatch. 14 Protocol version mismatch. (7.8.2)
15 Outdated binding information. 15 Outdated binding information. (7.1.3)
16 Less critical binding information. 16 Less critical binding information. (7.1.3)
17 No traffic within sufficient time. 17 No traffic within sufficient time. (8.6)
18 Hash bucket assignment conflict. 18 Hash bucket assignment conflict. (7.8.2)
19-253, reserved. 19 IP not reserved on this server. (7.1.3)
20 Message digest failed to compare. (7.8.2)
21 Missing message digest. (7.1.3)
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.21. sending-server-IP-address 12.22. sending-server-IP-address
The IP address of the server sending this message. This option is The IP address of the server sending this message. This option is
required for all messages if the message digest option used. required for all messages if the message digest option used.
Code Len Address Code Len Address
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
| 0 | 21 | 0 | 4 | a1 | a2 | a3 | a4 | | 0 | 22 | 0 | 4 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
12.22. 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 | 22 | 0 | 1 | flags | | 0 | 23 | 0 | 1 | flags |
+-----+-----+-----+-----+-------+ +-----+-----+-----+-----+-------+
The flags field is an 8-bit field; one bit position is The flags field is an 8-bit field; one bit position is
specified here. specified here.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|S| MBZ | |S| MBZ |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 114, line 5 skipping to change at page 119, line 5
byte-order) are used as follows: byte-order) are used as follows:
0 (S): STARTUP, 0 (S): STARTUP,
Bit 0 MUST be set to 1 whenever the server is in STARTUP state, Bit 0 MUST be set to 1 whenever the server is in STARTUP state,
and set to 0 otherwise. (Note that when in STARTUP state, the and set to 0 otherwise. (Note that when in STARTUP state, the
state transmitted in the server-state option is usually the last state transmitted in the server-state option is usually the last
recorded state from stable storage, but see section 9.3 for recorded state from stable storage, but see section 9.3 for
details.) details.)
1-7 : Must be zero 1-7 : Must be zero
12.23. server-state 12.24. server-state
This option is used to convey the current state of the failover This option is used to convey the current state of the failover
endpoint in the sending server. endpoint in the sending server.
Code Len Server State Code Len Server State
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
| 0 | 23 | 0 | 1 | 1-9 | | 0 | 24 | 0 | 1 | 1-9 |
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
Legal values for this option are: Legal values for this option are:
Value Server State Value Server State
----- ------------------------------------------------------------- ----- -------------------------------------------------------------
0 reserved 0 reserved
1 STARTUP Startup state (1) 1 STARTUP Startup state (1)
2 NORMAL Normal state 2 NORMAL Normal state
3 COMMUNICATIONS-INTERRUPTED Communication interrupted (safe) 3 COMMUNICATIONS-INTERRUPTED Communication interrupted (safe)
4 PARTNER-DOWN Partner down (unsafe mode) 4 PARTNER-DOWN Partner down (unsafe mode)
5 POTENTIAL-CONFLICT Synchronizing 5 POTENTIAL-CONFLICT Synchronizing
6 RECOVER Recovering bindings from partner 6 RECOVER Recovering bindings from partner
7 PAUSED Shutting down for a short period. 7 PAUSED Shutting down for a short period.
8 SHUTDOWN Shutting down for an extended 8 SHUTDOWN Shutting down for an extended
period. period.
9 RECOVER-DONE Interlock state prior to NORMAL 9 RECOVER-DONE Interlock state prior to NORMAL
10 RESOLUTION-INTERRUPTED Comm. failed during resolution 10 RESOLUTION-INTERRUPTED Comm. failed during resolution
11 CONFLICT-DONE Primary has resolved its conflicts
(1) The STARTUP state is never sent to the partner server, it is (1) The STARTUP state is never sent to the partner server, it is
indicated by the STARTUP bit in the server-flags options (see section indicated by the STARTUP bit in the server-flags options (see section
12.22). 12.22).
12.24. start-time-of-state 12.25. start-time-of-state
This option is used for different states in different messages. In a This option is used for different states in different messages. In a
BNDUPD message it represents the start time of the state of the lease BNDUPD message it represents the start time of the state of the lease
in the BNDUPD message. In a STATE message, it represents the start in the BNDUPD message. In a STATE message, it represents the start
time of the partner server's failover state. In all cases it is an time of the partner server's failover state. In all cases it is an
absolute time. absolute time.
Code Len Start Time of State Code Len Start Time of State
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
| 0 | 24 | 0 | 4 | t1 | t2 | t3 | t4 | | 0 | 25 | 0 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
12.25. TLS-reply 12.26. TLS-reply
This option contains information relating to TLS security This option contains information relating to TLS security
negotiation. It is sent in a CONNECTACK message negotiation. It is sent in a CONNECTACK message
A t1 value of 0 indicates no TLS operation, a value of 1 indicates A t1 value of 0 indicates no TLS operation, a value of 1 indicates
that TLS operation is required. that TLS operation is required.
Code Len TLS Code Len TLS
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
| 0 | 25 | 0 | 1 | t1 | | 0 | 26 | 0 | 1 | t1 |
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
12.26. 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 this server. A value of 0
indicates no TLS operation (to communicate the other server MUST NOT indicates no TLS operation (to communicate the other server MUST NOT
require TLS), a value of 1 indicates that TLS operation is desired require TLS), a value of 1 indicates that TLS operation is desired
but not required (to communicate, the other server MAY utilize TLS), but not required (to communicate, the other server MAY utilize TLS),
and a value of 2 indicates that TLS operation is required (to and a value of 2 indicates that TLS operation is required (to
communicate the other server MUST utilize TLS) to establish communicate the other server MUST utilize TLS) to establish
communications with this server. communications with this server.
Code Len TLS Code Len TLS
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
| 0 | 26 | 0 | 1 | t1 | | 0 | 27 | 0 | 1 | t1 |
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
12.27. 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.
Code Len vendor class string Code Len vendor class string
+-----+-----+-----+-----+----+-----+--- +-----+-----+-----+-----+----+-----+---
| 0 | 27 | 0 | n | c1 | c2 | ... | 0 | 28 | 0 | n | c1 | c2 | ...
+-----+-----+-----+-----+----+-----+--- +-----+-----+-----+-----+----+-----+---
12.28. 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.
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 | 28 | 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, and failover reject reason codes). For all of
these number spaces, certain values are defined in this specifica- these number spaces, certain values are defined in this specifica-
tion. New values may only be defined by IETF Consensus, as described tion. New values may only be defined by IETF Consensus, as described
in [RFC 2434]. Basically, this means that they are defined by RFCs in [RFC 2434]. Basically, this means that they are defined by RFCs
approved by the IESG. approved by the IESG.
skipping to change at page 117, line 18 skipping to change at page 122, line 18
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
edited their work into draft format and made other changes in time edited their work into draft format and made other changes in time
for the Summer Chicago IETF meeting. for the Summer Chicago IETF meeting.
Many people have reviewed the various earlier drafts that went into
this result. At American Internet, ideas were contributed by Brad
Parker. At Cisco Systems Paul Fox and Ellen Garvey contributed to
the design of the protocol.
During the summer and fall of 1998, two groups worked on separate During the summer and fall of 1998, two groups worked on separate
implementations of the UDP failover draft. Bernie Volz and Steve implementations of the UDP failover draft. Bernie Volz and Steve
Gonczi constituted one group, and Kim Kinnear, Mark Stapp and Paul Gonczi constituted one group, and Kim Kinnear, Mark Stapp and Paul
Fox made up the other. These two groups worked together to produce Fox made up the other. These two groups worked together to produce
considerable changes and simplifications of the protocol during that considerable changes and simplifications of the protocol during that
period, and Steve Gonczi and Kim Kinnear edited those changes into period, and Steve Gonczi and Kim Kinnear edited those changes into
-03 draft in time for submission to the December 1998 Orlando IETF -03 draft in time for submission to the December 1998 Orlando IETF
meeting. meeting.
In February of 1999 Kim Kinnear and Mark Stapp hosted a meeting on In February of 1999 Kim Kinnear and Mark Stapp hosted a meeting of
people interested in the failover draft. During that meeting a gen- people interested in the failover draft. During that meeting a gen-
eral agreement was reached to recast the failover protocol to use TCP eral agreement was reached to recast the failover protocol to use TCP
instead of UDP. In addition, the group together brainstormed a work- instead of UDP. In addition, the group together brainstormed a work-
able load-balancing technique. Kim Kinnear rewrote the entire draft able load-balancing technique. Kim Kinnear rewrote the entire draft
to include the changes made at that meeting as well as to restructure to include the changes made at that meeting as well as to restructure
the draft along guidelines suggested by Thomas Narten. The result the draft along guidelines suggested by Thomas Narten. The result
was the -04 draft, submitted prior to the Oslo IETF meeting. was the -04 draft, submitted prior to the Oslo IETF meeting.
The initial idea for a hash-based load balancing approach was offered The initial idea for a hash-based load balancing approach was offered
by Ted Lemon, and the determination of an algorithm and its integra- by Ted Lemon, and the determination of an algorithm and its integra-
skipping to change at page 118, line 6 skipping to change at page 123, line 11
perhaps the largest of which was to remove the load balancing perhaps the largest of which was to remove the load balancing
approach into a separate draft. Thanks to all of the many people approach into a separate draft. Thanks to all of the many people
who participated in the conference calls. Changes were made because who participated in the conference calls. Changes were made because
of contributions by: Ted Lemon, David Erdmann, Richard Jones, Rob of contributions by: Ted Lemon, David Erdmann, Richard Jones, Rob
Stevens, Thomas Narten, Diana Lane, and Andre Kostur. Stevens, Thomas Narten, Diana Lane, and Andre Kostur.
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.
This, the -07 draft was edited by Kim Kinnear and was based in part The -07 draft was edited by Kim Kinnear and was based in part on
on reviews by Richard Jones, Bernie Volz, and Steve Gonczi. It embo- reviews by Richard Jones, Bernie Volz, and Steve Gonczi. It embodies
dies several technical updates as well as numerous editorial revi- several technical updates as well as numerous editorial revisions
sions that enhance 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
results of two conference calls held in October and November of 2000.
It includes the correct second port number, a new state to synchron-
ize conflict resolution with load balancing, a generally accepted
approach to secondary pool allocation, and many other updates based
on both operational as well as implementation experience.
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.
Many people have reviewed the various earlier drafts that went into
this result. At American Internet, ideas were contributed by Brad
Parker. At Cisco Systems Paul Fox and Ellen Garvey contributed to
the design of the protocol.
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, [AGENTINFO] Patrick, M., "draft-ietf-dhc-agent-options-11.txt", July,
2000. 2000.
[DDNS] Rekhter, Y., Stapp, M., "draft-ietf-dhc-dhcp-dns-12.txt", [DDNS] Rekhter, Y., Stapp, M., "draft-ietf-dhc-dhcp-dns-12.txt",
March, 2000. March, 2000.
skipping to change at page 119, line 33 skipping to change at page 124, line 41
[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, [USERCLASS] Droms, R., Demirtjis A., Stump, G., Gu, Y., Vyaghrapuri,
R., Beser, B., Privat, J. "draft-ietf-dhc-userclass-08.txt", July, R., Beser, B., Privat, J. "draft-ietf-dhc-userclass-08.txt", July,
2000. 2000.
16. Author's information 16. Author's information
Ralph Droms Ralph Droms
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone: (717) 524-1145
EMail: droms@bucknell.edu
Kim Kinnear Kim Kinnear
Mark Stapp Mark Stapp
Cisco Systems Cisco Systems
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: (978) 244-8000 Phone: (978) 244-8000
EMail: kkinnear@cisco.com EMail: rdroms@cisco.com
kkinnear@cisco.com
mjs@cisco.com mjs@cisco.com
Bernie Volz Bernie Volz
IPWorks, Inc. IPWorks, Inc.
959 Concord St. 959 Concord St.
Framingham, MA 01701 Framingham, MA 01701
Phone: (508) 879-1809 Phone: (508) 879-1809
EMail: volz@ipworks.com EMail: volz@ipworks.com
skipping to change at page 120, line 35 skipping to change at page 125, line 35
Malvern, PA 19355 Malvern, PA 19355
Phone: (800) 208-2747 Phone: (800) 208-2747
EMail: grabil@lucent.com EMail: grabil@lucent.com
mdooley@lucent.com mdooley@lucent.com
akapur@lucent.com akapur@lucent.com
17. Full Copyright Statement 17. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to oth- This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis- assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations, references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
skipping to change at page 121, line 16 skipping to change at line 5656
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT- INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT-
NESS FOR A PARTICULAR PURPOSE. NESS FOR A PARTICULAR PURPOSE.
Open Issues
These issues need to be resolved:
1. Get another port number for connections.
2. Resolve how to handle secondary IP address allocation.
3. Figure out a better way to identify vendors. How about an
SNMP Enterprise MIB value?
4. Need to tie reject-reasons to text of draft, remove obsolete
reject-reasons.
 End of changes. 

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