idnits 2.17.1 draft-ietf-dhc-failover-01.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-19) 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. ** The abstract seems to contain references ([RFC2131]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes draft-ietf-dhc-failover-00.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 316 has weird spacing: '...ierData cli...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- No information found for rfcdraft-ietf-dhc-failover-00.txt - is the name correct? -- 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 (August 1998) is 9379 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 627, but no explicit reference was found in the text Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Greg Rabil 2 INTERNET DRAFT Mike Dooley 3 Obsoletes: draft-ietf-dhc-failover-00.txt Arun Kapur 4 Quadritek Systems 6 Ralph Droms 7 Bucknell University 9 February 1998 10 Expires August 1998 12 DHCP Failover Protocol 13 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Abstract 35 DHCP [RFC 2131] allows for multiple servers to be operating on a 36 single network. Some sites are interested in running multiple servers 37 in such a way so as to provide redundancy in case of server failure. 38 In order for this to work reliably, the servers must maintain a 39 consistent database of the lease information. This implies that 40 servers will need to coordinate any and all lease activity so that 41 this information is synchronized in case of failover. 43 This document defines a protocol to provide this synchronization 44 between two servers. One server is designated the "primary" server, 45 the other is the "secondary" server. Additionally, this document 46 describes a protocol for the automatic transfer of control from the 47 primary to the secondary in the case of failure (failover), as well 49 DRAFT DHCP Failover Protocol November 1997 51 as the re-establishment of control by the primary server. 53 1.0 Introduction 55 As the use of DHCP servers in networked environments grows, the 56 dependency of those networks on the DHCP server increases. This is 57 particularly true of the hosts that receive their configuration 58 information from the DHCP server. Therefore, it is very important to 59 be able to provide reliable, continuous availability of DHCP 60 services. 62 This specification describes a protocol to support automatic failover 63 from a primary to its secondary server. The failover mechanism 64 allows the secondary server to perform DHCP actions while the primary 65 is down. Additionally, the protocol defines how control is passed 66 back to the primary when it becomes operational again. 68 In providing the specification for the failover, the protocol 69 specifies how to guarantee reliable delivery of changes to the 70 secondary. This is required to synchronize the secondary's lease 71 data with that of the primary. The protocol further specifies a 72 mechanism for determining the state (operational or not) of the 73 primary server. The secondary will be able to automatically service 74 DHCP requests upon failover. When the primary server becomes 75 available again, the secondary will convey any changes that occurred 76 since the time of failover back to the primary prior to the primary 77 becoming operational. 79 1.1 Requirements Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC 2119]. 85 1.2 DHCP Terminology 87 This document uses the following terms: 89 o "DHCP client" or "client" 91 A DHCP client is an Internet host using DHCP to obtain 92 configuration parameters such as a network address. 94 o "DHCP server" or "server" 96 A DHCP server is an Internet host that returns configuration 98 DRAFT DHCP Failover Protocol November 1997 100 parameters to DHCP clients. 102 o "primary server" or "primary" 104 A DHCP server configured to provide primary service to a set of 105 DHCP clients. 107 o "secondary server" or "secondary" 109 A DHCP server configured to act as a backup to a primary server; 110 the secondary answers requests from DHCP clients only if its 111 primary is unable to respond. 113 o "bindings database" 115 The collection of bindings managed by a primary and secondary. 117 1.3 Requirements for this protocol 119 The following requirements must be met by this protocol. 121 o Implementations of this protocol must work with existing DHCP 122 clients. 124 o Implementations of this protocol must work with existing BOOTP 125 relay agents. 127 o The protocol must provide failover redundancy between servers that 128 are not located on the same subnet. 130 1.4 Goals of this protocol 132 o Provide for continued service to DHCP clients through an automated 133 mechanism in the event of failure of the primary server. 135 o Minimize the possibility of assigning an IP address to two 136 different clients simultaneously. 138 o Minimize any need for manual administrative intervention. 140 o Introduce no additional delays in server response time as a result 141 of inter-server communication. 143 o Share IP address ranges between primary and secondary servers; 144 i.e., impose no requirement that the pool of available IP addresses 145 be divided between servers. 147 o Continue to meet the goals and objectives of this protocol in the 149 DRAFT DHCP Failover Protocol November 1997 151 event of server failure or network partition. 153 o Provide graceful reintegration of full protocol service after 154 server failure or network partition. 156 o Allow for one computer to act as a secondary server for multiple 157 primary servers. Where possible, primary and secondary servers 158 should be "logical" servers and not necessarily physical computers. 160 1.4 Limitations to this protocol 162 o Under normal operation, only one server at a time will service DHCP 163 client requests; this protocol provides reliability through 164 redundancy but not load balancing. 166 o This protocol provides only one level of redundancy through a 167 single secondary server for each primary server. 169 o Under certain combinations of failures, both a primary and 170 secondary server may be active and assign the same IP address to 171 different DHCP clients. 173 DISCUSSION: 175 The details of this failure mode are discussed in section X. In 176 summary, for duplicate address allocation to occur, a network 177 partition must occur that prevents the servers from exchanging 178 messages and a subnet partition must occur so that some DHCP 179 clients on the subnet can only reach the server while other 180 clients on that same subnet can only reach the secondary. 182 o Primary and secondary servers require external configuration to 183 acquire server addresses, available IP address ranges and other 184 client configuration information. 186 DISCUSSION: 188 This protocol assumes external configuration of primaries and 189 secondaries; e.g., through an independent internet configuration 190 management tool. 192 o The primary and secondary server must synchronized before an 193 address with an expired lease can be reassigned to a new client. 195 o The primary and secondary servers must halt all DHCP transaction 196 processing while resynchronizing after a system failure. 198 DRAFT DHCP Failover Protocol November 1997 200 DISCUSSION: 202 Presumably, unless the primary and secondary servers have been 203 out of communication for an extended period, the servers will 204 have only a small amount of information to exchange. Thus, the 205 time during which the servers are not available to answer DHCP 206 requests will be minimal and should be bridged by the normal 207 DHCP client retransmission mechanism. 209 2.0 Protocol Summary 211 The protocol necessary in providing redundant/failover servers can be 212 grouped in three areas: 214 o Messages to keep the secondary server's lease data synchronized 215 with that of the primary so that when failover occurs, there is no 216 degradation of service 218 o Messages that allow the secondary to determine the operational 219 state of the primary, so as to know when to start servicing DHCP 220 traffic 222 o Messages that are used to coordinate the primary regaining control 223 when it has become available again. 225 2.1 Primary keeps secondary lease data synchronized 227 The messages for keeping the secondary's lease data up to date 228 include the following: 230 DHCPBNDADD - Primary notifies secondary of new binding 231 DHCPBNDUPD - Primary notifies secondary of modified binding 232 (e.g., extended lease) 233 DHCPBNDDEL - Primary notifies secondary of deleted binding 234 (e.g., expired or released lease) 236 In response to any of the above messages, the secondary server will 237 respond to the primary with a message describing the status of the 238 binding addition, modification, or deletion. 240 DHCPBNDACK - Positive acknowledgment of binding change 241 DHCPBNDNAK - Negative acknowledgment of binding change 243 2.2 Determination of operational state of a server 245 In order to determine the state of a given server, a participant can 246 use the following message to poll (or "ping") the server: 248 DRAFT DHCP Failover Protocol November 1997 250 DHCPPOLL - Check if server is operational 252 In response to the DHCPPOLL message, the participant will listen for 253 the following: 255 DHCPPRPL - Poll reply 257 2.3 Primary requests control from the secondary 259 After a failover, when the primary server is restarted, the following 260 messages are used to coordinate the primary taking control back from 261 the secondary: 263 DHCPCTLREQ - Request for control 264 DHCPCTLRET - Return of control initiated 265 DHCPCTLACK - Return of control completed 267 3 Message formats and semantics 269 The failover protocol messages are encoded as a DHCP/BOOTP option in 270 a DHCP message. A DHCP message carrying a failover protocol message 271 carries only the failover protocol message option and no other 272 options. The DHCP message is unicast from the source to the 273 destination. 275 The option code for these messages is TBD. Within each failover 276 protocol message, the specific message type is indicated by an option 277 subcode in the first octet of the data area of the option. The 'len' 278 field includes the number of octets in the option subcode byte and in 279 any additional data carried in the failover protocol message. 280 Bindings are encoded in a format that is TBD. 282 DISCUSSION 284 The use of the REQUEST/REPLY field in the DHCP message header and 285 the UDP port to be used needs to be considered. 287 The use of existing DHCP options and header fields to encode 288 bindings needs to be considered. 290 The sender places a 32-bit number in the DHCP header 'xid' field to 291 uniquely identify each failover protocol message. The receiver 292 copies the contents of the 'xid' field into any reply or 293 acknowledgment message. 295 The sender is responsible for reliable transmission and any 296 retransmission. 298 DRAFT DHCP Failover Protocol November 1997 300 3.1 Binding Information 302 Maintaining consistent binding information between the primary and 303 secondary servers is a high priority of this protocol. Both the 304 primary and secondary must be sychronized in order for the failover 305 operation to occur smoothly. The DHCPBNDADD, DHCPBNDUPD, and 306 DHCPBNDDEL messages described below require the following binding 307 information: 309 hType 1 byte 310 hLen 1 byte 311 chAddr 16 bytes 312 ipAddr 4 bytes 313 grantTime 4 bytes 314 expireTime 4 bytes 315 clientIdentifierLen 2 bytes 316 clientIdentifierData clientIdentifierLen bytes 317 status 2 bytes 318 hostNameLen 2 bytes 319 hostNameData hostNameLen bytes 320 domainNameLen 2 bytes 321 domainNameData domainNameLen bytes 323 The minimum size of the binding information is 32 bytes. 325 Note that the use of the client hardware address (hType, hLen, and 326 chAddr) are in order to facilitate servers which support both the 327 Bootp and DHCP protocols. Since most, if not all, Bootp clients do 328 not send a 'client identifier' option, it seems appropriate to use 329 this combination of fields of the Bootp packet to uniquely identify 330 the client within the primary and secondary servers' respective 331 bindings. 333 The 'ipaddr' is the IP address that the primary server has leased to 334 the client. The 'grantTime' and 'expireTime' fields are represented 335 as seconds since Jan 1, 1970 (i.e. ANSI C time_t time value 336 representation). An 'expireTime' of -1 (ffffffff) indicates an 337 infinite lease. 339 If available for the individual binding, the 'clientIdentifier' 340 fields SHOULD be provided by the primary server. These fields 341 correspond to the DHCP vendor extension option number 61. If such 342 information is provided, then the secondary SHOULD use this data to 343 uniquely identify the client within its bindings database as 344 discussed in RFC 2132 Section 9.14. 346 The 'status' field is used to convey the status of a particular 347 binding to the secondary server. The status may indicate that a 349 DRAFT DHCP Failover Protocol November 1997 351 particular lease has expired, or that an address 353 The 'hostName' and 'domainName' fields can be used to maintain 354 information required for Dynamic DNS updates. These fields 355 correspond to the DHCP vendor extension option number 12 and 15, 356 respectively. 358 DISCUSSION 360 The complete list of fields that may be required in the binding 361 information is still under discussion. Based upon such 362 discussions and other requirements, the information may be 363 expanded or scaled back. 365 3.2 Primary keeps secondary lease data synchronized 367 DHCPBNDADD 369 ------------------------------------------ 370 | XX | len | 1 | Binding information 371 ------------------------------------------ 373 The primary sends a DHCPBNDADD message to inform the secondary of a 374 binding that has been added to the primary's set of bindings. 376 DHCPBNDUPD 378 ------------------------------------------ 379 | XX | len | 2 | Binding information 380 ------------------------------------------ 382 The primary sends a DHCPBNDUPD message to inform the secondary of a 383 binding that has been changed in the primary's set of bindings. 385 DHCPBNDDEL 387 ------------------------------------------ 388 | XX | len | 3 | Binding information 389 ------------------------------------------ 391 The primary sends a DHCPBNDDEL message to inform the secondary of a 392 binding that has been deleted from the primary's set of bindings. 394 DRAFT DHCP Failover Protocol November 1997 396 DHCPBNDACK 398 -------------- 399 | XX | 1 | 4 | 400 -------------- 402 The secondary sends a DHCPBNDACK message to the primary to inform the 403 primary that the binding change request identified by the 'xid' field 404 has successfully been completed. 406 DHCPBNDNAK 408 -------------- 409 | XX | 1 | 5 | 410 -------------- 412 The secondary sends a DHCPBNDNAK message to the primary to inform the 413 primary that the secondary could not complete the binding change 414 request. For example, the secondary would send a DHCPBNDNAK in 415 response to a DHCPBNDUPD request for which the secondary had no 416 recorded binding. 418 DISCUSSION 420 The use of an additional field to indicate the reason for the 421 DHCPBNDNAK message should be considered. 423 3.3 Determination of operational state of a server 425 DHCPPOLL 427 ---------------------- 428 | XX | 2 | 6 | flags | 429 ---------------------- 431 A DHCP participant sends a DHCPPOLL message to a server to determine 432 whether that server is currently operational. 434 A DHCP secondary periodically sends a DHCPPOLL to its primary to 435 determine if the primary is currently operational. 437 A DHCP primary sends a DHCPPOLL to its secondary if the primary needs 438 to determine if the secondary is operational. 440 A DHCP client sends a DHCPPOLL to a DHCP server to determine if the 441 server is currently operational. 443 The flags octet is defined as follows: CRRRRRRR, where the secondary 445 DRAFT DHCP Failover Protocol November 1997 447 sets the 'C' bit to 1 to indicate that it has taken control of the 448 bindings database, and the 'R' bits are reserved for future use. 450 DHCPPRPL 452 ---------------------- 453 | XX | 2 | 7 | flags | 454 ---------------------- 456 A DHCP participant replies to a DHCPPOLL message with a DHCPPRPL 457 message. The sender copies the 'xid' field from the DHCPPOLL message 458 header into the 'xid' field in the DHCPPRPL message, 460 The flags octet is defined as follows: ERRRRRRR, where the primary 461 sets the 'E' bit to 1 (in response to a DHCPPOLL message with the 'C' 462 bit set to 1) to indicate to the secondary that the primary has not 463 relinquished control of the database. See section 4 for additional 464 details. 466 DISCUSSION 468 The DHCPPOLL and DHCPPRPL messages might also be useful to DHCP 469 clients to aid in determining the availability of specific DHCP 470 servers. Such use would avoid overloading the DHCPDISCOVER 471 message. 473 3.4 Primary requests control from the secondary 475 DHCPCTLREQ 477 -------------- 478 | XX | 1 | 8 | 479 -------------- 481 A primary sends a DHCPCTLREQ message to its secondary to request 482 control of the bindings database from the secondary. 484 DHCPCTLRET 486 -------------- 487 | XX | 1 | 9 | 488 -------------- 490 A secondary sends a DHCPCTLRET to its primary to begin the process of 491 returning control of the bindings database to the secondary. After 492 sending the DHCPCTLRET message, the secondary sends a sequence of 493 DHCPBNDADD, DHCPBNDUPD and DHCPBNDDEL messages to synchronize the 494 primary's bindings database with the secondary's database. 496 DRAFT DHCP Failover Protocol November 1997 498 DHCPCTLACK 500 --------------- 501 | XX | 1 | 10 | 502 --------------- 504 A secondary sends a DHCPCTLACK to its primary to indicate that the 505 secondary has finished returning control to the primary. 507 DISCUSSION 509 Primary and secondary servers may need to exchange some additional 510 information in DHCPCTLREQ, DHCPCTLRET and DHCPCTLACK messages. 511 This information would be encoded in an additional 'flags' or 512 'data' field added to the control messages. 514 The synchronization essentially requires a reliable transmission 515 protocol using DHCPBND* and DHCPBNDACK messages. An alternative 516 to using DHCPBND* messages to transfer bindings updates to the 517 primary would be to devise a separate transfer protocol based on 518 TCP. 520 4 Exchange of control between primary and secondary 522 The primary and secondary servers coordinate the exchange control 523 over the bindings database through the use of DHCPPOLL and DHCPCTLREQ 524 messages. In normal operation: 526 o the primary sends notification of each change to its bindings 527 database to the secondary, and the secondary keeps its bindings 528 database synchronized with the primary's database 530 o the secondary periodically sends DHCPPOLL messages to the primary, 531 and the primary responds to each DHCPPOLL message with a DHCPPRPL 532 message 534 If the secondary does not receive a DHCPPRPL response message, the 535 secondary takes control of the bindings database and begins 536 answering requests from DHCP clients. Note that the secondary 537 should be able to be configured to not perform the automatic 538 switchover. 540 DISCUSSION 542 The conditions under which a secondary takes control of the 543 bindings database, e.g., the number of consecutive missing 544 acknowledgments, should be configurable in the secondary by the 545 DHCP administrator. 547 DRAFT DHCP Failover Protocol November 1997 549 The secondary records any changes it makes to the bindings database 550 while it has control. The secondary continues to send DHCPPOLL 551 messages to the primary, with the 'D' bit set. 553 To regain control of the bindings database, e.g., after the primary 554 server has failed, the primary sends a DHCPCTLREQ message to the 555 secondary. The secondary stops answering DHCP client requests, and 556 responds to its primary with a DHCPCTLRET message. After sending 557 the DHCPCTLRET message, the secondary sends DHCPBND* messages for 558 each of the changes it has made to the bindings database. The 559 primary sends a DHCPBNDACK for each of the DHCPBND* messages it 560 receives. The secondary completes the transfer of control by 561 sending a DHCPCTLACK message to its primary. 563 If the primary server has not failed and has been answering DHCP 564 client requests, and receives a DHCPPOLL message from its secondary 565 with the 'D' bit set, then both the primary and the secondary have 566 been answering DHCP client requests, and their bindings databases 567 may be unsynchronized. In this situation, the primary responds to 568 the secondary with a DHCPPRPL message with the 'E' bit set. Both 569 the primary and secondary servers notify a network administrator, 570 who must take steps to manually resynchronize the two bindings 571 databases. 573 DISCUSSION 575 It may be appropriate to state that, under administrator 576 control, the primary and secondary both stop some or all DHCP 577 services when the servers discover that both have been 578 allocating DHCP addresses simultaneously and their databases are 579 potentially unsynchronized. 581 4.1 Minimizing the potential for duplicate bindings 583 One of the goals outlined in section 1.4 of this draft is to 584 minimize the possibility of assigning an IP address to two 585 different clients simultaneously. This possibility can occur only 586 if both the primary and secondary servers are handling requests 587 from the same subnet at the same time. Since the basis for this 588 protocol is that the secondary only becomes "active" in the case 589 that it has determined that the primary is no longer operational, 590 the situation in which both are operational at the same time can 591 occur only if there exists a failure in the mechanism for 592 determining the status of the primary. This failure could occur, 593 for example, if all routes between the primary and secondary were 594 unavailable such that secondary would not get a response to a poll, 595 even though the primary is still operational. In such 596 circumstances, if so configured on the secondary (see section 4 598 DRAFT DHCP Failover Protocol November 1997 600 above), manual intervention could be required to OK or disallow the 601 switchover. 603 If such an option is not configured, it is still possible for the 604 secondary to become active and servicing the same subnet(s) as the 605 primary. In this case, two clients could potentially get the same 606 IP address, but only if both clients are on the same subnet. This 607 situation could only occur if one of the client's packets went to 608 the primary and the other client's packets went to the secondary 609 server. This would be a very rare situation. However, as rare as 610 this may be, the potential exists, so another mechanism is needed 611 to ensure that this does not occur. Therefore, it is a requirement 612 of this protocol that each server particpating in the failover MUST 613 ping an address prior to offering that address. This should 614 eliminate virtually any possibility of duplicate addresses being 615 offered to clients from the participating servers. 617 5 Acknowledgments 619 6 References 621 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 622 Requirement Levels", RFC 2119, March 1997. 624 [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", 625 RFC2131, March 1997. 627 [RFC 2132] Droms, R., "DHCP Options and BOOTP Vendor Extensions", 628 RFC2132, March 1997. 630 7 Security Considerations 632 8 Authors' Addresses 634 Greg Rabil, Mike Dooley, Arun Kapur 635 Quadritek Systems, Inc. 636 10 Valley Stream Parkway, Quite 240 637 Malvern, PA 19355 639 Phone: (800) 408-2747 640 E-mail: grabil@quadritek.com 641 mdooley@quadritek.com 642 akapur@quadritek.com 644 Ralph Droms 645 323 Dana Engineering 646 Bucknell University 648 DRAFT DHCP Failover Protocol November 1997 650 Lewisburg, PA 17837 652 Phone: (717) 524-1145 653 E-mail: droms@bucknell.edu