draft-ietf-dhc-failover-06.txt   draft-ietf-dhc-failover-07.txt 
Network Working Group Ralph Droms Network Working Group Ralph Droms
INTERNET DRAFT Bucknell University INTERNET DRAFT Bucknell University
Kim Kinnear Kim Kinnear
Mark Stapp Mark Stapp
Cisco Systems Cisco Systems
Bernie Volz Bernie Volz
IPWorks
Steve Gonczi Steve Gonczi
Process Software Network Engines
Greg Rabil Greg Rabil
Mike Dooley Mike Dooley
Arun Kapur Arun Kapur
Lucent Technologies Lucent Technologies
March 2000 July 2000
Expires September 2000 Expires January 2001
DHCP Failover Protocol DHCP Failover Protocol
<draft-ietf-dhc-failover-06.txt> <draft-ietf-dhc-failover-07.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 31 skipping to change at page 2, line 35
This document is a substantial reorganization as well as a technical This document is a substantial reorganization as well as a technical
and editorial revision of draft-ietf-dhc-failover-05.txt. and editorial revision of draft-ietf-dhc-failover-05.txt.
Table of Contents Table of Contents
1. Introduction................................................. 4 1. Introduction................................................. 4
2. Terminology.................................................. 5 2. Terminology.................................................. 5
2.1. Requirements terminology................................... 5 2.1. Requirements terminology................................... 5
2.2. DHCP and failover terminology.............................. 5 2.2. DHCP and failover terminology.............................. 5
3. Background and External Requirements......................... 8 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.............. 12
3.5. Using TCP to detect partner server failure................. 13 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............................... 16
5. Protocol Overview............................................ 17 5. Protocol Overview............................................ 17
5.1. Messages and States........................................ 17 5.1. Messages and States........................................ 17
5.2. Fundamental guarantees..................................... 19 5.2. Fundamental guarantees..................................... 20
5.3. Load balancing............................................. 26 5.3. Load balancing............................................. 26
5.4. Operating in NORMAL state.................................. 27 5.4. Operating in NORMAL state.................................. 27
5.5. Operating in COMMUNICATIONS-INTERRUPTED state.............. 27 5.5. Operating in COMMUNICATIONS-INTERRUPTED state.............. 27
5.6. Operating in PARTNER-DOWN state............................ 27 5.6. Operating in PARTNER-DOWN state............................ 28
5.7. Operating in RECOVER state................................. 27 5.7. Operating in RECOVER state................................. 28
5.8. Operating in STARTUP state................................. 28 5.8. Operating in STARTUP state................................. 28
5.9. Time synchronization between servers....................... 28 5.9. Time synchronization between servers....................... 28
5.10. IP address binding-status................................. 29 5.10. IP address binding-status................................. 29
5.11. DNS dynamic update considerations......................... 32 5.11. DNS dynamic update considerations......................... 33
5.12. Reservations and failover................................. 36 5.12. Reservations and failover................................. 37
5.13. Dynamic BOOTP and failover................................ 37 5.13. Dynamic BOOTP and failover................................ 39
5.14. Guidelines for selecting MCLT............................. 38 5.14. Guidelines for selecting MCLT............................. 39
6. Common Message Format........................................ 39 6. Common Message Format........................................ 40
6.1. Message header format...................................... 39 6.1. Message header format...................................... 40
6.2. Common option format....................................... 42 6.2. Common option format....................................... 43
6.3. Batching multiple binding update transactions in one BNDUPD mes- 42 6.3. Batching multiple binding update transactions in one BNDUPD mes- 44
7. Protocol Messages............................................ 44 7. Protocol Messages............................................ 46
7.1. BNDUPD message............................................. 44 7.1. BNDUPD message [3]......................................... 46
7.2. BNDACK message............................................. 54 7.2. BNDACK message [4]......................................... 56
7.3. UPDREQ message............................................. 57 7.3. UPDREQ message [9]......................................... 59
7.4. UPDREQALL message.......................................... 59 7.4. UPDREQALL message [7]...................................... 60
7.5. UPDDONE message............................................ 59 7.5. UPDDONE message [8]........................................ 61
7.6. POOLREQ message............................................ 60 7.6. POOLREQ message [1]........................................ 62
7.7. POOLRESP message........................................... 61 7.7. POOLRESP message [2]....................................... 63
7.8. CONNECT message............................................ 62 7.8. CONNECT message [5]........................................ 64
7.9. CONNECTACK message......................................... 66 7.9. CONNECTACK message [6]..................................... 68
7.10. STATE message............................................. 70 7.10. STATE message [10]........................................ 71
7.11. CONTACT message........................................... 71 7.11. CONTACT message [11]...................................... 72
7.12. DISCONNECT message........................................ 72 7.12. DISCONNECT message [12]................................... 73
8. Connection Management........................................ 73 8. Connection Management........................................ 74
8.1. Connection granularity..................................... 73 8.1. Connection granularity..................................... 74
8.2. Creating the TCP connection................................ 73 8.2. Creating the TCP connection................................ 74
8.3. Using the TCP connection for determining communications status 75 8.3. Using the TCP connection for determining communications status 76
8.4. Using the TCP connection for binding data.................. 77 8.4. Using the TCP connection for binding data.................. 78
8.5. Using the TCP connection for control messages.............. 77 8.5. Using the TCP connection for control messages.............. 78
8.6. Losing the TCP connection.................................. 77 8.6. Losing the TCP connection.................................. 78
9. Failover Endpoint States..................................... 78 9. Failover Endpoint States..................................... 79
9.1. Server Initialization...................................... 78 9.1. Server Initialization...................................... 79
9.2. Server State Transitions................................... 78 9.2. Server State Transitions................................... 79
9.3. STARTUP state.............................................. 81 9.3. STARTUP state.............................................. 82
9.4. PARTNER-DOWN state......................................... 83 9.4. PARTNER-DOWN state......................................... 84
9.5. RECOVER state.............................................. 85 9.5. RECOVER state.............................................. 86
9.6. NORMAL state............................................... 88 9.6. NORMAL state............................................... 89
9.7. COMMUNICATIONS-INTERRUPTED State........................... 90 9.7. COMMUNICATIONS-INTERRUPTED State........................... 91
9.8. POTENTIAL-CONFLICT state................................... 94 9.8. POTENTIAL-CONFLICT state................................... 95
9.9. RESOLUTION-INTERRUPTED state............................... 95 9.9. RESOLUTION-INTERRUPTED state............................... 96
9.10. RECOVER-DONE state........................................ 96 9.10. RECOVER-DONE state........................................ 97
9.11. PAUSED state.............................................. 97 9.11. PAUSED state.............................................. 98
9.12. SHUTDOWN state............................................ 97 9.12. SHUTDOWN state............................................ 98
10. Safe Period................................................. 98 10. Safe Period................................................. 99
11. Security.................................................... 100 11. Security.................................................... 101
11.1. Simple shared secret...................................... 100 11.1. Simple shared secret...................................... 101
11.2. TLS....................................................... 101 11.2. TLS....................................................... 102
12. Failover Options............................................ 102 12. Failover Options............................................ 103
12.1. addresses-transferred..................................... 102 12.1. addresses-transferred..................................... 103
12.2. assigned-IP-address....................................... 102 12.2. assigned-IP-address....................................... 103
12.3. binding-status............................................ 103 12.3. binding-status............................................ 104
12.4. client-identifier......................................... 103 12.4. client-identifier......................................... 104
12.5. client-hardware-address................................... 103 12.5. client-hardware-address................................... 105
12.6. client-last-transaction-time.............................. 104 12.6. client-last-transaction-time.............................. 105
12.7. client-reply-options...................................... 104 12.7. client-reply-options...................................... 105
12.8. client-request-options.................................... 105 12.8. client-request-options.................................... 106
12.9. DDNS...................................................... 106 12.9. DDNS...................................................... 107
12.10. hash-bucket-assignment................................... 107 12.10. delayed-service-parameter................................ 108
12.11. lease-expiration-time.................................... 107 12.11. hash-bucket-assignment................................... 108
12.12. max-unacked-bndupd....................................... 107 12.12. lease-expiration-time.................................... 108
12.13. MCLT..................................................... 108 12.13. max-unacked-bndupd....................................... 109
12.14. message.................................................. 108 12.14. MCLT..................................................... 109
12.15. message-digest........................................... 108 12.15. message.................................................. 109
12.16. potential-expiration-time................................ 109 12.16. message-digest........................................... 110
12.17. receive-timer............................................ 109 12.17. potential-expiration-time................................ 110
12.18. protocol-version......................................... 109 12.18. receive-timer............................................ 110
12.19. reject-reason............................................ 110 12.19. protocol-version......................................... 111
12.20. sending-server-IP-address................................ 111 12.20. reject-reason............................................ 112
12.21. server-flags............................................. 111 12.21. sending-server-IP-address................................ 113
12.22. server-state............................................. 112 12.22. server-flags............................................. 113
12.23. start-time-of-state...................................... 112 12.23. server-state............................................. 114
12.24. TLS-reply................................................ 113 12.24. start-time-of-state...................................... 114
12.25. TLS-request.............................................. 113 12.25. TLS-reply................................................ 115
12.26. vendor-class-identifier.................................. 113 12.26. TLS-request.............................................. 115
12.27. vendor-specific-options.................................. 114 12.27. vendor-class-identifier.................................. 115
13. IANA Considerations......................................... 114 12.28. vendor-specific-options.................................. 116
14. Acknowledgments............................................. 114 13. IANA Considerations......................................... 116
15. References.................................................. 116 14. Acknowledgments............................................. 116
16. Author's information........................................ 117 15. References.................................................. 118
17. Full Copyright Statement.................................... 118 16. Author's information........................................ 119
17. Full Copyright Statement.................................... 120
1. Introduction 1. Introduction
DHCP [RFC 2131] allows for multiple servers to be operating on a sin- DHCP [RFC 2131] allows for multiple servers to be operating on a sin-
gle network. Some sites are interested in running multiple servers gle network. Some sites are interested in running multiple servers
in such a way so as to provide redundancy in case of server failure in such a way so as to provide redundancy in case of server failure
since the DHCP subsystem is in many cases a critical part of the net- since the DHCP subsystem is in many cases a critical part of the net-
work infrastructure. work infrastructure.
This document defines a protocol to provide synchronization between This document defines a protocol to provide synchronization between
two servers in order that each can take over for the other should two servers in order that each can take over for the other should
either one fail or become unreachable. either one fail or become unreachable.
One server is designated the "primary" server, the other is the One server is designated the "primary" server, the other is the
"secondary" server, and all DHCP client requests are sent to each "secondary" server, and most DHCP client requests are sent to each
server. server (see Section 3.1.1 for details).
In order to provide a high availability DHCP service, these In order to provide a high availability DHCP service, these
cooperating primary and secondary servers must maintain a consistent cooperating primary and secondary servers must maintain a consistent
database of lease information. This implies that servers will need database of lease information. This implies that servers will need
to coordinate all lease activity so that this information is syn- to coordinate all lease activity so that this information is syn-
chronized in case failover is required. The protocol messages and chronized in case failover is required. The protocol messages and
processing techniques required to maintain a consistent database are processing techniques required to maintain a consistent database are
specified in the protocol described here. specified in the protocol described here.
The failover protocol also contains a way to integrate the DHCP load- The failover protocol also contains a way to integrate the DHCP load-
skipping to change at page 8, line 36 skipping to change at page 8, line 41
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 address which is associ- A subnet address pool is the set of IP addresses which is asso-
ated with a particular network number and subnet mask. In the ciated with a particular network number and subnet mask. In the
simple case, there is a single network number and subnet mask simple case, there is a single network number and subnet mask
and a set of IP addresses. In the more complex case (sometimes and a set of IP addresses. In the more complex case (sometimes
called "secondary subnets", sometimes "superscopes"), several called "secondary subnets", sometimes "superscopes"), several
(apparently unrelated) network number and subnet mask combina- (apparently unrelated) network number and subnet mask combina-
tions with their associated IP addresses may all be configured tions with their associated IP addresses may all be configured
together into one subnet address pool. 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 tructure, and some general issues surrounding server failure detec-
detection. Some failure scenarios that provide particular challenges tion. Some failure scenarios that provide particular challenges to a
to a failover protocol are discussed. Finally, the challenges failover protocol are discussed. Finally, the challenges inherent in
inherent in using a TCP connection as a means to detect failure of a using a TCP connection as a means to detect failure of a partner
partner server are elaborated. server are elaborated.
3.1. Key aspects of the DHCP protocol 3.1. Key aspects of the DHCP protocol
The failover protocol is designed to augment the DHCP protocol as The failover protocol is designed to augment the DHCP protocol as
described in RFC 2131 [RFC 2131]. There are several key aspects of described in RFC 2131 [RFC 2131]. There are several key aspects of
the DHCP protocol which are required by the failover protocol in the DHCP protocol which are required by the failover protocol in
order to successfully meet its design goals. order to successfully meet its design goals.
3.1.1. Broadcast behavior 3.1.1. Broadcast behavior
skipping to change at page 10, line 51 skipping to change at page 11, line 9
At present, the failover protocol does not assume that a client send- At present, the failover protocol does not assume that a client send-
ing in an INIT-REBOOT request necessarily has a valid lease on the IP ing in an INIT-REBOOT request necessarily has a valid lease on the IP
address appearing in the dhcp-requested-address option in the INIT- address appearing in the dhcp-requested-address option in the INIT-
REBOOT request. REBOOT request.
The implications of this are as follows: Assume that there is a DHCP The implications of this are as follows: Assume that there is a DHCP
client that gets a lease from one server while that server is unable client that gets a lease from one server while that server is unable
to communicate with its failover partner. Then, assume that after to communicate with its failover partner. Then, assume that after
that client reboots it is able only to communicate with the other that client reboots it is able only to communicate with the other
failover server. If the failover servers have not been able to failover server. If the failover servers have not been able to com-
communicate with each other during this process, then the DHCP client municate with each other during this process, then the DHCP client
will get a new IP address instead of being able to continue to use will get a new IP address instead of being able to continue to use
its existing IP address. This will affect no applications on the DHCP its existing IP address. This will affect no applications on the DHCP
client, since it is rebooting. However, it will use up an additional client, since it is rebooting. However, it will use up an additional
IP address in this marginal case. IP address in this marginal case.
3.1.3. Stable storage update before DHCPACK 3.1.3. Stable storage update before DHCPACK
The DHCP protocol allocates resources, and in order to operate The DHCP protocol allocates resources, and in order to operate
correctly it requires that a DHCP server update some form of stable correctly it requires that a DHCP server update some form of stable
storage prior to sending a DHCPACK to a DHCP client in order to grant storage prior to sending a DHCPACK to a DHCP client in order to grant
that client a lease on an IP address. that client a lease on an IP address.
One of the goals of the failover protocol is that it not add signifi- One of the goals of the failover protocol is that it not add signifi-
cant additional time to this already time consuming requirement to cant additional time to this already time consuming requirement to
update stable storage prior to a DHCPACK. In particular, adding a update stable storage prior to a DHCPACK. In particular, adding a
requirement to communicate with another server prior to sending a requirement to communicate with another server prior to sending a
DHCPACK would greatly simplify the failover protocol, but it would DHCPACK would greatly simplify the failover protocol, but it would
limit the potential scalability of any DHCP server which employed the unacceptably limit the potential scalability of any DHCP server which
failover protocol in an unacceptable manner. employed the failover protocol.
3.2. BOOTP relay agent implementation 3.2. BOOTP relay agent implementation
Many DHCP clients are not resident on the same network segment as a Many DHCP clients are not resident on the same network segment as a
DHCP server. In order to support this form of network architecture, DHCP server. In order to support this form of network architecture,
most contemporary routers implement something known as a BOOTP Relay most contemporary routers implement something known as a BOOTP Relay
Agent. This capability inside of a router listens for all broadcasts Agent. This capability inside of a router listens for all broadcasts
at the DHCP port, port 67, and will relay any broadcasts that it at the DHCP port, port 67, and will relay any broadcasts that it
receives on to a DHCP server. The IP address of the DHCP server must receives on to a DHCP server. The IP address of the DHCP server must
have been previously configured into the router. As part of the have been previously configured into the router. As part of the
skipping to change at page 15, line 15 skipping to change at page 15, line 21
The conclusion drawn from this analysis is that TCP provides very The conclusion drawn from this analysis is that TCP provides very
useful support for the failover protocol in the areas of reliable and useful support for the failover protocol in the areas of reliable and
ordered message delivery, but cannot by itself be relied upon to ordered message delivery, but cannot by itself be relied upon to
detect partner server failure in a fashion acceptable to the needs of detect partner server failure in a fashion acceptable to the needs of
the failover protocol. Additional failover protocol capabilities the failover protocol. Additional failover protocol capabilities
have been created to support timely detection of partner server have been created to support timely detection of partner server
failure. See section 8.3 for details on this mechanism. failure. See section 8.3 for details on this mechanism.
4. Design Goals 4. Design Goals
This section lists the the design goals and the limitations of the This section lists the design goals and the limitations of the fail-
failover protocol. over protocol.
4.1. Design goals for this protocol 4.1. Design goals for this protocol
The following list of goals that are met by this protocol. They are The following is a list of goals that are met by this protocol. They
listed in priority order. are listed in priority order.
1. Implementations of this protocol must work with existing DHCP 1. Implementations of this protocol must work with existing DHCP
client implementations based on the DHCP protocol [1]. client implementations based on the DHCP protocol [1].
2. Implementations of the protocol must work with existing BOOTP 2. Implementations of the protocol must work with existing BOOTP
relay agent implementations. relay agent implementations.
3. The protocol must provide failover redundancy between servers 3. The protocol must provide failover redundancy between servers
that are not located on the same subnet. that are not located on the same subnet.
skipping to change at page 16, line 29 skipping to change at page 16, line 36
whichever server that originally offered it the binding. whichever server that originally offered it the binding.
13. Ensure that a new client can get an IP address from some 13. Ensure that a new client can get an IP address from some
server. Ensure that in the face of partition, where servers server. Ensure that in the face of partition, where servers
continue to run but cannot communicate with each other, the continue to run but cannot communicate with each other, the
above goals and requirements may be met. In addition, when above goals and requirements may be met. In addition, when
the partition condition is removed, allow graceful automatic the partition condition is removed, allow graceful automatic
re-integration without requiring human intervention. re-integration without requiring human intervention.
14. If either primary or secondary server loses all of the infor- 14. If either primary or secondary server loses all of the infor-
mation that is has stored in stable storage, ensure that it be mation that it has stored in stable storage, ensure that it be
able to refresh its stable storage from the other server. able to refresh its stable storage from the other server.
15. Support load balancing between the primary and secondary 15. Support load balancing between the primary and secondary
servers, and allow configuration of the percentage of the servers, and allow configuration of the percentage of the
client population served by each with a moderately fine granu- client population served by each with a moderately fine granu-
larity. larity.
4.2. Limitations of this protocol 4.2. Limitations of this protocol
The following are explicit limitations of this protocol. The following are explicit limitations of this protocol.
skipping to change at page 17, line 4 skipping to change at page 17, line 12
1. This protocol provides only one level of redundancy through a 1. This protocol provides only one level of redundancy through a
single secondary server for each primary server. single secondary server for each primary server.
2. A subset of the address pool is reserved for secondary server 2. A subset of the address pool is reserved for secondary server
use. In order to handle the failure case where both servers use. In order to handle the failure case where both servers
are able to communicate with DHCP clients, but unable to com- are able to communicate with DHCP clients, but unable to com-
municate with each other, a subset of the IP address pool must municate with each other, a subset of the IP address pool must
be set aside as a private address pool for the secondary be set aside as a private address pool for the secondary
server. The secondary can use these to service newly arrived server. The secondary can use these to service newly arrived
DHCP clients during such a period. The required size of this DHCP clients during such a period. The required size of this
private pool is be based only on the arrival rate of new DHCP private pool is based only on the arrival rate of new DHCP
clients and the length of expected downtime, and is not influ- clients and the length of expected downtime, and is not influ-
enced in any way by the total number of DHCP clients supported enced in any way by the total number of DHCP clients supported
by the server pair. by the server pair.
The failover protocol can be used in a mode where both the The failover protocol can be used in a mode where both the
primary and secondary servers can share the load between them primary and secondary servers can share the load between them
when both are operating. In this load balancing mode, the when both are operating. In this load balancing mode, the
addresses allocated by the primary server to the secondary addresses allocated by the primary server to the secondary
server are not unused, but are used instead to service the server are not unused, but are used instead to service the
portion of the client base to which the secondary server is portion of the client base to which the secondary server is
skipping to change at page 22, line 32 skipping to change at page 22, line 38
ing the times that the server MUST record in its stable storage and ing the times that the server MUST record in its stable storage and
the way that they interact with the lease time that may be offered to the way that they interact with the lease time that may be offered to
a DHCP client. a DHCP client.
Again, the fundamental relationship among these times which MUST be Again, the fundamental relationship among these times which MUST be
maintained is: maintained is:
actual lease interval < actual lease interval <
( acknowledged potential lease interval + MCLT ) ( acknowledged potential lease interval + MCLT )
Figure 5.2.1-1 illustrates a initial lease to a client using the Figure 5.2.1-1 illustrates an initial lease to a client using the
rules discussed in the example which follows it. Note that this is rules discussed in the example which follows it. Note that this is
only one example -- as long as the fundamental relationship is only one example -- as long as the fundamental relationship is
preserved, the actual times used could be quite different. preserved, the actual times used could be quite different.
DHCP Primary Secondary DHCP Primary Secondary
time Client Server Server time Client Server Server
| (time in intervals) | (absolute time) | | (time in intervals) | (absolute time) |
| | | | | |
| >-DHCPDISCOVER-> | | | >-DHCPDISCOVER-> | |
skipping to change at page 27, line 6 skipping to change at page 27, line 6
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 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.10. 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. 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. 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, then a BNDUPD message is sent with the contents of that storage (other than a change resulting from receiving a BNDUPD from
change to the partner server. The partner server then writes the the failover partner), then a BNDUPD message is sent with the con-
information about that binding in its bindings database in stable tents of that change to the partner server. The partner server then
storage and replies with a BNDACK message. writes the information about that binding in its bindings database in
stable storage and replies with a BNDACK message.
The binding database in a DHCP server would normally be changed as a
result of DHCP protocol activity with a DHCP client (e.g., granting
a lease to a DHCP client through the familiar
DISCOVER/OFFER/REQUEST/ACK cycle or extending a lease due to a
renewal from a DHCP client) or possibly (on some servers) because a
lease has expired or undergone another state change that must be
recorded in the DHCP binding database. These are the state changes
that would be communicated to the partner server using a BNDUPD mes-
sage. Of course, receipt of a BNDUPD message itself will normally
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
MUST NOT trigger a corresponding BNDUPD message to the partner.
5.5. Operating in COMMUNICATIONS-INTERRUPTED state 5.5. 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
skipping to change at page 29, line 34 skipping to change at page 29, line 46
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 proto-
col are: col are listed below. Unless otherwise noted below, there MAY be
client information associated with each of these binding-status
o FREE values.
IP address may be allocated by the primary to any DHCP client.
When the MCLT has passed after its time of entry into PARTNER-
DOWN state, the IP address may be allocated by the secondary to
any DHCP client.
o ACTIVE
Lease is assigned to a client. A client MUST appear. o
o ACTIVE -- Lease is assigned to a client. Client identification
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 to 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 if a BNDUPD has server. It may be allocated to the same client on the server
not yet been sent to the partner. A client SHOULD appear. 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
the servers are not in communication). Client identification
SHOULD appear.
o RELEASED -- indicates that a DHCP client sent in a DHCPRELEASE o RELEASED -- indicates that a DHCP client sent in a DHCPRELEASE
message. When the partner server ACK's the BNDUPD of an message. When the partner server ACK's the BNDUPD of an
RELEASED IP address, the server sets its internal state to FREE, RELEASED IP address, the server sets its internal state to FREE,
and it is available for allocation by the primary server to any and it is available for allocation by the primary server to any
DHCP client. It may be allocated to the same client if a BNDUPD DHCP client. It may be allocated to the same client if a BNDUPD
has not yet been sent to the partner. A client SHOULD appear. has not yet been sent to the partner. Client identification
SHOULD appear.
o FREE -- is used when a DHCP server needs to communicate that an o FREE -- is used when a DHCP server needs to communicate that an
IP address is unused by any DHCP client, but it was not just IP address is unused by any DHCP client, but it was not just
released, expired, or reset by a network administrator. When released, expired, or reset by a network administrator. When
the partner server ACK's the BNDUPD of an FREE IP address, the the partner server ACK's the BNDUPD of a FREE IP address, the
server sets its internal state such that it is available for server sets its internal state such that it is available for
allocation by the primary DHCP server to any DHCP client. (Note allocation by the primary DHCP server to any DHCP client. (Note
that in PARTNER-DOWN state, after waiting the MCLT, the IP that in PARTNER-DOWN state, after waiting the MCLT, the IP
address MAY be allocated to a DHCP client by the secondary address MAY be allocated to a DHCP client by the secondary
server.) A client MAY appear. server.)
Note that when an IP address that was allocated by the secondary
reverts to the FREE state, it must (like any other IP address)
be assigned to the secondary through the POOLREQ/BNDUPD process
before the secondary can reallocate it.
Client identification MAY appear.
o ABANDONED -- indicates that an IP address is considered unusable o ABANDONED -- indicates that an IP address is considered unusable
by the DHCP subsystem. An IP address for which a valid PING by the DHCP subsystem. An IP address for which a valid PING
response was received SHOULD be set to ABANDONED. An IP address response was received SHOULD be set to ABANDONED. An IP address
for which a DHCPDECLINE was received should be set to ABANDONED. for which a DHCPDECLINE was received should be set to ABANDONED.
A client MUST NOT appear. Client identification MUST NOT appear.
o RESET -- indicates that this IP address was made available by o RESET -- indicates that this IP address was made available by
operator command. A client MAY appear. operator command. This is a distinct state so that the reason
that the IP address became FREE can be determined. Client iden-
tification MAY appear.
o BACKUP -- indicates that this IP address can be allocated by the o BACKUP -- indicates that this IP address can be allocated by the
secondary server to a DHCP client at any time. When the MCLT has secondary server to a DHCP client at any time. When the MCLT has
passed after its time of entry into PARTNER-DOWN state, the IP passed after its time of entry into PARTNER-DOWN state, the IP
address may be allocated by the primary to any DHCP client. A address may be allocated by the primary to any DHCP client.
client MAY appear. Client identification MAY appear.
These binding-status values are communicated from one failover These binding-status values are communicated from one failover
partner to another using the binding-status option, see section 12.3 partner to another using the binding-status option, see section 12.3
for details of this option. Unless otherwise noted above there MAY for details of this option. Unless otherwise noted above there MAY
be client information associated with each of these binding-status be client information associated with each of these binding-status
values. values.
An IP address will move between these binding-status values using the An IP address will move between these binding-status values using the
following state transition diagram: following state transition diagram:
skipping to change at page 31, line 19 skipping to change at page 32, line 19
External >---->| RESET | | |ABANDONED| External >---->| RESET | | |ABANDONED|
command | | +-->| | command | | +-->| |
+----------+ +---------+ +----------+ +---------+
| |
Comm w/Parter(1) Comm w/Parter(1)
V V
+---------+ Comm(1) +----------+ Comm(1) +---------+ +---------+ Comm(1) +----------+ Comm(1) +---------+
| EXPIRED |--------->| FREE |<----------| RELEASED| | EXPIRED |--------->| FREE |<----------| RELEASED|
| | w/Parter | | w/Partner | | | | w/Parter | | w/Partner | |
+---------+ +----------+ +---------+ +---------+ +----------+ +---------+
^ ^ | | ^ ^ ^ | | +-----------+ ^
| Exp. grace IP address IP addr alloc. | | | | | | |
| period ends leased by to secondary(2) | | Exp. grace IP | IP addr alloc. IP addr |
| | primary V | | period ends address to sec.(2) reserved |
| | | +----------+ | | | leasedy V V |
| | | | BACKUP | | | | by | +----------+ +---------+ |
| wait for | | | | | | primary| BACKUP | | BACKUP- | |
| grace period | +----------+ | | wait for | | | | RESERVED| |
| 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.
(1) This transition MAY also occur if the server is in (1) This transition MAY also occur if the server is in
PARTNER-DOWN state and the MCLT has passed since the entry PARTNER-DOWN state and the MCLT has passed since the entry
in the RELEASED, EXPIRED, or RESET states. in the RELEASED, EXPIRED, or RESET states.
(2) This transition MAY occur if the server is the secondary (2) This transition MAY occur if the server is the secondary
and the MCLT has passed since its entry into PARTNER-DOWN state. and the MCLT has passed since its entry into PARTNER-DOWN state.
Again, note that a DHCP server implementing the failover protocol Again, note that a DHCP server implementing the failover protocol
does not have to implement either this state machine or use these does not have to implement either this state machine or use these
particular binding-status values in its normal operation of particular binding-status values in its normal operation of allocat-
allocating IP addresses to DHCP clients. It only needs to map its ing IP addresses to DHCP clients. It only needs to map its internal
internal binding-status-values onto these "standard" binding-status binding-status-values onto these "standard" binding-status values,
values, and map these "standard" binding-status values back into its and map these "standard" binding-status values back into its internal
internal binding-status values. For example, a server which imple- binding-status values. For example, a server which implements a
ments a grace period for a IP address binding SHOULD simply wait to grace period for a IP address binding SHOULD simply wait to update
update its partner server until the grace period on that binding has its partner server until the grace period on that binding has run
run out. out.
The process of setting an IP address to FREE deserves some detailed The process of setting an IP address to FREE deserves some detailed
discussion. When an IP address is moved to the EXPIRED,RELEASED, or discussion. When an IP address is moved to the EXPIRED,RELEASED, or
RESET binding-status on a server, it will send a BNDUPD with the RESET binding-status on a server, it will send a BNDUPD with the
binding-status of EXPIRED, RELEASED, or RESET to its partner. If its binding-status of EXPIRED, RELEASED, or RESET to its partner. If its
partner agrees that is acceptable (see sections 7.1.2 and 7.1.3 con- partner agrees that is acceptable (see sections 7.1.2 and 7.1.3 con-
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
skipping to change at page 33, line 5 skipping to change at page 34, line 5
DHCP failover protocol must also support DDNS updates. The purpose DHCP failover protocol must also support DDNS updates. The purpose
of this discussion is to clarify the areas where the DHCP failover of this discussion is to clarify the areas where the DHCP failover
and DHCP-DDNS protocols intersect for the benefit of implementations and DHCP-DDNS protocols intersect for the benefit of implementations
which support both protocols, not to introduce a new requirement into which support both protocols, not to introduce a new requirement into
the DHCP failover protocol. Thus, a DHCP server which implements the the DHCP failover protocol. Thus, a DHCP server which implements the
failover protocol MAY also support dynamic DNS updates, but if it failover protocol MAY also support dynamic DNS updates, but if it
does support dynamic DNS updates it SHOULD utilize the techniques does support dynamic DNS updates it SHOULD utilize the techniques
described here in order to correctly distribute them between the described here in order to correctly distribute them between the
failover partners. failover partners.
From the standpoint of the failover protocol, there is no reason why
a server which is utilizing the DDNS protocol to update a DNS server
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
to support DDNS or is not configured to support DDNS SHOULD output a
warning message when it receives BNDUPD messages which indicate that
its failover partner is configured to support the DDNS protocol to
update a DNS server. An implementation MAY consider this an error
and refuse to operate, or it MAY choose to operate anyway, having
warned the user of the problem in some way.
5.11.1. Relationship between failover and dynamic DNS update 5.11.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
skipping to change at page 36, line 45 skipping to change at page 38, line 8
5.12. Reservations and failover 5.12. 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 server serving the same sub- In a situation where there are two DHCP servers serving the same sub-
net without using failover, the two DHCP server's need to have dis- net without using failover, the two DHCP server's need to have dis-
joint IP address pools, but identical reservations for the DHCP joint IP address pools, but identical reservations for the DHCP
clients. clients.
In a failover context, both servers need to be configured with the In a failover context, both servers need to be configured with the
proper reservations in an identical manner, but if we stop there proper reservations in an identical manner, but if we stop there
problems can occur around the edge conditions where reservations are problems can occur around the edge conditions where reservations are
made for an IP address that has already been leased to a different made for an IP address that has already been leased to a different
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, in order that the secondary server be able to allocate it as BACKUP-RESERVED, in order that the secondary server be able to
as well. allocate it as well.
Note that this implies that a reserved IP address goes through the
normal state changes from FREE to ACTIVE (and possibly back to FREE).
The failover protcol supports this approach to reservations, i.e.,
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
reserved. Other approaches to the support of reservations exist in
some DHCP server implementations (e.g., where the IP address is
apparently leased to a particular client forever, without any expira-
tion). The goal is for the failover protocol to support any of the
usual approaches to reservations, both those that allow an IP address
to go through different states when reserved, and those that don't.
From the above, it follows that a reservation soley on the secondary
will not necessarily allow the secondary to offer that address to
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
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.13. 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
skipping to change at page 39, line 15 skipping to change at page 40, line 40
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
message message all use a two byte option number and two byte length format.
All failover protocol messages are sent over the TCP connection All failover protocol messages are sent over the TCP connection
between failover endpoints and encoded using a message format between failover endpoints and encoded using a message format
specific to the failover protocol. specific to the failover protocol.
There exists a common message format for all failover messages, which There exists a common message format for all failover messages, which
utilizes the options in a way similar to the DHCP protocol. For each utilizes the options in a way similar to the DHCP protocol. For each
message type, some options are required and some are optional. In message type, some options are required and some are optional. In
addition, when a message is received any options that are not under- addition, when a message is received any options that are not under-
stood by the receiving server MUST be ignored. stood by the receiving server MUST be ignored.
skipping to change at page 41, line 36 skipping to change at page 43, line 25
the XID value is meaningless, but MUST be supplied. The XID value is the XID value is meaningless, but MUST be supplied. The XID value is
used solely by the receiver of a response message to determine the used solely by the receiver of a response message to determine the
corresponding request message. corresponding request message.
Requests messages where the XID is used in the corresponding response Requests messages where the XID is used in the corresponding response
messages are: POOLREQ, BNDUPD, CONNECT, UPDREQALL, and UPDREQ. The messages are: POOLREQ, BNDUPD, CONNECT, UPDREQALL, and UPDREQ. The
corresponding response messages are POOLRESP, BNDACK, CONNECTACK, corresponding response messages are POOLRESP, BNDACK, CONNECTACK,
UPDDONE, and UPDDONE, respectively. UPDDONE, and UPDDONE, respectively.
As requests/responses don't survive connection reestablishment, XIDs As requests/responses don't survive connection reestablishment, XIDs
only need only need to be unique during a specific connection.
payload data - variable length payload data - variable length
The options are placed after the header, after skipping payload The options are placed after the header, after skipping payload
offset bytes from beginning of the message. The payload data options offset bytes from beginning of the message. The payload data options
are not preceded by a "cookie" value. are not preceded by a "cookie" value.
The payload data is formatted as DHCP style options using two byte The payload data is formatted as DHCP style options using two byte
option codes and two byte option lengths. The option codes are in a option codes and two byte option lengths. The option codes are in a
namespace which is unique to the failover protocol. namespace which is unique to the failover protocol.
skipping to change at page 43, line 30 skipping to change at page 45, line 18
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 binding-status option and others as at least the 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 binding-status option and others as at least the binding-status option and others as
required. required.
... ...
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
exactly exactly the same assigned-IP-address options as does its exactly the same assigned-IP-address options as does its correspond-
corresponding BNDUPD message. The order of the assigned-IP-address ing BNDUPD message. The order of the assigned-IP-address options
options MAY, however, be different. MAY, however, be different. Here is a schematic representation of a
BNDACK:
Non-IP Address/Non-client specific options first
assigned-IP-address option for the first IP address
If rejected, reject-reason option and message option.
assigned-IP-address option for the second IP address
If rejected, reject-reason option and message option.
...
Trailing options (message digest).
In case the server chooses to reject some or all of the IP address In case the server chooses to reject some or all of the IP address
binding information in a BNDUPD message in a BNDACK reply, the BNDACK binding information in a BNDUPD message in a BNDACK reply, the BNDACK
message MUST contain a reject-reason option following every message MUST contain a reject-reason option following every
assigned-IP-address option in order to indicate that the binding assigned-IP-address option in order to indicate that the binding
update transaction for that IP address was not accepted and why. As update transaction for that IP address was not accepted and why. As
with a BNDACK message containing a single binding update transaction, with a BNDACK message containing a single binding update transaction,
an assigned-IP-address option without any associated reject-reason an assigned-IP-address option without any associated reject-reason
option indicates a successful binding update transaction. option indicates a successful binding update transaction.
7. Protocol Messages 7. Protocol Messages
This section contains the detailed definition of the protocol mes- This section contains the detailed definition of the protocol mes-
sages, including the information to include when sending the message, sages, including the information to include when sending the message,
as well as the actions to take upon receiving the message. as well as the actions to take upon receiving the message. The mes-
sage type for each message appears as [n] in the heading for the mes-
sage (see section 6.1).
7.1. BNDUPD message 7.1. BNDUPD message [3]
The binding update (BNDUPD) message is used to send the binding data- The binding update (BNDUPD) message is used to send the binding data-
base changes (known as binding update transactions) to the partner base changes (known as binding update transactions) to the partner
server, and the partner server responds with a binding acknowledge- server, and the partner server responds with a binding acknowledge-
ment (BNDACK) message when it has successfully committed those ment (BNDACK) message when it has successfully committed those
changes to its own stable storage. changes to its own stable storage.
The rest of the failover protocol exists to determine whether the The rest of the failover protocol exists to determine whether the
partner server is able to communicate or not, and to enable the partner server is able to communicate or not, and to enable the
partners to exchange BNDUPD/BNDACK messages in order to keep their partners to exchange BNDUPD/BNDACK messages in order to keep their
skipping to change at page 44, line 34 skipping to change at page 46, line 36
The rest of this section is written as though every BNDUPD message The rest of this section is written as though every BNDUPD message
contains only a single binding update transaction in order to reduce contains only a single binding update transaction in order to reduce
the complexity of the discussion. See section 6.3 for information on the complexity of the discussion. See section 6.3 for information on
how to create and process BNDUPD and BNDACK messages which contain how to create and process BNDUPD and BNDACK messages which contain
multiple binding update transactions. Note that while a server MAY multiple binding update transactions. Note that while a server MAY
generate BNDUPD messages with multiple binding update transactions, generate BNDUPD messages with multiple binding update transactions,
every server MUST be able to process a BNDUPD message which contains every server MUST be able to process a BNDUPD message which contains
multiple binding update transactions and generate the corresponding multiple binding update transactions and generate the corresponding
BNDACK messages with status for multiple binding update transactions. BNDACK messages with status for multiple binding update transactions.
The message type for the BNDUPD message is 3.
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 MUST MUST MUST MUST assigned-IP-address (3) MUST MUST MUST MUST
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) Only SHOULD appear if server supports dynamic DNS. (1) MUST if server is performing dynamic DNS for this IP address, else
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
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
skipping to change at page 46, line 48 skipping to change at page 49, line 5
a value beyond that of the lease-expiration time. This is the a value beyond that of the lease-expiration time. This is the
value that is ACKed by the BNDACK message. A server sending a value that is ACKed by the BNDACK message. A server sending a
BNDUPD message MUST be able to recover the potential- BNDUPD message MUST be able to recover the potential-
expiration-time sent in every BNDUPD, not just those that expiration-time sent in every BNDUPD, not just those that
receive a corresponding BNDACK, in order to be able to protect receive a corresponding BNDACK, in order to be able to protect
against possible duplicate allocation of IP addresses after against possible duplicate allocation of IP addresses after
transitioning to PARTNER-DOWN state. See section 5.2.1 for transitioning to PARTNER-DOWN state. See section 5.2.1 for
details as to why the potential-expiration-time exists and details as to why the potential-expiration-time exists and
guidelines for how to decide on the value. guidelines for how to decide on the value.
The following option information is applies to all BNDUPD messages, The following option information applies to all BNDUPD messages,
regardless of the value of the binding-status, unless otherwise regardless of the value of the binding-status, unless otherwise
noted. noted.
o Identifying the client o Identifying the client
For many of the binding-status values a client MUST appear while For many of the binding-status values a client MUST appear while
for others a client MAY appear, and for some a client MUST NOT for others a client MAY appear, and for some a client MUST NOT
appear. appear.
A client is identified in a BNDUPD message by at least one and pos- A client is identified in a BNDUPD message by at least one and pos-
sibly two options. The client-hardware-address option MUST appear sibly two options. The client-hardware-address option MUST appear
any time that a client appears in a BNDUPD message, and contains any time that a client appears in a BNDUPD message, and contains
the hardware type and chaddr information from the DHCP request the hardware type and chaddr information from the DHCP request
packet. A failover client-identifier option MUST appear any time packet. A failover client-identifier option MUST appear any time
that a client appears in a BNDUPD message if and only if that that a client appears in a BNDUPD message if and only if that
client used a DHCP client-identifier option when communicating with client used a DHCP client-identifier option when communicating with
the DHCP server. See section 12.7 and 12.8 for details of how to the DHCP server. See section 12.5 and 12.4 for details of how to
construct these two options from a DHCP request packet. construct these two options from a DHCP request packet.
o start-time-of-state o start-time-of-state
The start-time-of-state SHOULD appear. It is set to the time at The start-time-of-state SHOULD appear. It is set to the time at
which this IP address first took on the state that corresponds to which this IP address first took on the state that corresponds to
the current value of binding-status. the current value of binding-status.
o last-transaction-time o last-transaction-time
skipping to change at page 47, line 42 skipping to change at page 49, line 44
which this DHCP server last received a packet from the DHCP client which this DHCP server last received a packet from the DHCP client
referenced by the client-identifier or client-hardware-address that referenced by the client-identifier or client-hardware-address that
was associated with the IP address referenced by the assigned-IP- was associated with the IP address referenced by the assigned-IP-
address. address.
o DDNS o DDNS
If the DHCP server is performing dynamic DNS operations on behalf If the DHCP server is performing dynamic DNS operations on behalf
of the DHCP client represented by the client-identifier or client- of the DHCP client represented by the client-identifier or client-
hardware-address, then it should include a DDNS option containing hardware-address, then it should include a DDNS option containing
the host name, domain name, and status of any dynamic DNS opera- the domain name and status of any dynamic DNS operations enabled.
tions enabled.
o client-request-options o client-request-options
If the BNDUPD was triggered by a request from a DHCP client (typi- If the BNDUPD was triggered by a request from a DHCP client (typi-
cally those with binding-status of ACTIVE and RELEASED), then the cally those with binding-status of ACTIVE and RELEASED), then the
server SHOULD include options of interest to a failover partner server SHOULD include options of interest to a failover partner
from the client's request packet in the client-request-options for from the client's request packet in the client-request-options for
transmission to its partner. transmission to its partner (see section 12.8).
A server sending a BNDUPD SHOULD remember the "interesting" options A server sending a BNDUPD SHOULD remember the "interesting" options
or the information that would appear in an "interesting" option for or the information that would appear in an "interesting" option for
transmission at a time when the BNDUPD is not closely associated transmission at a time when the BNDUPD is not closely associated
with a DHCP client request. with a DHCP client request.
A server SHOULD send the following "interesting" options. It MAY A server SHOULD send the following "interesting" options. It MAY
send any DHCP client options. As new options are defined, the RFC send any DHCP client options. As new options are defined, the RFC
defining these options SHOULD include information that they are defining these options SHOULD include information that they are
"interesting to failover servers" if they should be sent as part of "interesting to failover servers" if they should be sent as part of
skipping to change at page 48, line 35 skipping to change at page 50, line 35
Table 7.1.1-2: Options which SHOULD be sent in Table 7.1.1-2: Options which SHOULD be sent in
the client-request-options option in a BNDUPD message. the client-request-options option in a BNDUPD message.
o client-reply-options o client-reply-options
If the BNDUPD was triggered by a request from a DHCP client (typi- If the BNDUPD was triggered by a request from a DHCP client (typi-
cally those with binding-status of ACTIVE and RELEASED), then the cally those with binding-status of ACTIVE and RELEASED), then the
server SHOULD include options of interest to a failover partner server SHOULD include options of interest to a failover partner
from the server's DHCP reply packet in the client-reply-options for from the server's DHCP reply packet in the client-reply-options for
transmission to its partner. transmission to its partner (see section 12.7).
A server sending a BNDUPD SHOULD remember the "interesting" options A server sending a BNDUPD SHOULD remember the "interesting" options
or the information that would appear in an "interesting" option for or the information that would appear in an "interesting" option for
transmission at a time when the BNDUPD is not closely associated transmission at a time when the BNDUPD is not closely associated
with a DHCP client request. with a DHCP client request.
A server SHOULD send the following "interesting" options. It MAY A server SHOULD send the following "interesting" options. It MAY
send any DHCP client options. As new options are defined, the RFC send any DHCP client options. As new options are defined, the RFC
defining these options SHOULD include information that they are defining these options SHOULD include information that they are
"interesting to failover servers" if they should be sent as part of "interesting to failover servers" if they should be sent as part of
skipping to change at page 49, line 22 skipping to change at page 51, line 22
Table 7.1.1-3: Options which SHOULD be sent in Table 7.1.1-3: Options which SHOULD be sent in
the client-reply-options option in a BNDUPD message. the client-reply-options option in a BNDUPD message.
The BNDUPD message SHOULD be sent as soon as possible from the time The BNDUPD message SHOULD be sent as soon as possible from the time
that the DHCP client received a response and the lease bindings data- that the DHCP client received a response and the lease bindings data-
base is written on stable storage. base is written on stable storage.
7.1.2. Receiving the BNDUPD message 7.1.2. Receiving the BNDUPD message
When a server receives a BNDUPD message, it needs to decide how to When a server receives a BNDUPD message, it needs to decide how to
processes the binding update transaction it contains and whether that process the binding update transaction it contains and whether that
transaction represents a conflict of any sort. The conflict resolu- transaction represents a conflict of any sort. The conflict resolu-
tion process MUST be used on the receipt of every BNDUPD message, not tion process MUST be used on the receipt of every BNDUPD message, not
just those that are received while in POTENTIAL-CONFLICT state, in just those that are received while in POTENTIAL-CONFLICT state, in
order to increase the robustness of the protocol. order to increase the robustness of the protocol.
There are three sorts of conflicts: There are three sorts of conflicts:
o Two clients, one IP address conflict o Two clients, one IP address conflict
This is the duplicate IP address allocation conflict. There are This is the duplicate IP address allocation conflict. There are
skipping to change at page 50, line 37 skipping to change at page 52, line 37
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. In addition, it is worth not-
ing that two (and possibly three) binding-status values are the ing that two (and possibly three) binding-status values are the
direct result of interaction with a DHCP client, ACTIVE and RELEASED direct result of interaction with a DHCP client, ACTIVE and RELEASED
(and possibly ABANDONED). All other binding-status values are either (and possibly ABANDONED). All other binding-status values are either
the result of the expiration of a time period or interaction with an the result of the expiration of a time period or interaction with an
external agency (e.g., a network admistrator). external agency (e.g., a network administrator).
Every BNDUPD message SHOULD contain a client-last-transaction-time Every BNDUPD message SHOULD contain a client-last-transaction-time
option, which MUST, if it appears, be the time that the server last option, which MUST, if it appears, be the time that the server last
interacted with the DHCP client. It MUST NOT be, for instance, the interacted with the DHCP client. It MUST NOT be, for instance, the
time that the lease on an IP address expired. If there has been no time that the lease on an IP address expired. If there has been no
interaction with the DHCP client in question (or there is no DHCP interaction with the DHCP client in question (or there is no DHCP
client presently associated with this IP address), then there will be client presently associated with this IP address), then there will be
no client-last-transaction-time option in the BNDUPD message. no client-last-transaction-time option in the BNDUPD message.
The following list is indexed by the binding-status that a server The list in Figure 7.1.3-1 is indexed by the binding-status that a
receives in a BNDUPD message. In many cases, the binding-status of server receives in a BNDUPD message. In many cases, the binding-
an IP address within the receiving server's data storage will have an status of an IP address within the receiving server's data storage
affect upon the checks performed prior to accepting the new binding- will have an affect upon the checks performed prior to accepting the
status in a BNDUPD message. new binding-status in a BNDUPD message.
In the following list, to "accept" a BNDUPD means to update the In Figure 7.1.3-1, to "accept" a BNDUPD means to update the server's
server's bindings database with the information contained in the bindings database with the information contained in the BNDUPD and
BNDUPD and once that update is complete, send a BNDACK message once that update is complete, send a BNDACK message corresponding to
corresponding to the BNDUPD message. To "reject" a BNDUPD means to the BNDUPD message. To "reject" a BNDUPD means to respond to the
respond to the BNDUPD with a BNDACK with a reject-reason option BNDUPD with a BNDACK with a reject-reason option included.
included.
When interpreting the rules in the following list, if a BNDUPD When interpreting the rules in the following list, if a BNDUPD
doesn't have a client-last-transaction-time value, then it MUST NOT doesn't have a client-last-transaction-time value, then it MUST NOT
be considered later than the client-last-transaction-time in the be considered later than the client-last-transaction-time in the
receiving server's binding. If the BNDUPD contains a client-last- receiving server's binding. If the BNDUPD contains a client-last-
transaction-time value and the receiving server's binding does not, transaction-time value and the receiving server's binding does not,
then the client-last-transaction-time value in the BNDUPD MUST be then the client-last-transaction-time value in the BNDUPD MUST be
considered later than the server's. considered later than the server's.
The second rule concerns clients and IP addresses. If the clients in 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.
binding-status in received BNDUPD binding-status in received BNDUPD
binding-status binding-status
in recieving 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 reject reject reject accept
time(1): If the client-last-transaction-time in the BNDUPD time(1): If the client-last-transaction-time in the BNDUPD
skipping to change at page 52, line 12 skipping to change at page 54, line 12
Figure 7.1.3-1: Accepting BNDUPD messages Figure 7.1.3-1: Accepting BNDUPD messages
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. Server's 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.
7.1.5. Time values related to the BNDUPD message 7.1.5. Time values related to the BNDUPD message
There are four time values that MAY be sent in a BNDUPD message. There are four time values that MAY be sent in a BNDUPD message.
o lease-expiration-time o lease-expiration-time
The time that the server gave to the client, i.e., the time that The time that the server gave to the client, i.e., the time that
skipping to change at page 53, line 7 skipping to change at page 55, line 7
Remember that each server sends a potential-expiration-time and Remember that each server sends a potential-expiration-time and
receives an ACK for that as well as receiving a potential- receives an ACK for that as well as receiving a potential-
expiration-time and needing to remember what it has acked for that. expiration-time and needing to remember what it has acked for that.
While they don't have to be named in any particular way, the times While they don't have to be named in any particular way, the times
that a server needs to remember for every IP address in order to that a server needs to remember for every IP address in order to
implement the failover protocol are: implement the failover protocol are:
o lease-expiration-time o lease-expiration-time
The time that this server gave to the DHCP client. A DHCP The time that a server gave to the DHCP client. A DHCP server
server needs to remember this time already, just to be a DHCP needs to remember this time already, just to be a DHCP server.
server. A server SHOULD update this time with the lease-expiration time
received from a partner in a BNDUPD if the received lease-
expiration time is later than the lease-expiration time recorded
for this binding.
o sent-potential-expiration-time o sent-potential-expiration-time
The latest time sent to the partner for a potential-expiration- The latest time sent to the partner for a potential-expiration-
time. time.
o acked-potential-expiration-time o acked-potential-expiration-time
The latest time that the partner has acked for a potential The latest time that the partner has acked for a potential
expiration time. Typically the same as sent-potential- expiration time. Typically the same as sent-potential-
skipping to change at page 53, line 32 skipping to change at page 55, line 35
o received-potential-expiration-time o received-potential-expiration-time
The latest time that this server has ever received as a The latest time that this server has ever received as a
potential-expiration-time from its partner in a BNDUPD that this potential-expiration-time from its partner in a BNDUPD that this
server ACKed. server ACKed.
So, a server has to remember two additional times concerning BNDUPD So, a server has to remember two additional times concerning BNDUPD
messages that it has initiated, and one additional time concerning messages that it has initiated, and one additional time concerning
BNDUPD message that it has received. How are these times used? BNDUPD message that it has received. How are these times used?
First, let's look at the time that DHCP server can offer to a DHCP First, let's look at the time that a DHCP server can offer to a DHCP
client. A server can offer to a to a DHCP client a time that is no client. A server can offer to a DHCP client a time that is no longer
longer than the MCLT beyond the max( received-potential-expiration- than the MCLT beyond the max( received-potential-expiration-time,
time, acked-potential-expiration-time). One might think that the acked-potential-expiration-time). One might think that the server
server should be able to offer only the MCLT beyond the acked- should be able to offer only the MCLT beyond the acked-potential-
potential-expiration-time, and while that is certainly simple and expiration-time, and while that is certainly simple and easy to
easy to understand, it has negative consequences in actual operation. understand, it has negative consequences in actual operation.
To illustrate this, in the simple case where the primary updates the To illustrate this, in the simple case where the primary updates the
secondary for a while and then fails, if the secondary can then renew secondary for a while and then fails, if the secondary can then renew
the client for only the MCLT beyond the acked-potential-expiration- the client for only the MCLT beyond the acked-potential-expiration-
time, then the secondary will only be able to renew the client for time, then the secondary will only be able to renew the client for
the MCLT, because the secondary has never sent a BNDUPD packet to the the MCLT, because the secondary has never sent a BNDUPD packet to the
primary concerning this IP address and client, and so its acked- primary concerning this IP address and client, and so its acked-
potential-expiration-time is zero. potential-expiration-time is zero.
However, since the secondary is allowed to renew the client with the However, since the secondary is allowed to renew the client with the
skipping to change at page 54, line 34 skipping to change at page 56, line 37
potential-expiration-time), then the additional times sent- potential-expiration-time), then the additional times sent-
potential-expiration-time and acked-potential-expiration-time must be potential-expiration-time and acked-potential-expiration-time must be
added into the expression, since the partner could have used those added into the expression, since the partner could have used those
times as part of its own lease time calculation. times as part of its own lease time calculation.
Thus this optimization may require a longer waiting time when enter- Thus this optimization may require a longer waiting time when enter-
ing PARTNER-DOWN state, but will generally allow servers to operate ing PARTNER-DOWN state, but will generally allow servers to operate
considerably more effectively when running in COMMUNICATIONS- considerably more effectively when running in COMMUNICATIONS-
INTERRUPTED state. INTERRUPTED state.
7.2. BNDACK message 7.2. BNDACK message [4]
A server sends a binding acknowledgement (BNDACK) message when it has A server sends a binding acknowledgement (BNDACK) message when it has
processed a BNDUPD message and after it has successfully committed to processed a BNDUPD message and after it has successfully committed to
stable storage any binding database changes made as a result of pro- stable storage any binding database changes made as a result of pro-
cessing the BNDUPD message. A BNDACK message is used to both accept cessing the BNDUPD message. A BNDACK message is used to both accept
or reject a BNDUPD message. A BNDACK message which contains a or reject a BNDUPD message. A BNDACK message which contains a
reject-reason option is a rejection of the corresponding BNDUPD mes- reject-reason option is a rejection of the corresponding BNDUPD mes-
sage. sage.
In order to reduce the complexity of the discussion, the rest of this In order to reduce the complexity of the discussion, the rest of this
skipping to change at page 55, line 9 skipping to change at page 57, line 11
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 multi-
ple binding update transactions. If a server does not every create ple binding update transactions. If a server does not ever create
BNDUPD messages which contain multiple binding update transactions, BNDUPD messages which contain multiple binding update transactions,
then it does not need to be able to process a received BNDACK message then it does not need to be able to process a received BNDACK message
with multiple binding update transactions. However, all servers MUST with multiple binding update transactions. However, all servers MUST
be able to create BNDACK messages which deal with multiple binding be able to create BNDACK messages which deal with multiple binding
update transactions received in a BNDUPD message. update transactions received in a BNDUPD message.
Every BNDUPD message that is received by a server MUST be responded Every BNDUPD message that is received by a server MUST be responded
to with a corresponding BNDACK message. The receiving server SHOULD to with a corresponding BNDACK message. The receiving server SHOULD
respond quickly to every BNDUPD message but it MAY choose to respond respond quickly to every BNDUPD message but it MAY choose to respond
preferentially to DHCP client requests instead of BNDUPD messages, preferentially to DHCP client requests instead of BNDUPD messages,
skipping to change at page 55, line 31 skipping to change at page 57, line 33
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
using the same TCP connection from which the BNDUPD message was using the same TCP connection from which the BNDUPD message was
received, since the XID's in BNDUPD messages are guaranteed unique received, since the XID's in BNDUPD messages are guaranteed unique
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. A server with unprocessed BNDUPD tions (albeit with a different XID), or it MAY instead choose to pro-
messages when a TCP connection goes down 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 (again because of the issues surrounding XID uniqueness). in response.
The message type for the BNDACK message is 4.
The following table summarizes the options for the BNDACK message. The following table summarizes the options for the BNDACK message.
binding-status BACKUP binding-status BACKUP
RESET RESET
ABANDONED ABANDONED
Option ACTIVE EXPIRED RELEASED FREE Option ACTIVE EXPIRED RELEASED FREE
------ ------ ------- -------- ---- ------ ------ ------- -------- ----
assigned-IP-address MUST MUST MUST MUST assigned-IP-address (3) MUST MUST MUST MUST
binding-status MUST MUST MUST MUST binding-status MUST MUST MUST MUST
client-identifier MAY MAY MAY MAY client-identifier MAY MAY MAY MAY(2)
client-hardware-address MUST MUST MUST MAY(2) client-hardware-address MUST MUST MUST MAY(2)
reject-reason MAY MAY MAY MAY reject-reason MAY MAY MAY MAY
message MAY MAY MAY MAY message MAY MAY MAY MAY
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 SHOULD SHOULD SHOULD MAY client-last-trans.-time SHOULD SHOULD SHOULD MAY
DDNS(1) SHOULD SHOULD SHOULD SHOULD DDNS(1) SHOULD SHOULD SHOULD SHOULD
(1) Only SHOULD appear if the server supports dynamic DNS. (1) MUST if server is performing dynamic DNS for this IP address, else
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
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.
All of the options which appear in the BNDUPD message MUST be The assigned-IP-address option from the BNDUPD message MUST be
included in the BNDACK message. The values in the options MAY be included in the BNDACK message. Any additional options from the
updated to reflect current information on the server sending the BNDUPD message SHOULD NOT appear in the BNDACK message. Note that
BNDACK. Note that update of this information may be used for infor- any information sent in options (e.g, a later lease-expiration time)
mational purposes, but MUST NOT be assumed to necessarily be recorded in the BNDACK message MUST NOT be assumed to necessarily be recorded
in the stable storage of the server who sent the BNDUPD message in the stable storage of the server who receives the BNDACK message
because there is no corresponding ACK of the BNDACK message. Any because there is no corresponding ACK of the BNDACK message. Any
information that SHOULD be recorded in the partner server's stable information that SHOULD be recorded in the partner server's stable
storage MUST be transmitted in a subsequent BNDUPD. storage MUST be transmitted in a subsequent BNDUPD.
If the server is accepting the BNDUPD, the BNDACK message includes If the server is accepting the BNDUPD, the BNDACK message includes
only those options that appeared in the BNDUPD message. If the server only the assigned-IP-address option. If the server is rejecting the
is rejecting the BNDUPD, the additional option reject-reason MUST BNDUPD, the additional option reject-reason MUST appear in the BNDACK
appear in the BNDACK message, and the message option SHOULD appear in message, and the message option SHOULD appear in this case containing
this case containing a human-readable error message describing in a human-readable error message describing in some detail the reason
some detail the reason for the rejection of the BNDUPD message. for the rejection of the BNDUPD message.
If the server rejects the BNDUPD message with a BNDACK and a reject- If the server rejects the BNDUPD message with a BNDACK and a reject-
reason option, it may be because the server believes that it has reason option, it may be because the server believes that it has
binding information that the other server should know. A server binding information that the other server should know. A server
which is rejecting a BNDUPD may initiate a BNDUPD of its own in order which is rejecting a BNDUPD may initiate a BNDUPD of its own in order
to update its partner with what it believes is better binding infor- to update its partner with what it believes is better binding infor-
mation, but it MUST ensure through some means that it will not end up mation, but it MUST ensure through some means that it will not end up
in a situation where each server is sending BNDUPD messages as fast in a situation where each server is sending BNDUPD messages as fast
as possible because they can't agree on which server has better bind- as possible because they can't agree on which server has better bind-
ing data. Placing a considerable delay on the initiation of a BNDUPD ing data. Placing a considerable delay on the initiation of a BNDUPD
skipping to change at page 57, line 30 skipping to change at page 59, line 30
reject-reason option that means that the BNDUPD message was accepted, reject-reason option that means that the BNDUPD message was accepted,
and the server which sent the BNDUPD SHOULD update its stable storage and the server which sent the BNDUPD SHOULD update its stable storage
with the potential-expiration-time value sent in the BNDUPD message with the potential-expiration-time value sent in the BNDUPD message
and returned in the BNDACK message. Other values sent in the BNDUPD and returned in the BNDACK message. Other values sent in the BNDUPD
message MAY be used as desired. message MAY be used as desired.
If the BNDACK message contains a reject-reason option, that means If the BNDACK message contains a reject-reason option, that means
that the BNDUPD was rejected. There SHOULD be a message option in that the BNDUPD was rejected. There SHOULD be a message option in
the BNDACK giving a text reason for the rejection, and the server the BNDACK giving a text reason for the rejection, and the server
SHOULD log the message in some way. The server MUST NOT immediately SHOULD log the message in some way. The server MUST NOT immediately
try to resend the BNDACK message as there is no reason to believe the try to resend the BNDUPD message as there is no reason to believe the
partner won't reject it a second time. However a server MAY choose partner won't reject it a second time. However a server MAY choose
to send another BNDACK at some future time, for instance when the to send another BNDUPD at some future time, for instance when the
server next processes an update request from its partner. server next processes an update request from its partner.
7.3. UPDREQ message 7.3. UPDREQ message [9]
The update request (UPDREQ) message is used by one server to request The update request (UPDREQ) message is used by one server to request
that its partner send it all of the binding database information that that its partner send it all of the binding database information that
it has not already seen. Since each server is required to keep it has not already seen. Since each server is required to keep
track at all times of the binding information the other server has track at all times of the binding information the other server has
received and ACKed, one server can request transmission of all un- received and ACKed, one server can request transmission of all un-
ACKed binding database information held by the other server by using ACKed binding database information held by the other server by using
the UPDREQ message. the UPDREQ message.
The UPDREQ message is used whenever the sending server cannot proceed The UPDREQ message is used whenever the sending server cannot proceed
skipping to change at page 58, line 12 skipping to change at page 60, line 12
accepted or rejected by the BNDACK messages, but they MUST have been accepted or rejected by the BNDACK messages, but they MUST have been
responded to). Thus, the sender of the UPDREQ message can be sure responded to). Thus, the sender of the UPDREQ message can be sure
upon receipt of an UPDDONE message that it has received and committed upon receipt of an UPDDONE message that it has received and committed
to stable storage all outstanding binding database updates. to stable storage all outstanding binding database updates.
See section 9, Failover Endpoint States, for the details of when the See section 9, Failover Endpoint States, for the details of when the
UPDREQ message is sent. UPDREQ message is sent.
7.3.1. Sending the UPDREQ message 7.3.1. Sending the UPDREQ message
The message type for the UPDREQ message is 9.
The UPDREQ message has no message specific options. The UPDREQ message has no message specific options.
7.3.2. Receiving the UPDREQ message 7.3.2. Receiving the UPDREQ message
A server receiving an UPDREQ message MUST send all binding database A server receiving an UPDREQ message MUST send all binding database
changes that have not yet been ACKed by the sending server. These changes that have not yet been ACKed by the sending server. These
changes are sent as undistinguished BNDUPD messages. changes are sent as undistinguished BNDUPD messages.
However, the server which received and is processing the UPDREQ mes- However, the server which received and is processing the UPDREQ mes-
sage MUST track the BNDACK messages that correspond to the BNDUPD sage MUST track the BNDACK messages that correspond to the BNDUPD
skipping to change at page 59, line 5 skipping to change at page 60, line 48
to include all such later BNDUPD messages in the accounting for the to include all such later BNDUPD messages in the accounting for the
UPDREQ in order to be able to transmit an UPDDONE message. UPDREQ in order to be able to transmit an UPDDONE message.
When queuing up the BNDUPD messages for transmission to the sender of When queuing up the BNDUPD messages for transmission to the sender of
the UPDREQ message, the server processing the UPDREQ message MUST the UPDREQ message, the server processing the UPDREQ message MUST
honor the value returned in the max-unacked-bndupd option in the CON- honor the value returned in the max-unacked-bndupd option in the CON-
NECT or CONNECTACK message that set up the connection with the send- NECT or CONNECTACK message that set up the connection with the send-
ing server. It MUST NOT send more BNDUPD messages without receiving ing server. It MUST NOT send more BNDUPD messages without receiving
corresponding BNDACKs than the value returned in max-unacked-bndupd. corresponding BNDACKs than the value returned in max-unacked-bndupd.
7.4. UPDREQALL message 7.4. UPDREQALL message [7]
The update request all (UPDREQALL) message is used by one server to The update request all (UPDREQALL) message is used by one server to
request that its partner send it all of the binding database informa- request that its partner send it all of the binding database
tion. This message is used to allow one server to recover from a information. This message is used to allow one server to recover
failure of stable storage and to restore its binding database in its from a failure of stable storage and to restore its binding database
entirety from the other server. in its 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 message type for the UPDREQALL message is 7.
The UPDREQALL message has no message specific options. The UPDREQALL message has no message specific options.
7.4.1. Sending the UPDREQALL message 7.4.1. Sending the UPDREQALL message
The UPDREQALL is sent. The UPDREQALL is sent.
7.4.2. Receiving the UPDREQALL message 7.4.2. Receiving the UPDREQALL message
A server receiving an UPDREQALL message MUST send all binding data- A server receiving an UPDREQALL message MUST send all binding data-
base information to the sending server. These changes are sent as base information to the sending server. These changes are sent as
undistinguished BNDUPD messages. Otherwise the processing is the same undistinguished BNDUPD messages. Otherwise the processing is the same
as for the UPDREQ message. See section 7.3.2 for details. as for the UPDREQ message. See section 7.3.2 for details.
7.5. UPDDONE message 7.5. UPDDONE message [8]
The update done (UPDDONE) message is used by a server receiving an The update done (UPDDONE) message is used by a server receiving an
UPDREQ or UPDREQALL message to signify that it has sent all of the UPDREQ or UPDREQALL message to signify that it has sent all of the
BNDUPD messages requested by the UPDREQ or UPDREQALL request and that BNDUPD messages requested by the UPDREQ or UPDREQALL request and that
it has received a BNDACK for each of those messages. it has received a BNDACK for each of those messages.
While a BNDACK message MUST have been received for each BNDUPD mes- While a BNDACK message MUST have been received for each BNDUPD mes-
sage prior to the transmission of the UPDDONE message, this doesn't sage prior to the transmission of the UPDDONE message, this doesn't
necessarily mean that all of the BNDUPD messages were accepted, only necessarily mean that all of the BNDUPD messages were accepted, only
that all of them were responded to with a BNDACK message. Thus, a that all of them were responded to with a BNDACK message. Thus, a
NAK (comprised of a BNDACK message containing a reject-reason option) NAK (comprised of a BNDACK message containing a reject-reason option)
could be used to reject a BNDUPD, but for the purposes of the UPDDONE could be used to reject a BNDUPD, but for the purposes of the UPDDONE
message, such NAK would count as a response to the associated BNDUPD message, such NAK would count as a response to the associated BNDUPD
message, and would not block the eventual transmission of the UPDDONE message, and would not block the eventual transmission of the UPDDONE
message. message.
The message type for the UPDDONE message is 8.
The xid in an UPDDONE message MUST be identical to the xid in the The xid in an UPDDONE message MUST be identical to the xid in the
UPDREQ or UPDREQALL message that initiated the update process. UPDREQ or UPDREQALL message that initiated the update process.
The UPDDONE message has no message specific options. The UPDDONE message has no message specific options.
7.5.1. Sending the UPDDONE message 7.5.1. Sending the UPDDONE message
The UPDDONE message SHOULD be sent as soon as the last BNDACK message The UPDDONE message SHOULD be sent as soon as the last BNDACK message
corresponding to a BNDUPD message requested by the UPDREQ or corresponding to a BNDUPD message requested by the UPDREQ or
UPDREQALL is received from the server which sent the UPDREQ or UPDREQALL is received from the server which sent the UPDREQ or
UPDREQALL. The XID of the UPDDONE message MUST be the same as the UPDREQALL. The XID of the UPDDONE message MUST be the same as the
XID of the corresponding UPDREQ or UPDREQALL message. XID of the corresponding UPDREQ or UPDREQALL message.
7.5.2. Receiving the UPDDONE message 7.5.2. Receiving the UPDDONE message
A server receiving the UPDDONE message knows that all of the informa- A server receiving the UPDDONE message knows that all of the informa-
tion that it requested by sending an UPDREQ or UPDREQALL message has tion that it requested by sending an UPDREQ or UPDREQALL message has
now been sent and that it has recorded this information in its stable now been sent and that it has recorded this information in its stable
storage. It typically uses that the receipt of an UPDDONE message to storage. It typically uses the receipt of an UPDDONE message to move
move to a different failover state. See sections 9.5.2 and 9.8.3 for to a different failover state. See sections 9.5.2 and 9.8.3 for
details. details.
7.6. POOLREQ message 7.6. POOLREQ message [1]
The pool request (POOLREQ) message is used by the secondary server to The pool request (POOLREQ) message is used by the secondary server to
request an allocation of IP addresses from the primary server. It request an allocation of IP addresses from the primary server. It
MUST be sent by a secondary server to a primary server to request IP MUST be sent by a secondary server to a primary server to request IP
address allocation by the primary. The IP addresses allocated are address allocation by the primary. The IP addresses allocated are
transmitted using normal BNDUPD messages from the primary to the transmitted using normal BNDUPD messages from the primary to the
secondary. secondary.
The POOLREQ message SHOULD be sent from the secondary to the primary The POOLREQ message SHOULD be sent from the secondary to the primary
whenever the secondary transitions into NORMAL state. It SHOULD whenever the secondary transitions into NORMAL state. It SHOULD
periodically be resent in order that any change in the number of periodically be resent in order that any change in the number of
available IP addresses on the primary be reflected in the pool on the available IP addresses on the primary be reflected in the pool on the
secondary. The period may be influenced by the secondary server's secondary. The period may be influenced by the secondary server's
leasing activity. leasing activity.
The message type for the POOLREQ message is 1.
The POOLREQ message has no message specific options. The POOLREQ message has no message specific options.
7.6.1. Sending the POOLREQ message 7.6.1. Sending the POOLREQ message
The POOLREQ message is sent. The POOLREQ message is sent.
7.6.2. Receiving the POOLREQ message 7.6.2. Receiving the POOLREQ message
When a primary server receives a POOLREQ message it SHOULD examine When a primary server receives a POOLREQ message it SHOULD examine
the binding database and determine how many IP addresses the secon- the binding database and determine how many IP addresses the secon-
skipping to change at page 61, line 34 skipping to change at page 63, line 24
cated as a result of processing the POOLREQ message, and send that cated as a result of processing the POOLREQ message, and send that
number in the POOLRESP message. number in the POOLRESP message.
A primary server MAY choose to defer processing a POOLREQ message A primary server MAY choose to defer processing a POOLREQ message
until a more convenient time to process it, but it should not depend until a more convenient time to process it, but it should not depend
on the secondary server to resend the POOLREQ message in that case. on the secondary server to resend the POOLREQ message in that case.
If a secondary server receives a POOLREQ message it SHOULD report an If a secondary server receives a POOLREQ message it SHOULD report an
error. error.
7.7. POOLRESP message 7.7. POOLRESP message [2]
A primary server sends a POOLRESP message to a secondary server after A primary server sends a POOLRESP message to a secondary server after
the allocation process for available addresses to the secondary the allocation process for available addresses to the secondary
server is complete. Typically this message will precede some of the server is complete. Typically this message will precede some of the
BNDUPD messages that the primary uses to send the actual allocated IP BNDUPD messages that the primary uses to send the actual allocated IP
addresses to the secondary. addresses to the secondary.
The message type for the POOLRESP message is 2.
The xid in the POOLRESP message MUST be identical to the xid in the The xid in the POOLRESP message MUST be identical to the xid in the
POOLREQ message for which this POOLRESP is a response. POOLREQ message for which this POOLRESP is a response.
7.7.1. Sending the POOLRESP message 7.7.1. Sending the POOLRESP message
The POOLRESP message MUST contain the same xid as the corresponding The POOLRESP message MUST contain the same xid as the corresponding
POOLREQ message. POOLREQ message.
Only one option MUST appear in a POOLREQ message: Only one option MUST appear in a POOLREQ message:
skipping to change at page 62, line 21 skipping to change at page 64, line 9
addresses-transferred option in a POOLRESP message. Note this addresses-transferred option in a POOLRESP message. Note this
is the number of addresses that are transferred to the secondary is the number of addresses that are transferred to the secondary
in the primary's binding database as a result of the correspond- in the primary's binding database as a result of the correspond-
ing POOLREQ message, and that it may be some time before they ing POOLREQ message, and that it may be some time before they
can all be transmitted to the secondary server through the use can all be transmitted to the secondary server through the use
of BNDUPD messages. of BNDUPD messages.
7.7.2. Receiving the POOLRESP message 7.7.2. Receiving the POOLRESP message
When a secondary server receives a POOLRESP message, it SHOULD send When a secondary server receives a POOLRESP message, it SHOULD send
another POOLRESP message if the value of the addresses-transferred another POOLREQ message if the value of the addresses-transferred
option is non-zero. option is non-zero.
Typically, no other action is taken on the reception of a POOLRESP Typically, no other action is taken on the reception of a POOLRESP
message. message.
7.8. CONNECT message 7.8. CONNECT message [5]
The connect message is used to establish an applications level con- The connect message is used to establish an applications level con-
nection over a newly created TCP connection. It gives the source nection over a newly created TCP connection. It gives the source
information for the connection, and critical configuration informa- information for the connection, and critical configuration informa-
tion. It MUST be sent only by the primary server. Either server can tion. It MUST be sent only by the primary server. Either server can
initiate a TCP connection, but the CONNECT message is only sent by initiate a TCP connection, but the CONNECT message is only sent by
the primary server. the primary server.
The message type for the CONNECT message is 5.
The CONNECT message MUST be the first message sent down a newly esta- The CONNECT message MUST be the first message sent down a newly esta-
blished connection, and it MUST be sent only by the primary server. blished connection, and it MUST be sent only by the primary server.
The following table summarizes the options that are associated with The following table summarizes the options that are associated with
the CONNECT message: the CONNECT message:
Option Option
------ ------
sending-server-IP-address MUST sending-server-IP-address MUST
max-unacked-bndupd MUST max-unacked-bndupd MUST
receive-timer MUST receive-timer MUST
vendor-class-identifier MUST vendor-class-identifier MUST
protocol-version MUST protocol-version MUST
TLS-request MUST TLS-request MUST (1)
MCLT MUST MCLT MUST
hash-bucket-assignment MUST hash-bucket-assignment MUST
(1) MUST NOT if CONNECT is being sent over a TLS connection
Table 7.8-1: Options used in a CONNECT message Table 7.8-1: Options used in a CONNECT message
7.8.1. Sending the CONNECT message 7.8.1. Sending the CONNECT message
The CONNECT message MUST be the first message sent by the primary The CONNECT message MUST be the first message sent by the primary
server after the establishment of a new TCP connection with a secon- server after the establishment of a new TCP connection with a secon-
dary server participating in the failover protocol. dary server participating in the failover protocol.
The xid of the CONNECT message must be unique. The xid of the CONNECT message must be unique.
skipping to change at page 65, line 29 skipping to change at page 67, line 8
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 the appropri-
ate reject-reason in the CONNECTACK. If the server does sup- ate reject-reason in the CONNECTACK. If the server does sup-
port message-digests, then check this message for validity port message-digests, then check this message for validity
based on the message-digest, and reject it if the digest indi- based on the message-digest, and reject it if the digest indi-
cates the message was altered. cates the message was altered.
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 the any engage in failover activity. This is performed after any TLS
TLS or message digest processing so that it occurs after a or message digest processing so that it occurs after a secure
secure connection is created, to ensure that there is no connection is created, to ensure that there is no tampering
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.9 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 should reject the CONNECT request by sending a CONNECTACK mes-
message with a reject-reason of 4, time mismatch too great. sage with a reject-reason of 4, time mismatch too great.
If the time mismatch is not considered too great then the If the time mismatch is not considered too great then the
receiving server MUST record the delta between the servers. receiving server MUST record the delta between the servers.
The receiving server MUST use this delta to correct all of the The receiving server MUST use this delta to correct all of the
absolute times received from the other server in all time- absolute times received from the other server in all time-
valued options. Note that server's can participate in fail- valued options. Note that servers can participate in failover
over with arbitrarily great time mismatches, as long as it is with arbitrarily great time mismatches, as long as it is more
more or less constant. or less constant.
7. If the receiving server is a secondary server, it MUST examine 7. Examine the MCLT option in the CONNECT request and use the
the MCLT option in the CONNECT request and use the value of value of the MCLT as the MCLT for this failover endpoint.
the MCLT as the MCLT for this failover endpoint.
A receiving secondary server SHOULD be able to operate with The secondary server SHOULD be able to operate with any MCLT
any MCLT sent by the primary, but if it cannot, then it sent by the primary, but if it cannot, then it should send a
should send a CONNECTACK with a reject-reason of 5, MCLT CONNECTACK with a reject-reason of 5, MCLT mismatch.
mismatch.
8. The server MUST store hash-bucket-assignment option for use 8. The server MUST store hash-bucket-assignment option for use
during processing during NORMAL state. If this hash bucket during processing during NORMAL state. If this hash bucket
assignment conflicts with the secondary server's configured assignment conflicts with the secondary server's configured
hash bucket assignment for use in other than NORMAL state, the hash bucket assignment for use in other than NORMAL state, the
secondary server should send a CONNECTACK with a reject reason secondary server should send a CONNECTACK with a reject reason
of 19, Hash bucket assignment conflict. of 19, Hash bucket assignment conflict.
9. The receiving server MAY use the vendor-class-identifier to do 9. The receiving server MAY use the vendor-class-identifier to do
vendor specific processing. vendor specific processing.
7.9. CONNECTACK message 7.9. CONNECTACK message [6]
The CONNECTACK message is sent to accept or reject a CONNECT message. The CONNECTACK message is sent to accept or reject a CONNECT message.
It is sent by the secondary server which received a CONNECT message. It is sent by the secondary server which received a CONNECT message.
Attempting immediately to reconnect after either receiving a CONNEC- Attempting immediately to reconnect after either receiving a CONNEC-
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 message type for the CONNECTACK message is 6.
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
------ ------
sending-server-IP-address MUST sending-server-IP-address MUST
max-unacked-bndupd MUST max-unacked-bndupd MUST
receive-timer MUST receive-timer MUST
vendor-class-identifier MUST vendor-class-identifier MUST
protocol-version MUST protocol-version MUST
TLS-request MUST TLS-request MUST(1)
reject-reason MAY(1) reject-reason MAY(2)
message MAY message MAY
MCLT MUST NOT MCLT MUST NOT
hash-bucket-assignment MUST NOT hash-bucket-assignment MUST NOT
(1) Indicates a rejection of the CONNECT message. (1) MUST NOT if sending CONNECTACK after TLS negotiation
(2) Indicates a rejection of the CONNECT message.
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 68, line 16 skipping to change at page 69, line 35
the TCP connection MUST be placed in the max-unacked-bndupd option. the TCP connection MUST be placed in the max-unacked-bndupd option.
This SHOULD be a number greater than 10, and SHOULD be a number less This SHOULD be a number greater than 10, and SHOULD be a number less
than 100. than 100.
The length of the receive timer (tReceive, see section 8.3) MUST be The length of the receive timer (tReceive, see section 8.3) MUST be
placed in the receive-timer option. placed in the receive-timer option.
The 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.
If the server is rejecting the CONNECT message, then the reject-
reason option MUST appear. A message option SHOULD appear to give a
human readable version of the rejection reason.
After a connection is created (either by sending a CONNECTACK message After a connection is created (either by sending a CONNECTACK message
to the first CONNECT message, or sending a CONNECTACK message to a to the first CONNECT message, or sending a CONNECTACK message to a
CONNECT message received over a TLS connection), the server MUST send CONNECT message received over a TLS connection), the server MUST send
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.
skipping to change at page 68, line 48 skipping to change at page 70, line 15
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 there is a reject-reason option in the CONNEC- 2. Check to see if the xid on the CONNECTACK matches an outstand-
ing CONNECT message on this TCP connection.
3. Check to see if there is a reject-reason option in the CONNEC-
TACK message. If not, continue with step 3. If there is a TACK message. If not, continue with step 3. If there is a
reject-reason option, the server SHOULD report the error code. reject-reason option, the server SHOULD report the error code.
If a message option appears a server SHOULD display the string If a message option appears a server SHOULD display the string
from the message option in a user visible way. The server from the message option in a user visible way. The server
MUST close the connection if a reject-reason option appears. MUST close the connection if a reject-reason option appears.
3. Check to see if the xid on the CONNECTACK matches an outstand- 4. Check the value of the TLS-reply option (if any, which there
ing CONNECT message on this TCP connection. 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-
4. Check the value of the TLS-reply option, and if it was 1, then TACK message, and immediately enter into TLS connection setup.
skip processing of the rest of the CONNECTACK message, and
immediately enter into TLS connection setup.
If it does not, a server SHOULD report an error.
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.
5. Examine the value of the protocol-version option. If this 5. Examine the value of the protocol-version option. If this
server is able to establish connections with another server server is able to establish connections with another server
running this protocol version, then continue, else close the running this protocol version, then continue, else close the
connection. connection.
skipping to change at page 69, line 37 skipping to change at page 70, line 52
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 con- valued options. Note that the failover protocol is
structed so that two servers can be failover partners with constructed so that two servers can be failover partners with
arbitrarily great time mismatches. arbitrarily great time mismatches.
7. If the receiving server is a secondary server, it MUST examine 7. The receiving server MAY use the vendor-class-identifier to do
the MCLT option in the CONNECT request and use the value of
the MCLT as the MCLT for this failover endpoint.
A receiving secondary server SHOULD be able to operate with
any MCLT sent by the primary, but if it cannot, then it MUST
drop the TCP connection.
8. If the receiving server is a secondary server, it MUST store
the hash-bucket-assignment option for use during processing
during NORMAL state. If this hash bucket assignment conflicts
with the server's configured hash bucket assignment for use in
other than NORMAL state, the secondary server should send a
CONNECTACK with a reject reason of 19, Hash bucket assignment
conflict.
9. The receiving server MAY use the vendor-class-identifier to do
vendor specific processing. vendor specific processing.
10. 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 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 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
that didn't contain a reject-reason option, and MUST be sent after that didn't contain a reject-reason option, and MUST be sent after
receiving a CONNECTACK message without a reject-reason option. receiving a CONNECTACK message without a reject-reason option.
A STATE message MUST be sent whenever the failover endpoint changes A STATE message MUST be sent whenever the failover endpoint changes
its failover state and a connection exists to the partner. its failover state and a connection exists to the partner.
The STATE message requires no response from the failover partner. The STATE message requires no response from the failover partner.
The message type for the STATE message is 10.
The following table shows the options that MUST appear in a STATE The following table shows the options that MUST appear in a STATE
message: message:
Option Option
------ ------
sending-state MUST sending-state MUST
server-flags MUST server-flags MUST
start-time-of-state MUST start-time-of-state MUST
Table 7.10-1: Options used in a STATE message Table 7.10-1: Options used in a STATE message
skipping to change at page 71, line 36 skipping to change at page 72, line 36
7.10.2. Receiving the STATE message 7.10.2. Receiving the STATE message
Every STATE message SHOULD indicate a change in state or a change in Every STATE message SHOULD indicate a change in state or a change in
the flags. the flags.
When a STATE message is received, any state transitions specified in When a STATE message is received, any state transitions specified in
section 9 are taken. section 9 are taken.
No response to a STATE message is required. No response to a STATE message is required.
7.11. CONTACT message 7.11. CONTACT message [11]
The contact (CONTACT) message is sent to verify communications The contact (CONTACT) message is sent to verify communications
integrity with a failover partner. The CONTACT message is sent when integrity with a failover partner. The CONTACT message is sent when
no messages have been sent to the failover partner for a specified no messages have been sent to the failover partner for a specified
period of time. This is determined by the tSend timer expiring (see period of time. This is determined by the tSend timer expiring (see
section 8.3). section 8.3).
The message type for the CONTACT message is 11.
The CONTACT message has no message specific options. The CONTACT message has no message specific options.
7.11.1. Sending the CONTACT message 7.11.1. Sending the CONTACT message
The CONTACT message is sent. The CONTACT message is sent.
7.11.2. Receiving the CONTACT message 7.11.2. Receiving the CONTACT message
When a CONTACT message is received, the tReceive timer is reset (as When a CONTACT message is received, the tReceive timer is reset (as
it is with any message that is received). it is with any message that is received).
A server MAY use the time in the time field and the time recorded A server SHOULD use the time in the time field and the time the mes-
above to refine the delta time calculations between the servers. sage was received to refine the delta time calculations between the
servers.
7.12. DISCONNECT message 7.12. DISCONNECT message [12]
The DISCONNECT is the last message sent over a connection before The DISCONNECT is the last message sent over a connection before
dropping an established connection. dropping an established connection (note that an established connec-
tion is one where a CONNECTACK has been sent without a reject rea-
son).
After sending or receiving a DISCONNECT message, a server needs to After sending or receiving a DISCONNECT message, a server needs to
have some mechanism to prevent an error loop. Simply reconnecting to have some mechanism to prevent an error loop. Simply reconnecting to
the partner immediately is not the best option, especially after the partner immediately is not the best option, especially after
several consecutive attempts. several consecutive attempts.
A simple suggested solution is to wait a minute or two after sending A simple suggested solution is to wait a minute or two after sending
or receiving a DISCONNECT before attempting to reestablish communica- or receiving a DISCONNECT before attempting to reestablish communica-
tion. tion.
The message type for the DISCONNECT message is 12.
The DISCONNECT message MUST be the last message sent down a connec- The DISCONNECT message MUST be the last message sent down a connec-
tion before it is closed. tion before it is closed.
The following table summarizes the options that are associated with The following table summarizes the options that are associated with
the DISCONNECT message: the DISCONNECT message:
Option Option
------ ------
reject-reason MUST reject-reason MUST
message SHOULD message SHOULD
skipping to change at page 74, line 5 skipping to change at page 74, line 52
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 TBD 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 as a secondary server, and it is attempting to connect to this server to become a
server. Likewise, when an attempt to connect is received on port TBD secondary server for it. Likewise, when an attempt to connect is
the connection attempt is from a secondary server, and it is attempt- received on port TBD the connection attempt is from a secondary
ing to connect to this server as a primary server. The source port server, and it is attempting to connect to this server to be a pri-
of any TCP connection is unimportant. mary server. The source port of any TCP connection is unimportant.
See the schematic representation below:
Primary Server
--------------
Listens on port TBD for secondary server to connect to it
Periodically connects on port 647 to contact secondary
Secondary Server
--------------
Listens on port 647 for primary server to connect to it
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
that a connection has been rejected by a CONNECTACK message with a that a connection has been rejected by a CONNECTACK message with a
reject-reason option contained in it or a DISCONNECT message, a reject-reason option contained in it or a DISCONNECT message, a
server SHOULD reduce the frequency with which it attempts to connect server SHOULD reduce the frequency with which it attempts to connect
to that server but it SHOULD continue to attempt to connect periodi- to that server but it SHOULD continue to attempt to connect periodi-
cally. cally.
skipping to change at page 74, line 49 skipping to change at page 76, line 13
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.
Once TLS negotiation is complete, the primary server MUST resend the Once TLS negotiation is complete, the primary server MUST resend the
CONNECT message on the newly secured TLS connection and then wait for CONNECT message on the newly secured TLS connection and then wait for
the CONNECTACK message in response. The TLS-request and TLS-reply the CONNECTACK message in response. The TLS-request and TLS-reply
options MUST have the same values in this second CONNECT and CONNEC- options MUST NOT appear in either this second CONNECT or its associ-
TACK message as they had in the first messages. ated CONNECTACK message as they had in the first messages.
The second message sent over a new connection (either a bare TCP con- The second message sent over a new connection (either a bare TCP con-
nection or a connection utilizing TLS) is a STATE message. Upon the nection or a connection utilizing TLS) is a STATE message. Upon the
receipt of this message, the receiver can consider communications up. receipt of this message, the receiver can consider communications up.
It is entirely possible that two servers will attempt to make connec- It is entirely possible that two servers will attempt to make connec-
tions to each other essentially simultaneously, and in this case the tions to each other essentially simultaneously, and in this case the
secondary server will be waiting for a CONNECT message on each con- secondary server will be waiting for a CONNECT message on each con-
nection. The primary server MUST send a CONNECT message over one nection. The primary server MUST send a CONNECT message over one
connection and it MUST close the other connection. connection and it MUST close the other connection.
skipping to change at page 82, line 26 skipping to change at page 83, line 26
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. Is the previous-state NORMAL? If yes, set the previous-state
to COMMUNICATIONS-INTERRUPTED. to COMMUNICATIONS-INTERRUPTED.
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 to 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.
5. Wait for "communications okay", i.e., the process discussed in 5. Wait for "communications okay", i.e., the process discussed in
section 8.2 "Creating the TCP Connection", to complete, section 8.2 "Creating the TCP Connection", to complete,
including the receipt of a STATE message from the partner. including the receipt of a STATE message from the partner.
When and if communications become "okay", clear the STARTUP When and if communications become "okay", clear the STARTUP
skipping to change at page 86, line 37 skipping to change at page 87, line 37
timer goes off, the server will transition into RECOVER-DONE state. timer goes off, the server will transition into RECOVER-DONE state.
This is to allow any IP addresses that were allocated by this server This is to allow any IP addresses that were allocated by this server
prior to loss of its client binding information in stable storage to prior to loss of its client binding information in stable storage to
contact the other server or to time out. 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 when the recovering server went down, not necessarily when start not before the recovering server went down, not necessarily
it came back up. If the time when the recovering server failed is when it came back up. If the time when the recovering server
known, it could be communicated to the recovering server (perhaps failed is known, it could be communicated to the recovering server
through actions of the network administrator), and the wait period (perhaps through actions of the network administrator), and the
could be reduced to the maximum-client-lead-time less the differ- wait period could be reduced to the maximum-client-lead-time less
ence between the current time and the time the server failed. In the difference between the current time and the time the server
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-
ple if the recovering server periodically updates stable storage
with a time stamp, the wait period could be calculated to start at
the time of the last update of stable storage plus the time
required for the next update (which never occurred). This esti-
mate is later than the server went down, but probably not too much
later.
If an UPDDONE message isn't received within an implementation depen- If an UPDDONE message isn't received within an implementation
dent amount of time, and no BNDUPD message are being received, the dependent amount of time, and no BNDUPD messages are being received,
connection SHOULD be dropped. the 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 88, line 37 skipping to change at page 89, line 37
algorithm specified in [LOADB]. algorithm specified in [LOADB].
As discussed in section 5.3, each server will take the client- As discussed in section 5.3, each server will take the client-
identifier from each DHCP client request (or the client-hardware- identifier from each DHCP client request (or the client-hardware-
address, i.e., the htype concatenated to the front of the chaddr if address, i.e., the htype concatenated to the front of the chaddr if
no client-identifier is present in the request) and use it as the no client-identifier is present in the request) and use it as the
'Request ID' specified in [LOADB]. After applying the algorithm 'Request ID' specified in [LOADB]. After applying the algorithm
specified in [LOADB] and comparing the result with the hash bucket specified in [LOADB] and comparing the result with the hash bucket
assignment (performed during connect processing between failover assignment (performed during connect processing between failover
servers), each failover server will be able to unambiguously deter- servers), each failover server will be able to unambiguously deter-
mine if it should processes the DHCP client request. mine if it should process the DHCP client request.
In NORMAL state, a server MUST process every DHCPREQUEST/RENEWAL or
DHCPREQUEST/REBINDING request it receives.
9.6.3. Operation in NORMAL state 9.6.3. Operation in NORMAL state
When in NORMAL state, for every DHCP client request that it When in NORMAL state, for every DHCP client request that it
processes, as determined by the algorithm described in section 9.6.2, processes, as determined by the algorithm described in section 9.6.2,
above, a server will operate in the following manner: above, a server will operate in the following manner:
o Lease time calculations o Lease time calculations
As discussed in section 5.2.1, "Control of lease time", the As discussed in section 5.2.1, "Control of lease time", the
lease interval given to a DHCP client can never be more than the lease interval given to a DHCP client can never be more than the
MCLT greater than the most recently received potential- MCLT greater than the most recently received potential-
expiration-time from the failover partner or the current time, expiration-time from the failover partner or the current time,
whichever is later. whichever is later.
As long as a server adheres to this constraint, the specifics of As long as a server adheres to this constraint, the specifics of
the lease interval that it gives to a DHCP client or the value the lease interval that it gives to a DHCP client or the value
of the potential-expiration-time sent to its failover partner of the potential-expiration-time sent to its failover partner
are implementation dependent. One possible approach is dis- are implementation dependent. One possible approach is dis-
skipping to change at page 89, line 26 skipping to change at page 90, line 23
See section 7.1.5 for details concerning the storage of time See section 7.1.5 for details concerning the storage of time
associated IP addresses and how to use these times when calcu- associated IP addresses and how to use these times when calcu-
lating lease times for DHCP clients. lating lease times for DHCP clients.
o Lazy update of partner server o Lazy update of partner server
After an ACK of a IP address binding, the server servicing a After an ACK of a IP address binding, the server servicing a
DHCP client request attempts to update its partner with the new DHCP client request attempts to update its partner with the new
binding information. The lease time used in the update of the binding information. The lease time used in the update of the
secondary MUST be at that given to the DHCP client in the secondary MUST be at least that given to the DHCP client in the
DHCPACK, and the potential-expiration-time MUST be at least the DHCPACK, and the potential-expiration-time MUST be at least the
lease time, and SHOULD be considerably longer. lease time, and SHOULD be considerably longer.
o Reallocation of IP addresses between clients o Reallocation of IP addresses between clients
Whenever a client binding is released or expires, a BNDUPD mes- Whenever a client binding is released or expires, a BNDUPD mes-
sage must be sent to partner, setting the binding state to sage must be sent to partner, setting the binding state to
RELEASED or EXPIRED. However, until a BNDACK is received for RELEASED or EXPIRED. However, until a BNDACK is received for
this message, the IP address cannot be allocated to another this message, the IP address cannot be allocated to another
client. It can be allocated to the same client again. client. It can be allocated to the same client again.
In normal state, each server receives binding updates from its In normal state, each server receives binding updates from its
partner server in BNDUPD messages. It records these in its client partner server in BNDUPD messages. It records these in its client
binding database in stable storage and then sends a corresponding binding database in stable storage and then sends a corresponding
BNDACK message to the primary server. It MUST ensure that the infor- BNDACK message to the primary server. It MUST ensure that the infor-
mation is recorded in stable storage prior to sending the BNDACK mes- mation is recorded in stable storage prior to sending the BNDACK mes-
sage back to the primary server. sage back to its partner.
9.6.4. Transitions out of NORMAL state 9.6.4. Transitions out of NORMAL state
If an external command is received by a server in NORMAL state If an external command is received by a server in NORMAL state
informing it that its partner is down, then transition into PARTNER- informing it that its partner is down, then transition into PARTNER-
DOWN state. Generally, this would be an unusual situation, where DOWN state. Generally, this would be an unusual situation, where
some external agency new the partner server was down. Using the some external agency knew the partner server was down. Using the
command in this case would be appropriate if the polling interval and command in this case would be appropriate if the polling interval and
timeout were long. timeout were long.
If a server in NORMAL state fails to receive acks to messages sent to If a server in NORMAL state fails to receive acks to messages sent to
its partner for an implementation dependent period of time, it MAY its partner for an implementation dependent period of time, it MAY
move into COMMUNICATIONS-INTERRUPTED state. This situation might move into COMMUNICATIONS-INTERRUPTED state. This situation might
occur if the partner server was capable of maintaining the TCP con- occur if the partner server was capable of maintaining the TCP con-
nection between the server and also capable of sending a CONTACT mes- nection between the server and also capable of sending a CONTACT mes-
sage every tSend seconds, but was (for some reason) incapable of pro- sage every tSend seconds, but was (for some reason) incapable of pro-
cessing BNDUPD messages. cessing BNDUPD messages.
skipping to change at page 91, line 15 skipping to change at page 92, line 10
9.7.2. Operation in COMMUNICATIONS-INTERRUPTED State 9.7.2. Operation in COMMUNICATIONS-INTERRUPTED State
In this state a server MUST respond to all DHCP client requests, and In this state a server MUST respond to all DHCP client requests, and
the algorithm for load balancing described in section 5.3 MUST NOT be the algorithm for load balancing described in section 5.3 MUST NOT be
used. When allocating new IP addresses, each server allocates from used. When allocating new IP addresses, each server allocates from
its own IP address pool, where the primary MUST allocate only FREE IP its own IP address pool, where the primary MUST allocate only FREE IP
addresses, and the secondary MUST allocate only BACKUP IP addresses. addresses, and the secondary MUST allocate only BACKUP IP addresses.
When responding to renewal requests, each server will allow continued When responding to renewal requests, each server will allow continued
renewal of a DHCP client's current lease on an IP address irrespec- renewal of a DHCP client's current lease on an IP address irrespec-
tive of whether that lease was given out by the receiving server or tive of whether that lease was given out by the receiving server or
not, although the renewal period MUST not exceed the maximum client not, although the renewal period MUST NOT exceed the maximum client
lead time (MCLT) beyond the potential-expiration-time already ack- lead time (MCLT) beyond the latest of: 1) the potential-expiration-
nowledged by the other server or the lease-expiration-time or time already acknowledged by the other server, or 2) the lease-
potential-expiration-time received from the partner server. expiration-time, or 3) the potential-expiration-time received from
the partner server.
However, since the server cannot communicate with its partner in this However, since the server cannot communicate with its partner in this
state, the acknowledged-potential-expiration time will not be updated state, the acknowledged-potential-expiration time will not be updated
in any new bindings. This is likely to eventually cause the actual- in any new bindings. This is likely to eventually cause the actual-
client-lease-times to be the current time plus the maximum-client- client-lease-times to be the current time plus the maximum-client-
lead-time (unless this is greater than the desired-client-lease- lead-time (unless this is greater than the desired-client-lease-
time). time).
9.7.3. Transition out of COMMUNICATIONS-INTERRUPTED State 9.7.3. Transition out of COMMUNICATIONS-INTERRUPTED State
skipping to change at page 96, line 22 skipping to change at page 97, line 22
In this state a server MUST respond to all DHCP client requests, and In this state a server MUST respond to all DHCP client requests, and
any load balancing (described in section 5.3) MUST NOT be used. When any load balancing (described in section 5.3) MUST NOT be used. When
allocating new IP addresses, each server SHOULD allocate from its own allocating new IP addresses, each server SHOULD allocate from its own
IP address pool (if that can be determined), where the primary SHOULD IP address pool (if that can be determined), where the primary SHOULD
allocate only FREE IP addresses, and the secondary SHOULD allocate allocate only FREE IP addresses, and the secondary SHOULD allocate
only BACKUP IP addresses. When responding to renewal requests, each only BACKUP IP addresses. When responding to renewal requests, each
server will allow continued renewal of a DHCP client's current lease server will allow continued renewal of a DHCP client's current lease
on an IP address irrespective of whether that lease was given out by on an IP address irrespective of whether that lease was given out by
the receiving server or not, although the renewal period MUST not the receiving server or not, although the renewal period MUST not
exceed the maximum client lead time (MCLT) beyond the potential- exceed the maximum client lead time (MCLT) beyond the latest of: 1)
expiration-time already acknowledged by the other server or the the potential-expiration-time already acknowledged by the other
lease-expiration-time or potential-expiration-time received from the server or 2) the lease-expiration-time or 3) `potential-expiration-
partner server. time received from the partner server.
However, since the server cannot communicate with its partner in this However, since the server cannot communicate with its partner in this
state, the acknowledged-potential-expiration time will not be updated state, the acknowledged-potential-expiration time will not be updated
in any new bindings. in any new bindings.
9.9.3. Transitions out of RESOLUTION-INTERRUPTED state 9.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.
skipping to change at page 101, line 5 skipping to change at page 102, line 5
that partner without a message-digest option as failing authentica- that partner without a message-digest option as failing authentica-
tion. tion.
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.
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.15. The message-digest contains a one-way 16 octet MD5 See section 12.16. 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 101, line 43 skipping to change at page 102, line 43
To request the use of TLS, the server that successfully opened a con- To request the use of TLS, the server that successfully opened a con-
nection to its peer MUST send the TLS option as part of the CONNECT nection to its peer MUST send the TLS option as part of the CONNECT
message. The server receiving the TLS option MUST respond with a message. The server receiving the TLS option MUST respond with a
TLS-reply option indicating its acceptance or rejection of the TLS- TLS-reply option indicating its acceptance or rejection of the TLS-
request in the CONNECT message. request in the CONNECT message.
If the CONNECTACK message contained a TLS-reply of 1 , then both If the CONNECTACK message contained a TLS-reply of 1 , then both
servers begin TLS negotiation. servers begin TLS negotiation.
Upon completion of this negotiation, the server which originally sent Upon completion of this negotiation, the server which originally sent
the CONNECT message MUST resent its CONNECT message without any TLS- the CONNECT message MUST resend its CONNECT message without any TLS-
request, and must wait for a corresponding CONNECTACK. request, and must wait for a corresponding CONNECTACK.
Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [RFC 2246] Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [RFC 2246]
cipher suite is REQUIRED in Failover servers supporting TLS. This is cipher suite is REQUIRED in Failover servers supporting TLS. This is
important as it assures that any two compliant implementations can be important as it assures that any two compliant implementations can be
configured to interoperate. configured to interoperate.
12. Failover Options 12. Failover Options
This section lists all of the options that are currently defined to This section lists all of the options that are currently defined to
skipping to change at page 103, line 25 skipping to change at page 104, line 25
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 104, line 10 skipping to change at page 105, line 22
Code Len htype chaddr Code Len htype chaddr
+-----+-----+-----+-----+----+-----+-----+--- +-----+-----+-----+-----+----+-----+-----+---
| 0 | 5 | 0 | n | t1 | c1 | c2 | ... | 0 | 5 | 0 | n | t1 | c1 | c2 | ...
+-----+-----+-----+-----+----+-----+-----+--- +-----+-----+-----+-----+----+-----+-----+---
12.6. client-last-transaction-time 12.6. client-last-transaction-time
The time at which this server last received a DHCP request from a The time at which this server last received a DHCP request from a
particular client expressed as an absolute time (see section 6.2). particular client expressed as an absolute time (see section 6.2).
Code Len Partner Down Time Code Len client last transaction time
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
| 0 | 6 | 0 | 4 | t1 | t2 | t3 | t4 | | 0 | 6 | 0 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
12.7. client-reply-options 12.7. client-reply-options
This option contains options from a DHCP server's reply to a DHCP This option contains options from a DHCP server's reply to a DHCP
client request. It is sent in a BNDUPD message. The first 4 bytes client request. It is sent in a BNDUPD message. The first 4 bytes
of the option contain the "magic number" of the option area from of the option contain the "magic number" of the option area from
which the DHCP reply options were taken and serves to define the which the DHCP reply options were taken and serves to define the
skipping to change at page 107, line 5 skipping to change at page 108, line 5
0 (C): A RR update successfully completed 0 (C): A RR update successfully completed
1 (A): Server is controlling A RR on behalf of the client 1 (A): Server is controlling A RR on behalf of the client
2 (D): PTR RR update successfully completed (Done) 2 (D): PTR RR update successfully completed (Done)
3 (P): Server is controlling PTR RR on behalf of the client 3 (P): Server is controlling PTR RR on behalf of the client
4-15 : Must be zero 4-15 : Must be zero
All of the unspecified bit positions SHOULD be set to 0 by servers All of the unspecified bit positions SHOULD be set to 0 by servers
sending the Failover-DDNS option, and they MUST be ignored by servers sending the Failover-DDNS option, and they MUST be ignored by servers
receiving the option. receiving the option.
12.10. hash-bucket-assignment 12.10. delayed-service-parameter
The set of hash values to which the receiving server MUST respond. The delayed-service-parameter is an optional load balancing tuning
See section 5.3 for more information on how this option is used. parameter, defined in [LOADB]. If it is used, it MUST be sent in the
same message as the hash-bucket-assignment option (see section
12.11). Format :
Code Len Seconds
+-----+-----+-----+-----+----+
| 0 | 10 | 0 | 1 | S |
+-----+-----+-----+-----+----+
S is a one byte value, 1..255.
12.11. hash-bucket-assignment
A set of load balancing hash values for the secondary server. See
section 5.3 for more information on how this option is used.
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 | 10 | 0 | 32 | b1 | b2 | ... | b32 | | 0 | 11 | 0 | 32 | b1 | b2 | ... | b32 |
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
12.11. lease-expiration-time 12.12. 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 | 11 | 0 | 4 | t1 | t2 | t3 | t4 | | 0 | 12 | 0 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
12.12. max-unacked-bndupd 12.13. 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 | 12 | 0 | 4 | n1 | n2 | n3 | n4 | | 0 | 13 | 0 | 4 | n1 | n2 | n3 | n4 |
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
12.13. MCLT 12.14. 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 | 13 | 0 | 4 | t1 | t2 | t3 | t4 | | 0 | 14 | 0 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
12.14. message 12.15. 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 | 14 | 0 | n | c1 | c2 | ... | 0 | 15 | 0 | n | c1 | c2 | ...
+-----+-----+-----+-----+------+-----+-- +-----+-----+-----+-----+------+-----+--
12.15. message-digest 12.16. 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 | 15 | 0 | n | d1 | d2 | ... | 0 | 16 | 0 | n | d1 | d2 | ...
+-----+-----+-----+-----+----+-----+----- +-----+-----+-----+-----+----+-----+-----
12.16. potential-expiration-time 12.17. 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 | 16 | 0 | 4 | t1 | t2 | t3 | t4 | | 0 | 17 | 0 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
12.17. receive-timer 12.18. 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 | 17 | 0 | 4 | s1 | s2 | s3 | s4 | | 0 | 18 | 0 | 4 | s1 | s2 | s3 | s4 |
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
12.18. protocol-version 12.19. 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 | 18 | 0 | 1 | 1 | | 0 | 19 | 0 | 1 | 1 |
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
12.19. reject-reason 12.20. 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 BNDACK message, always associated with an assigned-IP-address used in a BNDACK message or a CONNECTACK message, always associated
option, which contains the IP address of the update being rejected. with an assigned-IP-address option, which contains the IP address of
the update being rejected.
Code Len Reason Code Code Len Reason Code
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
| 0 | 19 | 0 | 1 | R1 | | 0 | 20 | 0 | 1 | R1 |
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
Reason codes : Reason codes :
0 Reserved 0 Reserved
1 Illegal IP address (not part of any address pool). 1 Illegal IP address (not part of any address pool).
2 Fatal conflict exists: address in use by other client. 2 Fatal conflict exists: address in use by other client.
3 Missing binding information. 3 Missing binding information.
4 Connection rejected, time mismatch too great. 4 Connection rejected, time mismatch too great.
5 Connection rejected, invalid MCLT. 5 Connection rejected, invalid MCLT.
6 Connection rejected, unknown reason. 6 Connection rejected, unknown reason.
7 Connection rejected, duplicate connection. 7 Connection rejected, duplicate connection.
8 Connection rejected, invalid failover partner. 8 Connection rejected, invalid failover partner.
9 TLS not supported. 9 TLS not supported.
10 TLS supported but not configured. 10 TLS supported but not configured.
11 TLS required but not supported by partner. 11 TLS required but not supported by partner.
12 Message digest not supported. 12 Message digest not supported.
13 Message digest not configured. 13 Message digest not configured.
14 Protocol version mismatch. 14 Protocol version mismatch.
15 Missing binding information. 15 Outdated binding information.
16 Outdated binding information. 16 Less critical binding information.
17 Less critical binding information. 17 No traffic within sufficient time.
18 No traffic within sufficient time. 18 Hash bucket assignment conflict.
19 Hash bucket assignment conflict. 19-253, reserved.
20-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.20. sending-server-IP-address 12.21. 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 | 20 | 0 | 4 | a1 | a2 | a3 | a4 | | 0 | 21 | 0 | 4 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
12.21. server-flags 12.22. 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 | 21 | 0 | 1 | flags | | 0 | 22 | 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 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The bits (numbered from the least-significant bit in network The bits (numbered from the least-significant bit in network
byte-order) are used as follows: byte-order) are used as follows:
0 (S): STARTUP, 0 (S): STARTUP,
Bit 5 MUST be set to 1 Bit 0 MUST be set to 1 whenever the server is in STARTUP state,
whenever the server is in STARTUP state, and set to 0 otherwise. and set to 0 otherwise. (Note that when in STARTUP state, the
(Note that when in STARTUP state, the state transmitted in the state transmitted in the server-state option is usually the last
server-state option is usually the last recorded state from recorded state from stable storage, but see section 9.3 for
stable storage, but see section 9.3 for details.) details.)
1-7 : Must be zero 1-7 : Must be zero
12.22. server-state 12.23. 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 | 22 | 0 | 1 | 1-9 | | 0 | 23 | 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
(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.21). 12.22).
12.23. start-time-of-state 12.24. 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 | 23 | 0 | 4 | t1 | t2 | t3 | t4 | | 0 | 24 | 0 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+----+-----+-----+-----+ +-----+-----+-----+-----+----+-----+-----+-----+
12.24. TLS-reply 12.25. 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 | 24 | 0 | 1 | t1 | | 0 | 25 | 0 | 1 | t1 |
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
12.25. TLS-request 12.26. 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 | 25 | 0 | 2 | t1 | | 0 | 26 | 0 | 1 | t1 |
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
12.26. vendor-class-identifier 12.27. 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 | 26 | 0 | n | c1 | c2 | ... | 0 | 27 | 0 | n | c1 | c2 | ...
+-----+-----+-----+-----+----+-----+--- +-----+-----+-----+-----+----+-----+---
12.27. vendor-specific-options 12.28. 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 | 27 | 0 | n | c1 | c2 | ... | 0 | 28 | 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 115, line 50 skipping to change at page 117, line 50
ideas and text in the rest of the draft with several reviews. ideas and text in the rest of the draft with several reviews.
In early October of 1999, three conference calls were held to discuss In early October of 1999, three conference calls were held to discuss
the -04 draft. The -05 includes changes as a result of those calls, the -04 draft. The -05 includes changes as a result of those calls,
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 this Another conference call was held in mid-January of 2000, and the -06
latest draft, the -06, was produced to tighten up the the -05 draft draft was produced to tighten up the the -05 draft both technically
both technically as well as editorially. as well as editorially.
This, the -07 draft was edited by Kim Kinnear and was based in part
on reviews by Richard Jones, Bernie Volz, and Steve Gonczi. It embo-
dies several technical updates as well as numerous editorial revi-
sions that enhance both correctness as well as clarity.
These most recent changes have not been widely circulated among the These most recent changes have not been widely circulated among the
other authors. other authors prior to submission to the IETF.
Many people have reviewed the various earlier drafts that went into Many people have reviewed the various earlier drafts that went into
this result. At American Internet, ideas were contributed by Brad this result. At American Internet, ideas were contributed by Brad
Parker. At Cisco Systems Paul Fox and Ellen Garvey contributed to Parker. At Cisco Systems Paul Fox and Ellen Garvey contributed to
the design of the protocol. 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-08.txt", Janu- [AGENTINFO] Patrick, M., "draft-ietf-dhc-agent-options-11.txt", July,
ary, 2000. 2000.
[DDNS] Rekhter, Y., Stapp, M., "draft-ietf-dhc-dhcp-dns-11.txt", [DDNS] Rekhter, Y., Stapp, M., "draft-ietf-dhc-dhcp-dns-12.txt",
October, 1999. March, 2000.
[LOADB] Volz, B., Gonczi, S., Lemon, T., Stevens, R., "draft-ietf- [LOADB] Volz, B., Gonczi, S., Lemon, T., Stevens, R., "draft-ietf-
dhc-loadb-00.txt", October, 1999. dhc-loadb-02.txt", July, 1999.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specification", November, 1987. Specification", November, 1987.
[RFC 1321] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algo- [RFC 1321] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algo-
rithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data rithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data
Security Inc., April 1992. Security Inc., April 1992.
[RFC 1534] Droms, R., "Interoperation between DHCP and BOOTP", RFC [RFC 1534] Droms, R., "Interoperation between DHCP and BOOTP", RFC
1534, October 1993. 1534, October 1993.
skipping to change at page 117, line 21 skipping to change at page 119, line 27
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October IANA Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
[RFC 2487] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC 2487] Hoffman, P., "SMTP Service Extension for Secure SMTP over
TLS", RFC 2487, January 1999. TLS", RFC 2487, January 1999.
[RFC 2595] Newman, C., "Using TLS with IMAP, POP3, and ACAP", RFC [RFC 2595] Newman, C., "Using TLS with IMAP, POP3, and ACAP", RFC
2595, June 1999. 2595, June 1999.
[USERCLASS] Droms, R., Demirtjis A., Stump, G., Gu, Y., Vyaghrapuri, [USERCLASS] Droms, R., Demirtjis A., Stump, G., Gu, Y., Vyaghrapuri,
R., Beser, B., Privat, J. "draft-ietf-dhc-userclass-05.txt", R., Beser, B., Privat, J. "draft-ietf-dhc-userclass-08.txt", July,
February, 2000. 2000.
16. Author's information 16. Author's information
Ralph Droms Ralph Droms
323 Dana Engineering 323 Dana Engineering
Bucknell University Bucknell University
Lewisburg, PA 17837 Lewisburg, PA 17837
Phone: (717) 524-1145 Phone: (717) 524-1145
EMail: droms@bucknell.edu EMail: droms@bucknell.edu
Greg Rabil, Mike Dooley, Arun Kapur
Lucent Technologies
400 Lapp Road
Malvern, PA 19355
Phone: (800) 208-2747
EMail: grabil@lucent.com
mdooley@lucent.com
akapur@lucent.com
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: kkinnear@cisco.com
mjs@cisco.com mjs@cisco.com
Bernie Volz Bernie Volz
Steve Gonczi IPWorks, Inc.
Process Software Corporation
959 Concord St. 959 Concord St.
Framingham, MA 01701 Framingham, MA 01701
Phone: (508) 879-6994 Phone: (508) 879-1809
EMail: volz@process.com EMail: volz@ipworks.com
gonczi@process.com
Steve Gonczi
Network Engines, Inc.
25 Dan Road
Canton, MA 02021-2817
Phone: (781) 332-1165
Email: steve.gonczi@networkengines.com
Greg Rabil, Mike Dooley, Arun Kapur
Lucent Technologies
400 Lapp Road
Malvern, PA 19355
Phone: (800) 208-2747
EMail: grabil@lucent.com
mdooley@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 (1999). 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
 End of changes. 

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