embedaddon/dhcp/doc/References.html - view

File: [ELWIX - Embedded LightWeight unIX -] / embedaddon / dhcp / doc / References.html
Revision 1.1.1.1 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Tue Oct 9 09:06:54 2012 UTC (12 years ago) by misho
Branches: dhcp, MAIN
CVS tags: v4_1_R7p0, v4_1_R7, v4_1_R4, HEAD

dhcp 4.1 r7

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'></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>