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
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
|
<pre>Network Working Group M. Stapp
Request for Comments: 5460 Cisco Systems, Inc.
Category: Standards Track February 2009
<span class="h1">DHCPv6 Bulk Leasequery</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been
extended with a Leasequery capability that allows a client to request
information about DHCPv6 bindings. That mechanism is limited to
queries for individual bindings. In some situations individual
binding queries may not be efficient, or even possible. This
document expands on the Leasequery protocol, adding new query types
and allowing for bulk transfer of DHCPv6 binding data via TCP.
<span class="grey">Stapp Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Interaction between UDP Leasequery and Bulk Leasequery . . . . <a href="#page-5">5</a>
<a href="#section-5">5</a>. Message and Option Definitions . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. Message Framing for TCP . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.2">5.2</a>. Messages . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.2.1">5.2.1</a>. LEASEQUERY-DATA . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.2.2">5.2.2</a>. LEASEQUERY-DONE . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.3">5.3</a>. Query Types . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.3.1">5.3.1</a>. QUERY_BY_RELAY_ID . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.3.2">5.3.2</a>. QUERY_BY_LINK_ADDRESS . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.3.3">5.3.3</a>. QUERY_BY_REMOTE_ID . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.4">5.4</a>. Options . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.4.1">5.4.1</a>. Relay-ID Option . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.5">5.5</a>. Status Codes . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.6">5.6</a>. Connection and Transmission Parameters . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6">6</a>. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6.1">6.1</a>. Connecting . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6.2">6.2</a>. Forming Queries . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6.3">6.3</a>. Processing Replies . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6.3.1">6.3.1</a>. Reply Completion . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-6.4">6.4</a>. Querying Multiple Servers . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-6.5">6.5</a>. Multiple Queries to a Single Server . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6.5.1">6.5.1</a>. Example . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6.6">6.6</a>. Closing Connections . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7">7</a>. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7.1">7.1</a>. Accepting Connections . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7.2">7.2</a>. Forming Replies . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7.3">7.3</a>. Multiple or Parallel Queries . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-7.4">7.4</a>. Closing Connections . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-9">9</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-10">10</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-11">11</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-11.1">11.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-11.2">11.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<span class="grey">Stapp Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The DHCPv6 [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>] protocol specifies a mechanism for the
assignment of IPv6 address and configuration information to IPv6
nodes. IPv6 Prefix Delegation (PD) for DHCPv6 [<a href="./rfc3633" title=""IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6"">RFC3633</a>] specifies a
mechanism for DHCPv6 delegation of IPv6 prefixes and related data.
DHCPv6 servers maintain authoritative information including binding
information for delegated IPv6 prefixes.
The client of a PD binding is typically a router, which then
advertises the delegated prefix to locally-connected hosts. The
delegated IPv6 prefix must be routeable in order to be useful. The
actual DHCPv6 PD client may not be permitted to inject routes into
the delegating network. In service-provider (SP) networks, for
example, an edge router typically acts as a DHCPv6 relay agent, and
this edge router often has the responsibility to maintain routes
within the service-provider network for clients' PD bindings.
A DHCPv6 relay with this responsibility requires a means to recover
binding information from the authoritative DHCPv6 server(s) in the
event of replacement or reboot, in order to restore routeability to
delegated prefixes. The relay may be a network device without
adequate local storage to maintain the necessary binding-to-route
data. A DHCPv6 Leasequery protocol [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>] has been developed that
allows queries for individual bindings from the authoritative DHCPv6
server(s). The individual query mechanism is only useable when the
target binding is known to the requestor, such as upon receipt of
traffic. In the case of DHCPv6 Prefix Delegation, the PD binding
data may need to be known before any traffic arrives from the client
router. The DHCPv6 relay router may not be able to form individual
queries in such cases.
This document extends the DHCPv6 Leasequery protocol to add support
for queries that address these requirements. At the SP edge there
may be many thousands of delegated prefixes per relay, so we specify
the use of TCP [<a href="./rfc4614" title=""A Roadmap for Transmission Control Protocol (TCP) Specification Documents"">RFC4614</a>] for efficiency of data transfer. We specify
a new DHCPv6 option, the Relay Identifier option, to support
efficient recovery of all data associated with a specific relay
agent; we also add a query-type for this purpose. We add query-types
by network segment and by Remote-ID option value, to assist a relay
that needs to recover a subset of its clients' bindings.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="grey">Stapp Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
DHCPv6 terminology is defined in [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>]. DHCPv6 Leasequery
terminology is defined in [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Protocol Overview</span>
The Bulk Leasequery mechanism is modeled on the existing individual
Leasequery protocol in [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>]; most differences arise from the use
of TCP. A Bulk Leasequery client opens a TCP connection to a DHCPv6
server, using the DHCPv6 port 547. Note that this implies that the
Leasequery client has server IP address(es) available via
configuration or some other means, and that it has unicast IP
reachability to the server. No relaying for bulk leasequery is
specified.
After establishing a connection, the client sends a LEASEQUERY
message containing a query-type and data about bindings it is
interested in. The server uses the query-type and the data to
identify any relevant bindings. In order to support some query-
types, servers may have to maintain additional data structures or be
able to locate bindings based on specific option data. The server
replies with a LEASEQUERY-REPLY message, indicating the success or
failure of the query. If the query was successful, the server
includes the first client's binding data in the LEASEQUERY-REPLY
message also. If more than one client's bindings are being returned,
the server then transmits the additional client bindings in a series
of LEASEQUERY-DATA messages. If the server has sent at least one
client's bindings, it sends a LEASEQUERY-DONE message when it has
finished sending its replies. The client may reuse the connection to
send additional queries. Each end of the TCP connection can be
closed after all data has been sent.
This specification includes a new DHCPv6 option, the Relay-ID option.
The option contains a DUID (DHCP Unique Identifier) identifying a
DHCPv6 relay agent. Relay agents can include this option in Relay-
Forward messages they send. Servers can retain the Relay-ID and
associate it with bindings made on behalf of the relay's clients. A
relay can then recover binding information about downstream clients
by using the Relay-ID in a LEASEQUERY message. The Relay-ID option
is defined in <a href="#section-5.4.1">Section 5.4.1</a>.
Bulk Leasequery supports the queries by IPv6 address and by Client
DUID as specified in [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>]. The Bulk Leasequery protocol also
adds several new queries. The new queries introduced here cannot be
used effectively with the UDP Leasequery protocol. Requestors MUST
NOT send these new query-types in [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>] query messages.
<span class="grey">Stapp Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
Query by Relay Identifier - This query asks a server for the
bindings associated with a specific relay; the relay is identified
by a DUID carried in a Relay-ID option.
Query by Link Address - This query asks a server for the bindings on
a particular network segment; the link is specified in the query's
link-address field.
Query by Remote ID - This query asks a server for the bindings
associated with a Relay Agent Remote-ID option [<a href="./rfc4649" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option"">RFC4649</a>] value.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Interaction between UDP Leasequery and Bulk Leasequery</span>
Bulk Leasequery can be seen as an extension of the existing UDP
Leasequery protocol [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>]. This section tries to clarify the
relationship between the two protocols.
The query-types introduced in the UDP Leasequery protocol can be used
in the Bulk Leasequery protocol. One change in behavior is
introduced when Bulk Leasequery is used. [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>], in sections
4.1.2.5 and 4.3.3, specifies the use of a Client Link option in
LEASEQUERY-REPLY messages in cases where multiple bindings were
found. When Bulk Leasequery is used, this mechanism is not
necessary: a server returning multiple bindings simply does so
directly as specified in this document. The Client Link option MUST
NOT appear in Bulk Leasequery replies.
Only LEASEQUERY, LEASEQUERY-REPLY, LEASEQUERY-DATA, and LEASEQUERY-
DONE messages are allowed over the Bulk Leasequery connection. No
other DHCPv6 messages are supported. The Bulk Leasequery connection
is not an alternative DHCPv6 communication option for clients seeking
DHCPv6 service.
The new queries introduced in this specification cannot be used with
the UDP Leasequery protocol. Servers that implement this
specification and also permit UDP queries MUST NOT accept Bulk
Leasequery query-types in UDP Leasequery messages. Such servers MUST
respond with an error status code of NotAllowed [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>].
Implementors should note that the TCP message framing defined in
<a href="#section-5.1">Section 5.1</a> is not compatible with the UDP message format. If a TCP-
framed request is sent as a UDP message, it may not be valid, because
protocol fields will be offset by the message-size prefix.
<span class="grey">Stapp Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Message and Option Definitions</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Message Framing for TCP</span>
The use of TCP for the Bulk Leasequery protocol permits one or more
DHCPv6 messages to be sent at a time. The receiver needs to be able
to determine how large each message is. Two octets containing the
message size in network byte order are prepended to each DHCPv6
message sent on a Bulk Leasequery TCP connection. The two message-
size octets 'frame' each DHCPv6 message.
DHCPv6 message framed for TCP:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message-size | msg-type | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: transaction-id | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| .
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
message-size the number of octets in the message that
follows, as a 16-bit integer in network
byte order.
All other fields are as specified in DHCPv6 [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>].
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Messages</span>
The LEASEQUERY and LEASEQUERY-REPLY messages are defined in
[<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>]. In a Bulk Leasequery exchange, a single LEASEQUERY-REPLY
message is used to indicate the success or failure of a query, and to
carry data that do not change in the context of a single query and
answer, such as the Server-ID and Client-ID options. If a query is
successful, only a single LEASEQUERY-REPLY message MUST appear. If
the server is returning binding data, the LEASEQUERY-REPLY also
contains the first client's binding data in an OPTION_CLIENT_DATA
option.
<span class="grey">Stapp Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. LEASEQUERY-DATA</span>
The LEASEQUERY-DATA message carries data about a single DHCPv6
client's leases and/or PD bindings on a single link. The purpose of
the message is to reduce redundant data when there are multiple
bindings to be sent. The LEASEQUERY-DATA message MUST be preceded by
a LEASEQUERY-REPLY message. The LEASEQUERY-REPLY carries the query's
status, the Leasequery's Client-ID and Server-ID options, and the
first client's binding data if the query was successful.
LEASEQUERY-DATA MUST ONLY be sent in response to a successful
LEASEQUERY, and only if more than one client's data is to be sent.
The LEASEQUERY-DATA message's transaction-id field MUST match the
transaction-id of the LEASEQUERY request message. The Server-ID,
Client-ID, and OPTION_STATUS_CODE options SHOULD NOT be included:
that data should be constant for any one Bulk Leasequery reply, and
should have been conveyed in the LEASEQUERY-REPLY message.
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>. LEASEQUERY-DONE</span>
The LEASEQUERY-DONE message indicates the end of a group of related
Leasequery replies. The LEASEQUERY-DONE message's transaction-id
field MUST match the transaction-id of the LEASEQUERY request
message. The presence of the message itself signals the end of a
stream of reply messages. A single LEASEQUERY-DONE MUST BE sent
after all replies (a successful LEASEQUERY-REPLY and zero or more
LEASEQUERY-DATA messages) to a successful Bulk Leasequery request
that returned at least one binding.
A server may encounter an error condition after it has sent the
initial LEASEQUERY-REPLY. In that case, it SHOULD attempt to send a
LEASEQUERY-DONE with an OPTION_STATUS_CODE option indicating the
error condition to the requestor. Other DHCPv6 options SHOULD NOT be
included in the LEASEQUERY-DONE message.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Query Types</span>
The OPTION_LQ_QUERY option is defined in [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>]. We introduce the
following new query-types: QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS,
and QUERY_BY_REMOTE_ID. These queries are designed to assist relay
agents in recovering binding data in circumstances where some or all
of the relay's binding data has been lost.
<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>. QUERY_BY_RELAY_ID</span>
This query asks the server to return bindings associated with the
specified relay DUID.
<span class="grey">Stapp Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
QUERY_BY_RELAY_ID - The query-options MUST contain an
OPTION_RELAY_ID option. If the link-address field is 0::0, the
query asks for all bindings associated with the specified relay
DUID. If the link-address is specified, the query asks for
bindings on that link.
<span class="h4"><a class="selflink" id="section-5.3.2" href="#section-5.3.2">5.3.2</a>. QUERY_BY_LINK_ADDRESS</span>
The QUERY_BY_LINK_ADDRESS asks the server to return bindings on a
network segment identified by a link-address value from a relay's
Relay-Forward message.
QUERY_BY_LINK_ADDRESS - The query's link-address contains an
address a relay may have used in the link-address of a Relay-
Forward message. The Server attempts to locate bindings on the
same network segment as the link-address.
<span class="h4"><a class="selflink" id="section-5.3.3" href="#section-5.3.3">5.3.3</a>. QUERY_BY_REMOTE_ID</span>
The QUERY_BY_REMOTE_ID asks the server to return bindings associated
with a Remote-ID option value from a relay's Relay-Forward message.
The query-options MUST include a Relay Agent Remote-ID option
[<a href="./rfc4649" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option"">RFC4649</a>].
In order to support this query, a server needs to record the most-
recent Remote-ID option value seen in a Relay-Forward message along
with its other binding data.
QUERY_BY_REMOTE_ID - The query-options MUST include a Relay Agent
Remote-ID option [<a href="./rfc4649" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option"">RFC4649</a>]. If the Server has recorded Remote-ID
values with its bindings, it uses the option's value to identify
bindings to return.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Options</span>
<span class="h4"><a class="selflink" id="section-5.4.1" href="#section-5.4.1">5.4.1</a>. Relay-ID Option</span>
The Relay-ID option carries a DUID [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>]. A relay agent MAY
include the option in Relay-Forward messages it sends. Obviously, it
will not be possible for a server to respond to QUERY_BY_RELAY_ID
queries unless the relay agent has included this option. A relay
SHOULD be able to generate a DUID for this purpose, and capture the
result in stable storage. A relay SHOULD also allow the DUID value
to be configurable: doing so allows an administrator to replace a
relay agent while retaining the association between the relay and
existing DHCPv6 bindings.
<span class="grey">Stapp Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
A DHCPv6 server MAY associate Relay-ID options from Relay-Forward
messages it processes with prefix delegations and/or lease bindings
that result. Doing so allows it to respond to QUERY_BY_RELAY_ID
Leasequeries.
The format of the Relay-ID option is shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RELAY_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RELAY_ID.
option-len Length of DUID in octets.
DUID The DUID for the relay agent.
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. Status Codes</span>
QueryTerminated - Indicates that the server is unable to perform a
query or has prematurely terminated the query for some reason (which
should be communicated in the text of the message). This may be
because the server is short of resources or is being shut down. The
requestor may retry the query at a later time. The requestor should
wait at least a short interval before retrying. Note that while a
server may simply prematurely close its end of the connection, it is
preferable for the server to send a LEASEQUERY-REPLY or LEASEQUERY-
DONE with this status-code to notify the requestor of the condition.
<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>. Connection and Transmission Parameters</span>
DHCPv6 servers that support Bulk Leasequery SHOULD listen for
incoming TCP connections on the DHCPv6 server port 547.
Implementations MAY offer to make the incoming port configurable, but
port 547 MUST be the default. Client implementations SHOULD make TCP
connections to port 547, and MAY offer to make the destination server
port configurable.
This section presents a table of values used to control Bulk
Leasequery behavior, including recommended defaults. Implementations
MAY make these values configurable. However, configuring too-small
<span class="grey">Stapp Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
timeout values may lead to harmful behavior both to this application
as well as to other traffic in the network. As a result, timeout
values smaller than the default values are NOT RECOMMENDED.
Parameter Default Description
-------------------------------------------
BULK_LQ_DATA_TIMEOUT 300 s Bulk Leasequery data timeout
BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Requestor Behavior</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Connecting</span>
A requestor attempts to establish a TCP connection to a DHCPv6 server
in order to initiate a Leasequery exchange. If the attempt fails,
the requestor MAY retry.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Forming Queries</span>
After a connection is established, the requestor constructs a
Leasequery message, as specified in [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>]. The query may have
any of the defined query-types, and includes the options and data
required by the query-type chosen. The requestor sends the message
size then sends the actual DHCPv6 message, as described in
<a href="#section-5.1">Section 5.1</a>.
If the TCP connection becomes blocked or stops being writeable while
the requestor is sending its query, the requestor SHOULD be prepared
to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this
recommendation to allow requestors to control the period of time they
are willing to wait before abandoning a connection, independent of
notifications from the TCP implementations they may be using.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Processing Replies</span>
The requestor attempts to read a LEASEQUERY-REPLY message from the
TCP connection. If the TCP connection stops delivering reply data
(if the connection stops being readable), the requestor SHOULD be
prepared to terminate the connection after BULK_LQ_DATA_TIMEOUT, and
MAY begin retry-processing if configured to do so.
The requestor examines the LEASEQUERY-REPLY message, and determines
how to proceed. Message validation rules are specified in DHCPv6
Leasequery [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>]. If the reply contains an error status code
(carried in an OPTION_STATUS_CODE option), the requestor follows the
recommendations in [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>]. A successful reply that does not
include an OPTION_CLIENT_DATA option indicates that the target server
had no bindings matching the query.
<span class="grey">Stapp Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
Note: The Leasequery protocol uses the OPTION_CLIENT_LINK option as
an indicator that multiple bindings were present in response to a
single query. For Bulk Leasequery, the OPTION_CLIENT_LINK option is
not used, and MUST NOT be present in replies.
A successful LEASEQUERY-REPLY that is returning binding data includes
an OPTION_CLIENT_DATA option and possibly additional options. If
there are additional bindings to be returned, they will be carried in
LEASEQUERY-DATA messages. Each LEASEQUERY-DATA message contains an
OPTION_CLIENT_DATA option, and possibly other options. A LEASEQUERY-
DATA message that does not contain an OPTION_CLIENT_DATA MUST be
discarded.
A single bulk query can result in a large number of replies. For
example, a single relay agent might be responsible for routes for
thousands of clients' delegated prefixes. The requestor MUST be
prepared to receive more than one LEASEQUERY-DATA with transaction-
ids matching a single LEASEQUERY message.
The LEASEQUERY-DONE message ends a successful Bulk Leasequery request
that returned at least one binding. A LEASEQUERY-REPLY without any
bindings MUST NOT be followed by a LEASEQUERY-DONE message for the
same transaction-id. After receiving LEASEQUERY-DONE from a server,
the requestor MAY close the TCP connection to that server. If the
transaction-id in the LEASEQUERY-DONE does not match an outstanding
LEASEQUERY message, the client MUST close the TCP connection.
<span class="h4"><a class="selflink" id="section-6.3.1" href="#section-6.3.1">6.3.1</a>. Reply Completion</span>
The reply to a Bulk Leasequery request is complete (i.e., no further
messages for that request transaction-id will be received) when one
of these conditions is met:
1. if the LEASEQUERY-REPLY message had no OPTION_CLIENT_DATA option,
when the LEASEQUERY-REPLY is received,
2. else if the LEASEQUERY-REPLY did have an OPTION_CLIENT_DATA, when
the corresponding LEASEQUERY-DONE message is received,
3. else when the connection is closed.
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. Querying Multiple Servers</span>
A Bulk Leasequery client MAY be configured to attempt to connect to
and query from multiple DHCPv6 servers in parallel. The DHCPv6
Leasequery specification [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>] includes a discussion about
reconciling binding data received from multiple DHCPv6 servers.
<span class="grey">Stapp Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>. Multiple Queries to a Single Server</span>
Bulk Leasequery clients may need to make multiple queries in order to
recover binding information. A requestor MAY use a single connection
to issue multiple queries. Each query MUST have a unique
transaction-id. A server MAY process more than one query at a time.
A server that is willing to do so MAY interleave replies to the
multiple queries within the stream of reply messages it sends.
Clients need to be aware that replies for multiple queries may be
interleaved within the stream of reply messages. Clients that are
not able to process interleaved replies (based on transaction-id)
MUST NOT send more than one query at a time. Requestors should be
aware that servers are not required to process queries in parallel,
and that servers are likely to limit the rate at which they process
queries from any one requestor.
<span class="h4"><a class="selflink" id="section-6.5.1" href="#section-6.5.1">6.5.1</a>. Example</span>
This example illustrates what a series of queries and responses might
look like. This is only an example -- there is no requirement that
this sequence must be followed, or that clients or servers must
support parallel queries.
In the example session, the client sends four queries after
establishing a connection; "xid" denotes a transaction-id in the
diagram. Query 1 results in a failure; query 2 succeeds and the
stream of replies concludes before the client issues any new query.
Query 3 and query 4 overlap, and the server interleaves its replies
to those two queries.
<span class="grey">Stapp Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
Client Server
------ ------
LEASEQUERY xid 1 ----->
<----- LEASEQUERY-REPLY xid 1 (w/error)
LEASEQUERY xid 2 ----->
<----- LEASEQUERY-REPLY xid 2
<----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DONE xid 2
LEASEQUERY xid 3 ----->
LEASEQUERY xid 4 ----->
<----- LEASEQUERY-REPLY xid 4
<----- LEASEQUERY-DATA xid 4
<----- LEASEQUERY-REPLY xid 3
<----- LEASEQUERY-DATA xid 4
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DONE xid 3
<----- LEASEQUERY-DATA xid 4
<----- LEASEQUERY-DONE xid 4
<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>. Closing Connections</span>
The requestor MAY close its end of the TCP connection after sending a
LEASEQUERY message to the server. The requestor MAY choose to retain
the connection if it intends to issue additional queries. Note that
this client behavior does not guarantee that the connection will be
available for additional queries: the server might decide to close
the connection based on its own configuration.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Server Behavior</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Accepting Connections</span>
Servers that implement DHCPv6 Bulk Leasequery listen for incoming TCP
connections. Port numbers are discussed in <a href="#section-5.6">Section 5.6</a>. Servers
MUST be able to limit the number of currently accepted and active
connections. The value BULK_LQ_MAX_CONNS MUST be the default;
implementations MAY permit the value to be configurable.
Servers MAY restrict Bulk Leasequery connections and LEASEQUERY
messages to certain clients. Connections that are not from permitted
clients SHOULD BE closed immediately, to avoid server connection
resource exhaustion. Servers MAY restrict some clients to certain
query types. Servers MAY reply to queries that are not permitted
with the NotAllowed status code [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>], and/or close the
connection.
<span class="grey">Stapp Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
If the TCP connection becomes blocked while the server is accepting a
connection or reading a query, it SHOULD be prepared to terminate the
connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation
to allow Servers to control the period of time they are willing to
wait before abandoning an inactive connection, independent of the TCP
implementations they may be using.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Forming Replies</span>
The DHCPv6 Leasequery [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>] specification describes the initial
construction of LEASEQUERY-REPLY messages and the processing of
QUERY_BY_ADDRESS and QUERY_BY_CLIENTID. Use of the LEASEQUERY-REPLY
and LEASEQUERY-DATA messages to carry multiple bindings is described
in <a href="#section-5.2">Section 5.2</a>. Message transmission and framing for TCP is
described in <a href="#section-5.1">Section 5.1</a>. If the connection becomes blocked while
the server is attempting to send reply messages, the server SHOULD be
prepared to terminate the TCP connection after BULK_LQ_DATA_TIMEOUT.
If the server encounters an error during initial query processing,
before any reply has been sent, it SHOULD send a LEASEQUERY-REPLY
containing an error code in an OPTION_STATUS_CODE option. This
signals to the requestor that no data will be returned. If the
server encounters an error while processing a query that has already
resulted in one or more reply messages, the server SHOULD send a
LEASEQUERY-DONE message with an error status. The server SHOULD
close its end of the connection as an indication that it was not able
to complete query processing.
If the server does not find any bindings satisfying a query, it
SHOULD send a LEASEQUERY-REPLY without an OPTION_STATUS_CODE option
and without any OPTION_CLIENT_DATA option. Otherwise, the server
sends each binding's data in a reply message. The first reply
message is a LEASEQUERY-REPLY. The binding data is carried in an
OPTION_CLIENT_DATA option, as specified in [<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>] and extended
below. The server returns subsequent bindings in LEASEQUERY-DATA
messages, which can avoid redundant data (such as the requestor's
Client-ID).
For QUERY_BY_RELAY_ID, the server locates each binding associated
with the query's Relay-ID option value. In order to give a
meaningful reply to a QUERY_BY_RELAY_ID, the server has to be able to
maintain this association in its DHCPv6 binding data. If the query's
link-address is not set to 0::0, the server only returns bindings on
links that could contain that address. If the link-address is not
0::0 and the server cannot find any matching links, the server SHOULD
return the NotConfigured status in a LEASEQUERY-REPLY.
<span class="grey">Stapp Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
For QUERY_BY_LINK_ADDRESS, the server locates each binding associated
with the link identified by the query's link-address value.
For QUERY_BY_REMOTE_ID, the server locates each binding associated
with the query's Relay Remote-ID option value. In order to be able
to give meaningful replies to this query, the server has to be able
to maintain this association in its binding database. If the query
message's link-address is not set to 0::0, the server only returns
bindings on links that could contain that address. If the link-
address is not 0::0 and the server cannot find any matching links,
the server SHOULD return the NotConfigured status in a LEASEQUERY-
REPLY.
The server sends the LEASEQUERY-DONE message as specified in
<a href="#section-5.2">Section 5.2</a>.
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Multiple or Parallel Queries</span>
As discussed in <a href="#section-6.5">Section 6.5</a>, requestors may want to leverage an
existing connection if they need to make multiple queries. Servers
MAY support reading and processing multiple queries from a single
connection. A server MUST NOT read more query messages from a
connection than it is prepared to process simultaneously.
This MAY be a feature that is administratively controlled. Servers
that are able to process queries in parallel SHOULD offer
configuration that limits the number of simultaneous queries
permitted from any one requestor, in order to control resource use if
there are multiple requestors seeking service.
<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>. Closing Connections</span>
The server MAY close its end of the TCP connection after sending its
last message (a LEASEQUERY-REPLY or a LEASEQUERY-DONE) in response to
a query. Alternatively, the server MAY retain the connection and
wait for additional queries from the client. The server SHOULD be
prepared to limit the number of connections it maintains, and SHOULD
be prepared to close idle connections to enforce the limit.
The server MUST close its end of the TCP connection if it encounters
an error sending data on the connection. The server MUST close its
end of the TCP connection if it finds that it has to abort an in-
process request. A server aborting an in-process request MAY attempt
to notify its clients by using the QueryTerminated (<a href="#section-5.5">Section 5.5</a>)
status code. If the server detects that the client end has been
closed, the server MUST close its end of the connection after it has
finished processing any outstanding requests from the client.
<span class="grey">Stapp Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
The "Security Considerations" section of [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>] details the
general threats to DHCPv6. The DHCPv6 Leasequery specification
[<a href="./rfc5007" title=""DHCPv6 Leasequery"">RFC5007</a>] describes recommendations for the Leasequery protocol,
especially with regard to relayed LEASEQUERY messages, mitigation of
packet-flooding denial-of-service (DoS) attacks, restriction to
trusted clients, and use of IPsec [<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>].
The use of TCP introduces some additional concerns. Attacks that
attempt to exhaust the DHCPv6 server's available TCP connection
resources, such as SYN flooding attacks, can compromise the ability
of legitimate clients to receive service. Malicious clients who
succeed in establishing connections, but who then send invalid
queries, partial queries, or no queries at all also can exhaust a
server's pool of available connections. We recommend that servers
offer configuration to limit the sources of incoming connections,
that they limit the number of accepted connections and the number of
in-process queries from any one connection, and that they limit the
period of time during which an idle connection will be left open.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
IANA has assigned a new value in the registry of DHCPv6 Option Codes:
53 OPTION_RELAY_ID
IANA has assigned a new value in the registry of DHCPv6 Status Codes:
11 QueryTerminated
IANA has assigned the following values in the registry of DHCPv6
Message types:
16 LEASEQUERY-DONE
17 LEASEQUERY-DATA
IANA has assigned the following values in the registry of query-types
for the DHCPv6 OPTION_LQ_QUERY option:
3 QUERY_BY_RELAY_ID
4 QUERY_BY_LINK_ADDRESS
5 QUERY_BY_REMOTE_ID
The above-mentioned registries are available from
<a href="http://www.iana.org">http://www.iana.org</a>.
<span class="grey">Stapp Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgments</span>
Many of the ideas in this document were originally proposed by Kim
Kinnear, Richard Johnson, Hemant Singh, Ole Troan, and Bernie Volz.
Further suggestions and improvements were made by participants in the
DHC working group, including John Brzozowski, Marcus Goller, Alfred
Hoenes, Ted Lemon, Bud Millwood, and Thomas Narten.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 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-RFC4649">RFC4649</a>] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Remote-ID Option", <a href="./rfc4649">RFC 4649</a>,
August 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.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-RFC4301">RFC4301</a>] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", <a href="./rfc4301">RFC 4301</a>, December 2005.
[<a id="ref-RFC4614">RFC4614</a>] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
for Transmission Control Protocol (TCP) Specification
Documents", <a href="./rfc4614">RFC 4614</a>, September 2006.
<span class="grey">Stapp Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5460">RFC 5460</a> DHCPv6 Bulk Leasequery February 2009</span>
Author's Address
Mark Stapp
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone: +1 978 936 0000
EMail: mjs@cisco.com
Stapp Standards Track [Page 18]
</pre>
|
