idnits 2.17.1 draft-ietf-dhc-failover-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2131]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1998) is 9472 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 2132' is defined on line 434, but no explicit reference was found in the text Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Greg Rabil 3 INTERNET DRAFT Mike Dooley 4 Arun Kapur 5 Quadritek Systems 7 Ralph Droms 8 Bucknell University 10 November 1997 11 Expires May 1998 13 DHCP Failover Protocol 14 16 Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Abstract 36 DHCP [RFC 2131] allows for multiple servers to be operating on a 37 single network. Some sites are interested in running multiple servers 38 in such a way so as to provide redundancy in case of server failure. 39 In order for this to work reliably, the servers must maintain a 40 consistent database of the lease information. This implies that 41 servers will need to coordinate any and all lease activity so that 42 this information is synchronized in case of failover. 44 This document defines a protocol to provide this synchronization 45 between two servers. One server is designated the ''primary'' server, 46 the other is the ''secondary'' server. Additionally, this document 47 describes a protocol for the automatic transfer of control from the 48 primary to the secondary in the case of failure (failover), as well 50 DRAFT DHCP Failover Protocol November 1997 52 as the re-establishment of control by the primary server. 54 1.0 Introduction 56 As the use of DHCP servers in networked environments grows, the 57 dependency of those networks on the DHCP server increases. This is 58 particularly true of the hosts that receive their configuration 59 information from the DHCP server. Therefore, it is very important to 60 be able to provide reliable, continuous availability of DHCP 61 services. 63 This specification describes a protocol to support automatic failover 64 from a primary to its secondary server. The failover mechanism 65 allows the secondary server to perform DHCP actions while the primary 66 is down. Additionally, the protocol defines how control is passed 67 back to the primary when it becomes operational again. 69 In providing the specification for the failover, the protocol 70 specifies how to guarantee reliable delivery of changes to the 71 secondary. This is required to synchronize the secondary's lease 72 data with that of the primary. The protocol further specifies a 73 mechanism for determining the state (operational or not) of the 74 primary server. The secondary will be able to automatically service 75 DHCP requests upon failover. When the primary server becomes 76 available again, the secondary will convey any changes that occurred 77 since the time of failover back to the primary prior to the primary 78 becoming operational. 80 1.1 Requirements 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC 2119]. 86 1.2 Terminology 88 This document uses the following terms: 90 o "DHCP client" or "client" 92 A DHCP client is an Internet host using DHCP to obtain 93 configuration parameters such as a network address. 95 o "DHCP server" or "server" 97 A DHCP server is an Internet host that returns configuration 99 DRAFT DHCP Failover Protocol November 1997 101 parameters to DHCP clients. 103 o "primary server" or "primary" 105 A DHCP server configured to provide primary service to a set of 106 DHCP clients. 108 o "secondary server" or "secondary" 110 A DHCP server configured to act as a backup to a primary server; 111 the secondary answers requests from DHCP clients only if its 112 primary is unable to respond. 114 o "bindings database" 116 The collection of bindings managed by a primary and secondary. 118 2.0 Protocol Summary 120 The protocol necessary in providing redundant/failover servers can be 121 grouped in three areas: 123 o Messages to keep the secondary server's lease data synchronized 124 with that of the primary so that when failover occurs, there is no 125 degradation of service 127 o Messages that allow the secondary to determine the operational 128 state of the primary, so as to know when to start servicing DHCP 129 traffic 131 o Messages that are used to coordinate the primary regaining control 132 when it has become available again. 134 2.1 Primary keeps secondary lease data synchronized 136 The messages for keeping the secondary's lease data up to date 137 include the following: 139 DHCPBNDADD - Primary notifies secondary of new binding 140 DHCPBNDUPD - Primary notifies secondary of modified binding 141 (e.g., extended lease) 142 DHCPBNDDEL - Primary notifies secondary of deleted binding 143 (e.g., expired or released lease) 145 In response to any of the above messages, the secondary server will 146 respond to the primary with a message describing the status of the 147 binding addition, modification, or deletion. 149 DRAFT DHCP Failover Protocol November 1997 151 DHCPBNDACK - Positive acknowledgment of binding change 152 DHCPBNDNAK - Negative acknowledgment of binding change 154 2.2 Determination of operational state of a server 156 In order to determine the state of a given server, a participant can 157 use the following message to poll (or "ping") the server: 159 DHCPPOLL - Check if server is operational 161 In response to the DHCPPOLL message, the participant will listen for 162 the following: 164 DHCPPRPL - Poll reply 166 2.3 Primary requests control from the secondary 168 After a failover, when the primary server is restarted, the following 169 messages are used to coordinate the primary taking control back from 170 the secondary: 172 DHCPCTLREQ - Request for control 173 DHCPCTLRET - Return of control initiated 174 DHCPCTLACK - Return of control completed 176 3 Message formats and semantics 178 The failover protocol messages are encoded as a DHCP/BOOTP option in 179 a DHCP message. A DHCP message carrying a failover protocol message 180 carries only the failover protocol message option and no other 181 options. The DHCP message is unicast from the source to the 182 destination. 184 The option code for these messages is TBD. Within each failover 185 protocol message, the specific message type is indicated by an option 186 subcode in the first octet of the data area of the option. The 'len' 187 field includes the number of octets in the option subcode byte and in 188 any additional data carried in the failover protocol message. 189 Bindings are encoded in a format that is TBD. 191 DISCUSSION 193 The use of the REQUEST/REPLY field in the DHCP message header and 194 the UDP port to be used needs to be considered. 196 The use of existing DHCP options and header fields to encode 198 DRAFT DHCP Failover Protocol November 1997 200 bindings needs to be considered. 202 The sender places a 32-bit number in the DHCP header 'xid' field to 203 uniquely identify each failover protocol message. The receiver 204 copies the contents of the 'xid' field into any reply or 205 acknowledgment message. 207 The sender is responsible for reliable transmission and any 208 retransmission. 210 3.1 Primary keeps secondary lease data synchronized 212 DHCPBNDADD 214 ------------------------------------------ 215 | XX | len | 1 | Binding information (TBD) 216 ------------------------------------------ 218 The primary sends a DHCPBNDADD message to inform the secondary of a 219 binding that has been added to the primary's set of bindings. 221 DHCPBNDUPD 223 ------------------------------------------ 224 | XX | len | 2 | Binding information (TBD) 225 ------------------------------------------ 227 The primary sends a DHCPBNDUPD message to inform the secondary of a 228 binding that has been changed in the primary's set of bindings. 230 DHCPBNDDEL 232 ------------------------------------------ 233 | XX | len | 3 | Binding information (TBD) 234 ------------------------------------------ 236 The primary sends a DHCPBNDDEL message to inform the secondary of a 237 binding that has been deleted from the primary's set of bindings. 239 DHCPBNDACK 241 -------------- 242 | XX | 1 | 4 | 243 -------------- 245 The secondary sends a DHCPBNDACK message to the primary to inform the 246 primary that the binding change request identified by the 'xid' field 248 DRAFT DHCP Failover Protocol November 1997 250 has successfully been completed. 252 DHCPBNDNAK 254 -------------- 255 | XX | 1 | 5 | 256 -------------- 258 The secondary sends a DHCPBNDNAK message to the primary to inform the 259 primary that the secondary could not complete the binding change 260 request. For example, the secondary would send a DHCPBNDNAK in 261 response to a DHCPBNDUPD request for which the secondary had no 262 recorded binding. 264 DISCUSSION 265 The use of an additional field to indicate the reason for the 266 DHCPBNDNAK message should be considered. 268 3.2 Determination of operational state of a server 270 DHCPPOLL 272 ---------------------- 273 | XX | 2 | 6 | flags | 274 ---------------------- 276 A DHCP participant sends a DHCPPOLL message to a server to determine 277 whether that server is currently operational. 279 A DHCP secondary periodically sends a DHCPPOLL to its primary to 280 determine if the primary is currently operational. 282 A DHCP primary sends a DHCPPOLL to its secondary if the primary needs 283 to determine if the secondary is operational. 285 A DHCP client sends a DHCPPOLL to a DHCP server to determine if the 286 server is currently operational. 288 The flags octet is defined as follows: CRRRRRRR, where the secondary 289 sets the 'C' bit to 1 to indicate that it has taken control of the 290 bindings database, and the 'R' bits are reserved for future use. 292 DHCPPRPL 294 ---------------------- 295 | XX | 2 | 7 | flags | 296 ---------------------- 298 DRAFT DHCP Failover Protocol November 1997 300 A DHCP participant replies to a DHCPPOLL message with a DHCPPRPL 301 message. The sender copies the 'xid' field from the DHCPPOLL message 302 header into the 'xid' field in the DHCPPRPL message, 304 The flags octet is defined as follows: ERRRRRRR, where the primary 305 sets the 'E' bit to 1 (in response to a DHCPPOLL message with the 'C' 306 bit set to 1) to indicate to the secondary that the primary has not 307 relinquished control of the database. See section 4 for additional 308 details. 310 DISCUSSION 312 The DHCPPOLL and DHCPPRPL messages might also be useful to DHCP 313 clients to aid in determining the availability of specific DHCP 314 servers. Such use would avoid overloading the DHCPDISCOVER 315 message. 317 3.3 Primary requests control from the secondary 319 DHCPCTLREQ 321 -------------- 322 | XX | 1 | 8 | 323 -------------- 325 A primary sends a DHCPCTLREQ message to its secondary to request 326 control of the bindings database from the secondary. 328 DHCPCTLRET 330 -------------- 331 | XX | 1 | 9 | 332 -------------- 334 A secondary sends a DHCPCTLRET to its primary to begin the process of 335 returning control of the bindings database to the secondary. After 336 sending the DHCPCTLRET message, the secondary sends a sequence of 337 DHCPBNDADD, DHCPBNDUPD and DHCPBNDDEL messages to synchronize the 338 primary's bindings database with the secondary's database. 340 DHCPCTLACK 342 --------------- 343 | XX | 1 | 10 | 344 --------------- 346 A secondary sends a DHCPCTLACK to its primary to indicate that the 347 secondary has finished returning control to the primary. 349 DRAFT DHCP Failover Protocol November 1997 351 DISCUSSION 353 Primary and secondary servers may need to exchange some additional 354 information in DHCPCTLREQ, DHCPCTLRET and DHCPCTLACK messages. 355 This information would be encoded in an additional 'flags' or 356 'data' field added to the control messages. 358 The synchronization essentially requires a reliable transmission 359 protocol using DHCPBND* and DHCPBNDACK messages. An alternative 360 to using DHCPBND* messages to transfer bindings updates to the 361 primary would be to devise a separate transfer protocol based on 362 TCP. 364 4 Exchange of control between primary and secondary 366 The primary and secondary servers coordinate the exchange control 367 over the bindings database through the use of DHCPPOLL and DHCPCTLREQ 368 messages. In normal operation: 370 o the primary sends notification of each change to its bindings 371 database to the secondary, and the secondary keeps its bindings 372 database synchronized with the primary's database 374 o the secondary periodically sends DHCPPOLL messages to the primary, 375 and the primary responds to each DHCPPOLL message with a DHCPPRPL 376 message 378 If the secondary does not receive a DHCPPRPL response message, the 379 secondary takes control of the bindings database and begins 380 answering requests from DHCP clients. 382 DISCUSSION 384 The conditions under which a secondary takes control of the 385 bindings database, e.g., the number of consecutive missing 386 acknowledgments, should be configurable in the secondary by the 387 DHCP administrator. 389 The secondary records any changes it makes to the bindings database 390 while it has control. The secondary continues to send DHCPPOLL 391 messages to the primary, with the 'D' bit set. 393 To regain control of the bindings database, e.g., after the primary 394 server has failed, the primary sends a DHCPCTLREQ message to the 395 secondary. The secondary stops answering DHCP client requests, and 396 responds to its primary with a DHCPCTLRET message. After sending 397 the DHCPCTLRET message, the secondary sends DHCPBND* messages for 398 each of the changes it has made to the bindings database. The 400 DRAFT DHCP Failover Protocol November 1997 402 primary sends a DHCPBNDACK for each of the DHCPBND* messages it 403 receives. The secondary completes the transfer of control by 404 sending a DHCPCTLACK message to its primary. 406 If the primary server has not failed and has been answering DHCP 407 client requests, and receives a DHCPPOLL message from its secondary 408 with the 'D' bit set, then both the primary and the secondary have 409 been answering DHCP client requests, and their bindings databases 410 may be unsynchronized. In this situation, the primary responds to 411 the secondary with a DHCPPRPL message with the 'E' bit set. Both 412 the primary and secondary servers notify a network administrator, 413 who must take steps to manually resynchronize the two bindings 414 databases. 416 DISCUSSION 418 It may be appropriate to state that, under administrator 419 control, the primary and secondary both stop some or all DHCP 420 services when the servers discover that both have been 421 allocating DHCP addresses simultaneously and their databases are 422 potentially unsynchronized. 424 5 Acknowledgments 426 6 References 428 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", RFC 2119, March 1997. 431 [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", 432 RFC2131, March 1997. 434 [RFC 2132] Droms, R., "DHCP Options and BOOTP Vendor Extensions", 435 RFC2132, March 1997. 437 7 Security Considerations 439 8 Authors' Addresses 441 Greg Rabil, Mike Dooley, Arun Kapur 442 Quadritek Systems, Inc. 443 10 Valley Stream Parkway, Quite 240 444 Malvern, PA 19355 446 Phone: (800) 408-2747 447 E-mail: grabil@quadritek.com 448 mdooley@quadritek.com 449 akapur@quadritek.com 451 DRAFT DHCP Failover Protocol November 1997 453 Ralph Droms 454 323 Dana Engineering 455 Bucknell University 456 Lewisburg, PA 17837 458 Phone: (717) 524-1145 459 E-mail: droms@bucknell.edu