Annotation of embedaddon/dhcp/doc/References.html, revision 1.1.1.1
1.1 misho 1: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
2: <html lang="en"><head><title>ISC-DHCP-REFERENCES: ISC DHCP References Collection</title>
3: <meta http-equiv="Expires" content="Thu, 23 Jul 2009 00:21:33 +0000">
4: <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
5: <meta name="description" content="ISC DHCP References Collection">
6: <meta name="keywords" content="ISC, DHCP, Reference Implementation">
7: <meta name="generator" content="xml2rfc v1.33 (http://xml.resource.org/)">
8: <style type='text/css'><!--
9: body {
10: font-family: verdana, charcoal, helvetica, arial, sans-serif;
11: font-size: small; color: #000; background-color: #FFF;
12: margin: 2em;
13: }
14: h1, h2, h3, h4, h5, h6 {
15: font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
16: font-weight: bold; font-style: normal;
17: }
18: h1 { color: #900; background-color: transparent; text-align: right; }
19: h3 { color: #333; background-color: transparent; }
20:
21: td.RFCbug {
22: font-size: x-small; text-decoration: none;
23: width: 30px; height: 30px; padding-top: 2px;
24: text-align: justify; vertical-align: middle;
25: background-color: #000;
26: }
27: td.RFCbug span.RFC {
28: font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
29: font-weight: bold; color: #666;
30: }
31: td.RFCbug span.hotText {
32: font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
33: font-weight: normal; text-align: center; color: #FFF;
34: }
35:
36: table.TOCbug { width: 30px; height: 15px; }
37: td.TOCbug {
38: text-align: center; width: 30px; height: 15px;
39: color: #FFF; background-color: #900;
40: }
41: td.TOCbug a {
42: font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
43: font-weight: bold; font-size: x-small; text-decoration: none;
44: color: #FFF; background-color: transparent;
45: }
46:
47: td.header {
48: font-family: arial, helvetica, sans-serif; font-size: x-small;
49: vertical-align: top; width: 33%;
50: color: #FFF; background-color: #666;
51: }
52: td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
53: td.author-text { font-size: x-small; }
54:
55: /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
56: a.info {
57: /* This is the key. */
58: position: relative;
59: z-index: 24;
60: text-decoration: none;
61: }
62: a.info:hover {
63: z-index: 25;
64: color: #FFF; background-color: #900;
65: }
66: a.info span { display: none; }
67: a.info:hover span.info {
68: /* The span will display just on :hover state. */
69: display: block;
70: position: absolute;
71: font-size: smaller;
72: top: 2em; left: -5em; width: 15em;
73: padding: 2px; border: 1px solid #333;
74: color: #900; background-color: #EEE;
75: text-align: left;
76: }
77:
78: a { font-weight: bold; }
79: a:link { color: #900; background-color: transparent; }
80: a:visited { color: #633; background-color: transparent; }
81: a:active { color: #633; background-color: transparent; }
82:
83: p { margin-left: 2em; margin-right: 2em; }
84: p.copyright { font-size: x-small; }
85: p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
86: table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
87: td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
88:
89: ol.text { margin-left: 2em; margin-right: 2em; }
90: ul.text { margin-left: 2em; margin-right: 2em; }
91: li { margin-left: 3em; }
92:
93: /* RFC-2629 <spanx>s and <artwork>s. */
94: em { font-style: italic; }
95: strong { font-weight: bold; }
96: dfn { font-weight: bold; font-style: normal; }
97: cite { font-weight: normal; font-style: normal; }
98: tt { color: #036; }
99: tt, pre, pre dfn, pre em, pre cite, pre span {
100: font-family: "Courier New", Courier, monospace; font-size: small;
101: }
102: pre {
103: text-align: left; padding: 4px;
104: color: #000; background-color: #CCC;
105: }
106: pre dfn { color: #900; }
107: pre em { color: #66F; background-color: #FFC; font-weight: normal; }
108: pre .key { color: #33C; font-weight: bold; }
109: pre .id { color: #900; }
110: pre .str { color: #000; background-color: #CFF; }
111: pre .val { color: #066; }
112: pre .rep { color: #909; }
113: pre .oth { color: #000; background-color: #FCF; }
114: pre .err { background-color: #FCC; }
115:
116: /* RFC-2629 <texttable>s. */
117: table.all, table.full, table.headers, table.none {
118: font-size: small; text-align: center; border-width: 2px;
119: vertical-align: top; border-collapse: collapse;
120: }
121: table.all, table.full { border-style: solid; border-color: black; }
122: table.headers, table.none { border-style: none; }
123: th {
124: font-weight: bold; border-color: black;
125: border-width: 2px 2px 3px 2px;
126: }
127: table.all th, table.full th { border-style: solid; }
128: table.headers th { border-style: none none solid none; }
129: table.none th { border-style: none; }
130: table.all td {
131: border-style: solid; border-color: #333;
132: border-width: 1px 2px;
133: }
134: table.full td, table.headers td, table.none td { border-style: none; }
135:
136: hr { height: 1px; }
137: hr.insert {
138: width: 80%; border-style: none; border-width: 0;
139: color: #CCC; background-color: #CCC;
140: }
141: --></style>
142: </head>
143: <body>
144: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
145: <table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
146: <tr><td class="header">ISC-DHCP-REFERENCES</td><td class="header">D. Hankins</td></tr>
147: <tr><td class="header"> </td><td class="header">ISC</td></tr>
148: <tr><td class="header"> </td><td class="header">May 2007</td></tr>
149: </table></td></tr></table>
150: <h1><br />ISC DHCP References Collection</h1>
151:
152: <h3>Copyright Notice</h3>
153:
154: <p>Copyright (c) 2006-2007,2009 by Internet Systems Consortium, Inc.
155: ("ISC")
156: </p>
157: <p>Permission to use, copy, modify, and distribute this software for
158: any purpose with or without fee is hereby granted, provided that the
159: above copyright notice and this permission notice appear in all
160: copies.
161: </p>
162: <p>THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
163: WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
164: MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR
165: ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
166: WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
167: ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
168: OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
169: </p>
170: <h3>Abstract</h3>
171:
172: <p>This document describes a collection of Reference material that
173: ISC DHCP has been implemented to.
174: </p><a name="toc"></a><br /><hr />
175: <h3>Table of Contents</h3>
176: <p class="toc">
177: <a href="#anchor1">1.</a>
178: Introduction<br />
179: <br />
180: <a href="#anchor2">2.</a>
181: Definition: Reference Implementation<br />
182: <br />
183: <a href="#anchor3">3.</a>
184: Low Layer References<br />
185: <a href="#anchor4">3.1.</a>
186: Ethernet Protocol References<br />
187: <a href="#anchor5">3.2.</a>
188: Token Ring Protocol References<br />
189: <a href="#anchor6">3.3.</a>
190: FDDI Protocol References<br />
191: <a href="#anchor7">3.4.</a>
192: Internet Protocol Version 4 References<br />
193: <a href="#anchor8">3.5.</a>
194: Unicast Datagram Protocol References<br />
195: <br />
196: <a href="#anchor9">4.</a>
197: BOOTP Protocol References<br />
198: <br />
199: <a href="#anchor10">5.</a>
200: DHCP Protocol References<br />
201: <a href="#anchor11">5.1.</a>
202: DHCPv4 Protocol<br />
203: <a href="#anchor12">5.1.1.</a>
204: Core Protocol References<br />
205: <a href="#anchor13">5.2.</a>
206: DHCPv6 Protocol References<br />
207: <a href="#anchor14">5.3.</a>
208: DHCP Option References<br />
209: <a href="#anchor15">5.3.1.</a>
210: Relay Agent Information Option Options<br />
211: <a href="#anchor16">5.3.2.</a>
212: Dynamic DNS Updates References<br />
213: <a href="#anchor17">5.3.3.</a>
214: Experimental: Failover References<br />
215: <a href="#anchor18">5.4.</a>
216: DHCP Procedures<br />
217: <br />
218: <a href="#rfc.references1">6.</a>
219: References<br />
220: <br />
221: <a href="#rfc.authors">§</a>
222: Author's Address<br />
223: </p>
224: <br clear="all" />
225:
226: <a name="anchor1"></a><br /><hr />
227: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
228: <a name="rfc.section.1"></a><h3>1.
229: Introduction</h3>
230:
231: <p>As a little historical anecdote, ISC DHCP once packaged all the
232: relevant RFCs and standards documents along with the software
233: package. Until one day when a voice was heard from one of the
234: many fine institutions that build and distribute this software...
235: they took issue with the IETF's copyright on the RFC's. It
236: seems the IETF's copyrights don't allow modification of RFC's
237: (except for translation purposes).
238: </p>
239: <p>Our main purpose in providing the RFCs is to aid in
240: documentation, but since RFCs are now available widely from many
241: points of distribution on the Internet, there is no real need to
242: provide the documents themselves. So, this document has been
243: created in their stead, to list the various IETF RFCs one might
244: want to read, and to comment on how well (or poorly) we have
245: managed to implement them.
246: </p>
247: <a name="anchor2"></a><br /><hr />
248: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
249: <a name="rfc.section.2"></a><h3>2.
250: Definition: Reference Implementation</h3>
251:
252: <p>ISC DHCP, much like its other cousins in ISC software, is
253: self-described as a 'Reference Implementation.' There has been
254: a great deal of confusion about this term. Some people seem to
255: think that this term applies to any software that once passed
256: a piece of reference material on its way to market (but may do
257: quite a lot of things that aren't described in any reference, or
258: may choose to ignore the reference it saw entirely). Other folks
259: get confused by the word 'reference' and understand that to mean
260: that there is some special status applied to the software - that
261: the software itself is the reference by which all other software
262: is measured. Something along the lines of being "The DHCP
263: Protocol's Reference Clock," it is supposed.
264: </p>
265: <p>The truth is actually quite a lot simpler. Reference
266: implementations are software packages which were written
267: to behave precisely as appears in reference material. They
268: are written "to match reference."
269: </p>
270: <p>If the software has a behaviour that manifests itself
271: externally (whether it be something as simple as the 'wire
272: format' or something higher level, such as a complicated
273: behaviour that arises from multiple message exchanges), that
274: behaviour must be found in a reference document.
275: </p>
276: <p>Anything else is a bug, the only question is whether the
277: bug is in reference or software (failing to implement the
278: reference).
279: </p>
280: <p>This means:
281: </p>
282: <ul class="text">
283: <li>To produce new externally-visible behaviour, one must first
284: provide a reference.
285: </li>
286: <li>Before changing externally visible behaviour to work around
287: simple incompatibilities in any other implementation, one must
288: first provide a reference.
289: </li>
290: </ul>
291: <p>That is the lofty goal, at any rate. It's well understood that,
292: especially because the ISC DHCP Software package has not always been
293: held to this standard (but not entirely due to it), there are many
294: non-referenced behaviours within ISC DHCP.
295: </p>
296: <p>The primary goal of reference implementation is to prove the
297: reference material. If the reference material is good, then you
298: should be able to sit down and write a program that implements the
299: reference, to the word, and come to an implementation that
300: is distinguishable from others in the details, but not in the
301: facts of operating the protocol. This means that there is no
302: need for 'special knowledge' to work around arcane problems that
303: were left undocumented. No secret handshakes need to be learned
304: to be imparted with the necessary "real documentation".
305: </p>
306: <p>Also, by accepting only reference as the guidebook for ISC
307: DHCP's software implementation, anyone who can make an impact on
308: the color texture or form of that reference has a (somewhat
309: indirect) voice in ISC DHCP's software design. As the IETF RFC's
310: have been selected as the source of reference, that means everyone
311: on the Internet with the will to participate has a say.
312: </p>
313: <a name="anchor3"></a><br /><hr />
314: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
315: <a name="rfc.section.3"></a><h3>3.
316: Low Layer References</h3>
317:
318: <p>It may surprise you to realize that ISC DHCP implements 802.1
319: 'Ethernet' framing, Token Ring, and FDDI. In order to bridge the
320: gap there between these physical and DHCP layers, it must also
321: implement IP and UDP framing.
322: </p>
323: <p>The reason for this stems from Unix systems' handling of BSD
324: sockets (the general way one might engage in transmission of UDP
325: packets) on unconfigured interfaces, or even the handling of
326: broadcast addressing on configured interfaces.
327: </p>
328: <p>There are a few things that DHCP servers, relays, and clients all
329: need to do in order to speak the DHCP protocol in strict compliance
330: with <a class='info' href='#RFC2131'>RFC2131<span> (</span><span class='info'>Droms, R., “Dynamic Host Configuration Protocol,” March 1997.</span><span>)</span></a> [RFC2131].
331: </p>
332: <ol class="text">
333: <li>Transmit a UDP packet from IP:0.0.0.0 Ethernet:Self, destined to
334: IP:255.255.255.255 LinkLayer:Broadcast on an unconfigured (no IP
335: address yet) interface.
336: </li>
337: <li>Receive a UDP packet from IP:remote-system LinkLayer:remote-system,
338: destined to IP:255.255.255.255 LinkLayer:Broadcast, again on an
339: unconfigured interface.
340: </li>
341: <li>Transmit a UDP packet from IP:Self, Ethernet:Seelf, destined to
342: IP:remote-system LinkLayer:remote-system, without transmitting a
343: single ARP.
344: </li>
345: <li>And of course the simple case, a regular IP unicast that is
346: routed via the usual means (so it may be direct to a local system,
347: with ARP providing the glue, or it may be to a remote system via
348: one or more routers as normal). In this case, the interfaces are
349: always configured.
350: </li>
351: </ol>
352: <p>The above isn't as simple as it sounds on a regular BSD socket.
353: Many unix implementations will transmit broadcasts not to
354: 255.255.255.255, but to x.y.z.255 (where x.y.z is the system's local
355: subnet). Such packets are not received by several known DHCP client
356: implementations - and it's not their fault, <a class='info' href='#RFC2131'>RFC2131<span> (</span><span class='info'>Droms, R., “Dynamic Host Configuration Protocol,” March 1997.</span><span>)</span></a> [RFC2131] very explicitly demands that these packets' IP
357: destination addresses be set to 255.255.255.255.
358: </p>
359: <p>Receiving packets sent to 255.255.255.255 isn't a problem on most
360: modern unixes...so long as the interface is configured. When there
361: is no IPv4 address on the interface, things become much more murky.
362: </p>
363: <p>So, for this convoluted and unfortunate state of affairs in the
364: unix systems of the day ISC DHCP was manufactured, in order to do
365: what it needs not only to implement the reference but to interoperate
366: with other implementations, the software must create some form of
367: raw socket to operate on.
368: </p>
369: <p>What it actually does is create, for each interface detected on
370: the system, a Berkeley Packet Filter socket (or equivalent), and
371: program it with a filter that brings in only DHCP packets. A
372: "fallback" UDP Berkeley socket is generally also created, a single
373: one no matter how many interfaces. Should the software need to
374: transmit a contrived packet to the local network the packet is
375: formed piece by piece and transmitted via the BPF socket. Hence
376: the need to implement many forms of Link Layer framing and above.
377: The software gets away with not having to implement IP routing
378: tables as well by simply utilizing the aforementioned 'fallback'
379: UDP socket when unicasting between two configured systems is the
380: need.
381: </p>
382: <p>Modern unixes have opened up some facilities that diminish how
383: much of this sort of nefarious kludgery is necessary, but have not
384: found the state of affairs absolutely absolved. In particular,
385: one might now unicast without ARP by inserting an entry into the
386: ARP cache prior to transmitting. Unconfigured interfaces remain
387: the sticking point, however...on virtually no modern unixes is
388: it possible to receive broadcast packets unless a local IPv4
389: address has been configured, unless it is done with raw sockets.
390: </p>
391: <a name="anchor4"></a><br /><hr />
392: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
393: <a name="rfc.section.3.1"></a><h3>3.1.
394: Ethernet Protocol References</h3>
395:
396: <p>ISC DHCP Implements Ethernet Version 2 ("DIX"), which is a variant
397: of IEEE 802.2. No good reference of this framing is known to exist
398: at this time, but it is vaguely described in <a class='info' href='#RFC0894'>RFC894<span> (</span><span class='info'>Hornig, C., “Standard for the transmission of IP datagrams over Ethernet networks,” April 1984.</span><span>)</span></a> [RFC0894] (see the section titled "Packet format"), and
399: the following URL is also thought to be useful.
400: </p>
401: <p>http://en.wikipedia.org/wiki/DIX
402: </p>
403: <a name="anchor5"></a><br /><hr />
404: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
405: <a name="rfc.section.3.2"></a><h3>3.2.
406: Token Ring Protocol References</h3>
407:
408: <p>IEEE 802.5 defines the Token Ring framing format used by ISC
409: DHCP.
410: </p>
411: <a name="anchor6"></a><br /><hr />
412: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
413: <a name="rfc.section.3.3"></a><h3>3.3.
414: FDDI Protocol References</h3>
415:
416: <p><a class='info' href='#RFC1188'>RFC1188<span> (</span><span class='info'>Katz, D., “Proposed Standard for the Transmission of IP Datagrams over FDDI Networks,” October 1990.</span><span>)</span></a> [RFC1188] is the most helpful
417: reference ISC DHCP has used to form FDDI packets.
418: </p>
419: <a name="anchor7"></a><br /><hr />
420: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
421: <a name="rfc.section.3.4"></a><h3>3.4.
422: Internet Protocol Version 4 References</h3>
423:
424: <p><a class='info' href='#RFC0760'>RFC760<span> (</span><span class='info'>Postel, J., “DoD standard Internet Protocol,” January 1980.</span><span>)</span></a> [RFC0760] fundamentally defines the
425: bare IPv4 protocol which ISC DHCP implements.
426: </p>
427: <a name="anchor8"></a><br /><hr />
428: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
429: <a name="rfc.section.3.5"></a><h3>3.5.
430: Unicast Datagram Protocol References</h3>
431:
432: <p><a class='info' href='#RFC0768'>RFC768<span> (</span><span class='info'>Postel, J., “User Datagram Protocol,” August 1980.</span><span>)</span></a> [RFC0768] defines the User Datagram
433: Protocol that ultimately carries the DHCP or BOOTP protocol. The
434: destination DHCP server port is 67, the client port is 68. Source
435: ports are irrelevant.
436: </p>
437: <a name="anchor9"></a><br /><hr />
438: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
439: <a name="rfc.section.4"></a><h3>4.
440: BOOTP Protocol References</h3>
441:
442: <p>The DHCP Protocol is strange among protocols in that it is
443: grafted over the top of another protocol - BOOTP (but we don't
444: call it "DHCP over BOOTP" like we do, say "TCP over IP"). BOOTP
445: and DHCP share UDP packet formats - DHCP is merely a conventional
446: use of both BOOTP header fields and the trailing 'options' space.
447: </p>
448: <p>The ISC DHCP server supports BOOTP clients conforming to
449: <a class='info' href='#RFC0951'>RFC951<span> (</span><span class='info'>Croft, B. and J. Gilmore, “Bootstrap Protocol,” September 1985.</span><span>)</span></a> [RFC0951] and <a class='info' href='#RFC1542'>RFC1542<span> (</span><span class='info'>Wimer, W., “Clarifications and Extensions for the Bootstrap Protocol,” October 1993.</span><span>)</span></a> [RFC1542].
450: </p>
451: <a name="anchor10"></a><br /><hr />
452: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
453: <a name="rfc.section.5"></a><h3>5.
454: DHCP Protocol References</h3>
455:
456: <a name="anchor11"></a><br /><hr />
457: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
458: <a name="rfc.section.5.1"></a><h3>5.1.
459: DHCPv4 Protocol</h3>
460:
461: <p>"The DHCP[v4] Protocol" is not defined in a single document. The
462: following collection of references of what ISC DHCP terms "The
463: DHCPv4 Protocol".
464: </p>
465: <a name="anchor12"></a><br /><hr />
466: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
467: <a name="rfc.section.5.1.1"></a><h3>5.1.1.
468: Core Protocol References</h3>
469:
470: <p><a class='info' href='#RFC2131'>RFC2131<span> (</span><span class='info'>Droms, R., “Dynamic Host Configuration Protocol,” March 1997.</span><span>)</span></a> [RFC2131] defines the protocol format
471: and procedures. ISC DHCP is not known to diverge from this document
472: in any way. There are, however, a few points on which different
473: implementations have arisen out of vagueries in the document.
474: DHCP Clients exist which, at one time, present themselves as using
475: a Client Identifier Option which is equal to the client's hardware
476: address. Later, the client transmits DHCP packets with no Client
477: Identifier Option present - essentially identifying themselves using
478: the hardware address. Some DHCP Servers have been developed which
479: identify this client as a single client. ISC has interpreted
480: RFC2131 to indicate that these clients must be treated as two
481: separate entities (and hence two, separate addresses). Client
482: behaviour (Embedded Windows products) has developed that relies on
483: the former implementation, and hence is incompatible with the
484: latter. Also, RFC2131 demands explicitly that some header fields
485: be zeroed upon certain message types. The ISC DHCP Server instead
486: copies many of these fields from the packet received from the client
487: or relay, which may not be zero. It is not known if there is a good
488: reason for this that has not been documented.
489: </p>
490: <p><a class='info' href='#RFC2132'>RFC2132<span> (</span><span class='info'>Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions,” March 1997.</span><span>)</span></a> [RFC2132] defines the initial set of
491: DHCP Options and provides a great deal of guidance on how to go about
492: formatting and processing options. The document unfortunately
493: waffles to a great extent about the NULL termination of DHCP Options,
494: and some DHCP Clients (Windows 95) have been implemented that rely
495: upon DHCP Options containing text strings to be NULL-terminated (or
496: else they crash). So, ISC DHCP detects if clients null-terminate the
497: host-name option and, if so, null terminates any text options it
498: transmits to the client. It also removes NULL termination from any
499: known text option it receives prior to any other processing.
500: </p>
501: <a name="anchor13"></a><br /><hr />
502: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
503: <a name="rfc.section.5.2"></a><h3>5.2.
504: DHCPv6 Protocol References</h3>
505:
506: <p>For now there is only one document that specifies the DHCPv6
507: protocol (there have been no updates yet), <a class='info' href='#RFC3315'>RFC3315<span> (</span><span class='info'>Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.</span><span>)</span></a> [RFC3315].
508: </p>
509: <p>Support for DHCPv6 was added first in version 4.0.0. The server
510: and client support only IA_NA. While the server does support multiple
511: IA_NAs within one packet from the client, our client only supports
512: sending one. There is no relay support.
513: </p>
514: <p>DHCPv6 introduces some new and uncomfortable ideas to the common
515: software library.
516: </p>
517: <ol class="text">
518: <li>Options of zero length are normal in DHCPv6. Currently, all
519: ISC DHCP software treats zero-length options as errors.
520: </li>
521: <li>Options sometimes may appear multiple times. The common
522: library used to treat all appearance of multiple options as
523: specified in RFC2131 - to be concatenated. DHCPv6 options
524: may sometimes appear multiple times (such as with IA_NA or
525: IAADDR), but often must not.
526: </li>
527: <li>The same option space appears in DHCPv6 packets multiple times.
528: If the packet was got via a relay, then the client's packet is
529: stored to an option within the relay's packet...if there were two
530: relays, this recurses. At each of these steps, the root "DHCPv6
531: option space" is used. Further, a client packet may contain an
532: IA_NA, which may contain an IAADDR - but really, in an abstract
533: sense, this is again re-encapsulation of the DHCPv6 option space
534: beneath options it also contains.
535: </li>
536: </ol>
537: <p>Precisely how to correctly support the above conundrums has not
538: quite yet been settled, so support is incomplete.
539: </p>
540: <a name="anchor14"></a><br /><hr />
541: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
542: <a name="rfc.section.5.3"></a><h3>5.3.
543: DHCP Option References</h3>
544:
545: <p><a class='info' href='#RFC2241'>RFC2241<span> (</span><span class='info'>Provan, D., “DHCP Options for Novell Directory Services,” November 1997.</span><span>)</span></a> [RFC2241] defines options for
546: Novell Directory Services.
547: </p>
548: <p><a class='info' href='#RFC2242'>RFC2242<span> (</span><span class='info'>Droms, R. and K. Fong, “NetWare/IP Domain Name and Information,” November 1997.</span><span>)</span></a> [RFC2242] defines an encapsulated
549: option space for NWIP configuration.
550: </p>
551: <p><a class='info' href='#RFC2485'>RFC2485<span> (</span><span class='info'>Drach, S., “DHCP Option for The Open Group's User Authentication Protocol,” January 1999.</span><span>)</span></a> [RFC2485] defines the Open Group's
552: UAP option.
553: </p>
554: <p><a class='info' href='#RFC2610'>RFC2610<span> (</span><span class='info'>Perkins, C. and E. Guttman, “DHCP Options for Service Location Protocol,” June 1999.</span><span>)</span></a> [RFC2610] defines options for
555: the Service Location Protocol (SLP).
556: </p>
557: <p><a class='info' href='#RFC2937'>RFC2937<span> (</span><span class='info'>Smith, C., “The Name Service Search Option for DHCP,” September 2000.</span><span>)</span></a> [RFC2937] defines the Name Service
558: Search Option (not to be confused with the domain-search option).
559: The Name Service Search Option allows eg nsswitch.conf to be
560: reconfigured via dhcp. The ISC DHCP server implements this option,
561: and the ISC DHCP client is compatible...but does not by default
562: install this option's value. One would need to make their relevant
563: dhclient-script process this option in a way that is suitable for
564: the system.
565: </p>
566: <p><a class='info' href='#RFC3004'>RFC3004<span> (</span><span class='info'>Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, A., Beser, B., and J. Privat, “The User Class Option for DHCP,” November 2000.</span><span>)</span></a> [RFC3004] defines the User-Class
567: option. Note carefully that ISC DHCP currently does not implement
568: to this reference, but has (inexplicably) selected an incompatible
569: format: a plain text string.
570: </p>
571: <p><a class='info' href='#RFC3011'>RFC3011<span> (</span><span class='info'>Waters, G., “The IPv4 Subnet Selection Option for DHCP,” November 2000.</span><span>)</span></a> [RFC3011] defines the Subnet-Selection
572: plain DHCPv4 option. Do not confuse this option with the relay agent
573: "link selection" sub-option, although their behaviour is similar.
574: </p>
575: <p><a class='info' href='#RFC3319'>RFC3319<span> (</span><span class='info'>Schulzrinne, H. and B. Volz, “Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers,” July 2003.</span><span>)</span></a> [RFC3319] defines the SIP server
576: options for DHCPv6.
577: </p>
578: <p><a class='info' href='#RFC3396'>RFC3396<span> (</span><span class='info'>Lemon, T. and S. Cheshire, “Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4),” November 2002.</span><span>)</span></a> [RFC3396] documents both how long
579: options may be encoded in DHCPv4 packets, and also how multiple
580: instances of the same option code within a DHCPv4 packet will be
581: decoded by receivers.
582: </p>
583: <p><a class='info' href='#RFC3397'>RFC3397<span> (</span><span class='info'>Aboba, B. and S. Cheshire, “Dynamic Host Configuration Protocol (DHCP) Domain Search Option,” November 2002.</span><span>)</span></a> [RFC3397] documents the Domain-Search
584: Option, which allows the configuration of the /etc/resolv.conf
585: 'search' parameter in a way that is <a class='info' href='#RFC1035'>RFC1035<span> (</span><span class='info'>Mockapetris, P., “Domain names - implementation and specification,” November 1987.</span><span>)</span></a> [RFC1035] wire format compatible (in fact, it uses the RFC1035 wire
586: format). ISC DHCP has both client and server support, and supports
587: RFC1035 name compression.
588: </p>
589: <p><a class='info' href='#RFC3646'>RFC3646<span> (</span><span class='info'>Droms, R., “DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” December 2003.</span><span>)</span></a> [RFC3646] documents the DHCPv6
590: name-servers and domain-search options.
591: </p>
592: <p><a class='info' href='#RFC3633'>RFC3633<span> (</span><span class='info'>Troan, O. and R. Droms, “IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6,” December 2003.</span><span>)</span></a> [RFC3633] documents the Identity
593: Association Prefix Delegation, which is included here for protocol
594: wire reference, but which is not supported by ISC DHCP.
595: </p>
596: <p><a class='info' href='#RFC3679'>RFC3679<span> (</span><span class='info'>Droms, R., “Unused Dynamic Host Configuration Protocol (DHCP) Option Codes,” January 2004.</span><span>)</span></a> [RFC3679] documents a number of
597: options that were documented earlier in history, but were not
598: made use of.
599: </p>
600: <p><a class='info' href='#RFC3898'>RFC3898<span> (</span><span class='info'>Kalusivalingam, V., “Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” October 2004.</span><span>)</span></a> [RFC3898] documents four NIS options
601: for delivering NIS servers and domain information in DHCPv6.
602: </p>
603: <p><a class='info' href='#RFC3925'>RFC3925<span> (</span><span class='info'>Littlefield, J., “Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4),” October 2004.</span><span>)</span></a> [RFC3925] documents a pair of
604: Enterprise-ID delimited option spaces for vendors to use in order
605: to inform servers of their "vendor class" (sort of like 'uname'
606: or 'who and what am I'), and a means to deliver vendor-specific
607: and vendor-documented option codes and values.
608: </p>
609: <p><a class='info' href='#RFC3942'>RFC3942<span> (</span><span class='info'>Volz, B., “Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options,” November 2004.</span><span>)</span></a> [RFC3942] redefined the 'site local'
610: option space.
611: </p>
612: <p><a class='info' href='#RFC4075'>RFC4075<span> (</span><span class='info'>Kalusivalingam, V., “Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6,” May 2005.</span><span>)</span></a> [RFC4075] defines the DHCPv6 SNTP
613: Servers option.
614: </p>
615: <p><a class='info' href='#RFC4242'>RFC4242<span> (</span><span class='info'>Venaas, S., Chown, T., and B. Volz, “Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” November 2005.</span><span>)</span></a> [RFC4242] defines the Information
616: Refresh Time option, which advises DHCPv6 Information-Request
617: clients to return for updated information.
618: </p>
619: <p><a class='info' href='#RFC4280'>RFC4280<span> (</span><span class='info'>Chowdhury, K., Yegani, P., and L. Madour, “Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers,” November 2005.</span><span>)</span></a> [RFC4280] defines two BCMS server
620: options.
621: </p>
622: <p><a class='info' href='#RFC4388'>RFC4388<span> (</span><span class='info'>Woundy, R. and K. Kinnear, “Dynamic Host Configuration Protocol (DHCP) Leasequery,” February 2006.</span><span>)</span></a> [RFC4388] defined the DHCPv4
623: LEASEQUERY message type and a number of suitable response messages,
624: for the purpose of sharing information about DHCP served addresses
625: and clients.
626: </p>
627: <p><a class='info' href='#RFC4580'>RFC4580<span> (</span><span class='info'>Volz, B., “Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option,” June 2006.</span><span>)</span></a> [RFC4580] defines a DHCPv6
628: subscriber-id option, which is similar in principle to the DHCPv4
629: relay agent option of the same name.
630: </p>
631: <p><a class='info' href='#RFC4649'>RFC4649<span> (</span><span class='info'>Volz, B., “Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option,” August 2006.</span><span>)</span></a> [RFC4649] defines a DHCPv6 remote-id
632: option, which is similar in principle to the DHCPv4 relay agent
633: remote-id.
634: </p>
635: <a name="anchor15"></a><br /><hr />
636: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
637: <a name="rfc.section.5.3.1"></a><h3>5.3.1.
638: Relay Agent Information Option Options</h3>
639:
640: <p><a class='info' href='#RFC3046'>RFC3046<span> (</span><span class='info'>Patrick, M., “DHCP Relay Agent Information Option,” January 2001.</span><span>)</span></a> [RFC3046] defines the Relay Agent
641: Information Option and provides a number of sub-option
642: definitions.
643: </p>
644: <p><a class='info' href='#RFC3256'>RFC3256<span> (</span><span class='info'>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,” April 2002.</span><span>)</span></a> [RFC3256] defines the DOCSIS Device
645: Class sub-option.
646: </p>
647: <p><a class='info' href='#RFC3527'>RFC3527<span> (</span><span class='info'>Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, “Link Selection sub-option for the Relay Agent Information Option for DHCPv4,” April 2003.</span><span>)</span></a> [RFC3527] defines the Link Selection
648: sub-option.
649: </p>
650: <a name="anchor16"></a><br /><hr />
651: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
652: <a name="rfc.section.5.3.2"></a><h3>5.3.2.
653: Dynamic DNS Updates References</h3>
654:
655: <p>The collection of documents that describe the standards-based
656: method to update dns names of DHCP clients starts most easily
657: with <a class='info' href='#RFC4703'>RFC4703<span> (</span><span class='info'>Stapp, M. and B. Volz, “Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients,” October 2006.</span><span>)</span></a> [RFC4703] to define the overall
658: architecture, travels through RFCs <a class='info' href='#RFC4702'>4702<span> (</span><span class='info'>Stapp, M., Volz, B., and Y. Rekhter, “The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option,” October 2006.</span><span>)</span></a> [RFC4702]
659: and <a class='info' href='#RFC4704'>4704<span> (</span><span class='info'>Volz, B., “The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option,” October 2006.</span><span>)</span></a> [RFC4704] to describe the DHCPv4 and
660: DHCPv6 FQDN options (to carry the client name), and ends up at
661: <a class='info' href='#RFC4701'>RFC4701<span> (</span><span class='info'>Stapp, M., Lemon, T., and A. Gustafsson, “A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR),” October 2006.</span><span>)</span></a> [RFC4701] which describes the DHCID
662: RR used in DNS to perform a kind of atomic locking.
663: </p>
664: <p>ISC DHCP adopted early versions of these documents, and has not
665: yet synchronized with the final standards versions.
666: </p>
667: <p>For RFCs 4702 and 4704, the 'N' bit is not yet supported. The
668: result is that it is always set zero, and is ignored if set.
669: </p>
670: <p>For RFC4701, which is used to match client identities with names
671: in the DNS as part of name conflict resolution. Note that ISC DHCP's
672: implementation of DHCIDs vary wildly from this specification.
673: First, ISC DHCP uses a TXT record in which the contents are stored
674: in hexadecimal. Second, there is a flaw in the selection of the
675: 'Identifier Type', which results in a completely different value
676: being selected than was defined in an older revision of this
677: document...also this field is one byte prior to hexadecimal
678: encoding rather than two. Third, ISC DHCP does not use a digest
679: type code. Rather, all values for such TXT records are reached
680: via an MD5 sum. In short, nothing is compatible, but the
681: principle of the TXT record is the same as the standard DHCID
682: record. However, for DHCPv6 FQDN, we do use DHCID type code '2',
683: as no other value really makes sense in our context.
684: </p>
685: <a name="anchor17"></a><br /><hr />
686: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
687: <a name="rfc.section.5.3.3"></a><h3>5.3.3.
688: Experimental: Failover References</h3>
689:
690: <p>The Failover Protocol defines a means by which two DHCP Servers
691: can share all the relevant information about leases granted to
692: DHCP clients on given networks, so that one of the two servers may
693: fail and be survived by a server that can act responsibly.
694: </p>
695: <p>Unfortunately it has been quite some years since the last time
696: this document was edited, and the authors no longer show any
697: interest in fielding comments or improving the document.
698: </p>
699: <p>The status of this protocol is very unsure, but ISC's
700: implementation of it has proven stable and suitable for use in
701: sizable production environments.
702: </p>
703: <p><a class='info' href='#draft-failover'>draft-ietf-dhc-failover-12.txt<span> (</span><span class='info'>Droms, R., “DHCP Failover Protocol,” March 2003.</span><span>)</span></a> [draft‑failover]
704: describes the Failover Protocol. In addition to what is described
705: in this document, ISC DHCP has elected to make some experimental
706: changes that may be revoked in a future version of ISC DHCP (if the
707: draft authors do not adopt the new behaviour). Specifically, ISC
708: DHCP's POOLREQ behaviour differs substantially from what is
709: documented in the draft, and the server also implements a form of
710: 'MAC Address Affinity' which is not described in the failover
711: document. The full nature of these changes have been described on
712: the IETF DHC WG mailing list (which has archives), and also in ISC
713: DHCP's manual pages. Also note that although this document
714: references a RECOVER-WAIT state, it does not document a protocol
715: number assignment for this state. As a consequence, ISC DHCP has
716: elected to use the value 254.
717: </p>
718: <p><a class='info' href='#RFC3074'>RFC3074<span> (</span><span class='info'>Volz, B., Gonczi, S., Lemon, T., and R. Stevens, “DHC Load Balancing Algorithm,” February 2001.</span><span>)</span></a> [RFC3074] describes the Load Balancing
719: Algorithm (LBA) that ISC DHCP uses in concert with the Failover
720: protocol. Note that versions 3.0.* are known to misimplement the
721: hash algorithm (it will only use the low 4 bits of every byte of
722: the hash bucket array).
723: </p>
724: <a name="anchor18"></a><br /><hr />
725: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
726: <a name="rfc.section.5.4"></a><h3>5.4.
727: DHCP Procedures</h3>
728:
729: <p><a class='info' href='#RFC2939'>RFC2939<span> (</span><span class='info'>Droms, R., “Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types,” September 2000.</span><span>)</span></a> [RFC2939] explains how to go about
730: obtaining a new DHCP Option code assignment.
731: </p>
732: <a name="rfc.references1"></a><br /><hr />
733: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
734: <h3>6. References</h3>
735: <table width="99%" border="0">
736: <tr><td class="author-text" valign="top"><a name="RFC0760">[RFC0760]</a></td>
737: <td class="author-text">Postel, J., “<a href="http://tools.ietf.org/html/rfc760">DoD standard Internet Protocol</a>,” RFC 760, January 1980 (<a href="ftp://ftp.isi.edu/in-notes/rfc760.txt">TXT</a>).</td></tr>
738: <tr><td class="author-text" valign="top"><a name="RFC0768">[RFC0768]</a></td>
739: <td class="author-text">Postel, J., “<a href="http://tools.ietf.org/html/rfc768">User Datagram Protocol</a>,” STD 6, RFC 768, August 1980 (<a href="ftp://ftp.isi.edu/in-notes/rfc768.txt">TXT</a>).</td></tr>
740: <tr><td class="author-text" valign="top"><a name="RFC0894">[RFC0894]</a></td>
741: <td class="author-text">Hornig, C., “<a href="http://tools.ietf.org/html/rfc894">Standard for the transmission of IP datagrams over Ethernet networks</a>,” STD 41, RFC 894, April 1984 (<a href="ftp://ftp.isi.edu/in-notes/rfc894.txt">TXT</a>).</td></tr>
742: <tr><td class="author-text" valign="top"><a name="RFC0951">[RFC0951]</a></td>
743: <td class="author-text">Croft, B. and J. Gilmore, “<a href="http://tools.ietf.org/html/rfc951">Bootstrap Protocol</a>,” RFC 951, September 1985 (<a href="ftp://ftp.isi.edu/in-notes/rfc951.txt">TXT</a>).</td></tr>
744: <tr><td class="author-text" valign="top"><a name="RFC1035">[RFC1035]</a></td>
745: <td class="author-text">Mockapetris, P., “<a href="http://tools.ietf.org/html/rfc1035">Domain names - implementation and specification</a>,” STD 13, RFC 1035, November 1987 (<a href="ftp://ftp.isi.edu/in-notes/rfc1035.txt">TXT</a>).</td></tr>
746: <tr><td class="author-text" valign="top"><a name="RFC1188">[RFC1188]</a></td>
747: <td class="author-text"><a href="mailto:dkatz@merit.edu">Katz, D.</a>, “<a href="http://tools.ietf.org/html/rfc1188">Proposed Standard for the Transmission of IP Datagrams over FDDI Networks</a>,” RFC 1188, October 1990 (<a href="ftp://ftp.isi.edu/in-notes/rfc1188.txt">TXT</a>).</td></tr>
748: <tr><td class="author-text" valign="top"><a name="RFC1542">[RFC1542]</a></td>
749: <td class="author-text"><a href="mailto:Walter.Wimer@CMU.EDU">Wimer, W.</a>, “<a href="http://tools.ietf.org/html/rfc1542">Clarifications and Extensions for the Bootstrap Protocol</a>,” RFC 1542, October 1993 (<a href="ftp://ftp.isi.edu/in-notes/rfc1542.txt">TXT</a>).</td></tr>
750: <tr><td class="author-text" valign="top"><a name="RFC2131">[RFC2131]</a></td>
751: <td class="author-text"><a href="mailto:droms@bucknell.edu">Droms, R.</a>, “<a href="http://tools.ietf.org/html/rfc2131">Dynamic Host Configuration Protocol</a>,” RFC 2131, March 1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2131.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2131.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2131.xml">XML</a>).</td></tr>
752: <tr><td class="author-text" valign="top"><a name="RFC2132">[RFC2132]</a></td>
753: <td class="author-text"><a href="mailto:sca@engr.sgi.com">Alexander, S.</a> and <a href="mailto:droms@bucknell.edu">R. Droms</a>, “<a href="http://tools.ietf.org/html/rfc2132">DHCP Options and BOOTP Vendor Extensions</a>,” RFC 2132, March 1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2132.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2132.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2132.xml">XML</a>).</td></tr>
754: <tr><td class="author-text" valign="top"><a name="RFC2241">[RFC2241]</a></td>
755: <td class="author-text"><a href="mailto:donp@Novell.Com">Provan, D.</a>, “<a href="http://tools.ietf.org/html/rfc2241">DHCP Options for Novell Directory Services</a>,” RFC 2241, November 1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2241.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2241.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2241.xml">XML</a>).</td></tr>
756: <tr><td class="author-text" valign="top"><a name="RFC2242">[RFC2242]</a></td>
757: <td class="author-text"><a href="mailto:droms@bucknell.edu">Droms, R.</a> and <a href="mailto:kfong@novell.com">K. Fong</a>, “<a href="http://tools.ietf.org/html/rfc2242">NetWare/IP Domain Name and Information</a>,” RFC 2242, November 1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2242.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2242.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2242.xml">XML</a>).</td></tr>
758: <tr><td class="author-text" valign="top"><a name="RFC2485">[RFC2485]</a></td>
759: <td class="author-text"><a href="mailto:drach@sun.com">Drach, S.</a>, “<a href="http://tools.ietf.org/html/rfc2485">DHCP Option for The Open Group's User Authentication Protocol</a>,” RFC 2485, January 1999 (<a href="ftp://ftp.isi.edu/in-notes/rfc2485.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2485.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2485.xml">XML</a>).</td></tr>
760: <tr><td class="author-text" valign="top"><a name="RFC2610">[RFC2610]</a></td>
761: <td class="author-text"><a href="mailto:Charles.Perkins@Sun.Com">Perkins, C.</a> and <a href="mailto:Erik.Guttman@Sun.Com">E. Guttman</a>, “<a href="http://tools.ietf.org/html/rfc2610">DHCP Options for Service Location Protocol</a>,” RFC 2610, June 1999 (<a href="ftp://ftp.isi.edu/in-notes/rfc2610.txt">TXT</a>).</td></tr>
762: <tr><td class="author-text" valign="top"><a name="RFC2937">[RFC2937]</a></td>
763: <td class="author-text">Smith, C., “<a href="http://tools.ietf.org/html/rfc2937">The Name Service Search Option for DHCP</a>,” RFC 2937, September 2000 (<a href="ftp://ftp.isi.edu/in-notes/rfc2937.txt">TXT</a>).</td></tr>
764: <tr><td class="author-text" valign="top"><a name="RFC2939">[RFC2939]</a></td>
765: <td class="author-text">Droms, R., “<a href="http://tools.ietf.org/html/rfc2939">Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types</a>,” BCP 43, RFC 2939, September 2000 (<a href="ftp://ftp.isi.edu/in-notes/rfc2939.txt">TXT</a>).</td></tr>
766: <tr><td class="author-text" valign="top"><a name="RFC3004">[RFC3004]</a></td>
767: <td class="author-text">Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, A., Beser, B., and J. Privat, “<a href="http://tools.ietf.org/html/rfc3004">The User Class Option for DHCP</a>,” RFC 3004, November 2000 (<a href="ftp://ftp.isi.edu/in-notes/rfc3004.txt">TXT</a>).</td></tr>
768: <tr><td class="author-text" valign="top"><a name="RFC3011">[RFC3011]</a></td>
769: <td class="author-text">Waters, G., “<a href="http://tools.ietf.org/html/rfc3011">The IPv4 Subnet Selection Option for DHCP</a>,” RFC 3011, November 2000 (<a href="ftp://ftp.isi.edu/in-notes/rfc3011.txt">TXT</a>).</td></tr>
770: <tr><td class="author-text" valign="top"><a name="RFC3046">[RFC3046]</a></td>
771: <td class="author-text">Patrick, M., “<a href="http://tools.ietf.org/html/rfc3046">DHCP Relay Agent Information Option</a>,” RFC 3046, January 2001 (<a href="ftp://ftp.isi.edu/in-notes/rfc3046.txt">TXT</a>).</td></tr>
772: <tr><td class="author-text" valign="top"><a name="RFC3074">[RFC3074]</a></td>
773: <td class="author-text">Volz, B., Gonczi, S., Lemon, T., and R. Stevens, “<a href="http://tools.ietf.org/html/rfc3074">DHC Load Balancing Algorithm</a>,” RFC 3074, February 2001 (<a href="ftp://ftp.isi.edu/in-notes/rfc3074.txt">TXT</a>).</td></tr>
774: <tr><td class="author-text" valign="top"><a name="RFC3256">[RFC3256]</a></td>
775: <td class="author-text">Jones, D. and R. Woundy, “<a href="http://tools.ietf.org/html/rfc3256">The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option</a>,” RFC 3256, April 2002 (<a href="ftp://ftp.isi.edu/in-notes/rfc3256.txt">TXT</a>).</td></tr>
776: <tr><td class="author-text" valign="top"><a name="RFC3315">[RFC3315]</a></td>
777: <td class="author-text">Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “<a href="http://tools.ietf.org/html/rfc3315">Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</a>,” RFC 3315, July 2003 (<a href="ftp://ftp.isi.edu/in-notes/rfc3315.txt">TXT</a>).</td></tr>
778: <tr><td class="author-text" valign="top"><a name="RFC3319">[RFC3319]</a></td>
779: <td class="author-text">Schulzrinne, H. and B. Volz, “<a href="http://tools.ietf.org/html/rfc3319">Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers</a>,” RFC 3319, July 2003 (<a href="ftp://ftp.isi.edu/in-notes/rfc3319.txt">TXT</a>).</td></tr>
780: <tr><td class="author-text" valign="top"><a name="RFC3396">[RFC3396]</a></td>
781: <td class="author-text">Lemon, T. and S. Cheshire, “<a href="http://tools.ietf.org/html/rfc3396">Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)</a>,” RFC 3396, November 2002 (<a href="ftp://ftp.isi.edu/in-notes/rfc3396.txt">TXT</a>).</td></tr>
782: <tr><td class="author-text" valign="top"><a name="RFC3397">[RFC3397]</a></td>
783: <td class="author-text">Aboba, B. and S. Cheshire, “<a href="http://tools.ietf.org/html/rfc3397">Dynamic Host Configuration Protocol (DHCP) Domain Search Option</a>,” RFC 3397, November 2002 (<a href="ftp://ftp.isi.edu/in-notes/rfc3397.txt">TXT</a>).</td></tr>
784: <tr><td class="author-text" valign="top"><a name="RFC3527">[RFC3527]</a></td>
785: <td class="author-text">Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, “<a href="http://tools.ietf.org/html/rfc3527">Link Selection sub-option for the Relay Agent Information Option for DHCPv4</a>,” RFC 3527, April 2003 (<a href="ftp://ftp.isi.edu/in-notes/rfc3527.txt">TXT</a>).</td></tr>
786: <tr><td class="author-text" valign="top"><a name="RFC3633">[RFC3633]</a></td>
787: <td class="author-text">Troan, O. and R. Droms, “<a href="http://tools.ietf.org/html/rfc3633">IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6</a>,” RFC 3633, December 2003 (<a href="ftp://ftp.isi.edu/in-notes/rfc3633.txt">TXT</a>).</td></tr>
788: <tr><td class="author-text" valign="top"><a name="RFC3646">[RFC3646]</a></td>
789: <td class="author-text">Droms, R., “<a href="http://tools.ietf.org/html/rfc3646">DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</a>,” RFC 3646, December 2003 (<a href="ftp://ftp.isi.edu/in-notes/rfc3646.txt">TXT</a>).</td></tr>
790: <tr><td class="author-text" valign="top"><a name="RFC3679">[RFC3679]</a></td>
791: <td class="author-text">Droms, R., “<a href="http://tools.ietf.org/html/rfc3679">Unused Dynamic Host Configuration Protocol (DHCP) Option Codes</a>,” RFC 3679, January 2004 (<a href="ftp://ftp.isi.edu/in-notes/rfc3679.txt">TXT</a>).</td></tr>
792: <tr><td class="author-text" valign="top"><a name="RFC3898">[RFC3898]</a></td>
793: <td class="author-text">Kalusivalingam, V., “<a href="http://tools.ietf.org/html/rfc3898">Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</a>,” RFC 3898, October 2004 (<a href="ftp://ftp.isi.edu/in-notes/rfc3898.txt">TXT</a>).</td></tr>
794: <tr><td class="author-text" valign="top"><a name="RFC3925">[RFC3925]</a></td>
795: <td class="author-text">Littlefield, J., “<a href="http://tools.ietf.org/html/rfc3925">Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)</a>,” RFC 3925, October 2004 (<a href="ftp://ftp.isi.edu/in-notes/rfc3925.txt">TXT</a>).</td></tr>
796: <tr><td class="author-text" valign="top"><a name="RFC3942">[RFC3942]</a></td>
797: <td class="author-text">Volz, B., “<a href="http://tools.ietf.org/html/rfc3942">Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options</a>,” RFC 3942, November 2004 (<a href="ftp://ftp.isi.edu/in-notes/rfc3942.txt">TXT</a>).</td></tr>
798: <tr><td class="author-text" valign="top"><a name="RFC4075">[RFC4075]</a></td>
799: <td class="author-text">Kalusivalingam, V., “<a href="http://tools.ietf.org/html/rfc4075">Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6</a>,” RFC 4075, May 2005 (<a href="ftp://ftp.isi.edu/in-notes/rfc4075.txt">TXT</a>).</td></tr>
800: <tr><td class="author-text" valign="top"><a name="RFC4242">[RFC4242]</a></td>
801: <td class="author-text">Venaas, S., Chown, T., and B. Volz, “<a href="http://tools.ietf.org/html/rfc4242">Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</a>,” RFC 4242, November 2005 (<a href="ftp://ftp.isi.edu/in-notes/rfc4242.txt">TXT</a>).</td></tr>
802: <tr><td class="author-text" valign="top"><a name="RFC4280">[RFC4280]</a></td>
803: <td class="author-text">Chowdhury, K., Yegani, P., and L. Madour, “<a href="http://tools.ietf.org/html/rfc4280">Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers</a>,” RFC 4280, November 2005 (<a href="ftp://ftp.isi.edu/in-notes/rfc4280.txt">TXT</a>).</td></tr>
804: <tr><td class="author-text" valign="top"><a name="RFC4388">[RFC4388]</a></td>
805: <td class="author-text">Woundy, R. and K. Kinnear, “<a href="http://tools.ietf.org/html/rfc4388">Dynamic Host Configuration Protocol (DHCP) Leasequery</a>,” RFC 4388, February 2006 (<a href="ftp://ftp.isi.edu/in-notes/rfc4388.txt">TXT</a>).</td></tr>
806: <tr><td class="author-text" valign="top"><a name="RFC4580">[RFC4580]</a></td>
807: <td class="author-text">Volz, B., “<a href="http://tools.ietf.org/html/rfc4580">Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option</a>,” RFC 4580, June 2006 (<a href="ftp://ftp.isi.edu/in-notes/rfc4580.txt">TXT</a>).</td></tr>
808: <tr><td class="author-text" valign="top"><a name="RFC4649">[RFC4649]</a></td>
809: <td class="author-text">Volz, B., “<a href="http://tools.ietf.org/html/rfc4649">Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option</a>,” RFC 4649, August 2006 (<a href="ftp://ftp.isi.edu/in-notes/rfc4649.txt">TXT</a>).</td></tr>
810: <tr><td class="author-text" valign="top"><a name="RFC4701">[RFC4701]</a></td>
811: <td class="author-text">Stapp, M., Lemon, T., and A. Gustafsson, “<a href="http://tools.ietf.org/html/rfc4701">A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)</a>,” RFC 4701, October 2006 (<a href="ftp://ftp.isi.edu/in-notes/rfc4701.txt">TXT</a>).</td></tr>
812: <tr><td class="author-text" valign="top"><a name="RFC4702">[RFC4702]</a></td>
813: <td class="author-text">Stapp, M., Volz, B., and Y. Rekhter, “<a href="http://tools.ietf.org/html/rfc4702">The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option</a>,” RFC 4702, October 2006 (<a href="ftp://ftp.isi.edu/in-notes/rfc4702.txt">TXT</a>).</td></tr>
814: <tr><td class="author-text" valign="top"><a name="RFC4703">[RFC4703]</a></td>
815: <td class="author-text">Stapp, M. and B. Volz, “<a href="http://tools.ietf.org/html/rfc4703">Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients</a>,” RFC 4703, October 2006 (<a href="ftp://ftp.isi.edu/in-notes/rfc4703.txt">TXT</a>).</td></tr>
816: <tr><td class="author-text" valign="top"><a name="RFC4704">[RFC4704]</a></td>
817: <td class="author-text">Volz, B., “<a href="http://tools.ietf.org/html/rfc4704">The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option</a>,” RFC 4704, October 2006 (<a href="ftp://ftp.isi.edu/in-notes/rfc4704.txt">TXT</a>).</td></tr>
818: <tr><td class="author-text" valign="top"><a name="draft-failover">[draft-failover]</a></td>
819: <td class="author-text">Droms, R., “<a href="https://www.isc.org/sw/dhcp/drafts/draft-ietf-dhc-failover-12.txt">DHCP Failover Protocol</a>,” March 2003.</td></tr>
820: </table>
821:
822: <a name="rfc.authors"></a><br /><hr />
823: <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
824: <h3>Author's Address</h3>
825: <table width="99%" border="0" cellpadding="0" cellspacing="0">
826: <tr><td class="author-text"> </td>
827: <td class="author-text">David W. Hankins</td></tr>
828: <tr><td class="author-text"> </td>
829: <td class="author-text">Internet Systems Consortium,
830: Inc.</td></tr>
831: <tr><td class="author-text"> </td>
832: <td class="author-text">950 Charter Street</td></tr>
833: <tr><td class="author-text"> </td>
834: <td class="author-text">Redwood City, CA 94063</td></tr>
835: <tr><td class="author" align="right">Phone: </td>
836: <td class="author-text">+1 650 423 1300</td></tr>
837: <tr><td class="author" align="right">Email: </td>
838: <td class="author-text"><a href="mailto:David_Hankins@isc.org">David_Hankins@isc.org</a></td></tr>
839: </table>
840: </body></html>
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to References.html 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