idnits 2.17.1 draft-mrugalski-dhc-dhcpv6-failover-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3315]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2011) is 4688 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-03) exists of draft-ietf-dhc-dhcpv6-redundancy-consider-00 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration (DHC) T. Mrugalski, Ed. 3 Internet-Draft ISC 4 Intended status: Informational K. Kinnear 5 Expires: December 28, 2011 Cisco 6 June 26, 2011 8 DHCPv6 Failover Requirements 9 draft-mrugalski-dhc-dhcpv6-failover-requirements-00 11 Abstract 13 The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers 14 to operate on a single network, however it does not define any way to 15 decide which server responds to which client queries. Some sites are 16 interested in running multiple servers in such a way as to provide 17 increased availability in case of server failure. In order for this 18 to work reliably, the cooperating primary and secondary servers must 19 maintain a consistent database of the lease information. [RFC3315] 20 allows for but does not define any redundancy or failover mechanisms. 21 This document outlines requirements for DHCPv6 failover, enumerates 22 related problems, and discusses the proposed scope of work to be 23 conducted. This document does not define a DHCPv6 failover protocol. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 28, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Scope of work . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Failover alternatives . . . . . . . . . . . . . . . . . . 6 64 4.1.1. Short-lived addresses . . . . . . . . . . . . . . . . 6 65 5. Failover Scenarios . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. Hot Standby Model . . . . . . . . . . . . . . . . . . . . 6 67 5.2. Geographically Distributed Failover . . . . . . . . . . . 7 68 5.3. Load balancing . . . . . . . . . . . . . . . . . . . . . . 7 69 5.4. 1-to-1, m-to-1 and m-to-m models . . . . . . . . . . . . . 7 70 5.5. Split prefixes . . . . . . . . . . . . . . . . . . . . . . 7 71 5.6. Long lived connections . . . . . . . . . . . . . . . . . . 8 72 6. Principles of DHCPv6 Failover . . . . . . . . . . . . . . . . 8 73 6.1. Failure modes . . . . . . . . . . . . . . . . . . . . . . 8 74 6.1.1. Server Failure . . . . . . . . . . . . . . . . . . . . 8 75 6.1.2. Network partition . . . . . . . . . . . . . . . . . . 9 76 6.2. Synchronization mechanisms . . . . . . . . . . . . . . . . 9 77 6.2.1. Lockstep . . . . . . . . . . . . . . . . . . . . . . . 9 78 6.2.2. Lazy updates . . . . . . . . . . . . . . . . . . . . . 10 79 7. DHCPv4 and DHCPv6 Failover Comparison . . . . . . . . . . . . 10 80 8. DHCPv6 Failover Requirements . . . . . . . . . . . . . . . . . 11 81 9. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 9.1. DHCPv4 failover concepts . . . . . . . . . . . . . . . . . 13 83 9.1.1. Goals of DHCPv4 Failover . . . . . . . . . . . . . . . 13 84 9.1.2. Goals lead to Concepts . . . . . . . . . . . . . . . . 14 85 9.1.3. Use of the MCLT in practice . . . . . . . . . . . . . 15 86 9.1.4. Network Partition Events . . . . . . . . . . . . . . . 16 87 9.1.5. Conflict Resolution . . . . . . . . . . . . . . . . . 16 88 9.1.6. Load Balancing . . . . . . . . . . . . . . . . . . . . 16 89 9.2. DHCPv6 Redundancy Considerations . . . . . . . . . . . . . 17 90 10. DHCP Best Practices . . . . . . . . . . . . . . . . . . . . . 17 91 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 92 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 93 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 94 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 14.1. Normative References . . . . . . . . . . . . . . . . . . . 17 96 14.2. Informative References . . . . . . . . . . . . . . . . . . 18 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 99 1. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 2. Introduction 107 The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers 108 to be operating on a single network, however it does not define any 109 way to decide which server responds to which client queries. Some 110 sites are interested in running multiple servers in such a way as to 111 provide redundancy in case of server failure. In order for this to 112 work reliably, the cooperating primary and secondary servers must 113 maintain a consistent database of the lease information. 115 This document discusses failover implementations scenarios, failure 116 modes, and synchronization approaches to provide background to the 117 list of requirements for a DHCPv6 failover protocol. It then defines 118 a minimum set of requirements that failover must provide to be 119 useful, while acknowledging that additional features may be specified 120 as extensions. This document does not define a DHCPv6 failover 121 protocol. 123 3. Definitions 125 This section defines terms that are relevant to DHCPv6 failover. 127 Definitions from [RFC3315] are included by reference. In particular, 128 client means any device (e.g., end user host, CPE or other router) 129 that implements client functionality of the DHCPv6 protocol. A 130 server means a DHCPv6 server, unless explicitly noted otherwise. A 131 relay is a DHCPv6 relay. 133 A binding (or, client binding) is a group of server data records 134 containing the information the server has about the addresses in 135 an IA or configuration information explicitly assigned to the 136 client. Configuration information that has been returned to a 137 client through a policy - for example, the information returned to 138 all clients on the same link - does not require a binding. 140 DDNS - an abbreviation for "Dynamic DNS", which refers to the 141 capability to update a DNS server's name database using the on- 142 the-wire protocol defined in [RFC2136]. Clients and servers can 143 negotiate the scope of such updates as defined in [RFC4704]. 145 Failover - an ability of one partner to continue offering services 146 provided by another partner, with minimal or no impact on clients. 148 FQDN - a fully qualified domain name. A fully qualified domain 149 name generally is a host name with at least one zone name. For 150 example "dhcp.example.org" is a fully qualified domain name. 152 High Availability - a desired property of DHCPv6 servers to 153 continue providing services despite experiencing unwanted events 154 such as server crashes, link failures, or network partitions. 156 Load Balancing - the ability for two or more servers to each 157 process some portion of the client request traffic in a conflict- 158 free fashion. 160 Lease - an IPv6 address, an IPv6 prefix or other resource that was 161 assigned ('leased') by a server to a specific client. A lease may 162 include additional information, like associated fully qualified 163 domain name (FQDN) and/or information about associated DNS 164 updates. 166 Partner - A "partner", for the purpose of this document, refers to 167 a failover server, typically the other failover server in a 168 failover relationship. 170 Stable Storage - each DHCP server is required to keep its lease 171 database in some form of storage (known as "stable storage") that 172 will be consistent throughout reboots, crashes and power failures. 174 Partner Failure - A power outage, unexpected shutdown, crash or 175 other type of failure that renders a partner unable to continue 176 its operation. 178 4. Scope of work 180 In order to fit within the IETF process effectively and efficiently, 181 the standardization effort for DHCPv6 failover is expected to proceed 182 with the creation of documents of increasing specificity. It begins 183 with this document specifying the requirements for DHCPv6 failover 184 ("requirements document"). Later documents are expected to address 185 the design of the DHCPv6 failover protocol ("design document"), and 186 if sufficient interest exists, the protocol details required to 187 implement the DHCPv6 failover protocol itself ("protocol document"). 188 The goal of this partitioning is, in part, to ease the validation, 189 review, and approval of the DHCPv6 failover protocol by presenting it 190 in comprehensible parts to the larger community. 192 Additional documents describing extensions may also be defined. 194 DHCPv6 Failover requirements are presented in Section 8. 196 4.1. Failover alternatives 198 There are many scenarios when it seems that a failover capability 199 would be useful. However, there are often much simpler approaches 200 that will meet the required goals. This section documents examples 201 where failover is not really needed. 203 4.1.1. Short-lived addresses 205 There are cases when IPv6 addresses are used only for a short time, 206 but there is a need to have high degree of confidence that those 207 addresses will be served. A notable example is a scenario where 208 hosts require an address during boot. Address and possibly other 209 configuration parameters are used during boot process and are 210 discarded afterwards. Any lack of available DHCPv6 service at this 211 time may render the devices unbootable. 213 Instead of deploying failover, it is better to use the much simpler 214 preference mechanism, defined in [RFC3315]. For example, consider 215 two or more servers with each having distinct preference set (e.g. 10 216 and 20). Both will answer to a client's request. The client should 217 choose the one with larger preference value. In case of failure of 218 the most preferred server, the next server will keep responding to 219 clients' queries. 221 5. Failover Scenarios 223 The following section provides several examples of deployment 224 scenarios and use cases that may be associated with capabilities 225 commonly referred to as failover. These scenarios may be inside or 226 outside of scope for DHCPv6 failover protocol as defined by this 227 document. They are enumerated here to provide a common basis for 228 discussion. 230 5.1. Hot Standby Model 232 In the simplest case, there are two partners that are connected to 233 the same network. Only one of partners ('primary') provides services 234 to clients. In case of its failure, the second partner ('secondary') 235 continues handling services previously handled by first partner. As 236 both servers are connected to the same network, a partner that fails 237 to communicate with its partner while also receiving requests from 238 clients may assume with high probability that its partner is down and 239 the network is functional. This assumption may affect its operation. 241 5.2. Geographically Distributed Failover 243 Servers may be physically located in separate locations. A common 244 example of such a topology is where a service provider has at least a 245 regional high performance network between geographically distributed 246 datacenters. In such a scenario, one server is located in one 247 datacenter and its failover partner is located in another remote 248 datacenter. In this scenario, when one partner finds that it cannot 249 communicate with the other partner, it does not necessarily mean that 250 the other partner is down. 252 5.3. Load balancing 254 A desire to have more than one server in a network may also be 255 created by the desire to have incoming traffic be handled by several 256 servers. This decreases the load each server must endure when all 257 servers are operational. Although such a capability does not, 258 strictly, require failover - it is clear that failover makes such an 259 architecture more straightforward. 261 Note that in a load balancing situation which includes failover, each 262 individual server MUST be able to handle the full load normally 263 handled by both servers working together, or there is not a true 264 increase in availability. 266 5.4. 1-to-1, m-to-1 and m-to-m models 268 A failover relationship for a specific network is provided by two 269 failover partners. Those partners communicate with each other. This 270 scenario is sometimes referred to as the 1-to-1 model and is 271 considered relatively simple. In larger networks one server may be 272 participating in several failover relationships, i.e. it provides 273 failover for several address or prefix pools, each served by separate 274 partners. Such a scenario can be referred to as m-to-1. The most 275 complex scenario - m-to-m - assumes that each partner participates in 276 multiple failover relationships. 278 5.5. Split prefixes 280 Due to the extensive IPv6 address space, it is possible to provide 281 semi-redundant service by splitting the available pool of addressees 282 into two or more non-overlapping pools, with each server handling its 283 own smaller pool. Several versions of such a scenario are discussed 284 in [I-D.ietf-dhc-dhcpv6-redundancy-consider]. 286 5.6. Long lived connections 288 Certain nodes may maintain long lived connections. Since the IPv6 289 address space is large, techniques exist (e.g. 290 [I-D.ietf-dhc-dhcpv6-redundancy-consider]) that use the easy 291 availability of IPv6 addresses in order to provide increased DHCPv6 292 availability. However, these approaches do not generally provide for 293 stable IPv6 addresses for DHCPv6 clients should the server with which 294 the client is interacting become unavailable. 296 6. Principles of DHCPv6 Failover 298 This section describes important issues that will affect any DHCPv6 299 failover protocol. This section is not intended to define 300 implementation details, but rather high level concepts and issues 301 that are important to DHCPv6 failover. These issues form a basis for 302 later documents which deal with the solutions to these issues. 304 6.1. Failure modes 306 This section documents failure modes. Each failure mode is listed as 307 either an in-scope or out-of-scope requirement for the failover 308 protocol. 310 6.1.1. Server Failure 312 Servers may become unresponsive due to a software crash, hardware 313 failure, power outage or any number of other reasons. The failover 314 partner will detect such event due to lack of responses from the down 315 partner. In this failure mode, the assumption is that the server is 316 the only equipment that is off-line and all other network equipment 317 is operating normally. In particular, communication between other 318 nodes is not interrupted. 320 When working under the assumption that this is the only type of 321 failure that can happen, the server may safely assume that its 322 partner unreachability means that it is down, so other nodes (clients 323 in particular) are not able to reach it either and no services are 324 provided. 326 It should be noted that recovery after the failed server is brought 327 back on-line is straightforward, due to the fact that it just needs 328 to download current information from the lease database of the 329 healthy partner and there is no conflict resolution required. 331 This is by far the most common failure mode between two failover 332 partners. 334 When the two servers are located physically close to each other, 335 possibly in the same room, the probability that a failure to 336 communicate between failover partners is due to server failure is 337 increased. 339 6.1.2. Network partition 341 Another possible cause of partner unreachability is a failure in the 342 network that connects the two servers. This may be caused by failure 343 of any kind of network equipment: router, switch, physical cables, or 344 optic fibers. As a result of such a failure the network is split 345 into two or more disjoint sections (partitions) that are not able to 346 communicate with each other. Such an event is called network 347 partition. If failover partners are located in different partitions, 348 they won't be able to communicate with each other. Nevertheless, 349 each partner may still be able to serve clients that happen to be 350 part of the same partition. 352 If this failure mode is taken into consideration, a server can't 353 assume that partner unreachability automatically means that its 354 partner is down. They must consider the fact that the partner may 355 continue operating and interacting with a subset of the clients. The 356 only valid assumption is that partner also detected the network 357 partition event and follows procedures specified for such a 358 situation. 360 It should be noted that recovery after partitioned network is 361 rejoined is significantly more complicated than recovery from a 362 server failure event. As both servers may have kept serving clients, 363 they have two separate lease databases, and they need to agree on the 364 state of each lease (or follow any other algorithm to bring their 365 lease databases into agreement). 367 This failure mode is more likely (though still rare) in the situation 368 where two servers are in physically distant locations with multiple 369 network elements between them. This is the case in geographically 370 distributed failover (see Section 5.2). 372 6.2. Synchronization mechanisms 374 Partners must exchange information about changes made to the lease 375 database. There are two types of sychronization methods that may be 376 used. 378 6.2.1. Lockstep 380 When a server receives a REQUEST message from a client it consults 381 its lease database and assigns requested addresses and/or prefixes. 383 To make sure that its partner maintains a consistent database, it 384 then sends information about new or just updated lease to the partner 385 and waits for the partner's response. After the response from 386 partner is received the REPLY message is transmitted to the client. 388 This approach has the benefit of having a completely consistent lease 389 database between partners at all times. Unfortunately, there is a 390 large performance penalty for this approach as each response sent to 391 a client is delayed by the total sum of the delays caused by two 392 transmissions between partners and the processing by the second 393 partner. The second partner is expected to update its own copy of 394 the lease database in permanent storage, so this delay is not 395 negligible, even in fast networks. 397 6.2.2. Lazy updates 399 Another approach to synchronizing the lease databases is to transmit 400 the REPLY message to the client before completing the update to the 401 partner. The server sends the REPLY to the client immediately after 402 assigning appropriate addresses and/or prefixes and initiates the 403 partner update at a later time, depending on the algorithm chosen. 404 Another varation of this approach is to initiate transmission to the 405 partner, but not wait for its response before sending the REPLY to 406 the client. 408 This approach has benefit of a minimal impact on server response 409 times, thus it is much better from a performance perspective. 410 However, it makes the lease databases loosely synchronized between 411 partners. This makes the synchronization more complex (and 412 particularly the re-integration after a network partition event), as 413 there may be cases where one client has been given a lease on an 414 address or prefix of which the partner is not aware (e.g. if server 415 crashes after sending REPLY to the client, but before sending update 416 information to its partner). 418 7. DHCPv4 and DHCPv6 Failover Comparison 420 There are significant similarities between existing DHCPv4 and 421 envisaged DHCPv6 failovers. In particular both serve IP addresses to 422 clients, require maintaining consistent databases among partners, 423 need to perform consistent DNS Updates, must be able take over 424 bindings offered by failed partner, must be able to resume operation 425 after partner is recovered. DNS conflict resolution works on the 426 same principles in both DHCPv4 and DHCPv6. 428 Nevertheless, there are significant differences. IPv6 introduced 429 prefix delegation [RFC3633] that is a crucial element of the DHCPv6 430 protocol. IPv6 also introduced the concept of deprecated addresses 431 with separate prefered and valid lifetimes, both being configured via 432 DHCPv6. Negative response (NACK) in DHCPv4 has been replaced with 433 the ability in DHCPv6 to provide corrected response in a REPLY 434 message that differs from a REQUEST. 436 Also, the typical large address space (close to 2^64 addresses on /64 437 prefixes expected to be available on most networks) may make managing 438 address assignment significantly different from DHCPv4 failover. In 439 DHCPv4 it was not possible to use a hash or calculated technique to 440 divide the significantly more limited address space and therefore 441 much of the protocol that deals with pool balancing and rebalancing 442 might not be necessary and can be done mathematically. And, it may 443 also be possible and reasonable to use a much longer MCLT value -- as 444 reusing an address for a different client is generally not a 445 requirement (at least over the near term) as close to 2^64 addresses 446 may be available. 448 However, DHCPv6 Prefix Delegation is similar to IPv4 addressing and 449 therefore techniques for pool balancing and rebalancing and shorter 450 MCLT times will be needed. 452 8. DHCPv6 Failover Requirements 454 This section summarizes the requirements for DHCPv6 failover. 456 Certain capabilities may be useful in some, but not all scenarios. 457 Such additional features will be considered optional parts of 458 failover, and will be split and defined in separate documents. As 459 such, this document can be considered an attempt to define 460 requirements for the DHCPv6 failover 'core' protocol. 462 The core of the DHCPv6 failover protocol is expected to provide the 463 following properties: 465 1. The number of supported partners MUST be exactly two, i.e. there 466 are at most two servers that are aware of specific lease; this 467 approach is often called 1-to-1 model. 469 2. For each prefix or address pool, server MUST NOT participate in 470 more than one failover relationship. 472 3. Server MAY participate in multiple relationships only if those 473 relationships cover different prefix or address pools. 475 4. One partner MUST be able to continue serving leases offered by 476 the other partner. This property is also sometimes called 477 'lease stability'. The failure of either failover partner 478 SHOULD pose minimal or no impact on client connectivity. In 479 particular, it MUST NOT force the client to change addresses 480 and/or change prefixes delegated to it. Long-lived connections 481 MUST NOT be disturbed. 483 5. Prefix delegation MUST be supported. 485 6. Use of the failover protocol MUST NOT introduce significant 486 performance impact on server response times. Therefore 487 synchronization between partner MUST be done using some form of 488 lazy updates (see Section 6.2.2). 490 7. The pair of failover servers MUST be able to recover from server 491 down failure (see Section 6.1.1). 493 8. The pair of failover servers MUST be able to recover from a 494 network partition event (see Section 6.1.2). 496 9. The design MUST allow secure communication. 498 10. The definition of extensions to this core protocol SHOULD be 499 allowed, when possible. 501 High Availability is a property of the protocol that allows clients 502 to receive DHCPv6 services despite the failure of individual DHCPv6 503 servers. In particular, it means the server that takes over 504 providing service to clients from its failed partner, will continue 505 serving the same addresses and/or prefixes. This property is also 506 sometime called lease stability. 508 The core protocol MUST be limited to the 1-to-1 model (see 509 Section 5.4). In addition, the core protocol MUST restrict each 510 address or prefix pool to participate in at most one failover 511 relationship. (Note: these are different statements!) If there is 512 sufficient community support for failover servers to participate in 513 more than one failover relationship (thus providing support for a 514 form of m-to-1 deployment), this capability SHALL be defined as an 515 extension to the core failover protocol. 517 Despite the lack of standardization of DHCPv4 failover, the 518 coexistence of DHCPv4 and DHCPv6 failover MAY be taken into 519 consideration. In particular, certain features that are common for 520 both IPv4 and IPv6, like DNS Update mechanism SHOULD be taken into 521 consideration. 523 A Load Balancing capability is considered an extension and MAY be 524 defined in a separate document. It MUST NOT be part of the core 525 protocol, but rather defined as an extension. The primary reason for 526 this the desire to limit core protocol complexity. 528 Following features and capabilities are outside of scope of this 529 document: 531 m-to-m model (see section Section 5.4) 533 servers participating in multiple failover relationships 535 load balancing 537 9. Related work 539 This section describes related work. Readers may benefit from 540 familiarizing themselves with these approaches, their advantages and 541 limitations. 543 9.1. DHCPv4 failover concepts 545 9.1.1. Goals of DHCPv4 Failover 547 1. Provide a high availability DHCP service by leveraging the hooks 548 built into DHCPv4 [RFC2131] and its usual implementation to 549 support multiple servers able to respond to client requests. 550 These hooks are: 552 (a) The broadcast of DHCPDISCOVER requests. 554 (b) The transition from unicast for DHCPREQUEST/RENEW to 555 broadcast for DHCPREQUEST/REBIND. 557 (c) The usual implementation of DHCPv4 relay agents to allow 558 forwarding of DHCPv4 requests to multiple different DHCPv4 559 servers. 561 2. Produce a minimal impact on performance of the DHCPv4 server. 563 3. Prevent duplicate IP address allocation even in the event of a 564 network partition. 566 4. Allow multiple failover relationships per server. 568 5. Standardize only the minimum necessary to provide a high 569 availability DHCP service. In particular, avoid standardizing 570 the interchange of configuration information. 572 9.1.2. Goals lead to Concepts 574 The goal to have a minimal performance impact on the operation of the 575 DHCPv4 servers participating in failover is the driving force behind 576 the design of the DHCPv4 failover protocol. 578 The steps in this chain of reasoning are as follows: 580 1. To avoid the major performance impact that a lockstep update of a 581 failover partner would inflict, use a lazy update approach (see 582 Section 6.2.2). 584 2. When using lazy update, there is always the problem that the 585 failover server could crash after it has responded to some number 586 of DHCPv4 clients and before it has updated its partner with the 587 lease information it provided to those clients. 589 3. Thus, when one failover server cannot communicate with another 590 failover server, it cannot know what that other failover server 591 has told any of its DHCPv4 clients. 593 This creates an obvious problem. 595 The central concept in the DHCPv4 failover design is to place a limit 596 on the uncertainty described in point #3, above. The DHCPv4 failover 597 protocol is designed to ensure that every failover server knows at 598 all times, not exactly what its failover partner has told to the 599 DHCPv4 clients with which it is communicating, but rather the limits 600 of what its failover partner could have told any DHCPv4 clients with 601 which it was communicating. 603 This is done by ensuring that no DHCPv4 server participating in a 604 failover relationship will ever offer a lease time to any DHCPv4 605 client that is more than an agreed-upon value beyond that known by 606 its failover partner. 608 This agreed-upon value is called the "Maximum Client Lead Time", and 609 abbreviated MCLT. 611 Thus, every DHCPv4 failover partner needs to know what its partner 612 knows about every lease in the server, and it needs to ensure that it 613 will never provide a lease time to any DHCPv4 client that is beyond 614 what its partner believes the current lease time to be plus the MCLT. 616 Given this fundamental guarantee, if one failover server cannot 617 communicate with its failover partner, then it knows the limits of 618 what any DHCPv4 client of that missing partner might have for a lease 619 time. If this failover server waits until it believes a lease has 620 expired and then also waits until the MCLT has passed, it knows that 621 the lease is sure to have expired (or the DHCPv4 client will have 622 tried to renew the lease and communicated with the remaining DHCPv4 623 server). (We will deal with network partition events below.) 625 In order to allow a remaining failover server to provide service to 626 newly arrived DHCPv4 clients, while waiting out the MCLT beyond the 627 lease expiration (if any), the protocol provides for allocation of 628 some percentage of the available leases to each failover partner. 630 A failover server which cannot commuicate with its partner must 631 therefore wait out the MCLT beyond the lease expiration (if any) of 632 IP addresses before it can allocate them to DHCPv4 clients. This 633 could impact the server's ability to provide available IP addresses 634 to newly arrived DHCPv4 clients. To prevent this impact the DHCPv4 635 failover protocol divides the allocation of the available leases 636 between each failover partner. The protocol supports periodic 637 rebalancing of the allocation of these available leases. 639 9.1.3. Use of the MCLT in practice 641 From the above discussion, it should be clear how to avoid re-using 642 an IP address before it has expired. The MCLT is central to the 643 operation of the protocol. One server cannot offer a lease to a 644 DHCPv4 client that is more than the MCLT beyond the current lease 645 time for this client that is known by the failover partner. From 646 this standpoint, it would be good for the MCLT to be as long as 647 possible. However, in a failure situation, waiting the MCLT beyond 648 the current lease time in order to reuse a leased lease would suggest 649 that the MCLT should be as short as possible. 651 This tension is resolved by anticipating the need to extend lease 652 times when communicating with the failover partner. The first lease 653 offered to a DHCPv4 client can be only as long as the MCLT. However, 654 when the failover server updates its partner, it updates the partner 655 with the desired lease time plus the MCLT. Thus, when the client 656 returns with a renewal request at halfway through the MCLT, the 657 failover server can extend its lease for only the lease time known by 658 the partner plus the MCLT. But the partner now knows the desired 659 lease time, so that the server can extend the lease for as long as it 660 was configured since it had pre-updated the failover partner with 661 this time. 663 Using this approach, one can keep the MCLT relatively short, say 1 664 hour, and still offer leases of any desired extent to clients -- once 665 the failover partner has been updated with the desired lease time. 667 9.1.4. Network Partition Events 669 It is clear that when one failover server finds that it is unable to 670 communicate with its failover partner, it is impossible for that 671 server to tell if its failover partner is down or if the 672 communication path to that failover partner is broken, a situation 673 known as "network partition" (see Section 6.1.2). The DHCPv4 674 failover protocol distinguishes between these different situations by 675 having different failover states to represent "communications- 676 interrupted" situations and a "partner-down" situations. The 677 expectation is that (at least in some situations) it requires an 678 operator action to distinguish between a communications-interrupted 679 and partner-down event. In particular, the DHCPv4 failover protocol 680 does not conflate these two situations. 682 Correct handling of network partition events requires that a failover 683 server unable to communicate with its failover partner (but not yet 684 informed that its failover partner is down), must not re-allocate an 685 IP address from one DHCPv4 client to another. Available addresses 686 may be allocated to any DHCPv4 client. 688 After a failover server has been informed that its partner is down, 689 it can reallocate an IP address from one DHCPv4 client to another 690 once it has waited the MCLT beyond the lease expiration of that IP 691 address. This need to be informed by an external entity that the 692 failover partner is down is the only impact of correctly handling 693 network partition events. Of course, specific implementations can 694 assume that an unreachable failover partner is down after a shorter 695 or longer time, thus limiting the support for a network partition 696 event. 698 9.1.5. Conflict Resolution 700 Whenever one failover server receives an update from its failover 701 partner, it needs to decide if the update it has received is "better" 702 than the information it has in its own database concerning the DHCPv4 703 client or the lease on the IPv4 address. The DHCPv4 failover 704 protocol does not mandate the details of this decision, but this 705 activity must be part of any DHCPv4 implementation. In most cases, 706 comparing the times associated with the failover update with the 707 times held in the server's own database will allow this decision to 708 be made. 710 9.1.6. Load Balancing 712 The DHCPv4 Load Balancing protocol [RFC3074] integrates with the 713 DHCPv4 failover protocol by defining the way that each server decides 714 which DHCPv4 clients to process. Use of load balancing with the 715 DHCPv4 failover protocol is an optional extension to the failover 716 protocol. Both a simple active -- passive relationship without load 717 balancing is defined as well as a more complex active -- active 718 relationship. 720 9.2. DHCPv6 Redundancy Considerations 722 [I-D.ietf-dhc-dhcpv6-redundancy-consider] specifies an interim 723 architecture to provide a semi-redundant DHCPv6 solution before the 724 availability of vendor or standard based solutions. The proposed 725 architecture may be used in wide range of networks. Two notable 726 deployment models are discussed: service provider and enterprise 727 network environments. The described architecture leverages only 728 existing and implemented DHCPv6 standards. 730 10. DHCP Best Practices 732 TODO: Qin Wu provided this best practices link. Describe it briefly. 733 http://technet.microsoft.com/en-us/library/cc780311(WS.10).aspx 735 11. Security Considerations 737 TBD... 739 12. IANA Considerations 741 IANA is not requested to perform any actions at this time. 743 13. Acknowledgements 745 This document extensively uses concepts, definitions and other parts 746 of [dhcpv4-failover] document. Authors would like to thank Shawn 747 Routhier, Qin Wu, Jean-Francois Tremblay, Frank Sweetser, Jiang 748 Sheng, Yu Fu, Greg Gabil and Bernie Volz for their comments and 749 feedback. 751 14. References 753 14.1. Normative References 755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 756 Requirement Levels", BCP 14, RFC 2119, March 1997. 758 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 759 RFC 2131, March 1997. 761 [RFC3074] Volz, B., Gonczi, S., Lemon, T., and R. Stevens, "DHC Load 762 Balancing Algorithm", RFC 3074, February 2001. 764 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 765 and M. Carney, "Dynamic Host Configuration Protocol for 766 IPv6 (DHCPv6)", RFC 3315, July 2003. 768 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 769 Host Configuration Protocol (DHCP) version 6", RFC 3633, 770 December 2003. 772 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 773 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 774 Option", RFC 4704, October 2006. 776 14.2. Informative References 778 [I-D.ietf-dhc-dhcpv6-redundancy-consider] 779 Brzozowski, J., Tremblay, J., Chen, J., and T. Mrugalski, 780 "DHCPv6 Redundancy Deployment Considerations", 781 draft-ietf-dhc-dhcpv6-redundancy-consider-00 (work in 782 progress), April 2011. 784 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 785 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 786 RFC 2136, April 1997. 788 [dhcpv4-failover] 789 Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., 790 Rabil, G., Dooley, M., and A. Kapur, "DHCP Failover 791 Protocol", draft-ietf-dhc-failover-12 (work in progress), 792 March 2003. 794 Authors' Addresses 796 Tomasz Mrugalski (editor) 797 Internet Systems Consortium, Inc. 798 950 Charter Street 799 Redwood City, CA 94063 800 USA 802 Phone: +1 650 423 1345 803 Email: tomasz.mrugalski@gmail.com 804 Kim Kinnear 805 Cisco Systems, Inc. 806 1414 Massachusetts Ave. 807 Boxborough, Massachusetts 01719 808 USA 810 Phone: +1 (978) 936-0000 811 Email: kkinear@cisco.com