Network Working Group Greg Rabil INTERNET DRAFT Mike Dooley Arun Kapur Quadritek Systems Ralph Droms Bucknell University November 1997 Expires May 1998 DHCP Failover Protocol Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract DHCP [RFC 2131] allows for multiple servers to be operating on a single network. Some sites are interested in running multiple servers in such a way so as to provide redundancy in case of server failure. In order for this to work reliably, the servers must maintain a consistent database of the lease information. This implies that servers will need to coordinate any and all lease activity so that this information is synchronized in case of failover. This document defines a protocol to provide this synchronization between two servers. One server is designated the ''primary'' server, the other is the ''secondary'' server. Additionally, this document describes a protocol for the automatic transfer of control from the primary to the secondary in the case of failure (failover), as well Rabil, Dooley, Kapur, Droms [Page 1] DRAFT DHCP Failover Protocol November 1997 as the re-establishment of control by the primary server. 1.0 Introduction As the use of DHCP servers in networked environments grows, the dependency of those networks on the DHCP server increases. This is particularly true of the hosts that receive their configuration information from the DHCP server. Therefore, it is very important to be able to provide reliable, continuous availability of DHCP services. This specification describes a protocol to support automatic failover from a primary to its secondary server. The failover mechanism allows the secondary server to perform DHCP actions while the primary is down. Additionally, the protocol defines how control is passed back to the primary when it becomes operational again. In providing the specification for the failover, the protocol specifies how to guarantee reliable delivery of changes to the secondary. This is required to synchronize the secondary's lease data with that of the primary. The protocol further specifies a mechanism for determining the state (operational or not) of the primary server. The secondary will be able to automatically service DHCP requests upon failover. When the primary server becomes available again, the secondary will convey any changes that occurred since the time of failover back to the primary prior to the primary becoming operational. 1.1 Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. 1.2 Terminology This document uses the following terms: o "DHCP client" or "client" A DHCP client is an Internet host using DHCP to obtain configuration parameters such as a network address. o "DHCP server" or "server" A DHCP server is an Internet host that returns configuration Rabil, Dooley, Kapur, Droms [Page 2] DRAFT DHCP Failover Protocol November 1997 parameters to DHCP clients. o "primary server" or "primary" A DHCP server configured to provide primary service to a set of DHCP clients. o "secondary server" or "secondary" A DHCP server configured to act as a backup to a primary server; the secondary answers requests from DHCP clients only if its primary is unable to respond. o "bindings database" The collection of bindings managed by a primary and secondary. 2.0 Protocol Summary The protocol necessary in providing redundant/failover servers can be grouped in three areas: o Messages to keep the secondary server's lease data synchronized with that of the primary so that when failover occurs, there is no degradation of service o Messages that allow the secondary to determine the operational state of the primary, so as to know when to start servicing DHCP traffic o Messages that are used to coordinate the primary regaining control when it has become available again. 2.1 Primary keeps secondary lease data synchronized The messages for keeping the secondary's lease data up to date include the following: DHCPBNDADD - Primary notifies secondary of new binding DHCPBNDUPD - Primary notifies secondary of modified binding (e.g., extended lease) DHCPBNDDEL - Primary notifies secondary of deleted binding (e.g., expired or released lease) In response to any of the above messages, the secondary server will respond to the primary with a message describing the status of the binding addition, modification, or deletion. Rabil, Dooley, Kapur, Droms [Page 3] DRAFT DHCP Failover Protocol November 1997 DHCPBNDACK - Positive acknowledgment of binding change DHCPBNDNAK - Negative acknowledgment of binding change 2.2 Determination of operational state of a server In order to determine the state of a given server, a participant can use the following message to poll (or "ping") the server: DHCPPOLL - Check if server is operational In response to the DHCPPOLL message, the participant will listen for the following: DHCPPRPL - Poll reply 2.3 Primary requests control from the secondary After a failover, when the primary server is restarted, the following messages are used to coordinate the primary taking control back from the secondary: DHCPCTLREQ - Request for control DHCPCTLRET - Return of control initiated DHCPCTLACK - Return of control completed 3 Message formats and semantics The failover protocol messages are encoded as a DHCP/BOOTP option in a DHCP message. A DHCP message carrying a failover protocol message carries only the failover protocol message option and no other options. The DHCP message is unicast from the source to the destination. The option code for these messages is TBD. Within each failover protocol message, the specific message type is indicated by an option subcode in the first octet of the data area of the option. The 'len' field includes the number of octets in the option subcode byte and in any additional data carried in the failover protocol message. Bindings are encoded in a format that is TBD. DISCUSSION The use of the REQUEST/REPLY field in the DHCP message header and the UDP port to be used needs to be considered. The use of existing DHCP options and header fields to encode Rabil, Dooley, Kapur, Droms [Page 4] DRAFT DHCP Failover Protocol November 1997 bindings needs to be considered. The sender places a 32-bit number in the DHCP header 'xid' field to uniquely identify each failover protocol message. The receiver copies the contents of the 'xid' field into any reply or acknowledgment message. The sender is responsible for reliable transmission and any retransmission. 3.1 Primary keeps secondary lease data synchronized DHCPBNDADD ------------------------------------------ | XX | len | 1 | Binding information (TBD) ------------------------------------------ The primary sends a DHCPBNDADD message to inform the secondary of a binding that has been added to the primary's set of bindings. DHCPBNDUPD ------------------------------------------ | XX | len | 2 | Binding information (TBD) ------------------------------------------ The primary sends a DHCPBNDUPD message to inform the secondary of a binding that has been changed in the primary's set of bindings. DHCPBNDDEL ------------------------------------------ | XX | len | 3 | Binding information (TBD) ------------------------------------------ The primary sends a DHCPBNDDEL message to inform the secondary of a binding that has been deleted from the primary's set of bindings. DHCPBNDACK -------------- | XX | 1 | 4 | -------------- The secondary sends a DHCPBNDACK message to the primary to inform the primary that the binding change request identified by the 'xid' field Rabil, Dooley, Kapur, Droms [Page 5] DRAFT DHCP Failover Protocol November 1997 has successfully been completed. DHCPBNDNAK -------------- | XX | 1 | 5 | -------------- The secondary sends a DHCPBNDNAK message to the primary to inform the primary that the secondary could not complete the binding change request. For example, the secondary would send a DHCPBNDNAK in response to a DHCPBNDUPD request for which the secondary had no recorded binding. DISCUSSION The use of an additional field to indicate the reason for the DHCPBNDNAK message should be considered. 3.2 Determination of operational state of a server DHCPPOLL ---------------------- | XX | 2 | 6 | flags | ---------------------- A DHCP participant sends a DHCPPOLL message to a server to determine whether that server is currently operational. A DHCP secondary periodically sends a DHCPPOLL to its primary to determine if the primary is currently operational. A DHCP primary sends a DHCPPOLL to its secondary if the primary needs to determine if the secondary is operational. A DHCP client sends a DHCPPOLL to a DHCP server to determine if the server is currently operational. The flags octet is defined as follows: CRRRRRRR, where the secondary sets the 'C' bit to 1 to indicate that it has taken control of the bindings database, and the 'R' bits are reserved for future use. DHCPPRPL ---------------------- | XX | 2 | 7 | flags | ---------------------- Rabil, Dooley, Kapur, Droms [Page 6] DRAFT DHCP Failover Protocol November 1997 A DHCP participant replies to a DHCPPOLL message with a DHCPPRPL message. The sender copies the 'xid' field from the DHCPPOLL message header into the 'xid' field in the DHCPPRPL message, The flags octet is defined as follows: ERRRRRRR, where the primary sets the 'E' bit to 1 (in response to a DHCPPOLL message with the 'C' bit set to 1) to indicate to the secondary that the primary has not relinquished control of the database. See section 4 for additional details. DISCUSSION The DHCPPOLL and DHCPPRPL messages might also be useful to DHCP clients to aid in determining the availability of specific DHCP servers. Such use would avoid overloading the DHCPDISCOVER message. 3.3 Primary requests control from the secondary DHCPCTLREQ -------------- | XX | 1 | 8 | -------------- A primary sends a DHCPCTLREQ message to its secondary to request control of the bindings database from the secondary. DHCPCTLRET -------------- | XX | 1 | 9 | -------------- A secondary sends a DHCPCTLRET to its primary to begin the process of returning control of the bindings database to the secondary. After sending the DHCPCTLRET message, the secondary sends a sequence of DHCPBNDADD, DHCPBNDUPD and DHCPBNDDEL messages to synchronize the primary's bindings database with the secondary's database. DHCPCTLACK --------------- | XX | 1 | 10 | --------------- A secondary sends a DHCPCTLACK to its primary to indicate that the secondary has finished returning control to the primary. Rabil, Dooley, Kapur, Droms [Page 7] DRAFT DHCP Failover Protocol November 1997 DISCUSSION Primary and secondary servers may need to exchange some additional information in DHCPCTLREQ, DHCPCTLRET and DHCPCTLACK messages. This information would be encoded in an additional 'flags' or 'data' field added to the control messages. The synchronization essentially requires a reliable transmission protocol using DHCPBND* and DHCPBNDACK messages. An alternative to using DHCPBND* messages to transfer bindings updates to the primary would be to devise a separate transfer protocol based on TCP. 4 Exchange of control between primary and secondary The primary and secondary servers coordinate the exchange control over the bindings database through the use of DHCPPOLL and DHCPCTLREQ messages. In normal operation: o the primary sends notification of each change to its bindings database to the secondary, and the secondary keeps its bindings database synchronized with the primary's database o the secondary periodically sends DHCPPOLL messages to the primary, and the primary responds to each DHCPPOLL message with a DHCPPRPL message If the secondary does not receive a DHCPPRPL response message, the secondary takes control of the bindings database and begins answering requests from DHCP clients. DISCUSSION The conditions under which a secondary takes control of the bindings database, e.g., the number of consecutive missing acknowledgments, should be configurable in the secondary by the DHCP administrator. The secondary records any changes it makes to the bindings database while it has control. The secondary continues to send DHCPPOLL messages to the primary, with the 'D' bit set. To regain control of the bindings database, e.g., after the primary server has failed, the primary sends a DHCPCTLREQ message to the secondary. The secondary stops answering DHCP client requests, and responds to its primary with a DHCPCTLRET message. After sending the DHCPCTLRET message, the secondary sends DHCPBND* messages for each of the changes it has made to the bindings database. The Rabil, Dooley, Kapur, Droms [Page 8] DRAFT DHCP Failover Protocol November 1997 primary sends a DHCPBNDACK for each of the DHCPBND* messages it receives. The secondary completes the transfer of control by sending a DHCPCTLACK message to its primary. If the primary server has not failed and has been answering DHCP client requests, and receives a DHCPPOLL message from its secondary with the 'D' bit set, then both the primary and the secondary have been answering DHCP client requests, and their bindings databases may be unsynchronized. In this situation, the primary responds to the secondary with a DHCPPRPL message with the 'E' bit set. Both the primary and secondary servers notify a network administrator, who must take steps to manually resynchronize the two bindings databases. DISCUSSION It may be appropriate to state that, under administrator control, the primary and secondary both stop some or all DHCP services when the servers discover that both have been allocating DHCP addresses simultaneously and their databases are potentially unsynchronized. 5 Acknowledgments 6 References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC2131, March 1997. [RFC 2132] Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC2132, March 1997. 7 Security Considerations 8 Authors' Addresses Greg Rabil, Mike Dooley, Arun Kapur Quadritek Systems, Inc. 10 Valley Stream Parkway, Quite 240 Malvern, PA 19355 Phone: (800) 408-2747 E-mail: grabil@quadritek.com mdooley@quadritek.com akapur@quadritek.com Rabil, Dooley, Kapur, Droms [Page 9] DRAFT DHCP Failover Protocol November 1997 Ralph Droms 323 Dana Engineering Bucknell University Lewisburg, PA 17837 Phone: (717) 524-1145 E-mail: droms@bucknell.edu Rabil, Dooley, Kapur, Droms [Page 10]