diff options
Diffstat (limited to 'doc/References.html')
| -rw-r--r-- | doc/References.html | 804 |
1 files changed, 804 insertions, 0 deletions
diff --git a/doc/References.html b/doc/References.html new file mode 100644 index 00000000..8f8a6814 --- /dev/null +++ b/doc/References.html @@ -0,0 +1,804 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> +<html lang="en"><head><title>ISC-DHCP-REFERENCES: ISC DHCP References Collection</title> +<meta http-equiv="Expires" content="Fri, 13 Apr 2007 18:37:11 +0000"> +<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> +<meta name="description" content="ISC DHCP References Collection"> +<meta name="keywords" content="ISC, DHCP, Reference Implementation"> +<meta name="generator" content="xml2rfc v1.30 (http://xml.resource.org/)"> +<style type='text/css'> +<!-- + body { + font-family: verdana, charcoal, helvetica, arial, sans-serif; + margin: 2em; + font-size: small ; color: #000000 ; background-color: #ffffff ; } + .title { color: #990000; font-size: x-large ; + font-weight: bold; text-align: right; + font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif; + background-color: transparent; } + .filename { color: #666666; font-size: 18px; line-height: 28px; + font-weight: bold; text-align: right; + font-family: helvetica, arial, sans-serif; + background-color: transparent; } + td.rfcbug { background-color: #000000 ; width: 30px ; height: 30px ; + text-align: justify; vertical-align: middle ; padding-top: 2px ; } + td.rfcbug span.RFC { color: #666666; font-weight: bold; text-decoration: none; + background-color: #000000 ; + font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; + font-size: x-small ; } + td.rfcbug span.hotText { color: #ffffff; font-weight: normal; text-decoration: none; + text-align: center ; + font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; + font-size: x-small ; background-color: #000000; } + /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */ + div#counter{margin-top: 100px} + + a.info{ + position:relative; /*this is the key*/ + z-index:24; + text-decoration:none} + + a.info:hover{z-index:25; background-color:#990000 ; color: #ffffff ;} + + a.info span{display: none} + + a.info:hover span.info{ /*the span will display just on :hover state*/ + display:block; + position:absolute; + font-size: smaller ; + top:2em; left:2em; width:15em; + padding: 2px ; + border:1px solid #333333; + background-color:#eeeeee; color:#990000; + text-align: left ;} + + A { font-weight: bold; } + A:link { color: #990000; background-color: transparent ; } + A:visited { color: #333333; background-color: transparent ; } + A:active { color: #333333; background-color: transparent ; } + + p { margin-left: 2em; margin-right: 2em; } + p.copyright { font-size: x-small ; } + p.toc { font-size: small ; font-weight: bold ; margin-left: 3em ;} + table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; } + td.toc { font-size: small; font-weight: bold; vertical-align: text-top; } + + span.emph { font-style: italic; } + span.strong { font-weight: bold; } + span.verb, span.vbare { font-family: "Courier New", Courier, monospace ; } + + span.vemph { font-style: italic; font-family: "Courier New", Courier, monospace ; } + span.vstrong { font-weight: bold; font-family: "Courier New", Courier, monospace ; } + span.vdeluxe { font-weight: bold; font-style: italic; font-family: "Courier New", Courier, monospace ; } + + ol.text { margin-left: 2em; margin-right: 2em; } + ul.text { margin-left: 2em; margin-right: 2em; } + li { margin-left: 3em; } + + pre { margin-left: 3em; color: #333333; background-color: transparent; + font-family: "Courier New", Courier, monospace ; font-size: small ; + text-align: left; + } + + h3 { color: #333333; font-size: medium ; + font-family: helvetica, arial, sans-serif ; + background-color: transparent; } + h4 { font-size: small; font-family: helvetica, arial, sans-serif ; } + + table.bug { width: 30px ; height: 15px ; } + td.bug { color: #ffffff ; background-color: #990000 ; + text-align: center ; width: 30px ; height: 15px ; + } + td.bug A.link2 { color: #ffffff ; font-weight: bold; + text-decoration: none; + font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif; + font-size: x-small ; background-color: transparent } + + td.header { color: #ffffff; font-size: x-small ; + font-family: arial, helvetica, sans-serif; vertical-align: top; + background-color: #666666 ; width: 33% ; } + td.author { font-weight: bold; margin-left: 4em; font-size: x-small ; } + td.author-text { font-size: x-small; } + table.full { vertical-align: top ; border-collapse: collapse ; + border-style: solid solid solid solid ; + border-color: black black black black ; + font-size: small ; text-align: center ; } + table.headers, table.none { vertical-align: top ; border-collapse: collapse ; + border-style: none; + font-size: small ; text-align: center ; } + table.full th { font-weight: bold ; + border-style: solid ; + border-color: black black black black ; } + table.headers th { font-weight: bold ; + border-style: none none solid none; + border-color: black black black black ; } + table.none th { font-weight: bold ; + border-style: none; } + table.full td { + border-style: solid solid solid solid ; + border-color: #333333 #333333 #333333 #333333 ; } + table.headers td, table.none td { border-style: none; } + + hr { height: 1px } +--> +</style> +</head> +<body> +<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> +<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1"> +<tr><td class="header">ISC-DHCP-REFERENCES</td><td class="header">D. Hankins</td></tr> +<tr><td class="header"> </td><td class="header">ISC</td></tr> +<tr><td class="header"> </td><td class="header">August 2006</td></tr> +</table></td></tr></table> +<div align="right"><span class="title"><br />ISC DHCP References Collection</span></div> + +<h3>Copyright Notice</h3> + +<p>Copyright (c) 2006-2007 by Internet Systems Consortium, Inc. + ("ISC") +</p> +<p>Permission to use, copy, modify, and distribute this software for + any purpose with or without fee is hereby granted, provided that the + above copyright notice and this permission notice appear in all + copies. +</p> +<p>THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES + WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR + ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT + OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +</p> +<h3>Abstract</h3> + +<p>This document describes a collection of Reference material that + ISC DHCP has been implemented to. +</p><a name="toc"></a><br /><hr /> +<h3>Table of Contents</h3> +<p class="toc"> +<a href="#anchor1">1.</a> +Introduction<br /> +<br /> +<a href="#anchor2">2.</a> +Definition: Reference Implementation<br /> +<br /> +<a href="#anchor3">3.</a> +Low Layer References<br /> + <a href="#anchor4">3.1.</a> +Ethernet Protocol References<br /> + <a href="#anchor5">3.2.</a> +Token Ring Protocol References<br /> + <a href="#anchor6">3.3.</a> +FDDI Protocol References<br /> + <a href="#anchor7">3.4.</a> +Internet Protocol Version 4 References<br /> + <a href="#anchor8">3.5.</a> +Unicast Datagram Protocol References<br /> +<br /> +<a href="#anchor9">4.</a> +BOOTP Protocol References<br /> +<br /> +<a href="#anchor10">5.</a> +DHCP Protocol References<br /> + <a href="#anchor11">5.1.</a> +DHCPv4 Protocol<br /> + <a href="#anchor12">5.1.1.</a> +Core Protocol References<br /> + <a href="#anchor13">5.2.</a> +DHCPv6 Protocol References<br /> + <a href="#anchor14">5.3.</a> +DHCP Option References<br /> + <a href="#anchor15">5.3.1.</a> +Relay Agent Information Option Options<br /> + <a href="#anchor16">5.3.2.</a> +Dynamic DNS Updates References<br /> + <a href="#anchor17">5.3.3.</a> +Experimental: Failover References<br /> + <a href="#anchor18">5.4.</a> +DHCP Procedures<br /> +<br /> +<a href="#rfc.references1">6.</a> +References<br /> +<br /> +<a href="#rfc.authors">§</a> +Author's Address<br /> +</p> +<br clear="all" /> + +<a name="anchor1"></a><br /><hr /> +<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> +<a name="rfc.section.1"></a><h3>1. Introduction</h3> + +<p>As a little historical anecdote, ISC DHCP once packaged all the + relevant RFCs and standards documents along with the software + package. Until one day when a voice was heard from one of the + many fine institutions that build and distribute this software... + they took issue with the IETF's copyright on the RFC's. It + seems the IETF's copyrights don't allow modification of RFC's + (except for translation purposes). +</p> +<p>Our main purpose in providing the RFCs is to aid in + documentation, but since RFCs are now available widely from many + points of distribution on the Internet, there is no real need to + provide the documents themselves. So, this document has been + created in their stead, to list the various IETF RFCs one might + want to read, and to comment on how well (or poorly) we have + managed to implement them. +</p> +<a name="anchor2"></a><br /><hr /> +<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> +<a name="rfc.section.2"></a><h3>2. Definition: Reference Implementation</h3> + +<p>ISC DHCP, much like its other cousins in ISC software, is + self-described as a 'Reference Implementation.' There has been + a great deal of confusion about this term. Some people seem to + think that this term applies to any software that once passed + a piece of reference material on its way to market (but may do + quite a lot of things that aren't described in any reference, or + may choose to ignore the reference it saw entirely). Other folks + get confused by the word 'reference' and understand that to mean + that there is some special status applied to the software - that + the software itself is the reference by which all other software + is measured. Something along the lines of being "The DHCP + Protocol's Reference Clock," it is supposed. +</p> +<p>The truth is actually quite a lot simpler. Reference + implementations are software packages which were written + to behave precisely as appears in reference material. They + are written "to match reference." +</p> +<p>If the software has a behaviour that manifests itself + externally (whether it be something as simple as the 'wire + format' or something higher level, such as a complicated + behaviour that arises from multiple message exchanges), that + behaviour must be found in a reference document. +</p> +<p>Anything else is a bug, the only question is whether the + bug is in reference or software (failing to implement the + reference). +</p> +<p>This means: +</p> +<ul class="text"> +<li>To produce new externally-visible behaviour, one must first + provide a reference. +</li> +<li>Before changing externally visible behaviour to work around + simple incompatibilities in any other implementation, one must + first provide a reference. +</li> +</ul> +<p>That is the lofty goal, at any rate. It's well understood that, + especially because the ISC DHCP Software package has not always been + held to this standard (but not entirely due to it), there are many + non-referenced behaviours within ISC DHCP. +</p> +<p>The primary goal of reference implementation is to prove the + reference material. If the reference material is good, then you + should be able to sit down and write a program that implements the + reference, to the word, and come to an implementation that + is distinguishable from others in the details, but not in the + facts of operating the protocol. This means that there is no + need for 'special knowledge' to work around arcane problems that + were left undocumented. No secret handshakes need to be learned + to be imparted with the necessary "real documentation". +</p> +<p>Also, by accepting only reference as the guidebook for ISC + DHCP's software implementation, anyone who can make an impact on + the color texture or form of that reference has a (somewhat + indirect) voice in ISC DHCP's software design. As the IETF RFC's + have been selected as the source of reference, that means everyone + on the Internet with the will to participate has a say. +</p> +<a name="anchor3"></a><br /><hr /> +<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> +<a name="rfc.section.3"></a><h3>3. Low Layer References</h3> + +<p>It may surprise you to realize that ISC DHCP implements 802.1 + 'Ethernet' framing, Token Ring, and FDDI. In order to bridge the + gap there between these physical and DHCP layers, it must also + implement IP and UDP framing. +</p> +<p>The reason for this stems from Unix systems' handling of BSD + sockets (the general way one might engage in transmission of UDP + packets) on unconfigured interfaces, or even the handling of + broadcast addressing on configured interfaces. +</p> +<p>There are a few things that DHCP servers, relays, and clients all + need to do in order to speak the DHCP protocol in strict compliance + 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]. +</p> +<ol class="text"> +<li>Transmit a UDP packet from IP:0.0.0.0 Ethernet:Self, destined to + IP:255.255.255.255 LinkLayer:Broadcast on an unconfigured (no IP + address yet) interface. +</li> +<li>Receive a UDP packet from IP:remote-system LinkLayer:remote-system, + destined to IP:255.255.255.255 LinkLayer:Broadcast, again on an + unconfigured interface. +</li> +<li>Transmit a UDP packet from IP:Self, Ethernet:Seelf, destined to + IP:remote-system LinkLayer:remote-system, without transmitting a + single ARP. +</li> +<li>And of course the simple case, a regular IP unicast that is + routed via the usual means (so it may be direct to a local system, + with ARP providing the glue, or it may be to a remote system via + one or more routers as normal). In this case, the interfaces are + always configured. +</li> +</ol> +<p>The above isn't as simple as it sounds on a regular BSD socket. + Many unix implementations will transmit broadcasts not to + 255.255.255.255, but to x.y.z.255 (where x.y.z is the system's local + subnet). Such packets are not received by several known DHCP client + 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 + destination addresses be set to 255.255.255.255. +</p> +<p>Receiving packets sent to 255.255.255.255 isn't a problem on most + modern unixes...so long as the interface is configured. When there + is no IPv4 address on the interface, things become much more murky. +</p> +<p>So, for this convoluted and unfortunate state of affairs in the + unix systems of the day ISC DHCP was manufactured, in order to do + what it needs not only to implement the reference but to interoperate + with other implementations, the software must create some form of + raw socket to operate on. +</p> +<p>What it actually does is create, for each interface detected on + the system, a Berkeley Packet Filter socket (or equivalent), and + program it with a filter that brings in only DHCP packets. A + "fallback" UDP Berkeley socket is generally also created, a single + one no matter how many interfaces. Should the software need to + transmit a contrived packet to the local network the packet is + formed piece by piece and transmitted via the BPF socket. Hence + the need to implement many forms of Link Layer framing and above. + The software gets away with not having to implement IP routing + tables as well by simply utilizing the aforementioned 'fallback' + UDP socket when unicasting between two configured systems is the + need. +</p> +<p>Modern unixes have opened up some facilities that diminish how + much of this sort of nefarious kludgery is necessary, but have not + found the state of affairs absolutely absolved. In particular, + one might now unicast without ARP by inserting an entry into the + ARP cache prior to transmitting. Unconfigured interfaces remain + the sticking point, however...on virtually no modern unixes is + it possible to receive broadcast packets unless a local IPv4 + address has been configured, unless it is done with raw sockets. +</p> +<a name="anchor4"></a><br /><hr /> +<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> +<a name="rfc.section.3.1"></a><h3>3.1. Ethernet Protocol References</h3> + +<p>ISC DHCP Implements Ethernet Version 2 ("DIX"), which is a variant + of IEEE 802.2. No good reference of this framing is known to exist + 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 + the following URL is also thought to be useful. +</p> +<p>http://en.wikipedia.org/wiki/DIX +</p> +<a name="anchor5"></a><br /><hr /> +<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> +<a name="rfc.section.3.2"></a><h3>3.2. Token Ring Protocol References</h3> + +<p>IEEE 802.5 defines the Token Ring framing format used by ISC + DHCP. +</p> +<a name="anchor6"></a><br /><hr /> +<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> +<a name="rfc.section.3.3"></a><h3>3.3. FDDI Protocol References</h3> + +<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 + reference ISC DHCP has used to form FDDI packets. +</p> +<a name="anchor7"></a><br /><hr /> +<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> +<a name="rfc.section.3.4"></a><h3>3.4. Internet Protocol Version 4 References</h3> + +<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 + bare IPv4 protocol which ISC DHCP implements. +</p> +<a name="anchor8"></a><br /><hr /> +<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> +<a name="rfc.section.3.5"></a><h3>3.5. Unicast Datagram Protocol References</h3> + +<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 + Protocol that ultimately carries the DHCP or BOOTP protocol. The + destination DHCP server port is 67, the client port is 68. Source + ports are irrelevant. +</p> +<a name="anchor9"></a><br /><hr /> +<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> +<a name="rfc.section.4"></a><h3>4. BOOTP Protocol References</h3> + +<p>The DHCP Protocol is strange among protocols in that it is + grafted over the top of another protocol - BOOTP (but we don't + call it "DHCP over BOOTP" like we do, say "TCP over IP"). BOOTP + and DHCP share UDP packet formats - DHCP is merely a conventional + use of both BOOTP header fields and the trailing 'options' space. +</p> +<p>The ISC DHCP server supports BOOTP clients conforming to + <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]. +</p> +<a name="anchor10"></a><br /><hr /> +<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> +<a name="rfc.section.5"></a><h3>5. DHCP Protocol References</h3> + +<a name="anchor11"></a><br /><hr /> +<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> +<a name="rfc.section.5.1"></a><h3>5.1. DHCPv4 Protocol</h3> + +<p>"The DHCP[v4] Protocol" is not defined in a single document. The + following collection of references of what ISC DHCP terms "The + DHCPv4 Protocol". +</p> +<a name="anchor12"></a><br /><hr /> +<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> +<a name="rfc.section.5.1.1"></a><h3>5.1.1. Core Protocol References</h3> + +<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 + and procedures. ISC DHCP is not known to diverge from this document + in any way. There are, however, a few points on which different + implementations have arisen out of vagueries in the document. + DHCP Clients exist which, at one time, present themselves as using + a Client Identifier Option which is equal to the client's hardware + address. Later, the client transmits DHCP packets with no Client + Identifier Option present - essentially identifying themselves using + the hardware address. Some DHCP Servers have been developed which + identify this client as a single client. ISC has interpreted + RFC2131 to indicate that these clients must be treated as two + separate entities (and hence two, separate addresses). Client + behaviour (Embedded Windows products) has developed that relies on + the former implementation, and hence is incompatible with the + latter. Also, RFC2131 demands explicitly that some header fields + be zeroed upon certain message types. The ISC DHCP Server instead + copies many of these fields from the packet received from the client + or relay, which may not be zero. It is not known if there is a good + reason for this that has not been documented. +</p> +<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 + DHCP Options and provides a great deal of guidance on how to go about + formatting and processing options. The document unfortunately + waffles to a great extent about the NULL termination of DHCP Options, + and some DHCP Clients (Windows 95) have been implemented that rely + upon DHCP Options containing text strings to be NULL-terminated (or + else they crash). So, ISC DHCP detects if clients null-terminate the + host-name option and, if so, null terminates any text options it + transmits to the client. It also removes NULL termination from any + known text option it receives prior to any other processing. +</p> +<a name="anchor13"></a><br /><hr /> +<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> +<a name="rfc.section.5.2"></a><h3>5.2. DHCPv6 Protocol References</h3> + +<p>For now there is only one document that specifies the DHCPv6 + 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]. +</p> +<p>Support for DHCPv6 was added first in version 4.0.0. The server + and client support only IA_NA. While the server does support multiple + IA_NAs within one packet from the client, our client only supports + sending one. There is no relay support. +</p> +<p>DHCPv6 introduces some new and uncomfortable ideas to the common + software library. +</p> +<ol class="text"> +<li>Options of zero length are normal in DHCPv6. Currently, all + ISC DHCP software treats zero-length options as errors. +</li> +<li>Options sometimes may appear multiple times. The common + library used to treat all appearance of multiple options as + specified in RFC2131 - to be concatenated. DHCPv6 options + may sometimes appear multiple times (such as with IA_NA or + IAADDR), but often must not. +</li> +<li>The same option space appears in DHCPv6 packets multiple times. + If the packet was got via a relay, then the client's packet is + stored to an option within the relay's packet...if there were two + relays, this recurses. At each of these steps, the root "DHCPv6 + option space" is used. Further, a client packet may contain an + IA_NA, which may contain an IAADDR - but really, in an abstract + sense, this is again re-encapsulation of the DHCPv6 option space + beneath options it also contains. +</li> +</ol> +<p>Precisely how to correctly support the above conundrums has not + quite yet been settled, so support is incomplete. +</p> +<a name="anchor14"></a><br /><hr /> +<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> +<a name="rfc.section.5.3"></a><h3>5.3. DHCP Option References</h3> + +<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 + Novell Directory Services. +</p> +<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 + option space for NWIP configuration. +</p> +<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 + UAP option. +</p> +<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 + the Service Location Protocol (SLP). +</p> +<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 + Search Option (not to be confused with the domain-search option). + The Name Service Search Option allows eg nsswitch.conf to be + reconfigured via dhcp. The ISC DHCP server implements this option, + and the ISC DHCP client is compatible...but does not by default + install this option's value. One would need to make their relevant + dhclient-script process this option in a way that is suitable for + the system. +</p> +<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 + option. Note carefully that ISC DHCP currently does not implement + to this reference, but has (inexplicably) selected an incompatible + format: a plain text string. +</p> +<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 + plain DHCPv4 option. Do not confuse this option with the relay agent + "link selection" sub-option, although their behaviour is similar. +</p> +<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 + options for DHCPv6. +</p> +<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 + options may be encoded in DHCPv4 packets, and also how multiple + instances of the same option code within a DHCPv4 packet will be + decoded by receivers. +</p> +<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 + Option, which allows the configuration of the /etc/resolv.conf + '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 + format). ISC DHCP has both client and server support, and supports + RFC1035 name compression. +</p> +<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 + name-servers and domain-search options. +</p> +<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 + Association Prefix Delegation, which is included here for protocol + wire reference, but which is not supported by ISC DHCP. +</p> +<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 + options that were documented earlier in history, but were not + made use of. +</p> +<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 + for delivering NIS servers and domain information in DHCPv6. +</p> +<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 + Enterprise-ID delimited option spaces for vendors to use in order + to inform servers of their "vendor class" (sort of like 'uname' + or 'who and what am I'), and a means to deliver vendor-specific + and vendor-documented option codes and values. +</p> +<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' + option space. +</p> +<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 + Servers option. +</p> +<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 + Refresh Time option, which advises DHCPv6 Information-Request + clients to return for updated information. +</p> +<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 + options. +</p> +<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 + LEASEQUERY message type and a number of suitable response messages, + for the purpose of sharing information about DHCP served addresses + and clients. +</p> +<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 + subscriber-id option, which is similar in principle to the DHCPv4 + relay agent option of the same name. +</p> +<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 + option, which is similar in principle to the DHCPv4 relay agent + remote-id. +</p> +<a name="anchor15"></a><br /><hr /> +<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> +<a name="rfc.section.5.3.1"></a><h3>5.3.1. Relay Agent Information Option Options</h3> + +<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 + Information Option and provides a number of sub-option + definitions. +</p> +<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 + Class sub-option. +</p> +<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 + sub-option. +</p> +<a name="anchor16"></a><br /><hr /> +<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> +<a name="rfc.section.5.3.2"></a><h3>5.3.2. Dynamic DNS Updates References</h3> + +<p>The collection of documents that describe the standards-based + method to update dns names of DHCP clients starts most easily + 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 + 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] + 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 + DHCPv6 FQDN options (to carry the client name), and ends up at + <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 + RR used in DNS to perform a kind of atomic locking. +</p> +<p>ISC DHCP adoped early versions of these documents, and has not + yet synched up with the final standards versions. +</p> +<p>For RFCs 4702 and 4704, the 'N' bit is not yet supported. The + result is that it is always set zero, and is ignored if set. +</p> +<p>For RFC4701, which is used to match client identities with names + in the DNS as part of name conflict resolution. Note that ISC DHCP's + implementation of DHCIDs vary wildly from this specification. + First, ISC DHCP uses a TXT record in which the contents are stored + in hexadecimal. Second, there is a flaw in the selection of the + 'Identifier Type', which results in a completely different value + being selected than was defined in an older revision of this + document...also this field is one byte prior to hexadecimal + encoding rather than two. Third, ISC DHCP does not use a digest + type code. Rather, all values for such TXT records are reached + via an MD5 sum. In short, nothing is compatible, but the + principle of the TXT record is the same as the standard DHCID + record. However, for DHCPv6 FQDN, we do use DHCID type code '2', + as no other value really makes sense in our context. +</p> +<a name="anchor17"></a><br /><hr /> +<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> +<a name="rfc.section.5.3.3"></a><h3>5.3.3. Experimental: Failover References</h3> + +<p>The Failover Protocol defines a means by which two DHCP Servers + can share all the relevant information about leases granted to + DHCP clients on given networks, so that one of the two servers may + fail and be survived by a server that can act responsibly. +</p> +<p>Unfortunately it has been quite some years since the last time + this document was edited, and the authors no longer show any + interest in fielding comments or improving the document. +</p> +<p>The status of this protocol is very unsure, but ISC's + implementation of it has proven stable and suitable for use in + sizable production environments. +</p> +<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] + describes the Failover Protocol. In addition to what is described + in this document, ISC DHCP has elected to make some experimental + changes that may be revoked in a future version of ISC DHCP (if the + draft authors do not adopt the new behaviour). Specifically, ISC + DHCP's POOLREQ behaviour differs substantially from what is + documented in the draft, and the server also implements a form of + 'MAC Address Affinity' which is not described in the failover + document. The full nature of these changes have been described on + the IETF DHC WG mailing list (which has archives), and also in ISC + DHCP's manual pages. Also note that although this document + references a RECOVER-WAIT state, it does not document a protocol + number assignment for this state. As a consequence, ISC DHCP has + elected to use the value 254. +</p> +<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 + Algorithm (LBA) that ISC DHCP uses in concert with the Failover + protocol. Note that versions 3.0.* are known to misimplement the + hash algorithm (it will only use the low 4 bits of every byte of + the hash bucket array). +</p> +<a name="anchor18"></a><br /><hr /> +<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> +<a name="rfc.section.5.4"></a><h3>5.4. DHCP Procedures</h3> + +<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 + obtaining a new DHCP Option code assignment. +</p> +<a name="rfc.references1"></a><br /><hr /> +<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> +<h3>6. References</h3> +<table width="99%" border="0"> +<tr><td class="author-text" valign="top"><a name="RFC0760">[1]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC0768">[2]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC0894">[3]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC0951">[4]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC1035">[5]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC1188">[6]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC1542">[7]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC2131">[8]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC2132">[9]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC2241">[10]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC2242">[11]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC2485">[12]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC2610">[13]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC2937">[14]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC2939">[15]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC3004">[16]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC3011">[17]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC3046">[18]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC3074">[19]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC3256">[20]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC3315">[21]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC3319">[22]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC3396">[23]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC3397">[24]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC3527">[25]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC3633">[26]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC3646">[27]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC3679">[28]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC3898">[29]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC3925">[30]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC3942">[31]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC4075">[32]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC4242">[33]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC4280">[34]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC4388">[35]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC4580">[36]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC4649">[37]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC4701">[38]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC4702">[39]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC4703">[40]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="RFC4704">[41]</a></td> +<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> +<tr><td class="author-text" valign="top"><a name="draft-failover">[42]</a></td> +<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> +</table> + +<a name="rfc.authors"></a><br /><hr /> +<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> +<h3>Author's Address</h3> +<table width="99%" border="0" cellpadding="0" cellspacing="0"> +<tr><td class="author-text"> </td> +<td class="author-text">David W. Hankins</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Internet Systems Consortium, + Inc.</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">950 Charter Street</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Redwood City, CA 94063</td></tr> +<tr><td class="author" align="right">Phone: </td> +<td class="author-text">+1 650 423 1300</td></tr> +<tr><td class="author" align="right">Email: </td> +<td class="author-text"><a href="mailto:David_Hankins@isc.org">David_Hankins@isc.org</a></td></tr> +</table> +</body></html> |