idnits 2.17.1 draft-ietf-dhc-safe-failover-proto-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-25) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 a Security Considerations section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 219 instances of lines with control characters in the document. ** The abstract seems to contain references ([3], [RFC2131], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 433: '... The MDLI MAY be configurable, b...' RFC 2119 keyword, line 434: '... MUST be known to both the prima...' RFC 2119 keyword, line 436: '...e primary server MUST record in its st...' RFC 2119 keyword, line 475: '... server MUST ensure that the second...' RFC 2119 keyword, line 569: '...e, either server MUST wait for the MDL...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (September 1998) is 9354 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) -- Looks like a reference, but probably isn't: 'RFC 2131' on line 30 == Unused Reference: '2' is defined on line 1282, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1288, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-dhc-failover-00 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-01) exists of draft-ietf-dhc-security-arch-00 -- Possible downref: Normative reference to a draft: ref. '4' Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kinnear 3 INTERNET DRAFT American Internet Corporation 4 March 1998 5 Expires September 1998 7 DHCP Safe Failover Protocol 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute work- 15 ing documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 The DHCP protocol [RFC 2131] [1] allows multiple DHCP servers. A 31 recent draft, the DHCP Failover Protocol [3], has been distributed 32 which is designed to provide a redundant DHCP solution. While 33 clearly a work in progress, it is equally clear that it can be made 34 to work and meet the goals that the authors have set for it. One of 35 the goals of the Failover protocol is that it should avoid duplicate 36 IP address allocations, except under some rare circumstances. While 37 this approach may be quite reasonable in a wide variety of environ- 38 ments, some environments require a DHCP redundancy solution which can 39 (optionally) ensure that no possibility of duplicate IP address allo- 40 cation exists. 42 The Safe Failover protocol is designed to build on top of the 43 Failover protocol, and add to it certain protocol exchanges, prac- 44 tices and algorithms which will create a DHCP redundancy solution 45 which avoids duplicate IP address allocation. 47 1. Introduction 49 The DHCP Safe Failover protocol is designed to layer on top of the 50 DHCP Failover protocol, and in like manner support automatic failover 51 from a primary to a secondary server. 53 In certain unusual failure cases servers implementing the DHCP 54 Failover protocol can end up allocating the same IP address to two 55 clients. The DHCP Safe Failover protocol is designed to prevent this 56 situation from occurring. 58 1.1. The Language of Requirements 60 Throughout this document, the words that are used to define the sig- 61 nificance of particular requirements are capitalized. These words 62 are: 64 o "MUST" 66 This word or the adjective "REQUIRED" means that the item is an 67 absolute requirement of this specification. 69 o "MUST NOT" 71 This phrase means that the item is an absolute prohibition of 72 this specification. 74 o "SHOULD" 76 This word or the adjective "RECOMMENDED" means that there may 77 exist valid reasons in particular circumstances to ignore this 78 item, but the full implications should be understood and the case 79 carefully weighed before choosing a different course. 81 o "SHOULD NOT" 83 This phrase means that there may exist valid reasons in particu- 84 lar circumstances when the listed behavior is acceptable or even 85 useful, but the full implications should be understood and the 86 case carefully weighed before implementing any behavior described 87 with this label. 89 o "MAY" 91 This word or the adjective "OPTIONAL" means that this item is 92 truly optional. One vendor may choose to include the item 93 because a particular marketplace requires it or because it 94 enhances the product, for example; another vendor may omit the 95 same item. 97 1.2. Terminology 99 This document uses the following terms: 101 o "DHCP client" or "client" 103 A DHCP client is an Internet host using DHCP to obtain configura- 104 tion parameters such as a network address. 106 o "client" 108 Whenever the term client is used in this draft, it refers to a 109 DHCP client (and not a server communicating with another server 110 using this protocol). 112 o "DHCP server" or "server" 114 A DHCP server is an Internet host that returns configuration 115 parameters to DHCP clients. 117 o "binding" 119 A binding is a collection of configuration parameters, including 120 at least an IP address, associated with or "bound to" a DHCP 121 client. Bindings are managed by DHCP servers. 123 o "subnet address pool" 125 A subnet address pool is the set of IP address which is associ- 126 ated with a particular network number and subnet mask. In the 127 simple case, there is a single network number and subnet mask and 128 a set of IP addresses. In the more complex case (sometimes 129 called "secondary subnets"), several (apparently unrelated) net- 130 work number and subnet mask combinations with their associated IP 131 addresses may all be configured together into one subnet address 132 pool. 134 o "primary server" or "primary" 136 A DHCP server configured to provide primary service to a set of 137 DHCP clients for a particular set of subnet address pools. 139 o "secondary server" or "secondary" 140 A DHCP server configured to act as backup to a primary server for 141 a particular set of subnet address pools. 143 o "stable storage" 145 Every DHCP server is assumed to have some form of what is called 146 "stable storage". Stable storage is used to hold information 147 concerning IP address bindings (among other things) so that this 148 information is not lost in the event of a server failure which 149 requires restart of the server. 151 2. Goals and Limitations of the Protocol 153 2.1. Goals and Requirements 155 1. Implementations of this protocol must work with existing DHCP 156 client implementations based on the DHCP protocol [1]. 158 2. Implementations of the protocol must work with existing BOOTP 159 relay implementations. 161 3. Avoid binding an IP address to a client while that binding is 162 currently valid for another client. In other words, don't allo- 163 cate the same IP address to two clients. 165 4. Ensure that an existing client can keep its existing IP address 166 binding if it can communicate with either the primary or sec- 167 ondary DHCP server implementing this protocol -- not just 168 whichever server that originally offered it the binding. 170 5. Do not add any requirement for communication with another server 171 to the processing between a DHCPDISCOVER and a DHCPOFFER or 172 between a DHCPREQUEST and a DHCPACK. 174 DISCUSSION: 176 The implications of this goal are that "lazy" update of IP 177 address binding information is required. In other words, 178 because of this goal, the protocol cannot require one server 179 to update another server with information concerning a new IP 180 address binding prior to sending the DHCPACK to the DHCP 181 client. 183 6. Ensure that a new client can get an IP address from some server. 185 7. Ensure that in the face of partition, where servers continue to 186 run but cannot communicate with each other, the above goals and 187 requirements may be met. In addition, when the partition condi- 188 tion is removed, allow graceful automatic re-integration without 189 requiring human intervention. 191 8. If either primary or secondary server loses all of the informa- 192 tion that is has stored in stable storage, it should be able to 193 refresh its stable storage from the other server. 195 2.2. Limitations of this Protocol 197 1. Determination of permanent server failure. 199 The protocol provides a way to detect when the primary and sec- 200 ondary servers cannot communicate, but once this condition has 201 been detected, does not provide any way to further distinguish 202 between network failure and direct failure of one of the 203 servers. 205 2. Some additional IP addresses required. 207 In order to handle the failure case where both servers are able 208 to communicate with DHCP clients, but unable to communicate with 209 each others, each server has to have a small number of IP 210 addresses that it can use to allocate to newly arrived DHCP 211 clients during such a period. The number of additional IP 212 addresses required is based only on the arrival rate of new DHCP 213 clients, and is not influenced in any way by the total number of 214 DHCP clients supported by the server pair. 216 3. Not a load-sharing solution. 218 This protocol does not provide any solutions to load-sharing, 219 since only one DHCP server in the pair is supposed to be commu- 220 nicating with DHCP clients. 222 3. Protocol Overview 224 The DHCP Failover Protocol [3] presents a protocol designed to pro- 225 vide a redundant DHCP capability. It makes a number of simplifying 226 assumptions in order to allow specification of a straightforward, 227 easy to understand and relatively easy to implement protocol. 229 Some environments need a protocol which provides a redundant DHCP 230 solution in which the possibility of duplicate IP address allocation 231 is significantly reduced from that provided by the Failover protocol. 232 These are typically environments where the cost of correcting a pos- 233 sible duplication IP address assignment is sufficiently great that it 234 is worth considerable effort to ensure that such a condition does not 235 occur. 237 There are two cases where the Failover protocol [3] can end up with 238 duplicate IP address allocations: 240 o Primary server crash before "lazy" update: 242 In the case where the primary server sends an ACK to a client for 243 a newly allocated IP address and then crashes prior to sending 244 the corresponding update to the secondary server, the secondary 245 server will have no record of the IP address allocation. When 246 the secondary server takes over, it may well try to allocate that 247 IP address to a different client. In the case where the first 248 client to receive the IP address is not on the net at the time 249 (yet while there was still time to run on its lease), an ICMP 250 echo (i.e., ping) will not prevent the secondary server from 251 allocating that IP address to different client. 253 A more likely and subtle version of this problem is where the 254 primary server crashes after extending a client's lease time, and 255 before updating the secondary with new time using a lazy update. 256 After the secondary takes over, if the client is not connected to 257 the network the secondary will believe the client's lease has 258 expired when, in fact, it has not. In this case as well, the IP 259 address can be reallocated to a different client. 261 o Network partition where servers can't communicate but each can 262 talk to clients: 264 Several conditions are required for this situation to occur. 265 First, due to a network failure, the primary and secondary 266 servers cannot communicate. As well, some of the clients of the 267 primary server must be able to communicate with the primary 268 server, and some of the clients of the primary server must now 269 only be able to communicate with the secondary server. When this 270 condition occurs, both primary and secondary servers are going to 271 allocate IP addresses for new clients from the same pool of 272 available addresses. At some point, then, two clients will end 273 up being allocated the same IP address. This will cause poten- 274 tially serious problems when the network failure that created 275 this situation is corrected. 277 While the Failover protocol has protocol messages to detect this 278 condition when communications are restored, in some environments 279 preventing it is preferable to detecting it. 281 The remainder of section 3 discusses the concepts employed to solve 282 the problem presented by each of the above situations. In order to 283 define and explain these concepts, this protocol defines states into 284 which both the primary and secondary server may transition. Section 285 3.1 briefly discusses these states, and then section 3.2 goes on to 286 discuss how the problems presented above are solved. 288 3.1. Primary and Secondary States 290 In order to allow conceptual discussion and rigorous specification of 291 the safe failover protocol, several states are defined into which 292 either the primary or secondary server may transition. These states 293 are briefly discussed in this section. Full specification of the 294 each server's actions in each state is deferred until section 4 for 295 the primary server and section 5 for the secondary server. 297 The possible server states are: 299 o NORMAL State: 301 NORMAL state is the state used by a server when it can communi- 302 cate with the other server in the primary-secondary server pair. 304 When in this state, the primary responds to DHCP clients 305 requests, while the secondary does not. 307 o COMMUNICATION-INTERRUPTED state: 309 COMMUNICATION-INTERRUPTED state is the state into which a server 310 goes automatically whenever it cannot communicate with the other 311 server. Both the primary and secondary servers can go into this 312 state, although the behavior changes that result are different. 313 Primary and secondary servers cycle automatically (i.e., without 314 administrative intervention) between NORMAL and COMMUNICATION- 315 INTERRUPTED state as the network connection between them under- 316 goes failures and then becomes operational or as the other server 317 in the pair cycles between operational and non-operational. 319 No duplicate IP address allocation can occur while the servers 320 cycle between these states. 322 In this state both servers respond to DHCP client requests. When 323 allocating new IP addresses, each server allocates from a differ- 324 ent pool. When responding to renewal requests, each server will 325 allow continued renewal of a DHCP client's current lease on an IP 326 address. 328 o PARTNER-DOWN state: 330 PARTNER-DOWN state is a state either server can enter. Once a 331 server has entered NORMAL state, the PARTNER-DOWN state is 332 entered only on command of an external agency (typically an 333 administrator of some sort) or after the expiration of an exter- 334 nally configured minimum safe-time after the beginning of COMMU- 335 NICATION-INTERRUPTED state. 337 When in this state, the server ceases to operate in such a way 338 such that it assumes that the other server could still be opera- 339 tional and communicating to a different set of clients, but 340 instead assumes that it is the only server operating. 342 Only one server should be operating in this state at a time. 344 The server in this state will respond to DHCP client requests. 345 It will allow renewal of all outstanding leases on IP addresses, 346 and will allocate IP addresses from its own pool, and after a 347 fixed period of time, it will allocate IP addresses from the set 348 of all available IP addresses. 350 The server will transition out of PARTNER-DOWN state after auto- 351 matic re-integration the companion server is complete. This 352 automatic re-integration will typically be initiated by the 353 restart of the server which was down. 355 o RECOVER state: 357 This state indicates that the server has no information in its 358 stable storage. A server in this state will attempt to refresh 359 its stable storage from the other server. 361 o POTENTIAL-CONFLICT state: 363 This state indicates that the two servers are attempting to rein- 364 tegrate with each other, but at least one of them was running in 365 a state that did not guarantee automatic reintegration would be 366 possible. In POTENTIAL-CONFLICT state the servers may determine 367 that the same IP address has been offered and accepted by two 368 different DHCP clients. 370 o SYNC state: 372 In this state, the secondary server attempts to synchronize its 373 stable storage with the primary server. Both the primary and 374 secondary may have information that the other lacks. 376 3.2. Conceptual Overview 378 At the beginning of this section, two specific scenarios were dis- 379 cussed that need to be handled by the safe failover protocol. Now 380 that an introduction to the possible server states has been given, 381 the techniques used to solve these problems may be explained. 383 The following techniques are used: 385 o Control of lease time. 387 This protocol requires a DHCP server to deal with several differ- 388 ent lease intervals and places specific restrictions on their 389 relationships. The purpose of these restrictions is to allow the 390 other server in the pair to be able to make certain assumptions. 392 The different lease times are: 394 o desired client lease interval 396 The desired client lease interval is the lease interval that 397 the DHCP server would like to give to the DHCP client in the 398 absence of any restrictions imposed by the safe failover proto- 399 col. Its determination is outside of the scope of this proto- 400 col. Typically this is the result of external configuration of 401 a DHCP server. 403 o actual client lease interval 405 The actual client lease internal is the lease interval that 406 that DHCP server gives out to the DHCP client. It may be 407 shorted than the desired client lease interval (as explained 408 below). 410 o primary server lease interval 412 The primary server lease interval is the interval after which 413 the primary server believes that DHCP client's lease will 414 expire. 416 o desired secondary server lease interval 418 The desired secondary server lease interval is the interval the 419 primary server tells to the secondary server after which the 420 lease will expire. 422 o acknowledged secondary server lease interval 424 The acknowledged secondary server lease interval is the inter- 425 val the secondary server has most recently acknowledged. 427 The key restriction (and guarantee) that the primary server makes 428 with respect to lease intervals is that the actual client lease 429 interval never exceeds the acknowledged secondary server lease 430 interval (if any) by more than a fixed amount. This fixed amount 431 is called the "maximum delta lease interval" (MDLI). 433 The MDLI MAY be configurable, but for correct server operation it 434 MUST be known to both the primary and secondary servers. 436 The primary server MUST record in its state both the primary 437 server lease interval and the most recently acknowledged sec- 438 ondary server lease interval. It is assumed that the desired 439 client lease interval can be determined through techniques out- 440 side of the scope of this protocol. 442 DISCUSSION: 444 This protocol mandates no particular detailed algorithms con- 445 cerning these lease intervals, as long as the key relation- 446 ship of the actual client lease interval < ( acknowledged 447 secondary server lease interval + MDLI ). 449 In the interests of clarity, however, let's examine a spe- 450 cific example. The MDLI in this case is 1 hour. The desired 451 client lease interval is 3 days. In operation this might 452 work as follows: 454 When a primary server makes an offer for a new lease on an IP 455 address to a DHCP client, it determines the desired client 456 lease interval (in this case, 3 days). It then examines the 457 acknowledged secondary lease interval (which in this case is 458 zero). Since the actual client lease interval can not be 459 allowed to exceed the current secondary lease interval by 460 more than the MDLI, the offer made to the DHCP client (the 461 actual client lease interval) is for (essentially) the MDLI, 462 1 hour. 464 Once the primary server has performed the ACK to the DHCP 465 client, it will update the secondary server with the lease 466 information. However, the secondary server lease interval 467 will be composed of the current actual client lease interval 468 + ( 1.5 * desired client lease interval). Thus, the sec- 469 ondary server is updated with a lease interval of 4.5 days + 470 1 hour. 472 When the primary server receives an ACK to its update of the 473 secondary server's lease interval, it records that as the 474 acknowledged secondary server lease interval. The primary 475 server MUST ensure that the secondary server has received and 476 recorded in its stable storage the secondary server lease 477 interval. 479 When the DHCP client attempts to renew at T2 (approximately 480 one half an hour from the start of the lease), the primary 481 server again determines the desired client lease time, which 482 is still 3 days. It then compares this with the remaining 483 acknowledged secondary server lease interval (adjusting for 484 the time passed since the secondary server was last updated), 485 which is 4.5 days + .5 hours. The actual client lease inter- 486 val can now be equal to the desired client lease interval as 487 it is less than the acknowledged secondary lease interval. 489 When the primary DHCP server updates the secondary DHCP 490 server after the DHCP client's renewal ACK is complete, it 491 will calculate the secondary server lease interval as the 492 actual client lease interval (3 days this time) + .5 the 493 desired client lease interval (1.5 days). In this way, the 494 primary attempts to have the secondary always "lead" the 495 client in its understanding of the client's lease interval. 497 Once the initial actual client lease interval of the MDLI is 498 past, the protocol operates effectively like the DHCP proto- 499 col does today in its behavior concerning lease intervals. 500 However, the guarantee that the actual client lease interval 501 will never exceed the acknowledged secondary server lease 502 interval by more than the MDLI allows full recovery from 503 failures in lazy update. 505 The key problem with lazy update (in the absence of the control 506 of time described above) is that if, after updating a client with 507 a particular lease interval, the primary server fails in the 508 small window before updating the secondary server, the secondary 509 server will believe that a lease has expired even though the 510 client still retains a valid lease on that IP address. 512 Even with the regime described above, the actual client lease 513 interval can exceed the secondary server lease interval -- but by 514 an amount less than or equal to the MDLI. 516 In the case where the secondary needs to take over from the pri- 517 mary, in COMMUNICATIONS-INTERRUPTED state the secondary will not 518 reallocate any IP addresses from one client to a different 519 clients. When transitioning to the PARTNER-DOWN state (where the 520 secondary is allowed to reallocate IP addresses), the secondary 521 need merely wait the MDLI before reallocating any IP addresses 522 from one client to another. 524 In this way, any clients which have a lease on an IP address with 525 a lease time greater that than known by the secondary will either 526 have contacted the secondary during that time or the their lease 527 will have expired. 529 Two guarantees are required for this to be effective. The first 530 is the just described guarantee concerning actual client lease 531 time and its difference from the secondary server lease time. 532 The second is that the secondary server must be able to depend on 533 the fact that, after transition to PARTNER-DOWN state, the pri- 534 mary server is guaranteed to not respond to DHCP clients (as 535 described in section 3.1). 537 o Secondary creates its own address pool 539 When in COMMUNICATION-INTERRUPTED state, the secondary needs to 540 be able to allocate IP address to new clients appearing on the 541 network to which it can communicate. Were the secondary to sim- 542 ply allocate apparently available IP addresses, it could conflict 543 with the primary, which might be operating and simply unable to 544 communicate with the secondary. 546 In order to allow the secondary to respond to new DHCP clients 547 appearing on the network during periods when it is in the COMMU- 548 NICATIONS-INTERRUPTED state, the secondary must acquire from the 549 primary a set of IP addresses which it can use for this purpose. 550 In order to create this address pool, the secondary uses the 551 "Reply to" DHCP option to create and maintain the address pool. 552 (See Section 6.) 554 o Controlled re-allocation of IP addresses 556 Careful control of re-allocation of IP addresses is central to 557 the correct operation of this protocol. 559 When in NORMAL state the primary server must update the secondary 560 server whenever a lease expires or an IP address is released, and 561 it must ensure the secondary has been successfully updated before 562 offering the IP address of the expired or released IP address to 563 a different client. 565 When in COMMUNICATION-INTERRUPTED state, neither server will 566 allow an IP address previously used by one client to be offered 567 to a different client. 569 When in PARTNER-DOWN state, either server MUST wait for the MDLI 570 beyond the scheduled expiration of the lease for every IP address 571 before re-allocating that IP address to different DHCP client. 572 For IP addresses that are available (or have already expired), 573 the server must wait for at least the MDLI before allocating 574 available IP addresses from what was previously the "other" 575 server's pool of available IP addresses. 577 o Safe Period 579 Due to the restrictions imposed on each server while in COMMUNI- 580 CATIONS-INTERRUPTED state, long-term operation in this state is 581 not feasible for either server. One reason that these states 582 exist at all is to allow the servers to easily survive transient 583 network communications failures of a few minutes to a few days 584 (although the actual time periods will depend a great deal on the 585 DHCP activity of the network in terms of arrival and departure of 586 DHCP clients on the network). 588 Eventually, when the servers are unable to communicate, they will 589 have to move into a state where they no longer can re-integrate 590 without the some possibility of a duplicate IP address alloca- 591 tion. There are two ways that they can move into this state 592 (known as PARTNER-DOWN). 594 They can either be informed by external command that, indeed, the 595 partner server is down. In this case, there is no difficulty in 596 moving into the PARTNER-DOWN state since it is an accurate 597 reflection of reality and the protocol has been designed to oper- 598 ate correctly (even during reintegration) if, when in PARTNER- 599 DOWN state the partner is, indeed, down. 601 The other difficulty is when the servers are running unattended 602 for extended periods, and in this case the option is provided to 603 configure something called a "safe-period" into each server. 604 This OPTIONAL safe-period is the period after which either the 605 primary or secondary server will automatically transition to 606 PARTNER-DOWN from COMMUNICATIONS-INTERRUPTED state. If this 607 transition is completed and the partner is not down, then the 608 possibility of duplicate IP address allocations will exist. 610 The goal of the "safe-period" is to allow network operations 611 staff some time to react to a server moving into COMMUNICATIONS- 612 INTERRUPTED state. During the safe-period the only requirement 613 is that the network operations staff determine if both servers 614 are still running -- and if they are, to either fix the network 615 communications failure between them, or to take one of the 616 servers down before the expiration of the safe-period. 618 The length of the safe-period is installation dependent, and 619 depends in large part on the number of unallocated IP addresses 620 within the subnet address pool and the expected frequency of 621 arrival of previously unknown DHCP clients requiring IP 622 addresses. Many environments should be able to support safe- 623 periods of several days. 625 During this safe period, either server will allow renewals from 626 any existing client. The only limitation concerns the need for 627 IP addresses for the DHCP server to hand out to new DHCP clients 628 and the need to re-allocate IP addresses to different DHCP 629 clients. 631 The number of "extra" IP addresses required is equal to the 632 expected total number of new DHCP clients encountered during the 633 safe period. This is dependent only on the arrival rate of new 634 DHCP clients, not the total number of outstanding leases on IP 635 addresses. 637 In the unlikely event that a relatively short safe period of an 638 hour is all that can be used (given a dearth of IP addresses or a 639 very high arrival rate of new DHCP clients), even that can pro- 640 vide substantial benefits in allowing the DHCP subsystem to ride 641 through a minor problems that could occur and be fixed within 642 that hour. In these cases, no possibility of duplicate IP 643 address allocation exists, and re-integration after the failure 644 is solved will be automatic and require no operator intervention. 646 4. Primary Server Operation 648 The operation of the primary server is as specified in the Failover 649 protocol [3], with the exception of the following situations and 650 cases. 652 4.1. Primary Server Initialization 654 When the primary server starts, there are three possibilities: it 655 has never started before and therefore has no record of any previous 656 state nor of any client binding information; it has started before 657 and has a record of a previous state and possibly of some client 658 binding information; it has started before, but failed catastrophi- 659 cally, and now has no record of any previous state (nor of any client 660 binding information). 662 When the primary server starts, if it has any record of a previous 663 state, then if that state was NORMAL or COMMUNICATIONS-INTERRUPTED it 664 moves to COMMUNICATIONS-INTERRUPTED state. If that state was PART- 665 NER-DOWN or POTENTIAL-CONFLICT, then it moves to PARTNER-DOWN state. 666 If that state was RECOVER, then the primary server moves into the 667 RECOVER state. 669 If it has no record of any previous state, then either this is an 670 initial startup, or a recovery from a catastrophic failure where sta- 671 ble storage and all client binding information was lost. These are 672 distinguished by recovery from a catastrophic failure being indicated 673 by some external configuration indication to the primary server. If 674 this external indication is present, the primary server moves into 675 RECOVER mode and attempts to recover its client binding database from 676 the secondary server. If that indication is not present, the primary 677 server moves directly into PARTNER-DOWN state. 679 4.2. Primary Server State Transitions 681 Figure 4.2-1 is the diagram of the primary server's state transi- 682 tions. The remainder of this section contains information important 683 to the understanding of that diagram. 685 The server stays in the current state until all of the actions speci- 686 fied on the state transition are complete. If communications fails 687 during one of the actions, the server simply stays in the current 688 state and attempts a transition whenever the conditions for a transi- 689 tion are later fulfilled. 691 In the state transition diagram below, the "+" or "-" in the upper 692 right corner of each state is a notation about whether communication 693 is ongoing with the secondary server. The legend "responsive" and 694 "unresponsive" in each state indicates whether the primary server is 695 responsive to DHCP client requests in the respective state. 697 In the diagram state transition diagram below, when communication is 698 reestablished between the primary and secondary server, the primary 699 server must record the state of the secondary server when the commu- 700 nication was reestablished. If the state of the secondary server 701 changes while communicating, then the primary server moves through 702 the communications-failed transition, and into whatever state 703 results. It then immediately moves through whatever state transition 704 is appropriate given the current state of the secondary server. 706 DISCUSSION: 708 The point of this technique is simplicity, both in explanation of 709 the protocol and in its implementation. The alternative to this 710 technique of memory of partner state and automatic state transi- 711 tion on change of partner state is to have every state in the fol- 712 lowing diagram have a state transition for every possible state of 713 the partner. With the approach adopted, only the states in which 714 communications are reestablished require a state transition for 715 each possible partner state. 717 All state transitions of the primary server must be recorded in its 718 stable storage, and thus be available to the server after a server 719 restart. 721 Previous Primary State: 723 NORMAL or RECOVER PARTNER DOWN 724 COMMUNICATONS POTENTIAL CONFLICT 725 INTERRUPTED | 726 +---+ V | 727 | +----------------+ +-----------------+ 728 | | - | | - | 729 | | RECOVER | | PARTNER DOWN |<-----+ 730 | | (unresponsive) | | (responsive) | | 731 | +----------------+ +-----------------+ | 732 | | | | ^ | 733 | Comm. OK | Comm. OK | | 734 | Sec. State: | Sec. State: Comm. | 735 | | | V All Others Failed | 736 | | RECOVER +<---+ V | | 737 | All | | +-------------+ | 738 | Others | Comm. OK | POTENTIAL +| | 739 | | Note Sec. State: | CONFLICT | | 740 | | Poss. RECOVER |(responsive) |<---- | --+ 741 | V Error NORMAL +-------------+ | | 742 | Sec->Pri | Pri->Sec | | | 743 | Sync | Sync. Resolve Conflict | | 744 | | | V V | | 745 | Wait MDLI | +-----------------+ | | 746 | from Fail. | | + | External | | 747 | V V | NORMAL |-Command-->+ | 748 | +-----++------>| (responsive) | | | 749 | ^ +-----------------+ | | 750 | | | | | 751 | Pri<->Sec Comm. External | 752 | Sync Failed Command | 753 | | | or | 754 | Comm. OK | "Safe Period" | 755 | Sec. State: V expiration | 756 | NORMAL +-----------------+ | | 757 | COMM. INT. | - |---------->+ | 758 | RECOVER------| COMMUNICATIONS | | 759 | | INTERRUPTED | Comm. OK | 760 +------------------>| (responsive) |--Sec. State:--+ 761 +-----------------+ All Others 763 Figure 4.2-1: Primary server state diagram. 765 4.3. Primary Server in PARTNER-DOWN state 767 When it is in PARTNER-DOWN state, the primary server operates largely 768 as does a normal DHCP server, with none of the special algorithms 769 described below. In PARTNER-DOWN state the primary server MUST 770 respond to DHCP client requests. 772 Any available IP address tagged as belonging to the secondary server 773 (at entry to PARTNER-DOWN state) MUST NOT be used until the MDLI 774 beyond the entry into PARTNER-DOWN state has elapsed. 776 The primary server MUST NOT allocate an IP address to a DHCP client 777 different from that to which it was allocated at the entrance to 778 PARTNER-DOWN state until the MDLI beyond the its expiration time has 779 elapsed. If this time would be earlier than the current time plus 780 the MDLI, then the current time plus the MDLI is used. 782 Two options exist for lease times, with different ramifications flow- 783 ing from each. 785 If the primary server wishes the safe failover protocol to protect it 786 from loss of stable storage in any state, then it should adhere to 787 the restrictions on lease time discussed in section 3.2 and used in 788 COMMUNICATION-INTERRUPTED state, section 4.6, below. 790 If the primary server wishes to forego the protection of the safe 791 failover protocol in the event of loss of stable storage, then it 792 need recognize no restrictions on actual client lease times while in 793 PARTNER-DOWN state. 795 The primary server MUST poll the secondary server and attempt to 796 establish communications and synchronization with it. It does this 797 by attempting to update the secondary server with its existing bind- 798 ing information. 800 Once the primary succeeds in contacting the secondary server, the 801 primary checks the state of the secondary server. If the state of 802 the secondary server is RECOVER or NORMAL, then both servers have 803 been running in such a way that duplicate IP address allocations are 804 inhibited. In this case, the primary server updates the secondary 805 server with its client binding information, and moves into the NORMAL 806 state. 808 If, once contact has been established, the state of the secondary 809 server is anything other than RECOVER or NORMAL then the primary 810 server moves into the POTENTIAL-CONFLICT state. 812 4.4. Primary Server in RECOVER state 814 When primary server is initialized in the RECOVER state it expects to 815 refresh its stable storage from an existing secondary server. In 816 this state the primary server MUST NOT respond to DHCP client 817 requests. 819 When the primary server succeeds in contacting the secondary server, 820 if it determines that the secondary server is itself in the RECOVER 821 state (which indicates that the secondary server has no existing 822 client binding information), the primary server will move directly 823 into NORMAL state after signaling some kind of an error (since some 824 person had to explicitly start the primary server in RECOVER state to 825 refresh its lost client binding information from the secondary, and 826 the secondary had no state). 828 If the primary server determines that the secondary server is in any 829 state other than RECOVER, then the secondary server has some client 830 binding information that the primary server needs before it moves 831 into the NORMAL state. The primary server will attempt to refresh 832 its state from the secondary server, and it will remain in the 833 RECOVER state until it is successful in doing so. 835 The primary server MUST remain in RECOVER state until a period of at 836 least the MDLI has passed since the primary server was known to have 837 failed. This is to allow any IP addresses that were allocated by the 838 primary server prior to loss of primary server client binding infor- 839 mation in stable storage to contact the secondary server or to time 840 out. 842 DISCUSSION: 844 The actual requirement on this wait period in RECOVER is that it 845 start when the primary server went down, not necessarily when it 846 came back up. If the time when the primary server failed is 847 known, then it could be communicated to the recovering server, and 848 the wait period could be reduced to the MDLI less the difference 849 between the current time and the time the server failed. In this 850 way, the waiting period could be minimized. 852 4.5. Primary Server in NORMAL state 854 When in NORMAL state, the primary server takes the following actions 855 to implement the Safe Failover protocol: 857 o Lease Time Calculations 858 As discussed in section 3.2, "control of lease time", the lease 859 interval given to a DHCP client can never be more than the maxi- 860 mum delta lease interval greater than the acknowledged secondary 861 server lease interval. 863 As long as the primary server adheres to this constraint, the 864 specifics of the lease intervals that it gives to either the DHCP 865 client or the secondary DHCP server are implementation dependent. 866 One possible approach is shown in section 3.2, but that particu- 867 lar approach is in no way required by this protocol. 869 o Lazy Update of Secondary Server 871 After an ACK of a IP address binding, the primary server attempts 872 to update the secondary with the binding information. The lease 873 time used in the update of the secondary MUST be at least that 874 given to the DHCP client in the DHCPACK. It MAY, however, be 875 longer. 877 o Reallocation of IP Addresses Between Clients 879 As specified in the Failover protocol, whenever a client binding 880 is released or expires, an DHCPBNDDEL message must be sent to the 881 secondary server. 883 However, until a DHCPBNDACK is received for this message, the IP 884 address cannot be allocated to another client. 886 4.6. Primary Server in COMMUNICATION-INTERRUPTED Mode 888 When in COMMUNICATIONS-INTERRUPTED state the primary server operates 889 in such a way that correct operation is ensured even if the secondary 890 server is still up and operational, but unable to communicate to the 891 secondary server. When communications are reestablished between the 892 primary and secondary servers, if both are still in COMMUNICATIONS- 893 INTERRUPTED state, then the re-integration of their operation will 894 proceed automatically and without human intervention. The protocol 895 is designed to ensure that reintegration will proceed in an error 896 free manner and that no actions taken by either server while in COM- 897 MUNICATIONS-INTERRUPTED state will cause problems during re- 898 integration. 900 The primary server operates in COMMUNICATION-INTERRUPTED state as it 901 does in NORMAL state. 903 However, since it cannot communicate with the secondary in this 904 state, the acknowledged-secondary-lease-time will not be updated in 905 any new bindings. This is likely to eventually cause the actual- 906 client-lease-times to be the current-time plus the MDLI (unless this 907 is greater than the desired-client-lease-time). 909 The primary server can simply queue updates to the secondary on com- 910 munication interruption and stay in the NORMAL state. If, when com- 911 munications with the secondary is reestablished, the secondary 912 remains in the NORMAL state as well, then the queued updates for the 913 secondary will simply be processed. 915 COMMUNICATION-INTERRUPTED state for the primary server is a signal 916 that it has stopped queuing updates to the secondary, and is able to 917 respond to a variety of possible secondary states. 919 It is anticipated that some alarm condition would be raised upon the 920 transition from NORMAL state to COMMUNICATION-INTERRUPTED state. 922 Once the primary server has been in COMMUNICATION-INTERRUPTED state 923 for a period equal to the safe-period, then it can (if configured to 924 do so) transition into the PARTNER-DOWN state. An external command 925 may also force a transition to PARTNER-DOWN state. 927 5. Secondary Server Operation 929 The operation of the secondary server is as specified in the Failover 930 protocol [3], with the exception of the following situations and cases. 931 Note that the secondary server responds to DHCP client requests only in 932 the PARTNER-DOWN and COMMUNICATIONS-INTERRUPTED states. 934 5.1. Secondary Server Initialization 936 When the secondary server starts, there are three possibilities: it 937 has never started before and therefore has no record of any previous 938 state nor of any client binding information; it has started before 939 and has a record of a previous state and possibly of some client 940 binding information; it has started before, but failed catastrophi- 941 cally, and now has no record of any previous state (nor of any client 942 binding information). 944 When the secondary server starts, if it has any record of a previous 945 state, then if that state was NORMAL, COMMUNICATIONS-INTERRUPTED, or 946 SYNC, it moves to COMMUNICATIONS-INTERRUPTED state. If that state 947 was PARTNER-DOWN or POTENTIAL-CONFLICT, then it moves to PARTNER-DOWN 948 state. In all other cases (both other previous states and the cases 949 where there is no record of a previous state), the secondary server 950 moves into the RECOVER state. 952 5.2. Secondary Server State Transitions 954 The server stays in the current state until all of the actions speci- 955 fied on the state transition are complete. If communications fails 956 during one of the actions, the server simply stays in the current 957 state and attempts a transition whenever the conditions for a transi- 958 tion are later fulfilled. 960 In the state transition diagram below, the "+" or "-" in the upper 961 right corner of each state is a notation about whether communication 962 is ongoing with the primary server. The legend "responsive" and 963 "unresponsive" in each state indicates whether the secondary server 964 is responsive to DHCP client requests in the respective state. 966 In the state transition diagram below, when communication is reestab- 967 lished between the secondary and primary server, the secondary server 968 must record the state of the primary server when the communications 969 was reestablished. If the state of the primary server changes while 970 communicating, then the secondary server moves through the communica- 971 tions-failed transition, and into whatever state results. At that 972 time, it then immediately moves through whatever state transition is 973 appropriate for the current state of the primary server. 975 All state transitions of the secondary server must be recorded in its 976 stable storage, and thus be available to the server after a server 977 restart. 979 Previous Secondary State: 981 NORMAL RECOVER PARTNER DOWN 982 COMM. INT. POTENTIAL CONFLICT 983 SYNC | | 984 +---+ V V 985 | +----------------+ +-----------------+ 986 | | RECOVER - | | PARTNER DOWN - |<-----+ 987 | | (unresponsive) | | (responsive) | | 988 | +----------------+ +-----------------+ | 989 | | | | ^ | 990 | Comm. OK | Comm. OK | | 991 | Pri. State: | Pri. State: Comm. | 992 | | | V All Others Failed | 993 | | RECOVER +<---+ V | | 994 | | | | +--------------+ | 995 | | | Comm. OK | POTENTIAL + | | 996 | All | Pri. State: | CONFLICT | | 997 | Others | RECOVER |(unresponsive)|<--- | --+ 998 | | Note | +--------------+ | | 999 | | Poss. Sec->Pri | | | 1000 | V Error Sync. Resolve Conflict | | 1001 | Pri->Sec | V V | | 1002 | Sync | +-----------------+ | | 1003 | V V | NORMAL + |-External->+ | 1004 | +-----++------>| (unresponsive) | Command | | 1005 | ^ +-----------------+ | | 1006 | Pri<->Sec | ^ | | 1007 | Sync | Start Alloc Timer | | 1008 | | | Sec->Pri | | 1009 | +--------------+ | Sync | | 1010 | | + |--->+ | External | 1011 | | SYNC | Comm. Comm. OK Command | 1012 | | unresponsive | Failed Pri. State: or | 1013 | +--------------+ | RECOVER "Safe Period" | 1014 | ^ V | expiration | 1015 | | +------------------+ | | 1016 | Comm. OK | COMMUNICATIONS - |---------->+ | 1017 | Pri. State: | INTERRUPTED | Comm. OK | 1018 | NORMAL-----| (responsive) |--Pri. State:--+ 1019 | COMM. INT. +------------------+ All Others 1020 | ^ 1021 +---------------------+ 1023 Figure 5.2-1: Secondary Server State Diagram. 1025 5.3. Secondary Server in RECOVER state 1027 The secondary DHCP server comes up in the RECOVER state when it has 1028 no record of any previous state (or that previous state was RECOVER). 1030 It stays in this state until it establishes communication with the 1031 primary server, and is unresponsive to DHCP client requests in this 1032 state. Essentially it is idle until it can contact the primary 1033 server. 1035 When it establishes communication with the primary server, it 1036 attempts to load its client binding database from that of the primary 1037 server using the techniques specified by the Failover protocol (note 1038 that at present, in [3], the Failover protocol does not specify this 1039 technique). 1041 Once the secondary server's client binding database is refreshed from 1042 that of the primary, the secondary server moves into NORMAL state. 1044 5.4. Secondary Server in NORMAL state 1046 In normal state, the secondary server receives state updates from the 1047 primary server in DHCPBNDxxx messages. It records these in its 1048 client binding database in stable storage and then sends the corre- 1049 sponding DHCPBNDACK message to the primary server. 1051 While in NOMRAL state, the secondary server MUST also acquire a 1052 series of IP addresses from the primary server to be used to satisfy 1053 DHCPDISCOVER requests from DHCP clients when in COMMUNICATIONS- 1054 INTERRUPTED state. See Section 6 for details of the acquisition 1055 process. 1057 The secondary server periodically polls the primary server with the 1058 DHCPPOLL message. If it fails to receive a DHCPPRPL message in reply 1059 after a configured number of retries or some administratively deter- 1060 mined time, the secondary server transitions into COMMUNICATION- 1061 INTERRUPTED state. 1063 If an external command is received by the secondary server, it can 1064 move from NORMAL to PARTNER-DOWN state directly. Such a command 1065 might be sent when the primary server was removed from server, and an 1066 operator wanted the secondary server to take over immediately and 1067 completely from the primary server. (Note that the secondary server 1068 takes over from the primary server when in COMMUNICATIONS-INTERRUPTED 1069 state, but less completely than in PARTNER-DOWN state). 1071 5.5. Secondary Server in COMMUNICATION-INTERRUPTED state 1073 When in COMMUNICATIONS-INTERRUPTED state the secondary server oper- 1074 ates in such a way that correct operation is ensured even if the pri- 1075 mary server is still up and operational, but unable to communicate to 1076 the secondary server. When communications are reestablished between 1077 the primary and secondary servers, if both are still in COMMUNICA- 1078 TIONS-INTERRUPTED state, then the re-integration of their operation 1079 will proceed automatically and without human intervention. The pro- 1080 tocol is designed to ensure that reintegration will proceed in an 1081 error free manner and that no actions taken by either server while in 1082 COMMUNICATIONS-INTERRUPTED state will cause any conflicts to occur 1083 during re-integration. 1085 In COMMUNICATIONS-INTERRUPTED state, the secondary server responds to 1086 DHCP client requests. 1088 When processing a DHCPREQUEST from a DHCP client, the secondary 1089 server MUST ensure that the client-lease-time is never more than the 1090 maximum-delta-lease-interval from the current-time, independent of 1091 the desired-client-lease-time. 1093 When processing a DHCPRELEASE request from a DHCP client or the expi- 1094 ration of a lease, the secondary server must not reallocate the IP 1095 address to a different client. If the same client subsequently per- 1096 forms a DHCPDISCOVER request, the secondary server SHOULD offer it 1097 the previously used IP address. 1099 When processing a DHCPDISCOVER request from a DHCP client, the sec- 1100 ondary MUST allocate IP addresses from the list of IP addresses that 1101 it acquired from the primary server in RECOVER state. When it 1102 exhausts this list, it MUST stop responding to DHCPDISCOVER requests 1103 (except those it can satisfy by offering expired or released IP 1104 addresses to their previously bound clients). 1106 The secondary server MUST continue to send DHCPPOLL messages to the 1107 primary server when in COMMUNICATION-INTERRUPTED state. If it 1108 receives a DHCPPRPL message in reply, the secondary server determines 1109 the state of the primary server. If the primary server is in NORMAL 1110 or COMMUNICATIONS-INTERRUPTED state, then the secondary server moves 1111 into the SYNC state. 1113 If, however, the primary server is in RECOVER state, then the sec- 1114 ondary server updates the primary server with its known client bind- 1115 ing information, and moves into NORMAL state upon completion of that 1116 update. 1118 If instructed to by an outside agency (e.g., an administrator), the 1119 secondary server SHOULD move into PARTNER-DOWN state. Once the sec- 1120 ondary server has been in COMMUNICATION-INTERRUPTED state for a 1121 period equal to the safe-period, then it may (if configured to do so) 1122 transition into the PARTNER-DOWN state in the absence of an external 1123 command. 1125 5.6. Secondary Server in SYNCH state 1127 The secondary server does not respond to DHCP client requests when in 1128 SYNCHRONIZING state. 1130 DISCUSSION: 1132 This is the entire reason for this states existence, otherwise the 1133 activities specified for this state could happen as part of a 1134 state transition from the COMMUNICATIONS-INTERRUPTED state to the 1135 NORMAL state. However, in the COMMUNICATIONS-INTERRUPTED state 1136 the secondary server responds to DHCP client requests. Having the 1137 secondary server respond to DHCP client requests during the syn- 1138 chronization process (and thus taking actions requiring further 1139 synchronization) seemed like a bad idea. 1141 The secondary server synchronizes its information with the primary 1142 server while in SYNCHRONIZING state. Both primary and secondary 1143 servers may have information the other lacks because of operations 1144 performed while communications were interrupted. 1146 During the synchronization process, the secondary server continues to 1147 poll the primary server with DHCPPOLL messages. If it fails to 1148 receive a reply, it moves back into COMMUNICATION-INTERRUPTED state. 1150 When synchronization is complete, the secondary server moves into 1151 NORMAL state. 1153 5.7. Secondary Server in PARTNER-DOWN state 1155 The secondary server responds to DHCP client requests when in PART- 1156 NER-DOWN state. 1158 Any available IP address which does not belong to the private pool 1159 established by the secondary server (at entry to PARTNER-DOWN state) 1160 MUST NOT be used until the MDLI beyond the entry into PARTNER-DOWN 1161 state has elapsed. 1163 The secondary server MUST NOT allocate an IP address to a DHCP client 1164 different from that to which it was allocated at the entrance to 1165 PARTNER-DOWN state until the MDLI beyond the its expiration time has 1166 elapsed. If this time would be earlier than the current time plus 1167 the MDLI, then the current time plus the MDLI is used. 1169 Two options exist for lease times, with different ramifications flow- 1170 ing from each. 1172 If the secondary server wishes the safe failover protocol to protect 1173 it from loss of stable storage in any state, then it should adhere to 1174 the restrictions on lease time discussed in section 3.2 and used in 1175 COMMUNICATION-INTERRUPTED state, section 4.6, below. 1177 If the secondary server wishes to forego the protection of the safe 1178 failover protocol in the event of loss of stable storage, then it 1179 need recognize no restrictions on actual client lease times while in 1180 PARTNER-DOWN state. 1182 The secondary server continues to poll the primary server with DHCP- 1183 POLL messages. If the secondary server receives a reply, and the 1184 primary server is in the RECOVER state, the secondary server updates 1185 the primary server with all of the secondary's client binding infor- 1186 mation, and then moves into the NORMAL state. 1188 If communications with the primary server are reestablished, and the 1189 primary server is in any other state but RECOVER, the secondary 1190 server moves into the POTENTIAL-CONFLICT state (as does the primary 1191 server). 1193 5.8. Secondary Server in POTENTIAL-CONFLICT state 1195 The secondary server enters POTENTIAL-CONFLICT state when the combi- 1196 nation of its state and that of the primary indicate that a potential 1197 conflict of IP address allocation has occurred. There is no guaran- 1198 tee that such a conflict has occurred -- just the possibility. In 1199 this state each server compares its client binding information with 1200 that of the other server and any conflicts are resolved in an imple- 1201 mentation dependent manner. 1203 When (and if) the resolution process completes, each server moves 1204 into the NORMAL state. 1206 6. Open Issues 1208 A number of details remain to be worked out. They are as follows: 1210 o Communicating Server State 1211 A DHCP option which contains the DHCP server state must be 1212 defined for each server to use in messages sent between servers 1213 using the protocol. 1215 o Subnet Level Granularity 1217 This protocol talks about a "server" being in one state or 1218 another implying that the entire server is in just one state 1219 (with respect to the Safe Failover protocol) largely because that 1220 is the easiest way to think about the basic approach of this pro- 1221 tocol. The Failover protocol uses the same approach. 1223 However the intent is for this protocol to operate independently 1224 in each subnet address pool for which a primary and secondary 1225 server are defined. In this way, the "server" state really 1226 refers to the "subnet address pool" state. Once the general con- 1227 cepts behind this protocol are validated, the editing work to 1228 make it clear that it operates at subnet granularity will be per- 1229 formed. 1231 o Secondary Acquisition of an IP Address Pool 1233 A number of potential ways exist to allow one DHCP server to 1234 acquire an IP address pool from another DHCP server. Perhaps the 1235 easiest way is to define a new DHCP option called "Return to 1236 specified IP address". This option only affects the calculation 1237 of the IP address to which DHCPOFFERs, DHCPACKs, DHCPNAKs are 1238 sent. 1240 This option will cause any reply packets from a DHCP server to be 1241 sent to the IP address in the option. 1243 Using this option, the secondary DHCP server can acquire IP 1244 addresses from the primary server and renew those leases as 1245 appropriate. 1247 The primary server recognizes that the secondary server IP 1248 address is contained in the "Return to" DHCP option, and tags 1249 these leases in its internal database. 1251 Once tagged in this way, the primary server will take two special 1252 actions with regard to these leases. 1254 1. The primary server will allow clients other than the secondary 1255 server to renew or rebind the leases on these IP addresses 1256 when in any state. 1258 2. When in PARTNER-DOWN state, and after the period equal to the 1259 MDLI has elapsed, the primary server will add any of these IP 1260 addresses that remain available to its pool of available IP 1261 addresses. 1263 o Detailed Protocol Message Definition 1265 Detailed protocol messages must be defined for this protocol. 1267 7. Acknowledgments 1269 Some of the ideas in this proposal came from the an initial inter- 1270 server draft authored by Ralph Droms, and he acknowledged contribu- 1271 tions by Jeff Mogul, Greg Minshall, Rob Stevens, Walt Wimer, Ted 1272 Lemon, and the DHC working group. Additional ideas were generated 1273 while collaborating on a later version of the interserver draft with 1274 Bob Cole. Ideas have also been contributed by Mark Stapp, Brad 1275 Parker, and Glen Waters, and Ellen Garvey. 1277 8. References 1279 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 1280 March 1997. 1282 [2] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 1283 Extensions", Internet RFC 2132, March 1997. 1285 [3] Rabil, G., Dooley, M., Kapur, A., Droms, R., "DHCP Failover 1286 Protocol", draft-ietf-dhc-failover-00.txt. 1288 [4] Gudmundsson, Olafur, "Security Architecture for DHCP", draft- 1289 ietf-dhc-security-arch-00.txt. 1291 9. Author's information 1293 Kim Kinnear 1294 American Internet Corporation 1295 4 Preston Ct. 1296 Bedford, MA 01730-2334 1298 Phone: (781) 276-4587 1299 EMail: kinnear@american.com