idnits 2.17.1 draft-ietf-dhc-dhcpv6-redundancy-consider-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 7, 2012) is 4239 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) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) == Outdated reference: A later version (-07) exists of draft-ietf-dhc-dhcpv6-failover-requirements-01 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) J. Brzozowski 3 Internet-Draft Comcast Cable Communications 4 Intended status: Informational J. Tremblay 5 Expires: March 11, 2013 Videotron Ltd. 6 J. Chen 7 Time Warner Cable 8 T. Mrugalski 9 ISC 10 September 7, 2012 12 DHCPv6 Redundancy Deployment Considerations 13 draft-ietf-dhc-dhcpv6-redundancy-consider-03 15 Abstract 17 This document provides information for those wishing to use DHCPv6 to 18 support their deployment of IPv6. In particular, it discusses the 19 provision of semi-redundant DHCPv6 services. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 11, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Scope and Assumptions . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Applicability to Prefix Delegation . . . . . . . . . . . . 4 58 3. Service Provider Deployment . . . . . . . . . . . . . . . . . 4 59 4. Enterprise Deployment . . . . . . . . . . . . . . . . . . . . 5 60 5. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 5 61 5.1. DHCPv6 Servers . . . . . . . . . . . . . . . . . . . . . . 5 62 5.2. DHCPv6 Relays . . . . . . . . . . . . . . . . . . . . . . 5 63 5.3. DHCPv6 Clients . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 6 65 6.1. Split Prefixes . . . . . . . . . . . . . . . . . . . . . . 6 66 6.2. Multiple Unique Prefixes . . . . . . . . . . . . . . . . . 9 67 6.3. Identical Prefixes . . . . . . . . . . . . . . . . . . . . 10 68 7. Challenges and Issues . . . . . . . . . . . . . . . . . . . . 12 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 74 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Introduction 79 Redundancy and high availability for many components of IPv6 80 infrastructure are desirable and, in some deployments, mandatory. 81 Unfortunately, for DHCPv6 there is currently no standards-based 82 failover or redundancy protocol. An interim solution is to provide 83 semi-redundant services: this document specifies an architecture by 84 which this can be achieved. 86 2. Scope and Assumptions 88 DHCPv6 redundancy may be useful in a wide range of scenarios. 89 Although the architecture suggested in this document is able to be 90 used in a wide range of networks, just two deployment environments 91 are discussed here: service provider and enterprise network. All 92 other scenarios may be generalized to one of these two cases. 94 In the rest of the document, the following assumptions are made with 95 regards to the existing DHCPv6 infrastructure, regardless of the 96 environment being considered: 98 1. At least two DHCPv6 servers provide a service to the same 99 clients. (The architecture does not limit the number of servers, 100 and more may be provided if required.) 102 2. The existing DHCPv6 servers will not directly communicate or 103 interact with one another in the assignment of IPv6 addresses and 104 provision of configuration information to requesting clients. 106 3. DHCPv6 clients are instructed to run stateful DHCPv6 to request 107 at least one IPv6 address. Configuration information and other 108 options (such as a delegated IPv6 prefix) may also be requested 109 as part of the stateful DHCPv6 operation. 111 4. Clients participating in DHCPv6 configuration have to properly 112 handle the preference option, including the processing of 113 ADVERTISE messages, as required by [RFC3315]. 115 5. A DHCPv6 server failure does not imply a failure of any other 116 network service or protocol (e.g. TFTP servers). The redundancy 117 of any additional services configured by means of DHCPv6 are 118 outside the scope of this document. (For example, a single 119 DHCPv6 server may configure multiple TFTP servers, with 120 preference for each TFTP server, as specified in [RFC5970].) 122 While the techniques described in this document provide some aspects 123 of redundancy, it should be noted that complete redundancy will not 124 be available until a DHCPv6 failover protocol is standardized. The 125 requirements for such protocol are described in 126 [I-D.ietf-dhc-dhcpv6-failover-requirements]. 128 2.1. Applicability to Prefix Delegation 130 The same approaches discussed in this document can potentially be 131 applied to prefix delegation [RFC3633]. One obvious drawback of 132 using split prefix model for PD is that use of resources is doubled. 133 It should be noted that such applicability remains theoretical and 134 was not investigated thoroughly during work on this document. As 135 such, the applicability of presented mechanisms to the prefix 136 delegation is outside of scope of this document. 138 3. Service Provider Deployment 140 The service provider model represents cases where the network and 141 end-user devices may be administered by separate entities. 143 The DHCPv6 clients include cable modems, customer gateways or home 144 routers, and end-user devices: these are collectively referred to as 145 Customer Premises Equipment (CPE). In some cases hosts may be 146 configured directly using the service provider DHCPv6 infrastructure; 147 in others, configuration may be via an intermediate router which is 148 being configured by the provider DHCPv6 infrastructure. Either way, 149 the service provider DHCPv6 infrastructure may be semi-redundant. 151 In discussing this environment, additional assumptions to those 152 listed in Section 2 have been made: 154 1. The service provider edge routers and access routers (CMTS for 155 cable or DSLAM/BRAS for DSL for example) are IPv6 enabled when 156 required. 158 2. CPE devices are instructed to perform stateful DHCPv6 to request 159 at least one IPv6 address, delegated prefix, and/or configuration 160 information. CPE devices may also be instructed to use stateless 161 DHCPv6 [RFC3736] to acquire configuration information only, a 162 situation that assumes the IPv6 address and prefix information 163 has been acquired using other means. 165 3. The primary application of this architecture is for native IPv6 166 services. (Use and applicability to transition mechanisms is out 167 of scope for this document.) 169 4. The CPE devices must implement a stateful DHCPv6 client 170 [RFC3315]. Support for DHCPv6 prefix delegation [RFC3633] or 171 stateless DHCPv6 [RFC3736] may also be implemented. 173 4. Enterprise Deployment 175 The enterprise deployment environment covers cases where end-user 176 devices are direct consumers of the configuration without any 177 intermediate devices (as was the case with home routers used in the 178 service provider environment). Although enterprise IPv6 environments 179 quite often use or require DHCPv6 relay agents, the relays do not 180 influence or process the configuration in any way and merely act as a 181 transport mechanism. 183 The additional assumptions made for this model beyond those listed in 184 Section 2 are: 186 1. DHCPv6 clients are hosts and are considered end nodes i.e. they 187 consume provided configuration and not use it to provision other 188 devices. Examples of such clients include desktop computers, 189 laptops, printers, other typical office equipment and some mobile 190 devices. 192 2. The DHCPv6 clients generally do not require the assignment of an 193 IPv6 prefix delegation and as such they typically do not support 194 DHCPv6 prefix delegation [RFC3633]. 196 5. Protocol Requirements 198 Implementation of the architecture for semi-redundant DHCPv6 services 199 using existing protocols places require the component DHCPv6 clients, 200 relays, and servers to have certain capabilities. The following 201 sections describe the requirements of such devices. 203 5.1. DHCPv6 Servers 205 This interim architecture requires the DHCPv6 servers that are 206 [RFC3315] compliant and support the necessary options. Essential to 207 the architecture is support for stateful DHCPv6 and the DHCPv6 208 preference option [RFC3315]. For deployment scenarios where IPv6 209 prefix delegation is needed, DHCPv6 servers must support DHCPv6 210 prefix delegation as defined by [RFC3633]. Furthermore, the DHCPv6 211 servers must support [RFC3736] if stateless DHCPv6 is used. 213 5.2. DHCPv6 Relays 215 DHCPv6 relay agents must be [RFC3315] compliant and must support the 216 ability to relay DHCPv6 messages to more than one destination. 218 5.3. DHCPv6 Clients 220 DHCPv6 clients are required to be compliant with [RFC3315] and 221 support the necessary options required to support the solution 222 depending on the mode of operations and desired behaviour: 224 o If prefix delegation is required, DHCPv6 clients must support 225 DHCPv6 prefix delegation as defined in [RFC3633]. 227 o Clients must support the acquisition of at least one IPv6 address 228 and configuration information using stateful DHCPv6 as specified 229 by [RFC3315]. 231 o Stateless DHCPv6 [RFC3736] may also be supported. 233 o DHCPv6 clients must recognize and adhere to the processing of the 234 advertised DHCPv6 preference options sent by the DHCPv6 servers. 236 6. Deployment Models 238 At the time of writing, a standards-based DHCPv6 redundancy protocol 239 is not available. In the interim solution presented here, existing 240 DHCPv6 server implementations are used as-is to provide best effort, 241 semi-redundant DHCPv6 services. The behavior of these services will, 242 in part, be governed by the configuration of each of the servers. 243 Various aspects of the DHCPv6 protocol [RFC3315] are used to yield 244 the desired behaviour, although there is no inter-server or inter- 245 process communication to coordinate DHCPv6 events and/or activities. 247 The solution does not impact on DHCPv4, so DHCP services for both 248 IPv4 and IPv6 may operate simultaneously on the same physical 249 server(s) or may operate on different ones. 251 This section defines three semi-redundant models. Although /64 252 prefixes are used throughout the following sections as examples, 253 other prefix lengths may be used as well. 255 6.1. Split Prefixes 257 In the split prefixes model, each DHCPv6 server is configured with a 258 unique, non-overlapping pool derived from the /64 prefix deployed for 259 use within an IPv6 network. For example, distributing an allocated 260 /64 such as 2001:db8:1:0001::/64 between two servers would require 261 that it be split into two /65 pools, 2001:db8:1:0001:0000::/65 and 262 2001:db8:1:0001:8000::/65. 264 Both DHCPv6 servers are simultaneously active and operational, and 265 each allocates IPv6 addresses from the corresponding pools per device 266 class. The address allocation is governed largely through the use of 267 the DHCPv6 preference option, so the server with the higher 268 preference value is always preferred. Additional proprietary 269 mechanisms can be used to further enforce the favouring of one DHCP 270 server over another. An example of such a scenario is presented in 271 Figure 1. 273 It is important to note that, over time, it is possible that bindings 274 will be unevenly distributed amongst the DHCPv6 servers and no one 275 server will be authoritative for all of them. 277 As defined in [RFC3315], a DHCPv6 ADVERTISE message with a preference 278 option of 255 is an indicator to a DHCPv6 client to immediately begin 279 a client-initiated message exchange by transmitting a REQUEST message 280 to the server that sent the ADVERTISE. Alternatively, a DHCPv6 281 ADVERTISE message with no preference option (or one with a value less 282 than 255) is an indicator to the client that it must wait for 283 subsequent ADVERTISE messages before choosing the server to which is 284 responds, as described in Section 17.1.2 of [RFC3315]. 286 In the event of a DHCPv6 server failure it is desirable (but not 287 essential) for a server other than the server that originally 288 responded to be able to rebind the client's lease. Given the 289 proposed architecture, the remaining active DHCPv6 server will have a 290 different address pool configured, making it technically incorrect 291 for the same to rebind the client in its current state. Ultimately, 292 the rebinding will fail and the client will acquire a new binding 293 from the pool configured in the active server. 295 To reduce the possibility that a client or some other element on the 296 network will experience a disruption in service or access to relevant 297 binding data, shorter values for T1, T2, valid, and preferred 298 lifetimes can be used. The values for the last three can be adjusted 299 or configured to minimize service disruption. Ideally, setting them 300 equal (or nealy equal) can be used to trigger a DHCPv6 client to 301 reacquire the IPv6 address, prefix, and or configuration information 302 almost immediately after the rebinding fails. It is important to 303 note however, that shorter values will create an additional load on 304 the DHCPv6 servers. 306 While using a split prefix configuration model the dynamic updates to 307 DNS [RFC2136] can be coordinated to ensure that the DNS is properly 308 updated with the current binding information. Challenges arise with 309 regards to the update of the PTR resource record for IPv6 addresses 310 since the DNS information may need to be overwritten in a failure 311 condition. The use of a split prefixes enables the differentiation 312 of bindings and binding timing to determine which represents the 313 current state. This becomes particularly important when DHCPv6 314 Leasequery [RFC5007] and/or DHCPv6 Bulk Leasequery [RFC5460] are used 315 to determine lease or binding state. 317 Finally, a benefit of this scheme is that the use of separate pools 318 per DHCPv6 server makes failure conditions more obvious and 319 detectable. 321 +----------+ +-----------+ 322 | Client 1 +-\ +--+ Server 1 | 323 +----------+ \ | +-----------+ 324 \ | 325 \ | 326 \ | 327 +----------+ \ | +-----------+ 328 | Client 2 +--------------+--| Server 2 | 329 +----------+ / | +-----------+ 330 . / . 331 . / . 332 . / . 333 +----------+ / . +-----------+ 334 | Client N +-/ .--| n+1 Server| 335 +----------+ +-----------+ 337 Server 1 338 ======== 339 Prefix = 2001:db8:1:0:0::/64 340 Pool = 2001:db8:1:0:0::/65 341 Preference = 255 343 Server 2 344 ======== 345 Prefix = 2001:db8:1:0:0::/64 346 Pool = 2001:db8:1:0:8000::/65 347 Preference = 0 349 Server n+1 350 ========== 351 Prefix, pool, and preference would 352 vary based on prefix definition 354 Split prefixes approach. 356 Figure 1 358 6.2. Multiple Unique Prefixes 360 In the multiple prefix model, each DHCPv6 server is configured with a 361 unique, non-overlapping prefix. A /64 pool equal to the prefix is 362 configured on each server. For example, the 2001:db8:1:0000::/64 363 pool would be assigned to a single DHCPv6 server for allocation to 364 clients equal to its parent prefix 2001:db8:1:0000::/64. The second 365 DHCPv6 server could use 2001:db8:1:0001:::/64 as both pool and 366 prefix. This would be repeated for each active DHCP server. An 367 example of this scenario is presented in Figure 2. 369 The major difference between the split prefixes approach and the 370 multiple unique prefixes one is that the latter does not require 371 prefixes to be adjacent. In fact, the split prefixes approach can be 372 considered a special case of the multiple unique prefixes approach. 374 This approach uses a unique prefix and ultimately pool per DHCPv6 375 server with the corresponding prefixes configured for use in the 376 network. The corresponding network infrastructure must in turn be 377 configured to use multiple prefixes on the interface(s) facing the 378 DHCPv6 clients. The configuration is similar on all the servers, but 379 a different prefix and a different preference is used for each DHCPv6 380 server. 382 This approach drastically increases the rate of consumption of IPv6 383 prefixes and also yields operational and management challenges 384 related to the underlying network since a significantly higher number 385 of prefixes need to be configured and routed. It also does not 386 provide a clean migration path to the desired solution using a 387 standards-based DHCPv6 redundancy or failover protocol (which of 388 course, has yet to be specified). 390 The use of multiple unique prefixes provides benefits related to 391 dynamic updates to DNS similar to those referred to in Section 6.1. 392 The use of multiple unique prefixes enables the differentiation of 393 bindings and binding timing to determine which represents the current 394 state. This becomes particularly important when DHCPv6 Leasequery 395 [RFC5007] and/or DHCPv6 Bulk Leasequery [RFC5460] are used to 396 determine lease or binding state. The use of separate prefixes and 397 pools per DHCPv6 server makes failure conditions more obvious and 398 detectable. 400 +----------+ +-----------+ 401 | Client 1 +-\ +--+ Server 1 | 402 +----------+ \ | +-----------+ 403 \ | 404 \ | 405 \ | 406 +----------+ \ | +-----------+ 407 | Client 2 +--------------+--| Server 2 | 408 +----------+ / | +-----------+ 409 . / . 410 . / . 411 . / . 412 +----------+ / . +-----------+ 413 | Client N +-/ .--| n+1 Server| 414 +----------+ +-----------+ 416 Server 1 417 ======== 418 Prefix = 2001:db8:1:0000::/64 419 Pool = 2001:db8:1:0000::/64 420 Preference = 255 422 Server 2 423 ======== 424 Prefix = 2001:db8:1:1000::/64 425 Pool = 2001:db8:1:1000::/64 426 Preference = 0 428 Server 3 429 ======== 430 Prefix = 2001:db8:1:2000::/64 431 Pool = 2001:db8:1:2000::/64 432 Preference = [0..255) 434 Multiple unique prefix approach. 436 Figure 2 438 6.3. Identical Prefixes 440 In the identical prefix model, each DHCPv6 server is configured with 441 the same overlapping prefix and pool deployed for use within an IPv6 442 network. Distribution between two or more servers, for example, 443 would require that the same /64 prefix and pool be configured on all 444 DHCP servers. For example, the 2001:db8:1:0001:0000::/64 pool would 445 be assigned to all the DHCPv6 servers for allocation to clients 446 derived from the 2001:db8:1:0001::/64 pool. This would be repeated 447 for each active DHCP server. An example of such a scenario is 448 presented in Figure 3. 450 This approach uses the same prefix, length, and pool definition 451 across multiple DHCPv6 servers: all other configuration parameters 452 remain the same, with the exception of the DHCPv6 preference. Such 453 an approach conceivably eases the migration of DHCPv6 services to 454 fully support a standards based redundancy or failover protocol, once 455 such solution becomes available. Similar to the split prefix 456 architecture described above this approach does not place any 457 additional addressing requirements on the network infrastructure. 459 The use of identical prefixes provides no benefit or advantage 460 related to dynamic DNS updates, support of DHCPv6 Leasequery 461 [RFC5007] or DHCPv6 Bulk Leasequery [RFC5460]. In this case all DHCP 462 servers will use the same prefix and pool configurations making it 463 less obvious that a failure condition or event has occurred. 465 +----------+ +-----------+ 466 | Client 1 +-\ +--+ Server 1 | 467 +----------+ \ | +-----------+ 468 \ | 469 \ | 470 \ | 471 +----------+ \ | +-----------+ 472 | Client 2 +--------------+--| Server 2 | 473 +----------+ / | +-----------+ 474 . / . 475 . / . 476 . / . 477 +----------+ / . +-----------+ 478 | Client N +-/ .--| n+1 Server| 479 +----------+ +-----------+ 481 Server 1 482 ======== 483 Prefix = 2001:db8:1:0000::/64 484 Pool = 2001:db8:1:0000::/64 485 Preference = 255 487 Server 2 488 ======== 489 Prefix = 2001:db8:1:0000::/64 490 Pool = 2001:db8:1:0000::/64 491 Preference = 0 493 Server 3 494 ======== 495 Prefix = 2001:db8:1:0000::/64 496 Pool = 2001:db8:1:0000::/64 497 Preference = [0..255) 499 Identical prefix approach. 501 Figure 3 503 7. Challenges and Issues 505 The lack of interaction between DHCPv6 servers introduces a number of 506 challenges related to the operations of the same service instances in 507 a production environment. The following areas are of particular 508 concern: 510 o In the identical prefixes scenario, both servers must follow the 511 same address allocation procedure, i.e. they both must use the 512 same algorithm and the same policy to determine which address is 513 going to be assigned to a specific client. Otherwise there is a 514 distinct chance that each server will assign the same address to 515 two different clients. It is expected that both servers will 516 receive each incoming REQUEST message. Usually no special action 517 is required to achieve this as REQUEST messages are sent to 518 multicast address by directly connected clients. Relays are 519 expected to forward incoming client messages to all servers. The 520 client indicates chosen server by including its DUID in Server-ID 521 option. The chosen server assigns the address and other 522 configuration options, while the other server discards the 523 incoming request. In case of a failure of one server, the other 524 server will assign the same address by following the same 525 algorithm and the same policy. 527 o Interactions with DNS server(s) using dynamic update for the same 528 address when one or more DHCPv6 servers have become unavailable. 529 This specifically becomes a challenge when (or if) nodes that were 530 initially granted a lease: 532 1. Attempt to renew or rebind the lease originally granted, or 534 2. Attempt to obtain a new lease 536 The DHCID resource record [RFC4701] allows identification of the 537 current owner of the specific DNS data that is the target of an 538 update [RFC2136]. [RFC4704] specifies how DHCPv6 servers and/or 539 client may perform updates. [RFC4703] provides a way to solve 540 conflicts between clients. Although the [RFC4703] deals with most 541 cases, it is still possible to leave abandoned resource records. 542 Consider the following scenario: there are two independent 543 servers, A and B. Server A assigns a lease to a client and updates 544 the DNS with an AAAA record for the assigned address. When the 545 client renews, server A is not available and server B assigns a 546 different lease. The DNS is again updated, so now two AAAA 547 resource records are present for the client: there is no 548 indication as which of the two leases is active. If server A 549 never recovers, its information may never be removed (although it 550 should be noted that this case is somewhat similar to that of a 551 single server crashing and leaving abandoned resource records). 553 o Interactions with DHCPv6 servers to facilitate the acquisition of 554 IPv6 lease data by way of the DHCPv6 Leasequery [RFC5007] or 555 DHCPv6 Bulk Leasequery [RFC5460] protocols when one or more DHCPv6 556 servers have granted leases to DHCPv6 clients and later became 557 unavailable. If the lease data is required and the granting 558 server is unavailable, it will not be possible to obtain any 559 information about leases granted until one of the following has 560 taken place: 562 1. The granting DHCPv6 server becomes available with all lease 563 information restored. 565 2. The client has renewed or rebound its lease against a 566 different DHCPv6 server. 568 It is important to note that any exchange of available leases and 569 synchronization between DHCPv6 servers is not possible until a 570 redundancy or failover protocol is standardized or proprietary 571 solutions become available. 573 8. IANA Considerations 575 This document does not require any actions from IANA. 577 9. Security Considerations 579 Additional security considerations are created through the use of 580 this interim architecture beyond what has been cited in Section 23 of 581 [RFC3315]. In particular, Dynamic DNS update using the models 582 defined in this document allows for the possibility of not removing 583 abandoned DNS records, even when using conflict resolution mechanism 584 defined in [RFC4703]. However, this is no worse than a case where a 585 single deployed server crashes and its lease database cannot be 586 recovered. 588 When using identical prefixes model, care must be taken to ensure 589 that all servers use the same lease allocation procedure and are 590 configured with the same policy. If this guidance is not followed, 591 there is a risk of assignment of the same lease to two separate 592 clients. In some cases that situation can be recovered by using 593 Duplicate Address Detection (Neighbor Discovery) and DECLINE 594 mechanism (DHCPv6). 596 10. Acknowledgements 598 Authors would like to thank Bernie Volz, Kim Kinnear, Ralph Droms, 599 David Hankins, Chuck Anderson, Ted Lemon, Stephen Farrel, Pete 600 McCann, Robert Sparks, Martin Stiemerling, Brian Haberman and Barry 601 Leiba for their input and review. 603 Special thanks to Stephen Morris for his numerous spelling, grammar 604 corrections and proof-reading. 606 This work has been partially supported by Department of Computer 607 Communications (a division of Gdansk University of Technology) and 608 the Polish Ministry of Science and Higher Education under the 609 European Regional Development Fund, Grant No. POIG.01.01.02-00-045/ 610 09-00 (Future Internet Engineering Project). 612 11. References 614 11.1. Normative References 616 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 617 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 618 RFC 2136, April 1997. 620 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 621 and M. Carney, "Dynamic Host Configuration Protocol for 622 IPv6 (DHCPv6)", RFC 3315, July 2003. 624 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 625 Host Configuration Protocol (DHCP) version 6", RFC 3633, 626 December 2003. 628 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 629 (DHCP) Service for IPv6", RFC 3736, April 2004. 631 [RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource 632 Record (RR) for Encoding Dynamic Host Configuration 633 Protocol (DHCP) Information (DHCID RR)", RFC 4701, 634 October 2006. 636 [RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified 637 Domain Name (FQDN) Conflicts among Dynamic Host 638 Configuration Protocol (DHCP) Clients", RFC 4703, 639 October 2006. 641 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 642 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 643 Option", RFC 4704, October 2006. 645 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 646 "DHCPv6 Leasequery", RFC 5007, September 2007. 648 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 649 February 2009. 651 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 652 Options for Network Boot", RFC 5970, September 2010. 654 11.2. Informative References 656 [I-D.ietf-dhc-dhcpv6-failover-requirements] 657 Mrugalski, T. and K. Kinnear, "DHCPv6 Failover 658 Requirements", 659 draft-ietf-dhc-dhcpv6-failover-requirements-01 (work in 660 progress), July 2012. 662 Authors' Addresses 664 John Jason Brzozowski 665 Comcast Cable Communications 666 1306 Goshen Parkway 667 West Chester, PA 19380 668 USA 670 Phone: +1-609-377-6594 671 Email: john_brzozowski@cable.comcast.com 673 Jean-Francois Tremblay 674 Videotron Ltd. 675 612 Saint-Jacques 676 Montreal, Quebec H3C 4M8 677 Canada 679 Email: jf@jftremblay.com 681 Jack Chen 682 Time Warner Cable 683 13820 Sunrise Valley Drive 684 Herndon, VA 20171 685 USA 687 Email: jack.chen@twcable.com 688 Tomasz Mrugalski 689 Internet Systems Consortium, Inc. 690 950 Charter St. 691 Redwood City, CA 94063 692 USA 694 Phone: +1 650 423 1345 695 Email: tomasz.mrugalski@gmail.com