4
ISC-DHCP-REFERENCES D. Hankins
9
ISC DHCP References Collection
14
Copyright (c) 2006-2007 by Internet Systems Consortium, Inc. ("ISC")
16
Permission to use, copy, modify, and distribute this software for any
17
purpose with or without fee is hereby granted, provided that the
18
above copyright notice and this permission notice appear in all
21
THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
22
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
23
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY
24
SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
25
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
26
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
27
OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
31
This document describes a collection of Reference material that ISC
32
DHCP has been implemented to.
57
ISC DHCP References Collection August 2006
62
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
64
2. Definition: Reference Implementation . . . . . . . . . . . . . 3
66
3. Low Layer References . . . . . . . . . . . . . . . . . . . . . 4
67
3.1. Ethernet Protocol References . . . . . . . . . . . . . . . 6
68
3.2. Token Ring Protocol References . . . . . . . . . . . . . . 6
69
3.3. FDDI Protocol References . . . . . . . . . . . . . . . . . 6
70
3.4. Internet Protocol Version 4 References . . . . . . . . . . 6
71
3.5. Unicast Datagram Protocol References . . . . . . . . . . . 6
73
4. BOOTP Protocol References . . . . . . . . . . . . . . . . . . 6
75
5. DHCP Protocol References . . . . . . . . . . . . . . . . . . . 7
76
5.1. DHCPv4 Protocol . . . . . . . . . . . . . . . . . . . . . 7
77
5.1.1. Core Protocol References . . . . . . . . . . . . . . . 7
78
5.2. DHCPv6 Protocol References . . . . . . . . . . . . . . . . 7
79
5.3. DHCP Option References . . . . . . . . . . . . . . . . . . 8
80
5.3.1. Relay Agent Information Option Options . . . . . . . . 10
81
5.3.2. Dynamic DNS Updates References . . . . . . . . . . . . 10
82
5.3.3. Experimental: Failover References . . . . . . . . . . 10
83
5.4. DHCP Procedures . . . . . . . . . . . . . . . . . . . . . 11
85
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
87
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
113
ISC DHCP References Collection August 2006
118
As a little historical anecdote, ISC DHCP once packaged all the
119
relevant RFCs and standards documents along with the software
120
package. Until one day when a voice was heard from one of the many
121
fine institutions that build and distribute this software... they
122
took issue with the IETF's copyright on the RFC's. It seems the
123
IETF's copyrights don't allow modification of RFC's (except for
124
translation purposes).
126
Our main purpose in providing the RFCs is to aid in documentation,
127
but since RFCs are now available widely from many points of
128
distribution on the Internet, there is no real need to provide the
129
documents themselves. So, this document has been created in their
130
stead, to list the various IETF RFCs one might want to read, and to
131
comment on how well (or poorly) we have managed to implement them.
134
2. Definition: Reference Implementation
136
ISC DHCP, much like its other cousins in ISC software, is self-
137
described as a 'Reference Implementation.' There has been a great
138
deal of confusion about this term. Some people seem to think that
139
this term applies to any software that once passed a piece of
140
reference material on its way to market (but may do quite a lot of
141
things that aren't described in any reference, or may choose to
142
ignore the reference it saw entirely). Other folks get confused by
143
the word 'reference' and understand that to mean that there is some
144
special status applied to the software - that the software itself is
145
the reference by which all other software is measured. Something
146
along the lines of being "The DHCP Protocol's Reference Clock," it is
149
The truth is actually quite a lot simpler. Reference implementations
150
are software packages which were written to behave precisely as
151
appears in reference material. They are written "to match
154
If the software has a behaviour that manifests itself externally
155
(whether it be something as simple as the 'wire format' or something
156
higher level, such as a complicated behaviour that arises from
157
multiple message exchanges), that behaviour must be found in a
160
Anything else is a bug, the only question is whether the bug is in
161
reference or software (failing to implement the reference).
169
ISC DHCP References Collection August 2006
172
o To produce new externally-visible behaviour, one must first
175
o Before changing externally visible behaviour to work around simple
176
incompatibilities in any other implementation, one must first
179
That is the lofty goal, at any rate. It's well understood that,
180
especially because the ISC DHCP Software package has not always been
181
held to this standard (but not entirely due to it), there are many
182
non-referenced behaviours within ISC DHCP.
184
The primary goal of reference implementation is to prove the
185
reference material. If the reference material is good, then you
186
should be able to sit down and write a program that implements the
187
reference, to the word, and come to an implementation that is
188
distinguishable from others in the details, but not in the facts of
189
operating the protocol. This means that there is no need for
190
'special knowledge' to work around arcane problems that were left
191
undocumented. No secret handshakes need to be learned to be imparted
192
with the necessary "real documentation".
194
Also, by accepting only reference as the guidebook for ISC DHCP's
195
software implementation, anyone who can make an impact on the color
196
texture or form of that reference has a (somewhat indirect) voice in
197
ISC DHCP's software design. As the IETF RFC's have been selected as
198
the source of reference, that means everyone on the Internet with the
199
will to participate has a say.
202
3. Low Layer References
204
It may surprise you to realize that ISC DHCP implements 802.1
205
'Ethernet' framing, Token Ring, and FDDI. In order to bridge the gap
206
there between these physical and DHCP layers, it must also implement
209
The reason for this stems from Unix systems' handling of BSD sockets
210
(the general way one might engage in transmission of UDP packets) on
211
unconfigured interfaces, or even the handling of broadcast addressing
212
on configured interfaces.
214
There are a few things that DHCP servers, relays, and clients all
215
need to do in order to speak the DHCP protocol in strict compliance
218
1. Transmit a UDP packet from IP:0.0.0.0 Ethernet:Self, destined to
219
IP:255.255.255.255 LinkLayer:Broadcast on an unconfigured (no IP
225
ISC DHCP References Collection August 2006
228
address yet) interface.
230
2. Receive a UDP packet from IP:remote-system LinkLayer:remote-
231
system, destined to IP:255.255.255.255 LinkLayer:Broadcast, again
232
on an unconfigured interface.
234
3. Transmit a UDP packet from IP:Self, Ethernet:Seelf, destined to
235
IP:remote-system LinkLayer:remote-system, without transmitting a
238
4. And of course the simple case, a regular IP unicast that is
239
routed via the usual means (so it may be direct to a local
240
system, with ARP providing the glue, or it may be to a remote
241
system via one or more routers as normal). In this case, the
242
interfaces are always configured.
244
The above isn't as simple as it sounds on a regular BSD socket. Many
245
unix implementations will transmit broadcasts not to 255.255.255.255,
246
but to x.y.z.255 (where x.y.z is the system's local subnet). Such
247
packets are not received by several known DHCP client implementations
248
- and it's not their fault, RFC2131 [8] very explicitly demands that
249
these packets' IP destination addresses be set to 255.255.255.255.
251
Receiving packets sent to 255.255.255.255 isn't a problem on most
252
modern unixes...so long as the interface is configured. When there
253
is no IPv4 address on the interface, things become much more murky.
255
So, for this convoluted and unfortunate state of affairs in the unix
256
systems of the day ISC DHCP was manufactured, in order to do what it
257
needs not only to implement the reference but to interoperate with
258
other implementations, the software must create some form of raw
259
socket to operate on.
261
What it actually does is create, for each interface detected on the
262
system, a Berkeley Packet Filter socket (or equivalent), and program
263
it with a filter that brings in only DHCP packets. A "fallback" UDP
264
Berkeley socket is generally also created, a single one no matter how
265
many interfaces. Should the software need to transmit a contrived
266
packet to the local network the packet is formed piece by piece and
267
transmitted via the BPF socket. Hence the need to implement many
268
forms of Link Layer framing and above. The software gets away with
269
not having to implement IP routing tables as well by simply utilizing
270
the aforementioned 'fallback' UDP socket when unicasting between two
271
configured systems is the need.
273
Modern unixes have opened up some facilities that diminish how much
274
of this sort of nefarious kludgery is necessary, but have not found
275
the state of affairs absolutely absolved. In particular, one might
281
ISC DHCP References Collection August 2006
284
now unicast without ARP by inserting an entry into the ARP cache
285
prior to transmitting. Unconfigured interfaces remain the sticking
286
point, however...on virtually no modern unixes is it possible to
287
receive broadcast packets unless a local IPv4 address has been
288
configured, unless it is done with raw sockets.
290
3.1. Ethernet Protocol References
292
ISC DHCP Implements Ethernet Version 2 ("DIX"), which is a variant of
293
IEEE 802.2. No good reference of this framing is known to exist at
294
this time, but it is vaguely described in RFC894 [3] (see the section
295
titled "Packet format"), and the following URL is also thought to be
298
http://en.wikipedia.org/wiki/DIX
300
3.2. Token Ring Protocol References
302
IEEE 802.5 defines the Token Ring framing format used by ISC DHCP.
304
3.3. FDDI Protocol References
306
RFC1188 [6] is the most helpful reference ISC DHCP has used to form
309
3.4. Internet Protocol Version 4 References
311
RFC760 [1] fundamentally defines the bare IPv4 protocol which ISC
314
3.5. Unicast Datagram Protocol References
316
RFC768 [2] defines the User Datagram Protocol that ultimately carries
317
the DHCP or BOOTP protocol. The destination DHCP server port is 67,
318
the client port is 68. Source ports are irrelevant.
321
4. BOOTP Protocol References
323
The DHCP Protocol is strange among protocols in that it is grafted
324
over the top of another protocol - BOOTP (but we don't call it "DHCP
325
over BOOTP" like we do, say "TCP over IP"). BOOTP and DHCP share UDP
326
packet formats - DHCP is merely a conventional use of both BOOTP
327
header fields and the trailing 'options' space.
329
The ISC DHCP server supports BOOTP clients conforming to RFC951 [4]
337
ISC DHCP References Collection August 2006
340
5. DHCP Protocol References
344
"The DHCP[v4] Protocol" is not defined in a single document. The
345
following collection of references of what ISC DHCP terms "The DHCPv4
348
5.1.1. Core Protocol References
350
RFC2131 [8] defines the protocol format and procedures. ISC DHCP is
351
not known to diverge from this document in any way. There are,
352
however, a few points on which different implementations have arisen
353
out of vagueries in the document. DHCP Clients exist which, at one
354
time, present themselves as using a Client Identifier Option which is
355
equal to the client's hardware address. Later, the client transmits
356
DHCP packets with no Client Identifier Option present - essentially
357
identifying themselves using the hardware address. Some DHCP Servers
358
have been developed which identify this client as a single client.
359
ISC has interpreted RFC2131 to indicate that these clients must be
360
treated as two separate entities (and hence two, separate addresses).
361
Client behaviour (Embedded Windows products) has developed that
362
relies on the former implementation, and hence is incompatible with
363
the latter. Also, RFC2131 demands explicitly that some header fields
364
be zeroed upon certain message types. The ISC DHCP Server instead
365
copies many of these fields from the packet received from the client
366
or relay, which may not be zero. It is not known if there is a good
367
reason for this that has not been documented.
369
RFC2132 [9] defines the initial set of DHCP Options and provides a
370
great deal of guidance on how to go about formatting and processing
371
options. The document unfortunately waffles to a great extent about
372
the NULL termination of DHCP Options, and some DHCP Clients (Windows
373
95) have been implemented that rely upon DHCP Options containing text
374
strings to be NULL-terminated (or else they crash). So, ISC DHCP
375
detects if clients null-terminate the host-name option and, if so,
376
null terminates any text options it transmits to the client. It also
377
removes NULL termination from any known text option it receives prior
378
to any other processing.
380
5.2. DHCPv6 Protocol References
382
For now there is only one document that specifies the DHCPv6 protocol
383
(there have been no updates yet), RFC3315 [21].
385
Support for DHCPv6 was added first in version 4.0.0. The server and
386
client support only IA_NA. While the server does support multiple
387
IA_NAs within one packet from the client, our client only supports
393
ISC DHCP References Collection August 2006
396
sending one. There is no relay support.
398
DHCPv6 introduces some new and uncomfortable ideas to the common
401
1. Options of zero length are normal in DHCPv6. Currently, all ISC
402
DHCP software treats zero-length options as errors.
404
2. Options sometimes may appear multiple times. The common library
405
used to treat all appearance of multiple options as specified in
406
RFC2131 - to be concatenated. DHCPv6 options may sometimes
407
appear multiple times (such as with IA_NA or IAADDR), but often
410
3. The same option space appears in DHCPv6 packets multiple times.
411
If the packet was got via a relay, then the client's packet is
412
stored to an option within the relay's packet...if there were two
413
relays, this recurses. At each of these steps, the root "DHCPv6
414
option space" is used. Further, a client packet may contain an
415
IA_NA, which may contain an IAADDR - but really, in an abstract
416
sense, this is again re-encapsulation of the DHCPv6 option space
417
beneath options it also contains.
419
Precisely how to correctly support the above conundrums has not quite
420
yet been settled, so support is incomplete.
422
5.3. DHCP Option References
424
RFC2241 [10] defines options for Novell Directory Services.
426
RFC2242 [11] defines an encapsulated option space for NWIP
429
RFC2485 [12] defines the Open Group's UAP option.
431
RFC2610 [13] defines options for the Service Location Protocol (SLP).
433
RFC2937 [14] defines the Name Service Search Option (not to be
434
confused with the domain-search option). The Name Service Search
435
Option allows eg nsswitch.conf to be reconfigured via dhcp. The ISC
436
DHCP server implements this option, and the ISC DHCP client is
437
compatible...but does not by default install this option's value.
438
One would need to make their relevant dhclient-script process this
439
option in a way that is suitable for the system.
441
RFC3004 [16] defines the User-Class option. Note carefully that ISC
442
DHCP currently does not implement to this reference, but has
443
(inexplicably) selected an incompatible format: a plain text string.
449
ISC DHCP References Collection August 2006
452
RFC3011 [17] defines the Subnet-Selection plain DHCPv4 option. Do
453
not confuse this option with the relay agent "link selection" sub-
454
option, although their behaviour is similar.
456
RFC3319 [22] defines the SIP server options for DHCPv6.
458
RFC3396 [23] documents both how long options may be encoded in DHCPv4
459
packets, and also how multiple instances of the same option code
460
within a DHCPv4 packet will be decoded by receivers.
462
RFC3397 [24] documents the Domain-Search Option, which allows the
463
configuration of the /etc/resolv.conf 'search' parameter in a way
464
that is RFC1035 [5] wire format compatible (in fact, it uses the
465
RFC1035 wire format). ISC DHCP has both client and server support,
466
and supports RFC1035 name compression.
468
RFC3646 [27] documents the DHCPv6 name-servers and domain-search
471
RFC3633 [26] documents the Identity Association Prefix Delegation,
472
which is included here for protocol wire reference, but which is not
473
supported by ISC DHCP.
475
RFC3679 [28] documents a number of options that were documented
476
earlier in history, but were not made use of.
478
RFC3898 [29] documents four NIS options for delivering NIS servers
479
and domain information in DHCPv6.
481
RFC3925 [30] documents a pair of Enterprise-ID delimited option
482
spaces for vendors to use in order to inform servers of their "vendor
483
class" (sort of like 'uname' or 'who and what am I'), and a means to
484
deliver vendor-specific and vendor-documented option codes and
487
RFC3942 [31] redefined the 'site local' option space.
489
RFC4075 [32] defines the DHCPv6 SNTP Servers option.
491
RFC4242 [33] defines the Information Refresh Time option, which
492
advises DHCPv6 Information-Request clients to return for updated
495
RFC4280 [34] defines two BCMS server options.
497
RFC4388 [35] defined the DHCPv4 LEASEQUERY message type and a number
498
of suitable response messages, for the purpose of sharing information
499
about DHCP served addresses and clients.
505
ISC DHCP References Collection August 2006
508
RFC4580> [36] defines a DHCPv6 subscriber-id option, which is similar
509
in principle to the DHCPv4 relay agent option of the same name.
511
RFC4649 [37] defines a DHCPv6 remote-id option, which is similar in
512
principle to the DHCPv4 relay agent remote-id.
514
5.3.1. Relay Agent Information Option Options
516
RFC3046 [18] defines the Relay Agent Information Option and provides
517
a number of sub-option definitions.
519
RFC3256 [20] defines the DOCSIS Device Class sub-option.
521
RFC3527 [25] defines the Link Selection sub-option.
523
5.3.2. Dynamic DNS Updates References
525
The collection of documents that describe the standards-based method
526
to update dns names of DHCP clients starts most easily with RFC4703
527
[40] to define the overall architecture, travels through RFCs 4702
528
[39] and 4704 [41] to describe the DHCPv4 and DHCPv6 FQDN options (to
529
carry the client name), and ends up at RFC4701 [38] which describes
530
the DHCID RR used in DNS to perform a kind of atomic locking.
532
ISC DHCP adoped early versions of these documents, and has not yet
533
synched up with the final standards versions.
535
For RFCs 4702 and 4704, the 'N' bit is not yet supported. The result
536
is that it is always set zero, and is ignored if set.
538
For RFC4701, which is used to match client identities with names in
539
the DNS as part of name conflict resolution. Note that ISC DHCP's
540
implementation of DHCIDs vary wildly from this specification. First,
541
ISC DHCP uses a TXT record in which the contents are stored in
542
hexadecimal. Second, there is a flaw in the selection of the
543
'Identifier Type', which results in a completely different value
544
being selected than was defined in an older revision of this
545
document...also this field is one byte prior to hexadecimal encoding
546
rather than two. Third, ISC DHCP does not use a digest type code.
547
Rather, all values for such TXT records are reached via an MD5 sum.
548
In short, nothing is compatible, but the principle of the TXT record
549
is the same as the standard DHCID record. However, for DHCPv6 FQDN,
550
we do use DHCID type code '2', as no other value really makes sense
553
5.3.3. Experimental: Failover References
555
The Failover Protocol defines a means by which two DHCP Servers can
561
ISC DHCP References Collection August 2006
564
share all the relevant information about leases granted to DHCP
565
clients on given networks, so that one of the two servers may fail
566
and be survived by a server that can act responsibly.
568
Unfortunately it has been quite some years since the last time this
569
document was edited, and the authors no longer show any interest in
570
fielding comments or improving the document.
572
The status of this protocol is very unsure, but ISC's implementation
573
of it has proven stable and suitable for use in sizable production
576
draft-ietf-dhc-failover-12.txt [42] describes the Failover Protocol.
577
In addition to what is described in this document, ISC DHCP has
578
elected to make some experimental changes that may be revoked in a
579
future version of ISC DHCP (if the draft authors do not adopt the new
580
behaviour). Specifically, ISC DHCP's POOLREQ behaviour differs
581
substantially from what is documented in the draft, and the server
582
also implements a form of 'MAC Address Affinity' which is not
583
described in the failover document. The full nature of these changes
584
have been described on the IETF DHC WG mailing list (which has
585
archives), and also in ISC DHCP's manual pages. Also note that
586
although this document references a RECOVER-WAIT state, it does not
587
document a protocol number assignment for this state. As a
588
consequence, ISC DHCP has elected to use the value 254.
590
RFC3074 [19] describes the Load Balancing Algorithm (LBA) that ISC
591
DHCP uses in concert with the Failover protocol. Note that versions
592
3.0.* are known to misimplement the hash algorithm (it will only use
593
the low 4 bits of every byte of the hash bucket array).
597
RFC2939 [15] explains how to go about obtaining a new DHCP Option
602
[1] Postel, J., "DoD standard Internet Protocol", RFC 760,
605
[2] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
608
[3] Hornig, C., "Standard for the transmission of IP datagrams over
609
Ethernet networks", STD 41, RFC 894, April 1984.
611
[4] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951,
617
ISC DHCP References Collection August 2006
622
[5] Mockapetris, P., "Domain names - implementation and
623
specification", STD 13, RFC 1035, November 1987.
625
[6] Katz, D., "Proposed Standard for the Transmission of IP
626
Datagrams over FDDI Networks", RFC 1188, October 1990.
628
[7] Wimer, W., "Clarifications and Extensions for the Bootstrap
629
Protocol", RFC 1542, October 1993.
631
[8] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
634
[9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
635
Extensions", RFC 2132, March 1997.
637
[10] Provan, D., "DHCP Options for Novell Directory Services",
638
RFC 2241, November 1997.
640
[11] Droms, R. and K. Fong, "NetWare/IP Domain Name and
641
Information", RFC 2242, November 1997.
643
[12] Drach, S., "DHCP Option for The Open Group's User
644
Authentication Protocol", RFC 2485, January 1999.
646
[13] Perkins, C. and E. Guttman, "DHCP Options for Service Location
647
Protocol", RFC 2610, June 1999.
649
[14] Smith, C., "The Name Service Search Option for DHCP", RFC 2937,
652
[15] Droms, R., "Procedures and IANA Guidelines for Definition of
653
New DHCP Options and Message Types", BCP 43, RFC 2939,
656
[16] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, A.,
657
Beser, B., and J. Privat, "The User Class Option for DHCP",
658
RFC 3004, November 2000.
660
[17] Waters, G., "The IPv4 Subnet Selection Option for DHCP",
661
RFC 3011, November 2000.
663
[18] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
666
[19] Volz, B., Gonczi, S., Lemon, T., and R. Stevens, "DHC Load
667
Balancing Algorithm", RFC 3074, February 2001.
673
ISC DHCP References Collection August 2006
676
[20] Jones, D. and R. Woundy, "The DOCSIS (Data-Over-Cable Service
677
Interface Specifications) Device Class DHCP (Dynamic Host
678
Configuration Protocol) Relay Agent Information Sub-option",
679
RFC 3256, April 2002.
681
[21] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
682
Carney, "Dynamic Host Configuration Protocol for IPv6
683
(DHCPv6)", RFC 3315, July 2003.
685
[22] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
686
Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
687
Servers", RFC 3319, July 2003.
689
[23] Lemon, T. and S. Cheshire, "Encoding Long Options in the
690
Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
693
[24] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol
694
(DHCP) Domain Search Option", RFC 3397, November 2002.
696
[25] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, "Link
697
Selection sub-option for the Relay Agent Information Option for
698
DHCPv4", RFC 3527, April 2003.
700
[26] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
701
Configuration Protocol (DHCP) version 6", RFC 3633,
704
[27] Droms, R., "DNS Configuration options for Dynamic Host
705
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
708
[28] Droms, R., "Unused Dynamic Host Configuration Protocol (DHCP)
709
Option Codes", RFC 3679, January 2004.
711
[29] Kalusivalingam, V., "Network Information Service (NIS)
712
Configuration Options for Dynamic Host Configuration Protocol
713
for IPv6 (DHCPv6)", RFC 3898, October 2004.
715
[30] Littlefield, J., "Vendor-Identifying Vendor Options for Dynamic
716
Host Configuration Protocol version 4 (DHCPv4)", RFC 3925,
719
[31] Volz, B., "Reclassifying Dynamic Host Configuration Protocol
720
version 4 (DHCPv4) Options", RFC 3942, November 2004.
722
[32] Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
723
Configuration Option for DHCPv6", RFC 4075, May 2005.
729
ISC DHCP References Collection August 2006
732
[33] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time
733
Option for Dynamic Host Configuration Protocol for IPv6
734
(DHCPv6)", RFC 4242, November 2005.
736
[34] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host
737
Configuration Protocol (DHCP) Options for Broadcast and
738
Multicast Control Servers", RFC 4280, November 2005.
740
[35] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol
741
(DHCP) Leasequery", RFC 4388, February 2006.
743
[36] Volz, B., "Dynamic Host Configuration Protocol for IPv6
744
(DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
747
[37] Volz, B., "Dynamic Host Configuration Protocol for IPv6
748
(DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 2006.
750
[38] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource Record
751
(RR) for Encoding Dynamic Host Configuration Protocol (DHCP)
752
Information (DHCID RR)", RFC 4701, October 2006.
754
[39] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
755
Configuration Protocol (DHCP) Client Fully Qualified Domain
756
Name (FQDN) Option", RFC 4702, October 2006.
758
[40] Stapp, M. and B. Volz, "Resolution of Fully Qualified Domain
759
Name (FQDN) Conflicts among Dynamic Host Configuration Protocol
760
(DHCP) Clients", RFC 4703, October 2006.
762
[41] Volz, B., "The Dynamic Host Configuration Protocol for IPv6
763
(DHCPv6) Client Fully Qualified Domain Name (FQDN) Option",
764
RFC 4704, October 2006.
766
[42] Droms, R., "DHCP Failover Protocol", March 2003.
785
ISC DHCP References Collection August 2006
791
Internet Systems Consortium, Inc.
793
Redwood City, CA 94063
795
Phone: +1 650 423 1300
796
Email: David_Hankins@isc.org
added
removed
doc/References.txt
