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