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
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
|
<pre>Network Working Group J. Brzozowski
Request for Comments: 5007 Comcast Cable
Category: Standards Track K. Kinnear
B. Volz
S. Zeng
Cisco Systems, Inc.
September 2007
<span class="h1">DHCPv6 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.
Abstract
This document specifies a leasequery exchange for the Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) that can be used to obtain
lease information about DHCPv6 clients from a DHCPv6 server. This
document specifies the scope of data that can be retrieved as well as
both DHCPv6 leasequery requestor and server behavior. This document
extends DHCPv6.
<span class="grey">Brzozowski, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</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-3.1">3.1</a>. On-Demand Query . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. Anticipatory Query . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.3">3.3</a>. Query Types . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. Message and Option Definitions . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.1.1">4.1.1</a>. Messages . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.1.2">4.1.2</a>. Options . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.1.3">4.1.3</a>. Status Codes . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.1.4">4.1.4</a>. Transmission and Retransmission Parameters . . . . . . <a href="#page-12">12</a>
<a href="#section-4.2">4.2</a>. Message Validation . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.2.1">4.2.1</a>. LEASEQUERY . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.2.2">4.2.2</a>. LEASEQUERY-REPLY . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4.3">4.3</a>. DHCPv6 Leasequery Requestor Behavior . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4.3.1">4.3.1</a>. Creation of LEASEQUERY . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4.3.2">4.3.2</a>. Transmission of LEASEQUERY . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4.3.3">4.3.3</a>. Receipt of LEASEQUERY-REPLY . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-4.3.4">4.3.4</a>. Handling DHCPv6 Client Data from Multiple Sources . . <a href="#page-15">15</a>
<a href="#section-4.4">4.4</a>. DHCPv6 Leasequery Server Behavior . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-4.4.1">4.4.1</a>. Receipt of LEASEQUERY Messages . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-4.4.2">4.4.2</a>. Constructing the Client's OPTION_CLIENT_DATA . . . . . <a href="#page-17">17</a>
<a href="#section-4.4.3">4.4.3</a>. Transmission of LEASEQUERY-REPLY Messages . . . . . . <a href="#page-17">17</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-6">6</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-7">7</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<span class="grey">Brzozowski, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The DHCPv6 [<a href="#ref-2" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">2</a>] protocol specifies a mechanism for the assignment of
both IPv6 address and configuration information to IPv6 nodes. IPv6
Prefix Options for DHCPv6 [<a href="#ref-4" title=""IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6"">4</a>] specifies a mechanism for the automated
delegation of IPv6 prefixes and related options. Similar to DHCPv4
[<a href="#ref-5" title=""Dynamic Host Configuration Protocol"">5</a>], DHCPv6 servers maintain authoritative information related to
their operations including, but not limited to, lease information for
IPv6 addresses and delegated prefixes.
The requirement exists in various types of IPv6 deployments,
particularly those of a broadband variety, to leverage DHCPv6 [<a href="#ref-2" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">2</a>] for
retrieving data related to the operation of DHCPv6 servers
programmatically. In particular, it is desirable to be able to
extract lease information about IPv6 addresses and delegated prefixes
assigned using DHCPv6 [<a href="#ref-2" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">2</a>] [<a href="#ref-4" title=""IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6"">4</a>]. Specific examples where this
information has illustrated value are in broadband networks to
facilitate access control by edge devices. This capability to
programmatically extract lease data from the DHCPv6 server is called
leasequery.
The leasequery capability described in this document parallels the
DHCPv4 leasequery capability documented in [<a href="#ref-3" title=""Dynamic Host Configuration Protocol (DHCP) Leasequery"">3</a>]. As such, it shares
the basic motivations, background, design goals and constraints as
described in [<a href="#ref-3" title=""Dynamic Host Configuration Protocol (DHCP) Leasequery"">3</a>]. Differences are due to the differences between
IPv4 and IPv6 and by extension, DHCPv4 and DHCPv6. For example,
Neighbor Discovery [<a href="#ref-7" title=""Neighbor Discovery for IP Version 6 (IPv6)"">7</a>] is used in IPv6 instead of the Address
Resolution Protocol (ARP) [<a href="#ref-8" title=""Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware"">8</a>] (Section 4.1 of [<a href="#ref-3" title=""Dynamic Host Configuration Protocol (DHCP) Leasequery"">3</a>]) and DOCSIS 3.0
[<a href="#ref-11" title=""Data-Over-Cable Service Interface Specifications: DOCSIS 3.0, MAC and Upper Layer Protocols Interface Specification, CM-SP-MULPIv3.0-I04-070518"">11</a>] defines IPv6 support for cable modem environments.
<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="#ref-1" title=""Key words for use in RFCs to Indicate Requirement Levels"">1</a>].
DHCPv6 terminology is defined in [<a href="#ref-2" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">2</a>]. Terminology specific to DHCPv6
leasequery can be found below:
access concentrator
An access concentrator is a router or switch at the
broadband access provider's edge of a public
broadband access network. This document assumes that
the access concentrator includes the DHCPv6 relay
agent functionality.
<span class="grey">Brzozowski, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
client(s) The nodes that have one or more bindings with a
DHCPv6 server. This does not refer to the node
issuing the LEASEQUERY unless it itself has one or
more bindings with a DHCPv6 server.
gleaning Gleaning is the extraction of location information
from DHCPv6 messages, as the messages are forwarded
by the DHCP relay agent function.
location information
Location information is information needed by the
access concentrator to forward traffic to a
broadband-accessible host. This information includes
knowledge of the host hardware address, the port or
virtual circuit that leads to the host, and/or the
hardware address of the intervening subscriber modem.
requestor The node that sends LEASEQUERY messages to one or
more servers to retrieve information on the bindings
for a client.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Protocol Overview</span>
The focus of this document is to extend the DHCPv6 protocol to allow
processes and devices that wish to access information from a DHCPv6
server to do so in a lightweight and convenient manner. It is
especially appropriate for processes and devices that already
interpret DHCPv6 messages.
The LEASEQUERY message is a query message only and does not affect
the state of the IPv6 address or prefix, or the binding information
associated with it.
One important motivating example is that the LEASEQUERY message
allows access concentrators to query DHCP servers to obtain location
information of broadband access network devices. This is described
in Section 1 of [<a href="#ref-3" title=""Dynamic Host Configuration Protocol (DHCP) Leasequery"">3</a>] for IPv4.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. On-Demand Query</span>
The on-demand leasequery capability allows requesting just the
information necessary to satisfy an immediate need. If the requestor
is an access concentrator, then the immediate need will typically be
that it has received an IPv6 packet and it needs to refresh its
information concerning the DHCPv6 client to which that IPv6 address
is currently leased. In this case, the request will be by address.
This fits clearly into the single request/response cycle common to
other DHCPv6 message exchanges.
<span class="grey">Brzozowski, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
However, this approach has limitations when used with prefix
delegation [<a href="#ref-4" title=""IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6"">4</a>] as no traffic may arrive because the access
concentrator is unable to inject the appropriate routing information
into the routing infrastructure, such as after a reboot. This
approach does work if the access concentrator is configured to inject
routing information for a prefix that aggregates potentially
delegated prefixes. Or, it also works if the access concentrator and
requesting router use a routing protocol; as then the requesting
router can trigger the access concentrator to request information
from a DHCPv6 server and inject appropriate routing information into
the routing infrastructure.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Anticipatory Query</span>
A second approach for requesting information from a DHCPv6 server
would be to use a leasequery-like capability to rebuild an internal
data store containing information available from a DHCPv6 server.
The rebuilding of the data store in this approach can take place as
soon as possible after the need to rebuild it is discovered (such as
on booting), and doesn't wait on the receipt of specific packets to
trigger a piecemeal database update (as is the case for on-demand
leasequery). This approach would also remove the limitation
discussed above for prefix delegation.
This anticipatory query is not specified in this document and is an
area of future work.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Query Types</span>
Leasequery provides for the following queries:
Query by IPv6 address - This query allows a requestor to request
from a server the bindings for a client that either is bound to
the address or has been delegated the prefix that contains the
address.
Query by Client Identifier (DUID) - This query allows a requestor to
request from a server the bindings for a specific client on a
specific link or a list of the links on which the client has one
or more bindings.
<span class="grey">Brzozowski, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Protocol Details</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Message and Option Definitions</span>
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Messages</span>
The LEASEQUERY and LEASEQUERY-REPLY messages use the Client/Server
message formats described in [<a href="#ref-2" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">2</a>], Section 6. Two new message codes
are defined:
LEASEQUERY (14) - A requestor sends a LEASEQUERY message to any
available server to obtain information on a client's leases. The
options in an OPTION_LQ_QUERY determine the query.
LEASEQUERY-REPLY (15) - A server sends a LEASEQUERY-REPLY message
containing client data in response to a LEASEQUERY message.
<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>. Options</span>
<span class="h5"><a class="selflink" id="section-4.1.2.1" href="#section-4.1.2.1">4.1.2.1</a>. Query Option</span>
The Query option is used only in a LEASEQUERY message and identifies
the query being performed. The option includes the query type, link-
address (or 0::0), and option(s) to provide data needed for the
query.
The format of the Query 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_LQ_QUERY | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| query-type | |
+-+-+-+-+-+-+-+-+ |
| |
| link-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | .
+-+-+-+-+-+-+-+-+ .
. query-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_QUERY (44)
option-len 17 + length of query-options field.
<span class="grey">Brzozowski, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
link-address A global address that will be used by the
server to identify the link to which the
query applies, or 0::0 if unspecified.
query-type The query requested (see below).
query-options The options related to the query.
The query-type and required query-options are:
QUERY_BY_ADDRESS (1) - The query-options MUST contain an
OPTION_IAADDR option [<a href="#ref-2" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">2</a>]. The link-address field, if not 0::0,
specifies an address for the link on which the client is located
if the address in the OPTION_IAADDR option is of insufficient
scope. Only the information for the client that has a lease for
the specified address or was delegated a prefix that contains the
specified address is returned (if available).
QUERY_BY_CLIENTID (2) - The query-options MUST contain an
OPTION_CLIENTID option [<a href="#ref-2" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">2</a>]. The link-address field, if not 0::0,
specifies an address for the link on which the client is located.
If the link-address field is 0::0, the server SHOULD search all of
its links for the client.
The query-options MAY also include an OPTION_ORO option [<a href="#ref-2" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">2</a>] to
indicate the options for each client that the requestor would like
the server to return. Note that this OPTION_ORO is distinct and
separate from an OPTION_ORO that may be in the requestor's LEASEQUERY
message.
If a server receives an OPTION_LQ_QUERY with a query-type it does not
support, the server SHOULD return an UnknownQueryType status-code.
If a server receives a supported query-type but the query-options is
missing a required option, the server SHOULD return a MalformedQuery
status-code.
<span class="grey">Brzozowski, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
<span class="h5"><a class="selflink" id="section-4.1.2.2" href="#section-4.1.2.2">4.1.2.2</a>. Client Data Option</span>
The Client Data option is used to encapsulate the data for a single
client on a single link in a LEASEQUERY-REPLY message.
The format of the Client Data 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_CLIENT_DATA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. client-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLIENT_DATA (45)
option-len Length, in octets, of the encapsulated client-
options field.
client-options The options associated with this client.
The encapsulated client-options include the OPTION_CLIENTID,
OPTION_IAADDR, OPTION_IAPREFIX, and OPTION_CLT_TIME options and other
options specific to the client and requested by the requestor in the
OPTION_ORO in the OPTION_LQ_QUERY's query-options. The server MUST
return all of the client's statefully assigned addresses and
delegated prefixes, with a non-zero valid lifetime, on the link.
<span class="grey">Brzozowski, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
<span class="h5"><a class="selflink" id="section-4.1.2.3" href="#section-4.1.2.3">4.1.2.3</a>. Client Last Transaction Time Option</span>
The Client Last Transaction Time option is encapsulated in an
OPTION_CLIENT_DATA and identifies how long ago the server last
communicated with the client, in seconds.
The format of the Client Last Transaction Time 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_CLT_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client-last-transaction-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLT_TIME (46)
option-len 4
client-last-transaction-time
The number of seconds since the server last
communicated with the client (on that link).
The client-last-transaction-time is a positive value and reflects the
number of seconds since the server last communicated with the client
(on that link).
<span class="grey">Brzozowski, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
<span class="h5"><a class="selflink" id="section-4.1.2.4" href="#section-4.1.2.4">4.1.2.4</a>. Relay Data</span>
The Relay Data option is used only in a LEASEQUERY-REPLY message and
provides the relay agent information used when the client last
communicated with the server.
The format of the Relay Data 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_LQ_RELAY_DATA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| peer-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DHCP-relay-message |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_RELAY_DATA (47)
option-len 16 + length of DHCP-relay-message.
peer-address The address of the relay agent from which
the relayed message was received by the
server.
DHCP-relay-message
The last complete relayed message, excluding
the client's message OPTION_RELAY_MSG,
received by the server.
This option is used by the server to return full relay agent
information for a client. It MUST NOT be returned if the server does
not have such information, either because the client communicated
directly (without relay agent) with the server or if the server did
not retain such information.
If returned, the DHCP-relay-message MUST contain a valid (perhaps
multi-hop) RELAY-FORW message as the most recently received by the
server for the client. However, the (innermost) OPTION_RELAY_MSG
option containing the client's message MUST have been removed.
<span class="grey">Brzozowski, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
This option SHOULD only be returned if requested by the OPTION_ORO of
the OPTION_LQ_QUERY.
<span class="h5"><a class="selflink" id="section-4.1.2.5" href="#section-4.1.2.5">4.1.2.5</a>. Client Link Option</span>
The Client Link option is used only in a LEASEQUERY-REPLY message and
identifies the links on which the client has one or more bindings.
It is used in reply to a query when no link-address was specified and
the client is found to be on more than one link.
The format of the Client Link 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_LQ_CLIENT_LINK | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| link-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| link-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_CLIENT_LINK (48)
option-len Length of the list of links in octets;
must be a multiple of 16.
link-address A global address used by the server to
identify the link on which the client is
located.
A server may respond to a query by client-id, where the 0::0 link-
address was specified, with this option if the client is found to be
on multiple links. The requestor may then repeat the query once for
each link-address returned in the list, specifying the returned link-
address. If the client is on a single link, the server SHOULD return
the client's data in an OPTION_CLIENT_DATA option.
<span class="grey">Brzozowski, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
<span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>. Status Codes</span>
The following new status codes are defined:
UnknownQueryType (7) - The query-type is unknown to or not supported
by the server.
MalformedQuery (8) - The query is not valid; for example, a required
query-option is missing from the OPTION_LQ_QUERY.
NotConfigured (9) - The server does not have the target address or
link in its configuration.
NotAllowed (10) - The server does not allow the requestor to issue
this LEASEQUERY.
<span class="h4"><a class="selflink" id="section-4.1.4" href="#section-4.1.4">4.1.4</a>. Transmission and Retransmission Parameters</span>
This section presents a table of values used to describe the message
transmission behavior for leasequery.
Parameter Default Description
----------------------------------
LQ_TIMEOUT 1 sec Initial LEASEQUERY timeout
LQ_MAX_RT 10 secs Max LEASEQUERY timeout value
LQ_MAX_RC 5 Max LEASEQUERY retry attempts
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Message Validation</span>
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. LEASEQUERY</span>
Requestors and clients MUST discard any received LEASEQUERY messages.
Servers MUST discard any received LEASEQUERY messages that meet any
of the following conditions:
o the message does not include an OPTION_CLIENTID option.
o the message includes an OPTION_SERVERID option but the contents of
the OPTION_SERVERID option does not match the server's identifier.
o the message does not include an OPTION_LQ_QUERY option.
<span class="grey">Brzozowski, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>. LEASEQUERY-REPLY</span>
Requestors MUST discard any received LEASEQUERY-REPLY messages that
meet any of the following conditions:
o the message does not include an OPTION_SERVERID option.
o the message does not include an OPTION_CLIENTID option, or the
contents of the OPTION_CLIENTID option do not match the DUID of
the requestor.
o the "transaction-id" field in the message does not match the value
used in the original message.
Servers and Relay Agents (on the server port, 547 [<a href="#ref-2" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">2</a>]) MUST discard
any received LEASEQUERY-REPLY messages.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. DHCPv6 Leasequery Requestor Behavior</span>
This section describes how a requestor initiates lease data retrieval
from DHCPv6 servers.
<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>. Creation of LEASEQUERY</span>
The requestor sets the "msg-type" field to LEASEQUERY. The requestor
generates a transaction ID and inserts this value in the
"transaction-id" field.
The requestor MUST include an OPTION_CLIENTID option to identify
itself to the server.
The requestor MUST include an OPTION_LQ_QUERY option and set the
query-type, link-address, and query-options as appropriate to the
query-type (<a href="#section-4.1.2.1">Section 4.1.2.1</a>).
The requestor SHOULD include an OPTION_SERVERID if it is not
unicasting the LEASEQUERY yet only wants a response from a specific
server.
<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a>. Transmission of LEASEQUERY</span>
The requestor MAY be configured to use a list of destination
addresses, which MAY include unicast addresses, the All_DHCP_Servers
multicast address, or other addresses selected by the network
administrator. If the requestor has not been explicitly configured,
it MAY use the All_DHCP_Servers multicast address as the default.
<span class="grey">Brzozowski, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
The requestor SHOULD send LEASEQUERY to one or more DHCPv6 servers
that are known to possess authoritative information concerning the
query target.
In the absence of information concerning which DHCPv6 servers might
possess authoritative information on the query target, the requestor
SHOULD send LEASEQUERY to all DHCPv6 servers that the requestor knows
about or is configured with. For example, the requestor MAY send
LEASEQUERY to the All_DHCP_Servers multicast address.
The requestor transmits LEASEQUERY messages according to Section 14
of [<a href="#ref-2" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">2</a>], using the following parameters:
IRT LQ_TIMEOUT
MRT LQ_MAX_RT
MRC LQ_MAX_RC
MRD 0
If the message exchange fails, the requestor takes an action based on
the requestor's local policy. Examples of actions the requestor
might take include:
o Select another server from a list of servers known to the
requestor.
o Send to multiple servers by multicasting to the All_DHCP_Servers
address.
o Terminate the request.
<span class="h4"><a class="selflink" id="section-4.3.3" href="#section-4.3.3">4.3.3</a>. Receipt of LEASEQUERY-REPLY</span>
A successful LEASEQUERY-REPLY is one without an OPTION_STATUS_CODE
option (or an OPTION_STATUS_CODE option with a success code). There
are three variants:
1. If the server had bindings for the requested client, the message
includes an OPTION_CLIENT_DATA option and the requestor extracts
the client data from the LEASEQUERY-REPLY and updates its binding
information database. If the OPTION_CLIENT_DATA contains no
OPTION_CLT_TIME, the requestor SHOULD silently discard the
OPTION_CLIENT_DATA option.
2. If the server found bindings for the client on multiple links,
the message includes an OPTION_CLIENT_LINK option. The requestor
will need to reissue LEASEQUERY messages using each of the
returned link-addresses to obtain the client's bindings.
<span class="grey">Brzozowski, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
3. If the server had no bindings for the client, neither the
OPTION_CLIENT_DATA nor OPTION_CLIENT_LINK option will be present.
An unsuccessful LEASEQUERY-REPLY is one that has an
OPTION_STATUS_CODE with an error code. Depending on the status code,
the requestor may try a different server (such as for NotAllowed,
NotConfigured, and UnknownQueryType), try a different or corrected
query (such as for UnknownQueryType and MalformedQuery), or terminate
the query.
<span class="h4"><a class="selflink" id="section-4.3.4" href="#section-4.3.4">4.3.4</a>. Handling DHCPv6 Client Data from Multiple Sources</span>
A requestor may receive lease data on the same client from the same
DHCPv6 server in response to different types of LEASEQUERY. If a
LEASEQUERY is sent to multiple servers, the requestor may receive
from several servers lease data on the same DHCPv6 client. This
section describes how the requestor handles multiple lease data
sources on the same DHCPv6 client from the same server or different
servers.
The client data from the different sources may be disjoint or
overlapping. The disjoint and overlapping relationship can happen
between data from the same server or different servers.
If client data from two sources on the same client are of different
types or values, then the data are disjoint. An example of data of
different types is when a requestor receives an IPv6 address lease
from one server and a prefix lease from another server, both assigned
to the same client. An example of different values (but the same
type) is when a requestor receives two IPv6 address leases from two
different servers, both assigned to the same client, but the leases
are on two different IPv6 addresses. If the requestor receives
disjoint client data from different sources, it SHOULD merge them.
If client data from two sources on the same client are of the same
type and value, then the data are overlapping. An example of
overlapping data is when a requestor receives a lease on the same
IPv6 address from two different servers. Overlapping client data are
also called conflicting data.
The requestor SHOULD use the OPTION_CLT_TIME to resolve data
conflicts originated from different servers, and SHOULD accept data
with most recent OPTION_CLT_TIME.
<span class="grey">Brzozowski, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. DHCPv6 Leasequery Server Behavior</span>
A DHCPv6 server sends LEASEQUERY-REPLY messages in response to valid
LEASEQUERY messages it receives to return the statefully assigned
addresses, delegated prefixes, and other information that match the
query.
<span class="h4"><a class="selflink" id="section-4.4.1" href="#section-4.4.1">4.4.1</a>. Receipt of LEASEQUERY Messages</span>
Upon receipt of a valid LEASEQUERY message, the DHCPv6 server locates
the requested client, collects data on the client, and constructs and
returns a LEASEQUERY-REPLY. A LEASEQUERY message cannot be used to
assign, release, or otherwise modify bindings or other configuration
information.
The server constructs a LEASEQUERY-REPLY message by setting the "msg-
type" field to LEASEQUERY-REPLY, and copying the transaction ID from
the LEASEQUERY message into the transaction-id field.
If the query-type in the OPTION_LQ_QUERY option is not a known or
supported value, the server adds an OPTION_STATUS_CODE option with
the UnknownQueryType status code and sends the LEASEQUERY-REPLY to
the requestor. If the query-options do not contain the required
options for the query-type, the server adds an OPTION_STATUS_CODE
option with the MalformedQuery status code and sends the LEASEQUERY-
REPLY to the client.
A server may also restrict LEASEQUERY messages, or query-types, to
certain requestors. In this case, the server MAY discard the
LEASEQUERY message or MAY add an OPTION_STATUS_CODE option with the
NotAllowed status code and send the LEASEQUERY-REPLY to the
requestor.
If the OPTION_LQ_QUERY specified a non-zero link-address, the server
MUST use the link-address to find the appropriate link for the
client. For a QUERY_BY_ADDRESS, if the 0::0 link-address was
specified, the server uses the address from the OPTION_IAADDR option
to find the appropriate link for the client. In either of these
cases, if the server is unable to find the link, it SHOULD return an
OPTION_STATUS_CODE option with the NotConfigured status and send the
LEASEQUERY-REPLY to the requestor.
For a QUERY_BY_CLIENTID, if a 0::0 link-address was specified, the
server MUST search all of its links for the client. If the client is
only found on a single link, the server SHOULD return that client's
data in an OPTION_CLIENT_DATA option. If the client is found on more
<span class="grey">Brzozowski, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
than a single link, the server MUST return the list of links in the
OPTION_CLIENT_LINK option; the server MUST NOT return any client
data.
Otherwise, the server uses the data in the OPTION_LQ_QUERY to
initiate the query. The result of the query will be zero or one
client. This will result in zero or one OPTION_CLIENT_DATA option
being added to the LEASEQUERY-REPLY.
<span class="h4"><a class="selflink" id="section-4.4.2" href="#section-4.4.2">4.4.2</a>. Constructing the Client's OPTION_CLIENT_DATA</span>
An OPTION_CLIENT_DATA option in a LEASEQUERY-REPLY message MUST
minimally contain the following options:
1. OPTION_CLIENTID
2. OPTION_IAADDR and/or OPTION_IAPREFIX
3. OPTION_CLT_TIME
Depending on the bindings the client has on a link, either
OPTION_IAADDR options, OPTION_IAPREFIX options, or both may be
present.
The OPTION_CLIENT_DATA SHOULD include options requested in the
OPTION_ORO of the OPTION_LQ_QUERY option in the LEASEQUERY message
and that are acceptable to return based on the list of "sensitive
options", discussed below.
DHCPv6 servers SHOULD be configurable with a list of "sensitive
options" that must not be returned to the requestor when specified in
the OPTION_ORO of the OPTION_LQ_QUERY option in the LEASEQUERY
message. Any option on this list MUST NOT be returned to a
requestor, even if requested by that requestor.
<span class="h4"><a class="selflink" id="section-4.4.3" href="#section-4.4.3">4.4.3</a>. Transmission of LEASEQUERY-REPLY Messages</span>
The server sends the LEASEQUERY-REPLY message as described in the
"Transmission of Reply Messages" section of [<a href="#ref-2" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">2</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
Access concentrators are expected to be common leasequery requestors.
Access concentrators that use DHCPv6 gleaning (i.e., [<a href="#ref-10" title=""DHCPv6 Relay Agent Assignment Notification (RAAN) Option"">10</a>]), refreshed
with LEASEQUERY messages, will maintain accurate client/binding
information. This ensures that the access concentrator can forward
data traffic to the intended destination in the broadband access
network, can perform IPv6 source address verification of datagrams
from the access network, and can encrypt traffic that can only be
<span class="grey">Brzozowski, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
decrypted by the intended access modem (e.g., [<a href="#ref-12" title=""Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface Specification SCTE 22-2 2002"">12</a>] and [<a href="#ref-13" title=""Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12- 050812"">13</a>]). Thus,
the leasequery capability allows an access concentrator to provide
considerably enhanced security.
The "Security Considerations" section of [<a href="#ref-2" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">2</a>] details the general
threats to DHCPv6, and thus to LEASEQUERY messages. The
"Authentication of DHCP Messages" section of [<a href="#ref-2" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">2</a>] describes securing
communication between relay agents and servers, as well as clients
and servers. If the requestor is an access concentrator, the IPsec-
based [<a href="#ref-9" title=""Security Architecture for the Internet Protocol"">9</a>] security as described in [<a href="#ref-2" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">2</a>] <a href="#section-21.1">Section 21.1</a> SHOULD be used.
Other types of requestors are essentially DHCPv6 clients. Thus,
DHCPv6 authentication, Section 21 of [<a href="#ref-2" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">2</a>], is an appropriate mechanism
for securing LEASEQUERY and LEASEQUERY-REPLY messages. As the number
of leasequery requestors and servers in an administrative domain is
relatively small, any shared key distribution issues are minimized.
After implementing the above approaches, the DHCPv6 server should
only be communicating with trusted LEASEQUERY requestors, and so
security needs should be met.
However, not all traffic originates directly from these trusted
requestors. For example, trusted relay agents can relay LEASEQUERY
messages from untrusted requestors or elsewhere in the network. This
SHOULD be prevented at least at the perimeter relay agents (or on all
relay agents unless relayed LEASEQUERY messages are required for some
requestors). DHCPv6 servers MAY be configured to discard relayed
LEASEQUERY messages or restrict relay chaining.
DHCPv6 servers SHOULD also provide for the ability to restrict the
information returned for a client in a LEASEQUERY-REPLY even to a
trusted LEASEQUERY requestor, as described in <a href="#section-4.4.2">Section 4.4.2</a>.
Since even trusted access concentrators may generate LEASEQUERY
requests as a result of activity external to the access concentrator,
access concentrators SHOULD minimize potential denial-of-service
attacks on the DHCPv6 servers by minimizing the generation of
LEASEQUERY messages. In particular, the access concentrator SHOULD
employ negative caching (i.e., cache the fact that a particular
recent query failed to return client data) and address restrictions
where possible (i.e., don't send a LEASEQUERY message for addresses
outside the range of the attached broadband access networks).
Together, these mechanisms limit the access concentrator to
transmitting one LEASEQUERY message (excluding message retries) per
legitimate broadband access network address after a reboot event.
Packet-flooding denial-of-service attacks can result in the
exhaustion of processing resources, thus preventing the server from
serving legitimate and regular DHCPv6 clients as well as legitimate
<span class="grey">Brzozowski, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
DHCPv6 LEASEQUERY requestors, denying configurations to legitimate
DHCPv6 clients as well lease information to legitimate DHCPv6
LEASEQUERY requestors. While these attacks are unlikely when only
communicating with trusted LEASEQUERY requestors, the possibility
always exists that the trust is misplaced, security techniques are
compromised, or even trusted requestors can have bugs in them.
Therefore, techniques for defending against packet-flooding denial of
service are always a good idea, and they include good perimeter
security, as mentioned earlier, and rate limiting DHCPv6 traffic by
relay agents, other network elements, or the server itself.
One way to attack an access concentrator (as opposed to a DHCPv6
server) as a LEASEQUERY requestor is the establishment of a malicious
server with the intent of providing incorrect lease or route
information to the access concentrator, thwarting source IPv6 address
verification, and preventing correct routing. This type of attack
can be minimized by using IPsec as described in Section 21.1 of [<a href="#ref-2" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">2</a>].
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
IANA has assigned the following new DHCPv6 Message types in the
registry maintained in
<a href="http://www.iana">http://www.iana</a>.org/assignments/dhcpv6-parameters:
LEASEQUERY
LEASEQUERY-REPLY
IANA has assigned the following new DHCPv6 Option Codes in the
registry maintained in
<a href="http://www.iana">http://www.iana</a>.org/assignments/dhcpv6-parameters:
OPTION_LQ_QUERY
OPTION_CLIENT_DATA
OPTION_CLT_TIME
OPTION_LQ_RELAY_DATA
OPTION_LQ_CLIENT_LINK
IANA has assigned the following new DHCPv6 Status Codes in the
registry maintained in
<a href="http://www.iana">http://www.iana</a>.org/assignments/dhcpv6-parameters:
UnknownQueryType
MalformedQuery
NotConfigured
NotAllowed
<span class="grey">Brzozowski, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
IANA has created a new registry for the OPTION_LQ_QUERY option query-
type codes in the registry maintained in
<a href="http://www.iana.org/assignments/dhcpv6-parameters">http://www.iana.org/assignments/dhcpv6-parameters</a> with the following
initial assignments:
QUERY_BY_ADDRESS 1
QUERY_BY_CLIENTID 2
New OPTION_LQ_QUERY option query-type codes are assigned through
Standards Action, as defined in [<a href="#ref-6" title="">6</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
Thanks to Ralph Droms, Richard Johnson, Josh Littlefield, Hemant
Singh, Pak Siripunkaw, Markus Stenberg, and Ole Troan for their
input, ideas, and review during the production of this document.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-1">1</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-2">2</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-3">3</a>] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol
(DHCP) Leasequery", <a href="./rfc4388">RFC 4388</a>, February 2006.
[<a id="ref-4">4</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.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-5">5</a>] Droms, R., "Dynamic Host Configuration Protocol", <a href="./rfc2131">RFC 2131</a>,
March 1997.
[<a id="ref-6">6</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc2434">RFC 2434</a>,
October 1998.
[<a id="ref-7">7</a>] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", <a href="./rfc2461">RFC 2461</a>, December 1998.
<span class="grey">Brzozowski, et al. Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
[<a id="ref-8">8</a>] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
<a href="./rfc826">RFC 826</a>, November 1982.
[<a id="ref-9">9</a>] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", <a href="./rfc4301">RFC 4301</a>, December 2005.
[<a id="ref-10">10</a>] Droms, R., "DHCPv6 Relay Agent Assignment Notification (RAAN)
Option", Work in Progress, November 2006.
[<a id="ref-11">11</a>] CableLabs, "Data-Over-Cable Service Interface Specifications:
DOCSIS 3.0, MAC and Upper Layer Protocols Interface
Specification, CM-SP-MULPIv3.0-I04-070518", May 2007, available
at <a href="http://www.cablemodem.com/">http://www.cablemodem.com/</a>.
[<a id="ref-12">12</a>] SCTE Data Standards Subcommittee, "Data-Over-Cable Service
Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface
Specification SCTE 22-2 2002", 2002, available at
<a href="http://www.scte.org/standards/">http://www.scte.org/standards/</a>.
[<a id="ref-13">13</a>] CableLabs, "Data-Over-Cable Service Interface Specifications:
Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12-
050812", August 2005, available at <a href="http://www.cablemodem.com/">http://www.cablemodem.com/</a>.
<span class="grey">Brzozowski, et al. Standards Track [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
Authors' Addresses
John Jason Brzozowski
Comcast Cable
1800 Bishops Gate Boulevard
Mt. Laurel, NJ 08054
USA
Phone: +1 856 324 2671
EMail: john_brzozowski@cable.comcast.com
Kim Kinnear
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone: +1 978 936 0000
EMail: kkinnear@cisco.com
Bernard Volz
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone: +1 978 936 0000
EMail: volz@cisco.com
Shengyou Zeng
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone: +1 978 936 0000
EMail: szeng@cisco.com
<span class="grey">Brzozowski, et al. Standards Track [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc5007">RFC 5007</a> DHCPv6 Leasequery September 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Brzozowski, et al. Standards Track [Page 23]
</pre>
|
