summaryrefslogtreecommitdiff
path: root/doc/References.txt
blob: 28727260849320693b76182f5a9a84b86c0a9735 (plain)
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



ISC-DHCP-REFERENCES                                           D. Hankins
                                                            T. Mrugalski
                                                                     ISC
                                                        January 04, 2012


                     ISC DHCP References Collection

Abstract

   This document describes a collection of reference material to which
   ISC DHCP has been implemented as well as a more complete listing of
   references for DHCP and DHCPv6 protocols.

Copyright Notice

   Copyright (c) 2006-2007,2009,2011 by Internet Systems Consortium,
   Inc. ("ISC")

   Permission to use, copy, modify, and distribute this software for any
   purpose with or without fee is hereby granted, provided that the
   above copyright notice and this permission notice appear in all
   copies.

   THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
   WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
   MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY
   SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
   WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
   ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
   OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.




















Hankins & Mrugalski                                             [Page 1]

                     ISC DHCP References Collection         January 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Definition: Reference Implementation . . . . . . . . . . . . .  3

   3.  Low Layer References . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Ethernet Protocol References . . . . . . . . . . . . . . .  6
     3.2.  Token Ring Protocol References . . . . . . . . . . . . . .  6
     3.3.  FDDI Protocol References . . . . . . . . . . . . . . . . .  6
     3.4.  Internet Protocol Version 4 References . . . . . . . . . .  6
     3.5.  Unicast Datagram Protocol References . . . . . . . . . . .  6

   4.  BOOTP Protocol References  . . . . . . . . . . . . . . . . . .  6

   5.  DHCPv4 Protocol References . . . . . . . . . . . . . . . . . .  7
     5.1.  DHCPv4 Protocol  . . . . . . . . . . . . . . . . . . . . .  7
       5.1.1.  Core Protocol References . . . . . . . . . . . . . . .  7
     5.2.  DHCPv4 Option References . . . . . . . . . . . . . . . . .  7
       5.2.1.  Relay Agent Information Option Options . . . . . . . .  9
       5.2.2.  Dynamic DNS Updates References . . . . . . . . . . . .  9
       5.2.3.  Experimental: Failover References  . . . . . . . . . .  9
     5.3.  DHCP Procedures  . . . . . . . . . . . . . . . . . . . . . 10

   6.  DHCPv6 Protocol References . . . . . . . . . . . . . . . . . . 10
     6.1.  DHCPv6 Protocol References . . . . . . . . . . . . . . . . 10
     6.2.  DHCPv6 Options References  . . . . . . . . . . . . . . . . 11

   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Published DHCPv4 References  . . . . . . . . . . . . . . . 12
     7.2.  Published Common (DHCPv4/DHCPv6) References  . . . . . . . 17
     7.3.  Published DHCPv6 References  . . . . . . . . . . . . . . . 18

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20

















Hankins & Mrugalski                                             [Page 2]

                     ISC DHCP References Collection         January 2012


1.  Introduction

   As a little historical anecdote, ISC DHCP once packaged all the
   relevant RFCs and standards documents along with the software
   package.  Until one day when a voice was heard from one of the many
   fine institutions that build and distribute this software... they
   took issue with the IETF's copyright on the RFC's.  It seems the
   IETF's copyrights don't allow modification of RFC's (except for
   translation purposes).

   Our main purpose in providing the RFCs is to aid in documentation,
   but since RFCs are now available widely from many points of
   distribution on the Internet, there is no real need to provide the
   documents themselves.  So, this document has been created in their
   stead, to list the various IETF RFCs one might want to read, and to
   comment on how well (or poorly) we have managed to implement them.


2.  Definition: Reference Implementation

   ISC DHCP, much like its other cousins in ISC software, is self-
   described as a 'Reference Implementation.'  There has been a great
   deal of confusion about this term.  Some people seem to think that
   this term applies to any software that once passed a piece of
   reference material on its way to market (but may do quite a lot of
   things that aren't described in any reference, or may choose to
   ignore the reference it saw entirely).  Other folks get confused by
   the word 'reference' and understand that to mean that there is some
   special status applied to the software - that the software itself is
   the reference by which all other software is measured.  Something
   along the lines of being "The DHCP Protocol's Reference Clock," it is
   supposed.

   The truth is actually quite a lot simpler.  Reference implementations
   are software packages which were written to behave precisely as
   appears in reference material.  They are written "to match
   reference."

   If the software has a behaviour that manifests itself externally
   (whether it be something as simple as the 'wire format' or something
   higher level, such as a complicated behaviour that arises from
   multiple message exchanges), that behaviour must be found in a
   reference document.

   Anything else is a bug, the only question is whether the bug is in
   reference or software (failing to implement the reference).

   This means:



Hankins & Mrugalski                                             [Page 3]

                     ISC DHCP References Collection         January 2012


   o  To produce new externally-visible behaviour, one must first
      provide a reference.

   o  Before changing externally visible behaviour to work around simple
      incompatibilities in any other implementation, one must first
      provide a reference.

   That is the lofty goal, at any rate.  It's well understood that,
   especially because the ISC DHCP Software package has not always been
   held to this standard (but not entirely due to it), there are many
   non-referenced behaviours within ISC DHCP.

   The primary goal of reference implementation is to prove the
   reference material.  If the reference material is good, then you
   should be able to sit down and write a program that implements the
   reference, to the word, and come to an implementation that is
   distinguishable from others in the details, but not in the facts of
   operating the protocol.  This means that there is no need for
   'special knowledge' to work around arcane problems that were left
   undocumented.  No secret handshakes need to be learned to be imparted
   with the necessary "real documentation".

   Also, by accepting only reference as the guidebook for ISC DHCP's
   software implementation, anyone who can make an impact on the color
   texture or form of that reference has a (somewhat indirect) voice in
   ISC DHCP's software design.  As the IETF RFC's have been selected as
   the source of reference, that means everyone on the Internet with the
   will to participate has a say.


3.  Low Layer References

   It may surprise you to realize that ISC DHCP implements 802.1
   'Ethernet' framing, Token Ring, and FDDI.  In order to bridge the gap
   there between these physical and DHCP layers, it must also implement
   IP and UDP framing.

   The reason for this stems from Unix systems' handling of BSD sockets
   (the general way one might engage in transmission of UDP packets) on
   unconfigured interfaces, or even the handling of broadcast addressing
   on configured interfaces.

   There are a few things that DHCP servers, relays, and clients all
   need to do in order to speak the DHCP protocol in strict compliance
   with [RFC2131].

   1.  Transmit a UDP packet from IP:0.0.0.0 Ethernet:Self, destined to
       IP:255.255.255.255 LinkLayer:Broadcast on an unconfigured (no IP



Hankins & Mrugalski                                             [Page 4]

                     ISC DHCP References Collection         January 2012


       address yet) interface.

   2.  Receive a UDP packet from IP:remote-system LinkLayer:remote-
       system, destined to IP:255.255.255.255 LinkLayer:Broadcast, again
       on an unconfigured interface.

   3.  Transmit a UDP packet from IP:Self, Ethernet:Self, destined to
       IP:remote-system LinkLayer:remote-system, without transmitting a
       single ARP.

   4.  And of course the simple case, a regular IP unicast that is
       routed via the usual means (so it may be direct to a local
       system, with ARP providing the glue, or it may be to a remote
       system via one or more routers as normal).  In this case, the
       interfaces are always configured.

   The above isn't as simple as it sounds on a regular BSD socket.  Many
   unix implementations will transmit broadcasts not to 255.255.255.255,
   but to x.y.z.255 (where x.y.z is the system's local subnet).  Such
   packets are not received by several known DHCP client implementations
   - and it's not their fault, [RFC2131] very explicitly demands that
   these packets' IP destination addresses be set to 255.255.255.255.

   Receiving packets sent to 255.255.255.255 isn't a problem on most
   modern unixes...so long as the interface is configured.  When there
   is no IPv4 address on the interface, things become much more murky.

   So, for this convoluted and unfortunate state of affairs in the unix
   systems of the day ISC DHCP was manufactured, in order to do what it
   needs not only to implement the reference but to interoperate with
   other implementations, the software must create some form of raw
   socket to operate on.

   What it actually does is create, for each interface detected on the
   system, a Berkeley Packet Filter socket (or equivalent), and program
   it with a filter that brings in only DHCP packets.  A "fallback" UDP
   Berkeley socket is generally also created, a single one no matter how
   many interfaces.  Should the software need to transmit a contrived
   packet to the local network the packet is formed piece by piece and
   transmitted via the BPF socket.  Hence the need to implement many
   forms of Link Layer framing and above.  The software gets away with
   not having to implement IP routing tables as well by simply utilizing
   the aforementioned 'fallback' UDP socket when unicasting between two
   configured systems is needed.

   Modern unixes have opened up some facilities that diminish how much
   of this sort of nefarious kludgery is necessary, but have not found
   the state of affairs absolutely resolved.  In particular, one might



Hankins & Mrugalski                                             [Page 5]

                     ISC DHCP References Collection         January 2012


   now unicast without ARP by inserting an entry into the ARP cache
   prior to transmitting.  Unconfigured interfaces remain the sticking
   point, however...on virtually no modern unixes is it possible to
   receive broadcast packets unless a local IPv4 address has been
   configured, unless it is done with raw sockets.

3.1.  Ethernet Protocol References

   ISC DHCP Implements Ethernet Version 2 ("DIX"), which is a variant of
   IEEE 802.2.  No good reference of this framing is known to exist at
   this time, but it is vaguely described in [RFC0894] see the section
   titled "Packet format"), and the following URL is also thought to be
   useful.

   http://en.wikipedia.org/wiki/DIX_Ethernet

3.2.  Token Ring Protocol References

   IEEE 802.5 defines the Token Ring framing format used by ISC DHCP.

3.3.  FDDI Protocol References

   [RFC1188] is the most helpful reference ISC DHCP has used to form
   FDDI packets.

3.4.  Internet Protocol Version 4 References

   RFC760 [RFC0760] fundamentally defines the bare IPv4 protocol which
   ISC DHCP implements.

3.5.  Unicast Datagram Protocol References

   RFC768 [RFC0768] defines the User Datagram Protocol that ultimately
   carries the DHCP or BOOTP protocol.  The destination DHCP server port
   is 67, the client port is 68.  Source ports are irrelevant.


4.  BOOTP Protocol References

   The DHCP Protocol is strange among protocols in that it is grafted
   over the top of another protocol - BOOTP (but we don't call it "DHCP
   over BOOTP" like we do, say "TCP over IP").  BOOTP and DHCP share UDP
   packet formats - DHCP is merely a conventional use of both BOOTP
   header fields and the trailing 'options' space.

   The ISC DHCP server supports BOOTP clients conforming to RFC951
   [RFC0951] and RFC1542 [RFC1542].




Hankins & Mrugalski                                             [Page 6]

                     ISC DHCP References Collection         January 2012


5.  DHCPv4 Protocol References

5.1.  DHCPv4 Protocol

   "The DHCP[v4] Protocol" is not defined in a single document.  The
   following collection of references of what ISC DHCP terms "The DHCPv4
   Protocol".

5.1.1.  Core Protocol References

   RFC2131 [RFC2131] defines the protocol format and procedures.  ISC
   DHCP is not known to diverge from this document in any way.  There
   are, however, a few points on which different implementations have
   arisen out of vagueries in the document.  DHCP Clients exist which,
   at one time, present themselves as using a Client Identifier Option
   which is equal to the client's hardware address.  Later, the client
   transmits DHCP packets with no Client Identifier Option present -
   essentially identifying themselves using the hardware address.  Some
   DHCP Servers have been developed which identify this client as a
   single client.  ISC has interpreted RFC2131 to indicate that these
   clients must be treated as two separate entities (and hence two,
   separate addresses).  Client behaviour (Embedded Windows products)
   has developed that relies on the former implementation, and hence is
   incompatible with the latter.  Also, RFC2131 demands explicitly that
   some header fields be zeroed upon certain message types.  The ISC
   DHCP Server instead copies many of these fields from the packet
   received from the client or relay, which may not be zero.  It is not
   known if there is a good reason for this that has not been
   documented.

   RFC2132 [RFC2132] defines the initial set of DHCP Options and
   provides a great deal of guidance on how to go about formatting and
   processing options.  The document unfortunately waffles to a great
   extent about the NULL termination of DHCP Options, and some DHCP
   Clients (Windows 95) have been implemented that rely upon DHCP
   Options containing text strings to be NULL-terminated (or else they
   crash).  So, ISC DHCP detects if clients null-terminate the host-name
   option and, if so, null terminates any text options it transmits to
   the client.  It also removes NULL termination from any known text
   option it receives prior to any other processing.

5.2.  DHCPv4 Option References

   RFC2241 [RFC2241] defines options for Novell Directory Services.

   RFC2242 [RFC2242] defines an encapsulated option space for NWIP
   configuration.




Hankins & Mrugalski                                             [Page 7]

                     ISC DHCP References Collection         January 2012


   RFC2485 [RFC2485] defines the Open Group's UAP option.

   RFC2610 [RFC2610] defines options for the Service Location Protocol
   (SLP).

   RFC2937 [RFC2937] defines the Name Service Search Option (not to be
   confused with the domain-search option).  The Name Service Search
   Option allows eg nsswitch.conf to be reconfigured via dhcp.  The ISC
   DHCP server implements this option, and the ISC DHCP client is
   compatible...but does not by default install this option's value.
   One would need to make their relevant dhclient-script process this
   option in a way that is suitable for the system.

   RFC3004 [RFC3004] defines the User-Class option.  Note carefully that
   ISC DHCP currently does not implement to this reference, but has
   (inexplicably) selected an incompatible format: a plain text string.

   RFC3011 [RFC3011] defines the Subnet-Selection plain DHCPv4 option.
   Do not confuse this option with the relay agent "link selection" sub-
   option, although their behaviour is similar.

   RFC3396 [RFC3396] documents both how long options may be encoded in
   DHCPv4 packets, and also how multiple instances of the same option
   code within a DHCPv4 packet will be decoded by receivers.

   RFC3397 [RFC3397] documents the Domain-Search Option, which allows
   the configuration of the /etc/resolv.conf 'search' parameter in a way
   that is RFC1035 [RFC1035] wire format compatible (in fact, it uses
   the RFC1035 wire format).  ISC DHCP has both client and server
   support, and supports RFC1035 name compression.

   RFC3679 [RFC3679] documents a number of options that were documented
   earlier in history, but were not made use of.

   RFC3925 [RFC3925] documents a pair of Enterprise-ID delimited option
   spaces for vendors to use in order to inform servers of their "vendor
   class" (sort of like 'uname' or 'who and what am I'), and a means to
   deliver vendor-specific and vendor-documented option codes and
   values.

   RFC3942 [RFC3942] redefined the 'site local' option space.

   [RFC4280] defines two BCMS server options for each protocol family.

   RFC4388 [RFC4388] defined the DHCPv4 LEASEQUERY message type and a
   number of suitable response messages, for the purpose of sharing
   information about DHCP served addresses and clients.




Hankins & Mrugalski                                             [Page 8]

                     ISC DHCP References Collection         January 2012


5.2.1.  Relay Agent Information Option Options

   RFC3046 [RFC3046] defines the Relay Agent Information Option and
   provides a number of sub-option definitions.

   RFC3256 [RFC3256] defines the DOCSIS Device Class sub-option.

   RFC3527 [RFC3527] defines the Link Selection sub-option.

5.2.2.  Dynamic DNS Updates References

   The collection of documents that describe the standards-based method
   to update dns names of DHCP clients starts most easily with RFC4703
   [RFC4703] to define the overall architecture, travels through RFCs
   4702 [RFC4702] and 4704 [RFC4704] to describe the DHCPv4 and DHCPv6
   FQDN options (to carry the client name), and ends up at RFC4701
   [RFC4701] which describes the DHCID RR used in DNS to perform a kind
   of atomic locking.

   ISC DHCP adopted early versions of these documents, and has not yet
   synchronized with the final standards versions.

   For RFCs 4702 and 4704, the 'N' bit is not yet supported.  The result
   is that it is always set zero, and is ignored if set.

   For RFC4701, which is used to match client identities with names in
   the DNS as part of name conflict resolution.  Note that ISC DHCP's
   implementation of DHCIDs vary wildly from this specification.  First,
   ISC DHCP uses a TXT record in which the contents are stored in
   hexadecimal.  Second, there is a flaw in the selection of the
   'Identifier Type', which results in a completely different value
   being selected than was defined in an older revision of this
   document...also this field is one byte prior to hexadecimal encoding
   rather than two.  Third, ISC DHCP does not use a digest type code.
   Rather, all values for such TXT records are reached via an MD5 sum.
   In short, nothing is compatible, but the principle of the TXT record
   is the same as the standard DHCID record.  However, for DHCPv6 FQDN,
   we do use DHCID type code '2', as no other value really makes sense
   in our context.

5.2.3.  Experimental: Failover References

   The Failover Protocol defines means by which two DHCP Servers can
   share all the relevant information about leases granted to DHCP
   clients on given networks, so that one of the two servers may fail
   and be survived by a server that can act responsibly.

   Unfortunately it has been quite some years (2003) since the last time



Hankins & Mrugalski                                             [Page 9]

                     ISC DHCP References Collection         January 2012


   this document was edited, and the authors no longer show any interest
   in fielding comments or improving the document.

   The status of this protocol is very unsure, but ISC's implementation
   of it has proven stable and suitable for use in sizable production
   environments.

   draft-ietf-dhc-failover-12.txt [draft-failover] describes the
   Failover Protocol.  In addition to what is described in this
   document, ISC DHCP has elected to make some experimental changes that
   may be revoked in a future version of ISC DHCP (if the draft authors
   do not adopt the new behaviour).  Specifically, ISC DHCP's POOLREQ
   behaviour differs substantially from what is documented in the draft,
   and the server also implements a form of 'MAC Address Affinity' which
   is not described in the failover document.  The full nature of these
   changes have been described on the IETF DHC WG mailing list (which
   has archives), and also in ISC DHCP's manual pages.  Also note that
   although this document references a RECOVER-WAIT state, it does not
   document a protocol number assignment for this state.  As a
   consequence, ISC DHCP has elected to use the value 254.

   An optimization described in the failover protocol draft is included
   since 4.2.0a1.  It permits a DHCP server operating in communications-
   interrupted state to 'rewind' a lease to the state most recently
   transmitted to its peer, greatly increasing a server's endurance in
   communications-interrupted.  This is supported using a new 'rewind
   state' record on the dhcpd.leases entry for each lease.

   [RFC3074] describes the Load Balancing Algorithm (LBA) that ISC DHCP
   uses in concert with the Failover protocol.  Note that versions 3.0.*
   are known to misimplement the hash algorithm (it will only use the
   low 4 bits of every byte of the hash bucket array).

5.3.  DHCP Procedures

   [RFC2939] explains how to go about obtaining a new DHCP Option code
   assignment.


6.  DHCPv6 Protocol References

6.1.  DHCPv6 Protocol References

   For now there is only one document that specifies the base of the
   DHCPv6 protocol (there have been no updates yet), [RFC3315].

   Support for DHCPv6 was first added in version 4.0.0.  The server and
   client support only IA_NA.  While the server does support multiple



Hankins & Mrugalski                                            [Page 10]

                     ISC DHCP References Collection         January 2012


   IA_NAs within one packet from the client, our client only supports
   sending one.  There is no relay support.

   DHCPv6 introduces some new and uncomfortable ideas to the common
   software library.

   1.  Options sometimes may appear multiple times.  The common library
       used to treat all appearance of multiple options as specified in
       RFC2131 - to be concatenated.  DHCPv6 options may sometimes
       appear multiple times (such as with IA_NA or IAADDR), but often
       must not.  As of 4.2.1-P1, multiple IA_NA, IA_PD or IA_TA are not
       supported.

   2.  The same option space appears in DHCPv6 packets multiple times.
       If the packet was got via a relay, then the client's packet is
       stored to an option within the relay's packet...if there were two
       relays, this recurses.  At each of these steps, the root "DHCPv6
       option space" is used.  Further, a client packet may contain an
       IA_NA, which may contain an IAADDR - but really, in an abstract
       sense, this is again re-encapsulation of the DHCPv6 option space
       beneath options it also contains.

   Precisely how to correctly support the above conundrums has not quite
   yet been settled, so support is incomplete.

   [RFC5453] creates a registry at IANA to reserve interface identifiers
   and specifies a starting set.  These IIDs should not be used when
   constructing addresses to avoid possible conflicts.

6.2.  DHCPv6 Options References

   [RFC3319] defines the SIP server options for DHCPv6.

   [RFC3646] documents the DHCPv6 name-servers and domain-search
   options.

   [RFC3633] documents the Identity Association Prefix Delegation for
   DHCPv6, which is included here for protocol wire reference, but which
   is not supported by ISC DHCP.

   [RFC3898] documents four NIS options for delivering NIS servers and
   domain information in DHCPv6.

   [RFC4075] defines the DHCPv6 SNTP Servers option.

   [RFC4242] defines the Information Refresh Time option, which advises
   DHCPv6 Information-Request clients to return for updated information.




Hankins & Mrugalski                                            [Page 11]

                     ISC DHCP References Collection         January 2012


   [RFC4280] defines two BCMS server options for each protocol family.

   [RFC4580] defines a DHCPv6 subscriber-id option, which is similar in
   principle to the DHCPv4 relay agent option of the same name.

   [RFC4649] defines a DHCPv6 remote-id option, which is similar in
   principle to the DHCPv4 relay agent remote-id.


7.  References

7.1.  Published DHCPv4 References

   [RFC0760]  Postel, J., "DoD standard Internet Protocol", RFC 760,
              January 1980.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0894]  Hornig, C., "Standard for the transmission of IP datagrams
              over Ethernet networks", STD 41, RFC 894, April 1984.

   [RFC0951]  Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951,
              September 1985.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1188]  Katz, D., "Proposed Standard for the Transmission of IP
              Datagrams over FDDI Networks", RFC 1188, October 1990.

   [RFC1542]  Wimer, W., "Clarifications and Extensions for the
              Bootstrap Protocol", RFC 1542, October 1993.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC2241]  Provan, D., "DHCP Options for Novell Directory Services",
              RFC 2241, November 1997.

   [RFC2242]  Droms, R. and K. Fong, "NetWare/IP Domain Name and
              Information", RFC 2242, November 1997.

   [RFC2485]  Drach, S., "DHCP Option for The Open Group's User
              Authentication Protocol", RFC 2485, January 1999.



Hankins & Mrugalski                                            [Page 12]

                     ISC DHCP References Collection         January 2012


   [RFC2563]  Troll, R., "DHCP Option to Disable Stateless Auto-
              Configuration in IPv4 Clients", RFC 2563, May 1999.

   [RFC2610]  Perkins, C. and E. Guttman, "DHCP Options for Service
              Location Protocol", RFC 2610, June 1999.

   [RFC2855]  Fujisawa, K., "DHCP for IEEE 1394", RFC 2855, June 2000.

   [RFC2937]  Smith, C., "The Name Service Search Option for DHCP",
              RFC 2937, September 2000.

   [RFC2939]  Droms, R., "Procedures and IANA Guidelines for Definition
              of New DHCP Options and Message Types", BCP 43, RFC 2939,
              September 2000.

   [RFC3004]  Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis,
              A., Beser, B., and J. Privat, "The User Class Option for
              DHCP", RFC 3004, November 2000.

   [RFC3011]  Waters, G., "The IPv4 Subnet Selection Option for DHCP",
              RFC 3011, November 2000.

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

   [RFC3074]  Volz, B., Gonczi, S., Lemon, T., and R. Stevens, "DHC Load
              Balancing Algorithm", RFC 3074, February 2001.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.

   [RFC3203]  T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP
              reconfigure extension", RFC 3203, December 2001.

   [RFC3256]  Jones, D. and R. Woundy, "The DOCSIS (Data-Over-Cable
              Service Interface Specifications) Device Class DHCP
              (Dynamic Host Configuration Protocol) Relay Agent
              Information Sub-option", RFC 3256, April 2002.

   [RFC3361]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCP-for-IPv4) Option for Session Initiation Protocol
              (SIP) Servers", RFC 3361, August 2002.

   [RFC3396]  Lemon, T. and S. Cheshire, "Encoding Long Options in the
              Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
              November 2002.

   [RFC3397]  Aboba, B. and S. Cheshire, "Dynamic Host Configuration



Hankins & Mrugalski                                            [Page 13]

                     ISC DHCP References Collection         January 2012


              Protocol (DHCP) Domain Search Option", RFC 3397,
              November 2002.

   [RFC3442]  Lemon, T., Cheshire, S., and B. Volz, "The Classless
              Static Route Option for Dynamic Host Configuration
              Protocol (DHCP) version 4", RFC 3442, December 2002.

   [RFC3456]  Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic
              Host Configuration Protocol (DHCPv4) Configuration of
              IPsec Tunnel Mode", RFC 3456, January 2003.

   [RFC3495]  Beser, B. and P. Duffy, "Dynamic Host Configuration
              Protocol (DHCP) Option for CableLabs Client
              Configuration", RFC 3495, March 2003.

   [RFC3527]  Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
              "Link Selection sub-option for the Relay Agent Information
              Option for DHCPv4", RFC 3527, April 2003.

   [RFC3594]  Duffy, P., "PacketCable Security Ticket Control Sub-Option
              for the DHCP CableLabs Client Configuration (CCC) Option",
              RFC 3594, September 2003.

   [RFC3634]  Luehrs, K., Woundy, R., Bevilacqua, J., and N. Davoust,
              "Key Distribution Center (KDC) Server Address Sub-option
              for the Dynamic Host Configuration Protocol (DHCP)
              CableLabs Client Configuration (CCC) Option", RFC 3634,
              December 2003.

   [RFC3679]  Droms, R., "Unused Dynamic Host Configuration Protocol
              (DHCP) Option Codes", RFC 3679, January 2004.

   [RFC3825]  Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
              Configuration Protocol Option for Coordinate-based
              Location Configuration Information", RFC 3825, July 2004.

   [RFC3925]  Littlefield, J., "Vendor-Identifying Vendor Options for
              Dynamic Host Configuration Protocol version 4 (DHCPv4)",
              RFC 3925, October 2004.

   [RFC3942]  Volz, B., "Reclassifying Dynamic Host Configuration
              Protocol version 4 (DHCPv4) Options", RFC 3942,
              November 2004.

   [RFC3993]  Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID
              Suboption for the Dynamic Host Configuration Protocol
              (DHCP) Relay Agent Option", RFC 3993, March 2005.




Hankins & Mrugalski                                            [Page 14]

                     ISC DHCP References Collection         January 2012


   [RFC4014]  Droms, R. and J. Schnizlein, "Remote Authentication
              Dial-In User Service (RADIUS) Attributes Suboption for the
              Dynamic Host Configuration Protocol (DHCP) Relay Agent
              Information Option", RFC 4014, February 2005.

   [RFC4030]  Stapp, M. and T. Lemon, "The Authentication Suboption for
              the Dynamic Host Configuration Protocol (DHCP) Relay Agent
              Option", RFC 4030, March 2005.

   [RFC4039]  Park, S., Kim, P., and B. Volz, "Rapid Commit Option for
              the Dynamic Host Configuration Protocol version 4
              (DHCPv4)", RFC 4039, March 2005.

   [RFC4174]  Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic
              Host Configuration Protocol (DHCP) Option for the Internet
              Storage Name Service", RFC 4174, September 2005.

   [RFC4243]  Stapp, M., Johnson, R., and T. Palaniappan, "Vendor-
              Specific Information Suboption for the Dynamic Host
              Configuration Protocol (DHCP) Relay Agent Option",
              RFC 4243, December 2005.

   [RFC4361]  Lemon, T. and B. Sommerfeld, "Node-specific Client
              Identifiers for Dynamic Host Configuration Protocol
              Version Four (DHCPv4)", RFC 4361, February 2006.

   [RFC4388]  Woundy, R. and K. Kinnear, "Dynamic Host Configuration
              Protocol (DHCP) Leasequery", RFC 4388, February 2006.

   [RFC4390]  Kashyap, V., "Dynamic Host Configuration Protocol (DHCP)
              over InfiniBand", RFC 4390, April 2006.

   [RFC4436]  Aboba, B., Carlson, J., and S. Cheshire, "Detecting
              Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.

   [RFC4701]  Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource
              Record (RR) for Encoding Dynamic Host Configuration
              Protocol (DHCP) Information (DHCID RR)", RFC 4701,
              October 2006.

   [RFC4702]  Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
              Configuration Protocol (DHCP) Client Fully Qualified
              Domain Name (FQDN) Option", RFC 4702, October 2006.

   [RFC4703]  Stapp, M. and B. Volz, "Resolution of Fully Qualified
              Domain Name (FQDN) Conflicts among Dynamic Host
              Configuration Protocol (DHCP) Clients", RFC 4703,
              October 2006.



Hankins & Mrugalski                                            [Page 15]

                     ISC DHCP References Collection         January 2012


   [RFC5010]  Kinnear, K., Normoyle, M., and M. Stapp, "The Dynamic Host
              Configuration Protocol Version 4 (DHCPv4) Relay Agent
              Flags Suboption", RFC 5010, September 2007.

   [RFC5071]  Hankins, D., "Dynamic Host Configuration Protocol Options
              Used by PXELINUX", RFC 5071, December 2007.

   [RFC5107]  Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp,
              "DHCP Server Identifier Override Suboption", RFC 5107,
              February 2008.

   [RFC5192]  Morand, L., Yegin, A., Kumar, S., and S. Madanapalli,
              "DHCP Options for Protocol for Carrying Authentication for
              Network Access (PANA) Authentication Agents", RFC 5192,
              May 2008.

   [RFC5223]  Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
              Location-to-Service Translation (LoST) Servers Using the
              Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
              August 2008.

   [RFC5859]  Johnson, R., "TFTP Server Address Option for DHCPv4",
              RFC 5859, June 2010.

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd) -- Protocol Specification",
              RFC 5969, August 2010.

   [draft-failover]
              Droms, R., "DHCP Failover Protocol", March 2003.

   [I-D.ietf-dhc-dhcpv4-relay-encapsulation]
              Lemon, T. and H. Deng, "Relay Agent Encapsulation for
              DHCPv4", draft-ietf-dhc-dhcpv4-relay-encapsulation-00
              (work in progress), October 2010.

   [I-D.ietf-dhc-dhcpv4-bulk-leasequery]
              Kinnear, K., Volz, B., Russell, N., Stapp, M., Rao, D.,
              Joshi, B., and P. Kurapati, "Bulk DHCPv4 Lease Query",
              draft-ietf-dhc-dhcpv4-bulk-leasequery-03 (work in
              progress), October 2010.

   [I-D.ietf-dhc-leasequery-by-remote-id]
              Kurapati, P. and B. Joshi, "DHCPv4 lease query by Relay
              Agent Remote ID",
              draft-ietf-dhc-leasequery-by-remote-id-09 (work in
              progress), December 2010.




Hankins & Mrugalski                                            [Page 16]

                     ISC DHCP References Collection         January 2012


   [I-D.ietf-dhc-relay-id-suboption]
              Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption",
              draft-ietf-dhc-relay-id-suboption-07 (work in progress),
              July 2009.

   [I-D.ietf-mip6-hiopt]
              Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP
              Options for Home Information Discovery in MIPv6",
              draft-ietf-mip6-hiopt-17 (work in progress), May 2008.

7.2.  Published Common (DHCPv4/DHCPv6) References

   [RFC4280]  Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host
              Configuration Protocol (DHCP) Options for Broadcast and
              Multicast Control Servers", RFC 4280, November 2005.

   [RFC4477]  Chown, T., Venaas, S., and C. Strauf, "Dynamic Host
              Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack
              Issues", RFC 4477, May 2006.

   [RFC4578]  Johnston, M. and S. Venaas, "Dynamic Host Configuration
              Protocol (DHCP) Options for the Intel Preboot eXecution
              Environment (PXE)", RFC 4578, November 2006.

   [RFC4776]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic Addresses
              Configuration Information", RFC 4776, November 2006.

   [RFC4833]  Lear, E. and P. Eggert, "Timezone Options for DHCP",
              RFC 4833, April 2007.

   [RFC5417]  Calhoun, P., "Control And Provisioning of Wireless Access
              Points (CAPWAP) Access Controller DHCP Option", RFC 5417,
              March 2009.

   [RFC5678]  Bajko, G. and S. Das, "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility
              Services (MoS) Discovery", RFC 5678, December 2009.

   [RFC5908]  Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP)
              Server Option for DHCPv6", RFC 5908, June 2010.

   [RFC5970]  Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
              Options for Network Boot", RFC 5970, September 2010.

   [RFC5986]  Thomson, M. and J. Winterbottom, "Discovering the Local
              Location Information Server (LIS)", RFC 5986,
              September 2010.



Hankins & Mrugalski                                            [Page 17]

                     ISC DHCP References Collection         January 2012


   [I-D.ietf-dhc-vpn-option]
              Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet
              Selection Options for DHCPv4 and DHCPv6",
              draft-ietf-dhc-vpn-option-12 (work in progress),
              October 2010.

7.3.  Published DHCPv6 References

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3319]  Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
              Protocol (DHCPv6) Options for Session Initiation Protocol
              (SIP) Servers", RFC 3319, July 2003.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC3646]  Droms, R., "DNS Configuration options for Dynamic Host
              Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
              December 2003.

   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
              (DHCP) Service for IPv6", RFC 3736, April 2004.

   [RFC3898]  Kalusivalingam, V., "Network Information Service (NIS)
              Configuration Options for Dynamic Host Configuration
              Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.

   [RFC4075]  Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
              Configuration Option for DHCPv6", RFC 4075, May 2005.

   [RFC4076]  Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
              Requirements for Stateless Dynamic Host Configuration
              Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.

   [RFC4242]  Venaas, S., Chown, T., and B. Volz, "Information Refresh
              Time Option for Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 4242, November 2005.

   [RFC4580]  Volz, B., "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
              June 2006.

   [RFC4649]  Volz, B., "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,



Hankins & Mrugalski                                            [Page 18]

                     ISC DHCP References Collection         January 2012


              August 2006.

   [RFC4704]  Volz, B., "The Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
              Option", RFC 4704, October 2006.

   [RFC4994]  Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski,
              "DHCPv6 Relay Agent Echo Request Option", RFC 4994,
              September 2007.

   [RFC5007]  Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
              "DHCPv6 Leasequery", RFC 5007, September 2007.

   [RFC5453]  Krishnan, S., "Reserved IPv6 Interface Identifiers",
              RFC 5453, February 2009.

   [RFC5460]  Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
              February 2009.

   [I-D.ietf-mif-dhcpv6-route-option]
              Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6
              Route Options", draft-ietf-mif-dhcpv6-route-option-03
              (work in progress), September 2011.

   [I-D.ietf-dhc-dhcpv6-ldra]
              Miles, D., Ooghe, S., Dec, W., Krishnan, S., and A.
              Kavanagh, "Lightweight DHCPv6 Relay Agent",
              draft-ietf-dhc-dhcpv6-ldra-03 (work in progress),
              October 2010.

   [I-D.ietf-dhc-dhcpv6-relay-supplied-options]
              Lemon, T. and W. Wu, "Relay-Supplied DHCP Options",
              draft-ietf-dhc-dhcpv6-relay-supplied-options-09 (work in
              progress), September 2011.

   [I-D.ietf-dhc-pd-exclude]
              Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
              "Prefix Exclude Option for DHCPv6-based Prefix
              Delegation", draft-ietf-dhc-pd-exclude-01 (work in
              progress), January 2011.

   [I-D.ietf-dhc-secure-dhcpv6]
              Jiang, S., "Secure DHCPv6 Using CGAs",
              draft-ietf-dhc-secure-dhcpv6-02 (work in progress),
              December 2010.

   [I-D.ietf-mext-nemo-pd]
              Droms, R., Thubert, P., Dupont, F., Haddad, W., and C.



Hankins & Mrugalski                                            [Page 19]

                     ISC DHCP References Collection         January 2012


              Bernardos, "DHCPv6 Prefix Delegation for NEMO",
              draft-ietf-mext-nemo-pd-07 (work in progress),
              December 2010.

   [I-D.ietf-dhc-duid-uuid]
              Narten, T. and J. Johnson, "Definition of the UUID-based
              DHCPv6 Unique Identifier (DUID-UUID)",
              draft-ietf-dhc-duid-uuid-03 (work in progress),
              February 2011.

   [I-D.ietf-softwire-ds-lite-tunnel-option]
              Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
              Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite",
              draft-ietf-softwire-ds-lite-tunnel-option-10 (work in
              progress), March 2011.

   [I-D.ietf-mif-dns-server-selection]
              Savolainen, T. and J. Kato, "Improved DNS Server Selection
              for Multi-Homed Nodes",
              draft-ietf-mif-dns-server-selection-01 (work in progress),
              March 2011.

   [I-D.ietf-geopriv-rfc3825bis]
              Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic
              Host Configuration Protocol Options for Coordinate-based
              Location Configuration Information",
              draft-ietf-geopriv-rfc3825bis-17 (work in progress),
              February 2011.

   [draft-addr-params]
              Mrugalski, T., "Address Parameters Option for DHCPv6",
              April 2007.


Authors' Addresses

   David W. Hankins
   Internet Systems Consortium, Inc.
   950 Charter Street
   Redwood City, CA  94063











Hankins & Mrugalski                                            [Page 20]

                     ISC DHCP References Collection         January 2012


   Tomasz Mrugalski
   Internet Systems Consortium, Inc.
   950 Charter Street
   Redwood City, CA  94063

   Phone: +1 650 423 1345
   Email: Tomasz_Mrugalski@isc.org












































Hankins & Mrugalski                                            [Page 21]