Annotation of embedaddon/dhcp/doc/References.txt, revision 1.1.1.1
1.1 misho 1:
2:
3:
4: ISC-DHCP-REFERENCES D. Hankins
5: ISC
6: May 2007
7:
8:
9: ISC DHCP References Collection
10:
11: Copyright Notice
12:
13: Copyright (c) 2006-2007,2009 by Internet Systems Consortium, Inc.
14: ("ISC")
15:
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
19: copies.
20:
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.
28:
29: Abstract
30:
31: This document describes a collection of Reference material that ISC
32: DHCP has been implemented to.
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55: Hankins [Page 1]
56:
57: ISC DHCP References Collection May 2007
58:
59:
60: Table of Contents
61:
62: 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
63:
64: 2. Definition: Reference Implementation . . . . . . . . . . . . . 3
65:
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
72:
73: 4. BOOTP Protocol References . . . . . . . . . . . . . . . . . . 6
74:
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 . . . . . . . . . . 11
83: 5.4. DHCP Procedures . . . . . . . . . . . . . . . . . . . . . 11
84:
85: 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
86:
87: Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
88:
89:
90:
91:
92:
93:
94:
95:
96:
97:
98:
99:
100:
101:
102:
103:
104:
105:
106:
107:
108:
109:
110:
111: Hankins [Page 2]
112:
113: ISC DHCP References Collection May 2007
114:
115:
116: 1. Introduction
117:
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).
125:
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.
132:
133:
134: 2. Definition: Reference Implementation
135:
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
147: supposed.
148:
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
152: reference."
153:
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
158: reference document.
159:
160: Anything else is a bug, the only question is whether the bug is in
161: reference or software (failing to implement the reference).
162:
163: This means:
164:
165:
166:
167: Hankins [Page 3]
168:
169: ISC DHCP References Collection May 2007
170:
171:
172: o To produce new externally-visible behaviour, one must first
173: provide a reference.
174:
175: o Before changing externally visible behaviour to work around simple
176: incompatibilities in any other implementation, one must first
177: provide a reference.
178:
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.
183:
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".
193:
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.
200:
201:
202: 3. Low Layer References
203:
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
207: IP and UDP framing.
208:
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.
213:
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
216: with RFC2131 [RFC2131].
217:
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
220:
221:
222:
223: Hankins [Page 4]
224:
225: ISC DHCP References Collection May 2007
226:
227:
228: address yet) interface.
229:
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.
233:
234: 3. Transmit a UDP packet from IP:Self, Ethernet:Seelf, destined to
235: IP:remote-system LinkLayer:remote-system, without transmitting a
236: single ARP.
237:
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.
243:
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 [RFC2131] very explicitly demands
249: that these packets' IP destination addresses be set to
250: 255.255.255.255.
251:
252: Receiving packets sent to 255.255.255.255 isn't a problem on most
253: modern unixes...so long as the interface is configured. When there
254: is no IPv4 address on the interface, things become much more murky.
255:
256: So, for this convoluted and unfortunate state of affairs in the unix
257: systems of the day ISC DHCP was manufactured, in order to do what it
258: needs not only to implement the reference but to interoperate with
259: other implementations, the software must create some form of raw
260: socket to operate on.
261:
262: What it actually does is create, for each interface detected on the
263: system, a Berkeley Packet Filter socket (or equivalent), and program
264: it with a filter that brings in only DHCP packets. A "fallback" UDP
265: Berkeley socket is generally also created, a single one no matter how
266: many interfaces. Should the software need to transmit a contrived
267: packet to the local network the packet is formed piece by piece and
268: transmitted via the BPF socket. Hence the need to implement many
269: forms of Link Layer framing and above. The software gets away with
270: not having to implement IP routing tables as well by simply utilizing
271: the aforementioned 'fallback' UDP socket when unicasting between two
272: configured systems is the need.
273:
274: Modern unixes have opened up some facilities that diminish how much
275: of this sort of nefarious kludgery is necessary, but have not found
276:
277:
278:
279: Hankins [Page 5]
280:
281: ISC DHCP References Collection May 2007
282:
283:
284: the state of affairs absolutely absolved. In particular, one might
285: now unicast without ARP by inserting an entry into the ARP cache
286: prior to transmitting. Unconfigured interfaces remain the sticking
287: point, however...on virtually no modern unixes is it possible to
288: receive broadcast packets unless a local IPv4 address has been
289: configured, unless it is done with raw sockets.
290:
291: 3.1. Ethernet Protocol References
292:
293: ISC DHCP Implements Ethernet Version 2 ("DIX"), which is a variant of
294: IEEE 802.2. No good reference of this framing is known to exist at
295: this time, but it is vaguely described in RFC894 [RFC0894] (see the
296: section titled "Packet format"), and the following URL is also
297: thought to be useful.
298:
299: http://en.wikipedia.org/wiki/DIX
300:
301: 3.2. Token Ring Protocol References
302:
303: IEEE 802.5 defines the Token Ring framing format used by ISC DHCP.
304:
305: 3.3. FDDI Protocol References
306:
307: RFC1188 [RFC1188] is the most helpful reference ISC DHCP has used to
308: form FDDI packets.
309:
310: 3.4. Internet Protocol Version 4 References
311:
312: RFC760 [RFC0760] fundamentally defines the bare IPv4 protocol which
313: ISC DHCP implements.
314:
315: 3.5. Unicast Datagram Protocol References
316:
317: RFC768 [RFC0768] defines the User Datagram Protocol that ultimately
318: carries the DHCP or BOOTP protocol. The destination DHCP server port
319: is 67, the client port is 68. Source ports are irrelevant.
320:
321:
322: 4. BOOTP Protocol References
323:
324: The DHCP Protocol is strange among protocols in that it is grafted
325: over the top of another protocol - BOOTP (but we don't call it "DHCP
326: over BOOTP" like we do, say "TCP over IP"). BOOTP and DHCP share UDP
327: packet formats - DHCP is merely a conventional use of both BOOTP
328: header fields and the trailing 'options' space.
329:
330: The ISC DHCP server supports BOOTP clients conforming to RFC951
331: [RFC0951] and RFC1542 [RFC1542].
332:
333:
334:
335: Hankins [Page 6]
336:
337: ISC DHCP References Collection May 2007
338:
339:
340: 5. DHCP Protocol References
341:
342: 5.1. DHCPv4 Protocol
343:
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
346: Protocol".
347:
348: 5.1.1. Core Protocol References
349:
350: RFC2131 [RFC2131] defines the protocol format and procedures. ISC
351: DHCP is not known to diverge from this document in any way. There
352: are, however, a few points on which different implementations have
353: arisen out of vagueries in the document. DHCP Clients exist which,
354: at one time, present themselves as using a Client Identifier Option
355: which is equal to the client's hardware address. Later, the client
356: transmits DHCP packets with no Client Identifier Option present -
357: essentially identifying themselves using the hardware address. Some
358: DHCP Servers have been developed which identify this client as a
359: single client. ISC has interpreted RFC2131 to indicate that these
360: clients must be treated as two separate entities (and hence two,
361: separate addresses). Client behaviour (Embedded Windows products)
362: has developed that relies on the former implementation, and hence is
363: incompatible with the latter. Also, RFC2131 demands explicitly that
364: some header fields be zeroed upon certain message types. The ISC
365: DHCP Server instead copies many of these fields from the packet
366: received from the client or relay, which may not be zero. It is not
367: known if there is a good reason for this that has not been
368: documented.
369:
370: RFC2132 [RFC2132] defines the initial set of DHCP Options and
371: provides a great deal of guidance on how to go about formatting and
372: processing options. The document unfortunately waffles to a great
373: extent about the NULL termination of DHCP Options, and some DHCP
374: Clients (Windows 95) have been implemented that rely upon DHCP
375: Options containing text strings to be NULL-terminated (or else they
376: crash). So, ISC DHCP detects if clients null-terminate the host-name
377: option and, if so, null terminates any text options it transmits to
378: the client. It also removes NULL termination from any known text
379: option it receives prior to any other processing.
380:
381: 5.2. DHCPv6 Protocol References
382:
383: For now there is only one document that specifies the DHCPv6 protocol
384: (there have been no updates yet), RFC3315 [RFC3315].
385:
386: Support for DHCPv6 was added first in version 4.0.0. The server and
387: client support only IA_NA. While the server does support multiple
388:
389:
390:
391: Hankins [Page 7]
392:
393: ISC DHCP References Collection May 2007
394:
395:
396: IA_NAs within one packet from the client, our client only supports
397: sending one. There is no relay support.
398:
399: DHCPv6 introduces some new and uncomfortable ideas to the common
400: software library.
401:
402: 1. Options of zero length are normal in DHCPv6. Currently, all ISC
403: DHCP software treats zero-length options as errors.
404:
405: 2. Options sometimes may appear multiple times. The common library
406: used to treat all appearance of multiple options as specified in
407: RFC2131 - to be concatenated. DHCPv6 options may sometimes
408: appear multiple times (such as with IA_NA or IAADDR), but often
409: must not.
410:
411: 3. The same option space appears in DHCPv6 packets multiple times.
412: If the packet was got via a relay, then the client's packet is
413: stored to an option within the relay's packet...if there were two
414: relays, this recurses. At each of these steps, the root "DHCPv6
415: option space" is used. Further, a client packet may contain an
416: IA_NA, which may contain an IAADDR - but really, in an abstract
417: sense, this is again re-encapsulation of the DHCPv6 option space
418: beneath options it also contains.
419:
420: Precisely how to correctly support the above conundrums has not quite
421: yet been settled, so support is incomplete.
422:
423: 5.3. DHCP Option References
424:
425: RFC2241 [RFC2241] defines options for Novell Directory Services.
426:
427: RFC2242 [RFC2242] defines an encapsulated option space for NWIP
428: configuration.
429:
430: RFC2485 [RFC2485] defines the Open Group's UAP option.
431:
432: RFC2610 [RFC2610] defines options for the Service Location Protocol
433: (SLP).
434:
435: RFC2937 [RFC2937] defines the Name Service Search Option (not to be
436: confused with the domain-search option). The Name Service Search
437: Option allows eg nsswitch.conf to be reconfigured via dhcp. The ISC
438: DHCP server implements this option, and the ISC DHCP client is
439: compatible...but does not by default install this option's value.
440: One would need to make their relevant dhclient-script process this
441: option in a way that is suitable for the system.
442:
443: RFC3004 [RFC3004] defines the User-Class option. Note carefully that
444:
445:
446:
447: Hankins [Page 8]
448:
449: ISC DHCP References Collection May 2007
450:
451:
452: ISC DHCP currently does not implement to this reference, but has
453: (inexplicably) selected an incompatible format: a plain text string.
454:
455: RFC3011 [RFC3011] defines the Subnet-Selection plain DHCPv4 option.
456: Do not confuse this option with the relay agent "link selection" sub-
457: option, although their behaviour is similar.
458:
459: RFC3319 [RFC3319] defines the SIP server options for DHCPv6.
460:
461: RFC3396 [RFC3396] documents both how long options may be encoded in
462: DHCPv4 packets, and also how multiple instances of the same option
463: code within a DHCPv4 packet will be decoded by receivers.
464:
465: RFC3397 [RFC3397] documents the Domain-Search Option, which allows
466: the configuration of the /etc/resolv.conf 'search' parameter in a way
467: that is RFC1035 [RFC1035] wire format compatible (in fact, it uses
468: the RFC1035 wire format). ISC DHCP has both client and server
469: support, and supports RFC1035 name compression.
470:
471: RFC3646 [RFC3646] documents the DHCPv6 name-servers and domain-search
472: options.
473:
474: RFC3633 [RFC3633] documents the Identity Association Prefix
475: Delegation, which is included here for protocol wire reference, but
476: which is not supported by ISC DHCP.
477:
478: RFC3679 [RFC3679] documents a number of options that were documented
479: earlier in history, but were not made use of.
480:
481: RFC3898 [RFC3898] documents four NIS options for delivering NIS
482: servers and domain information in DHCPv6.
483:
484: RFC3925 [RFC3925] documents a pair of Enterprise-ID delimited option
485: spaces for vendors to use in order to inform servers of their "vendor
486: class" (sort of like 'uname' or 'who and what am I'), and a means to
487: deliver vendor-specific and vendor-documented option codes and
488: values.
489:
490: RFC3942 [RFC3942] redefined the 'site local' option space.
491:
492: RFC4075 [RFC4075] defines the DHCPv6 SNTP Servers option.
493:
494: RFC4242 [RFC4242] defines the Information Refresh Time option, which
495: advises DHCPv6 Information-Request clients to return for updated
496: information.
497:
498: RFC4280 [RFC4280] defines two BCMS server options.
499:
500:
501:
502:
503: Hankins [Page 9]
504:
505: ISC DHCP References Collection May 2007
506:
507:
508: RFC4388 [RFC4388] defined the DHCPv4 LEASEQUERY message type and a
509: number of suitable response messages, for the purpose of sharing
510: information about DHCP served addresses and clients.
511:
512: RFC4580 [RFC4580] defines a DHCPv6 subscriber-id option, which is
513: similar in principle to the DHCPv4 relay agent option of the same
514: name.
515:
516: RFC4649 [RFC4649] defines a DHCPv6 remote-id option, which is similar
517: in principle to the DHCPv4 relay agent remote-id.
518:
519: 5.3.1. Relay Agent Information Option Options
520:
521: RFC3046 [RFC3046] defines the Relay Agent Information Option and
522: provides a number of sub-option definitions.
523:
524: RFC3256 [RFC3256] defines the DOCSIS Device Class sub-option.
525:
526: RFC3527 [RFC3527] defines the Link Selection sub-option.
527:
528: 5.3.2. Dynamic DNS Updates References
529:
530: The collection of documents that describe the standards-based method
531: to update dns names of DHCP clients starts most easily with RFC4703
532: [RFC4703] to define the overall architecture, travels through RFCs
533: 4702 [RFC4702] and 4704 [RFC4704] to describe the DHCPv4 and DHCPv6
534: FQDN options (to carry the client name), and ends up at RFC4701
535: [RFC4701] which describes the DHCID RR used in DNS to perform a kind
536: of atomic locking.
537:
538: ISC DHCP adopted early versions of these documents, and has not yet
539: synchronized with the final standards versions.
540:
541: For RFCs 4702 and 4704, the 'N' bit is not yet supported. The result
542: is that it is always set zero, and is ignored if set.
543:
544: For RFC4701, which is used to match client identities with names in
545: the DNS as part of name conflict resolution. Note that ISC DHCP's
546: implementation of DHCIDs vary wildly from this specification. First,
547: ISC DHCP uses a TXT record in which the contents are stored in
548: hexadecimal. Second, there is a flaw in the selection of the
549: 'Identifier Type', which results in a completely different value
550: being selected than was defined in an older revision of this
551: document...also this field is one byte prior to hexadecimal encoding
552: rather than two. Third, ISC DHCP does not use a digest type code.
553: Rather, all values for such TXT records are reached via an MD5 sum.
554: In short, nothing is compatible, but the principle of the TXT record
555: is the same as the standard DHCID record. However, for DHCPv6 FQDN,
556:
557:
558:
559: Hankins [Page 10]
560:
561: ISC DHCP References Collection May 2007
562:
563:
564: we do use DHCID type code '2', as no other value really makes sense
565: in our context.
566:
567: 5.3.3. Experimental: Failover References
568:
569: The Failover Protocol defines a means by which two DHCP Servers can
570: share all the relevant information about leases granted to DHCP
571: clients on given networks, so that one of the two servers may fail
572: and be survived by a server that can act responsibly.
573:
574: Unfortunately it has been quite some years since the last time this
575: document was edited, and the authors no longer show any interest in
576: fielding comments or improving the document.
577:
578: The status of this protocol is very unsure, but ISC's implementation
579: of it has proven stable and suitable for use in sizable production
580: environments.
581:
582: draft-ietf-dhc-failover-12.txt [draft-failover] describes the
583: Failover Protocol. In addition to what is described in this
584: document, ISC DHCP has elected to make some experimental changes that
585: may be revoked in a future version of ISC DHCP (if the draft authors
586: do not adopt the new behaviour). Specifically, ISC DHCP's POOLREQ
587: behaviour differs substantially from what is documented in the draft,
588: and the server also implements a form of 'MAC Address Affinity' which
589: is not described in the failover document. The full nature of these
590: changes have been described on the IETF DHC WG mailing list (which
591: has archives), and also in ISC DHCP's manual pages. Also note that
592: although this document references a RECOVER-WAIT state, it does not
593: document a protocol number assignment for this state. As a
594: consequence, ISC DHCP has elected to use the value 254.
595:
596: RFC3074 [RFC3074] describes the Load Balancing Algorithm (LBA) that
597: ISC DHCP uses in concert with the Failover protocol. Note that
598: versions 3.0.* are known to misimplement the hash algorithm (it will
599: only use the low 4 bits of every byte of the hash bucket array).
600:
601: 5.4. DHCP Procedures
602:
603: RFC2939 [RFC2939] explains how to go about obtaining a new DHCP
604: Option code assignment.
605:
606:
607: 6. References
608:
609: [RFC0760] Postel, J., "DoD standard Internet Protocol", RFC 760,
610: January 1980.
611:
612:
613:
614:
615: Hankins [Page 11]
616:
617: ISC DHCP References Collection May 2007
618:
619:
620: [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
621: August 1980.
622:
623: [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams
624: over Ethernet networks", STD 41, RFC 894, April 1984.
625:
626: [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951,
627: September 1985.
628:
629: [RFC1035] Mockapetris, P., "Domain names - implementation and
630: specification", STD 13, RFC 1035, November 1987.
631:
632: [RFC1188] Katz, D., "Proposed Standard for the Transmission of IP
633: Datagrams over FDDI Networks", RFC 1188, October 1990.
634:
635: [RFC1542] Wimer, W., "Clarifications and Extensions for the
636: Bootstrap Protocol", RFC 1542, October 1993.
637:
638: [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
639: RFC 2131, March 1997.
640:
641: [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
642: Extensions", RFC 2132, March 1997.
643:
644: [RFC2241] Provan, D., "DHCP Options for Novell Directory Services",
645: RFC 2241, November 1997.
646:
647: [RFC2242] Droms, R. and K. Fong, "NetWare/IP Domain Name and
648: Information", RFC 2242, November 1997.
649:
650: [RFC2485] Drach, S., "DHCP Option for The Open Group's User
651: Authentication Protocol", RFC 2485, January 1999.
652:
653: [RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service
654: Location Protocol", RFC 2610, June 1999.
655:
656: [RFC2937] Smith, C., "The Name Service Search Option for DHCP",
657: RFC 2937, September 2000.
658:
659: [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
660: of New DHCP Options and Message Types", BCP 43, RFC 2939,
661: September 2000.
662:
663: [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis,
664: A., Beser, B., and J. Privat, "The User Class Option for
665: DHCP", RFC 3004, November 2000.
666:
667: [RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP",
668:
669:
670:
671: Hankins [Page 12]
672:
673: ISC DHCP References Collection May 2007
674:
675:
676: RFC 3011, November 2000.
677:
678: [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
679: RFC 3046, January 2001.
680:
681: [RFC3074] Volz, B., Gonczi, S., Lemon, T., and R. Stevens, "DHC Load
682: Balancing Algorithm", RFC 3074, February 2001.
683:
684: [RFC3256] Jones, D. and R. Woundy, "The DOCSIS (Data-Over-Cable
685: Service Interface Specifications) Device Class DHCP
686: (Dynamic Host Configuration Protocol) Relay Agent
687: Information Sub-option", RFC 3256, April 2002.
688:
689: [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
690: and M. Carney, "Dynamic Host Configuration Protocol for
691: IPv6 (DHCPv6)", RFC 3315, July 2003.
692:
693: [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
694: Protocol (DHCPv6) Options for Session Initiation Protocol
695: (SIP) Servers", RFC 3319, July 2003.
696:
697: [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the
698: Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
699: November 2002.
700:
701: [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration
702: Protocol (DHCP) Domain Search Option", RFC 3397,
703: November 2002.
704:
705: [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
706: "Link Selection sub-option for the Relay Agent Information
707: Option for DHCPv4", RFC 3527, April 2003.
708:
709: [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
710: Host Configuration Protocol (DHCP) version 6", RFC 3633,
711: December 2003.
712:
713: [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
714: Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
715: December 2003.
716:
717: [RFC3679] Droms, R., "Unused Dynamic Host Configuration Protocol
718: (DHCP) Option Codes", RFC 3679, January 2004.
719:
720: [RFC3898] Kalusivalingam, V., "Network Information Service (NIS)
721: Configuration Options for Dynamic Host Configuration
722: Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
723:
724:
725:
726:
727: Hankins [Page 13]
728:
729: ISC DHCP References Collection May 2007
730:
731:
732: [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for
733: Dynamic Host Configuration Protocol version 4 (DHCPv4)",
734: RFC 3925, October 2004.
735:
736: [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration
737: Protocol version 4 (DHCPv4) Options", RFC 3942,
738: November 2004.
739:
740: [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
741: Configuration Option for DHCPv6", RFC 4075, May 2005.
742:
743: [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
744: Time Option for Dynamic Host Configuration Protocol for
745: IPv6 (DHCPv6)", RFC 4242, November 2005.
746:
747: [RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host
748: Configuration Protocol (DHCP) Options for Broadcast and
749: Multicast Control Servers", RFC 4280, November 2005.
750:
751: [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
752: Protocol (DHCP) Leasequery", RFC 4388, February 2006.
753:
754: [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6
755: (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
756: June 2006.
757:
758: [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
759: (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
760: August 2006.
761:
762: [RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource
763: Record (RR) for Encoding Dynamic Host Configuration
764: Protocol (DHCP) Information (DHCID RR)", RFC 4701,
765: October 2006.
766:
767: [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
768: Configuration Protocol (DHCP) Client Fully Qualified
769: Domain Name (FQDN) Option", RFC 4702, October 2006.
770:
771: [RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified
772: Domain Name (FQDN) Conflicts among Dynamic Host
773: Configuration Protocol (DHCP) Clients", RFC 4703,
774: October 2006.
775:
776: [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
777: IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
778: Option", RFC 4704, October 2006.
779:
780:
781:
782:
783: Hankins [Page 14]
784:
785: ISC DHCP References Collection May 2007
786:
787:
788: [draft-failover]
789: Droms, R., "DHCP Failover Protocol", March 2003.
790:
791:
792: Author's Address
793:
794: David W. Hankins
795: Internet Systems Consortium, Inc.
796: 950 Charter Street
797: Redwood City, CA 94063
798:
799: Phone: +1 650 423 1300
800: Email: David_Hankins@isc.org
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: Hankins [Page 15]
840:
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to References.txt CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / dhcp / doc