1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
|
<pre>Internet Engineering Task Force (IETF) J. Brzozowski
Request for Comments: 6853 Comcast Cable Communications
BCP: 180 J. Tremblay
Category: Best Current Practice Videotron G.P.
ISSN: 2070-1721 J. Chen
Time Warner Cable
T. Mrugalski
ISC
February 2013
<span class="h1">DHCPv6 Redundancy Deployment Considerations</span>
Abstract
This document provides information for those wishing to use DHCPv6 to
support their deployment of IPv6. In particular, it discusses the
provision of semi-redundant DHCPv6 services.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6853">http://www.rfc-editor.org/info/rfc6853</a>.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Brzozowski, et al. Best Current Practice [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6853">RFC 6853</a> DHCPv6 Redundancy Considerations February 2013</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Scope and Assumptions . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2.1">2.1</a>. Applicability to Prefix Delegation . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Service Provider Deployment . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. Enterprise Deployment . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5">5</a>. Protocol Requirements . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5.1">5.1</a>. DHCPv6 Servers . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5.2">5.2</a>. DHCPv6 Relays . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5.3">5.3</a>. DHCPv6 Clients . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-6">6</a>. Deployment Models . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-6.1">6.1</a>. Split Prefixes . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-6.2">6.2</a>. Multiple Unique Prefixes . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6.3">6.3</a>. Identical Prefixes . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-7">7</a>. Challenges and Issues . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-9">9</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-10.1">10.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-10.2">10.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Redundancy and high availability for many components of IPv6
infrastructure are desirable and, in some deployments, mandatory.
Unfortunately, for DHCPv6 there is currently no standards-based
failover or redundancy protocol. An interim solution is to provide
semi-redundant services: this document specifies an architecture by
which this can be achieved.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Scope and Assumptions</span>
DHCPv6 redundancy may be useful in a wide range of scenarios.
Although the architecture suggested in this document is able to be
used in a wide range of networks, just two deployment environments
are discussed here: service provider and enterprise network. All
other scenarios may be generalized to one of these two cases.
In the rest of the document, the following assumptions are made with
regards to the existing DHCPv6 infrastructure, regardless of the
environment being considered:
1. At least two DHCPv6 servers provide a service to the same
clients. (The architecture does not limit the number of servers,
and more may be provided if required.)
<span class="grey">Brzozowski, et al. Best Current Practice [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6853">RFC 6853</a> DHCPv6 Redundancy Considerations February 2013</span>
2. The existing DHCPv6 servers will not directly communicate or
interact with one another in the assignment of IPv6 addresses and
the provision of configuration information to requesting clients.
3. DHCPv6 clients are instructed to run stateful DHCPv6 to request
at least one IPv6 address. Configuration information and other
options (such as a delegated IPv6 prefix) may also be requested
as part of the stateful DHCPv6 operation.
4. Clients participating in DHCPv6 configuration have to properly
handle the preference option, including the processing of
ADVERTISE messages as required by [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>].
5. A DHCPv6 server failure does not imply a failure of any other
network service or protocol (e.g., TFTP servers). The redundancy
of any additional services configured by means of DHCPv6 are
outside the scope of this document. (For example, a single
DHCPv6 server may configure multiple TFTP servers, with
preference for each TFTP server, as specified in [<a href="./rfc5970" title=""DHCPv6 Options for Network Boot"">RFC5970</a>].)
While the techniques described in this document provide some aspects
of redundancy, it should be noted that complete redundancy will not
be available until a DHCPv6 failover protocol is standardized. The
requirements for such a protocol are described in [<a href="#ref-FAILREQ" title=""DHCPv6 Failover Requirements"">FAILREQ</a>].
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Applicability to Prefix Delegation</span>
The same approaches discussed in this document can potentially be
applied to prefix delegation (PD) [<a href="./rfc3633" title=""IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6"">RFC3633</a>]. One obvious drawback of
using a split prefix model for PD is that use of resources is
doubled. It should be noted that such applicability remains
theoretical and was not investigated thoroughly during work on this
document. As such, the applicability of presented mechanisms to the
prefix delegation is outside of the scope of this document.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Service Provider Deployment</span>
The service provider model represents cases where the network and
end-user devices may be administered by separate entities.
The DHCPv6 clients include cable modems, customer gateways or home
routers, and end-user devices: these are collectively referred to as
Customer Premises Equipment (CPE). In some cases hosts may be
configured directly using the service provider DHCPv6 infrastructure;
in others, configuration may be via an intermediate router that is
being configured by the provider DHCPv6 infrastructure. Either way,
the service provider DHCPv6 infrastructure may be semi-redundant.
<span class="grey">Brzozowski, et al. Best Current Practice [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6853">RFC 6853</a> DHCPv6 Redundancy Considerations February 2013</span>
In discussing this environment, additional assumptions to those
listed in <a href="#section-2">Section 2</a> have been made:
1. The service provider edge routers and access routers are IPv6
enabled when required. These routers are, for example, CMTS
(Cable Modem Termination System) for cable or DSLAM/BRAS (Digital
Subscriber Link Access Multiplexer / Broadband Remote Access
Server) for DSL.
2. CPE devices are instructed to perform stateful DHCPv6 to request
at least one IPv6 address, delegated prefix, and/or configuration
information. CPE devices may also be instructed to use stateless
DHCPv6 [<a href="./rfc3736" title=""Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6"">RFC3736</a>] to acquire configuration information only, a
situation that assumes the IPv6 address and prefix information
has been acquired using other means.
3. The primary application of this architecture is for native IPv6
services. (Use and applicability to transition mechanisms are
out of scope for this document.)
4. The CPE devices must implement a stateful DHCPv6 client
[<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>]. Support for DHCPv6 prefix delegation [<a href="./rfc3633" title=""IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6"">RFC3633</a>] or
stateless DHCPv6 [<a href="./rfc3736" title=""Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6"">RFC3736</a>] may also be implemented.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Enterprise Deployment</span>
The enterprise deployment environment covers cases where end-user
devices are direct consumers of the configuration provided by the
DHCP servers without any intermediate devices (as was the case with
home routers used in the service provider environment). Although
enterprise IPv6 environments quite often use or require DHCPv6 relay
agents, the relays do not influence or process the configuration in
any way and merely act as a transport mechanism.
The additional assumptions made for this model beyond those listed in
<a href="#section-2">Section 2</a> are:
1. DHCPv6 clients are hosts and are considered end nodes, i.e., they
consume provided configuration and do not use it to provision
other devices. Examples of such clients include desktop
computers, laptops, printers, other typical office equipment, and
some mobile devices.
2. The DHCPv6 clients generally do not require the assignment of an
IPv6 prefix delegation, and as such they typically do not support
DHCPv6 prefix delegation [<a href="./rfc3633" title=""IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6"">RFC3633</a>].
<span class="grey">Brzozowski, et al. Best Current Practice [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6853">RFC 6853</a> DHCPv6 Redundancy Considerations February 2013</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Protocol Requirements</span>
Implementation of the architecture for semi-redundant DHCPv6 services
using existing protocols requires the component DHCPv6 clients,
relays, and servers to have certain capabilities. The following
sections describe the requirements of such devices.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. DHCPv6 Servers</span>
This interim architecture requires the DHCPv6 servers that are
[<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>] compliant and support the necessary options. Support for
stateful DHCPv6 and the DHCPv6 preference option [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>] is
essential to the architecture. For deployment scenarios where IPv6
prefix delegation is needed, DHCPv6 servers must support DHCPv6
prefix delegation as defined by [<a href="./rfc3633" title=""IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6"">RFC3633</a>]. Furthermore, the DHCPv6
servers must support [<a href="./rfc3736" title=""Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6"">RFC3736</a>] if stateless DHCPv6 is used.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. DHCPv6 Relays</span>
DHCPv6 relay agents must be [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>] compliant and must support the
ability to relay DHCPv6 messages to more than one destination.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. DHCPv6 Clients</span>
DHCPv6 clients are required to be compliant with [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>] and
support the necessary options required to support the solution
depending on the mode of operations and desired behavior:
o If prefix delegation is required, DHCPv6 clients must support
DHCPv6 prefix delegation as defined in [<a href="./rfc3633" title=""IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6"">RFC3633</a>].
o Clients must support the acquisition of at least one IPv6 address
and configuration information using stateful DHCPv6 as specified
by [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>].
o Stateless DHCPv6 [<a href="./rfc3736" title=""Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6"">RFC3736</a>] may also be supported.
o DHCPv6 clients must recognize and adhere to the processing of the
advertised DHCPv6 preference option sent by the DHCPv6 servers.
<span class="grey">Brzozowski, et al. Best Current Practice [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6853">RFC 6853</a> DHCPv6 Redundancy Considerations February 2013</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Deployment Models</span>
At the time of writing, a standards-based DHCPv6 redundancy protocol
is not available. In the interim solution presented here, existing
DHCPv6 server implementations are used as-is to provide best effort,
semi-redundant DHCPv6 services. The behavior of these services will,
in part, be governed by the configuration of each of the servers.
Various aspects of the DHCPv6 protocol [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>] are used to yield
the desired behavior, although there is no inter-server or inter-
process communication to coordinate DHCPv6 events and/or activities.
The solution does not impact DHCPv4, so DHCP services for both IPv4
and IPv6 may operate simultaneously on the same physical server(s) or
may operate on different ones.
This section defines three semi-redundant models. Although /64
prefixes are used throughout the following sections as examples,
other prefix lengths may be used as well.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Split Prefixes</span>
In the split prefixes model, each DHCPv6 server is configured with a
unique, non-overlapping pool derived from the /64 prefix deployed for
use within an IPv6 network. For example, distributing an allocated
/64 such as 2001:db8:1:1::/64 between two servers would require that
it be split into two /65 pools, 2001:db8:1:1:0000::/65 and 2001:db8:
1:1:8000::/65.
Both DHCPv6 servers are simultaneously active and operational, and
each allocates IPv6 addresses from the corresponding pools per device
class. The address allocation is governed largely through the use of
the DHCPv6 preference option, so the server with the higher
preference value is always preferred. Additional proprietary
mechanisms can be used to further enforce the favoring of one DHCP
server over another. An example of such a scenario is presented in
Figure 1.
It is important to note that, over time, it is possible that bindings
will be unevenly distributed amongst the DHCPv6 servers, and no one
server will be authoritative for all of them.
As defined in [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>], a DHCPv6 ADVERTISE message with a preference
option of 255 is an indicator to a DHCPv6 client to immediately begin
a client-initiated message exchange by transmitting a REQUEST message
to the server that sent the ADVERTISE. Alternatively, a DHCPv6
ADVERTISE message with no preference option (or one with a value less
<span class="grey">Brzozowski, et al. Best Current Practice [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6853">RFC 6853</a> DHCPv6 Redundancy Considerations February 2013</span>
than 255) is an indicator to the client that it must wait for
subsequent ADVERTISE messages before choosing the server to which is
responds, as described in <a href="./rfc3315#section-17.1.2">Section 17.1.2 of [RFC3315]</a>.
In the event of a DHCPv6 server failure, it is desirable (but not
essential) for a server other than the server that originally
responded to be able to rebind the client's lease. Given the
proposed architecture, the remaining active DHCPv6 server will have a
different address pool configured, making it technically incorrect to
rebind the client in its current state. Ultimately, the rebinding
will fail and the client will acquire a new binding from the pool
configured in the active server.
To reduce the possibility that a client or some other element on the
network will experience a disruption in service or access to relevant
binding data, shorter values for T1, T2, valid, and preferred
lifetimes can be used. The values for the last three can be adjusted
or configured to minimize service disruption. Ideally, setting them
equal (or nearly equal) can be used to trigger a DHCPv6 client to
reacquire the IPv6 address, prefix, and/or configuration information
almost immediately after the rebinding fails. It is important to
note, however, that shorter values will create an additional load on
the DHCPv6 servers.
While using a split prefix configuration model, the dynamic updates
to DNS [<a href="./rfc2136" title=""Dynamic Updates in the Domain Name System (DNS UPDATE)"">RFC2136</a>] can be coordinated to ensure that the DNS is
properly updated with the current binding information. Challenges
arise with regards to the update of the PTR resource record for IPv6
addresses since the DNS information may need to be overwritten in a
failure condition. The use of split prefixes enables the
differentiation of bindings and binding timing to determine which
represents the current state. This becomes particularly important
when DHCPv6 Leasequery [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>] and/or DHCPv6 Bulk Leasequery
[<a href="./rfc5460" title=""DHCPv6 Bulk Leasequery"">RFC5460</a>] are used to determine lease or binding state.
Finally, a benefit of this scheme is that the use of separate pools
per DHCPv6 server makes failure conditions more obvious and
detectable.
<span class="grey">Brzozowski, et al. Best Current Practice [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6853">RFC 6853</a> DHCPv6 Redundancy Considerations February 2013</span>
+----------+ +-----------+
| Client 1 +-\ +--+ Server 1 |
+----------+ \ | +-----------+
\ |
\ |
\ |
+----------+ \ | +-----------+
| Client 2 +--------------+--| Server 2 |
+----------+ / | +-----------+
. / .
. / .
. / .
+----------+ / . +-----------+
| Client N +-/ .--| n+1 Server|
+----------+ +-----------+
Server 1
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1:0000::/65
Preference = 255
Server 2
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1:8000::/65
Preference = 0
Server n+1
==========
Prefix, pool, and preference would
vary based on prefix definition
Figure 1: Split prefixes approach
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Multiple Unique Prefixes</span>
In the multiple prefix model, each DHCPv6 server is configured with a
unique, non-overlapping prefix. A /64 pool equal to the prefix is
configured on each server. For example, the 2001:db8:1:1::/64 pool
would be assigned to a single DHCPv6 server for allocation to clients
equal to its parent prefix 2001:db8:1:1::/64. The second DHCPv6
server could use 2001:db8:1:5::/64 as both pool and prefix. This
would be repeated for each active DHCP server. An example of this
scenario is presented in Figure 2.
<span class="grey">Brzozowski, et al. Best Current Practice [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6853">RFC 6853</a> DHCPv6 Redundancy Considerations February 2013</span>
The major difference between the split prefixes approach and the
multiple unique prefixes approach is that the latter does not require
prefixes to be adjacent. In fact, the split prefixes approach can be
considered a special case of the multiple unique prefixes approach.
This approach uses a unique prefix and ultimately a single pool per
DHCPv6 server with the corresponding prefixes configured for use in
the network. The corresponding network infrastructure must in turn
be configured to use multiple prefixes on the interface(s) facing the
DHCPv6 clients. The configuration is similar on all the servers, but
a different prefix and a different preference are used for each
DHCPv6 server.
This approach drastically increases the rate of consumption of IPv6
prefixes and also yields operational and management challenges
related to the underlying network since a significantly higher number
of prefixes need to be configured and routed. It also does not
provide a clean migration path to the desired solution using a
standards-based DHCPv6 redundancy or failover protocol (which, of
course, has yet to be specified).
The use of multiple unique prefixes provides benefits related to
dynamic updates to DNS similar to those referred to in <a href="#section-6.1">Section 6.1</a>.
The use of multiple unique prefixes enables the differentiation of
bindings and binding timing to determine which represents the current
state. This becomes particularly important when DHCPv6 Leasequery
[<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>] and/or DHCPv6 Bulk Leasequery [<a href="./rfc5460" title=""DHCPv6 Bulk Leasequery"">RFC5460</a>] are used to
determine lease or binding state. The use of separate prefixes and
pools per DHCPv6 server makes failure conditions more obvious and
detectable.
<span class="grey">Brzozowski, et al. Best Current Practice [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6853">RFC 6853</a> DHCPv6 Redundancy Considerations February 2013</span>
+----------+ +-----------+
| Client 1 +-\ +--+ Server 1 |
+----------+ \ | +-----------+
\ |
\ |
\ |
+----------+ \ | +-----------+
| Client 2 +--------------+--| Server 2 |
+----------+ / | +-----------+
. / .
. / .
. / .
+----------+ / . +-----------+
| Client N +-/ .--| n+1 Server|
+----------+ +-----------+
Server 1
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1::/64
Preference = 255
Server 2
========
Prefix = 2001:db8:1:5::/64
Pool = 2001:db8:1:5::/64
Preference = 0
Server 3
========
Prefix = 2001:db8:1:f::/64
Pool = 2001:db8:1:f::/64
Preference = [1..254]
Figure 2: Multiple unique prefix approach
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Identical Prefixes</span>
In the identical prefix model, each DHCPv6 server is configured with
the same overlapping prefix and pool deployed for use within an IPv6
network. Distribution between two or more servers, for example,
would require that the same /64 prefix and pool be configured on all
DHCP servers. For instance, the 2001:db8:1:1::/64 pool would be
assigned to all the DHCPv6 servers for allocation to clients derived
from the 2001:db8:1:1::/64 prefix. This would be repeated for each
active DHCP server. An example of such a scenario is presented in
Figure 3.
<span class="grey">Brzozowski, et al. Best Current Practice [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6853">RFC 6853</a> DHCPv6 Redundancy Considerations February 2013</span>
This approach uses the same prefix, length, and pool definition
across multiple DHCPv6 servers. All other configuration parameters
remain the same, with the exception of the DHCPv6 preference. Such
an approach conceivably eases the migration of DHCPv6 services to
fully support a standards-based redundancy or failover protocol once
such solution becomes available. Similar to the split prefix
architecture described above, this approach does not place any
additional addressing requirements on the network infrastructure.
The use of identical prefixes provides no benefit or advantage
related to dynamic DNS updates, support of DHCPv6 Leasequery
[<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>] or DHCPv6 Bulk Leasequery [<a href="./rfc5460" title=""DHCPv6 Bulk Leasequery"">RFC5460</a>]. In this case, all
DHCP servers will use the same prefix and pool configurations making
it less obvious that a failure condition or event has occurred.
<span class="grey">Brzozowski, et al. Best Current Practice [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6853">RFC 6853</a> DHCPv6 Redundancy Considerations February 2013</span>
+----------+ +-----------+
| Client 1 +-\ +--+ Server 1 |
+----------+ \ | +-----------+
\ |
\ |
\ |
+----------+ \ | +-----------+
| Client 2 +--------------+--| Server 2 |
+----------+ / | +-----------+
. / .
. / .
. / .
+----------+ / . +-----------+
| Client N +-/ .--| n+1 Server|
+----------+ +-----------+
Server 1
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1::/64
Preference = 255
Server 2
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1::/64
Preference = 0
Server 3
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1::/64
Preference = [1..254]
Figure 3: Identical prefix approach
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Challenges and Issues</span>
The lack of interaction between DHCPv6 servers introduces a number of
challenges related to the operations of the same service instances in
a production environment. The following areas are of particular
concern:
o In the identical prefixes scenario, both servers must follow the
same address allocation procedure, i.e., they both must use the
same algorithm and the same policy to determine which address is
going to be assigned to a specific client. Otherwise, there is a
distinct chance that each server will assign the same address to
<span class="grey">Brzozowski, et al. Best Current Practice [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6853">RFC 6853</a> DHCPv6 Redundancy Considerations February 2013</span>
two different clients. It is expected that both servers will
receive each incoming REQUEST message. Usually, no special action
is required to achieve this as REQUEST messages are sent to a
multicast address by clients. Relays are expected to forward
incoming client messages to all servers. The client indicates the
chosen server by including its DHCP Unique Identifier (DUID) in
the Server-ID option. The chosen server assigns the address and
other configuration options, while the other server discards the
incoming request. In case of a failure of one server, the other
server will assign the same address by following the same
algorithm and the same policy.
o Interactions with DNS server(s) using dynamic update for the same
address when one or more DHCPv6 servers have become unavailable.
This specifically becomes a challenge when (or if) nodes that were
initially granted a lease:
1. Attempt to renew or rebind the lease originally granted, or
2. Attempt to obtain a new lease
The DHCID resource record [<a href="./rfc4701" title=""A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)"">RFC4701</a>] allows identification of the
current owner of the specific DNS data that is the target of an
update [<a href="./rfc2136" title=""Dynamic Updates in the Domain Name System (DNS UPDATE)"">RFC2136</a>]. [<a href="./rfc4704" title=""The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option"">RFC4704</a>] specifies how DHCPv6 servers and/or
clients may perform updates. [<a href="./rfc4703" title=""Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients"">RFC4703</a>] provides a way to solve
conflicts between clients. Although [<a href="./rfc4703" title=""Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients"">RFC4703</a>] deals with most
cases, it is still possible to leave abandoned resource records.
Consider the following scenario: there are two independent
servers, A and B. Server A assigns a lease to a client and
updates the DNS with an AAAA record for the assigned address.
When the client renews, server A is not available and server B
assigns a different lease. The DNS is again updated, so now two
AAAA resource records are present for the client: there is no
indication as to which of the two leases is active. If server A
never recovers, its information may never be removed (although it
should be noted that this case is somewhat similar to that of a
single server crashing and leaving abandoned resource records).
o Interactions with DHCPv6 servers to facilitate the acquisition of
IPv6 lease data by way of the DHCPv6 Leasequery [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>] or
DHCPv6 Bulk Leasequery [<a href="./rfc5460" title=""DHCPv6 Bulk Leasequery"">RFC5460</a>] protocols when one or more DHCPv6
servers have granted leases to DHCPv6 clients and later became
unavailable. If the lease data is required and the granting
server is unavailable, it will not be possible to obtain any
information about leases granted until one of the following has
taken place:
<span class="grey">Brzozowski, et al. Best Current Practice [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6853">RFC 6853</a> DHCPv6 Redundancy Considerations February 2013</span>
1. The granting DHCPv6 server becomes available with all lease
information restored.
2. The client has renewed or rebound its lease against a
different DHCPv6 server.
It is important to note that any exchange of available leases and
synchronization between DHCPv6 servers is not possible until a
redundancy or failover protocol is standardized or proprietary
solutions become available.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
Additional security considerations are created through the use of
this interim architecture beyond what has been cited in <a href="./rfc3315#section-23">Section 23 of
[RFC3315]</a>. In particular, the dynamic DNS update using the models
defined in this document allows for the possibility of not removing
abandoned DNS records even when using the conflict resolution
mechanism defined in [<a href="./rfc4703" title=""Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients"">RFC4703</a>]. However, this is no worse than a
case where a single deployed server crashes and its lease database
cannot be recovered.
When using the identical prefixes model, care must be taken to ensure
that all servers use the same lease allocation procedure and are
configured with the same policy. If this guidance is not followed,
there is a risk of assignment of the same lease to two separate
clients. In some cases, that situation can be recovered by using
Duplicate Address Detection (Neighbor Discovery) and the DECLINE
mechanism (DHCPv6).
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgements</span>
The authors would like to thank Bernie Volz, Kim Kinnear, Ralph
Droms, David Hankins, Chuck Anderson, Ted Lemon, Stephen Farrel, Pete
McCann, Robert Sparks, Martin Stiemerling, Brian Haberman, and Barry
Leiba for their input and review.
Special thanks to Stephen Morris for his numerous spelling, grammar
corrections, and proofreading.
This work has been partially supported by Department of Computer
Communications (a division of Gdansk University of Technology) and
the National Centre for Research and Development (Poland) under the
European Regional Development Fund, Grant No. POIG.01.01.02-00-045/
09-00 (Future Internet Engineering Project).
<span class="grey">Brzozowski, et al. Best Current Practice [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6853">RFC 6853</a> DHCPv6 Redundancy Considerations February 2013</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-RFC2136">RFC2136</a>] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
<a href="./rfc2136">RFC 2136</a>, April 1997.
[<a id="ref-RFC3315">RFC3315</a>] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", <a href="./rfc3315">RFC 3315</a>, July 2003.
[<a id="ref-RFC3633">RFC3633</a>] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", <a href="./rfc3633">RFC 3633</a>,
December 2003.
[<a id="ref-RFC3736">RFC3736</a>] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", <a href="./rfc3736">RFC 3736</a>, April 2004.
[<a id="ref-RFC4701">RFC4701</a>] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource
Record (RR) for Encoding Dynamic Host Configuration
Protocol (DHCP) Information (DHCID RR)", <a href="./rfc4701">RFC 4701</a>,
October 2006.
[<a id="ref-RFC4703">RFC4703</a>] Stapp, M. and B. Volz, "Resolution of Fully Qualified
Domain Name (FQDN) Conflicts among Dynamic Host
Configuration Protocol (DHCP) Clients", <a href="./rfc4703">RFC 4703</a>,
October 2006.
[<a id="ref-RFC4704">RFC4704</a>] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", <a href="./rfc4704">RFC 4704</a>, October 2006.
[<a id="ref-RFC5007">RFC5007</a>] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", <a href="./rfc5007">RFC 5007</a>, September 2007.
[<a id="ref-RFC5460">RFC5460</a>] Stapp, M., "DHCPv6 Bulk Leasequery", <a href="./rfc5460">RFC 5460</a>,
February 2009.
[<a id="ref-RFC5970">RFC5970</a>] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
Options for Network Boot", <a href="./rfc5970">RFC 5970</a>, September 2010.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-FAILREQ">FAILREQ</a>] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover
Requirements", Work in Progress, September 2012.
<span class="grey">Brzozowski, et al. Best Current Practice [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6853">RFC 6853</a> DHCPv6 Redundancy Considerations February 2013</span>
Authors' Addresses
John Jason Brzozowski
Comcast Cable Communications
1306 Goshen Parkway
West Chester, PA 19380
USA
Phone: +1-609-377-6594
EMail: john_brzozowski@cable.comcast.com
Jean-Francois Tremblay
Videotron G.P.
612 Saint-Jacques
Montreal, Quebec H3C 4M8
Canada
EMail: jf@jftremblay.com
Jack Chen
Time Warner Cable
13820 Sunrise Valley Drive
Herndon, VA 20171
USA
EMail: jack.chen@twcable.com
Tomasz Mrugalski
Internet Systems Consortium, Inc.
950 Charter St.
Redwood City, CA 94063
USA
Phone: +1 650 423 1345
EMail: tomasz.mrugalski@gmail.com
Brzozowski, et al. Best Current Practice [Page 16]
</pre>
|
